Digging for Gems

I've been working on a project the last three weeks for a dev shop out of San Francisco. A lot of the work has been adding additional features to an already completed site, and it's been an enjoyable project. It's nice to see completed work, and I'm able to learn a lot when following someone else's code and picking up on new techniques I haven't seen before. For example, the Ruby if-statement on one line:

foo_bar.present? ? puts "foo" : puts "bar"

Beyond just exposing new syntax, this project has also turned up plenty of new gems to add to the toolbox. A few of my favorites:

• friendly_id - take out the ugly Rails routes that include ids and instead use the blog posts' titles, for example
• carrierwave - easy file uploads
• rmagick - resize images
• feedzirra - pull in a RSS feed and parse the data into blog titles, url, blog author, blog content, etc.
• sanitize/htmlentities - strip out any html or harmful content

Working on this project, I've found that I continue to come across stuff in the code that puts me back in the Gemfile and researching the various gems. Which got me thinking - why can't I upload a Gemfile that then spits out a nicely organized list of the gems, a short summary of the gem, their github repos, their ruby gems page, and any railscasts tutorials that exist?

Changing redirect after Devise signin

We use Devise to manage user sign authorization and authentication. This solution offers a lot of stuff for free, such as password resets and account confirmations, but it's also a little hard to navigate at first since most of the functionality seems hidden from view. Read up a little bit though and you'll find just about every customization you desire is written about on the Devise wiki, with instructions on implementation.

Yesterday, I customized the redirect after a user signs in. Initially, devise is set up to redirect to the root_url after sign in, but it's easy enough to override it by adding a after_sign_in_path_for(resource) method in the application controller. Because our signin "page" is actually a small menu that sits on every page, I wanted the user to stay on the current page after signin rather than be redirected to a specific page. For example, if a user is using our map and decides to sign in, I want that user to stay on the map after signin, not be redirected to a different page. Seems easy enough, and although it took me a little while to figure out a solution, the implementation for this functionality isn't all that hard.

The key for me was learning about Rails' request.fullpath, which will return path the user is on. (There is also request.uri, request.url, request.path, request.host and a few others). So, on my sign in form, I added a variable that I set to the fullpath returned from request.fullpath, and passed that variable to the user sign in path as a params. With that, I have the current page the user is on and can redirect them there after successful sign in.

<% current_path = request.fullpath %>
 <%= form_for("user", :url => user_session_path(:current_page => current_url), :html => { :id => "signin_form" }) do |f| %>


application_controller

def after_sign_in_path_for(resource)
 params[:current_page] || super
end

Code Academy: Week 11

Until this week, I haven't felt comfortable saying this:

I'm a software developer.

Despite being a part of Code Academy and learning the skills of a developer, to call myself one always felt wrong, like I was a poser faking it in a field I knew very little about. And though I'm no where close to where I want to be in terms of my ability as a developer, a couple of things happened this past week that gave me enough confidence where it finally feels natural to call myself what I've become over the last 11 weeks: a developer.

• On Wednesday I went to a Chicago meetup put on by a company called Heroku. I've been using Heroku to deploy the applications I'm building and they organized an evening session to talk more about their product and to show off some demonstrations on how to use it. About 30 developers were in attendance (maybe half of them Rubyists) and there wasn't any moment that I felt out of place or in over my head. In fact, they had a live coding demonstration of an email/signup app that they deployed to Heroku and as a few of the audience members watched in amazement at the speed with which he was able to code and deploy, my thoughts were generally something like - "that's easy." I could have gotten up in front of a room full of Chicago developers and offered some of them new skills related to the software craft. A poser developer couldn't do that.

