I had the privilege of attending this year’s San Francisco Smashing Conference in early April where I listened to presentations from founders, designers, and front-end developers.
Smashing Magazine is a fantastic online resource for professional designers and developers. They also publish their own books and e-books, as well as host conferences in the U.S. and Europe.
Due to the recent increase of personnel at Grio, it emerged the need of having an automated way of setting up new employers’ machines.
Starting with a brand new machine is always a pain for a developer, and setting it takes at least a couple of days if not the whole first week, resulting in big waste of valuable time. Besides, when a developer starts on a new technology it is not always clear which tools are suggested and which ones the rest of the team are using. Therefore, I have been asked to work as a side project on a way to solve such issues.
In a previous blog post, I covered the “textbook” definition of continuous integration, along with a handful of tools and practices that fulfill or help to fulfill said definition. These tools and practices include breaking up your app into components (e.g. front-end and back-end, or, for much larger projects, using microservices), utilizing “watch” utilities locally to iteratively run tests, and choosing test-oriented frameworks (e.g. Rails, Django, Grails, etc.). However, I didn’t talk much about any specific continuous integration setup, nor some of the third-party services that go together to make an efficient release process. I also didn’t talk much about how continuous integration fits into the larger cycle of deployment and release management. I aim to cover some of those topics here, and fill in the larger picture of how CI helps to ensure code quality and stability in a software project.
As part of my exploration of a minimum set of devops tools, I’ve been learning how to stack containers full of Rails apps onto the Docker. There are plenty of examples of how to get started with Rails and Postgres on Docker, even one from the whale’s mouth, as it were. Working from this example, it was pretty clear to me that one of Docker’s major strengths is that it makes it really, really easy to get something running with a minimum of fuss; it took all of about a half day to learn enough Docker to hoist anchor, and even tweak a few things to my liking. One thing kept nagging me about the Docker example, though, and that was a warning from bundler when running docker-compose.
Software Engineering is about more than just writing code. It is a complex process that has a lot of moving parts. Requirements gathering, planning, testing, deployment and source control management are just a few of the pieces to the software engineering puzzle. So how do we manage all this complexity? Software methodologies come to the rescue.
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.