Tales from the Evil Empire

Philip asked an interesting question on the DecentCMS forums: “are there plans to allow for theme settings”? That is a great question, and I’m happy to report that the system already allows for it, that I was able to verify that it works, and that it was ridiculously easy.

The default mechanism to store content items in Decent CMS is to use files under the /sites directory. This can be replaced with database storage, of course (the first provider I’ll implement after the file-based one will be CouchDB), but the file storage has some unique advantages. While it’s obviously not something you’d use on a big site, being able to xcopy contents, and deploy contents with a simple ftp client is very powerful. Being able to look into folders and find content items as single files that can be modified with a simple text editor is extremely comfortable.

Identity is a funny thing. It’s one of those concepts that we use all the time, but that are tremendously difficult to pin down precisely. To keep things “simple”, in philosophy and in physics, it’s about equivalence relations. In computer science, I’d say it’s more like a bijection between two categories of objects. The difficulty is that you can only approximate real identity this way: by definition, an object is only identical to itself. What we call identity in code really is a proxy for identity, a substitute for it that usually takes less bits to represent than the object itself. The difficulty when building an identity algorithm is twofold: you need to be able to deterministically extract an id from an object, and the id needs to be different when the objects are different. In other words, same yield same ids, and distinct yield distinct ids. Of course, this can be made more complicated with mutable objects. The constraints are in fact very close to those of a good hashing algorithm.

The content type system in Orchard is one of the reasons for its great flexibility. The ability to build your own content types from building blocks that are just the right size is essential to building a great CMS. Orchard has content types that are made of content parts, that can have properties and fields. Parts are aspects of a type, such as title, comments, or body, that there can be only one of per type. Fields are named, and there can be any number of each type of field per content type. Confused yet? There’s a reason for all this, of course, but in DecentCMS, I’ve opted for a simplified version.

There are a few things that nobody should ever do. One of these things is to write a new CMS. So about four months ago, I decided to write a new CMS using Node.js. It’s called DecentCMS, and I’ve had insane amounts of fun building it so far.

After all these years, JavaScript still occasionally trips me up. Today, I built a test that was failing mysteriously. I use Chai to write my assertions, and that particular test was failing to agree that the array I had constructed was deeply equal to its theoretical value. WebStorm’s test tooling has a diff visualization for deep object or array equality, and this was showing the arrays as equal:

I’ve been asked what my take was on the new Raspberry Pi 2, in particular about the newly announced Windows 10 support. The previous versions of the Raspberry Pi have been tremendously successful, and sold close to 5 million units, which is not surprising considering how capable this little board is for only $35. The new iteration is basically a much welcome upgrade of the CPU and memory over the original specifications from three years ago. The rest of the board is unchanged from this summer’s B+ model, which means that almost all accessories, including cases, should work. It’s a little disappointing that the hardware upgrade would be so limited: USB3 and/or SATA would have taken care of the problem that an SD card is not the reliable storage solution that’s needed for write-intensive data acquisition applications. The price is unchanged, however, so it remains one of the most inexpensive boards on the market.

If there’s a class that’s caused Orchard users more confusion, bugs, and disappointment than Repository<T>, I’d like to know about it… Generic repositories are a well-known anti-pattern, something that the designers of the Orchard data layer were fully aware of, but decided to use anyway as helpers in the implementation of this piece of code that bridges Orchard’s runtime dynamic type system to nHibernate’s database mappings. The class should arguably have been made internal or private (which is something you won’t hear me say every day), but it wasn’t, and now we’re stuck with it until we get to redesign that part of the platform.

Orchard 1.9 is just around the corner (don’t ask me exactly when it will be out, instead go and help with the remaining high priority bugs), and if you own existing Orchard modules, now is a really good time to test them against the latest 1.x build. You should be mostly fine as the new version doesn’t introduce significant breaking changes (that we know of), but there is one thing that you may have to do nonetheless to build a compatible version of your code. Orchard 1.9 will bump up its .NET Framework dependency to 4.5.1. As a consequence, if your modules are compiled against an earlier version of the framework, and take dependencies on assemblies such as Orchard.Core or Orchard.Framework, which are now built on the updated framework, Visual Studio will refuse to build your module.