Outsource It! in beta, Practical Vim in print

Functions that return functions are the luckiest functions in the world

Here’s some JavaScript:

var foo = function(a, b) { return a * b };

var bar = function(func) {
  return function() {
    return func.apply(this, arguments)
  };
};

baz = bar(foo);
console.log(baz(2, 3));

What we have here is a function, bar, that both takes a function as an argument and returns a function as it’s result. It’s transforming the function passed to it into a different function.

Okay, that’s cool in kind of an abstract way, but so what? Let’s play around with function that take and return functions to show off some potentially useful tricks.

I’ll note right here up top, that there are more complex, fully featured, and robust versions of all the things I’m showing here. I’m just playing with functions.

We can add diagnostics.

var foo = function(a, b) { return a * b };

var trace = function(func) {
  return function() {
    console.log("calling " + func);
    console.log(new Error("normal trace").stack);
    return func.apply(this, arguments)
  };
};

foo = trace(foo);
console.log(foo(2, 3));

All the trace function is doing here is logging a couple of things before actually calling the function — namely, it’s printing the function body (JavaScript doesn’t have a consistent way to get the function’s name), and a stack trace. The console output is:

calling function (a, b) { return a * b }
Error: normal trace
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:8:17
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:15:13

Okay, that’s kind of neat. You can also tweak it to do something like a Jasmine spy object, but it takes some object manipulation. Here we really start to take advantage of the fact that JavaScript functions are basically just JavaScript objects.

var foo = function(a, b) { return a * b };

var spy = function(func) {
  var returnFunc = function() {
    returnFunc.timesCalled += 1;
    returnFunc.args.push(arguments);
    return func.apply(this, arguments);
  }
  returnFunc.timesCalled = 0;
  returnFunc.args = [];
  return returnFunc;
};

foo = spy(foo);

console.log(foo(2, 3));
console.log(foo.timesCalled);
console.log(foo.args)

Same basic idea here, except we’re doing some dancing with scope to make sure we have access to all the variables we want to, when we want them. Specifically, rather than just returning an anonymous function, we’re giving it the name returnFunc. Inside the funtion body of returnFunc, we’re accessing properties of the returnFunc functional object itself. Specifically we’re incrementing a counter and adding to a list of called arguments.

After we define the function, we initialize the timesCalled and args properties, and return our functional object. This works because we can access properties of the functional object inside the function itself, which seems weird, but makes more sense if you think of it just as an ordinary object accessing other properties of the same object.

Here’s a related example — in this case, our function object has its own methods.

var benchmark = function(func) {
  var returnFunc = function() {
    returnFunc.startDate = Date.now();
    result = func.apply(this, arguments);
    returnFunc.endDate = Date.now();
    return result
  }
  returnFunc.elapsedTime = function() {
    return returnFunc.endDate - returnFunc.startDate;
  };
  return returnFunc;
}

foo = benchmark(foo);
console.log(foo(2, 3));
console.log(foo.elapsedTime());

In this one, we’re running the inner function surrounded by time stamps, and we’re adding a function to the function object, which again, seems weird. At the end, we can query a benchmarked function as to how long it takes. (Yes, I realize that the dev tools allow you to do this.)

Here’s one that might be more practical. Memoizing is the act of caching the results of function calls so that you don’t need to re-evaluate an expensive computation.

var memoize = function(func) {
  var returnFunc = function() {
    argsToCheck = (JSON.stringify(arguments));
    if (returnFunc.cache[argsToCheck]) {
      return returnFunc.cache[argsToCheck];
    } else {
      result = func.apply(this, arguments);
      returnFunc.cache[argsToCheck] = result;
       return result;
    }
  }
  returnFunc.cache = {};
  return returnFunc;
}

foo = memoize(foo);
console.log(foo(2, 3));

In this case, we hold on to the functional argument as before, but when we call the memoized function, we first compare the argument list against a cache. We’re using the JSON string version of the argument list, so we do have that conversion overhead. If this particular argument list has already been called, then we return the result of the previous call without recalculating. If not, we calculate the function, and place the result in the cache. So, our first call to foo in the example places (2, 3) in the cache, but the second call would retrieve it, to avoid that very expensive multiplication.

This is the beginning of manipulating functions in JavaScript — functional programming in general is a big topic, but worth looking at. Adapting a functional style where side effects and mutable state are downplayed in favor of manipulating functions, can really pay off in less complexity in your code.

Like this? You might like my book Master Time and Space With JavaScript, free sample available, and $15 for the whole thing.

