A Tour of Dashboard

When you sign into Heroku from your browser, you’re in the Heroku Dashboard. Dashboard is a personalized, interactive command center for all of your apps on Heroku. It provides simple visibility and management for app status, activity, resources, add-ons, collaborators, and other critical aspects of your app. You can also use it to manage all information about your Heroku account – from SSH keys to past invoices. In this post, we take a quick tour through Dashboard and some of its recent new features, including production check and notifications.

Everything About Your Apps

The first thing you'll see when you log in to Dashboard is the Apps page. Here, you can see a full list of all the apps you own or are a collaborator on – whether you have just one app or a whole portfolio you are working on. If there are pending collaboration requests, such as a request to transfer your app, that will appear as well.

Dashboard

Use the search bar to easily locate a particular app in a long list. Favorite an app by clicking on the star – it will appear at the top of your list for easy access.

The app icons next to each of the app names provide additional information about your app, such as if it isn’t currently running, or if the app is sleeping (apps with one dyno will “sleep” after one hour without any web traffic).

You can also create an app directly from Dashboard. Simply click on "Create a New App", enter the app name (or let us pick one for you) and pick the region you want the app to live in. You'll get a remote Git repository to push code to and a unique URL on Heroku, just as if you'd used heroku create from the CLI.

Dashboard

Dashboard also lets you drill into each app for more detailed visibility and management. Just click into the app on the apps list, and get a control panel for its resources, activity, collaborators and settings.

Dashboard

Resources will show you dynos your app is consuming, as well as their process type, be it worker, web, queue or something else. You can even scale dynos directly from the interface. View all add-ons in use by the app, or add even more add-ons through the interface. Under Activity, see all releases made to your application, who made them, and when, to get immediate insight into recent changes. You can even use the Dashboard to rollback to a previous release in the event of a bad deploy. Collaborators will show you everyone who is a collaborator on the app, and even let you add additional collaborators. Finally, in Settings, set custom domains, find out the repo size, and see critical information about your app including its Git URL and region.

Dashboard

Production Check and Notifications

We've been working hard at bringing more awesome functionality into Dashboard. The two newest features are production check and notifications center.

Once you're viewing an app in Dashboard, use production check to run a series of tests on your app that we recommend for maintaining and monitoring availability – such as appropriate DNS configuration, dyno redundancy, and app and log monitoring.

Production

The Notifications Center is in the top right of your dashboard and delivers events that are relevant to you and your app – like new platform defaults, changes in add-on state, and modifications to billing.

Notifications

Account Information

Finally, the Account section, which you can access through the dropdown menu on your user icon, lets you see and change lots of relevant account information – from basics like your password, name and email, to billing information, current usage and previous invoices. You can also use the settings section to add SSH keys, and to see all 3rd party applications built on the Heroku Platform API that have access to your account. You can revoke them right from the interface if you decide to revoke access.

Account

Feedback and Feature Requests

We'd love to hear what you think in the comments below. Curious about new things we're working on for Dashboard? Join our beta program to get early access and provide feedback.

101 Design Ingredients to Solve Big Tech Problems now in print

101 Design Ingredients to Solve Big Tech Problems now in print

Releases and Rollbacks

Heroku tools let you create robust, healthy workflows for your apps, from development to production to ongoing delivery. Add other developers to your app with heroku sharing, create homogeneous staging and production apps with heroku fork, and quickly deploy directly from staging to production with pipelines.

Deploying quickly and often is awesome, but with multiple developers and multiple deployments each day, how do you see and manage changes to your app over time? And what happens if you accidentally deploy bad code?

We address these issues with two aspects of the Heroku platform – heroku releases and heroku rollback. heroku releases brings simplicity and visibility to application changes, letting you see releases made to your app, who made them, and when they occurred. With heroku rollback, you can rollback to a previous, known good release in a single command – providing a fast way to revert in case of bad deploys or config changes. In this post, we give a quick overview of releases and rollbacks on Heroku and how to use them.

Releases

Anytime you deploy code, change your config vars, or add, remove, upgrade or change an Add-on resource, Heroku creates a new release and restarts your app with the changes you made.

To see the history of releases for an app:

$ heroku releases
Rel   Change                   By                    When
----  ----------------------   -------------------   -------------
v52   Config add AWS_S3_KEY    shanley@heroku.com    5 minutes ago
v51   Deploy de63889           kendra@heroku.com     7 minutes ago
v50   Deploy 7c35f77           katie@heroku.com      3 hours ago

The deploy string – in the above example, de63889 – corresponds to the commit hash in your Heroku remote git repository. Use this to correlate changes in a release with changes in your code repository. Call git log -n 1 de63889 to get more detailed information on the commit, including the full commit hash, exact timestamp, and commit message.

You can get additional details on the release, including Add-ons present and config, by calling heroku releases:info vNN, where NN is the release number. Whenever a new release is created, NN is incremented and the release recorded on an append-only ledger. For example:

$ heroku releases:info v24
=== Release v24
Change:   Deploy 575bfa8
By:       shanley@example.com
When:     6 hours ago
Addons:   deployhooks:email, releases:advanced
Config:
  MY_CONFIG_VAR  => 42
  RACK_ENV       => production

Especially for apps that have several or many collaborators, release history helps teams work together with less friction and more visibility. When you start working each day, use release history to see what changes have been made to the app while you were away. Quickly look up commit information in the git logs for additional context. Check the release history before deploying changes to avoid a redundant commit or other error. And if something goes wrong, audit the release history to identify when bad code may have been rolled out.

Rollbacks

A release is more than just metadata about your app's history – it’s everything needed to run that version of your app. It consists of a full copy of any given releases’ config vars and its slug – a bundle of your source, fetched dependencies and compiled/generated output of the build system, ready for execution. This means you can rollback to a prior, known good version of an app quickly – no re-compilation is required. In the event you deploy bad code, use heroku rollback to restore the previous release. This lets you maintain uptime for your app even when things go wrong, and gives you time to fully dig into the problem and accurately diagnose and remedy it.

To rollback to a specific release, specify the release number:

$ heroku rollback v46
Rolling back test-rollback... done, v46

Your release history will reflect the rollback:

$ heroku releases
v47    Rollback to v46    shanley@heroku.com    2013-07-12 15:32:17 -0700

Note that the state of the database or any external state held in Add-ons used will not be recorded, so you'll have to reconcile that yourself in the case of a bad deployment. Please note that running a rolled-back version of your app is meant as a temporary fix so you can minimize negative impact to your users while you make the necessary changes to deploy a correct version of your code.

