enum IceCreamTaste {  
  awesome,
  meh,
  dunnoYet
}

And now we want a switch that returns an answer to your friend's question "How does your ice cream taste?". Like so:

function getAnswer(taste: IceCreamTaste) {  
    switch (taste) { 
        case IceCreamTaste.awesome:
            return `It's like a party in my mouth!`;
        case IceCreamTaste.meh:
            return 'Umm I think someone has eaten this before me.';
         case IceCreamTaste.dunnoYet:
            return 'Lemme try it first, ok?';
        default:
            throw new Error('unreachable case');
    } 
}

Now, it sure would be nice if TypeScript could hand-hold us a little and verify that we've covered all the possible values of the IceCreamTaste enum, right? Otherwise if I add, say, a new chocolate taste (which is obviously above awesome), I would have to remember to update all the switches that reference the enum and...oh hey, welcome, bugs!

Unreachability

Fortunately TypeScript 2+ sports a useful type called never (sometime referred to as the "bottom" type) which represents a value that can never occur.

OK, so how is that useful, you ask? Well, because our IceCreamTaste switch is exactly such a case - we want to tell the TypeScript compiler that the default branch of the switch statement is one of those "code execution can never get there" blocks.

Let's define an UnreachableCaseError:

class UnreachableCaseError extends Error {  
    constructor(val: never) { 
        super(`Unreachable case: ${val}`);
    }
}

Now if we plug this error into our ice cream switch, we get this type safe bliss:

function getAnswer(taste: IceCreamTaste) {  
    switch (taste) { 
        case IceCreamTaste.awesome:
            return `It's like a party in my mouth!`;
        case IceCreamTaste.meh:
            return 'Umm I think someone has eaten this before me.';
         case IceCreamTaste.dunnoYet:
            return 'Lemme try it first, ok?';
        default:
            throw new UnreachableCaseError(taste);
    } 
}

Try commenting out one of the cases and TypeScript will report an Argument of type 'IceCreamTaste.dunnoYet' is not assignable to parameter of type 'never' error.

Happy exhaustive switching! I'm @tomasbrambora

TypeScript modules are written in one of two modes: declaration mode or augmentation mode. The difference is that in declaration mode, you can declare new top-level declarations - wow, that's a mouthful - but you can't update existing ones whereas in augmentation mode it's vice versa.

Real-life example is extending React to support onTouchTap attribute.

If you have a, say, on-touch-tap-react.d.ts declaration file that looks like this

declare module 'react' {  
    interface HTMLProps<T> {
        onTouchTap?: React.EventHandler<React.TouchEvent<T>>;
    }
}

You'll get a flurry of errors from tsc because, whoa, you've just overwritten react.

What you need to do instead is:

import React from 'react';

declare module 'react' {  
  interface HTMLProps<T> {
    onTouchTap?: React.EventHandler<React.TouchEvent<T>>;
  }
}

The only difference is the import statement at the top of the file which switches the module to the augmentation mode, hence updating reactrather than overwriting it.

Well, good to know.

Happy augmenting! I'm @tomas_brambora.

Omit

Pick is handy when you need to create a new type from an existing interface with only the specified keys. Which is great but sometimes you need just the opposite. Like when you're defining the return type for your API endpoint where you want to include everything except for one or two private fields.

Using Pick for that gets awkward very fast. You can use Partial but that throws typechecking out of the window.

So what you actually need is Omit. Here it is:

type Diff<T extends string, U extends string> = ({[P in T]: P } & {[P in U]: never } & { [x: string]: never })[T];  
type Omit<T, K extends keyof T> = Pick<T, Diff<keyof T, K>>;  

(Update: Thanks to Andrew Bradley for his comment below about homomorphic transformation; snippet updated)

Now you can do things like:

type TCleanedUser = Omit<IUser, 'privateField1' | 'privateField2'>;  

Note: The original author of this is @tycho01 and the code was taken from this GitHub issue.

Projection (i.e., typesafe Mongo projection specifier)

If you use MongoDB it's pretty useful to be able to typecheck your projection specifiers, i.e., which fields should - or should not - be returned in the result. To do that, you can use this mapped type:

type Projection<T> = Partial<Record<keyof T, 0 | 1>>;  

Now you can write code like

MyCollection.find({}, {importantField: 1: anotherImportantField: 1} as Projection<IMyDoc>);  

