Week 8 Day 5: The Calm After the Storm

Major Activities of the Day: Today we had a lot of free time.  (It's sort of a running theme for Fridays.)  Since my major presentation was yesterday, I was too wired up to really use the time productively.  I ended up chatting with a few other students, getting to know people better, talking about the meetup and our projects, trying to get some advice about what went well and what didn't.

Of course, I couldn't just abandon my project 100%.  So I went back and tried to figure out what went wrong with Facebook login.  It turns out (and I discovered this in about 2 minutes, fixed it in maybe 3 more) that Facebook requires you to tell them that your app is live and available for people to access.  In practice, this means that at developer.facebook.com, on the page for your app, you flip a switch to indicate that the app is live.  That's all.  I also now understand why I could log in - because I'm the developer - but no one else could.

At the end of the day, Avi spoke for a while about Project Mode, which we'll be having for the next few weeks.  It sounds pretty cool - build a new web app every week, in a group of 2-3 students.  We're also supposed to deploy every day - i.e., we need to have something deploy-ready on day one, and then build up from there.  It'll be a very different atmosphere than we've had until now, but that's not a bad thing - in fact, it sounds like a reasonable approximation of the atmosphere we'll have in real work environments, with strict deadlines and lots of teamword.  Looking forward!

Skills developed: Not much today, to be honest.  But I'm super excited for next week!

Week 8 Day 4: Eateract!

Major Activities of the Day: Alright, I'll be honest.  We got some labs to do today, but I ignored them, because... tonight I presented at the meetup!  My project is called Eateract.

At the center of the application is a super-fancy JavaScript/Ajax-based form that grabs user options from the server.  The user puts together a meal - invites friends, chooses a topic of conversation and some links to send out, searches for recipes (using the Yummly API) and assembles a menu, adds a custom message, picks a date and time, and submits.  The application then sends emails to the requested users, letting them know they've been invited to a meal, and giving them a link to the meal page.  On the first page load, they can accept or reject the invite, after which subsequent loads will just lead them to the page.  They can volunteer to make particular recipes, and the application shows each user who's signed up for what.  Of course, there are active links to all the recipes, as well as the links the host has selected for everyone to view in advance.

By the way, here are the pieces I added today:

• Full display for an individual meal
• ActionMailer to send emails to guests
• HTML email (designed for Gmail - sadly, it broke horribly when I tried it in Yahoo! mail)
• Authentication tokens for guests so only guests, not random people, can see the meal (the tokens are included in the links being sent out in the emails)
• Add custom message to email
• RSVP system

So yeah, you can do a lot with Rails in one day, even as a newbie.  You can check out the code at https://github.com/amcaplan/eateract; I'll post an update to this post once I put up the app on Heroku.

One slight problem happened during the presentation.  I have Facebook login for hosts, and during my presentation, I tried to do a live demo with a new user volunteer from the crowd.  Unfortunately, the login failed for her, even though it always worked for me.  Should have done a user test first with someone besides myself... anyway, I just logged myself in, and then let her act as me.  After that, pretty much everything was fine.

Truth is, what stuck with me wasn't a feeling of how good my product was.  I'm very proud of what I was able to put together, but to me, what was more important was just forcing myself to get in front of a crowd, present enthusiastically, and not get fazed by bugs (because I was sure that bugs would crop up, and hey, one did!).  I tried to imagine myself giving a TED talk, and used that sort of method - walk around the stage, interact with the crowd, tell people to call stuff out - I think the audience responded well, even if I went a bit overtime.

Bottom line - why did I do this project?  Because I see how we as a society are becoming more addicted to social media, and losing our ability to connect face-to-face.  I see phones getting pulled out at meals, if not entire laptops, and I worry that our connections with others are becoming superficial.  So I decided to put together a project that would flip the agenda - use technology to generate, rather than break up, meaningful social experiences.  I also imagine that this would provide a toolset for parents to talk about values with their children.  It's not a matter of parents transmitting values as much as showing their children that values are important and worth thinking about.

P.S. Here's a couple of screenshots:

Homepage before login

The beginning of the form...

Choosing a topic

It's responsive!  (This is the small-screen view)

Choosing recipes

Whoa!!! It's a super-cool modal!

After a meal is created

A dashing dashboard

Skills developed: Technical presentations in front of a crowd

Week 8 Day 3: Persistence is Key (or: Persistence in Object Keys... and Values!)

Major Activities of the Day: Today started with a couple of jQuery labs.  I ignored them, because I'm going crazy worrying about my project, and I feel like I'm learning more by doing an actual project than by doing predesigned labs that isolate me from many of the problems.  It's good to have that isolation and really focus on one problem initially, but once I'm more comfortable, it just feels like going backward.

We had lecture today about the power of remote: true in Rails.  It's basically a shortcut to setting up an Ajax form.  More info is available in the Rails guide about Ajax.  (Warning: the information there is written in CoffeeScript rather than plain JavaScript.)

We moved on to some more labs, which I continued to ignore for the above rationale.  Aaaaand there was homework.  Ignored.  Doing a project, is hard, ok, people?

Here's what's interesting, though: I had to figure out how to make the page persist data while the user was making selections, despite the fact that the page was displaying other things.  Here's what I mean: The page displays a bunch of links related to a particular issue, and the user can check off particular links.  The user might decide to check out a different topic, but then come back to this one.  I want the user to not need to re-check what was checked before.  So I used an array in the background that is updated when any checkbox is checked or unchecked, and when the user switches topics, it looks in the checked links array for which, if any, link have been checked before.

Here's a more complex example: I'm displaying recipes collected from Yummly's API based on a user's search.  These recipes are selectable via checkbox, and the selected recipes are displayed in a menu at the top of the page.  Here's where it gets challenging:

1) I want to let the user do multiple searches, and have the recipe data persist from search to search.
2) I want the user to be able to go back to a previous search, and have everything checked off as appropriate.
3) I want to store 2 pieces of information about each recipe: its name and its Yummly ID (which I can use to build a link in the form http://www.yummly.com/recipe/[recipeID]).
4) I want the user to be able to remove menu items by either clicking "remove" on the menu next to the item, or unchecking a box in the search.
5) When the form is submitted, exactly one copy of the selected recipes should be sent to the server.

