Search This Blog


Wednesday, April 25, 2012

IronWorker Goes Hyperpolyglot - Adds Java, Node and Go Support

A hyperpolyglot is one who can speak six or more languages fluently. The term was coined by the linguist Richard Hudson in 2003 and derives from the word "polyglot", meaning one who can speak multiple languages.

Today marks a major step forward for IronWorker as we've opened the platform to a wide array of new languages, vastly expanding the possibilities of what you can do with it. IronWorker aims to be a language-agnostic platform that lets developers use the language they are comfortable with and, with today's release, we've come a lot closer to achieving that goal.

New Languages

In the past we've been focused on a few specific languages: Ruby, PHP and Python. Now we've added a bunch of new officially supported languages:

  • Java and other JVM Languages, such as:
    • Scala
    • Clojure
    • Groovy
  • Node.js
  • Go
  • It's even possible to run more languages, but we'll leave that discussion for another day 

Check the links above for how to get started using those languages and we're always here to help so please ask us any questions or let us know if you are having any problems, we respond quickly.

EV-9D9: "How many languages do you speak?" 
C-3PO: "I am fluent in over six million forms of communication..."

Tuesday, April 24, 2012 is a cloudControl Add-on

cloudControl has teamed with to make IronWorker and IronMQ supported add-ons within the cloudControl platform. cloudControl is one of the leading cloud platforms in Europe with thousands of energetic developers building applications and making heavy use of cloud resources and cloud services. fits perfectly into this picture.

cloudControl offers hassle-free agile deployment along with rock-solid app server autoscaling. supercharges the cloudControl platform by providing their developers with a fast and serverless way to scale-out their processing and use do things asynchronously and in parallel. 
With IronWorker, they can run thousands of tasks in parallel and shrink the duration of a set of tasks from hours to minutes. Developers can also offload processes from the front-end, providing users with a faster response, plus they can get reliable and flexible scheduling. All this without having to setup anything or manage servers. With IronMQ, developers can take monolithic apps and turn them into a set of loosely coupled components that are able to independently scale. An important pattern for companies developing responsive web apps that deal with many users.

Although we already serve many customers in Europe and around the world (almost the nature of cloud services), aligning more closely with a top European partner to closely connect with developers makes perfect sense. Small teams doing big things can be found the world over and cloud technologies take away many barriers.

Plus we take pride in being multi-lingual. It's something we've talked about more than a few times – and that you'll continue to hear about from us.

Learn more about the IronWorker and IronMQ add-ons on cloudControl. If you have any questions, you can always hit us up at our public chat room at

Wednesday, April 11, 2012

One Webhook to Rule Them All - One URL, Millions of Possibilities

Have you ever wished the service you were using had integrations with other third party services? If it supports webhooks, I'll show you in this post how to easily integrate with any service that has an API. And no server is required.

What is a Webhook?

"The concept of a WebHook is simple. A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST."

That is taken directly from

The Problem with Webhooks Today

There are some great services that support webhooks (otherwise known as a callback URL): GitHub, Tender, Freshbooks, Papertrail, etc, but the problem is they usually only support a few services. This is generally because the webhook is sort of useless unless the third party also has an endpoint that can accept the webhook and understand and do something with the data it's receiving. There are some solutions to this problem:

Thursday, April 5, 2012 + Claremont Colleges Hackathon is a big believer in helping close-knit teams do big things. Which is why we're enthusiastic supporters and sponsors of a growing set of hackathons around the country.

This weekend there's a hackathon at the Claremont Colleges in Pomona, CA. The focus here is to "build something a 5C student would love to use."

We're thrilled to be a sponsor of it. Any event centered around getting something awesome up and running over the course of a weekend captures our heart. Our advice, have fun and do lots of things in the background.

Monday, April 2, 2012

Why Aren't You Developing in the Cloud?

Cloud computing has completely altered software distribution. Traditionally, software licenses were purchased, installed and accessed on personal machines. Today, most applications are service based and accessible from any network connected device. E-mail, documents and even business applications have transitioned to SaaS applications and give users quicker access, more control and fewer dependencies compared to installable software.

Software-as-a-Service (SaaS) has become the most popular way to consume software; however, when it comes to developing software, the majority of developers have yet to abandon their local installations for service-based alternatives. Cloud application services are growing by leaps and bounds and it won’t be long before applications, both large and small, will be developed almost exclusively using cloud services. It all started for me when we started using Amazon's SimpleDB. There just wasn't an offline option so I was forced into using a service for my database that I couldn’t install locally. But now that I’ve done it, there’s no going back.

The number one objection to transitioning to a cloud development model is fairly simple: connectivity. The only way to get value from a cloud development environment is to connect to it. While Internet connectivity is fairly ubiquitous, it isn’t everywhere (yet). Developers on the go prefer to keep their projects locally so they don’t have to worry about Internet connection. Second would be performance. It is a lot slower to connect to your database in the cloud than it is to connect to a local database, but unless you’re moving lots of data, that is pretty negligible.