☢ u2622.ca

Meteor tips, help and sometimes random things

5 Steps to Understanding Meteor Better by Improving Your JavaScript

| Comments

I don’t believe you need to be a JavaScript expert before diving into Meteor, but I highly recommend taking the time to learn advanced topics first. By levelling up your JavaScript, you will understand the concepts faster, and will feel less frustrated and confused. Even if you don’t stick with Meteor or do Meteor full time, the skills these books will teach you will help you in all aspects of development.

I recommend starting by watching a series of Douglas Crockford’s lectures on JavaScript, and then following it with Reginald Braithwaite’s Javascript Allongé.

  1. Watch Crockford’s The JavaScript Programming Language. Watch it even if you already have built some applications with JS already. It goes into the fundamentals in-depth, and will help cement the basics in your mind, which is essential when learning advanced topics.
  2. Watch Crockford’s Theory of the DOM. Watch it even if you think you know the DOM well. Again, establishing fundamentals makes learning advanced topics easier.
  3. Watch Crockford’s Advanced JavaScript. It covers some advanced topics sometimes unique to JavaScript, and common advanced patterns. If you’ve ever tried reading a JavaScript library and couldn’t even begin to comphrehend it, this lecture will help clear things up.
  4. Watch Crockford’s JavaScript: The Good Parts. It will help you pick out the best parts of the language to use, and the parts that you need to actively avoid.
  5. Read Reginald Braithwaite’s JavaScript Allongé. Reginald (aka ragnwald) covers advanced functional topics, and this will permanently change how you write your JavaScript, enabling you to write resuable code faster and with much higher confidence.

I recommend doing the above in that order. Allongé is more advanced and builds off of topics covered by Crockford. Each step will help bring your JavaScript game to the next level, with Crockford’s lessons establishing solid fundamentals, and Allongé teaching (in a very effective manner) the more advanced usages of functional programming with JS.

Note that I did all of the above (and worked through the exercises in Allongé) before I even touched Meteor, and for the most part, the only Meteor help I’ve needed has been the official Meteor docs. Having such a solid foundation of knowledge let me pick up Meteor with lightning speed, and all of those skills will stay with me when it comes time to learn another framework.

If you have trouble following Crockford’s lectures, then I recommend reading his print edition of JavaScript: The Good Parts instead. While you’re reading it, really work through the examples to make sure you’re understanding it as you go along.

Have you ever felt that your JavaScript skills were inadequate? Have you ever looked inside one of the libraries you use (jQuery perhaps?) and felt as though you didn’t understand JavaScript at all? I want to hear about it. Email me with your story (write as much or as little as you’d like).

Disadvantages of Using Meteor (Over Rails)

| Comments

You can save significant amounts of time by developing some web applications by using Meteor instead of Ruby on Rails, but it doesn’t come without drawbacks. Here are some of the ones that I’ve encountered: What are the disadvantages of using Meteor compared to Ruby on Rails?

Immature Environment: The biggest problem right now is that Meteor is new. Pretty much brand new, in the scope of web development. It’s not even version 1.0 yet, though it’s getting close. This means that it doesn’t have as many users, as many tutorials, as many books, as many screencasts. It can be hard if you run into a problem that no one else has run into yet, so you’ll need to be willing to dig into it a bit yourself. I’ve been there, and fortunately Meteor’s codebase is fairly cleanly written (especially compared to Rails and AngularJS, two other frameworks whose code I’ve read).

Not Widely Supported: Another consequence of being so new is that there aren’t as many hosting services available for Meteor apps yet. It is possible to deploy Meteor on Heroku, and in my experience it works well, though it feels very raw.

Nothing but JavaScript: You must run JavaScript (or Coffeescript) on the server side. This isn’t a big deal for me, but JS is definitely far from the first language I would choose to work with. The upside is that you can run the same code on the server and the browser, without worrying about having to cross-compile from another language.

Only MongoDB: As of now, the only supported database is MongoDB. They have plans to expand this in the future.

Rapidly Changing: The Meteor API is rapidly changing, so each new minor version may bring breaking changes. This is expected to lessen as it reaches 1.0.

Testing Frameworks: Testing frameworks haven’t been a high priority since the beginning, and the ones available so far have tended to be cumbersome and brittle. The community is working on solutions, but nothing stable has yet emerged, and the testing culture is nothing like the Ruby on Rails community’s.

While there are many disadvantages, I feel like the advantages heavily outweigh them (usually). But the list of advantages is for another post entirely!

What are some other disadvantages you can think of? Email me or leave a comment!

Implementing Web Hooks With Meteor

| Comments

It’s possible to add web hooks to your Meteor application by using iron-router.

Declare a server-side route in your Routes.map declaration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Router.map(function() {
  ... // Your other routes go here

  this.route('hook', {
    path: '/hook',
    where: 'server',
    action: function() {

      // Watch the Meteor log to see this output
      console.log("Hook called.");
      console.log("Headers: ", this.request.headers);
      console.log("Data: ", this.request.body);

      this.response.writeHead(200, {'Content-Type': 'text/html'});
      this.response.write("You wrote: " + this.request.body.message);
      this.response.write("\n");

      // `this.response.end` *must* be called, or else the connection is left open.
      this.response.end('Success!\n');
    }
  });

});

