JakeOnRails

RSS
Apr 3

A Postgres Gotcha: NULL != ‘a string’ == NULL

Comparing NULL columns to any string value does not return FALSE, it returns NULL and those rows will not participate in your result set.

postgres=# select null != ‘a string’;

 ?column?

(1 row)

postgres=# select ” != ‘a string’;

 ?column?

t (1 row)

What does this mean?

If you have a record where a column value is nil/NULL, and you try to do a != “some string” constraint on that column, it will not be in your result set.

Make sure you have defaults for your columns, and you aren’t leaving them blank! Even if a default is an empty string, this one weird behavior makes it worth having something there.

How I learned to program as a kid

I started teaching myself how to program when I was 12 years old. That was around 16 years ago now. Since I didn’t have a teacher, and I loved to read, I borrowed a programming book and read it from cover to cover. This is probably not how you learned to program, or how you try to learn a new language.

But something happened for me, which was probably one of the most amazing moments of my programming career, and also one of the experiences that cemented for me that I was meant to write code.

After reading the book once (I think it was Sam’s Teach Yourself QBasic), I went to my computer and started trying some of the examples. I could type one in verbatim and generate the correct output, but when I tried to write my own code I just didn’t get it.

So, I read the book again. And once more, I still did not understand nor have control over the language. So I started to read the book for what would be the final time.

Somewhere in the section about looping, I had an epiphany. Something fell into place, and I understood that single concept with amazing clarity. I rushed to my computer, and typed out some original code - and it worked!

What happened next is the event that has kept me at programming all these years. Suddenly, in a way very akin to Neo’s revelation at the end of The Matrix, almost all of the concepts I’d been reading about in the book started to make sense. Whoah!

Now I started to write code that used all of those concepts together, and it worked! For me, this was such a mind-jolt. Grokking most of the concepts that had been plaguing me for the previous 3 or 4 weeks, all in one sitting, was (and has to this day) been the single most amazing learning experience of my life.

Migrating from Postgres 9.0/Postgis 1.5 to Postgres 9.2/Postgis 2.0 on Heroku

Since Tumblr’s Markdown syntax is just dreadful (GFMD for everyone!), I’ve instead linked to a public gist with these instructions. Enjoy and please comment if you have any feedback:

Instructions on my Gist at Github

1600% Faster App Requests with Rails on Heroku

> Using rainbows! and em-http-request resulted in a 1600% performance increase compared to using unicorn and net_http. (For the use case described below)

This is geared towards apps that have a lot of external requests to third party APIs, (like Facebook apps)but it looks like a useful trick to have in your hat.

by DOMMMEL via Coderwall

How to Improve Rails Application Performance on Heroku

If you’re looking for ways to improve your application’s performance on Heroku, first make sure you are measuring performance and looking for ways to optimize your application. If your application’s memory footprint allows, consider using Unicorn to double, triple or maybe even quadruple the number of requests your web dynos can handle.

From Big Nerd Ranch

Your Commit Log Should Be Your Repository’s Blog Engine

I’m pretty sure we’ve all seen commit messages that give absolutely no context or useful, actionable information to the reader, like the following:

  • fixes from CR
  • fixing back button css
  • back button for mobile
  • removing location for spec
  • overriding redirect to
  • adding rake task
  • capitalizing PID

I recently set up a deploy hook that emails the business team on my project with a list of the commits that are new in the latest release.

After reading the summaries our commit logs were generating, and trying to parse them through the eyes of a non-programmer, intimately familiar with the codebase, I realized that we were missing an opportunity to better document our code. Not just by writing good comments or documentation, but by using the idea of a commit log as a blog to explain the thinking behind various code changes. Answering questions like:

  • What is the business value of this code change?
  • If this is a bug fix, how was the bug expressed and how does this code fix it?
  • What future concerns, technical debt, or considerations should developers who work on this code in the future be aware of?

