Products

Customers

About

Resources

Relocation & HR Trends

John Wood

Lead a team of software engineers and quality assurance engineers in building out a self service employee relocation application. Perform product research to analyze the problems our customers face with relocation, and design and develop solutions to help solve those problems. Strongly encourage and enforce software development best practices amongst the team (TDD, code reviews, SOLID design, continuous integration, etc). Pair with members of the team help them tackle tough problems, or to explain certain aspects of the application. Mentor engineers at all levels to ensure they are on a trajectory to reach their career goals, and grow as engineers. Participate in the design, coding, and testing of the application, along side the rest of the team. Help build the necessary software development processes to keep the team running smoothly and communicating effectively. Work with employees outside of the product team to effectively communicate what we are working on, and when it will be delivered. Actively recruit engineers who would be a great addition to the team.

Recent Posts

ActiveRecord validations are a very powerful tool. They allow you clearly and concisely declare rules for your model that must be met in order for any instance of that model to be considered “valid”. And using them gives you all sorts of nifty error handling and reporting out of the box.

Our deployment process at UrbanBound has matured considerably over the past year. In this blog post, I’d like to describe how we moved from prescribed deployment windows with downtime, to a deploy-when-ready process that could be executed at any point in time.

Feature specs are great for making sure that a web application works from end to end. But feature specs are code, and like all other code, the specs must be readable and maintainable if you are to get a return on your investment. Those who have worked with large Capybara test suites know that they can quickly become a stew of CSS selectors. It can make the tests difficult to read and maintain if CSS selectors are sprinkled around through the suite. This is even more problematic if the name of the CSS selector doesn’t accurately reflect what the element actually is or does.

In a previous post, I wrote about how the proper use of Capybara’s APIs can dramatically cut back on the number of flaky/slow tests in your test suite. But, there are several other things you can do to further reduce the number of flaky/slow tests, and also debug flaky tests when you encounter them.

A good suite of reliable feature/acceptance tests is a very valuable thing to have. It can also be incredibly difficult to create. Test suites that are driven by tools like Selenium or Poltergeist are usually known for being slow and flaky. And, flaky/erratic tests can cause a team to lose confidence in their test suite, and question the value of the specs as a whole. However, much of this slowness and flakiness is due to test authors not making use of the proper Capybara APIs in their tests, or by overusing calls to sleep to get around race conditions.

Testing is a very large part of how we build UrbanBound. We test at various phases in our software development lifecycle, and we have tests that target different levels of the application’s stack. Testing reassures us that the application will behave as we expect it to, ensures that it continues to behave as we expect it to as we change it, and catches problems early, making them easier and cheaper to fix.

The ability to work remotely is a tremendous benefit. There is certainly something to be said about getting everybody in the same physical space. Great things happen when a bunch of slightly over-caffeinated engineers pile into a conference room with a whiteboard and a collection of multi-colored dry erase markers. And pairing is certainly most effective when your pair is right next to you. However, there is also something to be said for giving people the option to work where they feel they are most productive, or the option to be more involved with their families. Remote work also opens the door to work with talented people outside of your geographic area.

I’ve always thought that Migrations were one of Rails’ best features. In one of the very first projects I worked on as a n00b software engineer straight out of college, schema and data migrations were a very large, and painful, part of that project’s deployment process. Being able to specify how the schema should change, and being able to check in those changes along with the code that depends on those changes, was a huge step forward. The ability to specify those changes in an easy to understand DSL, and having the ability to run arbitrary code in the migration to help make those changes, was simply icing on the cake.

These days companies have a lot of choices when it comes to where to host their web applications. Not only are there many different providers to choose from, there are many different types of hosting to choose from. Do you need the raw performance of running on bare metal? Do you need total customization or control of your environment? Or, do you simply need to deploy your application somewhere, and let somebody else manage all of the finer details?