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.
Continue reading “Framework: Strongloop’s Loopback”

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

vikingI 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:

Coding

  • 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 docs.deconstructed.io. 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 blog.deconstructed.io for more on this.
  • …and also inspired by Rick Turoczy @turoczy eternally another fucking side project will be going live soon. 😮

Writing

Organizing

  • 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!

Coding on Orchestrate.io & Orchestrate.js & Orchestrate.NET

First context, then I’ll dive in.

Orchestrate

http://orchestrate.io/

Orchestrate is a service that provides a simple API to access a multitude of database types all in one location. Key value, graph or events, some of the database types I’ve been using, are but a few they’ve already made available. There are many more on the way. Having these databases available via an API instead of needing to go through the arduous process of setting up and maintaining each database for each type of data structure is a massive time saver! On top of having a clean API and solid database platform and infrastructure Orchestrate has a number of client drivers that provide easy to use wrappers. These client drivers are available for a number of languages. Below I’ve written about two of these that I’ve been involved with in some way over the last couple of months.

Orchestrate.NET

https://github.com/RobertSmith/Orchestrate.NET

This library I’m currently using for a demonstration application built against the Deconstructed.io services (follow us on twitter ya! @BeDeconstructed), a startup I’m co-founding. I’m not sure exactly what the app will be, but being .NET it’ll be something enterprisey. Because: .NET is Enterprise! For more on this project check out the Deconstructed.io Blog.

Some of the latest updates with this library.

But there’s still a bit of work to do for the library, so consider this a call out for anybody that has a cycle they’d like to throw in on the project, let us know. We’d happily take a few more pull requests!  The main two things we’d like to have done real soon are…

Orchestrate.js

https://github.com/orchestrate-io/orchestrate.js

With the latest fixes, additions and updates the orchestrate.js client driver is getting more feature rich by the day. In addition @housejester has created an orchestrate-brain project for Hubot that uses Orchestrate.js. If you’re not familiar with Hubot, but sure to check out the company robot that can dramatically improve and reduce employee efficiency! Keep an eye on that project for more great things, or create a Hubot to keep a robotic eye on the project.

Here are a few key things to note that have been added to help in day-to-day coding on the project.

  • The travis.yml file has been added for the Travis Continuous Integration build. This build runs against node.js v0.10 and v0.8.
  • Testing is done with mocha, expect.js and nock. To get the tests up and running, clone the repo and then build with the make file. The tests will run in tdd format.
  • Promises are provided via the kew library.

If you’re opening up the project in WebStorm, it’s great to setup the mocha tests with the integrated mocha testing as shown below. After you’ve cloned the project and run ‘npm install’ then follow these steps to add the Mocha testing to the project. We’ve already setup exclusions in the .gitignore for the .idea directory and files that WebStorm uses.

First add a configuration by clicking on Edit Configurations.

Edit Configurations
Edit Configurations

Next click on the + to add a new configuration to run. Select the Mocha option from the list of configurations.

Mocha & Other Configurations in WebStorm
Mocha & Other Configurations in WebStorm

On the next screen set a name for the configuration. Set the test directory to the path for the test directory in the project. Then finally set the User interface option for Mocha to TDD instead of the default BDD.

Edit Configuration Dialog
Edit Configuration Dialog

Last but not least run the tests and you’ll see the list of green lights light up the display with positive results.

Test Build
Test Build

Fixing Up Passport.js ‘passport-http’ for Express v4

Even though it isn’t in the primary trunk of code for the ‘passport-http’ Passport.js Strategy, I’ve upgraded the packages.json and app.js file for the basic username and passport authentication to Express.js v4. If you’re using Express.js and are looking to migrate to v4 from v3 or earlier a great starting place is to check out the “Migrating from 3.x to 4.x” wiki page. As for the passport-http strategy, here’s the updated example I put together in a commit here with my own fork here, with the code changes below.

First step was to bump to the latest Express.js v4 Module. I did this with a simple edit to the packages.json file. The original looked like this

[sourcecode language=”javascript”]
{
"name": "passport-http-examples-basic",
"version": "0.0.0",
"dependencies": {
"express": ">= 0.0.0",
"passport": ">= 0.0.0",
"passport-http": ">= 0.0.0"
}
}
[/sourcecode]

which I changed the depedency from >= 0.0.0 to >= 4.0.0 so that it would require something above v4.

[sourcecode language=”javascript”]
{
"name": "passport-http-examples-basic",
"version": "0.0.0",
"dependencies": {
"express": ">= 4.0.0",
"passport": ">= 0.0.0",
"passport-http": ">= 0.0.0"
}
}
[/sourcecode]

Technically the old file would have pulled the latest (which as of today I believe is 4.1.1) but it would also not do anything if you’d already pulled the example down. It just make sit more specific that the version is v4+ now.

