technologies

So You Want to Be a Ruby on Rails Developer at a Startup in NYC?

Ruby on Rails is about the Joy of Coding. NYC is about encouraging interactions with new and diverse people who you may or may not ever meet again. Startups are about learning how to solve a problem in the face of enormous uncertainty. The Venn intersection of the three areas provides an opportunity for exciting and fulfilling (as well as frustrating and demoralizing) experiences.

So… how do you go from where you are to being a Ruby on Rails Developer at an NYC Startup? Besides moving to NYC (congrats if you already have; very much good luck if you have not), there are two areas of your life that you need to focus on.

Learning is King

Learning is supposed to be both frustrating an fun and believe me, the process of learning web development is both! Even on a day-to-day basis you will be challenged to find answers to questions you did not know existed. Can you say the same of other professions?

If you learn Ruby on Rails, you will be well on your way to being a top-notch web developer since learning Ruby on Rails requires that you also learn many of the moving pieces of web development. Here are some good first steps on your journey to learning Ruby on Rails:

Get a Mac

You can find Macbook’s on Craigslist for decent prices and I promise that if you are really making a commitment to becoming a Ruby on Rails Developer, you will *not* regret your purchase. Web Development on Windows is downright painful. You can also just dual-boot to Linux (the free alternative), but I maintain that Linux is for mental masochists who enjoy tweaking configuration files — the very opposite of Ruby on Rails’ motto “Convention Over Configuration“. In the end, you wil enjoy development more on a Mac since you will have the tools and environment necessary to get shit done.

Complete a Ruby on Rails Tutorial

There are many Ruby on Rails tutorials both in digital and printed form, but the Ruby on Rails Tutorial by Michael Hartl is both free and excellent. Whether or not you have experience programming, you should make yourself follow the examples in each section. Treat this free tutorial as a $5000, 12-week course so that you give it the correct amount of respect. By following along with each section, your fingers, eyes, and mind will start getting used to what you are (ostensibly) wanting to make your every-day job. You will go from wondering what the differences between <%, <%- and <%= are to realizing (and intuitively knowing) the important distinctions. That is a small example, but the point is that it is only by experiencing the learnings that you will actually internalize the knowledge. So jump in. Don’t rush. Pace yourself. And push yourself past the frustrations you are bound to encounter.

Use the Right Tools

Ruby on Rails Web Development entails a lot of different tools that you use on an everyday basis. As you scale up in the scope of your work, you need more tools; however, to start, you really only need a few:

  • The OSX Terminal – Even the most basic Ruby on Rails action — starting your local webserver — requires that you use the command line. Down the road, you will be using it for everything from version control to code deployment. Start getting familiar with it early on and push yourself to use it in lieu of Finder. You will thank yourself later.
  • A good Ruby IDE – Each programmer has his own favourite environment for programming his own favourite language. It is all about ease-of-use and how the IDE helps you do what you need to do. RubyMine by JetBrains is a good IDE that helps you understand the file structure of a Ruby on Rails application as well as suggests and corrects ruby syntax and methods. It costs money, but it will help you overcome the inevitable learning curve. TextMate is also a good option.
  • git Version Control – You need to get familiar with git from day one. It will make your life easier as an individual (“oh no! I just deleted that file and now it’s gone perminently!”) and is absolutely necessary when working with one or more other developers. Yes, there are other version control systems, but none as flexible and future-thinking as git. All the cool kids are using it, and so should you.
  • Firebug Plugin for Firefox – You cannot be an effective front-end web developer without using Firebug. It saves time and headaches and lets you try things quickly without refreshing the page. This is not specifically related to Ruby on Rails, but as you start thinking about your HTML / CSS / Javascript, you will find that Firebug is your new best friend.

Not such a long list, right? Each of these things will add a little bit of time to your Ruby on Rails learning curve at the beginning, but will put you much farther ahead in the long-run. Think of these tools as that really difficult putt-putt shot through the windmill that gets you a hole-in-one: it may be a harder set-up, but by trying to avoid it you are resigning yourself to a 2+ stroke hole.

Run a Side Project

What are you interested in? Create a small-scale website devoted to it that both drives you to learn more about Ruby on Rails and exemplifies your capabilities to others. This (or these) projects are both learning canvasses and talking points — a double-win for both you as a developer and for you as an interviewee.

As  a Developer

One of the nicest things about a personal project is that there is no pressure! You can fabricate reasons for trying out new gems or CSS3 techniques. By creating even a small site with a minimal feature set, you expose yourself to the whole stack of web development in a very contained environment. You will make a new Rails Project, generate your MVC for your domain, think about UX / SEO, deploy your site to Heroku, maybe set up some S3 Buckets for your images, etc. Push yourself to try to learn some new acronym that you saw on a job posting or as a tag on Stack Overflow. Your side project will be a great playground for learning in that sense.

