Full Text Search for Meteor

As per the 1.0.4 release notes for Meteor, MongoDB 2.6 and 3.0 are now supported; and Meteor now comes bundled with MongoDB 2.6.7.

So what? This makes it easy to implement full text search via MongoDB's full text search support as follows:

Let's assume a Meteor collection Messages, with properties subject and content. When doing full text search, we want to have both subject and content indexed.

We need to ensure the collection underpinning the Messages collection has a full-text index defined:

Messages._ensureIndex({ subject: "text", content: "text" })

This gives us a full-text index covering both subject and content. (_ensureIndex should be used server-side only.)

A query (e.g. in a publish function) is now as simple as:

Messages.find({ $text: { $search: "invoice" }})

More information can be found in MongoDB's documentation on full text indexes and in Meteor's release notes.

A complete and runnable example is on Github.

The Unbearable Lightness of Estimating Effort

By the wonderful xkcd.com.

Generated code, like fish, begins to smell after three days.

Agreed. Thanks, http://linemanjs.com/

Mythology and Software Developers

Laurent Bossavit in The Making of Myths:

We could have constructed a different myth, one in which the canonical image of a programmer depicted the activity "talking to a person who's going to use the software, to figure out what their needs are and how best to support them."

Yes, that would be much better. I pledge to avoid playing broken telephone with those that really need the software I build, and I encourage my peers to do the same.

Git Submodules for Ansible Roles

Not totally sure this is the right way to do it, but here is what I want to achieve, and how I do it:

For different apps I want to use Ansible for setup/deployment, using my own roles, and I want to re-use those roles between apps. I could have everything in one directory tree (living in git for version control), but that means keeping deployment configuration for all apps in a single repo; I would rather like to have those configurations separated.

I couldn't find any authoritative info on how to do this, so here's my approach.

• Every role lives in its own git repo. An example is Vincent Rischmann's ansible-role-java.
• Every app (or project) has its own git repo for its Ansible configuration (inventory definition and playbooks etc.).
• The app repo has a roles sub directory. Actual roles (e.g. the java role) are then added as git submodules.

git submodule add https://github.com/vrischmann/ansible-role-java.git roles/java

and, voilá, Vincent's role is now available as a role 'java' in my project's Ansible configuration.

Node's http-proxy to simulate high latency

For testing a web app under "worse" connectivity conditions than I normally have on my dev machine, I created a proxy to increase latency. With Node's http-proxy this was surprisingly simple:

In a new directory, create app.js like this:

var http = require('http'),    httpProxy = require('http-proxy');
// initialize parametersvar listenPort = 5001,  destinationPort = 5000,  delay = 1000;
// router optionsvar options = {  router: {    '.*': 'localhost:' + destinationPort  }};
// create server and listenvar server = httpProxy.createServer(function(req, res, next) {  var delayedResponse = function() {    next();  };  setTimeout(delayedResponse, delay);}, options);server.listen(listenPort);

Install http-proxy (assuming you are using npm):

npm install http-proxy

And kick it:

node app.js

Making hard coded parameters configurable is left as an exercise to the reader. Hint: process.argv gives you access to command line arguments in Node.

Note that this is *not* simulating low bandwidth, just a sleepy server with high latency; once the delay is over, the proxy will respond with all bandwidth available. Thus, this approach isn't generally suitable to simulate a slow network connection.

Understanding CQRS, What I've Read

First, I read Kanasz Robert's article, which gave me a rough understanding of typical terminology, but otherwise left me with a feeling of "this is rather complicated and confusing".

Second, I read Greg Young's summary, which went back to basics, and untangled CQRS nicely from Event Sourcing, Task Based UI and Eventual Consistency. Thanks for that!

Next on my reading list is this PDF. It does not specify authorship, but the About Page of the related Blog contains some info.