Learning from React series:

  • Part 1 (this one) - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

  A billion years ago, Microsoft was trying to push a web development model that simulated Windows Forms development: ASP.Net Web Forms. It featured several ideas:

  • component based design (input fields were a component, you could bundle two together into another component, the page was a component, etc)
  • each component was rendering itself
  • components were defined using both HTML-like language, Javascript, CSS and server .Net code bundled together, sometimes in the same file
  • the rendering of the component was done on the server side and pushed to the client
  • data changes or queries came from the client to the server via event messages
  • partial rendering was possible using UpdatePanels, which were a wrapper over ajax calls that called for partial content
    • at the time many juniors were putting the entire page into an UpdatePanel and said they were doing AJAX while senior devs smugly told them how bad that was and that it shouldn't be done. I agreed with the senior devs, but I really disliked their uninformed condescending attitude, so I created a method of diffing the content sent previously and the new content and sending only the difference. This minimized the amount of data sent via the network about a hundred times. 

  Sound familiar? Because for me, learning React made me think of that almost immediately. React features:

  • component based design
  • each component renders itself
  • components are defined by bundling together HTML, Javascript/Typescript and CSS
  • the rendering of the component is done in the virtual DOM and pushed to the actual browser DOM
  • data changes or queries are sent from the browser to the React code via event messages
  • partial rendering is built in the system, by diffing the existing render tree with a newly generated one from data changes

  At first look, an old guy like me would say "been there, done that. It's bad design and it will soon go away". But I was also motivated enough at the time of ASP.Net Forms to look into it, even under the hood, and understand the thing. To say it was badly designed would be stupid. It worked for many years and powered (and still does) thousands of big applications. The reason why Forms failed is because better ideas came along, not because it was a bad idea when it was created.

  Let's look a little bit on what made Forms become obsolete: the MVC pattern, more specifically implemented by Ruby developers and taking the world by storm and ending up being adopted by Microsoft, too. But Model View Controller wasn't a new pattern, it has been used forever on desktop applications, so why was it such a blow to Forms? It was a lot of fashion elitism, but also that MVC molded itself better on web applications:

  • a clear separation of concerns: data, logic and display
  • the ability to push the display more towards the client, which was new but becoming increasingly easy in browsers
  • a clear separation of programming languages: HTML in html files, Javascript in .js files, server code in .cs files
  • full (and simple) control over how things were rendered, displayed and sent to the server

  Yet in the case of React, things are going in the opposite direction, going from MVC applications with clearly separated language files to these .jsx or .tsx files that contain javascript, html and even css in the same file, mixed together into components. Is that bad? Not really. It kind of looks bad, but the entire work is done on the client. There is no expensive interface between a server and a browser that would make the model, otherwise used successfully for decades in desktop applications, ineffective. It is basically Windows Forms in the browser, with some new ideas thrown in. As for the combination of languages in a single syntax, it can be abused, just like any technology, but it can also be done right: with state, logic and UI represented by different files and areas of the application. Yes, you need script to hide or show something based on data, but that script is part of the UI and different from the script used to represent logic. Just the language is the same. 

  "Is Siderite joining the React camp, then? Switching sides, going frontend and doing nasty magic with Javascript and designing web pages?" people will ask. A reasonable question, considering most of my close friends still think React is for people who can't code or too young to remember the .aspx hell. The answer is no! Yet just as with the UpdatePanel seniors that couldn't stop for a second to look a bit deeper into an idea and see how it could be done and then cruelly dismissing curious juniors, thinking that React can't teach you anything is just dumb.

  In this series I will explore not only React ideas, but also the underlying principles. React is just an example of reactive programming, which has been in use, even if less popular, for decades. It is now making a comeback because of microservices, another fashionable fad that has had implementations since 1990, but no one gave them the time of day. Ideas of data immutability are coming from functional programming, which is also making a comeback as it works great with big data. So why not try this thing out, iron out the kinks and learn what they did right?

  So you go into Visual Studio Code, fire up the terminal, run npm start and suddenly you see these ugly warning all over the place, when no code was changed and it had worked before. WTH?!

  And of course, the first thing you do is google the error "there are multiple modules with names that only differ in casing" and click on the first StackOverflow link found and you find the exact problem that you have. But the leading answer was completely misleading for me.

  Here is my scenario: I have a folder that is a clone of a Git repo. I had added another folder with a completely new React application to the same repo, meaning I have to open Visual Studio Code in the main folder, but then change directory in the terminal before I can run commands like npm start. And what I did was do a simple cd myappfolder, like I would normally do and noticed in passing and immediately dismissed that the path in the terminal is now shown as MainFolder/myappfolder and not MainFolder/MyAppFolder as it is on the disk. And that was the exact issue! All I had to do was cd ../MyAppFolder and the annoying warning disappeared.

  To be fair, that's actually the second answer for the SO question, but it did make me waste a few minutes looking at import statements. Lesson learned: when you change directory from the Code terminal, use the Tab autocomplete feature to get disk paths with their actual capitalization!

  And it's clear that this ridiculous issue has caused others a lot of grief, too, as the same answer was rewarded with +50 SO points by someone. Me, being a cheap bastard, I am not doing that.

