rkneufeld

Check-in .gitconfig Without Your Github Token

Source-controlling your dotfiles has been all the rage. Github, unfortunately, dumps your username and token into your global .gitconfig.

Luckily one of Git’s newest features as of 1.7.10 is an include directive for config files (commit). If you don’t have this version already brew update && brew upgrade git should get you there.

To make use of this feature change the github section of your ~/.gitconfig from:

[github]
  user = someone
  token = <MY HASH>
...

to

[include]
  path = ~/.gitconfig.github

and place the pre-existing [github] section into ~/.gitconfig.github.

Now you’re free to source control your .gitconfig and ln -s to it directly. Granted, you will still need to be careful about checking in your token; the upside is systems already properly configured can git pull and see changes to .gitconfig take affect without rejiggering your .gitconfig on every box whenever it changes.

Comments

Building a Bare-bones NPM Package

I’ve been spending a lot of time lately writing JavaScript, and my latent curiosity about npm has finally got the better of me once I started writing a mocha wrapper for Douglas Crockford’s recently released JavaScript QuickCheck implementation called JSCheck. (stretch.js if you want to check it out)

I wasn’t able to find a clear reference on how to start a package from scratch. After scouring the npm docs, blog articles and some popular npm packages I was able to come up with a basic formula for creating a new npm package.

This is that formula:

Get Nodejs

If you’re on a mac

$ brew install nodejs

Otherwise visit the nodejs download page to get a version for your system.

npm init

Create a directory for your project and cd into it

$ mkdir your-project && cd your-project

Now run npm init, entering any information you choose.

npm init will gather metadata about your project and create ./package.json that npm uses as the primary location for project metadata, dependencies and execution instructions.

One option of note is “Main module/entry point”. This option (default: index.js) names the file that is initially entered when require('your-project') is called.

Flesh it out

Now that package.json is created we can start fleshing out our project. I prefer to keep index.js simple, and thus it only acts as an entry point into the rest of the project.

module.exports = require('./lib/your-project');

Application code can now live happily sequestered in ./lib. We may as well get that started now too:

$ mkdir lib
$ touch lib/your-project.js

For now lets keep your-project.js simple and fill it with something like this:

exports.version = require('../package').version;

// actual code goes here...

Test it with Mocha

We’d preferably like to be able to test our application, so lets add mocha and chai to the project.

Open up package.json and change

  "devDependencies": {},

to

"devDependencies": {
  "mocha": "~1.0",
  "chai" : "~0.5"

},

npm supports a number of version specifiers, but in this case I just want anything less than 2.0. (The dependencies section of docs/json.html has further details.)

$ npm install

will install mocha and chai into ./node_modules. I suggest we also hide this from git

$ echo "node_modules" >> .gitignore

Add a basic test

Place the following in test/your-project.js

var mocha  = require('mocha');
var expect = require('chai').expect;

describe("My project", function () {
  it("should know its version", function () {
    var myProject = require('../index');
    expect(myProject.version).to.not.equal(undefined);
    expect(myProject.version).to.equal('0.0.0');
  });
});

Now if you run the command mocha test/your-project.js or, more generally, mocha, you should see:

$ mocha

  .

  ✔ 1 test complete (2ms)

Setup a Makefile

A pattern I observed in a few npm packages was using Makefiles to manage build and test tasks. Place the following in ./Makefile

test:
  ./node_modules/.bin/mocha

.PHONY: test

Now you can

$ make test

to execute your test suite. Makefile’s are sensitive about whitespace. Use tabs, not spaces

Bonus: Travis CI Integration

If you want to go the extra mile, setup continuous integration on Travis. I’m not going to go into detail now, but the general steps to follow are:

  1. Push your-project to github
  2. Go to your profile page
  3. Turn on “your-project””
  4. Create a ./.travis.yml

Your .travis.yml should look like this:

language: node_js
node_js:
  - 0.6

For further detail check out Travis docs > getting started.

Recap

Setup a basic project:

brew install nodejs
mkdir your-project && cd your-project
npm init 
echo "module.exports = require('./lib/your-project')" >> index.js
mkdir lib
echo "exports.version = require('../package').version;" >> lib/your-project.js

