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.

References:

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.

Configuring Node.js Web Applications… Manually || Convict.js

There’s more than a few ways to configure node.js applications. I’ll discuss a few of them in this blog entry, so without mincing work, to configuring apps!

Solution #1: Build Your Own Configuration

Often this is a super easy solution when an application just needs a single simple configuration. Here’s an example I found that’s pretty clean that Noli posted on Stackoverflow to the question “How to store Node.js deployment settings/configuration files?“.

[sourcecode language=”javascript”]
var config = {}

config.twitter = {};
config.redis = {};
config.web = {};

config.default_stuff = [‘red’,’green’,’blue’,’apple’,’yellow’,’orange’,’politics’];
config.twitter.user_name = process.env.TWITTER_USER || ‘username’;
config.twitter.password= process.env.TWITTER_PASSWORD || ‘password’;
config.redis.uri = process.env.DUOSTACK_DB_REDIS;
config.redis.host = ‘hostname’;
config.redis.port = 6379;
config.web.port = process.env.WEB_PORT || 9980;

module.exports = config;
[/sourcecode]

…then load that in with a require…

[sourcecode language=”javascript”]
var config = require(‘./config’)
[/sourcecode]

The disadvantage is when the application gets a little bigger the configuration can become unwieldy without very specific, strictly enforced guidelines.

Solution #2: Use a Library/Framework Like Convict.js

The use of a library provides some baseline in which to structure configuration. In the case of convict.js it uses a baseline schema that then can be used to extend or override based on configurations needed for alternate environments. A first steps in setting up convict.js for the fueler project looks like this.

Setup a convict.js file:

[sourcecode language=”javascript”]
var convict = require(‘convict’);

// Schema
var conf = convict({
env: {
doc: "The App Environment.",
format: ["production", "development", "test"],
default: "development",
env: "NODE_ENV"
},
port: {
doc: "The port to bind.",
format: "port",
default: 3000,
env: "PORT"
},
database: {
host: {
default: "someplace:cool",
env: "DB_HOST"
}
}
});

// perform validation
conf.validate();

module.exports = conf;
[/sourcecode]

The main two configuration values are the environment and port values. Others will be added as more of the application is put together, but immediately I just wanted something to put in the project to insure it works.

Next get the convict.js library in the project.

[sourcecode language=”bash”]
npm install convict –save
[/sourcecode]

The save gets it put into the package.json file as a dependency. Once this is installed I opened up the app.js file of the project and added a require at the top of the file after the path require and before the express() call.

[sourcecode language=”javascript”]
var path = require(‘path’);
var config = require(‘./config’);

var app = express();
[/sourcecode]

In the app.set line for the port I changed the setting of the port to be the configuration parameter.

[sourcecode language=”javascript”]
app.set(‘port’, process.env.PORT || config.get(‘port’));
[/sourcecode]

Now when I run the application, the port will be derived from the config.js file setting.

Now What Did I Do?

I’ll write more about this in the near future, but for now I’ve run into something not being setup right. I’m still working through various parts of customizing my setup. In the instructions for convict.js, which aren’t very thorough beyond the most basic use, is how to insure that the other environments are setup with *.json files. What I mean by this is…

I’ve setup a directory with three json files. It looks like this.

My Config Directory
My Config Directory

Each of these files (or at least one of the files) I would think, based on the instructions, get loaded and merged into configuration based on the code in my app.js as shown below.

[sourcecode language=”javascript”]
var env = conf.get(‘env’);
conf.loadFile(‘./config/’ + env + ‘.json’);
[/sourcecode]

The order of override for the configuration values starts with the base config.js, then any *.json files override those config.js settings and any environment variables override the *.json set configuration variables. Based on that, unless of course I’ve missed something for this snippet of code, I should be getting the configuration settings from the *.json files.

My config file data looks like this. Since it is using cjson I went ahead and stuck comments in there too.

[sourcecode language=”javascript”]
/**
* Created by adron on 3/14/14.
* Description: Adding test configuration for the project.
*/

{
"port": {
"doc": "The port to bind.",
"format": "port",
"default": 1337,
"env": "PORT"
}
}
[/sourcecode]

Until later, happy coding, I’m going to dive into this and figure out what my issue is. In my next blog entry I’ll be sure to post an update to what the problem is.

Oh, and that fueler project. Feel free to ping me and jump into it.

WebStorm JavaScripting & Noding Workflow Webinar Recording

Today the JetBrains team wrapping up final processing for my webinar from last week. You can check out the webinar via their JetBrains Youtube Channel:

JavaScriptFor even more information be sure to check out the questions and answers on the JetBrain WebStorm IDE blog entry. Some of the questions include:

  • Q: How to enable Node.js support in PhpStorm (PyCharm, IntelliJ IDEA, RubyMine)?
  • Q:How to enable autocompletion for Express, Mocha and other libraries?
  • Q: Is it possible to debug a Node.js application that runs remotely? Is it possible to debug when your node and the rest of the dependencies (database, etc.) are running in a VM environment like Vagrant?
  • Q: Does the debugger support cluster mode?

…and others all here.