<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[rkneufeld]]></title>
  <link href="http://blog.ryanneufeld.ca/atom.xml" rel="self"/>
  <link href="http://blog.ryanneufeld.ca/"/>
  <updated>2012-06-12T10:55:05-05:00</updated>
  <id>http://blog.ryanneufeld.ca/</id>
  <author>
    <name><![CDATA[Ryan Neufeld]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Check-in .gitconfig without your github token]]></title>
    <link href="http://blog.ryanneufeld.ca/blog/2012/05/01/check-in-gitconfig-without-your-github-token/"/>
    <updated>2012-05-01T10:01:00-05:00</updated>
    <id>http://blog.ryanneufeld.ca/blog/2012/05/01/check-in-gitconfig-without-your-github-token</id>
    <content type="html"><![CDATA[<p>Source-controlling your dotfiles has been <a href="http://dotfiles.github.com/">all the rage</a>. Github, unfortunately, dumps your username and token into your global <code>.gitconfig</code>.</p>

<p>Luckily one of Git&#8217;s newest features as of 1.7.10 is an include directive for config files (<a href="https://github.com/gitster/git/commit/9b25a0b52e09400719366f0a33d0d0da98bbf7b0">commit</a>). If you don&#8217;t have this version already <code>brew update &amp;&amp; brew upgrade git</code> should get you there.</p>

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

<pre><code>[github]
  user = someone
  token = &lt;MY HASH&gt;
...
</code></pre>

<p>to</p>

<pre><code>[include]
  path = ~/.gitconfig.github
</code></pre>

<p>and place the pre-existing <code>[github]</code> section into <code>~/.gitconfig.github</code>.</p>

<p>Now you&#8217;re free to source control your <code>.gitconfig</code> and <code>ln -s</code> to it directly. Granted, <strong>you will still need to be careful about checking in your token</strong>; the upside is systems already properly configured can <code>git pull</code> and see changes to <code>.gitconfig</code> take affect without rejiggering your <code>.gitconfig</code> on every box whenever it changes.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Building a bare-bones NPM package]]></title>
    <link href="http://blog.ryanneufeld.ca/blog/2012/04/29/building-a-bare-bones-npm-package/"/>
    <updated>2012-04-29T14:56:00-05:00</updated>
    <id>http://blog.ryanneufeld.ca/blog/2012/04/29/building-a-bare-bones-npm-package</id>
    <content type="html"><![CDATA[<p>I&#8217;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 <a href="http://visionmedia.github.com/mocha/">mocha</a> wrapper for Douglas Crockford&#8217;s recently released JavaScript QuickCheck implementation called <a href="http://jscheck.org">JSCheck</a>. (<a href="http://github.com/rkneufeld/stretch.js">stretch.js</a> if you want to check it out)</p>

<p>I wasn&#8217;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.</p>

<p>This is that formula:</p>

<h3>Get Nodejs</h3>

<p>If you&#8217;re on a mac</p>

<pre><code>$ brew install nodejs
</code></pre>

<p>Otherwise visit <a href="http://nodejs.org/#download">the nodejs download page</a> to get a version for your system.</p>

<h3>npm init</h3>

<p>Create a directory for your project and cd into it</p>

<pre><code>$ mkdir your-project &amp;&amp; cd your-project
</code></pre>

<p>Now run <code>npm init</code>, entering any information you choose.</p>

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

<p>One option of note is <strong>&#8220;Main module/entry point&#8221;</strong>. This option (default: <code>index.js</code>) names the file that is initially entered when <code>require('your-project')</code> is called.</p>

<h3>Flesh it out</h3>

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

<pre><code>module.exports = require('./lib/your-project');
</code></pre>

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

<pre><code>$ mkdir lib
$ touch lib/your-project.js
</code></pre>

<p>For now lets keep <code>your-project.js</code> simple and fill it with something like this:</p>

<pre><code>exports.version = require('../package').version;

// actual code goes here...
</code></pre>

<h3>Test it with Mocha</h3>

<p>We&#8217;d preferably like to be able to test our application, so lets add <a href="http://visionmedia.github.com/mocha/">mocha</a> and <a href="http://chaijs.com/">chai</a> to the project.</p>

<p>Open up <code>package.json</code> and change</p>

<pre><code>  "devDependencies": {},
</code></pre>

<p>to</p>

<pre><code>"devDependencies": {
  "mocha": "~1.0",
  "chai" : "~0.5"

},
</code></pre>

<p>npm supports a number of version specifiers, but in this case I just want anything less than 2.0. (<a href="http://npmjs.org/doc/json.html#dependencies">The dependencies section</a> of docs/json.html has further details.)</p>

<pre><code>$ npm install
</code></pre>

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

<pre><code>$ echo "node_modules" &gt;&gt; .gitignore
</code></pre>

<h4>Add a basic test</h4>

<p>Place the following in <code>test/your-project.js</code></p>

<pre><code>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');
  });
});
</code></pre>

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