Dashboard

Heroku Dashboard provides a useful, beautiful GUI to see all of your apps and view and manage resources, collaborators, settings and more. You can also view release history and rollback directly from Dashboard via the activity tab within each app.

Dashboard

Also in Dashboard, you can link your deploy hashes to GitHub by adding a repository on the settings page for your app. Then just click on the deploy hashes in the activity logs to see the full changelog on GitHub!

Happy Workflows

Combined with tools like fork, pipelines and collaborators, heroku releases and heroku rollback make for faster, safer and more flexible workflows. Releases gives you full visibility and history into your application, while rollbacks means you can recover quickly from accidental bad deploys with minimal impact to your users. For more information on releases and rollbacks, make sure to check out the Dev Center.

This Month in Ruby: PeepCode Acquired, Rails 3.2.14, And More

Welcome to a roundup of Ruby news, articles, videos, and more, for July 2013 cobbled together from my e-mail newsletter, Ruby Weekly.

Highlights include: PeepCode acquired by Pluralsight, Practicing Ruby archives made public, Rails 3.2.14, and an interesting interview with Matz.

Featured

The First Four Volumes of Practicing Ruby, Now Available Online
Practicing Ruby is a high quality, paid Ruby journal run by Gregory Brown, but he’s made archives of over 60 articles available to the public. There’s a ton of stuff to enjoy here.

PeepCode Acquired by Pluralsight
Ruby and Rails screencasting pioneer Geoffrey Grosenbach has announced he has sold Peepcode to Pluralsight, a large online training provider.

The Plan for RSpec 3
RSpec 2.0 was released in October 2010 and RSpec 2.14 will be the last RSpec 2 feature release. Work on RSpec 3 has begun and Myron Marston shares what’s going to be involved.

Rails 3.2.14 RC1 and RC2 Released
A variety of bug fixes for Rails 3.2 arrived in 3.2.14 RC1 with one minor regression fixed in RC2. Final due soon.

The Future of Computing – An Interview with Matz
Last year, Ruby’s creator Yukihiro ‘Matz’ Matsumoto released a book called The Future of Computing (only in Japanese, I believe) and did an interview with a Chinese publisher. Fred Wu has translated it into English.

RSpec 2.14 Released
Myron Marston unveils the last 2.x feature release of the popular spec framework and announces work is well underway for the future RSpec 3. 2.14 includes a new feature called ‘spies’ which is shown off here.

Functional Programming and Ruby
At GoRuCo 2013, Pat Shaughnessy gave a 40 minute talk comparing Haskell (a functional language) to Ruby and looked at how to implement common functional patterns in Ruby. Well explained and backed by good slides.

Reading

Streaming with Rails 4
Saurabh Bhatia looks at Rails 4’s support for live streaming (the ability to send partial requests out to the client on the fly).

Reading the Ruby Source to Understand Rails Idiosyncrasies
I’m not sure you always need to dig quite so deep but Eno Compton takes an interesting journey through MRI’s source code to see the difference between Range#cover? and Range#include?

Speed Up Heroku Deploys
Alex MacCaw was suffering from slow deploys to Heroku but he found a workaround.

Shoes 4 – A Progress Report
Shoes was a graphical toolkit put together by Why the Lucky Stiff that made it simple to create GUI apps in Ruby. Since Why disappeared, others have picked up work on it, and Shoes 4 is set to be a complete rewrite.

Put Yourself on Rails with A Push of A Button
A technique for quickly bringing up a workspace for doing Rails work (including terminals, a Rails console, a Rails server, etc.)

Multitenancy with Rails: An E-book by Ryan Bigg
Ryan Bigg, of Rails in Action fame, is writing an e-book about building a multi-tenanted Rails app.

Incremental Redesign with Rails
Lars Klevan shows how to use prepend_view_path to make in-progress redesigns on a production codebase simpler.

How to Declutter Your ‘lib’ Directory
If you have an established Rails project, its ‘lib’ folder might be getting a little full. Kuba Suder looks at ways to clean it up and put things elsewhere.

Design Patterns: The Template Method Pattern
An introductory Ruby-oriented look at arguably the simplest design pattern.

Object Oriented Rails: Writing Better Controllers
Damien Le Berrigaud of Pivotal Labs tries to avoid stubs and mocks and leans on dependency injection to test his controllers’ code.

Vimscript And You
HashRocket’s Jonathan Jackson demonstrates how you can use RSpec against Vim to aid in the development of a Vim plugin with Vimscript.

MotionPhrase: Next Level Localization for RubyMotion Applications
PhraseApp is a translation management tool for producing multilingual Web sites, Rails apps, etc, but it also works for localizing RubyMotion apps too, as demonstrated here.

Ruby’s Eigenclasses Demystified
Andrea Singh looks at Ruby’s quirky ‘eigenclasses’ (a.k.a. metaclasses) and explains things in both code and diagrams. Dates from 2011 but worth revisiting.

The Self-Pipe Trick Explained
Jesse Storimer shows off a cute Unix trick/technique in Ruby.

Practical RSpec Wrapping
Why would you want to use around hooks in RSpec? Dru Riley explains.

Using PostgreSQL’s ‘hstore’ in A Rails Application on Engine Yard Cloud
If you want to take advantage of schemaless features without abandoning your relational database, using ‘hstore’ within Postgres is a great option. Here’s an introduction on using the hstore PostgreSQL extension in a Rails app.

Implementing Subdomain and Custom Domain Support in Rails
A look at how one development team implement subdomain and custom domain features in their Rails app.

Events

dotRB: The Largest Ruby Conference in France (October 18, Paris)
Following on from a successful ‘dotJS’ JavaScript event comes dotRB. Announced speakers so far include Steve Klabnik, Konstantin Haase, and Brian Ford.

Watching

11 Talks from La Conf Paris
Some big names to enjoy here including Yehuda Katz, Amy Hoy, Sandi Metz, and Steve Klabnik.

Deathmatch: Bundler vs Rubygems.org
At GoRuCo 2013, Andre Arko told the story of the quest to make ‘bundle install’ faster.

How to Set Up RSpec
A well produced 6 minute screencast.

To Know A Garbage Collector
Mike Bernstein discusses his experiments with MRI Ruby’s garbage collector, his investigations into other languages and the influence of their GC implementations, the history of the subject, and more.

Kata and Analysis with Jim Weirich
From RubyConf India 2013 comes a live coding session by the inimitable Jim Weirich where he walks through the popular ‘roman numeral’ conversion kata using TDD along the way.

