Tales from the Evil Empire

That one gave me a really hard time, so I have to share… I’m implementing a logging module in a Node application, that uses Winston. The Winston feature that I wanted to test is the exception logging. That proved to be surprisingly difficult, because of conflicting exception handling from Winston and from the test runner.

It has been my experience that the most rewarding communities to work with are open source communities. When you give your time and expertise freely, not everyone may recognize the value that you’re bringing to the table, but enough do. There is no better way for a developer to build a reputation, which eventually converts into more business, and better positions and wages.

As a Node application grows, a modular design where features reside in neatly separated units is a must in order to keep things manageable. Node makes this relatively easy with its package management. For the application as a whole, however, there is little guidance available to help you keep things consistent.

Most code samples that you’ll find, both on the Grunt web site, and on the readme.md for Grunt plug-ins, will tell you to set the configuration using the grunt.initConfig method:

In my series of posts about building fake Orchard content items for testing purposes, here’s a short one that shows how to add tags to a fake content item. This one is interesting because it shows a basic case of relationship (between the item and its tags). The way tags have been implemented (it’s one of the oldest modules in Orchard, and one that should honestly be replaced with taxonomies in almost all cases), in order to add tags, we’ll need to create records for each:

Douglas Crockford has long advocated for relatively unusual object creation patterns that do away with the “new”, and now the “this” keywords altogether. While watching a recent talk that he gave about the better parts of EcmaScript 6, I spotted the evolution of his pattern for the new version of the language. I haven’t found it explained anywhere else so far, so I thought I’d try to deconstruct it in a post…

Sometimes, small improvements can go a long way to making a language more enjoyable. One thing that I seem to feel acutely for some reason is noise. Noise is those parts of the language that –with compiler changes– you could remove without changing the meaning of the program, and without making it less clear. In many cases, removing the noise would actually make the code clearer, because the reader can focus on the meaningful parts without being distracted by the noise.

In previous posts, I’ve shown how to build fake content items, and how to use a fake content manager for testing Orchard modules. In this post, I’ll show how to add fields to a fake content item.