Sunsetting and Deprecation at Heroku

Software erosion is what happens to your app without your knowledge or consent: it was working at one point, and then doesn’t work anymore. When this happens you have to invest energy diagnosing and resolving the problem. Over a year ago Heroku’s CTO, Adam Wiggins, first wrote about erosion-resistance on Heroku. Part of erosion-resistance is communication, and knowing what to expect moving into the future. This post will clarify what we mean by erosion-resistance, and help you understand what to expect when one of our features is deprecated or is sunset.

Erosion Resistance

Erosion-resistance means that your apps are protected against accidental or unannounced changes because there is an explicit contract between your app and the platform. Heroku insulates you from erosion by providing a transparent, managed service. We give you early visibility and full details on what’s happening with your app, and options for how to respond to any changes. In many cases we can take care of system changes for you automatically, but when we can’t, we tell you what your options are, how to proceed, and how much time you have.

To keep your application stable Heroku applies fixes and improvements, such as backwards-compatible updates released by maintainers, to the software on our platform. This protects applications on our platform without interrupting them. Occasionally security patches are introduced to operating systems and sometimes to programming languages. By using the Heroku platform, you can be confident that the underlying software you are using is safe and stable.

If a backwards-incompatible change needs to be applied to our platform we will always communicate the change ahead of time and provide sufficient information so that you can take the necessary steps to fix any incompatibilities. These changes are communicated through our deprecation and sunsetting process.

Deprecation Notices

When Heroku deprecates a product or service, we are actively suggesting that you no longer use that feature. Deprecations may be communicated through notices coming from the Heroku CLI, banners in our Dev Center, or messages on our website. These notices may be accompanied by blog posts, changelog entries, official tweets, or direct emails when appropriate. Deprecation of a product will typically suggest using a more recent, stable, or feature rich product, so you can have the best experience using Heroku. These notices will not affect currently running apps. If, however, only a few applications are using a feature in production, Heroku may choose to sunset the feature.

Sunsetting a Product

As a product is sunset, it will be gradually phased out until it can be deactivated or removed from our system. We will only sunset products that have seen significantly decreased usage, and we will not deactivate heavily used features. Any product being sunset will have been deprecated for some time and will begin with an announcement similar to the deprecation but including additional information such as the date of the product’s deactivation.

If possible, we will migrate any affected users to a comparable product. A good example of this is the Cron Add-on. Cron was deprecated in April of 2012, and after a majority of its users transitioned away from the product it was sunset. Any users left using Cron were automatically migrated to the superior Scheduler Add-on.

If we sunset a product you are using, and we cannot automatically migrate, there are several things you can expect from Heroku. You will receive communication of the changes along with a plan moving forward. This will include a time-line with enough time to make any changes needed. Our goal is always to provide the best experience, to our developers, and to give the highest level of support possible.

Conclusion

At Heroku, we seek to be the most powerful platform to the largest number of users. By providing a strong contract with our platform, you can be confident using Heroku, and be prepared for when change happens. To stay up to date with our current erosion-resistance policies, you can always check our erosion-resistance documentation on the Dev Center.

iOS SDK Development beta updated to iOS 6

iOS SDK Development beta updated to iOS 6, print coming soon.

#382 Tagging

There are several gems to help implement tags in a Rails app. Here I show you how to integrate acts-as-taggable-on and then show how to do it from scratch.

Missing attr_unsearchable in ransack?

If you are upgrading to ransack from meta_search, and you are missing
being able to use attr_unsearchable to hide various model methods from
search, you can add this to your model instead:

def self.ransackable_attributes(auth_object = nil)
  (column_names - ['company_name']) + _ransackers.keys
end

In this case, company_name will no longer be searchable with the
dynamic scopes that ransack creates.

Missing attr_unsearchable in ransack?

If you are upgrading to ransack from meta_search, and you are missing being able to use attr_unsearchable to hide various model methods from search, you can add this to your model instead:

def self.ransackable_attributes(auth_object = nil)
  (column_names - ['company_name']) + _ransackers.keys
end

In this case, company_name will no longer be searchable with the dynamic scopes that ransack creates.

This Week in Ruby: What to Expect in Rails 4.0 talk, EventMachine tutorial, and StrongParameters hit Edge Rails

Welcome to this week’s Web-based syndication of Ruby Weekly.

Featured

