Framework: Strongloop’s Loopback

Recently I did a series for New Relic on three frameworks, both for APIs and web apps. I titled it “Evaluating Node.js Frameworks: hapi.js, Restify, and Geddy” and it is available via the New Relic Blog. To check out those frameworks give that blog entry a read, then below I’ve added one more framework to the list, Strongloop’s Loopback.

Strength: Very feature-rich generation of models, data structures and related enterprise-type needs. Solid enterprise-style API framework library.
Weakness: Complexity could be cumbersome unless it is needed. Not an immediate first choice for a startup going after lean and clean.
Great for: Enterprise API Services.

When I dove into StrongLoop, I immediately got the feel that I was using a fairly polished package of software. When installing with ‘sudo npm install -g strongloop’ I could easily see the other packages that are installed. But instead of the normal Node.js display of additional dependencies that are installed, the StrongLoop install displayed a number of additional options with a shiny ASCII logo.

StrongLoop's ASCII art begins.

StrongLoop’s ASCII art begins.

Once the library was installed, I took it for a test drive. The loopback library builds a basic API service with a simple command of ‘yo loopback’.

More ASCII Art!!!!

More ASCII Art!!!!

To build an initial model in the API service, simply run ‘yo loopback:model WidgetStuff’. From here I dove into what was being generated.

Taking a look at the JSON for WidgetStuff, the default generation looks like the code below.

	"name": "WidgetStuff",
	"base": "PersistedModel",
	"properties": {},
	"validations": [],
	"relations": {},
	"acls": [],
	"methods": []

In the JSON, the library has done a good job of leaving hooks for validations, relations, ACLs (Access Control Lists) that all point to an enterprise-grade product.

Moving along to other parts of the standard generated application, I took a look at the server.js file. In that file the code is simple, with comments to explain where to integrate other elements of the application. By default there are other parts of the application that are already in place with a basic minimal functionality. The code file starts off with the basic code as shown.

var loopback = require('loopback');
var boot = require('loopback-boot');

var app = module.exports = loopback();

// Set up the /favicon.ico

// request pre-processing middleware

// -- Add your pre-processing middleware here --

// boot scripts mount components like REST API
boot(app, __dirname);

// -- Mount static files here--
// All static middleware should be registered at the end, as all requests
// passing the static middleware are hitting the file system
// Example:
// app.use(loopback.static(path.resolve(__dirname', '../client')));

// Requests that get this far won't be handled
// by any middleware. Convert them into a 404 error
// that will be handled later down the chain.

// The ultimate error handler.

It’s good to see a starting code base that already has compression, basic error handler, not found handler and related functionality. Toward the end of the file there is the startup code.

