subscribe via RSS

  • Making sense of Blockchain

    Any business transaction is based upon trust and requires secure way of transferring assets between transacting parties. Financial institutions like banks provide this trust by maintaining a true record of their business transactions that can be relied upon to verify each transaction. They usually achieves this by maintaining a central store for recording these transactions. Blockchain attempts to reduce the cost and increase trust in business transactions by using distributed transaction store on peer to peer networks rather than a central authority. In simple terms rather than a single authority like a bank responsible for maintaining the transactions, it is now a group of people running blockchain servers that do this. This decentralized approach allows customers to make an exchange (e.g. pay for an item) without third party involvement. This has profound implications for a wide variety of business processes in the financial, healthcare and the energy industry to name a few.

  • Demonetisation: Surgical strike or carpet bomb

    At 8pm on the 8th of November prime minister Narendra Modi announced that from midnight all 500-rupee and 1,000-rupee notes would cease to be legal tender. This deliberate shock demonetisation policy was announced with the following 3 main objectives:

  • Think Docker! Think Security!

    Docker allows you to completely abstract the underlying operating system and run your app across multiple platforms (local machine, cloud or on-premise data centre) as long as the destination has the Docker runtime (Docker daemon) running. With Docker, the Continuous Delivery philosophy Build once deploy anywhere really comes to the fore. You build your binary artifact as a Docker image that includes all the application stack and requirements once and deploy the same image to various environments. This ensures the binary is built once and the same source code is promoted in subsequent deployments, allowing agile, continuous application delivery.

  • Services, microservices, bounded context, actors.. the lot

    I was at the DDD exchange recently where we had the likes of Udi Dahan, Eric Evans and Scott Wlaschin on the panel. In a post event Q&A session I asked the panel - “Is microservices SOA renamed? “ which triggered an hour long debate. The panelists argued amongst themselves about what exactly a service or a microservice means. By the end of the debate I doubt any one of us was any more wiser. Clearly there was no consensus on the definition of the word service and what it means. It is a term that is widely used and abused in our industry but we do not seem to have a common understanding of it. This raised a few questions in my head. Disappointed with the expert advice, I decided to look out for a definition of my own.

  • Problem with mutating state

    The purpose of any computer program is to take some inputs and produce an output. Producing an output causes the program to have an effect which means during its execution cycle, the program changes certain values. A live program models the real world where things change frequently over time and in parallel. But while writing programs we only have a static view of the problem domain and with the best of intentions and tools at hand we try to manage state change in our program as it would happen in the real world. This leaves us having to deal with values that change over time. Are OO languages capable of handling this complexity easily or do we need to look further?

  • Are mocks worth it?

    Mocks are widely used in most development teams I’ve worked with practicing TDD. According to Uncle Bob A mock object is a very powerful tool, providing two major benefits: isolation and introspection. But like all power tools, mocks come with a cost. He goes on to list the benefits as well as possible issues of using mocks. Between the two extremes of too many mocks and no mocks I tend to start with no mocks until I absolutely and necessarily need one. Therefore, I am always interested in techniques that allow me the freedom of working without learning an external mocking framework. In statically typed languages like Java and C#, interface based polymorphism allows us to use mocked implementations for tests. Functional programming provides an alternative to interface based polymorphism.

  • How did AAP win the way it did? By saying Sorry!!

    Apart from the well known reasons that have been written about and discussed ad nauseam ranging from AAP’s issue based politics to BJP’s overconfidence, complacency, negative campaign, inability to reign in its communal forces to the Congress’s sheer ineptitude to come to terms with contemporary politics, it is interesting to look beyond these to try and understand the unprecedented mandate received by AAP. So how did a party that was written off after the general elections to such an extent that the BJP did not even deem fit to campaign in Delhi up until the last few weeks, achieve such a resounding victory? By saying the magic word: Sorry!

  • From object to function composition

    Composition is a technique often used to build software by creating cohesive units that interact with each other to form the overall system. At the code level these units mainly consist of functions and objects. A system can be built by composing objects with abstractions that define the rules for communication with other objects. An alternative way of building the system is by composing functions and defining the rules of communication through functional contracts (i.e. passing functions into functions). Coming from an object oriented background I feel this second approach is worth exploring further.

    Using the C# GildedRose kata as an example, an object oriented way of expressing the quality adjustment in a product looks like this

    Now I have a couple of issues with the code above. First there is some repetition and unnecessary noise in the code that declares constructors for various IAdjustQuality implementations. Secondly IAdjustQuality and IProduct are single-method interfaces and I am suspicious of interfaces with single methods. Interfaces are generally created for a bunch of related methods.

    An alternative way to express the quality adjustment in a Product in the GildedRose example would be to compose functions rather than objects. Although C# traditionally has been perceived to be an object oriented language but with lambda expressions it is very much possible to write functional code in C#. Single-method interfaces are easy to replace with the usage of closures and "function pointers" as long as the function has a compatible signature to the method declared in the single-method interface. Lets see how we can replace IAdjustQuality with its functional equivalent.

    Creating the AdjustQuality and AdjustBackstageQuality functions results in the removal of  2 classes and the interface declaration itself. Notice AdjustQuality function uses partial application i.e. it is a function that returns another function. The first function is applied partially to return the actual function. This should be more clear after looking at the Product class now.

    Applying the same technique of replacing an interface with its equivalent function pointer the IProduct interface can also be removed and the resulting code looks like this. 

    So why compose functions rather than objects. One of the benefits as you may have noticed straight away is that functional code is pretty succinct and has less lines of code (less than half of the original object oriented approach). The noise around declaring single-method interfaces and their implementations is no more present. However the functional approach might seem confusing and less readable especially the excessive use of lambda expressions and partial application. But I guess depending on whether you come from the object oriented background or the functional one you could sway either way. There is no right or wrong here. The basic idea is how objects and functions can be used to split your overall system into manageable chunks. The flexibility of achieving that in more than one way is a powerful tool to have.
  • Git Basics

    Git overview

    • Distributed Version Control
    • Data Consistency and Integrity
    • Performance - Diffs are local therefore quicker, do not have to go over the network to perform diffs.
    • Merging - Automatic merge if there are no conflicts (more than one change at the same position of the modified file).
    • Conflicts have to be merged manually.
  • Voice to the Mango People

    A lot has been said and written about the Aam Aadmi Party phenomenon. It originated from an anti corruption movement, had a stupendous electoral performance and is now on the verge of forming a government in Delhi. Before the Delhi election results were announced, the claim to form the government was far from reality even for the most ardent AAP supporter. The emergence of AAP as a political force in the national capital has disrupted conventional politics. Ever since their formation, they have brought the issues of corruption, honesty and political propriety at the forefront of our political discourse. The future of AAP as a political force in India is far from having been realised and will depend a lot upon their administrative performance, but the impact that they are having on India’s political culture and representative democracy is extraordinary.

  • Democrazy

    The time and effort we spend talking about the Indian democracy and how every Indian swears by it comes a cropper when events like what happened in Mumbai following Bal Thackeray’s death occur. The recent arrest of two Mumbai girls for posting an allegedly defamatory comment on Facebook is a case in point. The intolerance of our so called democracy is such that a reasonable opinion expressed in anguish on social media can make you end up in jail and result in a violent attack on your next of kin. The absurdity doesn’t stop here, it also means your friend is arrested too for the heinous crime of liking your Facebook post.