Creating Gmail in 3 minutes using C#, ASP.NET Core and Magic

For those not following me on GitHub, I can inform you that I have created a new “Starter Kit” framework called Magic. Its purpose is to be a kickstarter for your own ASP.NET Core web API projects, allowing you to rapidly get started with creating your own HTTP REST web APIs. In the video below I am demonstrating how I use this to create a webmail backend, for both sending emails over SMTP, and retrieving emails over POP3. The idea is to create commoditised solutions for most common problems, to avoid repeating myself, and hopefully also to encourage you to also keep your code DRY.

The project(s) are Open Source, but a commercial license path exists for those wanting to create closed source apps, which will cost you in total €100 for both projects; Magic Core and Magic Email. In the above video I am using;

Advertisements

Teach yourself DDD in 15 minutes

DDD or Domain Driven Design is one of the most difficult thing to learn. Entire libraries have been written about the subject, and many senior developers have spent decades trying to learn it, often unsuccessfully may I add. Its elusiveness for software architectures, sometimes feels almost like the equivalent of searching for the grail. At the same time, it’s considered the most important concept to know for a software architecture to be considered a senior architect among his peers. However, if you simplify DDD, and create generalisations around its ideas, it’s actually pretty simple to understand.

I have created a Micro Framework for ASP.NET Core web APIs that allows you to browse its 400 lines of code in 20 minutes, and afterwards actually have not only a pretty strong grip upon DDD, but also your own tool to start using DDD in your own solutions. In essence, it’s a starter kit for ASP.NET Core web API development, that creates a template for you, that makes sure you’re following all best practices if you follow a simple recipe as you create your own web APIs.

The basic ideas are DRY, DRY and DRY – As in “Don’t Repeat Yourself”. By following this axiom as deep into the Rabbit Hole as possible, you end up with a framework, that allows you to create your C# apps, literally without coding almost at all.

Check it out for yourself here

Work and live on the island where Aphrodite was born

Nissi beach in Ayia Napa, possibly one of the most beautiful beaches in the world.

I probably have the most beautiful commute in the world. I wake up at dawn, I enjoy my coffee on me balcony, from where I can enjoy the warm sun 9 months of the year, overlooking the sea – And on my way to my office in Limassol, I drive past the place where legend has it Aphrodite was born. I work in a pleasant environment, in one of the nicest office buildings in Limassol, with great colleagues, and a nice leader, always willing to listen to my opinions. In fact, I actually asked him if I could write this blog, and he instantly said “Love it, go for it!” You should envy me.

In my weekends, me and my girl often enjoy one of the beautiful beaches that are just some few kilometres away from where we live, or we go visiting one of the thousands of amazing tourist attractions on the island, such as the oldest Christian monastery on earth, Nissi Beach in Ayia Napa, or maybe we bring our mountain bikes to Troodos, to go “off roading”, while filling up our bags with chanterelle on our way back home. Cyprus simply has everything you can dream of.

My office 🙂

Below is a photo from the “top of the Island”, the mountain of Troodos, who’s highest peak is named after the place where the Greek Gods lived; Mount Olympus!

You simply can’t beat this view!

However, there is one thing missing here, and that is YOU! If you’re a software developer, which you probably are if you’re reading my blog, we would love to talk to you. You see, London Capital Group which is my employer, are looking for more software developers. Specifically, we’re looking for .Net developers, in addition to one SugarCRM/PHP guru. However, if you’re among the best of the best, you probably realize like I do, that life is more than work. So why should you choose us instead of some other company? Well, Cyprus is the answer. Below is one of my favourite spots on the island. I have stood on top of that rock many times, enjoying the view to the sea, from where I have dipped my body into many times. According to legend, you grow 10 years younger if you swim around that rock three times 😉

The view from Aphrodite’s Rock, where legend has it Aphrodite was born from the sea

Sure, we might not be able to meet your City of London salary expectations, but then again your living costs are basically half of what a one bedroom apartment in the City of London will cost you. And for the price of a train ticket in London, you can take your girlfriend to dinner, go to a cinema, and still have a handful of euros left afterwards for a couple of beers. And the best part is that in your weekends, you can experience first hand why this is the Island of Love and Aphrodite. Maybe you’ll meet me and my girlfriend, as we are enjoying a bottle of wine, at one of the hundreds of beautiful beaches down here, often at night, during the weekends, under the full moon.

If you want to hear more, feel free to write me an email at thomas.hansen@lcg.com, and hopefully we’ll meet you soon. Welcome to Cyprus 🙂

Yours truly swimming in Larnaca, where legend has it Lazarus used to live.

