Sunday, December 16, 2007

Parallels vs VMWare

Just a mental note to myself to keep off Parallels on Mac if I have a choice, it wasted almost my entire weekend since it had trouble after I upgraded the OS to Leopard & installed new parallels trial. XP image kept on crashing after a Windows update. Finally, I switched to VMWare and had to reinstall all OSes. Hopefully, it is just a problem with the trial copy, but I found VMWare to be trouble free. I had a great opinion about Parallels, but all that changed this weekend. My vote - VMWare!

Tuesday, October 09, 2007

Ruby on Rails

It is hard to be excited over a new language nowadays, but recently I came across one which seemed to make web & database development fun again.
I am referring to the combination of Ruby & Rails (RoR). This was a framework built for real world development problems rather than for 'building a framework' as per it's founder.

It has several interesting features:

1. Lack of strong typing & support for 'duck typing' - it works even though you feel lost sometimes if you have been a C/C++/Java/C# programmer.
2. Configuration by convention - no need to configure stuff if you follow the convention, but you can configure if you need to as well.
3. Brevity of expression - introduced by C which can easily get you a cult following. eg. one line to write a program which prints itself.
4. Dynamic nature - ability to add methods or redefine methods on the fly - to any class in the system, even built-in ones.
5. script/console - a hidden gem, difficult to live without once you use it.
6. code generation & metadata programming - similar to wizards in VS, but used for many more tasks and ActiveRecord takes metadata programming to next level.
7. production vs development vs test modes - is there any web app which has the same env in development & production? RoR acknowledges that.
8. Agile development, unit tests & scaffolding - it is constantly evolving, encourages testing, scaffolding is now getting obsolete in EdgeRails but useful.
9. AJAX & REST - supports the latest trends in web development, Java is just beginning to have a JSR to support REST!
10. Moreover, it encourages you to provide features and not spend time write ORM xmls or waste your machines resources running a J2EE server!!

Some of these features are 'interesting' and could be scary to a C++/Java developer or someone with an enterprise development background.
But, you have to consider that this is mainly for web server side development with a lot of work on databases!
JAVA had it's run with banks & financial institutions but it seems RoR just needs a corporate sponsor to mature & succeed in the long run - Hint: IBM, Oracle, Sun.

Note: RoR is already several years old now.

Sunday, August 19, 2007

The end of SOAP webservices.

It is probably a bit early to say this, but SOAP webservices doesn't have a future.
I had been a myopic fan of SOAP webservices and one of the early adopters of the technology in various implementations - .NET 1.0, axis, xfire, JAX-WS, BPEL, JSR 180 etc.

It is a great example of how excitement about a new technology can blind your judgment.
It failed the single most important test - it was just not _simple_ enough to succeed in the long term.

1. complexity meant few stable implementations. eg. jboss changed their webservice implementation twice or thrice already.
2. complexity meant inherent concerns about it's security after deployment. eg. how does it handle a malformed request?
3. it needed client & server support which meant changing platforms as your clients change. eg. javascript, actionscript, java, .NET clients.
4. it was supposed to be cross platform, but it required another standard (ws-i profile xx) to standardize the standard. Still, it is a challenge getting a .NET client to talk to a JAVA SOAP webservice.

The answer for the future is some form of REST API. The paradigm shift here is the focus on data instead of services. This has it's own problems. But, it is simple and works for all your clients - very important if you are developing a global distributed service. Examples of this include the GData API & JSR 311.

If you missed the SOAP webservice bandwagon, consider yourself lucky and develop yours using RESTful APIs.

Wednesday, July 25, 2007

Future of the web.

The answer is right in front of you even if you don't see it already:

The web started with simple HTML.
Then came the dynamic web where content is dynamically generated for the users.
Then came the wikis which enabled editable webs.
Then web applications got more interactive with AJAX.
The next level of interactivity is where applications execute and behave like Desktop applications within the browser.
Then there will be the web OS where you store all the important data in the web and access the same from everywhere.

* The web OS sounds grand but the closest we have today for the client is Flash/Flex & Silverlight & XUL to a lesser extent.
* This will blur the line between desktop apps & web apps further.
* Making toy applications for web will no longer fly & traditional players might get another shot. (MSFT vs GOOGL)
* The recent acquisition of 'Parakey' by Facebook is an indication of where the future is going.
* HTML or AJAX(to a lesser extent) will still be around as there are applications for which they are suited more.
* AJAX was a mistake, making a Java VM to virtualize the development or coding for 'n' browsers is not the future.
* Flash/Flex is the underdog here where people often associate Flash with those 'flashy' sites. It is no longer the case.
* With cross-platform support in Flex & Apollo along with synchronization & native db support it is an example of how the web platform of the future is going to be!
* And then, sometime in the future we will have a web OS which has some features from Omnidrive & Parakey.

