I’ve just uploaded a first ver­sion of ele­mentZap­per, a very small Google Chrome exten­sion that’ll allow you to quickly & eas­ily remove ele­ments on any Web page.

Its usage is rather sim­ple: select any­thing on the page, right click and select “Zap!” and the selected ele­ments will be removed from the page. It’s par­tic­u­larly use­ful for print­ing only what is rel­e­vant to you.

My goal with this exten­sion was to dis­cover Google Chrome’s exten­sion devel­op­ment, mainly out of curios­ity.. Now I can say that it’s pretty neat and easy to get started :)

ele­mentZap­per is avail­able on the Chrome Web Store: https://chrome.google.com/webstore/detail/elementzapper/efeljanahmlnjhckmohcfbgkfdjdmnog?hl=en

Also, for those inter­ested, the source code is avail­able on GitHub: https://github.com/dsebastien/elementZapper

Last week I fin­ished read­ing this book called “The Power of LESS” which is all about doing less and get­ting more done. The author (Leo Babauta, also author of the Zen Habits blog) pro­vides all kinds of tips and tricks designed to help you iden­tify, pri­or­i­tize and con­cen­trate on what’s essen­tial for *you* (whether short or long term) as well as ways to avoid get­ting side­tracked along the way. The book also illus­trates how you can moti­vate your­self and change your behav­ior, which is key to cre­at­ing new habits.

Over­all, The Power of LESS is in the same cat­e­gory as David Allen’s excel­lent book called “Get­ting Things Done” which describes a sim­ple & effi­cient time man­age­ment method­ol­ogy. I see both of these books as com­ple­men­tary since they’re like two sides of the same coin. On one side you want to de-clutter your life, avoid over-commitment and con­cen­trate on what mat­ters while on the other, you want to be effi­cient in what­ever you do and the only way to achieve that is to be organized.

You might argue that such books are bor­ing as hell and/or that they are full of **** …and that might be true — to some extent. It’s true that a lot of the mate­r­ial pre­sented in these is just com­mon sense, but the thing is that most peo­ple never try to ana­lyze the use they make of their time; they just com­plain about the fact that there aren’t enough hours in a day and they fail to tackle the real prob­lem: their behav­ior, their orga­ni­za­tion, their “sys­tem”. I’ll write about my own man­age­ment “sys­tem”, but that’s for another day!

Read­ing books such as “The Power of LESS” or “Get­ting Things Done” has the huge ben­e­fit that it forces you to con­sciously think about the use that you make of your time (the sin­gle most valu­able cur­rency that we have at our dis­posal) and just by doing that, you can iden­tify waste. Try this once: ana­lyze your Inter­net usage for a week. How long do you spend surf­ing the Inter­webs each day? Is the time invest­ment worth it? Can it be reduced and spent doing some­thing else that might have more impact on your life?

At some point in his book, Leo Babauta pro­poses a set of habits that might be use­ful to inte­grate in our lives. One of these being to do some exer­cises daily. I’ve heard count­less times that exer­cis­ing reg­u­larly helps lower the risks of car­dio­vas­cu­lar dis­eases, help you con­trol your weight, etc, but at the end of the day that didn’t moti­vate me enough to start exercising.

Think­ing about that made me real­ize that it had been like for­ever since I last exer­cised (well did you ever exer­cise you may ask? … fair ques­tion for sure ;-)).

Just for fun, I then decided to inte­grate that habit in my daily routine.

Result after 15 days:

My cur­rent progress

I started with abs only. On the first day, I’ve tried doing as many as I could (just to see whether I would sur­vive, oth­er­wise there’d be no point in con­tin­u­ing :p). Ret­ro­spec­tively that was a mis­take, as I felt very demo­ti­vated a few days later. The thing is that I just set the bar too high all at once and dur­ing the days that fol­lowed, I’ve just tried to push fur­ther, but I didn’t have enough mar­gin for improve­ment (you just can’t go from 10 to 100 in two days :p

That explains the huge drop on the fifth day. After that, I felt pretty bad because I was already aban­don­ing and dur­ing the fol­low­ing days I set out to con­tinue and tried to do more each day with­out push­ing too hard.

After 15 days, I’m pretty happy with the results; I already feel a huge dif­fer­ence and as the graph shows, I keep improv­ing the num­ber of abs I’m able to do each day.

You might have noticed that I have skipped two exer­cise ses­sions in the last days. I don’t really feel bad about it because I didn’t have a choice for these two. I’ll report on my progress in the com­ing weeks.

Next to the abs ses­sions in the evening and see­ing my progress, I’ve also decided to add other habits to my daily routine:

• speed walk­ing between the train sta­tion & my work place (5 min­utes in the morn­ing & afternoon)
• tak­ing the stairs when­ever I can instead of lifts & escalators

I wanted to con­tinue this post series but time goes by sooooo quickly (and I’m in a quite lazy mood lately).

Any­way, back for a new fea­ture that Java has brought us: mul­ti­ple catch clauses. And hon­estly, even if it’s a lit­tle one com­pared to other fea­tures, I find it a great addi­tion to the Java developer’s toolkit. We (should) always seek to improve our code and reduce main­te­nance costs through refac­tor­ing etc, but some­times the lan­guage doesn’t help.

Han­dling excep­tions has been one area where code rep­e­ti­tion often comes up. You’ve prob­a­bly all writ­ten stuff like this:

} catch (SomeException ex) {
     logger.error(ex);
     throw ex;
} catch (OtherException ex) {
     logger.error(ex);
     throw ex;
}

