Happy New Year! So much has changed for me over the past few months, I’m really not sure where to start.

Last year I wrote a series of blog posts about landing a new job as a programmer. I covered setting up your LinkedIn and Github profiles, updating your resume, writing portfolio code, etc. I even interviewed a few friends about their experiences. I had plans to turn this into a book. (I still think this will happen.) This series of posts should have made it obvious to anyone what was on my mind.

I’ve never really been a fan of online advertising (is anyone really?), but around the beginning of last year I had grown completely disillusioned with it. I read so many articles and listened to so many podcasts about just how bad things were getting. As a result of this, I was honestly doing a terrible job at work. I kept telling myself that it was just a job. The people were great, the pay was good. But in the end, I just couldn’t do it.

I signed up for a couple of the tech job matching services and things basically exploded. I interviewed with around 25 different companies. I started with a single idea: I want to work on a product that people pay for with money, not attention or engagement. As I talked to more companies, another idea started to seem possible: I want to work full-time remote. Those two requests narrowed the field and in the end I accepted a position as a Software Engineer at Braintree.

The new job is great. I’m back to writing code every day. I’m part of a smart, helpful team. I’m learning new things all the time. I pair program every day. I’m doing more backend / infrastructure work than ever before. In addition to Ruby, I’m also writing Java (and actually enjoying it) and working with things like Docker, Puppet, and Kubernetes. And the best part is, my commute has gone from around 2 hours per day round trip to however long it takes me to walk from the bedroom to the office.

Over the course of interviewing for a coding job, you’ll be required to prove that you actually know how to write code. This is usually by solving a problem of some kind. This might be a take-home challenge, a pair-programming exercise, or even (shudder) coding on a whiteboard. Obviously, you’ll want to practice these kinds of problems.

Many of the problems used in interviews can be found online in the form of a code kata. The name code kata comes from the kata in martial arts. In martial arts this involves practicing a set of moves repeatedly until they become like a reflex. Here’s the definition of a code kata on Wikipedia:

an exercise in programming which helps programmers hone their skills through practice and repetition.

I’m not really happy with that definition. To me, a code kata is different in that you shouldn’t repeat the same problem. Instead, solve a variety of challenges to build your problem-solving and coding skills. Of course, if you aren’t happy with a solution, refactor it or even start over, but I feel like the biggest gain comes from solving a many different problems.

Coding

So, where do you find these problems? Here are a few websites I’ve used in the past:

Project Euler has hundreds of challenging mathematical and computer programming problems. If you work your way through this list, you’ll be ready for anything. Many of these will be too difficult for a beginning programmer.

CodeKata is a site by PragDave (aka Dave Thomas of the Pragmatic Programmers). According to Wikipedia, Dave Thomas was probably the first person to use the term code kata. This site has a collection of 21 challenges.

Exercism has a collection of practice problems in over 30 different programming languages. If you only visit one site on this list, start here. After you submit your solution, you can see other users solutions and give and receive feedback.

Refactoring

The sites above involve solving a problem of some kind, but The Gilded Rose kata is all about refactoring. You’re given a program and asked to add a feature. Unfortunately, the program is poorly written and has no tests. Rather than just add the new feature, you’re expected to also clean up the program.

Now that your LinkedIn profile is looking good, use the information it contains to write your resume. A resume is not strictly required since most companies are happy with just a LinkedIn profile, but it never hurts to have one.

There are many fancy resume templates available online, but I recommend something clean and simple. I follow a format similar to the way my LinkedIn is setup.

Header

First, put your name at the top in large text. I used Microsoft Word’s Title style, a 28-point font. Under your name, put your LinkedIn address and contact information. Include at least your email address and phone number. Finally, finish off the first section with your summary statement. Here’s mine:

Experience

Add a heading, then list your experience. Put your job title in bold, followed by the company name and dates of employment. For your most recent roles, give 3-5 bullet points with the things you do as part of your job. Also include a list of technologies used in case someone is just scanning for keywords.

