Tuesday, November 28, 2006


Ever heard of POJOs? Plain Old Java Objects? That term got popularized in the Java world after the backlash against EJBs a few years ago. Enterprise JavaBeans were considered heavy-weight, cumbersome to write and maintain, and over-engineered. POJOs were a cry-out to return to the roots of Java development in applets and desktop apps when using plain objects and JavaBeans was the norm.

POROs is a term that my colleague Tyler coined today while we were pair-programming on our Rails project. It stands for Plain Old Ruby Objects. Tyler used the term to refer to a model object that is not created as a Rails ActiveRecord.

ActiveRecords are somehow equivalent to Entity Beans in Java except they are much lighter, and do not put much burden on the developer. So, the use of the term POROs was not a backlash in any way against them. It was simply used for convenience to distinguish model objects that are written for long-term persistance (ActiveRecords) from plain model objects that do not extend the framework and may not necessarily require long-term persistance.

Tyler posted more details under his Blog post "Using OpenStruct for transient data models"

Friday, November 17, 2006

Ruby's one line guideline

I was doing some development in Ruby today and noticed that I was using this guideline often to detect Ruby code-smells: If I wrote more than one line of code to do something that takes 5 lines of code in Java, then I must be doing something wrong. Following this guideline over and over taught me many Ruby tricks. Try it and let me know what you think. Otherwise, if you know other guidelines, please let us know what they are in a comment.

Amazon Web Services

I attended a CHIRB meeting last night (CHIcago RuBy User Group) in which a guy talked about Amazon Web Services. These are general-purpose web services provided by Amazon Web Services, a company under the same umbrella of Amazon.com

The most interesting services of the bunch were S3, EC2, and The Mechanical Turk.

S3 stands for Simple Storage Service. It is basically a storage web service that allows companies to store any kind of data remotely on Amazon's servers. It costs $0.15 a gigabyte a month (with a transfer fee of $0.20 a gigabyte)

EC2 stands for Elastic Compute Cloud. The fancy name is just a label for a web service that allows companies to rent a virtual server with Linux on it. Its performance is equivalent to 1.7Ghz x86 processor, 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth.

Finally, the Mechanical Turk, aka Artificial Artifical Intelligence, reverses the web services paradigm to have people serving computers instead of computers serving people. For example, if a photo storage web application needs to categorize photos, since humans can do the job much more accurately than a commercial-grade computer vision technology, the photo storage web app can simply advertise need for categorizing photos in the Mechanical Turk, and people around the world can respond to the ad and perform the service for the billing rate advertised.

A real world example is a website called The Sheep Market. It is a website that allows people to submit sheep drawings, contributing to a collection of 10,000 sheep. The website uses the Mechanical Turk to cheaply identify whether drawings submitted represent sheep or not. That costs pennies per drawing identification. The website then builds on this knowledge by selling worthy sheep drawings for $20 each. Imagine how much fortune it would be to sell 10,000 of those drawings.

These were the highlights of the presentation. Amazon Web Services are interesting indeed, both for building Web 2.0 websites and for serving enterprise needs.

Tuesday, November 14, 2006

High energy standup meetings

Given that we practice eXtreme Programming at our team, we hold daily standup meetings. Having attended them for 9 months, I appreciate their value in keeping the team connected and committed to the project.

One thing that I find particularly important however is keeping energy high in the meetings.

To achieve that, here are several suggestions that I have applied:
  • Before everybody shows up, begin a casual conversation with someone, speaking with a loud voice and showing great enthusiasm and interest. Works best if you get other people to join the conversation before the meeting begins as it puts everybody in an excited enthusiastic mood.
  • Start the meeting with News of the Day. Make sure to select a single ground-breaking story that will attract the team's interest
  • Crack a joke, especially if you're natural at telling jokes. (I find that getting people to laugh at my lousy performance of a joke does the trick of energizing the team as well. ;) )
  • Rotate who leads the team as this creates variety in the meetings and infuses different personal flavors
If anyone has interesting ideas to energize a standup meeting or would like to share personal experiences with standup meetings, please post a comment.

Remember, keep energy high in standup meetings.

Friday, November 10, 2006

Can you tell I have Mac envy?

Thursday, November 09, 2006

Pair programming and exotic Ideas

