CSCI E-168

Oops. Reproduced the “todo” list in a post: Go over here if you want to make comments: resources/johns-to-dos/

John’s “to-do” list of miscellaneous things that have come up but haven’t been addressed. In priority order.

1. If you do instance_eval, can you get at private methods?
2. stack traces in exceptions?
3. method_missing — in what form do the args to the original method call come to method_missing?
4. super and initialize
5. screencast of Ruby editors
6. screencast of Rails IDEs
7. Inheritance, pros and cons
8. Ruby debuggers
9. Post VM image for pre-built Linux with Ruby and Rails
10. More on Ranges
11. Definitive statement on splat
12. Notes on hash keys
13. default namespace?
14. Multiple mixins, what happens to instance variables with same names?

The Evolving Project for Assignments 4, 5, and 6

Revision history:

• 28-Oct-2007 The following changes were applied to the schema: A foreign key to users from invitations marking the ownership of the invitation was removed; instead, go to the playdate for the invitation, and check the organizer of the playdate. The foreign keys to users from invitations and playdates to users were also changed to reflect their semantics.
• 22-Oct-2007 Tweaks to schema
• 21-Oct-2007 Original

The evolving project is called Childcare Co-op.

This project will be the basis for Assignments 4, 5, and 6 (the final project).

Assignment 4 is about ActiveRecord (database), and Assignment 5 is about Action Controller and Action View (application flow and display). Before I discuss the nature of the evolving project, a word or two about each of the assignments.

I’ll start with Assignment 6 — the final project.

For assignment 6, there are going to be two options:

1. You will extend Assignment 5, adding 2 or 3 new features leveraging other aspects of the Rails system. For instance, you might add REST, or generate XML feeds, or manage e-mail. We will provide a list of possible new features.

2. You can propose a project of your own. It will need to have a data model and browser interface that is at least as complicated as what you develop for Assignments 4 and 5, as well as 2 or 3 new features, as in Option 1. For option 2, you will need to write a project proposal, and get it accepted by your grader. I haven’t decided on a due date for the final project proposal, but right after Thanksgiving is pretty likely: So that would be around Nov. 25.

Option 1 has more guardrails, and is probably more suitable for people who want to go deeper into Rails details. Option 2 is probably best for students who have an existing project they want to create with or adapt to Rails. NOTE: You may not adapt an existing Rails project. E.g., if you already have your own Rails site, you may not build on it to satisfy Option 2. It must be new work.

Assignment 4 is about creating the data model for the project using ActiveRecord. This assignment will have many automated tests.

Assignment 5 is about creating the controllers and views for the project. Some parts of this assignment will have automated tests. Also note that we may very well throw out the specific data model from Assignment 4 — that is, we will likely hand out a modified data model for Assignment 5. It will be very much like Assignment 4, but it will become more or less complicated depending on how Assignment 4 goes. Assignment 5 will also be looser in the sense that there will be some opportunities for development that isn’t as constrained by testing.

Ongoing project for Assignments 4, 5, and 6 (Final Project): Childcare Co-op

The Childcare Co-op is a web-based product that helps parents organize playdates for their children.

Scenario

Many families organize “play dates” for their kids. Parents and kids get together for a couple of hours, say, on a Saturday afternoon at a park or playground. Other locations for play dates are someone’s home, the zoo, etc. The kids get to play, and the parents get to talk. Typically one parent will organize the play date. That parent, or another parent, may be responsible for bringing a snack for the kids. The responsibility for “hosting” the play dates may rotate amongst the parents.

The Problem

It turns out that this kind of activity is hard for parents to organize. There are a number of reasons for this. First off, parents are incredibly busy, so remembering that there is a Saturday obligation is sometimes hard. Second, the scheduling for kids is oftentimes not managed by the same software parents use at work. It’s a different calendar, and can be very poorly managed (could be on paper, on stickies on the fridge, or on fading ink on the back of one’s hand…). Parents also require notifications of upcoming play dates, via e-mail and text message.

It is worth noting as well that existing products are not very well suited for this kind of social organization. For example, generic calendars don’t provide for the kind of security we imagine (that is, privacy amongst the parents). Blogs are too public as well. Facebook is an interesting possibility, but it’s also not very private, and the target Facebook audience is still primarily college students, despite the growth in the over-25 demographic. Having said that, Childcare Co-op will eventually provide means to publish information to calendars (such as Google Calendar), and it will expose and consume feeds. In other words, the product will leverage the existing protocols of Web 2.0 to make it a platform for organizing multi-family information.

