Pages

Saturday, May 11, 2019

Problems of the 'new' keyword

How do we create an object in most languages? It's by using the 'new' keyword and there's a big problem lurking in there! Some languages of-course skip it, like Python, where you can create an instance of class just by doing 'ClassName()' instead of 'new ClassName()' but the underlying problem remains the same.

The new keyword causes our codes to get coupled.

Let's take this simple example:

interface IShape
{
  public string Name { get; }
}
class Square : IShape
{
  public string Name { get; private set; }
  public Square()
  {
    Name = "Square";
  }
}
class Circle : IShape
{
  public string Name { get; private set; }
  public Circle()
  {
    Name = "Circle";
  }
}
class ShapeHolder
{
  public IShape Shape { get; private set; }
  ShapeHolder()
  {
    shape = new Square();
  }
}

If we see the above example, even though we have used an interface 'IShape', our ShapeHolder is now tightly coupled to the Square instance. It can never ever hold an instance of a circle. This may seem fine but this causes two major problems:
  1. Unit Tests: There's no way to test ShapeHolder independently of Square class. Any test written for ShapeHolder would end up working with a concrete instance of Square class. If Square class was modified later to start using network access or a db call, unit tests of ShapeHolder may start failing or take up huge amounts of time, as the testing environment won't have the necessary setups.
  2. Extensibility: The above code doesn't show run time polymorphism. In future if a new shape comes in, which must work with the ShapeHolder class, we will have to modify the ShapeHolder class too. This may in-turn cause some other class to be modified. This is a violation of open closed principle.
The main way to solve this is to use Dependency Inversion. Instead of ShapeHolder being responsible for creating the Square class, it should be passed in to the class, either via the parameter of the constructor or using something like the Factory design pattern. Now at runtime we can change which IShape type is being held by the ShapeHolder. For unit tests, this can be a simple MockShape class.

Friday, May 10, 2019

Space Based Architecture





Like CQRS (Command Query Responsibility Segregation), this architecture is used for high scalability and performance.
In a typical setup there is usually a client, an application server and a database. Whenever load increases, we can increase the number servers handling the client requests, once we fix that we soon find that the application server handing all the business logic is now the bottleneck. Once we scale that up we are pass the bottleneck on to the database.
Unlike the previous layers, scaling up the database is very tough. Databases are not really meant to be scaled. Sure, there are solutions out there which try to address this, but it’s difficult and expensive.
This pattern tries to address that bottleneck – the database. In this architecture, there are 5 components:
  1. Processing Unit
  2. Middle ware
    1. Message grid
    2. Data Grid
    3. Processing Grid
    4. Deployment Manager
The processing unit is the component which houses the business application. Its complete with it’s own persistence store (the database) and is self sufficient.
Message Grid is responsible for orchestrating the various requests from client to the different processing units.
Data Grid: It’s responsible for keeping the data in sync within all the individual persistence stores in the processing units.
Processing Grid: Often the request is split between multiple processing units to get even better throughput. Processing grid is responsible for this.
Deployment Manager: As the load increases, it’s responsible for spawning up more processing units. Similarly when the load decreases, it’s responsible for getting the number of processing units down.
The reason why this architecture effectively solves the database bottleneck problem is that in this solution there is no common repository. Every processing unit has it’s persistence store. So the database never becomes a bottleneck here.
Also, as the load increases/decreases, the system scales accordingly.
So, both CQRS and Space Based Architecture support scalability by having multiple instances of the databases. The Space Based Architecture scales the system dynamically based on the load, however, with this additional power comes the additional complexity. If the load fluctuates a lot, then Space Based Architecture is the better option.

A More Beautiful Question

This is an amazing book and it’s all about how to innovate. The author raises a very interesting point that we are always running after answers however, to come up with something truly innovative, we must ask the ‘More Beautiful Question’.
So what does it mean to ask the more beautiful question? It can be broken down into 3 main steps:
  • Why?
    As we grow up, our minds become more rigid and accept a lot of things because that’s how it has always been. We stop asking this basic question – why? The application is slow, um, that’s because it’s a large system which needs to serve multiple requests concurrently. No, we need to step back and ask – why? Why is the application slow and come to the root cause.
  • What if?
    Now that we have identified the probable root cause, next question is ‘what-if’? In this step we must forget about all constraints and what’s practical and impractical. We should just come up with all solutions that we can think of, and as stated before these does not have to be practical. This is important to understand, as an absurd idea in itself may not be of much value but it can lead to more and more ideas some which may actually be viable.
  • How?
    Now, that we have brainstormed a lot of solutions to the given problem, now is the time to figure out what actually is practical of all the options mentioned. Which one of these can be really achieved given the current constraints and one or two may actually fit the bill.
What happened in this exercise is that we kept aside the practical aspects till the last stage and let our thoughts move freely beyond any restrictions. By taking a step back and not chasing after answers we have allowed ourselves to think beyond the obvious and come up some potentially unique solutions.

CQRS

