Engine Yard Sponsors Bundler

Engine Yard Sponsors Bundler

Open Source is at the heart of what we and our customers do here at Engine Yard. As a company that founded itself in the roots of the Ruby and Rails communities, we always find the best tools to help foster growth when it comes to building the best applications. In that vein, we are proud to announce our sponsorship of Bundler!

In the dark days, adding gems and managing dependencies in a Ruby application was cantankerous at best. Luckily, a few developers saw the need to fix this. Early in its development, Engine Yard employed Yehuda Katz, Carl Lerche, and André Arko to develop Bundler and help all Ruby developers get out of “dependency hell”.

Read More

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
Learn about Engine Yard
Try Engine Yard for your Ruby or PHP Apps

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

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

CHECK OUT OUR CURATED COLLECTIONS

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