Skip to main content


Showing posts from July, 2015

Dev v Ops

When we think about programming, we think about source code. Scenes from the matrix come to mind, with streaming source code everywhere. We think about files, and databases. We think about architecture diagrams and class structures. We think about good practices and code patterns.We rarely think about deploymentAs a developer who has routinely deployed his own applications I know what it means to be in the Operations role. I know that sometimes hardware breaks. Sometimes time-zones are incorrect. Sometimes processors get overloaded. Sometimes (nearly always) your test environment isn’t the same as your production environment. Sometimes permissions break (ACL) or your middleware goes down (IIS) or your infrastructure has to be moved to the cloud (AWS) on the weekend.It’s crazy being an Ops guy. I don’t envy the challenges they face. In fact, I hold their skill in high regard. But that’s not something I see a lot of developers do. In fact, more often than not, due to their …


I needed a wildcard processing tool for an application I was working on.  I didn't want to use regular expressions, because the wildcard values were going in a configuration file, and regex would basically render them unreadable.  So I looked around for a wildcard library for JS and couldn't find a decent one.  In fact, when people asked for one, they generally were told "Learn Regular Expressions".  While I completely agree that knowledge of regular expressions is an incredible boon to a programming career, my response to a problem is not to tell someone it can't be solved, so I wrote a library of may own

Introducing wildstring wildstring does simple wildcard processing without any dependencies.  It works both on the client and in the server, so you can use it anywhere.  wildstring handles wildcard string processing simply.  Here are some examples
wildstring.match('Wild*', 'Wild Thing'); // returns true, because ' Thing' is matched by '…