One Weird Trick to SSH into your JVM

If you’re anything at all like me, you write perfect code.  And once you’ve written that code, it runs flawlessly and you never have any reason to look at look at it while it’s actually running.  I mean, seriously, you’ve written tests that show everything working, and besides that, when you’re as handsome as we are, who would want to even try to tear your eyes away from a mirror?

Since you’re reading this, I’m going to go out on a limb and guess that you’ve only landed on my blog in order to enjoy a quick moment of mirth at the expense of the imperfect proles who actually need my advice.  Drink it in.  You’ve earned it.

If you don’t fit into that camp, don’t worry!  You’re exactly the person that they had in mind when they designed Ruby!  Or Python!  Or any one of a dozen other languages with a REPL.  Don’t worry, I know you know what a REPL is, but I’m going to prove that I know what it is, so that you can skip straight to agreeing with me, thereby proving that you knew what I was talking about the whole time.

“REPL” is just technobabble that means “Read-eval-print loop”.  Still too much technobabble?  The REPL is the cool little tool that lets you run big-boy code from an interactive shell and it gives you the ability to get inside the computer and poke around while your program is running.  It’s so simple.  It’s IN the computer…:

I'm (not) a computer

I’m (not) a computer

The above screenshot gives a tiny example of the sorts of things you can do with your Ruby REPL.  I picked Ruby for this example, but you’d see something similar in any language that provides a REPL.  You can do simple stuff like print a string, or, even better, you can dig into your application and just mess with things!  After all, who doesn’t like to mess with things?!  That couldn’t possibly have side-effects, right?

Anytime you can use an interactive mode like the ones I mentioned above, it’s going to be easy to get close to the application that you’re developing.  These tools are extremely powerful, especially when you combine them with some sweet Dependency Injection action.

One day, you’ll see the light that is Java and you will be amazed.  With a healthy supply of semi-colons, you’ll migrate your application to Java while shedding a tear for all the lost time that you could have spent together.  Migrating from one language to another is easy, so you’ll immediately want to fire up your Java interpreter and mess with all of the things in your new Java app.

Unfortunately for you, Me-from-the-past is going to tell you “No dice.”  Java doesn’t come with an interactive mode out-of-the-box.  The closest that you could come to a REPL in Java was using the Java Management Extensions (JMX) to examine registered resources.  After you register a few Beans, you’ll hopefully be able to run something like JConsole to look at your application’s guts.  If you did everything right, you’ll probably see some objects that you can look at… and you’ll immediately begin thinking that maybe you should migrate back, if only to get your REPL back.

Fortunately for you, Me-from-right-now is here to tell you that our own brilliant Marshall Pierce has felt your pain and has leveraged the arcane magics of Groovy and SSH to provide you with a mega-hammer that he assumes you are not going to use to hit yourself in the face: a interactive prompt for your JVMs, both local and remote! A local REPL for exploring your app in dev mode is great, but a remote REPL for poking around in your live app is even better. (Where by better, I mean dangerous and awesome.)

“Wh—…H—…How did he do that?” you might ask, ever so eloquently.  Basically, you’ll embed a tiny SSH server that exposes a Groovy shell that can execute arbitrary code inside a running JVM.  Marshall has helpfully provided a small demo app that shows exactly what this looks like.  Seriously, go run the example project.  When you do and you realize how you have now become the master of time and space, you won’t have anything to say except, “That was easy.”

Hopefully, you skipped right over that part about executing arbitrary code in your JVM, because that sounds terrifying.  But, if that made you a little queasy, you can rest easy knowing that your precious JVM is safe and sound.  With only a few more characters, you can tell your app where to find a set of public keys (RSA or DSA) that it can use to authenticate SSH requests.  Now, when you run your Groovy shell, you just have to specify the location of your private key file, and you’ll automatically get the secure handshake that feels ever-so-good.

If you’re looking for more detail, you should check out the project’s public GitHub page, where you will find helpful instructions on how you can start poking around where James Gosling never intended for you to be…

2T2J Release

You certainly didn’t ask for it, but we’re giving it to you anyway!

