I’m going to take another break from writing technical articles and focus on something else I know very well. I was being interviewed last Friday about my work with The Heroin Epidemic Relief Organization (HERO) and the last question I was asked was “what do you want people to take away from this story”. That’s such a tough question to answer. Besides being far too vague and open-ended I really didn’t know what the reporter’s purpose in writing the story was either. I get that question a lot though and it always stumps me. Sure, the easy way to handle it would be with some trite, feel-good message like “don’t give up” or “anyone can do it” but I have to admit I really don’t believe either of those things, sadly. What I could speak to was the subject of identity. I’ve seen far too many addicts and their families during the course of my work that, besides the issue of the addict in their lives, all had the same problem – addicts and their families struggle with their identities when the addict decides they want something better for themselves. Families have a hard time knowing how to behave and the addict is sometimes set up for failure even when, technically, they’re doing everything right.

A couple years ago I picked up the habit of “doing the hard thing”, a practice where, basically, if you’re too tired, lazy, or think something is too difficult to do you do it anyway. From there, about a year ago (you can see the post in the archives), I decided it would be a good time to start doing the “scary things”. They may seem the same but they’re very different though hard and scary often overlap. The scary things are things you want to do but are afraid to for one reason or another. So how did all that work out? I can’t say the system was a total success but there was definitely a good amount of growth that came from it.

I wasn’t planning to upgrade to OS X Mavericks any time soon. I knew the upgrade would be worth it in some respects but I was fearful that my Mac would slow down and that I would end up paying $30 for an upgrade that added new features but negatively impacted performance. It turns out that this wasn’t the case at all! Mavericks, so far, is the best release of OS X since Snow Leopard in my opinion.

User Authorization is a common problem and there are tons of Gems for Rails apps out there that promise to take care of it. I’ve been researching how I was going to solve the problem for a few weeks now and came to the conclusion that a Gem isn’t necessary and in fact may even complicate things. I came across a great article on user authorization in Rails this week that describes a solution that I’ve adapted to suit my unique situation. If you’re looking for an easy way to implement user authorization from scratch this might be for you.

When you’re creating a user authentication system you want your usernames to be case-insensitive upon creation and on authentication too. Rails makes this super easy with its built-in validators and has_secure_password but it fails us when authenticating users. We want our passwords to be case-sensitive but we only care that users type in the right characters for their usernames and not whether they capitalized them the same way as when they signed up. I ran across this problem today and decided scopes are the way to go. There are plenty of suggestions on how to do case-insensitive searches out there but in the end all you need is a simple scope. Here’s how and why.

Updated: 10/20/2013 Updated with better working code samples

If you’re creating an API that you yourself are consuming through a pure front-end client (along the lines of how Twitter does it) you’ll probably end up needing to track user state – sessions, basically. RESTful APIs should not be keeping track of state but unfortunately this is often unavoidable. Here I’ll go over one way to manage user state for users using your front-end client and authenticating users accessing the API programmatically (using HTTP Basic, Digest, Token authentication or something similar). My experience with this is Rails-centric as I’m rebuilding my favorite project as a pure (mostly) RESTful back-end API with a front-end API consuming client. For this particular use case you probably want to avoid reading and writing from the database as much as possible. I’ve been wanting to try out Redis for a while now and this use case has given me a perfect opportunity for that. Here’s one way to manage the state and authentication of users in a Rails app using Redis instead of a traditional session or database solution.

The Rails Guides has a great list of HTTP status codes you can throw in your Rails app. Too bad I can never find it. So I’m reposting it here for myself and whoever comes across it from a Google search. Thanks to this blog which I have blatantly copied from. Read on for the complete list.

In working with Ruby on the new Write.app API, I’ve come across a number of problems related to using it as a pure RESTful API server rather than a full web app with views. Because the new Write.app is an API server only it comes with some challenges and troubleshooting common issues becomes a bit harder sometimes. In this case I had a problem with POST’ing JSON data to a controller which accepted nested attributes and getting a ‘No implicit conversion from symbol to integer’ error in return. Turns out it was a simple mistake with a very simple solution that trips up a lot of developers.

I mentioned a million times by now that the new Write.app is being written in Ruby. Ruby is fucking amazing if you’re coming from languages like PHP or Java on the backend. There are so many ways to write your code, the code is so much easier to understand, and its overall a very pleasant experience. One of the cool things about Ruby syntax is the ||= assignment operator. It took me a while to wrap my head around it so I’m posting it here for future reference for myself and whoever else wants to use it.

(Post updated 10/10/2013 – See addendum at bottom of post) Lately I’ve been working a lot with client side JavaScript applications using Angular as a front-end framework. After being exposed to this way of developing web I truly believe client-side apps are the future of web development. There are a lot of advantages of using the single-page/client-side model for web apps but they also come with a few big problems, not least of which is security. There are surprisingly very few answers to the question of how to secure API keys in a JavaScript app. Since it’s so difficult to find an answer to this question online I decided I’d share with you how I’m securing API calls made from a client side Angular app.