The Art of Efficiency

Every now and then in our journey through life, we meet some amazing individual, able to astound us, either because of their resolve, stamina, knowledge or wisdom – Tim Ivaikin is one of those individuals for me. When Tim became my colleague, I immediately understood that he’s an extraordinarily skilled software developer. And as we started talking about Buddhism and Philosophy, I also realized that he’s much deeper than what you would normally expect from a “mere software developer”. However, what I didn’t know, before today in fact – Was that he had written a book – Which perfectly illustrates his meek nature may I add 🙂

Tim’s book, where he combines his software development theories with Philosophy and the ideas of Buddhist Enlightenment

In the first chapter of the book, he manages to use analogies of “never ending loops” to illustrate bad habits, scrum as a process to achieve entering the now, and software development theory as the means to improve how your brain works. I am not sure what to say really, I am simply stunned! But one thing I do know, I now know what I want for x-mas!

Buy his book here

My DZone articles

I remember DZone from more than a decade ago, when it was a small website, where if you went viral, at most you’d get some 3-4.000 page views. Today even a “flunked” article often gets 10-15.000 views, and it’s everything but a small website, but rather one of the primary sources of information for aspiring developers, looking to learn the tricks of the trade.

I’m a member of their core team, which implies I get early access to having my articles published, and I get invited to attend meet-ups and gatherings. In addition I get access to exclusive statistical material, giving me hints and clues about trending subjects, such that I know more accurately what I should write about, to increase the likelihood of gaining lots of page views. I have followed DZone on this journey now for more than a decade. Just some few years ago, Mike was little more than an avatar with a photo. Today him and Blake, their community manager, are living people, whom I can relate to, and have private conversations with – Sometimes face to face. And with this change, came the opportunity to be heard, be listened to, and raise my voice in regards to how they develop and maintain their site. I love it.

Below are some of my articles for those that’s interested in what the “weird Hyperlambda dude” has been writing about over there for the last couple of years.

There are many more, but you can probably find them from my breadcrumbs above I presume. However, a popular article of mine today, easily gets more than 20K readers. 10 years ago, I was lucky if I would get 4K readers. I congratulate DZone, Mike, Blake and the others on this growth, and I hope to be able to follow them for many more years. Thank you #DZone 🙂

The things you cannot reach for

A couple of days ago, I was invited to Tim and Sergey’s podcast. We were supposed to speak about Magic and automation in software development – But ended up speaking more about Buddhism, Spirituality, Art and life in general. Feel free to listen to it if you wish.

Buddhism, I, Myself, the Now, and the Buddha

Please like it and leave a review if you can 🙂

Magic getting started

We have just now created a new getting started video, since the process of getting started has been significantly simplified. Follow it below, and get started with Magic in less than 10 minutes.

Our new Getting Started Video

Aligned incentives

I once read a story about an airliner that internally timed when takeoff started according to when all passengers were on board, and not when the plane actually started flying. I think the idea was that from the point in time that all passengers were inside of the airplane, it was no longer the employees fault if the plane become late. Then they paid bonus to their employees according to how “punctually” the plane was, and how fast the employees could fill up the plane. So basically, all employees had financial incentives towards making sure the plane would fill up as fast as possible.

The guy who wrote the story down spent 8 hours sitting inside of one of these planes before the plane took of from the runway, because the plane wasn’t allow to take of from flight control. Him and several of the other customers asked several times if they could be let of the plane, to grab some fresh air, and move around a little bit – Since they had been told it would be several hours before the actual flight would start. The cabin personal said “no”, because they didn’t want to loose their own bonus, which was due, simply because all passengers was physically sitting inside of the plane. Needless to say, but I doubt many of those passengers ever flew with that airliner again.

If your company’s incentives, or your employees incentives, are in direct opposition to your client’s needs and desires, you will probably wake up hard one of these days, realizing your clients have simply gone to the competition …

Just my 2 cents here … 😉

Modern Web application architecture

