Chris W Jones

Hobbiest Programmer

I found a great group of people this week at Unallocated Space []!

I went to their weekly web dev night. I had a great time learning how to build a Drupal module. I can't wait to return next week.

With the holiday weekend last weekend, I was finally able to program some on Bibliophilium which as you may recall is the library managing site that I'm working on.

I spent most of the weekend getting logins working and getting the hosting to work. I feel so behind because I don't work with heroku [] on a regular basis.

There is quite literally nothing to look at on the staging site [] but rails is chugging away in the background.

UPDATE (5/18/2015): Here are my config files []

I've talked before [] about how my favorite programming editor is Sublime Text. Just because I have a favorite though doesn't mean that I always get to use it. Today's post is about my second favorite text editor.

Vim is my backup text editor. I like it because

  • it's installed everywhere
  • its commands are very powerful
  • it's crazy customizable
  • and the plugins

To the first point, vim is always installed when I first log into a new terminal. Sometimes other, simpler editors like nano [] aren't. If not vim then at least vi which is close enough for most of my work. It works great at the command line too since I don't always have access to a full-on graphical interface.

The commands in vim have a long and infamous history. You run a command like :s/hi/bye/g to swap text around. To save and exit, you type :wq. And if you're not expecting it, the differences between the modes will get you every time. You'll think you're in insert mode and start typing away only to discover that you're in command mode and you've just accidentally created 10 documents, deleted 5 and written gibberish in the first. If it seems like I'm complaining, I'm not. It's more like teasing a sibling. For all its quirks, vim is amazing.

If it's quirkiness annoys you, most of it can be changed through customizing your .vimrc file. For example, I hate that the default key to exit insert mode is escape. On most of my keyboards, I feel like Richard Nixon's secretary making that stretch. In my .vimrc file, I always override the escape key and set the sequence jj to exit out of insert mode. Changing command sequences is only one of many options that can be changed in the file. You can turn line numbers on, change the status bar around, tell vim how to handle mouse interaction, wrap your lines at a certain point and a ton of others. The main point is that if there is something you don't like about vim, you can probably change it in your .vimrc.

Unfortunately, you can't change everything in your .vimrc. It's great for changing already existing capabilities but it can't substantially change the way vim functions. For that, we turn to plugins. Plugins extend the capabilities of vim. For example, if you want to see a file tree while your programming so you can easily open files, there's a plugin for that (NERD tree []).

If you want to align all the equal signs in a block of code, there's a plugin for that (Tabular []).

There are plugins that do all sorts of neat things that save time and keystrokes.

Although it can be intimidating to learn, once you have the basics down, vim can be a powerful ally. It's ubiquity, extensibility, and general kick-assery put it ahead of its (console-based) opponents.

This weeks article is going to be about a blog that I consider to be a mentor. That blog is Giant Robots Smashing Into Other Giant Robots []. It is written by different people at the company thoughtbot [].

I really like this blog. Out of all of the resources that I have on the internet for programming, I turn to it first. They develop mainly in Ruby on Rails which is what I mainly use too. They also share pretty much every step of their development process.

They write books documenting their best practices as well as new techniques. I am actually reading through their new employee handbook because I find it interesting to see how they develop new software. Obviously since I program as a team of one, a lot of their team processes don't make sense for me. But I still read them because I think they will come in handy when I start looking for a job as a programmer.

They don't just write books and blogs though. They also write and release code on github []. High quality code that is used by a lot of people. I actually started using one of their projects before I realized it was a project of theirs. I started using factory girl [] in my tests because I find it easier to use in rails than fixtures.

So tl;dr for this post is that Thoughtbot rocks!

At work, I hang out in a chat room with other programmers. We mainly tell bad jokes all day but I was tipped off to a really fun programming exercise game. It's called Elevator Saga [].

The point of the game is to program a set of elevators to efficiently go from floor to floor, picking up and dropping off passengers. And if you're wondering how exactly you program an elevator, the designers have created an API [] for controlling the elevators

There are different objectives for different levels. Sometimes you need to move X amount of passengers in Y amount of time. On other levels, your elevator can only make Z moves. I spent an evening tinkering around on it. Even though I don't know a ton of javascript, it was easy enough to pick up on. Give it a try!

Here's the code that I have which I liberally borrowed:

I've learned a lot about programming over the years. I started learning programming with HTML which is the language of the web. Through the years, I have found a bunch of great resources for learning. This post is dedicated to my current sources of information.

My favorite blog that I read these days is called Giant Robots Smashing into Other Giant Robots []. It's written by a company of programmers. They work Monday thru Thursday and help others on Friday. Writing the blog is one way they help. The provide insight into their current best practices as well as new techniques they are developing. Just this week, I have read several of their blog posts relating to testing Ruby on Rails applications. These guys rock!

The next blog up that I read regularly is called RubyFlow []. It is a firehose of information. It collects blog posts about Ruby and publishes links to them. It's how I stay up-to-date on the Ruby world.

The final blog that I'm going to mention is called Coding Horror []. It's sometimes related to programming and sometimes it's about general software development culture. I enjoy the style of it and I also read it because Jeff Atwood is a mammoth figure in the development world. He co-created the website Stack Overflow.

Wrapping this up, I'm going to mention a podcast that I listen to. It's called the Ruby On Rails podcast [] (super original). This is a relatively long podcast that publishes about bi-weekly. I enjoy it because they will interview developers of major projects. Like for example in this last episode, he interviewed a developer working.

