Paneque's Technology Blog

A cache is a component where data is stored so that future requests can be served faster. So for example, in the context of a web application responding to multiple requests,  instead of hitting your backend database or microservice every time, the application can remember the last value for a given computation or call. One particular flavor is a centralized cache system, provided by tools like Redis, Memcached, etc. A central place where we store data temporarily and all instances of our app (and even other apps) can use it. There are many uses, from storing session data in a multi-server web application to providing a performance advantage by keeping a value that is costly to calculate or obtain.  A centralized cache is a lifesaver. But it tends to be overused and there are some scenarios where we could reduce its usage or completely skip it, and in doing so, save costs and improve performance.  Reducing the usage of the centralized cache. Let's have an example of a web...

Quite too often we see discussion about what is and what is not REST, some developers excitedly discuss about REST purity. However, does it actually matter? Do you need that level of "purity"? I personally think that it does not and will try to explain why, although I am already convinced that will fail on my attempt. REST means REpresentational State Transfer, and while almost everybody will tell you that is not necessarily  related to HTTP (and technically isn't), in reality, it is, and that's a fact. So when we apply it to our Web Services, we have our new REST APIs or RESTful APIs mixed with HTTP flavors. Also consider that they do not conform a protocol, or a specification, is an architectural style. So, technically, they are a set of conventions and guidelines and not an actual set of unbreakable rules (like a protocol).   But they are great, RESTful, REST-like, almost RESTful APIs are all great. I have been writing and playing with APIs since aroun...

Well, initially I might get upset, but only if they break something. But here I am not talking a team member changing your code... No... that's OK This blog entry is about that 'non-deterministic' behavior that sometimes happens to 'us' while developing software and all of the sudden something does not work as it 'should' be. Who does not hate that kind of bugs right? This example is a real case scenario using Telerik components in a web application. Consider the following piece of ASPX code, I have placed a button and a label, the button 's click event in code-behind event will change the value of the label. Pretty simple right? Just a button with a javascript confirmation dialog before performing the page's post back. Now lets 'ajaxify' this... Using the new ajaxified code now have pretty much same effect, except we are not performing a full page post back, but only updating elements inside the UpdatePanel control. But what if I...

When deploying and testing websites that use secure connections (SSL)  we might get warnings about non secure content on the page. This is usually an easy thing to fix. Just find a tool like "Fiddler" and find out what traffic is going over a regular HTTP (non secure) channel. Sometimes even a simple FIND over the code will let you find those "unsecured" elements. But that's not enough if you refer some javascript or refer a link over SSL that then does some non-SSL redirection.  Each browser has a similar way to show you how secure you are on a website. Google Chrome shows website security indicators (icons) that will appear next to your site URL in the toolbar. The first one (1) is just a regular site with no SSL, and we want number (2) the green one, you should avoid the other ones. Now two notes on that. Google Ads Don't use Google Adsense on your website if you use SSL and you care about your site not showing any warning, the ads will b...