Taming Asynchronous JavaScript with Async.js

JavaScript is often described as asynchronous, meaning that function calls and operations don’t block the main thread while they execute. This is true in some situations, but JavaScript runs in a single thread, and therefore has lots of synchronous components.

It’s more accurate to say that many function calls in JavaScript can be made asynchronously. Web programming essentials like DOM event handlers and AJAX calls are asynchronous, and because these common tasks make up a great bulk of JavaScript programming, JavaScript itself is often labeled "asynchronous."

When a function runs asynchronously, that means it doesn’t stop subsequent function calls from running while it finishes. Take this example:

var users = [];
$.get(/users, function(data) {
  users = data;
});
renderUsersOnPage(users);

Since $.get() is asynchronous, the next functional call (to render the users) will execute immediately, whether the fetch call has finished or not. This means that our data won’t be available to us when we try to render it, because the earlier call to fetch them from the API is still being executed!

So, the main problem with asynchronous programming is how to call asynchronous functions that depend on each other. How do you ensure function A has finished before calling function B, if you can’t rely on function A blocking until it’s done?

Read More

Introduction to MySQL's Innodb Memcached Interface

Introduction to MySQL's Innodb Memcached Interface

Note: This is part three in our Extending MySQL with PHP's MySQLnd Series

With MySQL 5.6 a memcache-compatible innodb-backed key-value store was added to MySQL.

The InnoDB Memcache Daemon gives you the permanence of innodb for key-value data, that can be accessed via the much faster, optimized memcached protocol — using this will skip the query parser, optimizer and other parts of engine that are unnecessary.

With mysqlnd_memcache, you can transparently route queries to this memcache-compatible interface.

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

Graph Kit for Ruby: Deployment with Graph Story and Engine Yard

Graph Kit for Ruby: Deployment with Graph Story and Engine Yard

Welcome to the third and final installment of the Graph Kit for Ruby post series. Part 1 kicked the series off with a brief look at the idea of a graph database and some description of the Spree online store I planned to enhance with a graph. Part 2 went in depth with the addition of a graph-powered product recommendation system to a Spree online store. In this final entry we’ll learn how to tweak our Spree + Neo4j store to deploy it to a production server on Engine Yard Cloud.

Provisioning

Pushing this Spree store to Engine Yard worked in three major phases: provisioning the server, configuring the server, and pushing the code. That runs for ten minutes or so, and then you have a new server running. Next up – SSH into the server to do the last-mile config before your first deployment.

Read More

Ruby Isn't Dead

Ruby Isn't Dead

Some might say 2014 has been a year of programming related death. TDD is dead. Agile is dead. The Framework is dead. If this keeps up, all of programming should be dead by about December 31st.

Earlier this year I was lucky enough to attend a small conference in Southern france known as Ruby Lugdunum. In the late afternoon of the final day we retreated to a cafe and there was a panel discussion on the future of Ruby hosted by Joshua Ballanco. The beginning thrust of the panel discussion, which featured such Ruby luminaries as Terence Lee, Chris Kelly, and Sam Phippen, was the idea of Ruby fading away or dying out.

The idea itself disturbed me. Maybe my head was in the sand and I missed something, but I love Ruby. It’s easily the favorite of all the languages I’ve programmed with. It couldn’t be dying... it just couldn’t!

Read More

Graph Kit for Ruby: Bootstrapping a Spree Store and Integrating with Neo4j

Graph Kit for Ruby: Bootstrapping a Spree Store and Integrating with Neo4j

Welcome to the second installment of the Graph Kit for Ruby series. In the first post I described the plan for the project — to showcase the ease of use and business value of graph databases in the context of a Ruby project. Today we’re digging into the implementation of a Neo4j-backed product recommendation engine. This recommendation engine will sit atop an online store built with the Rails-based e-commerce project Spree.

Brief note on prerequisites and recommended experience level

This post assumes that the reader has a basic understanding of the Ruby ecosystem. You’ll need a newer version of Ruby (2.0+ preferred) and the `bundler` utility. You might also need to be able to install some packages on your system like the PostgreSQL and Neo4j database engines. I used Ubuntu to prototype this but you should be able to get by fine with any recent version of Linux or OSX. The finished project is published on Graph Story’s GitHub account as the Graph Kit for Ruby, so feel free to dig in for specific implementation details.

If at any point you get stuck feel free to reach out to the Graph Story team for help. Here we go!

Starting a new Spree Project

You’ll want to follow the recommendations in the official Spree Getting Started Guide to get your workspace set up. Note that you’ll start with the usual rails new installer before getting into Spree-specific setup. Here are the basic shell commands to get your Rails project started with Spree loaded into its Gemfile:

Read More

CHECK OUT OUR CURATED COLLECTIONS

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