Ruby Shoes Tetris(November 07, 2014)

I was inspired by a talk from @jasonrclark at this weeks @pdxruby that reminded us that the Shoes project is still alive and well. I had a little free time so I thought I’d make a tiny contribution and take a day to port over one of my simpler javascript games to Shoes.

Shoes was is a cross-platform Ruby desktop GUI framework aimed at beginners wanting to get into programming. For those of us who have been in the Ruby community for a while we might have assumed that Shoes died when _why left the community. However, from the shoesrb.com history…

“Way way back in the day, there was a guy named _why. He created a project known as Hackety Hack to teach programming to everyone. In order to reach all corners of the earth, _why decided to make Hackety Hack work on Windows, Mac OS X, and Linux. This was a lot of work, and so _why decided to share his toolkit with the world. Thus, Shoes was born. Everybody loved Shoes. Many apps were made, and put into The Shoebox, which no longer exists. But, one day, _why left. In his memory, Team Shoes assembled, and carried on making Shoes. They released Shoes 3 in late summer 2010.”

… and they are actively working on Shoes4.

So here’s a version of Tetris you can run with Ruby Shoes:

Continued...

Daemonizing Ruby Processes(September 15, 2014)

Your application might need a long running process in order to:

  • Listen on a socket (e.g. a web server)
  • Subscribe to a queue (e.g. a resque worker)
  • Poll a DB job table (e.g. a DelayedJob)

Much of the time you will use an appropriate 3rd party server such as Unicorn, Resque, or RackRabbit, but sometimes you just want to write some Ruby code and make it daemonizable. To achieve this you might reach for gems such as Dante or Daemon-kit, and these are good options, but with a little work you can avoid the additional gem dependency and get a deeper appreciation for the underlying Unix process mechanisms along the way.

As part of my work on the RackRabbit server I had to learn a little more about daemonizing and forking unix processes, and so I wrote up a little how-to for those of you who might want to daemonize your own Ruby code without adding any new dependencies.

Continued...

SOA - Introducing RackRabbit(September 04, 2014)

In this series we have discussed:

We talked about why we might implement a Service Oriented Architecture in order to scale to meet…

  • the demands of our users
  • the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, the practical implications of building a distributed system, and the 3 main communication patterns of a distributed system:

  • Synchronous Request/Response
  • Asynchronous Worker Queue
  • Asynchronous Publish/Subscribe

When implementing SOA using HTTP, we discovered that we have access to a robust set of technical options such as Rack, Unicorn, HTTParty, Faraday, Redis, Resque, or Beanstalkd, but no single technology can provide for all 3 communication patterns.

When implementing SOA using AMQP, we discovered that we can implement all 3 patterns using a single technology, but the implementation details are a little more tricky, programming directly to the AMQP interface, and the infrastructure and community support for hosting production-ready consumers are lacking (e.g. there is no easy-to-program-to Rack interface, or Unicorn style server for easily load balancing RabbitMQ consumer processes).

Just like everything in our profession, there are trade-offs.

Continued...