If you don’t have a lot of professional experience, include volunteer work or personal / freelance projects here. This is especially important if you’re seeking your first job as a software engineer. If you’re looking for a coding job, but your only experience is driving for Uber, then your resume isn’t really helping.

If you have a lot of experience, list fewer and fewer details for older jobs. For past positions maybe only list technologies used. For jobs that aren’t relevant to the position you’re currently seeking, only list the title, company, and dates. You might even leave these off assuming it wouldn’t look like a gap in employment.

Education

Finish up your resume with information about your education. List your college degree if you have one. List the bootcamp you attended and/or any online classes you’ve completed.

If you haven’t done any of these things, just leave this section off. I would avoid doing something clever like “graduate of the school of life.” Some hiring managers might think that’s cute, but others will probably discard your resume.

Done

I make no mention of skills other than as part of my employment history. I don’t see the need for a big block of skills. Anyone can type a list of programming languages, show me what you really know by listing some experience.

I also don’t mention references. Everyone knows you’ll provide references on request, so why bother taking up space on your resume? Many companies don’t even ask for references anymore.

My resume is just under two pages long. Many people will tell you that your resume should fit on a single page. I don’t see how that’s possible for someone with a few different jobs and some education. List everything you need and don’t worry about the length.

Finally, export your resume as a PDF. I don’t usually print my resume unless I’m going for an in-person interview. In that case, I print a few copies and stash them in my bag in case someone asks for it. So far no one has ever asked for a hard copy, but better safe than sorry.

The first thing I look at when someone applies for an engineering job is their LinkedIn profile. Even before I look at their resume. To me, there are two big benefits to going straight to LinkedIn:

I can easily see how we’re connected. Do we know people in common? Maybe you used to work somewhere I used to work. Maybe you met someone I know in a user group. This connection could tell me what you’re really capable of, even if you aren’t good at selling yourself.

It’s in a standard format. You can customize your profile page a little, but for the most part they all look the same. I know where to find your experience and education without thinking. It’s easy to quickly scan the page and get a sense of where you’ve been.

Intro

The first section is called the intro. As I said in my post about your GitHub profile, put a current, recognizable picture of yourself here. Next, add a headline consisting of your current job title and employer.

If you aren’t currently working, or aren’t working in technology, I would be a little more creative here. Are you doing any freelance work, writing, or teaching? If nothing else, write something like “Aspiring Software Engineer.”

Finally, add your summary. This is basically your elevator pitch. Think of one or two sentences that quickly tell an employer what you can do.

Experience & Education

The experience section can be a challenge for someone seeking their first coding job. How can you list experience when you don’t have any? Obviously, you can’t. If you’re currently working outside of the technology world, you should list your job. Even if it’s barista at Starbucks.

Once you land your first technical job remove your earlier experience, unless you can make a compelling case for how it might make you more attractive to a future employer. For example, if you had management experience in a previous, non-technical job, you might want to keep that on your profile.

Include a few sentences or bullet points describing what you accomplished at each of your previous jobs. If you aren’t sure what to write or how to word your accomplishments, try looking at job postings for similar jobs. Recruiters work hard getting the wording just right on their postings. Reuse their work.

You can also add volunteer experience in this section. Many organizations need help building or updating their web site. You can also volunteer to teach coding or other skills in your free time. Code.org is always looking for programmers to volunteer to teach coding to kids in the classroom.

The education section should be straight-forward. If you have a college degree, list it here along with your major field of study. Similarly, if you attended a coding bootcamp, list it here. You can also include relevant online courses such as those at Udemy,Coursera, or freeCodeCamp.

Skills & Endorsements

List skills such as programming languages and frameworks, industry knowledge, and interpersonal skills in this section. If you have demonstrated these skills to other people, ask them to endorse you. An endorsement from someone tells me that you truly have the listed skill.

Recommendations