Yehuda Katz Needs Your Input on the Tokaido (a.k.a. rails.app) UI
5 months ago, Yehuda Katz raised $51k to work on Tokaido, an app designed to make setting up a Rails environment on OS X easy. He now has some mockups of the app’s user interface and needs your input.

Tddium Looking for Beta Testers of its New JRuby CI Service
Tddium is a cloud-based continuous integration service for Ruby apps and they’re expanding into CI for JRuby. Got a JRuby app and want to get into the beta program? Check it out.

Reading

How Ruby Borrowed a Decades Old Idea From Lisp
Pat Shaughnessy shares another excerpt from his Ruby Under a Microscope book that digs deep into the world of blocks, lambdas, procs, and bindings and how they relate to closures.

raise ‘hell’: Better Programming Through Error Messages
Exceptions suck, but they don’t have to. Learn how to program better with error messages, and see how improved messages will lead to a better experience in Rails 4.0.

Ruby’s EventMachine: Event-based Programming (Part 1)
Not up to speed with EventMachine yet? No worries, Phil Whelan kicks off a series of blog posts introducing us to the popular event-processing library (which, incidentally, hit version 1.0 just this month.)

An Experiment in Static Compilation of Ruby: FastRuby
Charles Nutter (of JRuby fame) shows off an experiment in doing static compilation of Ruby to Java. Short and sweet and leans on JRuby’s parser and AST walker.

8 (New) Steps for Fixing Other People’s Code
Many moons ago, Dr Nic wrote a popular article about contributing to open source projects. Alex Grant builds on Dr Nic’s work with a more up to date set of guidelines.

Learning Chef
Some things Mathias Lafeldt has picked up while learning to use the Ruby-based infrastructure automation framework.

Watching and Listening

Simulating the World with Ruby
Brian Liles (remember TATFT?) digs into creating simulations in Ruby, covering concurrency issues, domain modelling, testing, and more.

Ruby’s Symbol#to_proc: A Walkthrough
A 15 minute extract from my Ruby Reloaded course that digs into what Symbol#to_proc is, where it came from, how it works, and how to make your own version from scratch.

What to Expect in Rails 4.0
Prem Sichanugrist shows off some of the new features and changes in the forthcoming new version of Rails.

Libraries and Code

minitest-reporters: Reporters for MiniTest
A new way to create customizable MiniTest output formats. I’ve tried it. It works. It’s awesome.

oEmbed Ruby Library
oEmbed is a format for allowing an embedded representation of a URL on third party sites. The ‘oembed’ gem helps you lean on oEmbed’s functionality in Ruby.

Ongoing ActiveRecord Optimizations: Freeze Columns Before Using Them As Hash Keys
An interesting (and ongoing) pull request on the Rails GitHub repository where freezing column names before using them as hash keys seems to result in memory and performance improvements.

Sinatra-Like Routes in Rails Controllers
Jose Valim demonstrates how simple it is to tinker with Rails controllers to support Sinatra-style routes.

Jobs

Back-end Software Engineer at Geckoboard (London, UK)
We’re looking for a Rails engineer to help architect, build, test and improve a young, fast moving and market defining web application with all the challenges that come with that. 2+ years’ experience with a dynamically-typed, object-oriented language.

Last but not least..

Dumper: Cloud Database Backup Service for Rails
A (paid) service that hooks into your Rails app and provides cloud-based backup. Has a free trial though.

Announcing Heroku Enterprise for Java

A year ago we we launched Java support with the ability to deploy Maven based Java applications using Heroku’s familiar git based workflow. Many customers, like Banjo, have since taken advantage of the new capabilities and built a wide variety of Java applications on the platform.

With the introduction of Java support, we are seeing growing interest from larger enterprises who are often heavy Java users and who are looking for a platform like Heroku to increase the speed of application delivery.

Today, we are announcing Heroku Enterprise for Java, a new product that makes it simpler than ever for enterprise developers to create, deploy and manage Java web applications using their preferred tools and processes. The product is priced at a monthly subscription fee per production application making it easy for the business to align investment with value.

Let us look at the features in detail.

Full stack Java

The vast majority of Java web apps use a baseline set of components: A JDK, a Tomcat web app container, a SQL database and a caching layer to handle session state. Heroku Enterprise for Java includes these baseline components, pre-configured and pre-integrated out of the box.

OpenJDK 6, 7 or 8

You can choose the Java environment that you need whether it is version 6, 7, or the upcoming OpenJDK 8. Read more…

Tomcat 7 web app container

The open source Apache Tomcat container is the most popular way to run Java web applications. Heroku supports Tomcat 7 deployment through WAR files and Maven builds. Read more…

Memcache backed distributed HTTP session state

For maximum scalability Heroku applications can use a Memcache store for distributed session state. This alleviates the scalability limitations associated with typical session replication strategies. Externalized session state alleviates memory and replication overhead while providing durability across application updates. Read more…

Production Heroku PostgreSQL database

Heroku Enterprise for Java includes a Heroku Postgres production database because almost every Java web application stores data in a SQL database. Read more…

Continuous Delivery

Built-in best practices for rapidly deploying new application versions

Deploy and Test – then Promote

With Heroku Enterprise for Java you can instantly deploy Java web apps to staging environments where those applications can be tested and then promoted to production. This provides a major simplification over the usual deployment workflows for enterprise apps.

Continuous Integration Plug-in for Atlassian Bamboo

Heroku Enterprise for Java enables automated deployment of tested applications (i.e. Continuous Delivery) through a plug-in for Atlassian’s Bamboo CI solution. Read more…

Continuous Delivery

Dynamic Runtime Environments

Create and scale complete, self-healing environments

Managed and instantly scalable environments for production and staging

A key enabler for continuous delivery is the ability to seamlessly provision and manage many different environments. This is a core feature of the Heroku platform where a new environment can be brought up with a simple heroku create. Heroku Enterprise for Java includes a full set of development, testing, staging and production environments that can be easily manipulated from the Eclipse IDE, web interface or command line tool.

Native Java Tools

Heroku Enterprise for Java works with tools you know and trust

Eclipse-based development using the new Heroku Eclipse plug-in

For developers who use IDE workflows the new Heroku Eclipse plug-in makes it easy to create, deploy, and manage their Heroku apps entirely within Eclipse. Read more…

Eclipse plugin

WAR based deployment of Java web apps

Java web applications are often packaged into WAR files and deployed to a container. Heroku now supports the deployment of WAR files to a Tomcat 7 container from the command line and from Eclipse. Read more…

WAR based deployment

Enterprise-Grade Support

Enterprise-grade applications need enterprise-level support. Heroku Enterprise for Java includes SLA based support over tickets or email for quick resolution of deployment or operational problems.

Heroku Enterprise for Java is available now!

Learn more…

The Definitive ANTLR 4 Reference now in beta

The Definitive ANTLR 4 Reference now in beta

Using `heroku pg:transfer` to Migrate Postgres Databases

Development of most applications takes place in several disparate environments with the most common pattern being dev-staging-production. While it’s necessary for the source versions in each environment to differ it is quite useful to retain some level of data synchronicity between the environments (for example, to populate your local database with production data to diagnose a bug).

When managing environments on Heroku the recommendation has been to use Taps and heroku db:pull/heroku db:push to transfer data to and from the remote Postgres database. While Taps aimed to be database-agnostic (allowing you to import/export between different database vendors) this came at the expense of robustness and maintainability. The fragility of the tool is evident on Stackoverflow.

The Heroku pg:transfer CLI plugin is a more stable and predictable tool that automatically transfers data between two Postgres databases using native pg tools and protocols. You should consider heroku pg:transfer an immediate replacement for heroku db:pull.

Install

As more developers adopt the Twelve-Factor tenet of environment parity the need to perform data migrations across database vendors is eliminated. This allows the ability to use a database’s native import/export tools, resulting in a much more predictable data migration process.

Most apps on Heroku are already using the incredible Heroku Postgres service and should be running Postgres locally as well. If not, the Postgres.app project will get you up and running on OSX in minutes.

Install the plugin by running the following from the terminal:


$ heroku plugins:install https://github.com/ddollar/heroku-pg-transfer

Confirm the plugin installation by running the pg:transfer --help command:


$ heroku pg:transfer --help
Usage: heroku pg:transfer

 transfer data between databases

 -f, --from DATABASE  # source database, defaults to DATABASE_URL on the app
 -t, --to   DATABASE  # target database, defaults to local $DATABASE_URL

Download

pg:transfer has a very simple purpose – to transfer data from one Postgres db to another. As such it only requires two arguments, the source and target database locations (in its vernacular the “to” and “from”).

If you’re in the root folder of an app already deployed to Heroku the “from” and “to” will assumed to be at the location specified by the DATABASE_URL config var on the remote app and the local environment variable DATABASE_URL for the local db, respectively. In other words, by default, heroku pg:transfer will export from your Heroku database and import into your local development database.


