Polyglot Persistence and Event Store Database

With the advent of polyglot persistence, the rise of specialized databases seemed inevitable. If your system already has more than one database, no reason to stop at just two. I’m interested in working with more different kinds of databases and experimenting with the variety of what is available. I’ve worked with a bunch of different SQL databases, a couple of different document databases, some key value databases and a full text database; I’ve talked about a my experiences with a graph database some before.

I hadn’t tried a spatial database, time series database, columnar database, or an event store database. The spatial database clearly needs a specific kind of data to work, and is good for solving a specific kind of problem. Time series databases also need a specific kind of data, and solve particular kinds of problems so you need to find the right kind of problem to give one a fair shake. Columnar databases seem harder to get a feeling for since it can do most things that a regular SQL database can do, but the performance characteristics are very different. This means you could build a toy system based on one that looks perfectly reasonable, but the real test would be how it performs under load; you would need to try that to understand how it really works. So when I ran across an event store database I felt like it was time to give it a try and better understand what it could do.

Event Store is a database designed to store event data and not do anything else. It doesn’t have any significant search capabilities, and no update or delete. It does have a built in feature to create an atom feed. While I haven’t used the feature, it is an interesting idea. It’s all about event streams and subscriptions.

I worked on a toy project with it and it fit the event store niche well. I can’t say much about its performance and scalability. But it seems designed with those aspects in mind, and due to the limited feature set, outlined above, it can make significant design tradeoffs to accomplish this. The .net client was written with modern features and idioms, which is nice in comparison to a lot of other database libraries that aren’t written with the .net specific features in mind.

I was using it to store events that one microservice was creating, and used it implement web service endpoints that other services could poll to get this event data. You could implement a similar system using a variety of message buses. Compared to a message bus-based design, this particular design means that the consumers need to know more about where the events are coming from, but it also makes it easier for consumers to go back and reprocess historical events. This design also reduces coupling to any particular technology.

Overall my experience with polyglot persistence have been positive. There are a couple of considerations I would suggest if you were looking to do this as well. Any particular piece of data should have one store that is the owner of the data. Other data stores can cache the data for ease of use or performance, but one is always the truth everything else is just a representation. The polyglot persistence approach does ratchet up complexity for getting started, but in the long term it can significantly improve the overall design.


NuGet Conversion part 2

This is a followup to the earlier post on the NuGet conversion I’ve been working on in a large and complex code base. I wanted to give an update on the next round of changes we’ve made.

The first change we put in last time to add a common package checkout location had an unforeseen side effect. There were other teams working to mass convert some old vbscript code to VB.net; they were working on the same developer virtual machine using all of the same database infrastructure as the C# portion of the system, and global NuGet config file change to set the package location also impacted them. They were able to remove it on the VMs they were working on right now, but we needed to remove that from the system in the long term. We found an interesting catch – the config command doesn’t have an option to remove a setting. We briefly considered if there was a value we could set that would be equivalent to what happened if there was no value set, but it wasn’t clear what it would be. We ended up changing the config file as xml manipulation, but it wasn’t as easy as it was to set it in the first place.

The second change was that we switched back to automatic package restore using the hierarchical NuGet config. When the team hosting our internal NuGet server said the url was changing and we needed to update our configuration. We considered updating our several hundred config files with the new url, but instead decided to use this as an opportunity to revisit the decision of how to do the NuGet restore. This time around we got buy in from various groups to change the build processes and switch to automatic package restore.

I used the suggested powershell scripts to do most of the conversion. The conversion went pretty smoothly; I had to make a couple of little tweaks to the version we used since we wanted to totally remove the .nuget folders. The overall process worked out fine. I wish we had pushed harder to do it in the first place.

We still haven’t dealt with the ILmerge problem described last time. So, we still have that open issue to deal with, before we can start using our own packages internally as the primary distribution means.

Pair Programming Interviews

I had an interesting experience with a pair programming interview recently; it was conducted very differently from the other ones I had been on before and I want to explore the differences between them. Pair programming is a great way to solve problems and it makes for a good interview too. As an interview, it gives you insight into the problem-solving process and the social aspect of working with someone. It is a great way to see them do what you want them to do day in, day out.

