Fine-Tuning Memcached

Fine-Tuning Memcached

Are you getting memcached interruptions in your application logs? Does memcached say its been running but your app says something else?

Diagnosing the Problem

The first step is to check memcached stats with Telnet. If you’re running on Engine Yard (we use Gentoo) you can run emerge -g netkit-telnetd on your memcached server. You can then telnet localhost 11211 and then type stats. You should see something like this:

STAT pid 27631
STAT uptime 104
STAT time 1401932723
STAT version 1.4.5
STAT pointer_size 64
STAT rusage_user 0.004999
STAT rusage_system 0.010998
STAT curr_connections 10
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 4354
STAT bytes 0
STAT curr_items 0
STAT total_items 0
STAT evictions 23420009
STAT reclaimed 0
Read More

It's raining gems! - How to build your own Ruby gem

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 - 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!

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

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.

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


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