Introducing madmin: An admin console for generating mock services with RESTful URIs.

January 29th, 2013 by Todd Anderson


madmin is a node application that provides a means to construct RESTful URIs that are immediately accessible on the server. While URIs can be defined using the command line – using such CLI tools such as cURLmadmin also provides an admin console as a GUI to aide in defining the URI and JSON response data structure.

The github repo for madmin can be found at


madmin was born out of the intent to minimize time spent by front-end development teams building applications against a living spec for service requirements.

> The Problem

We found that our front-end developers were curating two service layers implementing a common interface during development of an application:

  • [Fake] One that does not communicate with a remote resource and provides _fake_ data.

    Used during development without worry of remote endpoint being available (either from being undefined or no network) and can be modified to provide different responses in testing application response.

  • [Live] One that does communicate with a remote resource, sometimes utilizing libraries that abstract the communication.

    Used for integration tests and QA on staging before pushing application to production.

This would allow the service layer dependency to easily be switched out during development and deployment while providing a common API for other components of the application to interact with.

Though these service layers are developed against the same interface providing a common API, the curation of both in tandem during development can be exhaustive timewise as specifications and requirements change. When we multiplied that curation time across the numerous applications being developed, it became clearer that the fake service layer needed to be eliminated from development – especially seeing as it is not part of the release or unit tests at all.

> The Solution

Instead of defining the service layer as a dependency between these two implementations, if we could define the endpoints that the service layer communicates with then we could eliminate the need to have a fake service layer.

Just as the service references are changed from staging to production, why couldn’t we provide a living service endpoint with URIs that are being discussed and hashed out between teams. As well, why can’t we deploy that service locally and eliminate the need for a network resource to boot – we could continue our front-end development while relaxing on some remote un-connected island!

That is what madmin sets out to do.

> The By-Product

Though the initial intent was to eliminate the curation of an unnecessary service layer from front-end development, by defining RESTful URIs using madmin we were actually providing useful documentation of the service layer and opened up comminication between the back-end and front-end teams with regards to requirements and data structure.

Opening channels for communication is always a plus, and the fact that it provided self-documentation just seemed like a winner!

:: What It is Not

madmin is not meant to replace writing proper unit tests for client-side applications that communicate with a remote service nor is it mean to stand in for integration testing.


The madmin application works by updating a target JSON source file that describes the RESTful URIs. This file is modified using a RESTful API of the madmin server application, itself. You can check out the schema for the source JSON file that defines the API at

While it is possible to interact with the madmin server-side applicaiton using the command line – with such CLI tools such as cURL – a client-side applicaiton is available that provides ease of use and self-documentation.

> Usage

Full instructions on how to clone and install dependencies for madmin can be found at the repository for the madmin project:

Once installed, you can start the madmin server from the command line with the following options:

$> node index.js [port] [json]

The following example shows it’s usage and the default values:

The json source file provided will be read from and modified as you add URIs in madmin. The most common and easiest way to add URIs is to use the client-side console application available at http://localhost:<port> after starting the madmin node server.

> Client-Side Console

Once the server is started, you can access the GUI console for madmin at either: http://localhost:<port>/ or http://localhost:<port>/admin, with the <port> value wither being the default (8124) or the one specified using the --port command line option.

With an empty JSON API resource file, you will be presented with a console that provides an “add new” button only:
Empty madmin console

Upon adding a new route, you are presented with an empty editable console with various parameters:
Empty new route in console.

The following is a breakdown of each section from this route console UI:

– Method –

The Method dropdown allows you to select the desired REST method to associate with the URI defined in the Path field:
Route Method panel

– Path –

The Path field defines the URI to add to the REST service:
Path panel

The Summary field allows for entering a description for the URI. When input focus is lost on the Path field, the listing of Parameters is updated and allows for providing descriptions for each variable:
Route with multiple parameters

– Response –

The Response field allows for defining the JSON returned from the URI. As well, you can choose which response to provide:
Route Response panel

In reality it will return a 200 status with the selected JSON from either Success or Error. We often supply errors on a 200 and parse the response. This was an easy way for the team to coordinate the successful and error responses that come in JSON from the request.

Viewing Route URIs and Responses

When saved, the new route will be added to the supplies source JSON file and the client-side madmin console will change to the listing of URIs defined:
Saved Route to madmin

As well, the path and its proper response will be available immediately and available to develop against.

With Error selected from the Response field:
Defined Error Response

With Success selected from the Response field:
Defined Success Response

As mentioned previously, the source JSON file provided when launching the madmin server is updated while working on the URIs. If left to the default – or otherwise accessible from the server directory – you can point your web browser to that JSON resource file and check for validity:
Updated JSON route URIs