and has 2 comments

  The Moties series is a strange one. Written in collaboration by Larry Niven and Jerry Pournelle, the first book, The Mote in God's Eye, was released in 1975. The second book in the series, The Gripping Hand, was published in 1993, also a collaboration. The third one, Outies, was published in 2010 and it written by Pournelle's daughter. The action in the books is also happening decades apart.

  As I was saying some days ago, I liked the first book quite a lot. It was cerebral and carefully crafted. In a sense, The Gripping Hand is more than the first book, it's more cerebral and grips (heh!) the reader in even more details. But at the same time, they get to the Moties' star system only after two thirds of the book, a part of the story that is only about people discussing things and planning things and arguing things, then the last part is a prolonged space battle between so many parties that nothing is clear. Meanwhile, detailed negotiations and planning take place, so you don't get out of that for the entire length of the story.

  So, yeah, it brings some new ideas, but at the same time it's really boring and hard to follow. And it becomes especially jarring when you realize that the details in which the story is bogged are just a small subset of what could have been: the Motie culture, the way they spend their lives, the way they actually feel as individuals is completely missing. And, spoiler alert, Outies seems to be going in the same direction, although it does appear to want to address the lives of Moties outside the negotiations with the Human Empire. 

  Bottom line: I liked it, but much less than the first book. That doesn't mean it's not well written and that it doesn't add value to the universe created, but it needs significant investment from multiple writers to bring it to a critical mass so that people pay attention to it.

So you are working on a React app and, to test it, you repeatedly run npm start in the Powershell terminal window of Visual Studio Code. Only you have a browser open on the application and don't want to open another one whenever you restart the server. Or perhaps you have a default browser that is not optimal.

The solution is to set the environment variable BROWSER to either "none" or "chrome" or whatever browser you need. In order to set it in the same Powershell terminal, use $Env:BROWSER="none". Now running npm start will not open a new browser window/tab.

More details here: Advanced Configuration

  So you started working on a React application with Typescript and, after running npx create-react-app someapplicationname --template typescript you executed npm run start and Internet Explorer 11 opened up with a blank page and an unexpected colon issue in the console. Heh, that's not a pun! You click on the error and you see that somehow the rendered website is using Javascript modules which, of course, are not supported by Internet Explorer.

  Why, oh why, would the default browser be set to Internet Explorer? Because you might be working for a company that is high in paranoia and low in technical competence and the only way its house of cards security would work is using obsolete bug ridden hackable systems based on old technology. This post is not about solving corporate culture, though.

  Don't overthink it! Just follow these steps in the Visual Studio Code terminal or an admin command prompt in the folder of your application and never think about it again:

  • make sure you kill the server if it is running (Ctrl-C, then Y in the terminal where you ran npm run start)
  • run npm i fast-text-encoding in the terminal
  • edit index.tsx and add these lines at the very beginning:
    import 'react-app-polyfill/ie11';
    import 'react-app-polyfill/stable';
    import 'fast-text-encoding/text';
  • edit package.json and add the value "ie 11" in the browserlist/development array (or you might want to replace the entire browserlist value with a simple array containing ["ie 11"])
  • from the left side expand the node_modules folder and delete the .cache folder (Shift-Right click to avoid deleting to Recycle bin)
  • run npm run start in the terminal again
  • make sure that the page in Internet Explorer 11 is also completely refreshed by pressing Ctrl-F5

  Now the page should work.

  More on this on the React issue page IE11 support doesn't work in dev mode, even after adding all polyfills and enabling ie11 support #8197

  Many people, including myself, automatically think of "the client is always right" when talking capitalism, but that's not correct. In fact, capitalism is defined as "an economic and political system in which a country's trade and industry are controlled by private owners for profit, rather than by the state"; profit is the only goal or driver of the system, even for different systems, which might be controlled by the state, for example. Every social or legislative characteristic of a particular political system is just a patch that tries to fix from outside what is obviously a ridiculously simplistic concept.

  Even so, we still cling to the idea that we are "served" by companies, like we are some sort of aristocrats being catered for by legions of servants. There is a logic to that, as when a company stops catering to their clientele, they are supposed to lose it. But that's just an illusion. In fact, this only happens if some very specific conditions are met:

  1. the client is aware of the bad service, meaning:
    • they know what they're supposed to get
    • they know what they are getting
  2. there is an alternative to the service, meaning:
    • there is at least another company able to meet the requirements
    • the company is accessible to the client
      • the cost of access is reasonable
      • the client is allowed to access the competitor
    • the client knows the competitor exists
  3. the client wants to get better service, meaning:
    • there isn't too small of a difference between various services (subjective perception that all companies are the same)
    • the effort of changing the service is not too large (subjective perception of effort)
    • the emotions of the client do not bind them to the company (subjective perception of the company)

  Now, all of the points above require not only effort, but persistent effort. One needs to get the necessary knowledge and then keeping up to date, avoiding misdirection and obfuscation, then make decisions and then take action. But even so...

  A company is usually a client of other companies. In my job I am usually hired by companies who do management of people for other companies that need software, with any number of intermediaries and internal chains of command inside each. One might think that because the end client is paying for the entire chain, we should all care about what they want. But we do not! And here are a few of the reasons:

  1. the client does NOT know what they want, therefore they will never be aware of what they're supposed to get
  2. the client has spent considerable effort in creating a relationship between them and the company that provides them with the software, therefore the effort of changing to another provider is quite forbidding
  3. the client has spent considerable effort in creating a relationship with just one company, because they don't want to handle ANY of the responsibilities that company is supposed to handle, therefore they are not in contact with competitors
  4. the chain of command inside the client is made up of people who have personal connections with the company in question, so changing to another provider would be in their detriment, therefore the client is not allowed to change to another provider
  5. the company itself is not providing a better service because it doesn't have to, for the same profit; their competitors think alike, so there is absolutely no reason to change
  6. there is an intermediary system to measure productivity: instead of getting paid for value, the company gets paid for hours worked, for example
  7. a smaller nimbler company might rise to provide the same service for less money or a better service for the same amount, but there is point 4. as well as the perception that smaller companies are riskier
  8. a company might want to change, but be unable to because it depends on other companies or it lacks the necessary competency
  9. one might be competent inside of a company, but if the company is big enough, they get promoted to other posts until they reach a position were they are not competent enough to be promoted
  10. clients themselves prefer to cut costs than get better service

  This happens at every level from the top - where you feel you might be, to the bottom - where you actually are. And guess what? When you realize the same effort and care that you expect from others should be coming from you, you quickly find reasons not to provide any of them:

  1. my job is boring, why should I do better?
  2. my boss is an ass, why should I do better?
  3. my clients are idiots, why should I do better?
  4. I never meet my clients, that someone else's job, why should I do better?
  5. whenever I tried to change something, someone shut me down because they are better positioned than me, why should I do better?
  6. I am getting paid by the hour, so working faster means less money, why should I do better?
  7. most of the money from the client remains with the entire chain of people over me and I get the scraps, why should I do better?
  8. my job is not important for me, it's just a means to support my actual life, why should I do better?

  This may appear as a pyramid of interests where you are just a cog in the machine or whatever, but it is not, it's a full circle. You get what you give. The client and the company and the least competent employee is always you. There are no other species of creatures that fill any of these positions. Your boss is human, your employee is human, your client is human. In Romania there is the saying that you're stealing your own hat.

  But it's OK. You can't do any better, so why should you do better? You are only human, so why be more human? You are a tiny cog in the machine so why grow larger? Do whatever you want, I don't care.

