Setting Up A Client-Side JavaScript Project With Gulp And Browserify

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:

|- build
|- client
   |- less
|- public
   |- javascripts
   |- stylesheets
|- server
|- test

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.

Read More

Engine Yard’s Two Factor Authentication

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).

Many previous data breaches could have been easily avoided if the target company used 2FA. Last year JPMorgan Chase was attacked, as were Tablooa and Forbes. Later it was disclosed that JPMorgan Chase’s data breach fiasco could have been avoided if they implemented 2FA. The same can be said about Tablooa and Forbes.

If you are concerned about different cloud services, and would like to enroll in 2FA in as many places as possible, visit 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.

Learn about Engine Yard
Try Engine Yard for your Ruby or PHP Apps

Measuring Client-Side JavaScript Test Coverage With Istanbul

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.

Read More

Query Caching with PHP & MySQLnd

While MySQL has a query cache built in, it has several big problems:

Pros Cons
Easy to use Just enable it in the MySQL config Simplistic It has zero knowledge of your intentions
Transparent No application-level changes are needed Easy to invalidate Any change to a table will invalidate all associated data, even if unnecessary (see: simplistic)
Single threaded because the query cache is single threaded it can actually harm performance

We can solve these issues by using application-level caching, but how can we get the simplicity and ease of use of the query cache without the problems?

This is where the mysqlnd_qc plugin comes in.

Read More

Instances, Classes, and Modules, Oh My!

One of the biggest challenges of object oriented programming in Ruby is defining the interface of your objects. In other languages, such as Java, there is an explicit way to define an interface that you must conform to. But in Ruby, it's up to you.

Compounding with this difficulty is the problem of deciding which object should own a method that you want to write. Trying to choose between modules, class methods, instance methods, structs, and lambdas can be overwhelming.

In this post, we'll look at several ways to solve the Exercism Leap Year problem, exploring different levels of method visiblitiy and scope level along the way.

Leap Year

If you sign up for and start solving Ruby problems, one of the first problems you will look at is called Leap Year. The tests guide you to write a solution that has an interface that works like this:

#=> true

A leap year is defined as a year that is divisible by four, unless it's also divisible by 100. Apparently, centuries aren't leap years. That is, unless they are centuries that are divisible by 400. So there are three rules for leap years:

  1. If it's divisible by 400, it's an exceptional century and is a leap year.
  2. If it's divisible by 100, it's a mundane century and in not a leap year.
  3. Otherwise, if it's divisible by 4, it's a leap year, otherwise it's not.
Read More


Look through our specially curated posts to get focused, in-depth information on a single topic.