Software architecture has evolved a long way from the standard 3 tier architecture. A lot of the previous architectures were optimized for the constraints present at that time like limited resources but with time such restrictions no longer apply.
The most promising of the new architecture is the Domain Centric Architecture which places domain right at the center of the architecture. But more on the domain driven design later.
Another interesting concept is CQRS – Command Query Responsibility Segregation. This is useful for creating a system optimized for performance. The principle is simple, keep the command and query separate.
Command is anything that changes the state of the system on the other hand query requests some information from the system. A query should never alter the state of the system and the command should ideally not return some information. Of-course, a strong distinction is not always possible, a command does often return whether it was successful or not but keeping them separate leads to a lot of benefits.
Code level:
CQRS should be even strived at a code level. A function responsible for fetching some information should never alter the state of the class. As the codebase grows, a public facing getter API can be called from different modules. It’s next to impossible to control that and other modules may not have enough information to identify when a simple get call ended up altering the state of system inadvertently.
Architecture level:
A lot of the features in the software are data-read heavy and usually a smaller set of features in the software actually update the data. If we keep them separate we can scale them independently. The ‘Query’ module having optimized for fast reads and ‘Command’ module optimized for writes. In a little more advanced version of CQRS, both the stacks can have independent databases. Every write into the main database is then synchronized with the database meant for ‘read’. For short duration these databases will be out of sync but this leads to highly performant systems and the performance won’t degrade as you scale the system.
There are downsides of it too. Implementing CQRS makes the architecture complex and should not be used if the performance and scalability are not the primary needs of the software. Also, the query and command stacks will have data which will be out of sync which leads to additional complexity in the system.

Technical Expertise

I was going through a course on software architecture and I came across an interesting concept. It’s nothing too uncommon but it’s something I haven’t paid attention to.
In the simplest terms it states that our knowledge is like a pyramid. What we know forms a small part on the top of the pyramid. What we know that we don’t know forms the next layer. But what really takes up the most chunk are stuff we don’t know that we don’t know about.

An example of this might be that I need to create an application which should run across iOS, Android and Windows phone. Given this requirement I might blindly start using a framework like ‘Xamarin’ and start implementation. What I did not know that there is another way – creating a ‘hybrid’ app using the ‘webview’ component present in all the three SDKs. While at the end of the day Xamarin might still be the better choice, based on the requirements, but now knowing that another approach exists, we missed out on an opportunity to create a simpler solution.
Also, as we grow in our careers we need to move things out of the lower triangle and at-least move it into the middle triangle, so that whenever an opportunity presents itself, we know that a way to tackle the problem already exists. This increases our ‘technical breadth’ which is more useful than ‘technical depth’ as we go higher up the technical career path.

Mind Scripts

As we saw in the last post, making the first impression right is very important. But often we are faced with precarious situations where it’s not easy. It could be that we are going for the interview for the dream job in the dream company so we are nervous and being nervous can lead to a very bad first impression. How do we overcome this?
In his book ‘The Full Facts Book of Cold Reading’, Ian Rowland gives a very simple solution: ‘Mind Scripts’.
So what are ‘Mind Scripts’? It’s nothing but repeating a small positive statement about the upcoming encounter. So in this scenario it could be something like this: ‘I am prepared, I’ll do good and they will like me.’ Keep repeating this in your mind till the initial conversation starts. This makes a good impact on out mindset and body language.
You should also checkout the book for other interesting facts like how to ‘foretell’ someone’s past and future using some clever tricks.

First Impressions are Key

Roger is smart, intelligent proud and lazy.
Smith is lazy, proud, intelligent and smart.
So, of the two who do you think is the better person? Roger, right? Isn’t it obvious?
Well, not really. They both have the same qualities. Only difference being that in case of Roger adjectives like ‘smart’ and ‘intelligent’ were used first and for Smith they were used later. So our first impression of Roger was that of a smart person and that of Smith was of a lazy person.
So, you see. Even simple statements like the ones above can create a impact and these are not to be taken lightly. In the book – ‘Social Animal’ Elliot Aronson highlights a number of psychological experiments where the impact is clearly seen. For example, assume Roger and Smith are students in your class. Initially, Roger does well but over time Roger’s grades fall and Smith’s catches up. You are more likely to believe Roger is the true genius of the two but his mind is little diverted for the time being where as Smith is not that bright but is working hard these days.

Key to Success – How not to approach your supervisor

Here is a simple trick for success, whenever we are faced with a challenge, we should not go to our supervisor with that problem. The supervisor will soon start seeing us as another source of problem and would start to avoid us if possible.
What we should do instead is go with a possible solution to the problem along with the original problem and discuss it.
Suppose there are some quality concerns with the feature developed by a team member. The wrong approach would be to directly go to the manager and complain. By doing that we have placed the ball in manager’s court and the manager must figure out what to do. Everyone is busy and as people go higher in their career, they have less and less time. The manager now must take time out of his/her busy schedule and address the issue.
The proper approach to this would be that we try to identify where the gap is, if possible. Suppose we find that the employee actually has strong design and coding skills but given the fact that he/she is new to the domain, the employee is often not able to take the right decisions required for the problem. So, now when we approach our supervisor, we not only know the problem but also can suggest some potential corrective actions to it (like organizing domain sessions). Of-course, the supervisor may not always agree with the solution we provide, but the supervisor will be really happy that we saved a lot of his/her time and brainstormed some potential solutions up front.