Do you want to share my paradise? Send me an email then, and let’s talk. My email address is thomas.hansen@lcg.com – See you down here 🙂

Microsoft to bury .Net Framework

Notice, I have this information from a credible inside source, and no I won’t tell you who. However, apparently Microsoft has plans to bury .Net Framework as of version 4.8. This means that version 4.8 will be the last update to .Net Framework to ever be released by Microsoft.

Apparently all focus is on .Net Core in the future. The reasons I assume is that .Net Core is platform agnostic, and Microsoft apparently no longer have an interest in creating lockins towards their own Windows systems. However, think about the ramifications of this for a while …

For instance, no more WCF, no more WPF, no more WinForms, no more WebForms, the list goes on …

Personally, I must admit I have mixed feelings to this. On the one hand, there’s a millions methods and classes I have grown accustomed to in .Net Framework, which simply does not have an equivalent in .Net Core. At the same time, I love the idea of cross platform development, and every time I have to mess with Mono to get my stuff working, it seems to create head aches for me. I also adore the modularity of .Net Core, which is in extreme contrast to the monolithic nightmare of .Net Framework …

However, .Net Framework will be killed by Microsoft, and the last major upgrade will be version 4.8. How they intend to do it, and if they intend to create security releases for a decade or so, fixing security holes the way they usually do when they snuff their own stuff, I don’t know. But one thing is certain, if you’ve got intellectual investments on .Net Framework today, you’d better start reading up on .Net Core – Otherwise I assume you’ll end up as the dinosaurs …

Extending Linux and Mac with C#

In the following video I play around with a simple Console application, which allows me to evaluate Lizzie snippets, which I again extend with C# methods. This allows me to create cross platform daemons and shell extension scripts, that can be evaluated in a Mac, a Linux machine, or a Windows machine. Since Lizzie is a scripting language, it also allows me to dynamically change whatever my snippets do, and use the same “host” for multiple scripts.

You can find the code I am using beneath the video. My personal use cases ranges from build scripts, to all sorts of automated jobs, where I need to do more complex stuff than what a simple bash script allows me to do. The additional benefit of course is that my scripts are cross platform. Expanding upon the code to allow for it to take multiple files, would obviously be easy.

Here is the code I ended up with as I wrapped up the video …

using System;
using System.IO;
using lizzie;

class MainClass
{
    [Bind(Name = "write")]
    object WriteLine(Binder<MainClass> binder, Arguments arguments)
    {
        Console.WriteLine(arguments.Get(0));
        return null;
    }

    [Bind(Name = "read")]
    object ReadLine(Binder<MainClass> binder, Arguments arguments)
    {
        return Console.ReadLine();
    }

    public static void Main(string[] args)
    {
        // Figuring out file caller supplied
        if (args.Length != 1) {
            Console.WriteLine();
            Console.WriteLine("**************************************************************");
            Console.WriteLine("*     Add a filename you want to evaluate as an argument     *");
            Console.WriteLine("**************************************************************");
            Console.WriteLine();
            return;
        }
        var filename = args[0];
        using (var reader = new StreamReader (File.OpenRead(filename))) {
            var lambda = LambdaCompiler.Compile(new MainClass(), reader.ReadToEnd());
            lambda();
        }
    }
}

Lizzie, a Turing Complete “Structure Query Language” for your server

Although Lizzie is only in its first initial 0.5 release, and not mature by any measure, I must confess that I have a lot of ideas in regards to it. First things first though, Lizzie will highly likely never grow particularly much in size. This is because of its extendible architecture, that allows you to extend it as you wish. Sure, I’ll fix bugs in it, and I might add one or two additional features, but Lizzie is not one of those programming languages that’ll simply pack features upon features until it’s all fat and muddy.

Not because I don’t want to add features to it, but because it’s not necessary to add features to it, since if I miss some feature, I can simply create a delegate and add to my “binder”, or create a method on the type I bind to it, and such easily extend the language, without modifying it. Below is an example.

using System;
using lizzie;

class MainClass
{
    // This method will be available as a function in your Lizzie code
    [Bind(Name = "write")]
    object Write(Binder<MainClass> ctx, Arguments arguments)
    {
        Console.WriteLine(arguments.Get<string>(0));
        return null;
    }

