When working on projects with multiple developers following a feature branching workflow, you can end up with a lot of branch laying around. I’ve been trying to optimize my branch cleanup workflow for a while now and had a big breakthrough recently.Read on →
Recently I’ve been dabling in Go. I was lured in by the lore of a purposefully
simple language with amazing concurrency features. While that is true, I have to
admit that I stayed around for the documentation. Golang.org
has a this great Tour which walks you through the
basics of the language through interactive examples and exercises. Secondly, the
godoc command has a
--server flag which spins up essentially a local copy of
golang.org but the docs pages also include any locale packages you have pulled
down, or that you’ve developed. Ok, enough gushing about Go documentation.
The end of the tour talks about concurrency and has some exercises to help you learn by doing. I found this method very compelling and came up with two different methods for handling concurrency in Go; each suited for slightly different use cases.Read on →
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 →
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 →
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
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 →
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 →