Personal recommendations can be hard to get. Give recommendations and hope that the recipient will recommend you in turn. I would also directly ask for recommendations from managers and coworkers. Just be aware that asking for a recommendation on LinkedIn can be interpreted as a sign that you’re looking for a new job.

Accomplishments

Use the accomplishments section to highlight things like publications you’ve written, awards you’ve earned, or special projects you’ve completed. This can be a great way to fill out your profile if you don’t have a lot of experience yet. Also, include any foreign languages you speak here.

As a follow up to my previous post, I thought I would walk through the basic web app I built using Go, Gin, and GORM. I realize this might not be the most idiomatic Go program, but I was going for simplicity and brevity.

The Code

Every Go application starts with a package definition. Since this program is an executable and not a library, call this package main. This tells the compiler that the main function, where execution starts, is found here.

package main

Next, import libraries needed by the program. In this case gin and gorm, as mentioned earlier, as well as the GORM postgres driver. The program needs godotenv and os for loading environment variables and finally net/http which defines HTTP status codes.

Now that the environment is loaded, use the DATABASE_URL variable to connect to the database. Again, panic if there is an error. The defer statement calls dB.Close() when this function ends to close the database connection.

A recent project at work required a high performance API and a light-weight front end. I’ve been looking for an opportunity to explore other languages and frameworks and this seemed like a perfect opportunity. We already have a few services written in Go, so I decided to start there.

The Go Programming Language is a “fast, statically typed, compiled language.” In other words, very different from Ruby (which is dynamically typed and interpreted). In Ruby, everything is an object; Go doesn’t have classes. Yes, very different.

Web

With my choice of programming language set, it was time to find a web framework. After a bit of Googling, I came upon Gin. It promises “performance and productivity” which is exactly what I needed.

Gin features a very fast router for processing requests as well as easy rendering of responses in JSON or HTML. Gin uses the html/template package for rendering dynamic HTML pages (also see text/template for complete documentation).

Database

The next step was database access. I typically work with Active Record, so I started searching for something similar. GORM is an ORM Library in Go. It is full-featured (almost) and developer friendly. Its API is similar to Active Record and it supports all of the features I need including a PostgreSQL driver.

Creating models is easy using GORM. Define the model as a Go struct and include gorm.Model to add ID and timestamp columns. Then pass the model to db.AutoMigrate and GORM will create a table with the required columns automagically. The migration doc has examples of automatic and manual migrations.

Miscellaneous

Since I plan on eventually deploying this application to Heroku, and Heroku uses an environment variable for the DATABASE_URL, I’m also using the Go port of Ruby’s dotenv project named godotenv to load environment variables in development.

Sample App

I posted a complete sample application named goweb on GitHub. Feel free to clone that repo as a starting point for your own creations. The README file includes instructions for setting everything up on a Mac with Homebrew.

If you haven’t heard of Dwitter.net, its creators describe it like this:

Dwitter.net is a challenge to see what awesomeness you can create when limited to only 140 characters of javascript and a canvas.

I would also say that it’s a great way to kill a few spare minutes during the day. It’s fun and you’ll probably learn something in the process. I wrote code this morning while enjoying a cappuccino.

If you’re interested in JavaScript, go to my first dweet to see the 76 characters that make this work. Also, check out my Dwitter.net profile for future creations. Hopefully my next dweet will be a little more colorful.

It seems like I’m always looking for new creative outlets, but rarely finding them. There are plenty of things I want to do — working on one of my writing projects, coding creative programs, etc. But it seems like I never have the time.

I know that lack of time isn’t really the problem. I just haven’t prioritized creative outlets and developed a habit. A great way to build a habit is to try to do something for an extended period of time and make yourself publicity accountable.

With that in mind, I was happy to come across the fifth annual The 100 Day Project, a “free, global art project that anyone can participate in.” Starting April 3rd, create something every day and post it on Instagram with the hashtag #The100DayProject.

I have a few ideas of things I want to work on, but no where near one hundred. They say “It’s okay if you miss a day! Keep going.” So that’s what I’ll do. Most of my “art” is writing, and I’m not really sure how that’s going to translate to Instagram, but it should be fun.

