Expecting Rain

In years past watching Steve Job's keynote at Macworld prompted an urge to purchase an Apple product. Sometimes the urge was met, in some cases it still lingers (I don't currently own an iPhone or iPod Touch).

Not this year. I think the things that were demoed were all very good looking products (MacBook Air) and services (iTunes movie rentals), but neither product fits me. I'm not looking for that lightweight of a laptop, and I don't typically rent movies.

I didn't watch the keynote live, nor have I seen it replayed. I followed the highlight feeds that were available hoping for "one more thing" that would be aimed directly at me. It didn't come. That being said, I don't feel they went in the wrong direction or that it was a failure as many of my coworkers were quite impressed.

I guess it is time to start pushing for the iPhone or iPod Touch. :)

When performing a merge from a branch into the HEAD, make sure you workset is the HEAD and merge the branch into it.

...is being able to fix things that don't behave the way I wish they would.

I take quite a bit of pride in the fact that I feel comfortable in getting things to work appropriately. Case in point, I have a very good mobile plan that allows me unlimited txting for a very reasonable cost. The downside is that it doesn't work with quite a few web applications and services such as Google mobile or twitter. Being the geek that I am, I decided to fix this.

Using a linux server I have access to, I created an email address alias at my domain by going into the /etc/mail/aliases file. I then piped that email address to a ruby script I had written.

The script parses the incoming txt message verifying who I am and determines what service I wish to use. It then interacts with Google mobile or passes messages to twitter sending the responses back to my cell phone.

Now, I have access to those applications and services. I wonder how people without this skill set survive... Next time I take my car to get worked on at the auto shop, I'll wonder if the mechanic feels the same way towards auto related problems as I do towards web problems.

Ryan Stewart, among other things, a blogger for ZDNet has posted an article called Rich Internet application predictions for 2008 which makes 10 (really 11) predictions for the upcoming year. It is an excellent post and I tend to side with the majority of his forecast.

The three points he made that stood out to me were:

• 2. AIR changes how people think of the web.


• 7. The days of smaller RIA technologies are numbered.


• 9. Real time data becomes an important selling point for RIAs.

AIR changes how people think of the web.
I don't want to sound like I'm gushing about AIR, but I think Adobe has the pieces coming together to do something great. I am especially impressed with their dedication to the platform and the people using it. Shortly after the initial release that included SQLite there was some complaint that they only exposed asynchronous methods for working with databases. The very next release of AIR had synchronous methods. They didn't wait for 1.0 to come out or put it somewhere in the future on their roadmap, they did it immediately. Very impressive.

The days of smaller RIA technologies are numbered.
I've spent sometime, not much mind you, working with OpenLaszlo, I even created a proof of concept application that I still have sitting on my local test server. I just don't have the passion for it that I do for Flex. There just isn't much of a buzz around it in my opinion. However, one thing to watch is that they can compile the application into either Flash or DHTML. I've never yet needed to do that, but it is an interesting feature.

I can't really comment on Curl. I know what it is generally, but have never really done anything with it.

Real time data becomes an important selling point for RIAs.
This stood out to me, not because I have a strong opinion either way, but feel I need to develop an opinion. In my line of work, I've not really needed real time data. Let me rephrase that, in my line of work I've not noticed a need for real time data. I do very little "polling" from servers. I don't know if that is because my applications don't need it or I have limited vision of what they could become. Either way, I'm going to spend a bit more time checking it out.

I'm very excited about the way things are developing on the web. I think it is a great time to be involved with any of these technologies. Comparing what is available now to what we had a few short years ago is truly amazing. It gives great hope for the future.

I really look forward to seeing how the year progresses and reading Ryan's score card for his 2008 predictions.

We have a pretty small Software Development department and have had very few software version problems. As such, we have never truly utilized version control to its fullest. To us, version control has been a way to get a copy of the software to each developer's workstation.

As time goes on projects become more complex, users' wish lists become more complicated, and software is release more often we have found the need to hold certain updates back from being released that aren't ready while other updates need to be pushed out. In comes version control, particularly branching.

We are now officially utilizing branching in with our version control. We do bug fixes and urgent (short-term) updates to a branch while adding new features to our trunk. We release from our branch merging it into our trunk each time. Once we determine the trunk has reached a new version milestone, we merge the branch into the trunk, tag it with the appropriate version and create a new branch to do bug fixes on again.

A large part of our policy for version control comes from http://www.tldp.org/REF/CVS-BestPractices/html/.

It will be interesting to watch this over time and see how well it works for our group and our dynamics. It is a proven method of software development, we just haven't needed it yet, or at least we haven't realized that we needed it before now. I'm sure that as we use it we will look back wishing we had implemented it earlier.