app.start = function() {
	// start the web server
	return app.listen(function() {
			console.log('Web server listening at: %s', app.get('url'));

	// start the server if `$ node server.js`
	if (require.main === module) {

This code from start to finish is pretty clean. And with basic functionality for API services already represented, I can start building a working application right from the start.

I found StrongLoop’s Loopback product to be a great starting point to build APIs off of with minimal ties to dependencies. Plus, the user interface provides an excellent way to interact with the generated API endpoints. In short, StrongLoop offers one of the best API-building experiences available on the Node.js platform. This will give you a better idea of what I’m talking about:

The first user interface screen that displays upon navigating to the explorer end point i shown here.

The LoopBack API web user interface. Very Enterprisey.

The LoopBack API web user interface. Very Enterprisey.

A number of endpoints for the WidgetStuffs model that I generated are now available. To interact with the actual endpoint itself, simply click on one to list or expand the operations.

UI Expanded.

UI Expanded.

The real time saver? Having the ability to check out the explorer interface and immediately send data to the APIs without typing in cryptic curl commands.

My Sample Loopback Project:

Troubleshooting Node.js Deploys on Beanstalk – The Express v4 node ./bin/www Switch Up

I’ve gotten a ton of 502 errors and related issues that crop up when deploying the Beanstalk. One of the issues that cropped up a few times recently, until I stumbled into a working solution was the 502 NGINX error. I went digging around and ended up just trying to deploy a default, fresh from the ‘express newAppNameHere’ creation and still got the error.

I went digging through the Beanstalk configuration for the app and found this little tidbit.

Node Command (Click for full size image)

Node Command (Click for full size image)

I’ve pointed out the section where I’ve added the command.

node ./bin/www

Based on the commands that are executed normally, it seems `npm start` would work work to get the application started. But I have surmised the issue is that the commands are executed sequentially;

node server.js
node app.js
npm start

When these are executed in order, errors crop up and the command that should work `npm start` begins with a corrupted and error laden beginning. Leaving the application not running. However by adding the `node ./bin/www` to the text box all the others are skipped and this command is issued, resulting in a running application.

The other thing is to follow the now standard approach of just issue `npm start`, but being sure to replace what I put in the text box above (`node ./bin/www`) with `npm start` so that beanstalk only runs npm start instead of the ordered execution.

Xamarin and I Are Hella Busy Hacking This Week

This week, along with the normal duties of getting everything from SSL working to code slung for account management to intellectual property (what is that exactly :o )…  this week is going to get hella busy. Here’s a few of the public events and training that I’ll be attending this week along with the normal bike n’ hacking n’ gettin’ shit done.

Shared Code Projects, PCL and Xamarin on 7/8/14 @

Intel JFCC Auditorium
2111 N.E. 25th Ave
Hillsboro, OR

James Montemagno  from Xamarin is coming to learn us the deets on how to create common core code that can run on any or all common platforms. Find out the differences between shared code project, portable class libraries, and simple file linking to share more code on iOS, Android, and Windows. This should be pretty kick ass to help kick OrchestrateExecutive off the ground. There’s a little more info here for the event:

Database Stuff that aint RDBMS on 7/10/14 @

I’ll @adron be presenting on database types, what’s available out there outside of the relational and RDBMS world. How to resolve various problems with alternate data solutions for better results, better performance and ways to leap around the hurdles that are sometimes faced with RDBMS use.  More info here:

Xamarin Hands-on-Lab/Hackathon on 7/12/14 @

Montgomery Park

Kelly White @mckhendry has put together a hands-on-lab and hackathon, just a few days later hosting a hand-on-lab working with Xamarin to build apps. I’m going to hit up this event too (then go ride a 100+ kilometer bike ride, anybody up for the ride, ping me?) and sling some code on OrchestrateExecutive. Also a little more info here for the event:

There’s more, but these are the top few meets I’ll be attending over the next two weeks. Happy hacking!

Installing OpenSSL, Other Notes. Because: Security

I am in the process of setting up an SSL (Secure Sockets Layer) Cert to enable HTTPS on some sites and APIs I’m building. In that effort I needed to setup OpenSSL to create a CSR (Certificate Signing Request) and get the process started. Here’s the steps I went through to accomplish this. First download OpenSSL.

Next make sure you have the prerequisites installed:

  • make
  • Perl 5
  • ANSI C Compiler
  • Dev Environment  in form of dev libraries and C header files
  • Supported Unix Operating System (i.e. – not windows, you’ll have to google those directions separately, for these steps though, get a *nix OS)

Get the zipped contents of the OpenSSL into a working directory to build them. Then follow the standard config, make, and make install steps below.

make test
make install

Once you have that installed there are a number of actions you can perform. Here’s a few.

  • Create a CSR (Certificate Signing Request):
    openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

    This creates a CSR.csr and privateKey.key file for use for SSL.

  • Create a self-signed certificate:
    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

    Self signed certificates are great to use on local servers that are used internally, great for dev servers that need SSL, and similar reasons. For most dev needs there is no need to purchase an extra certificate for SSL, just generate one yourself and use it for development purposes.

  • Check a CSR:
    openssl req -text -noout -verify -in CSR.csr
  • Check a private key:
    openssl rsa -in privateKey.key -check
  • Check a cert:
    openssl x509 -in certificate.crt -text -noout
  • Generate a cert signing request from existing cert:
    openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
  • Removing a pass key:
    openssl rsa -in privateKey.pem -out newPrivateKey.pem
  • Generate a CSR for an existing private key:
    openssl req -out CSR.csr -key privateKey.key -new

More to come in the near future. I’ve almost got this SSL mess straightened out and am putting together a more complete how-to.


Getting Started with Swift, For NON-Apple Devs

This past weekend I attempted to get started with Swift coding. Since I have not been an Apple Developer for a while, it wasn’t immediately obvious how to get started. But once I fumbled around a few minutes I realized I needed a developer account to get the latest XCode. Jeez, it really shows how much Apple loves to lock you in hard core to their development ecosystem. An unfortunate trait of a company that is actually extremely closed in much of its behavior, while taking advantage of so much of the open source community. But I digress, this isn’t a rant about the unethical behavior of Apple. I’ll reserve that for the novels worth of material it deserves.

One I signed up for the developer program, which costs $99 bucks, I immediately made my first huge mistake. This damnable mistake blew the entire weekend of hacking. I added under “Company” my simple DBA (Doing Business As) name. I already had an account, and because of this change for making this existing account become a developer account from a personal base level account, sprung a red flag. I checked back frequently over the weekend, but it wasn’t until Monday that somebody checked the app, realized the Company name I added was merely a DBA and ok’d my account. So far, 38 hours down the drain for getting started hacking on Swift! Dammit.

However, this morning I was happy to find everything was ok’d, and thus, the remaining bit of this blog entry is a bit more example and a little less story of my day.

Developer @ Apple

Developer @ Apple

Getting XCode 6 beta

I wanted to do Swift hacking, the first step was to download XCode 6 beta. That’s available via download on the iOS Developer page (and I suppose the Mac Developer page). Scroll down on that page until you find the XCode Download button.

The Warnings and the Download XCode 6 beta page.

The Warnings and the Download XCode 6 beta page.

Also note, if you’re looking to do Swift hacking like I’m doing here, I’d actually advise against getting the iOS 8 beta or OS-X Yosemite Developer Previews right now. Best to keep as stable a machine while toying around with a new language. At least, that’s what the conversations have been so far…

OS-X Yosemite & iOS 8

OS-X Yosemite & iOS 8

Once I got Xcode 6 beta installed I dove right into creating a Swift Project. I created a simple new project that is empty to just check out what Xcode 6 provides out of box for the Swift Project.

Selecting an empty Xcode 6 beta project to use with Swift.

Selecting an empty Xcode 6 beta project to use with Swift.

The next dialog is where the Swift magic is selected.

Selecting Swift, entering a project name and other information dialog.

Selecting Swift, entering a project name and other information dialog.

After that I just clicked through on defaults until I got into the Xcode IDE with the project open.

Selecting the appropriate simulator.

Selecting the appropriate simulator.

Next I executed the project. Since I’d had my phone attached it wanted to run it there, but I have 7.1 iOS on it which won’t execute Swift code. I had to select the appropriate simulator then to run the application project. Once that ran, since I’d not done so on this particular computer, I needed to enable developer mode.

Enabling developer mode.

Enabling developer mode.

I did so and the empty application launched.

An empty iOS 8 iPad Retina Application.

An empty iOS 8 iPad Retina Application.

So that’s the basic getting started, no code actually slung. But rest assured I’ll have another post soon detailing some first code snippets. I also hope to get some comparisons written up between XCode with Swift and Xamarin Studio and C#. It’s cool that Apple finally has a modern feature rich language, so it’ll be interesting to see how each stacks up from a language and IDE perspective.


Back From Scandinavia, Back to Project Coding, Writing and Organizing

Scandinavia Viking.

Scandinavian Viking.

I just got back from Scandinavia (and Amsterdam). I went for a million reasons, mostly for the adventure of it. Visiting Stockholm, Copenhagen and Reykjavik I saw about a zillion bikes, great architecture, Tivoli, amazing and beautiful waterways, Viking boat building museums, design to die for and so much more. It’s truly one of the amazing areas of the world. But now I’m back in ‘Merica and ready to get back to working on projects, design efforts and all the things I love to do. This blog post is a summary of my immediate return to projects, here’s the list broken into coding, writing and organizing:


  • Deconstructed – [site] This is the startup I’ve cofounded with Aaron Gray @agray. Check out our main site at Deconstructed. Check out some of the open source projects we’ve started here and listed below.
  • Deconstructed Docs – [site] [JavaScript] [Node.js] I’m using Wintersmith to build docs with static site generation. The docs are located at Previous blog entries I did on building a static site with Wintersmith are available at Wintersmith Creating Documentation and Working in -34c, Wintersmith Customization & Github Hosting.
  • Symphonize.js – [site] [JavaScript] [Node.js] [issues] This is a project I started to use configuration as a basis for creating data for any database, but specifically Orchestrate (see blog entries under the writing section I did for Orchestrate). The idea behind this started since I needed something to generate test data for Deconstructed. This one is incomplete, but I’ll be pushing it forward to a deployable NPM Module soon that will be easy to download and just use. There’s also a possibility that this becomes a service that I make available in the near future.
  • Orchestrate.NET – [site] [c#] [issues] I’ve been helping out Robert Smith and a crew to manage the effort around the .NET client driver for Orchestrate. This is currently functional and we’d love anybody and everybody using it to really test it out. Currently I’m using this for the OrchestrateExecute Project listed below too.
  • orchestrate-rapping – [repo] [go] [issues] [group] Yo yo yo, hit the beat. This is an effort that I and others have kicked off to put together a wrapper for Orchestrate’s API. The reason is simple, we want to be able to develop sitting far away from wifi and connectivity, in a park or a cabin in the woods, with a beer in hand and a fire crackling. All while knowing we’re building something that will work when we reconnect to the land of the internet!
  • OrchestrateExecutive – [repo] [c#] [issues] For a very serious enterprise application, I’ve started hacking together a C# Application using Xamarin that will provide a library tier (that could be used as a sample) to use in building to Android, iOS or Windows Phone and all of the native Windows, Linux or OS-X apps that might be needed. In the application I’ll be using Orchestrate and Deconstructed to build out the application. Stay tuned at for more on this.
  • …and also inspired by Rick Turoczy @turoczy eternally another fucking side project will be going live soon. :o



  • Bike n’ Hack – Follow @bikenhack for information and more coming soon.
  • Node PDX – More to come on this soon.

…subscribe to the RSS link, hit the e-mail subscription or just ping me or follow me @adron on Twitter and I’ll keep you posted on the goings on of all my efforts and others. Cheers!

Great New European Technology Invention

One of the things that I’ve noticed throughout Europe is this really cool invention they’ve created here called a schedule. This schedule is something that is based on another piece of technology called a clock. The clock is designed to show the passing of time, something very similar to what we in America have, except that they pay attention to this passing of time. We Americans just seem to race around it in what we call the “rat race”.

This clock progresses forward while people work, relax and interact with each other. It ticks slowly and this is where the real interesting aspect of this technology is shown. As the time passes the European people eat and enjoy each other’s company. They tell each other a particular time, that each of them will show up and greet each other. They then carry on with their day and then meet at this time and enjoy a bit of each other’s company. For some odd reason it seems we Americans just go toward each other randomly and sometimes run into each other for company. But we don’t dare actually follow or respect this passing of time.

The other use of this schedule technology, is the use in transportation. It’s so fascinating that when a schedule in Europe shows that a train will arrive at 14:29 or 9:11 the train arrives at the respective 14:29 or 9:11. The same for this schedule of departure times. It is, unlike the lack of any schedule in America, amazingly useful. It seems, we could really use such a piece of technology in the United States!

The shock of the accurate movement of peoples between places, based on these schedules and their interactions is truly amazing! I highly suggest everybody give it a try sometime!