    public static void Main(string[] args)
    {
        // Some inline Lizzie code
        var code = @"
var(@foo, 57)
write(foo)
set(@foo, +(foo, 10))
write(foo)";

        // Creating a tokenizer for our Lizzie code
        var tokenizer = new Tokenizer(new LizzieTokenizer());

        // Creating a lambda function from our code, using the above tokenizer
        var function = Compiler.Compile<MainClass>(tokenizer, code);

        // Creating an instance of our class, which we can bind to our Lizzie code
        var context = new MainClass();

        // Creating a binder, and adding some pre-defined functions to it
        var binder = new Binder<MainClass>();
        binder["var"] = Functions<MainClass>.Var;
        binder["set"] = Functions<MainClass>.Set;
        binder["+"] = Functions<MainClass>.Add;

        // Evaluates our Lizzie code, making sure we bind it to our instance
        function(context, binder);

        // Waiting for user input
        Console.Read();
    }
}

Notice how the “write” function is not something that actually exists in Lizzie, but available to my Lizzie code, since the type I am binding my code towards have that method, and have marked it with the “Bind” attribute. This adds a new “keyword” to my Lizzie code, that I can use internally within my Lizzie code, to invoke C# methods, having access to the “context” that my Lizzie code is evaluated within.

With the ability to easily extend a programming language such as I illustrated above, the need to expand on the language simply isn’t there. So Lizzy will probably never grow much in size beyond its current codebase, which is surprisingly small, ~2 KLOC in fact. In such a way, you might argue that C# becomes the equivalent for Lizzie as Macros are to Lisp.

The above extension abilities though, opens up a really interesting axiom I think myself – Which is the ability to create generic functions such as I do above, that solves generic problems, such as (securely) querying your database for instance. This allows for me to create a handful of methods, where I can use Lizzie as the “query language”, deciding what I want to evaluate on my server, and have that code translated to SQL, according to what authorisations the client has to do some particular operation on some particular table. This again allows me to for instance create a single HTTP REST endpoint, that accepts Lizzie code as input, and returns JSON to the caller – Which of course allows me to create a web app, where the server side doesn’t contain a single line of business logic code, and my JavaScript client transmits Lizzie code to the server, which effectively *is* my business logic. And in fact, I am confident in that I’ll be able to pull it off securely, such that having a client inject malicious code that is to be evaluated on my server, becomes literally impossible. This just so happens to tie in perfectly well with “fat client frameworks”, such as Angular and React, where the assumption is that you’re supposed to build your entire application on the client, and simply use the server as an HTTP REST endpoint. The only difference is that instead of POSTing JSON, and having JSON returned, you POST Lizzie code, yet still get JSON in return.

Then the job of authorising whether or not a specific client is legally allowed to perform some specific operation or not, becomes a simple configuration job on the server, allowing me to “declare” which tables and operations a specific client is legally allowed to do, according to some role based security map, which decides which server side methods Lizzie code transmitted from that particular client will load up, and allow that particular client to execute – And if a client is not authorised to execute some specific “keyword”; Exceptions! Which allows me to use the same HTTP REST endpoint to retrieve any data from any table in my database on the server side, including aggregated values and joins, without opening up for security holes, effectively turning Lizzie into the equivalent for servers in general, as what SQL is for your database. Creating methods that are not related to databases is also easy may I add, such as creating a method that allows an (authorised) client to send an email, change a configuration setting, etc, etc, etc – Is obviously equally easy, and can be done securely, without opening up a “can of worms” in regards to security …

In such a way, Lizzie might prove to become the “Structured Server Side Query Language” of computing. Simply put, because what man would I be, if I didn’t have a bunch of fancy acronyms, to describe my axioms … 😉

SSSQL for the masses 😀

Lizzie, a scripting language for .Net

I have just released Lizzie, probably the smallest programming language in the world. Its documentation are 12 pages of printed text, and the entire source code for the language is roughly 2,000 lines of code. The compiler is only 500 lines of code, most of which are comments. You can literally teach yourself Lizzie in 20 minutes.

Lizzie is a dynamically “compiled” script language for .Net, that is so blistering fast to compile, I can compile 10,000 snippets of Lizzie code on my own computer in roughly 2 seconds. Since everything “compiles” down to CLR delegates, it is also surprisingly fast when executed.

The idea is to create a dynamic script language for the CLR, that allows for easily creating Domain Specific Languages, to solve problems related to your domain – While at the same time, making the language so secure by default, that it literally is impossible to execute malicious code written in Lizzie out of the box. Extending Lizzie with your own “keywords” is as easy as marking a method with an attribute.

Check it out here

New CSS skin – NUX

In my latest release of Phosphorus Five, there’s now a new default Micro CSS skin called “NUX”. Its name implies “!UX”, since I have tried to make it very much minimalistic. The idea is to create a skin, completely free from colours and other types of “bling”, to allow for higher readability and more easily navigate your app’s actual content. You can see a screenshot of it in the above right corner. If you’d like to see the screenshot fullscreen, feel free to simply click the image.

