Wednesday, October 19, 2016

The evolution of web development

Custom HTML Attributes Are Evil


HTML is itself a static content, and many developers have used the specification <!DOCTYPE >, which points out that it is merely a document.
The dynamic part is represented by JavaScript language. And here arose the problem.

Looking how various programming languages are used to build UI reveals that the language itself is a part of UI blocks. For example, Windows Presentation Framework uses XAML with C# controls:
<Grid Background="#555555" Width="400" Height="300">
    <Button Click="OnButtonClick">Press me</Button>
 </Grid>

Here will be created an instance of Grid class and an instance of Button class. Also it is possible to write logic whatever we like inside custom controls as they are just usual classes:
class Grid {
     public Color Background {get; set;}
     // methods and other UI logic
}
The same is true for Java with Android layouts, and many other languages and platforms.

HTML initially does not provide such idea, it does not link <html-element> to a JavaScript instance. To enhance it we can simply declare HTML elements as objects of JavaScript types:
  class div {
     public string style {get;set;}
     // methods and other UI logic


     render: function(){
         // return real html '<div>'+content+'</div>'
     }
  }
  class MyWindowPopup {
     public boolean fullScreen {get;set;}
     public boolean visible {get;set;}
     // methods and other UI logic

  }

Then it becomes possible to build pages and components in a common way:
   <MyWindowPopup visible="true" fullScreen="false">
     <div>Popup text</div>
   </MyWindowPopup>
Moreover we can advance some property types, e.g. use string[] array instead of string for class property <div class="typeof string[]">.

Then a browser or a server (NodeJS) is simply converts JavaScript to HTML and shows layout to a user. This approach took Facebook team with React and its JSX style.
---------------------------------------

Many other teams try to overcome HTML static nature by putting custom attributes, which seems very strange and inconvenient for me. Angular, Vue.js, Aurelia.js and many other JS frameworks use logic with custom marks (*ngIf, v-if, bind.click):
<div *ngIf="currentHero">Hello, {{currentHero.firstName}}</div>
<div *ngFor="let hero of heroes">{{hero.fullName}}</div>

JavaScript Monopoly


Nowadays JavaScript is the king of UI and there is no alternative.
I think every team that works with Web tried to create a converter from their languages to JavaScript. However this approach produces massive bunch of problems due the nature of languages.

Google created GWT where Java is converter to JavaScript and developers can write kind of UI logic in Java. Also Google tried to apply usage of Dart language in modern browsers and again created conversion to JavaScript.
Microsoft uses aspx controls that can be written in .NET compatible language, Razor views, and TagHelpers in Asp Core, which all finally are converted to JavaScript and HTML. You can find same idea for Elm, Python, PHP and other languages.

The problem is that JavaScript and C#, JavaScript and Java, JavaScript and [your favourite language] are very different beasts.

Javascript is a prototype-based language with first-class functions. There is no even idea of an object instance of a class (class declaration leads again to a function). There are just six types in JavaScript: Object, Number, String, Boolean, Null, and Undefined, plus some object helpers like RegEx. There is no even notion of Integer or Decimal type because JavaScript Number only holds double-precision 64-bit format value. Run in a JS console "0.1 + 0.3" and see what you get, while with Decimal types in C# the result will be "0.4".

