Ideas Into Software

Musings on writing code

Ten-fold Query Execution Speedup For Larger Datasets In Meteor

Blaze's reactivity is an incredibly nifty feature of Meteor. It does away with a huge amount of boilerplate code and is mostly really nice to work with. 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

Harmful Timeouts

Whenever I see code that goes like this: // 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

Git Tips: Ignore Changes To a Local File

You know how sometimes when you need to change a flag in a versioned config file, it is just so hard to remember not to do git add ., commit, accidentally push the change and break everyone else's toys? Turns out the authors of Git are a forgetful (and smart) bunch too. Which is why there's git update-index and why it

Fine-Grained Reactivity Via Mongo Projections

MongoDB's find method allows us to specify a projection, i.e., what fields should be included in or omitted from the result set. Meteor, connected to a database on both the server side and client side, can benefit from using projection in two major and different ways. Published Cursor Projection (Server-side) The benefits of using projection on a published cursor

How To Crash Your Meteor Server: Unlimited Cursors

When it comes to determining what goes where from the server, Meteor does some pretty cool optimisations to be fast and effective. Yet, I’ve found in certain special cases - especially if you’re deploying to RAM-tight environments such as Heroku or DigitalOcean - it can be surprisingly easy to kill your server if you’re not a bit

Opting Out of Contenteditable Reactivity in Meteor

It's a sad fact that Blaze (Meteor's reactive UI library) doesn't play particularly well with contenteditable elements. The corresponding ticket in GitHub is marked as closed but the issue itself is unfortunately far from resolved. 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.