• First foray with PixiJS

    As I mentioned in a previous post, my wife plays this colour-by-numbers game that has a simple user experience but charges a high subscription price for content. That didn’t seem appropriate for what it was, but it seems the colour-by-numbers space suffers from price inflation. My theory is that they pay artists or moderators to produce the artwork. If that isn’t the case i don’t see how the price could be justified (£15-20 a month).

    I’m not an artist myself, I may have a little artistic flair, but not skilled enough to produce original artwork to the required pedigree. Instead I will lean on algorithms and machine learning to source royalty-free images and transform them into colour-by-numbers canvases.

    The first step for me is to get into building the application to allow a user to colour-by-numbers. This will help me to decide what format the source artwork needs to be in order to render efficiently on a mobile device.


  • Exchange 2013 - not a bitwise exclusion

    A few months ago I was implementing a bug fix involving Exchange integration. Our product supports Exchange 2010SP2 and above, so modern(ish). We leverage Exchange Web Services (EWS) to perform operations on a user’s mailbox. One such operation, and related to the bug being fixed, requires a search for items that have a specific flag set.

    The MessageFlags field is the most common of these, so if I want only read messages I would perform a search that restricts results to items that have the read bit set.

    Unfortunately EWS only supports an exclusion bitflags operation which is documented as “a bitwise AND that will match only if the result is 0”. So if we want to filter by read (i.e. The bit is set) we cannot use exclusion alone.

    Fortunately EWS also supports NOT, which matches items if and only if the inner expression did not match.

    So a query that looks like this NOT(EXCLUDES(READ)) should suffice.

    And it does, for the most part… applying the same logic we saw strange results - notably Exchange 2010 and 2016 were working as expected, but Exchange 2013 was not doing what we expected. In fact it was doing the opposite!


    Exchange 2013 => not a bitwise exclusion:

    • 2010 passes
    • 2013 fails
    • 2016 passes

    Cause - 2013 is “optimising” the query and performing a negated bitwise AND rather than performing the bitwise AND and then negating the result.


  • Why you need a framework, possibly (opinion)

    The big caveat here is that the project has to be at least complex enough that static HTML or simple JavaScript won’t suffice.

    If you are faced with a project that has a definite shelf life of under a couple of years then you probably want to use a framework. Otherwise you may want to think carefully about when and how to use a framework.


  • Why no framework can be the best framework (opinion)

    The JavaScript ecosystem is fragmented. That’s not a bad thing. It does make life difficult when trying to decide what framework(s) to leverage in new and existing projects. You don’t want to be locked into a framework that becomes stale while your project is actively developed for a variety of reasons (I plan on another post to describe situations when you might not want to care).

    There was a sizable movement towards micro-frameworks to alleviate some of the issues with lock-in, but also to make things more focused and maintainable. Of course that also has its downsides. However, there still remains many more complete do-it-all frameworks or popular combinations of frameworks. Some frameworks appear to be modular, but in reality you’re probably going to end up using all the modules together anyway.

    The problem is when you have a long-running project you need a framework that is stable and will remain maintained and stable as you continue to use it. You may worry about choosing a certain combination of frameworks because you can’t be sure they will continue to exist and aren’t just some current fad in the fast moving world of npm packages.

    Or you could think about what is critical project code and what is not. Then avoid leaning on frameworks for your core critical code.


    Use an appropriate framework, but keep your core business logic out of a framework (or use a simple in-house framework).


  • What happened to indcht?!

    The short answer is nothing. I realised that such a broadly scoped project was far too much for a half hour a day train journey.

    I started coming up with ideas for indcht, outlining what subsystems would be required - database, authentication, real-time message distribution, session management, caching and so on. The thing is that each of those is complex and even using a library like passport for authentication still leaves a lot of work to join it all together. In the end indcht just has too much scope.

    So I regrouped and instead focused on one interesting part and then moved on to look at smaller-scope things that might take a few weeks at a time.


    Instead of indcht I built:

    • A couple of Microsoft Orleans .NET core projects that represent a real-time group chat with connected client sessions.
    • A static-site generated version of my CV using metalsmith
    • A CV builder that takes markdown and a CV layout described in React with server-side rendering to produce a static CV
    • The start of a colour-by-numbers game built with pixi.js


  • Announcing indcht - a team-based communication toy project

    So I was hoping to make a more interesting post this month, but having been struck down with a debilitating case of flu I didn’t make as much progress as I had hoped. However, I will introduce what I’m working on!


    I’m starting work on a toy project called indcht (“inched”) which stands for Indescrible Chat.

    The synopsis is that indcht will be a team-based chat system akin to Slack or RocketChat.

    It will begin life as a toy project to explore a non-trivial and interesting realm with tools, patterns and practices that I would like to leverage more.


  • Help! My Awesome Webpack Configuration Isn't Building Incrementally!

    This is a story about how a fairly complex Webpack configuration failed horribly and started building far more modules than it should do for incremental builds.


    There are a few reasons a module may be rebuilt unnecessarily:

    1. You changed a file accidentally (even if you deleted the change and saved)
    2. The name/path of the file being imported does not match the name/path of the file on the file system (case sensitive!)
    3. The loader you use has a bug :O

    A module being rebuilt affects all of the modules that depend upon it transitively.

    It ultimately comes down to whether the Webpack cache contains a dependency and whether that dependency was last modified after the last build time.

    You can find out by running webpack-dev-server with debugging using:

    node --inspect node_modules/webpack-dev-server/bin/webpack-dev-server.js

    This will give you a URL to throw into Chrome like this:

    Debugger listening on port 9229.
    Warning: This is an experimental feature and could change at any time.
    To start debugging, open the following URL in Chrome:

    Then navigate to NormalModule and breakpoint with a condition !ts here.

    When you hit this breakpoint it signals that the currently executing module is going to be rebuilt because the current file has been modified or could not be found. Check that the file is normalized (uses forward slashes) and is correctly cased to the import in the executing module. You can find out the executing module and therefore which file to look at for the matching import by inspecting the locals and the value of this.

    Resolve the issue either by fixing the normalization (which may only be possible by fixing the loader) or the path. If the breakpoint isn’t hit or the names and paths are all good then something else is not working as it should - sorry, this post won’t help :(


  • 2017 - the quest to start something

    Howdy to anybody reading this blog, this is where it starts.

    I have wanted to start a blog for a few years, but I didn’t for a number of reasons. However, I now have 2 toddlers running around the house and that has made me realise that I’m not young anymore.

    Of course age is relative, but I decided that this year would be the year that I actually publish something.

    I have spent a decidedly large amount of my time studying - school and university and I am always learning. I believe to be really good at something you have to continually learn and strive to do so.

    I read countless technical blogs, follow the latest advancements in the technologies I use day to day and make sure that I’m watching what’s trending on github.

    This means that I am exposed to all these amazing people who contribute so much to the developer community while seemingly maintaining a healthily balanced life. I wonder much of the time how do they do it?

    Over the last year I started to contribute back to projects that I use at work, where previously I might find a workaround or write an in-house module I now fix the problem in the project and submit a pull request when I can. Many have been accepted and merged and of course some sit that and are ignored. That doesn’t so much matter to me, the point is that I am contributing back to the projects and people that have made my life easier.

    It’s early days into 2017 yet, but I hope that I can continue the trend I have started; continue to contribute to open source projects and to this blog. There are plenty of moments when I have solved a problem and thought perhaps I should tell the world how to fix it and save somebody else a headache. Instead of doing that I have moved onto another problem that demands my attention and by the time I’m at home that desire to publish my findings has faded.

    I think this is a feeling shared by many developers, often you do not have the privilege of blogging in work hours or do not have the time to do so. Yet all the while the problems you have solved may need solving again by somebody else in the world and you could have helped them, as I am sure that you have been helped by a blog or a tweet or a github issue.

    Will somebody else encounter the problems I’ve faced? Will they read this blog and find the solution? Maybe. Even if nobody reads this, the process of writing down a problem and how you solved it can enhance your understanding of it and of your own strengths and weaknesses.

    Obviously I hope that somebody somewhere does find it helpful!

subscribe via RSS