Just a bit side-off discussion — what kind of benefits does the package-private give? I mean more specific than “better encapsulation”. More like “what kind of problems you faced before that this strategy would mitigate/solve”?

I probably wrote too much, as teammates suggested converting it into a blog post…

Modularity

Why do we use private fields and methods when everything can be just public? List all the pros and most (if not all) of them would work at the package level. Then, at the module level, at the microservice level, etc.

High cohesion & encapsulation to put it simply. But it’s not all.

It’s all about making better abstractions and a more dev-friendly codebase. Reading code is more frequent than actual coding and it’s useful to have something like a table of contents to quickly verify if you look at the part that is worth reading at the moment. I see a proper usage of packages and package-private access as that.

Also, in that limited situations when you actually write code (😉), having much lower number of available classes/methods to choose from, makes it easier to choose a proper one. Less erroneous, and less likely to misuse that part of the codebase.

Enforcing package-by-feature approach

Still one can say, the world didn’t collapse because of not using package-private access. I think the same can be said about many other things, but is that our only metric?

How about organizing code using package-by-feature approach? It’s not as extreme as with package-private access, but I think most code I’ve seen was organized rather with package-by-type (a.k.a. package-by-layer) approach. Especially when counting in front-end codebases I worked with. Most code is organized like that, but it doesn’t mean it’s easier to work with such a code. See nice, thought-provoking examples at the end of this article: http://www.javapractices.com/topic/TopicAction.do?Id=205.

I think it’s obvious, but let me emphasize it

• Package-by-feature helps to have package-private access
• Using package-private access makes you think more in package-by-feature manner
• Contrary, package-by-layer forces you to use public access to make classes from different packages visible to each other

Default

There is another reason people don’t use package-private access as much as they could. It was meant to be default access (Java design), but then IDEs and alternative JVM languages made public a default. My (educated) guess is they went that way because package-by-layer approach was encouraged by Java EE, Grails and other frameworks.

Taking a wonderful IntelliJ as an example, you have 3 places to override settings to encourage package-private access:

1. Check Show Visibility Icons in Project Window -> Tree Appearance
2. Modify File and Code Templates under Preferences
3. Check a proper option under Code Style -> Java -> Code Generation

Because public is effectively a default, it’s in many articles, code examples, open source projects, etc. So fewer people think package-private access is useful, etc. And it drives itself.

Nevertheless, the original idea was to have a different default 🙂

Join the elite 😉

Despite the above, frameworks like Spring and JUnit 5 (fun fact: version 5 premiered in 2017) worked with Java’s default from the very beginning. So it’s not like no one was thinking about the package-private access. I’d even call these two Top Performers and I prefer taking the inspiration from them 😉

Implementing well-known patterns

There is a huge library of software design/integration/architecture patterns. You might not like package-private access, but willing to use e.g. Service Layer. My recommendation is to treat package-private access as a more convenient way of introducing the pattern. Treat it as an implementation detail and a helping technique.

Smarter code organization

One can still say packages should be used to organize the code and push towards package-by-feature approach and having 20+ package-private classes and one public Service or Facade class might not be the ideal organization.

My response is with Java’s default access as a default option you still use (sub)packages as the organizing structure, but you use them smarter 😄

• REST API and DTOs can go to a separate subpackage. It’s even better because you ensure RestController doesn’t expose anything “internal” from the part of the system
• Considering CQRS, a whole Query part can be a dedicated subpackage, containing just public classes
• The whole infrastructure part created with Spring can be a dedicated subpackage (Spring works perfectly with package-private access, remember? 🙂)
• Design patterns requiring class hierarchies can have their dedicated subpackages. E.g. strategy subpackage with a public interface and all package-private implementations

Thanks to promoting package-private access, you also discover files as a way of organizing your code. Something between the class and the package. I’d say it’s even encouraged with Java 16+ sealed classes, which can skip permits for same-file implementations.

Apart from files, I observed I started using Maven/Gradle modules better. E.g. you can extract adapters or api modules and use the same packages between them. So effectively you have like 20+ classes under a package but split into 2+ modules.

Real-life benefits

There are people much smarter than I who promote package-private access. I recommend taking a look at J. Bloch, Effective Java. Precisely, Item 15: Minimize the accessibility of classes and members. I also recommend watching

And my personal experiences connected with the above:

1. Not only I watched that talk 20+ times, but I also worked with the presented code for a moment, so I have some insight knowledge 😄

• It was something called “team tourism” at the company I worked and the presenter was on vacation when I worked with his team
• System was developed for a couple of years already and I was able to introduce a new, quite serious feature within a week. I mean from 0 to deploy it on production. I started working on Monday and the next Monday I got my first feedback from the end users (it was a back-office app)

Mateusz Chrzonstowski (mat3e) on Twitter: "I joined one of #developers team last Monday, I finished my task on Thursday, it was deployed on Friday. Today, I got first feedback from the end users.The power of #Microservices 😎 / Twitter"

I joined one of #developers team last Monday, I finished my task on Thursday, it was deployed on Friday. Today, I got first feedback from the end users.The power of #Microservices 😎

• There was a new team member there as well and he introduced a change, making one thing public. It was immediately caught by reviewers and comments were not like “rename this method”, but rather “is this a responsibility of that module”, “should this module know about that/expose that”, etc. Modularity was just a part of the team’s DNA. I see this as a side-effect of design, because looking at the team seniority, etc., it wasn’t a very experienced team

2. Closer to what is highlighted by Joshua Bloch — I guess you faced API versioning problems, didn’t you? When you have REST/events and there are already clients/other systems using them, you need to support old versions for almost forever 😄

• In one team we decided to introduce service clients rather than public API. Then, package-private access was really handy to hide things. Similarly to what you do with limiting your REST services, but at the code level. I also used service clients later, in another company, and just interfaces were left public there
• I also have some experience with autoconfigs, libraries and software plugins. Package-private access really makes these things easier to maintain. Contrary, what’s public has to be treated as “published” there

TL;DR

