Paneque's Technology Blog

 In previous articles, we've stressed the importance of caching to enhance the performance of our applications. This time, we're discussing a small yet potent tip to further amplify the benefits derived from caching. A standard caching routine often looks like this: This code is 'functional' and can be regarded as the 'default' approach to caching. Here, we're fetching a value from the cache, and if it's missing, we generate it and store it for future requests. However, a problem arises when we deal with a high-traffic application, such as a .NET Core web application or API, which must handle many concurrent requests. Suppose multiple requests reach this code simultaneously, each finding that it needs to generate the value. In such a case, you'll experience "multiple" refreshes of the same value and several calls to SetValue. To prevent this, we can employ a mutual-exclusion (mutex) lock to restrict multiple threads from accessing the sam...

The words distributed and monolith are usually adversaries in software architecture, contrary to the monolith model,  a distributed approach will allow you to have isolated services as building blocks of functionality for your system. Let's assume you reached that architecture already, either from scratch or by decomposing an existing monolith. At this point you have a set of services.  Some people go and just say - "it's microservices!". Well..., that's not enough yet, but now you have all the pieces into individual services and the whole system working together.  This is a step into the right direction for scalability, but we can do more in other areas.  So, let's check: how do you deploy them ? If you deploy all services at once , you still have a lot to improve, for now you have a "distributed monolith" (Open to a better name for this), which I consider to be an antipattern, and this is more of a common practice than expected,...

I have published apps and games for Microsoft Windows Phone, and I update them in a regular basis. Most of the time is because a bug is found, sometimes is a new feature or just because I am trying something new. It helps to keep things moving and people thank you for that. However, I never had to protect an app or a game from human stupidity. Until now . Software developers learn  over time how to deal with the final user - in some measure - and I must admit is not easy; as programmers we are not trained to deal with them, is usually another person's job. But when it comes to phone/tablet apps, that individual is you, because as an 'indie' developer you are too close to the complete production line. I classify the users like this: The happy mute The unhappy mute The fan The hater The stupid The mute ones... There are always people that either like or don't like your app or website, or tool, but they just don't say anything. This is good and b...

App is the new black, everyone talks about downloading, buying or selling apps, advertising about them is everywhere. The phone manufacturers have marketplaces and stores where phone users can get get those "apps". We all know the term app is short from application. If this term was coined because was easier or because of a marketing strategy I don't know. But it is catchy, and so we will use it. But to be exact on term, int this case it means "mobile application". Otherwise any program would be an app right? But exactly what is an "app",  really ?  Third-party programs running on mobile is not something new at all, for  more than 10 years we had Java Midlets for almost any kind of cell phone, and I myself programmed for years for the Pocket PC and Windows Mobile, using either eVC, eVB, and later any .NET language like C# or VB.NET by using the .NET Compact Framework (.NET CF). And all those were actually apps . So, if is not new, why the boom...