If you’ve had a bit of experience in the Ruby programming language, you know the importance of gems in your work. Like the plugins that came before them, gems are mini-pieces of code used to perform specific duties without interfering with or becoming a direct part of your code. The code required for a gem is still part of your project’s ecosystem, but you’ve removed some overhead (and duplication) by using the gem instead of coding it up yourself.

So what happens when you have a piece of code that might be broken out to stand alone? What if that code might actually be helpful to others? It’s time to build a gem.

Getting started is easy and will use tools you already have installed in your environment, most likely. Your first step is to get bundler installed.

$ gem install bundler

Once bundler is installed, we are ready to start the gem making process. Before actually writing anything or creating a sandbox to work with, we need to do one of the most difficult things in all of programming: naming things. Our gem should have a name that describes what it does, is easy to remember, and (hopefully) hasn’t been used before. To check on names of gems, check out the search function of Rubygems.org - this may also bring you to a gem with the same functionality and save you some work in the long run.

For our example we are going to write a gem called sleepr - it will be used to point out when people using our app are doing so after hours and should just go to sleep. Not very useful, but great for our example as it will be pretty simple. Let’s get started!

For JavaScript developers, it can be hard to keep up to date with the latest frameworks and libraries. It seems like every day there's a new something.js to check out. The build process is no exception, so it's worth re-evaluating your options every now and then.

My build process toolset has traditionally been comprised of RequireJS for dependency loading, and Grunt. They've worked great, but recently I was pairing with someone who prefers to use Gulp and Browserify instead. After using them on a couple of projects, I'm coming to like them quite a bit. They're great for use with Backbone, Angular, Ember, React, and my own hand-rolled JavaScript projects.

In this post, we'll explore how to set up a client-side JavaScript project for success using Gulp and Browserify.

Defining the Project Structure

For the purposes of this post, we'll pretend we're building an app called Car Finder, that helps you remember where you parked your car. If you want to follow along, check out the code on GitHub.

When building a full application that includes both an API server and a client-side JavaScript app, there's a certain project structure that I've found often works well for me. I like to put my client-side app in a folder called client, one level down from the root of my project. This folder usually has sibling folders named server, test, public, and build. Here's how this would look for Car Finder:

The idea is to do our app developent inside of client, then use a build task to compile the JS and copy it to the build folder, where it will be minified, uglified, and copied to public to be served by the backend.

Two factor authentication (2FA) is becoming more and more important when it comes to securing your cloud assets. 2FA increases security by requiring that the user has access to two separate components. For example, something you know (e.g. a password) and something you have (e.g. a phone or token generator).

If you are concerned about different cloud services, and would like to enroll in 2FA in as many places as possible, visit TwoFactorAuth.org. They do a great job tracking different cloud companies and the availability of 2FA.

As you can see, Engine Yard is listed as having having 2FA available.

Engine Yard is committed to security and we continually do everything we can to ensure all environments are secure. We have increased security measures regarding system access and physical security for our staff around the globe.

This is why we offer 2FA on our platform. If you are an existing customer and you would like to have it enabled, visit our Development Center.

If you have questions about security procedures or controls in place at Engine Yard, please do not hesitate to contact support via the ticketing system or in the #engineyard channel on Freenode.

Testing is a vital part of any development process. Whether a project's authors are hoping for scalability, fewer bugs, or just code that stands the test of time, a solid test suite is essential.

It's all well and good writing tests, but how do you know that you've tested the code that matters? Did you cover the most important components? Did you test the sad path? The edge cases? What about the zero states?

Using Istanbul, you can generate a nice coverage report to answer these questions. In this article, we'll look at how to get it set up in a typical client-side JS project.