We’re excited about our first ever WSO2 Convention. But we know that for many of our WSO2 fans Colombo is a long way from home. So we are offering a special opportunity for one lucky WSO2 OxygenTank member and WSO2 Customer to join us for free, including airfare, accommodations, conference and VIP special event passes, and more!

Visit here for more information.

I thought that I could reduce the effect on productivity, if I can trigger some notification sound and a bubble when build is finished. Using Growl notification system(You need to install growlnotify tool as from Growl extras.) and afplay command line tool I came up with the following script which let me trigger notification after invoking any command line tool.

For example think you want to get a notification after a maven build, you can execute the maven command like following(Note: I have named above script growlexec and made it a executable):

growlexec mvn clean install -Dmaven.test.skip=true

This will create notification bubble and will make a sound after the command line tool is done with it’s work.

How can we create something like this for use on Linux?

You can use libnotify to trigger visual notification bubbles. For audio notifications you can use tool like beep.

Read rest of the article at blogs.hbr.org.

As a developer, you are sitting on a goldmine. Do you even realize it?

No, seriously, a @#$% goldmine! Never in modern history has it been so easy to create something from scratch, with little or no capital and a marketing model that is limited only by your imagination.

Think about the biggest websites you visit or use on a regular basis: Facebook, Twitter, Flickr, Foursquare, or even Google for that matter — all of them were created by developers who created something from little more than an idea in their head. Was it easy for them? Heck no. But it could only have been done in today’s day and age. So why in the world are you sitting there day after day working for someone else?

Yeah, I do too. I hate it.

So if there are so many amazing opportunities out there, why aren’t more developers out there working for themselves? I think there is a pretty common set of excuses that we tell ourselves. None of them are legit!

- Intermittent Intelligence

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

Comments are not like Schindler’s List. They are not “pure good.” Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much-perhaps not at all.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code. Every time you express yourself in code, you should pat yourself on the back. Every time you write a comment, you should grimace and feel the failure of your ability of expression.

Why am I so down on comments? Because they lie. Not always, and not intentionally, but too often. The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.

Code changes and evolves. Chunks of it move from here to there. Those chunks bifurcate and reproduce and come together again to form chimeras. Unfortunately the comments don’t always follow them-can’t always follow them. And all too often the comments get separated from the code they describe and become orphaned blurbs of ever-decreasing accuracy. For example, look what has happened to this comment and the line it was intended to describe:

MockRequest request;
private final String HTTP_DATE_REGEXP =
“[SMTWF][a-z]{2}\\,\\s[0-9]{2}\\s[JFMASOND][a-z]{2}\\s” +
“[0-9]{4}\\s[0-9]{2}\\:[0-9]{2}\\:[0-9]{2}\\sGMT”;
private Response response;
private FitNeseContext context;
private FileResponder responder;
private Locale saveLocale;
// Example: “Tue, 02 Apr 2003 22:18:49 GMT”

Other instance variables that were probably added later were interposed between the HTTP_DATE_REGEXP constant and it’s explanatory comment.

It is possible to make the point that programs should be disciplined enough to keep the comments in a high state of repair, relevance, and accuracy. I agree, they should. But I would rather that energy go toward making the code so clear and expressive that it does not need the comments in the first place.

Inaccurate comments are far worse than no comments at all. They delude and mislead. They set expectations that will never be fulfilled. They lay down ld rules that need not, or should not, be followed any longer.

Truth can only be found in one place: the code. Only the code can truly tell you what it does. It is the only source of truly accurate information. Therefore, though comments are sometimes necessary, we will expend significant energy to minimize them.

- Robert C. Martin (Clean Code)

Update(16-08-2010)

Some other resources worth reading(Don’t forget to read the comments, comments contain very good arguments on commenting):

• When good comments go bad
• Coding without comments
• The bad code spotter’s guide

• Use mysqldump to backup your databases to text files!
• Stop the database server
• sudo rm /usr/local/mysql
• sudo rm -rf /usr/local/mysql*
• sudo rm -rf /Library/StartupItems/MySQLCOM
• sudo rm -rf /Library/PreferencePanes/My*
• edit /etc/hostconfig and remove the line MYSQLCOM=-YES-
• rm -rf ~/Library/PreferencePanes/My*
• sudo rm -rf /Library/Receipts/mysql*
• sudo rm -rf /Library/Receipts/MySQL*

The last two lines are particularly important as otherwise, you can’t install an older version of MySQL even though you think that you’ve completely deleted the newer version!

Via akrabat.com.

Here are some interesting Vim viewport keybindings:

• :sp (or :split) – Split the Vim viewport horizontally(divvy up the viewport into two equal viewports for the file that you have open)
• :vsp (or :vsplit) – Split the Vim viewport vertically
• :sp filename – Will open the filename in the new viewport(same is true for :vsp)
• :10 sp filename – New viewport will fill 10 lines(you can change the value).
• Ctrl w = – Tells Vim to assign an equal number of lines to each viewport
• Ctrl w j – Moves one viewport down
• Ctrl w k – Moves one viewport up
• Ctrl w h – Moves one viewport to the left
• Ctrl w l – Moves one viewport to the right
• Ctrl w + – Increase the active viewport by one line
• Ctrl w - – Decease the active viewport by one line
• Ctrl w q - Close the active viewport
• Ctrl w r – Will rotate windows to right
• Ctrl w R – Will rotate windows to left

Update: Some of the above keybindings will not work in Mac OS X.

Additional Resources on Vim Viewports

• Vim Tips: Using Viewports
• Splits and multi-file editing

Every fall, I explain to a fresh batch of Ph.D. students what a Ph.D. is. It’s hard to describe it in words. So, I use pictures.

- Matt Might

Read “What the HTTP is CouchApp?” to know more about CouchApps.

WSO2 Carbon Studio - BPEL Editor

WSO2 tooling team recently released the 14th milestone of Carbon Studio with numerous features like;

• Support for creating Carbon Application(cApp) projects which includes Axis2 services, BPEL processes, ESB proxy services, Gadgets, Data Services and etc..
• Also it includes Governance Registry plugin which will helpful when working with WSO2 Governance Registry

Please refer documentation for installation guide and guides on various tools integrated in to Carbon Studio.