A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.
I use Chrome extensions all the time and decided it was time to figure out how to make my own. I found it to be incredibly easy and I’d like to share with you some of the basics, as well as an example of an extension I made. Let’s get started!
To get a better handle on Erlang’s behavior, I decided to install a popular set of tools for debugging and performance profiling: EPER. I think it stands for “Erlang PERformance tools”, but it could also mean “Everything Proves Erlang Rules” or “Egrets Prefer to Eat Robots” or really anything for that matter. One thing is for certain, however: getting these tools built and running on Mac OS X was fraught with danger and build errors.
Positioning an element on a web page can be tricky. You can specify the position of an element using left, right, top and bottom properties. But these properties will not work if the position value is not properly set. The positioning properties also display differently depending on the positioning value.
In case you haven’t yet heard of it yet, Elixir is a functional programming language (technically, a collection of macros) written in Erlang. I have been persuaded to add it to my (and, consequently, Grio’s) technical repertoire due to a good amount of recent buzz in the blogosphere (as well as some points I’ll get to later). To make sure I have a strong foundation for my Elixir learning experience, I am starting my adventure with a foray into the underlying syntax of Erlang.
Continuous Integration at Grio
In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.
For years developers (and consequently consumers), have had to accept the fact that the Tablets (and some phones) would always have the System/Navigation Bar visible on their screens. A 10.1 inch advertised screens, offered in fact a 9.8 inch usable screen.
Finally Google’s latest Android OS, KitKat, introduces a decent user-friendly tool that gives us ownership of that last bit of screen.
As one would expect with a fine product, it would work best right out of the box. In the case of Android Studio, some assembly is required. The issue I found was that a newly created project with default settings wouldn’t compile. I thought that this bug might have been specific to my setup, but after reproducing it on 3 different computers and finding several outstanding questions as well as a few open bugs with Google concerning the issue, I decided that a fix would be a fine thing to write up, hoping it enables other people to develop as painlessly as possible.
With the release of iOS 7, there are several changes in how you lay out and customize the appearance of your UI. In particular, the status bar is now transparent, and your views will show through it. Now this is a great opportunity to redesign your app and take advantage of this new look and feel, but what if you aren’t ready and you want to the old iOS 6 status bar back? Well, I’m excited to tell you that there is a way to do this!