Aaron ‘tenderlove’ Patterson’s RubyConf India 2013 Keynote
An hour with Ruby and Rails core contributor Aaron ‘tenderlove’ Patterson covering esoteric Ruby stuff and Postgres to career advice and cats. Warning: The audio is rather poor here and cuts out entirely for the second half so don’t waste your time if this will drive you crazy.

5 Minutes of EuRuKo 2013
European Ruby conference (EuRuKo) took place in Athens last month and Clemens Helm has put together a 5 minute collection of clips and insights from the event. Includes Matz, Xavier Noria, Benjamin Smith, Pat Shaughnessy and Steve Klabnik.

Nokogiri: History and Future
Nokogiri is the most popular way to parse and process XML in Ruby and at GoRuCo 2013, Mike Dalessio gave a short 11 minute talk on the origins of the project, how to determine if it suits you, and looks at some of the tooling around it.

Libraries, Code and Tools

Upton: A Web Scraping Framework
A Ruby-based web-scraping framework that abstracts away the common parts of web scraping so developers can concentrate on the unique parts of their project.

LanguageFilter: Detect and Optionally Filter Multiple Categories of Language
Wave goodbye to sex, hatred, profanity, violence, etc, in your app.

Lita: A Ruby Chat Bot with Redis-based Storage
Can be twisted to work with any chat service and extended with plugins.

Pkgr: Make A Debian Package Out of A Rails App in 5 Minutes
A high-level tool that turns Rails applications into native Debian packages.

Flynn – Open Source Platform As A Service, Powered by Docker
Flynn is an as-yet-unreleased Heroku-inspired system to simplify deploying and maintaining apps. Instead of using complex config management systems, Flynn allows self-serve management of containerized deployments. The creator is currently trying to raise money to work on the project.

Jobs

Software Craftsperson at Bendyworks
If you’re the type of person who learns new languages as a matter of course, contributes to open source for fun, and ships code with a calm and collected professionalism: you seem like our kind of developer. Join our world-class team in Madison, Wisconsin.

Senior backend- / API-developer at Rabble (Stockholm, Sweden)
Tired of bullshit ads? Help us develop Sweden’s leading app for mobile offers, where customers and businesses meet on equal terms! Join us in the heart of Stockholm to play with geospatial data and Ruby API’s all day long!

Ruby on Rails developer at SupaDupa (London, UK)
We’re looking for an experienced Ruby on Rails developer to join the small team behind SupaDupa.me, an e-commerce platform aimed at creatives. Excited about the challenge of working on the full stack, from front-end dev to system administration? Get in touch!

Ruby Programmer: IT and System Automation
Want to change the future of education? We are trying to build an awesome team that enjoys challenges and results. Interested? Come work with us in beautiful Switzerland.

Ruby Developers at HouseTrip (London, UK)
Want to work with a 18-person team of passionate Ruby developers who love good code and care for their product in central London? We are currently hiring. Ranked by Wired Magazine the number two start-up in London (2012), HouseTrip is Europe’s largest holiday rental booking website!

Last but not least..

ruby -run -e httpd . -p5000
Run a local HTTP server with a single line of Ruby. Just one character longer than the classic python -m SimpleHTTPServer but more obviously flexible (plus, it’s Ruby ;-)).

iCloud for Developers: Automatically Sync Your iOS Data, Everywhere, All the Time

A “FREE” Online Course: Programming the Web with Ruby – 5th batch

Programming the Web with Ruby

Registrations are now open for RubyLearning’s “Pay if you like“, online course on “Programming the Web with Ruby“. The first batch had over 2000 participants. Web-based applications offer many advantages, such as instant access, automatic upgrades, and opportunities for collaboration on a massive scale. However, creating Web applications requires different approaches than traditional applications and involves the integration of numerous technologies. The course topics would hopefully help those that have some knowledge of Ruby programming to get started with web programming (this does not cover Ruby on Rails).

Who’s It For?

Anyone with some knowledge of Ruby programming.

Dates

The course starts on Saturday, 17th August 2013 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.

For those who contribute US$ 15, we shall email them a copy of the book (.pdf) “Programming the Web with Ruby” – 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).

Course Contents

  • Using Git
  • Using GitHub
  • Using RVM (for *nix)
  • Using pik (for Windows)
  • Using bundler
  • Using Heroku
  • Creating a simple webpage using HTML5, CSS and JavaScript
  • Store your webpage files on GitHub
  • Understanding HTTP concepts
  • Using cURL
  • net/http library
  • Using URI
  • Using open-uri
  • Using Nokogiri
  • Creating one’s own Ruby Gem
  • Learning Rack
  • Deploying Pure Rack Apps to Heroku
  • Deploying a static webpage to Heroku
  • Using Sinatra
  • Deploying Sinatra apps to Heroku
  • Sinatra and SQLite3 interaction

The course contents are subject to change.

Mentors

Satish Talim, Victor Goff III, Michele Garoche and others from the RubyLearning team.

RubyLearning’s IRC Channel

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.

Here are some details on how the course works:

Important:

Once the course starts, you can login and start with the lessons any day and time and post your queries in the forum under the relevant lessons. Just to set the expectations correctly, there is no real-time ‘webcasting’.

Methodology:

  • The Mentors shall give you URL’s of pages and sometimes some extra notes; you need to read through. Read the pre-class reading material at a convenient time of your choice – the dates mentioned are just for your guideline. While reading, please make a note of all your doubts, queries, questions, clarifications, comments about the lesson and after you have completed all the pages, post these on the forum under the relevant lesson. There could be some questions that relate to something that has not been mentioned or discussed by the mentors thus far; you could post the same too. Please remember that with every post, do mention the operating system of your computer.
  • The mentor shall highlight the important points that you need to remember for that day’s session.
  • There could be exercises every day. Please do them.
  • Participate in the forum for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Please do not post a simple "Thank you" note or "Hello" message to the forum. Please be aware that these messages are considered noises by people subscribed to the forum.

Outline of Work Expectations:

  1. Most of the days, you will have exercises to solve. These are there to help reinforce what you have just learned.
  2. Some days may have some extra assignments / food for thought articles / programs.
  3. Above all, do take part in the relevant forums. Past participants have confirmed that they learned the best by active participation.