Well at least till typed projection gets into the typings for your favourite Mongo driver by when you can just forget about this. :-)

Happy typechecking! I'm @tomas_brambora.

You see, I started with the simplest thing: a "click here to reply" link in the emails. Naturally, it turned a lot of our users were trying to reply directly to the emails rather than following the link. Because people want convenience. And it makes much sense, right? After all, who has to time to follow reply links in email.

So I decided to implement email routing for ShareWaste so that users can reply to emails directly. And for posterity, here's how I went about it.

Quick Overview

We'll be using Mailgun as the email provider in this example. That said, the approach would be very much the same for any provider that offers webhooks for incoming emails (e.g. Sendgrid).

Here's what we'll do:

1. First, we'll set up a Mailgun "route" (an incoming traffic webhook with configurable rules).
2. Then we'll implement a routine in our app that sends out emails with a specific replyTo header value (so that we can match incoming replies with their respective "parent" messages)
3. Finally, we'll create an API endpoint that handles the incoming emails (POST requests from Mailgun).

We'll be using mg.sharewaste.com for the domain (but obviously you'd use your own app's domain instead).

Let's look at these steps in a little more detail.

Mailgun Config

After you've signed up with Mailgun and created the domain (mg.sharewaste.com in our case), go to the routes tab and create a new route. Use the following settings:

1. Expression type: Match recipient
2. Recipient: .*_reply@mg.sharewaste.com
3. Forward actions: add https://sharewaste.com/api/email/reply
4. Fill in the route description (e.g. "email reply handler")
5. Hit Create route.

Now any email that goes to .*_reply@mg.sharewaste.com will trigger this route which means Mailgun will send an HTTP POST request to https://sharewaste.com/api/email/reply (which we specified in Forward actions) with the parsed email data in payload. Sweet as!

Next, we need two things: a) consume Mailgun's payload; and b) figure out which message is being replied to. Let's start with the latter.

Email sending logic

In order to match the incoming messages with their thread, we'll use a Mongo collection to store the mapping between the incoming email and the thread it belongs to. Let's call the collection mailRepliesMapping.

Here's what the documents will look like:

interface IMailData {  
  _id: string;

  // Id of the thread the email reply belongs to.
  threadId: string;

  // Id of the recipient of the email (i.e., of
  // the user who will send the reply).
  replySenderId: string;

  // Created at date, 'nuff said.
  createdAt: Date; 
}