• A fellow Code Academy student sent me an email this week about stripe.com, a payment processing service similar to Paypal. He had just implemented it on his site, found it to be very easy and seamless, and knew I had been struggling with Paypal. He recommended I check it out. If you go to the homepage the first thing you'll see is "Payments for Developers." 11 weeks ago this service wouldn't have been for me, I wasn't a developer, but I'm happy to report that after spending about 2 hours this week working on implementation, I got Stripe hooked up to my site without too much trouble. I was able to follow along with their code tutorials, make a few customizations needed for my site, and perhaps most tellingly, appreciate their product from a developer's point of view. Their homepage headline made sense...because I'm a developer.

Learn how to code!

This internet thing might be around for a while.

The Rise of Developer Economics

The one absolutely solid place to store your capital today — if you know how to do it –  is in software developers’ wallets. 

Code Academy: Week 10

I've found a lot of success in failure this week. I've spent the better part of 3 days struggling to get PayPal integrated to a site I'm working on and still haven't managed to get it set up properly. Digging through PayPal's endless and poorly organized API docs, researching how to handle the params I'm receiving from PayPal, understanding that redirect_to is a HTTP GET request while I need a POST, and reading production log files to troubleshoot hasn't solve my problem. I'm still forced to disable auto-return (forcing the user to click on a link after payment to get back to my site) in order to finish the transaction. Frustrating but not a completely lost battle.

API, params, GET, POST, production logs. What?!!? Exactly. There was a moment yesterday while knee deep in my investigation where I took a quick step back and realized how far I've come in the past ten weeks. I've picked up a whole new skill set (and the vocabulary to go with it!) and am writing code to handle a custom PayPal integration to accept credit card payments on a site built from scratch. Awesome!

I'm close to solving this PayPal riddle and after talking to a lot of folks this week about what I was working on, the general consensus was that PayPal is terrible and that its API and documentation is some of the most confusing out there. I'm hoping they're right because if I get this hooked up, everything else I tackle should be easier.

Code Academy: Week 7

A couple of weeks ago I came across a site out of Detroit that allowed anyone to enter in an idea for the redevelopment of Michigan Central Station. I liked the idea and decided it'd be a good exercise to try to build a similar site as practice for what I've been learning in class. Detroit Pays Off was born (more on the idea at some other point).

The actual rails coding was really easy. There isn't much to the site, just a model for the posts that includes the idea, the posted on date, and the number of votes, but because I wanted to share the site here, I spent a lot of time last week taking my first stab at the frontend coding of a site - mainly CSS and a few cool effects written with javascript/jquery.

I basically just stole Tumblr's colors and layout as a model for the CSS coding and messed around with different divs and options until I managed to get things where I wanted them. Much easier said than done but it was a worthwhile endeavor. I have a much greater grasp of what CSS is and how to hack something together that looks somewhat presentable. As for the javascript/jquery, I spent just about all weekend working on getting three very small effects working. You'll notice the first one when you click on "Submit Your Idea". Oh yeah! You saw that animation slide? Took me all day Sunday to figure that out. The other two were somewhat less difficult, you can click on the hand and it counts a vote without refreshing the page, and when you enter in a new idea it fades in as the newest idea submitted. You'll have to submit an idea to see that last one so don't be shy...submit!

I'm pretty critical of how things have turned out and what still needs to be done on the site (for starters, I hate how the submitted ideas section is laid out in a table, and I'd like to add comments and the ability to sign in with Facebook), but being able to do this on my own has been awesome. Just a few weeks ago I would have seen the Talk to The Station site and been frustrated that I couldn't build a similar site without resorting to a pre-built WordPress theme. Now when I come across any site or idea, I can just create it myself.

Have any ideas for a website/web app? Send 'em over...I'll build it.

Code Academy: Week 6

We're half way through the very first Code Academy program. It's surprising how quickly the weeks are passing and even more surprising how far we've all come along since that first week. Our progress has never been clearer than last night at 5pm when we presented the result of our work during the Startup Weekend we had just completed.