Some Commonly Asked Questions

  • Qs. Is there any specific time when I need to be online?
    Ans. No. You need not be online at a specific time of the day.
  • Qs. Is it important for me to take part in the course forums?
    Ans. YES. You must Participate in the forum(s) for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves (participants) during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Past participants will confirm that they learned the best by active participation.
  • Qs. How much time do I need to spend online for a course, in a day?
    Ans. This will vary from person to person. All depends upon your comfort level and the amount of time you want to spend on a particular lesson or task.
  • Qs. Is there any specific set time for feedback (e.g., any mentor responds to me within 24 hours?)
    Ans. Normally somebody should answer your query / question within 24 hours.
  • Qs. What happens if nobody answers my questions / queries?
    Ans. Normally, that will not happen. In case you feel that your question / query is not answered, then please post the same in the thread – “Any UnAnswered Questions / Queries”.
  • Qs. What happens to the class (or forums) after a course is over? Can you keep it open for a few more days so that students can complete and discuss too?
    Ans. The course and its forum is open for a month after the last day of the course.

Remember, the idea is to have fun learning Ruby.

Acknowledgments

About RubyLearning.org

RubyLearning.org, since 2005, has been helping Ruby Newbies go from zero to awesome!

Technorati Tags: , , , ,


(Powered by LaunchBit)

OAuth for Platform API in Public Beta

In May, we launched the beta Heroku Platform API – making it possible to automate, extend and combine the Heroku platform with other services in a programmatic, self-service way. As of today, OAuth 2.0 support for the Platform API is available in public beta.

With OAuth support, developers building integrations and services that use the Heroku API can provide a much better experience to their users. Instead of requesting full access to user accounts, access requests can be scoped to just the information and control a service needs. Instead of using one API key for all third-party services, users can check and revoke authorizations on a case-by-case basis. And users can manage all of their third-party authorizations within their Heroku dashboard.

API Developers

If you are building a service that uses the Platform API, you should implement OAuth. First, register a client from the account page on Dashboard. You can then incorporate OAuth into your app using OmniAuth, the Heroku Bouncer middleware or another tool of your choice. The Heroku OAuth article has additional details, resources and links to sample apps.

For Heroku Users

With the Platform API, developers can now build awesome services that integrate with Heroku – for example, an iPhone app to monitor apps running on Heroku, or a CI service that can push changes to your apps so your workflow is smoother and more automated. However, these services need access to some or all of your Heroku account to work. OAuth gives you a safe mechanism to control this access. When a service uses OAuth to request access to your account, you will be redirected to id.heroku.com where you can see who is requesting access and the scope of the access requested. Here are the scopes we have implemented so far:

  • global: Full access to account and to control all apps and resources. Equivalent to API key (but revocable).
  • identity: Read-only access to account-info.
  • read and write: Access to read and write info on apps and other resources, except configuration variables. This scope lets you grant access to your apps without necessarily revealing runtime secrets such as database connection strings.
  • read-protected and write-protected: Same as above, but including access to config vars.

Note that the read, write, read-protected and write-protected scopes do not grant access to account identity details such as email address.

Before granting access to a 3rd party service, make sure that you trust that service to access your Heroku account in a way you feel comfortable with. You can see what external services are authorized on the account page on Dashboard or using the authorizations CLI command from the OAuth CLI plugin. You can revoke authorizations at any time using either the dashboard or Heroku CLI.

OAuth gives 3rd parties services safe, granular and revocable access to the power of the Heroku Platform API. We can’t wait to see what new apps and services get built with these technologies.

If you have questions, suggestions or want to show us what you have created, then drop us a line at api-feedback@heroku.com.

Programming Groovy 2 and Developing Android on Android

Programming Groovy 2 in print and Developing Android on Android in beta

Introducing a New How Heroku Works

Humans, in their quest for knowledge, have always wanted to know how things work.

We sit in our bedrooms, kitchens and garages pulling things apart with eager hands, examining the bits with a glimmer in our eye as our fingers turn them around and around, wondering what they do, how they do what they do–hoping that everything still works without that pretty residual part that no longer seems to fit.

Introducing How Heroku Works

How Heroku Works follows this well trodden path. It dissects the platform, laying its innards bare upon the table, letting us gather around and look at what's inside.

Look here, and see the muscular router pumping packets to and fro. Look there, and see the dyno manager in all its glory, effortlessly orchestrating the platform.

Look yonder and see the database's WAL-E continuously archiving data bits.

And there, behold the dynos: like mitochondria they are the powerhouse of the platform, running your applications.

History

Like Galen's contributions to an early understanding of the human circulatory system, Heroku's venerable How it Works diagrams have been instrumental in advancing our understanding of Heroku.

image

This monument to progress provided a pioneering map of the Heroku platform. Etched with a surgeon's eye, its stylish and sleek lines drew praise from around the world, while its descriptive text provided some solace to those wanting to know more, wanting to understand how it worked.

Going forward

But we were left wanting. How, really, is the foot bone connected to the leg bone? How, really, is my code transformed from a git push into a slug into a release into something that executes, making use of config vars and third-party add-ons whilst unifying logging via logplex, all running on set of dynos, controlled by a dyno manager?

How Heroku Works is intended to answer these questions.

The article provides a high-level, accurate, technical overview of the Heroku platform.

Describing the platform required a certain balance. Too detailed, and you'll get lost in the mire of minutiae. Too broad, and you'll just have a caricature.

We hope you appreciate this struggle, and the resulting text – which is generous in its linking to other documents that provide deeper material.

Two views: static and dynamic

It's difficult to describe an organism. Do you describe the body parts, and how they fit together (the static view, the deploy-time view), or do you describe the journey of blood and electricity (the dynamic view, the run-time view)?

How Heroku Works describes both–using words–in a story that takes you through a journey of the major components of the platform. A sequential reading is necessary (some components are intertwined with others), but in the end you should have a pretty solid understanding of both the run-time and deploy-time views.

You should be rewarded with a better understanding of how it all fits together – how you go from code to executing bits.

Design choices

This description of the Heroku platform is radically different from its predecessor. Here are some of the design choices that went into its creation:

  • Audience: we're assuming a much more technically savvy audience in this description. You're tinkerers, makers. You want to know how stuff works.
  • Timing: this article is an optional read, but a really great read after deploying your first couple of apps.
  • Language: while describing the platform we found a few terms that were a little too nebulous, so we changed them. The "Routing Mesh" is now simply called "routers". "Dyno Manifold" is now called a "Dyno manager". Both concisely describe the components, and don't require you to look up additional descriptions.
  • Words: you will have to read – instead of gaze at awesome pictures. We'd love to iterate on this, and move it towards something that has a little more visual allure – but hope you instead enjoy an accuracy and detail difficult to depict in pretty pictures.

