Ruby

Heroku provides an opinionated platform in order to help you build better applications. We give you a default version of Ruby to get you started, and give you a way to declare your version for total control. In the past creating an application would give you 1.9.2, starting today the default is 2.0.0. Ruby 2.0.0 is fast, stable, and works out of the box with Rails 4. Applications running on 2.0.0 will have a longer shelf life than 1.9.3, giving you greater erosion resistance. Default Behavior If you have a previously deployed app it will continue to use Ruby 1.9.2, any new applications will run on 2.0.0. Heroku is an erosion resistant platform, which means we will not change a major or minor version of Ruby on your app without you taking action. Setting your Ruby Version In addition to providing a default version of Ruby, you have the ability to specify your version of Ruby in your Gemfile: ruby '2.0.0' While you can prototype on the default Ruby, we recommend explicitly setting your version on all production applications. When you specify the Ruby version in your codebase, you get the exact same version: across every developer and across every app. This means any new developers on your team, any new staging apps you set up on Heroku and any forked apps will have the same version. If your app needs consistency: define your Ruby version. Ruby 2.0 Ruby 2.0 includes copy on write friendly garbage collection which can reduce memory usage in a forking server such as Unicorn. Ruby 2.0.0 has faster code loading which means large frameworks such as Rails start much faster. Ruby 2.0.0 is mostly backwards compatible with 1.9.3 and at Heroku our developers already run Ruby 2.0.0. Using the latest stable version of Ruby has advantages for the community as well as for application's performance. In the past some Rubyists have resisted upgrading. This resulted in libraries needing to support multiple versions of Ruby for long periods of time, and creating factions within the community. For instance while Ruby 1.9.3 was released in 2011 there are many developers who are just now upgrading from Ruby 1.8.7 which, was released in 2008. We have encouraged developers to run Ruby 2.0.0 on our platform by making the preview available, and the GA version available on launch day. By setting the default version to 2.0.0 we hope to encourage more developers to run on the most recent stable Ruby version. Stability, speed, and community are all good aspects to support, but we also care about application maintainability. At the end of this month Ruby 1.8.7 will reach end-of-life. Maximize the life of your application and simplify your upgrade to 2.1.0, coming in December, by using the most recent release. Conclusion Ruby at Heroku provides both defaults and flexible choices. You can explicitly declare a Ruby version or accept a stable, default version. Sometimes you may just need something to work, and others you want to enforce dev/prod parity between developers. By supporting a default Ruby you can do either. Thanks to Japan based Herokai: Ayumu Aizawa, Yukihiro "Matz" Matsumoto, Koichi Sasada, and Nobuyoshi Nakada, for working with us to push our defaults forward. Ruby Core is excited to see Heroku support the new 2.0 default, we hope you are too. Try it on Heroku and let us know what you think: @heroku.

I’ve got a simple mailer working for my app now. I feel like I’m almost getting to the point where I can start deploying, but I’m beginning to realize that I need to crystallize my direction a little here. I’ve got a minimal UI going with twitter bootstrap and some code from Mike Hartl’s railstutorial, but I think I need to figure out what I want from the end product a little better. Today I’m going to try and use Apple keynote and gimp to see if I can put together a couple of User Experience stories together. If they’re good enough, maybe I can cut them together for use on my launchrock page. Once that’s done, I’ve decided to make another change in direction. I would like to switch back from MongoDB to Postgres. I know I put a lot of work into making this work with a document based database, but the more I look at the problem I’m trying to solve, the more I realize I need a relational database. How all these individual data rows relate to each other is more important that what is actually in them. This way I can re-establish has-many through relationships. There are a lot of cool things about MongoDB, but I don’t think I’ll be able to use them until the site starts getting large. It might be possible for me to use MongoDB for more high-volume functions later. So for now, I’ll be using a more classic use case for Rails. I won’t give myself more than a day or so to do it, otherwise I’ll be throwing away a perfectly functional system.