And here's a code snippet of what we'll do when a new message is added to a thread. (With Meteor, sending emails is pretty easy - just use the Email.send function. But with vanilla Node it's really not much harder.)

function sendEmailForPost(post) {  
  // Get thread, get recipients, prepare email data.
  // ...


  const emailMappingDocId = MailDataCollection.insert({
    threadId: thread._id,
    replySenderId: emailRecipient._id,
    createdAt: new Date()
  });

  Email.send({
    // ...
  })
}

The idea is that every time Mailgun tells us we have a new reply, we'll find out the relevant mailRepliesMapping and we'll fetch all the metadata we need in order to add the message where it belongs.

To make things easily configurable, we'll add a replyEmailSuffix field to our Meteor settings with the value _reply@mg.sharewaste.com. We'll use this constant to easily parse out our internal id from an incoming email and lookup the relevant mailRepliesMapping document.

When we send our email out, we'll use the following replyTo header value:

const replyEmailSuffix = Meteor.settings['replyEmailSuffix'];  
const replyTo = `${emailMappingDocId}${replyEmailSuffix}`  

Now when the recipient replies, the email will be sent to an email address that looks like this: <my_document_id>_reply@mg.sharewaste.com. That way we're able to easily parse out the <my_document_id> section (as we describe in the next section).

Server Endpoint For Incoming Emails

The last bit is the "incoming email" handler. No curve ball there. Create a module file (e.g. imports/server/incoming-mail-handler.js) that looks like this:

import express from 'express';  
import bodyParser from 'body-parser';  
import { WebApp } from 'meteor/webapp';  
import { parseOneAddress } from 'email-addresses';  
import ThreadsApi from '../../api/threads';

// We need `multer` middleware because sending an email
// with attachments will produce a multipart message.
import multer from 'multer';

import { MailDataCollection } from '../../api/mailData';

// Create and set up Express app.
// Note: You would just use Express `Router` in
// production and create the Express App object in another module.
export const app = express();  
export const router = express.Router();  
const upload = multer();

// The incoming email handler, deals with Mailgun webhook payload.
router.post('/api/email/reply', upload.any(), Meteor.bindEnvironment((req, res) => {  
  console.log('MailHandler: processing email');

  // Parse out the email mapping document id from the email address.
  const replyEmailSuffix = Meteor.settings['replyEmailSuffix'];
  const parsedTo = parseOneAddress(req.body.To || req.body.to);
  const dataKey = parsedTo.address.replace(replyEmailSuffix, '');
  const data = MailDataCollection.findOne({ _id: dataKey });

  if (!data) {
    console.error(`Mailhandler: invalid mail reply key ${dataKey}`);
    return res
      .status(400)
      .send(`Invalid mail reply key ${dataKey}`);
  }

  const emailText = `${req.body['stripped-text']}\n\n${req.body['stripped-signature']}`;
  const threadId = data.threadId;
  if (!threadId) {
    console.error(`Mailhandler: invalid thread id ${threadId}`);
    return res
      .status(400)
      .send(`Invalid thread id ${threadId}`);
  }

  const sender = Meteor.users.findOne({ _id: data.replySenderId });
  if (!sender) {
    console.error(`Mailhandler: invalid sender ${data.replySenderId}`);
    return res
      .status(400)
      .send(`Invalid sender ${data.replySenderId}`);
  }

  const post = ThreadsApi.insertPost(emailText, threadId, sender);

  // Don't forget to send an email notification to the actual recipient.
  ThreadsApi.sendEmailForPost(post._id, sender);

  // In case we want to track which messages have been replied to via email.
  MailDataCollection.update({ _id: dataKey }, { $set: { emailReplyRouted: true } });

  // All done!
  res.send('ok');
}));

// Again, in production app, you'd use Express Router
// and create the app in another module.
app.use(bodyParser.urlencoded({  
  extended: true
}));
app.use(router);

// Wire up Meteor.
WebApp.connectHandlers.use(app);  

And that's it! Now every time any of our users replies to a message directly from their email client, we'll route the reply through Mailgun to our server which will append the message to the right thread and will also send an email notification to the recipient.

A cool feature of Mailgun is that if your server is down, Mailgun will try to re-deliver the payload a number of times (with semi-exponential backoff) in the next eight hours before giving up.

Attachments

Please note that in our example we don't handle attachments - they will simply be ignored. Inline attachments will just show as string ids in the email body. Parsing attachments wouldn't be very hard though (although you'd need to upload them somewhere); check out Mailgun's Documentation to see how to get them from the payload.

Summary

We've learnt to route incoming emails to our Meteor app via Mailgun. Here's what we covered:

• When we send a message from our app, we use a special replyTo header value with a unique identifier for each email.
• When a user replies to an email directly from the email client, the message will be routed to our server via Mailgun
• When we detect an incoming email reply, we parse the email address to get the email's unique identifier. Then we look up the relevant metadata in our database and we figure out who sent the message and which thread the message should be appended to.
• If our server is down momentarily, Mailgun will re-send the notification a couple times (so we don't lose messages).

And that's all there is to it. Not that hard, right?

Happy routing! I'm @tomas_brambora.

PS: If you're into composting or if you simply think that composting scraps - and producing soil - is better than just chucking them into garbage, be sure check out ShareWaste. And spread the word, the more, the merrier! :-)

Static imports like this bring about a number of benefits such as first-class support for circular dependencies between modules and (potential) support for macros but it also means you cannot conditionally import modules. Which can be a fairly big issue if you're using e.g. Meteor, as code-sharing between server and client is one of its core propositions.

Now, this is not reallly a problem when using vanilla JS as you can simply switch to raw require. However, if you're using TypeScript (and some smart people say you should), this doesn't really cut it because, hey, where did my types go?

So that's the question - with require which is just a regular function, how do I tell compiler the type of what I'm requiring?

Reference Elision

Enter reference elision. See, in TypeScript, when you import a module, the compiler only emits code into the JavaScript output if you use the import in a value position in the body of the module. In other words, if you import a module but never use any of the imported values other than as TypeScript types, the resulting javascript file will look as if you never imported the module at all.

Which means these two files will output the same JS code:

b.ts

import * as ModuleA from './a';  
const modA: typeof ModuleA = require('./a');  
console.log('modA.foo', modA.foo);  

c.ts

const modA = require('./a');  
console.log('modA.foo', modA.foo);  

Conditional Imports

This is incredibly useful because if we combine the typeof keyword (which returns the type of its argument) with what we know of reference elision, we can achieve conditional imports in TypeScript while maintaining type safety:

import * as ServerOnly from './top-secret';

let serverMod: typeof ServerOnly;  
if (Meteor.isServer) {  
  serverMod = require('./top-secret');
}

if (Meteor.isServer) {  
  console.log('topSecret:', serverMod.topSecret);
}

Note that this won't prevent you from accidentally calling the (undefined) module from your client code; that would require something like preprocessor directives which TS doesn't currently support. But at least you'll have types when calling it from the server.

Happy importing! I'm @tomas_brambora.

Sidenote: There was a proposal to make reference elision explicit via the type keyword but it was rejected.

Sidenote2: Once TypeScript supports the ES dynamic import proposal this will be a non-issue.

Sidenote3: Kudos to TypeScript handbook which is where I've found info on reference elision and optional imports.

Sidenote4: I've submitted a pull-request to the Meteor guide.

Bad approach - using a timeout

Pretty simple:

User.onSignup((user) => {  
  setTimeout(() => {
    sendFollowupEmailToUser(user);
  }, FOLLOWUP_EMAIL_DELAY_MS);
})

Also: wrong.

Don’t do this. If the server restarts, the delayed task is lost; and since we’re in the age of clouds, you should expect your server to restart anytime and surprisingly often (see e.g. Heroku dyno cycling). It’s wrong if you wait just for a couple seconds, but it’s even wronger (read: pretty much useless) if you wait twenty four hours or longer.

Better approach - periodic polling

Periodically fetch for new users and send them the email. Here's the pseudocode:

setInterval(() => {  
  const dayAgo = moment().subtract(24, ‘h’).toDate(); 
  const users = Users.find({
    createdAt: { $gt: dayAgo},
    welcomeEmailSent: { $exists: false }
  }).fetch();
  users.each((user) => {
    try {
      sendFollowupEmailToUser(user);
      Users.update({ _id: user._id}, { $set: { welcomeEmailSent: true } });
    } catch (e) {
      logger.error(‘Failed to send welcome followup email’, e);
    }
  })
}, POLLING_INTERVAL_MS);

This approach is better in that it is robust with regards to server restarting. But it’s quite wordy. And you have to manually keep track of which users have been sent the welcome email which is slightly annoying and it pollutes the user document (or becomes more annoying if you decide to keep the flag outside of the user document).

Best approach - delayed task in a task queue

Here we go:

const WELCOME_FOLLOWUP_EMAIL_TASK_KEY = ‘sendWelcomeFollowupEmail’;

User.onSignup((user) => {  
  const delay = moment.duration(24, ‘h’).asMilliseconds();
  const payload = { userId: user._id };
  jobQueue.addJob(WELCOME_FOLLOWUP_EMAIL_TASK_KEY, {
    delay,
    maxRetries: 3,
    backoff: ‘exponential’
  }, payload);
});

jobQueue.processTask(WELCOME_FOLLOWUP_EMAIL_TASK_KEY, (data) => {  
  const { userId } = data;
  const user = Users.findOne({ _id: userId });
  sendFollowupEmailToUser(user);
});

I left out the necessary ceremonies to set up the task queue. Which can be very straightforward (or not - depends on the queue you’re using).

This approach is robust w/r to server restarting and we’ve “outsourced” the flag-keeping to the job queue itself, i.e., existing pending task means we haven’t sent the email yet. Also - depending on the task queue - we get (limited) retries, possibly with exponential back-off, for free.

You can choose from a number of task queues, here's just a few: Kue, Agenda, IronMQ, JobCollection - if you're into Meteor - or RabbitMQ)

What to look out for with delayed jobs

Mainly two things:

1. Persisted delayed jobs introduce backwards compatibility issues into your system (your server code might have changed since the job was scheduled).

2. If the delayed action is conditional, you need to make sure to check abort-condition when processing the task (e.g. sending invitation reminder only makes sense if the invited user hasn’t joined yet)

With regards to problem #1, to minimise the compatibility issues, you should always pass as little information in the payload as possible and fetch whatever you need when the job executes; e.g., pass document identifiers instead of whole documents. And if you must make breaking changes, start versioning the jobs, either by adding version field to the payload or by modifying the job key itself. Then just wait out till all old-style jobs are gone and clean up your code.

Problem #2 is fairly self-explanatory. If you use a delayed job, you schedule the job for everyone and then you need to check if the job still makes sense when it actually executes. So, e.g., in sendReminder job you need to make sure it still makes sense to actually remind the user at the time the job runs.

Happy scheduling! I’m @tomas_brambora

1. Make. Yourself. Comfortable.

I can't stress this enough. Don't suffer in silence. Or, you know, loudly. Make it your number one priority to stay focused when programming.

Your job is hard. And it is demanding. And there's only so much willpower you can muster each day (and you can only really replenish it by sleeping). Don't allow yourself to be frustrated by things you can fix.

If your build process takes too long, make it a priority to fix that. Use Google! Ask on Stack Overflow. Use Travis or CircleCI to make it trivial to deploy your app. Deploy to Heroku. Make your life easier.

Get a second monitor, a big one with good resolution (I use ASUS PB278Q) and - please! - get yourself a good keyboard (IMO nothing beats Kinesis Advantage). Your eyes and wrists will thank you.

And last but not least - you spend a lot of time sitting. So get a good chair. No, wait, scratch that. Get a great chair! I can recommend Spinalis Hacker - this chair fixed my lower back problems. True story.

2. Learn to stay calm

Seriously. Just calm down. You're writing a web app. People are not going to die if you don't fix it within the next fifteen minutes. All your restless leg syndrome and quiet "fuck fuck fuck" muttering does is stress out your colleagues. Breathe deep.

There's more to life than coding. Make sure you get some perspective. Read books. Travel. Travel anywhere. Travel to a developing country and have a chat with someone who lives on $5 a day. Have a baby. Go skydiving. Anything.

Be passionate about what you do - you should be because, well, programming rocks! - but don't get all OCD about it. It's a marathon, not a sprint.

Or, as Goethe put it: die ganze Arbeit ist Ruhig sein (all the effort consists of staying calm).

3. Read Out of the Tar Pit

This paper is pure gold. Get it here: http://shaffner.us/cs/papers/tarpit.pdf . Then go brew yourself a big mug of tea, sit down and read. And re-read. And then think about how you program and how you deal with state.

4. Learn functional programming techniques

You don't need to drop everything and start using Clojure or Haskell. FP is not a silver bullet; nothing is, really. But what FP will do for you is it will teach you to reason about state and that explicit is usually better than implicit. And that there is beauty in pure functions. And that in most cases, immutable is better than mutable.

Let's face it - web development is kinda like shovelling dirt. You get a bunch of data and you move it around (plus you map it to a different representation that works better for your problem domain). Learn to use map, filter and reduce. Check out lodash, you will most likely want to use it. That said, don't be too cryptic - the goal is to use FP techniques to make your code clear and easier to follow. So don't overdo it. Especially with reduce which is usually the trickiest to understand.

5. Learn to manage code debt

There's nothing wrong with code debt. Yeah, I said it. You see, code debt is pretty much like any other debt - you can use it to your advantage or you can ignore it till it crushes you. You accrue code debt when you need to take a shortcut and move faster than you normally would (for which there are often very much legit reasons). And then eventually you have to slow down and pay back what you've borrowed.

When code debt becomes problematic is when it's not managed. Either because you don't know about it (which is arguably the worst case) or because you were sitting on it for too long and now all you can do is pay the interest. And put in extra time to cut down the debt on top of that.

Every coding project has code debt. It's a fact of programming life. And there's nothing wrong with that. Just be aware of it and do your best to keep it in check.

Incidentally, this is one area where you can really tell apart senior and junior developers. The former are better at judging and managing code debt. It's one of the things that only comes with experience.

6. Use Typescript

Yep. Types are helpful. Refactoring vanilla Javascript is a nightmare (even with unit/integration tests). There's virtually no disadvantage to using Typescript; it's a superset of JS and it's maintained by Microsoft and used in Angular 2 so it's here to stay for the foreseeable future.

That said, Typescript is not perfect; the types are only as good as you - or whoever wrote the definition file you're using - make them and it's just too easy to use the any type (which is essentially telling the compiler to give up). And - at least till Typescript 2.0 - all types are implicitly nullable (yuck!). But anything that helps us write code with less errors counts.

If you have any thoughts, please do leave a comment. I hope you liked my tips and - enjoy coding, guys! It's a great craft.

I'm @tomas_brambora!

> List of commits that have already been cherry picked

I'm a fan of trunk based development, I find it to be a nice way to handle complexity in configuration management.

But it also means I cherry-pick a lot. And so it's pretty useful to know what commits I've already copied onto the target branch.

To do just that, run git cherry -v <target_branch> <source_branch>. Each line beginning with the + sign is a commit that hasn't been picked into target branch (while - means it's there).

> (So Much) Nicer commit graph

git log is boring. And verbose. And uses too much unnecessary whitespace. And I can't see what's where with regards to branches. We can do better. Much better.

Like git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev -commit --date=relative better.

Seriously, try it and you'll never use git log ever again.

> Stored-my-code-in-a-branch-and-forgot-which-one

Now, this happens to me regularly: I implement a new feature in a branch and forget the name immediately. Or definitely the next day. And since there's twenty other (mostly legacy) branches in my git which I haven't merged in and haven't cleaned up because, well, I'm a lazy bum, it's hard to find it again.

This command will list your branches sorted by the last commit's date (starting with the newest one).

git for-each-ref --sort=-committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color: reset))' | less -R