I just recently participated in a discussion at Reddit about which architecture to use when creating Web applications. My personal opinion is that when creating a Web application, is that there are no real alternatives to pure Web APIs, combined with something such as Angular, React or Vue. The reasons is that it’s the only method we know about to create a clean separation of your application’s logic and its UI.

If you create an MVC application, the view is rendered on the server side. This results in an unhealthy mixture of view and logic, tied together, making it much more difficult to do modifications to one of these parts, without affecting the other side of the equation.

As to Blazor, don’t even get me started. I am not even sure about if I want to publicly raise my opinion about it.

If you’re looking to get into Web application development today, do yourself a favour, and drop all ideas of everything that does not contain the words JSON, API and HTTP REST in them somehow – It’s simply not worth the time!

Validators, transformers and injectors

Most software developers tends to inflate the complexity of their own business logic, to the point where the cognitive context required to understanding their product, becomes so overwhelming, that maintaining their code base becomes literally impossible. When this happens, it is referred to as “the big ball of mud”.

If the GoF taught us one thing in their famous book “Design Patterns”, it was that language helps us understand and categorize problems, which again results in better structure, due to making the code more easily recognized, and possible to speak about, within a common terminology, easily understood by everyone agreeing upon the vocabulary – Hence, I propose the following language additions to our vocabulary as we create methods taking input intended to be somehow stored.

  • Validators, validates input data before the data is stored
  • Transformers, mutates data before the data is stored
  • Injectors, adds to the input data before it is being stored

Most developers have probably heard of validators. These are for instance objects that prevents us from registering at some website unless we provide a valid email address, etc. However, I don’t think anyone have proposed the other two elements previously. Hence I will explain them below.

A transformer is something that takes one of your input fields, and somehow mutates it, to become something different. The typical use case is storing a password from some website. You never want to store the password in plain text though, typically you want to hash it using for instance BlowFish or something similar. This is just one example, and there exists hundreds of other similar concepts, such as for instance always storing data as UPPER CASE or only lower case for that matter. Cleaning up sentences with correct punctuation and sentence capitalization, or making sure names are stored correctly with capital letters. The creative mind can probably come up with dozens of additional similar constructs, but they can all be categorized into the “transformer” category.

Injectors are not part of the input data, but somehow retrieved from some other source, yet still needs to be associated with the data you want to store. From my own industry, which is FinTech and trading systems, a typical example is the trading accounts. When a user registers as a trader in my system, I often want to create a trading account and associate with the user record somehow. This process is typically done by an external system, often the trading platform itself, and then as I persist the user, it becomes associated with that user. Other examples might include storing the IP address during a registration process, or using the IP address to lookup the country of origin the user is registering from, and storing its three letter abbreviated code. All of these can be referred to as “injectors”. Basically, an injectors adds data to the existing input before the object is stored.

The point of this exercise, is that once you realize that the above three simple concepts and words probably includes 95% of your existing business logic, you have a language to use as you speak about your logic, making it much easier to convey your meaning. Basically, it becomes the software development equivalent of what Domain Driven Design refers to as “bounded context”. Or, to be more specific, it becomes the bounded context for storing data from input given by another client somehow.

As you realize that these are generic constructs, you can start dividing your business logic into reusable blocks of code, where 95% of your existing business logic is replaced by three simple interfaces, with some 3-5 different implementations each.

  • IValidate (field)
  • ITransformer (field)
  • object IInjectable ()

At which point everyone can easily see what your code does, and the cognitive requirement to understanding it, is significantly reduced – Making it much more maintainable and easy to debug. In fact, one could even imagine constructs such as these.

class Client
   [Validator(Type = typeof(EmailValidator))]
   public string Username { get; set; }

   [Transformer(Type = typeof(BlowFishTransformer))]
   public Username { get; set; }

   [Injectable(Type = typeof(TradingAccountInjectable))]
   public string TradingAccount { get; set; }