— note —

The default admin console location can be found at the http://localhost:<port>/admin location. As such, /admin is a reserved route and can not be defined as a valid URI in madmin.

It is on the TODO list to define a custom URI for the admin portal of madmin in order to allow the currently reserved /admin.


> Server-Side

madmin server-side application has been tested against Node.js version >=0.8.4

> Client-Side

madmin client-side application utilizes some ES5 objects and properties – ie, Object.create and Array.prototype.indexOf – and does not load in an additional polyfills to provide support for non-modern browsers.

The madmin client-side application should work properly in the following:

  • Chrome 12+
  • Safari 4+
  • IE 9+
  • Opera 12+

Grunt Integration

The madmin repository has build files for grunt with support for <=0.3.x (grunt.js) and ~0.4.0 (Gruntfile.js) and tasks for linting and testing both the server-side and client-side code utilizing Jasmine.

To run the grunt build tasks simply run the following from the command line in the directory where you cloned the madmin repository:

Depending on your install version of grunt the proper build file should be run. To learn more about grunt and how to install, please visit the grunt project page.


We saw a need here at Infrared5 to cut out front-end development time in curating multiple service layer implementations in order to support development efforts when resources – including server-side and network – were unavailable. The madmin application is our effort in reducing that time and extra effort and code that never saw the light of staging or production.

While doing so, we hope madmin can open up the communication channels between server-side and client-side teams in discussion service requirements and JSON data structure, all while having a living document of the endpoint URIs.

Hopefully you will find it as useful as we have!

, ,

Red5 1.0.1 Released

January 15th, 2013 by Paul Gregoire

Red5 1.0.1 Released

Announcing the release of Red5 server version 1.0.1 Final.
This is primarily a bug-fix release, coming just a little over a month after the 1.0 release. The following 13 bugfixes are addressed in this release:

  • Admin application fixed
  • ClientBroadcastStream was modified to handle stream listeners more efficiently
  • Fixed RTMPS server freeze
  • Plugged memory leak in the RTMP protocol decoder
  • Fixed several minor issues with client streams
  • Addressed tight-loop issue bubbled up from Mina when file handles are exceeded
  • Fixed loading issue with persistent shared objects
  • Repaired some Maven related problems with our builds

A major change from 1.0 on the project side of things is our move from Ant and Ivy based builds to Maven.

The server documentation has also received some updates and has been regenerated in HTML
and PDF formats; granted there are still a lot of sections that need to be updated, but this is a start. The googlecode hosted wiki has also been started during this period since we lost faith in the older Trac system. The unfortunate thing about losing Trac is that we lost a lot of the content.

Red5 Binaries

Binaries have been created to fill most of our users needs; absent from the list is a dedicated OSX build. OSX and Linux users should grab the Tarball or build from source. The following links are now active: Windows Installer (Java 7) | Windows (Java 6) | ZIP | Tarball

How to add Red5 as a Maven dependency in your project

Add the red5 repository

Add a dependency entry for the server:

Also if you’re doing RTMP client work in your project, you’ll also have to add the client library entry:

For both the server and client libraries you must add the “-java6″ prefix to the “version” node if you are not using Java 7.

Building Red5 in Eclipse

A Maven plugin now comes pre-installed in some Eclipse releases, but if you are using an older version and need install instructions go here first: Maven plugin install

Last but not least, I created a quick screencast to show how to build the server in Eclipse now that we’ve switched to Maven.

, , ,

Top 10 Boston Area Game Conferences, Festivals and Symposia You Should Know About for 2013

January 10th, 2013 by Elliott Mitchell

PAX East Indie Megabooth Developers - Photo Courtesy Ichiro Lambe

1 ) Pax East
Spawned from Washington State based Penny Arcade Conference, Boston’s three day PAX East Conference is debatably the largest game conference in the United States. Boasting over 70K attendees in 2011 and even more in 2012, PAX East has much to offer game enthusiasts, developers, students and the press. Some highlights of PAX East are: The indie Megabooth, panel talks, the expo floor and the multitudes of game enthusiasts.

2 ) Boston Festival of Indie Games
A vibrant offspring of the Boston Indies Group, the Boston Festival of Indie Games (Boston FIG) held it’s first event in 2012 at MIT in Cambridge, MA. Several thousand attendees from across the the region comprised of game enthusiasts, all manner of game developers, tech startups, students and supportive parents enjoyed the day long festival. Highlights include:  prominent industry speakers, playing local indie games while having many opportunities to talk to the game developers, cutting edge tech demos, screening films like Indie Game the Movie, participating in a game jam, local industry art show and amazing networking opportunities.