Spree has recently updated its documentation regarding contributions and has included (maybe for the first time?) an official Release Policy. This is an important step forward for the Spree community so that developers can communicate to clients the potential costs and benefits when upgrading Spree, understand how well Spree supports older releases, and gauge the overall speed of the "upgrade treadmill". Deprecation Warnings Deprecation warnings are to be added in patch releases (i.e. 2.0.2) and the code being deprecated will only be removed in minor versions. For example, if a deprecation warning is added in 2.0.2, 2.0.3 will still contain the same deprecation warning but in 2.1.0 the deprecation warning and the code will be gone. Deprecation warnings are very helpful for developers, but without a robust test suite exercising your application, it's easy for deprecation warnings to go unnoticed. A strong test suite coupled with deprecation warnings helps you manage your client's expectations about how upgrades can affect your Spree customizations and extensions. Master Branch Receives All Patches Master branch receives all patches, including new features and breaking API changes (with deprecation warnings, if necessary). No surprises here; the master branch is for developers and should not be used for production. If you think you've encountered a bug in Spree, make sure to create a failing test against master to make sure it hasn't be resolved by any existing patches. Read more about filing an issue for additional details. Current Stable Release Branch One branch "back" from master (currently 2-0-stable) receives patches that fix all bugs, and security issues, and modifications for recently added features (for example, split shipments). Breaking API changes should be avoided, but if unavoidable then a deprecation warning MUST be provided before that change takes place. Continuing Spree's history of very aggressive refactoring, breaking API changes are permitted in the current stable branch. If you're looking for a truly stable release of Spree, you'll need to look back two stable branches behind master. Two Releases Behind Master Two branches "back" from master (currently 1-3-stable) receives patches for major and minor issues, and security problems. Absolutely no new features, tweaking or API changes. In my opinion, this is the only branch that should be considered for use in production. With the API locked down and a greater chance of most bugs worked out while it was the current release branch, the "two-back" stable branch is a safe bet that's going to have the most up-to-date feature set. Three and Four Releases Behind Master Three branches back from master (currently 1-2-stable) receives patches for major issues and security problems. The severity of an issue will be determined by the person investigating the issue. Absolutely no features, tweaking or API changes. Four branches and more "back" from master (currently 1-1-stable and lesser) receive patches only for security issues, as people are still using these branches and may not be able to or wish to upgrade to the latest version of Spree. It's nice to see a fairly strong commitment to accepting security patches, although if we look at this in absolute terms, the 1.1.x release was put into security-patches-only mode after just 13 months. Considering that the 1-1-stable branch is 2,127 commits behind the 1-3-stable branch (!!), it's clear that Spree is now formalizing it's very aggressive release culture. Managing the Upgrade Treadmill As stated previously, a strong test suite is the best tool available to be able to determine what upstream updates affect your Spree customizations. Coupled with deprecation warnings, it becomes a fairly straight-forward process for identifying breaking changes, creating estimates for fixes, and communicating these costs to clients. Following the stated guides for customizing Spree is also recommended. When visiting the

Onion Pi - Anonymous browsing anywhere with this portable Tor proxy. Stubbing Views in Rails Controller Testing - Avoid the overhead of rendering views when you don't need them. Returning to Free Software: A Guide - Cutting ties with the folks who have cooperated with PRISM. Arproxy - Analyze or modify SQL in between Active Record and your database. RailsMailPreview - Free solution for previewing email from Rails applications on OS X. Docracy Terms of Service Tracker - Adds/edits/deletes across more than a thousand sites.

ZURB's Foundation is a front-end for quickly building applications and prototypes. It is similar to Twitter Bootstrap but uses Sass instead of LESS. Here you will learn the basics of the grid system, navigation, tooltips and more.

Change is a constant. At Heroku, we often deliver important information to users about changes and events on the platform, their apps and their accounts. We use a variety of media to keep users informed about these changes, including email, Twitter, the changelog and the blog. To help provide more direct and relevant information, we've added a new feature to Dashboard called Notification Center. We'll be using the Notification Center to keep you informed of important events affecting you and your apps. When new notifications arrive, you'll see a badge in Dashboard's header. If you log in today, you'll see something that looks like this: We'll be carefully curating the events we post to make sure they don't become too noisy. Here's a list of some of the things we're planning to notify about to start: Billing changes such as 2X Dyno pricing going into effect. New platform defaults that affect your applications. Important framework security vulnerabilities that affect your apps. Account alerts, such as expired credit card information or overdue invoices. Changes in add-on state, such as an add-on you're using leaving its beta phase. We hope you enjoy having notifications available on Dashboard. We're always looking for better ways to keep you up to date with changes that affect your apps on the platform, so let us know where we can help you out.

