TL;DR they don’t.

It’s been quite a while since I adopted RxJS and fell in love with the idea of Reactive Programming. It takes time and quite a bit of practice to really get to know reactive programming and learn to appreciate it. When you start playing with RxJS one of the first things you would notice is the similarities of an Observable to a Promise. The next thing you would do is google “promise vs observable” and the internet will explain to you what the differences are quite well.

I’m baffled by the number of people I come across who think observables are a replacement for promises. I guess we have Angular to partly blame for that. Despite Angular playing an important role in the fame and adoption of RxJS, it did play a part in this misconception with its use of Observables for use-cases where Promises are more applicable. …

When you travel out of your resident country there are things that you miss quite often. One of those things that most people end up missing is the caller-id when you receive calls from your resident country. This happens mostly because people tend to save phone numbers without the country code for local numbers. This bites you back big-time when you are traveling. I recently moved to Singapore from Sri Lanka and it has been a blast, except when I get calls or WhatsApp messages.

So I wanted to convert all my Sri Lankan contact numbers that did not have a country code to have one. Usually I would use Automator on my mac to get this sort of little tasks done. But this time it was too much of a stretch for Automator to include all my nitty-gritty requirements to get the job done. Enter JXA (JavaScript for Automation), something that Apple included in Yosemite as an alternate to AppleScript. …

Picking the right software architecture/design is just like picking the right tool for a job. You use the wrong tool and then everything may seem a little bit more difficult or little bit more messier. When it comes to software architecture/design though, there is no such thing as the “correct” tool for the job. Most solutions would work and the difference would be relative. It really boils down to how optimal a solution is, for the problem(s) at hand.

When we started rebuilding Creately from scratch, we revised a lot of our design and architectural decisions. One of them was to use Event Sourcing as one of the key patterns in the overall solution. …

RxJS is something I have come to appreciate quite a bit in the recent past, in it’s ability to manage asynchronous operations. It really is a shift in the programing paradigm of how you look at asynchronous code. If it is adopted consistently well across your app, you can see a significant improvement in how you manage asynchronous code. In this post I want to talk about a particular principle of Observables. This post wouldn’t make a lot of sense if you have not had exposure to RxJS.

Unsubscribing or Cancelling.

One of the key features of Observables is its ability to cancel the underlying operation of the source. In fact the ReactiveX documentation explains the primary purpose of the Subscription as this. …

In the second part of this series I talked about how we actually deliver our products every single day - the process and the tooling. In this final post I want to discuss why some of these practices are important to achieving the level of efficiency you need to deliver quality product, fast.

When we start a new project, there are a bunch of things that we setup to ensure the smoothest and fastest operation of that project and the best quality outcome of that project. …

Anyone who is an experienced application developer understands that if your application is not the typical todo app, you have at least a few states that are application wide (they conceptually exist regardless of how they are implemented/handled). There are lots of powerful ways to maintain states well (like routes, singletons, storage and so on). But it all boils down to how you define them and use them.

Why disaster?

Centralized states can be a disaster for the very reason why global variables can be the same. When there is a central/global state, it can affect different parts of the application and at the same time it can be modified by different parts of the application. Trying to understand how a specific part of the application works, will depend on any global states that are affected by it or modified by it. This also means one specific part of the application will be bound to another part of the application by these states. As the application grows it becomes harder and even impossible to understand how different parts of the application are affected. …

In the first part of this series I spoke about what this whole thing means for us. In summary the three key focuses are: World-class product quality, fast delivery of smaller things and automating everything. In this post I will be going through how it is done.

How we work is what enables us deliver product everyday.

Environment

Each of our projects are on their own git repo. Each project is bootstrapped with package management, linting, code styling, unit test coverage reporting and a full-on build process. Every repo has

• a dev branch which aligns with staging environment.
• a master branch which aligns with production environment. …

F**k that.

I fully appreciate the notion of not taking failure as a negative emotion and I have practiced that many a times. Failure happens and there is so much that you learn from it and almost every failure is a gain, not a loss. So telling yourself “it’s ok to fail” when you fail, is one thing.

What bothers me is whenever I see a Startup or even any sort of initiative that is driven with the safety net of “it’s ok to fail”. This I feel sets you in the wrong direction all-together. If you are being scientific about how you think (not emotional) you can 100% of the time plan meticulously to achieve the set goals. Yes, it is true that no one plans exclusively to fail. …