and has 0 comments

  Shorefall continues the story of Foundryside, but the careful plans of the characters are completely upended by the arrival of a terrible villain. And when I say upended, I mean almost nothing except the characters in the first book in the Founders trilogy remains relevant and by the end, which I don't want to spoil, even less is left. This is a cataclysmic book in regards to the story and therefore it feels like a rollercoaster ride. I just couldn't put the book down. It's fun and terrifying, it's smart and compelling.

  I was complaining in my review of Foundryside that the story and characters have turned formulaic and that the information given to the reader was too revealing. I guess in Shorefall these concerns are no longer relevant, since the characters have been already defined and knowledge is no longer imparted to the reader except when it is about to be used. Which is worse! Time and again the story seems to judder and change direction because of something a character suddenly remembers or reveals or gets a glimpse of in a vision related to some magical scriving. Scrivings don't work like that, they are code, they are careful imprintings of arguments designed to do a very very specific thing. There is no reason for them to contain personal memories. This is the equivalent of hacker films where the protagonist is using a graphical interface to break into a computer system and then gets a self playing video from the administrator on the screen.

  Bottom line: I liked the book, it entertained me tremendously and I will no doubt read the third book in the trilogy, probably due in 2022 if the same rate of writing is applied. However there is a vagueness in the scriving of the book that makes it vulnerable to argumentation. The next trilogy (one can only hope it would be a stand alone book) from Robert Jackson Bennett will probably prove what direction he is willing to take in his writing.

and has 0 comments

  I don't remember where I got the idea of reading Prosper's Demon, but I am glad I did! Having listened to it on my headphones I got to that part where they list other works by the same author and so I've learned that K. J. Parker is a nom de plume for Tom Holt. I hadn't heard of him until then, but the list of works went on and on and on. Probably I will have to read some other books from him now, but which one should I start with?

  Prosper's Demon is a novella about an exorcist that wanders the land in order to excise demons from living people, often leaving those people hurt, dead or insane. You get little glimpses of what this means as the story progresses, making it more and more clear that you have to be a certain kind of person to do a job like this. I don't want to spoil the ending, but I have to say that the writing was so good that I really wouldn't have cared much how the story ended. I had fun just seeing this anti hero's character unfold in front of me. The world building was also exquisite, considering the short length of the work.

  Bottom line: really good fun, mixing together logic, science, art and philosophy with pure unapologetic mischief and good writing.

and has 0 comments

A few years ago I wrote an article about using RealProxy to intercept methods and properties calls in order to log them. It was only for .NET Framework and suggested you inherit all intercepted classes from MarshalByRefObject. This one is a companion piece that shows how interception can be done in a more general way and without the need for MarshalByRefObject.

To do that I am going to give you two versions of the same class, one for .NET Framework and one for .NET Core which can be used like this:

//Initial code:
IInterface obj = new Implementation();

//Interceptor added:
IInterface obj = new Implementation();
var interceptor = new MyInterceptor<IInterface>();
obj = interceptor.Decorate(obj);