To show you how small your side-project can be, I want to point out one of my side projects: simpsons-episodes.info (note: I am slightly hypocritical here in the sense that I do not actively maintain this site). This simple site involves SEO, CSS3, some deeper model associations, friendly URLs, authentication, hosting on Heroku, Design / UX, web crawling, etc. You can checkout the source code for the website and the crawlers on github.

As an Interviewee

As someone who has interviewed with and interviewed for web development positions at multiple companies, it is crucial that the interviewee have some sort of side-project that they maintain. It does not have to be grand-scale or even main-stream, but it has to exist in a public sense. This means that for you to be taken seriously as a Ruby on Rails Developer in the NYC Startup scene, you need to find something that interests you and have an (open-source) project that others can see and use. Why?

  • What You Know – Your side-project is a good way to showcase your skills and breadth / depth of knowledge. It gives you a starting point for having discussions about the technologies that you are comfortable with. It also gives an accurate depiction of what you are capable of.
  • You like what you do :: You do what you like – You show that you do web development not just as a day-job but also as a hobby — that you are interested in the field for more than just a paycheck. This is an important trait in a Ruby on Rails Web Developer as both an individual and as a co-worker.
  • Self-Starter – You push yourself past the nine-to-seven exhaustion barrier to keep creating something worthwhile which means that when the shit hits the fan you will have the energy and drive necessary to finish the sprint that is required of you. Nothing says “I can work hard” like talking about a project that you run during your nights / weekends.

It’s All About Relationships

Meeting new people and keeping in touch with existing acquaintances is the name of the game when trying to become a Ruby on Rails Developer at a Startup in NYC. Most web Startups in NYC use Ruby on Rails, so that is a definite plus for you as you look around for potential Startups to join. Many of the Startups that exist are in “stealth mode”, though, or are so alpha-stage that they can hardly yet be called a Startup. To learn what options exist out there for you as a Ruby on Rails Developer in NYC, you will need to hear about the full gambit of exiting Startups, and that means talking with people.

  • New York Tech Meetup (NYTM) – This monthly event showcases the creme-de-la-creme of up-and-coming Startups in NYC. Not only will you get to hear about interesting new ventures, but you will get a chance to rub elbows with some interesting people as well. The NYTM is the NYC Startup Scene’s main social event for those interested in meeting others. You don’t need to go every month, but NYTM is a good way to keep your finger on the pulse of Silicon Alley.
  • Startup Weekend – The premise is simple: you have 72 hours to form a group around a common goal, flesh out and test your idea, mould it into the beginnings of a business, then present it to others who have just done the same thing with other ideas. Startup Weekend is a fantastic “for entertainment purposes only” event where you get to meet and work (very, very closely with) interesting people in an interesting new space that you may not have thought about before. What happens at the end of the weekend? Even though most people are still high from the excitement of presenting and commit to working on the idea over the coming months, the truth is that most groups fizzle out due to lack of momentum. Still, the people you meet and the thought-exercises you go through have immense value, even if you do not end up finding your next big thing there.
  • Different Weekly Meetups – Every week there are new and interesting Startup- and Ruby on Rails-related events that (hopefully) will pique your interest. My favourite source of upcoming events is Charlie O’Donnell’s weekly newsletter, This is Going to be Big. I read it religiously every Monday and sign up for events ASAP since they tend to fill up quickly (by the way, you can pay $5 for the privilege of beating the signup-rush). The list of potential event sources continues with SkillshareStartup Digest, hackNY, General Assembly, Startup One Stop, etc. The more you go out and meet people at cool events, the more you will learn about ways to find out about cool events.

Find at least one event a week that you can say “I will regret not going to this” and go! Bring some business cards with your Twitter handle on them. Or, better yet, use Hashable to keep track of everyone you meet, where you met them, and the context of why you want to continue knowing them. By going to these events you are not just learning and having a good time, you are networking. You never know who you might talk to that will lead  you to your next gig as a Ruby on Rails Developer at a Startup in NYC — so act like it!

Summary

So you have no experience programming, eh? This is going to be exciting. You have experience with Java, but have never done web-development? Get ready for a brave new world. You have gone to networking events before, but never in NYC, and never for Startups? You’re in for a real treat. It is great that you are committed to making a career switch, and I am glad that you have chosen one that I find to be very satisfying. It is going to take a lot of work and persistence and pushing yourself outside your comfort zone, but the potential payoff is very rewarding. Working as a Ruby on Rails Developer at a Startup in NYC is a good life — now get started making it a reality!

Real-Time, In-Browser Notifications with Node.js and Faye (HTML5 WebSockets)