There are startup weekend events throughout the country and they all function pretty much the same. You start on Friday at 6pm. Those who are interested, pitch various ideas for businesses or web applications and after all the pitches, the attendees vote on their favorites. Through either one or two rounds of voting and questions, the list of ideas is whittled down to the winners and then teams are formed around each idea. At that point, once the teams are created, you have until Sunday at 5pm to work on the idea and try to get it launched over the course of the weekend. Our Code Academy startup weekend worked in this fashion, and since we're all at least novice developers at this point, our projects were very much functioning web applications by Sunday.

A Code Academy startup weekend in week one of the program would have looked something like this - 

• Powerpoint presentations with slides on the market potential, a SWAT analysis on the idea, and a summary of competition.
• Wireframes of the web application

There's certainly nothing wrong with this work and, in fact, it'd be smart to do that for any idea, but a Code Academy startup weekend after week six looks a lot different. It looks real. We can build shit. Real, functioning applications. To see the ideas that were decided upon on Friday come to life through the weekend and result in fully featured websites by Sunday was really special. Very motivating for the next half of the program and a very good reminder of how far we've come in the first half.  See for yourself at two of the sites that were built in just 46 hours:

Hangar18

TellMeWhen

Code Academy: Week Five

I can't specifically pin point what finally became clear this week, but by Monday afternoon while still working on the application we had built the week before, a lightbulb went off and things started to click. During the first four weeks, I understood each individual concept on a fairly superficial level, but it turns out that a somewhat superficial understanding isn't all that useful in programming. Trying to orchestrate your web pages, controllers, data models, and browser requests with code requires an understanding that allows a programmer to see how everything works together, and looking back on where I was last week versus where I am now, I think it was this deeper understanding that was missing. I understood the various parts in isolation rather than in the context of how everything was working together, and it wasn't until the lightbulb went off on Monday that those same isolated parts became one - a beautiful application with several moving pieces working together to output exactly what I was telling it to do.

The lightbulb continued to burn bright this week and I've surprised even myself with what I've been able to accomplish on my own. In thirty minutes I was able to rebuild the same application that took me two days last week, and after conquering that, filled with confidence, I started to tackle two of my own projects - an application for learning about and exploring city neighborhoods and an application to submit and vote on ideas. This new ability to turn a vague idea and a blank screen into a functioning application is empowering and exciting. The whole world opens up with possibility. New apps, new ideas, new things that I CAN BUILD.  The work involved is creative, satisfying, frustrating, simple, complex, beautiful, and fun. I've found myself not wanting to do much else this past week but build. The lightbulb came on this week. I don't think it's turning off anytime soon.

Code Academy: Week Four

I've finally taken off on my own. During the first three weeks of the course, I was "coding" during class time with the help of classmates and the instructor or with the hand holding of web tutorials. This safety net was necessary at first but after three weeks under my belt, I decided I'd give everything a try on my own during week four.

During class this week, we worked on our first full scale Rails app. Whereas during the first three weeks we worked on small examples to put concepts into practice, this week we were presented with a more complete picture of a business/site and spent the entire week building out the web application, an airline site that allows users to sign-up/sign-in/out, view flights available, and book reservations. As usual, we were paired up in class and built the application after watching the instructor implement each feature. Working with someone and coding immediately after watching the instructor makes everything a lot easier than it should be and can dangerously lead one to believe he knows what he's doing. This weekend I worked alone to try to build the site from scratch. To find out if I actually knew what I was doing.

The answer - somewhat. I didn't get all the way through and spent a lot of time stuck at various points while writing the code. It took me way too long to get things working but regardless, I feel pretty good with what I was able to accomplish. What I was able to build on my own isn't too far off from what we built in class, and I've found that I understand the concepts we've learned in class much more deeply after having to troubleshoot my errors by reading the Rails guides. The most exciting part is that the site I built has a lot of the functionality that any web application requires; additional features would be nice but as for a basic site that includes just about everything you need, I built it on my own this weekend! Pretty sweet considering I didn't know anything but the name Ruby on Rails four weeks ago and that it was my first time working on my own.