Please use the feedback box at the bottom of the article to send me any feedback.

Thank you!
Jon

Logging on Heroku

Logs tell the story of your app – a continuous, living stream of events, changes and behaviors. Logs let you rapidly identify and act on critical events, debug issues in your code, and analyze trends to make better decisions over time.

But log management is increasingly complex. As apps scale across distributed infrastructure, many independent processes must be tracked and made sense of. Numerous components and backing services each produce their own log streams. Multiple developers may be collaborating on your app, and multiple services must consume its logs. And logs must be useful not only to machines and applications, but to the humans viewing them.

Heroku brings simplicity and order back to logging. Heroku automatically collates and routes logs from every part of your app into a single channel, providing truly comprehensive, extensible, app-centric logging.

Your log stream comes with rich command line functionality, is easy to plug into other services, and handles the heavy lifting of log management for you. This post presents Heroku's distributed logging platform, shows how to execute basic functions, and introduces logging services available with Heroku Add-ons. Finally, we take a look at two new, experimental logging tools available in Heroku Labs.

Logplex: An Open Source, Distributed Logging Platform

Logplex is Heroku’s distributed log routing and collation platform. Logplex uses a publish/subscribe model, merging and redistributing multiple incoming streams from various application components to individual subscribers. It’s open source, written primarily in Erlang, and relies on standard protocols and formats including syslog, stdout and HTTP.

Logplex collects underlying events from the Heroku platform, API logs with administrative actions performed by you and your collaborators, and output from within your app, app server, installed libraries and any backing services that have been configured to publish to your stream. The result is a full story of your application – logs from every piece of the Heroku platform, each component of your app, all of its processes, and all changes made to it by you or your teammates.

Working with Logs

timestamp source[dyno]: message

Logs on Heroku are designed to be human-readable, with an easy-to-parse format. Logs on Heroku consist of a timestamp, source, the name of the dyno that wrote the log, and the message.

Anything written to stdout or stderr will automatically be routed and collated by Logplex.

$ heroku logs --tail 

Run an open session to collect incoming logs right in your terminal, providing insight into live behavior as it happens for rapid debugging.

$ heroku logs --source app

Filter down to an individual source or dyno, i.e. app logs, logs from a particular dyno, or logs from the Heroku platform itself using simple commands like --source app (filters to only app logs) or --source heroku (filters to system logs such as crash processes, error pages, dynos coming up and down, etc). You can even filter to logs from specific dynos using --ps filtering arguments.

Extensibility and Add-ons

$ heroku addons:add papertrail

Logplex maintains the last 1,500 lines of consolidated logs for your app and can be easily plugged into external services for long-term storage, monitoring, alerting and analysis. The Heroku Add-ons platform offers fully-managed tools including Loggly and Papertrail that automatically integrate with your Heroku logs and can be added to your app in a single command. You can also set up your own log drains so you can forward logs to any external syslog server.

Logging for Teams

2013-07-06T12:00:01+00.00 heroku[api]: Release v3 created by email@example.com

Heroku makes it easy to collaborate with other developers and members of the application team simply by adding them to an app. Heroku logging will not only display API logs, but which collaborator initiated commands, releases and other changes. Want to keep an audit log of all changes ever made to your app? Once you’ve set up an Add-on for log persistence, use it to search and filter all historical, developer-initiated events. Got lots of people working on your app at the same time? Open a logs --tail session and see all activity going on in the app in real time. Heroku logging supports team-wide visibility and makes it easier to construct the full picture of your app, narrow in on critical events, and identify problems or changes quickly.

Labs

Heroku Labs lets you enable and test experimental features on the platform. Here are two Labs features around logging we’re currently piloting. Please remember that Heroku Labs features are experimental only and may be changed or removed without notice.

$ heroku labs:enable log-runtime-metrics
Enabling log-runtime-metrics for myapp... done
$ heroku restart 

log-runtime-metrics is a Labs feature that will give you in-depth per-dyno stats, including memory use, swap use, and load averages. These stats will appear as part of your app’s normal log stream. For additional information, check out the Dev Center article.

$ heroku labs:enable http-request-id

http-request-id lets you correlate router logs for a given web request against the web dyno logs for that same request. With a simple search of stored logs, look up events or messages correlated with a unique request ID. This helps you find the source of request errors, see how requests and application code may be resulting in behaviors at lower levels of the system, and get greater visibility into how various elements of your app are interacting.

Better Logging for Better Development

Logplex helps manage and deliver millions of messages every minute, managing the complexity of distributed logging so you can focus on making better decisions, solving problems fast, and using awesome services. Email us at labs@heroku.com to let us know what you think of log-runtime-metrics and http-request-id, and what you want to see next from Heroku logging.

Video and Slides: Running Production Apps on Heroku

On June 27th, our customer advocate team presented the first webcast in a two-part series on running production apps on Heroku. In case you missed it, the recording and slides are below. This first session is designed for an audience familiar with Heroku basics and covers:

  • Production app setup and expectations
  • App production checklist
  • Using Unicorn to increase app performance
  • Using 2X dynos to increase app performance
  • How to configure timeouts to ensure app stability
  • Using log-runtime-metrics for added visibility

Resources from the presentation:

Stay tuned. We'll be announcing the next part in the series soon.

Ruby Programming 44th Batch: Registrations are now open

Send to Kindle

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.

Course Fee

Please create a new account first and then pay US$ 19.95 (for the first 10 participants, after which the course fee will be US$ 39.95) by clicking on the PayPal button Paypal


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

Here is what Demetris Demetriou, a participant who just graduated, has to say – “When I joined this course I was sceptical about how useful this course would be for me instead of reading material and watching videos on YouTube and thus saving money. After the course started I realised how valuable this course was. In the past I had read many Ruby books over and over, but never got into really getting practical with it and never had confidence in it. Lots of theory but couldn’t use it. I feel that the exercises in this course and the support, monitoring from our mentor Victor, made the huge difference that all books in the past didn’t. It wasn’t about reading lots of books, but simply few things and get practical and understand them well. I feel I learnt a lot and I’m coming back for more to rubylearning.org Thanks a lot Victor and Satish and all the other Rubyists who gave us today’s Ruby.”

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.

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 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, 27th July 2013 and runs for seven weeks.

RubyLearning’s IRC Channel

Most 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.

