October 2007

Oct 29, 2007

When I tell people that I'm now working for myself at home, the first reaction is usually "wow, that takes a lot of self discipline". True, it does. There's no replacement for healthy self discipline. However, as with most things in life, there are levels of gray here. I always seek ways to improve.

I found this great tool that helps me keep going. It's called RescueTime. It's a small little gizmo that sits on my machine and monitors what I'm doing. I can then log into the RescueTime web site, see a graph that shows how much I've worked and when. It logs tasks according to the process being executed or the web site being visited. Monitoring URLs is important since many applications are online today. I can then tag the activities with tags like "work", "fun", etc., and get a summary of my activities according to my tags.

So, if you tend to lose track of time reading your RSS feeds or in IM chats, this will give you the required feedback to get back on track. It's like a mirror, providing silent, yet deadly honest, feedback.

Oct 15, 2007

Online applications are no longer a trend, they're a reality. The concept of SaaS, Software as a Service, started as small drops (online e-mail) and quickly became a surge. The Online Office, also known as Office 2.0, became a ruthless battleground for giants and smaller players, eating chunks from the desktop office applications market share (see this growing list of Office 2.0 applications).

The main reason is to reduce costs. The major costs are installation and maintenance (upgrades, support). In an organization, installing and maintaining individual machines, each with somewhat different software configuration, means huge costs. This can all be simplified if the only software you'll need is your browser. An upgrade is done only on the server and most client problems can be solved by cleaning the browser cache. One may say that this is the holy grail of the IT department.

It is just a matter of time until the trend reaches software development tools. There are some examples of "online IDEs", but none of them seems strong and generic enough to replace the desktop IDE. Most of the online alternatives are focused on developing specific applications for a proprietary online platform (like Coghead). The major players in the IDE world (Microsoft, Eclipse, IBM, Sun) are still investing in desktop solutions.

Two new technologies, which has been recently introduced, suggest an online direction for Eclipse. While it's possible that none of them is adequate, this is a strong indication on the future of the platform. I don't think that the desktop version will fade away in the near future, from the same reason that desktop office applications are still with us. Nevertheless, it is possible we will see a viable online alternative to the desktop IDE soon.

The first technology is RAP, Rich Ajax Platform, a new Eclipse sub-project, aimed to "enable developers to build rich, Ajax-enabled Web applications by using the Eclipse development model...". In other words, it gives you an online Eclipse-like environment, which you can use to develop your own applications. It works a bit like Google's GWT: you use a Java API, closely resembling the basic Eclipse SWT API, which produces HTML and JavaScript for you. The results are impressive, but it does require developing your plug-ins specifically for RAP, so you can't just run all the current Eclipse plug-ins you have, like the Java Development Tools.

The second technology is from IBM AlphaWorks, called EcliFox or "Eclipse on the Browser" (IBM are known for bad names :-). It's "An Eclipse plug-in that enables browser-based access to Eclipse". Instead of using HTML, this plug-in converts the SWT controls to XUL. This means it will only work with Gecko-based browsers, like Firefox. However, it holds the potential of running existing plug-ins, which brings us closer to the goal of having an online IDE. The demo is impressive as well.

These are very different technologies, but the goal is the same: to take the Eclipse platform on-line. I'm thinking of the amount of time spent of installing and troubleshooting the Eclipse installations in my previous project and it makes a lot of sense. This is something to keep an eye on.

Oct 14, 2007

I just got back from a long break of over a month. I spent two and a half weeks in Champaign, IL, giving a training for my former employer and two weeks doing Jeep Safari in Morocco.

Morocco was great. We had 6 days with the Jeeps, traveling through the Atlas Mountains and the Sahara Desert. My pictures are still under development (the camera I'm holding is a film SLR), I'll post some more soon.

It's very hard for me to focus back on my software. I did a critical mistake and started changing the design just before I left. Before I took off, I got some new ideas and decided it was not too late to implement them. The thing is, I had about a day of work left. I knew it will not be enough for me to implement all the changes and I knew that leaving the system in an unstable state is going to hurt me. Yet, wasting a day of work was too much.

It's now really hard to get back on track. I'm seriously considering undoing what I did in the last day and starting over. Luckily, I took some time to document my ideas before I jumped into implementing them, so it shouldn't be too hard. My main lesson is: if you know you're going to leave your system for some time, document as much as you can.

It also reminds me of a blog post I read some time ago, which discussed techniques for working efficiently. One of the ideas was not to set up any appointments. For example, if I set up an appointment at 11:00, I will not start anything major in the morning, since I know it's going to be interrupted. When I return, half the day is gone and it will take me time to get back to focus.

The original post claims you should not keep any schedule and only meet people ad-hoc. If you can do that, great. If not, here are some other ideas for mitigation:

Set up the meetings in the early morning or late afternoon (or evening).

Work on small issues. I keep a list of smaller to do items that can be done in less than an hour. This is good for "filling the gaps".

Document before coding. Then start working on the major issue and it will be easier to get back to it later.