I'm going to hire two full time, experienced web people in September as the first members of my product delivery team at Lean Startup Machine. We'll mostly be working on Javelin, our killer app for product managers that's currently entering pilot phase at a handful of Fortune 100 companies. Senior Web Developer Primarily looking for full-stack web technology experience, especially with modern browser-based MVC and CSS. Best candidate will be a generalist with broad understanding of OO application design, automated testing, cloud-based production environments and Agile processes. UX Designer / Front End Specialist Looking for someone special with experience designing and coding modern web and mobile user interfaces. Javascript/HTML/CSS experience is a must. RubyMotion is a big, big plus. Location: Anywhere in the United States Compensation: Short-term contract to perm. Low six figures annually plus generous equity More Information: We are a results-oriented work environment, which means all team members must possess a strong work ethic and high-degree of emotional maturity. Unless they happen to live near me in NW Atlanta suburbs or New York City, candidates must be able to work from home reliably and communicate well via email and videoconferencing. Additionally, as an investor-funded startup, the pressure is often quite high and the right candidates need to be confident enough in their skills and opinions to hold their own among co-founders (me and Trevor) with strong personalities. Our current technology stack includes Mongo, Ruby on Rails, Spine.js, and Twitter Bootstrap, so experience with those is definitely a plus. Existing interest in lean startup topics is (of course) another big plus. Occasional travel will be required, for company meetings and/or attendance and support of our weekend workshops around the world.   If you're a recruiter don't bother contacting me.

This is the week a big chunk of the San Francisco development team went on a roadtrip to our Portland office to do some intense cross-office feature pollination. Things may have started out with some office rivalry, but developers quickly overcame any differences to work together to build, drink copious amounts of amazing coffee, and figure out the location of some of the awesome restaurants Portland has to offer. Pro-Tip: check out Blue Star donuts #amazing. --Tasha Drew, Product Manager Engineering Updates Customer feedback is important to us and is an important part of how we prioritize work within our product management process. We received a few comments from customers who were frustrated because they couldn’t figure out why they were being charged money when they didn’t have any running instances. The answer was that they still had IP addresses that were detached from instances when the instances were terminated, but not deleted. Customers can always see IP addresses and manage them in the dashboard by going to Tools -> IP addresses, but we decided to add more messaging to call this out to people. Going forward, you will see a dashboard notice if you delete an instance and don’t delete the IP address - and you will also receive an email. We will also be sending out emails to any customer who has an account where the only items they’re being billed for are IP addresses and snapshots to let them know. Hope this helps going forward! Big thanks to one of our newest platform developers, the amazing Daniela, for turning this request around so quickly. We’re also wrapping up some cool new features around snapshot management which you should be reading about in this space next week! Data Data Data Our lead data engineer, Ines, has been busy working on the underlying code for exciting new features that we’ll be rolling out in the next few months. She also handed off a new feature that allows for database version locking to alleviate upgrade pains. The DBA team is actively testing and improving it and we should make it available soon. Watch out for her blogpost next week. Ines and I were delighted to get to meet up with local Postgres ladies while we were in Portland. Selena Deckelmann has some great thoughts on the intersection of developers and Operations on her blog for those of you who need some fun weekend reading.  Kris Pennella gave me a valuable reminder to take a deep breath when facing stressful situations in her blog, “3 Tips Channeling a Negative into a Positive.” We also had the pleasure of seeing Basho’s Eric Redmond (author of 7 Databases in 7 weeks and the Little Riak Book). We got a chance to hear some of the features that will come in Riak 1.4 and we are very excited! Social Calendar (Come say hi!) Friday June 14 - Saturday June 15: DevOps Days Amsterdam!: Meet the always charming Slava and the ridiculously knowledgable Richard as they hang out and participate in this awesome DevOps conference where we are not only a PaaS -- we are also a cake. Tuesday June 18, 19:00: Ruby Ireland Meetup at Engine Yard Dublin. We are Going off The Rails this month at Ruby Ireland as we go through some of the options for extending your web apps with mobile apps or through a Javascript framework. Kevin Fagan, Fergal Condron, Simon Rand, Gavin Joyce and Paul Watson will be speaking. Thursday June 20 - Friday June 21st: Lyon, France, Ruby Lugdunum: Crowd favorite Engine Yard engineer PJ Hagerty will be presenting at Ruby Lugdunum in exotic Lyon, France, on how to grow and nurture your local Ruby group. Thursday June 20, 18:30: Open Data Ireland #8 at Engine Yard Dublin. General theme for ODI Meetup #8 is 'Open Government Partnership'. This meetup will be facilitated by Denis Parfenov, Tom Stewart and Nuala Haughey. We'll be hosting a brief presentation from OGP representative. The rest of the evening will be dedicated to building topic- specific, multi-stakeholder/multi-disciplinary working groups with a view to takin

