I didn’t intend to do another non technical post, but this was hilarious. My previous post was about taking my daughter to the ice cream shop.

My wife, naturally, wanted to comment on the post. She told me she gave up after failing to complete the CAPTCHA.

I’m not sure if I should be worried about the UX of the blog or upgrade my wife’s firmware.

My daughter is 3​¼ years old now. About the time that she was born, I decided that I needed to make a small change in my language. Whenever I felt the urge to curse, I would say a food’s name. For example, after being puked on, my reaction would be some variant of: “PASTA”, “PASTA BOLOGNESE” or other pasta’s favorites.

As time went by, I got better and better at expressing emotion through increasingly disturbing food references. My current favorite is: “Pasta Bolognese with pickled carrots in a bun with anchovies and raw eggs”.

A couple of days ago, I took my daughter and a friend to an ice cream shop. As expected of an ice cream shop in the middle of (very hot) summer, the place was packed. My daughter was quite excited to go there and expressed her emotions by standing up and shouting at the top of her lungs (she is three, with a voice that carry like a foghorn): “PASTA! PASTA BOLOGNESE” over and over again.

This is a crowded shop, full of small kids and parents. I got some looks for the little girl holding up a full ice cream cone and shouting about pasta, but it was infinitely preferable to the alternative.

An unforeseen side effect, however, is that because I can, I’m very free with pasta based profanities. This had led to what is effectively a competition, with her trying to cause me to go overboard with that.

And now I must go back to work, before the gluten police arrival.

In my previous post, I was asked:

Is it reasonable to look for a developer who knows all the complexities of backend development (Particularly for the enterprise, at least while designing distributed applications or Micro-Services) and expect them to know React, Angular, TypeScript, and many other front-end technologies on the same level?

In my experience, it is absolutely possible to have someone who is fluent in both front end (React, Angular, etc) technologies and backend technologies (databases, k8s, distributed systems, design patterns, etc). I can point at two or three of them without searching too hard. The problem, however, is that while it is possible, it is also rare. The people I have in mind who qualify for the full stack developer moniker are also people with about a decade plus of experience in the field.  And make no mistakes, I don’t include myself in that category. I can use a user interface, but don’t ask me to build one.

For the most part, I see people who exists on a spectrum, and are typically strong in certain areas and have passing familiarity in others. For example, you may have someone who is very strong in building client side user interface and calling back to the server, with some ability to create their own server side endpoints, but without the capabilities to build a full server side solution from end to end. On the other hand, someone who is capable of building the server side, maybe do some client side work, but is stumped on the more complex issues on the client.

Now, I’m speaking in generalizations here, because I’m talking about large segments of developers, not individuals. But this seems to hold true for large swaths of them. It also make sense, there is quite a bit to learn, and you can either be a butterfly and skim through a lot of subjects, or you can dive deeper and become an expert on a few topics.

Either option has its value, but it is important to remember that each also has its costs. If you have dipped your toes into many areas, you don’t usually have the depth to actually handle the more complex and non trivial stuff. For example, I would generally not expect someone who spent most of their time on the client side to be aware of everything that needs to happen for a proper server side caching solution.

When talking about skills in an area, I’m talking about being able to develop, support, debug and maintain such a solution. Everyone can write code in most areas, but it takes effort, skill and knowledge to take a piece of code and turn that into production software.

The term full stack developer is a way to punt. It usually says “I do a little bit here, and little bit there”. There is some meaning here, in the sense that these are the people you’ll turn to when you want to build a full application from scratch. The problem is that they are usually only able to deliver an application that does OK across the board. When you need to do more than OK (and I’m willing to admit that in many cases you don’t), you start to need to specialize. And that takes time, and effort. I would rather the term application developer, rather than full stack. If seems to be more accurate and it doesn’t ping my spider sense about false advertising.

We recently got a CV at the office, from a developer that has about three years of experience as a Full Stack Developer. The CV was… strange, in the sense that I was intimately familiar with all the web technologies in it. This is peculiar, because about five years ago I just threw the gauntlet and stopped even trying to pretend that I have any skills in building anything that is near the front end. And my skills as a front end developers has been atrophying even before that.

