Everyday Vim – A Basic Vim Commands Cheat Sheet

Vim is a pretty great text editor, but learning to use it effectively can be a challenge. Even if you keep a quick-reference card or cheatsheet around, it can be difficult to figure out which commands are the most useful. But the truth is, Vim can still be super helpful if all you know is a few commands. So I’ve compiled a few of the Vim commands that I use every day. Read more on Everyday Vim – A Basic Vim Commands Cheat Sheet…

CoreLocation in the Wild: Experiments in Monitoring More than 20 iBeacon Regions

On a recent project, we were using iBeacons and Core Location monitoring and ranging to track a user’s location in an indoor space. iBeacons are placed around the space and each iBeacon maps to a real world room or area like “conference room” and “entry area.”

We had a simplifying assumption that beacons, Core Location regions, and real-world regions have a one-to-one-to-one relationship. We were pretty happy with how well it was reporting locations with up to 20 beacon regions, but “Core Location limits to 20 the number of regions that may be simultaneously monitored by a single app.” So we needed to engineer a way around this limit in order to track more than 20 distinct locations in our system. Read more on CoreLocation in the Wild: Experiments in Monitoring More than 20 iBeacon Regions…

“Owning It” Every Step of the Way

Building custom software is costly, complicated, and sometimes emotional. A well-executed project must hew to a fine line to navigate many constraints successfully, threading the needle between cost, timing, purpose, user needs, technical constraints, maintainability, extensibility, and operational considerations.

An idea for a product is just the beginning. To find success, you need a broad view of what’s important, the willingness to proactively go above and beyond, and careful planning. We call this collection of attributes “owning it”—personally investing ourselves in the success of our projects and seeing them through to success. Read more on “Owning It” Every Step of the Way…

Why Estimate Bugs and Chores in Your Backlog?

When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.

In general, we classify backlog items into three buckets:

  • Features (new or enhancements)
  • Chores (dev work not resulting in tangible product changes)
  • Bugs (fixing unexpected behavior or regressions)

Read more on Why Estimate Bugs and Chores in Your Backlog?…

Espresso – Testing RecyclerViews at Specific Positions

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…

Three Great Talks at Next Month’s GLSEC 2016

This year’s Great Lakes Software Excellence Conference (GLSEC) will be held Monday, May 16 at GVSU’s Eberhard Center in downtown Grand Rapids. This year’s theme is The Mobile Movement.

GLSEC will have fifteen talks this year, spread across three rooms. I won’t be able to attend all of them, but there are three I’d be especially bummed to miss. Read more on Three Great Talks at Next Month’s GLSEC 2016…

Introducing a 6th Atomic Value: “Think Long-Term”

We’re expanding our company values to include “Think Long-Term.”

Articulating our values is a team effort. Read Carl’s post “Company culture maintenance: Adding a 6th Atomic value” to learn how we got here.

Following through on our values is also a team effort. I wanted to know how Atoms defined “Think Long-Term,” so I asked them. Below are some of their answers. Read more on Introducing a 6th Atomic Value: “Think Long-Term”…

Retrying Network Requests in Ember.js: Part 2

This is the second post in a series of two that cover capturing, storing, and retrying network requests using Ember and Ember Data. In the first post, I discussed how to intercept HTTP requests and store those requests in local storage. In this post, I will cover how to retrieve them from local storage and retry them.
Read more on Retrying Network Requests in Ember.js: Part 2…

Retrying Network Requests in Ember.js: Part 1

My team is currently working on an application to help students learn how to conduct experiments. The app is an Ember.js frontend supported by a Rails API backend. Since the application is used in schools where Internet connectivity is spotty at best, we needed a way to support dropping off the network periodically. I think we came up with a pretty cool solution that I’ll explain at a high level in a series of posts. This post will cover how we stored requests in local storage. Read more on Retrying Network Requests in Ember.js: Part 1…

How to Pick the Perfect Code Sample for Your Next Job Application

Last month, I reviewed a lot of applications for our summer internship program. The interview process for interns is essentially a more brief version of our developer interview process, and during both we ask for a code sample (shared via jsfiddle or gist) that is representative of the applicant’s problem-solving ability.

Read more on How to Pick the Perfect Code Sample for Your Next Job Application…

loading…