Kudos Jakub Narębski!

> Last minute check before commiting

Super simple but super useful one. Shows the diff at the bottom of the commit message (don't worry, git will strip it for you before storing it). You wouldn't believe how often you can catch a bug just by glancing at your patch right before you commit.

git commit -v

Happy gitting, folks! I'm @tomas_brambora.

However, nothing really comes for free, does it. The problem with reactivity is that unless you do some relatively awkward things, you may easily lose a lot of control over what gets called when in your own code: yes, I'm talking about Blaze's helpers.

Helper functions are reactive by design which means if you reference any reactive data source (such as minimongo cursor) in them, the helpers will be rerun anytime the underlying collection data changes to determine whether the UI should be updated. Speaking from experience, the helpers can run very often. Now, usually this is not a problem because computers have become pretty darn fast lately and the helper queries run in milliseconds so everything works just fine and UI is smooth.

Except sometimes it's not.

If you have a lot of data - and/or big documents - in your minimongo collection, re-runing the helpers can become a massive bottleneck because the minimongo query runs synchronously. Yes, "blocks CPU until finished" synchronously. How bad can it get? Well, let's see an example.

Slow Query

In this gist (the "slow query" section) I'm inserting 1000 documents (sample doc taken from https://www.reddit.com/.json) into an anonymous minimongo collection and then I run a simple query, sort the result using the sort operator and limit the result set to 50. Which is similar to what one could do for example when you want to show a list of posts for a user. Pretty usual stuff.

The results are pretty horrifying.

On my 2015 Macbook Pro the query runs on average in 150 ms. That's CPU blocked for over one eight of a second for a single run of the (hypotetical) helper. Which gets run every time you insert a new document into the collection. Not great, right? How can we do better?

Optimising Minimongo Query

After some experimenting it turns out that the slowest parts of the query is:

1. Sorting the results (which is by Meteor's own admission "laughably inefficient").

2. Retrieving the actual documents as JS objects (looks like minimongo does a lot of EJSON operations on the docs before returning them to you).

Fortunately, we can work around both of those: see the fetch optimised section of the gist. The key to making the query faster is a combination of:

1. Avoiding minimongo's sort implementation in favor of our own (in this case underscore's sortBy).

2. Using minimongo projection to limit what's returned in the result set.

Those two simple changes result in roughly ten-fold speedup in the query execution time (150 ms vs 16 ms on average).

Of course, if we use projection, the result set will not contain the full documents. However, minimongo has an implicit "index" on the _id field (which we already have) and therefore fetching the full document in a helper in a child template will be fast enough (cca 0.2 ms on average which means 0.2 * 50 = 10ms to fetch 50 documents one by one).

Overall, we've just made a speedup from 150 ms to 16 + 10 = 26 ms per query run. Pretty nice, right?

Happy reactive meteoring! I'm @tomas_brambora.

// Make sure foo is closed. 
setTimeout(function () {  
  openNewFoo();
}, 150);

my spidey sense starts tingling. Why? Because coding that way too often leads to "followup" code that looks like this:

// Make sure foo is closed. 
setTimeout(function () {  
  openNewFoo();
}, 150);

// Make sure new foo is open
setTimeout(function () {  
  doBar();
}, 170);

Which is a sure one-way ticket to world full of a pain and a gordian knot of code where timeouts need to run after timeouts that need to run after timeouts. It's like an asynchronous goto.

As a programmer you should always be aware of the order of actions you need to execute. Your aim is to reduce complexity and allow fellow programmers (including future yourself) to reason about your code. This means you should prefer synchronous execution model whenever possible (simply because it's easier to follow).

Timeouts and debounces are an easy way out when you're in trouble because you need to carry out an action after another one or you want to prevent a function from being called too often (e.g. because it's called from two different places) - but more often than not it's the wrong solution. Like treating a symptom instead of the illness.

It's almost always possible to do away with setTimeout and _.debounce. If your code calls the same function from two places in quick succession perhaps those two places need to be more tightly coupled and made aware of each other. If you need to wait until something is rendered on the screen, Meteor offers the Tracker.afterFlush function.

setTimeout

setTimeout really should be reserved for operations that are explicitly time-dependent - such as when you want to run something every five minutes and you don't want to use setInterval (there are many legit cases where setInterval doesn't cut it).

