the force that pushes object up

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.

1. Pursue what you love. Passion is an incredible motivator. It fuels focus, resilience, and perseverance.
2. Do the hardest work first. We all move instinctively toward pleasure and away from pain. Most great performers, Ericsson and others have found, delay gratification and take on the difficult work of practice in the mornings, before they do anything else. That’s when most of us have the most energy and the fewest distractions.
3. Practice intensely, without interruption for short periods of no longer than 90 minutes and then take a break. Ninety minutes appears to be the maximum amount of time that we can bring the highest level of focus to any given activity. The evidence is equally strong that great performers practice no more than 4 ½ hours a day.
4. Seek expert feedback, in intermittent doses. The simpler and more precise the feedback, the more equipped you are to make adjustments. Too much feedback, too continuously, however, can create cognitive overload, increase anxiety, and interfere with learning.
5. Take regular renewal breaks. Relaxing after intense effort not only provides an opportunity to rejuvenate, but also to metabolize and embed learning. It’s also during rest that the right hemisphere becomes more dominant, which can lead to creative breakthroughs.
6. Ritualize practice. Will and discipline are wildly overrated. As the researcher Roy Baumeisterhas found, none of us have very much of it. The best way to insure you’ll take on difficult tasks is to ritualize them — build specific, inviolable times at which you do them, so that over time you do them without having to squander energy thinking about them.

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

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.

Viewport splitting support is a really cool feature provided by Vim. This allows to split the viewable area between one or more files. Most Vim user may already familiar with this feature if you have ever used Vim’s help(:help topic). When you enter help, Vim splits the viewport and opens the help in top viewport while you document is open in bottom viewport.

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

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.

WS-BPEL is used in Web Services based Service Oriented Architectures to

• Create business processes from Web Services and Human Activities which span across organizations
• Create complex services from other less complex services from heterogeneous environments
• Create application integration flows from various existing and new applications based Web Services

In most cases we utilize the existing services available, to implement business processes. And there can be situations that those available services are secured using WS-Security.

WS-BPEL 2.0 specification doesn’t define a standard way of handling this type scenarios. And WS-BPEL handles the Web Services at the port-type level. So BPEL engine implementations has there own ways to handle this kind of situation.

We use Apache ODE in WSO2 BPS and we have separate integration layer written based on ODE-Axis2 integration layer. There is a slight difference between WSO2 BPS 1.1.1 and WSO2 BPS 2.0.0 when it comes to configuring WS-Security for partner services. In WSO2 BPS 1.1.1, user needs to create a separate file called package-config.xml which contains endpoint configuration information while in 2.0.0 we have extended deploy.xml to support these configuration. But both these mechanisms share same configuration elements and only difference is the place we keep them.

Users can use Policy XML compatible with Apache Rampart or services.xml file which compatible with Axis2 and contains security policies compatible with Rampart to configure WS-Security for partner services.

How to configure security for partner endpoints?

WSO2 BPS 1.1.1

You need to create a separate file called package-config.xml which looks like following, and put it in the root of your BPEL package.

In this package configuration file we have ‘endpoints’ element which contains configurations of all the endpoints exposed by BPEL process and invoke by BPEL process. When configuring endpoints you need to specify serviceName, servicePort and serviceNS attributes according to the configurations in deploy.xml. For example if you want to call secured CreditRatingPL partner link(CreditRating service partner service) in following deploy.xml file, endpoint configuration will look like above example.

To configure security you can use either a policy XML or services.xml file. And policy configurations are same as configuring security for normal Axis2 based service clients using Rampart. There are Rampart specific policy extension elements which let you configure key stores, user name – password pairs and password callback classes.

You can put the policy XML files and services.xml files in BPEL package or in anywhere in the file system and put the correct location in location attribute. If your password callback classes are in a separate JAR, you can put them on the BPS_HOME/repository/components/lib directory.

You can download sample BPEL package for WSO2 BPS 1.1.1 which shows you how to configure security from here.

WSO2 BPS 2.0.0

The main difference in version 2.0.0 is you can specify security and other endpoint configuration parameters directly in deploy.xml file. For example to configure security for CreditRatingPL partner link, you can directly specify endpoint configuration inside ‘service’ element as follows. In this case you don’t need to specify service name or port name, because they are already available in the parent element(‘service’).

You can download sample BPEL package from here.

Resources

• Secure Web Services with Apache Rampart
• Rampart FAQ blog