Rails Hotline

Starting this Friday, Hungry Academy students will be volunteering for the Rails Hotline. This Friday, May 11th, from 1pm to 4pm Eastern, we’re having a kickoff! A few Hungry Academy students will simultaneously be on the line. From beginner to advanced rails topics, feel free to call us. Please be prepared with Github repo, Gist, or a post on StackOverflow so we can better help. Also curious about how the program’s going or what we’ve been learning recently? Want to just say hello? Give us a call at (877) 817-4190.

The Rails Hotline is a free resource where anyone can get help on rails issues from fellow programmers. Whether you’re stuck on a problem or just getting started, volunteers are there to support.

We’ve most recently completed multi-tenant Rails marketplaces with page and fragment caching, multiple authorization types, mail with Redis and Resque, and performance with at least one hundred thousand products in our stores. Next up, we’ll be working on API-filled content management systems. We’ve got a lot to talk about!

Google Calendar Link

Personal Weather

Introduction

Interacting with remote APIs can be one of the most entertaining parts of programming. As a novice programmer, you can immediately enhance your application through simple calls to external services.

There are thousands of APIs you can use to display and interact with remote data. The possibilities are pretty much endless! Below, we’re going to walk through what would go into building a personal weather site. You could easily extend this into a homemade personal dashboard - for example: include custom news, personal recommendations from Etsy, and your friend’s most recent tweets. The possibilities are endless!

Personal Weather Application: Getting Started

Wunderground.com provides weather forecasts nationwide based on zip code lookup. Wunderground’s API allows you to find weather data based on parameters passed in by your application. For our basic weather application, we’ll show the current weather for Washington, DC.

Step 1: API Key

Sign up for an API key. An API key is a unique identifier that the website uses to track your usage of the site. Wunderground provides a key when you sign up.

Step 2: Determine What Data You Want

Check out the API documentation. For our application, we need to set up the query to find the current weather for zip code 20001.

Wunderground’s API query format is as follows:

http://api.wunderground.com/api/YOUR_API_KEY/hourly/q/20001.xml

Once you replace “YOUR_API_KEY” with your personal API key, you can put this search in the browser to make sure that it works. Note that 20001 is my zip code in Washington, DC.

Step 3: Building the Basic Application

In this tutorial, we’ll just get the minimum code up to make this work. After the site’s up, you can certainly push farther.

From the command line:

rails new personal_weather

Step 4: Set up your homepage

For the homepage, we’ll need a controller and a view.

Create the pages controller by typing the following in the command line:

rails g controller pages

Then, open up app/controllers/pages_controller.rb and add a blank method called home, which will indicate we want a home page:

class PagesController < ApplicationController
  def home
  end
end

To create the view (what will be seen by the user):

Navigate to the app/view/pages folder and create a new file called “home.html.erb” within it. In this file, you can write HTML, so let’s add <h1>Home Sweet Home!</h1> to the content of that file.

Lastly, we need to add the route so your application can appropriately direct traffic.

Navigate to “app/config/routes.rb” and add:

PersonalWeather::Application.routes.draw do
  get "pages/home"
  root :to => "pages#home"
end

Be sure to save all of those files as you go along! We’ve nearly got a complete rails site!

Step 5: Startup the Server

Go back to your command line and open a new tab. Type “rails server” to get your local server started. You can now go to any web browser and type “http://localhost:3000”. You should see a page that says “Welcome abord! You’re riding Ruby on Rails!”

That’s great, but we want our “Home Sweet Home!” page to show. Navigate to “app/public” and delete the index.html file. Then refresh the your browser - you should see Home Sweet Home!

Step 6: Create a WeatherLookup model

We need a good way to retrieve, manage, and save the information we get from Wunderground. Let’s do that in a WeatherLookup model. Instead of creating the model from the command line (which will give us way more than we need), let’s create one ourselves. Navigate to the app/models folder and create a file called “weather_lookup.rb”. Inside the file, type the following:

class WeatherLookup end

Step 7: Setting up HTTParty

To get the information from Wunderground (like we did in our browser), we’ll use a gem called HTTParty. To install the gem, go to your Gemfile and type the following:

gem 'httparty'

Save the file and go to your command line. Type “bundle install” to get HTTParty set up for your application.

Step 8: Fetch data from Wunderground