How do I register and pay the course fees?

  • The course is based on the The Ultimate Guide to Ruby Programming eBook. This book is priced at US$ 9.95
  • You can pay 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$ 19.95 (for the first 10 participants, after which the course fee will be US$ 39.95) by clicking on the PayPal button Paypal

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

Here are some details on how the course works:

Important:

Once the course starts, you can login and start with the lessons any day and time and post your queries in the forum under the relevant lessons. Someone shall always be there to answer them. Just to set the expectations correctly, there is no real-time ‘webcasting’.

Methodology:

  • The Mentors shall give you URL’s of pages and sometimes some extra notes; you need to read through. Read the pre-class reading material at a convenient time of your choice – the dates mentioned are just for your guideline. While reading, please make a note of all your doubts, queries, questions, clarifications, comments about the lesson and after you have completed all the pages, post these on the forum under the relevant lesson. There could be some questions that relate to something that has not been mentioned or discussed by the mentors thus far; you could post the same too. Please remember that with every post, do mention the operating system of your computer.
  • The mentor shall highlight the important points that you need to remember for that day’s session.
  • There could be exercises every day. Please do them.
  • Participate in the forum for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Please do not post a simple "Thank you" note or "Hello" message to the forum. Please be aware that these messages are considered noises by people subscribed to the forum.

Outline of Work Expectations:

  1. Most of the days, you will have exercises to solve. These are there to help you assimilate whatever you have learned till then.
  2. Some days may have some extra assignments / food for thought articles / programs
  3. Above all, do take part in the relevant forums. Past participants will confirm that they learned the best by active participation.

Some Commonly Asked Questions

  • Qs. Is there any specific time when I need to be online?
    Ans. No. You need not be online at a specific time of the day.
  • Qs. Is it important for me to take part in the course forums?
    Ans. YES. You must Participate in the forum(s) for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves (participants) during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Past participants will confirm that they learned the best by active participation.
  • Qs. How much time do I need to spend online for a course, in a day?
    Ans. This will vary from person to person. All depends upon your comfort level and the amount of time you want to spend on a particular lesson or task.
  • Qs. Is there any specific set time for feedback (e.g., any mentor responds to me within 24 hours?)
    Ans. Normally somebody should answer your query / question within 24 hours.
  • Qs. What happens if nobody answers my questions / queries?
    Ans. Normally, that will not happen. In case you feel that your question / query is not answered, then please post the same in the thread – “Any UnAnswered Questions / Queries”.
  • Qs. What happens to the class (or forums) after a course is over? Can you keep it open for a few more days so that students can complete and discuss too?
    Ans. The course and its forum is open for a month after the last day of the course.

Remember, the idea is to have fun learning Ruby.

Technorati Tags: , , ,


(Powered by LaunchBit)

Heroku Labs: Managing App Deployment with Pipelines

Editor's Note: Features added through Heroku Labs are experimental and may change or be removed without notice.

heroku fork lets you create unique, running instances of existing applications in a single command, making it fast and simple to set up homogenous development, staging and production environments. But have you ever wished you could deploy directly from staging to a production app after testing and validation?

Heroku pipelines, now an experimental feature available in Heroku Labs, lets you define the relationship between apps and easily promote a slug from one app to another. On Heroku, a slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system, ready for execution.

Pipelines will copy the slug from the upstream app to the downstream app. Time to deploy is significantly faster as the slug is already compiled – pipelines simply copies and moves it to the downstream app. Pipelines also reduces the risk of accidentally pushing the wrong commit or deploying to the wrong environment, and makes it easier to manage your workflow so you can develop and test new features quickly, verify expected behavior, and release safely to end users. Here’s how to try it.

Set Up Pipelines

To use pipelines, you must first enable it in Heroku Labs:

$ heroku labs:enable pipelines

Then install the CLI plugin:

$ heroku plugins:install git://github.com/heroku/heroku-pipeline.git

Defining a Workflow

If you don’t already have your application environments set up, use heroku fork to quickly spin up unique, homogeneous application environments from existing apps. You can then use these instances for various stages of your workflow.

For this example, let’s assume that myapp-production is the name of your existing app, and you want to create a fork called myapp-staging:

$ heroku fork -a myapp-production myapp-staging

This will clone the source app’s precompiled slug and config-vars, re-provision the source app’s add-ons, copy over Heroku Postgres data (if present), and scale web processes to one dyno in the new myapp-staging environment. For more on heroku fork, its behaviors and limitations, read the blog post.

Next, we use pipeline to map the relationship between the staging and production apps. In pipeline vocabulary, a production app is "downstream" from a staging app. Given a dev —> staging —> production pipeline, staging would be downstream of dev, and production downstream of staging.

For simplicity’s sake, let’s set up a basic staging-to-production workflow between myapp-staging and myapp-production. Add the production app as the downstream environment:

$ heroku pipeline:add -a myapp-staging myapp-production

Confirm by calling heroku pipeline:

$ heroku pipeline -a myapp-staging
Pipeline: myapp-staging ---> myapp-production

Diff Between Application Environments

Diff is a powerful tool for seeing changes between code, here extended to entire application environments. Diff against your downstream app:

$ heroku pipeline:diff
Comparing myapp-staging to myapp-production ...done, myapp-staging ahead by 1 commit:
73ab415  2013-07-07  A super important fix  (Shanley)

Promote Changes

Once you’ve defined a pipeline, you can deploy from one app to a downstream app with one command:

$ heroku pipeline:promote
Promoting myapp-staging to myapp-production...done, v2

This will copy the upstream app’s currently running slug to the downstream app as a new release. In this example, application changes made in staging will now be live and running in your production app, ready to serve end users.

Pipelines only manage the application slug. Config vars, Add-ons and other environmental dependencies are not considered part of a pipeline and must be managed independently. Similarly, pipeline doesn't update the downstream app's repository, so a heroku git:clone of a downstream app will not retrieve the latest code base.

If you're adding application code that interacts with an Add-on, but that Add-on is not yet present in a downstream app, you'll want to provision the Add-on there before promoting application changes to it. Promoted changes by mistake, or need to roll back? Revert a promotion on the downstream app with heroku rollback to deploy a previous, known version of your code.

Feedback?

Heroku Labs lets us get experimental features out early and often so you can try them and tell us what you like and how we can improve. Check out our current Labs features, and email us at labs@heroku.com.

The Healthy Programmer: Get Fit, Feel Better, and Keep Coding now in print

The Healthy Programmer: Get Fit, Feel Better, and Keep Coding now in print

