Engine Yard

Developer Blog

May 24, 2013: This Week at Engine Yard

By | May 24th, 2013 at 1:05PM

Just finished speaking at the delightful Cloud East Conference in Cambridge, England! Glad to say that my velociraptor slide went over well. Bridget and I have been visiting customers in London and Brighton, and are going to Berlin on Monday for DevOps Day! If you’re there, be sure to say hi! The intrepid Kevin Holler and inimitable Slava will also be in attendance.

Tasha Drew, Product Manager

Engineering Updates

We have a couple fun and useful items in our early access phase! If you go to the dashboard, and from the menu select Tools >> Early Access, you will now find Application Takeover Preference and Ruby 2.0.

Application takeover preference allows you to easily set how you want our automated application takeovers to occur, in case our default behavior isn’t working for you.  Once enabled, you can go to “Edit Environment,” and you will see a new dropdown:

So if you’ve been having any trouble with your specific customizations not booting properly when we are automatically handling application takeover, you can select to instead boot from a new volume; have a takeover occur, but without booting a new application slave to replace the one being promoted; or disable the feature entirely.

As with all our early access features, we would be delighted if you shared your thoughts on these as you use them. Need something additional? Anything not working correctly? Documentation confusing? Love it and want to let us know? Tell us any and everything at our Early Access Forum!

And, also in early access, we have big news for our Rubyists: Engine Yard now has Ruby 2.0! We’ve had Rails 4 for a while now if you want to try them together. The full featured Ruby 2.0 integration in the UI, etc., is still getting some work done, so for now the installation instructions have some unique steps (i.e. not through the dashboard). See our docs for all the details!

Data Data Data

As we continue to enhance our new cluster model, we are in the planning phase for upcoming new data stacks! One of our top priorities is our mySQL database stack and how to make it more awesome as it takes advantage of the new data model. We are in the early stages of re-productizing it, so if you have any wish lists of things you’d like to see from our mySQL offering, please let us know in the feature request forums!

Social Calendar (Come say hi!)

Monday May 27th – Tuesday May 28th: Engine Yard will be participating as a sponsor of DevOps Day Berlin! Kevin Holler will be delivering a 5 minute talk about Engine Yard Cloud, and Tasha Drew and Bridget Gleason will cheer him on from the audience.

Wednesday May 29th: Our Portland office will be hosting the weekly Coder Dojo PDX!

Thursday May 30th: Engine Yard’s Dublin office is host to another addition of Node.js Dublin, featuring Dominykas Blyžė, Daniel McKay, and Isaac Schlueter.  Pizza and beer will be served!

Saturday June 1st: Engine Yard Dublin will host an IXDA Prototyping workshop. In this workshop you will learn how to create wireframes and interactive prototypes using the popular tool Axure RP.

Articles of Interest 

Cern launched a public appeal to find the world’s oldest webpage, and this is what they found.

What would the Games of Thrones characters look like if the show was staged in the 1990’s? Now we know.

Announcing: Moonshine, the Distill Kick-off Party, Sponsored by New Relic

By | May 23rd, 2013 at 1:05PM

By now you’ve heard that Engine Yard is proudly presenting our inaugural developer conference, Distill, on August 8-9. In addition to a lovely Treasure Island venue and a stellar lineup of speakers, we will also be throwing a kickoff party the likes of which you’ve never seen.

In keeping with the theme of distillation, which during the daytime events means learning, best practices and collaboration, we’ve dubbed the sure-to-be-awesome kick-off soiree “Moonshine”  as a nod to the tasty beverages we’ll be providing for you all. World-class DJs will kick out the jams as you enjoy our distillation-themed smorgasboard of hors d’oeuvres and the company of your fellow conference-goers. Throughout the evening, we’ll also be doing a few surprise giveaways (and if you know Engine Yard, you know that we don’t disappoint!)

Moonshine will take place at the Old Mint in San Francisco. We want to thank our partner New Relic for sponsoring. If you haven’t purchased your ticket for Distill yet, hurry and grab your First Batch (early bird discounted) ticket! Tickets will be increasing in cost from $400 to $500 on June 1.

A Conversation About Testing in PHP

By | May 22nd, 2013 at 1:05PM

We are proud to sponsor Chris Hartjes and Ed Finkler’s Development Hell podcast series where they record their freewheeling, uncensored discussions on programming the web, so future generations can learn from their failures.

Read on to get the low down on different testing tools and their relative merits–check it out as Ed and Chris weep for the future, come to some interesting conclusions and get their hands dirty so you don’t have to.

To hear more from Chris and Ed tune in to their podcast, /dev/hell

Ed and Chris had a little chat about testing in PHP.

Chris: Okay, so today’s topic is PHP testing