And you’ll be pleased to know that with Java 7, you can now refac­tor your code and do this instead:

} catch (SomeException  | SomeOtherException ex) {
     logger.error(ex);
     throw ex;
}

Yummy!

Some pic­tures from our mini-trip to Zeebruges:

In the first post of this series, I’ve told you a bit about the new dia­mond nota­tion which is a nice addi­tion and pro­vides for bet­ter code read­abil­ity and less ver­bosity. And not only that, but since we’re typ­ists first and pro­gram­mers sec­ond, it also allows us to increase the LOC / minute count (and whether that is a good thing is actu­ally open to debate) ;-) (sorry for those poor hunt and peck typ­ists among you).

For this sec­ond post, I want to talk about a fea­ture that has been requested about 16 YEARS ago and that was finally imple­mented in Java 7: the abil­ity to write switch state­ments with String cases. I won’t insult you with an exam­ple, if you want one, then check the offi­cial docs.. Also, I won’t cover the per­for­mance aspects, which other peo­ple have already explained quite nicely.

As many of you know, it’s a fea­ture that has been avail­able for a long time in many other pro­gram­ming lan­guages (e.g., C#, JavaScript, ruby, …) and even though hard­cod­ing String lit­er­als should be avoided when­ever pos­si­ble, there are still cases where it makes sense.

To cater for the lack of that fea­ture, mul­ti­ple workarounds were used. One of which (the ugli­est IMHO) being to use if-then-else blocks to han­dle all the cases for non-binary deci­sions (more com­plex than sim­ple if-else), which indeed leads to unreadable/unmaintainable code (even though it is con­text based and some­times if-then-else blocks make more sense than using a switch).

Another approach, which I think is way bet­ter on mul­ti­ple lev­els is to define an enum with a fromString(String) method and use the enum val­ues in a switch via the val­ueOf method. That tech­nique allows to avoid repeat­ing hard­coded Strings all over the place and keeps the code eas­ily refac­torable. Not only that, but it is also way more flex­i­ble. For exam­ple, in the from­String method (or what­ever you decide to call it), you can decide whether you want to sup­port case sen­si­tiv­ity or not, how to treat null val­ues, etc. You can find a nice writeup of that idiom there.

The sup­port for String objects in switch state­ments is very wel­come, but keep in mind that it isn’t the sil­ver bul­let and that it shouldn’t be used in all cases (haha) :)

Java 7 has finally been released! There have been a lot of dis­cus­sions around the fea­tures that would/wouldn’t be included in Java 7. After a while, I decided to stop check­ing the news around that sub­ject since it changed so often. And appar­ently, some of the most awaited fea­tures have been deferred to Java 8 or later. Among which: JSR 294 (Lan­guage and VM sup­port for mod­u­lar pro­gram­ming), clo­sures,  or JDK mod­u­lar­iza­tion (project Jig­saw). Too bad! But any­how, now Java 7 is here and it’s time for me to check it out. In this series of posts, I’ll write about the new fea­tures that I find inter­est­ing as I dis­cover them (don’t except the list to be exhaus­tive though).

So let’s get started! Here’s the first bit I’ve just read about:

You can now replace the type argu­ments required to invoke the con­struc­tor of a generic class with an empty set of type para­me­ters (<>: infor­mally called the dia­mond) as long as the com­piler can infer the type argu­ments from the context.

If we trans­late this to actual code, it really means that instead of:

Map<Foo,Bar> fooBar = new HashMap<Foo,Bar>();

You can now write this:

Map<Foo,Bar> fooBar = new HashMap<>();

Or this:

Map<Foo,List<Bar>> fooBars = new HashMap<>();

Instead of that:

Map<Foo, List<Bar>> fooBars = new HashMap<Foo, List<Bar>>();

This is a nice addi­tion, but make sure to check out the ref­er­ence doc­u­men­ta­tion for more details, it doesn’t stop there ;-)

Syn­tax­High­lighter is a very cool syn­tax high­light­ing JavaScript library cre­ated by Alex Gor­batchev (if you don’t know about it yet, check out the demo page). As you’ll notice, I actu­ally use it on this very blog.

