Making the ugly elegant one day at a time
Gerald Jay Sussman
...And So Many More...
05/01/2003 - 06/01/2003
06/01/2003 - 07/01/2003
07/01/2003 - 08/01/2003
08/01/2003 - 09/01/2003
09/01/2003 - 10/01/2003
10/01/2003 - 11/01/2003
11/01/2003 - 12/01/2003
12/01/2003 - 01/01/2004
01/01/2004 - 02/01/2004
02/01/2004 - 03/01/2004
03/01/2004 - 04/01/2004
04/01/2004 - 05/01/2004
05/01/2004 - 06/01/2004
06/01/2004 - 07/01/2004
07/01/2004 - 08/01/2004
08/01/2004 - 09/01/2004
09/01/2004 - 10/01/2004
10/01/2004 - 11/01/2004
11/01/2004 - 12/01/2004
12/01/2004 - 01/01/2005
01/01/2005 - 02/01/2005
02/01/2005 - 03/01/2005
03/01/2005 - 04/01/2005
04/01/2005 - 05/01/2005
05/01/2005 - 06/01/2005
06/01/2005 - 07/01/2005
07/01/2005 - 08/01/2005
08/01/2005 - 09/01/2005
09/01/2005 - 10/01/2005
10/01/2005 - 11/01/2005
11/01/2005 - 12/01/2005
12/01/2005 - 01/01/2006
01/01/2006 - 02/01/2006
02/01/2006 - 03/01/2006
03/01/2006 - 04/01/2006
04/01/2006 - 05/01/2006
05/01/2006 - 06/01/2006
06/01/2006 - 07/01/2006
07/01/2006 - 08/01/2006
08/01/2006 - 09/01/2006
09/01/2006 - 10/01/2006
10/01/2006 - 11/01/2006
11/01/2006 - 12/01/2006
12/01/2006 - 01/01/2007
01/01/2007 - 02/01/2007
02/01/2007 - 03/01/2007
03/01/2007 - 04/01/2007
04/01/2007 - 05/01/2007
05/01/2007 - 06/01/2007
06/01/2007 - 07/01/2007
07/01/2007 - 08/01/2007
08/01/2007 - 09/01/2007
09/01/2007 - 10/01/2007
10/01/2007 - 11/01/2007
11/01/2007 - 12/01/2007
12/01/2007 - 01/01/2008
01/01/2008 - 02/01/2008
02/01/2008 - 03/01/2008
03/01/2008 - 04/01/2008
04/01/2008 - 05/01/2008
05/01/2008 - 06/01/2008
06/01/2008 - 07/01/2008
07/01/2008 - 08/01/2008
08/01/2008 - 09/01/2008
10/01/2008 - 11/01/2008
01/01/2009 - 02/01/2009
09/01/2009 - 10/01/2009
Friday, June 30, 2006
I just finished reading "Practices of an Agile Developer". It's filled with tons of practical advice. I think it should have been called "Practices of a Good Developer. Period.", but I doesn't have the nice sexy ring to it. It's extremely short and they touch on the topics. It's great if you don't have a lot of time on your hands. I still recommend "Code Complete 2" for more coverage on good practices. But, I loved the "how to work with people" aspect of it which is unusual in technical books, but common in manager texts. The devil/angel quotes were cute and entertaining. It's certainly not a dull moment with lots of excellent analogies (common for the pragmatic programmer series). Anyway, I recommend it and it doesn't take long to read at all.
Monday, June 26, 2006
Brent Adkisson just started his blog and gave me a compliment. Perhaps one of the best that I've ever heard. It'll be one of those that I stash away for those rainy negative days.
If you know Blaine you have had a glimpse of one of the best coding minds I have ever had the pleasure to meet.
Wow! Brent is too kind. I don't think I would go that far...I'm still a journeyman in my mind. Brent is a great guy. Always laughing and smiling and never ceases to put me in a good mood. Oh, and did I mention, he's a kick ass coder as well?! I only keep the best company (so I always plenty of brains to learn from).
Sunday, June 25, 2006
I love the fact that there's a new interface in java.util: Iterable. Why you might ask? Could it be for the new shorthand for?
Well, that would be one reason to get excited. Close, but no cigar, no, I like the fact that the method iterator() has been split from java.util.Collection. It allows one to have infinite collections. Most of the time, you don't care how large the collection is, you just want to traverse over its elements. Iterable allows you to do just that. All you care about is that it can produce elements. This means if you have a large file, you could read it in chunks without anyone being the wiser. They would just have an Iterable object and not know how things worked in the back end. Encapsulation at its finest.
The client of RecordReader knows nothing about how many records are read in from the file at once nor should they care. They just want each record. We could for example read in 500 records in at a time or just one. It doesn't matter. We could even pass how many to read in at once as an argument to on. Throttling is left to us as a performance enhancement in one class.
Iterables allow us to have true object streams. How cool is that! For giggles, we could have also implemented it totally differently. This time I return an Iterable when asked instead of making the RecordReader implement it. I like this approach much better.
The naive (or simplest) implementation of records() could simply return the entire collection of the file using an ArrayList. And when the file got too big, then move to a custom Iterable object that could read in chunks of the file. By putting iterator() into its own interface, we got a greater flexibility beyond the nice new for sugar. Polymorphism is a wonderful thing wouldn't you agree?
I use Iterables all over the place in my Reflective Testing Framework to traverse over classes, class path items, and methods. It allowed me to have a nice pipes and filters pattern throughout the code. It also made it easy for others to extend what I have done. Have fun! Iterable might be the best new feature of Java5.
Matt Payne had great things to say about my talk:
"a Java 5 tour de force presentation that was backed up with a whole bunch of fantastic BSD licensed code"
WOW! You can't ask for a better compliment than that! Harish Keshwani had good things to say as well.
The thing that shocked me the most was how well my talk and Matt Secoske's on Performance fit so well together. We discussed our presentations before the meeting, but didn't plan on them being such a one-two punch! It was very cool.
I can't wait to expand the code that I have. ROCK!
Monday, June 19, 2006
In celebration of my talk tomorrow night, I have started a page on Automated Standards Enforcement. There's not a lot of content there yet. But, I plan on adding plenty of examples and more resources. Right now, I link to a bunch of books, articles, and my two frameworks. One is written for Squeak and the other Java 5. Both have source and tests available. I'm going to try to have the Java presentation up soon. My talk from Smalltalk Solutions is already there. Enjoy!
Saturday, June 17, 2006
Mike Bowler said:
The majority of programmers fall into the non-expert category. They can see the differences between some of the less powerful languages like Visual Basic or Java™. They do not, however, understand how much more powerful some languages are.
Wednesday, June 14, 2006
The most successful teams that I have been have all been small. In fact, I've long believed that four was the perfect team size (three the minimum, and five the max). Of course, this was simply a gut instinct. It has been experience. I never thought to look up an research on the matter.
I was talking with my co-workers today and about fell over myself when one of the mentioned that the optiomal team size was three to five. I asked him why he felt this and he said, "Well, I found some research that says so." The look on my face must have been priceless. Eagerly, I asked him to give me the papers. He kindly told me to google "Optimal Team Size". I asked him what made him look it up and he replied, "I wanted to know the optimal group size for role playing games."
Here are the best articles that I found. Enjoy reading! All of it gave me lots of information to chew on.
The most telling quote was one by Steve McConnell. He not only advocates a small team, but relates what we've always known: code quality is dependent on the qaulity of the programmer. Methodology plays a little role in all of that. It's all about the people. Check it out:
According to Capers Jones's "Program Quality and Programmer Productivity" (IBM Technical Report TR 02.764, Jan. 1977), on small projects, construction errors make up about 75% of all errors found. Methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the program.
I thought it was cool that there was research out there to prove my gut instincts.
Tuesday, June 13, 2006
It is written that a great leader is not only good at leading, but following too. The same rule can be applied to coders. Sometimes you take the lead over a design when you feel the passion and other times you let someone else take the reigns. The important thing is not to feel the need to always be the one in charge. Let others lead.
Following does not mean to blindly go over the cliff, but to question and suggest. Realize that the person leading has the final decision. Without a clear leader, tug of wars result in code decay of the worst kind. Trust your team partner, but make sure your communication is clear when you disagree.
Too many times developers get into the mindset of always wanting to be the lead dog. Resist the urge. Learn to standback, do things differently, and most importantly grow and learn from doing a design differently. You will also gain the respect and admiration of your team. If you want people to support you, you must support them too.
Sunday, June 11, 2006
This Java Generics FAQ is a whopping 433 pages in PDF form. Holy Moses! I went to print it out at work and was shocked by the size. The special cases are simply amazing. There's things that I hadn't even thought about it. It's comprehensive and well-written. 433 pages is a whole book on one small feature.
I've been using Java 5 at work and I must admit it makes developing proper frameworks possible, but it also complicates matters. It made my life as a framework developer nicer, but made the life of my user more difficult. Features should make my user's life easier, not mine. Simplicity is the key to good design.
Colin Putney was kind to inform me that #--> method from the previous is already implemented in Squeak! In Squeak, it's called #in:. So, the code before looks like this now:
((2 in: [:x| x * x ]) in: [:x| x + 5 ]) in: [:x| x sqrt ]
How cool is that?
Howard Oh had the following suggestion on comp.lang.smalltalk.dolphin:
What a cool idea! How I love messages and closures!
This discussion on Lisp and its community is revealing. I've found comp.lang.lisp to be imitidating, not because of the hostility of some of the posters, but because everyone is so scary smart. It seems a lot of people have felt the wrath of impatient masters. The discussion shows a community taking a good long hard look at itself.
I remember not looking at PLT Scheme for years because of their poor behavior at Lightweight Langugages Conference Two. Matz gave a talk at the same conference and it's when Ruby won my heart. The community follows his lead. I have had nothing but great experiences in the Smalltalk and Ruby communities. I am thankful for that. The exchange of ideas and enthusiasm of people is contagious. I wish the same for the Lisp community.
I guess I'm shocked. I've always found Lisp folks to be helpful. The Lisp community has a lot going for it with two new books published last year. Renewed interest from a young audience is growing. I say forget the past and bury all hatchets. Start new. Lisp and Scheme are mad fun.
I almost forgot to post about the talks that I'm giving in the near future. If you're in the Omaha area, please stop by. It's going to be a blast!
June 20,2006 - Reflective Testing In Java
Omaha Java User's Group
This is my talk from Smalltalk Solutions geared toward Java. The idea is the same, but the implementation is different. I will show how JUnit with other technologies can be used for contract enforcement and uncovering design smells. If you have any interest in meta/reflective systems or AspectJ, then this might be the talk for you. The presentation is itself written in Java5/AspectJ using the Eclipse/SWT APIs. Expect the unexpected! Learn how automation in testing can not only verify your code, but your designs as well! Stop code smells before they stink.
July 11, 2006 - Seaside
Omaha Dynamic Language User's Group
I hope to see everyone there at BOTH!
Monday, June 05, 2006
Yes, I will be observing National Day Of Slayer tomorrow. They are the band that got me started down the road to extreme music. Long live metal! I will be playing "Reign in Blood" and "South of Heaven" as loud as I possibly can.
Sunday, June 04, 2006
I have a simple dare. In fact, it's a triple dog dare to all developers. Are your ready? Here it is:
Stop using the same examples to show how great your favorite technology is.
Programming in general has "Hello, World" and every beginning programming book uses it. Even worse is the heavy use of "foo bar" in all its forms. Used to be cute, but not any more.
But, the worse by far is the fibonacci sequence used by every beginning functional programming article to prove the elegance of recursion or functional pattern matching. Come on. There are examples that prove it much better (pick anything in the real world). And that leads me to the final one...
ATMs are used as the example in almost every book in OO design. It's played to death and no longer interesting. Certainly, there's better examples than that out there now, right? And no, don't continue with the bowling example. It's already a cliche in all of the agile books.
Computer science is an exciting field filled with untapped potential and great ideas. But, cliched examples, while good for comparisons, fall flat in their simplicity. Fibonacci doesn't show the elegance obtained from functional programming. Much like showing that you can create a function to add one to prove the elegance of closures. I think a meatier example grounded in the real world will excite the reader much more. This is my dare. Dare to write an original example that makes me realize how clever you are and not @#$%^& ANOTHER FIBONACCI EXAMPLE?!
Friday, June 02, 2006
Reading great code is like reading a great book. If you don't believe me, download Seaside or Dolphin Smalltalk. Of course, there's more examples than just that (Lisp 1.5 manual, Paul Graham's Lisp books, Structure and Interpretation of Computer Programs, etc), but I digress. You might now think I'm off my rocker and my brain is burnt from too much heavy metal music. But, I have a point to make.
There are simple rules to follow when writing: Outline your ideas; know your audience; and be concise. I'm sure there's more, but these are the three that I strive for. The funny thing is that these concepts correlate directly to code. Code is not merely communicating with the compiler and making things happen. If your software does anything of value or importance, it will be read by other people.
The act of design is the way we frame our ideas before we code. It allows us to plan out the high level view. It should not spell out everything, but give a blue print to how things will interface. It's the journey of thinking about the design that helps us. Code with a clear design is easier to maintain. Otherwise, it's a collection of incoherent thoughts glued together that might execute, but breaks often.
Writing your program for the computer is flat out wrong. In reality, the computer never really reads your code nor does it have to. It's the poor person awoken at three o'clock in the morning because a developer forgot to check for a null condition. It's the team interfacing their project on your library. In short, it's humans. We know this. Your audience is fellow developers. Take the extra time to name your variables well. Don't succumb to i,x,y, index, or each. Think about what business functionality you are implementing and write in that language. What if you had to give your code to someone non-technical? Could they understand what the code was doing? They should. Requirements live on in the program listing. Always strive for creating a domain specific language inside of your code.
Don't repeat yourself. I can't say it more simply. Don't be too clever and be concise. Prevent clutter from ruining the flow of a good program. Try to say the most with the least. It's good advice in art, writing, and programming.
There's probably more parallels that I could draw from, but I thought to keep this post simple. I enjoy reading books on good writing because I can try out new ideas for writing my code. I'm always asking myself how I could write something better for other developers to read. You can't learn from or maintain unreadable code. It's not hard to write well. It just takes practice. I'm amazed at how much code I read that is written for the computer. There's an over abundance of good code out there. The only way to become a great author is by reading great authors. Open source gives us a plethora of great code to admire and learn from. Get reading!
My Weekly Top 20 Artists