Way back in 2011, I wrote a blog post showing how to Run Tests from MacVim via Terminal.app or iTerm.app. I’ve been using that setup for years without a problem, but when iTerm2 Version 3 was released, it stopped working. I’ve updated the AppleScript and am posting it here for anyone who wants to run tests in iTerm2 (Version 3) while writing code in Vim.
It seems that on every Rails project I work on, I end up writing utility scripts that make changes to the production data in some way or another. Perhaps it’s pre-loading hundreds of user accounts for a customer that wants to provide a spreadsheet of users, or populating an account with fake data that can be used for a demo, or manually fixing a data integration issue with an external system. Often, this requires parsing and processing a source file (like a CSV file). Read more on Code Generation for Rails Utility Scripts…
Heroku provides a convenient command line interface for executing snippets of Ruby code remotely. One-liners can easily be piped into the
heroku run console command. But what about much longer scripts that you write locally and want to execute in a remote Heroku environment? In this post, I’ll show you how to execute a long Ruby/Rails script in a remote Heroku environment.
Recently, I had to deal with a command line process that was occasionally hanging during my project’s continuous integration test suite. I decided to write a wrapper script that would watch the output of the wrapped process. If it didn’t see a particular bit of output after some period of time, it would kill the process and try again. To limit the dependencies needed in the CI environment, I decided to write this wrapper script in Bash.
I recently attended elm-conf (videos of the elm-conf presentations), which was hosted at Strange Loop on its preconference day. I’d been meaning to play around with Elm for years and was finally sparked to do so to prepare for the conference. Read more on Chaining HTTP Requests in Elm – An Example…
Earlier this year, Ryan Abel wrote about Managing Multiple Releases in a Production Application. One of the strategies he discussed was using “feature flags” to manage when sets of features are released in production. I’ve found that feature flags work well when there’s a need to maintain backward compatibility with multiple versions of an external integration. In my case, it’s with a Bluetooth Low Energy (BLE) device, but the same would hold true for a remote web service API, etc.
As a long-time developer at Atomic Object, I’ve had many opportunities to work with developers who were new to pair programming. Whether pairing with senior developers who’ve been working solo for their entire careers, or with a new hire straight out of college, I’ve run into almost the exact same situation every time.
For the last three and a half years, every single command I’ve run from the command line on my MacBook Pro has been logged to a set of log files.
Uncompressed, these files take up 16 MB of disk space on my laptop. But the return I’ve gotten on that small investment is immense. Being able to go back and find any command you’ve run in the past is so valuable, and it’s so easy to configure, you should definitely set it up today. I’m going to share how to do this so you can take advantage of it as well.
My team recently added a RecyclerView to a screen in an Android app we’re working on. It’s a horizontal view that allows a user to scroll left and right to see content that’s offscreen. One of the challenges we’ve faced while working on this view has been testing it in our Espresso tests—specifically, testing the contents of items at certain positions. In this post, I’ll show you an Espresso matcher that can be used to aid in testing RecyclerViews.
Read more on Espresso – Testing RecyclerViews at Specific Positions…
I recently spent some time working through ways to automate running an Android test suite on my MacBook Pro. I found helpful bits and pieces all over the place—from Stack Overflow answers to blog posts talking about how to get Android into various CI servers (Travis, Jenkins, etc.)—but the information was scattered. In this post, I’m going to document what I learned while writing an Android test script.