Thousands of security vulnerabilities found this last year

CERT has a list that is a summary of the thousands of security vulnerabilities reported in 2005. Amazing.

Seven Habits of Highly Effective Programmers

Good advice from the Seven Habits of Highly Effective Programmers

In particular:

The first step in becoming an effective programmer is to ensure that you are spending your time wisely. And there is no greater waste of time than in working on something that is not useful or never shipped.

Google Reader API

I've been aching for a Blackberry based RSS reader that consumes my Google Reader stream of RSS feeds. That way I can read from anywhere while maintaining my history of read articles. This is a step in this direction, and also an interesting example of defacto web services in action.

Read more at www.niallkennedy.com/bl...

Java for Ruby

I was at The Server Side Symposium a couple of years ago. It was an exciting conference--lots of smart people there talking about some pretty cool Java tools and practices. I can't help but think that the symposium (if it's even going to ever happen again due to The Middleware Company's demise) would be nothing but crickets these days. A lot of that same talented group has left for Ruby..

Project Aardvark

I got my copy of Aardvark'd in the mail today. A movie version of The Soul of a New Machine it ain't. But the real disappointment is that it's not about Joel illustrating the finer points of the advice he dishes out on his site.

I couldn't help but get the feeling that all of these people, Joel included, take themselves way too seriously. I guess that's what makes geeks geeks. Note to self: lighten up.

The Rails train is gathering steam..

A recent post on the Ruby on Rails blog cites a couple of interesting articles. The headline being, " ThoughtWorks wins big contract on Rails. "

Okay, now Google's starting to scare me

I just saw the Blogger Web Comments Firefox Extension that was released yesterday. I installed it (painlessly) and now a small (well designed) toaster-style pop-up appears on most of the web pages I visit and shows me a sample of what people are saying about the page I'm currently visiting.

This is "social networking" done right. It hooks me into the so-called blogsphere without requiring that I navigate to some special site to connect what people are saying (and linking) to what is out in the world. That is, rather than viewing the web from the blogsphere, I'm able to view the blogsphere from the web. The relevance is high, and I can be sure I'll find people and other sites that are of interest to me based on where ever I find myself on the web.

Finally! Moble Gmail

To be honest, I only yesterday started looking for a way to get my gmail on my BlackBerry. In typical Google fashion, I didn't have to wait long. :) Now if only I could use Google Reader via my BlackBerry I'd be set.

Read more at mail.google.com/mail/he...

Enplaned

Who knew the airline industry observers had such nicely done blogs? Thankfully, I no longer travel from coast to coast once every monthy or two:

Enplaned

There is nothing as permanent as temporary: A pleasant surprise in Rails performance

When we started our Rails project a few weeks ago we had to scramble to learn Rails, tool up, and literally find a spare box as an integration/development machine. An old desktop box was found and Linux was installed. It was hastily plugged into the network under somebody's desk. Rails and its dependencies were installed, and the first embryonic version of our application was deployed under Webrick on port 3000. A duct tape and bailing wire deployment--but that's okay because it's only temporary.

As the weeks have ticked off we've been working to get "real" servers purchased, installed, configured, etc. This effort was plagued by all the usual suspects: wrong OS shipped on the servers, licenses for Red Hat Enterprise are missing, sys admins are scarce, rack rails don't fit our custom racks, the machine is finally running but not available across our VPN or our NY offices, etc. It's 4 hours until the application is set to go live to 200 users and the only viable way to deploy the application is.. You guessed it--on our temporary development box. "Can it handle the load?" "What are those errors in the development.log anyway?" "Better make sure the nightly build doesn't step on the app."

Fortunately the application is running just fine. Loads of users are on and the app is still snappy and smooth. Granted this is an internal application--not the type of application that gets pounded on the public internet. But it's still nice to see it going well--even if it is on a "temporary" and "not intended for production" server.

Best Practices & Patterns with Rails

As I alluded to in an earlier post in which I argued for using Ruby on Rails over J2EE, Rails provides some pretty convenient tools for implementing some best practices and patterns. Some concurrence here in this interview about the migration of cdbaby.com to Rails.