After changing that dependency I added Morgan. Morgan is a replacement middleware for the logger. The final packages.json file looked like this when I was done.

[sourcecode language=”javascript”]
{
"name": "passport-http-examples-basic",
"version": "0.0.0",
"dependencies": {
"express": ">= 4.0.0",
"passport": ">= 0.0.0",
"passport-http": ">= 0.0.0",
"morgan": "~1.0.0"
}
}
[/sourcecode]

Once that was done I nuked my node_modules directory and ran npm install to pull down the latest bits. Once I did that, starting with the app.js I made a few changes. Below is what the app.js file looked like when I started with.

[sourcecode language=”javascript”]
var express = require(‘express’)
, passport = require(‘passport’)
, util = require(‘util’)
, BasicStrategy = require(‘passport-http’).BasicStrategy;

var users = [
{ id: 1, username: ‘bob’, password: ‘secret’, email: ‘bob@example.com’ }
, { id: 2, username: ‘joe’, password: ‘birthday’, email: ‘joe@example.com’ }
];

function findByUsername(username, fn) {
for (var i = 0, len = users.length; i < len; i++) {
var user = users[i];
if (user.username === username) {
return fn(null, user);
}
}
return fn(null, null);
}

// Use the BasicStrategy within Passport.
// Strategies in Passport require a `verify` function, which accept
// credentials (in this case, a username and password), and invoke a callback
// with a user object.
passport.use(new BasicStrategy({
},
function(username, password, done) {
// asynchronous verification, for effect…
process.nextTick(function () {

// Find the user by username. If there is no user with the given
// username, or the password is not correct, set the user to `false` to
// indicate failure. Otherwise, return the authenticated `user`.
findByUsername(username, function(err, user) {
if (err) { return done(err); }
if (!user) { return done(null, false); }
if (user.password != password) { return done(null, false); }
return done(null, user);
})
});
}
));

var app = express.createServer();

// configure Express
app.configure(function() {
app.use(express.logger());
// Initialize Passport! Note: no need to use session middleware when each
// request carries authentication credentials, as is the case with HTTP Basic.
app.use(passport.initialize());
app.use(app.router);
app.use(express.static(__dirname + ‘/public’));
});

// curl -v -I http://127.0.0.1:3000/
// curl -v -I –user bob:secret http://127.0.0.1:3000/
app.get(‘/’,
// Authenticate using HTTP Basic credentials, with session support disabled.
passport.authenticate(‘basic’, { session: false }),
function(req, res){
res.json({ username: req.user.username, email: req.user.email });
});

app.listen(3000);
[/sourcecode]

First changes, add some requires, remove some requires.

[sourcecode language=”javascript”]
var express = require(‘express’)
, passport = require(‘passport’)
, util = require(‘util’)
, BasicStrategy = require(‘passport-http’).BasicStrategy;
[/sourcecode]

and changed it to

[sourcecode language=”javascript”]
var express = require(‘express’)
, passport = require(‘passport’)
, util = require(‘util’)
, BasicStrategy = require(‘passport-http’).BasicStrategy
, morgan = require(‘morgan’)
, app = express();
[/sourcecode]

Then I deleted the entire section shown below.

[sourcecode language=”javascript”]
var app = express.createServer();

// configure Express
app.configure(function() {
app.use(express.logger());
// Initialize Passport! Note: no need to use session middleware when each
// request carries authentication credentials, as is the case with HTTP Basic.
app.use(passport.initialize());
app.use(app.router);
app.use(express.static(__dirname + ‘/public’));
});
[/sourcecode]

I replace that with a nicely cleaned up Express.js v4 section of code and the replacement for logger, the morgan() library. Initializing passport however is still done in the same ole’ trusty way with initialize().

[sourcecode language=”javascript”]
app.use(morgan());
app.use(passport.initialize());
[/sourcecode]

Ordering of code has changed a bit for express.js, which meant I needed to have the app.use commands before the following section, which I moved right up underneath the two app.use statements.

[sourcecode language=”javascript”]
// curl -v -I http://127.0.0.1:3000/
// curl -v -I –user bob:secret http://127.0.0.1:3000/
app.get(‘/’,
// Authenticate using HTTP Basic credentials, with session support disabled.
passport.authenticate(‘basic’, { session: false }),
function(req, res){
res.json({ username: req.user.username, email: req.user.email });
});
[/sourcecode]

Finished app.js File

After those changes the app.js file should look like this.

[sourcecode language=”javascript”]
var express = require(‘express’)
, passport = require(‘passport’)
, util = require(‘util’)
, BasicStrategy = require(‘passport-http’).BasicStrategy
, morgan = require(‘morgan’)
, app = express();

app.use(morgan());
app.use(passport.initialize());