Modularity, ownership, security/confidence and freedom to change 😄

Java’s default access was originally published in The Glovo Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storage

Counter’s state has to be stored somewhere. Amazon offers a NoSQL database, but I was afraid it was too much. I googled a bit (with duckduckgo.com 😛) and found something which calmed me:

After reading that, I’ve created a simple table in DynamoDB (5). It’s a key-value store, so you can have an entry like that:

Lambda (6)

The logic behind the counter: to get its value, increment it, store a new value, return it through HTTP.

It’s not much, but it’s too much for a simple database. I went for AWS Lambda, which allows executing a simple code snippet. Serverless.

The best way of creating Lambda with an access to DynamoDB, exposed to the outer world is to create it from a blueprint. There is an existing template “microservice-http-endpoint” which does everything we want. With NodeJS:

Behind the scenes, this blueprint configures also CloudWatch (7), API Gateway (8) and the corresponding IAM roles and policies (9).

Wow.

IAM

Let’s start from the end. IAM stands for Identity and Access Management. This is a formalized way of handling permissions. S3 Bucket Policy was just for S3 and here we have a central place for all the policies.

Blueprint adds us a single role containing 2 policies: for Lambda to read from and write to DynamoDB and for Lambda to write to CloudWatch.

Roles and polices defined in IAM can be reused all over the services.

CloudWatch

This is a place when you can monitor your services — check logs and metrics and see some nice charts, telling you e.g. what is the average execution time of your Lambda and so on.

API Gateway

This is your way to expose something like Lambda from AWS! The screenshot tells it all:

Each building block is a place where you can add something, like e.g. additional mapping to the flow.

In API Gateway you can also configure which HTTP methods you want to support, you can go for Actions and enable CORS (it was needed to make a call from the browser) and you can specify stages on which everything is available. Example stages would be dev, test and prod. Then, you can expose different Lambdas under different stages or have the same Lambda, but e.g. with different Gateway limits, depending on the stage.

Show me the code!

As mentioned, you can write your Lambda logic using NodeJS. I used the 8th version of the runtime, but you can also choose Node 10 recently.

What is nice in both versions you can use async/await and then, what is returned, will be a response body and what is thrown and not caught, will cause an error response.

const AWS = require('aws-sdk');
const doc = require('dynamodb-doc');
AWS.config.update({ region: 'eu-west-1' });
const dynamo = new doc.DynamoDB();

const TableName = 'table';
const Key = { id: 1 };

exports.bumpCounter = async(event, context) => {
  const {Item: {counter}} = await dynamo.getItem({TableName, Key}).promise();
  return {
    statusCode: 200,
    body: JSON.stringify(
      (await dynamo.updateItem({
        TableName,
        Key,
        UpdateExpression: 'set #C = :counter',
        ExpressionAttributeNames: { '#C': 'counter' },
        ExpressionAttributeValues: { ':counter': (counter + 1) },
        ReturnValues: 'UPDATED_NEW'
      }).promise()).Attributes
    )
  };
};

At the beginning of the snippet, there are imports to use AWS mechanisms. To be 100% sure everything happens in my region of choice, I set it at the beginning with AWS.config.update function.

What is exported is our lambda. It’s an async function, which consumes 2 parameters — an event which triggered Lambda (HTTP request and its details) and the Lambda context. In the context you can have e.g. variables, which can be defined when configuring Lambda.

Then, I use DynamoDB client, which can work with await thanks to its promise() method. And, personally, I found these Expression things from updateItem confusing. At the beginning I had an update expression like

`set counter = ${counter + 1}`

but it was problematic as counter is a reserved DynamoDB keyword and there were some problems with the value passed like that. Therefore, I used template mechanisms from the client, where #alias is an alias for a table column and :alias — for its value.

It’s worth setting ReturnValue to 'UPDATED_NEW' to get a response with the changed database columns. Accessing Attributes from this response will give us exactly that.

In case of errors, you should rely on CloudWatch. I found it really helpful together with a plain ol’ console.log.

To be super safe when it comes to costs, you can set a number of possible parallel lambdas to 1.

What next?

Adding a simple visitor counter to our webpage, brought up another 5 services: DynamoDB, Lambda, CloudWatch, API Gateway and IAM.

But it’s not over.

Everything can be improved, e.g. by limiting CloudFront just to European countries and by limiting the access to S3 — it could be available only for CloudFront.

Also, what if our webpage becomes super popular and we will get close to DynamoDB/Lambda limits?

I encourage you to start #AwsVisitorCounterChallenge and to create a visitor counter with as many AWS services, as it makes sense. On your own!

Bonus: Chrzonstowski’s law

With my simple webpage I learned a lot about cloud computing. And reading about all the services and AWS users made me think about when should or shouldn’t you use a public cloud infrastructure.

As there is an empirical Conway’s law, I decided to make my own. If there is already something like this, just let me know. If no — enjoy a new law 😁

The larger the company the less, the more, the less and the more public cloud computing it needs.

[hypothesis] Until becoming a new public cloud provider.

It makes sense, doesn’t it? The higher on the y-axis, the more public cloud is used. Being on the “growing” part of the graph means the company is moving some of its work to the public cloud and — contrary — “falling down” part of the red line means the company is moving OUT of the public cloud.

Our lovely website as well as startups are almost 100% in the clouds.

Then, my company, allegro (which has like 17 mln users and 1 mln daily transactions) is using its own data centers to host 800+ microservices.

Then, Pokemon GO, which you could think was dead, appeared to get 147 mln active users in May, 2018. Number of users vary, depending on many conditions (e.g. the weather), so the scalability possibilities granted by the cloud are really important in this case. Pokemon GO relies on NoSQL database from Google Cloud and is the biggest deployed Kubernetes cluster. Ever.

Then, there is Dropbox with its outstanding number of 500 mln users. By moving out from AWS S3 to its own tech, Dropbox saved $75 mln in 2 years.