The ones I had been to before had worked like a normal pairing session. We had a problem and worked together to solve it. Give and take. Since these were interviews I was driving probably two-thirds to three-fourths of the time, not the normal fifty-fifty split you would expect in an on-the-job session. I had always enjoyed the experience.

This most recent experience I had with a pair programming interview was quite different. The partner wouldn’t actively contribute to resolve the problem. If you asked a question they would answer it, but they didn’t drive at all, and didn’t proactively contribute to the task at hand. This was especially confusing in the afternoon session, which was set up to be done in a programming language I had never used before – by design. I think it was actively trying to push the applicant out of their comfort zone and see how they would react.

It was an interesting experience, and I got to learn a little ruby programming. I would definitely do another pair programming interview. But I feel like I would react against this sort of pseudo-pairing vocally if presented with this again. If that’s how they pair, I wouldn’t be interested in the job. If it’s a behavioral test, I wonder what sort of day-to-day activities they are engaging, if this is the kind of test they think would give them good information. The whole experience turned me off during the interview.

If you haven’t done any pair programming grab a partner and give it a try. Pair programming is a lot of fun, and helps you solve programs in a new way. If you already pair program regularly consider adding it to your interview circuit, but really treat it as a normal pair programming session.

Recruiters and Jobs


In the DC area, tech recruiters seem to be a fact of life. Late January into February always seems to be a very active season. The manner in which jobs are presented by recruiters makes me wonder about the state of the industry. Maybe it’s a DC thing, but I get calls offering 3- or 4-month contract work a couple times a month, offering really low rates. I don’t mean low for my experience level but low compared to cost of living. I’m trying to understand who is offering or taking these contracts.

There is the old adage that everyone hires the top 1% or 0.5% of programmers. Does that mean that 99% of programmers are no good? Not at all, the same people who are not employed currently are out there sending out resumes and staying in the market. It means that there are all the same people out there spamming any job opening. If you think about the inverse there are those jobs out there that everyone passes on, the job equivalent of those programmers who nobody is interested in. These jobs nobody is interested would be these odd contracts.

The different kinds of jobs are for different kinds of people. But sometimes it seems like the recruiters forget that there is a symbiotic relationship between the developers and the recruiters. For example today I got two calls from the same agency about the same job I wasn’t interested in hearing about. The second knew I had talked to the first recruiter and seemed intent on trying to address the reasons I told the first recruiter I wasn’t interested rather than extolling the benefits of the job.

The relationship between developers and recruiters needs a better defined rulebook. The current rules seem to be defined by the low end of the spectrum, where there is enough money to be made moving people around and putting butts in seats. I ran across a blog post about what recruiters should know about reaching out to software developers, and it resonated  with me. It described the issues I had seen where the recruiters just seemed to be offering the same job over and over. Do you have 10+ years of experience with Java EE, spring, bootstrap and jquery? Nothing about what you would be building, nothing about why you should want this job. Just that it’s there and you should want it since it is something.

The recruiters need to sell the job, and understand the uniqueness of that job compared to the other jobs in their current portfolio. This requires a lot more effort on the recruiter’s end to start with, but the longer-term payoff would be much more valuable. You develop a longer-term relationship with the clients and I know I would appreciate that sort of interest in what I wanted as opposed to a person calling me on a keyword match on a resume. My realtor has a stronger relationship with me than most of these recruiters are interested in. Expect better and you might just get it. I’ve had a recruiter send a handwritten card to try and stand out from the pack, and it worked. I read that card and thought to myself ‘This is a unique opportunity thought out for me.’

It will take a long time to get rid of recruiter season due to how it ties into budget cycles. But it would be nice to be respected as a person, rather than placed as a resource. I’ve asked some recruiters that called recently and given a weak pitch of a job, and I told them as much. The best thing you can do is to put direct feedback into the system. If they consistently hear that people want more than a three sentence description of the technical needs they’ll hopefully have something more valuable than that.