My Blog

Choosing the right cache software for your web application is not an easy job. The first and most important question that you have to ask yourself is if you actually need a cache in your application. But what exactly is a cache and how an application can profit or not from its use?

A cache is a software component that is used for storing data in memory (RAM) in order to provide faster accesses to this data. Using a cache you can save time and I/O operations, since you do not access the data stored in other slower types of storages such as relational databases or XML files in a hard disk drive.

Most of the cache implementations provide a simple key-value storage, where the key is unique in the cache. The value can be then extracted by using the unique key. The type of the value can be from a simple primitive value (boolean, string, number) to a complex object. In both type-cases you have to serialize the key-value pair and most of the times store it a simple string in the cache (continue reading for more information about serialization and deserialization).

The ES6 specification of JavaScript and of course the TypeScript language, provide us the template literal syntax (the `` characters). With the template literals we can write multiline strings in JavaScript without having to use the old syntax. Take a look at the following example:

    var testString = "Lorem ipsum dolor sit amet, \
            \nconsetetur sadipscing elitr, \
            \nsed diam nonumy eirmod tempor \
            \ninvidunt ut labore et dolore";
 

If you use the Google Webmasters for your webpage then you most probably have seen the Mobile Usability page under the Search Traffic menu. In this subpage Google lists for you CSS, HTML or SEO errors that have to do with the mobile version of your website. One of the most common errors that is listed there is the Content wider than screen error.

When working in an application which is divided into multiple architectural layers, it is often the case that the developers of a team do not trust the data their function get in one layer from a function in the same or in an another layer. For that reason they often add null checks (very common in C#) or in JavaScript’s case they add if (variable) {...} checks (implicit cohersion of values in an if clause) in order to catch an error before it happens and avoid breaking the execution of the code.

But is it that bad for a function to fail or is it that bad for your application to throw an exception when something did not go as it is supposed to go?

With this article I like to post my thoughts about TypeScript and some of the advantages of the language that I use on my everyday programming tasks.

1. Types, types, types

Who does not know or have not implemented code like the following in JavaScript:

    var person = {
        firstname: "Christos",
        lastname: "Monogios"
    };
    
    // Lines of code...
    
    person.skills = ["TypeScript"];
    
    console.log(person);