How to beat Procrastination – A Stitch in Time saves Nine

Procrastination is definitely one of the bigger challenges we face when we start any work. We know something needs to be done but we just don’t feel like it, putting it off for another moment which becomes days and sometimes even longer.
The task is usually something that’s seen as less pleasurable like reading about a new technology (oh well, I don’t feel up to it right now, lets read a novel instead) or it could be a household chore or that presentation you need to prepare for office. We keep delaying it till the last moment and then scamper to finish it at the end. Well, they have a very old and true saying for that – ‘a stitch in time saves nine!’ and so what should have taken only a ‘stitch’ before now needs eight more ‘stitches’ to get it right.
So how do you beat it?
I read this great article few years back and it went like this:
– Why do we procrastinate? No, don’t worry, you don’t have to reason it out for every task. The reason is usually same for all and that is we think it’s mundane/boring and there are more pleasurable things to do instead of it. The mind is resisting devoting time to it.
– So, how do you fix it? As stated above we don’t wish to allocate time for it so don’t! Just do it for 5 minutes and stop. Take a break for as long as you want and then come back to it for another 5 minutes and then again take a break. So the initial resistance of allocating time is gone after all we are just going to do it for 5 minutes and usually after a couple of breaks we pick up the momentum and the thing gets done.
One thing to note though – the break truly can be of any duration you want so you are not getting committed to it. If you don’t believe it, your mind won’t believe it either and you’ll only end up procrastinating about breaking procrastination.

WPF – Using Dispatcher vs SynchronizationContext

Every time I had to update the ui from a non-ui thread I always used the Application.Current.Dispatcher and never paid much attention to it. Just call a begin invoke from the other thread and you are done. It was only recently that I realized that that’s not the only way of doing things. There is an alternative way using the ‘SynchronizationContext’ which also gets the job done. So what’s the difference?
I couldn’t figure out anything obvious so I started reading up articles on it and finally found a comprehensive article here.
So basically SynchronizationContext adds another level of indirection. Unlike the dispatcher which is WPF specific, the SynchronizationContext has different implementations – WPF and WindowsForms being some of them. So, now your code is not dependent on any technology which is always great.
Though in theory the synchronization context can be used to communicate between any two threads, not all threads have a synchronization context. Only the UI thread has the required context and the plumbing code required for getting it to work.

Devs rejoice – LINUX dev environment on the CLOUD for FREE!

Okay, not exactly the entire OS that’s free, you cant just go there, open Libre office and do everything you would normally do on a PC from a web browser. But what you can do is run your NodeJS service, run an entire web application on the MEAN stack and much more without worrying about any setup. The complete dev environment is out there.
I had never played wih NodeJS before and wanted to try it out. So I began searching on how to work with NodeJS when I stumbled upon this gem of a website – CodeAnywhere!
This is a development environment hosted on the cloud and when you log in you are presented with a ‘Devbox’ which is virtually a small VM with 256 MB RAM and 2GB hard-disk space. You can choose between a Ubuntu setup or a CentOS setup along with the technology stack be it node, MEAN, Python etc. And there I was writing a service from my web browser which got hosted on a remote location accessible via an URL with no cost at all and with zero setup time. It was phenomenal. It’s simple to create a static web-page and see it working on web browser without any real effort. But to know that it’s as easy to create a service having access to MySQL/MongoDB exposing APIs to solve your business logic is very impressive.
Only catch is in the free version, your devbox runs only for the time you are logged in. So, once you log off your service hosted on the devbox is inaccessible. But nevertheless it is an excellent tool for learning.
On the downside, their app for iOS is really not upto the mark.

Sharing and Applying multiple Event Handlers – JavaScript / jQuery

This was back when I didn’t use Angular and used jQuery a lot for making my views interactive. A thing that I learned back then was that class can be used to not only share styles but functionality.
Unlike the ‘id’ which is unique to an element, same class name can be shared across multiple elements and helps in reusing styles using CSS. Or at-least that’s the extent to which I used them.
So, here I was creating a form and I realized that along with styles, there was also common functionality. A lot of the fields in the form shared validation logic and when using jQuery I realized that I can simply pass in a class name to the ‘$()’ and I am done!
I can attach the same event handler to all elements which had that class name. Also I can add multiple event handlers to the same element (of-course ensuring that the event handlers are not order dependent).
This simplified the code greatly as I could now add a class name and I would automatically get the relevant styles and the required event handling applied.
Sample Code:

<html>
  <head>
  </head>
  <body>
<form>
      Name: <input type= "Text" class="MustNotBeEmpty"/>
      Account Number: <input type= "Text" class="MustNotBeEmpty MaxSize6" />
    </form>
    <script>
      $(".MustNotBeEmpty").blur(function ()
      {
        if(this.value.length === 0)
        {
          alert("You need to have some value.");
        }
      });
      $(".MaxSize6").blur(function ()
      {
        if(this.value.length > 6)
        {
          alert("Value cannot exceed 6 characters.");
        }
      });          
    </script>
  </body>
</html>

So now when the validation occurs: