We used to run internal hackdays at Pachube and found them extremely productive. Come to work on Friday, use the Pachube API, make something cool and show it at the end of the day. They were always immensely useful for finding bugs and gaps in our API. In fact a single hackday was often better than weeks of R&D, when it came to improving the core product. For some reason they fizzled out over time but we have brought them back in 2012.

As we are rolling out oAuth soon, I thought having an oAuth themed hackday to kick off the year seemed logical. Others started getting excited about the prospect of the return of hackdays and extended the invitation out to interesting techies passing through London that day.

Suddenly something changed, as we had inadvertently imposed rules and a certain formality to proceedings. Even though we still managed to debug several issues within our oAuth workflow, the usual level of creativity and fun somewhat died.

I’ve had brilliant ideas brewing for weeks but they don’t fit the theme!

oAuth sucks!

Who is going to entertain the guests?

Must we form groups to include them?

After thinking about better ways of running them and agreeing with much of this post on stackexchange, I believe our next internal hackday should follow a few basic guidelines:

• Keep it within the team
• Start with everyone in one space at a certain time
• Require no participation or collaboration
• Provide lunch

Levent Ali · 8 January 2012 · hackday oauth pachube

We are hiring and will continue to do so over the next few months.

As you may or may not know, we were recently acquired by LogMeIn. What this means is that we can finally achieve the targets we’ve been striving to reach.

The only thing holding us back right now is the size of the team (we are 4 engineers).

What have we been working on?

Pachube is basically an API designed to facilitate the connection of every internet enabled device past, present and future.

Whether you want to store sensor readings, allow two remote devices to communicate/control each other, aggregate stats from small/large-scale research projects, check if you left the oven on, control traffic light timings based on traffic flow, see the impact of natural phenomena in realtime, study livestock, monitor and control your home, Pachube is the platform that allows all of it to happen.

However, to fully realise that on a global scale there is a ton of work to be done.

You can’t argue that this terribly named world “The Internet of Things” is going to be very real very soon. I can guarantee that Pachube are at the forefront and there are few, if any, London based startups that are as exciting and potentially epic as ours is.

How can you help?

We have massive amounts of work to do on the API but we also need to put a tremendous amount of effort onto our web front. We need to create a compelling experience for developers, manufacturers and most importantly anyone else familiar with a browser. We need new ideas and to implement existing ideas in order to shape the IoT at this crucial time in the industry.

Basically we need to scale the fuck up and reach the fuck out.

If you are interested, think you can help, want to disrupt the future of the internet and are primarily a nice person, we want to hear from you.

Here are a handful of our challenges interspersed with buzzwords:

• Storing massive amounts of time-series data
• Analysing massive amounts of time-series data
• Handling many many thousands of writes and reads every second
• Making Pachube powered hardware
• Designing social network sites and features
• UX
• Client side programming
• Functional programming
• Developing highly scalable socket / websocket servers (EventMachine / Node.js / Aleph)
• SQL (PostgreSQL)
• NoSQL (HBase / Cassandra / not-MongoDB)
• Continuous integration / automated deployment
• Coding Ruby
• Writing Pachube libraries in JavaScript
• Writing Pachube libraries in all languages
• Building interactive documentation for software developers and hardware makers
• Writing mobile applications for iPhone and Android
• Writing standards for the IoT
• Communicating/educating on the potential of an IoT
• Defining the IoT

We want front-end developers, software developers and the devops master now.

Questions? Interested?

Email me or find me on Twitter!

Proof that we are actually hiring

http://community.pachube.com/jobs

Levent Ali · 6 September 2011 · pachube iot ruby

Disclaimer: That’s Serge on the left and Niki on the right. Not Serge and Ruba.

Levent Ali · 6 April 2011 · photography

Here at Pachube we’re great for devices but not so much for people. Whilst our API is a good fit for sensors, Arduino’s and the like our website is not an enthralling place to be.

We’re putting a tremendous effort into changing this around and once we’re ready it’s going to open up Pachube’s possibilities for everyone.

Many of our recent discussions have revolved around how we open up the wealth of data contained within Pachube, and make it more accessible whilst engaging our users.

However behind that static façade there really is a tremendous amount going on thanks to the multitude of devices and sensors plugged into us.

For this week’s hackday I built a realtime counter that just shows how much information is coming into our system at any moment. It’s using our Socket Server.