Market Opportunity

Because of the pain of keeping play dates organized, we believe that parents would pay for this service. When a parent signs up, he or she will pay $20/year to participate in as many playdates as he or she wants. When a playdate is created, parents are invited by e-mail. If the invited parent is not registered, they will have to pay the $20/year themselves. As an option, the initial host may pay for invitation credits, so that the signup cost would be waived for selected invitees. By this means, we believe that Childcare Co-op will have viral adoption. The size of this market is vast: There were 36 million households in the United States in 2006 with children under 18 (http://www.census.gov/population/www/socdemo/hh-fam/cps2006.html - table AVG3). Capturing even a 10th of a percent of this market would be 36,000 households; at $20/family, that would be revenue of about $720,000/year. We believe that the primary market will be households with annual incomes of $75,000 or higher. These are typically families with two wage-earners who are time-strapped and might find the service useful. To start, Childcare Co-op plans to focus on the greater Boston market. In Suffolk County, there are 26,417 households with incomes of $75,000 or greater (http://www.dwellings.com/dw/pages/boston.html). Guessing that at least half at that income level have at least one child, that would be about 15,000 households with children. In Boston, we hope to capture 1% of that market (150 families) by the end of a year. That would result in revenue of about $3,000 per annum which is a good start. (We will also serve Google AdSense ads, though that probably won’t make us any money for quite awhile). The subscriptions would obviously pay for all hosting costs, which would be less than $200 for the year. The rest of the money would be used for targeted marketing, chiefly Google AdWords) for the second year.

Customer Story

Lisa Smith and Rick Jones are married and have two children, Boris (age 10) and Sara (age 4). It happens that Boris’s last name is Jones and Sara’s last name is Smith. They call their family the “Smith-Jones” family. Lisa and Rick have a part-time babysitter named Cassie Rogers, whose schedule is somewhat unpredictable. Most every Tuesday there is a playdate at 10 AM for Sara at Lincoln Park. (Note that sometimes the playdate is delayed until 10:30 AM because another family sometimes has a late breakfast. In most cases, Lisa takes Sara, but sometimes Cassie takes over. The playdate lasts two hours and includes lunch. There are four other families who usually attend the playdate, with 6 kids among those families. At each playdate, one family is responsible for bringing a snack suitable for all of the kids.

Lisa is de facto the leader of the playdate, and she’s been having a lot of trouble lately keeping everyone up-to-date on the schedule. Some people like to be notified about the starting time and the snack obligations by e-mail, while others want text messages. And some people need a week’s notice, while others just need to be updated the night before.

Lisa also takes Boris to soccer practice most Wednesdays right after school; that’s at 3:00 PM. She has missed at least one practice because the coach didn’t tell her about the date. It happens that the coach’s 4-year old son is also in Sara’s playgroup for the Tuesday playdate.

Clearly, Lisa needs help.

Using the Product

NOTE: What is described here is a bit in advance of what will be released for Version 1.0.

Lisa has recently heard about Childcare Co-op and how it makes it easy to organize these kinds of events.

She goes to the web site, and first registers herself, providing her e-mail address, phone number, first and last names, address, and other materials required to charge with her credit card. Lisa is given the option to pay $20 in advance for others (i.e., she can buy “credit” in the system.

Then, as time permits, she enters information for each of her children (Boris and Sara) and for the other two parents / guardians / caregivers for her family (Rick and Cassie) [remember: caregivers are out-of-scope for 1.0.]

Next she defines a Playdate “Tuesday Lincoln Park Playdate” for 10 AM every Tuesday.

Now she invites other parents to participate by entering their e-mails and an optional message. She can also check the invitation so that the recipient is paid for by any credits she might have in the system (credits are only drawn down when a recipient actually registers and is confirmed by the inviter). The e-mail invitations are sent out. Each notification contains a link that, when clicked, returns the user to the site. If the e-mail is in the system (i.e., the parent is already registered) the parent is allowed to add his or her kid(s) to the playdate. If the e-mail is NOT in the system, the recipient is invited to register (and pay, if Lisa didn’t pre-pay them), or log in. Then the user is given a means to join kid(s) to the particular event. If Lisa had already had a playdate joined by other kids, then during the invite process she would have been given an opportunity to check off any “already known” kids. The parents of those kids would be sent the invitations.

Once an event is set up, and invitations are sent out, Registered invitees can review the event and see who’s coming. The parents of participating kids can control their notifications of upcoming playdates.

Now Lisa has a consistent reminder for Sara’s regular Saturday playdate. Because Boris’s coach joined Childcare Co-op because of his son’s participation in the Saturday group, he has started using it to manage soccer practice. Recently, the coach changed the practice start time, and Lisa received a text message the night before with the updated time. So for once she isn’t surprised when the practice time changed.

Some Initial Use Cases

1. A Parent can sign up for the service. During the alpha, the product is free and registrants don’t need to supply credit card info, etc.
2. A Parent can define multiple Children.
3. A Parent can define a Playdate.
4. A Parent can invite others (by e-mail) to participate in a Playdate.
5. A Parent can review Invitations.
6. A Parent can accept an Invitation.
7. A Parent can associate a Child with a particular Playdate.
8. A Parent can review upcoming Playdates.

Technology

The product is designed and built with Ruby on Rails. Because the requirements for the product will change frequently owing to intense assessment of customer needs and wants, we require a platform that is amenable to rapid iteration. The CTO/co-founder who is responsible for the technology has experience with JavaEE, .NET, and Ruby on Rails, and in her own development practice she has found that Ruby on Rails is especially appropriate for a product like this one because of the framework’s shallow learning curve and quick demonstration of results. The product in its present form also does not require heavy enterprise integration or internationalization (two weak spots for Rails, though engineering believes that by the time the product goes international, these problems will be solved by the Rails community).

Furthermore, the CTO is aware of a new course n Rails offered by Harvard Extension. The new course promises to increase dramatically the number of local developers who are proficient in Rails — so she is not too worried about a lack of developers should the product take off and the technical team need to be expanded.

The CTO plans to have a working product with the basic features completed in a couple of months, and a full preview release (working beta) in three months. One thing that will probably be out of scope for the working beta is payment processing and some other security features regarding invitations. There is also a key feature involving the delegation of responsibility to non-subscribers. That will have to come later.

Getting Started

To begin development, we’ll focus on the data model that will support the product. Here are some of the entities (things) the product must manage:

User: Someone who can log in. Very generally, this is a parent. We may actually change the name to Parent at some point. Users can invite other users to join their children to Playdates. NOTE: For the initial version, “Subscriber” is a synonym for “User” in all requirements. In a later version of the product, there will be two types of Users, Subscribers and Caregivers.

Caregiver: [Caregiver is out of scope for initial version — do not implement.] a person to whom a User may delegate responsibility for her children. Caregivers can also log in; i.e., all Caregivers are also Users. A Caregiver might be an aunt, uncle, babysitter, nanny, or close friend. A Subscriber may have 0 or more Caregivers. A Caregiver may be a Caregiver for many Subscribers. A Subscriber may also note that a Caregiver has custody of her Children.

Note: Thus a Caregiver can do many of the things a Subscriber can do, with one very important exception: A Caregiver cannot invite others to a Playdate.

Note: A Subscriber’s Caregiver may be responsible for any of the Subscriber’s Children at a Playdate. We do not model the idea that one Caregiver might be responsible for, say, only one of the Children, while another Caregiver is responsible for the Subscriber’s other kids. The point of designating a Caregiver as having custody (like a Subscriber) is to support different levels of information privacy and authority between Subscriber and Caregivers. For example, only a Subscriber or a Caregiver with custody can change a Child’s allergy settings.

Finally: It is possible for a Caregiver to be such for more than one Subscriber. Indeed, a User might be Subscriber herself, but a Caregiver for another Subscriber. [In other words, there has to be a join table.]

Child: We interpret “child” very loosely: a Child is a person who is managed by a Subscriber. A Subscriber may have 0 or more Children. (Remember, in the initial release, by Subscriber we just mean: User.)

Location: A place for a Playdate. A Location may be marked as “public” so that Subscribers [out of scope: and Caregivers] can comment on it, and so that it can be used by others during Playdate scheduling.

Playdate: something that happens at a Location on a certain date, starting at a certain time. There is also an optional end time. The Location may be null (i.e., unassigned at the time the Playdate is created: Essentially, that would mean that the Playdate Location is TBA). Subscribers create Playdates, and invite other Subscribers [out of scope: and Caregivers] to participate. In the web application, but not in the data model, a Subscriber will also be shown the names of children whose own subscribers have previously accepted playdate invitations — the invitation to a Child in the web app effectively goes to the Child’s Subscriber.

Here is a diagram of these entities and their relationships (click for larger view) (about the schema diagram: The relationship lines in all cases show one-to-many relationships. The “crows-feet” icon designates the “many” side of the relationship. In other words, in the diagram, a user may have many children. For some discussion, see http://en.wikipedia.org/wiki/Entity-relationship_model#Crow.27s_Feet):

Based on these entities and relationships, we should be able to answer the following questions:

Who are the children of a subscriber?

What are a subscriber’s created playdates (i.e., managed by the subscriber)?

Which users are invited to a playdate?

What children are assigned to a playdate?

Where will that playdate be located?

And so forth.

“Art inhabits the country between chaos and cliché.” — Barbara Herrstein Smith.

Take a look at that quotation above from B. H. Smith. Your code needs to observe her rule about art. Obviously there is a big problem if your code is chaotic: No one will understand it. What about cliché? Writing code that takes no advantage of the power that Ruby gives you is clichéd: It’s just the same old boring code you could write in any language like C, Java, etc.: Wordy, baggy, voluminous. Ruby gives you the opportunity to be concise and elegant. What follows are some notes so that you can write stylistic code, which is to say, code that that is neither chaotic nor clichéd.

Please let us know if there are additional topics you’d like to see addressed here.

Visual Style

• indent 2 spaces: “using two-character indentation will make you friends in the community if you plan on distributing your code” (Pickaxe, p. 14). If you are flagrant in your disregard of this recommendation, we may ask you to update your formatting and re-submit. Make sure that your editor uses spaces for the indentation. Some editors will accept tabs and present the indentation visually as two spaces, while there will be tabs in the file. In any case, here’s what two-character indentation should look like:
  [sourcecode language=”ruby”]
  class MVC
  # Instantiate an MVC applicatio with the given Model and Array of Views
  def initialize(model, *views)
  controller = Controller.new(model, *views)
  controller.get_input
  end
  end
  [/sourcecode]
• line up your hashes all pretty, please. don’t make a hash of them.
  [sourcecode language=”ruby”]
  ZIP_COMMANDS = {
  ‘0. Native ZIP’ => ‘zip’,
  ‘1. rubyzip’ => ‘ruby ‘ + quote_if_windows(File.join(File.dirname(__FILE__), ‘bin’, ‘zip_in_ruby.rb’)),
  ‘2. PKZIPC’ => (quote_if_windows(File.join(File.dirname(__FILE__), ‘bin’, ‘PKZIPC.exe’)) + ‘ -add -dir -r’)
  }
  [/sourcecode]

Conventions

• do/end vs {}: If a block contains 1 (or 2…) statements, use braces. If it is a multi-line block, use do/end (Pickaxe, p. 21).
  [sourcecode language=”ruby”]
  a = [ 1, 2, 3 ].collect { |e| e + 1 }
  [/sourcecode]
  vs.
  [sourcecode language=”ruby”]
  a = [ 1, 2, 3 ].collect do |e|
  puts “incrementing #{e}”
  e += 1
  end
  [/sourcecode]
  Remember that the precedence of braces is higher than do/end (see Pickaxe, p. 168). Generally, this means that braces apply to the single item just to the left of the braces, while with do/end, everything to the left is evaluated first… The stylistic issue here is that it’s unclear without parentheses:
  [sourcecode language=”ruby”]
  def method1(p1, p2)
  if block_given?
  yield
  end
  end
  def method2
  if block_given?
  yield
  end
  end
  # do/end binds with method1 (do/end has lower precedence)
  method1 1, method2 do puts ‘do/end block’ end
  # {} binds with method2 ({} has higher precedence)
  method1 1, method2 { puts ‘braces block’ }
  [/sourcecode]
• don’t use globals, please. Guess what? We haven’t taught you the syntax for global variables. If you need something at the “global” level, stick it in a file, and then create a class that supplies that “global” variable to any other class that needs it. Why do globals stink? First off, you’re asking for a name collision (some other class may just happen to make different assumptions about a global with the same name). Even if the name is sufficiently obscure, you’re locking in any code that would also use that global to that specific name. Ick.

Idioms

• ||=
  
  The idea here is this: You want to assign a value to some variable only if the variable doesn’t have a value. If you ask for the value of a variable that has never been defined, that value is nil. Therefore, you can write “a = a || 10″ which means: If a does not have a value, set it to 10. Shorthand: a ||= 10. I’m a bit surprised that the Pickaxe doesn’t discuss this.

Things to Avoid

• Special variables such as $=, $/, etc. (see Pickaxe, p. 333ff). Why? They’re just not clear. If your shop has lots of Perl developers, maybe it’s ok.

Rules of thumb

Some of these are a bit sketchy . . . will get expanded over time.

• When to use parens with method names (short answer: If there’s any hint of ambiguity, use parens)
• If you want to use return, be consistent
• how much method chaining is reasonable? (Law of Demeter)
• Lots of short methods: good
• consider a flat / shallow class_hierarchy
• Metaprogramming is appropriate when…
  • Huge payoff in terms of usage (esp. if facilitates DRY)
  • Can’t be done any other way

This screencast goes through the Assignment 3 package. We’ll focus on:

• The package layout. By and large this is a pretty standard layout for a Ruby application. (Not a Rails application — a plain Ruby application.)
• The assignment (in the instructions/ directory).
• The files you need to modify to finish the application.
• What the demo.rb application looks like once your code is working.
• What it would look like if your code passes all of the tests.
• Three strategies for getting the assignment done:
  1. Think about the big picture, and about how you’d design your own application to determine the strength of a random selection of 5 cards according to the rules of poker. You might even write such an application. Then you would adapt it to satisfy the tests.
  2. Study the instructions/ web pages, and implement the code according to the various definitions of the classes and methods.
  3. Try to pass the tests one by one.
• We believe that the best way to proceed is through a combination of 2 and 3. 1 is hard, because it may turn out that the semantics you come up with are at odds with the framework we’ve defined for the tests. So . . . we will walk through a bit of combining strategies 2 and 3, showing:
  1. The rake command (more on rake: Pickaxe, p. 229 [a bit out-of-date], and this tutorial: http://www.railsenvy.com/2007/6/11/ruby-on-rails-rake-tutorial
  2. What a test looks like (more: Pickaxe, chap. 12)
  3. How to interpret what a test “Error” or “Failure” means
• That should be it.

A word to the wise: Writing code to tests will look bewildering at first, but once you start doing it, you will love it.

View (you will want to maximize your browser; to go “full-screen” in Firefox, press F11; then to turn off full-screen, press F11 again)

Errata:

1. When I define the reader for @card_number, I say that I’m defining a local variable. In the heat of producing the screencast, I misspoke: It’s an instance variable.
2. Also, when I’m nattering on about converting card_number in the appropriate suit, I say: card numbers 2 to 25 are Hearts. Of course I meant 13 to 25. I get these things wrong. That’s what computers are for!

“Computers are useless. They can only give you answers.” — Pablo Picasso

Folks,

A few notes:

1. I’ve posted the slides and a link to the slide outline:

http://e168f07.7fff.com/private/lectures/

I *will* be tweaking Lecture 3, so stay tuned for a revised version that fixed the “spaceship” example and a few other things. There is also a ZIP of some scripts for Lecture 3 that are easiest run outside of the browser (i.e., the normal way: See below).

2. There is also a link to download all of the lectures in one bundle. This includes the code to make the dynamic Ruby in the slides work, so it’s a hefty download.

3. The provisional version of Assignment 3 is here:

http://e168f07.7fff.com/private/assignments/

To read the instructions, open instructions/rdoc/index.html

The requirements for the assignment will not change. A later release of the assignment will include expanded tests, and possibly more documentation on some of the methods. If you’re an early bird who plans to look at this right away, by all means e-mail me requests for clarifications and I try to get them into the next release.

4. I will make a screencast that shows how you would work on Assignment 3, running the tests as you study the assignment.

5. I left out something rather important in last night’s lecture:

We have now moved from working in irb to writing full-fledged Ruby scripts.

A multiple-line Ruby program goes into an ordinary text file. It should have the file type .rb. Examples:

game.rb
card.rb

etc.

To run the script, you type:

ruby game.rb

See Pickaxe, p. 7.

Linux and OS X users: Of course, you can make the name of the file just ‘game’ and use sh-bang notation to define what should run the file (see p. 7, note 2) and chmod +x the file. And, of course, you can stow your scripts anyplace you want and put that location in your PATH.

Windows users: The one-click installer does some magic so that if you have a script in your current directory called, say, game.rb, and just type ‘game’ . . . and it runs. Or is supposed to. If you installed in other ways, this might not work, and it’s a bit of a pain to get set up. If you’re interested, I will circulate instructions.

Four students have asked me what blogs/feeds I read, so I suppose I should answer the question, since there are probably more people who are curious but not inclined to arouse my vanity by asking such a question.

Here are a few notes on how I leverage feed reading personally and professionally.

First off, the beauty part of a feed in my humble opinion is that it comes to your via your reader in a uniform format; so I don’t have to be distracted by the idiosyncratic layout or ads on a random blog. I do appreciate good-looking blogs, but when I’m in my reader, I’m consuming information rapidly. Indeed, I’m frequently sifting it. I really don’t have time to read a lot of info from the web; indeed, I find it rather counter-productive. But for competitive reasons I need to stay on top of certain things. Here’s a list; first work, then personal. The links are to the blogs, you can find the feeds yourself. I’ll save Ruby/Rails and engineering feeds for a later time.

Work

1. I subscribe to all of the blogs of our direct and semi-direct competitors, and all of the blogs of the developers in those companies. I have learned some amazing things this way — I’ve known about layoffs before the employees of our competitors in some cases. I also know a lot about their software and hardware infrastructures, and about their development strategies. So I know who’s doing a great job executing technically, and who’s blowing it, which can be very helpful when we think about partnering or exposing our web services to another company. If you pursue this strategy, note that sometimes the profiles of people on social networking sites expose a feed, so if their employment status changes, you can monitor it.

2. I subscribe to the blogs of pundits in our marketplace. I won’t mention most of them by name because they don’t need to know how interested I am in what they say, but I will say that Cheezhead is great.

3. I subscribe to a key few excellent blogs regarding high tech business in general. The best for me are Xconomy (local news regarding Kendall Square and greater Boston), GigaOM, John Battelle’s blog, and Rough Type, Nicholas Carr’s blog.

4. I subscribe to a lot of alerts regarding system uptime and platform changes. For example, TextDrive has a feed about system reboots, and Facebook has a feed about their frequent and embarrassing disruptions in service. These are worth searching out if you depend on any services.

5. I subscribe to a lot of engineering feeds; more about that in a later post. As it happens, it rarely occurs that I read something technical that has immediate impact on software development in the company; usually consequential changes there build up after a lot of reading and thinking.

6. I subscribe to a few feeds regarding venture capital. A mixed bag. Because everyone wants their money, many of the VC bloggers know they have an audience and will blog about the most inane things.

Personal

Here I’m just going to list some of my all-time favorite feeds/blogs.

10. Rands in Repose. This is one of the greatest project management blogs, ever. The posts are long but fascinating. Here’s a recent one regarding job interviews. The author has compiled his bests posts into a book.

9. Scott Burns is a personal finance columnist for the Dallas Morning News who is oriented around numbers. He’s carried in the Globe. What makes him a little different is that he co-wrote an important book with an economist on how demographic changes affect debt, the value of the dollar, and inflation, the Coming Generation Storm.

8. xkcd. This is the blog with the famous “sudo make me a sandwich” cartoon.

7. A feed from the Washington Post that tells me how my congressman has been voting. This is actually quite tedious because it is loaded with reports on, e.g., “Expressing Sympathy and Support for the People and Governments of the Countries of Central America, the Caribbean, and Mexico Which Have Suffered From Hurricanes Felix, Dean, and Henriette and Whose Complete Economic and Fatality Toll Are Still Unknown” (I don’t mean to diminish this gesture, but it seems to be on a different level from a vote regarding policy). Frankly I should stop subscribing to this because I always know how he’s going to vote; but if you have a rep who needs monitoring, this is useful.

6. Steve Yegge’s blog. Always interesting. Long posts. You have to control for his spin. Like Rands, a matter of recent interest for him is strategizing the job market. Wonder what’s going on with these guys? Anyway, I read him for the tech commentary, not for the biz.

5. Collision Detection, the blog of Clive Thompson, who writes frequently for Wired and the New York Times. His speciality is reporting on unusual or provocative recent scientific findings. He also writes on computer games; his best stuff in this regard are his pieces on so-called “casual” games.

4. The Cambridge Chronicle. I think they must cherry-pick articles for their feed, because a lot of the posts are about people getting shot in the butt, loud parrots, and stuff from the police blotter, an alarming amount of which happens within a three block radius of where I live. My town.

3. Bug Bash. Cartoons about, um, product development? Teamwork? I don’t know, but it’s all too true. Maybe this should be in the “work” category.

2. Crud Crud. I subscribe to a lot of music feeds, most of them awful. I need to unsubscribe to most. But a good one is the Crud Crud blog of Steve Soriano, who reports on oddities in his expansive collection of dusty singles (7″ vinyl records). He also rips from the vinyl, so the MP3s he puts up are really quite rare and hard to come by. Caution: Edgy.

1. Google Sightseeing. People report on strange things they’ve identified in Google Maps; or things of historical or engineering note, such as this recent one. This may well be my favorite feed of them all, and it’s first on my list in my reader.

There have been a number of inquiries about this: So far e-mail addresses have only been in lecture materials, etc.

For the record, staff e-mail addresses are: john at 7fff dot com and amy dot newell at gmail dot com.

Guest starring: Max Newell of thirdbIT
(In two parts)

Ruby and Rails Install Screencast for Mac OSX, Part 1

Ruby and Rails Install Screencast for Mac OSX, Part 2

This presentation is a quick walkthrough of installing Ruby, Rails, and MySQL on a Mac OS X Tiger ( 10.4) machine. It’s somewhat simpler than HiveLogic’s excellent tutorial, which requires building Ruby from source.

The prerequisites: You’ll need an account that is allowed to provide administrative functions, and you’ll need to have downloaded the MySQL installer and the Ruby one-click installer.

1) Install MySQL from .dmg package. This doesn’t have to go first, but it does have to go before the very last steps. Download from http://dev.mysql.com/downloads/mysql/5.0.html

2) Install Ruby oneclick; download from http://rubyosx.rubyforge.org/

3) Install rails via gem: “sudo gem install rails –include-dependencies” from terminal window.

4) Install the mysql bindings. Rails doesn’t require these native bindings to connect to MySQL, but the performance is better.
“sudo gem install mysql — –with-mysql-dir=/usr/local/mysql”
Choose most recent native Ruby gem.

5) Lastly, you must run this step to avoid Rails/MySQL problems when using the native bindings:

“sudo install_name_tool -change /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib /usr/local/mysql/lib/libmysqlclient.15.dylib /usr/local/lib/ruby/gems/1.8/gems/mysql- 2.7/lib/mysql.bundle”

6) Test Rails application: “rails test1″ ; “cd test 1″ ; “script/server”
Test localhost:3000 in browser window.

7) Edit ~/.bash_profile and add /usr/local/mysql/bin to PATH.

HiveLogic tutorial describes how to do the whole shebang from source: http://hivelogic.com/narrative/articles/ruby-rails-mongrel-mysql-osx

Cheating BAD, but Cheatsheets, GOOD

Okay, in the first class John mentioned Harvard’s very detailed policy about academic integrity. And I mentioned that my favorite gem was cheat. I thought I’d throw together a few of my favorite Ruby and Rails cheatsheets for your benefit as well. I’ll post more specific cheatsheets as we reach the specific topics that they’re about.

• My top pick: InVisible’s Rails reference: 20 pages of rails cheatsheet goodness. I still use mine all the time, as it’s often the fastest way to remember some syntax. Note that it is for Rails 1.1, not 1.2, so there may be some deprecated stuff there (not much, though).
• There’s a cute little one-page Rails cheatsheet available from the bizarrely named site ILoveJackDaniels.com.
• And here’s a two-page Ruby cheatsheet.

Two Textmate and Ruby/Rails cheatsheets here for your cheatsheet pleasure:
http://pragmaticstudio.com/rails/RailsTextMateCheats.pdf
and

http://www.fruitionsoftware.net/blog/2007/06/27/textmate-ruby-on-rails-cheat-sheet/