//Interceptor class (every method there is optional):
public class MyInterceptor<T> : ClassInterceptor<T>
{
    protected override void OnInvoked(MethodInfo methodInfo, object[] args, object result)
    {
        // do something when the method or property call ended succesfully
    }

    protected override void OnInvoking(MethodInfo methodInfo, object[] args)
    {
        // do something before the method or property call is invoked
    }

    protected override void OnException(MethodInfo methodInfo, object[] args, Exception exception)
    {
        // do something when a method or property call throws an exception
    }
}

This code would be the same for .NET Framework or Core. The difference is in the ClassInterceptor code and the only restriction is that your class has to implement an interface for the methods and properties intercepted.

Here is the .NET Framework code:

public abstract class ClassInterceptor<TInterface> : RealProxy
{
    private object _decorated;

    public ClassInterceptor()
        : base(typeof(TInterface))
    {
    }

    public TInterface Decorate<TImplementation>(TImplementation decorated)
        where TImplementation:TInterface
    {
        _decorated = decorated;
        return (TInterface)GetTransparentProxy();
    }

    public override IMessage Invoke(IMessage msg)
    {
        var methodCall = msg as IMethodCallMessage;
        var methodInfo = methodCall.MethodBase as MethodInfo;
        OnInvoking(methodInfo,methodCall.Args);
        object result;
        try
        {
            result = methodInfo.Invoke(_decorated, methodCall.InArgs);
        } catch(Exception ex)
        {
            OnException(methodInfo, methodCall.Args, ex);
            throw;
        }
        OnInvoked(methodInfo, methodCall.Args, result);
        return new ReturnMessage(result, null, 0, methodCall.LogicalCallContext, methodCall);
    }

    protected virtual void OnException(MethodInfo methodInfo, object[] args, Exception exception) { }
    protected virtual void OnInvoked(MethodInfo methodInfo, object[] args, object result) { }
    protected virtual void OnInvoking(MethodInfo methodInfo, object[] args) { }
}

In it, we use the power of RealProxy to create a transparent proxy. For Core we use DispatchProxy, which is the .NET Core replacement from Microsoft. Here is the code:

public abstract class ClassInterceptor<TInterface> : DispatchProxy
{
    private object _decorated;

    public ClassInterceptor() : base()
    {
    }

    public TInterface Decorate<TImplementation>(TImplementation decorated)
        where TImplementation : TInterface
    {
        var proxy = typeof(DispatchProxy)
                    .GetMethod("Create")
                    .MakeGenericMethod(typeof(TInterface),GetType())
                    .Invoke(null,Array.Empty<object>())
            as ClassInterceptor<TInterface>;

        proxy._decorated = decorated;

        return (TInterface)(object)proxy;
    }

    protected override object Invoke(MethodInfo targetMethod, object[] args)
    {
        OnInvoking(targetMethod,args);
        try
        {
            var result = targetMethod.Invoke(_decorated, args);
            OnInvoked(targetMethod, args,result);
            return result;
        }
        catch (TargetInvocationException exc)
        {
            OnException(targetMethod, args, exc);
            throw exc.InnerException;
        }
    }


    protected virtual void OnException(MethodInfo methodInfo, object[] args, Exception exception) { }
    protected virtual void OnInvoked(MethodInfo methodInfo, object[] args, object result) { }
    protected virtual void OnInvoking(MethodInfo methodInfo, object[] args) { }
}

DispatchProxy is a weird little class. Look how it generates an object which can be cast simultaneously to T or Class<T>!

There are many other things one can do to improve this class:

  • the base class could make the distinction between a method call and a property call. In the latter case the MethodInfo object will have IsSpecialName true and start with set_ or get_
  • for async/await scenarios and not only, the result of a method would be a Task<T> and if you want to log the result you should check for that, await the task, get the result, then log it. So this class could make this functionality available out of the box
  • support for Dependency Injection scenarios could also be added as the perfect place to use interception is when you register an interface-implementation pair. An extension method like container.RegisterSingletonWithLogging could be used instead of container.RegisterSingleton, by registering a factory which replaces the implementation with a logging proxy

I hope this helps!

P.S. Here is an article helping to migrate from RealProxy to DispatchProxy: Migrating RealProxy Usage to DispatchProxy

and has 0 comments

  I wish I would have read Women when I was a teenager. I would have learned then that there is no shame in being a man and wanting women and not caring about their neuroses. They might complain about it, but that's their point of view. And in a way, that's the only good thing this book has to teach: how to live unapologetically, accepting who you are. Other than that, the main character, an alter ego of Charles Bukowski, is an old writer who drinks all day, fucks whatever he finds and gambles at the horse race track. By his own admission he only writes so he can do these three things.

  The prose is almost without introspection, just what people did and what they said, but when the character delves into analysing the situations, there are some brilliant passages, some hilariously funny. Imagine someone going through life like in a third person game. They see themselves do things, things that they just feels like doing, and feel little to no shame or responsibility. The entire book is dedicated to the women in his life which are, although very different from one another, easy, sexual, desperate and sometimes downright crazy. He never judges them, except for their sexual technique or pussy size and shape, but he never gets stuck with any of them, even the ones he is in love with.

  What I liked about the character is that he is never violent. Like a Big Lebowski kind of guy, he sails through life like a goose in water; nothing sticks. He loves and leaves, he cares but up to a point, he tries to be good to the people around him, but only after he takes care of his own needs. I had a friend like that once. He was caring and amazingly charismatic, but never right or reliable. Another similar character was Hank Moody, from Californication, which I really loved in the first two seasons.

  Did I love the book? I can't say that I did, but I did like it a lot. It was different from other things I've read and what I feel is probably gratefulness for having such a raw depiction of everything the character/the writer lived and felt. So many books are trying too hard to be smart and fail to pass that first bar of characters laid bare so the reader can fully understand them. There is absolutely no story in this other than the life of Henry Chinaski.

  Something else that I have to say is that the book is something that should be read in this period. It goes back to the basic essence of man and woman, without caring one iota about politics or correctness or trying to absolve the main character in any way. Just like the guy lives in the book, the writing is take it or leave it.