// curl -v -I http://127.0.0.1:3000/
// curl -v -I –user bob:secret http://127.0.0.1:3000/
app.get(‘/’,
// Authenticate using HTTP Basic credentials, with session support disabled.
passport.authenticate(‘basic’, { session: false }),
function(req, res){
res.json({ username: req.user.username, email: req.user.email });
});

var users = [
{ id: 1, username: ‘bob’, password: ‘secret’, email: ‘bob@example.com’ }
, { id: 2, username: ‘joe’, password: ‘birthday’, email: ‘joe@example.com’ }
];

function findByUsername(username, fn) {
for (var i = 0, len = users.length; i < len; i++) {
var user = users[i];
if (user.username === username) {
return fn(null, user);
}
}
return fn(null, null);
}

// Use the BasicStrategy within Passport.
// Strategies in Passport require a `verify` function, which accept
// credentials (in this case, a username and password), and invoke a callback
// with a user object.
passport.use(new BasicStrategy({
},
function(username, password, done) {
// asynchronous verification, for effect…
process.nextTick(function () {

// Find the user by username. If there is no user with the given
// username, or the password is not correct, set the user to `false` to
// indicate failure. Otherwise, return the authenticated `user`.
findByUsername(username, function(err, user) {
if (err) { return done(err); }
if (!user) { return done(null, false); }
if (user.password != password) { return done(null, false); }
return done(null, user);
})
});
}
));

app.listen(3000);
[/sourcecode]

If you execute either of the curl commands shown in the comments in the app.js code you should see the respective response when running the application.

[sourcecode language=”bash”]
curl -v -I http://127.0.0.1:3000/
curl -v -I –user bob:secret http://127.0.0.1:3000/
[/sourcecode]

…and that should get you running with Passport.js and Express.js v4.

A Recap Of My Top 4 Tech Article Reads From Pocket

Sometimes I get overwhelmed with the number of articles that are in my pocket. I’ve got articles on livability, transit, cycling, auto issues, node.js, java, javascript, coding practices, software craftsmanship, feminism, heavy metal, death metal, black metal, jazz, progressive jazz, fusion jazz, NASA news, space discoveries, space research, Star Trek news, Star Wars news, information on sci-fi books and a slight spattering of politics and some other just interesting nonsensical stuff.

Here's a shot of Pocket on OS-X with an article about Seattle's Tech Advantage over many American cities being rooted in urban density. Which, I'd also argue, gives Seattle a unique advantage (And is a serious pain point for Microsoft's misstep into the suburbs decades ago)
Here’s a shot of Pocket on OS-X with an article about Seattle’s Tech Advantage over many American cities being rooted in urban density. Which, I’d also argue, gives Seattle a unique advantage (And is a serious pain point for Microsoft’s misstep into the suburbs decades ago)

I’ve taken the time to sort through this list of articles, pick out the top technical articles and get this down to a manageable level again. In the process I’ve created this list of solid articles that I’ve now officially read or found useful in some way and present it here for you dear reader. Enjoy, I hope they’re useful to you too.

Article Recon, The Top

  1. Zef Hemel wrote up a piece titled “Docker: Using Linux Containers to Support Portable Application Deployment“. In the article Zef delves into a number of things that are key to understanding Docker and the notion of portland application deployment. Other topics covered include isolation, security, reproducing deployments and resource constraints. The article closes with an example of  application containers and their respective deployment.
  2. 7 Javascript Basics Many Developers Aren’t Using (Properly) albeit slightly useful, I found this one more entertaining. It does give some small insight to the scope of oddities that JavaScript has and how one can easily miss the basics in JavaScript.
  3. Even though the article is from late last year, “The Premature Return to SQL” is a good read. As Alex Popescu   states it, “This pisses me off. A lot.” I too find myself pissed off a lot at the naive understanding and decisions making around SQL or alternate options. It’s almost as if some people decide to just flip a coin to make these determinations with zero insight into what they’re actually attempting to do.
  4. The article “No Deadlines for You! Software Dev Without Estimates, Specs or Other Lies” is spectacular in laying out how bullshit specs and estimates are. They’re almost entirely wasted effort on the developers part. In my own opinion it is often a failure (and yeah, I’ve been in management and leadership too, and removed these issues) of management to understand in the slightest what is actually being built or how it is being built. A lack of vision on behalf of the project is a sure fire sign that the original estimates are already completely off, the design and build out of whatever it is will likely be wrong and a host of other issues. Building software isn’t a bridge, it’s more like a painting, you decide as you go. There is no paint by numbers in software development.

Anyway, that’s my list from the 50+ tech articles that were in my Pocket app. Maybe on day I can get disciplined enough to keep the list limited to really good reads and I’ll start putting together a “My Top Pocket Reads this Month” blog entries? That sounds like it could be useful. Until then, happy coding.