__4 “CD Is Working, Let’s Get a Site Live with Loopback!”

Since it has been more than a few weeks let’s do a quick recap of the previous posts in this series.

  1. Introducing the Thrashing Code Team & Projects” – Know who’s working on what and what the projects are.
  2. Getting Started, Kanban & First Steps for a Sharing App” – Getting the kanban put together and the team involved.
  3. Starting a Basic Loopback API & Continuous Integration” – Getting the skeleton of the API application setup and the continuous integration services running.
  4. Going the Full Mile, Continuous Delivery” – Here the team got the full continuous delivery process setup for ongoing development efforts.

In this article of the series I work with some of my cohort to get initial parts of the application deployed to production. For the first part of this, let’s get some of the work that Norda has done into the project and get it running on the client side.

Client Side

client directory of the loopback project.

client directory of the loopback project.

The first thing I needed was to get a static page setup. This page would then be used to submit an email to the server side that would then deal with whatever processing that I would have for the email message confirmation and related actions.

In Loopback, it is very easy to setup a static page. I just needed a simple index.html page so I created an empty one in the client directory of the project.

The first thing I did was literally put an index.html file with the words “this should work” in the client directory of the project. But after some tweaking and adding in Norda’s work the team ended up with the following.

The next thing to do is setup the Loopback.io framework to host a static site page.

Static Page via Loopback.io

This part of the article is taken pretty much straight out of the static page hosting Strongloop Loopback.io Documentation.

Applications typically need to serve static content such as HTML and CSS files, client JavaScript files, images, and so on.  It’s very easy to do this with the default scaffolded LoopBack application.  You’re going to configure the application to serve any files in the /client directory as static assets.

First, you have to disable the default route handler for the root URL.   Remember back in Create a simple API (you have been following along, haven’t you?) when you loaded the application root URL, http://localhost:3000/, you saw the application respond with a simple status message such as this:


This happens because by default the scaffolded application has a boot script named root.js that sets up route-handling middleware for the root route (“/”):