Here's how I did it: There is a plain old JavaScript object in the background, which uses recipe IDs as keys and recipe names as values.  Every time there is a checkbox checked or unchecked, or the user clicks on "remove" next to an item on the menu, the object is updated.  Additionally, there is a hidden text area which is updated with the toString()ed contents of the object.  When the form is submitted, the contents of the text field are interpreted by the controller by converting the string to a hash using the ActiveSupport::JSON::decode method, and the hash can then be used to input information into the database.

I'm not sure this is the best pattern, but it works.

Then, to get the information back into the form if the user is editing again, I initialize the object with its contents (or an empty object if the recipes weren't filled in last time, or this is the user's first interaction with this form), and the text area is filled with the object's contents, right off the bat.  So the previous user data ends up in the form right away.  I used a similar method for the user-selected links.

Skills developed: More jQuery and Ajax, persisting data in two directions: form -> database, and database -> form

Week 8 Day 2: Going Deeper Into Ajax

Major Activities of the Day: We had a lecture about Ajax, followed by a slew of labs to apply our knowledge.  The first was some simple work with selectors - far less complicated than what I've been doing thus far - so I finished it quickly.  Next was taking a comment form for a news website and making it have validations.  In the middle of working on it, I just got very stressed out about my project and returned to working on it.  (I also did some work with it in the morning as well.)

Today's major task was figuring out how to get my application to properly interface with Yummly, which offers an API to gather information on recipes based on search terms.  I get 500 free API calls per day, so I have to make sure my app isn't making unnecessary calls, but otherwise it should be fine.  I also added some dynamic elements to the form to add fields on the fly and build a menu of recipes based on which recipes the user checks off.  The checkboxes and descriptions are generated through an Ajax call, where the client queries the server, and the server calls the API, gets a list of recipes, and sends them to the client.  I also figured out how to listen for an enter press as an alternative to clicking a button.

Skills developed: Working with APIs and Ajax

Week 8 Day 1: jQuery Is Now In My Vocabulary

Major Activities of the Day: Today we started JavaScript!  To make things simpler, Avi had us all go through the CodeSchool JavaScript Roadtrip videos.  In the afternoon, we had a lecture about jQuery and Ajax.

