If you’re reading other books, articles, blogs, on Ruby, Rails, etc., by all means post a review or comment in our books section. If you find a resource that is truly outstanding, I’ll get it and add my own review to our annotated list of resources.
Also, I notice that I hadn’t actually published that “John’s To-dos” page. It’s there now.
Oops. Reproduced the “todo” list in a post: Go over here if you want to make comments: resources/johns-to-dos/
Now that we are past the one-liner era in our progress along the Ruby Way, I’d like to invite you to propose some one liners of your own.
Just to kick it off:
Given a dictionary d with bad words:
d = [ ‘Yankees’, ‘Rockies’, ‘Indians’ ]
write a one-liner that replaces any usage of such bad words in a sentence with the first letter of the bad word followed by stars, one star for each of the remaining letters.
Input:
“As much as I can’t stand the Yankees and relish beating them, I’m glad we faced the Indians.”
Output:
“As much as I can’t stand the Y****** and relish beating them, I’m glad we faced the I******.”
P.S. I haven’t implemented this one. Seems like a one-liner . . .
John’s “to-do” list of miscellaneous things that have come up but haven’t been addressed. In priority order.
I’ve added a page with an overview of Assignments 4, 5, and 6 (also in the sidebar under “Assignments”). Comments most welcome on the general project / product; questions for Assignment 4 and ActiveRecord specifically will be more appropriate for the page on Assignment 4, which will be appearing shortly…
Revision history:
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.
The Childcare Co-op is a web-based product that helps parents organize playdates for their children.
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.
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.
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.
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.
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.
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.
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.
Here’s a link for some Perlisms in Ruby. There are of course many more that those the author lists here:
http://blog.nicksieger.com/articles/2007/10/06/obscure-and-ugly-perlisms-in-ruby
The whole discussion is very interesting. I think the author is being awfully harsh on the defined? method, because it is easy to imagine scenarios where you’re having a little trouble determining if Ruby is understanding something as a method or constant.
“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.
Some of these are a bit sketchy . . . will get expanded over time.
While working on the page that will display Ruby style suggestions, I discovered that the 800 width was really not too hot for code snippets.
So I have hacked the theme to assume that the screen is 1024 pixels wide or larger. Even if you are in that 14% (probably less now) of users with an 800-pixel wide screen, the main page area still fits within that width.
There are still a couple of widths that are funky (e.g., for comments) and I had to lose (for now) the banner image and the background behind the sidebar, but those will come back in some form.
As you will recall, I set up this site so that books ordered on Amazon through it (and I also put some links on my personal blog) would generate referral earnings.
Well, we’ve now earned $144.53, which we will be spent on ourselves [i.e., people in the course] toward the end of the semester . . . for food and drink at some kind of post-meeting event.
Recent Comments