dickey.xxx

After coaching a Rails Girls, I can finally answer the question "Why do I love programming?"

2013-04-14T00:00:00Z

After coaching a Rails Girls, I can finally answer the question "Why do I love programming?"

Yesterday I coached a Rails Girls event in Santa Monica. For those that aren't familiar, here is a description of the program in their own words:

Our aim is to give tools and a community for women to understand technology and to build their ideas. We do this by providing a great experience on building things and by making technology more approachable.

I've done a few of these events such as RailsBridge and a group at UC Berkeley now and have really enjoyed the experience. When I moved to Santa Monica from San Francisco a couple months ago I was looking to get involved down here and found Rails Girls.

What I haven't really thought too much about is why I enjoy doing these sort of events, or programming in general. When @jlsuttles was welcoming everyone to the event she told everyone that the coaches all loved programming and want other people to love programming too. She encouraged the participants to ask the coaches why they loved programming.

She hit the nail on the head, that was exactly why I was there. But then I had to prepare for the question to be asked of me, "Why do you love programming?"

I've been programming a very long time, writing basic code probably before I was even 10. As long as I could touch a computer I was fascinated with them. When I went to high school there was no question what I was going to do later in life. In college I was one of the lucky few that had a very clear idea of what I wanted my major to be (CS). It's been with me so long, I can't imagine a life doing anything else. That makes the question hard to answer.

For me, it's sort of like answering why you like music or bacon.

It wasn't a new question. I've had to answer this question before, mostly in interview contexts. I have a few hand-wavy answers like

I like solving puzzles
I get to stretch my brain on a daily basis
I like to build things

Not that those aren't true, but they are not very satisfying answers for me or the person asking. So, Why do I love programming?