SOA - using AMQP(September 03, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

In the introductory article we talked about why we might implement a Service Oriented architecture in order to:

  • scale to meet the demands of our users
  • scale to meet the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, and the practical implications of building a distributed system.

In the previous article we showed how to build an SOA using HTTP that implements the 3 main communication patterns of a distributed system:

  • Synchronous Request/Response
        using Faraday, Unicorn, and Sinatra.
  • Asynchronous Worker Queue
        using Redis and Resque.
  • Asynchronous Publish/Subscribe
       using Redis.

This article will show how to implement the same 3 communication patterns using a single technology, an AMQP message broker such as RabbitMQ.

Continued...

SOA - using HTTP(September 02, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

In the introductory article we talked about why we might implement a Service Oriented architecture in order to:

  • scale to meet the demands of our users
  • scale to meet the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, the practical implications of building a distributed system, and the 3 typical communication patterns we might need:

  • Synchronous Request/Response
  • Asynchronous Worker Queue
  • Asynchronous Publish/Subscribe

There are many ways to approach an SOA infrastructure, but within the Ruby and Rails community we tend to see the following two choices being considered:

  • SOA using HTTP - making an HTTP call to a rack-based server is bread-and-butter for the RoR community and so this is the natural technology we reach for when thinking about the synchronous request/response communication pattern. However we need to reach for additional technologies, such as Redis and Resque if we want to implement the additional asynchronous communication patterns.

  • SOA using AMQP - using a message broker such as RabbitMQ is not as common in our community as using direct HTTP calls, but this is a great option for providing a common transport for all three of our desired communication patterns (and more), as well as providing a robust, managed broker to act as the hub for all internal communication.

This article shows how to implement an SOA using HTTP.

Continued...

SOA - Overview(September 01, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

Table of Contents

Introduction

Regular readers of my (irregular) posts will know that I enjoy making fun little javascript games on the side, however my day-to-day work is generally spent building SaaS-style web applications, primarily within the Ruby on Rails eco-system.

For the last 7+ years I worked on a single RoR application that grew from an experimental prototype, into a beta product, through those first paying customers, via many, many short iterative releases, up to a large, robust, and feature rich application with thousands of users, supported by a company rapidly growing towards 100 employees.

Rails is a fantastic framework to get through those early years. It’s certainly not without it’s faults, but in terms of productivity and getting features to market it is hard to beat.

However, if we follow the vanilla Rails path we can easily end up with a large, monolithic application, and after a while begin to feel the creaks and groans of the framework and start to think a lot about the issue of scaling.

How are we going to…

Continued...

Development Values(May 14, 2014)

A couple of years ago, with the help of a co-worker, I put together a high level list of “Development Values and Principles” for LiquidPlanner. I was re-reading them today and thought they were well worth sharing…

(P.S. we’re hiring)

Values

  • Value Quality above both Quantity, and Speed of development
  • Value Clear above Clever
  • Value Maintainability above The Quick Fix
  • Value Collaboration above Individuality
  • Value Refactoring, Iteration, and Evolution above Engineering
  • Value Just-In-Time above Just-In-Case
  • Value Automated Testing above Manual QA
  • Value Metrics above Instinct
  • Value Readable Code above Comments and Documentation
  • Value Small but Complete above Large and Unfinished
  • Value Libraries and Components above Frameworks
  • Value Containment above Inheritance
  • Value MVP above Kitchen Sink
  • Value Realism above both Optimism and Pessimism
  • Value Thought above Action but avoid Analysis Paralysis
  • Value Pragmatism above Idealism
  • Value The User above all else
Continued...

Javascript Delta(May 03, 2014)

A couple of weeks ago I started a prototype for a horizontal shoot-em-up game in the style of the old c64 classic Delta. It was just a simple weekend project (although it ended up taking 2 - naturally) to allow the player to shoot some swirly alien bad guys…

… but it is in a good enough state to publish the source and let you play now:

  • arrow keys to fly
  • space to shoot.
  • shoot aliens
  • survive!
Continued...

Sprite Factory 1.6.0(March 16, 2014)

I have released a minor update (v1.6.0) to the sprite-factory ruby gem. This version adds 2 small features:


Direct support for ImageMagick

You can now use ImageMagick directly, without needing to install the RMagick gem dependency

Simply specify image_magick as the library, either using the command line tool:

$ sf icons --library image_magick

… or using the Ruby API directly:

SpriteFactory.run!('icons', :library => :image_magick)

Thanks to @willglynn for implementing this feature!


Added padding/margin support in the command line tool

The padding & margin options have been exposed in the command line tool:

$ sf icons --padding 2 --margin 3

Thanks to @miguelgonz for implementing this feature!


Installation

As usual, installation is just a gem away:

$ gem install sprite-factory

And detailed instructions can be found in the README.

Nothing fancy, just a minor update. Let me know if you have any problems/feedback.

Enjoy!


I took a little time out today to clean up a few loose ends and publish a tiny point-release to my javascript state machine library. The code, as usual, is available on github.

The release includes:

  • nodejs support
  • bower support
  • requirejs/amd support


And now that I’ve (finally) added nodejs support, you can run the tests without a browser:

$ cd javascript-state-machine
$ npm install
$ node test/runner.js

The Future

Continued...

All Articles