Ed: Word up

Chris: Now, Ed, I know that for the most part you are not a big fan of the mainstream PHP testing tools

Ed: Yes, that’s true

Chris: So what is it that you don’t like about them

Ed: I guess realistically my complaints are aimed at PHPUnit . It’s very powerful and very complete from what I can tell, but I think it’s difficult to pick up and I think that difficulty makes people less likely to use it. Because it’s by far the best known testing tool, I think that tends to limit the use of unit testing, period, in PHP. That’s not necessarily PHPUnit’s fault per se. I just think it’s the situation we’re in. I think the documentation, the setup, and just obtaining PHPUnit is a challenge, particularly when compared to unit testing options I’ve seen in other languages. Python, for example, has a simple but effective unit testing library built into the core.

Chris: So, when you say “difficult to pick up”, is it because tests look like this?

May 17, 2013: This Week at Engine Yard

By | May 17th, 2013 at 11:05AM

I spent this week with the team of engineers who made Riak on Engine Yard Cloud possible, attending RICON East: all Distributed Systems, all the time. Later in the week we took advantage of being in New York City to visit local customers and discuss the various features we’re working on and field any technical, product, and data questions.

Both our engineering and product teams love incorporating customer feedback into our direction. Speaking of which — if you’re in San Francisco, I’m organizing customer UX feedback sessions! Hit me up :)

Tasha Drew, Product Manager

Engineering Updates

PHP is now GA on Engine Yard Cloud! Per Product Manager Noah Slater: “PHP has been an important part of Engine Yard’s growing family since the acquisition of Orchestra in 2011. And now, PHP on Engine Yard Cloud represents the culmination of our efforts to deliver the industry’s best Platform as a Service for PHP developers. The result of this work is a unified service offering for PHP, Node.js, and Ruby applications.” Read all about the GA launch announced by Davey Shafik at php[tek] in Chicago this week!

Data Data Data

Riak and Clusters are live! See our blog post for more info – https://blog.engineyard.com/2013/riak-is-ga-engine-yard

A cluster is a new way to organize and manage instances that share a specific function.  Clusters take much of the functionality that was once placed at the environment level, and moves it down to the cluster level. One environment can have many clusters, and each cluster can run different cookbooks and be in different regions.

We drove the cluster model hand in hand with our productization of Riak on Cloud because the distributed model of Riak paired perfectly with where we wanted to drive the future of our platform. We can now take this underlying work and begin to re-productize other offerings to take advantage of its flexibility in many ways.

Social Calendar (Come say hi!)

Tuesday May 20th: Engine Yard Dublin hosts the PHP meetup where Eugene Kenny, Adverts.ie discusses his “Developer Toolbox”, and then Matthew Weier O’Phinney of Zend Framework & Nate Abele of Lithium go head to head on the subject of Frameworks.

Wednesday May 21st: Engine Yard’s San Francisco HQ will be hosting the monthly Riak meetup! Lead data engineer and fan favorite Ines Sombra will be presenting about Riak on Engine Yard Cloud, followed by Basho’s Mark Phillips discussing Riak CS.

Wednesday May 21st: Our PDX office will be hosting Coder Dojo for students K-12 to learn about software! Grab a ticket and bring your parents for some software fun.

Thursday May 22nd: Engine Yard Dublin plays host to Open Data Ireland, “Give us our health data!”

Friday May 23rd: In which I talk about myself in the 3rd person? Tasha Drew will be speaking at Cloud East in Cambridge, UK, about deployments in the cloud, including various strategies we at Engine Yard see for environments of different sizes — and concluding with sharing our own deployment strategy.

Articles of Interest 

Lightweight screenshot and annotation tool http://glui.me/ has gained some fans in our office!

Engine Yard friend Daragh Curran, Head of Product Engineering, Intercom shared an awesome blog here. “Shipping brings life to your team, to your product, and to your customers. Shipping is your company’s heartbeat.”

Shipping is your company’s heartbeat

By | May 16th, 2013 at 4:05AM

Note: Engine Yard friend Daragh Curran, Head of Product Engineering, Intercom has graciously let us post this great piece about code deployment on our blog. Check it out on their own blog here.

Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions.

Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible for your customers, and gives you the opportunity to focus on the next thing.

Shipping brings life to your team, to your product, and to your customers. Shipping is your company’s heartbeat.

Shipping will try to kill you

The scramble to get that one last feature done, the late nights, the compromises, the sinking feeling when we realise something major is broken, the post-mortems… It’s agony, but if it was easy everyone would do it. Shipping exposes mistakes. We’re nervous about it, and our natural reaction is to do it reluctantly and infrequently, which actually carries higher risk, causing more reluctance in the future.

The cost of shipping is approaching zero