Debouncing

Important point here: your app logic must work without debouncing. Yes, it may be unbearably slow but when you remove the _.debounce calls it must still run correctly. Debouncing is an optimisation, not a fix.

Typical usecases for debouncing are things like handling window resize events or saving editor content when user is typing - generally speaking you use it anywhere where you have to handle lots of events and you can safely ignore some of them plus your app doesn't need to react immediately. If you use _.debounce because for some reason your function is getting called more times than you expect, you're simply doing it wrong.

Happy coding! I'm @tomas_brambora.

Turns out the authors of Git are a forgetful (and smart) bunch too. Which is why there's git update-index and why it has the super-handy --skip-worktree flag. What it does is that it that tells Git "hey, Git, let's pretend I didn't do any changes to this file and also don't track any of its further changes either, OK?" Kind of like a transient .gitignore. You can run it on your config file and stop worrying about accidentally commiting changes that should stay local.

Now, one can immediately see how this can be pretty useful, right? Two obvious questions pop up though:

1. How do I turn this thing off?
2. I forgot what I told Git to forget; how do I tell which files are skipped?

Luckily for us, both have easy enough answers:

1. git update-index --no-skip-worktree <file> will make all the untracked changes appear in Git as modifications again;
2. git ls-files -v | grep '^S' will tell you all the files that have been marked as skipped.