Before I was about to start the rewrite anyway, I decided I really wanted to do things according to the best practices in real object-oriented systems. Encapsulation was my goal. The CD Baby PHP code is 7 years of tangled mess. There are many things the system is unable to do without a total rewrite, because of its total lack of encapsulation.

I was already studying Martin Fowler's books like a schoolboy, ingesting the lessons while preparing for the rewrite. Then when Tobi really showed me Rails I got it : by sticking with Rails' conventions, I would be already working by these best-practices I was aspiring towards.

Understanding the iPod's success

Like a lot of people, I'm amazed at the iPod's success. It's only just as technically sophisticated as many other MP3 players already available on the market. But the device rules the market through its style rather than its function. It's hard to put your finger on the difference. When I got my iPod photo about a year ago (my first MP3 player), I was appreciative of its solid feel and good performance. I didn't realize how unique the iPod's style was until my wife got me a Delphi MyFi XM radio as a gift. This new machine, while *more* functional than the iPod, felt lacking. I still don't know what many of its buttons are for. It has a cheap, tinny, plastic feel. And it's not quite the right size for one's shirt pocket.

I owned one of the original 128K Macintosh computers, and have owned and worked with an example from every generation since. I've come to enjoy the feel of the Macintosh. With the exception of the "dark ages" in the mid 1990's, the Macintosh has held a special place in my heart for its fantastic design.

I ran across a site with tons of Macintosh history. Apple and the History of Personal Computer Design gives an extensive history of the vision that Steve Jobs had for Apple computers as "consumer products" and "works of art." This history and vision, and the many examples of design from the Macintosh history in particular, lead almost directly to an explanation of the iPod's success.

An argument for using Ruby on Rails rather than Java

I was a little nervous about telling my boss I'd decided that the apps we were going to be building would be implemented in Rails rather than J2EE. After all, he is an ex-Oracle guy who knows J2EE. I was hired because of my J2EE background. And all the conversations we'd had to-date were around using J2EE (although not in any technical detail).

I took a few minutes one Saturday afternoon and wrote up my reasoning on the subject. The primary goal being to produce something quickly. Since we're still in the process of hiring, the initial applications we'll be building will be done by existing engineers who don't know J2EE any better than they do Ruby or Rails. So I figured we needed to take a hit with the learning curve anyway. It is a good opportunity to get tooled up with Rails. If it doesn't work out, we will have built a decent prototype and can build the real system(s) in Java.

Here's my email to him (only slightly edited). The code examples are from Ruby on Rails and J2EE: Is there room for both? I took a little poetic license with some of the explanations, but that was because I wanted to keep it as brief as possible. I thought about using some of the diagrams from the RoR vs J2EE article, but figured that would get too technical.