$ heroku pg:transfer
Source database: HEROKU_POSTGRESQL_BLACK (DATABASE_URL) on someapp.herokuapp.com
Target database: someapp on localhost:5432

 !    WARNING: Destructive Action
 !    This command will affect the app: someapp
 !    To proceed, type "someapp" or re-run this command with --confirm someapp

> someapp
pg_dump: reading schemas
pg_dump: reading user-defined tables
...

If the local database you want to import to isn’t set in your environment you can quickly do so just for the pg:transfer command with the env utility,


$ env DATABASE_URL=postgres://localhost/someapp-dev heroku pg:transfer

Apps using Foreman for local process management can quickly provision the correct environment variables from the .env file with: source .env && heroku pg:transfer.

Upload

If you want to push data from your local environment to your Heroku database you’ll need to specify the to and from flags to reverse the default direction of the transfer. For added convenience pg:transfer is aware of the Heroku Postgres COLOR naming scheme.


$ heroku config | grep POSTGRES
HEROKU_POSTGRESQL_JADE_URL: postgres://ads8a8d9asd:al82kdau78kja@ec2-23-23-237-0.compute-1.amazonaws.com:5432/resource123

$ heroku pg:transfer --from $DATABASE_URL --to jade --confirm someapp
...

Transfer

While pushing data from a local db to a remote one is of limited usefulness a more common use-case is to transfer between two remote databases. For instance, populating a staging or test environment with production data.

To transfer data between databases on different applications specify the full connection info of the target database in the --to flag.


$ heroku pg:transfer --to `heroku config:get DATABASE_URL -a app-staging` --confirm someapp
Source database: HEROKU_POSTGRESQL_JADE on someapp.herokuapp.com
Target database: kai89akdkaoa on ec2-23-21-45-234.compute-1.amazonaws.com:5742

pg_dump: reading schemas
pg_dump: reading user-defined tables
...

Here the heroku config:get command is used to fetch the full PG connection info for the target app.

Outside Heroku

Somewhat un-intuitively for a Heroku CLI plugin, you can also use pg:transfer to transfer data between two databases that are not associated with Heroku. Since the plugin accepts raw connection URLs for both the --from and the --to locations you’re really not limited in how you use the feature.

As Postgres’ fame grows more and more platforms are supporting the database. Transferring data between Engine Yard Postgres databases, between dbs on EY and Heroku, or from EY to your local database is simple. Though you need the heroku command on your path it’s really quite agnostic.

To transfer from EY PG to your local database at the env var DATABASE_URL:


$ heroku pg:transfer --from "postgres://deploy:password@127.0.0.1:5433/dbname" --to $DATABASE_URL

To gain ingress to an EY Postgres database, follow the SSH tunnel instructions here. Hence the local 127.0.0.1 connection URL in this example.

The Heroku pg:transfer CLI plugin is a much more stable and flexible tool for migrating data between Postgres databases than the Taps gem and the corresponding db:pull or db:push commands. Use it to robustly manage data transfer between Postgres databases.

Presenting the Heroku Dashboard

Here at Heroku, we focus our energy on developer experience and productivity. Historically, this has revolved around command-line tools like the Heroku Toolbelt. As a polyglot platform, we have developers that come from all backgrounds — some that prefer command-line workflows and others that prefer web interface. Most use a bit of both.

Today, we’re introducing a new first-class interface to our platform: the Heroku Dashboard.

App Awareness and Discoverability

The new Heroku Dashboard features a fresh look and feel, optimized for readability and workflow efficiency.

The more apps you deploy to Heroku, the harder keeping track of them becomes. With Dashboard, you can instantly filter your apps not only by name, but also by stack, and buildpack.

App List

If there’s an app you access frequently, you can favorite it. This moves it to the top of your app list permanently.

Favorites

The new Activity view displays all code, config, and resource changes by every developer working on an app.

Activity

Additionally, if you specify an app’s GitHub repo then you’ll have clickable links to a diff of every deploy. Collaboration has never been easier.

New Horizons

As of today, the Dashboard is the default web experience for everyone on the platform.

Watch closely for updates and new features. Dashboard is a great foundation that allows for quick iterations and experimentation — a standard Heroku app that consumes our public API.

2012 Rails Hosting Survey results

A few months ago we invited the Ruby on Rails community to participate in our hosting survey. We’ve since published the results and created an infographic.

<p>To learn more, check out the <a href="http://rails-hosting.com/">Rails Hosting</a> site.</p><div class="feedflare">