Wherefore, I began to write more “human friendly” commit message summaries, that I feel convey more meaning:

  • Upgrade rails and json gems due to security vulnerabilities
  • Return the LDP overlay delay to 3 seconds
  • Use double quotes for HTML attributes
  • Monitor scheduled jobs with NewRelic

First, notice that these summaries are much easier to read through the eyes of a non-programmer. They convey value and intent, whereas a code specific commit message does not.

Second, these commit summaries are not the entire commit message. These are just the first lines. In the case of the “Return the LDP overlay delay to 3 seconds” summary, the body of the commit message goes on to explain that the “LDP (Listing detail page) had a better conversion rate after A/B testing various delays on when an overlay would appear”.

Take this commit message, for example:

Monitor scheduled jobs with NewRelic

Use newrelic-rake gem to get exception reporting/performance metrics on rake tasks. Several background rake tasks fail occasionally but we don’t have error reporting for these jobs in NewRelic. By adding NewRelic reporting to all rake tasks, we’ll be able to better troubleshoot these scheduled jobs.

In this case, code change was just adding the newrelic-rake gem to the project. Prior to writing more meaningful commit messages, I might have just said “added newrelic-rake gem”. That doesn’t really help the reader at all, unless they already know what that gem does.

When used this way, commit log is a tool to give information about context, motivation, business value, and overall intent of the code changes, instead of just summarizing the change to the code itself. Now the next time someone runs git blame on my code, they won’t just see a summary of the code change, but they’ll see why the code change was made.

Next time you are composing a commit message, think about why you are committing that code, and try to convey that reason to the coder who comes after you, along with the other non-code context that is important to the work you are doing!

Mar 8

Search a Git Repo Like a Ninja

Wow, there are some really handy tips for searching your project’s git repo in this post by Travis Jeffery.

Mar 7

What kind of a software engineer do you want to be known as?

Nicholas C. Zakas writes about how to be a better software developer by “Review Driven Development” (my name for it), where you decide what you want to hear in your next annual review and make it happen.

Mar 7

Programming is an Art

Ruben Verborgh shares some thoughts on how to write elegant, artful code, by first understanding a problem, and only then writing the code to solve it.

Mar 7

Learning Ruby on Rails is Hard

Recently there was a semi-inflammatory post about how one new Ruby on Rails developer has grown to “hate Rails” because he was “lied to” about how easy it is to learn to build web applications with Rails.

Unfortunately, learning Ruby on Rails is hard.

That should be rephrased:

Learning to build web applications is hard.

Ruby on Rails is a tool to build web applications, and like most tools, it requires effort and dedication to learn.

When one sets out to learn how to build web applications on the Ruby on Rails track, they may not realize how much “other stuff” they need to know in order to succeed.

In order to build a modern web application, one must know at a minimum the following:

  • HTML
  • CSS
  • Javascript
  • A server-side programming language (PHP/Python/Ruby/etc…)
  • Usually some web application framework (Django/Ruby on Rails/CakePHP)
  • A database programming language (MySQL/Postgresql/etc…)
  • How to deploy a web application and possibly configure a web server (Heroku/Capistrano)

In order to build something more complex than a basic blogging application, one will likely need to delve into the following:

  • Source control (SVN/Git)
  • Third party libraries (Eggs/RubyGems)
  • Test driven development tools (Rspec/Test::Unit)
  • Caching (Memcached/Redis)
  • Third party APIs (Twilio/Google Maps/Facebook)
  • Authentication Libraries/standards (Oauth)

To learn each one of these items from scratch would likely take a person months or possibly years unless it was their sole focus or they have someone who will invest in teaching them.

Even after spending months or years learning these things, one could hardly call themselves an expert. Most or all of these technologies are in a constant state of flux, adding and removing features and specifications. By the time one has learned any one of these technologies, it is likely that there are new things about that technology left to learn.

This is a good thing! Learning is fun, and that is one of the big reasons that the profession of web application development is so rewarding.

The fact remains, though, that learning Ruby on Rails, or rather, learning web application development, is a long, hard road, and those who embark on it should not expect instant gratification if they want to truly master the framework and the process.