Within your WeatherLookup model, you can create a method called fetch_weather that has what’s called a “get request” to Wunderground’s API.

 def fetch_weather
    HTTParty.get("http://api.wunderground.com/api/YOUR_API_KEY/hourly/q/20001.xml")
 end

Note that the URL we’re using in our fetch_weather method is the same as what you put in the browser earlier!

Step 9: Saving what you Want

Each time we do a new weather lookup, we want to do a number of things:

  • Store the results from the fetch_weather method.
  • Grab the temperature and weather icon from the XML that Wunderground returns.

First, let’s assign our results from the fetch_weather method into a variable we can use called weather_hash. We’ll do that in a special method called initialize (initialize gets run when a new weather lookup is created).

def initialize
  weather_hash = fetch_weather
end

Then, let’s create a method called assign_value that will save the temperature and weather icon values for our use.

def assign_values(weather_hash)
      hourly_forecast_response = weather_hash.parsed_response['response']['hourly_forecast']['forecast'].first
      self.temperature = hourly_forecast_response['temp']['english']
      self.icon = hourly_forecast_response['icon_url']
 end

The code to the right of the equals sign is probably pretty confusing! What this is is us going inside the weather_hash and digging through nested hashes. You can navigate through these in rails console (we’ll go through that in the end - for now, you can take my word for it!)

After we create that assign_values method, we want to make sure it’s called upon initialize, too. Let’s add it to the initialize method:

def initialize
   weather_hash = fetch_weather
  assign_values(weather_hash)
end

We also want to make temperature and icon accessible on our home view. To do this, add them as attr_accessors above your initialize method:

 attr_accessor :temperature, :icon

Step 10: Doing a weather lookup when you visit home

Go back to app/controllers/pages_controller.rb. You’ll want the controller to do a new weather lookup each time we go to the home page. Add the following code inside your home method to create the new weather lookup:

def home
    @weather_lookup = WeatherLookup.new
end

Step 11: Modify your view

We now have some info that we can put on our home page. Go to your /app/views/home.html.erb file and replace <h1>Home Sweet Home!</h1> with the following code:

<h1>My Personal Weather Lookup</h1>
It is <%= @weather_lookup.temperature %> degrees in Washington, DC!
<%= image_tag @weather_lookup.icon %>

Step 12: Go live!

Restart your server by going to the command line tab in which you typed rails server and type CTRL+C, then rails server again.

Go to your browser and reload “http://localhost:3000/”. Your personal weather lookup should be up!

Extension: Viewing the results of the API call

In step 9, we already knew what values we wanted from the hash returned by our fetch_weather method. What if we didn’t or wanted to look up something else? This is easy using IRB. In a new terminal tab, type irb.

Then, make sure that you can use HTTParty by typing:

require 'httparty'

Now we can make our HTTParty get call straight from the terminal window:

HTTParty.get(“http://api.wunderground.com/api/YOUR_API_KEY/hourly/q/20001.xml”)

The results are super long! However, you can dig through and find all the data you need in the nested hashes to extract the right values.

Thanks! I hope you enjoyed the basic API Tutorial. Check out http://api-fun.herokuapp.com and https://github.com/eliseworthy/api_fun for ideas on how this simple app can be extended.

Just for starters, here are some ideas to keep going:

  • Push your application to Heroku
  • Create validation for the temperature and icon in case the service is unavailable
  • Allow for a user-defined zip code
  • Find another API and add dynamic content to your home page!

Focus

There is an old Buddhist saying, “First learn the rules, then break them”. The typical Hungry Academy cadet is a young, intelligent, and highly motivated person who loves to create. A prerequisite of that love is a desire to know and understand how things work. Once you have grasped the essence of something, you can bend and shape it to your will.

This mentality has served us well, but it is not without its downsides. The web is vast, and the sheer amount of information produced and distributed through it is both overwhelming and awe-inspiring. It is the ultimate playground for builders like us, and it can be as overwhelming as when a seven year old kid walks into the world’s biggest candy store.

The availability and sheer volume of information can, ironically, stunt our capacity and the speed at which we learn. The information overload is like quicksand, sucking us into a morass of possibilities and options. There are so many new technologies, tools, and languages in the development world that a narrow focus is needed when you begin - otherwise it is easy to feel overwhelmed, or worse, paralyzed by all the options.

One example: Hungry Academy. The aim is to teach “Web Development”. We’ve already been exposed to Ruby, Rails, HTML, CSS, JQuery, HAML, SASS/LESS, RSpec, Capybara, and Git. It’s a lot to learn - especially for those of us new to the field, but it represents a tiny fraction of the available frameworks and languages for web development.

Let’s be clear for a moment - the diversity of information and options in web development is a strength, not a weakness. However, when learning it is important to keep a narrow focus on the objectives. Otherwise it is incredibly easy to be sidetracked.

So how to stay focused while learning? Here’s one way.

Create a breakable toy - a small app that you can constantly tinker with and implement new technologies you are exploring. You’ll learn things that are hard to get out of tutorials or books, and doing more of what you got into web development to begin with: creating things.

Now get learning!

Maria Thomas

The 24 souls in Hungry Academy were joined by rougly 60 of our LivingSocial colleagues for an enlightening talk by Maria Thomas on her experiences working at Amazon, directing digital media at NPR, and her time as CEO of Etsy. For the faithful supporters and followers of Hungry Academy, here are a few of the gems Maria shared.

At the core of Amazon’s product is a single, core word: customer. Maria’s presentation emphasized Amazon’s goal of creating “the world’s most customer-centric company” and the way they do it: building products focused on the customer. Customers are so important at Amazon that at Jeff Bezos’ insistance a chair is left empty in every meeting, to represent the customers who cannot be there in person yet whose needs need to be considered in every business decision. She also highlighted how Amazon focused on long-term investments that took customer well being into account, rather than giving in to the pressure for short-term results.

At NPR, Maria’s focus was to build the digital media unit and expand the NPR brand across the digital landscape. It was a new frontier for the formerly b2b company. The company became a pioneer in the digital space under Maria’s guidance, taking what had been a purely audio brand and translating it to visual and digital form. Her mission was to maintain what was termed the “NPR-ness” of the customer’s experience in new mediums. As Maria explained it: you know what the magic of your brand is. Preserve that “ness” for every user, no matter how they interact with your product.

She also stressed how at NPR the team used iterative testing to observe how users used their products - and that testing could be as simple as running down to Starbucks and asking a few people to try it out on a laptop.

Maria’s time as CEO of Etsy came during an evolutionary period in the company’s life. She focused on using metrics to understand how users interact with the product. Interestingly, as a market for hand-crafted goods, Etsy did not have the standard conversion funnel of a traditional e-commerce site. Customers came to Etsy to browse beautiful, hand-crafted goods - much as they might browse similar items in a brick and mortar craft fair. While conversion was important, the experience needed to preserve the desire for entertainment that drove many customers to the site. It was another lession in listening to and understanding your customers and the importance of their needs.

As someone rather succinctly put it, “Without customers, there’s no business.”

When Life Gives You Lightning

Mark Twain once wrote, “I didn’t have time to write a short letter, so I wrote a long one.”

A lightning talk is the modern day equivalent of Twain’s letter. Each presentation is only five minutes long. The challenge lies in delivering something of value within that short timeframe. Lightning talks are a cornerstone of the software industry - especially within the Ruby community - and regularly occur during conferences and meetups. The goal of Hungry Academy is not just to teach us coding but also to bring us into the wider development world - which makes preparing and giving lightning talks an important part of the Hungry Academy curriculum. Every Friday morning, 8-12 of us deliver a talk on the topic of the week. Topics so far have ranged from the Ruby community at large to authentication and testing tools.

Why Important

Lightning talks are great for two reasons. They allow developers a less formal and less intimidating forum to practice presentation skills. Because of the nature of our work, we often do not have many opportunities to practice “soft” business skills. In the past this has led to developers taking the role of code monkeys that simply need to be fed tasks. Ironically, developers are in fact excellent problem solvers, and given the opportunity they can contribute greatly to the direction of their companies. Lightning talks help bridge the communications gap, turning mere coders into business leaders.

Meanwhile, giving a presentation in under five minutes reqires a clear, concise understanding of the topic. Your mastery will continue develop as you educate others. Lightning talks are a good skill to foster, increasing both soft business skills and technical mastery.

Tips on Preparing

Because lightning talks are shorter, preparing for them is different than for a standard presentation.

Here are five tips for success:

1) Center your talk around one point and make that point as early as possible. Although you usually have 5 minutes for the lightning talk, if the point can be made in two - take two. 2) Keep background information to a minimum. The audience for most lightening talks is made up of smart, problem solving individuals. They don’t need their hands held. Just make your point. 3) Slides are not required. Think of a lightning talk as a conversation you have with a group of your friends, but they keep quiet for five minutes. A fancy chart isn’t necessary to make your point. 4) DO NOT LIVE CODE. EVER. DON’T DO IT. DON’T EVEN TRY. Murphy’s law will bite you. Use a screencast or screenshot instead. 5) Practice. Your presentation is five minutes but without practice it is just a waste of your audience’s time. Remember who is watching - people who live and breathe efficiency.