Using it is pretty straightforward:

• load the XReg­exP library required by Syn­tax­High­lighter: http://xregexp.com/

• load the main script:

  <script src="js/shCore.js" type="text/javascript"></script>

• load one or more of the avail­able brushes (syn­tax high­light­ing scripts):

  <script src="css/shBrushJScript.js" type="text/javascript"></script>

• include at least one of the avail­able theme stylesheets:

  <link href="css/shCore.css" rel="stylesheet" type="text/css" />
  <link href="css/shThemeDefault.css" rel="stylesheet" type="text/css"/> 

• wrap the code to high­light in a <pre> block and spec­ify the brush that should be used:

               <pre class="brush: js">function foo(){ ... }</pre>
             

• finally, exe­cute the high­lighter using the following:

               <script type="text/javascript">
                 SyntaxHighlighter.all();
               </script>
             

The main issue with this way of con­fig­ur­ing Syn­tax­High­lighter is that you’ll either have to load exactly those brushes you need or load them all even if they’re not needed. This prob­lem remained until ver­sion 3 intro­duced the Autoloader script.

You can find all the details about its usage on that page, but basi­cally you have to load the autoloader script and tell it about all the brushes aliases that it should rec­og­nize along with the path to the cor­re­spond­ing scripts. Much bet­ter, yay!

One prob­lem I’ve had with the autoloader script is that it doesn’t seem to appre­ci­ate URIs for the loca­tion of the brush scripts when using the default syntax:

Array: [ 'alias1 alias2 /full/path/to/brush.js', ... ]

Although, it works per­fectly fine when using the alter­nate syn­tax (which is alas a lit­tle bit more verbose):

Array: [ [ 'alias1', 'alias2', '/full/path/to/brush.js' ], ... ]

Finally, I’ve come up with the fol­low­ing script, largely inspired by the exam­ple on that page but using the alter­nate syntax:

	<script type="text/javascript">
		var baseSyntaxHighlighterScriptsPath = "http://base-path-to-scripts-folder/";
		function getSyntaxHighlighterScriptPath(name){
			return name.replace('@', baseSyntaxHighlighterScriptsPath);
		}

		SyntaxHighlighter.autoloader(
			[ 'applescript', getSyntaxHighlighterScriptPath('@shBrushAppleScript.js') ],
			[ 'actionscript3', 'as3', getSyntaxHighlighterScriptPath('@shBrushAS3.js') ],
			[ 'bash', 'shell', getSyntaxHighlighterScriptPath('@shBrushBash.js') ],
			[ 'coldfusion', 'cf', getSyntaxHighlighterScriptPath('@shBrushColdFusion.js') ],
			[ 'cpp', 'c', getSyntaxHighlighterScriptPath('@shBrushCpp.js') ],
			[ 'c#', 'c-sharp', 'csharp', getSyntaxHighlighterScriptPath('@shBrushCSharp.js') ],
			[ 'css', getSyntaxHighlighterScriptPath('@shBrushCss.js') ],
			[ 'diff', 'patch', 'pas', getSyntaxHighlighterScriptPath('@shBrushDiff.js') ],
			[ 'erl', 'erlang', getSyntaxHighlighterScriptPath('@shBrushErlang.js') ],
			[ 'groovy', getSyntaxHighlighterScriptPath('@shBrushGroovy.js') ],
			[ 'java', getSyntaxHighlighterScriptPath('@shBrushJava.js') ],
			[ 'jfx', 'javafx', getSyntaxHighlighterScriptPath('@shBrushJavaFX.js') ],
			[ 'js', 'javascript', 'jscript', getSyntaxHighlighterScriptPath('@shBrushJScript.js') ],
			[ 'perl', 'pl', getSyntaxHighlighterScriptPath('@shBrushPerl.js') ],
			[ 'php', getSyntaxHighlighterScriptPath('@shBrushPhp.js') ],
			[ 'text', 'plain', getSyntaxHighlighterScriptPath('@shBrushPlain.js') ],
			[ 'py', 'python', getSyntaxHighlighterScriptPath('@shBrushPython.js') ],
			[ 'ruby', 'rails', 'ror', 'rb', getSyntaxHighlighterScriptPath('@shBrushRuby.js') ],
			[ 'sass', 'scss', getSyntaxHighlighterScriptPath('@shBrushSass.js') ],
			[ 'scala', getSyntaxHighlighterScriptPath('@shBrushScala.js') ],
			[ 'sql', getSyntaxHighlighterScriptPath('@shBrushSql.js') ],
			[ 'vb', 'vbnet', getSyntaxHighlighterScriptPath('@shBrushVb.js') ],
			[ 'xml', 'xslt', 'html', 'htm', getSyntaxHighlighterScriptPath('@shBrushXml.js') ]
		);

		SyntaxHighlighter.all();
	</script>