Android Development: First Impressions

As a web application developer working in a company full of mobile app developers with a mobile focus and as a full time Android user, there’s a natural gravity in my universe toward mobile apps and the power of the app plus server backend paradigm. Naturally, I wanted to build my own app and really see what it is like on the other side of the API.

As with any new platform, language or environment, I read up extensively on the Android ecosystem, poured over countless resources on design princiles and best practices—NOT. I jumped right in. Since I was shopping for a new car at the time, I whipped up a quick and dirty Car Payment Calculator. I mostly wanted to see the whole process of building an app and deploying it to the Anroid market. I must say the process is extremely simple and straightforward. However, the car payment app doesn’t really do anything…


Read on →

Commit Message Starters

As I’ve been working in git and crafting my commits with rebase working toward creating pull requests which are easy to read, review, and comment, I’ve been noticing myself fall into habits of naming commit messages similarly which contain code to acheive similar ends. Further, when I struggle to find the correct words for a commit message, it’s often easier to being with a familiar word to get things flowing.

Over the past few months, I’ve also had the pleasure of working with some great developers. As such, I’ve been afforded the opportunity to review a lot of their code. If there is one thing I recommend to all developers, from novice to expert, it’s read code. Your own, your friend’s, strangers, projects you admire, anything you can get your hands on. Not only will it enlighten you to how others write code, new coding patterns and syntax, but it will empower you to be able to figure out how the code you use works and how to fix it.

As a quick aside, I was able recently to dig into the Ruby source code, even into the C, to discover exaclty what was happening with Range bracket operator access on an empty Array. It felt great to be able to see how Ruby herself was implemented and know exactly why my code worked; to go beyond “well, it worked in irb so it must be correct.”

The great thing about reviewing pull requests is that I am able to open discussions with the authors and inquire as to why they made certain decisions and what their motiviations were for writing certain code. Also, it gave me a chance to see code which was not polished and final. Thereby, recognizing anti-patterns and less than best practices.

Coming back to the topic of this post. These anti-patterns and less than best- practices extend to commit messages as well. Below I’ve listed some of the dos and don’ts which I have started to use in my everyday committing.

Read on →
git

Better Pull Requests With Git –autosquash

UPDATE (Jun 7, 2013): I created an ascii.io video demo of autosquash for your viewing pleasure.

Pull requests are an extremly crucial part of our workflow at Mobile Defense. We pride ourselves on producing quality code and we do not subscribe to the git-blame “I didn’t write it” culture. We all take responsibility for all the code we produce, as a team. As such, being able to review our code efficiently and thoroughly before it gets into master is a goal we are constantly looking to improve upon.

A somewhat paradox in reviewing code arises when the need for reviewers to see the updates based on their feedback quickly and efficiently and for the developer to be able to ‘fixup’ their branch before merging to ensure the code enters master as cleanly as possible. That’s where git-rebase comes in.

Rebase is an extremely powerful tool in the git toolbelt. Combine commits, edit commits in-place, rewrite history, etc. It’s especially great for cleaning up your topic branches before submitting for code review. However, remembering which commits need to be squashed into which can be tricky especially when being the reviewee and the reviewer on multiple pull requests daily. Well, it turns out git already has a really clever, built-in way to organize and automate the branch cleanup process. It is perfectly suited for making changes based on pull request feedback. It’s called autosquash.

Read on →

Oh My! What Large Hot Fixes You Have.

We’ve all been there: just finished a nice new feature, deployed it out to production only to find that you’ve completely overlooked an edge case or use case which is now totally breaking your app. Sometimes you have to push a big hot fix. It has to get in immediately. It can’t wait for writing correct tests or other better abstractions and implementations. What to do? What to do?

Read on →
git

Zeus Gem Error: “Panic: Runtime Error: Invalid Memory Address or Nil Pointer Dereference”

I was getting this error and the excellent Zeus rails environment loader gem was crashing making it a huge bummer to dev.

Luckily, I found a fix in one of the open issues on the project.

It was easy to fix, just run a bundle install to add the missing gems:

$ bundle install

Easy as that. Hope this helps someone else!

— Chris

Help! I Lost a Commit From Days Ago!!!

Oh no! I’m screwed! Better try to remember what work I did and recreate it… :( J/K! This is git! Of course there’s a slick way to recover what you lost. Here’s my situation: I was working on a feature branch happily coding away. Finished the feature, rebased it quickly to fix a typo and then merged it into master. All’s well in my world. However, that was days ago and today I just realized that I accidentally removed one of my commits from the feature branch while I was working on it. No worries. Here’s how I got the commit back with relative ease.

Read on →

SuperBowl Commercial Bingo Card Generator

Everybody loves the SuperBowl commercials! Last year, I hacked up a script to randomly generate items to create your own bingo cards. This year, I improved the script to actually generate the cards as a PDF file based on an excel sheet of bingo items.

Read on →