Below is an example of how Hyper IDE looks like when using this new skin.

I feel the content of your apps becomes more visible, and emphasised, simply since there are less colours in this skin. It also significantly increases the sizes of clickable elements, such as radio buttons and checkboxes. Which I feel makes it more usable for smaller devices, such as tablets and phones.

In addition to the NUX skin, I have also created a couple of new convenience widgets, for more easily creating checkboxes and groups of radio buttons. And I have also significantly improved the rendering of Camphora Apps on smaller devices, and in general. Below is a screenshot of the “sales” app.

Feel free to check it out 🙂

Encapsulating your system through the file system

To a seasoned developer, the above sentence might sound like a Haiku. Something a computer might have generated automatically by following the rules of grammar, to create random sentences, incapable of communicating meaning. However, here’s an example of what I mean. Feel free to browse the “imp” folder to understand what I mean.

Hyperlambda has no namespaces, no classes, no private or protected keywords – Still, I’d argue it allows you to create much better encapsulation of your code. Simply since I can evaluate files as if they were functions. I can pass in arguments to my files, and do something resembling the following.

eval ("/backend/tickets/model/get-ticket.hl", id:5)

The above code is of course pseudo code, however its actual implementation is surprisingly similar in syntax. You can see it below. What it returns, is pretty obvious I assume.

micro.evaluate.file:@INGEN/imp/backend/tickets/model/get-ticket.hl
  id:x:/../*/id?value

Let’s use another example, how I build the toolbar in the top right corner of the system.

  micro.widgets.file
    class:strip themepark-top-buttons
    folder:@INGEN/imp/common/toolbar-buttons/

It doesn’t require a rocket scientist to understand what that code does, or? Here is the folder it’s pointing to. If you take a look at one of its buttons, you’ll see something like this.

button
  innerValue:@"<span class=""icon-key""></span>"
  oninit
    whoami
    if:x:/@whoami/*/default?value
      !=:bool:true
      delete-widget:x:/../*/_event?value
  onclick
    desktop.authentication.login

Even without its comments, I believe most 10 year olds would instantly understand what the above code does. Below is a screenshot of what happens when I click the button. Notice, the screenshot below, including the button to trigger it, was created with no more than 9 lines of code.

Creating a new toolbar button, is as easy as creating a new Hyperlambda file, and putting it in the “/imp/common/toolbar-buttons/” folder. How many lines of code would you need to create something like the above in C#? Let’s try to imagine that as a thought experiment …

First we’d need support for dynamically loading up controls to populate our toolbar. This would probably require at least some 3-4 different design patterns, such as an Abstract Factory, Factory Methods, etc. Each button would have to implement some interface. Then we’d have to create some sort of JavaScript frontend part, allowing us to actually click the button, and creating an Ajax HTTP request, which does whatever the button does once clicked. A qualified guess would be.

  1. Factory methods and classes to dynamically populate toolbar ==> easily 300 – 500 lines of code
  2. Interface for buttons ==> probably 50 – 100 lines of code
  3. Each button’s C# file ==> between 50 and 500 lines of code, depending upon what the button does
  4. JavaScript to create our Ajax HTTP requests ==> At least 100-200 lines of code for each button

And we’d end up with a solution where even the smallest change in one of our parts, often would result in cascading effects, forcing us to change every single button, and every single part of our solution. For instance, adding another argument to our interface method results in having to change every single code file. Even with a conservative estimate, the above would result in 800 lines of code for three simple buttons – Possibly as much as 2,900 lines of code. I don’t think many seasoned developers would object to these numbers. If you don’t count the comments, the Hyperlambda equivalent becomes

  1. 3 lines of code for the toolbar
  2. 35 lines of code for all buttons

That’s 38 lines of code! Versus 800-2,900 lines of code. If we were to use our worst possible estimate from our C# solution, it would require 82 times as much code! Since the amount of cognitive energy you have to apply to a software project is directly proportional to the number of lines of code your solution contains, this results in that a pure C# solution would require possibly 82 times as much cognitive energy to be understood as its Hyperlambda equivalent. This translates into that if you require 5 minutes to understand the Hyperlambda code, you’d need almost 7 hours to understand the C# solution.

  1. Hyperlambda ==> 5 minutes, 38 lines of code
  2. C# ==> ~7 hours, 2,900 lines of code

All of these numbers I played around with here are numbers that most seasoned system developers could easily agree with me in regards to, so I cannot be blamed for having skewed the numbers in any ways. In addition to that purely mathematically the C# solution would require 82 times as much energy, it also contains 2 different programming languages (JavaScript and C#). On top of that, it contains several design patterns, to facilitate for creating a plugin architecture capable of dynamically loading buttons. Possibly some sort of configuration file (JSON/XML?) too, to declare which buttons you want to load. Hence, the C# solution would literally be scattered with dependencies, making even the tiniest change in any one of those files, possibly cascade into all 2,900 lines of code – Forcing you to effectively rewrite your entire solution, due to adding a single additional parameter to the instantiation of your buttons (style argument …?)

While for the Hyperlambda solution, all you’d have to do would be to change the [micro.widgets.file] invocation from above, to resemble the following.

micro.widgets.file
  class:strip themepark-top-buttons
  folder:@INGEN/imp/common/toolbar-buttons/
    style:"padding:3rem;"

One additional line of code, compared to spending an entire afternoon rewriting interfaces and implementations. The above addition to my toolbar changed my buttons from this …

… to this …

It doesn’t take a rocket scientist to understand the advantage here … 😉

So while the C# developer is changing his interface to pass in style arguments to the instantiation of his buttons, editing literally every single code file in his solution, spending the better parts of an entire afternoon – Assuming he understands the code in the first place, and don’t need 5 days to simply understand the class hierarchy. I’ve moved on to the “next problem” literally after 2 seconds!!

Didn’t like my style argument? Well, OK – Let’s create an [onmouseover] event, that displays the title attribute in an “information bubble” window for our buttons.

micro.widgets.file
  class:strip themepark-top-buttons
  folder:@INGEN/imp/common/toolbar-buttons/
    onmouseover
      get-widget-property:x:/../*/_event?value
        title
      micro.windows.info:x:/-/*/*?value

4 additional lines of code, and all of a sudden every single button in our toolbar displays something resembling the following when the mouse is hovered over the button.

How many hundreds or thousands of additional lines of C#/JavaScript/“whatever” do you think the above would need in literally any other traditional programming language …?

In case you didn’t like my above example, let’s do something more “hard core”. In fact, let’s invoke a web service, and let’s PGP encrypt our invocation and cryptographically sign our invocation. And just for the fun of it, let’s have the client supply the code that we evaluate on the web service endpoint. For then to have the web service verify the signature of our PGP key used to cryptographically sign our invocation, and allow specific PGP key signers to have “extended rights” during evaluation on our server.

/*
 * Invoking web service, passing in Hyperlambda to
 * be evaluated on my server.
 */
