At Sittercity we primarily use Go and Ruby to develop our applications, including our new product, Chime. In this very technical article (don’t say I didn’t warn you!) I talk about an advanced Ruby topic, metaprogramming. If you already have a solid knowledge of Ruby but want to better understand how the language works and learn a few metaprogramming tricks, then this article is for you.

When they hear the word “metaprogramming”, many Ruby developers think that it is some mysterious, hard to understand and therefore dangerous thing that is irrelevant to their daily work, while not realizing that they may already be using some of its concepts in their code. Part of the confusion is that in Ruby there is no clear boundary between metaprogramming and “doing normal things that normal people do,” given how dynamic the language is. But there is really no reason to be “afraid” of metaprogramming in general: many of its concepts are straightforward, and even those that are harder to wrap your head around have a well thought out system behind them.

I had the opportunity to go to Smashing Conference in San Fransisco. It was a great experience and would highly recommend anyone interested in front-end technology to attend. At Sittercity, we are asked to write or present what we learned at a conference. I found Alla Kholmatova’s talk on Atoms, Modules, and Other Fancy Particles to be the most interesting because it could be beneficial to our new product, Chime.

Kholmatova works for a company called FutureLearn. It is a massive, open online course learning platform. They derive their design thinking from Brad Frost’s Atomic Design. Atomic Design is a methodology for creating effective design systems by utilizing reusable components. These components can be broken down to Atoms, Molecules, Organisms, Templates, and Pages.

So far, 2016 has been a great year. Our small, but rockstar, QA team has been making huge strides towards improving automated regression suites across all of our projects. We have tackled the endless QA dilemma regarding automation, how to do it effectively and efficiently. There are always obstacles when automating any app. For example, let’s say you have a new release and bug fixes ready to ship. How will you ensure that the new bug fix(es) have not introduced any new issues in previous working functionality? Manually testing all of the functionality of an application for every single fix or new feature is an option when a project is just starting. However, as a project grows, large manual test regression plans are daunting and in my opinion a red flag. With larger regression plans you might be able to accomplish it, but then you are not going to be testing effectively in terms of company cost, resources, time, etc. More and more companies are trying to move toward continuous delivery, making a need for QA automation.

Like most technology outfits we have work that we would like to perform ‘off-cycle’. This just means that we don’t want make a customer wait for a particular task that is not critical for their experience at that moment. This is a very normal problem and there are many solutions out there in the world, so many in fact that it would take forever to list them all.

At Sittercity we have a handful of existing solutions. Our main platform has traditionally been something we call Stormtrooper. This is a custom, homegrown library written in Ruby and backed by RabbitMQ. It works pretty well but we have intermittently experienced issues with lost messages and ballooning memory usage. As we have grown we have come to realize that it just wasn’t cutting it anymore. We would need to look for a new solution.

As a woman in technology I want to speak to women. I want to speak not from a position of weakness, but from a position of possibility. I want to speak to any of you who at some point believed that their possibilities were limited. I want to tell you, “You can make IT happen.”