I mean, <table> is still how you properly layout things today, as far as I’m concerned. However, in a rare moment of self reflection, I have to admit that I wouldn’t hire myself to do anything related to the browser.

So we have a CV with the following keywords:

• HTML
• CSS
• JavaScript
• Ajax
• jQuery

And that’s a bit suspicious. Oh, certainly these are foundational topics for a front end developer, and I get the need to sometimes pack a CV with keywords for the purpose of matching. However, not having anything else there is strange, and not usually indicative of a good outcome. We gave the candidate a call and talked for a bit, nonetheless. 

It appears that the first job the candidate had after university was maintaining and building an already existing application. The architecture and framework choices were already done and there hasn’t been any pressing need to change them. Therefor, that was what the candidate was used to and familiar with.

So far, this is reasonable story. I can certainly see how this can happen. What I don’t understand is the candidate’s reaction to that.  Sure, the current job may be resistant to changing things. It works, probably reasonable well as far as the current workplace is concerned. And moving to a new technology just because a person want to (literally in this case) pad their resume is a bad idea.

But what about the candidate? At this point, they are actively hunting for a new job. I would expect them to take a look at the market, evaluate their current situation and identify that they are currently working on something that give them no real value for prospective employers. In fact, I would be willing to bet that this is a large part of why this candidate is looking for a new job.

I would expect the candidate at this point to actively work at improving their skills. Spend some time watching Plural Sight videos, build sample applications, go over tutorials, etc. Coming to a job interview and saying something like: “My current job only uses jQuery, but I have been studying React on the side using Plural Sight and here is my GitHub’s sample project showing my progress so far” is amazing. It indicates a lot about the candidate, including the ability to learn and develop oneself on your own.

We aren’t going to go forward with this candidate, but I’m certain that they will be able to find another position in a company where their jQuery skills will be very valuable. However, I don’t expect that they’ll learn anything new in that place, and in 3 years or so, if they will be looking for a new job, they will be in the same exact same place.

On an unrelated note, I have another CV which listed both WinForms and VB6 as core skills.

I recently had a discussion at work about the complexity of modeling data in real world systems. I used the example of a bottle of milk in the discussion, and I really like it, so I thought it would make for a good blog post.

Consider a supermarket that sells milk. In most scenarios, this is not exactly a controversial statement. How would you expect the system to model the concept of milk? The answer turns out to be quite complex, in practice.

To start with, there is no one system here. A supermarket is composed of many different departments that work together to achieve the end goal. Let’s try to list some of the most prominent ones:

• Cashier
• Stock
• Warehouse
• Product catalog
• Online

Let’s see how each of these think about milk, shall we?

The cashier rings up a specific bottle of milk, but aside from that, they don’t actually care. Milk is fungible (assuming the same expiry date). The cashier doesn’t care which particular milk cartoon was sold, only that the milk was sold.

The stock clerks care somewhat about the specific milk cartoons, but mostly because they need to make sure that the store doesn’t sell any expired milk. They might also need to remove milk cartoons that don’t look nice (crumpled, etc).

The warehouse care about the number of milk cartoons that are in stock on the shelves and in the warehouse, as well as predicting how much should be ordered.

The product catalog cares about the milk as a concept, the nutritional values, its product picture, etc.

The online team cares about presenting the data to the user, mostly similar to the product catalog, until it hits the shopping cart / actual order. The online team also does prediction, based on past orders, and may suggest shopping carts or items to be purchased.

All of these departments are talking about the same “thing”, or so it appears, but it looks, behaves and acted upon in very different ways.

Here are the slides from today’s talk.

Subscriptions in RavenDB allow you to build persistent queries, batch operations and respond immediately to changes in your data. You can read more about them in this post, and I have dedicated a full chapter to discussing them in the book.

In RavenDB 4.1 we improved subscription support by adding the ability to include related documents directly as part of the subscription. Consider the following subscription:

The output of this subscription is going to be orders where the geographical coordinates of the subscriptions are not known. We use that to enrich the data by adding the missing location data from the shipping address. This is important for features such as spatial searches, planning deliveries, etc.  For the purpose of this post, we’ll assume that we accept user’s addresses, which do not have spatial information on them and we use a background process to fill them in.

On the one hand, we do want to add the location data as soon as possible but on the other hand, we want to avoid making too many address resolution requests, to avoid having to pay for them. Here is what we come up with to resolve this.

You can see that there are a bunch of interesting things in this code:

• We can access the related company on the order using Load, and it will not trigger any network call.
• If the company already has this address, we can use the known location, without having to make an expensive geo-location call.
• If the company doesn’t have an address, we’ll fill this in for the next run.
• If the company’s address doesn’t have location, only then we’ll make a remote call to get the actual location data.
• We don’t call Store() anywhere, because we are using the session instance from the batch, when we call SaveChanges(), all the changes to the loaded documents (either orders or companies) will be saved as a single transaction.
• Because we update the Location field on the order, we won’t be called again with the updated order, since the subscription filters this.

All in all, this is a pretty neat way to handle the scenario in a very efficient manner.

Queries are one of the most important things you do in RavenDB, and analyzing queries to understand their costs is an important step in many optimization tasks.

I’m proud to say that for the most part, you don’t need to do this very often with RavenDB. Usually the query optimizer just works and give you query speed that is fast enough that you don’t care how this is achieved. With RavenDB 4.1, we made it even easier to figure out what are the costs of the query. Here is a good example:

With the inclusion of “include timings()”, RavenDB will provide you with detailed stats on the costs of the relevant pieces in the query. The output in the studio looks like this:

You can see in a glance exactly how much time RavenDB spent on each part of your query. Armed with that information, you can set out to improve things a lot faster (pun intended).

I’ll be speaking tomorrow at the Sela Developer Practice Conference. I’m going to talk about:

• Staying Friendly with the GC
  
  .Net Garbage Collector is an important factor in improving development efficiency by eliminating the need to manually manage memory.
  But sometimes, it's overhead may cause very long pauses in application execution. In this talk, I will show why this happens and how we can deal with it.
  
  
• Rebooting Design
  
  

This talk will explore how we REBOOTED our Project Design. After a decade of production usage, the RavenDB team addressed a lot of ongoing concerns & changed some of RavenDB's core architecture.
We'll investigate the driving forces behind it, the reasoning process & look at how it all turned out.

We put a lot of effort into making RavenDB’s default setup a secured one. The effort wasn’t so much about securing RavenDB itself although we certainly spent a lot of time on that. Instead, a lot of the work went into making sure that the security will be usable. In other words. If you build a lock that no one can open, that isn’t a good lock, it is a horrible one. No one will use it. Indeed, the chief challenge in the design of the security mechanisms in RavenDB was making sure that they are secure and usable.

I think that we hit the right spot for the most part. You can see that it take barely any effort to setup a secured RavenDB cluster in a few minutes. That works, if you are setting up RavenDB yourself. But what happens when you need an unattended setup? What happen if you are building a Docker container? What happens if you aren’t setting up a single RavenDB instance, but three hundreds of them?

There are ways to handle this, by making sure that you are preparing the certificates and configuration ahead of time. But that is complex, and you still end up with the chicken and egg problem. How do you create a new node securely in such a way that it will know that you can trust it?

The feature itself is pretty small:

--Security.WellKnownCertificates.Admin=a909502dd82ae41433e6f83886b00d4277a32a7b

You can pass this argument as part of the RavenDB command line, in the settings.json file, in a Docker environment variable, etc.

The idea is simple. This tell RavenDB that the certificate matching this well known thumbprint is an administrator. As such, it will be trusted to perform all operations. A simple use case may be spawning three containers with this setting and using the well known certificate to connect them together and create a full cluster out of them.

For automatic deployment, this issue keeps popping up, because setting up properly is hard. We hope that this feature will make things easier.