<pre><code>$ mocha

  .

  ✔ 1 test complete (2ms)
</code></pre>

<h4>Setup a Makefile</h4>

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

<pre><code>test:
  ./node_modules/.bin/mocha

.PHONY: test
</code></pre>

<p>Now you can</p>

<pre><code>$ make test
</code></pre>

<p>to execute your test suite. <strong>Makefile&#8217;s are sensitive about whitespace. Use tabs, not spaces</strong></p>

<h3>Bonus: Travis CI Integration</h3>

<p>If you want to go the extra mile, setup continuous integration on <a href="travis-ci.org">Travis</a>. I&#8217;m not going to go into detail now, but the general steps to follow are:</p>

<ol>
<li>Push your-project to github</li>
<li>Go to your <a href="http://travis-ci.org/profile">profile page</a></li>
<li>Turn on &#8220;your-project&#8221;&#8221;</li>
<li>Create a <code>./.travis.yml</code></li>
</ol>


<p>Your <code>.travis.yml</code> should look like this:</p>

<pre><code>language: node_js
node_js:
  - 0.6
</code></pre>

<p>For further detail check out <a href="http://about.travis-ci.org/docs/user/getting-started/">Travis docs > getting started</a>.</p>

<h2>Recap</h2>

<p>Setup a basic project:</p>

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

<p>Add Mocha + Chai for testing</p>

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

<p>Optionally,</p>

<ol>
<li>Push to Github</li>
<li>Integrate with Travis CI</li>
</ol>