(Said that I'm using RoR on our project)

First some history:

Over the past 5 years or so I've been deeply immersed in the J2EE world and have been following the architectural trends there carefully. The overall trend is abandonment of the "heavyweight" J2EE framework itself for a collection of lighter weight frameworks. For example, a few years ago, the common consensus among J2EE architects was that EJB was typically not necessary in most applications, and even in cases where it provided useful capabilities, it was difficult to implement and too expensive to maintain simply for transactionality or object/relational mapping. New frameworks have been popping up all over the place—Spring, Hibernate, Tapestry, WebWorks, etc.

I'm a big believer in development frameworks. Too many shops spend too much of their time reinventing the wheel building application infrastructure when they should be using existing best practice pattern implementations and concentrating programmers on the "domain" problem at hand. J2EE and Java have blazed a trail, proven the value of design patterns, and taken a lot of knocks along the way. Java and J2EE are battle scared as a result. And J2EE in particular has picked up a lot of baggage that it would probably be better without.

During this same period, architects discovered where the core value from component frameworks like J2EE lies, and distilled this into new frameworks. A big surprise was how productive programmers are using these new frameworks. A good example is in object/relational mapping. For example, given the problem of defining an "order" object and providing persistence, in the most productive Java persistence framework in use today (Hibernate), three major aspects need to be considered:

1. Modeling the "order" entity in a database. This might involve a table called "orders" with columns like Id and Name, and a relation to another table named "items".
2. Tooling up and deploying a Servlet or J2EE container (i.e, Tomcat) and the Hibernate framework
3. Writing (and maintaining) code such as the following:

  

 <hibernate-mapping>
   <class name="models.Order" table="ORDERS"
       dynamic-update="true" dynamic-insert="false"
       discriminator-value="null">

 <id name="id" column="id" type="java.lang.Long"
            unsaved-value="null">
            
        </id>

        <set name="items" lazy="false" inverse="false"
           cascade="none" sort="unsorted">
            <key column="id"/>
            <one-to-many class="models.Item"/>
        </set>

        <property name="name" type="java.lang.String"
            update="true" insert="true"
            access="property" column="name"/>
    </class>
</hibernate-mapping>


 

(Hibernate Mapping File)

public class Order {

    private Set items;

     private String name;

     private Long id;

     public Long getId() { return id;}

     public void setId(Long id) { this.id = id;}

     public Set getItems() { return items;}

     public void setItems(Set items) { this.items = items; }

     public String getName() { return name; }

     public void setName(String name) { this.name = name; }

}

(Order JavaBean)

Rails was developed from the beginning as a framework that natively implements some of the best practice patterns. In the case of persistence, it implements the object relational pattern defined in the pattern texts as an "Active Record." This implementation takes advantage of Ruby's abilities for reflection. It reduces the above Java implementation of an "order" entity stored in a database to the following three tasks:

1. Modeling the "order" entity in a database. This might involve a table called "orders" with columsn like Id, Name, and a relation to another table named "items".
2. Tooling up with the Rails framework (no separate Servlet container/OR framework is necessary)
3. Writing the following source code:

class Order <>

  has_many :items

end

In the above example, if you would like to add a new attribute to your order entity in your object model, you need only add a new column to your orders table in the database. The Rails framework uses the reflection capabilities of Ruby to expose the new attribute to the object model, and thus to your application.

Another huge productivity gain from Rails is the elegant implementation of the Model View Controller (MVC) interaction pattern. In Java/Struts works well initially, but its configuration based approach can quickly become a tangled mess and over time tends to evolve into a rigid, brittle application that is difficult to extend and maintain.

Rails implements MVC as a first class citizen in the framework. And breaks out the model (for example, the "Order" object above), the controller (which implements action classes and methods that act on the model), and the view (in this case, Rails HTML files), into separate files in their own directories under a common application source structure. Again, using Ruby's capabilities for reflection, Rails wires together the MVC components into a running application based simply on naming conventions, object inheritance and the location of source in certain directories. The result is an elegant and surprisingly modular implementation of MVC. For example, was able to add the "file upload" capabilities to our existing prototype by finding a Rails implementation of file upload on the Internet and dropping the MVC component files into the appropriate directories in our project. This was within only a couple of days of getting started with Rails.

One other highlight to mention is that Rails is cited as being the easiest web framework available for implementing Ajax style web programming. Ajax is an acronym standing for Asynchronous JavaScript and XML. If you use any of Google's applications (such as Gmail or Google Maps), Flickr, Amazon's A9.com, you'll notice that a ton of functionality is implemented without round trips from the browser to the server. This model of programming is catching on fast, and is one of the driving forces behind Rails' explosive growth. The authoritative Rails book, Agile Programming with Ruby on Rails recently reached #1 in Amazon's sales rankings in the Computers/Internet category. It's ranks roughly 250 in Amazon's overall sales. Developers are really excited about using Rails. Use of Rails attracts talent to our work.

My current thinking is that we use Rails to get a lot done quickly. In addition to rapid development, we'll tool up the developers with best practice patterns in mind. If long term we need to shift technology, we've codified good patterns and architecture into our team—something that's harder to teach, in my experience, than a particular technology or framework.

Xooglers

Some very good reading at a blog that is a gathering spot for ex-Google employees (calling themselves Xooglers). They're reminiscing about old-times in some suprisingly lucid and well written posts. A sample:

Another Googler did, in fact, tell me once about answering interview questions as Sergey, attired in a full-size cow suit, absentmindedly stroked his rubber udder. In retrospect, a roller hockey getup seems fairly formal by Google standards.