Quote: Paul Graham on Beautiful software

"Great software requires a fanatical devotion to beauty.

If you look inside good software, you will find parts no one is suppose to see are beautiful too."


Paul Graham from Hackers and Painters 

 

LOTW - 20 Sept 2010

I missed last weeks LOTW due to lots of work and basically I was lazy haha, so this week gonna do a bumper issue. Enjoy


97 things every programmer should know - I guess most would already know about this, every programmer should go read what's in there, there are so many pearls of wisdom, now we have a video by Kevlin Henney at the keynote at jazoon talking about. Slides can be found at the video link.


Epic failures: 11 infamous software bugs


Google is going to release Wave in a Box, an installable version of Google Wave, since they have decided to discontinue Google Wave. The version is not going to have all the features of the original wave, but they are going to support federated across other Google wave boxes.


Lisp cabinet - For those who wants to tinkle with Common Lisp "Lisp Cabinet is a set of configuration files, tools and utilites bundled with automated installer to deliver full-fledged Emacs based Lisp development environment for Microsoft Windows"


Check out all the cool videos from NDC 2010 in this torrent
interested to hear Uncle Bob and Mike Cohn speak, Uncle Bob's slides from his Clean Code I Args are here.

Lamda the Ultimate has two posts that focus on Software Transactional Memory, one post quotes from a study that STM actually helps reduce errors as compared to the traditional locking model, while the other post talks about the support for STM in .NET and the decisions they have to make. I haven't really tried STM yet in any language, but basing modifications around a database like transactional model can probably make understanding and programming easier.

Designing Interfaces guidelines.

We all write interfaces when programming, these are the few rules that I found useful to keep in mind when designing and implementing interfaces.

1. Do not write interfaces for Model classes
Model like classes are classes like your DB model, or any other kind of class whoose primary function is to hold values. I usually do not write interfaces for these kind of classes for their main purpose is to hold values, and so let say you have Person class with getters and setters for Name and Address. And you have a interface call IPerson so you have getters and setters in the interface for IPerson. If you add a Telephone to Person, you need to add both the getters and setters to the IPerson. And it just goes on and on.

So far I haven really found a nice use case for implementing interfaces for simple value/model kind of classes.

2. Reduce your external dependecies
The reason you are writing interfaces is so that you can reduce the dependcies and change implementations if necessary. Consider the following

import org.internal.*
import org.external.NameValuePair

public interface HttpPost{
public void setPostParameters(NameValuePair[] pairs);
....
}

You are writing an interface to HttpPost and you have a method to add the post parameters. Your NameValuePair class actually comes from an external library. Now you have a dependency to that external library and you will need to package that every time you are using this interface.

I will try to keep this to a minimium, the reason why I write interfaces is to keep dependencies simple not to introduce new ones. So i might introduce a new class to break that dependency if needed or change the method signature to something like addPostParameter(String,String);

3. Keep your interfaces small and cohesive
Try not to have interfaces that does sort of everything, keep your interfaces small and cohesive (that means the methods in the interfaces are related to each other).

Bob martin in his article on the Interface Segregation Principle talks about using the Adapter pattern and multiple inheritance to join multiple interfaces together.

I like the line from Uncle Bob, "Clients should not be forced to depend on interfaces they do not use". Keep that as a rule when designing and implementing interfaces.

Martin Fowler Role Interface article also talks about this.

Interfaces are great for breaking up dependency and when use together with the Dependency Inversion principle you will have a easier time coping with changes to your software.

These are the book I recommend to improve your code.
Effective Java

Clean Code: A Handbook of Agile Software Craftsmanship


Agile Software Development, Principles, Patterns, and Practices

LOTW - 6 Sept 2010

Yahoo releases the Yahoo YUI Testing Interface it allows running to units tests in different browsers simultaneously.

The first step is to start from 37 signals - If you want to start something, just start, dont worry about it. As Yoda says "Do there is no try". Good advice for me ...

James Gosling creates a "Free Java from Oracle" t-shirt. Frankly I wonder what if Java was free from the beginning, would it reach the popularity that it has today? Look at those with ISO like organizations behind it like C++ or Ecmascript, they tend to have abit too much political maneuvering and arguing and it take a long time for them to agree on standards. For the one person system that Python, Ruby have, the seem to lack the mass acceptance that Java commands (because SUN was backing it up those days), yeap they are popular but are they really being used a lot in the Enterprise space?

Scott Hanselman talks about 2 tools he use for a more readable web, Instapaper and Readablility.

Google Code University  - Offers courses on C++, Python, Android, Web security, lots of good stuff comes with slides, assignments and videos.

Let's face it programmers are probably not the best designers in the world (me included), hope the following 2 links can help out.

20 useful free pdf books for designers and bloggers

10 resources for design challenged programmers

What's your motivation for programming?

Studies since the 1970s that show that Intrinsic motivation (from within) rather than Extrinsic motivation (external factors like money) is the main motivation for people doing good work. In Drive: The Surprising Truth About What Motivates Us, Daniel Pink talks about the various research and studies and even gave some suggestions on how to improve your workplace, if you are a lead or manager go read the book. If you don't have time to read the book, RSA has a nice video (about 10 mins) that sums up book quite nicely.



So what is your motivation for doing your job as a programmer? What are some of the motivations that you have for continuing to do programming as work? Here are some that I came up with, feel free to add more in the comments section.

1. Joy of knowing that there is always something new to learn

I am always amaze that there are still so many things that I can learn in this field, and that's a motivation for me, because I will always have some new framework, language, technology to play with.

2. Joy of finding a solution to a problem.

Solving a problem be it in programming, performance or a process issue is always satisfying

3. Joy of seeing a user liking your solution.

For most of us, we program for real users and its a good feeling when a user tells you that you did good work.

4. Joy of doing work with people that you like or like minded.

 I am glad to be able to work with a bunch of guys who I like and feel comfortable with, the pantry talks and the lunches help make for a more interesting day.