On to week five.

Code Academy: Week Three

I felt more in control during week three than at any other point during the program. Some of the basic steps that we had learned during the first two weeks finally felt like they sunk in a little more, and I noticed that by the end of last week I was able to use those steps without much thought. And those were steps I knew nothing about just three weeks ago, so to put them into practice and every once in a while reflect on how far I've come felt pretty good. Unfortunately, as I feel a little more comfortable with the basics, the more advanced stuff continues to approach and present itself, leaving me feel about as overwhelmed as I did when I started.

A big portion of the difficulty in learning Ruby on Rails (or any type of web development) is that you aren't just learning one thing. Within the first three weeks, I've spent more than a few hours trying to learn the basics of Rails, Ruby, HTML, CSS, TextMate Editor, GitHub, Heroku, and the command line, and each of these aspects alone is the subject of hundreds of tutorials and guides. Rails actually makes it all a bit easier because you can learn all of these things within the context of the framework rather than tackling each of them. For example, you don't really need to know a lot of Ruby when you're first learning Rails and the Ruby that you do indeed need to know, you'll likely pick up while learning Rails. But for me, a process orientated learner, having all of these new subjects and topics thrown at me all at once has been overwhelming. I don't want to learn a new topic when I haven't even conquered the topic that the new one is built upon.

Code Academy has done a good job of feeding us digestable portions of content that limit our exposure to "too much, too soon," and I've found that the Michael Hartl Ruby on Rails tutorial has been equally helpful in providing a very practical and easy to follow guide to learning not just Rails but a lot of the other aspects I mentioned above. So far, the combination of the CA coursework and the tutorial have been a great way to rather quickly learn the basics in a structured and logical manner. I've also spent a lot of time going through the Learning to Program book to learn the basics of Ruby which has helped me better understand Rails. This approach has worked for me up to this point, and I'm starting to feel just about in a position to start building my own projects. They won't be pretty but they'll exist, and that's a lot more than I could have said three weeks ago.

Code Academy: Week Two

I haven't really done any useful computer programming or website development. I took some programming courses in college and have messed around with HTML, but I've never actually coded an application or anything (until last week!). So, you can take my opinion with a grain of salt, that of a beginner who doesn't really know any better, but after spending two weeks learning the beginnings of Ruby on Rails, I must insist that it is the coolest thing around if you're at all interested in web application coding. And maybe even just the coolest thing around.

Why? My sexy answer is that as a complete beginner to the framework and the Ruby language, I had a working web application up and running by the end of last week (sexy!). It was a simple bank account site that showed the bank's accounts and each account's balance and allowed you to add, edit, and delete accounts. Each of those functions (add, edit, delete) could be done by a user on the site and his/her actions on the site were completely mapped to a database that kept track of all of the accounts and the accounts' information. Sure, the site looked a little like 1996, but I was able to add all that site functionality with just a few steps. 

Of course, we learned about the unsexy answer too. Admittedly, I'm still trying to grasp all of this, but as I understand it now, Rails is cool because of its slick use of restful routing and its scaffold generator.  Unsexy - 

• Restful routing - Rails has a way in which it can handle requests and map them to seven different actions and this is all done with one simple line of code
• Scaffold generate - This generates a database resource based on convention (what you'd initially want 80% of the time)

Actually seeing these two portions of Rails in action is sweet (and much more convincing than my above explanation) and since learning these little bits of Rails, I've started to think of every webpage I visit in a new way, one in which I try to figure out how someone may have built the initial site, and I've started to think of my own ideas within the context of "how would I go about building that using Rails." It's inspiring and yet completely overwhelming. In week two, I grasped the power that Rails can give me but my skills at using that power are still so frustratingly weak that I'm left just slowly chipping away at the overwhelming amount of material to learn so that one day I may enjoy the fruits of that power. I'm not there yet but at least I now know how I might get there - Ruby on Rails.