3 ) Games for Health
Established 9 years ago in Boston, MA, Games for Health is an unique conference focused on non-traditional uses of game technology and motivational game mechanics utilized to facilitate healing, healthy practices and gathering data. The conference is attended by a wide range of professional game designers, tech startups, researchers, educators, healthcare providers and more.

4 ) MIT Business in Gaming
Originating in 2009, the MIT BIG conference was conceived as an event to bring together the best and brightest business leaders around Massachusetts to talk about succeeding in the business of making games. High profile panels and industry focused topics make this conference unique. Attendees range from entrepreneurs, publishers, investors, AAA studios, students and indie developers.

5 ) Mass Digi Game Challenge
Initiated in 2012, the Mass DiDI Game Challenge is an annual games industry event and competition focused on mentoring aspiring game development teams. The goal of the conference is to boost the odds of new startups in Massachusetts to pitch, fund, create and publish successful games. Winners receive prizes, valuable mentorship, new industry connections and lots of publicity.

6 ) Boston GameLoop
Established back in 2008, Boston GameLoop is an amazing unConference where all walks of game industry people unite for an afternoon or self organizing talks, debates, presentations and networking opportunities. Indies, Students and AAA industry folks come together for a day of inspiration.

7 ) MIT Game Lab Symposium
First held in 2012, The MIT Game Lab Symposium is a fascinating event focused on game research, education and non-traditional use cases of game mechanics and technologies. The all day event is highlighted with expert panel discussions and amazing networking opportunities. Attendees include industry leaders, top researchers, indies, students and other interested people from various external disciplines and industries.

8 ) 3D Stimulus Day
Conceived in 2009, 3D Stimulus Day is unique because it is the only all-day 3D game related event around Boston. Attendees network, watch professional’s speak, learn about new technologies, demo games, receive vital information on how to get jobs as well as show off their portfolios. 3D artists ranging from industry veterans to students unite for a day dedicated to 3D for games.

9 ) No Show Conference
Initiated in 2012, the self described goal of the two day No Show Conference is “to give game industry professionals a space to explore our skillsets, our motivations, and our limits as developers”. The conference is comprised in part by highly pertinent industry related presentations, networking opportunities, a demo hall showcasing local indie game developers and a game jam.

10 ) MassTLC Innovation Unconference
This annual event held by the Mass Technology Leadership Council for C-level executives, young entrepreneurs, investors and students is not solely focused on the games industry. The Innovation Unconference is a great forum to network, exchange ideas, learn from the pros and gather fresh ideas from new innovators.  Although the conference is not solely focused on games, a high percentage of attendees with connections to the game industry do attend.

Elliott Mitchell
Technical Director @
Indie Game Developer
Twitter: @mrt3d

, , ,

A Practical, Applicable Approach to Responsive Web Design

January 4th, 2013 by Kyle Kellogg

When choosing a design for your web and mobile needs, it is important to chose a design approach that suits the needs of the project. There are two approaches that I want to discuss in this post. The first approach involves creating two compelling experiences, one for the web and the other for mobile. This design approach allows for separate designs and gives the designer more freedom in regards to the user experience for each device. The other approach revolves around a responsive design, which uses CSS3 properties to decide which media to show and where to place that media based on the constraints of the browser. This is not to say that responsive design cannot do both web and mobile with the same freedom, but that responsive design may have additional effort needed in order to achieve the same results. Responsive design is quickly becoming an effective way to design and develop maintainable web sites that reach a majority of endpoints and browsers.

To begin, let’s address what responsive web design is and how it differs from an adaptive approach. For our purposes here, and most others that I can think of, let’s limit responsive web design to be the combination of  a design and layout that respond to the size, orientation, and visible capabilities of whatever they’re being viewed in. What do I mean by visible capabilities? I’m talking about the specific capabilities or quirks of how the browser/renderer shows your user what you’ve made, i.e. drop shadows – but only if they’re available. Let me be clear:  We’re defining a responsive approach as being limited to changing styling and not functionality or content (although, in a little bit, I’ll describe a cheap and effective way to blur that definition in order to accommodate a semi-adaptive approach).