module.exports = function(server) {  // Install a `/` route that returns server status
  var router = server.loopback.Router();
  router.get('/', server.loopback.status());

This code says that for any GET request to the root URI (“/”), the application will return the results of loopback.status().

To make your application serve static content you need to disable this script.  Either delete it or just rename it to something without a .js ending (that ensures the application won’t execute it).

Define static middleware

Next, you need to define static middleware to serve files in the /client directory.

Edit server/middleware.json.  Look for the “files” entry:

  "files": {


Add the following:

  "files": {
    "loopback#static": {
      "params": "$!../client"

These lines define static middleware that makes the application serve files in the /client directory as static content.  The $! characters indicate that the path is relative to the location of middleware.json.

Add an HTML file

Now, the application will serve any files you put in the /client directory as static (client-side) content.  So, to see it in action, add an HTML file to /client.  For example, add a file named index.html with this content:


        Some static content...  but just look at the big HTML file below!  🙂

Of course, you can add any static HTML you like–this is just an example.

Graphic Assets

Norda setup the project with a number of assets for the current page creation as well as future pages the site will need. The theme is a high quality theme, with the Coder Swap Logo added at respective key locations. The following are the graphics assets included in the project under the client directory here.

The key files that are included that will be used for our first site we deploy are the various favicon, logo, and related images. You can see those in the root of the client directory. There are a whole bunch of them because of the funky mobile design requirements.


The first page I’ve setup is a simple sign up page, with no real functionality. Just something to get started with to build off of. The code for that page looks like this.

<!DOCTYPE html>
        Code Swap - Notify Me!
    <link href="http://fonts.googleapis.com/css?family=Lato:100,300,400,700" media="all" rel="stylesheet"
    <link href="stylesheets/bootstrap.min.css" media="all" rel="stylesheet" type="text/css"/>
    <link href="stylesheets/font-awesome.min.css" media="all" rel="stylesheet" type="text/css"/>
    <link href="stylesheets/se7en-font.css" media="all" rel="stylesheet" type="text/css"/>
    <link href="stylesheets/style.css" media="all" rel="stylesheet" type="text/css"/>
    <link rel="shortcut icon" href="favicon.ico">
    <link rel="apple-touch-icon" sizes="57x57" href="apple-icon-57x57.png">
    <link rel="apple-icon" sizes="114x114" href="apple-icon-114x114.png">
    <link rel="apple-icon" sizes="72x72" href="apple-icon-72x72.png">
    <link rel="apple-icon" sizes="144x144" href="apple-icon-144x144.png">
    <link rel="apple-icon" sizes="60x60" href="apple-icon-60x60.png">
    <link rel="apple-icon" sizes="120x120" href="apple-icon-120x120.png">
    <link rel="apple-icon" sizes="76x76" href="apple-icon-76x76.png">
    <link rel="apple-icon" sizes="152x152" href="apple-icon-152x152.png">
    <link rel="apple-icon" sizes="180x180" href="apple-touch-icon-180x180.png">
    <link rel="icon" type="image/png" href="favicon-192x192.png" sizes="192x192">
    <link rel="icon" type="image/png" href="favicon-160x160.png" sizes="160x160">
    <link rel="icon" type="image/png" href="favicon-96x96.png" sizes="96x96">
    <link rel="icon" type="image/png" href="favicon-16x16.png" sizes="16x16">
    <link rel="icon" type="image/png" href="favicon-32x32.png" sizes="32x32">
    <meta name="msapplication-TileColor" content="#ffffff">
    <meta name="msapplication-TileImage" content="mstile-144x144.png">
    <meta name="msapplication-config" content="browserconfig.xml">

    <script src="http://code.jquery.com/jquery-1.10.2.min.js" type="text/javascript"></script>
    <script src="http://code.jquery.com/ui/1.10.3/jquery-ui.js" type="text/javascript"></script>
    <script src="javascripts/bootstrap.min.js" type="text/javascript"></script>
    <script src="javascripts/modernizr.custom.js" type="text/javascript"></script>
    <script src="javascripts/main.js" type="text/javascript"></script>
    <meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" name="viewport">
<body class="login2">
<!-- Registration Screen -->
<div class="login-wrapper">
    <a href="./">
        <img width="100"
        <div class="form-group">
            <div class="input-group">
                <span class="input-group-addon">
                    <i class="fa fa-envelope"></i>
                <input class="form-control"
                       value="Enter your email address">
        <input class="btn btn-lg btn-primary btn-block"
               value="Register for updates!">
<!-- End Registration Screen -->

As you can see a bulk of the page is favicon and logo related nonsense while about a 1/3rd of the screen is actually the HTML for the form itself. What that looks like when rendered is something like this.

The registration page.

Once that page is up we can then commit to the production branch as outlined in the previous blog entry.

btw – If you’re curious (especially if you’ve read the intro blog entry about the mock team), you might be wondering where and who and how did I create this gorgeous theme? Well, I didn’t, I actually purchased this sweet theme from Theme Forrest. The specific theme is se7en.

Thor Project Opens Up, Building the Cloud Foundry Ecosystem with the Community

The Iron Foundry Team are big advocates of open source software. We write code across all sorts of languages, just like many of the development shops out there do. Sometimes we’re heavy on the .NET, other times we’re all up in some Java, Ruby on Rails, spooling up a Node.js Application or something else. So keeping with our love of open source and our polyglot nature we’ve created the Thor Project with three distinct apps.

Before jumping into the applications though, a little context for what and where Thor is in the grand scheme of things. We need to roll back to the Cloud Foundry Project to get into that. The Cloud Foundry Project is an open source project built around software for PaaS (Platform as a Service) which can be used to build your own PaaS internally or externally, in a cloud provider or directly on hardware. It’s your choice how, when and where you want to use it. For more context on PaaS check out my previous entry “The Confusions of IaaS, PaaS and SaaS“.

Thor Project

Cocoa for OS-X

Thor Odinson

Thor Odinson, God of Thunder

You know who Thor is right? He’s this mythic Norse God, also known as the God of Thunder. Since we’re all about bringing the hamma we welcomed Thor into our team’s stable of applications. So starting immediately we’ve released Thor into the realms for contributions and fighting the good open source software battle! If you’d like to join the effort, check out the github project and feel free to join us!

Technically, what is the Thor Application? This is a Cocoa Application built for OS-X that is used for managing, deploying and publishing applications to Cloud Foundry enabled and or Iron Foundry extended PaaS Environments.

.NET for Windows 7

The .NET Metro version of the Thor Application is also released via github with a provided installer. We’ve almost taken the same path, except of course for the very different UX and UI queues with Windows 7 and the Metro UX design guidelines.

WinRT for Windows 8

I wasn’t really sure what to call this version. Is it Metro or WinRT or Windows 8 or something else? Anyway, there is a project, it is albeit empty at this point, but it is the project where the Windows 8 version of Thor will go! For now get the Windows 7 version and install it on Windows 8, it won’t have touch interface support and things, but should work just like a regular application on Windows 8.

The Code

To get started with these, generally you’d just clone the repo and do a build, then get started checking out the code. There is one catch, for the OS-X version you’ll want to pull down the sub-modules with the following command.

git clone git@github.com:YourForkHere/Thor.git
git submodule update --init --recursive

Once you do that in XCode just make sure to then select the right project as the starting build project.

…then when the application is launched…

Thor Running in OS-X

Thor Running in OS-X

I’ll have more in the coming days and weeks about Thor & Iron Foundry. For now, check out the blog entry on the Iron Foundry Blog and subscribe there for more information.

Thor Brings the Hamma! Cloud Foundry OS-X, Windows 7 and Windows 8 Interfaces FTW!

One of the things that I do in my work is lead the efforts around creating and leading open source projects. As regular readers may know, I’m big into open source efforts, especially around PaaS. My preferred PaaS offering these days for internal, external and public cloud PaaS is Cloud Foundry (with Iron Foundry for all of my .NET needs). Today the we made the projects official and I’m charging forward with a a great team of people. You’ll be able to use these new user interfaces for Cloud Foundry against Tier 3 Web Fabrics, CloudFoundry.com, Stackato, AppFog and any other company that uses Cloud Foundry at the core and exposes the web service APIs for use!

Thor & Thor.NET

In a couple weeks we’ll be making the github repositories completely public, open sourcing the code & products entirely and looking forward to working with the community to make these tools as awesome as we can. For now, if you’d like to jump into the repositories and see where we are and what we’re up to as we step toward opening them completely, sign up via “early access“. We’ll get you setup on the repo so you can fork, pull and add you’re own signature bits.

Why did we name the project Thor? Well, we’ve been spearheading the Iron Foundry Community efforts for .NET support on Cloud Foundry so we figured we needed someone to bring the hamma to the battle, nobody better than Thor for that!

I’ll have a regular write up of snippets, code and other things I’m working on here so subscribe and give me a follow on Twitter (@adron) and App.net (@adron). Also, for official open source releases of the project check out the Iron Foundry Organization site that has the Iron Foundry downloads, source, Thor and the official Iron Foundry Blog.