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.
no subject
Date: 2007-11-19 04:58 pm (UTC)no subject
Date: 2007-11-20 01:15 am (UTC)no subject
Date: 2007-11-20 02:11 am (UTC)"Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server."
...of which I understand only the last two sentences. Where can I go to decode the rest?
no subject
Date: 2007-11-20 06:06 am (UTC)After that, reading the source code is recommended.
Basically, Rails is a framework (a wrapper for a program) written in Ruby, a language "like" Perl and Python (i.e. it looks a lot like them, but it behaves more like Scheme and ECMA) and you write a program, using Ruby, HTML, and sometimes Javascript, in that framework. When you run the framework, the program runs, giving you an interactive website backed by a high-powered database.
There are lots of frameworks like this. Rails is the "best" in that it does more than any other to get all of this done.