Do you know how to create a bot in Ruby?

Do you know how to create a bot in Ruby?

This guest post is by Apoorv Saxena. He’s a Ruby Enthusiast, and has been coding in Ruby since 2009. In his free time, he builds hacks using Ruby and JavaScript; latest being Advanced Search for Facebook. He likes to blog about Sinatra, Ruby, Digital Marketing and Programming concepts. He would love to hear from you on Google Plus or through mail.

Introduction

Apoorv Saxena A bot can be defined as a continuously running script that is responsible for performing a specific task regularly or respond to an action triggered on a specific event. Bots are targeted to perform an action that is repetitive in nature or has a limited number of events to respond. See the Wikipedia article on bots that describes the different types of bots built to perform a variety of different tasks.

Today, we are going to create a bot that repeats a certain task after every X mins of time. The repetitive task that we have chosen to perform, is to get the links of the Most Trending Stories on Internet in Real Time (using Bitly’s Social Data APIs) and display them on our command line. Our bot will also send notification pop-ups on our screen whenever it fetches the latest data after every X mins of time. We will name our bot as Bitly-Bot as it uses Bitly’s APIs to bring us Trending Data in Real Time.

OurBot
OurBot

Running Bitly-Bot

You can clone Bitly Bot’s Code from GitHub for reference and run it as well on your machine, it contains the instructions to setup Bitly-Bot on your local machine, it also contains the links to create Bitly Application (required to access Bitly’s Social Data APIs) and install Growl Application on your Mac OS X (to send notification pop-ups from Bitly-Bot).

Understanding the Working of Bitly-Bot

We start with the initialization of a class named Bitly that is responsible for handling the API calls interaction, it sends request to Bitly  containing our Application Generic Access token, to validate our application and fetches the Hot and Bursting Topics data along with the Most Trending Story links associated with these topics in JSON format. We have used Threads to make two network API calls simultaneously to Bitly(one to bring Hot Topics and the other to bring Bursting Topics), instead of triggering them sequentially, thus saving us time and patience to see our Bot’s response.

class Bitly

  def initialize()
    @access_token = $config['access_token']
    @colorize = Colorize.new
  end

  def get_url(phrase)
    @base_url = "https://api-ssl.bitly.com/v3/realtime/#{phrase}_phrases?access_token=#{@access_token}"
  end

  def get_topics(phrase_types)
    threads = []
    phrase_types.each do |phrase_type|
      base_url = get_url phrase_type
      threads << Thread.new(base_url, phrase_type) do |url, phrase_type|
        begin
          response = JSON.parse RestClient.get url
          if response['status_code'] != 200
            puts  @colorize.display 'Error: ' + response['status_txt'] + '\n', :error
            exit
          end
          display response,phrase_type
        rescue
          display_error_message
        end
        puts "\n\n"
      end
    end
    threads.each { |aThread|  aThread.join }
  end

  def display(response,phrase_type)
    puts GrowlNotifications.display "#{phrase_type.capitalize} Topics"
    puts @colorize.display "#{phrase_type.capitalize} Topics", :heading
    response['data']['phrases'].each do |data|
      puts @colorize.display("#{data['phrase']}", :text) + " " + @colorize.display("http://bit.ly/#{data['ghashes'][0]['ghash']}", :link)
    end
  end

  def display_error_message
   puts @colorize.display 'Unable to connect to the Server', :error
   exit
  end

end

We have a class named Colorize which contains a method named display that displays the different parts of APIs response in different colors, while also colorizing an error message that is displayed when we are not able to connect to Bitly. Another class named GrowlNotifications simply echoes a text on the terminal that contains the code which triggers the Growl Notifications on Mac OS X.

class Colorize
  def display(text, element)
    color_code = case element
      when :text
        ['1;','32;','40m']
      when :heading
        ['1;','33;','40m']
      when :error
        ['1;','','31m']
      when :link
        ['4;','31;','48m']
    end
    "33[#{color_code[0]}#{color_code[1]}#{color_code[2]}#{text}33[0m"
  end
end  

class GrowlNotifications
  def self.display(text)
    "\e]9;#{text}07"
  end
end

Now that we have finished writing our bot script, we would like to run it as a Daemon in a terminal window. Most processes that run as Daemon, are run as background jobs, however, in our case, we would like to see the Trending Topics links inside our terminal window, for which the daemon has to run in the current terminal window in which it is started. We specify the bot to run in our current terminal window by giving an additional parameter ontop when writing the code to run our Daemon.

Daemons.run('application.rb', {:ontop => true, :app_name => 'Bitly-Bot'})

Now we code our application to run continuously with a delay of X minutes while controlling it via our Daemon process.

loop do
  Bitly.new.get_topics ['bursting', 'hot']
  sleep $config['delay'] * 60 # delaying in minutes
end

That’s it! We are ready to receive Trending Story Links from our Bot after every X mins, along with Notification Popups and Colored Output to grab our attention.

I hope this article explains and motivates you enough to create a bot in Ruby by yourself, and explore the amazing stuff that you can perform with a bot at your disposal. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , , , ,


(Powered by LaunchBit)

Add-ons for Production Apps

Heroku Add-ons are services exposed through the Heroku platform. They are managed by experts, provisioned and scaled in a single command, and consumed by your application as loosely coupled components. This post provides an overview of Add-ons for logging, persistence, caching and monitoring in production apps.

Logging

heroku addons:add papertrail

Logs provide the foundation for trend analysis, error inspection, performance tuning and other processes critical for running production apps. Heroku routes and collates real-time logs from each part of your app, including running processes, system components, API events… even Add-ons themselves. Heroku presents app logs in a single stream of time-ordered events, providing comprehensive logging for everything from simple prototypes to complex, highly distributed apps.

While Heroku handles collating and routing for you, you can use one of our logging Add-ons to consume the log stream and provide higher-order services such as persistence, search, alerts, and integration with other services.

Papertrail is one of the most popular logging Add-ons. In two clicks, receive a nightly email with platform errors, deploys, and critical app logs. It automatically integrates with Heroku’s log stream so no code changes are needed, and provides real-time tail, search, alerting and integration with other services. It can be used via your browser, command line, or an HTTP API. Their free plan gets you started with seven days of log archiving, search for up to the past two days, and 10MB of data per day. You can see our other logging services here, including Logentries, Loggly, and FlyData.

Persistence

heroku addons:add heroku-postgresql