And, finally, we have Netflix. It is well-known AWS customer with 152 mln users, but almost twice as many people who actually use it. Netflix has heavy calculations per user and it uses its own CDN (The best way to express it is that everything you see on Netflix up until the play button is on AWS, the actual video is delivered through our CDN).

Will Netflix become the next public cloud provider? We will see… At some point in time, Amazon went this way to make use of its servers, which were not used up until Black Fridays and other Boxing Days.

How many AWS services do you need to host a static webpage? (2/2) was originally published in WarsawJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

The public cloud is just happening. Period.

I knew some of AWS/Azure/GCP services by their names and functions, but I really wanted to gain hands-on experience in using them.

As with (probably) most programmers, I created a couple of webpages one of which was for a member of my family. I’m ashamed of what it looks like now, but I still maintain it. Recently, I had to change its hosting, so… I decided to use AWS! To do what was needed and to achieve what I wanted.

JS modifications

First things first, let’s start with a JS code. The webpage was almost 100% static, with a visitor counter. PHP script was using a text file to store the number of visitors and to increment it. What’s worse, there were HTML frames to get around the problem of calculating visits after refreshing the page.

I’ve almost never used Vue, so it was a natural choice. I created 2 components in the index.html:

1. For the main context of the webpage
2. For the “intro”, disappearing after the first click:

const Intro = {
  data: function () {
    return {
      shouldHide: !!sessionStorage.getItem('shouldHide')
    }
  },
  template: '<div v-if="!shouldHide" @click="startPage" style="(...)"><img src="img/bg.jpg" style="(...)"></div>',
  methods: {
    startPage: function () {
      const vm = this;
      vm.shouldHide = true;
      sessionStorage.setItem('shouldHide', true);
      const reqresp = new XMLHttpRequest();
      reqresp.onreadystatechange = function () {
        if (reqresp.readyState == 4 && reqresp.status == 200) {
          const counter = JSON.parse(reqresp.responseText).counter;
          vm.$emit('got-counter', counter);
          sessionStorage.setItem('counter', counter);
        }
      };
      reqresp.open('GET', url, true);
      reqresp.send();
    }
  }
}

Old browsers had to be supported (😢) and configuring Babel with build scripts was too much. While const works with IE11, fetch and arrow functions don’t.

Why having HTTP requests here? As you can see from the emitted event name, it is something connected with the new counter mechanism. We’ll come back to it later.

Also, to get around the multiple visits on refresh problem, we have sessionStorage. Why not localStorage? The answer is EU Cookie Law. It seems sessionStorage doesn’t require you to have this terrible Cookie Policy info on your webpage.

Files in clouds

How to host static files? AWS S3 (1) is the answer! S3 means SSS which means Simple Storage Service. Moreover, it can be configured to expose a bucket content as a website! I thought my job was done there.

It wasn’t.

OK, what is the “bucket”? It is something like a folder on your computer. Creating it is really simple, but there are some tricky parts.

• Choose its name carefully. For the webpage like example.com, bucket should be named example.com as well. Moreover, the name has to be unique across all the existing AWS buckets
• Always choose an appropriate AWS Region. A rule of thumb for simple scenarios: the same Region for all the services to minimize the costs (Internet transfer between different parts of the world). I decided to go with EU (Ireland)
• Default options are OK in almost all the cases. However, your website should be available from the outside, so you should disable blocking public and cross-account access