Thus, developers restrict their language of choice too much and loose the power of JavaScript. In addition to these points most of the time they loose highlighting and intellisense while producing JavaScript and HTML as a string, e.g. in Asp Core TagHelpers:

     public class IconTextTagHelper : TagHelper
    {
        public string  Glyph { get; set; }
        [HtmlAttributeName("class")]
        public string ClassName { get; set; }

        public override void Process(TagHelperContext context, TagHelperOutput output)

        {
           string classnames = String.IsNullOrWhiteSpace(ClassName) ? "icontext" : "icontext " + ClassName;
                output.TagName = "a";
                output.TagMode = TagMode.StartTagAndEndTag;
                output.Attributes.Add("class", classnames);
                
                output.Content.SetHtmlContent(
                // String, string, string

                   $@"<span>
                          <i class=""icon fa fa-{Glyph ?? ""} icontext__icon""></i>
                          <span class=""icontext__text"">{this.Text}</span>
                      </span>");                     
        }
    }
 A way better solution is to work with JavaScript itself, or even better with TypeScript, which provides static type checking.

Breaking JavaScript Monopoly


To overcome the monopoly of JavaScript the IT community are making an attempt to specify WebAssembly, which later can be supported by browsers vendors.
The idea is very simple:
   Browsers will support agnostic language (through ASTs) that will include many features from modern languages. It will be some kind of Intermediate Language that is used in Java and .NET virtual machines nowadays. It will be faster to parse, faster to transfer, faster to run, it will be in binary format instead of text format of current JavaScript.

Sadly web development progress is very slow.
The web community still tries to build some kind of XAML with its custom components, inline styles, namespaces and modules.
It is 2016 and only now we have Flexbox, which is analogue of StackPanel in WPF for arranging elements horizontally or vertically in a single line. And what about Grid,  without a hack and whistles there is no way to do it in modern CSS, only recently W3C CSS Grid specification has passed from a Draft type to a Candidate Recommendation type.

There are so many bright minds in our realm but the overall picture is appalling.

P.S. JavaScript word is used for convenience, while ECMAScript is the proper notion in some places.

Saturday, October 15, 2016

SPA

It is common nowadays to have the acronym for SPA as a Single Page Application.

Nevertheless the actual meaning is quite different, the page is not single, the page is actually shelled.

SPA approach has the same idea as in a mobile application or a thin desktop client. A user downloads a thin shell for the app: a header, a footer, a body placeholder and possibly sidebars. Then asynchronously this app updates the content for the placeholders, while footer and header is not reloaded.

From a user experience the app is working with several navigation links and many pages. So calling such shelled app layout as a one page sounds misleading.


SPA = Shelled Page Application


Wednesday, October 12, 2016

Application workflow strategy and Staging verbosity

One of the famous app flow strategies is DTAP, which is acronym for Development Testing Acceptance Production.

Let us consider each step in detail, but before this let us make step back and add a source control and a continuous integration step for the full picture.

The scheme represent a de-facto standard in current development process.

Source control
  • holds project source files and likely provides history changes, as project branches and users control management.

Continous integration 

  • a continuous integration tool checks for the source control changes, grabs source files from the source control and builds the projects;
  •  runs unit tests;
  •  produces artifacts (application packages) that are ready for publishing;
  •  publishes the app to Dev server;
  •  for the published app runs smoke tests, which check basic and the most important functionality, e.g. products are displaying and a user can log in and pay for a product;
  • for the published app runs functional tests, which makes in-depth testing of the whole application pretending to be a human tester, e.g. opening Internet Explore browser, opening page with the contact form, filling contact data and submitting it, checking that email is received or was added to a fake queue.
    (Note: most of the time CI tool cannot itself run Smoke or Functional tests as there is a need to have visual APIs in the operating system, which provides ability for example browsers to be installed or other GUI apps. For these purposes special test apps are built with tools  like SelenuimHQ and are placed on a Dev server (or other suitable place with support of reach GUI), while CI tool can be installed in the cloud or a small linux server without rich GUI support. Then CI tool requests from the Smoke/Functional test app to run these tests.
  • finally we can guaranty that the app is almost fully functional on the dev server, otherwise if any of the previous steps are failed the responsible person will be notified about the problem.


Then we have the following steps for the application:


Dev environment

  • holds automatically tested application;

Test environment

  • if you have testers in your team this place is for them;
    the app is tested by testers in isolation from other steps
  • tester makes subtle tests as the app is already tested automatically;
    if there is a bug, then one of the functional test is missing, which should be added by developer in the fix process
  • a CI manager can manually request CI tool to propagate the app to Test server(s) after Dev phase
  • another approach is to automatically propagate the app from Dev phase to Test phase by CI tool when you have versioned app running simultaneously or several Test servers, so that testers will not be interrupted while they are providing tests

Acceptance (also known as UAT/User Acceptance Test) environment
  • holds application that waits for a testing from a stakeholder/ a customer;
  • if there is no tester in your team you can propagate (manually or automatically) the app from Dev to UAT phase with CI tool
  • A stakeholder makes tests and whether accepts or rejects the changes
Note: environment can be presented by different amount of servers and machines. For example Dev, Test and UAT environment can be hold on a one server, or in other case Test environment can be hold on N-servers.



STAGING

Although DTAP model is obviously clear there is another step called Staging. I've phased a lot of confusion with Staging step among developers as there is no single definition for it.
Some people argue that Staging is another name for UAT step.  Other people go further and combine Test step with UAT step and call this combination as Staging. Any of this is definitely valid while you have one concept across your whole team.
Nevertheless personally I prefer to have the notion of Staging as a pre-production step. What does it mean? Let us look at the image from Steve's blog post about staging in Azure.



Staging is an additional step before publishing an app to a production environment.

Staging

  • is propagated from UAT phase after a stakeholder approval
  • holds the app ready to go live in production;
  • has connection settings (database, email server, and so on) the same as in production 
  • CI tool runs Smoke tests to verify critical functionality
  • if needed a stakeholder or a developer can manually verify some special points
After all theses steps are done Staging can be simply swapped with a Production environment, for example for a website by changing routes in a hosting tool (IIS, Nginx, Apache). Thus staging becomes production, while production becomes stale staging, which can be removed or used as a backup. This approach is known as Blue Green deployment.