Jonathan Altman

So I am going to set myself out a hopefully fun little challenge: 100 lines of code in 100 coding days. It's my challenge (and if this catches on, my meme ;-)), so I get to define my groundrules. Of course, someone else who wants to quibble with these is free to come up with their own groundrules for their own challenge, publish them, and see how they do on their own ground rules. Point of this, however, isn't to have a flame war on the ground rules. It's to write code, have fun, and see where doing something this regimented leads.

Ground Rules

• There will be 100 coding days. I am going to exclude certain days from the 100 day count like:

  • Any day I'm away skiing
  • Vacation by default, although if I feel like coding on a vacation day I reserve the right to make it a coding day
  • Operational crises at work, although hopefully those are going to be at a comparative minimum these days
  • Sick days, with the same caveat as vacation days
  • One weekend day a week, choice of which one each week

• For each of the 100 coding days, either:

  • Write 100 lines of code
  • Remove 100 lines of code by refactoring

• Lines of code are counted as any non-comment, non-blank code that has any alphanumeric symbol, constant, value, etc. Here are some things I will or wll not count as a line of code:

  • Do not count: comments
  • Do not count: blank lines (zero or more whitespace characters)
  • Do not count: closing lexical scope symbols like } in C/C++/Ruby etc
  • Count: closing HTML/XML tags. They have identifiers on them, so I'm counting them. And remember, these are my rules
• Blog about each day's experience: how many lines, what was accomplished, what issues were resolved or came up; any other thoughts about the day's effort
• Publish the code: put the code out there for people to see at some point when it gets done. I will probably use my github account

Why I Am Doing It

I have a whole pile of interesting hobby projects that have been sitting around, not getting very far. There is some tangential work application to some of them, but some of them are just brain stretchers: play with something new, learn it, figure out some paradigms and programming models. I am tired of not forcing myself past roadblocks in these hobby projects and letting them just languish. So this is a way to force myself to work on finishing at least one of them up. It is also an experiment in writing things that are just good enough. By pushing to finish them, I am hoping I won't get into bouts of perfectionism of making sure every single artifact in my code utilizes the cleanest, most elegant paradigm in the toolkit I'm working on, since a major part of the goal of this is intellectual mastery of the subject matter. Going back to refactor, I may clean things up and make them more elegant. But this may force me to _get things done_ instead of _polish them to perfection_. If I want to clean something up, I'll go back and do it after I'm done with a first cut.

What Am I Coding?

I have been playing with a Google App Engine application since right after their initial limited beta got expanded the first time and I got my invite. The app has been sitting stuck on a particular error for over 6 months now. So I am going to finish the application. One goal with the app, besides learning Google App Engine, is to build myself a modern, ajax-y web application using new shiny toolkits on the server and browser. As of right now I am using Google App Engine on the back end, and YUI for the DHTML/Ajax stuff. I may post more about the actual experiences with the toolkits as additional posts when there is a longer topic. DHTML toolkits is a very possible start. YUI is definitely an "accomodation" choice: there are reasons I'm using it here that are very specific to this project's situation that I'd like to explore.

After Google App Engine?

Another goal is to play with "cloud"-type apps. That was the interest in Google App Engine when it came out. Given that, if I actually finish the Google App Engine app, some other things I'd like to attack would be to see what challenges I face trying to port the app to different platforms, for example:

• Heroku, where I also have a beta account languishing
• A different python framework like TurboGears2 or Django, running on my Joyent Accelerator and maybe even Amazon EC2
• The Nitrogen Erlang framework, again hosted on my Joyent Accelerator or Amazon EC2 (or both!) There has been lots of discussion about portability, vendor lock-in, OSGi stack-level mismatches between various cloud offerings. By taking a sample app that is small enough to be written reasonably easily, but has enough breadth of functionality to tickle enough parts of a modern AJAX web app, maybe I'll provide some interesting data points about writing for the cloud.