Running Apache Solr 6.5 on an Azure App Service instance

This post describes a daring way to attempt to deploy a single Solr node to an Azure App Service. I say daring because I could not find a copy paste solution on Stack Overflow. I saw some light at the end of the tunnel after reading the Upload a custom Java web app to Azure article on Azure documentation which mentions Jetty and since Solr is running in a Jetty Servlet container by default I guessed I should at least give it a try. Read More…

FileOptions Enumeration, Windows Cache Manager and Memory-Mapped Files (C#) Part 1

Because working with files is such a common and potentially expensive operation, every operating system introduces numerous levels of indirection when serving I/O requests. This is necessary in order to execute I/O operations in a reasonable time frame. But managing complexity through abstraction of various hardware and software layers that interact during file operations also has its disadvantages: you get a false impression that you don’t need to know what is really going on under the hood :)

I needed to optimize a part of my code that was writing data to random locations in a binary file. After realizing that FileOptions.RandomAccess does not automagically do the trick and make seeks (in a loop!) run noticeably faster, I started to dig into the FileOptions Enumeration. A couple of days later, bursting with knowledge on internal working of Windows Cache Manager and speeding up random writes using Memory-Mapped Files I decided to write a two part blog post about it.

Read More…

Keep your Mercurial revision history clutter free

I have been using Mercurial revision control system as a weapon of choice for quite some time now. For controlling changes made to source code, as for backing up to a private repository hosted at Bitbucket I used the basic commands for committing, adding, pushing and pulling files to/from the local /remote repository on a daily basis. And that was sufficient for my needs….until recently. I stumbled upon an interesting blog post titled “Segregate your commits into tiny topical changes” that made me think of how my current revision history on a project looks like…

Read More…

Refactoring a spaghetti C# serial communication app & asynchronous control flow modeling with async/await

A couple of months back I’ve got a task of implementing a protocol for an embedded device sending/receiving streams of data through serial communication. Together with this task I also inherited a Windows Forms C# application that already did some of the previous but in a different protocol with a different device. The more I struggled to understand and reuse some of the existing infrastructure, the more I wanted to rewrite the whole thing (sounds familiar?).

Some facts about existing code:

  • Each scenario was implemented as a complex state machine with long switch statements.
  • For each scenario a heavy weight enum with all possible states was defined.
  • State machine transitions were implemented with a table of Action delegates paired with already mentioned enumerations in a key/value dictionary.
  • Events were used to signal status of long running operations.

Such code was really hard to read and even harder to maintain. And if you don’t have the documentation for the device’s programming interface it’s all even harder.

In this post I’m trying to solve two things:

  1. How to design a more robust flexible issue/response system used for communicating with the serial device.
  2. How to model complex asynchronous control flows, without blocking, using Task Parallel Library and C# 5.0 async/await.

Read More…

Prevent large file commits with PowerShell and Mercurial hooks

Because of Mercurial’s immutable historical record of project files there is no way to make a committed file completely disappear from the history tree. Our only hope in this case it’s not Obi-Wan but the hg rollback command if we act quickly. Since this command only works for one most recent operation (How to keep a Mercurial repository small?) it will not work if we already committed one or more changes after the change that we would like to completely remove (Accidentally committed a large amount of raw data in Mercurial, how do I keep it from overloading my Bitbucket repository?). Our problems escalate even faster if we already pushed or pulled changes to a remote repository and our bad commit propagated to other collaborators.

Two most common cases of brown paper bag commits (a commit that is so bad you want to pull a brown paper bag over your head) are accidentally committing sensitive information files (passwords, connection strings…) and large files. The latter case is less critical because it only increase s repository size and the time it takes to perform operations like pull or clone.

If you are interested in how to prevent yourself from committing large files and are more comfortable with PowerShell then please read on. If you are more of an indentation than squirrely brackets guy then you can check this similar solution in Python - Mercurial hook to disallow committing large binary files.

Read More…