A “Free” online course on Sinatra – 12th batch

A “Free” online course on Sinatra – 12th batch

RubyLearning announces the twelfth batch of its “Free” online “Sinatra” course starting from Saturday 1st Feb. 2014.

Sinatra – quickly create tiny web apps and services

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 15 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay and hence the course would be free for you.

For those who contribute US$ 15, we shall email them a copy of the book (.pdf) “Introduction to Sinatra” – the course is based on this book.

How do I register and pay the course fees?

  • First, create an account on the site and then pay the fees of US$ 15 by clicking on the PayPal button Paypal
  • After payment of the fees please send us your name to satish [at] rubylearning [dot] org so that we can send you the eBook, which normally takes place within 48 hours.
  • If you want to take the course for free, please just create an account and send us your name (as mentioned above).

Who’s It For?

Anyone who knows the Ruby programming language can take the “Sinatra” course, and is a starting point for people new to Sinatra and a guide to help learn it as quickly and easily as possible.

Dates

The course starts on Saturday 1st Feb. 2014 and runs for a week.

What’s Sinatra?

Sinatra is a micro-framework for quickly creating tiny web-applications and small services in Ruby. It is not a Model-View-Controller (MVC) based framework.

Please read – Sinatra, a Ruby web framework, and Why it Matters.

Heroku Logo

Thanks to Heroku for providing the facility to create free hosting accounts for all the participants, to host their apps created during the course. Heroku – it’s fast, it’s easy, and it just works!

What Will I Learn?

In this introductory course, you will learn the essential features of Sinatra that you will end up using every day. The course topics are:

  • What is Sinatra?
  • Sinatra Installation and its dependencies
  • Routes
  • set
  • before block
  • pass
  • status
  • Building a trivial Sinatra application
  • Deployment of a Sinatra app to Heroku
  • Views – ERB and HAML
  • Handler
  • Form parameters
  • Layouts
  • Error Handling – 404 and 500
  • Helpers
  • Exercises
    • Hosting a static webpage on Heroku
    • Text String Reversal Service
    • Stock Exchange Quote Service
    • Using Sinatra to access the Google+ API
    • Running a Sinatra app using JRuby
    • A Sorter Web Service in Sinatra
    • Finding Photos on Flickr
    • A Sinatra app to access GEO Info via GeoCoder
    • Sinatra Street View
    • Simple CRUD app with ActiveRecord, SQLite3 and YAML
  • Using Rack Middleware

You can read through the RubyLearning FAQ.

Some Fun Apps

Sinatra Icon

Here are some of the fun apps created by the previous batch participants and deployed to Heroku:

Yes, you too can build all such applications and many more.

Famous Rubyists using Sinatra talked to RubyLearning and gave us their views on:

Also, thanks to Adam Keys, Aaron Quint, and Ryan Tomayko for sharing their expertise on Sinatra with the course participants.

So hurry, registrations have started.

By the end of the course, you can quickly create your own tiny web-applications in Ruby and write lots of small services.

Technorati Tags: , , , , ,


(Powered by LaunchBit)

A “FREE” Git and GitHub Course – 10th batch

A “FREE” Git and GitHub Course – 10th batch

Registrations are now open for RubyLearning’s popular “Pay if you like” online Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 25th Jan. 2014 and runs for a week.

The first nine batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 10 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 10 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • First, create an account on the site and then pay the fees of US$ 10 by clicking on the PayPal button Paypal
  • After payment of the fees please send us your name to satish [at] rubylearning [dot] org so that we can send you the eBook, which normally takes place within 48 hours.
  • If you want to take the course for free, please just create an account and send us your name (as mentioned above).

Mentors

Satish Talim and Victor Goff III from the RubyLearning team.

Some Highlights

RubyLearning’s IRC Channel