Persisting, managing and scaling state is one of the primary concerns of a production application. Traditionally, the persistence layer has been both brittle and fragile. Heroku Postgres brings the Heroku flow to your database, offering safe and straightforward provisioning, scaling, development and collaboration:

  • Fork your database. In a single command, create a clone of your database and all of its data. Use it to test migrations, do load testing, or spin up a development database. This makes working with your database more flexible, and lets you test and experiment with safety and confidence.
  • Share dataclips. Run SQL queries against your data and share results in an easy, visual way with your team members. Dataclips can be downloaded or shared via URLs. The results will auto-refresh over time, and you can also view point-in-time snapshots.
  • Fully managed. Heroku Postgres provides write-ahead logs backed up every 60 seconds, supports unmodified Postgres 9.2 by default, and makes it easy to set up replicas. We take care of operations, provisioning, upgrades and security.

Heroku Postgres offers free and development tiers, as well as plans for larger apps. Make sure to read our documentation on choosing the right Heroku Postgres plan – many apps get a starter Heroku Postgres database by default, but it should be upgraded to a production tier plan before launch. Other popular options for persisting and sharing state include RedisToGo and MongoHQ.

Caching

heroku addons:add memcachier

Caching is critical for web and mobile performance, significantly improving the response time and user experience of your app. MemCachier lets you add memcache to your production app on the Heroku platform, managing and scaling clusters of memcache servers behind the scenes so you can focus on using the exposed features. MemCachier provides stats on cache usage, lets you flush the cache from the web dashboard, and provides documentation for most languages supported on Heroku. You can start with 25MB free, then provision a plan based on how much memory you need as you grow.

The Caching category in the Add-on Marketplace also includes IronCache, which supports the memcache protocol, and Cachely which is a rack middleware for Ruby on Rails apps.

Monitoring

heroku addons:add newrelic

Monitoring provides peace-of-mind, problem detection and visibility into key indicators over time. When you provision the New Relic Heroku Add-on, it will create a private New Relic account and configure access for Heroku’s servers. Once you install the New Relic agent, the Add-on will begin monitoring your app right away, and provides SSO for login to New Relic’s dashboard.

New Relic’s free Standard plan includes eight days of data retention, error detection, a look at database performance, and snapshots of front-end performance, health and availability. The Pro plan provides 90 days of data retention, proactive alerting, and more comprehensive data on performance, transactions, and more.

Node.js developers can look to Nodetime for performance profiling and monitoring. For those that want to customize their dashboards, Librato is quick to setup and consumes data from your application logs. These and other options are in our Monitoring category.

Next Steps

When you're ready to move your app into production, make sure to try Production Check in your Heroku dashboard – this will test your app’s configuration against a set of highly recommended criteria around DNS, dyno redundancy, app monitoring and more.

While this post explored some of our most popular Add-ons for production apps, Heroku has over 100 Add-ons for you to try, including push notifications, search, email and SMS, workers and queuing, analytics and more. To become an Add-on provider, check out our Provider Program. Docs for Heroku Add-ons are available in the Dev Center.

More State of The Stuff, July 2013

Ongoing update and stuff

I know, I haven’t been blogging much. I can always tell when I’m putting things off because the half-finished blog posts stack up.

First, Master Space and Time In JavaScript is still on sale, and for the moment it’s still $15. Somebody using the twitter handle @shakerdev just called it a “great fucking read for JS devs.” So, I’ve got that going for me.

The ongoing projects list looks like this:

Master Space and Time Book 4: Ember

Still caught in the tension between wanting — really wanting — to get this one done, and the fact that the Ember team keeps releasing cool new stuff and not going to a 1.0 final release.

I should mention, in the wake of some comments on line about Ember’s volatility and books, that no matter what else I wind up doing over the next few months, my plan is to continue to keep the Ember book current through at least Ember 1.0, and I hope somewhat beyond that.

My planned topic list hasn’t changed a ton:

  • More on views and handlebar helpers
  • Ember data details
  • Ember-testing details
  • The new async routing API — this will probably include a short section on promises, which may get promoted to book 1.
  • I’d like to deal with some real-world examples, at least briefly, of things like authentication
  • I also may switch from jasminerice to teaspoon as a test runner, which may also mean going back and retro-fitting earlier parts of the books.

Angular Update

Since I last blogged about this, I’ve taken one baby step towards an Angular book, namely getting a new branch up in the book’s code repo set with Angular. The goal is to create the basic admin console stuff similar to the Ember book example. If I feel like I can do that and explain it clearly, then I’ll start writing. I think the odds are at just over 50/50 that I’ll do it. If I do, it will probably go on sale as a beta in very early stages.

Project Book Update

I should probably put this higher, but it’ll get its own post in a week or two.

A while back, I casually mentioned on Twitter that I was thinking about writing about how to deal with projects. This met, I think it’s fair to say, with near-total indifference.

Nevertheless, I’m still doing it, because I want to write some of this stuff down. The book now has a title, a scratch cover, and about 15 pages written. Final length will probably be in the 120 page neighborhood, but who knows.

Full announcement, including the title, and cover and a way to be notified when it goes on sale, will come when I get to a) 25 pages and b) a coherent outline.

I’m very excited about this, I think it’s going to be good.

If you’ve ever worked on projects with people who are not you, this book will help you.

Pricing

If you follow me on Twitter, you may have noticed that I was discussing book pricing with Jim Gay of Clean Ruby fame. This was in the context of a new Ember book from Giles Bokett, that is priced at $47.

It seems like Giles, at $47, and I, at $7, are both sub-optimal in terms of maximizing revenue from our Ember work. I generally err on the side of under-pricing my stuff though some combination of my own insecurity and also the idea that an inexpensive book is accessible to more people.

Still, there’s erring on the side of inexpensive, and then there’s not having confidence in the value of your work. The full set of Master Space and time With JavaScript is going to be about 125 – 150% the length of Rails Test Prescriptions for less than 2/3 of the price. (And yes, I know that page length isn’t really a marker for anything. Still…)

Which is a long winded way of saying that the price of MSTWJS will be going up, with the actual date being either a) the draft-complete version of the Ember book, b) the first beta release of the Ember book over 120 pages (currently at 94), or c) the on-sale date of a currently-mythical Angular book. Exact pricing still TBD, though I’m still open to argument. I’ll probably also add some kind of workaround for students and others for whom the price is a hardship — not sure what that will look like yet.

Finally

Buy the book, please: Master Space and Time In JavaScript.

PragPub Magazine for July, new Studio Courses

PragPub Magazine for July, new Studio Courses