Geeky thoughts
Nov. 19th, 2007 08:27 amThought number 1: Like many geeks, I have a cluttered directory of "source code I've downloaded that I intend to do something with someday." My absolute biggest pet peeves with packagers who put source code onto the web is this: I open up the README file and it doesn't tell me what the program is or does. Sometimes, software can be very obscure, especially when it's system software. This morning I had to hunt through source code to find a URL and go to a defunct website to find out that this mass of undocumented code was some kind of audio sequencer.
Every README file ought to start with "[Program] is a [lofty sentiment] and can be used to achieve [these mundane tasks]." For example:
This sort of distribution results in a layout that "fits your brain," as the python people like to say. However, it makes writing the "how I did it and how it works" documentation style that I learned from Knuth very, very difficult. Knuth's style is extremely verbose, but Rails discourages verbosity. I haven't quite yet figured out how to integrate NoWeb with Rails.
Thought number 3: The Consilience example up above is no accident. There's a program that's been a hit with a lot of GTD people recently called Consistency, and while I can understand it's functionality, I just glanced at the help file that comes with it and the whole program just blossemed in my head. It's a pair of tables: TASKS (task_id, start_date, min_interval, max_interval, bool_active) and DONES (done_id, task_id, date_done). That's it. That's the whole program right there. Everything else is an implementation detail. Plus, it's been done before: there's a program for the Palm platform called BlueMoon that does exactly the same thing, and it's been around for five years.
It wouldn't take me more than a day to write it in Rails.
Sadly, I don't have "a day" anymore.
Every README file ought to start with "[Program] is a [lofty sentiment] and can be used to achieve [these mundane tasks]." For example:
Consilience is a ToDo list manager for tasks that happen only intermittently, rather than on a precise day and time. Consilience can be used to track your performance an routine tasks that are not necessarily done every day or every week, displaying your progress in a grid with color-codes to show your progress.Thought number 2: Rails handles just about every routine aspect of web application development you could possibly imagine. It's fast, efficient, and simple. For those things that can't be handled automatically, Rails has the generate script, which creates blank "your visuals go here" and "your business logic goes here" files to which you, the programmer, just add the knowledge needed.
This sort of distribution results in a layout that "fits your brain," as the python people like to say. However, it makes writing the "how I did it and how it works" documentation style that I learned from Knuth very, very difficult. Knuth's style is extremely verbose, but Rails discourages verbosity. I haven't quite yet figured out how to integrate NoWeb with Rails.
Thought number 3: The Consilience example up above is no accident. There's a program that's been a hit with a lot of GTD people recently called Consistency, and while I can understand it's functionality, I just glanced at the help file that comes with it and the whole program just blossemed in my head. It's a pair of tables: TASKS (task_id, start_date, min_interval, max_interval, bool_active) and DONES (done_id, task_id, date_done). That's it. That's the whole program right there. Everything else is an implementation detail. Plus, it's been done before: there's a program for the Palm platform called BlueMoon that does exactly the same thing, and it's been around for five years.
It wouldn't take me more than a day to write it in Rails.
Sadly, I don't have "a day" anymore.