Then, you can create Bucket Policy to specify the mentioned open access:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example.com/*"
        }
    ]
}

Having these things fixed, you can upload all the files to your bucket and go for Properties → Static website hosting. You need to choose a main file (index.html) and — optionally — an error file.

Domain?

If URL like http://example.com.s3-website-eu-west-1.amazonaws.com works for you, you can stop right now. But it wasn’t enough for me.

I had a nice domain, managed through OVH and I wanted to connect it with my S3 files.

Managing in OVH

First try was to add S3 URL as CNAME DNS record in OVH management tool. CNAME means Canonical Name and it can just lead to a different domain. Sounds good, doesn’t work — OVH requires providing an absolute URL. With “.” at the end. And using S3 address with a dot at the end leads to 404 error (NoSuchBucket).

At least, it happened to me.

AWS distribution

Googling a little never killed anybody. It appeared, there is a dedicated AWS service for distributing files, AWS CDN — CloudFront (2). Distributing files may not sound as the solution for the domain problem, but CloudFront offers some configuration options connected with this topic.

When creating a distribution, remember about a default root object:

It took some time to distribute all the files, but then, loading the webpage with CDN URL was much faster.

Using this CDN URL as CNAME? Nope.

403 ERROR
The request could not be satisfied.
Bad request.

Generated by cloudfront (CloudFront)

Request ID: xxx

CloudFront allows providing alternative domains, but you need a certification — a proof it is really your domain. I gave up and switched from OVH to AWS. It’s easier to configure the certification this way.

Managing in AWS

I started managing my domains from AWS Route 53 (3).

Warning: Route 53 is something you have to pay for. Each Hosted Zone costs like 0.62 $, including tax. Costs of S3, CloudFront and others are skippable for tiny scales. Moreover, as a new user, you have a free tier, but Route 53 has its fixed price.

The goal is to create a Hosted Zone in Route 53 for the domain and then, it is super easy to plug S3 or CloudFront URL there. Well… should be, but there are 2 things to be fixed first.

1. DNS servers in OVH Control Panel
2. HTTPS

Switching from OVH to Route 53 is as simple as playing with “DNS servers” tab in OVH Control Panel. Provide Route 53 servers there:

HTTPS

Why do we need it? Not even because it’s a standard nowadays, but because CloudFront requires it for its alternative domains.

As stated in the above screenshot, you can use ACM (AWS Certificate Manager) (4) to get the SSL Certificate. It’s as simple as clicking

and going with default options.

I’ve just defined an Alternate Domain Name in CloudFront Distribution Settings and filled the SSL Certificate in. Then, I was able to add DNS A record in Route 53 and provide my CloudFront URL there.

Your safe & fast static webpage is ready! There are just 4 AWS services used for it :)

Bonus: CloudFront invalidation

What after changing something e.g. in index.html? Putting a new version in S3 is not enough, as CloudFront is cached for a long time.

In simple scenarios, you can go to your CloudFront distribution and choose “Invalidations” tab there:

Read part 2/2 here.

How many AWS services do you need to host a static webpage? (1/2) was originally published in WarsawJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at https://www.linkedin.com on November 23, 2017.

After the latest performance of Elon Musk, there are opinions like “Tesla should rather focus on Model 3”, “Tesla is driven by hopes and dreams”, “Tesla has no chance to survive” and so on and so forth.

I see the point here and I’m aware of the problems including, but not limited to:

• 400 000 people waiting for Model 3, 60 000 Model 3 cancellations
• Delays when it comes to the production line improvements
• Unhappy and fired out employees
• Last quarter losses

I also understand people thinking the whole truck and roadster things are to start a new discussion, far away from the real problems. I know articles like:

• Look At The Shiny Semi-truck To Keep Your Eye Off The Model 3 Problems
• The 5 biggest questions Tesla didn’t answer last night

All present the valid points.

Moreover, some researches and engineers argue that Elon overpromised (once again) when it comes to the performance and numbers presented by him are just unreal.

I know all of this, but my article is about a separate thing. I want to point out what are the good things about the new cars and how showing them can help e.g. addressing Model 3 issues. I don’t want to focus on whether an electric truck with such a performance can be created or not. I just assume Tesla can do this.

My personal top 3 arguments for the new cars.

1. Creating your own reality

All the motivational books I know, have something in common. It is about creating your own reality and pushing bad thoughts out of the head by short and positive sentences, affirmations. This is one of the techniques for making dreams come true. This is for restoring the faith in something. Musk restored faith in Tesla. At least partially.

I think Barney Stinson nailed this technique in “HIMYM” series:

2. Motivating the employees

Long story short: I’m building a cathedral!

Truck and roadster are shiny new products, which make Tesla great again. At least the hype is back. 500 miles? 1.9 sec? 250+ mph? I think you got the point ;)

3. Escaping… to the front

What if I told you Tesla is not the first company named after Nikola Tesla, which announced an electric truck? What if I told you Nikola Motors got 7000 preorders for something which doesn’t even exist as a prototype?

Tesla already got some preorders and something prototype-like was already shown during the event.

Moreover, Roadster preorders should give the company $250 million right now. Sounds good for me…

I think all this together can help the company survive the hard time. But even a miracle won’t help in the long-term perspective, without having those 5000 cars a week, starting from March 2018.

Originally published at https://www.linkedin.com on September 2, 2017.

Popular articles appear in the “article waves”. The recent waves were about Google memo and Infosys. Now, it is about the cooperation between Microsoft and Amazon. And I want to be a part of this wave.

For me, it all started with the article: Amazon’s Alexa and Microsoft’s Cortana are going to work together. I remember some reports showing Alexa as a market leader, so I was confused after reading this. Is Cortana integration with Microsoft’s applications a real value for Amazon? Is this enough for giving back thousands of Alexa skills?

Then I took a second look. Bing is already a default search engine for Alexa. Microsoft competes with Amazon rather just in the public cloud area. And it is like Amazon is a leader of IaaS, while Microsoft is good with PaaS and, especially, SaaS (e.g. Office 365). On the other hand, Google and Facebook are/will be Amazon’s direct competitors in advertising, shopping and video.

I agree that even just the voice assistants’ cooperation is valuable for both sides. Good summary on this is presented e.g. in the article: Why Amazon And Microsoft Are Joining Forces On Voice.

But it’s not over yet. There is a broader context.

Microsoft does a favor even in the mentioned cloud area! Amazon engineers were supporting Microsoft to integrate its Visual Studio (IDE) with AWS. And something happens in freeware Visual Studio Code as well:

Visual Studio Code on Twitter

Using @code and deploying Node apps to the cloud? We would love to talk to you...https://t.co/pKxH99EOIA

For me it looks like a bigger cooperation and a part of a broader strategy.

And my thoughts? Looking into the crystal ball and knowing that the next update of Windows 10 is going to support mixed reality, I’d say that Alexa is a great improvement for Microsoft. And being a part of a mixed reality system can help Amazon with their potential messenger app — Anytime. Merging this with another interesting vision, Amazon and Microsoft cooperation may result in AR social media giant, which would overtake Facebook and Google.

But even without going so much into the future, we have a win-win situation for both Microsoft and Amazon, at present.

DORF QuickStart - part I - Plunker

Step-by-step

Main problems identified in the first part:

1. There are no indicators on the required fields; in our case all the fields are required, but anyway…
2. There are 2 buttons visible and just the first one is doing something
3. First button is 'Save' instead of 'Submit'
4. update function is not the perfect way of acting with DORF Object

Required fields

Putting a characteristic red star after the label of the required field is really trivial in DORF. All you need is requiredWithStar set to true somewhere inside DorfModule.forRoot method in app.module.

Styling buttons

Currently we are having 2 buttons and one of them is not needed. Also, they are ugly. The solution for this — once again — is a modification of DorfModule.forRoot method. The end result can look like this:

DorfModule.forRoot({
  css: {
    section: 'row',
    wrapper: 'form-group col-12 row',
    label: 'col-2 col-form-label',
    fieldGeneralization: 'col-10',
    htmlField: 'form-control',
    buttons: {
      save: 'btn btn-primary',
      reset: 'hidden-xs-up'
    }
  },
  dorfFields: [{
    tag: DorfField.CHECKBOX,
    css: {
      wrapper: 'checkbox col-12 row',
      htmlField: 'checkbox'
    }
  }],
  requiredWithStar: true
})

Styles are taken directly from Bootstrap.

Changing the buttons

Time for something harder. In the current version of DORF, there are no mechanisms for customizing button text. But we can still achieve our goal by:

1. Overriding DORF component(s)
2. Talking with DORF in a different way

Let’s take a look at the first option.

Overriding DORF components

DORF is written in a modular way. Dependencies are presented below:

There are 3 main modules:

1. DorfCoreModule — an essence, which exports the configuration, ReactiveFormsModule from Angular and abstract TypeScript classes, used later by the fields.
2. DorfFieldsModule — module which collects field-related stuff: input, select, radio, checkbox and the field generalization. The idea behind one module for all the field components is simple — it should allow an easy switch. E.g. it is doable to define components with DORF-like selectors which use e.g. Angular Material behind the scenes. Then, a new module containing them should be used on top of DorfCoreModule. Sooner or later DORF should be improved to allow even an easier way for overriding the default fields.
3. DorfModule — final module, which uses the previous ones and adds wrappers and buttons.

As written above, DorfModule stores buttons component. Let’s take a deeper look at this:

What needs to be done is similar to what happened in definition-extras example from the official DORF repository. DorfButtonsComponent has HTML template which is the source of our problem. And the solution is to create a new component, e.g. src/app/ext/custom-buttons-component.ts:

import { Component } from '@angular/core';
import { DorfButtonsComponent } from 'dorf';

@Component({
    selector: 'dorf-buttons',
    template: `
    <section [ngClass]="config.css.buttons?.group">
        <button (click)="submit()" [ngClass]="config.css.buttons?.save" [disabled]="!form || !form.valid">Submit</button>
    </section>
    `
})
export class CustomButtonsComponent extends DorfButtonsComponent { }

HTML was modified to match our requirements. We even removed unneeded “Reset” button. Hints:

• The selector has to match the original selector
• It may be useful to extend the original component

New component should be registered in the module:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';

import { 
  DorfFieldsModule,
  DorfField,
  DorfFieldWrapperComponent,
  DorfGroupWrapperComponent
} from 'dorf';

import { CustomButtonsComponent } from './ext/custom-buttons-component';

import { UserFormComponent } from './user/user-form.component';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    UserFormComponent,
    AppComponent,
    CustomButtonsComponent,
    DorfFieldWrapperComponent,
    DorfGroupWrapperComponent
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule,
    DorfFieldsModule.forRoot({
      css: {
        section: 'row',
        wrapper: 'form-group col-12 row',
        label: 'col-2 col-form-label',
        fieldGeneralization: 'col-10',
        htmlField: 'form-control',
        buttons: {
          save: 'btn btn-primary'
        }
      },
      dorfFields: [{
        tag: DorfField.CHECKBOX,
        css: {
          wrapper: 'checkbox col-12 row',
          htmlField: 'checkbox'
        }
      }],
      requiredWithStar: true
    })
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Note that we switched from DorfModule to DorfFieldsModule, so it was needed to register DorfFieldWrapperComponent and DorfGroupWrapperComponent “manually”.

The end result for this part is available here: http://embed.plnkr.co/38WWfdqRICzB4zlzmKon/

Talking with DORF in a different way

Overriding DORF pieces is a powerful technique, but it is too much in our case. Let’s undo the last changes and modify DorfForm decorator on UserFormComponent:

@DorfForm({
  renderWithoutButtons: true
})

Then, let’s add <button class="btn btn-primary">Submit</button> manually to the template of AppComponent.

A better way of acting with DORF Object

What if I told you that you can use DORF and enjoy the [(ngModel)]-like experience? Let’s start the modification with removing the update function from our model. Then, for every field we want an immediate updating, we have to add updateModelOnChange: true option:

@DorfObject()
export class User {
  @DorfInput({
    label: 'Username',
    type: 'input' as InputType,
    validator: Validators.required,
    updateModelOnChange: true
  })
  private _login: string;

  @DorfInput({
    label: 'Password',
    type: 'password' as InputType,
    validator: Validators.required,
    updateModelOnChange: true
  })
  private _password: string;

  @DorfCheckbox({
    innerLabel: 'I accept the terms and conditions',
    validator: Validators.requiredTrue,
    updateModelOnChange: true
  })
  private _acceptance: boolean;

  constructor(options?: IUser) {
    if (options) {
      this._login = options._login;
      this._password = options._password;
      this._acceptance = options._acceptance;
    }
  }

  get login() { return this._login; }
  get password() { return btoa(this._password); }
  get acceptance() { return this._acceptance; }

  get basicAuth() {
    if (this._login && this._password) {
      return btoa(`${this._login}:${this._password}`);
    }
  }
}

Bonus: you can specify debounce parameter, to delay an update. It expects a number of milliseconds as a value. It is similar to one of ngModelOptions parameter from Angular 1.3.

That’s it. Having such updating, it is possible to consume user directly in AppComponent.

Recap

We fulfilled all the requirements from the previous part and extended our DORF knowledge:

1. DorfModule.forRoot method allows not only assigning CSS classes to fields, but also to buttons; it also has additional parameters, e.g. for setting a red star on the required fields
2. DORF is modular and its components can be overridden pretty easily
3. DORF allows for [(ngModel)]-like updating. Behind the scenes, immediate updating uses events, so it is a reactive way, not a two-way binding

Finished app is presented here:

Angular DORF QuickStart - part II, finished - Plunker

The future

DORF is still under the development, but its code already allows for handling plenty of use cases and scenarios, which are not yet presented in tutorials.

Planned tutorials

• Advanced options and further overriding of DORF components
• Nested objects and a column layout
• Adding custom fields
• Testing DORF

Introduction

First part of DORF QuickStart tutorial covers the following topics:

• what is the target form structure,
• how to use CSS libraries together with DORF,
• how to play with basic DORF annotations

Prerequisites

It may be useful to read the following tutorials on Angular:

• Reactive Forms
• Dynamic Forms

The latter from the list was a direct inspiration for DORF.

What does Domain Object mean?

Library has to have a catchy name and DORF sounds better than ORF (only Germans are allowed to disagree :)). The term is taken from the Domain Driven Design approach (DDD), where system is divided into separate parts (domains). It’s not like every object in the system should have its own form. It is needed for the selected, main ones. And those can be called Domain Objects even if the architecture is not DDD.

Step-by-step

We are going to create a simple form, getting to know DORF better and better with each step.

Starting point

In order to start we should generate/download an app according to Angular QuickStart.
Then it is needed to install DORF, e.g. by using npm install dorf --save command.

CSS library

DORF is very configurable. Especially when it comes to the CSS classes. From the beginning, the main idea was to leave a choose of CSS framework to the end library user.

For the tutorial let’s choose Bootstrap, while the library’s GitHub examples use rather Pure. It is enough to include just CSS part from the library, so the changed index.html can look like this:

<!doctype html>
<html>

<head>
  <meta charset="utf-8">
  <title>DORF App</title>
  <base href="/">

  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">
  <link rel="stylesheet" href="https://unpkg.com/bootstrap@4.0.0-alpha.6/dist/css/bootstrap.min.css">
</head>

<body>
  <app-root>Loading...</app-root>
</body>

</html>

Example requirements

DORF can be imported in a way, which matches our needs. Let’s keep things simple and define the following requirements:

1. Form for the user (login, password, acceptance of terms and conditions)
2. 1 field per line
3. Label and field in the same line as here
4. Checkbox with just one label as here
5. 1 button for submitting the form

DORF output

To understand how to configure CSS in DORF, let’s take a look at the skeleton of the form generated by the library:

<dorf-form-component>                                    
  <form class="form">                                    
    <fieldset class="fieldset"><!-- optional -->         
      <section class="section">                          
        <dorf-field-wrapper class="wrapper"><!--...--></dorf-field-wrapper>
        <dorf-field-wrapper class="wrapper"><!--...--></dorf-field-wrapper>
        <!-- ... -->
      </section>
      <dorf-group-wrapper><!--...--></dorf-group-wrapper>
      <dorf-group-wrapper><!--...--></dorf-group-wrapper>
      <section class="section">
        <!--...-->
      </section>
      <!-- ... -->
    </fieldset>
    <dorf-buttons><!--...--></dorf-buttons>
  </form>
</dorf-form-component>

In general:

1. dorf-form-component - Angular component created by the library consumer to manage the form
2. form - standard HTML element; first place where classes can be set during importing DORF module (form property)
3. fieldset - optional parameter. Visible when renderFieldsetAroundFields set to true inside @DorfForm annotation. CSS classes for this can be set when importing DORF module (fieldset property). This main fieldset doesn't contain any legend (unlike the fieldset from dorf-group-wrapper)
4. section - HTML element; it is always around dorf-field-wrapper elements. When importing DORF module, there is a columnsNumber property which defines how many dorf-field-wrapper elements should be inside each section. Section CSS classes can by set when importing DORF module (section property)
5. dorf-field-wrapper - DORF component which "wraps" the field context. It stores label, field and the error message. It is described in detail later. CSS classes for this component can be assigned in many places, but always with a wrapper property
6. dorf-group-wrapper - another DORF component, used when nesting DORF Objects. We are not going to use this in this tutorial and CSS classes cannot be assigned directly at its level anyway
7. dorf-buttons - DORF component for storing form buttons. When importing DORF module, there is renderWithoutButtons property and when it is set to true, dorf-buttons won't be presented. CSS classes cannot be set directly on the component, but later, within its body

The output of dorf-field-wrapper

The content of dorf-field-wrapper looks like this:

<dorf-field-wrapper class="wrapper">
  <label class="label">...</label>
  <dorf-field class="fieldGeneralization">
    <dorf-input class="dorfField"><!--...--></dorf-input>
    <dorf-radio class="dorfField"><!--...--></dorf-radio>
    <dorf-select class="dorfField"><!--...--></dorf-select>
    <dorf-checkbox class="dorfField"><!--...--></dorf-checkbox>
    <!--...-->
  </dorf-field>
  <div class="error">...</div>
</dorf-field-wrapper>

In short words:

1. label and error are within standard HTML elements. CSS classes for them can be set thanks to label and error properties
2. dorf-field is a DORF component which allows operating on fields without going into detail. It stores both out of the box fields and the custom ones, added with dorfFields property when importing DORF module. At the end only one of the fields listed within dorf-field body is presented. Therefore the good way of thinking about this component is "field generalization". Therefore CSS classes can be assigned to this, with a fieldGeneralization property
3. dorf-input, dorf-radio, dorf-select, dorf-checkbox - out of the box DORF components. Each one represents a different HTML field. As mentioned above, only one of them would be presented under the dorf-field under the concrete conditions. It is possible to assign CSS classes at this level with dorfField property

DORF is written in a very modular way, that’s why each field is defined by its own component.

The output of different out of the box fields

We can divide out of the box fields into 2 groups: those which support additional labeling and those which don’t. Knowing HTML, you can guess that dorf-checkbox and dorf-radio are supporting additional labeling (inner label).

Inner label means here that we have a label around the field. Let’s take a look at the simplified content of dorf-radio:

<label *ngFor class="innerLabel">
  <input type="radio" class="htmlField"> ...
</label>

Each option is wrapped with the label. Label can have CSS classes, defined by an innerLabel property. Options are standard HTML input elements which can have CSS classes assigned with htmlField property. Worth mentioning that innerLabel is independent from label underneath dorf-field-wrapper, so it is possible to have 2 labels, to have just a chosen one or to not have any at all.

On the other hand, dorf-select and dorf-input don't support inner labels. Simplified template of dorf-input looks like this:

<input class="htmlField" />

Nothing fancy :) once again, htmlField property is strictly connected with the HTML representation of the form field.

The output of dorf-buttons

The last DORF component is pretty simple when it comes to its body:

<section class="group">
  <button class="save">Save</button>
  <button class="reset">Reset</button>
</section>

There are 2 predefined buttons, grouped within the section HTML element. CSS classes can be assigned to them thanks to group, save and reset properties.

Initial configuration

From the requirements we can figure out that just input and checkbox fields should be used. When configuring CSS classes, it is good to have as much as possible at the general level and override just a couple of styles at the field level. Then, in rare cases, everything can be overriden at the definition level. DORF approach to CSS is similar to the well-known browser one - the closer the element, the more likely to be assigned.

At the end app.module can look like this:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';

import { DorfModule, DorfField } from 'dorf';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule,
    DorfModule.forRoot({
      css: {
        section: 'row',
        wrapper: 'form-group col-12 row',
        label: 'col-2 col-form-label',
        fieldGeneralization: 'col-10',
        htmlField: 'form-control'
      },
      dorfFields: [{
        tag: DorfField.CHECKBOX,
        css: {
          wrapper: 'checkbox col-12 row',
          htmlField: 'checkbox'
        }
      }]
    })
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Importing DorfModule at the beginning is needed in order to use it under the imports module property. Then, the configuration is done by executing forRoot static method on the module level and passing IDorfService object as a parameter. Many things are defined at the general, css level. CSS classes are taken from the Bootstrap examples and mapped according to the knowledge about the rendering:

• each section should be a separate block element ('row'),
• something, which groups field and label (wrapper) should be both 'form-group' and 'row'; it is already under the 'row', so we should add 'col-12' at this level as well,
• in order to have label and field in the same line, 'col-' classes should be assigned (to label and to fieldGeneralization),
• htmlField got 'form-control' class

The only exception from those patterns is dorf-checkbox. In order to assign CSS classes just to this kind of field (and override the previous classes if exist), dorfFields array is used. It can change existing fields and/or add new ones. tag property is the required key for elements in this array (in our case key was taken from imported DorfField class).

Model for the form

For the simple requirements we have here, there is a simple model to be created. It’s a good idea to start with a “contract”. Let’s create a file src/app/user/model.ts with a following interface inside:

export interface IUser {
  _login: string;
  _password: string;
  _acceptance: boolean;
}

Interface defines what will be returned from our form. Interface properties have to match the future annotated Domain Object class properties. Let’s create a class now and enrich it with a constructor, consuming the interface. Let’s act as guys who care about the security (the usage of btoa and stuff):

export class User {
  private _login: string;
  private _password: string;
  private _acceptance: boolean;

  constructor(options?: IUser) {
    if (options) {
      this._login = options._login;
      this._password = options._password;
      this._acceptance = options._acceptance;
    }
  }

  update(options?: IUser) {
    if (options) {
      this._login = options._login;
      this._password = options._password;
      this._acceptance = options._acceptance;
    }
  }

  get login() { return this._login; }
  get password() { return btoa(this._password); }
  get acceptance() { return this._acceptance; }

  get basicAuth() {
    if (this._login && this._password) {
      return btoa(`${this._login}:${this._password}`);
    }
  }
}

Model is almost ready. The last part is to make it DORF! The final shape of model.ts can look like this:

import { Validators } from '@angular/forms';
import { DorfObject, InputType, DorfInput, DorfCheckbox } from 'dorf';

export interface IUser {
  _login: string;
  _password: string;
  _acceptance: boolean;
}

@DorfObject()
export class User {
  @DorfInput({
    label: 'Username',
    type: 'input' as InputType,
    validator: Validators.required
  })
  private _login: string;

  @DorfInput({
    label: 'Password',
    type: 'password' as InputType,
    validator: Validators.required
  })
  private _password: string;

  @DorfCheckbox({
    innerLabel: 'I accept the terms and conditions',
    validator: Validators.requiredTrue
  })
  private _acceptance: boolean;

  constructor(options?: IUser) {
    if (options) {
      this._login = options._login;
      this._password = options._password;
      this._acceptance = options._acceptance;
    }
  }

  update(options?: IUser) {
    if (options) {
      this._login = options._login;
      this._password = options._password;
      this._acceptance = options._acceptance;
    }
  }

  get login() { return this._login; }
  get password() { return btoa(this._password); }
  get acceptance() { return this._acceptance; }

  get basicAuth() {
    if (this._login && this._password) {
      return btoa(`${this._login}:${this._password}`);
    }
  }
}

It is OK to put DORF annotations on the private fields. It is a property name which matters here, not an access modifier. And the above piece of code, should prove that DORF is about Model-driven forms within the model.

Form component

To finalize the app, we need just one more piece from the Angular library — component which consumes DorfObject. Here is the example code of user-form.component.ts from src/app/user/ directory:

import { Component, Output, EventEmitter } from '@angular/core';
import { IDorfForm, DorfForm, DorfObjectInput, DorfConfigService } from 'dorf';

import { IUser, User } from './model';

@DorfForm()
@Component({
  selector: 'app-user-form'
})
export class UserFormComponent implements IDorfForm {
  @DorfObjectInput() user: User;

  constructor(public config: DorfConfigService) { }

  onDorfSubmit() {
    this.user.update(this['form'].value as IUser);
  }
}

A couple of things worth mentioning:

1. DorfForm is a special annotation, which should be placed over Component annotation; if Component has no template nor templateUrl, then DorfForm generates the template for us! DorfForm can consume an interface with 3 options: additionalTags, renderFieldsetAroundFields and renderWithoutButtons
2. IDorfForm is a helper interface, something like e.g. OnChange from Angular which forces us to have DorfConfigService somewhere inside the component
3. DorfObjectInput works like Angular Input, but should be used once within the component in order to point out an object marked as DorfObject previously
4. DorfConfigService is needed within the component; it should be injected and used in the constructor e.g. to disable all the fields
5. onDorfSubmit is a special method, connected with DORF save button from dorf-buttons; this['form'].value is the way of getting an object with actual form values (which can be casted to IUser in our case)

UserFormComponent has to be presented inside the main module declarations array.

Polishing the app

At the end of the first iteration, we should update AppComponent:

import { Component } from '@angular/core';

import { User } from './user/model';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  title = 'My DORF App';

  // object to be passed to the form
  user: User = new User();
}

And its HTML:

<main class="container">
  <h1>
    {{title}}
  </h1>

  <app-user-form [user]="user"></app-user-form>

  <!-- the evidence that the user has changed -->
  <hr> Basic {{user.basicAuth}}
</main>

Recap

First version is ready. It can be run with npm start command and verified on localhost:4200. Things to be improved (in the second part of the tutorial):

1. There are no indicators on the required fields; in our case all the fields are required, but anyway…
2. There are 2 buttons visible and just the first one is doing something
3. First button is 'Save' instead of 'Submit'
4. update function is not the perfect way of acting with DORF Object

The future

DORF is still under the development, but its code already allows for handling plenty of use cases and scenarios, which are not yet presented in tutorials.

Planned tutorials

• Advanced options and overriding DORF components
• Nested objects and a column layout
• Adding custom fields
• Testing DORF

Originally published at mat3e.github.io.

I’m a software developer with a hands-on experience in various technologies, from back-end to front-end, including an integration layer. And, as other developers, I’m witnessing changes in the world of code.

Changes, changes, changes

2014–2015 I was a proud user of TypeScript and AngularJS combo. Then, I had like 12-month break from the front-end and came back to this in 2016. What can I say? I just agree with this article. It changed…

Technologies are always first to be changed, but it is not only about switching from language A to language B. Not even about new frameworks/libraries. Problems are even with the official versions of the languages. A couple of examples:

• I used to know C++ (no professional experience, but still). And I recently took a look at its Wikipedia description. I realized I don’t know it anymore. I don’t even know C++11, while C++17 is already presented.
• At some point in time there were plans to introduce Java 9 just 2 years after Java 8. And from version 7, its evolution is pretty dynamic.
• JavaScript specification, ECMAScript, has now an alternative versioning convention to point out yearly updates. The newest version is ES2017.

All those syntax changes in programming languages are not the results of authors’ fantasies. In my opinion, those are just obligatory things in the IoT, containerization, cloud computing and Microservices era. It is needed to support asynchronous communication to process massive data and asynchronous communication is usually implemented with promises/observables and those usually consume functions, so programming languages start including lambda expressions. Containers enforce modularization, so programming languages start moving into modularization. And so on and so forth.

OK, we got it. But, what are the trends? What is the direction? My answer is automation. We are moving into the declarative programming. I see 2 things which become more and more popular:

1. Annotations and “behind the scenes” approach,
2. Functional programming.

Annotations and “behind the scenes” approach

I’ve mentioned Microservices Pattern. With this pattern, IT architects should focus on the cooperation between the small applications. Focus is moved to the higher level of abstraction. Every service is declaring its functionalities within the contract and that’s it. Scalability, fast time-to-market and technology independence are the main advantages here [source].

And contracts are presented at the lower, programmer’s level as well:

• Popular Java frameworks, like Spring and Hibernate have XML configuration/contracts for a long time. Nowadays they support also configuration by annotations. And this works also for the front-end world. Angular is the evidence here.
• Annotations are not only for configuring. The less lines of the written code, the less bugs in the code. Annotations in Lombok, AsspectJ, Spring AOP and Feign literally generate the code for us. And a related topic are things like Spring Repositories, which require just method names and the implementation happens automagically.
• Declarative/contracts approach is presented in Spring Boot, which is a mechanism for getting a preconfigured app (with all the libraries in their proper versions) based on our choices.
• Declarative/contracts approach is presented in all the CLI tools and code generators like: Angular CLI, Yeoman or JHipster.

You declare what and it just happens. It is already here, especially for data model and UI (forms, views etc.).

Functional programming

On the other hand, we can observe the functional programming (r)evolution. One step forward from Microservices resulted in Serverless Architecture. There is a following way of thinking: “ Microservice shouldn’t do much, but should do it perfectly, so why not converting it into a single function?”.

Functions make sense, because we are using verbs at a daily basis to clarify our intentions. Just try to describe your morning routine without using verbs. In Polish language, we have even a differentiation between a “sentence” and the “equivalent of a sentence”. In short words — you cannot tell the “sentence” without verbs.

Core Java way of evolution is enough for me to accept this functional trend. Non-trivial business logic would be always described by verbs: “ calculate a premium (add this, multiply by this, subtract that)”, “ verify the customer (e.g. check his shopping history)” and so on [similar opinion].

I believe that this functional thing can also be automated. Microsoft has already created AI which is able to code. Sooner or later it should be possible for such AI to code every simple function and then it would be a matter of dividing system into fine-grained functions in order to implement it.

Simple functions and contracts and we are done.

The programmers of tomorrow

I really see the world, where machines overtake people’s jobs. But, unlike in some reports, in my vision programmers are NOT safe from the automation. The automation already started. Every time someone uses JHipster or Spring Boot, they move closer to the full automation.

The only thing programmers (including me) can do, is to adapt. You can sit and cry that escalator makes you fat, but it would be better to use it to walk faster instead. Thanks to the automation, programmers would be able to take a responsibility for more ambitious tasks. Programmers could become real human-machine translators. Without spending too much time on the implementation details, being sure the code follows all the best practices at the same time.

But I’m referring here to the ambitious programmers, not to the ordinary “coders”, who currently earn a lot of money, while they do nothing but copying and pasting to create yet another similar thing (a part of the UI, an entity, a logging functionality, a process, etc.). Such coders are going to be fully replaced by the machines. Sooner or later.

But there is a light of hope, even for such coders. Having all the automation, software should be developed faster and cheaper. And it should result in more systems in general. More systems require more testers, because each application, even the one created by the machines, would be used by the end users, humans in most cases. And testers are humans as well. I see the ordinary coders as the future “technical testers”, who are able to do small fixes and a tiny customization of an app.

So even a big automation doesn’t scare me. I see more advantages than disadvantages here. Either a more ambitious work or new job positions (for less ambitious guys). And a faster time-to-market for everyone. But when? This is a separate topic…

And you, what do you think? Are programmers safe from automation?

Originally published at https://www.linkedin.com on July 30, 2017.