Check back on the Hungry Academy site in the next few days and weeks as we begin publishing screencasts and videos from our weekly lightning talks!

Hungry Academy: One Month In

One month ago, 24 of us walked into the glass double doors on our floor in LivingSocial HQ. We didn’t know each other, and while some people had done a fair amount of work in Ruby, Rails, and other programming languages, some of us were complete beginners. What a difference a month makes!

At times, Hungry Academy feels like a mini-conference. We have fantastic speakers coming in each week, giving us the ins and outs of what they are working on and how they do what they do (And we’ll try to keep up on posting about some of them so you all can enjoy too!). Sometimes the conversations are internal to LivingSocial and the tools they use, but more often they are peeks into the larger world of Ruby and Rails – the world that we already seem to be a part of.

We’ve worked on three major projects so far, all of them in Ruby. It’s amazing when we pause and look back at what we’ve done, especially for those of us who weren’t programmers at the start. Concepts that seemed impossible at the beginning of March now make sense. We built an event manager to do extract, translate, and load processes. We built an EventReporter that extended those concepts. And then we built a relational ‘database’ essentially from scratch – setting us up for the next project on our plate.

Coming at us hard and fast: Rails. Our first project is a doozy: building the creatively dubbed ‘StoreEngine’. It’s got a list of products. It’s got a shopping cart. It’s got administrators and users. It’s got transactions. Authentication. Authorization. As one of us put it, “It’s a big project – but when it’s done we’ll have a very good idea of what Rails does”. So if you have a friend in Hungry Academy, don’t be surprised when they dig in and turn down invitations to go play for a few weeks. And if you’re following along, get ready. This one is fun.

One month down. Four to go!

The Power of Community

Most people’s mental image of the typical computer programmer is less than appetizing. He (or possibly she) is an overweight, glasses-wearing nerd who hacks away in his or her basement and finds more comfort in their computer then in other people. It’s a shame that such a stereotype exists, as it discourages those who might be interested in programming from making the leap.

As is often the case, the truth is vastly different than what people think when looking in from the outside. These so-called “antisocial nerds” quietly built one of the most active, enthusiastic, and robust communities I’ve ever seen. And that community does not exist solely in the world of bits and bytes.

There is great strength in healthy communities. They fulfill our desire for human interaction and provide motivation, inspiration, and education for their members. These ideas are not groundbreaking, but it is worthwhile to show how these principles played out in the Hungry Academy community during our latest project: Sales Engine.

Motivation

A major aspect of programming is dealing with constant frustration. If you have no one around to keep you focused, the temptation to throw in the towel comes sooner than most of us care to admit. At Hungry Academy, we work harder and longer than we have before because we are surrounded by others who are doing the same. It is not uncommon for us to regularly put in 10 to 15 hour days to meet a project deadline – and these are projects for ‘class’, not for any real-world client or job.

Inspiration

Sales Engine required us to break into pairs for partner programming, which meant that 12 different teams were building their own version of the project. We rolled our own relational database and published a gem that allows a user to make specific queries on that database. The beauty of having 12 groups tackle the problem is that we had 12 different implementations. Discussions between groups on how they approached specific problems allowed us to gain new insight into tackling similar problems in our own projects, or similar problems in the future. Seeing the simplicity, power, and elegance of another group’s well-written code inspired us to write code that was not only functional, but beautiful as well.

Education

Working in pairs allowed us to learn from each other. Not only did we gain insight into how other programmers approach and solve problems, we also had to explain our solutions to our team members in a way they would understand. If you can teach someone else a new concept, you are well on your way to mastering it yourself. It’s a little paradoxical, perhaps – but if your desire is to be the best student, you also need to be the best teacher.

