• Route Organisation with Express 4+

    Caveat Emptor: As far as I can tell, this routing functionality will continue to work in Express 5, which at this time of writing is still in early alpha stage. Read the Express 5 Upgrading Guide here. Also, in the Nested Routes section below, I mention passing the mergeParams option the Router method - this was only introduced in Express 4.5.0.

    The express.Router class was introduced in Express 4 to allow developers to instantiate routers as standalone modules with their own middleware and routing systems.

    For me, the greatest benefit is that this affords more flexibility and makes it easier to manage different combinations of middleware of varying specificity.

    This simple example gives a bird’s eye view of the different components of a working router implementation:

    import express from 'express'
    //... other Express boilerplate
    
    const mainRouter = express.Router()
    mainRouter.get('woah', (req, res) => {
      //... do something
    })
    
    const userRouter = express.Router()
    userRouter.use(authenticationMiddlware())
    userRouter.get('profile', (req, res) => {
      //... do something
    })
    
    // mount the routers by specifying their mount points, in this case `/` and `/users`
    app.use('/', mainRouter)
    app.use('/users', userRouter)
    

    At this point, the active routes would be:

    GET /woah
    GET /users/profile
    

    How I Organise my Routes

    Now, with a big app, we can split its many routes into different files, and instantiate/mount them neatly. This is great if you’re intending to be RESTful, because the organisation will come quite intuitively. I’m assuming a directory structure like this, where apples, oranges and pears are our resources:

    ├── index.js
    ├── routes.js
    ├── routes
    │   ├── apples.js
    │   ├── oranges.js
    │   └── pears.js
    

    In index.js, all we have to do is bootstrap the routes:

    require('./routes')(app)
    

    In routes.js, we require each route file iteratively. Take note that usual routing precedence rules apply - both the file order as well as the route order inside a file matters.

    import express from 'express'
    const routes = [
      {mountPoint: '/apples', filePath: './routes/apples'},
      {mountPoint: '/oranges', filePath: './routes/oranges'},
      {mountPoint: '/pears', filePath: './routes/pears'}
    ]
    
    module.exports = app => {
      for (let route of routes) {
        let router = express.Router()
        require(route.filePath)(router)
        app.use(route.mountPoint, router)
      }
    }
    

    We can DRY it up even more by getting the file path from the mount point (or the other way around):

    import express from 'express'
    const routesDirectory = './routes'
    const routes = [
      'apples',
      'oranges',
      'pears'
    ]
    
    module.exports = app => {
      for (let route of routes) {
        let router = express.Router()
        require(`${routesDirectory}/${route}`)(router)
        app.use(`/${route}`, router)
      }
    }
    

    There are many different ways to specify middleware for one or many route files. Here are some ideas:

    import express from 'express'
    const routes = [
      {mountPoint: '/apples', filePath: './routes/apples', auth: true},
      {mountPoint: '/oranges', filePath: './routes/oranges'},
      {mountPoint: '/pears', filePath: './routes/pears'}
    ]
    
    module.exports = app => {
      for (let route of routes) {
        let router = express.Router()
    
        // this middleware is applied to all routes
        router.use(defaultMiddleware())
    
        // only routes with auth: true will have this middleware
        if (route.auth) { router.use(authMiddleware()) }
    
        require(route.filePath)(router)
        app.use(route.mountPoint, router)
      }
    }
    

    We can run multiple separate loops:

    import express from 'express'
    const routesDirectory = './routes'
    const routes = [
      'oranges',
      'pears'
    ]
    
    const authRoutes = [
      'apples'
    ]
    
    module.exports = app => {
      for (let route of routes) {
        let router = express.Router()
        require(`${routesDirectory}/${route}`)(router)
        app.use(`/${route}`, router)
      }
      for (let route of authRoutes) {
        let router = express.Router()
        router.use(authMiddleware())
        require(`${routesDirectory}/${route}`)(router)
        app.use(`/${route}`, router)
      }
    }
    

    We can even use regex (regex for flex!):

    import express from 'express'
    const routesDirectory = './routes'
    const routes = [
      'apples',
      'oranges',
      'pears'
    ]
    const someRegex = /something/
    
    module.exports = app => {
      for (let route of routes) {
        let router = express.Router()
    
        if (someRegex.test(route)) { router.use(authMiddleware()) }
    
        require(`${routesDirectory}/${route}`)(router)
        app.use(`/${route}`, router)
      }
    }
    

    Within a route file like apples.js, we can specify a middleware specific to the routes inside the file:

    module.exports = router => {
    
      // only routes in apples.js will have this middleware
      router.use(specificMiddleware())
    
      router.get('/', (req, res) => {
        //...
      })
      router.post('/', (req, res) => {
        //...
      })
      //... other routes
    }
    

    And last but not least, if you only want to apply middleware to a single endpoint, you can do that too:

    module.exports = router => {
    
      router.use(specificMiddleware())
    
      router.get('/', superSpecificMiddleware(), (req, res) => {
        //...
      })
      router.post('/', (req, res) => {
        //...
      })
      //... other routes
    }
    

    Well, I did mention flexibility, didn’t I?

    Nested Routes

    Since we’re on the topic of RESTful, how can we do nested routes?

    Let’s say pineapples is a resource nested within apples, so we’ll want to have routes that look like:

    GET /apples/:appleId/pineapples
    POST /apples/:appleId/pineapples
    GET /apples/:appleId/pineapples/:pineappleId
    ...
    

    and so on.

    You can add nested routers as middleware.

    The key is to add mergeParams: true to the Router factory so that the nested router can access the params from its parent router, which in this case is appleId.

    In apples.js, it’ll look like this:

    const nestedRoutes = [
      'pineapples'
    ]
    
    module.exports = router => {
    
      for (let route of nestedRoutes) {
        let nestedRouter = express.Router({mergeParams: true})
        require(`./${route}`)(nestedRouter)
        router.use(`/:appleId/${route}`, nestedRouter)
      }
    
      router.get('/', (req, res) => {
        //...do something
      })
      //... other apple routes
    }
    

    Of course, if your app is really complex, you can put nested route files inside folders:

    ├── index.js
    ├── routes.js
    ├── routes
    │   ├── apples.js
    │   ├── oranges.js
    │   ├── pears.js
    │   ├── apples
    │   │   ├── pineapples.js
    │   │   └── mangoes.js
    │   └── oranges
    │       └── starfruits.js
    

    and change the code above to reflect this file structure.

  • Initial Form Values with redux-form

    Caveat emptor: I’m currently using 3.0.6 of redux-form. As with most things on the bleeding edge, this post will probably be irrelevant in a few months (or weeks).

    There’re a few reasons one may need to have form values initialized upon render - edit forms, or default select values.

    In vanilla HTML, one would simply do:

    <select>
      <option value="apple">Apple</option>
      <option value="orange" selected>Orange</option>
    </select>
    

    It’s a little different in JSX. In JSX, Facebook recommends the following way.

    To set initial form values in redux-form that are actually initialized in the Redux state, one needs to pass in an object with a initialValues main key and field key-value pairs as props to the redux-form Form component:

    import { React, Component } from 'react'
    import { bindActionCreators } from 'redux'
    import { connect } from 'react-redux'
    
    import { reduxForm } from 'redux-form'
    import { registerPerson } from 'actions/coolStuff'
    
    @connect(null, dispatch => ({
      registerPerson: bindActionCreators(registerPerson, dispatch)
    }))
    export default class ExampleComponent extends Component {
      render() {
        const myInitialValues = {
          initialValues: {
            name: 'John Doe',
            age: 42,
            fruitPreference: 'apples'
          }
        }
        return (
          <div>
            <h1>Check out my cool form!</h1>
            <CoolForm  {...myInitialValues} onSubmit={(fields) => {this.props.registerPerson(fields)}} />
          </div>
        )
      }
    }
    
    @reduxForm({
      form: 'exampleForm',
      fields: ['name', 'age', 'fruitPreference']
    })
    class CoolForm extends Component {
      render() {
        const { fields: {name, age, fruitPreference}, handleSubmit } = this.props
        return (
          <form onSubmit={handleSubmit}>
            <label>Name</label>
            <input type='text' {...name} />
            <label>Age</label>
            <input type='text' {...age} />
            <label>Do you prefer apples or oranges?</label>
            <select {...fruitPreference}>
              <option value="apples">Apples</option>
              <option value="oranges">Oranges</option>
            </select>
            <button type='submit' onClick={handleSubmit}>Submit</button>
          </form>
        )
      }
    }
    

    If all goes well, you’ll see the initial values being loaded into Redux state upon initialization, which can be submitted (to handleSubmit) right away:

    success

  • Viterbi's Algorithm for first-order and second-order hidden Markov models

    I originally wrote this post to help me understand and internalize HMMs and the Viterbi algorithm, but school got too busy and I couldn’t finish the post. Still, there’s a fair amount of material here so I decided to publish it anyway. I hope it helps you at least a little bit, as it did for me.

    Hidden Markov models (HMMs) are representations of many kinds of real observations in real life. For example, when a baby is crying, you don’t actually know why she’s crying - it could be that she is hungry, or that she is tired, or any other multitude of reasons.

    As a parent who is also a machine learning practitioner, you decide to use data to predictably determine why, so that you can soothe them as effectively as possible.

    Firstly, you want to establish the parameters of the model. This means establishing 3 kinds of parameters:

    Set of (hidden) states

    For simplicity’s sake, we’re just going to assume that the baby can only be in states “normal”, “tired”, and “hungry”. These states not directly observable by us, or put another way, they are hidden from us - thus the “hidden” in hidden Markov models. This is what we want to be able to predict.

    Set of observable outputs

    In this case, the set would consist of crying and not_crying. This output is a cause of the hidden state that the baby is in, and is said to be “emitted” from the current state. For each state, there is a chance of emitting a certain output.

    Transition probabilities

    The transition probabilities is a set of numbers that describe the probability of transiting from any state to another. In this case, this would be described by:

                 crying   not_crying  STOP
    START          0.2        0.8      0
    crying         0.8        0.1     0.1
    not_crying     0.4        0.5     0.1
    
    

    So, given that the baby is currently crying, there’s a 0.8 probability that she will continue to cry, a 0.1 probability that she will stop, and a 0.1 probability that the observed sequence will end (this is when you pass the baby to your spouse and question, for the 124th time, why you became a parent).

    Emission probabilities

    The emission probabilities is a set numbers that describe the probability of an observable output being “emitted” given a current state.

                normal   tired  hungry
    crying        0.1     0.4    0.5
    not_crying    0.6     0.2    0.2
    

    So, given that a baby is currently not crying, there is a 0.6 probability that she is feeling okay, a 0.2 probability that she is tired, and a 0.2 probability that she is hungry.

    (START and STOP represent the start and end of an observed sequence, so an example would look something like START not_crying not_crying crying crying STOP)

    The question is:

    If I observed my baby to be not_crying crying crying, what’s the most likely sequence of states my baby was feeling throughout that period of observation? Could it be normal tired hungry, or normal tired tired?

    Given all these parameters, we can now conduct supervised learning on the hidden Markov model. The easiest way would be to enumerate through all the permutations and calculate their probabilities.

    The more efficient way to do it would be to use Viterbi’s algorithm, which is a dynamic programming algorithm with a time complexity that is linear in the length of the observed sequence and quadratic in the number of possible hidden states.

  • Daily brew with launchd

    It’s a good idea to run brew every day.

    Instead of cron, I use launchd instead. launchd has better integration with system behavior, such as running scripts on system wake. (Admittedly, the XML syntax is quite horrid, but we’ll live with it.)

    Create a local.custom.brew.plist file in ~/Library/LaunchAgents:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    
      <key>Label</key>
      <string>local.custom.brew</string>
    
      <key>ProgramArguments</key>
      <array>
        <string>brew</string>
        <string>update</string>
        <string>brew</string>
        <string>upgrade</string>
        <string>brew</string>
        <string>cleanup</string>
        <string>brew</string>
        <string>doctor</string>
      </array>
    
      <key>StartCalendarInterval</key>
      <dict>
          <key>Hour</key>
          <integer>00</integer>
          <key>Minute</key>
          <integer>00</integer>
      </dict>
    
    </dict>
    </plist>
    

    This will run brew update, brew upgrade, brew cleanup, and brew doctor at midnight every day.

    Load the .plist file

    To load the .plist file, there are two options available:

    launchctl

    $ launchctl load ~/Library/LaunchAgents/local.custom.brew.plist
    $ launchctl start local.custom.brew
    

    lunchy

    lunchy is a wrapper around launchctl:

    $ gem install launchctl
    $ lunchy restart local.custom.brew
    
  • Liquid Tag Parameters

    This is a nifty one.

    I wanted to create manual categories for my coding posts, so I ended up doing something like this in my coding/index.html (a simplified excerpt):

    <div>
      <h3>Ruby</h3>
      <ul>
        {% for post in site.posts %}
          {% if post.categories contains "ruby" %}
            {{ post.title }}
          {% endif %}
        {% endfor %}
      </ul>
    
      <h3>Javascript</h3>
      <ul>
        {% for post in site.posts %}
          {% if post.categories contains "javascript" %}
            {{ post.title }}
          {% endif %}
        {% endfor %}
      </ul>
    
      <h3>Erlang</h3>
      <ul>
        {% for post in site.posts %}
          {% if post.categories contains "erlang" %}
            {{ post.title }}
          {% endif %}
        {% endfor %}
      </ul>
    
      <!-- and so on -->
    </div>
    

    … which was really ripe for DRYing up. The problem was that the partial would need to accept a parameter of some sort (for the category name). The official Liquid documentation leaves much to be desired, but there’s a tiny part in the Templates section of the Jekyll documentation that saved the day:

    You can also pass parameters to an include. Omit the quotation marks to send a variable’s value. Liquid curly brackets should not be used here:

    {% include footer.html param="value" variable-param=page.variable %}
    

    These parameters are available via Liquid in the include:

    {{ include.param }}
    

    So I abstracted the above into a partial, naturally so:

    <!-- _includes/post-category.html -->
    <h3>{{ include.name | capitalize }}</h3>
    <ul>
      {% for post in site.posts %}
        {% if post.categories contains include.name %}
          {{ post.title }}
        {% endif %}
      {% endfor %}
    </ul>
    

    and the resulting index.html:

    <div>
      {% include post-category.html name="ruby" %}
      {% include post-category.html name="javascript" %}
      {% include post-category.html name="erlang" %}  
    </div>
    

    Neato!