You know how you and your friends sit around, talk about a problem and say "There should be an app to do this"? I can literally build that app. Given enough time, I can solve pretty much any problem that can be solved by a computer (and that's a lot of damn problems). The power that comes with knowing that is completely intoxicating to me.

And that's what my life is. If I see a problem that looks interesting, I solve it. I get to go to work every day and find a way to build things that nobody has built before.

There's also a ton of gratification you get in my field. I've done only a small amount of open source work, but even I have received tweets and emails from strangers thanking me for my contributions. Inside the firms I've worked for, when I ship features, people get psyched.

As an example, at a previous company I came up with a clever solution to ease data entry for this guy that was working with excel spreadsheets for years. I spent about a half a day on the feature and he told me I literally saved him an entire month of time for a year. He was so ecstatic he took me out to dinner that night on his own dime.

I genuinely can't believe I get paid to do what I would do for free.

Storytelling on your team

2013-01-30T00:00:00Z

Storytelling on your team

Last week I gave a talk at the SFRails meetup. It was by far the largest group I've spoken to and a truly enjoyable experience. I titled the talk "Leveling up Rails developers" and it was geared towards helping engineers build a team which fosters learning and advancement of skills.

Fostering a learning culture

One of the major issues in the bay I've been interested in lately has been getting more junior engineers into the industry. My article on Dev Bootcamp highlights some of these issues.

Our industry changes so rapidly that a constant state of learning is necessary in any team. Learning the toolchain, syntax, business, industry, all of these topics and more. This is true just as much from a junior engineer as a senior engineer. Learning goes hand-in-hand with teaching. I personally value teaching ability over coding ability with any engineer. Learning a platform is also not necessarily a task performed by a manager, but by peers just as much. We should be in a constant state of learning and educating.

Storytelling is one method of fostering this culture.

Storytelling is natural

Narratives are a part of human culture. They cross every cultural boundary. If you go to a bar and look around, everyone is sitting around telling stories. It's the most natural method of communication we have.

Evidence strongly suggests that humans in all cultures come to cast their own identity in some sort of narrative form. We are inveterate storytellers. - Owen Flanagan

Dave Hoover, author of Apprenticeship Patterns told me that he studied various organizations to get ideas of how they bring those less experienced up to speed. He told us about an interesting article studying the collective dynamics of aircraft carriers.

Dave told us aircraft carriers were a great group to parallel since they had younger recruits fresh on the boat as well as senior crew that have been there for decades. The accident rate on aircraft carriers is exceptionally low. What they didn't find was a heavy amount of documentation, rules or mandatory meetings for new recruits. They found that information passed from the seniors to juniors simply by sitting around tables and telling stories.

I believe this is effective since it's simply so natural. Nobody has to tell the senior crew to prepare stories to tell. The junior crew listen intently since the stories are simply interesting to them. These stories are probably funny, but also have a moral subtext. A moral that might be complicated, but deep and effective.

Get your team telling stories too!

Dave brought this onto his team at Obtiva (later sold to Groupon) through a weekly Geekfest. It's still happening at Groupon today. Each week, a member from a different team gets up to give a prepared story to the group. He said it was one of the most valuable practices on his team.

I wanted to take this a step further. I want to emphasize the natural ability of humans to give and receive narratives. On my team at Tapjoy, I started a similar practice called Alcotales. Every Friday we get together at 3:30, leave our laptops, grab a pint and gather around a table. I try and keep the conversation around stories of failure.

Failure is a great place to start since it humanizes the senior engineers. It proves that they are not perfect. It also teaches valuable lessons to the new engineers and provides a natural "what would you have done differently" discussion. Failure stories are not often heard on a team, and usually really entertaining.

We've only had 2 alcotales sessions, so it's hard to say how effective it is. I can say that I (and the rest of my team) looks forward to it every week. Our junior engineers have found it a valuable source of information as well.

Explain your product as a narrative

Another way to leverage the power of narratives is by using it to explain the codebase. Admittedly, Tapjoy doesn't have as easy to understand product as other companies might. This can make explaining the codebase a difficult task. One of our engineers mentioned that what helped him learn the product was to have a story to explain everything from.

Often, as engineers, we think about the component of a system and how they relate to each other. When we're learning, however, we need to think more holistically. We need to imagine what a user might be doing, and why certain code needs to be run.

If we used Hipmunk as an example, the story might be: "Molly is trying to book a plane on April 15th to Portland, Oregon." We can keep referring back to this example to make it clear how the code relates to the business.

Those are my two suggestions on how I plan on using narratives to increase the learning culture on my team. I'm curious if your team has any similar practices, definitely let me know.

How to attend a hackathon

2012-12-09T00:00:00Z

How to attend a hackathon

I think hackathons are really a great thing. They are a relatively new concept, so it is not surprising when I attend one I find myself hacking away with others that are new to the idea. I also think they are a little misunderstood. Even some organizers do not focus on where the real value is with hackathons.

My background with hackathons

I wouldn't be involved in startups if I didn't attend Startup Weekend in Seattle back when I was in college. The idea of taking the extra effort to build products with likeminded people immediately struck a chord with me. I haven't looked back since.

I also wouldn't be in the bay. I attended another Startup Weekend in San Jose shortly after the one in Seattle that helped me network with people. From there, I was able to meet the people that got me my first job in the bay. More importantly, I'm still close friends with many of the people I met at hackathons. Even years later we meet regularly.

Different hackathon types

There are 3 general types of hackathons as I see it.

In-person (AngelHack, Startup Weekend, Disrupt)

Usually a large group of people that don't know each other well. Usually a competition is involved with the winning receiving some sort of seed-funding or support to continue their project into a real company. These are the most 'entrepreneurially' focused. These are the focus of my article.

Internal

A hackathon at work. We've done this at Tapjoy a couple times. The rule we have is, "you have to work on something you wouldn't do on a normal work-day." As I understand, it's gone very well from all sides. I would encourage looking into doing something like this for your own team. We've had some variations in how we've done it (assigned/unassigned teams, in-office and off-site), but I can't say what's better/worse just yet.

Online (Rails Rumble, Node Knockout)

A hackathon that is conducted only online. These are the most engineer-focused. Typically the products will have a smaller scope and target more specific challenges. Usually there are prizes, but most people participate just to build something. There is usually little-to-no need for non-engineers and non-designers in these types.

Who can attend a hackathon

Pretty much anyone can attend so long as they are willing to participate. Even if you don't code/design, you can work on building a business model, pitch deck, website copy, etc.

If you're a student or new to coding don't be worried. Hackathons are a great place to learn new things. If you're looking for a job, they're incredibly good for networking. Unlike most networking events, your contacts will actually be able to speak about your skill in a very intense environment. In fact, I would actually like to see universities get much more involved in hackathons.

Why attend a hackathon

The number one reason is to have a good time. Expect to laugh, socialize, learn a ton and spur some creativity. It is so powerful that I find after I attend a hackathon I have a much improved attitude and have a higher level of creativity.

Expect to meet some new friends. Even if your team is with co-workers or current friends, you will find you're much closer to them following the event.

Hackathons are intense. I try and do very little the day before a hackathon starts (and I typically don't even pull the all-nighters as some do).

What shouldn't you expect?

Don't expect to find a great idea; hackathons are about execution.
Don't expect to win; hackathons are an experience first and competition second.
Don't expect to launch a company; the way you execute in a hackathon context does not translate to the real world.
Don't work too hard; there's a high probability that most of the work you do will never be seen by anyone outside your team.

Most importantly though: try not to expect anything. Every hackathon involves a ton of chaos. That chaos is where the benefits lie.

Regardless of the hackathon, they have a standard formula that takes place over 1-3 days:

Pitches and building teams
Deciding what to build
Building product
Deciding what to demo and how to demo
Demo/presenting/judging
Heavy drinking

The pitches

I like how Startup Weekend does this part the best. They start everyone out on Friday night before the weekend. Everyone goes down to a big auditorium where they have soda + pizza, give some introductions, thank the sponsors, then have everyone line up that brought an idea to pitch it for about a minute.

I haven't actually given a pitch myself, but I am pretty analytical with regards to the pitches. Picking a team is a big deal, and most of my decision will be based on the pitch.

Pitches contain the following:

A problem to solve
A vague idea or 2 on possible solutions
What roles are filled and need to be filled
Roughly what the pitcher's background is

Some are serious, some are less so, and some are not even real projects. At AngelHack there was a team that was going to spend the day flying a plane around in the parking lot. Another team wanted to film pornography.

Personally, I am looking for the following in the pitch:

Do I care about the problem?
Does he/she understand the problem?
Does he/she understand their own solution and it's complexity?
Is it something I think can get done in a weekend, with time to prep a demo?
Will the solution actually demo well?
What is their role? Is it someone I think I will like to work with? (Hard to answer this one)
Will it be fun to work on?

You might be incredibly disappointed after hearing the pitches. I was my first couple of times. The reality is that ideas really aren't ever that great. It's virtually impossible to tell what the winning team will be at pitch time. Remember though: this isn't about winning, it's about the experience.

Another tip: Take notes. Write down the teams that sound interesting. Make sure to also note what the speaker looks like, what their name is and what they're wearing so you can find them later.

Finding your team

After the pitches everyone breaks out and tries to find their team. It's the most chaotic part of the weekend.

People start swarming different presenters. You'll find that some groups get a ton of people and some get very few. Your job is to talk to as many teams as you can to find the right one for you.

This is also the point when you might get a little scared. You might think "well I didn't really love any of the ideas... maybe I should just go home and relax for the weekend". Power through it. This happens to me as well. You'll be glad you did.

Find out what the roles are going to be exactly. Are you a PHP developer? Do they want to build the back-end in Django? You might want to break out of your comfort zone and try something new. In fact, hackathons are where I learned both Rails AND Django. If you could believe it, I wanted to build my first app in .NET. Still, be realistic. If you're really not interested in learning what they want to build the app in then find a different team.

Brainstorm the solution, you'll quickly be able to decide if you want to work with that team.

Don't worry about big vs small teams. I've had a 8-person group that was great. We all had specific roles and executed well. Obviously, I met way more people as well. Large teams are also more likely to win (but again, that's not your focus).

I also have had 2-people groups that were great too. Definitely walked out after the weekend with someone I was happy to call a friend. I also got to have way more input in the solution and felt much closer to the product. More coding, less discussion.

Really though: find the team that feels right. You'll find one, I promise. One time I actually switched teams mid-hackathon because I found a better fit where people needed me more.

Refining the concept

Now that you've found your team, you'll likely seamlessly transition into some planning. Brainstorm different ideas about solutions. The conversation will be a little crazy. You'll jump all over the place. Only thing to keep in mind is to be optimistic and positive. This is no time to ruin creativity by shooting down ideas.

Find a place to set up camp for the weekend. Grab a drink. Just let the conversation go wherever it goes for a little while.

Once you have all these ideas out there, you'll start nailing down exactly what the product should be. Then it'll get even finer to 'what you can demo in a weekend'. This all happens pretty naturally.

When deciding your scope, keep it crazy small. Can't/won't demo it? Don't build it. You can build apps anytime: hackathons are for doing this socially. If nobody sees your code in action, it might as well not exist.

Hacking

There is really not much to say here. This is the most natural part of the event. Don't work too hard. Remember to meet people. Walk around and ask others what they're working on at least once during the event.

Oh, and caffeine is the hackathon wonder drug. You'll hack harder, longer, and be more motivated. Keep the red bull + coffee handy for you and your team.

Some hackers will go all night, I don't suggest it. Get what sleep you can. It'll be hard to sleep since the ideas will be swarming through your head. It's likely the morning of day 2 will involve some dramatic shifts in the product, almost always for the better. Hacking through the night won't encourage the healthy perspective after the drive home and a good night's sleep.

Start the day off with a solid re-analysis of the plan. Figure out what you can do for the demo.

That demo is hugely important. Repeatedly stop coding and think about what you're actually going to demo. It's tempting to build out features that won't be involved in the demo, but stop yourself.

Get screenshots! The best demos I've done have only been screenshots. Screenshots also can't fail like demos always seem to.

Demo time

It can be hard, but try and support your competitors. Winning is not important. Still, you're going to want to put on a good demo for the judges.

If you're actually going to show off your real product, remember to have your screenshots handy just in case. Last time I gave a demo we had to use a powerpoint on an iPhone. Be prepared for every piece of technology to fail. They're all likely to.

Post-hackathon

Go grab a beer with your team! If everyone is too tired, or not in the mood or whatever, set up a time during the following week to meet up. Even if you have to email them and meet individually: do it.

When networking, if you have that second interaction, it really 'seals' it somehow. You'll also have a ton to talk about between the idea you hacked on, the execution of it, the teammates, the other teams, the judges, everything. It won't be a boring conversation.

The number one thing hackathons do wrong

People disagree with me on this one, but the number one thing that virtually all hackathons do that I do not like is have a winner. I attended one hackathon (the Ballmer Peak-A-Thon) that did not have a winner. Everyone presented their projects and instead of critiquing everyone while thinking, "psh, mine is better" I was excited to see what each team built and felt a much better sense of community.

I didn't realize there was not going to be a winner until the pitches were already halfway through. At first I was disappointed thinking that our project could have won. I felt like I lost. That went away quickly. I noticed I appreciated the other projects SO much more.

Don't get me wrong: I love competition. I'm also sure that you reading this are probably thinking that without the without the competition the motivation would disappear. I disagree. People are naturally motivated to build things. The only thing having a winner provides is everyone to believe their project should win, and that every other project is worse.

I would like to see more winner-less hackathons. It's a much more pleasant environment.

Get out there and do it!

I try to attend a hackathon every couple of months. It's a big time investment that makes my weekend completely disappear. Still, every hackathon I've walked away from feeling as if I really gained a life-changing experience. They are intense, but so worth it.

Does Rails scale?

2012-10-15T00:00:00Z

Does Rails scale?

First, the short answer: Damn right it does.

Twitter had to quit using it because Ruby is so slow

It is well known that around 2008 Twitter moved their job backend from Rails to Scala. To me it seems they absolutely made the right choice. Twitter had way outgrown the version of Ruby it was on and they needed a different solution.

Keep in mind that Ruby 1.9 came out a year later in 2009. The performance characteristics between 1.8 and 1.9 is huge. Just look at this graph from Zendesk's report of moving from 1.8 to 1.9

In addition, Rails had no support for asynchronous jobs at the time. Rails would not have done anything to help job processing, so moving to Scala probably made a lot of sense. Today, we have Resque and Sidekiq which make the process much cleaner on the code side.

But Ruby is slow even in 1.9

It's not a fast language. However, that rarely matters. The hard part about scaling an application is proper architecture, solid caching and CDNs, the right database for the job and so on. It's more about external resources than the code in the app. The runtime of the language rarely becomes an issue. The goal is to leverage existing tools in order to do less work on the web stack.

In most scenarios, you're scaling concern will not be waiting on the speed of Ruby, but the I/O. When Ruby is really able to leverage its fibers (such as in em-synchrony), we'll start to see node.js levels of performance.

None of this matters

I wouldn't call Twitter unsuccessful. They did build their product and eventually found the right architecture for them. I doubt the engineers at Twitter think that going with Scala right off the bat would've been the right choice. Using Rails, they could build the product quickly. They could change it in order to build the product in a way that was successful. Rails empowers the developers to change direction without a lot of code change.

Not only can developers alter features, but the same is true on the backend as well. I've worked on a system where we swapped database backends from MySQL to PostgreSQL with almost no code change. Another project where we included advanced caching layers without modifying existing models. In the same way that Ruby allows rapid product changes, the ability to rapidly alter architecture changes ensures scalability.

These are all changes that would've been so prohibitively difficult in my .NET and Django days that we would've just greenfielded a new project.

Rails is not all roses

While Rails does a lot of things well, there is one part of scaling it does not do well. The human issue. Rails encourages the 'monorail' architecture. Projects approach the size that become difficult to work on. No single engineer will understand the project from beginning to end. New engineers will be lost in the project and feel unproductive. Bugs might arise out of seemingly disconnected parts of the code-base.

A more disconnected architecture has many pros in a large system. Engineers will feel more productive as they can really own their project. The knowledge needed to be productive will be much lower.

Square, Groupon, YP, Tapjoy and others have all experienced these growing pains. They've also all moved to a service-oriented architecture (SOA) to solve these issues. One of the biggest issues Rails has is with easing that transition. Now that it's been happening regularly, I think we'll start to be able to identify patterns and enhance the framework to support it, however.

That doesn't mean you should go for SOA right off the bat though. I believe moving from a monorail and then breaking the system apart is the correct approach. With any platform, SOA is simply a more complicated architecture. You also won't know what services there actually should be until you've got a large codebase.

So yes, it does scale

Even given the faults on the monorail problem, Rails scales beautifully. Between the speed of Ruby 1.9, the fact that most of our work is I/O heavy, and the ability to alter the stack: it certainly scales.

Rails Rumble: ARSS

2012-10-14T00:00:00Z

Rails Rumble: ARSS

This weekend I have been participating in the 2012 Rails Rumble. I worked with @amdtech and @childoftv to build ARSS.

Check it out at http://arss.io

The idea

A few weeks before the event I started a group and asked both if they would like to join. About a week before the event we got together and chatted about a few product ideas. One stood above the rest, and that was a system to aggregate information around the internet in order to be consumed and redistributed to others.

An example of what we were looking for would be to have the system pull in all the github commits on a project, and let a team lead aggregate them together to display them on a status board so an entire company can get a solid glimpse of what a team is working on.

The roles

Aaron is the lead ops engineer at Tapjoy so naturally we planned for his role was with the core of the system. Integrating various services, setting up production, setting up the databases, things like that.

Ben is a front-end developer that specializes in UI development. He also has a solid understanding of UX and product. Ben's role was css/js, copywriting and some design work.

My role in the project was building the back-end functionality. I would be integrating the apis, building authentication and adding email receiving support.

The process

We started the project early Saturday morning. We used a whiteboard to communicate with each other what the architecture should look like.

We decided to start out with the least work possible: a simple site that just shows incoming emails through pusher. Not even any authentication.

We got there, it took about 4 hours. We used cloudmailin to grab the incoming emails, submit them to our rails app, stored the results in mongodb, then pushed that to the client. We then started working on building authentication and users accounts. That's when trouble started.

The first roadblock

We ran into a pretty serious issue. Aaron read the rules a little closer and found that we couldn't use any paid external services. We were currently using 2: cloudmailin and pusher. We first felt that we had almost built nothing since the most impressive parts we had built, we couldn't use.

We spoke about it a bit and realized we weren't as bad as we originally thought. We could simply use 'setTimeout' in javascript to replace pusher. We then needed to replace cloudmailin. That actually ended up not being a huge deal either. We had abstracted out the mail processing enough that Aaron was quickly able to replace the cloudmailin functionality with a job that pulled down gmail content using the 'gmail' gem.

End of the first day

We started to get pretty tired around 10:00 at the end of the first day and took a moment to have a few beers. We realized that there was a little bit of confusion over what exactly we were building. Ben and I were picturing it as a way to show ALL updates from the sources in a combined feed, whereas Aaron thought of the output as a feed that was generated by hand.

We were a little confused with why having a user go through and manually select updates to put on the feed would be helpful. He told us how he planned to use it at Tapjoy as a way to notify people of deploys or when we get reports of system instability. Simply getting the firehose of updates from airbrake, github or newrelic is simply too much for most people. There are people in Tapjoy that would like to get more information about the system, but not by automated means. Currently that means drafting a new email to send out to many aliases that are hard to keep track of. What would be better is if he could just post it to a secure site for people to check out if they were curious or seeing issues.

After the discussion, Ben and I went home, but Aaron worked late into the night developing most of the core functionality.

Second day

Starting the second day around 10AM we felt pretty good. Even given that we had different plans for the product, it hadn't made any of the work we had previously done useless. Ben and Aaron cleaned up the UI, I finalized the Github integration, Ben created some artwork and did the copywriting, we were working hard, but felt confident we would complete the project by the due time of 5:00pm.

The result

We were pretty happy with what we had built. We had 2 sources (email and github) and felt that it would be easy to start including others such as issue trackers, continuous integration or exception notifiers.

We wanted to get more support for notifications going out of the system. We want people to consider ARSS the place where information is aggregated before going to external services. Email and an API are necessary to make that a reality.

We plan to keep working on the service and hopefully using it professionally as well.

Want a demo?

If you'd like to try out a demo of the service, login with these credentials at arss.io

user: aaron@arss.io
pass: arss.io2012

Dev Bootcamp is the future of our industry

2012-08-18T00:00:00Z

Dev Bootcamp is the future of our industry

Yesterday, I attended the Dev Bootcamp Hiring Day for the class of Summer 2012. I was incredibly inspired by the people I met there.

Startup careers

I really enjoy my career. I'm always trying to sell the lifestyle to my friends that are either already developers or just looking at a career change in general. With this economy, the ability to grab a 6 figure salary with kick-ass perks is absolutely incredible. Also, engineering is naturally satisfying and fun.

The way to get into the industry is seriously backwards though. Up until very recently, it basically required a Computer Science degree from a university. These degrees are a very difficult degree to attain, accessible only by those that get into computing at a young age.

My career

I have a CS degree myself. I remember my very first day of CS160 at Oregon State in 2004. There was probably ~300 people in the that room. After the first day, only about 200 people remained. After the first week: 150. At the end of the term there were less than 100 that had actually finished the full 10 weeks.

I would not be surprised if there isn't a major more switched out of at Oregon State than Computer Science. It's really tough to stick it out if you're not deeply in love with core CS fundamentals.

For me, classes like algorithms and compilers were really hard because I just didn't care. Luckily, I had great friends that pushed me along. I also got involved in startups during my last couple years which drove me to power through and get the degree out of the way.

I am interested in building products, not pointless optimization. I don't think there is anything wrong with that. There is a whole market of engineers out there with a similar mindset. They're interested in hacking products together, but not in getting an expensive 4-year degree only partially related to what they want to do.

Enter Dev Bootcamp

I heard of Dev Bootcamp a few months ago when TechCrunch ran the article Startups Court Dev Bootcamp’s Ruby Grads: 88% Have Offers At Average Of $79K. This was a huge story to me. I was really happy to see something like that pop up.

They teach exactly what you need to know for a career in modern web development. Most of the program isn't even touched upon in a university. They teach:

Rails development - a truly modern framework with very portable knowledge.
Test driven development - the best way to code, and something I wish I had more in my core than I do.
Agile methodologies - how most companies operate.
Git - the best source control solution as it's better than any other with collaboration, code reviewing and working on multiple features at once.
Soft skills - interviewing, pair-programming, code reviews.

My experience

I attended the event on behalf of my company in order to see if we might want to bring any of the guys in. I'll admit that I'm generally see a more optimistic view of people in interviews, and they were short ~5 minute conversations. Still, I was blown away by pretty much every student. I totally would have brought each of them in for a full interview.

I was told that they only spent a bit of time on the soft skills portion, but I am pretty sure they told each and every one of them how to interview for Jeff Dickey.

The full-stack mindset

I asked most students what part of the stack they wanted to work on. (front-end, back-end, ops, etc). Literally every student answered in a similar way. They wanted to work on the full stack. They wanted to learn as much as they could about general development and be able to work at a company willing to facilitate that.

That's absolutely the best answer to that question, but the answer I rarely get.

Willingness to branch out to unfamiliar territory

When they described the applications they built, they would mention different techniques they used. Doing ajax with straight javascript is an example of just one of these conversations I had with a student. I asked him if he had heard of alternate techniques (such as backbone.js or ember.js). He responded by saying he had researched them, that the tools looked awesome and (genuinely) would love the opportunity to try them out.

Engineers have a tendency to vote for the tools they know best. These students have this early direction of wanting to investigate as much as they can will take them far. It was very refreshing to see.

Excitement for hacking

They all came from vastly different backgrounds as well. One was 19, a couple came from law backgrounds, another biotech, they were all over the map. However, their level of enthusiasm for building applications and learning tech was very similar.

I'm convinced that excitement doesn't come from a CS degree. There are people all over the place that want to build cool shit.

I absolutely loved it

I was incredibly inspired after the event. The only thing I'm disappointed about is that this isn't everywhere. There are certainly other groups like Railsbridge and Code School that are also doing great things for our community, but I want to see more!

I don't think the traditional 4-year computer science path is a only way to get into this industry (or even a good one). Computer Science is only related to software engineering.

Imported lager is the uncanny valley of beer

2012-07-07T00:00:00Z

Imported lager is the uncanny valley of beer

Recently at Tapjoy I became the official Kegmeister. My reign lasted for maybe 24 hours before a coup.

Upon given the honor, I quickly drafted 3 executive orders:

We shall have a third can of co2 at all times to ensure the beer never stops flowing.
We shall have a third keg not inside a kegerator on hand in case of emergency.
That third keg (to replace our beer pong beer) shall be of the Great Domestic Lager: Bud Light. The sure sign of a good time.

I imagine you can assume why I was ousted. Bud Light does not attract fans in the bay area. Not by a long shot. I was quick (but unsuccessful) defending my decisions.

My defense is that beer need not always be flavorful. There is a place for the refreshing taste of a simple domestic lager. It's not worse, just different. Since this was intended to be our drinkable, light, beer pong beer. I felt Bud Light fit the bill perfectly.

I love beer! Being a native Northwesterner, it is unsurprising that I am attracted to the hoppiest of IPAs. I prefer them unbalanced and bitter to the point of ripping paint of walls. I want them to have ABV equivalent to some wines. Some of my other favorites include: the amber, the belgian trippel, and the RIS. On occasion, I will have a porter, pilsner, wheat beer, or really any style. The only style that I am not really a fan of is Framboise. I participated in the Heart of the Valley Homebrewers association back in Oregon. Some of my friends are very into making beer, and while homebrewing isn't my thing, I love to talk about it! (And taste the results!)

But still, I love myself a nice domestic lager. Bud Light, Coors Light, or even better: Shiner Bock and Yuengling! It is a different type of satisfaction, however. What I look for in domestic lager is high carbonation, cold temperature, light flavor, light mouthfeel, simple aroma, consistency and overall refreshing nature.

This brings me to my point. I think that craft and European lager misses the point. They fit somewhere between a nice, flavorful beer and a refreshing, simple lager. These lagers confuse me. I don't know what I'm looking for. They're too 'good' to be lager, but not 'good' enough to be an ale.

They simply fall into the uncanny valley of beer.

MySQL is done. It's the Postgres Age.

2012-05-23T00:00:00Z

MySQL is done. It's the Postgres Age.

Postgres is a relational(-ish) database that's really starting to become the one-size-fits-all of databases. I think this is very interesting since I wouldn't have predicted this direction a year ago.

Schema-less data, array columns, queueing, full-text searching, geo-spatial indexing, it's insane what Postgres can do.

I had a conversation yesterday with Sam Stokes of Rapportive. I wanted to know about their experience using Postgres. They run a pretty massive Postgres system. Sam mentioned that it's gone very well and, if he were to do it again from scratch, he would absolutely use Postgres.

Sam's not the only one, I've heard some great comments about people using Postgres for just about their entire data back-end. Even the data guys I know love Postgres.

I would say that Postgres is by far the top tool being raved about in web dev.

Has nosql failed?

A couple years ago, I thought the nosql tools would be the future. It was really all about "using the right tool for the job". I thought this was an awesome new way of thinking. RDBs shouldn't be the go-to, but a combination of tools. Tools catered to solve the right problem.

Postgres has taken the features out of all of these tools and integrate it right inside the platform. Now you don't need to spin up a mongo cluster for non-rel data, rabbitmq cluster for queueing, solr box for searching. You can just have a single postgres server. That saves a huge ops headache since each of those clusters/boxes have to be durable, replicated, and scalable.

The bad part of using Postgres for everything

Now obviously, there's a glaring downside with this approach: you get one box. Maybe a read slave or something, but really, you can't scale it. I don't want to get into pre-optimization here, but one Postgres box is probably fine no matter what you're doing. If a part starts to underperform, pull it out.

Making a giant distributed data system is a lot of work though. Pre-optimizing here could certainly compromise your project.

Backup is also a huge issue with a distributed system. When you have one box, you can go back into any point in time without any issues. Having even one more data system makes backup really hard. In fact, I'm not even sure how you'd do it.

MySQL has the same problem of having one box, but obviously supports none of these features.

What about MySQL?

Now to address my link-bait:

MySQL is done. There is no reason to use it anymore. The current state of Postgres blows MySQL out of the water. I don't see the MySQL community catching up either. Postgres has been solidly improving.

Performance-wise, it seems to be a wash.

I seriously want someone to tell me just ONE feature that MySQL has over Postgres. I ask everybody this question, and I haven't heard a single thing. Yes, Google and Facebook use it, but I don't really care.

I want to use it!

If you're on Rails, you're in luck. Ryan Bates just posted a Railscast on the topic.

Convergence in web development

2012-05-21T00:00:00Z

Convergence in web development

I want to talk about architecture. Specifically, products backed by a server with a thick front-end. The new hot shit. I'm also very Rails focused. Not that you shouldn't be on something else, but if you are, your life will be less fun attempting this.

A little history

Right now, the big thing (at least in web dev) is the convergence of the front-end to the back-end. We've been here before. First, we had monolithic computers that barely did anything. Then we broke them out into mainframes and thin clients. The mainframes did all the work, and the thin clients were a dumb interface. Personal computing then came next in the 80's and away from the distributed system. The internet came again in the late 90's with servers that crunched web pages and computers that browsed them. Again, a dummy interface. Now browsers are fucking awesome. Tools like v8 have empowered javascript to do a ton of awesome things.

This is nothing new, I just like how computing moves like a pendulum from distributed to non-distributed. I don't believe one is better than the other.

Anyways, that's not my point, what I want to talk about is: What if you're making a system today?

Making a convergent system

I'm going to make a few assumptions about your product here:

You need a server. Probably in order to allow users to interact with each other, or give them information not available locally.
You want to use badass HTML5 stuff on an immersive experience in a single page application.
You want to be able to fall-back to make everything work sans-js.

Now on the server-side, we've figured out how to make awesome server side platforms that are very product-focused and scale very well.

On the front-end, you've got jquery to make life easier, as well as some up and coming frameworks like backbone, ember and a million others. It's new stuff, but there are some solid frameworks.

The problem? Getting them to work with each other.

My experience with this problem.

The biggest experience I had was building an iPad app for Vixely that basically worked like an advanced CMS with many content types users could interact with in limited ways. (voting, saving, etc) I really wanted to find the best way to make the platforms, and I tried out a few different methods before I settled on a final one.

I ended up using backbone + rails. I would quantify my experience as a 6/10.

Things that went well with backbone + rails

Asset pipeline. Being able to keep the code together, run the js templates through erb to add in things like image links was invaluable. Making coffeescript, sass and everything work in dev + prod was fantastic. I loved it.
ActiveAdmin. It's an admin interface for rails that the editors were in love with. Some came from larger companies and found it very easy to use. I wanted to make sure that it was flexible and easy to use. It was, and I'm so happy I didn't try to homebrew all that admin stuff.
Coffeescript. I hate javascript. This made me tolerate the syntax.

There are more, but things that go well aren't as obvious as things that didn't.

Templates make no sense

If you know Rails, you know that HTML-ish files are stored in app/views/*. Backbone also has a similar structure to its templates. Problem is, they are different. One has ruby as the underlying language, one has coffee/javascript. One is generated by the server, one is generated on the client. I duplicated a lot of code here, and it was pretty ugly. I'm not going to lie.

Scaffolding is insane

This is similar to the template problem, but takes place all over. If I have a full server-generated project that you want to add a feature to, it's common in Rails to add a migration to add the table to the db, a model to interface that table to the code, a controller to view/modify the model, and views to display it. The power in knowing where to put things is huge.

Backbone works similarly, but the problem is making them work together. If I wanted a new feature, I had to do the following:

Add migration to db for table
Add rails model to interface to from controller + view
Controller to provide json + html endpoints to browse/edit content
Model serializer
Views on the server for non-js clients
Model in backbone to interface with the Rails server
Backbone route + controller to actual hit the content
Backbone view controller (Rails has no concept of this) to manage interactions
Backbone template to render html

It sucked and felt so dirty.

Testing didn't work

Just so we're on the same page: This is 2012. Don't skip this if you think you don't need tests: you do need tests.

Javascript testing frameworks are nowhere near where Ruby is, no question. There are some around, and they work okay, but it requires a lot more effort. (Well worth it though!) I would bet that the number of JS engineers that test their code vs Ruby is vastly different.

Once again, making it all work together was really painful. I feel like asset pipeline should offer some support here.

Serialization in Rails is broken

At Railsconf, Katz spoke a bit about adding serializers to Rails to make Javascript interoperate with server-side code. He proposed making an app/serializers folder with special serializers that define how models should be serialized. I like where he is headed with it, but I think it's a little too front + center for a Rails project. I doubt that it will end up being in the full framework for mostly that reason.

I say this without any proposal to make it better. It's something that needs to be easy, and I don't think Katz's method is easy enough. It needs to be laughably easy like most Rails stuff.

What to do?

That's the problem, there is no answer right now. A ton of frameworks are claiming to solve it, so evaluate as many as you can reasonably evaluate. Don't expect too much though. The problem with shitty frameworks is rarely lack of a feature, but just being painful to work with.

Negativity on Rails

2012-04-25T00:00:00Z

Negativity on Rails

In attending my first Railsconf, one thing I noticed that I did not expect was a theme of negativity around Rails itself.

It appears a common message that I seem to get from the various speakers is a negative perception about Rails. Whether it is that there are parts of the code base that are buggy, badly designed code, lack of documentation, disagreements on what/how to improve, the level of issues, the performance of the codebase, it is clear nobody is content with Rails the way it is now.

To be fair, if you were to ask anyone directly if they thought about Rails, you would get a positive response I bet. Rails vs PHP, or if they thought that Rails was a 'good' framework that the answer wouldn't be surprising. People would be very much pro-Rails. However, that's not what people are talking about.

Aaron Patterson's keynote was specifically about this. He spoke about how using a queueing system with Rails was not straight forward or maintainable as there was no direct interface to manage queues. He also mentioned there was a queueing system inside of Rails called ActiveQueue, that nobody has heard of, let alone implemented. He called for the community to standardize itself and work together to solve that problem.

I agree with Aaron to a point, but I also feel that having different approaches to queueing provides a sort of Darwinist-software evolution.

DHH's keynote was about how Rails will cause bugs and pain for people migrating to newer versions, and how that was unlikely to change moving forward. He said it was necessary in order to keep Rails an amazing framework.

I think this negativity is fantastic.

I think this shows that the community isn't resting on its laurels. It is self-aware of the problems facing it. Nobody is talking about what they've done well, only about how to proceed. This negativity has probably been the driving force improving the framework.

Open source tools

2012-04-19T00:00:00Z

Open source tools

The octocat above is a rendition of Github's logo, created by cameronmcefee and relevant not only because they exemplify open source, but also since I went to an awesome Giants game last night!

I'm about to head down to my first Railsconf down in Austin tomorrow, and I'm really giddy about it. I'm a huge fan of Ruby. I sometimes hear people ask what it is that I think is better about Ruby vs other languages. I always like to reply that it's not the language, it's the open source community that makes Ruby special.

The Ruby community is heavily influenced by companies like 37signals (I mean, they did make Rails). Which are really transforming the way business is conducted. If you haven't read one of their books, I highly recommend it.

The effect this has on the how Ruby does OSS has shifted more from a technological perspective, and onto a product perspective.

Enterprise tools vs open source tools

Now, I think that in rapid web application development, there is two different schools of thought in a way. On the one end, you have commercial firms developing tools (e.g. Sencha, ASP.NET), and on the other, open source tools which may or may not be developed by a commercial firm (e.g. Rails, Django).

The enterprisey type typically involves IDEs, auto-generated code, designers, things that typically sound freaking awesome in some marketing pages, but fall short in practice. They also have a tendency to try and pull you away from the code a bit.

The open-sourcey type typically involves focuses on text editors as opposed to IDEs, no designers, no stupid graphics, just text and code that works well. It's developer friendly even if it doesn't look as sexy. They also drop you straight into the code, leaving little in the way. When it is in the way (as in the case of sass, jquery or activerecord) it's helpful yet flexible. This is accomplished by having active communities that shape the frameworks as real products get made.

I'm unabashedly biased here. I think the era of people selling developer tools has ended long ago. It's often times difficult for me to argue against the enterprise systems since they do market well for sure, but in my experience, they are hell to actually work with.

On open source as a whole

The best open source projects are by commercial firms that sell their by-products. Some are incredibly well known for it (37signals, ThoughtBot, GitHub). You know what's crazy about these by-products? They are usually insanely good. The best code I've ever seen is virtually come from someone making a paycheck at a respected company and releasing it to the community.

You can bet that if I am suggesting a gem to my colleagues, and I mention that 37signals created it, their trust in it will increase dramatically.

Github

Github is the medium that open source is accomplished. It dovetails so well with Ruby's Bundler dependency manager that I can take an existing project, add a feature to it, and use my version of it in minutes. I can then submit a pull request to the original author to request that my feature get added in. This wasn't possibly even just a few years ago, and it's even becoming standard practice with a lot of firms.

On Ruby

Ruby executed all of this so well. They didn't invent it, but the focus from making something very tech-oriented (like Linux) to product-oriented has resulted in this amazing era of commercial products with free open source tools to make them.

For example, there are tools coming out now such as ActiveAdmin, or Cucumber that, while not for everyone, are insanely innovative and easy to use.

I've been eyeballing Railsconf's schedule, and I'm disappointed that there are only so many sessions I'm going to. Some of the ones I'm interested in?

Practical Machine Learning and Rails
Ruby on Rails on a Roomba (probably not going to shape the future of the internet too much, although nerds love arduinos)
Patella: It's Memoization into Memcached calculated in the background with Resque.
Basecamp next: Code spelunking
Katz's presentation on where Rails should be in the next 5 years!

A final note

I said open source tools are the future. Not products. Even Github itself is absolutely not an open source product, and shouldn't be. If you want to actually license Github to run it on your own server? $5,000/year. Even Github itself recognizes that some things work well as open source, and some don't.

The element NoSQL is missing

2012-01-18T00:00:00Z

The element NoSQL is missing

I'm a big fan of NoSQL products. MongoDB, Redis, CouchDB– it's really awesome stuff. However, I almost always just use a relational database. I feel much more comfortable with RDBs actually.

My favorite DB design is when you have a relational database for businessy things (users, money, content) and a fast, scalable store for relationships, transient data and whatever other application logic would benefit best from NoSQL.

NoSQL is all about the right tool for the job. My assumption is that this implies a system could use several stores.

I know how to make a system like that work, what the pro's and con's of using various db's are, but there's one element I am not sure how to handle: Backup.

I write this article as a question to you: how do you backup two systems? When I have architected this type of design, I have to have one of the following be true:

I don't care about backup as one of the stores isn't critical
The data in one of the stores can be regenerated
Concurrency between stores isn't important

For a reasonably complex system, I doubt any of these would be true. Is there a good, general way to snapshot a whole system across multiple DB's?

Send email from your domain? Make sure your SPF headers are set.

2011-12-16T00:00:00Z

Send email from your domain? Make sure your SPF headers are set.

Here's a quick thing you can do to make sure your email doesn't end up in spam folders. I'll keep this simple for people that don't know much about how email works.

First of all, go here: http://www.mxtoolbox.com/spf.aspx and check your domain to see if anything shows up for your SPF records.

You should see something like 'v=spf1 include:_spf.google.com ~all' for Google mail. If you don't see that, follow the rest of this article.

The crazy thing about email

Most people have no idea that the 'from' part of an email has NO built-in security in it whatsoever. I can easily send email pretending to be from any email address I want. I can be bill@microsoft.com, obama@whitehouse.gov, whoever I want.

As spam became a problem, it was clear that we needed at least some protection against this.

So one thing that was invented was SPF (sender policy framework) records.

What are SPF records?

When you get an email, traditionally the incoming server had no way to check to see if the server that sent it was legit.

As an example, I own a domain through namecheap. I send my email through google. Technically, anyone could setup any server, anywhere to send email through my domain. However, I know that the only legit email server able to send email is google.

SPF records let me tell anyone that gets my email "If an email gets sent with an @jeffdickey.info account and DIDN'T come from Google, it's probably not me".

Why fix them?

Not having an spf record in place is a huge red flag to incoming email and will result in it ending up in spam folders.

It also provides security since if anyone sends email through your domain, the spam algorithms will know to flag it as invalid.

So spend 5 minutes and fix this. Here is instructions for those on Google Apps: http://support.google.com/a/bin/answer.py?hl=en&answer=33786

DKIM

When you get done with that, set up DKIM for many of the same reasons: http://support.google.com/a/bin/answer.py?hl=en&answer=174124

Python vs Ruby: Maintainability

2011-12-15T00:00:00Z

Python vs Ruby: Maintainability

One of my favorite subjects is comparing and contrasting tools and frameworks available today. Python and Ruby are probably the big 2 languages right now in web development.

Now, a language is less important than the framework. However, the language sets the stage for framework's philosophies. Obviously all frameworks are different, but Django acts like Python and Rails acts like Ruby.

Writing a full article would be way too much. I've used both tools extensively for years. I am totally biased, I much prefer Rails to Django. Django does have its place though, and there are some things that the Python community simply does better.

Consider this the first in a series of articles comparing the two. This one, will be on the topic of maintainability. Maintainability is how easy it is to change/fix a product after it has been released.

Python culture

The Python culture is very idealistic. You get a total sense that there is a Right and a Wrong way to do something. Often times they will not have shortcuts you find in other languages, because the culture is very against having multiple ways of doing things.

The reason for this is readability. Something that Python excels at. I think it's probably the biggest goal of the Python community: to force readable code. It's actually difficult to make unreadable Python code.

It certainly isn't always concise (compared to Ruby, but very concise to Java/C++). Still, concise and readable are not the same thing.

Python also has this concept of 'Pythonic', which really means the Right way of doing something. They also have a king: Guido van Rossum. If you're in a debate with someone about Python, and you can find Guido saying something on the topic, Guido is always right.

This all moves towards this goal of simplicity and readability. For this reason, Python is without a doubt the easiest language to read. If I had to work on a project with developers I knew were going to suck, I would push hard for Python.

Ruby culture

Ruby has an incredible culture. It is similar to Python in some ways, open source is very much encouraged, it's practical, not run by a corporation, and it's just flat out an awesome language.

Backwards compatibility and readability though, definitely are not the main focus of Ruby. It's important, sure, but it takes the back-seat to productivity.

Ruby is very, very productive. There may be multiple ways to do things. As an example, with Django, authentication is built into the framework, there is one Right way to do it. Ruby has no built in authentication, and you can either do it yourself, use Warden, Devise, Sorcery or many other options. Each themselves has good and bad things about it, but they all work well.

You can absolutely get things done faster with Ruby. Especially when it comes to things like caching, nosql, workers. I know Python better than Ruby, but I still work much faster with Ruby.

Ruby has no king, it has a creator (Matz) but to be honest, I don't know much about him. I just know he works for Heroku. I'm sure he has a large influence on the community, but not like Guido.

Maintainability is also mitigated through other means. Rather than focusing on readability, it's taken care of simply by having less and better code. Also, the heavy focus on test-driven development absolutely reduces the amount of bugs, and can almost remove the chance of regressions.

I would also argue the gem system is much better than Python's packages, resulting in making it easier to share code between projects/companies/people. Python has always done this well, but things like Ruby's Bundler are just way better than anything Python has.

So in some ways, Ruby just doesn't need to be as readable to stay maintainable.

Summary

Still, Python wins in maintainability. This is both because the code is readable, and has a heavy emphasis on backwards compatibility.

However, maintainability is not everything. In fact, I think most developers focus TOO hard on it. Getting the product out the door is absolutely more important.

Also, while the language helps with maintainability, it's up to the developer. You can have super maintainable C code, and totally unmaintainable Python code. The language helps, but it is really nothing compared to the engineer.

My good friend Max Kanat-Alexander said this so well:

Python is the easiest language to read, Ruby is the most fun to write.

I could never have said it better myself.

Pixelmator rocks

2011-12-13T00:00:00Z

Pixelmator rocks

I love pixelmator. It's one of the best applications that I own, and I would buy a mac just to use it.

Pixelmator is an image-editing tool VERY similar to Photoshop. It's available only on OSX for $30. Photoshop right now is running for $700.

Don't let that fool you into thinking you have less value. I would probably STILL use Pixelmator over Photoshop even if you flipped the prices.

Pixelmator starts way faster, doesn't use as much memory, it's easier to use, has a much better UI. It's better in every way I can see.

Now, obviously, I am a developer, so my needs are different than a graphic designer's. However, I still have needs for an image-editing tool. Most of my work is around cropping, resizing, background removal, simple text graphics, and just generic basic editing of existing images. For this, Pixelmator is faster and easier to use.

I can also open, splice and save my designer's Photoshop PSD files.

I hear from people that Pixelmator is not as capable of Photoshop. Since Pixelmator 2.0 came out, there's nothing I haven't been able to do that I've needed to. As I get more into graphic design, I find that Pixelmator is offering me much better tutorials and guides as well. I think people say that because they're heartbroken over how much they've paid Adobe.

I don't care if it's not what the industry uses, it's a better tool as far as I've ever seen. Don't let the price-point fool you; we don't need to be paying hundreds for photo editors.

Can we fix HTML/CSS/JS syntax?

2011-12-12T00:00:00Z

Can we fix HTML/CSS/JS syntax?

As in my last post on how we need to stop abstracting, I wanted to talk about the syntax itself of the big 3 web languages, HTML/CSS/JS.

I use HAML, SASS and CoffeeScript. It might seem like I'm going against my own advice in my last article about abstraction since these are all layers on top of the big 3, but let me explain a bit.

As I said, abstraction is a tool, that can be helpful and might not be. Syntax alone, I think the big 3 have terrible syntax. HTML is hard to read and verbose, writing straight JS always results in me lining up curly braces and why the hell does CSS have no concept of nesting?

These issues are easily fixed with HAML, SASS and CoffeeScript. You get beautiful syntax, but they're still only lightweight abstractions that create code that is very easy to read. I can debug CoffeeScript generated javascript, for example.

These tools feel like shims to me. As if all the syntaxes could take away some of the ideas (especially css) and use them. Will these syntaxes ever be improved? Will these 'shims' become standard practice? They almost are in the Rails community.

We need to stop abstracting

2011-12-11T00:00:00Z

We need to stop abstracting

Abstraction has been essential to make computing what it is today. Without it, we would all be writing assembly code. Abstraction allows us to think at a higher level and be comfortable the lower level is working well. It promotes reuse of code. It's a cornerstone of object-oriented programming.

However, it is a tool like any other. My truck is a tool, and if I want to go to Los Angeles, it's going to be much more efficient to use it rather than just walking. If I need to go to the kitchen though, it may not prove to be so helpful.

Maintainability problem

Abstracted code is more difficult to understand than direct code.

For example, say I have a Python web server. Part of this server needs to turn objects into XML in a fairly standard fashion. Part of the XML contains bits of double formatting that can have a variable number of decimal points and padded zero's. So you make a function like convert_double_to_xml_format. It takes in various arguments to handle these different options.

This is abstraction. You're taking the act of performing string manipulation and putting it into a separate call. You will greatly simplify the character count inside of the XML generation as well.

However, say a new engineer comes along. If you hadn't abstracted and simply did the formatting in-line, he would have no trouble understanding exactly what the code is doing. Now that you've abstracted, he has to find the file containing the abstraction, figure out it's intent, and decide how it's being used at each point.

Code duplication

The enemy to the modern software engineer: Code duplication. The act of even assuming I might copy and paste some logic to use it somewhere else is a sin.

I do it every day. I do it more than I even abstract.

Often times, the 2 code paths will diverge and come completely different things through refactoring anyways, so abstracting would never have worked. Other times, the code is just more readable. While you can argue that this is prone to bugs and complicates change, the fact that anyone can pick it up and understand it immediately is a totally valid trade-off.

We generally don't acknowledge the cost of having logic in 2 separate files. Python helps with the imports at the top of a file, but most languages offer little help here. Readability is always more important than abstraction.

Abstraction is only helpful if you understand how the abstraction itself works.

1% of the problems take 90% of the time

I've heard this many times. It is absolutely not true. Engineers working with dinosaur frameworks will say this, and for them it is true. Abstraction is the reason for this.

If a framework is abstracting something out for you, then it needs to account for your business problem before you do. In exactly the same way. Obviously in the enterprise, this is more common than someone like me in consumer web, but I refuse to believe that any framework can solve even simple business problems with entirely pre-built solutions.

That's why that 1% takes so long.

Keep your project running locally

2011-12-07T00:00:00Z

Keep your project running locally

Every web project starts out with the best intentions, running locally, unit testing, easy deployments, provisioning of servers. As a project moves on, some of these niceties drop by the wayside, specifically: The ability to run locally.

Never let this happen to a project. You cannot afford the cost of it.

It happens to all projects for the same reason. You have some bug you need to fix, or are working on some feature that NEEDS to get out and you decide to just fire up vim on staging/production, fix it and make the change later.

Eventually, (and it doesn't take long) this creates an environment that cannot be run on a local machine. It's even more likely to happen if you're on Windows.

There may be other things to consider though. Servers are almost always a different operating system and have different dependencies. They probably aren't capable of provisioning themselves automatically. The dev environments also might need to run a separate process (like a worker thread, or solr or something)

Keeping the project running on the dev's boxes is no easy task.

Why is a project running locally so important?

When a project can only be run on a server, you have to do a few things you wouldn't have to do on a local box.

(Generally) you can't have your own text editor setup, especially if the text editor of choice isn't a console one
You're probably not using automated tests
Someone else deploys to that server, all your work is gone
You have to SSH in
Somehow you have to transfer files back and forth. Most devs will use their own memory or copy-paste, better devs will use rsync, but even rsync sucks here
Restart the server after a change (or enable code-reloading)

In the end, everything takes more time. When I code like this, I'm probably less than half as efficient as I could be. Not so much the extra steps, this is the sort of thing that makes an engineer's life miserable.

Most companies I've worked at have had this problem, and it's one of the things that ultimately made me quit working for them. Perks and money are nice, but having to go through this everyday is something that I personally cannot deal with for very long. It tears apart my sanity.

This will immensely help with onboarding. Since new engineers won't have to be brought up to speed with as much. They can also be comfortable messing around in their own environment.

How can you avoid this problem?

I'll be honest, it's not easy to avoid this problem. It takes serious dedication and willpower. Again though, it's not worth it to give up on.

Here's what you need to do:

Be able to create a new dev environment very easy
Be able to provision new servers easily
Make production as close to the development environment as possible
Use code-reloading on the development environment
Use git

There's some tools out there to help with this. The ones I'm going to mention are all ruby-focused, but I know many python and php developers that use them and they work great.

Vagrant

Vagrant is sort of a command-line wrapper around virtualbox. Sounds totally boring and useless, but it's designed specifically to tack most of the problems I just mentioned. It can not only start up a vanilla linux distro in 2 commands, but it can provision them as well!

So if you have a Vagrantfile in the root of your project, a new developer only has to type 'vagrant up' into the command line, and they'll have the ability to run a fully provisioned, ready to go production-like environment.

It will also link the local project directory to one at /vagrant on the box, so any changes made locally take immediate effect on the box. It also sets up port forwarding so you can just hit 127.0.0.1:3000 and you'll be hitting the vm.

It can use either a bash script, or chef or puppet (or a combination) for the provisioning.

I don't use it on every project, it does take time to setup. Most of my projects will run just fine over osx. However, if you're on Windows, you NEED this.

You can also mess around with crazy things like updating all your gems, trying out the next version of django, whatever you want. You feel comfortable knowing you can destroy the whole environment and regenerate it.

Another bonus: Whether you use chef, puppet or a straight file, you've got the ability to provision a production machine as well. Load up a new ec2 install, run the provisioner against it and you've got a production ready machine that works just like the dev environment.

Chef + Puppet

Chef and Puppet are the new big deals in the unix community. They provision servers. I've used both, and hated both. They're difficult to learn in my opinion. I have used both enough to get by, but it's not an enjoyable experience like I feel like it should be.

I probably just need to learn them better.

Still, they're the best out there I know of for you're provisioning servers.

Capistrano + Fabric

Capistrano and Fabric are deployment tools. When your server has been provisioned, run these to deploy/start/stop/migrate dbs, whatever you might need. Use one of them.

Foreman

Foreman is VERY simple. All it does is let you have a file like this

web:    bundle exec thin start -p $PORT
worker: bundle exec rake resque:work QUEUE=*
clock:  bundle exec rake resque:scheduler

And if you run 'foreman start' at the command line, it'll run like this:

Image from David Dollar's Introducing Foreman

Easy way to ensure that the server is being started the same way by everyone, and all the dependencies get started as well. This is so you don't have to have an extra command window open for your worker server.

Summary

As many people know I am a big fan of Heroku. One of my favorite things about Heroku is you cannot access the server. I know a lot of engineers that would see this as a drawback, but I see it as prevention against me shooting myself in my foot.

So there is some tips on the worst thing a project can do to an engineer. Like I said, these are not easy problems to solve, which is why I only told you what the tools you need are and where to find more information on them.

Spend the time to use them and learn them, it's worth it.

Cache correctly: stop invalidating

2011-12-04T00:00:00Z

Cache correctly: stop invalidating

There are only two hard problems in Computer Science: cache invalidation and naming things. - Phil Karlton

One of my favorite things about Rails is that when I read the docs, sometimes I find little gems that just jump out and make me cheer with happiness.

ActiveModel's cache_key method is one of these things.

Let me explain

On my blog, I write the body in markdown. I have a method on the model (not a helper, like it probably should be) called body_html that takes the blog's body and converts the markdown into html. In a given view, I call this a couple times, once for the body, but also for the description meta tags.

It would be nice to only have to perform this computationally intensive operation once, then cache it for later use.

In Django, which is where I was before Rails, I've had to implement caching on some serious systems. Django has much less syntax sugar around caching. If I had to implement this in Django, I would've done the following:

def body_html(self):
    body_html = cache.get('article:' + self.id + ':body_html')
    if not body_html:
        body_html = markdown(self.body)
        cache.set('article:' + self.id + ':body_html', body_html)
    return body_html

What this does is attempts to get the cache for the key 'article:[id]:body_html'. If it can't find it, it converts the body into markdown, then saves it into memcache for later use.

This works great, until you change the text.

Now Django will be pulling in the stale html out of memcache instead of updating itself.

So what do you do?

You could set an expiration time of say, 10 minutes, but this is somewhat inefficient since it'll update when it doesn't need to, and you can't see your changes right away.

You could use a signal on the model to reset the cache at that html. (But as anyone that's used Django intensively can tell you, signals are flaky at best). You'd also need to be super careful you're never bypassing the signals or anything.

Like the quote at the top, cache invalidation is very hard. Not hard to do, you just call cache.delete. Hard because it's not obvious WHERE to invalidate the cache.

So what genius does Rails provide here? The cache_key. The cache_key, unlike my lame cache key I would've used with Django 'article:[id]' includes the timestamp of the last updated time of the model, so something like: 'article/5-20071224150000' instead.

This makes it so if the model is updated, the cache_key will never get hit again!

You would use it, like so:

def body_html
  Rails.cache.fetch "#{cache_key}/body_html" do
    markdown(body)
  end
end

Note: you have to have an updated_at column on the db table for this to work, but rails will add one to all table migrations by default.

My first reaction was, 'well, how would I invalidate it if I can never reference it again?' but you don't need to.

Memcache is an LRU cache (probably don't want to use this pattern on a cache backend that isn't). So if the cache fills up, it'll just dump things that haven't been accessed in a long time.

Obviously this isn't limited to Rails, but I never thought to use the timestamp before. Maybe this is something everyone knows (it seems obvious). But I really wish I would've learned this trick earlier.

I would argue the best form of cache invalidation is this. Don't invalidate if you can help it, just alter the cache key.

Won't work for all cases, but it's a nice pattern for most.

Commenting systems: Disqus vs Livefyre

2011-12-03T00:00:00Z

Commenting systems: Disqus vs Livefyre

Commenting systems are the big thing nowadays. I think pretty much all sites should use something rather than rolling their own.

I chose to look at 2 that I've had experience with. There is also another one I have not yet used called Intense Debate.

So here it is, my review of the 2 site plugins with the worst names in existence.

Why are these tools better than having your own commenting system?

Low barrier of entry for readers to comment
Users may already have an account with the service
Spam and moderation is much easier to manage
Offloads work from the server
Very easy to install
Can show feedback that is happening on social networks
Sorts comments by popularity and importance rather than recency

Disqus

I'm somewhat familiar with Disqus for other reasons. David Cramer is active in the Python/Django community and has built some awesome open source tools. So when the time came to integrate comments on my site, Disqus was the first thing I thought of.

Disqus is also very popular. You see it everywhere. This means it's likely users will already have an account and be more likely to comment.

The setup process was easy. I did a bit of work afterwards to setup some things like enabling local support, linking to the article rather than the url, and highlighting my own name on the comments so the readers can easily see my replies.

I love the design, and it is really easy to customize. The moderation tools are top-notch as well.

It went well. I really only have 2 complaints about Disqus.

First, since I use slugs for my articles, sometimes I change the names of them while I'm still writing them. When I do this, it messes up disqus a bit. The comments are still there, but users will get an email to the article at an old slug. This is really annoying and causes me to have to manually update the urls in their system (which requires uploading a csv for updates). It's really annoying.

I could remove the hard link via the article id's, but if I did that, the comments wouldn't show on my local box, and if I ever wanted to change a name after people started commenting, it would be lost.

My other issue with Disqus is that it's slow. Most of my site's total loading time of pages is with Disqus. The CSS stylesheet they use very inefficient. There may be more problems with their speed, but this is most likely a huge cause of the slow performance.

It's not so bad since it's on the bottom of my page. However, I like having an all-around fast site, and Disqus makes that impossible.

Livefyre

I tried out Livefyre today. They have a few more features that Disqus does not. The biggest difference between the two is that they really focus on heavy social functionality. I hear it works well and has good results in creating a lively community.

Tagging of people on AND off the site. This can bring people into the site directly in the comments
Captures conversations on twitter and facebook to bring all the conversation into the site
LinkedIn integration, this is important for my audience
Search engine crawlable, this is pretty cool too

I don't think it is wrong to argue that Livefyre has more features than Disqus.

So I decided to integrate livefyre on my blog to test it out.

The setup process was really easy. A little too easy though, let me explain. It's a 2 step process, put in your url, paste a simple code. You can get it running very quickly. Problem is, it doesn't tell you how to customize it. On Disqus, it was easy to define the article id and name, but with Livefyre they gave no indication on how to do either of these things. In fact, I'm still not sure if I can define the article name. They probably use the site title, but I would rather not use that since I always append 'by Jeff Dickey' on my site title.

I looked through the support on their site and found nothing. They have no documentation. Maybe they figure they don't need documentation because they're so easy to use?

Well, they're wrong, they definitely do need some docs. Preferably a link to them after the setup process. For getting the site to link to the article id's rather than the URL, I eventually guessed how to do it and got right. I sent in the key 'article_id' in the initializer, but that was a lucky freaking guess.

It also dumps a ton of console.log statements into the console. That might be okay if I wanted to debug Livefyre, or just didn't care, but if I had a javascript heavy app, that would be truly annoying.

It has no support for running the commenting system locally either. Disqus does this and clearly describes how to do it. I had to push it up to production and 'hope' it didn't break. (Oh and get this, it DID break)

This is definitely up there with the least developer friendly tool I've ever integrated on a site.

How developer-friendly a product is does not make or break a company, but you can bet after my experience how I would feel about suggesting a tool like this to a client.

The design in their internal site is odd too. Parts of it are pretty good, but then they had shit like this:

More inability to line up things:

Then, while browsing around on their site and clicking the Log In button, I got this:

Calling me a 'punk' for clicking your login button? You do have a 'dumb site'.

404 is the wrong error code from that description anyways. It should be 401 or 403. For someone that has worked on a lot of web sites, this is actually a clue into their system. 404's should be handled very differently than access denied codes. No matter what framework or platform they are on, this is telling me that they're totally reinventing the wheel with authentication, and that wheel is looking pretty square.

Obviously, I'm only drawing conclusions based on very small bits of what I've seen, but I would put money on Livefyre's code-base being just as flaky as their design. Disqus, on the other hand, I have seen their code (gargoyle and sentry), used it in production systems, and it's excellent.

The entire system feels unfinished. Maybe some of those design details seem small, but as a whole it feels really chintzy. Running into a bug when I click login did not help my stance on that.

The UX is terrible. To get to my site's moderation takes a ton of hunting. Like I said, I also never found a way to configure the code.

It's safe to say that I did not like the process of integrating Livefyre. Not at all. Disqus was good, not perfect, but good. I've yet to use Livefyre to actually moderate, but based on what I've seen so far, I'm not terribly excited about moderating.

I love the direction they are going. They seem to be ahead of the market as far as the product vision goes. It's a shame the product is in the state that it is in.

Summary

So I've yet to use Livefyre in-depth, but so far I feel like Disqus is the better option. Even though it's slow and has a bug that bothers me. It has a larger user base, I like the onboarding more, the design is much better. As an engineer, it genuinely feels more solid and reliable.

I could be swayed depending on how this social interaction that Livefyre has works out. If I find that people seem to chat much more with Livefyre, it may be the better option.

So I'm A/B testing them both, you'll see some articles with disqus, and some with livefyre. I'm just going to see what works out better!

EDIT: And would you look at that, I try and actually use Livefyre on my site, and it thinks it's running locally, actually, it's not even the right article! It thinks it's the Redis article. I have no idea how that even happened. The ID for this article was always correct. (Post a comment and see the url that it thinks the site is at). This is similar to the problem I had with Disqus, except that with Livefyre I have no clue how to fix it. I don't even think it is fixable. That was probably my last straw for that pathetic commenting system.

CloudFront vs CloudFlare: We have a winner.

2011-12-02T00:00:00Z

CloudFront vs CloudFlare: We have a winner.

This a follow-up to my first post on CloudFlare. This will make more sense if you read that one first.

John from CloudFlare was kind enough to invite me (well, technically I kind of invited myself) down to the CloudFlare offices. Conveniently located just a few blocks from where I'm working! Gotta love San Francisco's SOMA district. We talked about my earlier post.

I gotta say, everything from configuring CloudFlare on my system, to writing up the first article, to visiting their office has been incredibly fun. I've really enjoyed it.

On the snake oil

As you remember from my first post, I had a big issue with CloudFlare. I couldn't quite put my finger on it, but it sort of just felt like marketing spam. I'm also not the only one. The odd thing was, I couldn't find anything they were actually doing wrong. Now, I think I've decided what my problem was:

They're just too damn cheap.

I worked with a client once that was paying thousands/month on their CDN through EdgeCast. I found it incredibly hard to believe that CloudFlare would be willing to provide a similar service for absolutely nothing. Yet, there they are.

Most of my conversation was trying to find some loophole where you would have to start paying more if you were really hammering their system. John mentioned they have several high profile sites (such as 4chan, youm7, the 6th largest site in Egypt, nerdlist, and laughingsquid) that are on their system. They have >100,000 sites, which makes them much bigger than I imagined. He said that some of the high-end clients to pay a bit more, but that's for an SLA, not bandwidth.

He said a few times the pro package was working well for them. Even at 20 bucks/month. No matter how big you are.

I had some concerns that CloudFlare might increase it's rate and remove it's free plans. John assured me they will be adding more pricing tiers, but they will not be removing, or taking away functionality from the free plan. Still though, even if they did dramatically increase their rates, there is no vendor lock-in. It would be trivial to switch over to another CDN.

I still don't understand how a company could have a 2k/month EdgeCast bill, and CloudFlare would be willing to let them on for free with the basic features. If this is working for them, either the other CDNs are totally overcharging, or CloudFlare is just running so efficiently internally that it's not necessary to charge more than they are.

On stability

Now, Andrew Lippert has a great comment on the original post. John mentioned that he knew Andrew quite well, and that Andrew has been very active in the community for CloudFlare. John replied to Andrew directly on the same post.

I won't reiterate what they said on there. I also cannot comment on the stability of CloudFlare as I have not had any downtime myself. Their site did have a lot of slow responses and timeouts while I was using yesterday, but mine has been fine. It's only been 24 hours though, so who knows. John did mention that they're working hard to make sure the platform is incredibly stable.

On the security

One of the interesting problems CloudFlare has is they can't quite find their core value. Are they a CDN? Are they a security company? Something else? It's hard to tell, they do all these things.

I didn't mention the security much in my last article. This is really only because on my blog I don't really care.

What I do find odd though, is that according to them 21% of the traffic to my site is 'threats by attackers'. From reading my logs... I find this hard to believe. I'm wondering how much of that is false positives.

One neat feature he mentioned is it actually is looking at sql injection and xss attacks that might be coming across. As you'll see in my security article, I'm a big fan of another layer of prevention for this.

Now the big comparison: CloudFront vs CloudFlare

It's hard to not choose CloudFlare here. Here's what CloudFlare has:

Much better interface
Much easier to setup
Can optimize many things not related to just static assets
Security preventions (CloudFront, being solely a CDN has none of this)
Analytics to measure how well the CDN is helping your server
It's freaking free

What about CloudFront? I can't think of much, I would appreciate thoughts in the comments.

The only thing I can think of is that CloudFront has much more control. If you need to invalidate cache on an individual asset, for example, CloudFlare can't do this (but John specifically mentioned this is coming). I imagine there might be similar issues such as this, but I can't think of any else to be honest.

There is a Client API for CloudFlare I did not know about in the previous article: http://www.cloudflare.com/wiki/Client_Interface_API I wouldn't call it extensive, but it's nice they've got something to potentially build out. There is some neat things in there though, like querying for search terms hitting the site.

The lack of control is intentional on CloudFlare's side though, they don't want you to have to think about things like that.

In summary

John asked me if there would be any reason I wouldn't go with their system in the future. To be honest, I couldn't think of one. CloudFlare is providing an excellent service for nothing (or next to nothing). It's also packed with a million times more features than any other CDN.

Bye CloudFront, I'm going the free route. Here's the proof.

Bonus: S3 and CloudFlare how-to

I hate to turn this into a how-to, but I did get my question on how to get S3 working with CloudFlare working. It's so easy it doesn't warrant it's own how-to:

Just make your s3 bucket the full host you want. For example, for me it was 'content.jeffdickey.info'. Then set your DNS CNAME in CloudFlare to 'content.jeffdickey.info.s3.amazonaws.com' (obviously replacing my bucket name with yours). Then you'll be good to go.

What would a web engineer certification look like?

2011-12-01T00:00:00Z

What would a web engineer certification look like?

Image credit to Randall Munroe

I did a couple of Google searches for this, but surprisingly came up short. Someone must've came up with something, so if you know of a similar write-up, please leave it in the comments. I would love to see it!

On the other hand, looking at the issue with sort of fresh eyes might not be a bad thing.

Security is not my favorite topic

It's painfully boring. A lot of it is dealing with rare edge cases. Most of security preventions are preventing highly unlikely scenarios that never happen. As well they should. I ensure that my apps have a solid amount of security in place. It's not difficult, but it's a rare time in programming where experience really does matter.

You can code for years and not have a clue what a sql injection, xss, or rainbow table attack is.

So if you aren't into security, why are you writing about it?

There are terrible engineers out there. At Some Major Companies.

Each of these attacks could have been avoided completely by the simple suggestions in this article.

So what are you suggesting?

I'm not so much suggesting there should actually be a certification to be a web engineer. I'm not a huge fan of that sort of thing in general. However, all other engineers in other fields need to be certified in their trade. Mostly because they can kill people. I can't write bad code that can kill someone (I hope). However, I can write code that can ruin someone's life.

If there was a certification though, these are the big 3 security things that every single web engineer should know (**especially** the novices). If you are an engineer, and you don't take the time to learn and follow these, you are absolute scum. Ignorance is no excuse with these. These are unavoidable.

Password hashing

This is the most important security prevention. Unfortunately, there are some cases where this will not work. (Often where you are storing credentials used to login on behalf of a user.) But OAUTH is mitigating the need to avoid these rules.

It's really simple too. Imagine you have a database with usernames and passwords. When a user logs in on a website, the website looks up the username, checks to see if the password matches, and logs them in.

Works great, but what happens if a hacker sees the DB? Or what happens if someone with legitimate access to the database just wants to start stealing those passwords? Bad stuff happens. This is how almost all serious attacks with the big companies happen.

So what can you do? You could encrypt the password. Then have a decryption key stored somewhere 'safe' that can decrypt it and compare it to what the user typed in. Now the database would just have what looks like garbage to an attacker.

You've added an extra step, but the engineers with access to that 'safe' key can still get in and get all the passwords. And a hacker could potentially get the key as well. So, you haven't really solved anything.

Okay, but here's the thing, say the user's password is 'hunter2'.

In the database, it might store that encrypted as '3ksk2b'.

So when the user logs in, it takes the db password, decrypts it to 'hunter2', then compares it to what the user typed in.

We don't have to do that though, we can compare the encrypted version rather than the original. We can just encrypt what the user typed in, then compare it to '3ksk2b' since if they typed in the right password, it will match! Now we never have to decrypt the password.

There are algorithms that help with this. They take an input, munge it up, and can never be decrypted by anyone. They're called hashing algorithms. Most well known of which is MD5 and SHA1.

So that's how you do it! Just never store the password, and ensure the application has no ability to decrypt the password and no hacker will be able to either. Do this. Always.

Hashing (in this way) is still susceptible to an attack called rainbow tables. Jeff Atwood wrote an excellent article on this. I won't get into it here as it's fairly technical, but you should watch out for it if your site can host personal info. Rainbow table attacks can not produce the original password (in general), so they are not as severe as plain-text password thefts.

One final note on passwords: If you are logging the GET and POST url parameters, make sure you remove passwords from log files. Rails, for example, will do this with its filtered log params automatically.

SQL Injection

In order to understand SQL injection, you need to know a bit of SQL. Imagine you were running a php sql command like this:

// This query is ignoring my previous section, but it's just an example

// Assume a request like /login?username=dickeytk&password=hunter2

// Get the user out of the database that matches the given username and password
$username = $_GET["username"];
$password = $_GET["password"];
$query  = "select * from users where user_name = '$username' and password = '$password';";

Looks great right! Sure does. It's going to run this query:

select * from users where user_name = 'dickeytk' and password = 'hunter2';

Alright so that's going to lookup the user's name, and the password in the database. All is well. Now, what if I wanted to be malicious and instead of 'hunter2' for the password, I typed 'hunter2' OR true; //'.

Hmm. I think the SQL query would instead look like this:

select * from users where user_name = 'dickeytk' and password = 'hunter2' OR true; \\';

Now it doesn't matter what the user typed in for their password since the logic will hit 'or true' and login any user. So even if the user's password is something totally different, they login just fine.

This is my favorite attack. It's just sort of fun.

So how can it be avoided? One way is escaping the quotes. Making it so you can't get out of a string inside a variable. In php, just wrap the variable in the mysql_real_escape_string function.

In modern frameworks, you can use parameterized queries. They work like this:

Bad ruby

Article.where("name = 'security'");

Good ruby

Article.where("name = ?", 'security');

Looks very similar, but is very different since the second one will not only escape the variable, but also execute it so that the query is ran with placeholders, that are filled in with another command.

You don't have to think and a SQL injection can never happen.

Cross-site scripting or XSS

XSS can also be fun. It is similar to SQL injection, but works with HTML instead of SQL.

If you allow users to input things that might be used on a page, they could potentially insert javascript, giving them basically total control over a page.

For example, if Facebook had a XSS vector in status updates, I might add a status update like this:

'I am creating an xss attack <script>alert('woo dickey is 1337');</script>'

Funny note: when I wrote this article I actually XSS'ed myself. I had a js alert popup saying 'woo dickey is 1337!'

Now all my friends getting my status update will have a javascript alert show up. You can get much more malicious though, by farming for password input fields and things.

It is the hardest of these to prevent. All the big sites have XSS attacks all the time. You need to ensure that user input is encoded into html when it is displayed, basically.

So when you take an input like a status update, and it's displayed on the page, you should escape <'s into < along with the other HTML you need to escape. Every programming language has a shorthand for this. Rails will do it automatically, unless you add 'html_safe' or 'raw' in your view.

So don't use those if it's straight user input you are displaying. Unless you REALLY trust your users. (but you don't, do you?)

On frameworks

Every web framework has tools built in to avoid these problems. It's a double edged sword. If you use Rails, for example, you will pretty much never run into these problems since the framework avoids many of them in its design. However, you will probably never learn about them either.

Using straight PHP and these are incredibly important and you need to be aware all the time. It means you need to watch out and always be thinking about them.

Obviously frameworks are better for this, but you still have to be aware fo these things.

CloudFlare review: not snake oil, but it feels like it

2011-11-30T00:00:00Z

CloudFlare review: not snake oil, but it feels like it

I had the opportunity to meet with John from CloudFlare in his office after writing this article. Read the follow-up after reading this.

I switched my blog over to use CloudFlare today. I'll be honest, most of the reason for trying it out was curiosity into what it was exactly. My site handled the load from being on the top of ycombinator on a single heroku dyno without wincing, so to be honest, CloudFlare couldn't have offered me much. It was a total curiosity decision, not a business one.

What is a CDN?

Skip this section if you already know.

I'm going to use the word 'CDN' a lot in this post. If you don't know what a CDN is, it's a caching service. Say you have a file on your site, like I have my css for this site right here: http://jeffdickey.info/assets/application.css

If you access my CDN (assets.jeffdickey.info) you download it through the CDN instead of my server: http://assets.jeffdickey.info/assets/application.css

Same file, it's just going through the CDN, the CDN gets the file from my server, then the CDN delivers that to you. If a lot of people are requesting the file at the same time, it just hangs onto it so my server doesn't get pinged.

And the CDN is a zillion times faster than my web server.

So it offloads the work of my server, scales limitlessly (practically speaking), and makes the site super fast. It's a win for everyone.

That's with Amazon's CloudFront (way too similar of a name) which is a much more traditional CDN, CloudFlare is different. So, onto my CloudFlare experience:

Now I recklessly reconfigured everything

What is CloudFlare? This was my big question. I watched their 5 minute intro video, and didn't learn a damn thing. It was pretty (I liked the evil devil dude!) but honestly, I didn't learn a thing. There was mention about the server going offline and the site staying live, spam prevention, SEO enhancement and other things, but I felt like they were offering all these great things without anything to back it up.

So then I had 2 options, either read some copy, or say "fuck it, we'll do it live". You can safely assume what I did next.

I had no clue what I was doing. It became clear to me though, that all CloudFlare really does is replace your DNS server. Then magic.

The setup process is insanely good. Easy signup form, you point CloudFlare to your current host, it finds all your DNS info, you just look through it, make sure it looks good, then you mark which ones you want 'CloudFlare optimized' (whatever that is) and change your nameservers over. It's so well done, anyone could do it.

I'm not sure I've ever had so much fun with setting up an architecture component in my life.

Alright, so hopefully I learned something

I got an email a few minutes later letting me know my nameservers had switched over. I reset my DNS, checked out my site, it was still running, and immediately was wondering what the hell I did.

My first worry was that it was going to cache all my html, resulting in outdated content. Would it cache my blog index for several days? What if I needed to edit an article? I wanted to know how the invalidation worked. I still don't know how invalidation works (if at all), but CloudFlare is different than most CDNs since it only cached some files (css, javascript and images). It does not cache your HTML. It can also process the css and js to minify them.

I think this is really where it differentiates itself from other CDNs. All the CDNs I know of you have to setup a different server, you can CNAME it so it's like assets.yourdomain.com, but you can't have the CDN and the content both running on the same host. The benefit here is that it's super easy to setup. You don't even have to think about it at all. The minification on top of that is huge. I remember I spent quite a bit of time working on the minification part of a build process for a major CMS. It kills me that kids these days can click a button to minify their shit.

After I did a bit of research, this whole thing was a freaking accident. That's hilarious.

There is a few other cool features, I really like how it shows me how much the CDN is actually saving me in bandwidth and things as well.

I think the best way to get an idea of the features is just linking my whole settings page.

Some of the cool ones:

It can munge the email addresses on a site so that email scrapers can't find them
Purty analytics showing how well the site and CloudFlare is doing
Can cache with or without querystring params (I don't think any other CDN does that)
Asynchronous javascript loading
Preloader can preload 200 of your most accessed content (requires paid account)
IP geolocation in the HTTP headers
Can warn you if google analytics isn't working correctly

Another big plus, there is 0 vendor lock-in here. You can easily migrate to any other CDN. Nothing I have done I feel like has been permanent to my project.

Downsides

CloudFlare won't help many sites with scaling issues. It helps with static files and front-end performance, but can't do anything to scale your application tier. That's okay, it's impossible for them to do that reliably anyways. If you're on a CDN and you're having scaling issues, CloudFlare will not help you.

I also feel super uncomfortable with this whole thing. There just feels like way too much magic for me. Everything about it just screams snake oil to me. It appears to not be snake oil, but something is off. It might be the loss of control, it might be the copy, it might be just that CloudFlare does so much for free. I'm not sure.

How does CloudFlare handle caching? I have the hash of my static content embedded in the filename, so invalidation isn't a problem for me, but what if I didn't? How and how long does it take to get a new version of a cached file? What exactly happens if my server goes down? I clicked a checkbox that will keep it up, but what the hell does that actually do? If the server 500's it shows an old version?

Will it work with S3? Maybe that's a specific question, but I'm still using CloudFront for my S3 assets.

Is it fast?

Too hard to tell. My site is already pretty freaking fast, and I was already using a CDN. CloudFlare is a good first CDN, because it's easy to configure. If you're on another one, I see no reason to come over to CloudFlare.

Looking at others tests, this seems to agree with what I said. Those that weren't on a CDN were amazed at how fast it made their site (well, duh) and those that were on a different CDN were disappointed at CloudFlare.

Who the hell are these 'big guys' and what 'tools' do they have?

This sort of bothers me, on CloudFlare's twitter, they state:

CloudFlare brings the performance and security tools previously reserved for the Internet giants to the rest of the web for free.

But what? I have no clue what performance and security tools they're even talking about here. I don't have much else to add to that, it just confuses me.

In short

CloudFlare works. I was really apprehensive about it at first. Although I think that I am not the target market, I think webmasters with less of a technical background would only be more apprehensive. It almost seems too good to be true. They say on their site though:

On average, a website on CloudFlare
- loads twice as fast
- uses 60% less bandwidth
- has 65% fewer requests
- is way more secure
All for free!

It's not snake oil. I bet you could even get better numbers than that on a popular site. We all know CDNs are great. I rarely setup any site where I don't use one. CloudFlare just found a way to let essentially anyone set one up. Then they throw on a couple more awesome features on top of that. There are some drawbacks, but the fact that it's... you know... free... and has absolutely no vendor lock-in, there is no reason I can think of you shouldn't use it.

To CloudFlare: Please put more of the 'how' in your copy. Could just be a link or something, but if you're going to say something is faster, or safer, or better, I'm never going to believe you until you can prove it.

EDIT: In editing this article, CloudFlare's site actually went down for me. Doesn't add a ton of reassurance for me, but my site is fine. They do claim 5 nines of availability. (99.999%)

I had the opportunity to meet with John from CloudFlare after this article. He cleared up a lot of questions for me. Here is a follow-up article to this one: http://jeffdickey.info/cloudfront-vs-cloudflare

Why I love making CMS's

2011-11-29T00:00:00Z

Why I love making CMS's

The most common application that I have built has been the good old fashioned content management system. This includes more than blogs though, I would argue that anything where a user can edit content without changing a codebase is a CMS. However, just off the top of my head, Jekyll is absolutely a CMS but still doesn't fit into that already generous bucket.

Let's focus on blogs for a bit though,

Blogs especially are fun to make

I like to get the most amount done with the least amount of work. I am a lazy developer. Writing a blog is obvious. If a client needs a blog I immediately know what I need to do, many things they might not even know about. Including:

Admin interface
Templating engine
Social plugins/interaction
Caching
Tagging
Related articles
Sorting
Archive sections
RSS/ATOM feeds
Sitemap.xml
Slug generation
Drafting method
Author functionality
Workflow
Commenting
SEO

Scale? Performance? Psh. That's easy mode software when it's a CMS.

I've architected the whole damn database by the time they said 'article'. Even though they might not even know what caching or a sitemap is, I've solved their problems without having to even encountered them or mentioned them.

It's a beautiful, rare time in architecture where you immediately know what to do.

This continues onto the development, which will be crazy fast.

So why not just use Wordpress?

Believe me, I'm the first guy to avoid coding and leveraging the community wherever possible. Wordpress is the right choice in many circumstances, as is Tumblr and a lot of other sites. However, while blogs and brochureware are generally a solved problem, CMS's are not.

The client also probably isn't get a hold of someone with my background if all they need is something as simple as Wordpress.

Why might a CMS not be a blog

Several reasons. I consider a blog to be an index showing articles in a reverse chronological order. Nothing more. Even this website I've made for myself is more. It has projects which I can edit. Those are absolutely nothing like a blog. It's just 'content to manage'.

Simple features break off-the-shelf CMS's

Maybe I want to link to GitHub and show my most recent commits for each article? Wordpress would be a particular pain in the ass for this, and Tumblr would be absolutely useless. In a custom CMS? Easy peasy.

Still though, I love this kind of development where I can leverage my existing knowledge of similar systems (CMS's in general) and focus on the specific feature at hand (GitHub integration).

Still, why do you 'love' making CMS's?

This is simple. I can easily make a platform, get a designer to make it purty (or half-ass it myself like I did here), then some writers create some awesome content!

From then on, it can be used for years without me having to lift a finger, yet I still feel like I was a part of creating each and every post!

memcache on Heroku's cedar stack in Rails 3.1

2011-11-28T00:00:00Z

memcache on Heroku's cedar stack in Rails 3.1

If you're building a Rails site, you almost definitely need to have caching. memcache is the best solution for that problem right now. It's not too hard, but there are only bits on the internet on how to do it.

Instructions

Install memcache addon

$ heroku addons:add memcache

Install memcache locally

$ sudo port install memcached         # for macports
$ brew install memcached              # for homebrew
$ sudo apt-get install memcached      # for ubuntu/debian

Put the 'dalli' gem into your Gemfile (this is the memcache driver) and run the 'bundle' command

# Gemfile
gem 'dalli'

In production.rb and development.rb, set the cache_store

# /config/environments/production.rb
config.cache_store = :dalli_store

# /config/environments/development.rb
config.cache_store = :dalli_store

Now change your session initializer (for memcache session support)

# config/initializers/session_store.rb
require 'action_dispatch/middleware/session/dalli_store'
YOURAPPNAMEHERE::Application.config.session_store :dalli_store

Now start caching things!

How this works

This works without setting any configuration since dalli will connect to the MEMCACHE_SERVERS environment variable, which gets set when you install the addon. If that environment variable is not present, it will connect to localhost (which works for development).

Dev environment troubleshooting

The most common error you will see is dalli not being able to connect. First, make sure that memcache is running. For that, I like to use telnet to connect to the local running memcache service. It's kinda fun too!

$ telnet 127.0.0.1 11211

Then you can do:

SET foo bar
GET foo

(should return bar)

Still running into problems?

I've ran into a problem on Vagrant and a Windows development installs where Dalli would not be able to find the local running memcache service. For that, I found that setting the host to '127.0.0.1' fixed the problem. I imagine it's something to do with IPv6, but I'm not sure.

So to fix, just do

$ export MEMCACHE_SERVERS=127.0.0.1

That worked for me!

node.js introduction

2011-11-26T00:00:00Z

node.js introduction

node.js is an event-driven web server written in javascript.

node.js is popular with big CS nerds. I had a very difficult time understanding exactly 'what it was' when I first heard about it. This is my attempt to explain it for those of us without a neckbeard.

Disclaimer: Some of what I'm saying in this article is not entirely true, I know. I'm over-simplifying how computers work to illustrate how node.js works, not explain how CPU schedulers work. That'd just be a snooze-fest anyways.

Why I'm trying out node.js

node.js is something that I've been very excited about. I've watched/read a lot of what Ryan Dahl and the rest of the community has said about node.js. It's my latest hammer.

node.js is an excellent tool if you want some kind of live interaction on a website. It is capable of very quickly delivering data to/from a web browser.

What could you do with that? Well, as an example, say you were building a CRM. You could have a feature where viewing a customer's profile could be updated live. So if a sales guy is on a call taking comments, another employee could be seeing the updates instantly. (No reloading of the page.)

Yes, this has been done before with ajax and things, but node.js does it much, much faster and better. Even the fastest Rails requests will be 10x what node.js can do.

My job is to use my knowledge of technical resources to solve problems. Node.js allows us to do neat things on web sites that so far really haven't been leveraged by anyone. It's very young and has tremendous potential.

I've also been working on a little toy with node.js. More on that in a later post.

node.js should be used if you want a specific piece of your web architecture to be live and/or super fast

It works well for that, but it doesn't have the same niceties of other web frameworks like rails, django, .net and everything else. It's not that it couldn't, just that it isn't the intent.

If you were building Facebook, for example, node.js would be good for updating the newsfeed when new status updates come in, but not great at much else.

Now, to explain HOW it works

So traditionally, there has always been a big problem with computers where the CPU can only do one thing at a time. It was solved long ago with multi-threading, allowing us to have multiple 'threads' on a single CPU.

So, to simplify, if you have 10 threads going on, a CPU scheduler will split up the CPU's time evenly between all of them so they get equal time slices. So maybe in 1 second, each of the 10 threads would get 100ms.

It switches between them all the time, and while it's pretty fast, the switching has a ton of overhead. I won't get into how, but let's say in my CS class when I learned this I was actually amazed that computers are even as close to as fast as they are.

Avoiding that overhead would be nice.

node.js is evented programming

This is the absolute core of node.js. It is not the fact it's server side javascript. It's a single threaded server that acts upon callbacks and never blocks on the main thread.

Why? Let me illustrate,

So, if you think of a blog cms engine, for example. A traditional web server looks like this:

Take in a request for the blog index
Call out to the db to get the blog articles
Build the html containing the blog articles
Send the response out

Node.js doesn't work any different here. It's under the hood where it's different.

Now, on the second step, (calling out to the db to get the blog articles), let's say that takes 100ms. Almost the entire time the thread is waiting for the db to come back with its response. We call this IO heavy.

However on the third, where the server is building HTML from the database's response, it's crunching that database's response and building HTML. It's quicker, around 10ms, but it's CPU intensive. It's not waiting on anyone, just crunching away. We call this CPU heavy.

Now earlier I mentioned the bit about splitting the CPU's time up between threads. If we have 1 thread where the CPU is crunching the HTML (CPU), and another where it's waiting on the DB (IO), the CPU could literally (and does) waste an entire time-slice switching into the IO thread.

node.js solves this problem by running in a single, event-driven thread

It takes control of deciding what work needs to be done, rather than having a scheduler try to figure it out.

Rather than have a new thread get created on each request, there is one thread for every single request. When a new one comes in, it fires an event that runs some code. VERY much like how jQuery works. When you make a call to a database, for example, rather than block until it's returned, you just run a callback function after the call is complete.

The difference isn't really in node.js itself, it is your code that ends up being different. It just heavily guides you into doing it the node.js way. You can do this with other languages, but javascript's syntax, and node's framework is really good for it.

Heavy IO applications benefit well from this, whereas CPU intensive applications will not.

However, most web development is IO intensive, so that's generally an OK tradeoff.

CarrierWave on Heroku with CloudFront

2011-11-25T00:00:00Z

CarrierWave on Heroku with CloudFront

This post will enable you to have your Rails app accept file uploads through a gem called CarrierWave. Optionally, you can use CloudFront in order to have a CDN backbone for those files. This is currently the best method for file uploading on Heroku.

For a full-fledged working project with this on Heroku's cedar stack, check out http://github.com/dickeytk/painting-gallery

Prerequisites

Go to S3 and get an AWS Access Key ID and an AWS Secret Access Key.
Create a new S3 bucket in the US East Availability Zone. (Since that's the same one that your Heroku dyno is already in)
If you want to use CloudFront, add a CloudFront distribution pointing to the S3 bucket you just created.

Instructions

Add the gems to your Gemfile

gem 'fog'
gem 'carrierwave'
gem 'rmagick' # optional, for image resizing support

Add the file './config/initializers/carrierwave.rb' for your CarrierWave configuration

# ./config/initializers/carrierwave.rb
CarrierWave.configure do |config|
  config.fog_credentials = {
    :provider => "AWS",
    :aws_access_key_id => ENV['AWS_ACCESS_KEY_ID'],
    :aws_secret_access_key => ENV['AWS_SECRET_ACCESS_KEY'],
  }
  config.fog_directory = ENV['S3_BUCKET']

  # use only one of the following 2 settings
  config.fog_host = "http://#{ENV['S3_BUCKET']}.s3.amazonaws.com" # for no cloudfront
  config.fog_host = ENV['S3_CDN'] # for cloudfront

end

Add your environment variables

$ heroku config:add AWS_ACCESS_KEY_ID=[your_access_key_here]
$ heroku config:add AWS_SECRET_ACCESS_KEY=[your_access_key_here]
$ heroku config:add S3_BUCKET=[your_s3_bucket]
$ heroku config:add S3_CDN=[your_cloudfront_url] # optional for cloudfront support

That's it! Should be configured now. All you need to do is add a string column to a model for the file name, a file uploader to add files to a model, and a form to actually accept the uploads. CarrierWave's docs explain how to do that all very well.

Using your own domain

If you want to use your own domain (such as content.jeffdickey.info like I use on this site) simply add a CNAME in your dns config pointing to the S3 bucket, then change the S3_CDN environment variable to point to it.

Optional CloudFront note

Now, if you are going to use CloudFront, you should add this bit to your uploader which will append a file's hash to the end of a filename. This is so CloudFront won't cache old content.

  # ./app/uploaders/image_uploader.rb
  # Appends hash to filename to prevent CloudFront from caching old content
  def filename
    if original_filename
      @hash ||= Digest::MD5.hexdigest(File.dirname(current_path))
      "#{file.basename.split('_').last}-#{@hash}.#{file.extension}"
    end
  end

Known issue

There is a potential issue to look out for here. Uploading files that will take >30 seconds will result in Heroku killing the request, so you need to directly upload the files. This S3 SWF upload plugin should help with that. But don't throw that on just 'because'. It's likely to just cause grief.

Summary

I hope this works out well for you! I've configured this type of setup several times now and seems to work great! I did it all from memory though, so let me know if you run into any issues.

Unix tips du jour

2011-11-24T00:00:00Z

Unix tips du jour

The thing about unix tools is they are incredibly hard to learn. Even if you understand a tool, you need to build it into your workflow, which takes serious time and experience. Here's just a quick intro into 2 simple ones, and one complex one for you to chew on:

fc

fc opens the last ran command in your text editor, then runs it after you save.

It's nice when you make a mistake.

ctrl-r

Search your last ran commands. Just try it.

rsync

This one is really scary.

You probably already know this one, it just syncs a remote directory. A great use-case for web developers is when you have a server up and running, and want to change say, an HTML file, you can use rsync on the folder and will update just what has changed.

It is complicated, but VERY good. If you have a server you want to attempt to update with local files (and if you're a web developer you probably do), YOU NEED THIS.

Spend 30 minutes reading the man page and you'll thank me later.

It's a bitch to learn and work into your workflow, and you won't understand the rsync string you wrote, but you'll be in love anyways.

Besides, you can always just fc your rsync command to save it as a script and you only need to make it once!

The Great Redis Misapprehension

2011-11-23T00:00:00Z

The Great Redis Misapprehension

Redis is NOT a database.

It's closer to memcache than mysql, for example. However, it's not a cache either.

This is the biggest point I want to drill in people's heads. For some reason, people seem to think it's a key-value store, or some persistent database, but that's totally not it at all.

I myself thought this, and had a tough time learning why it was useful since that was stuck in my head, so if you've been thinking it's persistent, get that OUT of your head now!

Redis is a data structure server

It's super low level things like lists, sets, and yes, key-value, but that's not the heart of it.

There's no one killer feature of Redis. The best way to learn its value is just to look through the docs at interesting things.

You sort of feel like a toddler playing building blocks, but these building blocks are freaking awesome.

It has some persistence support, but does not appear to be super durable. If you're thinking of using like that though, you're misunderstanding the tool.

EDIT: This comment on persistence has been met with much criticism from the community, so I will add to this: Redis can be configured to be a durable store. It is out of scope for this article, but the docs describe possible configurations very clearly: http://redis.io/topics/persistence

The following is 3 example use-cases for Redis

Leaderboards

If you're designing a leaderboard, you need to be using Redis. One of the few data types it supports is called 'sorted sets' and honestly, they should've just called the damn things 'leaderboards'.

It's pathetically easy to use. Say we're building Tetris, and we want to show a high score table.

Each time a user gets a score, use ZADD to add their score to the system:

ZADD highscores 1337 dickeytk
ZADD highscores 100 whatgoodisaroad

Now let's get the top 5 players using ZRANGEBYSCORE:

ZRANGEBYSCORE highscores -inf +inf WITHSCORES LIMIT 0 5

I don't even need to explain that. It's fast enough for you, in case you're a worry wort.

Check the docs for more information on sorted sets.

Queue

You can do some super simple queuing things with Redis. I mean dead simple too, literally one line of code in almost every programming language I would say.

It works just like you would expect.

Put something at the end of the queue:

RPUSH my_list 6

(RPUSH means 'push data onto the right side of the list')

Grab the next thing from the beginning of the list:

LPOP my_list
(LPOP means 'pop data from the left side of the list')

A common issue in web development though, is that your queue may not have anything in it! In which case it is often helpful to maybe do something like this:

data = None
while not data:
    data = redis.('LPOP', 'mylist')

Just loop until you get your data. However, there's a better way, using BLPOP. BLPOP is just a blocking version of LPOP:

data = redis.('BLPOP', 'mylist')

Which just blocks until it returns! Marinate on just how useful that is for a second.

A caching example!

EDIT: The community was very upset about this section in my post. I still maintain that it is a perfectly acceptable way to handle cache invalidation, however, if you are implementing this in a production system, you definitely need to read http://redis.io/commands/keys thoroughly. Still though, even if this isn't preferable for performance reasons, it's pretty cool!

Redis is pretty much a drop-in replacement for memcache. If you've used memcache, you probably have a caching pattern using keys like this:

post/83/body

post/83

or maybe like this

article:28:related_tags

Basically, you're namespacing the tags so they don't conflict. Good on you for that! Now, as you've probably noticed, invalidation is no easy task, since in memcache, you can delete post/83 but that won't delete post/83/body since it's just a string, memcache doesn't parse anything.

Now, this is where Redis comes in. You can find keys on wildcards! So you can just query it like so:

keys post/83*

And that will return all the keys you need to invalidate!

As tabbyjabby on ycombinator mentioned that Antirez (one of the creators of Redis) wrote a very good article on many of the same things I have discussed here: http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

The soapbox is open for business

2011-11-22T00:00:00Z

The soapbox is open for business

Muahaha. I am now a blogger. I suppose technically this isn't my first time blogging, but it's the first time I'm blogging about something that isn't what I had for breakfast.

I don't even eat breakfast anymore.

Now I get to share what beer I'm drinking! Racer 5, of course. But I digress.

Why am I blogging? Because I think I'm some sort of expert in my field with valuable information. It's ridiculous, I know.

What will I blog about? Mostly technical things, there's a few articles I've wanted to write for a while but just haven't had the platform to do it from, including:

My long overdue love letter to Heroku
A post, or series of posts, on useful unix commands (fc is a recent one that comes to mind)
A more personal note on why I'm a web developer
BEGINNER'S GUIDES! this is something I've wanted to do for a long time.
Angle brackets, and why I need to be able to control every damn one of those suckers

What's the end goal? 2 things really, I want to be a better writer, and I want to be more involved in the community. I want to write an article like this that really pisses people off haha

So I hope you enjoy the new blog! My goal right now is A POST A DAY! I know at least for a long time I'll definitely have some content.

dickey.xxx

After coaching a Rails Girls, I can finally answer the question "Why do I love programming?"

After coaching a Rails Girls, I can finally answer the question "Why do I love programming?"

Storytelling on your team

Storytelling on your team

Fostering a learning culture

Storytelling is natural

Get your team telling stories too!

Explain your product as a narrative

How to attend a hackathon

How to attend a hackathon

My background with hackathons

Different hackathon types

In-person (AngelHack, Startup Weekend, Disrupt)

Internal

Online (Rails Rumble, Node Knockout)

Who can attend a hackathon

Why attend a hackathon

The pitches

Finding your team

Refining the concept

Hacking

Demo time

Post-hackathon

The number one thing hackathons do wrong

Get out there and do it!

Does Rails scale?

Does Rails scale?

Twitter had to quit using it because Ruby is so slow

But Ruby is slow even in 1.9

None of this matters

Rails is not all roses

So yes, it does scale

Rails Rumble: ARSS

Rails Rumble: ARSS

The idea

The roles

The process

The first roadblock

End of the first day

Second day

The result

Want a demo?

Dev Bootcamp is the future of our industry

Dev Bootcamp is the future of our industry

Startup careers

My career

Enter Dev Bootcamp

My experience

The full-stack mindset

Willingness to branch out to unfamiliar territory

Excitement for hacking

I absolutely loved it

Imported lager is the uncanny valley of beer

Imported lager is the uncanny valley of beer

MySQL is done. It's the Postgres Age.

MySQL is done. It's the Postgres Age.

Has nosql failed?

The bad part of using Postgres for everything

More awesome Postgres shit

What about MySQL?

I want to use it!

Convergence in web development

Convergence in web development

A little history

Making a convergent system

Things that went well with backbone + rails

Templates make no sense

Scaffolding is insane

Testing didn't work

Serialization in Rails is broken

What to do?

Negativity on Rails

Negativity on Rails

Open source tools

Open source tools

Enterprise tools vs open source tools

On open source as a whole

Github

On Ruby