Allowing you to 100% declaratively see what happens to the data by simply inspecting your model. The above of course illustrates how logic can be associated with your data, to increase data integrity, using an AOP type of syntax – While making the code 100 times more easily understood and maintainable – At which point your specialized business logic implementation is effectively reduced to ZERO lines of code!

Business logic you said? Sorry, we don’t do that here … 😉


BlowFish will inevitably at some point in your near future become the most important word in your life as a software developer. The reasons are simply because the only thing governments knows how to do, is to legislate, regulate, and restrict – And as they realize that the GDPR only addressed the tip of the iceberg, they will start digging deeper, looking for more ways to protect their constituents from other malicious activities online. At which point BlowFish will be shoved down your throat as a software vendor, either you like it or not.

BlowFish allows us to cryptographically secure our passwords, and no, any hashing algorithm does not do that – Because BlowFish have some special characteristics, which implies that when combined with individual salts, creating a rainbow dictionary attack, becomes purely mathematically impossible. The reasons is that it is slooooooooooooow! So slow in fact, that for a computer to generate trillions of BlowFish values, based upon a random guess, combined with a random generated salt, becomes theoretical impossible – Even for NSA’s and the CIA’s super computers. Which of course is its purpose.

With any other hashing algorithm, its main feature is that it’s fast. This allows a computer to generate trillions of hash values, in minutes, allowing for it to “guess” your users’ passwords, even though you have done your best to hide them as hashed values in your database. Once they have the password for your little app, regardless of what it is, ranging from “Puppy counting games website” to your “internet banking system”, they’ll also (probably) have your passwords for most other websites too – Including any public website, allowing them to impersonate you in front of your government, removing all liability from you, and completely pulverizing all responsibility from the individual, effectively resulting in Anarchy – Simply because most people use the same passwords on most of their sites.

Hence, at some point in the future, even stupid governments, which knows about as much about software development, as a kitten knows about rocket science – Will be forced to creating legislations, shoving it down software development companies throats, making them forced to implementing it. So there are no reasons to wait for it to happen. You might as well implement BlowFish today, before it becomes a problem for you …

FYI, Magic (of course) stores its passwords as BlowFish hashes, with individual salts, making brute forcing the passwords become literally impossible. Just sayin’ … 😉

How many seconds do you need to secure your app’s passwords …?

Treating methods as URLs

A URL is beautiful conceptually. It points to an entity, is easy to remember, and often speaks conceptually about what you might expect to find at that entity. Hence, it translates written language into an addressable point on Earth, allowing you to easily remember thousands of them, and such access the point behind the URL. It allows you to move the point implementing the URL around as you see fit, and exchange its inner details, without having to change the URL. Pure brilliance if I may say so!

A function on the other hand, has arcane syntax, often contains weird looking characters, and due to its arcane syntax, seldom allows you to remember more than a handful of them. In addition, the lack of a “function DNS system”, prevents you from easily traversing meta information behind your functions, and such increases the cognitive requirements to remember what they do.

So why don’t we treat functions as URLs?

Well, actually you can.

Methods and URLs

URLs and HTTP is a standard. This allows us to generically use it, without knowing anything about its implementation. Create some query parameters, or a JSON payload, pass it to the URL using the correct verb, and voila! You’ve integrated two different systems.

This is actually the very definition of perfect encapsulation. So why don’t modern programming languages learn something from this? Why not create a generic tree structure, allowing us to generically pass data into our methods, and reference our methods as URLs?

Actually, the above perfectly describes Hyperlambda. Hyperlambda is the equivalent of an in-process URL method routing system, with the ability to pass in generic arguments, completely decoupling your components – Resulting in perfect encapsulation.

No references between the method invocation and its implementation. No strongly types adding to your dependency graphs. Nothing! The method invocation and its implementation knows no more about each other than an HTTP endpoint, and its consumer. And of course, since everything is in-process, execution of your method is as fast as using your IoC container to resolve a type. It doesn’t take a rocket scientist to realise this is a good thing!