Those of us in Hungry Academy have made amazing leaps in our learning and development in the last month, and all that hard work was made palatable – and fun – because of the community LivingSocial and Jumpstart Lab fostered. If you’re interested in programming, know you don’t have to hack it alone! Find a local meetup, or join many of the online communities – it will be much easier to master the language, and you’ll have more fun doing it.

Jesse & Improv

Improv for All!

Take a moment, if you will, to imagine the following scenario.

You walk into a room - concrete floors, white walls, modern looking chairs and desks. Surrounding you are 23 mostly 20-something individuals. You know that you’ve all been selected, or chosen, or hired, or picked - everyone is in the room for a reason. A few faces are familiar, but you don’t really know anyone - and for the next five months you’ll be spending most your waking hours working side by side.

What’s your first reaction? Would you be yourself from the first second? Or would you pull back a little, keep things contained and professional rather than genuine?

It happens all the time in classrooms across the country. Students who know little to nothing about each other file in and sit down and learn from their teachers. Eventually they learn about each other - who is fast, who is hilarious, and who _____. But learning is an exercise practiced by individuals - not an activity performed as a team.

Surprising fact: The first day at Hungry Academy, none of us touched the command line. No one opened up a text editor or tried to understand the basics of Ruby. Our first day was all about Improv.

Improv is about being comfortable in a group. It’s about letting that genuine, wacky, creative person show through a little. And the magic of a team comes when it’s members are comfortable enough to let the wacky come through.

Leading us in our improv journey was Jessie Sternshus, founder of The Improv Effect. In less than 48 hours, she took a group of friendly strangers and created a team. People who know each others’ names, but more importantly know each others’ personalities. We know that certain people are killer at organizing things or people. We know who in a group setting is more likely to aggressively start throwing out ideas and who is more comfortable letting the ideas flow for a while and then adding some really great concepts when things quiet down.

Most importantly, we learned that it is OK to fail so long as you learn from the failure. We learned that inside our Hungry Academy team, people won’t snicker or judge if we say something nonsensical. That the words “I don’t understand” won’t mark us as unitelligent or bad students or strange people. After all, after you’ve passed sounds and movements around a circle in a full-body version of Telephone it’s pretty clear that we’re all a little strange. And that’s not a bad thing.

First Week

The lead-up to Hungry Academy was exciting to say the least. Emails flew from one coast to the other filled with getting-to-know-you facts, advice the best areas of the District for intrepid apartment-searchers, and hopes and thoughts on Hungry Academy itself. It was a time filled with what would most aptly be described as “unbridled enthusiasm”.

After orientation, we hopped straight into two days of hand holding and group meditation.

Just kidding, it was improv based team building exercises. Groan if you like, but it was fun - and helpful! In a crowd of 23 new faces, it was a great way to get to know each other. Otherwise it would have been 6 months of “Dude, can you help me with this?”, “nice work, Ace”, and “Hey Monster-Man, can you teach me how to dougie?”. Jessie Shternshus deserves a lot of credit for forging 26 individuals into a team in less than 48 hours.

With a solid team foundation under-foot, we rolled up our sleeves and took a peek under the hood of Ruby. Here’s the rundown:

Step 1:

Get our feet wet with a walk through of Jeff’s intro tutorial: Ruby in 100 minutes

Step 2:

Take the basics and apply that knowledge to something a bit more real world. Enter: Event Manager. Here we learned what a mess data can become. So, we cleaned it up and got everything into a standardized format. Pretty awesome for the first week!

Step 3:

Annoy everyone you know on Twitter! Why use a dummy account when you can spam real people with JSTwitter?

There it is. We’re a few days in, and we’re already creating programs that have real world applications. All in all, it’s been an awesome week and we’re excited to dig into the next project: Event Reporter.

Welcome to the New HungryAcademy.com

When we announced Hungry Academy we promised to follow a model of open education. We’d publish our curriculum, tutorials, projects, and calendar.

This is the fulfillment of that promise. HungryAcademy.com will be the hub for our activity. In the navigation above you find links to our writings, calendar, and discussion forum. We expect these collections and resources to change dramatically over the next few weeks as we figure out what works and what doesn’t.

If you want to become a developer, we invite you to follow along, participate in our community, and learn to build amazing software.