Category — Programming

I use Maven every day to build WSO2 Carbon based products and it takes huge amount of time due to the size of WSO2 Carbon platform. So I used to run the build and do some other work until it finishes. But most of the times, I forget to check the build status and this has effected badly on my productivity.

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.

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

To uninstall MySQL and completely remove it (including all databases) from your Mac do the following:

• 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.

A CouchApp is just a JavaScript and HTML5 app that can be served directly to the browser from CouchDB, without any other software in the stack.

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

WSO2 Carbon Studio is a fully tooling environment which facilitate you to develop, test, deploy and test WSO2 Carbon Artifacts.

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.

Each and every WSO2 Carbon 3.0.0 based product contains a “Registry” which we used to store data. There three main partitions of this registry space which used to store different kind of data namely, Local Data Repository, Configuration Registry and Governance Registry. This registry space partitions are there to allow share resources and configuration replication.

Local Data Repository

Contains system configuration as well as runtime data that is local to a single instance of a product. This partition of the registry space is not for sharing among multiple servers.

Configuration Registry

This is the most widely used partition and contains product specific configurations intended to be shared across multiple instances of the same product(for example, a cluster of ESB instances sharing set of proxy service configurations).

Governance Registry

Contains data and configuration shared across the platform. The WSO2 Governance Registry makes use of this partition of the registry space to store services and related metadata such as WSDLs, schemas, policies and endpoints. The governance registry partition has been designed in a way that it can be made use of by multiple instances of various Carbon based products.

You need to be careful when using these separate partitions when designing you solutions and “Sharing Registry space across Multiple Product Instances” article describes how you can leverage the registry partitions to successfully implement highly scalable SOA based solutions using WSO2 Carbon based products.

• Function names matter: we’ve known this for a long time, but now we know that we scan function names first. A good name, and you don’t need to focus on the implementation all that much.
• Variable names matter: again, nothing new. Notice, though, how the eye goes back to the variable definition and assignments. We constantly look for reminders of the state of the variable.
• Loops are the source of all evil: well, that’s not entirely true, but they are worse than all other statements. Notice how figuring out the loop is the most time consuming bit of the code. It’s where most pitfalls are (Oh, the index should be smaller OR EQUAL. Right. I forgot). Commenting can help some, but just keeping the conditions simple and readable is key. Break complexity down around the loop.
• Short code is easier to process, so get your refactoring tools out, everybody, it’s time to split these functions.

Read More….

In this presentation, Joshua Bloch and  William Pugh describes eight short Java programs with curious behavior. Things discussed in this presentation will help you a lot, if you are a Java developer.

Following is the list of problems and summary of things you can learn from studying those problems.

1. The Joy Of Sets

What is the out put of following program.

Moral of the above problem:

• Collection<E>.remove takes Object, not E
• Integral arithmetic always results in int or long
• Avoid mixing types
• Avoid short; prefer int and long

2. More Joy of Sets

Out put of the above program will depends on the whether you are connected to internet or not. This happens because URL’s equals and hashCode are broken.

Things we can learn from above problem:

• Do not use URL as a Set element or Map key
  • equals and hashCode aren’t well defined
  • They do not obey their general contracts
• Use URI instead of URL
  • Make URL from URI as neccessary
• equals should not depends on the environment

3. Racy Little Number

How often does the following test pass.

Moral of the problem:

• JUnit does not support concurrency
• You must provide your own way of handling concurrency
  • If you don’t you will get a false sense of security

4. Elvis Lives Again

What does following program print?

Moral of the problem:

• Wrapped primitives aren’t primitives
  • Prefer primitives to wrapped primitives
• Auto-unboxing can occur when you leas expect it
  • It can cause NullPointerException
• Never use Boolean as a three-valued return type
  • Almost guarantees NullPointerException
• Watch out for circularities in class initialization
  • Construct instance at end of class initialization

5. Mind The Gap

What does following program prints?

Moral of the problem:

• The skip method is hard to use and error prone.
• Use your skipFully(you will learn about it during the presentation) instead of skip
• More generally, if an API is broken, wrap it
• For API designers
  • Don’t violate the principle of last astonishment
  • Make is easy to do simple things

jQuery is one of the popular JavaScript frameworks out there and it simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.

To get the best out of any framework or API used for developing software, developers need to understand fundamentals of that framework and need to get the know how of basic building blocks of those frameworks. This is same for jQuery as well.

Open sourced training materials and the book from Rebecca Murphey will help you a lot to get the jQuery fundamentals right.

Step One: Write More Code

The easiest way to do this? Start new side projects and contribute simple patches to open source projects. Every time you write code,you will learn something about thecode, your tools, or yourself.

Step Two: Work With Great Developers

Now that you’re creating code, you need to work with great developers so you can see how they write great code.

Above was extracted from article “2 Steps to Becominge d a Great Developer” of   HackerMonthly magazine’s first issue. It’s the monthly magazine of Hacker News and great magazine for every software developer.

The above mentioned article was written by Eric Davis, and in that article, he shares the two steps that he is using to walk the patch to becoming a great developer.