Saturday, April 28, 2007

Importance of "keeping it simple".

Sometimes you have to keep repeating a message so that everyone gets it, at the risk of sounding like a broken record.

There was a quote in this month's Popular science which applies to  software world as I had been trying to say in earlier posts- "good engineers find solutions to hard problems that are complex and hard to understand, but great engineers find solutions to hard problems that are so simple that you wonder why you didn't think about it in the first place"

Simplicity is not only important in software design but also to the user. I remember working on a product  which had a versioning scheme which was so complex that even the QA required several days of training to understand it. You can imagine the frustration for the customer and how long the feature existed in the product!

The next level of simplicity is in the user interface, Microsoft Office 2007 UI is a great example of how to scare the user by showing all options. 37 signals has some good examples of how to design a simpler UI. Sometimes you just don't want to see the configuration or edit controls unless you need it.

It is the job of every engineer and designer to ensure what they are working on is simple. If not, you are just working hard to make life hard for others!!!

Tuesday, April 10, 2007

ABCs of good design

Good design and architecture has always been identified as a key requirement for a product to succeed in the long term.
But how how can you measure the quality of a design or identify the recipe to come up with the best design always?
These are not questions with easy answers, but help to illustrate the challenges in the area.

There have been many approaches to improve the quality of design in computer software over the course of time:

1. Functions & subroutines - This helped improve the design of monolithic programs by separating commonly used functionality into functions & subroutines. This improved the maintenance and reuse of code by having less duplication etc.

2. OOP - This was another major step forward in design in which we tried to model the objects in real world using classes having methods & properties. This was more natural to humans than working with procedures. eg. Rumbaugh & Booch.

3. CASE - 'Computer aided software engineering' evolved into excellent tools like Rational Rose which helped document the design using UML etc. This indirectly helped to improve the understanding of the system before implementation and added 'engineering' to software.

4. Design patterns - formalized the various constructs used to solve common problems, documented it, gave them names so that the language used to express the design is almost universal.

5. Agile development - uses evolving design approach based on user feedback using a working prototype. It assumes that the user knows what he really wants only when he uses it.

Still, can anyone claim that their design is perfect even if it uses all of the advancements in software design given above? It is probably why one of the comments posted earlier mentioned that you can never learn design from a book, rather it comes from experience and expertise in a variety of disciplines.

There is no secret pill to always come up with the best design, I don't claim to be an expert either but here are some of my thoughts that might help.

1. Identify the goals, requirements and the problem you are trying to solve correctly.Here is where mockups, prototypes and documentation help. If possible, share it with the target user to see if the solution is appropriate.

1. View the problem space and solution from different perspectives. eg. UML has various diagrams which help you do this. A better undestanding of what you are trying to build is always good.

2. Stick to basics and simple constructs. These will stand the test of time rather than the 'fad' of the time. Complexity in design helps nobody.

3. There will be always be related problems which have already been solved. Use the learning from them to improve or adapt your design. Don't try to reinvent everything.

The factors by which I usually evaluate a design are it's simplicity & extensibility. There are many others which are covered in related literature.

1. Simple - this is one of the most underrated features of a good design. If a design is not simple, it is usually not maintainable or extensible either. This is where bulk of your experience, intelligence & expertise in various disciplines come to play.

2. Extensible - this is also related to maintenance & readability which are all required for the design to stay relevant over a long time. The strength of a good design is often proven when the component or product can be easily adapted to un-planned scenarios.

3. Effective - it solves the problems it was meant to. ie. it doesn't fail to address the original requirements or loses sight of it's goals.

In the real world, it is not enough to have a good design to succeed. But it is always a good start!

Wednesday, April 04, 2007

OS Review

I have always been a Windows admirer, but a newly converted Mac fan, so it is probably time to see the OS world in a more 'objective' way!



  • It is great as a server - controlled environment and free software without support works just fine.
  • It is not a good home machine OS - at least not yet for the typical person who need driver support for his peripherals and who needs to run PC software.

Mac OS X

  • It is technically & visually the best OS for a home machine OS out there though a bit expensive & have limited peripherals - great usability & innovation. I expect to see the iSync+.mac integration in the next version of Windows!
  • It is good as a server - the unix background gives it the required skills, but it is still not acceptable for many businesses as desktop due to lack of support for Outlook etc.


  • It is a good OS for a home machine - the sheer volume of software & peripherals is good. Security is more of a challenge as it is a popular target.
  • It is ok as a server - Longhorn server with role specific customization should help, but still far from free to use in server farms.


