The blog of
  • Pie in the Sky-Hole [A Pi-Hole in the cloud for ad-blocking via DNS]
    Monday, August 24th 2015

    Inspired by Marco Arment's recent post about blocking advertisements on the web, I decided to explore the same idea. However, while Marco focuses on the annoyance of advertisements, I am interested in the security benefits of removing them. There have been numerous incidents of otherwise respectable websites compromising the security of their users due to the advertisements they include. Searches for "web site hacked 'ad network'" on Google and Bing provide some examples; another is this XSS attack on Troy Hunt's site, which is interesting thanks to the detailed analysis Troy provides. Popular sites of all kinds have been compromised in this way, and one might argue they should be treated as attackers because of the approach used to serve third-party ads.

    Marco's article describes an in-browser solution for ad-blocking, but I prefer something that automatically protects all the machines on my network (at least, while they're using the network; see below). So I set out looking for something that works at the network level and came across Pi-Hole, a DNS-based ad-blocker for the Raspberry Pi. Aside from the fact that I don't own a Pi, this seemed like exactly what I wanted. ;)

    Fortunately, there are no actual dependencies on Pi hardware, so I decided to create my own Pi-Hole on a server in the cloud - thus the name "Sky-Hole". To do so, I opened the Microsoft Azure Portal, created a small virtual machine running Ubuntu Server 15.04, and configured it according to the manual instructions for Pi-Hole (with a few customizations outlined below). Then I updated my wireless router to use Sky-Hole as the DNS server for my home network - and all my devices stopped showing advertisements!


    I used a minimal set of steps to configure the Sky-Hole and list them below so they're easy to reproduce. I made a couple of tweaks to the Pi-Hole process along the way and explain them in turn.

    First, create a virtual machine to run everything on (I've used both Microsoft Azure and Amazon Web Services, but any provider should do). Then, install dnsmasq:

    sudo apt-get -y install dnsmasq
    sudo update-rc.d dnsmasq enable
    sudo mv /etc/dnsmasq.conf /etc/dnsmasq.orig
    sudo nano /etc/dnsmasq.conf

    Configure dnsmasq.conf as follows (replacing "sky-hole" on the last line with the host name of your virtual machine):


    The addn-hosts option is meant to be optional, but I needed it because /etc/hosts was not updated by The host-record option was necessary to avoid a "sudo: unable to resolve host" error which showed up whenever I enabled dnsmasq. (Though this may be an artifact of the default virtual machine configuration under Azure.)

    Update 2015-08-30: host-record was similarly necessary on AWS, where the automatically-assigned host name was of the form ip-123-123-123-123.

    Now, download the Pi-Hole script and run it to generate the list of domain names to block:

    sudo curl -o /usr/local/bin/
    sudo chmod 755 /usr/local/bin/
    sudo /usr/local/bin/
    sudo sed -i "s/^[0-9\.]\+\s/ /g" /etc/pihole/gravity.list

    The last line is my own and replaces the virtual machine's IP address with an unusable address when redirecting undesirable sites. Because I'm not running a web server on the Sky-Hole, this seems like a more appropriate way to block unwanted domain names. (Besides, hostname -I in Azure reports the virtual machine's internal address which is on a private network.)

    Restart dnsmasq to apply the changes:

    sudo service dnsmasq restart

    Now, test things locally via ping, dig, nslookup (or similar) to verify that desirable domain names are returned as-is and undesirable ones are blocked by returning the IP. Assuming that's the case, update the virtual machine to accept incoming UDP traffic on port 53 (per the DNS specification) and test again from a different machine. If everything is working as expected, configure your router to use the Sky-Hole's public IP address for DNS resolution. This automatically applies to all devices on the local network and avoids the need to update each one manually.

    Update 2015-08-30: You may also want to enable TCP traffic on port 53 (per RFC 5966).

    Congratulations, you're done!


    • The nice thing about this approach is that it covers all the machines on your network. However, it can only protect machines when they're connected to that network. Taking a phone or tablet elsewhere or using cellular data exempts a device from this kind of protection.
      • So this may be an argument in favor of per-device ad-blocking - though perhaps as a strategy to be used in addition to (rather than instead of) a network-wide approach.
    • When creating the virtual machine, I used the Basic A1 size which would cost about $34.97 per month on Azure (though I don't plan to leave it running very long).
      • I tried the A0 size first (which would have cost $13.39 per month on Azure), but it ran out of memory building the domain list, seemingly due to this known issue.
    • As I note above, I chose not to configure a local web server on my Sky-Hole. While doing so offers interesting benefits, it didn't seem compelling for the purposes of this experiment and I preferred to keep thing simple. Should you choose to, directions are available in the Pi-Hole documentation.
    • If you end up using Pi-Hole like this (or on its own) please consider donating to the author, Jacob Salmela, to help support his work.


    I'm only been running Sky-Hole for a couple of days, but the usability and performance improvements for some sites are quite noticeable. More importantly, it seems to me the browsing experience is necessarily safer by virtue of removing not just a subset of traffic, but the subset which is most likely to contain unwanted content.

    As an experiment and a learning experience, Sky-Hole has been a successful side-project. I hope others find it interesting or thought-provoking and I welcome comments on improving or enhancing the approach!

    Tags: Miscellaneous Technical Web
  • Not romantically binding [promise-ring wraps Node.js callbacks with native ES6 Promises]
    Monday, July 20th 2015

    JavaScript Promises are a powerful way of working with asynchronous code. They make sequencing operations easy and offer a clear, predictable way to handle errors that might occur along the way. Much has been written about the benefits of Promises and I won't try to repeat it here.

    What I do hope to do is make Promises a slightly more natural part of the Node.js development experience. In version 0.12.* (as well as in io.js), ES6 Promises are natively available. But the standard set of modules (such as File System) still use their original callback-based design and there's a bit of a disconnect between how you might want to write something and how you're able to. Fortunately, most of the Promise libraries that are already available include wrappers to convert callback-based functions into ones that return a Promise. However, most of those libraries assume you'll be using their custom implementation of Promise (from the "olden days" when that was the only option). And while different Promises/A+ implementations are meant to be interoperable, it seems silly to pull in a second Promise implementation when a perfectly good one is already available.

    That's where promise-ring comes in: it's a tiny npm package that provides functions to convert typical callback-based APIs into their Promise-based counterparts using the V8 JavaScript engine's native Promise implementation. Briefly:

    promise-ring is small, simple library with no dependencies that eases the use of native JavaScript Promises in projects without a Promise library.

    Documentation is available in the README along with runnable samples demonstrating the use of each API. It's all quite simple and exactly what you'd expect. A bonus feature is the wrapAll function which makes it easier to work with modules that expose many different callback-based functions (such as the File System module; see below).

    For an example of using promise-ring and Promises to simplify code, here is a typical callback-based snippet to copy a file onto itself:

    var fs = require("fs");
    // Copy a file onto itself using callbacks
    fs.stat(file, function(err) {
      if (err) {
      } else {
        fs.readFile(file, encoding, function(errr, content) {
          if (errr) {
          } else {
            fs.writeFile(file, content, encoding, function(errrr) {
              if (errrr) {
              } else {
                console.log("Copied " + file);

    And here's the same code converted to use Promises via promise-ring:

    var pr = require("promise-ring");
    var fsp = pr.wrapAll(require("fs"));
    // Copy a file onto itself using Promises
      .then(function() {
        return fsp.readFile(file, encoding);
      .then(function(content) {
        return fsp.writeFile(file, content, encoding);
      .then(function() {
        console.log("Copied " + file);

    The second implementation is more concise, easier to follow, and DRY-er. That's the power of Promises! :)

    Find out more by visiting promise-ring on GitHub or promise-ring in the npm gallery.

    Tags: Node.js Technical
  • Lint-free documentation [markdownlint is a Node.js style checker and lint tool for Markdown files]
    Tuesday, May 12th 2015

    I'm a strong believer in using static analysis tools to identify problems and catch mistakes. The Node.js/io.js community has some great options for linting JavaScript code (ex: JSHint and ESLint), and I use them regularly. But code isn't the only important asset - documentation can be just as important to a project's success.

    The open-source community has pretty much standardized on Markdown for documentation which is a great choice because it's easy to read, write, and understand. That said, Markdown has a syntax, so there are "right" and "wrong" ways to do things - and not all parsers handle nuances the same way (though the CommonMark effort is trying to standardize). In particular, there are constructs that can lead to missing/broken text in some parsers but which are not obviously wrong in the original Markdown.

    To show what I mean, I created a Gist of common Markdown mistakes. If you're not a Markdown expert, you might learn something by comparing the source and output. :)

    Aside: The Markdown parser used by GitHub is quite good - but many issues are user error and it can't (yet) read your mind.


    You shouldn't need to be a Markdown expert to avoid silly mistakes - that's what we have computers for. When I looked around for a Node-based linter, I didn't see anything - but I did find a very nice implementation for Ruby by Mark Harrison. I don't tend to have Ruby available in my development environment, but I had an itch to scratch, so I installed it and added a couple of rules to Mark's tool for the checks I wanted. Mark kindly accepted the corresponding pull requests, and all was well.

    Except that once I'd tasted of the fruit of Markdown linting, I wanted to integrate it into other workflows - many of which are exclusively Node-based. I briefly entertained the idea of creating a Node package to install Ruby then use it to install and run a Ruby gem - but that made my head hurt...


    So I prototyped a Node version of markdownlint by porting a few rules over and then ran the idea by Mark. He was supportive (and raised some great points!), so I gradually ported the rest of the rules to JavaScript with the same numbering/naming system to make it easy for people to migrate between the two tools. Mark already had a fantastic test infrastructure and great documentation for rules, so I shamelessly reused both in the Node version. Configuration for JavaScript tools is typically JSON, so the Node version uses a slightly different format than Ruby (though both are simple/obvious). I started with a fully asynchronous API for efficiency, but ended up adding a synchronous version for scenarios where that's more convenient. I strived to achieve functional parity with the Ruby implementation (and continue to do so as Mark makes updates!), but duplicating the CLI was a non-goal (please have a look at the mdl gem if that's what you need).

    If this sounds interesting, please have a look at markdownlint on GitHub. As of this writing, it supports the same set of ~40 rules that the Ruby implementation does - you can read all about them in Mark's fantastic markdownlint exposes a single API which can be called in an asynchronous or synchronous manner and accepts an options object to identify the files/strings to lint and the set of rules to apply. It returns a simple object that lists the items that were checked along with the line numbers for any violations. The documentation shows of all of this and includes examples of calling markdownlint from both gulp and Grunt.


    To make sure markdownlint works well, I've integrated it into some of my own projects, including this blog which I wrote specifically to allow authoring in Markdown. That's a nice start, but it doesn't prove markdownlint can handle larger projects with significant documentation written by different people at different times. For that you'd need to integrate with a project like ESLint which has extensive documentation that's entirely Markdown-based.

    So I did. :) Supporting ESLint was one of the motivating factors behind porting markdownlint to Node in the first place: I love the tool and use it in all my projects. The documentation is excellent, but every now and then I'd come across weird or broken text. After submitting a couple of pull requests with fixes, I decided adding a Markdown linter to their test script would be a better way to keep typos out of the documentation. It turns out this was on the team's radar as well, and they - especially project owner Nicholas - were very helpful and accommodating as I introduced markdownlint and tweaked things to satisfy some of the rules.


    At this point, maybe I've convinced you markdownlint works for my own purposes and that it works for some other purposes, but it's likely you have special requirements or would like to "try before you buy". (Which seems an ironic thing to say about free software, but there's a cost to everything, so maybe it's not that unreasonable after all.) Well, I have just the thing for you:

    An interactive markdownlint demo that runs in the browser!

    Although browser support was not (is not!) a goal, the relevant code is all JavaScript with just one dependency (that itself offers browser support) and only two methods that need polyfills (trimLeft/trimRight). So it was actually fairly straightforward (with some help from Browserify) to create a standalone, offline-enabled web page that lets anyone use a (modern) browser to experiment with markdownlint and validate arbitrary content. To make it super easy to get started, I made some deliberate mistakes in the sample content for the demo - feel free to fix them for me. :)


    In summary:

    • Markdown is great
    • It's easy to read and write
    • Sometimes it doesn't do what you think
    • There are tools to help
    • markdownlint is one of them
    • Get it for Ruby or Node
    • Or try it in the browser
    Tags: Node.js Technical Web
  • Extensibility is a wonderful thing [A set of Visual Studio Code tasks for common npm functionality in Node.js and io.js]
    Thursday, April 30th 2015

    Yesterday at its Build conference, Microsoft released the Visual Studio Code editor which is a lightweight, cross-platform tool for building web and cloud applications. I've been using internal releases for a while and highly recommend trying it out!

    One thing I didn't know about until yesterday was support for Tasks to automate common steps like build and testing. As the documentation shows, there's already knowledge of common build frameworks, including gulp for Node.js and io.js. But for simple Node projects I like to automate via npm's scripts because they're simple and make it easy to integrate with CI systems like Travis. So I whipped up a simple tasks.json for Code that handles build, test, and lint for typical npm configurations. I've included it below for anyone who's interested.

    Note: Thanks to metadata, the build and test tasks are recognized as such by Code and easily run with the default hotkeys Ctrl+Shift+B and Ctrl+Shift+T.



      "version": "0.1.0",
      "command": "npm",
      "windows": {
        "command": "npm.cmd"
      "tasks": [
          // Build task, Ctrl+Shift+B
          // "npm install --loglevel info"
          "taskName": "install",
          "isBuildCommand": true,
          "args": ["--loglevel", "info"]
          // Test task, Ctrl+Shift+T
          // "npm test"
          "taskName": "test",
          "isTestCommand": true
          // "npm run lint"
          "taskName": "lint",
          "args": ["run"]

    Updated 2015-05-02: Added --loglevel info to npm install for better progress reporting

    Tags: Node.js Miscellaneous
  • Solving puzzles at 30,000 feet [An iterative solution for the "Is this a binary search tree?" programming problem]
    Tuesday, April 7th 2015

    Sitting on a plane recently looking for a distraction, I recalled a programming challenge by James Michael Hare: Little Puzzlers-Is Tree a Binary Search Tree?. All I had to work with was a web browser, so I used JavaScript to come up with a solution. James subsequently blogged a recursive implementation in C# which is quite elegant. Wikipedia's Binary search tree page uses the same approach and C++ for its verification sample.

    Because I did things a little differently, I thought I'd share - along with a few thoughts:

     * Determines if a tree of {value, left, right} nodes is a binary search tree.
     * @param {Object} root Root of the tree to examine.
     * @returns {Boolean} True iff root is a binary search tree.
    function isBinarySearchTree(root) {
      var wrapper, node, stack = [{ node: root }];
      while (wrapper = stack.pop()) {
        if (node = wrapper.node) {
          if ((node.value <= wrapper.min) || (wrapper.max <= node.value)) {
            return false;
          stack.push({ node: node.left, min: wrapper.min, max: node.value },
                     { node: node.right, min: node.value, max: wrapper.max });
      return true;


    • Tree nodes are assumed to have a numeric value and references to their left and right nodes (both possibly null).
      • I used the name value (vs. data) because it is slightly more specific.
    • I decided on an iterative algorithm because it has two notable advantages over recursion:
      • In the worst case for a tree with N nodes, an iterative solution has bookkeeping for N/2 nodes (when starting to process the leaf nodes of a balanced tree assuming nodes were queued) whereas a recursive solution has bookkeeping for all N nodes (when processing the deepest node of a completely unbalanced tree).
        • Because there are two recursive calls, I don't think tail recursion can be counted on to fix the worst-case behavior.
      • The memory used for bookkeeping by an iterative solution comes from the heap which is generally much larger than the thread stack.
      • To be fair, neither advantage is likely to be significant in practice - but they make good discussion points during an interview. :)
    • The iterative algorithm has a disadvantage:
      • Bookkeeping requires an additional object type (wrapper in the code above) which associates the relevant min and max bounds with pending node instances.
        • ... unless you avoid the wrapper by augmenting the node elements themselves.
          • ... which is quite easy in JavaScript thanks to its dynamic type system.
        • The creation/destruction of wrapper objects creates additional memory pressure.
          • Although these objects are short-lived and therefore low-impact for typical garbage collection algorithms.
    • I intended the code to be concise, so I made use of assignments in conditional expressions.
    • The code uses a stack (vs. a queue) because stacks tend to be simpler than queues - especially when implemented with an array.
    • I made use of the fact that comparing a number to undefined evaluates to false so I could avoid specifying explicit minimum/maximum values (as in the Wikipedia example) or making HasValue checks (as in James's example).
    • If you have a different approach or a suggestion to simplify this one, please share!
      • And note: I'm interested in algorithmic changes, not tweaks like removing extra parenthesis. :)
    Tags: Miscellaneous Technical
  • Supporting both sides of the Grunt vs. Gulp debate [check-pages is a Gulp-friendly task to check various aspects of a web page for correctness]
    Tuesday, February 10th 2015

    A few months ago, I wrote about grunt-check-pages, a Grunt task to check various aspects of a web page for correctness. I use grunt-check-pages when developing my blog and have found it very handy for preventing mistakes and maintaining consistency.

    Two things have changed since then:

    1. I released multiple enhancements to grunt-check-pages that make it more powerful
    2. I extracted its core functionality into the check-pages package which works well with Gulp


    First, an overview of the improvements; here's the change log for grunt-check-pages:

    • 0.1.0 - Initial release, support for checkLinks and checkXhtml.
    • 0.1.1 - Tweak README for better formatting.
    • 0.1.2 - Support page-only mode (no link or XHTML checks), show response time for requests.
    • 0.1.3 - Support maxResponseTime option, buffer all page responses, add "no-cache" header to requests.
    • 0.1.4 - Support checkCaching and checkCompression options, improve error handling, use gruntMock.
    • 0.1.5 - Support userAgent option, weak entity tags, update nock dependency.
    • 0.2.0 - Support noLocalLinks option, rename disallowRedirect option to noRedirects, switch to ESLint, update superagent and nock dependencies.
    • 0.3.0 - Support queryHashes option for CRC-32/MD5/SHA-1, update superagent dependency.
    • 0.4.0 - Rename onlySameDomainLinks option to onlySameDomain, fix handling of redirected page links, use page order for links, update all dependencies.
    • 0.5.0 - Show location of redirected links with noRedirects option, switch to crc-hash dependency.
    • 0.6.0 - Support summary option, update crc-hash, grunt-eslint, nock dependencies.
    • 0.6.1 - Add badges for automated build and coverage info to README (along with npm, GitHub, and license).
    • 0.6.2 - Switch from superagent to request, update grunt-eslint and nock dependencies.
    • 0.7.0 - Move task implementation into reusable check-pages package.
    • 0.7.1 - Fix misreporting of "Bad link" for redirected links when noRedirects enabled.

    There are now more things you can validate and better diagnostics during validation. For information about the various options, visit the grunt-check-pages package in the npm repository.


    Secondly, I started looking into Gulp as an alternative to Grunt. My blog's Gruntfile.js is the most complicated I have, so I tried converting it to a gulpfile.js. Conveniently, existing packages supported everything I already do (test, LESS, lint) - though not what I use grunt-check-pages for (no surprise).

    Clearly, the next step was to create a version of the task for Gulp - but it turns out that's not necessary! Gulp's task structure is simple enough that invoking standard asynchronous helpers is easy to do inline. So all I really needed was to factor out the core functionality into a reusable method.

    Here's how that looks:

     * Checks various aspects of a web page for correctness.
     * @param {object} host Specifies the environment.
     * @param {object} options Configures the task.
     * @param {function} done Callback function.
     * @returns {void}
    module.exports = function(host, options, done) { ... }

    With that in place, it's easy to invoke check-pages - whether from a Gulp task or something else entirely. The host parameter handles log/error messages (pass console for convenience), options configures things in the usual fashion, and the done callback gets called at the end (with an Error parameter if anything went wrong).

    Like so:

    var gulp = require("gulp");
    var checkPages = require("check-pages");
    gulp.task("checkDev", [ "start-development-server" ], function(callback) {
      var options = {
        pageUrls: [
        checkLinks: true,
        onlySameDomain: true,
        queryHashes: true,
        noRedirects: true,
        noLocalLinks: true,
        linksToIgnore: [
        checkXhtml: true,
        checkCaching: true,
        checkCompression: true,
        maxResponseTime: 200,
        userAgent: 'custom-user-agent/1.2.3',
        summary: true
      checkPages(console, options, callback);
    gulp.task("checkProd", function(callback) {
      var options = {
        pageUrls: [
        checkLinks: true,
        maxResponseTime: 500
      checkPages(console, options, callback);

    As a result, grunt-check-pages has become a thin wrapper over check-pages and there's no duplication between the two packages (though each has a complete set of tests just to be safe). For information about the options above, visit the check-pages package in the npm repository.


    The combined effect is that I'm able to do a better job validating web site updates and I can use whichever of Grunt or Gulp feels more appropriate for a given scenario. That's good for peace of mind - and a great way to become more familiar with both tools!

    Tags: Node.js Technical Web
  • Everything old is new again [crc-hash is a Node.js Crypto Hash implementation for the CRC algorithm]
    Tuesday, January 27th 2015

    Yep, another post about hash functions... True, I could have stopped when I implemented CRC-32 for .NET or when I implemented MD5 for Silverlight. Certainly, sharing the code for four versions of ComputeFileHashes could have been a good laurel upon which to rest.

    But then I started using Node.js, and found one more hash-oriented itch to scratch. :)

    From the project page:

    Node.js's Crypto module implements the Hash class which offers a simple Stream-based interface for creating hash digests of data. The createHash function supports many popular algorithms like SHA and MD5, but does not include older/simpler CRC algorithms like CRC-32. Fortunately, the crc package in npm provides comprehensive CRC support and offers an API that can be conveniently used by a Hash subclass.

    crc-hash is a Crypto Hash wrapper for the crc package that makes it easy for Node.js programs to use the CRC family of hash algorithms via a standard interface.

    With just one (transitive!) dependency, crc-hash is lightweight. Because it exposes a common interface, it's easy to integrate with existing scenarios. Thanks to crc, it offers support for all the popular CRC algorithms. You can learn more on the crc-hash npm page or the crc-hash GitHub page.


    • One of the great things about the Node community is the breadth of packages available. In this case, I was able to leverage the comprehensive crc package by alexgorbatchev for all the algorithmic bits.
    • After being indifferent on the topic of badges, I discovered and its elegance won me over. You can see the five badges I picked near the top of on the npm/GitHub pages above.
    Tags: Node.js Technical Web
  • Out of hibernation [A new home and a bunch of updates for TextAnalysisTool.NET]
    Monday, January 12th 2015

    TextAnalysisTool.NET is one of the first side projects I did at Microsoft, and one of the most popular. (Click here for relevant blog posts by tag.) Many people inside and outside the company have written me with questions, feature requests, or sometimes just to say "thank you". It's always great to hear from users, and they've provided a long list of suggestions and ideas for ways to make TextAnalysisTool.NET better.

    By virtue of changing teams and roles various times over the years, I don't find myself using TextAnalysisTool.NET as much as I once did. My time and interests are spread more thinly, and I haven't been updating the tool as aggressively. (Understatement of the year?)

    Various coworkers have asked for access to the code, but nothing much came of that - until recently, when a small group showed up with the interest, expertise, and motivation to drive TextAnalysisTool.NET forward! They inspired me to simplify the contribution process and they have been making a steady stream of enhancements for a while now. It's time to take things to the next level, and today marks the first public update to TextAnalysisTool.NET in a long time!


    The new source for all things TextAnalysisTool is: the TextAnalysisTool.NET home page

    That's where you'll find an overview, download link, release notes, and other resources. The page is owned by the new TextAnalysisTool GitHub organization, so all of us are able to make changes and publish new releases. There's also an issue tracker, so users can report bugs, comment on issues, update TODOs, make suggestions, etc..

    The new 2015-01-07 release can be downloaded from there, and includes the following changes since the 2013-05-07 release:

    2015-01-07 by Uriel Cohen (
    * Added a tooltip to the loaded file indicator in the status bar
    * Fixed a bug where setting a marker used in an active filter causes the
      current selection of lines to be changed
    2015-01-07 by David Anson (
    * Improve HTML representation of clipboard text when copying for more
      consistent paste behavior
    2015-01-01 by Uriel Cohen (
    * Fixed a bug where TAB characters are omitted in the display
    * Fixed a bug where lines saved to file include an extra white space at the
    2014-12-21 by Uriel Cohen (
    * Changed compilation to target .NET Framework 4.0
    2014-12-11 by Uriel Cohen (
    * Redesigned the status bar indications to be consistent with Visual Studio and
      added the number of currently selected lines
    2014-12-04 by Uriel Cohen (
    * Added the ability to append an existing filters file to the current filters
    2014-12-01 by Uriel Cohen (
    * Added recent file/filter menus for easy access to commonly-used files
    * Added a new settings registry key to set the
      maximum number of recent files or filter files allowed in the
      corresponding file menus
    * Fixed bug where pressing SPACE with no matching lines from filters
      crashed the application
    * Fixed a bug where copy-pasting lines from the application to Lync
      resulted in one long line without carriage returns
    2014-11-11 by Uriel Cohen (
    * Added support for selection of background color in the filters
      (different selection of colors than the foreground colors)
    * The background color can be saved and loaded with the filters
    * Filters from previous versions that lack a background color will have the
      default background color
    * Saving foreground color field in filters to 'foreColor' attribute.
      Old 'color' attribute is still being loaded for backward compatibility
    * Changed control alignment in Find dialog and Filter dialog
    2014-10-21 by Mike Morante (
    * Fix localization issue with the build string generation
    2014-04-22 by Mike Morante (
    * Line metadata is now visually separate from line text contents
    * Markers can be shown always/never/when in use to have more room for line text
      and the chosen setting persists across sessions
    * Added statusbar panel funnel icon to reflect the current status of the Show
      Only Filtered Lines setting
    2014-02-27 by Mike Morante (
    * Added zoom controls to quickly increase/decrease the font size
    * Zoom level persists across sessions
    * Added status bar panel to show current zoom level


    These improvements were all possible thanks to the time and dedication of the new contributors (and organization members):

    Please join me in thanking these generous souls for taking time out of their busy schedule to contribute to TextAnalysisTool.NET! They've been a pleasure to work with, and a great source of ideas and suggestions. I've been really pleased with their changes and hope you find the new TextAnalysisTool.NET more useful than ever!

    Tags: Technical TextAnalysisTool Utilities
  • Casting a Spell✔ [A simple app that makes it easy to spell-check with a browser]
    Thursday, December 4th 2014

    I pay attention to spelling. Maybe it's because I'm not a very good speller. Maybe it's because I have perfectionist tendencies. Maybe it's just a personality flaw.

    Whatever the reason, I'm always looking for ways to avoid mistakes.

    Some time ago, I wrote a code analysis rule for .NET/FxCop. More recently I shared two command-line programs to extract strings and comments from C#/JavaScript and followed up with a similar extractor for HTML/XML.

    Those tools work well, but I also wanted something GUI for a more natural fit with UI-centric workflows. I prototyped a simple WPF app that worked okay, but it wasn't as ubiquitously available as I wanted. Surprisingly often, I'd find myself on a machine without latest version of the tool. (Classic first world problem, I know...) So I decided to go with a web app instead.

    The key observation was that modern browsers already integrate with the host operating system's spell-checker via the spellcheck HTML attribute. By leveraging that, my app would automatically get a comprehensive dictionary, support for multiple languages, native-code performance, and support for the user's custom dictionary. #winning!

    Aside: The (very related) forceSpellCheck API isn't supported by any browser I've tried. Fortunately, it's not needed for Firefox, its absence can be coded around for Chrome, and there's a simple manual workaround for Internet Explorer. Click the "Help / About" link in the app for more information.


    Inspired by web browsers' native support for spell-checking, I've created Spell✔ (a.k.a. SpellV), a simple app that makes it easy to spell-check with a browser. Click the link to try it out now - it's offline-enabled, so you can use it again later even without a network connection!

    To import content, Spell✔ supports pasting text from the clipboard, drag-dropping a file, or browsing the folder structure. For a customized experience, you can switch among multiple views of the data, including:

    • Original text (duh...)
    • Unique words, sorted alphabetically and displayed compactly for easy scanning
    • HTML/XML content (including text, comments, and attributes)
    • JSON content (string values only)
    • JavaScript code comments and string literals

    Read more about how Spell✔ works, how it was built, or check out the code on the GitHub page for SpellV!

    Tags: Technical Utilities Web
  • A quick programming challenge with money [Counting and enumerating the ways to break a $1 bill]
    Tuesday, December 2nd 2014

    Sunday evening I happened across a blog post by Josh Smith about finding all the ways to break a $1 bill. Specifically, the goal is to:

    Count the number of ways to combine coins worth 100, 50, 25, 10, 5, and 1 cent for a total value of 100 cents

    As Josh says, it's a fun challenge and I encourage you to stop reading now and solve it!

    Seriously: Stop now. Spoilers ahead...

    I took his advice and sat down with pen, paper, and a self-imposed 30 minute time limit. I came up with the C# solution below just before time ran out. As I note in the code, I forgot one line (though I caught it when typing up the solution). Less embarrassingly, this implementation worked correctly the first time I ran it. What's more, it's flexible with regard to the target amount and number/value of the coins (both of which are passed as parameters to the constructor). For bonus points, it outputs all the combinations it finds along the way.

    I've added some comments to the code to outline the general algorithm. There are some opportunities to refactor for clarity and an implicit assumption values are passed in decreasing order, but otherwise I'm pretty happy with how it turned out.

    If you take on the challenge and come up with something interesting, please leave a note - I'd love to see other approaches!


    using System;
    // Problem: Count (and output) all ways to make $1 with U.S. coins (100, 50, 25, 10, 5, 1 cents).
    // Inspiration:
    class BreakADollar
        public static void Main()
            // Entry point/test harness
            Console.WriteLine("Total possibilities: {0}",
                new BreakADollar(
                    new[] { 100, 50, 25, 10, 5, 1 })
        // Input
        private readonly int _target;
        private readonly int[] _values;
        // State
        private readonly int[] _counts;
        private int _ways;
        public BreakADollar(int target, int[] values)
            // Initialize
            _target = target;
            _values = values;
            _counts = new int[values.Length];
            _ways = 0;
        public int Invoke()
            // Start the recursive process and return the result
            Recurse(0, 0);
            return _ways;
        private bool Recurse(int i, int sum)
            if (_target == sum)
                // Met the target, done here
                return false;
            else if (i == _counts.Length)
                // Out of values, keep looking
                return true;
            else if (sum < _target)
                // Search, using increasing counts of current value
                while (Recurse(i + 1, sum))
                    _counts[i]++; // Note: Missed this line at first
                    sum += _values[i];
                // Reset and continue
                _counts[i] = 0;
                return true;
                // Exceeded the target, done here
                return false;
        private void ShowCounts()
            // Show the count for each value
            for (var i = 0; i < _counts.Length; i++)
                Console.Write("{0}:{1} ", _values[i], _counts[i]);
    Tags: Miscellaneous Technical