Definition

So, the task at hand is the subject of a common interview question: Implement an algorithm to get all valid (opened and closed) combinations of n pairs of parentheses. This means that for n=1 there is only one solution: "()". "((" or "))" are not valid, for 2 you will have "(())" and "()()" and so on. The question is trying to test how the interviewee handles recursion and what is commonly called backtracking. But as usual, there's more than one way to skin a cat, although for the life of me I can't see why you would want to do that.

The solutions here will be in C# and the expected result is an enumeration of strings containing open and closed parentheses. The code can be easily translated into other languages, including Javascript (ECMAScript 2015 introduced iterators and generator functions), but that's left to the reader. Let's begin.

Analysis

Before we solve any problem we need to analyse it and see what are the constraints and the expected results. In this case there are several observations that can be made:

  • the resulting strings will be of length n*2 (n pairs)
  • they will contain n '(' characters and n ')' characters
  • they cannot start with a ')' or end in a '('
  • in order to generate such a string, we can start with a smaller string to which we add '(' or ')'
  • we cannot add a ')' if there isn't at least one corresponding unclosed '(' 
  • if we add a '(' we need to have enough characters left to close the parenthesis, so the number of unclosed parentheses cannot exceed the characters left to fill
  • we could count the open and closed parentheses, but we only care about the number of unclosed ones, so instead of "closed" and "open" values, we can only use "open" to represent unclosed parentheses

Let's go for some variables and calculations:

  • n = number of pairs
  • open = number of unclosed parentheses in a string
  • open cannot be negative
  • one cannot add ')' if open = 0
  • one cannot add '(' if open >= n*2 - substring.length

Recursive solution

A simple implementation of these requirements can done with recursion:

public IEnumerable<string> GenerateRecursive(int n, string root = "", int open = 0)
{
    // substring is long enough, return it and exit
    if (root.Length == n * 2)
    {
        yield return root;
        yield break;
    }
    // if we can add '(' to existing substring, continue the process with the result
    if (open < n * 2 - root.Length)
    {
        // if only C# could just 'yield IteratorFunction()' this would look sleeker
        foreach (var s in GenerateRecursive(n, root + "(", open + 1))
        {
            yield return s;
        }
    }
    // if we can add ')' to existing substring, continue the process with the result
    if (open > 0)
    {
        foreach (var s in GenerateRecursive(n, root + ")", open - 1))
        {
            yield return s;
        }
    }
}

However, every time you see recursion you have to ask yourself: could n be large enough to cause a stack overflow? For example this fails for n=3000. The nice thing about this method, though, is that it can be limited to the number of items you want to see. For example var firstTen = GenerateRecursive(1000).Take(10) is very fast, as the generation is depth first and only computes the first ten values and exits.

So, can we replace the recursion with iteration?

Iterative solution

In order to do thing iteratively, we need to store the results of the previous step and use them in the current step. This means breadth first generation, which has its own problems. Let's see some code:

public IEnumerable<string> GenerateIteration(int n)
{
    // using named tuples to store the unclosed parentheses count with the substring
    var results = new List<(string Value,int Open)>() { ("",0) };
    for (int i = 0; i < n*2; i++)
    {
        // each step we compute the list of new strings from the list in the previous step
        var newResults = new List<(string Value, int Open)>();
        foreach (var (Value, Open) in results)
        {
            if (Open < n * 2 - Value.Length)
            {
                newResults.Add((Value + "(", Open + 1));
            }
            if (Open > 0)
            {
                newResults.Add((Value + ")", Open - 1));
            }
        }
        results = newResults;
    }
    return results.Select(r=>r.Value);
}

It's pretty sleek, but if you try something like var firstTen = GenerateRecursive(1000).Take(10) now it will take forever since all combinations of 1000 parentheses need to be computed and stored before taking the first 10! BTW, we can write this much nicer with LINQ, but be careful at the gotcha in the comment:

public IEnumerable<string> GenerateLinq(int n)
{
    // looks much nicer with LINQ
    IEnumerable<(string Value, int Open)> results = new[] { ("", 0) };
    for (var i = 0; i < n * 2; i++)
    {
        results =
            results
                .Where(r => r.Open < n * 2 - r.Value.Length)
                .Select(r => (Value: r.Value + "(", Open: r.Open + 1))
            .Concat(results
                .Where(r => r.Open > 0)
                .Select(r => (Value: r.Value + ")", Open: r.Open - 1))
            );  // but if you do not end this with a .ToList()
                // it will generate a huge expression that then will be evaluated at runtime! Oops!
    }
    return results.Select(r => r.Value);
}

But can't we do better? One is going to stack overflow, the other memory overflow and the last one kind of does both.

Incremental solution

They did say this requires an incremental solution, right? So why don't we take this literally? '(' and ')' are like 0 and 1, as ')' must always follow a '('. If you view a parenthesis string as a binary number, then all possible combinations can be encoded as numbers. This means that we could conceivably write a very fast function that would compute all possible combinations using bit operations, maybe even special processor instructions that count bits and so on. However, this would work only for n<=32 or 64 depending on the processor architecture and we don't want to get into that. But we can still use the concept!

If a string represents a fictional number, then you can start with the smallest one, increment it and check for validity. If you combine the incremental operation with the validity check you don't need to go through 2n operations to get the result. It doesn't use any memory except the current string and it is depth first generation. The best of both worlds! Let's see some code:

public IEnumerable<string> GenerateIncrement(int n)
{
    // the starting point is n open parentheses and n closing ones
    // we use the same array of characters to generate the strings we display
    var arr = (new string('(', n) + new string(')', n)).ToCharArray();
    // iteration will stop when incrementation reaches the "maximum" valid combination
    var success = true;
    while (success)
    {
        yield return new string(arr);
        success = Increment(arr, n);
    }
}

private bool Increment(char[] arr, int n)
{
    // we begin with a valid string, which means there are no unclosed parentheses
    var open = 0;
    // we start from the end of the string
    for (var i = arr.Length - 1; i >= 0; i--)
    {
        // ')' is equivalent to a 1. To "increment" this string we need to go to the previous position
        // incrementing 01 in binary results in 10
        if (arr[i] == ')')
        {
            open++;
            continue;
        }

        // '(' is equivalent to a 0. We will turn it into a ')' to increment it,
        // but only if there are unclosed parentheses to close
        open--;
        if (open == 0) continue;

        // we 'increment' the value
        arr[i] = ')';
        // now we need to reset the rest of the array
        var k = n - (open + i) / 2;
        // as many opening parenthesis as possible
        for (var j = i + 1; j < i + 1 + k; j++)
        {
            arr[j] = '(';
        }
        // the rest are closing parentheses
        for (var j = i + 1 + k; j < n * 2; j++)
        {
            arr[j] = ')';
        }
        return true;
    }
    // if we reached this point it means we got to a maximum
    return false;
}

Now doing GenerateIncrement(1000000).Take(10) took more to display the results than to actually compute them.

More solutions

As this is a classic interview question, there are a billion solutions to it at LeetCode. Yet the purpose of interview questions is to find out how one thinks, not what the solution of the problem actually is. I hope this helps.

and has 0 comments

Intro

  When talking Dependency Injection, if a class implementing Interface1 needs an implementation of Interface2 in its constructor and the implementation for Interface2 needs an implementation of Interface1 you get a circular dependency error. This could be fixed, though, by providing lazy proxy implementations, which would also fix issues with resources getting allocated too early and other similar issues.  Now, theoretically this is horrible. Yet in practice one meets this situation a lot. This post will attempt to clarify why this happens and how practice may be different from theory.

Problem definition

  Let's start with defining what an interface is. Wikipedia says it's a shared boundary between components. In the context of dependency injection you often hear about the Single Responsibility Principle, which stipulates that a class (and by extension an interface) should only do one thing. Yet even in this case, the implementation for any of the Facade, Bridge, Decorator, Proxy and Adapter software patterns would do only one thing: to proxy, merge or split the functionality of other components, regardless of how many and how complex they are. Going to the other extreme, one could create an interface for every conceivable method, thus eliminating the need for circular dependencies and also loading code that is not yet needed. And then there are the humans writing the code. When you need a service to provide the physical location of the application you would call it ILocationService and when you want to compute the distance between two places you would use the same, because it's about locations, right? Having an ILocationProviderService and an ILocationDistanceCalculator feels like overkill. Imagine trying to determine if a functionality regarding locations is already implemented and going through all the ILocation... interfaces to find out, then having to create a new interface when you write the code for it and spending sleepless nights wondering if you named things right (and if you need to invalidate their cache).

  In other words, depending on context, an interface can be anything, as arbitrarily complex as the components it separates. They could contain methods that are required by other components together with methods that require other components. If you have more such interfaces, you might end up with a circular dependency in the instantiation phase even if the execution flow would not have this problem. Let's take a silly example.

  We have a LocationService and a TimeService. One handles points in space the other moments in time. And let's say we have the entire history of someone's movements. You could get a location based on the time provided (GetLocation) or get the time based on a provided location (GetTime). Now, the input from the user is text, so we need the LocationService and the TimeService to translate that text into actual points in space and moments in time, so GetLocation would use an ITimeService, while GetTime would use an ILocationService. You start the program and you get the circular dependency error. I told you it would be silly. Anyway, you can split any of the services into ITimeParser and ITimeManager or whatever, you can create a new interface called ITextParser, there are a myriad refactoring solutions. But what if you don't have the luxury to refactor and why do you even need to do anything? Surely if you call GetLocation you only need to parse the time, you never call GetTime, and the other way around.

Solution?

  A possible solution is to only actually get the dependency implementation when you use it. Instead of providing the actual implementation for the interface you need, you provide a lazy proxy. Here is an example of a generic (and lazy one liner) LazyProxy implementation:

public class LazyProxy<TInterface>:Lazy<TInterface>
{
    public LazyProxy(IServiceProvider serviceProvider) : base(() => serviceProvider.GetService<TInterface>()) { }
}

  Problem solved, right? LocationService would ask for a LazyProxy<ITimeService> implementation, GetLocation would do _lazyTimeService.Value.ParseTime(input) which would instantiate a TimeService for the first time, which would ask for a LazyProxy<ILocationService> and in GetTime it would use _lazyLocationService.Value.ParseLocation(input) which would get the existing instance of LocationService (if it's registered as Singleton). Imagine either of these services would have needed a lot of other dependencies.

  Now, that's what called a "leaky abstraction". You are hiding the complexity of instantiating and caching a service (and all of its dependencies) until you actually use it. Then you might get an error, when the actual shit hits the actual fan. I do believe that the term "leaky" might have originated from the aforementioned idiom. Yuck, right? It's when the abstraction leaked the complexity that lies beneath.

  There are a number of reasons why you shouldn't do it. Let's get through them.

Criticism

  The most obvious one is that you could do better. The design in the simple and at the same time contrived example above is flawed because each of the services are doing two very separate things: providing a value based on a parameter and interpreting text input. If parsing is a necessary functionality of your application, then why not design an ITextParser interface that both services would use? And if your case is that sometimes you instantiate a class to use one set of functions and sometimes to use another set of functions, maybe you should split that up into two. However, in real life situations you might not have full control over the code, you might not have the resources to refactor the code. Hell, you might be neck deep in spaghetti code! Have you ever worked in one of those house of cards companies where you are not allowed to touch any piece of code for fear it would all crash?

  The next issue is that you would push the detection for a possible bug to a particular point of the execution of your code. You would generate a Heisenbug, a bug that gets reproduced inconsistently. How appropriate this would have been if an IMomentumService were used as well. Developers love Heisenbugs, as the time for their resolution can vary wildly and they would be forced to actually use what they code. Oh, the humanity! Yet, the only problem you would detect early is the cycle in the dependency graph, which is more of a design issue anyway. A bug in the implementation would still be detected when you try to use it. 

  One other issue that this pattern would solve should not be there in the first place: heavy resource use in constructors. Constructors should only construct, obviously, leaving other mechanisms to handle the use of external resources. But here is the snag: if you buy into this requirement for constructors you already use leaky abstractions. And again, you might not be able to change the constructors.

  Consider, though, the way this pattern works. It is based on the fact that no matter when you request the instantiation of a class, you would have a ready implementation of IServiceProvider. The fact that the service locator mechanism exists is already lazy instantiation on the GetService method. In fact, this lazy injection pattern is itself a constructor dependency injection abstraction of the service provider pattern. You could just as well do var timeService = _serviceProvider.GetService<ITimeService>() inside your GetLocation method and it would do the exact same thing. So this is another reason why you should not do it: mixing the metaphors. But hey! If you have read this far, you know that I love mixing those suckers up!

Conclusion

  In conclusion, I cannot recommend this solution if you have others like refactoring available. But in a pinch it might work. Let me know what you think!

  BTW, this issue has been also discussed on Stack Overflow, where there are some interesting answers. 

and has 0 comments

  I wanted to read something by Larry Niven, so I've decided to go with The Mote in God's Eye, written in collaboration with Jerry Pournelle. I may have read it a long time ago, decades past, because I remembered one particular line from it, but just that. And it is a wonderful book. I guess I appreciate it now more than I would have ever appreciated it in my childhood because now I know what kind of crap can be sold as science fiction and also how ridiculous most science predictions from 1975 turned out to be.

  This book stands the test of time and the test of writing and the test for science fiction. The first one, for me, it's the more extraordinary, but it is helped a lot by the second. It takes a certain amount of maturity to decide to write something respectful to the reader and only include the minimal technical and scientific descriptions required to fully describe the situation. As for the third, I think the genre is defined by asking "What if?" and taking it to a plausible technological extreme. And this book does it brilliantly.

  Imagine, if you will, what would happen when the Empire of Man will meet a race of aliens that are stuck in their solar system, but other than that older, smarter, faster and more advanced than we are. The slight anachronism of the book allows for people to discuss what should be done before anything is decided, that both military, political and civilian agencies get to have a say. To get the scientists be actual caring people who argue their cause and viewpoint, the soldiers actual caring people who think about what their best choice should be in concordance with their beliefs, thoughts as well as their orders and to have nobles that care about their empire and their people and listen before they decide. Imagine that in a recent fiction book.

  I don't want to spoil it. The species of the "moties" is defined and explored very well, as are the humans and their society. It was interesting to me that the less plausible things were not technological, but biological and medical. We've come a long way since fifty years ago in that area and I am glad to see it. The ending of the book had a much slower pace than the rest. I felt like it was going to end, but it just kept going. It is important to reach the end, but that's just about the only problem I have with the book: the pacing problems at the end.

  Bottom line: I forced myself to start reading another book because I wanted to immediately read the entire series, which contains an immediate sequel, a prequel and a 2010 sequel written by Jennifer R. Pournelle, the original author's daughter. I highly recommend it. 

  MultiSelect is a Kendo UI control that transforms a select element into a nice dropdown with text filtering which allows the selection of multiple items. This is how you use the same control to write values directly in the list, something akin to the Outlook address bar functionality.

  Long story short: the control exposes some events like: 'filtering','open','close' and 'change'. In the filtering event, which is fired by someone writing or pasting text in order to filter the list of items, we dynamically create a list item that holds that value, so that the user can just press Enter and enter the value in the list. The code also allows for a custom transformation function, so for example someone could enter "1,2,3" and it would be translated into three values 1, 2 and 3 instead of an item with the value "1,2,3". On the close and change events we clear the items in the list that have not been selected. This means you cannot use this code as is to show an autocomplete list and also add dynamic values, but it is easy to tweak for that purpose.

  In order to use it, instead of doing $(selector).kendoMultiSelect(options), just use $(selector).kendoDynamicMultiSelect(options). Here is the code:

$.fn.kendoDynamicMultiSelect = function (options) {
  var multiSelect = $(this).kendoMultiSelect(options).getKendoMultiSelect();

  multiSelect.bind('filtering', function (ev) {
    var val = ev.filter && ev.filter.value;
    if (!val) return;
    
    var dataSource = ev.sender.dataSource;
    var items = dataSource.data();
    
    // if there is an existing item in the list, don't create a new one
    var existingItem = items.filter(function (i) {
      return i.value == val;
    })[0];
    if (existingItem) return;

    // find or create the item that will hold the current filter value
    var inputItem = items.filter(function (i) {
      return i.isInput;
    })[0];
    if (!inputItem) {
      inputItem = dataSource.insert(0, { isInput: true });
      // when inserting a value the input gets cleared in some situations
      // so set it back 
      ev.sender.input.val(ev.filter.value);
    }
    inputItem.value = val;
  });

  // cleans input items and also applies an optional value transformation function
  var updateValues = function (ev) {
    var values = ev.sender.value();
    if (typeof options.valueTransformationFunction === 'function') {
      // for example split comma separated values
      values = options.valueTransformationFunction(values);
    }

    var dataSource = ev.sender.dataSource;
    var items = dataSource.data();
    for (var i = 0; i < items.length; i++) {
      var item = items[i];
      item.shouldBeKept = false;
    }

    // add items for existing values
    for (var i = 0; i < values.length; i++) {
      var value = values[i];
	    
      var item = items.filter(function (i) { return i.value == value; })[0];
      if (!item) {
        item = dataSource.add({ value: value });
      }
      item.isInput = false;
      item.shouldBeKept = true;
    }

    ev.sender.value(values);

    // delete all others
    for (var i = 0; i < items.length; i++) {
      var item = items[i];
      if (!item.shouldBeKept) {
        dataSource.remove(item);
      }
    }
  };

  multiSelect.bind('change', updateValues);
  multiSelect.bind('close', updateValues);
};

I kind of copied this code by hand and tried it on another computer. If you find any bugs, let me know. Also, I know this is old time tech, but they use it in my company and I couldn't find this functionality by googling it, so here it is.

I hope it helps.

OK, so I played a little with SQL and I found an interesting flow for analysing queries. It uses the SET STATISTICS PROFILE functionality, but the results of this are usually hard to read and handle in any meaningful way. There are applications that help out with this, but this blog post is trying to show you a method that doesn't need any extra software (for when you are working for a paranoid company that doesn't allow you to install what you need to do your work, for example).

This works in the query itself, so no need of any extra tool except SQL Server Management Studio and Excel:

  1. Add SET STATISTICS PROFILE OFF at the start of the query (because you don’t need to profile the setup)
  2. Add SET STATISTICS PROFILE ON just before the SELECT that you want to optimize
  3. Clear cache and stats - this is optional, but good practice. There are multiple ways of doing this and it depends on your environment and preferences, so I am not covering this here.
  4. Execute the query -> In the query results you will get the results of the query, but also the profiling statistics of the query execution, also in table form
  5. Copy the entire statistics table with headers and insert it into a new Excel sheet
  6. Add a new column right after Parent, call it IsLeaf
  7. Fill the IsLeaf column with a formula to see if the value in NodeId exists in the Parent column
    1. Write "=COUNTIF($F$2:$F$10000,E2)=0" as the first value of the column
    2. Keep pressing Shift, then press End and Down arrow (and release Shift) – you should have the entire column selected
    3. Press Ctrl-D
  8. Select the header row of the table
  9. Click on "Sort and Filter"
  10. Select "Filter"
  11. Click on a random cell, click on "Sort and Filter" again
  12. Click on "Custom sort"
  13. Select TotalTreeSubcost and "From largest to smallest"
  14. Now click on the filter on the IsLeaf column and filter on value TRUE (only the leaves)

You should now have the rows of the final tree branch nodes, ordered descending by the cost to the query.

Here you can look at the IO cost, CPU cost and Rows columns to find the places you need to work on. These values need to be as small as possible.

I hope this helps.