I █████ T-██████

I’ve censored the following, in protest of a bill that gives any corporation and the US government the power to censor the internet–a bill that could pass THIS WEEK. To see the uncensored text, and to stop internet censorship, visit: http://americancensorship.org/posts/3880/uncensor

I ████ got off my █████ T-██████ █████ ████ in as ████ █████. ████ ████ ████ ████████ me ██████ my ██████ ███████ ████ for █████ ████ my ███████ and █████. █████ ████████? ███████ 2-████ ████████. My ████████? ██████ ████████. Sad ████ is ████ ████ win no ██████ ████ I do: ██████ ████ ████ me ████ ███████ 2 ████ ████████ ████ of ████ █████████ and ███████ and too-████, or ████ get to ███████ █████ █████ of the ████ few ██████ by ██████ ████ ████ got as ████ █████ out of me as ████████ ██████ I ███████ ████ as a ███████. ████ ███████ me of the ████████ “███████ ████” ███████ █████ █████ ████ he can do ████████ he █████ to ████ █████ he’s 18 and ████ ████ he’s 17 he █████ to ████ him ████ a dog ███████ he █████ the end is ████. ████’s the ████ ███████ █████ ████ █████ to ██████ a ███████ ███████████ █████. I █████ the ███████ is ████ T-██████ ████ as ████ █████ ████ me as ████ █████ as ████ as ████████, so I ████████ to ████████████ to ████ the ██████████. I ████ █████, and I ████ T-██████.

Uncensor This

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.

Beers, Brewers, Styles, and More!

We just quietly launched a new website for beer lovers. Libatious lets you browse brewers, styles, and beers to find about about beers you have had and beers you would like to try. We have lots in store for the new generation of beer drinkers, so let us know if you have any questions, issues, or feedback about the beers, brewers, or beer styles that you see.

On Facebook (And Now For Something Completely Different)

I want to discuss a topic that not many people have heard about recently; a topic that the MSM continues to ignore. But first, we have to think back: The year is 2004. A new social network, The Facebook, is just launching, started by an up-and-coming young go-getter…

jk. roflz.

I realize everyone (and their twitter handle) is talking about FB these days. All the same, I enjoyed this Slate article about “The Other Social Network” which looks at 2004 from the eyes of one of FB’s competitor in those days: Campus Network (aka CU Community).

Below are my take-aways: lessons that I want to internalize instead of repeating others’ costly mistakes.

Think Small

FB+CU were specifically for college students (read: a large, but well-defined vertical). As such, they had a base of users they could easily reach who were co-located, had similar demographics, and hung out in similar locations (both physical and virtual). Both FB+CU did a good job at narrowly defining their audience and pursuing them wholeheartedly.Would that all companies would deeply understand that “as big as possible” in and of itself is not a good goal.

Features Schmeatures

CU’s team was working extremely long hours and sleeping in their office while working on adding features (e.g., customizable interfaces). If The Zuck was working really long hours, it was researching the competition, planning strategy, and scaling infrastructure — NOT investing in feature creep. I have respected the manner and pace with which FB has developed their product from the day I signed up in 2004. In a sense, I am glad that CU did not win, if only because the world does not need another MySpace.

Limited Resources = Fierce Competition

I personally can fall victim to varying degrees of what I call “ostrich complex”: if I dismiss a threat as unimportant, it will simply leave me alone, right? It sounds like CU had this same problem but did not proactively combat this tendency; and they paid a top-dollar price ($200k) to learn their lesson. If CU had taken their heads out of the sand for long enough to realize that the 4 hour drive between Harvard and Columbia did *NOT* mean that they could co-exist in their respective niches, CU might have behaved much more aggressively (or defensively, whatever). History might have been different.

First Mover Don’t Mean Shit (or: Execution is Everything)

This is the real message that I take away from this story: CU (and MySpace and Friendster) were first but FB ate their lunch anyway: they took away their users, and their users were better off for it. This is 2010. Your idea is *NOT* sacred. It does not matter if you are able to rightfully say “But they copied me! I was first!” Users want what users want, and they will take it from whoever will give it to them (the little whores). The only thing you can do is to take your idea and execute as damn well as you are able to.

And May the Best Team Win

Wishing Will Not Bring Riches

I am currently reading Think And Grow Rich by Napoleon Hill. I found this paragraph too good to not post, but too long to tweet:

Every human being who reaches the age of understanding of the purpose of money, wishes for it. Wishing will not bring riches. But desiring riches with a state of mind that becomes an obsession, then planning definite ways and means to acquire riches, and backing those plans with persistence which does not recognize failures, will bring riches

I think that is about as simple as it can get. Any questions? =)

Be a Little Bit Swash-Buckling

“In the end, we are our choices. Build yourself a great story.”
  - Jeff Bezos, founder and CEO of Amazon.com

If you are looking for inspiration and confirmation about your choice to strike out on your own, watch Jeff Bezos’ Princeton address “What matters more than your talents”. He talks about his decision, 16 years ago, to quit his job at a financial firm in NYC to start Amazon.com.

Cause.

Just last week I quit a job that I liked at a company that I admired to run a one-man Android application development shop. Like Jeff, after talking with my boss I needed to take some time to “think about it”; I was being offered a promotion during the same meeting that I was letting my boss know I was planning to leave. Something like that requires serious re-consideration.

If you are like me and have second-guessed your choice because of what someone else has said to you, you are not alone! Even Jeff Bezos, mastermind of Amazon.com, net worth of $12.3 billion (billion with a ‘b’) in 2010, was advised by his boss to not make the choice to leave and start Amazon.com. Be inspired by Jeff’s comments about his choice: “I didn’t think I’d regret trying and failing; and I suspected I would always be haunted by a decision to not try at all…. I took the less-safe path to follow my passion; and I am proud of that choice.”

Effect.

When you make life choices, you have to be daring; “a little bit swash-buckling”, as Jeff puts it. There will always be people who will try to make you second-guess your choices; who will give their opinion about how you are deciding to run your life (even though you did not ask); and who give their own reasons why they would definitely not do what you are choosing to do.

This is a natural effect of choice. When you choose a new adventure (striking out on your own) and someone else is left with the old and familiar, both parties have a need to rationalize their situations. You, obviously, have your reasons, or else you would not be taking this large risk. They, however, need to re-justify their situation and why they are not choosing to make choices like you are. Sometimes, their rationalization involves belittling your choice; sometimes it involves explaining your choice away; inevitably, there will be someone who will (in as many words) tell you that you are making a bad choice.

Take heart.

Jeff presents the following dichotomies which I am calling “You vs. The World”. In my opinion, you must choose to belong in one of the two columns; abdicating choice is a choice in and of itself. Choosing to be in the “You” column means you choose to take the road less traveled.

The World You
Let inertia be your guide Follow your passions
Follow dogma Be original
Choose a life of ease Choose a life of service and adventure
Wilt under criticism Follow your convictions
Bluff it out when you’re wrong Apologize
Guard your heart against rejection Act when you fall in love
Play it safe Be a little bit swash-buckling
Give up when it’s tough Be relentless
Be a cynic Be a builder
Be clever at the expense of others Be kind

Remember these dichotomies and remember that you and only you have the power to decide what life you will live.

“In the end, we are our choices. Build yourself a great story.”
  - Jeff Bezos, founder and CEO of Amazon.com

AppRoulette

Discover the best apps in the Android Marketplace that do not make it on any Top 10 list.

Just like real roulette, you may see a few losers before you win big.

Later versions will give recommendations based on apps you like.

Take a chance on a new app, with AppRoulette!

You can download AppRoulette in the Android Marketplace by tapping here from your Android phone, searching for “app roulette” from within the Android Marketplace, or using your Barcode Scanner to read the QRCode to the left.

AppRoulette helps you find content within the Android Marketplace that simply does not make it onto the “Top 10″ or “Best Of” lists that some people publish. The applications that AppRoulette helps you find are still valuable, they are just buried deep within the Android Market!

Using AppRoulette, play a few rounds until you find an application that you find valuable. When you install the newly-found application, you have a Winner!

AppRoulette tracks both your valuable “Winner” applications (those you have installed) and the applications that you did not find valuable: “Losers”.

Use the icon in the notification bar to quickly play another round while you are inside the Android Market — no need to go back inside the AppRoulette application!

Configure your preferences and choose whether to include paid apps, free apps, or both. Also choose which categories interest you, and un-check those categories that you do not wish to have recommended to you.

AppRoulette is both a tool, and an app to pass the time. Have a 5 minute break? Play a few rounds and see if you win any great new apps.

Share applications — both “Winners” and “Losers” — with your friends. Sometimes, these apps are just too good to keep to yourself!

If you have any questions, comments, or suggestions, please leave a message in the comments section below. Thank you for your interest in AppRoulette!