Differences with update index --assume-unchanged

To make things complicated, there are actually two flags to update-index whose task is to prevent Git from tracking changes to a file: --skip-worktree and --assume-unchanged. And people usually seem to know about --assume-unchanged only. What's the difference?

Well, turns out --assume-unchanged has been designed with a different usecase in mind: as a performance optimisation for files that are expensive to calculate diff of (think SDKs). On the other hand --skip-worktree goes the extra mile to prevent you from losing your changes such as when you do a git reset --hard (which can obviously save you from potentially a lot of trouble). You can find a great comparison here.

Happy gitting! I'm @tomas_brambora.

Published Cursor Projection (Server-side)

The benefits of using projection on a published cursor are fairly straightforward; two main use cases here:

• bandwidth optimisation: send less data down the wire
• security: prevent sensitive data from being sent to the client

Nothing to surprise you here.

Minimongo Projection (Client-side)

This is where things get a little more interesting. Obviously, since the data has already been loaded on the client side, we don't have to concern ourselves with network traffic or bandwidth. Similarly, if server is sending any sensitive data, now it's too late to do anything about that. What good can projecting fields do us on the client side then?

A lot, in fact! You see, in my experience Meteor's minimongo makes it quite easy to forget about any optimisations and just fetch whole documents in template helpers. And this is actually fine and convenient in the beginning but it may lead to severe performance problems if your template helpers run expensive queries (because every update of the document will trigger the query to be reactively re-run).

