Charles Nutter writes an eloquent blog entry "On Coding". I couldn't have said it better about what it means to be a coder.
Code is my religion.
Code is in my blood.
Elegance is not optional.
My heroes are all coders. I'm proud to be part of this journey with many others. So, Charles count me in as one of those with passion. I do this its strange that we are outcasts and people think us strange. But, I love being eccentric. And I love being around others that have the same passion. It's the reason I started all of the user groups and attend conferences. Ideas give me strength. Coding makes me feel alive.
As a side note, I love the term coder too. I hate the terms: "hacker", "geek", and "nerd". Coder to me symbolizes someone with passion about their craft. I can relate to that.
Saturday, July 29, 2006
Friday, July 28, 2006
Re: Do We Have To Sacrifice Virgins?
Ben Bleything said:
Perhaps I flew off the handle a bit. I think it's because I see so much synergy between the Ruby and Smalltalk communities. I consider myself to be both. I'm a dynamic language enthusiast (and President of the Omaha Chapter). Both technologies excite me and the communities ROCK! I just don't like to see bad blood or the appearance there of. Thank you for clarifying for me. I just want to keep the positive interaction to keep going.
Obie Fernandez posts more thoughts and clarified his meaning of "voodoo". I took the bad voodoo connotation because of the use of the word "heckling". I don't like it when technology I love does not get the respect it deserves. It seems Obie meant no disrespect.
It's all love, guys. I want both of us to be successful. And Ben, you are right. We are not in competition. I never meant to insinuate that at all.
"We're all stars. It's just your shine is different!"-Chocolate, Graham Central Station
Blaine-
I can't speak for Obie, of course, but I certainly don't feel the way you seem to think. I'm incredibly impressed by Seaside and Smalltalk in general. Avi is clearly a very smart guy doing very smart stuff.
I was IMing Obie during the talk, and said "it's probably just because I don't understand smalltalk, but this feels like total voodoo to me".
But I don't think voodoo is a bad thing. Voodoo is what gets me interested in something; I want to figure out how it works.
I don't feel like I'm in any position to comment on whether or not Seaside poses a "threat"... I don't even totally buy that there's a competition.
Perhaps I flew off the handle a bit. I think it's because I see so much synergy between the Ruby and Smalltalk communities. I consider myself to be both. I'm a dynamic language enthusiast (and President of the Omaha Chapter). Both technologies excite me and the communities ROCK! I just don't like to see bad blood or the appearance there of. Thank you for clarifying for me. I just want to keep the positive interaction to keep going.
Obie Fernandez posts more thoughts and clarified his meaning of "voodoo". I took the bad voodoo connotation because of the use of the word "heckling". I don't like it when technology I love does not get the respect it deserves. It seems Obie meant no disrespect.
It's all love, guys. I want both of us to be successful. And Ben, you are right. We are not in competition. I never meant to insinuate that at all.
"We're all stars. It's just your shine is different!"-Chocolate, Graham Central Station
Thursday, July 27, 2006
Do We Have To Sacrifice Virgins?
Obie Fernandez (and Ben Bleything) had some thoughts on the Seaside presentation at OSCON:
I'm a little disappointed with this coming from Rails developers. I guess when you become the mainstream you can start thumbing your nose at non-mainstream technology. I see both Rails and Seaside as technologies to show how easy things can be. Sure, Seaside seems more like voodoo and the ideas "out there". But, the technology and ideas have been around for quite sometime. I guess I love being a part of the lunatic fringe. It's always more fun. I've enjoyed the meteoric rise of Rails, but I guess I thought Ruby enthusiasts would have more respect for what Seaside is doing. Or at least understand it. I wonder how many java developers still heckle and chuckle at Rails' voodoo? I didn't expect such comments from my dynamic brothers.
Don't worry guys, I still love you. There's space for both of us. You are always welcome at my table. I would never heckle you, only share my ideas and thoughts.
"First they ignore you, then they ridicule you, then they fight you, then you win."-Gandhi
Avi, on how to do maintenance and debugging on Seaside servers: "We can just vnc into the server. Squeak has vnc built into it."
Django Jacob, "Of course it does..."
I'm having fun in this session, sitting next to Ben Bleything, and trying not to contribute to the sporadic chuckling and heckling about the voodooo magic of Seaside. This is definitely one of the more enjoyable sessions I've attended so far, but I don't think Seaside poses serious competition to any of the major web frameworks.
I'm a little disappointed with this coming from Rails developers. I guess when you become the mainstream you can start thumbing your nose at non-mainstream technology. I see both Rails and Seaside as technologies to show how easy things can be. Sure, Seaside seems more like voodoo and the ideas "out there". But, the technology and ideas have been around for quite sometime. I guess I love being a part of the lunatic fringe. It's always more fun. I've enjoyed the meteoric rise of Rails, but I guess I thought Ruby enthusiasts would have more respect for what Seaside is doing. Or at least understand it. I wonder how many java developers still heckle and chuckle at Rails' voodoo? I didn't expect such comments from my dynamic brothers.
Don't worry guys, I still love you. There's space for both of us. You are always welcome at my table. I would never heckle you, only share my ideas and thoughts.
"First they ignore you, then they ridicule you, then they fight you, then you win."-Gandhi
Long methods
Yes, I do get allergic reactions when I see any method that I have to scroll. Small methods are the best, the smaller the better. That's all I have to say about that.
Code Pet Peeve
I've been unlucky lately. I keep running into coding pet peeves of mine. One of them is the following:
OK, you can probably guess I hate the variable name "ex" and that I also hate the catch all Exception (generally, always catch the lowest level exception class you're expecting). The most offensive and biggest peeve though is the "printStackTrace()" method call. The worst is that this is the default in the code templates that come with Eclipse! Its good when you're trying to get things working, but many developers leave it in all the way to production. I avoid it at all costs. If I care, I log it or throw a more domain specific wrapped exception. The problem is when you try to find the stack trace in the logs. Of course, you can redirect standard out and error to some log, but why bother? Do it right the first time through.
I always remember the pragmatic programmer's mantra: "Dead programs tell no tales". Think about your exception handling and never settle for the defaults. It's sloppy and you will pay the devil eventually.
try {
//something potentially dangerous
} catch(Exception ex) {
ex.printStackTrace();
}
OK, you can probably guess I hate the variable name "ex" and that I also hate the catch all Exception (generally, always catch the lowest level exception class you're expecting). The most offensive and biggest peeve though is the "printStackTrace()" method call. The worst is that this is the default in the code templates that come with Eclipse! Its good when you're trying to get things working, but many developers leave it in all the way to production. I avoid it at all costs. If I care, I log it or throw a more domain specific wrapped exception. The problem is when you try to find the stack trace in the logs. Of course, you can redirect standard out and error to some log, but why bother? Do it right the first time through.
I always remember the pragmatic programmer's mantra: "Dead programs tell no tales". Think about your exception handling and never settle for the defaults. It's sloppy and you will pay the devil eventually.
August Omaha Dynamic Language Meeting
August brings us another great talk from none other than Sam Tesla. He will presenting us with the many wonders of Lisp. If you've ever been curious about the origin of dynamic languages, please come! See the lambda calculus come to life. Fun will be had by all. Be prepared to be delighted.
Please notice that we have changed locations. I got the meeting room at Panera Bread. Just tell them Blaine sent you. Cafe Gelato unfortunately closed. It will be missed! It's been our home from the beginning.
Please notice that we have changed locations. I got the meeting room at Panera Bread. Just tell them Blaine sent you. Cafe Gelato unfortunately closed. It will be missed! It's been our home from the beginning.
When | August 1, 2006, 7pm-9pm |
Where | Panera Bread 13410 W Maple Rd Omaha, NE 68164 (402) 964-1110 We have reserved the backroom |
Wednesday, July 26, 2006
Good Code and Examples
Why are so many examples in books so poor? For example, take this one from page 254 of "Java In A Nutshell" 5th edition:
"What's so wrong with this?!", you ask. It's chock full of baby sins. It's important that beginners will copy the example and try it on their own. Sometimes this code is tweaked into production code. Just think someone at 3am is probably answering a pager because of a bad code example somehwhere in the universe. Why not take the opportunity as teachers to show off exemplery code?
So, what are the sins? Right off the bat, poor variable names. It should be an abomination to have single letter variable names. We're in the 21st century finally! Variable names don't take up much more space. Why not be intention revealing?
The next sin is that the example is not useful. It would be nice to have a small example of what a random access file is good for.
The magic values is the next killer. Why not make constants? Production code should never have magic values neither should your examples.
The final sin is the worst. No finally or any exception handling code on the file close. You need to always make sure you leave the file in a good state (i.e. not open). There's several ways to do that, but at least make sure your examples ensure they close themselves.
Here's how I would have done the same example:
I could have broken this code out more, but I wanted something concise to show RandomAccessFile without much fluff. But, I also showed good coding practices. It's also a simple example that beginners could easily wrap their head around. Remember we are the teachers and it is our job to always show great code.
//Open a file for read/write ("rw") access
RandomAccessFile f = new RandomAccessFile(datafile, "rw");
f.seek(100); //Move to byte 100 of the file
byte[] data=new byte[100]; //Create a buffer to hold the data
f.read(data); //Read 100 bytes from the file
int i = f.readInt(); //Read a 4-byte integer from the file
f.seek(100); //Move back to byte 100
f.writeInt(i); //Write the integer first
f.write(data); //Then write the 100 bytes
f.close(); //Close the file when done with it
"What's so wrong with this?!", you ask. It's chock full of baby sins. It's important that beginners will copy the example and try it on their own. Sometimes this code is tweaked into production code. Just think someone at 3am is probably answering a pager because of a bad code example somehwhere in the universe. Why not take the opportunity as teachers to show off exemplery code?
So, what are the sins? Right off the bat, poor variable names. It should be an abomination to have single letter variable names. We're in the 21st century finally! Variable names don't take up much more space. Why not be intention revealing?
The next sin is that the example is not useful. It would be nice to have a small example of what a random access file is good for.
The magic values is the next killer. Why not make constants? Production code should never have magic values neither should your examples.
The final sin is the worst. No finally or any exception handling code on the file close. You need to always make sure you leave the file in a good state (i.e. not open). There's several ways to do that, but at least make sure your examples ensure they close themselves.
Here's how I would have done the same example:
private static final String READ_WRITE_ACCESS="rw";
private static final int TOTAL_RECORD_LOCATION=100;
public void addAmountToTotalAndSave(int amountInCents, String fileName) throws IOException {
RandomAccessFile totalFile = new RandomAccessFile(fileName, READ_WRITE_ACCESS);
try {
//go to total record location
totalFile.seek(TOTAL_RECORD_LOCATION);
int previousTotalAmountInCents = totalFile.readInt();
int newTotalAmountInCents = previousTotalAmountInCents + amountInCents;
//reset position to total record location so that we can write new total
totalFile.seek(TOTAL_RECORD_LOCATION);
totalFile.writeInt(newTotalAmountInCents);
} finally {
totalFile.close();
}
}
I could have broken this code out more, but I wanted something concise to show RandomAccessFile without much fluff. But, I also showed good coding practices. It's also a simple example that beginners could easily wrap their head around. Remember we are the teachers and it is our job to always show great code.
Sunday, July 23, 2006
Animals And Colloboration
My wife and I have been enjoying going to the zoo during the member appreciation days. It's been fun to watch and talk with the zoo keepers as they are feeding the animals. Last wednesday, we watched them feed the elephants. The interesting thing was that we always noticed that they kept the elephants separated. Someone asked, "Why?" The answer was simple, yet surprising: The elephants didn't get along. This got me thinking. Isn't it funny that we expect people to just get along when we randomly throw them on a team?
I've always believed that teams should pick their members. The most successful teams I've been on have all liked and respected each other. Sometimes the universe did align and I got on a random team thrown together that everyone magically jelled. But, that's only happened twice. It's easier to find people that all get along in small teams because the more people the more conflict and communication there will be. It's important when interviewing people that they interact with everyone on the team. Technical skills can be taught, but if someone rubs you the wrong way, then they are better being on another team. I firmly believe that there's a team for everyone.
Colloboration is richer in smaller teams that respect and like each other. The synergy is incredible. I just find it funny that even in the wild, not all animals get along. But, in the corporate and business world, we expect people to be randomly slammed together and just get things done. It just doesn't happen. Why build the team morale when you an start out of the gate with one kick ass team?
I've always believed that teams should pick their members. The most successful teams I've been on have all liked and respected each other. Sometimes the universe did align and I got on a random team thrown together that everyone magically jelled. But, that's only happened twice. It's easier to find people that all get along in small teams because the more people the more conflict and communication there will be. It's important when interviewing people that they interact with everyone on the team. Technical skills can be taught, but if someone rubs you the wrong way, then they are better being on another team. I firmly believe that there's a team for everyone.
Colloboration is richer in smaller teams that respect and like each other. The synergy is incredible. I just find it funny that even in the wild, not all animals get along. But, in the corporate and business world, we expect people to be randomly slammed together and just get things done. It just doesn't happen. Why build the team morale when you an start out of the gate with one kick ass team?
Lady in the Water
We went to go see M. Night Shyamalan's "Lady in the Water" on my birthday. What a wonderful movie. I love all of Shyamalan's movies. He's the best film maker out there right now. We gets you so involved with the characters that the plot seems almost secondary. Every minute of it was enjoyable. I wish there were more movies made like Shyamalan makes them.
Friday, July 21, 2006
Email Fixed
If anyone has been trying to send email via my web interface, please try again now. My provider changed how I was receiving mail and it started to kick things back. But, everything is good now.
Friday, July 07, 2006
July Omaha Dynamic Languages Meeting
July brings many surprises. Unfortunately, I will not be able to present Seaside because I will be out of town. But, fret not, I will be presenting Seaside in October. Jeremy Sydik has been kind of to step in short notice to give an overview of his trip to RailsConf! It might be a little short, so I thought it might also be nice to swap code/tell stories. So, fire up those computers and bring in those cool snippets that you are proud of! Or bring up a cool story on how dyanmic languages helped the day! We can all learn new tricks. I will miss everyone!
When | July 11, 2006, 7pm-9pm |
Where | Cafe Gelato 156th & Dodge 445-4460 |
Subscribe to:
Posts (Atom)