Wei's Blog

I was reading a Stackoverflow question about generating short unique identifiers in C# and saw people are using baseline date time and time difference  for ID generation. I really like the idea and wondered how that could be shortened even more. After some attempts, I found it is possible to use a combination of Unix epoch and a counter to make a short unique identifier with only 11 characters. How this works? Unix epoch in C#   is represented as a long 64-bit integer value. Due to the range of DateTime in C#, the first 2 bytes of the 8 bytes of the 64-bit value are always 0. So that gives us 2 bytes to place a counter value in. The best choice here is an unsigned short value, with a range from 0 to 65535, giving us 65536 unique IDs per epoch value. In another word, as long as the number of ID generation does not exceed 65536 per millisecond, this approach should work. The final ID is base64 encoded string representation of the generated long integer. With Base64, 8 bytes

Recently our development team attempted migrating our software architecture to microservices architecture. Despite being the most popular pattern mentioned everywhere, our journey came to the end with a surprising result, that was the team eventually decided to cancel the migration. After one developer from our team wrote a post to share our experience, I also want to share some of my personal opinions about microservices, a term, architecture, or pattern that was so controversial in the team in the last couple months. Engaging microservices The first time the term attracted me was when I saw a post about doing microservices on top of Azure Service Fabric. I absolutely loved the idea of splitting a monolith service into several stateless and stateful services, each of which could be deployed and maintained separately. Shortly after Azure had its Kubernetes and docker hub, I was also amazed how easy it was to build a containerized ASP.Net Core application and deploy it as a microse

This time let's talk about Autofac, probably one of the most popular Dependency Injection container. In the past few months, I have been working on a project in which Autofac is used to provide service instances. In some of the singleton services, I needed to access some request scoped services, so I built a fun type called IScoped<T> to be able to use per HTTP request lifetime to resolve service types. And it works. However, today, when I was building a service in which I needed a list of IScoped<T> , I ran into a problem. One of the cool features that Autofac provides is implicit support for resolving IEnumerable<T> . Say if we register two implementation types as the same interface type, we could resolve an instance of IEnumerable of the interface type to retrieve all instances of both implementations types in one go. That's very cool, isn't it? However, it doesn't work as what I expect when resolving a list of IScoped<T> , where T has mu

So this is the first post in the blog and the topic is interesting. A couple days ago, I did a code review for one of our developers, where I made a comment regarding how tasks are scheduled in ASP.Net applications (not ASP.Net Core). I was saying in the code review that no multiple tasks can run in parallel because of the special AspNetSynchronizationContext . Today I was asked the same question by another developer and later figured out I was not 100% correct. So I decided to spend sometime digging a bit deeper into the magic synchronization context and post what I have found. So the source code of the synchronization context could be found here . For those who are not familiar with synchronization context, I would recommend you read this stackoverflow post before continue reading the rest of the content. To make some tests, I wrote a very simple synchronization context class which schedules tasks using the same way as how AspNetSynchronizationContext schedules tasks: So sim