Today, Palomino Labs is equal parts proud, confused, and apathetic to announce the release of 2 Tumble 2 Jump, the second in a series of games that puts the player squarely where they want to be: in the mind of a frozen tumbleweed.

The masses have spoken!  We have listened to what they said!  And we have ignored what they said in favor of bringing you more Tumble Jump!!!  After all, who knows you, better than us?  And we say that you want more tumbleweeds!

You probably thought that your phone doesn’t need more than one game about tumbleweeds.

You probably thought that you could escape Ol’ Slopey Mountain.

You probably thought that Yetis and cacti don’t share exactly the same shape.

You probably thought that we would introduce new mechanics in a sequel game.


We humbly accept your apology, and we offer you the chance to atone for your past mistakes by downloading 2 Tumble 2 Jump right now.  You’ll find the same tumbling and jumping that enthralled you the first time around, but this time it’s winter.  What does that mean?  It means that there’s snow now!  And Yetis!

Submit your PTO requests; arrange for the kids to stay at Grandma’s; prepare the hydration IVs— because you’re going to want to play this game way more than you should.

Too Much Pressure or: How I Simplified My iOS Design with the Tweaks Library

A few months ago, Facebook released an iOS library that they’re calling Tweaks and that you should really check out.

Tweaks is designed to bridge the gap between developers and designers during the development phase of a project.  Unless a single person is playing the roles of both the designer and the developer, there’s going to be a lot of communication overhead during the refining process of the UI.  The process usually starts with the designer bringing mockups to the developer.  The developer takes these screens and tries to get as close as possible to what the designer had in mind.  Since we’re talking about (at least) two different people, thinking in (at least) two different ways, we can almost guarantee that the product is not going to match the vision.  Even if the developer somehow magically manages to implement the exact thoughts of the designer, it may turn out that what the designer had imagined doesn’t make sense after all.  Regardless, in a project of any scale, both sides are going to spend a lot of time going back and forth in a conversation that you might recognize.

Developers and Designers: Can't we just get along?

Developers and Designers: Can’t we just get along?

The real problem here is that we can’t afford to have designers and developers working on the same screen while a UI is being created.  It would be hugely inefficient because they speak different languages (or at least different dialects) and it’s pretty much impossible to keep both people actively working the whole time.  That’s why we’re forced to have this back-and-forth conversation that wastes time with multiple deployments and context-switching.

It seems to me like Tweaks is going to consolidate the back-and-forth into a single conversation that looks more like this.

Fewer iterations == more efficient.

Fewer iterations == more efficient.

Tweaks allows a developer to expose certain UI properties to a designer (or really, anyone who has a dev build of the application) who can update those values dynamically.  While the designer is reviewing the developer’s work, they can use the shake gesture to bring up a secret menu that lets the designer change values on the fly.

One easy example to imagine is adjusting the background color.  This is an extremely easy task for a developer, but the time required to redeploy and pass the changes on to the developer is going to be wasted.  On the other hand, the designer might not know how to change the background color and might not even have access to the source.

Before Tweaks, the developer probably would have hardcoded the view with something like this:

self.backgroundColor = [UIColor colorWithRed:0.2

And then when the designer comes back and tells the developer that the background color should be more red, they’ll update those hardcoded values and push a new version to the designer.  If the designer doesn’t have specific RGB values in mind, this could be repeated several times while they zero in on the color that is “just right.”

Instead, Tweaks is proposing that you replace those hardcoded values with a Tweaks macro like this:

self.backgroundColor =
    [UIColor colorWithRed:FBTweakValue(@"Window", @"Color", @"Red", 0.2)
                    green:FBTweakValue(@"Window", @"Color", @"Green", 0.9)
                     blue:FBTweakValue(@"Window", @"Color", @"Blue", 0.2)

The first three arguments describe where in the Tweaks hierarchy you’ll find the adjustment.  In this example, you’d be able to change the red component of the RGB value by going to the “Window” section and looking for the “Color” section of that table.  As you can see below, you’re able increment or decrement the values that developer exposed, or you can tap the value itself to show a keyboard if you have a specific value in mind.  In addition to numeric values you can expose other basic data types like strings and booleans.

What the designer will see after they shake the device and navigate to the leaf values.

What the designer will see after they shake the device and navigate to the leaf values.

Are you worried about how this library will affect your production releases?  You should be!  However, you can rest easy knowing that the adjustment functionality is disabled by default in production.  When you deploy in production mode, the macros are expanded into the default values that the developer provided.  This means that you don’t incur any performance penalty for evaluating values, and at the same time you don’t expose any secret dev options to the end user.

Final Thoughts?

  • It’s a very cool idea and one that I’d really like to start including in my iOS projects.
  • Fortunately for us, Ron (the brilliant gentleman who most often wears the designer hat at Palomino) is more than capable of manipulating an iOS view himself, so I’m not sure how much time it would actually save us.
  • This is still going to require some designer-developer face time, so that the developer can show the designer what things can be tweaked.  It’s easy to understand in a small example, but when you have a real app with lots of changeable properties, the developer is going to have to be very careful about how he organizes the hierarchy of adjustable properties.  It would be very helpful to take some time to explain his scheme to the designer.
  • This library would really benefit from an export function.  When a designer finishes making all of the adjustments that he wants, there should be some easy way for him to pass the new (changed) values back to the developer.  As far as I know, there is currently no functionality to do this.  Update: it looks like this ticket was raised to accomplish the exact thing that I want, but it hasn't been merged yet.  Hopefully soon!
  • The library is still young and has a few rough edges.  For example, installation via Cocoapods did not work for me.  I found this issue that claims to resolve the problem, but it was easier for me to just drop the library into my project.  If it continues to grow and be maintained, I expect these sorts of problems to disappear, but make sure you go into it with your eyes open.

Introduction to Docker with Rails

Docker is a lightweight framework for containerizing applications. Employing the Linux cgroups, Docker allows containers to be run in a virtual environment that is completely isolated from the host system and other containers, without the overhead of hardware virtualization. It’s a lot like chroot applied not only to filesystems, but also the process and memory space.

The Docker community is full of wide-eyed idealists who see the world as a place of default configurations and simple use cases using only the latest things. The Docker examples include Node.js, CouchDB, and Riak, among others. No mention of, say, Rails, despite it being one of the most popular frameworks over the past 5 years. I’ll try to fill that void.

What this tutorial covers

This blog post is an introduction to Docker for folks who use Rails. You don’t have to know anything about Docker, but you do need to know how to get a Rails app running. I’ll walk you through setting up Docker for development on a Mac, creating a Dockerfile, and running that Dockerfile on your development Docker host.

Read on

Easy, Fast, Powerful: This is Your Rails on Ninefold

At Palomino Labs, we strive to recommend to our clients frameworks and platforms that are best-suited for their products. As such, we’re constantly evaluating new technologies. Recently, I spent some time checking out Ninefold, a Rails hosting platform that’s aiming to combine the ease and low barrier-to-entry of Heroku with the configurability and power of AWS. Over a couple of days, I branched a simple in-house app and pushed it to Ninefold. I’ve distilled my first impressions down to a few points that I hope are useful the next time you’re looking for a Rails host.

As you’re reading this, it’s important to keep in mind that the Ninefold Rails platform is relatively young and still looking to build out it’s feature set.  With that in mind, a big part of what I’m evaluating is potential.  There are certainly other, more mature tools that have more features, but what I saw in Ninefold was promising enough to bring it to your attention.


Before you start using Ninefold, you should know that the GUI is going to let you do most of the things you want to do, but it’s going to be in a very no-nonsense kind of way. If you came from the Ninefold home page—which looks very cool with its faceted design—you might be expecting a dashboard with a lot of personality and a cool design. I wouldn’t call any of the dashboard pretty, but any developer is going to be immediately comfortable within it, and it’s going to let you get things done efficiently.

The last time you'll see any color...

The last time you’ll see any color…

The no-nonsense dashboard...

The no-nonsense dashboard

I found that it was fairly straightforward to navigate around the dashboard and I never found myself asking “Where do I go now?”

The one big downside to the web dashboard is that it tends to be slower than I’d like.  Every tab is a separate page load, and it doesn’t take long to start feeling the pain of that.  That said, I didn’t feel like it was unusably slow and I’m hoping that that’s something that would improve with time.


In my experience, log aggregation is one of those things that seems like it should be easy, but is never as elegant as I would like it to be. I am very happy to say that this is not the case for any Ninefold apps that you might create. Once you deploy an app, the Ninefold dashboard shows a logging section that makes debugging and issue resolution much easier.

The logs for my application along with the sources that are available.

The logs for my application along with the sources that are available.

Log Searching

If you look at the screenshots, you’ll notice that the dashboard kindly offers you the ability to string-search whichever logs you’re looking at. When I look at a log, I almost always want to do some kind of search like this, so the fact that it’s built in is pretty cool and it saves me a bunch of munging that I might otherwise have to spend time on. As happy as I was to see a built-in log searcher widget, I was even more excited to see the ability to select sources and hosts of logs to filter by.

Log Filtering

When I write to a log, I always feel like I’m trying to walk a fine line between giving enough information to diagnose issues that may crop up and giving so much information that the really important stuff is lost in a sea of garbage. Ninefold makes me feel much better about my logging because they allow you to restrict what you’re looking at to one (or many) of any of a dozen different logging mechanisms. Most of the time, I don’t want to see something like the migration logs, so I can remove those from the list of what is displayed. Being able to filter at a high level like that is really cool and it’s something that I’m going to miss the next time I’m not on Ninefold. It’s worth noting here that you can do the same thing, relative to the servers that you’re deployed on. If you’re running on two different hosts, you can restrict your log view to only look at the host(s) that you’re concerned with. I was running a simple app with just a single host, so I didn’t have reason to use that feature, but I can imagine it being really cool in a high-traffic production environment.


It seems to me like Ninefold is still trying to gain traction (at least here in the States) so they don’t have nearly as big of a user community as some other platforms might.  When I started using Ninefold, I was a little worried that this would mean that it would be easier to get stuck on one issue or another.  After using it for a while, I think that it would be hard to argue against that unfortunate truth.  However, in my experience, the in-app support that Ninefold offers is good enough that the smaller community ends up not even being a factor.  I rarely had any problem figuring out what to do next, but when I did get stuck, Ninefold has a little “Chat Now” dialog on the bottom of every page that connects you almost instantaneously with a support person.  Normally, I avoid these support chats as much as possible, but the person who answered my support requests was prompt, obviously familiar with the framework, and had the power to solve my problem.  I’m no longer worried that I’ll run into any sort of significant blocker that would halt my development.

Data Migration

The thing that I was probably least happy with during my Ninefold experience was the way that you interact with data.  I started with an app that one of my coworkers built that tracks the beers that we’re trying at Palomino Labs.  The app is new and the existing dataset is relatively small, so I wanted to import the data from the real app into my test app.  Unfortunately, it doesn’t seem like there’s a good way to do that from the dashboard.  I was able to take a snapshot of the other database without any problem, but I couldn’t find any way to bootstrap my app with that snapshot.  I ended up using the Ninefold CLI gem to manually recreate a few important pieces of data (e.g. app user accounts) and then living in a sad reality where my app didn’t have much data.

At this point, I would like to add two caveats to my complaints here.  First, like I mentioned above, Ninefold provides a CLI that I didn’t explore much, but that seems like it would be pretty useful.  I didn’t try to do any sort of data restoration through that system, instead preferring to use it just like a Rails console.  It’s possible that the CLI provides a way to restore database backups, but I was trying to restrict my usage to the dashboard as much as possible.  The second caveat is that I mentioned this specific use case to one of the Ninefold developers last time I had a chance to talk with them, and it sounded like this might be on the short-term roadmap.  I’m hopeful that the next update to the dashboard includes a means to restore backups.


The first thing that I’ll note about deployment is that it’s extremely easy.  If you have a git repo in Github or Bitbucket, Ninefold provides you with a handy little wizard that will create your app in about 30 seconds.  It’s easy to deploy from branches, and you can check a box to add post-commit hooks that will automatically redeploy  your app whenever you make a change.  I never had any problems with the post-commit hooks on this project, but one of my coworkers reported that the hooks stopped working for him mid-development.  This is one of the areas that I’m willing to overlook some rough edges because of the new-ness of the platform and I’m fairly confident that this is a piece of functionality that the Ninefold developers are fully on top of.

The big downside to the deployment process was that it seemed to take a fairly long time for me.  Due to a few of my own mistakes, I had to redeploy our (small) app 3-4 times in a short timespan, and it seemed like I was waiting about 10-15 minutes for each deploy.  I don’t expect anything blazingly fast, but I spent more time waiting on a deployment than I would’ve liked.


At the moment, the Ninefold ecosystem is a little bit young and that shows in the number of add-ons that are available to include in the app.  There are a handful of cool-looking modules (e.g. New Relic, SSL, etc.) that you can add to your app with the click of a button, but you’ll need to wait (or roll your own) if you want to use any modules that aren’t on the shortlist.  That said, the number of add-ons that ARE available right now is totally reasonable given the age of the platform, and they claim some interesting functionality (like when they set up a New Relic account for you, if you don’t already have one).  I’m optimistic that more tools are going to get added as time goes on, so if you have something you need, try reaching out to them.


I have yet to see a Rails hosting platform that is really good at splitting an app into different environments (e.g. staging and production environments for a single logical app) and I didn’t feel like Ninefold did much to solve that problem.  I only deployed one version of our app, but when I talked to Hayden about how he solved the environment problem, he told me that he just handles the environments as separate apps.  So, we have one app for production and one for staging and there is nothing (except the code) in common between the two.  I don’t fault Ninefold in any way here, because I’m not sure how I want these to be related in the interface, but it seems like they could be linked better.


After spending some time with Ninefold, I’m fairly happy with the service.  It’s still a young product, but what they have is solid and, even better, they seem to be moving in the right direction.  If you have the time, I’d definitely recommend checking it out to see if it fits in your workflow.

Ext JS 5: Now With 25% More Ext JS

We’ve been using Ext JS since the days when it was still YUI.  With every new version, the framework has become faster, clearer, and more feature-complete.  So whenever a new version is announced, we’re excited to see what’s next.  It’s sort of like a really geeky Christmas.  Here’s a few of the newly-announced features coming in Ext JS 5 that we’re most excited about.

  • Better Touch Support.  If you’ve ever tried to use your Ext JS 4 application on an iPad, you know that the experience leaves a lot to be desired.  A few of the most glaring issues — scrolling and touch events — have been resolved in Ext JS 5.  It’s important to stress that Ext JS 5 is still a framework for building applications for desktop browsers, and Ext JS 5 is not a replacement for a mobile framework like Sencha Touch, but at least now your Ext JS apps will be functional on an iPad.
  • Two-Way Data Binding.  Previous versions of Ext JS made many complicated things very easy: grids and RESTful AJAX come to mind.  But one thing that always bothered us was that updating a view when model data changed — or vice versa — was always more work than it seemed like it should be.  Ext JS alternatives like Ember.js, for example, make binding data to views painless by comparison.  With Ext JS 5, two-way data binding is finally a reality. Gone are the days of boilerplate code juggling data changes between the various layers.  Ext JS 5 introduces a very simple but powerful templating language to wire views and view models together.  Rejoice.
  • View Controllers. Ext JS is great for building reusable components for large applications.  One drawback of this approach, however, is that you often find yourself having to choose between cluttering your view classes with control logic specific to that view (violating MVC), or duplicating that control logic in increasingly-complex, bloated, and non-DRY controllers.  This problem is magnified when you start needing to manage multiple instances of the same component independently of one another.  Well, good news friend: Ext JS 5 introduces the concept of a View Controller, which is essentially an instance of a controller tied to a specific view instance.  Instantiating a second instance of the view creates a second, independent View Controller.  Ext JS 5 even takes care of the memory management for you.  We expect that this will make our applications far simpler and more maintainable.
  • View Models.  Another anti-pattern that we often find in our Ext JS applications is that data-level logic often creeps into view classes.  Think store configurations, or manipulating model data (e.g., concatenating first and last name, or calculating averages).  The new View Models in Ext JS 5 are classes (again, tied to specific view instances) responsible managing data munging so that views can just be views.  Together, View Models and View Controllers are a huge win for separation of concerns enthusiasts like ourselves.
  • Routing.  Previous versions of Ext JS have had token support for URL-based routing, in that they provided a utility class for interacting with hash changes.  In practice, though, deep-linking and URL-based routing required writing a fair amount of custom logic.  This meant that deep-linking was often either completely ignored or bolted on later as an afterthought.  In Ext JS 5, routes are now first class citizens.  We can now define routes in the controller, complete with pattern-matched URL tokens, and per-action interruptible before filters.  Routing in Ext JS 5 is now so easy that there’s no reason not to build it into your app from the beginning.
  • Chained Stores.  Ext stores make it very easy to load and filter data from a server.  But what if you want several stores with slightly different views of the same basic dataset?  If you apply filters, those filters are reflected in every component that uses that store, so filtering a grid might have unintended consequences elsewhere in your application.  As a result, it becomes common practice to create several different versions of the same basic store.  While this is conceptually easy to maintain, it adds quite a bit of memory and network overhead, as loading these stores will actually load the same records individually.  Enter the new Chained Stores.  Now, multiple stores can share the same pool of records (each of which is loaded over the network  only once), while each store has their own filters applied.  It’s the best of both worlds: clear code, and efficient memory and network usage.
  • Data Sessions.  Ext JS 5 introduces a new concept called a Data Session, which aims to keep track of multiple (possibly dependent) changes to several models, allowing for efficient and intelligent bulk updates.  Data Sessions can also be used to isolate change sets, in effect giving you some of the powers of database transactions.  This feature is definitely a departure from how JavaScript developers are used to interacting with models, but it sounds like a very powerful new tool that’s worth checking out.
  • Components in Grid Cells.  We can now put buttons in grid cells.  That’s all I have to say about that. (But sparklines look pretty cool too.)

Those are just a few of the improvements coming in Ext JS 5.  For a more complete list, check out What’s New in Ext JS 5.  We’re certainly looking forward to all the new goodies.

What’s Being Poured at Palomino Labs

Here at Palomino Labs, there are many things that are important to our culture. If you take a tour of our office, we hope many of these passions will be apparent. While you won’t see a taqueria built into one of our conference rooms, or a smoker out on our office patio (also known as the roof of the yoga studio next door), some things might catch your eye.

In the hallway you’ll find our coffee station, with a Breville espresso machine and a Chemex, as well as a dozen or so varieties of beans from a number of our favorite roasters. On display in the main work area are our bowling trophies, including Ron’s 1st place win. And then… there’s beer.

Read on

Parse Gotchas

Backend as a Service (BaaS) companies seek to provide you, the developer, with a reliable backend solution that is quick and easy to use. With one of these services you can, in theory, save yourself the time and costs of configuring AWS servers and load balancers, or building and deploying a Ruby codebase to Heroku. However, from our experience working with Parse, one of the leading BaaS providers, we encountered a number of major gotchas that ended up making the development process take a lot longer than we estimated it would have, had we built out a Ruby backend ourselves. We hope this post will help developers realize the promise of Parse as a BaaS and avoid the efficiency killers that hampered us.

Some Backstory

Parse is the latest BaaS provider we’ve experimented with, but it is not the first. If you’re familiar with our blog, then you’ve likely seen our post on how to build An App in an Afternoon using StackMob. We liked the idea of BaaS, especially as a tool for rapidly prototyping web apps, and intended to use StackMob as part of an application to help a startup vet their idea. We had just sent our client a proposal and were out for our regular Taqueria Tuesday lunch when it was announced that PayPal was acquiring StackMob.

Read on