Not too long ago, shipping software involved actual ships, disks, and printed manuals. It happened perhaps once a year. Bug fixes weren’t automatic over the internet like today. Everything was slower and more controlled. The cost of shipping was massive, the consequence of a mistake was large. Today, the cost of shipping has approached zero. Most people can deploy in seconds or minutes with a single command or button click. With a little thought you can do that without your customers noticing, and with automated monitoring you’ll find out immediately if something goes wrong.

Despite the cost of shipping approaching zero, many people still ship software guided by very old habits.

Shipping cadence defines your company

The cadence at which you ship defines your company. A yearly cadence results in a very structured approach to the design->build->test cycle. A few months of building, while the rest is spend fixing. Engineers can join and leave before seeing their hard work end up in the hands of customers. The approach to design becomes one of anticipating all possible needs, rather than focusing and iterating on the important ones.

Obstacles downstream propagate upstream

An obstacle downstream propagates upstream. If you’re not allowed to implement new ideas, you stop having them.
- Paul Graham

The right approach to shipping has a positive influence on your company’s productivity and your team’s happiness & job satisfaction. Shipping infrequently is an obstacle. Ship slow, and you’ll introduce challenges that push you to ship even slower. Ship frequently, and see positive effects everywhere in your company. For example, lets examine how behaviour changes along with shipping frequency, while handling a simple request from a customer.

Time to production behavior

Lets say a customer gets in touch to say “No matter what I do, I cannot save my name correctly, I think it doesn’t like hyphens“. In a company where you ship continuously, you see this and think Simple — I’ll tweak a test and a regex pattern, get a quick code review from my buddy beside me, merge to mainline, and 1 minute later when it’s deployed to production, reply to the customer: “Sorry about this, it’s fixed now, thanks for letting us know“. They’ll reply: “Wow, thanks for fixing so quickly“. High fives all around!

If we stretch the time to production (TTP) out a little, even to 10 minutes, the behaviour changes. You either do the same, but reply saying it’ll be fixed with our next deploy (probably 10 minutes) – or you wait, so that you can communicate with certainty. The waiting is time where you’ll shift focus to something else, but have the baggage of having to follow up. Perhaps you’ll think, I’ll have a quick coffee, then move on to something else afterwards. Even though your deployments are entirely automated, you lose time because of waiting and losing focus.

Customer support shipping

If TTP is hours, the behaviour changes again. No longer can you say with certainty when the change will be out there, so you’re tempted to batch up with other similar small changes. You postpone replying until you get time to do it, sometimes forgetting about it. You’re less likely to take prompt action, wow’ing the customer, and you pay some mental cost for having it on a todo list. Since getting to production takes hours now, your team will start restricting to morning only deploys, so miss that slot and it’s further delays.

If TTP is days, it exacerbates that further – perhaps you’ll reply “Thanks for letting us know. We’ll fix this in our next sprint”. It gets bundled in with a whole load of other small low, priority items, you spend more time debating estimates, and priorities, than the first guy took to fix it and reply to the customer. Miss the beginning of week deploy window and further slippage. The larger releases bring higher risk, you’ll tell your customer it’s fixed, only to later require rolling back because of a separate change. Your bug database gets bigger and bigger, with little details that you’ll probably never fix.

When TTP is weeks, it exaggerates that even further – perhaps you’ll reply “Sorry about this, I’ll let the development team know” or something equally lame from your customer’s standpoint. Deep down you realise nothing will be fixed, and the job of talking to customers becomes a cost or hassle, rather than an opportunity to improve your product and nurture happy loyal customers.

Shipping continuously

Better approaches to writing or testing software help us iterate more quickly and confidently, but the benefits are quite local to engineering teams. Continuous shipping on the other hand, touches all parts of your company, as do the benefits, and the behaviours it enables and encourages.

Linkedin’s transition to continuous deployment is linked to their recent financial success.

Good products, are a side effect of combining good people with an idea in an environment that helps those people to kick ass. Your attitude to shipping is a big part of that environment you create.

Shipping breathes life into how we think. The feedback loop helps us learn, gain confidence in making quick decisions, and build momentum. Momentum in product improvements excites and engages our customers. Seeing quickly the benefits of our hard work, motivates us to do more. Building a team where people can work hard and move fast attracts others to join you – hiring gets easier.

shipping-brings

Shipping continuously isn’t an achievement you unlock and then move on. You’ve got to constantly obsess about it. If you believe in the benefits it brings, you’ll be driven to shrink 20 minutes down to 1 minute or less, you’ll consider ‘ability to ship‘ as an equal to ‘does it scale‘ when building new systems. And you’ll do that because of all the life it breathes into your company and your product.

Shipping is your company’s heartbeat.