Pachube Devices Served

Note: The counter only includes public feeds and each update could include any number of individual datastream updates, so the figures are rather conservative.

Levent Ali · 1 April 2011 · pachube ruby websockets eventmachine

I built Agileista years ago. We use it at Pachube to manage our backlog and iterations. For some time I’ve been meaning to add realtime updates to the task board.

Using the standard pub/sub model I wanted it to work as follows:

1. User makes an update
2. Rails publishes changes to the task board’s subscriber channel
3. Current subscribers instantly receive in their browser

We built a socket server at work that follows this pattern using EventMachine and RabbitMQ. This time around I wanted to use Redis and Node.js. Well this is what Alex MacCaw’s rewrite of Juggernaut does. It provides a Ruby interface for publishing messages to Redis. It leverages Socket.IO which selects the transport mechanism your browser supports (WebSockets, Flash, AJAX long polling etc.). You connect to the Node.js server via JavaScript and you publish messages via Ruby.

Follow the Juggernaut README and you’ll be up and running in minutes. I installed Node.js and Redis via homebrew on OS X during development. Here are the steps I took to get that running in production…

Production setup tutorial:

Most of this is one off server configuration. Only a few lines of code were required to modify Agileista, thanks to Juggernaut.

I’m running Ubuntu 10.04.

Install Redis

wget http://redis.googlecode.com/files/redis-2.2.2.tar.gz
tar xzvf redis-2.2.2.tar.gz
cd redis-2.2.2
make
sudo make install

Install Node.js

wget http://nodejs.org/dist/node-v0.4.2.tar.gz
tar xzvf node-v0.4.2.tar.gz
cd node-v0.4.2
make
sudo make install

Configure the Redis Server via Upstart

# /etc/init/redis-server.conf
description "redis server"

start on runlevel [23]
stop on shutdown

exec sudo -u rails /path/to/redis-server /path/to/redis.conf

respawn

post-start script
    # Make a .pid file for monit
    PID=`status redis-server |egrep -oi '([0-9]+)$' |head -n1`
    echo $PID > /var/run/redis-server.pid
end script

post-stop script
   # Remove the .pid file used by monit
   rm -f /var/run/redis-server.pid
end script

Start the Redis server

sudo start redis-server

Configure the Juggernaut server via Upstart

# /etc/init/juggernaut.conf
description "node.js server"
author      "lebreeze"

start on runlevel [23]
stop on shutdown

script
    # We found $HOME is needed. Without it, we ran into problems
    export HOME="/home/rails"
    cd /u/apps/juggernaut/current
    exec sudo -u rails node server.js >> /var/log/node.log
end script

Start the Juggernaut server

sudo start juggernaut

Publish messages onto Redis from your Ruby app

# TaskBoardController
def update
  do_stuff_with(@task)
  Juggernaut.publish("task_board_#{@task_board.id}", @task.as_json)
end

Include the necessary JavaScript files in the view

<script src="/javascripts/json.js?1300034527" type="text/javascript"></script> 
<script src="/javascripts/socket_io.js?1300034527" type="text/javascript"></script> 
<script src="/javascripts/juggernaut.js?1300034527" type="text/javascript"></script> 

Connect to the server

var log = function(data){
  // notify
};

var update = function(data){
  // update the taskboard
};

var jug = new Juggernaut({secure: ('https:' == document.location.protocol)});

jug.on("connect", function(){ log("Connected") });
jug.on("disconnect", function(){ log("Disconnected") });
jug.on("reconnect", function(){ log("Reconnecting") });

jug.subscribe("task_board_NN", function(data){
  update(data);
});

Monitor Redis and Juggernaut server via monit (extra credit)

sudo vim /etc/monit/monitrc

# monitrc
check process redis with pidfile /var/run/redis-server.pid
  start program = "/sbin/start redis-server"
  stop program = "/sbin/stop redis-server"
  if failed host 127.0.0.1 port 6379 then restart
  if 5 restarts within 5 cycles then timeout

check host nodejs with address 127.0.0.1
  start program = "/sbin/start juggernaut"
  stop program  = "/sbin/stop juggernaut"
  if failed port 8080 protocol HTTP
    request /
    with timeout 10 seconds
    then restart
# end monitrc

Levent Ali · 13 March 2011 · node.js ruby juggernaut rails monit redis rabbitmq eventmachine ubuntu