Archives
-
Some asynchronous JavaScript weirdness
I feel a little silly about the time it took me to find that bug, but it’s a fairly typical one, so it’s worth sharing. While writing a test case for an asynchronous operation, execution of my code would seemingly magically skip over a whole bit of code and jump directly to the assertions at the end of my test case. It looked really bizarre, as if JavaScript didn’t want to run my test code, and I suspected a bug in the debugger for a brief moment. Of course, that was just me not spotting the obvious bug I had written a few minutes earlier. But let me show you some simplified code that demonstrates the issue...
-
Exception Catch 22
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.
-
Giving a few thanks
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.
-
Grunt in a modular application
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.
-
Use grunt.config.merge
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:
-
Tagging a fake Orchard content item
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:
-
Crockford’s 2014 object creation pattern
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…
-
Can we make commas optional in JavaScript literals?
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.
-
Adding fields to a fake Orchard content item
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.
-
Stubbing the Orchard content manager
I’ve shown in the previous post how to build fake content items for testing purposes. When the code being tested gets content items from the content manager, however, you will also need a stub for the content manager, so your code receives fake content items that you have prepared, and not real ones from the database.
-
Faking Orchard content items for testing
When testing Orchard modules, it’s often necessary to build fake content items that will be usable by your code, but won’t be database-bound. For this purpose, I’ve built a number of stubs and helpers over the years that enable most scenarios to work using fake content items. Because everything in Orchard is based off interfaces and dependency injection, mocking is rarely necessary, and a few good stubs are often all you need.
-
Unit tests are to testing…
Developing good software at a large scale requires the collaboration of several disciplines, that are not, contrary to your boss’ opinion, interchangeable. You need developers, of course, but you also need designers, PMs, QA, writers, usability people, localization, pointy-haired bosses, etc. There has been a tendency in some companies, however, to try to get developers to do more and more beyond coding, or even to magically transform test engineers into developers.
-
Node pitfalls 3: this is not the file you want
In Node, each module has its own copy of its dependencies, under its own node_modules directory. Each of those modules in turn can have its own dependencies under its own node_modules, and so on, in matryoshka doll fashion. This is not a bad way to deal with dll hell: module A can depend on a specific version of module B, and cohabitate within the same application with other modules that depend on another version of module B.
-
ASP.NET v.next’s killer features are already here
ASP.NET v.next is definitely an interesting beast. It’s open-source, developed in the open, and the team has clearly studied the competition, Node.js in particular, very closely. Its killer features, however, the ones that may be hardest to reproduce by others, are not new features: we already have them.
-
Node pitfalls 2: lingering responses
One of the main appeals of Node is how it encourages asynchronous code. You may very well write synchronous code in Node, but if you do, you’re not going to reap the benefits, and you should probably use another platform. I’ll talk in another post about some of the challenges associated with JavaScript asynchronous code, but there is one specific consequence that made me trip more than a couple of times while I was learning Node: it is very easy to create wrong expectations about when or whether a specific callback will get called, and then things can go really bad.
-
My TechEd Europe talk on Orchard is online
I spent a lot of time on planes last week (which explains why I haven’t posted anything), on my way to Barcelona, where Microsoft had invited me to talk on the .NET Open Source Showcase. It was a great experience and opportunity, and I hope I did justice to Orchard in the time I had to present it. I focused on what makes Orchard a success story, and how to reproduce that success on other open source projects.