Major Activities of the Day: We started in earnest on Language 80/20 today! After figuring out how to seed the data last night, it was time to give our application a face. We built up the views a bit, to show words from each language and paginate, and choose on the front page which language and how many words to view. Each word now displays its translations as a tooltip.
We had some trouble getting translations to display when we launched to Heroku, and spent quite a while working with Heroku logs trying to show the information we needed, and making tons of commits in order to be able to push up to Heroku and debug. We finally realized that the translations weren't showing up because we were using the unofficial API-ish Google Translate gem (which is more of a scraper), and Google has presumably learned not to respond to GET requests from herokuapp.com. So we realized we would have to gather the data on our own, seed the database, and work from there. That will be a project for the next couple of days.
We had a middle-of-the-day Skype conversation with Tom Dale, one of the creators of EmberJS. He came down pretty hard on Rails for being slower than JavaScript (in terms of both execution and size of Ajax requests), which I was aware of, but I guess this was a good reminder to me that many employers will want me to program in other languages because of the problems with Ruby and Rails. As an aside, he happens to be a pretty inspiring example of how quickly someone can become a great programmer. Six years ago, he was a non-CS college grad working in the Apple store, and got himself hired for a programming job in the company. Fast forward to today, and he's partnered with Yehuda Katz to create EmberJS, a JavaScript framework that's rapidly growing in popularity. Pretty cool stuff.
At the end of the day, we made a brief video showcasing what we'd done over the course of the day. We're supposed to do this every day over the course of the project.
Skills developed: Working with Twitter Bootstrap, debugging with Heroku logs
P.S. Version 0.0 is already up - check out our app at language-80-20.herokuapp.com!
Tuesday, April 1, 2014
Week 9 Day 1: Ready for Deploy, Captain!
Major Activities of the Day: Today we spent the morning rallying the troops and figuring out what project we're going to work on. I'm going to be working with Chris Kohlbrenner and Jisu Kim on an app that helps users learn the most commonly used words in a language, based on the Pareto principle, also known as the 80/20 rule. Essentially, most of our conversation consists almost entirely of the most-used words, so common words give you far more bang for your buck than less-used words.
We had a lecture today by Spike Grobstein, who showed us how to set up a Linux server using DigitalOcean's cloud service. It was super confusing. We all got our own little server to try with, and of course, despite working for several hours, I just couldn't get things to work properly. (In all fairness, it may have been a problem with my app, since I tried to deploy Eateract to the server.) Luckily for me, there are platforms like Heroku that let you avoid these problems, but eventually I'll have to learn how to do this SysAdmin stuff, I suppose.
We ended the day by conferring with our teammates about the coming few days' project. We're starting in earnest tomorrow morning, and I'm eager to greet the challenge!
Skills developed: Server setup/administration, project planning
We had a lecture today by Spike Grobstein, who showed us how to set up a Linux server using DigitalOcean's cloud service. It was super confusing. We all got our own little server to try with, and of course, despite working for several hours, I just couldn't get things to work properly. (In all fairness, it may have been a problem with my app, since I tried to deploy Eateract to the server.) Luckily for me, there are platforms like Heroku that let you avoid these problems, but eventually I'll have to learn how to do this SysAdmin stuff, I suppose.
We ended the day by conferring with our teammates about the coming few days' project. We're starting in earnest tomorrow morning, and I'm eager to greet the challenge!
Skills developed: Server setup/administration, project planning
Saturday, March 29, 2014
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!
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!
Friday, March 28, 2014
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:
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:
Skills developed: Technical presentations in front of a crowd
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 |
Wednesday, March 26, 2014
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
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
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
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
Tuesday, March 25, 2014
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
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
Monday, March 24, 2014
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
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
Subscribe to:
Posts (Atom)