<p><strong>Questions? Suggestions for improvement?</strong></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Accessing the Remote MintChip page on OS X]]></title>
    <link href="http://blog.ryanneufeld.ca/blog/2012/04/05/accessing-the-remote-mintchip-page-on-os-x/"/>
    <updated>2012-04-05T14:19:00-05:00</updated>
    <id>http://blog.ryanneufeld.ca/blog/2012/04/05/accessing-the-remote-mintchip-page-on-os-x</id>
    <content type="html"><![CDATA[<p>Wahoo! You got your acceptance email for the <a href="mintchipchallenge.com">MintChip challenge</a> and now you want to access <a href="https://remote.mintchipchallenge.com/">remote.mintchipchallenge.com</a>. Screw waiting for the physical MintChip, you want to muck around with it <strong>now</strong>. Hit up the <a href="http://developer.mintchipchallenge.com/devguide/developing/common/mintchip-api.html">instructions page</a> however, and you will find it notably lacking in instructions on how to use it with OSX. <em>Doh.</em></p>

<p>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:</p>

<h2>How to install the certificates</h2>

<ol>
<li>You have your certificates right? You should have gotten two of them attached to your &#8220;Welcome to the MintChip Challenge&#8221; email. If you don&#8217;t have this email then you need to wait a little while (you did <a href="http://mintchipchallenge.com/details/register-to-participate">apply</a> didn&#8217;t you?)</li>
<li>Double-click on the first .p12 certificate. Enter the password included in the email. (Add these to whatever keychain you choose, I chose my &#8220;login&#8221; keychain)</li>
<li>Repeat for the second .p12 cert.</li>
<li><strong>Optional:</strong> choose to trust the &#8220;Remote MintChip Certificate Authority&#8221; if you want to cut down on errors &amp; warnings. You can do this by selecting the certificate, clicking <code>File &gt; Get Info</code>, then under &#8220;Trust&#8221; change &#8220;Use system defaults&#8221; to &#8220;Always Trust&#8221;.</li>
<li>Close Keychain Access.app</li>
</ol>


<p>We&#8217;re ready to go.</p>

<h2>How to access your account</h2>

<ol>
<li>Visit <a href="https://remote.mintchipchallenge.com/">remote.mintchipchallenge.com</a>. You&#8217;ll be prompted to select a certificate, choose either of the two you just installed.</li>
</ol>


<p><strong>There is, however, one caveat to this step. You <em>have</em> to use Safari, and <em>not</em> Chrome. I haven&#8217;t checked with other</strong></p>

<p>Now that you have everything all set up you&#8217;re free to get started writing sweet apps for MintChip. Have fun.</p>

<p><img src="http://blog.ryanneufeld.ca/images/remote-mintchip.png" alt="Success!" /></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Where the Hell Is scala:console!?]]></title>
    <link href="http://blog.ryanneufeld.ca/blog/2011/10/04/where-the-hell-is-scala-console/"/>
    <updated>2011-10-04T20:25:00-05:00</updated>
    <id>http://blog.ryanneufeld.ca/blog/2011/10/04/where-the-hell-is-scala-console</id>
    <content type="html"><![CDATA[<p>Ever since I started programming Scala in the <a href="http://playframework.org">Play! framework</a> I&#8217;ve been absolutely floored by the lack of an interactive console in play! and <a href="http://scala.playframework.org/">play-scala</a>.</p>

<p>Up until a week or two ago I&#8217;ve been programming heavily in Cocoa on the Mac version of our uploader, but since we launched <a href="http://getgush.com">Gush</a> publicly last week I&#8217;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).</p>

<h3>what happened?</h3>

<p>Well, play-scala <strong>used</strong> to have a command called <code>scala:console</code> that brought up a wicked sweet console a la <code>rails console</code>. Then <a href="https://github.com/playframework/play-scala/commit/f59224658cc6cc12efee1a7e6cf593c8ada20589">f59224658cc6cc12efee1a7e6cf593c8ada20589</a> happened on Jan. 11, 2011; For no obvious reason other than &#8220;Global refactoring and cleaning&#8221; <a href="https://github.com/guillaumebort">guillaumebort</a> dropped <code>Console.scala</code> out of existance. What gives?</p>

<p>This time around I dig some digging and managed to find some <a href="https://groups.google.com/d/topic/play-framework/Fi4ond4eTDc/discussion">old</a> <a href="https://groups.google.com/d/topic/play-framework/hI-ZGasGIrc/discussion">posts</a> referencing trouble with <code>readLine</code> and apparently even the author of <a href="http://code.google.com/p/simple-build-tool/">sbt</a> had tried chiming in to help. Since then, however, there doesn&#8217;t appear to be any chatter other than this <a href="https://play.lighthouseapp.com/projects/74274/tickets/1">ticket</a> on lighthouse, which I commented on over three months ago with no response from Guillaume.</p>

<h3>the rant</h3>

<p>Frankly I think it&#8217;s unacceptable to <strong>not</strong> 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&#8217;ve tried using Eclipse with the <a href="http://www.scala-ide.org/">Scala IDE</a> plugin, and heck, one time I even got a scala console open that had included some Play! stuff, but I&#8217;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&#8217;t any.</p>

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

<h3>living with it</h3>

<p>What now? Well Gush is pretty much the best (<a href="http://getgush.com/jobs">we&#8217;re hiring, btw</a>) and I get to spend 20% of my time on an open-source project of my choosing. I think I&#8217;m going to be contacting Guillaume directly and doing whatever I can to get <code>scala:console</code> <em>back</em> into play-scala &lt; 1.0 and get <code>scala:console</code> <em>into</em> <a href="http://www.playframework.org/2.0">play 2.0</a>.</p>

<p>Mr. Bort, await my call (or message).</p>
]]></content>
  </entry>
  
</feed>