Projection gives us a big win in that if we exclude fields in a cursor in a template helper (or generally in any Tracker.autorun context), Meteor's reactivity will not trigger when the excluded fields change.

var coll = new Mongo.Collection(null);  
coll.insert({who: 'Darth Vader', what: 'father'});

// Set up a reactive callback (projection via `fields` option).
Tracker.autorun(function() {  
  console.log('reactively called');
  coll.find({}, {fields: {who: 1}}).fetch();
});

// Update excluded field.
var item = coll.find().fetch()[0];  
coll.update(item._id, {$set: {what: 'son'}});  
// no log output

// Update included field.
coll.update(item._id, {$set: {who: 'Luke Skywalker'}});  
// "reactively called"

Which means we can only project the fields we actually need in a template helper and we can rest assured our helper will be called when any of those fields are updated but not when other fields change. In other words, we can move reactivity from document level to field level!

In certain - and actually quite common - cases, projecting only a subset of document's fields in reactive contexts will help your app's client-side performance a lot.

Happy reacting! I'm @tomas_brambora.

Use case: subscribing to a list of changes

Imagine you’re implementing an offline-enabled app and have a collection which contains a list of changes since the client last connected. When the client connects, it subscribes to the collection and you start inserting documents which the client drains. Every time it gets a document, it removes it from local minimongo so that the removal is propagated to the database on the server.

