Australian vs US Coffee Terms Comparison

This took me a while to figure out when I first moved to Australia. I still remember the look on the barista’s face when I tried to order an Americano, and then the absolute puzzlement over what the hell a flat white vs a long black was.

I hope this helps other visitors to Australia from the US order a decent cup of coffee!

Description Australian Name US Name
A shot of espresso. Short Black Expresso
A shot of espresso mixed with hot water. Long Black Americano
A shot of espresso topped with milk froth. Macchiato
A cup of hot milk with a shot of expresso poured in. Macchiato
A shot of espresso with steamed milk. Flat White Latte No Foam
A shot of espresso with steamed milk and a little milk froth. Latte Latte
A shot of espresso with steamed milk, milk froth, and cocoa powder. Mocha Mocha
A shot of espresso with half steamed milk, half milk froth. Cappuccino Cappuccino
A shot of espresso with cold milk and ice cream. Iced Coffee
A cup of drip coffee over ice. Iced Coffee

Derby.js – Playing with Models

Been playing around with Derby in my spare time. The idea behind the platform is excellent – using node and express, you write one set of code, and that code automatically syncs data between browsers, servers, and a database.

So far, Derby is still very raw, and the documentation, while comprehensive, puts important information about the same topic in various places. I’ve culled the following eight lines of documentation of defining models from the documents:

Racer Paths

Racer paths are translated into database collections and documents using a natural mapping:

collection.documentId.document

All synced paths (anything that doesn’t start with an underscore) must follow this convention.

In other words, all model data stored at the first two path segments should be an object and not a string, number, or other primitive type.

Private paths

Paths that contain a segment starting with an underscore (e.g. _showFooter or flowers.10._hovered) have a special meaning.

These paths are considered “private,” and they are not synced back to the server or to other clients.

Private paths are frequently used with references and for rendering purposes.

Now, this information is VERY useful if you’re trying out the model system for the first time. The most important line (at least for my initial playing around), was this one:

In other words, all model data stored at the first two path segments should be an object and not a string, number, or other primitive type.

What this means: if, in creating your first model, you trying something like this:

model.set('people', []);

Eventually you will get an error. However,

model.set('myApp.containers.people', []);

will work just fine.

A follow up to this post is here.

Some node.js and express.js beginner help

I’ve just started using node.js with express.js on both Windows (with iisnode) and Ubuntu.

I love the stack (one programming language from front to back!), but some of the documentation has been frustrating for me.

I wanted to document what I’ve learned so far in the hopes that it’ll help someone else down the line.

Generate the starter app

At first, I wanted to just hack away modify some of the existing example apps that were out there. However, this ended up being a pretty frustrating experience as most of the basic examples were just sending ‘Hello World’ back to the browser.

Now, I didn’t want to do much more than this when I was starting out, but I did at least want to load a basic page with some basic information I passed in. After many hours of browsing blogs and the express documentation, I managed what I wanted, but right after I did all of this from scratch, I found out that the exact basic application I wanted can be generated automatically by express.

From the express.js documentation:

The quickest way to get started with express is to utilize the executable express(1) to generate an application as shown below:

Create the app:


$ npm install -g express
$ express /tmp/foo && cd /tmp/foo

Install dependencies:


$ npm install -d

Start the server:


$ node app.js

But what does “generate an app” mean? When I first read those lines, I skipped right past this step, as I though I already had express and its dependencies setup correctly.

However, these commands create the basic structure of a web app (with all the basic files, folders, and dependencies installed). Let’s walk the commands to get a better idea what each of them does

The installation commands, explained

npm install -g express

NPM, or the Node Package Manager, is a tool that comes with node that allows your install node packages quickly and easily from the command line. This command installs express, the popular MVC-ish framework for node.

$ express /tmp/foo && cd /tmp/foo

This line of code installs express into /tmp/foo, then changes the directory to /tmp/foo. You can also run this command from the folder you want to install express in (just run express from the command line). You can also specify some options when you generate your starter app, such as the templating and stylesheet language you want to use.

express -t jade -c stylus

This command tells express you want to install in the current directory, using Jade as your template language, and Stylus as your stylesheet language.

$ npm install -d

This command installs any dependencies that express needs for the instance you have installed. Express has a couple js packages that it needs to run, so this command goes and downloads the latest version of these dependencies.

What “Generate An App” Gives You

  • node_modules
  • This folder contains all the js dependencies (like express, stylus, jade, etc)
    that you need to run express on node.

  • public
  • This is where your static files go (by default). By default, this folder contains three sub-folders:

    1. images
    2. javascripts
    3. stylesheets
  • routes
  • This is where your routing logic goes. Initially, this only contains one route (to your example view).

  • views
  • This folder is the default location for the views you’ll use in your application.
    Views usually contain dynamic content, and are often written in a templating language.

The last thing that’s generated is app.js, which contains a good sample of configuration code as well as the only route your example route contains:

var express = require('express')
, routes = require('./routes');
...
app.get('/', routes.index);

If you jump into the routes folder, and open index.js, you’ll see your index route:

exports.index = function(req, res) {
res.render('index', { title: 'Express' })
};

But what does this code mean?

The first line of code defines two variables, express and routes. The first is a registered node module, express, and the second is just a js file. Later in app.js , the line app.get tells node that when the the base Url of your application (something like http://localhost:3123/) is called in a browser, that the routes.index method should be called.

But how does routes variable in the first file get the index method, when in index.js in the routes folder only defines the index function on something calls exports?

To keep the system loosely coupled, node using a library called RequireJs to inject dependencies into an application. One way to do this is create a function you want to be able to export to the rest of your application, then simply add your function to the exports object in your code.

When you call require(PATH_TO_YOUR_FILE) , any methods you added to exports will be added to the object returned by your call to require.

The final code is the the call to res.render. This is a call to express, which is telling express to load the file ‘index.jade’ (because in this instance, jade is the default render engine). The second parameter is passing a javascript object containing one element, title, which will be passed the index.jade template to be rendered.