Elapsed Time in ksh

Being a novice on shell programming (ksh & bash), I've been looking for something short and sweet that would tell me how much time was taken up for my build (ant) to complete. Printing out the time(s) at the beginning of the script and at the end is very simple.. but what I'd wanted to was to print out something like.. " application build took and was completed successfully at ". I tried googling (of course) and found various scripts involving grep/awk and some perl scripts.. Damn.. quite a lot to do for a simple stuff.. But then my stars aligned properly and I hit upon a forum which gave me EXACTLY what I was looking (something short and sweet)! Just a simple $SECONDS did it! Here's how it was used:

START_TIME=$SECONDS
.. do what you need here..
END_TIME=$SECONDS
ELAPSED_TIME=$(($END_TIME-$START_TIME))

echo "A took $ELAPSED_TIME seconds to complete.."

Mylyn is awesome

When I was trying to install an update for an eclipse plugin, I noticed that there were couple of mylyn related stuff present and I had no idea where they came from.. but later realized that it was bundled along with eclipse europa and later versions. Didnt bother much that time.. but couple of days later, ran into a developerworks article that was talking about how mylyn makes you even more productive. That sprouted my curiosity and I took a dig into what it was about. Played around with it a little bit.. and Boy, was I glad to have run into mylyn! It REALLY DOES make you MUCH MORE productive and more focussed.
And its very simple to use as well.
All you need to do is create a new local task (if you dont have a repository setup) and give it a due date, schedule date (based on ur schedule) and a priority. Activate the task and thats pretty much it! From there on, any file that you open to work on are automatically associated with the currently active mylyn task.. and it also makes it easy on you by removing the files that were closed and that havent been edited, but opened for a long time. Another beauty is that it even associates (displays in package explorer) only the methods that were accessed, which means you dont have to really get lost with sorting through the various classes that are present in your project and even the numerous methods in a class that have no relevance to the task you're working on currently! Finally, since mylyn integrates with CVS, if you have eclipse hooked up to CVS, you'll see that when its time to checkin the changes, all the classes impacted by the task you worked on are automatically grouped for you, making it much easier to group check in the files that were updated for a specific fix or for a new change. Just awesome! No more hassle of trying to figure out which files were changed for which task.. especially when you're working on multiple tasks in a huge project. It also tracks the amount of time spent on each task after its activated.. again making it easy for you to provide an estimate or provide better estimates of time spent on each task (for micro-managing bosses). Im yet to play around with the bug tracking feature.. but I already know that Im gonna love that as well.. even if I dont, Im gonna continue using mylyn from now on for creating my personal tasks.. Please give it a try and fall in love with it.
Here's the link that got me onto mylyn:
http://www.ibm.com/developerworks/java/library/j-mylyn1/

Adios.
Arun

Agile Practices

While I was reading "Pragmatic Programmers" by Venkat Subramaniam and Andy Hunt, I ran into lots of good quips and quotes. BTW, I really enjoyed reading the book. Very well written and doesnt get into a boring lecture, instead keeps it very short and succinct just like what they preach.
I thought it'd be a good idea to summarize some of them for nailing it further into my head.. and also to remind me whenever I feel like Im getting away from the agile practices.. So here they are in no particular order:

• Fix the problem, not the symptom.
• Quick fixes become quick sand.
• You dont have to be great to get started, but you have to get started to be great.
• Learn iteratively and incrementally; Read voraciously.
• Strech beyond purely technical books and topics (project estimation, communication skills etc)
• Learn the new; unlearn the old (which holds you back)
• Only difference between a rut and grave is its dimensions - Keeping old habits past their expiration date is hazardous to your career.
• Small reachable goals keep you moving forward. (Break down your task into smaller and manageable units of code rather than write one do-all function only to realize later that you misunderstood a key point or the client wants to change the process in few areas)
  
• Keep records of decisions and the reasoning behind them. (log, wiki, issue tracking db, etc)
• One test is worth a thousand expert opinions.
• When writing code, choose readability over convenience.
• Instead of being too opaque or clever, follow the PIE (Program Intentively and Expressively) principle.
• Write code to be clear, not clever.
• Dont complicate the design for the sake of perceived performance or elegance.
• Premature optimization is the root of all evil.
• Elegance is easy to understand and recognize, but much harder to create.
• Develop the simplest solution that works - Incorporate patterns, principles and technology only if you have a compelling reason to use them.
• Keeping balance - A box of cotton fibers isnt helpful when you need a sock. (In the name of breaking down functionality into smaller units, do not fragmentize to such an extent that it becomes ridiculously convoluted to invoke a simple function.)
  
• Maintain a log of problems and their solutions.
• Point your colleagues in the right direction instead of handing them the solution.
  
• Code reviews are useless unless you follow up on the recommendations quickly.
• Knowledge grows when given - if you use your candle to light mine, I get light without darkening you.