That's what (almost) everyone else did.  I had the good fortune of having done the CodeSchool course before, and I spent the weekend studying jQuery and Ajax with the CodeSchool courses.  So I spent most of the day working on my project, actually implementing jQuery stuff.  So there are lots of event listeners, a getJSON call to retrieve data stored on the server based on a user selection, etc.  It was a pain to deal with a new language and framework when I'm still struggling somewhat with Rails, but the effects were incredibly pretty, and at the end of the day, I'm proud of what I managed so far.

Skills developed: jQuery, Ajax

Week 7 Day 5: Free Period!

Major Activities of the Day: Today we had lots of chill time, so I focused on moving ahead with my project.  And by that, I mean that I spent 2 hours putting together a logo.  It was kind of tough to find free software, and it's a raster image rather than what it should be - a vector image (faster to load and scales without going grainy) - but it's something, and the logo just isn't the main point here.  (Which is why I spent 2 hours on it.  Um...)  I added some frontend stuff, including tabbed content, which Foundation gives you right out of the box.  (Oh, to be clear, I'm using Zurb Foundation - I decided not to go the standard Twitter Bootstrap route, because I imagine I'll eventually learn Bootstrap, and Foundation looks pretty cool, so I may as well get to know it.  We'll see how it goes!)

As an aside, I learned a bit today about being open to changing directions.  I originally started out imagining a multi-page form with lots of controller actions to handle each step of the process.  Then I realized I could just have a tabbed form - hey, that's much nicer!  It's better from lots of perspectives - easier for the user (if they don't know about X, they can move on to Y and come back easily), and easier for me, the programmer (because I can just write one big controller action).  That's where tabs came in.  I didn't want to have lots of stuff appearing at one time on the page - things need to be organized, simple, attractive, and not overwhelming - so I kept it clean by showing only one piece of the form at once, using tabs.  Of course, I've only done the first part of the form, which is the easy part, just inputting names and email addresses.  The next parts will involve dynamically updated content, so basically I'm spending this weekend studying jQuery and Ajax, and hoping I can accomplish what I want to accomplish.

In the afternoon, we went over the Arel exercise from earlier this week, and then I had more time for project work.

Today was my first Feeling Friday.  (I'm an Orthodox Jew, so until this week when the days are longer, I had to leave early on Fridays to get home in time for the Sabbath.)  Essentially, everyone gathers in a big circle and we share our feelings about the week.  It was kind of neat to hear how everyone else feels, and hear that I'm not the only one who's gotten a bit stressed out about how much work we're doing!

Skills developed: Using a CSS/JS design framework (Zurb Foundation), flexibility in design

Week 7 Day 4: Regexps and OmniAuth

Major Activities of the Day: We began with a Ruby exercise writing a program that does math in words, e.g., four times seven plus three.  This was basically a way to get some more experience with regular expressions in Ruby.  Apparently, Ruby has a Regexp syntax where you write /(?<hello>world)/.match("the world") and it will give you a MatchData object; if you assigned it to a variable m_data and write m_data[:hello], it will give you "world".  This is useful if you want to find multiple matches in a string, and access each one by an independent variable.  Additionally, under some very particular conditions, when I use the =~ operator, it will assign a local variable with the name between the <>s and the value of the match associated with it.  So in this case, if I did this in IRB: /(?<hello>world)/ =~ "the world" and then entered hello, it will respond with "world".

We kept working on Arel stuff for a while.  It was tough, but I managed to get basically everything done with one SQL query per task (it may have been 100%, but I can't remember, and possibly one of them was impossible to do without 2 queries).

We had lecture today where Avi showed us a pattern for creating users with different permissions (in the case of his blog, users need permission to create/edit a post, create/edit a comment, etc.).  We also went over OmniAuth, which I already have some experience with from adding Facebook login to my project.  It's a standardized system of user authentication using big websites like Facebook, Google, Twitter, etc.  And it's a great way to keep your users from dealing with the hassle of making a new login just for your site, while saving you from shouldering the burden of dealing with encrypting passwords (and potentially making a mistake).

I got a lot of work done on my upcoming project today.  I'm debating whether to blog about it beforehand, but I'll probably keep it secret... :)

Skills developed: Ruby Regexps, Arel, User Authentication and OmniAuth