I hope to keep up around weekly blog posts here and work on some unannounced projects, too. Who knows, maybe in a hundred days I’ll be able to announce something new?

GitHub recently introduced security alerts for Ruby and JavaScript applications. If they see that your application has dependencies with known security vulnerabilities, they will notify you.

New security vulnerabilities are discovered all the time, so it’s important that you keep your application and its dependencies up-to-date. I have first-hand experience with these alerts. Here’s what it looks like and how to fix any issues.

Notification

As you probably know, I wrote the book Rails Crash Course which was published back in October 2014. This book included two sample applications which are hosted on GitHub. Being over 3 years old, these applications now have outdated dependencies with known security vulnerabilities.

As promised, GitHub let me know about these vulnerabilities. First I received an email like this:

The email continues on for a total of 8 Ruby gems with known security vulnerabilities. Visiting the GitHub repo for this app, I’m greeted with this message:

Note that only the owner of the repo or other who have been specifically assigned access to vulnerability alerts can see this message. Otherwise, it would be easy for attackers to locate vulnerable applications.

Resolution

Looking over the listed vulnerable dependencies, I notice that all of the gems appear to be part of Rails. With that in mind, I’ll first update Rails.

Checking the application‘s Gemfile, I see that it’s using a fixed version of Rails. In this case the Gemfile is explicitly installing version 4.1.7. The security alert email recommends changing this to ~> 4.1.14.1.

The tilde followed by a greater than ~> forms an arrow that means to install a version of Rails matching all but the last digit in the given number. In this case, it means to install version 4.1.14.n, where n is any number greater than or equal to 1.

This way you can install security updates, while continuing to use the known good 4.1 version. Later versions, such as 5.2, may not be compatible with the application as written. Upgrading a Rails application to a new major version may require code changes and is a post for another day.

After updating the Gemfile, run the command bin/bundle update rails. This will take a few minutes as bundler resolves dependencies then downloads and installs the newer version of Rails. Once that’s complete, make sure the application still runs.

Not Quite Done

In a perfect world, this would be the end of this blog post. Unfortunately, Rails 4.1.14.1 also has a known security vulnerability. After pushing this change to GitHub, it recommended upgrading to version 4.2.5.1.

Of course, Rails 4.2.5.1 also has a known security vulnerability. This required an upgrade to Rails 4.2.7.1. GitHub also pointed out a security vulnerability in the version of the jquery-rails gem I was using. On their recommendation, I upgraded it to version ~> 3.1.3. And with that, I was done.

You can see the changes in the commit named Rails Security Update on GitHub. If you used a later version of Rails when you worked through the book you may not need these changes. Also, these instructions were only tested on Mac OS X. Users on Linux or Windows may need to make adjustments.

I usually try to avoid meta posts, that is blog posts about blogging, but I thought this might be interesting to others looking to setup their own site. A blog can really help when you’re looking for a job as a programmer. I speak from experience.

My Blogging Workflow

In a previous post I talked about switching to Jekyll so I could write my blog posts in Markdown and keep my site on Github. That was nice, but lately I’ve been spending more and more time writing in Ulysses.

I started using Ulysses around the time of NaNoWriMo. With Ulysses I still write in Markdown and I can write on my laptop, iPad, or iPhone. In Ulysses it’s easy to organize my writing and the iCloud synchronization makes everything available everywhere.

Ulysses even has built in support for publishing to Medium and WordPress. I like to own my content so, as the title suggests, I switched my site back to WordPress.

That’s a screenshot of a small part of my Ulysses library on my iPhone in Dark Mode. I have a folder named Blog and sub folders for Drafts and Posted posts.

Now whenever I come up with an idea for a blog post, I can quickly create a sheet for it. Then when I have some free time I can work on the post on any of my devices. Once it’s ready, I can publish to my site. Even from my iPhone, like I’m doing right now.