To test it out, issue this curl command from the command line:

1
curl -H "Content-Type: application/json" -d '{"message":"foo"}' http://localhost:3000/hook

The documentation for this.response and this.request are available on the node.js website: http://nodejs.org/api/http.html

I’ve created a sample Meteor application demonstrating this, which you can view at https://github.com/rgould/meteor-posthooks

Not clear enough? Send me an email at rgould@u2622.ca for some more help!

Icelandic Language Music Roundup

| Comments

While focusing heavily on learning Icelandic, I dug deeply looking for Icelandic-language music. There are surprisingly high amounts of Icelandic bands that sing exclusively in English. Here are my favourite songs with Icelandic lyrics:

Mammút - They play energetic rock music, bordering on post-punk sometimes. The first Icelandic language band I liked, and my favourite still. Here’s Svefnsýkt: Bónus: Rauðilækur

Q4U - Postpunk from the 80s, mostly in Icelandic. They’re still around. Here’s Sigurinn: Bónus: Snjóhvít

Samaris - Atmospheric minimal electro/triphop with clarinet. Very haunting. Here’s Góða Tungl: Bónus: Stofnar Falla

Nóra: Indie rock, ranging from upbeat and energetic to atmospheric and introspective. The more I listen, the more I like it. They sing entirely in Icelandic. Here’s Himinbrim: Bónus: Sjónskekkja

Lockerbie - Post-rock, but with a bit more pop/rock than usually characterised by Icelandic post-rock. Here’s Snjóljón:

Úlfur Úlfur - Hiphop with awesome backing percussion. They sing entirely in Icelandic. Here’s Út: Bónus: Ég er farinn

Pascal Pinon - D.I.Y., lo-fi, indie pop electronic. Many songs in Icelandic. Here’s Ekki Vanmeta: Bónus: Sandur

Sólstafir - Post-black metal, with elements of country and rock. They are amazing live. Their album Svartir Sandar is entirely in Icelandic and highly recommended. Here’s Fjara: Bónus: Svartir Sandar

There’s lots of music that I’ve discovered that I didn’t cover here, but I only wanted to showcase the music I liked the most. Feel free to leave other suggestions in the comments.

Screencast: Using Shell History to Create Aliases

| Comments

Contents:

  1. Introduction to aliases @ 0:00
  2. Analysing shell history to create relevant aliases @ 4:43

Download: mov 24MB, 8:26 (Recommended)

Watch (recommended in full screen and in HD):

Notes:

Make an alias:

1
2
alias l="ls -al"
alias glog="git log"

Add those to your ~/.aliasrc.

Modify ~/.zshrc or ~/.bashrc (works for both):

1
2
3
if [[ -r ~/.aliasrc ]]; then
  source ~/.aliasrc
fi

View shell history: history

View count of common commands:

1
2
history | awk '{ print $2 }' | sort | uniq -c | sort -n
history | awk '{ print $2,$3 }' | sort | uniq -c | sort -n

Use that output to create better aliases!

Here’s some of my favourite aliases:

1
2
3
4
5
6
7
8
9
10
11
12
13
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../../'
alias .....='cd ../../../../'
alias be='bundle exec'
alias g=git
alias ga='git add'
alias gc='git commit -v'
alias gca='git commit -v -a'
alias gch='git checkout'
alias gl='git pull'
alias gst='git status'
alias l='ls -al'

Machinist and Association Validations

| Comments

While upgrading to Machinist 2, I had a hell of a time getting blueprints with associations to actually save.

The problem turned out to be that the code was using validates_presence_of :hometown_id, where hometown is the name of the association, and the solution is to use validates_presence_of :hometown, or the newer version: validates :hometown, presence: true.

If you have a given class:

1
2
3
4
5
class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates_presence_of :hometown_id
end

and blueprints:

1
2
3
4
Viking.blueprint do
  name { "Heiðrek" }
  hometown
end

Then calling Viking.make will properly return an unsaved Viking object (with a Hometown object viking.hometown), but valid? will return false.

Calling Viking.make! will throw an exception: ActiveRecord::RecordInvalid: Validation failed: Hometown can't be blank

If you really want to keep using validates_presence_of :hometown_id, you can modify the blueprint like this:

1
2
3
4
Viking.blueprint do
  name { "Heiðrek" }
  hometown { Hometown.make! }
end

Then Viking.make! will succeed. Viking.make will also work, and will return an unsaved Viking object, but it will actually create and save the associated Hometown object, which negates part of the point of calling .make instead of .make! (make creates objects but does not save them to the database, giving quite a performance boost for test suites).

The proper solution is to adjust the validation in your model:

1
2
3
4
5
6
class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates :hometown, presence: true
  validates_associated :hometown
end

The key is that we’ve changed validates_presence_of :hometown_id to validates :hometown, presence: true. The validation actually checks the association itself, not the presence of an id field (which is only ever set once the hometown is saved).

We’ve also added a validates_associated :hometown call, which will check hometown.valid? before saving, and if the hometown fails validation, then the viking object will as well.

See API docs about validations here:

Goðan Daginn!

| Comments

Goðan Daginn, Heimur!

I just set up this new octopress instance in roughly half an hour! Hooray!