Add Mocha + Chai for testing

# add mocha version ~1.0 and chai version ~0.5 to devDependencies in package.json
npm install
echo "node_modules" >> .gitignore
mkdir test
curl https://raw.github.com/gist/2552913/b42f89808c4d7b9ee6241aa83bc42ba1300e81f9/your-project-test.js > test/your-project.js
echo "test:\n\t./node_modules/.bin/mocha\n\n.PHONY: test" > Makefile
make

Optionally,

  1. Push to Github
  2. Integrate with Travis CI

Questions? Suggestions for improvement?

Comments

Accessing the Remote MintChip Page on OS X

Wahoo! You got your acceptance email for the MintChip challenge and now you want to access remote.mintchipchallenge.com. Screw waiting for the physical MintChip, you want to muck around with it now. Hit up the instructions page however, and you will find it notably lacking in instructions on how to use it with OSX. Doh.

Not including proper OSX instructions is kind of a jerk-move on their part, but the process is simple enough. Let me walk you through it:

How to install the certificates

  1. You have your certificates right? You should have gotten two of them attached to your “Welcome to the MintChip Challenge” email. If you don’t have this email then you need to wait a little while (you did apply didn’t you?)
  2. Double-click on the first .p12 certificate. Enter the password included in the email. (Add these to whatever keychain you choose, I chose my “login” keychain)
  3. Repeat for the second .p12 cert.
  4. Optional: choose to trust the “Remote MintChip Certificate Authority” if you want to cut down on errors & warnings. You can do this by selecting the certificate, clicking File > Get Info, then under “Trust” change “Use system defaults” to “Always Trust”.
  5. Close Keychain Access.app

We’re ready to go.

How to access your account

  1. Visit remote.mintchipchallenge.com. You’ll be prompted to select a certificate, choose either of the two you just installed.

There is, however, one caveat to this step. You have to use Safari, and not Chrome. I haven’t checked with other

Now that you have everything all set up you’re free to get started writing sweet apps for MintChip. Have fun.

Success!

Comments

Where the Hell Is Scala:console!?

Ever since I started programming Scala in the Play! framework I’ve been absolutely floored by the lack of an interactive console in play! and play-scala.

Up until a week or two ago I’ve been programming heavily in Cocoa on the Mac version of our uploader, but since we launched Gush publicly last week I’ve been neck-deep in play! work. Things got rough, the framework started fighting back, and I was immediately reminded how much I love using a console. So I went digging (again), and the state of things was so dismal that I thought it warranted a blog post (and restarting my entire blog).

what happened?

Well, play-scala used to have a command called scala:console that brought up a wicked sweet console a la rails console. Then f59224658cc6cc12efee1a7e6cf593c8ada20589 happened on Jan. 11, 2011; For no obvious reason other than “Global refactoring and cleaning” guillaumebort dropped Console.scala out of existance. What gives?

This time around I dig some digging and managed to find some old posts referencing trouble with readLine and apparently even the author of sbt had tried chiming in to help. Since then, however, there doesn’t appear to be any chatter other than this ticket on lighthouse, which I commented on over three months ago with no response from Guillaume.

the rant

Frankly I think it’s unacceptable to not have an interactive console in a web framework, but apparently the rest of the play! and play-scala community gets by fine without it. What are these people using when they need to closely observe behaviour!? I’ve tried using Eclipse with the Scala IDE plugin, and heck, one time I even got a scala console open that had included some Play! stuff, but I’ve never been able to consistently get Eclipse to do anything other than tell me I have hundreds upon hundreds of source errors - even when there aren’t any.

As a result I’m back to vim, but still no easy way other than the slow and painful cycle of: write code -> refresh page -> watch console.

living with it

What now? Well Gush is pretty much the best (we’re hiring, btw) and I get to spend 20% of my time on an open-source project of my choosing. I think I’m going to be contacting Guillaume directly and doing whatever I can to get scala:console back into play-scala < 1.0 and get scala:console into play 2.0.

Mr. Bort, await my call (or message).

Comments