PasteMonitor is a service I built to improve the monitoring possibilities for paste sites. I worked on and built PasteMonitor in early 2015 and it went live at the end of February. This post covers the technical aspects of PasteMonitor and the technology it runs on. If you haven’t already, you might first wish to read my introduction to PasteMonitor. Overall architecture PasteMonitor is a made up of separate Azure components that work together to drive the functionality behind the user interface.
This week I had intended to post a deep dive into the technical details of how PasteMonitor operates. However, in the middle of writing the first draft, something came up that I thought I should act upon. That thing was the registration process behind PasteMonitor. From the beginning, I had built PasteMonitor on the premise that a user would authenticate themselves with an email address and password. I didn’t question this or consider why, it was just how things go; when a user registers for a service online, they use an email address and password to authenticate, whether directly or through a delegated OAuth system.
I’ve been working with the Azure platform for a couple of years now, yet still feel I’ve barely scratched the surface of available services. One of the areas that I was particularly interested in getting up to speed with was WebJobs. In Azure, a WebJob is a separate process that sits underneath a website and runs either on a trigger (such as a new message in a queue), a schedule (i.
Microsoft’s Azure ‘Websites’ platform as a service is a great way for me to host websites because of how easy it makes monotonous tasks. Even something as obvious as setting up a new website is just a couple of clicks, compared to what might be hours of configuration in other less integrated platforms. One aspect of software development and delivery that I despise is deployment, so anything I can do to mitigate the impact it has upon my working time is a positive.
When deploying a new Azure WebJob direct from git to an Azure Website, my deployment was failing with the message: error MSB4057: The target “ResolveWebJobFiles” does not exist in the project. The unusual thing about this particular message is that searching Google for it yields very few results. The only real clues were in this Twitter conversation and this GitHub gist. The second of these resources isn’t even specifically about this error, but contains a reference to “ResolveWebJobFiles”.
Every November, hundreds of thousands of people get involved in Nanowrimo, where each tries to write a 50,000 novel in a month. The aim is to help wannabe novelists to actually commit something to paper/screen, and as the target is numbers based (1,666⅓ words a day are required to hit the goal). This lends itself to statistics, charting, and competition. Naturally, being about writing and writers, the official Nanowrimo site only provides a limited set of online stats for those who like numbers.
I’ve had a feeling creeping up on me for a while now. It’s a discontentment, a niggling resentment of the code-bases I work in. It’s my fault, and it’s other people’s fault as well. And the problem? Horrible code. I’m talking about working, production code. Code that’s battle proven in the field. Code that I’ve written, that colleagues have written, and that strangers I’ve never known have written, that services the original business requirements it was built for.