Rails 4.0 rc2, Understanding the GIL, Font Awesome Rails, String Inquirer, and gist dep are all featured in this RubyLoco powered Ruby5 Listen to this episode on Ruby5 This episode is sponsored by New Relic NewRelic recently released dPerf – A Distributed Low Impact CPU Profiler for iOS. dPerf is a small on-device profiling framework. Metrics collected by the profiler are pushed to a Node.js service with JSON over REST and are stored in a MongoDB collection. The Node service then provides a view that renders the profile data with Google Charts. And here’s the best part: New Relic is releasing dPerf as an open source project! You should be using NewRelic by now... and as always, your free account is waiting for you at newrelic.com Ruby on Rails 4.0 RC2 Nobody understand the GIL Font Awesome Rails Font Awesome 3.2.0, with 58 new icons was released this week, and Ryan McGeary had update the font-awesome-rails asset gem in near-record time! If you find yourself looking for an easy way to use a bunch of common icons in your web app, from thumbs up, to buttons, to stars, to popular service logos, you should check out font-awesome and the corresponding gem; its much quicker to download one font file that it would be dozens of icons! String Inquirer StringInquirer is a great little utility for making string comparisons in Ruby look better, resulting in much more readable code. Andrew Hooker has been breaking down and telling stories about some Rails internals; let this be your introduction to this wealth of information. gist-dep Eric Anderson released this spiffy little gem that lets you point at github gists and include them into your projects. Do you have a little bit of javascript, perhaps a favorite bit of sass or maybe a lone rake task you tend to copy from project to project? Not worthy of turning it into a full blown gem? Gist-dep it!

For as long as I can remember, I’ve been a fan of Saturday Night Live and improvisational theater. Improv looks chaotic and uncontrolled, but the best practitioners operate under strict rules that govern interactions between players. Some of the most successful entertainers today, people like Stephen Colbert and Tina Fey, directly credit what they have learned in improv with making them better at what they do both on and off screen. Unlike workplace policies that you are probably used to, the rules of improv aren’t meant to constrain you, but to open you up to the ideas of others. Let’s take a look at some of the rules the Mr. Colbert and Ms. Fey live by and see how they can improve team collaboration. Agree and Say “Yes”. Here’s Tina, from her book Bossypants, talking about the rules of engagement: The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt. But if I say, “Freeze, I have a gun!” and you say, “Yes! The gun I gave you for Christmas! You bastard!” then we have started a scene because we have AGREED that my finger is in fact a Christmas gun. The same is true of engineering teams. When one of your teammates has an idea, your first response needs to be affirmative. Take any and all ideas from your teammates as positive contributions and you start from a place of being open-minded and welcoming. Nothing kills team morale faster than someone who says “No, that won’t work” in response to any idea that they didn’t come up with. It’s Not Just “Yes”, it’s “Yes, and…” Everyone loves games and games are more fun when everyone  plays nicely. Make positive contributions and you will foster a spirit of openness, collaboration and — dare I say — fun.  Make it your habit to answer your teammate’s ideas with “Yes, and…” instead of “No, because”. Always offer your ideas, you just are as entitled to be silly and wrong as everyone else. Ideas seldom spring fully-formed from the head of Zeus and the part you’re holding back out of fear might be the thing that makes it work. “Yes, and…” makes you part of the solution; “No, because” makes you part of the problem. Your Team is the Most Important Person on Your Team  Stephen Colbert went back to his alma mater, Northwestern University, to give the commencement address in 2011. He may play a know-it-all blowhard on The Colbert Report, but that’s clearly not the case in real life. Here’s an excerpt from his speech: …One of the things I was taught early on is that you are not the most important person in the scene. Everybody else is. And if they are the most important people in the scene, you will naturally pay attention to them and serve them. But the good news is you're in the scene too. So hopefully to them you're the most important person, and they will serve you. No one is leading, you're all following the follower, serving the servant. You cannot win improv. And life is an improvisation. You have no idea what's going to happen next and you are mostly just making things up as you go along. And like improv, you cannot win your life. The software corollary to this is: “You cannot win engineering”. Think about the implications of this for a moment. If everyone on your team acts as if their teammates are more important than they are, you create an environment of support, giving, and progress that is mutually enriching and productive. You’ll know you have succeeded when no one on your team remembers where a great idea came from. More importantly, no one will care. When one of your teammates asks you a question, don’t tell them to Google it (which is a bit of a jerk response in any case). Act as if their problems are more important than yours, serve the team by serving them.