Windows needs to take a step back and stop adding glut to the OS. It is time to give users an upgrade which lowers the memory & resource usage by half and apply the lessons learned with IIS security to the entire OS.  - 'less is better'

Apple will always be a minority player unless they change it so that it runs on any platform.  It seems the only thing to do to get wide user & peripheral support.

Linux needs a pretty face and improve usability. Please stop expecting an user to download the source and it's myriad dependencies to build the binaries. ie. drivers in binary form is a good start.

Google doesn't have an OS yet, but can be seen a company that can potentially tip the scales due to it's collection of  talent & money. It has to stop relying on chaos theory and have a solid strategy. Where is the second wave after search?


Windows franchise doesn't seem to be at risk in the near term, but virtualization & multi core CPUs might be the biggest threat for Windows in the future.

1. Virtualization in the server world is well understood and should make the application more important than the OS or hardware. eg. webserver, database etc.

2. Virtualization in the PC world is less of a threat, but it is what enables 'Parallels' to give access to Windows apps for Mac users.

But the worst case scenario might be Linux with open source Mac OS UI getting customers and thus developer mindshare for apps & drivers - relegating Windows to the guest OS!

Sunday, March 11, 2007

ABCs of product development

These should be obvious to anyone who has developed a real software product before. But, recently I had talked to a few people who were working on their first large scale projects on their own but were making some basic mistakes without realizing it.

1. If you are developing a new product or technology, prototyping and research is a must. Agile development methodologies are good, but for a large scale product use agile methodologies after your research phase.

2. Prototyping and research often takes longer than developing the actual product itself. Someone should actually write a prototype which acts as the prototype for modularization & abstraction as well if possible.

3. Always separate your UI code from your non-UI code. Often, the non UI code will be implemented as services in the windows platform. Develop a fool proof mechanism to keep the software upto-date as well.

4. Never try to automate your UI testing first. It should be done only after automating tests for the non-UI portion. The tests should be such that they perform the test and are able to validate the success or failure as well. Every bug which is found should be part of your automated test suite.

5. Plan to have daily builds if your team is more than 5 people and run your automated test suite on every build. If the build or the tests fail, make it the first priority to fix it.

6. Setup is not an after thought. Plan for upgrades, patches, partial upgrades etc before your first release.  Use VMWare or similar tool with snapshots for setup testing to save time.

7.  Use the best tools for the job. Pick the language, IDE & server technologies which are the best fit for the customer - not for you. ie. Don't develop in C because you don't like C#.

8. Use peer reviews for improving code quality. Every checkin should be reviewed by lead or peers before it is committed. It is all about catching bugs early on in the development cycle.

9. Architecture & good design are a must if you expect your product to be in the market for a long time. Think about changes in market and the possible different uses your components could be put to. Learn this elsewhere, not from this blog.

10.  Security in today's world is important. Your reputation depends on it. Think about it when you design, not when someone finds the first vulnerability in your product and your reputation is already lost.

11. Three documents which should be ready before development starts are Functional Specification(is done when design& test plan can proceed), Design Specification(is done when coding can start) & QA Test plan(is done when testing can start). Preferably, do a team review of all of them

12. Remember that products never get filled with hacks in one day, it takes small hacks everyday to create a monster which everyone wants to re-write because they do not understand!

Saturday, February 10, 2007

Story of a website being hacked

Hosting a website at home is one thing, but hosting one on the live internet is a whole different ballgame. Yesterday, I decided to expose one of my Xen virtual machines at home to the internet just to see if it works. I wasn't expecting to be hacked in less than an hour though with just 2 ports open. It brought down my jboss server(did a security no-no by running as root- hey, I was running it on XP before! :-), no ssh access etc.

It helped that it was a Xen guest, I deleted the disk image and restored my backup. I just had to have more control if someone did attempt to break in again.

So, put the machine back live again with more security tools & help from Google. Eg. apache with mod_jk instead of jboss, host FW rules in addition to h/w firewall rules, snort with upto-date rules, did a portscan with nmap, chkrootkit, backed up the system profile with tripwire and checks running every hour with automatic emails to me. I thought this was a good start, comments welcome?

It was less than 12hrs before I spotted attacks again, Frontpage seems to be the favorite of hackers. There were continuous scans for fp30reg.dll. There were also attempts to utilize known vulnerabilities using extra long SEARCH requests etc. No more portscans though. Is that out of fashion now? Atleast,this time I was happy to watch than be a victim.

Sunday, January 07, 2007

Customers & managing complexity

The only reason you should ever be solving a complex problem is if it makes your customer's life so much more simpler. But again, all complexity can be put into this category, so think twice before you do that!