For real-time, in-browser notifications, I just learned about this at a Node.js Meetup presented by Xydo (let me know if you would like an invite). Xydo wanted to be able to notify a user in their browser whenever an event happened (like a friend sent them a direct message; or a news topic they followed was updated). The main idea is that the user should not have to refresh their page to see that these events are happening — they should know in real-time, in their browser.

The traditional method of doing this is to use polling — you have a client-side script that pings your server for any new messages that the user may want to know. This method is high CPU and high I/O (having to keep pinging your server can overload it with requests, and having to keep checking your database can cause an I/O bottleneck). Needless to say, this does not scale well.

The Xydo solution utilizes two “hot, new technologies”: Node.js and HTML5 WebSockets. The idea is that they keep an open connection from the browser to the server which allows for communication from the server to the browser, even after the initial request.

Why is Node.js important? Well, because Node.js can handle orders of magnitude more connections than a traditional webserver (like Apache) can. A traditional webserver receives a request, blocks (i.e., ignores other requests) while it services that request (most of that time is taken up waiting for I/O resources to become available), then moves on to handle the next request. This limits a typical webserver’s throughput. Node.js does NOT block while it handles requests which means it can handle many more per second; which makes it uniquely suited to handle many low-service, open-ended requests.

HTML5 WebSockets use exactly that sort of low-service, open-ended requests to do their majik. Xydo specifically uses a Pub/Sub framework called Faye which utilizes both Node.js and WebSockets. Faye allows them to “publish” content from the servers to a given browser subscribed to that content, and the content “majikly” shows up in the user’s web browser. For the record, Faye does degrade gracefully in browsers that do not support WebSockets (by using JSONP or LongPolling) so you do not have to worry about excluding the slow-adopters (read: all Internet Explorer users).

So put the two together: Xydo creates a publishing channel for each user when the user signs in (something like "/user/#{user_id}"). The user’s browser is the only subscriber to this channel. Whenever something of interest to the user happens, a message is published onto the user’s channel which is then read to by the user’s browser. In the use-case of a direct message sent by another user, at the same time that you are INSERTing the message into your database, you publish a message using Faye. In the use-case of a particular topic being updated, you would find (in your database) all users who subscribe to that topic, and publish multiple messages, one on each user’s channel.

The final piece of the puzzle is formatting the messages to be published, for which Xydo uses Mustache (a template engine even more strict than HTML/ERB).

So that’s it! Spin up some Node.js servers on a service like NodeJitsu, use the Faye rack plugin in your rails application, and you can easily provide real-time, in-browser updates to your users WITHOUT overwhelming your servers.

Social Proof with Redis

I learned about this method of implementing social proof from the guys at Scribd during their Web 2.0 Expo presentation “Social Design with Facebook”. When implementing avatars, the Scribd guys suggest that you show all users who have liked a particular item; but show the CURRENT user’s friends FIRST so they can quickly recognize their friends’ avatars at the top of the cluster of avatars. These are the avatars that really matter; the rest of the avatars are just to prove how popular a given item is.

The traditional, relational database solution (e.g., using MySQL) is I/O-intensive for getting this information due to the scale of modern social apps (the number of items and user-friend connections) and due to a number of other issues inherent in how the data is stored and retrieved (such as the cartesian product nature of joins).

The Scribd solution uses Redis which, if you haven’t heard of it, is essentially an in-memory set-based database (mathematical sets, which can support operations such as unions, intersections, subtractions, etc.). Scribd stores two types of sets in memory:

  1. All friend ids for a given user, for all users. So if user 1 has friends 2, 3, and 4 then the key would be 1, and the set would contain the values {2, 3, 4}. This size of storing these sets in memory would be ((# of users) x (number of average friends per user))
  2. All user ids for people who follow a particular item, for all items So if Item 10 is followed by Users 3, 6, and 7, then the key would be 10 and the set would contain the values {3, 6, 7}. This size of storing these sets in memory would be ((# of items) X (average # of people following any given item))

The social proof is quickly generated by doing:

  1. “The current user’s friends who follow the current item” would be {the set of the current user’s friends} intersect {the set of the current item’s followers}. In the above example, it would be {2,3,4} intersect {3,6,7} which results in {3}.
  2. “The other people who follow the current item who are not friends with the current user” would be {the set of the current item’s followers} subtract {the current user’s friends}. In the above example it would be {3,6,7} subtract {1,2,3} which would be {6,7}.

That’s it! Two quick and painless, in-memory operations with no I/O bottlenecks to worry about. You would still store users, friendships, and item follows in a traditional database for persistence, but you would duplicate some of that content in Redis for these quick operations. Any CRUD operations would be duplicated in Redis. When you restart your servers, you would re-generate the in-memory sets.