This week I'm doing the obligatory post about the tools that I use to program. Let's start out with the tools I use:

  • Sublime Text
  • Linux Virtual Machine
  • Git
  • rvm

With those, I can conquer anything thrown my way.

I'm a recent convert to Sublime Text []. Before that, I mainly used Notepad++. I love it's speed mainly. Using Notepad++ with a lot of files in a project causes it to move deathly slow. I've yet to notice a slow down in Sublime Text. In addition, I enjoy the robust plugin support and the theming support.

As linux virtual machines go, I keep one running at Digital Ocean []. Nothing too massive but one that I use for my development. I keep my development directory in sync with it using a VPN. Developing on Windows sucks. I never know when a package won't run correctly or if there is some weird quirk for installing it. It's so much easier to just develop in *nix.

Git [], how I love thee. Git is the version control system that I use. I've poked around with Subversion and mercurial too just so that I know them. My work has been saved more than once because I checked it into the git repository. Git tracks the changes to the files and allows me to move between versions of the files. So awesome.

Finally, rvm [] for Ruby development. Using rvm, I can easily manage the version of ruby intalled in my development environment. I find it super useful when I'm working on other projects. When they are using an older version of ruby for some reason, rvm gracefully switches to their version so that I'm developing like them.

That's all for this week, I hope you enjoyed it!

Boy, this one is late. I blame moving. Hilary and I finally got the keys to our new place and have started moving in. Last time I wrote about programming, I discussed APIs. In this post, I want to continue in the same theme and discuss implementing an API in a Rails application.

Rails has a great, simple way to output standard JSON instead of an HTML document.

class FlashcardsController < ApplicationController def index render json: Deck.all end end

That block of code would output all of the Decks in the database as a JSON object. The problem is that it doesn't give you much control over it. What if you had a relation where each deck hasmany: cards? That controller wouldn't give you any indication about it. That's where a handy gem called activemodelserializers [] comes in. Active model serializers gives you very fine control over what is output in JSON.

The way it works is you create a file in the serializers directory for each model. Then you can define exactly which attributes are output as JSON as well as how they're output. This is what a simple AMS looks like for a model Deck(id: number, title:string, public: boolean, card_id: number).

class DeckSerializer < ActiveModel::Serializer embed :ids attributes :id, :title

has_many :cards end

The attribute line specifies which parts of the model to expose in your API. The has_many line tells AMS to expose that there decks and cards are related. The neat part of this is the embed :ids line. Taking that line out AMS will include the cards that are associated with the deck in the JSON response. With that line in, AMS will simply give you the ids instead of the whole card object.

I love using AMS for creating JSON responses. Next week I'll combine what I talked about APIs with AMS and Grape.

I was planning on writing another post about creating an API but I'm exhausted. This weekend Hilary and I moved our worldly possesions into some U-Haul U-Boxes []. We finished moving out of our apartment today and as of 2pm, we're officially homeless for a week until our new townhome is available.

With all this flurry of activity, I just don't have it in me to write a blog post about how to create an API for a website using the Grape gem. Check back next week for a new article!

Part 1 in my series on creating an API in Rails. Here's part 2 [/52in52/api/2015/04/01/using-grape-api/].

This week, I have been working hard to add an API to a website that I wrote. I'm going to explain what an API is and why I want one for this website.

When you visit a website, your browser uses a protocol called HTTP. HTTP is made up of verbs that describe interactions with the server. When you visit, your browser uses the HTTP verb GET because you want to “get” the page. When you log in to a website, your browser uses the verb POST like you're mailing the data to the server. There are a bunch of other verbs used as well but I'm not going to get into them. After doing a GET request, the server located at responds with the page you requested, its response will look something like:


Believe it or not, that response is hard for a computer to read. The difficulty comes from the fact that anything can be in between those tags. It could be a picture of a cat or it could be the entire text of the Iliad. Computers don't do so well with that much ambiguity which is why developers use APIs. APIs are the computer's interface to a website.

When designing an API, developers think about what kinds of information that users will want to use from their site. For example in my Bibliophilum website, I might have an API endpoint that allows users to request the books in their library. Another endpoint might allow users to see which books are currently loaned from their library. When a user wants the list of their books, they'll do a GET request to that endpoint and the server will respond with something that a computer can understand like:

[ { id: 1, title: “Moby Dick”, author: “Herman Melville” }, { id: 2, title: “Accelerando”, author: “Charles Stross” } ]

The format of the response from the server is usually documented and doesn't change. This allows the computer using the API to understand the data received.

I really wanted to develop an API for this website because of a new trend in web development. This trend is towards using a single page to serve the whole website and requesting the different pages in the background. Gmail is a good example of a single page application (SPA) like this.

In the traditional client/server architecture, your browser sends a GET request to my server. My server responds with the page. You click the link which sends another GET request for that page which my server responds with. In the SPA architecture, your browser sends a GET request for my main page. After that, when you click a link on the page the page rewrites itself to be the new page, requesting additional data from the server as needed.

The main benefit of using this SPA is that the processing power my server would use to generate the page is offloaded to your browser saving me bandwidth and electricity. The API comes into this when the SPA requests additional data as needed. It needs to be able to understand the data so it queries the API.

That is an overview of what APIs are and one way that they're used. Next week, I'm going to explore a specific way to implement an API in Rails using a gem called Grape.