Now, say you have a couple hundred documents in your changes collection (for example because the client disconnected before it managed to pull all the changes, so there are some leftovers from the last sync) and you subscribe using something like this:

return changes.find({userId: ‘<myUserId>’});  

Now, I've found when you start generating the documents and pushing them into the changes collection, Meteors CPU and memory usage just skyrockets. I've been monitoring the server with kadira and the memory usage grows from 150MB to 1500MB within a couple of minutes taking the heroku server - which usually runs with 0.5 or 1 GB RAM - down.

Here's a snapshot of my console (memwatch logs):

What happens? Well, hard to say for sure as Meteor's code dealing with data synchronisation is quite complex but my theory is if you are subscribed to a collection and your cursor doesn’t have a limit (meaning everything matching the query is to be sent down the wire), every time you add a new document to a collection, Meteor stores a snapshot of the cursor's contents. Then, when you add a new document, Meteor stores a snapshot of the new set. When you add another one, again. And again and again. With each document added, another chunk of RAM is used. Mind you - this is not a memory leak per se: the memory is eventually freed; there’s just a good chance your server will die before it happens.

How to prevent this? Super easy:

return changes.find({userId: ‘<myUserId>’}, {limit: 10});  

That way, Meteor will only snapshot the first 10 documents in the collection and as the client drains the data, the cursor “window” will move. Memory impact: negligible.

Moral of the tale

Simple enough: always remember to limit your published cursors. Or even better, use some sort of pagination that handles that for you. And use some monitoring tool - such as kadira - to see when the figurative shit hits the fan (pardon my French).

Happy meteoring! I’m @tomas_brambora.

This makes implementing e.g. autosave for contenteditable elements quite annoying - say you're throttling the keypress event and saving every two or three seconds. However, when you save the document to Mongo, reactivity kicks in and the text in contenteditable randomly gets duplicated and/or the caret jumps somewhere (read: the contenteditable is pretty much rendered unusable). Incredibly frustrating.

There's a couple workarounds suggested in the GitHub issue comments but none of them works particularly great - in general they are either too complicated or they have issues with focus getting lost.

Which is why my colleague, Alon, came up with a workaround that is actually quite simple and preserves focus and caret position.

What we need to do is to essentially opt-out from Blaze's reactivity for the contenteditable element. When we save the content, we don't want Blaze to re-render it based on the stored version (which, in case we're throttling the keypress event, will often be behind the actual content). So how do we do that?

The idea is based on the fact that Blaze is trying to do as little work as it can when re-rendering the DOM (because reflows/repaints are expensive). This means that when we use a template helper and its value does not change, Blaze knows it does not need to re-render the corresponding DOM tree...and so it won't.

Now, what we want to do is to persuade Blaze the value of the helper that affects the contenteditable element never changes after it's rendered, i.e., we want to turn it into a constant function. In order to do this, we need to somehow tap into the lifecycle of the relevant Blaze template - lucky for us, Blaze provides a created callback which gets called before anything gets rendered and before any helpers are called.

Which in other words means we can do this:

MyTemplate.created = function () {  
  this.data.__values_override__ = {
    editableContent: this.data.editableContent
  }
};

MyTemplate.helpers({  
  myEditableHelperContent: function () {
    var instance = Template.instance();
    return instance.__values_override__.editableContent;
  }
});

Now we can be sure Blaze will load the contents of the editor from Mongo when the relevant DOM tree is first rendered and that it will then not mutate the content under our hands afterwards (because we've turned the helper into a constant function so Blaze will never try to re-render it).

Pretty? Not particularly. Functional? Very. :-)

Happy meteoring! I'm @tomas_brambora.