Pair programming is a wonderful practice that incredibly increases productivity and quality of code. Some of the reasons according to my experience are:
  • Complex problems get solved faster, sometimes 8 times faster
  • Solutions are more elegant, making code more extensible
  • Code is written in a clearer way enhancing maintainability
  • Relationships with other programmers are improved, yielding a smoother-going team with less team member conflicts
  • Knowledge is transferred between team members making them produce faster and better in the long run
However, one thing that I learned from Tyler yesterday is that pair programming does not necessarily suit exploring exotic ideas that require significant pondering. It would be more time-economic for the pair programmers to do the simplest thing that solves their problem, and then later explore the exotic idea on their own time. On a subsequent pairing session they can share their findings, discuss the idea, and potentially apply an improved solution to the problem.

Benefits are:
  • The programmers will have a "good-enough" solution for the problem to meet their deadline
  • It is preferred to do deep pondering solo and in silence to avoid distractions and the pressure of having another person waiting for you to speak
  • Once the exotic idea is pondered enough, the programmers will have a much more productive conversation about it
  • If the exotic idea did not prove practical, the programmers can still fall back to the existing "good-enough" solution

Tuesday, November 07, 2006

Starting JVM twice in Desktop app

So, I encountered a problem today that would have been solved easily by starting the JVM twice, but mentioning the solution to the senior architect immediately got his head shaking in disapproval.

After getting the courage to ask why, I learned the implications of starting a JVM twice, and got reminded of why architects are an important part of any software team.

After all, architects are named that way because they are responsible for creating the software architecture, and one of the cornerstones of that process is thinking about non-functional requirements. Ever heard of the 'ilities??? Security, Usability, Reliability, Safety, Maintainability, Extensibility, etc... Our architect never ceases to amaze me with having those concerns at the back of his mind all the time.

So, concerning the problem I mentioned, the reason starting a JVM twice was not a good idea is because it increases the app startup-time considerably, driving usability down, particularly responsiveness of the application upon launching it by the user. It also potentially decreases safety and maintainability as it requires handling a number of different scenarios that can go wrong, thus increasing code complexity.

Lesson of the day: Think twice before starting the JVM twice in your desktop application!!!

MVC Web vs. MVC Desktop

So today, I had this interesting conversation with my colleague Tyler about the differences between MVC for web development and MVC for rich client desktop development.

Having come from a Swing/SWT Java background, I find myself often trying to apply desktop Object-Oriented paradigms to web development while working on this new Ruby on Rails project with Tyler.

I like the fact that I am attempting to transfer my desktop OO knowledge to the web instead of scrapping it and beginning from scratch. That is because I see so many developers nowadays that learn programming on the web right away from web technology books, ending up without solid OO knowledge. So, they often follow procedural/structural techniques in development that make code obscure and time-costly to maintain.

I learned from Tyler today that it is not recommended to apply the Model View Presenter variation of MVC in web development using session objects. I suggested that we use a stateful Presenter as a session object that abstracts the View that the client is seeing as an HTML file. However, Tyler discouraged it because while using a Presenter to abstract a View makes separation of concerns cleaner, it ends up storing a lot of stateful data on the server that negatively impacts scalability and performance, which are apparently very important web development non-functional requirements. To save the server from storing stateful data about the View, Tyler recommended embedding data directly in served-up HTML files, either as tag attributes or hidden fields, as long as the data did not represent critical information that needed to remain secure. Such stateful data is later utilized by serving it back up to the server on a subsequent action.

Doing Ruby on Rails development is quite a fun journey for a Java desktop developer as I am getting to toy with Ruby, Rails, AJAX, CSS, and other related technologies. It is quite a challenge for a desktop developer to deal with the constraints of web development, such as bandwidth, scalability, security, and the web UI paradigms.

Saturday, November 04, 2006

A plunge into the blogging world

I once read a science fiction novel called Ender's Game. Although it was written before the Internet was born, it predicated many of the things that happened post its birth. It spoke of an interconnected web of computers; forums where people communicate, and even kids disguising as adults leading online organizations and political campaigns. While the last bit may have not manifested completely yet, it is interesting how the power of imagination can predict many things far before they occur.

I am finally plunging into the blogging world because I realized that it is a great way to communicate my ideas to people, discuss them, refine them, and contribute them to the world.

This blog will be dedicated mostly to technology-related topics. However, every once in a while, I will sprinkle in other topics that are related to my personal interests (skiing, rollerblading, kung fu, snowboarding, skateboarding, psychology, philosophy, etc...)