micro.web-service.invoke:"https://home.gaiasoul.com/hypereval/lambda-ws"
  fingerprint:ea630b9a61448b7f647045c210e1e050ce6feb1d
  encrypt:true
  lambda
    .foo:This code was evaluated on the web service endpoint
    split:x:/-?value
      =:" "
    return:x:/-/*?name

8 lines of code. In fact, I am so certain about that you’d need thousands of lines of code to be able to do something even closely resembling the above in C#, that I am willing to bet a kidney on that you can’t without at least some 5-10,000 lines of C# code! 8 lines of code replacing 10,000 lines of code. That’s an increase of 1,250 times the cognitive load to implement the above in C#. And for the record, the above code is working code. If you download Phosphorus Five, you can immediately paste it into “Hypereval” and execute it. It will evaluate the code inside of its [lambda] node on my server for the record!

If it takes 5 minutes to implement the above in Hyperlambda, it would require 104 hours to do it in C#!

A seasoned software architect and software developer might laugh of Hyperlambda, proclaiming it’s not a “real” programming language, since it doesn’t contain x, y or z. However, none of that matters, because when somebody skilled enough to understand it puts themselves behind the controls of that thing, they’re doing warp 10, and have crossed half the galaxy and returned – Before the competition has even managed to start up his steam engines …

It has no wheels, no visible engines, and no gearbox – How can you claim it’s a vehicle …?

Well, since a picture is worth more than a thousand words, I’ll finish this article with a picture and a simple question …

How would you want to travel today Sir …?

InGen Dinosaur Theme Park system, adding speech synthesis and guided tours

I put in a handful of additional coding hours today in the InGen Dinosaur Theme Park Software System,  and below is the results so far. So far I have spent about 10-12 hours of actively coding on the system, yet it’s still very feature rich, with among other things guided tours localised to “whatever” language using your browser’s speech synthesis features, and Google Translate to translate the tour into whatever language you want to have your tour in.

It features integrated QR codes that are automatically created as URLs leading to such tours, allowing the theme park to plaster these around at relevant locations, to provide their guests with guided tours, in as many languages as they want to. Watch the video below demonstrating the system.

I’ll probably add some additional 5-10 hours of coding before I consider it done. However, if you want to try it out, you can download its zip file, and simply upload it into any existing Phosphorus Five installation.