Some of the mentors and students hang out at RubyLearning’s IRC (irc.freenode.net) channel (#rubylearning.org) for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

Google Hangouts

There is a Hangout Event that is open for students, for drop-in hangouts where students can pair program with mentors or with each other. This is often where you can get help with your system, editor, and general environment. Anything that can help you with your coding environment that you are having problems with are usually discussed interactively here.

Git Repositories

Shared (private) repositories available for those that want to learn git and the revision controlled programming workflow. This allows students that want to collaborate while learning. This is a great way to record your progress while learning Ruby.

How does the course work?

For details on how the course works, refer here.

Technorati Tags: ,


(Powered by LaunchBit)

A “FREE” Online Course: Build your own web-application framework with Ruby – 1st batch

Build your own web-application framework with Ruby

Registrations are now open for RubyLearning’s “Pay if you like“, online course on “Build your own web-application framework with Ruby“.

At the end of the course the participant will learn:

  • Rack the layer on which Sinatra, Rails is built.
  • the fundamentals of every Ruby web framework. This will give you an insight on how Sinatra works.

Who’s It For?

Anyone with some knowledge of:

  • Ruby programming
  • RubyGems
  • Bundler
  • Git

Dates

The course starts on Saturday, 18th Jan. 2014 and runs for 2 weeks.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 15 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay and hence the course would be free for you.

How do I register and pay the course fees?

  • First, create an account on the site and then pay the fees of US$ 15 by clicking on the PayPal button Paypal
  • If you want to take the course for free, please just create an account and send us your name to satish [at] rubylearning [dot] org.

Course Contents

  • Build and Install (locally) the Saral gem
  • Uploading the Saral gem to GitHub
  • Exercise 1 – URL of your GitHub repo for your Saral gem
  • A quick look at Rack
  • Exercise 2 – Thin server
  • Exercise 3 – Rack app for env
  • Optional: A detailed look at Rack
  • Understanding the Rails folder structure
  • Build an app – Display some text to the user
  • Saral and MVC
  • Our first Router and Action Controller
  • Exercise 4 – courses_controller.rb
  • Exercise 5 – NameError
  • Exercise 6 – Catch Exceptions
  • Exercise 7 – Using Google’s Geocoding API
  • Some optimization for Saral
  • Optional: Request and Response with Saral
  • Optional: Rack Middleware with Saral
  • Rendering Views
  • Exercise 8 – Street View modified
  • Exercise 9 – Saral Web Service: Sorter
  • How to upload your Framework Gem to RubyGems.org
  • How to upload your app to Heroku
  • Exercise 10 – Handling Exceptions
  • Exercise 11 – Upload Gem and App

The course contents are subject to change.

Mentors

Satish Talim and Victor Goff III from the RubyLearning team.

Some Highlights

RubyLearning’s IRC Channel

Some of the mentors and students hang out at RubyLearning’s IRC (irc.freenode.net) channel (#rubylearning.org) for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

Google Hangouts

There is a Hangout Event that is open for students, for drop-in hangouts where students can pair program with mentors or with each other. This is often where you can get help with your system, editor, and general environment. Anything that can help you with your coding environment that you are having problems with are usually discussed interactively here.

Git Repositories

Shared (private) repositories available for those that want to learn git and the revision controlled programming workflow. This allows students that want to collaborate while learning. This is a great way to record your progress while learning Ruby.

How does the course work?

For details on how the course works, refer here.

You will find Noah Gibbs book “Rebuilding Rails: Understand Rails by Building a Ruby Web Framework” useful. Use discount code “rubylearning”

Technorati Tags: , , ,


(Powered by LaunchBit)

Christmas Discount on the Online Ruby Programming 49th Batch

Registrations are now open for RubyLearning’s popular Ruby programming course. This is an intensive, online course for beginners that helps you get started with Ruby programming. The course starts on Saturday, 4th Jan. 2014 and runs for seven weeks.

Course Fee and Christmas Special

Please create a new account first and then pay US$ 49.95 by clicking on the PayPal button Paypal

After paying the fee you can in addition, gift this Ruby course to one of your friend or relative. Please create a new account for him/her and let us know. We shall enroll him/her into the course for free.


Download ‘Advice for Ruby Beginners’ as a .zip file.

Here is what Sandra Randall (Butler), a participant who just graduated, has to say – “You kindly offered me the opportunity to join your Ruby course. I’m new to development and found the course, even though basic for programmers, a little tricky for me. I managed to complete all of the assessments and really learnt a lot. Thank you very much for the opportunity. It has really given me the push I needed to learn Ruby and I’m currently treading my way through both the pickaxe and Agile Development books and enjoying it. I’ve recently been offered a position as a Junior Systems Developer at a local Software house in South Africa – all thanks to the push you gave me which gave me the motivation and drive to get going.”

What’s Ruby?

Ruby

According to http://www.ruby-lang.org/en/ – “Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. Ruby’s elegant syntax is natural to read and easy to write.”

Yukihiro Matsumoto, the creator of Ruby, in an interview says –

I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby.

What Will I Learn?

In the Ruby programming course, you will learn the essential features of Ruby that you will end up using every day. You will also be introduced to Git, GitHub, HTTP concepts, RubyGems, Rack and Heroku.

Some Highlights

RubyLearning’s IRC Channel

Some of the mentors and students hang out at RubyLearning’s IRC (irc.freenode.net) channel (#rubylearning.org) for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

Google Hangouts

There is a Hangout Event that is open for students, for drop-in hangouts where students can pair program with mentors or with each other. This is often where you can get help with your system, editor, and general environment. Anything that can help you with your coding environment that you are having problems with are usually discussed interactively here.

Git Repositories

Shared (private) repositories available for those that want to learn git and the revision controlled programming workflow. This allows students that want to collaborate while learning. This is a great way to record your progress while learning Ruby.

eBook

The course is based on the The Ultimate Guide to Ruby Programming eBook. This book is priced at US$ 9.95. However, the Kindle edition of the eBook is available for US$ 6.

Challenges and Side Tracks

This is course material not found in the RubyLearning Study Notes nor in the E-Book! Depending on participation levels, we throw a Ruby coding challenge in the mix, right for the level we are at. We have been known to give out a prize or two for the ‘best’ solution.

Who’s It For?

A beginner with some knowledge of programming.

You can read what past participants / online magazines have to say about the course.

Mentors

Satish Talim, Michael Kohl, Satoshi Asakawa, Victor Goff III and others from the RubyLearning team.

Dates

The course starts on Saturday, 4th Jan. 2014 and runs for seven weeks.

How do I register and pay the course fees?

  • You can pay the course fees either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, this Ruby course, the Ruby eBook, and provide quality content to you.

To pay the Course Fee:

Please create a new account first and then pay US$ 49.95 by clicking on the PayPal button Paypal

After paying the fee you can in addition, gift this Ruby course to one of your friend or relative. Please create a new account for him/her and let us know. We shall enroll him/her into the course for free.

How does the course work?

For details on how the course works, refer here.

At the end of this course you should have all the knowledge to explore the wonderful world of Ruby on your own.

Remember, the idea is to have fun learning Ruby.

Technorati Tags: , , ,


(Powered by LaunchBit)

Programmatically release code to Heroku

Currently in beta, the Heroku Platform API lets developers automate, extend and combine the Heroku platform with other services in a programmatic, self-service way. Today we are setting the capstone into the API by adding slug and release endpoints to the API beta.

These API endpoints are special. They expose a very core part of what Heroku does best: Quickly and safely releasing new versions of an app onto the Heroku platform.

Using the new slug and release endpoints, platform developers can build integrations and services that completely sidestep the traditional Heroku Git deployment flow. So instead of requiring git push heroku master to deploy, it’s now possible to do things like:

  • Write a script that builds an app in a local directory on your machine, tars it up, and deploys it directly to a Heroku app
  • Extend your favorite continuous integration server or service to deploy directly to Heroku if unit tests pass – no need to use Git or manage SSH keys
  • Move slugs around between Heroku apps, for example to promote a release on a staging app to a production app

Are you a CI service provider, source code repository provider, or just a plain old hacker interested in the opportunities this opens up? We want to work with you, get in touch with friis@heroku.com.

The slug and release endpoints complete the functionality that we plan to expose in the first version of the Heroku Platform API. The API is still in beta and we welcome questions and feedback in the Heroku API Forum.

Slugs and Releases

Platform API

“Slug” refers to one of two things:

  1. A tarballed bundle of source code, fetched dependencies and compiled or generated output of a build system, ready for execution on the Heroku runtime
  2. A record created in the Heroku database when you register and upload a slug tarball using the slug endpoint on the platform API

The slug API endpoint allows slug records to be created and read. It contains attributes including the URL of the slug tarball, the process types that the slug can run (mirroring the contents of the Procfile), and a version control identifier (typically the SHA from the Git commit of the source code used to create the slug)

Releases are versioned deployments of an app, containing a slug and a set of config vars. The release API endpoint allows releases to be created and read. Releases require a slug and can optionally contain a description.

Slugs can be shared amongst releases – by fetching the slug from an existing release on any given app, a new release can be created on any other app using the existing slug. This allows slugs to be quickly and efficiently promoted between environments (such as from staging to production), and the release endpoint can be used to programmatically create custom deployment workflows.

The rest of this post contains two examples that demonstrate the power of the new API endpoints. The first shows how to move slugs between apps, the second demonstrates how to create and deploy slugs from scratch, from your local machine.

Full documentation is available on Dev Center in these articles:

Copying slugs

There are several ways to get a valid slug that can be released to an app. The simplest method is to copy a slug generated by Heroku for a different app. Imagine that you have pushed code to a staging app, the code has been tested and you are now ready to release to production. Instead of pushing to the production app and waiting for the code to build again, you can simply copy the slug from the staging app to the production app.

First, list releases on the staging app to get the id of the slug to release:

$ curl -H "Accept: application/vnd.heroku+json; version=3" -n \
https://api.heroku.com/apps/example-app-staging/releases
...
"slug":{ "id":"ff40c84f-a538-4b65-a838-88fdd5245f4b" }

Now, create a new release on the production app using the slug from the staging app:

$ curl -X POST -H "Accept: application/vnd.heroku+json; version=3" -n \
-H "Content-Type: application/json" \
-d '{"slug": "ff40c84f-a538-4b65-a838-88fdd5245f4b"}' \
https://api.heroku.com/apps/example-app-production/releases

That’s it! The new code is now running on the example-app-production app.

Note that copying slugs between apps is already possible using the beta Pipelines plugin, and Heroku Fork uses a similar mechanism when forking an app. The slug and releases endpoints expose the primitives necessary for third-party API developers to build services offering similar functionality and much more.

Creating slugs from scratch

Slugs don’t have to be generated by Heroku: You can use the releases endpoint to deploy anything the platform recognizes as a valid slug. Let’s create a slug containing a simple Node.js app and the dependencies required to run it on Heroku. On your local machine, create a folder named app to hold the slug and fetch the Node.js runtime:

$ mkdir app 
$ cd app
$ curl http://nodejs.org/dist/v0.10.20/node-v0.10.20-linux-x64.tar.gz | tar xzv

Add the app code in a file named web.js:

// Load the http module to create an http server
var http = require('http');

// Configure HTTP server to respond with `Hello World` to all requests
var server = http.createServer(function (request, response) {
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.end("Hello World\n");
});

var port = process.env.PORT;

// Listen on assigned port
server.listen(port);

// Put a friendly message on the terminal
console.log("Server listening on port " + port);

Tar up the slug:

$ cd ..
$ tar czfv slug.tgz ./app

The above process of creating a slug is a very simplified variant of what buildpacks do when normal slugs are created on Heroku: Make sure the source code is placed where it’s supposed to be and package any dependencies (the Node.js runtime in this case) into the slug.

The slug is now ready for release. This is a three-step process:

  1. Create a unique id and URL for the slug using the new slug endpoint
  2. Upload the slug
  3. Release the slug on the app

First, we register the new slug using the API. We have to keep track of the “put” url and the id that Heroku returns:

$ curl -X POST -H 'Content-Type: application/json' \
-H 'Accept: application/vnd.heroku+json; version=3' \
-d '{"process_types":{"web":"node-v0.10.20-linux-x64/bin/node web.js"}}' \
-n https://api.heroku.com/apps/example-app/slugs
...
  "blob":{
    "method": "put",
    "url": "https://s3-external-1.amazonaws.com/herokuslugs/heroku.com/..."
  },
  "id":"d969e0b3-9892-3113-7653-1aa1d1108bc3"

Notice that we pass a “process_types” parameter. This has content similar to what is included in the Procfile that is typically included in apps pushed to Heroku. Passing process_types is necessary because the Procfile is not parsed when slugs are launched in dynos. Instead, the Procfile is parsed by the build system and the contents are passed in when the slug is created as demonstrated above.

Use curl to upload the slug to the URL provided by Heroku:

$ curl -X PUT -H "Content-Type:" --data-binary @slug.tgz "https://s3-external-1.amazonaws.com/herokuslugs/heroku.com/…"

Finally, release the slug to the app example-app:

$ curl -X POST -H "Accept: application/vnd.heroku+json; version=3" \
-H "Content-Type: application/json" \
-d '{"slug":"d969e0b3-9892-3113-7653-1aa1d1108bc3"}' \
-n https://api.heroku.com/apps/example-app/releases

We can then check that the release was created:

$ heroku releases --app example-app
=== example-app Releases
v3  deploy  example@example.com  2013/10/08 16:09:54 (~ 1m ago)

To verify that the slug was deployed, run$ heroku open --app example-app. Please see the full example on Dev Center for additional details on how to create slugs. The Dev Center article has both the Node.js example above and examples demonstrating how to create simple slugs with Ruby and Go apps.

Summary

With the releases and slugs endpoints, the primitives that power Heroku features like Pipelines and Fork are now available to developers using the Platform API. This opens up a lot of exciting possibilities for partners and hackers to build and innovate on top of Heroku. We will be working with partners to build integrations as we take the API to general availability. Get in touch with friis@heroku.com if you are interested in participating.

The release and slug endpoints are in public beta with the rest of the Platform API. Once we’re confident the API is free of bugs, we will freeze the design and release it into GA. Until that time, we may introduce breaking changes to the API. All changes will be posted in the Heroku Changelog.

If you have any questions or feedback, please start a discussion in the Heroku API Forum.

Crafting Rails 4 Applications; Raspberry Pi

Crafting Rails 4 Applications in print; Raspberry Pi in beta

Programming Google Glass; The Agile Samurai (audio book)

Programming Google Glass; The Agile Samurai (audio book) now available

Why Heroku Adopted a Code of Conduct Policy and Sponsored The Ada Initiative

Editor's note: This is a guest post from Rikki Endsley. Rikki Endsley is a technology journalist and the USENIX Association's community manager. In the past, she worked as the associate publisher of Linux Pro Magazine, ADMIN, and Ubuntu User, and as the managing editor of Sys Admin magazine. Find her online at rikkiendsley.com and @rikkiends on Twitter.

A code of conduct is a signal to attendees that conference organizers have carefully considered the issues involved with attending events, and that they want to make their conference welcoming and safe for everyone. Heroku recently adopted an event sponsorship policy that shows that the company recognizes the importance of formal codes of conduct. By announcing its new code of conduct policy, Heroku plans to help cultivate a more inviting and diverse community. Sara Dornsife, Director of Developer Marketing at Heroku, says that before agreeing to sponsor an event, the company will verify that the conference has a code of conduct in place. “If they do not, we will introduce them to the Ada Initiative so that they can get help to adopt one. If they refuse to adopt one, we will not sponsor.”

Events Should Be Fun and Informative

Sara runs the events team at Heroku, which organizes, sponsors, attends, and sends speakers to a range of tech events each year. Recently she worked on developing a code of conduct policy with Heroku colleagues — Shanley Kane, Jacob Kaplan-Moss, Matt Zimmerman, and Dominic Dagradi.

The Heroku team decided to work with the Ada Initiative to develop the new policy. “I have been really impressed with Ada,” Sara says. “They have taken it on themselves to create clear and fair codes of conduct for conferences and to work with organizers to adopt them.”

Matt Zimmerman, Vice President of Engineering at Heroku (and former member of The Ada Initiative board of directors and former advisory board member), says that working on the Heroku code of conduct policy provided an opportunity to connect his personal passion with his work.

Following PyCon's Lead

Jacob Kaplan-Moss, Django web framework co-founder and a core contributor, joined Heroku in May 2013 as the Director of Security. In November 2013, he also joined the Ada Initiative advisory board. Although Jacob's role on the advisory board is new, his support for the Ada Initiative is not. In fact, in August 2013, Jacob called on the Python community to raise $10,000 to help support the non-profit, and he ponied up $5,000 in matching funds. The Python community accepted the challenge and chipped in the initial $5,000 in only 27 hours.

Jacob isn't new to the idea of adopting a code of conduct policy for events, either. Back in August 2011, Jacob announced a new personal code of conduct policy for attending and speaking at tech conferences. “I’m proud that PyCon, the conference I help organize, has adopted and published our own code of conduct.”

According to Jacob, PyCon adopted a code of conduct in 2011. Back then, women made up about 1-2% of attendees, whereas the 2013 event included approximately 20% women. Although the code of conduct policy isn't 100% responsible for the increase in participation by women, Jacob says it's a vital part in making community events safer for all attendees.

With his PyCon experience in mind, Jacob was eager to help Heroku adopt a code of conduct policy. “Heroku supports a lot of developer events,” he says, “And I think as a company, we have similar concerns to those I have as an individual and organizer. We want to be involved with events that attract and support as wide a range of attendees as possible, and we want the events we support to be safe and fun for everyone.” Jacob jumped at the chance to help get Heroku involved in promoting and support codes of conduct as 'table stakes' for a tech conference.

“A code of conduct sends a strong message that inappropriate behavior will be taken seriously, and that victims will be treated with respect. Codes of conduct aren't the end of the things we can — and should — do to help make our communities more welcoming and diverse, but they're an easy, powerful first step in the right direction.”

“Although a code of conduct is quickly becoming table stakes for modern programming conferences, every action, no matter how small, that supports and reinforces equality and accessibility is an important step toward an all-around healthier community,” says Dominic Dagradi, an engineer on the Web Apps team at Heroku.

Helping to Foster Change With The Ada Initiative

Heroku has thrown additional support behind the Ada Initiative efforts by contributing $10,000 and becoming a corporate sponsor. “The great part about sponsorships like Heroku's is that they let us do higher-impact projects that take longer to plan and serve women around the world,” says Valerie Aurora, co-founder and Executive Director of the Ada Initiative. For example, the Ada Initiative plans to host several international AdaCamps in 2014. “At each AdaCamp, we spend a significant part of our budget on travel scholarships to give women that initial leg up in open tech/culture that makes such a difference to whether women stay or drop out,” Valerie says. “However, we always get more excellent applications than we have travel scholarships, and sometimes people can't get the necessary visas even when they get the scholarship.” She says that most AdaCamp sponsors are more likely to sponsor a local conference near where their employees work. “When companies like Heroku sponsor the entire Ada Initiative, it makes it much easier for us to do long-term international outreach like this.”

Contributions like Heroku's corporate sponsorship also help fund the Ada Initiative's on-going work reducing harassment and increasing the diversity of speakers and attendees at conferences. Three years after its founding, The Ada Initiative is making a major impact in open tech/culture companies, Valerie says. “A crucial part of its success is that the Ada Initiative provides support and advice to conference organizers and sponsors one-on-one, through phone calls, emails, and in-person meetings. We answer questions about training staff, give advice on travel scholarship programs, review conference materials to make them more welcoming, and much more. Without this immediate support and advice, many conference organizers would not have made these changes, which is one reason why earlier similar projects using volunteer effort fizzled out. And without sponsorship, we wouldn't be able to provide this kind of professional expert support.”

Heroku supports a range of tech organizations and events, but before asking the company to sponsor your tech conference, make sure you meet their new requirement. “If you are interested in Heroku sponsoring your event, make sure you have a code of conduct in place,” says Sara Dornsife. “If you do not have a code of conduct, the Ada Initiative can help. If you refuse to adopt a code of conduct policy, we will not be sponsoring your event.”

You can find Heroku's Conference and Event Policy and code of conduct here.

Contact Us

If you have a code of conduct in place and want information about Heroku event sponsorships, contact events@heroku.com.

If you need help with creating your event's code of conduct policy, or to contribute to the Ada Initiative, visit: https://adainitiative.org.

Announcing a new and improved Node.js Buildpack

Last week we released a new version of our node buildpack that features dependency caching, faster downloads of the node binary, and support for any recent version of node. This new build process is now the default for all node apps on Heroku, so keep deploying your apps as you normally would and you should start to notice the speed improvements.

Faster Deployments

The new buildpack makes use of a build cache to store the node_modules directory between builds. This caching can mean dramatically reduced build times, particularly in cases where your modules include binary dependencies like pg, bson, or ws.

We've also shaved time off the build process by caching precompiled node binaries on our own S3-backed proxy of nodejs.org/dist.

Some observant users noticed the performance improvements right away:

More Versions of Node

Your apps can now run any recent version of Node.js on Heroku, including unstable pre-release versions. As of this writing, that includes all versions from 0.8.6 up to 0.11.9.

To automate the process of version discovery, we created semver.io, an open-source webservice that aggregates version information from nodejs.org/dist and makes it queryable by the buildpack. This eliminates the need for manual intervention each time a new version of node is released.

To see what versions of node are currently available at any given time, visit semver.io or what-is-the-latest-version-of-node.com. This information is also available on Heroku's Dev Center.

Custom Registry Support

The public npm registry has seen immense growth in recent years, and with that has come occasional instability. As a result, many node users are seeking alternatives to the public registry, either for the sake of speed and stability in the development and build cycle, or as a means to host private node modules.

As of today, you can include a .npmrc file in the root directory of your node app and the new buildpack will honor it when running npm install. The .npmrc file lets you configure npm to download modules from your own private registry, a European mirror, or otherwise.

A Cleaner Codebase

Clean, commented code is key to the success of any open-source project. A tidy codebase lowers the barrier to understanding, and increases the likelyhood of useful community contributions. With nearly 600 forks on GitHub, clean code is of paramount importance to the buildpack's future success and adoption. The new buildpack has a lighter footprint, fewer dependencies, and lots of comments.

Product Feedback

About 3 months ago, we announced the beta version of the buildpack on the new Heroku Discussion Forum, asking node developers to try the new buildpack and give feedback. The forum proved to be a great tool for collecting insight from users, and soliciting feedback in a public forum meant fewer redundant bug reports and feature requests from users.

The beta period is now over, but we'd still love to hear your thoughts.

Thank You

Thanks to all the brave hackers who tested the new buildpack on their apps, found bugs, provided useful feedback, and submitted pull requests. Here's to the future of Node.js!

A Patch in Time: Securing Ruby

There have been thousands of reported security vulnerabilities in 2013 alone, often with language that leaves it unclear if you're affected. Heroku's job is to ensure you can focus on building your functionality, as part of that we take responsibility for the security of your app as much as we're able. On Friday, November 22nd a security vulnerability was disclosed in Ruby (MRI): CVE-2013-4164 . Our team moved quickly to identify the risk to anyone using the Heroku platform and push out a fix.

The vulnerability

The disclosed Ruby vulnerability contains a denial-of-service vector with the possibility of arbitrary code execution as it involves a heap overflow. In a denial-of-service attack, a malicious individual sends your app requests that either causes the system to lock up or become unresponsive. When multiple people or systems do this, it becomes a distributed denial-of-service attack (or DDoS).

A denial-of-service attack can vary in damage depending on how crucial uptime is to your app. For example if your app brings in a significant amount of money every hour, an attacker could cost you a large sum by bringing your service down.

In this case, the denial-of-service was particularly easy to execute, making this a potentially devastating attack to some users. In addition, because this attack triggers a heap overflow, there is also a slim theoretical possibility of a much more serious vulnerability, an arbitrary code execution. We could not rule out the possibility of arbitrary code execution even though there is no known way to achieve it through this vulnerability.

The fix

When the vulnerability was announced, patched versions of Ruby 1.9.3, 2.0.0, and 2.1.0 were made available from Ruby core. Heroku’s Ruby Task Force pulled in the latest versions, compiled them and after running tests to confirm their compatibility with the platform released updated versions of 1.9.3, 2.0.0, and 2.1.0. Any new pushes to the platform receive these patched versions.

Some have asked why we didn’t automatically force-update all Ruby apps. First, Heroku will not re-deploy a user’s app without their direct knowledge or action. Additionally, since some upstream dependencies may have changed since an app’s last deploy, we also want to maintain erosion resistance by only changing components on an explicit push.

In addition to building and deploying the fixed versions of Ruby, we:

We also did something unprecedented in the history of Heroku: patched and released two unmaintained language versions, Ruby 1.8.7 and 1.9.2.

Unmaintained Ruby versions

The Ruby 1.8.7 version has been at the End of Life for months, which means that the Ruby Core team will no longer issue bug or security fixes for the language. However, developers are still using it actively in production. Ruby 1.9.2 is currently unmaintained, though this status has not been formally announced.

While security patches were not made available for Ruby 1.8.7 and 1.9.2, Ruby engineer Terence Lee discovered that he could cleanly apply the security fix to both versions. The source for these are available on Heroku's fork of Ruby: 1.8.7p375 and 1.9.2p321. He then built, tested, and released these versions on Heroku’s Cedar stack. Terence recently got commit access to Ruby core and is currently working on pushing the changes upstream even though the two versions are technically unmaintained.

Terence’s actions give you a longer runway but developers using Ruby 1.8.7 or 1.9.2 must upgrade as soon as possible. Heroku recommends upgrading to Ruby 2.0.0 or at very minimum 1.9.3. Matz has stated that support for 1.9.3 will likely be dropped within a year. Heroku’s Bamboo stack runs Ruby Enterprise Edition which has been at end of life since early 2012 and was not patched. Bamboo users should upgrade to the Cedar stack to stay secure.

Staying on a current version is crucial to being able to iterate quickly and respond to vulnerabilities. For example, the Chrome web browser auto updates in the background, and recently Apple software has moved their Mac and iOS app stores to this model. Using updated software provides benefits to a maintainer: less fragmentation and less time spent supporting legacy versions. This means more time for features, performance, and compatibility.

The Rails web framework only supports Ruby 1.9.3+ for their 4.0.0 release, and it is rumored that they will be supporting only 2.0.0+ for their 4.1.0 release. Without dropping support for older syntaxes, developers cannot utilize new ones. As a language user, staying current means you have access to the latest features, latest security updates, and most active language support. For all these reasons, we want to encourage Heroku users to regularly upgrade and stay up-to-date.

The ending of support for Ruby 1.8.7 and 1.9.2 are interesting events for Heroku: they represent the first time a technology used on the platform became unmaintained by its core developers. While we have extended the period you are secure on these unmaintained versions, we have not made a commitment to maintain either Ruby 1.8.7 or 1.9.2 indefinitely. We know that these environments are still in use, and want to make sure customers have ample time to upgrade. We’re working to make Heroku’s Ruby version support commitments and timelines explicit, and will publish documentation to that effect.

Security Matters

For Heroku’s security team, communication is as much a concern as technical fixes. When communication breaks down, so does security. This year we’ve seen several large vulnerabilities that required notifications for languages, frameworks and tools including a Postgres patch and the Rails YAML vulnerability. We’re working on better ways to notify affected application owners. In this incident, we sent notifications to all Ruby application owners even if they were running JRuby or Rubinius, runtimes that were not affected. In the future we aim to be able to dial up our signal-to-noise ratio on security notifications, and even be able to provide app-specific information quickly and securely. If this sounds like fun, our Security team is hiring.

If you’re using Ruby on the platform, be sure to take advantage of the fix as soon as possible. If you’re depending on an older, unmaintained version of Ruby, upgrade as soon as possible. If you’re maintaining your own versions of Ruby, make sure you update and re-compile.

If you’re running on Heroku, sleep well knowing that we care about your security.

Batkid Saves the Day in SF

Editor's Note: This is a guest post from Jonathan Cipriano, creative developer based in San Francisco currently working as a Creative Research & Development Manager at AKQA.

A few weeks back, the Make-a-Wish Foundation made a 5-year old cancer survivor named Miles dream come true by helping him play out a Batman-style adventure in San Francisco. The city was morphed into Gotham for a day with the help of 12,000 volunteers. A rescue mission turned the pint-sized crusader into a social media sensation. Miles became Batkid for a day.

Inspired by his story, some creative devs at AKQA thought it would be fitting to memorialize the heroic event with an interactive comic book, thebatkid.com and created it on Heroku.

The Batkid Lives On

By using images of the #SFBatkid shared through Instagram, Twitter, Facebook and Flickr, our creative team chronicled Miles' adventure as he raced from rescue to rescue, saving the city from crime and earning himself a key to the city from Mayor Ed Lee himself.

RequestReturn

To best tell Miles’ digital story in a timely and seamless way, thebatkid.com needed to be designed and developed within a few days using a platform that could be easily managed without significant knowledge of server setup and configuration. Naturally, Heroku was an automatic choice. We have all of our source code on GitHub and we were able to deploy the site with custom DNS in literally minutes. With the Heroku CLI, deploying an application only takes 2-3 commands in the terminal.

Node.js is becoming very popular with us for rapid prototyping. The learning curve is super low for front-end developers who already know javascript well. The availability of node modules also enables developers to get a running application in no time. For thebatkid.com we developed a small node.js application to aggregate all of the incoming Twitter photos that we would potentially use in the comic. Following the Getting Started with Node.js tutorial we had the express.js application developed and deployed within a few hours.

What we ended up creating is something that is actually very simple technically speaking. However, from our experience, even simple projects can suffer if you can't get them live when you need it to. Heroku allowed us to get up and running quickly without the dev-ops overhead, so we could just concentrate on creating a cool comic book for Miles Scott (aka The Batkid).

CREDITS
Art Director: John Ta, Michael Dooley, Ben Pang
Copywriter: Keith Hostert, Alex Gavin
Developer: Mikko Tormala, Jonathan Cipriano

Programming Minecraft; Remote Pairing; PragPub; Secret Santa!

Programming Minecraft in beta; Remote Pairing in print; December PragPub; Secret Santa program!

Message Queues, Background Processing and the End of the Monolithic App

Editor's note: This is a guest post from Ken Fromm and Paddy Foran at Iron.io. Iron.io's services are designed for building distributed cloud applications quickly and operating at scale.

Platform as a Service has transformed the use of cloud infrastructure and drastically increased cloud adoption for common types of applications, but apps are becoming more complex. There are more interfaces, greater expectations on response times, increasing connections to other systems, and lots more processing around each event. The next shift in cloud development will be less about building monolithic apps and more about creating highly scalable and adaptive systems.

Don’t get us wrong, developers are not going to go around calling themselves systems engineers any time soon but at the scale and capabilities that the cloud enables, the title is not too far from the truth.

Platforms as Foundation

It makes sense that platforms are great for framework-suited tasks – receiving requests and responding to them – but as the web evolves, more complex architectures are called for, and these architectures haven’t yet evolved in an equivalent manner as all encompassing framework-centered applications.

By way of example, apps are rapidly evolving away from a synchronous request/response model towards a more asynchronous/evented model. The reason is because users are demanding faster response times and more immediate data. Also, more actions are being triggered by each event.

Rather than thinking of the request and response as the lifecycle of your application, many developers are thinking of each request loop as just another set of input/output opportunities. Your application is always-on, and by building your architecture to support events and process responses asynchronously and highly concurrently, you can increase throughput and reduce operational complexity and rigidity substantially.

RequestReturn EventFlow

Building N-Tier Applications

The traditional framework-centered application is a two-tier application. You have an application tier, which runs your application’s software, and then you have your database servers, which store your data. At some point, you might start adding background processing that hands off of your application tier.

Cloud applications, however, are quickly moving away from this traditional two-tier architecture that then starts growing organically out of need towards a proper n-tier architecture at the onset. These additional tiers – the specialised components that help an application escape the request/response loop – provide alternative computing, storage, and process orchestration to handle the growing set of response needs.

TwoTier NTier

Independent processing components operation in the background, for example, might make use of these resources to perform specific actions – resizing images, sending emails and notifications, creating a bridge or buffer between processes, or doing any sort of variable-length processing.

Message queues often form the backbone to help orchestration these event actions. They have usually been introduced after the first generation architecture when an app needs to expand and scale. In brief, they provide asynchronicity, task dispatch, event buffering, and process separation. But they are such basic components – the High Scalability blog likens them to an arch or beam in building design – that they should be built into architectures from the start.

Incorporating additional computing resources into your IT stack ensures you not only have immediate scalability at hand but also a robust mesh of response services that communicate over loose APIs. This allows you to swap out, modify, or upgrade individual processes and computing modules at will – even while your application is running – without affecting other components.

Decoupling Your Application

Once you decide to move away from a monolithic application to an n-tiered one, the process of actually converting the application can be as gradual or as abrupt as you like. Because each piece speaks its own informal API, and doesn’t care about the other pieces, it makes no difference whether you overhaul your application all at once, or slowly transition it piecemeal.

The general rule of thumb for determining whether a piece of functionality should be broken out of the main application is “Is it absolutely necessary that the user wait for this action to be completed before we can give them a response?”

Things like resizing images, scraping web pages, and interacting with APIs take a long, sometimes variable, amount of time, so you shouldn’t make the user wait for them. They’re good candidates for being broken out into their own processing elements.

Offloading

Once you’ve identified these elements, then reduce them to reusable pieces but have them operate independent of any other pieces. Right from the start you’ll want to loosely connect these “services” using message queues and worker systems. The benefit is each service will be independent of any other processes and so they can more easily change and adapt without adversely impacting other parts of the system. Events can be routed to multiple message queues so that additional actions can easily and transparently be added to specific events. Message queues also create buffers so that differences in processing throughput among the components can be handled efficiently and allowing each worker class to be scaled out independently.

Breaking things down into components will depend on the specific functionality, but there are a few tools you can use:

Workers

Workers provide the muscle in these distributed systems; they are the processing power that actually gets things done. Workers generally provide for custom-built environments that only survive for the duration of the task – whatever work needs to be done, like resizing a single picture. Then the environment is destroyed, and rebuilt for the next task.

The benefit of workers are their flexibility; because they’re highly reproducible and self-contained, workers can be scaled effortlessly to meet demand. The weakness of workers that needs to be architected around is their startup costs; because each task requires a new environment to be built, it can be expensive to set up complex environments. To work around this, we recommend batching tasks into groups that can be performed in the same environment.

Patterns

The other thing customers usually need to wrap their heads around is that tasks don’t get executed immediately – they’re things that will happen at some point in the future. While there are some user-visible actions that it’s okay to offload to workers – forking GitHub repos, for example, happens in a worker – generally you want to keep actions that the user specifically requests in the request/response loop.

IronWorker, Heroku Worker Dynos, Celery, and Sidekiq are good options to look at for building workers into your architecture.

Message Queues

Message queues are the bonds that tie distributed architectures together. They’re used to transmit data between the component parts of the architecture. The general concept is that chunks of data (messages) are put into a group (a queue) then removed from that group in a predefined order, either FIFO (first in first out) or FILO (first in last out). Message queues generally come in two flavours: pull queues and push queues.

MessageQueue

Pull queues are queues that ask clients to periodically check for messages on a queue. If a message is found, the queue will give it to the client and remove it from the queue. If a message is not found, the client just tries again after a set period of time. Pull queues are great for data flows that are heavy or consistent, because there’s a high chance that the request will yield a message, not a waste of bandwidth and processing power, but the queue won’t bring down the client by delivering more messages than the client can handle.

Push queues are queues that inform subscribers when a message is added to the queue. This means that data is processed more promptly, because subscribers know about it immediately, but it also means that the queue and client have to do more work, sending and receiving the data. Push queues are great for data flows that are sporadic, because the data comes infrequently. Knowing about the data as soon as it comes is worth the tradeoff of the minimal increase in extra processing.

IronMQ, Beanstalkd, and RabbitMQ are good options for message queues that will connect your architectures.

For more information on uses of a message queue, check out this post on Top 10 Uses of a Message Queue.

Key-Value Datastores

Key-value datastores are the simple memory and counters behind distributed systems. They’re used to store and index the data that workers create or need. The difference between a key-value datastore and a queue is that queue data is tied to a specific task – it’s meant to be processed once, then forgotten.

Patterns

Key-value data typically lives outside of the task lifecycle – it can be shared between many tasks and survive after processing. This is useful for storing results or communicating shared information that is not task-specific. The benefit of caches is that they provide an easy, predictable interface for accessing and storing data. The drawback is that not all caches are concurrency-safe, so it’s possible to corrupt data if two or more clients are trying to write to the same key at the same time. This can be architected around by generating IDs that will only be used by a single client, but it’s something to keep in mind.

IronCache, Memcached, and Redis are good options for datastores that will keep your data handy and safe while you process it or share data between tasks.

The Right Tools | The Right Services

The large marketplace of cloud applications that have integrated with Heroku as add-ons are indispensable tools in this kind of architecture. These single-minded components require no standup or provisioning, and they also require no maintenance from the developer. They just work.

Besides the peace of mind this buys – which, in its own right, is worth it – this specialization allows the services to be specialised and feature-rich, moreso than if they were all implemented by the developer. Orthogonal, flexible components are hard to make, and diluting a developer’s attention with the plumbing will detract from their application – the thing they actually care about making.

At Iron.io, we’re big fans of using elastic cloud services as components. Our mindset from the beginning as early cloud developers has been to use service components wherever possible, so as to focus on our core competencies. It’s probably not surprising that we ended up making cloud services for other developers to use.

Start breaking your monolithic apps into their composite pieces today. You’ll be glad you did. And if you need help, read more about loose-coupled architectures and strategies on the Iron.io blog or check-in with us at the Iron.io chatroom. Our engineering team is always happy to talk about scalable architectures.

Searchlight and CanCan

I’m currently working on a client project where site adminstrators use
the same UI that site users do, so there are permissions checks in the
views and controllers to ensure the current user has the right to do or
see certain things. CanCan provides the access control, which takes
care of most of the issues with a simple can? check or
load_and_authorize_resource.

In one case I wanted to provide search on a list of items (the index
action) to admins so they could search through all items in the database, but users
should be able to only search on their own items. I’m using Searchlight
(highly recommended) for search, which returns results as an
ActiveRecord::Relation, so it’s easily chainable via CanCan, like so:

class InvoicesController < ApplicationController
  def index
    @search = InvoiceSearch.new(params[:search])
    @invoices = @search.results.accessible_by(current_ability, :index)
  end
end

Searchlight is also smart enough to return all results if there no
search params provided, so this also works as a typical index action
that lists all items the user can see. If you’re curious about the
@search instance variable, that is used in the search form in the
index view.

So, if you need search with access control, use Searchlight and
CanCan… they are a great combo!

oh-my-zsh reaches over 500 contributors

Earlier today, I noticed that we now have over 500 developers from around the globe who I have accepted pull-requests from1. That is so fantastic.

<img src="http://robbyonrails.com/files/505contributors-1.jpg" alt="" />


Thanks to each and every one of you who has helped make this project so wonderful for others. :-)


<p id="fn1"><sup>1</sup> This number could be a lot higher if I spent more than a hour or two a week on this, but I&#8217;m a big fan of slow and steady&#8230; a good number of the open pull-requests are themes at the moment.</p><div class="feedflare">