The benefits of a responsive approach may be self-evident, but for specificity’s sake we’ll review them. You end up with a single product and a single codebase. It’s much easier to maintain than making multiple, synchronized edits to a split (mobile-specific and non-mobile) approach. It’s usually quicker and more cost-effective to create than a split approach, however that can vary depending on how forward thinking you are with the website or web app as retrofitting one to support a responsive design can be a bit more involved than creating one from scratch. It can cater to your users’ or customers’ devices’ capabilities, which allows for a unified look and feel while still being forgiving for older or less capable browsers. It lends itself to reusing graphics, which can later be made adaptive by loading graphics only as big as they need to be (see more about responsive images here). It helps us meet the demands of a world in which resolutions and devices are changing at a lightning-quick pace. There already exist many excellent foundations and tools to build upon or with (Grids:,,,, or make your own at (Foundations/Frameworks:,, and (Tools: There are many more grids, foundations, frameworks, and tools out there to assist you – just search for whatever you’re looking for and you’ll probably be provided with many options to choose from.

Like any approach, a responsive approach also has some considerations that must be taken into account before proceeding with it. Developers and designers must both be forward-thinking in their approaches so that all variables are considered. For instance, if you’re developing and know that a specific section must be right aligned for desktop targets but center or left aligned for mobile targets then plan ahead so you’ll be able to accommodate that when the time comes. If you’re designing, consider how much a specific grouping or section will change with each target so that nothing crazy needs to happen on the developers’ side. This planning will be extremely helpful in cutting down the overall time for creating a finished product. This approach also necessitates that certain requirements be met, so shims for media queries ( and HTML5 tags ( will be necessary as well as feature detection (I prefer As you are developing, you’ll need to curate and optimize your codebase so that you’re not adding too much and creating a long load time. Most importantly, however, responsive web design is not a magic bullet – remember its limitation of affecting only styling.

Now that I’ve gone over some of the benefits and considerations, let’s get to the important bit – how can you apply this to current and future projects? Let’s break it down into steps:

  1. Planning
    1. Plan your targets. Will you have a different design or layout for desktops, tablets, and mobile devices? A different design or layout for iOS and Android? Nail down exactly what you’ll be designing and then developing for.
    2. Plan your designs and layouts. How will your designs and layouts differ in your targets? Imagine how they’ll flow from one to the next and describe everything in as much detail with still graphics, animations, or words as best as you are able to.
    3. Plan your development. How can you best architect the markup to allow for a fluid layout for each target?
  2. Designing
    1. Create designs for each target based on your planning.
    2. Using your designs, save/export each asset you’ll need.
    3. If your graphics are changing size, save/export each size as it’s own asset.
    4. Compile assets into a spritesheet for use by the developer(s). If you want, you can split it up into one spritesheet for each target.
  3. Developing
    1. Create your markup. Allow for a loose architecture that can be adapted to all targets.
    2. Input your content and implement responsive images (if you so choose).
      1. If you need to swap some content or shake the layout up a bit for a specific target, or for each target, consider adding with target classes so that you can swap by changing the visibility and/or display styling. While not lightweight, this is a quick and cheap way to adopt a semi-adaptive approach.
    3. Styling
      1. Create basic styling first. Start with your primary target and work from there.
      2. Move from your layout up to implementing the design specifics (font sizing, et cetera)
      3. Add on to your basic styling for each target, making only the necessary changes to each.
      4. Remember to make full use of Modernizr, or whatever feature detection you’re using, so that as much of your implemented design will remain as possible no matter what browser or renderer it’s being viewed in.
      5. Try and keep the tips from this video about Github’s CSS performance ( in your mind when styling
  4. Testing
    1. Test on as many devices, browsers, resolutions, and operating systems as possible.
    2. Though I’ve never had much luck with them, you can try to use to capture what your site looks like on operating systems or browsers you don’t have access to.
    3. You can also use,,, and to test at sizes your browser may not get to or multiple sizes at once.
    4. Once you’ve tested, test it again – trust me.

Those steps, while in a logical order, are also in order of importance (from greatest to least) – except for testing, which is of utmost importance throughout every project. I cannot stress enough how important the planning stage is to a responsive approach (or any approach, for that matter). With enough forethought and constant, consistent consideration for that planning, testing is merely a matter of double-checking your work to make sure you haven’t forgotten to cross a ‘t’ or dot an ‘i’ somewhere. You’ll find small things, but it shouldn’t be anything big enough to warrant serious time and effort in order to rectify. It’s unlikely you’ll be able to nail this the first time around, so test as frequently as you want or are able to. The more you test the more likely it is that you’ll get relevant feedback from recent changes and gain an understanding of how to improve your own processes. If you’ve planned and designed everything really well, with considerations to how the layouts and designs can flow into one another, you’ll find development becomes much easier. Each step stands upon the shoulders of the step before it, so have a strong base and you’ll be able to build bigger, better projects.

Hopefully you feel more confident in applying a responsive approach to your next website or web app.