How to implement unstable behavior / requirement

The customer, as we know, is always right even when he returns on his steps, and he forces you to review / rewrite a behavior for a component that seemed clear.

But the worst has not yet arrived, because the user can ask to change that requirement again, or worse, put things back as they were before.

Fortunately, Object Orientation comes to your aid with one of the most important design principles.

“Identify aspects of application that vary and separate them from what stays the same.”

If you have a feature of your program that

  • your client asks you to change several times
  • or simply that it can have different behaviors based on different inputs

then it is necessary to extract it from the main context and create one or more components that implement these different versions / behaviors.
Don’t be fooled to use the inheritance! In this case, in fact, inheritance cannot help you because there is the risk of having unwanted behavior performed.

Even the interfaces may not be sufficient because it forces you to write methods that are not used or to write the same method several times, duplicating the code.

Solution
Create a set of classes for each feature that tends to vary, where each class represents a possible behavior
Of course this set of classes implements the same interface.

Furthermore, following the principle
“Program with Interface and not with implementation”

to implement “unstable requirement” you will refer this interface in the main system.

In this way your client can change his mind whenever he wants, and you will be ready to please him and, perhaps, become his best friend or psychologist …

React Native – The Practical Guide

How to use React Native and React knowledge to take web development skills and build native iOS and Android Apps

  • Build native mobile apps with JavaScript and React
  • Dive deeper into React Native
  • Develop cross-platform (iOS and Android) mobile apps without knowing Swift, ObjectiveC or Java/ Android
How to integrate young framework like React in old web pages

In these days I’m trying to improve the user experience of an old JSP page. So I thought of injecting into it some custom components of the framework react.

Integrate a basic React app inside an existing web page, like for example an HTML or JSP or PHP page, is very very simple and, most important thing, it does not require a build and an import of tons of prebuild files.

Below an example of how to do this integration inside a generic html page.

<script crossorigin src="https://unpkg.com/react@16/umd/react.development.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
<script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
<script type="text/babel" src="/js/app.js"></script>

<div id="react-content" />

<script type="text/babel">
ReactDOM.render(<CustomApp />, document.getElementById('react-content'));
</script>

And nothing special in app.js file than a classic CustomApp class react component!

The possibility of using React directly in existing web pages, without big frills and various builds, is really very convenient.
I don’t know if Angular can also be used in the same way. I’ll try in the next few days.


Architecture stack for 2019

When an IT consultant/architect/developer wakes up in the morning he knows that he has to study a new programming language before the fullstack runs away.

And that the new programming language tomorrow is already deprecated.

If you want to save your big fat neck today you have to know at least 80% of next languages.

Frontend layer

Angular and or React (better both, I know it’s not possible if you have also a private life).

If you have to choose today, for example, if you start programming now, I bet on React.
Rest WS as a client

Backend layer

Node.js and or Java (Spring it’s enough).
API Rest WS (Ok with Spring).

DB layer

MongoDb (or any nosql db) and or Oracle (or MySql or any sql db)

But there is good news. All Network layer is simple to manage now, thanks to different infrastructure-as-service like AWS, Firebase and Heroku

If you know all above things, well, you can continue sleep 30 minutes more!

Amazon is eating also System and server administrators

With so much of computing becoming cloud-based (see AWS or Google Cloud), the general IT person who patrolled your office is becoming less and less relevant in today’s workforce.

The change is already happening at smaller businesses, which find it cheaper and more efficient to outsource the work. Yes, like me for example.

The good news is that it is creating the opportunity for programmers, freelancers and system administrators willing to pivot to manage their client servers remotely and profitably, and at better scale.

So, maybe, system administrator could see this thing from another perspective. What do you think?

AWS Concepts

This course provides practical and conceptual introduction to the concepts of Cloud Computing and Amazon Web Services.

  • Have the conceptual foundation to move forward onto more advanced AWS courses
  • Be more prepared to tackle the more complex technical concepts and terminology
Exceptions in the life: Checked vs Unchecked problems

In Java, as well as in your life, there two type of exception:

  1. checked exception that are the expected problems
  2. unchecked exception, that are the unexpected problems.

As in the life, for the expected events you are prepared because you plain to have that problem. So you are organized to intercept and block that problem. For example, if you are a student, or you have been a student, you know that your teacher could exam you. To avoid a negative
vote, or problem with you parents , you (theoretically) study. If you don’t study enough you could have a bad vote. But basically you are aware.

In Java is exactly the same, apart from the fact that problems are named Exception. You, and also the compiler, know that you can expect an exception calling a method and then you prevent that exception intercepting it with a try-catch-finally block.

int vote;
try{
vote=teacher.exams(you);
}
catch(NoStudiedException nse){
vote=VOTE.Very_Bad;
}
finally{
register.setVote(you,vote);
}

In Java you are aware because exists the throws clause that forces you to face up to your problem.

The exams method of Teacher class is like below:

public int exams(Student student) throws NoStudiedException{

}

But, unfortunately, there are no just checked exception. We can have also unexpected exception that you and the compiler are not aware, for example RuntimeException, ArrayIndexOutOfBoundException, but above all: NullPointerException.

They are all problems you could never have imagined it could happen to you. They are Unchecked.

All exception under Error and RuntimeException classes are Unchecked

You have to know the difference even because there are some framework that have different behavior based on checked and unchecked events.

For example JPA, that is in charge of transactions, makes an automatic rollback just in case of unchecked exception, BUT doesn’t make the same for the checked ones. It means that, if you use JPA and you want rollback when a CheckedException happens, then you have manually rollback out, adding the clause “rollbackFor=<CheckedException>.class” above the method. If you don’t use JPA and his children/nephew then pretend I did not say anything…

Design pattern for chess masters

Today I played chess with a colleague, I made a couple of very good forks.
But he put me in trouble with a good opening.

Do you know what openings, forks and also nailing are in chess?

They are very precise schemes, they have the names (Gambetto di donna, Sicilian defense, English match, French defense,…), well-defined patterns, every good chess player must know in memory.

These chess pattern are grouped into different families like opening, finals, and so on.

They are very precise moves, which you can always repeat, in every game or several times in a game, to which names have been assigned and they bring a very precise benefits.

So, what tactics are for chess, then Design pattern are for OO Design:

  • a general design solution
  • to a repeatable situation 
  • with a description 
  • a very precise schema
  • and that you have to know
  • grouped in different families: creational, structural and behavioral

The general design situation means that, when you are designing an object oriented software, there is a well know way to do it for each type of component and layer.

Repeatable means that the situations are the same for each system you can design and so you can use again that model

With a description means that that situation has a name

Very precise schema means that there is a design model already ready to use and that you could adapt it to your component

You have to know means that you should study them so that you can apply in every situation

The different families are about the different type of design situations

  • Creational are abut the way in which objects are created
  • Structural pattern identify a simple way to realize relationships among entities
  • Behavioral provide solution for the better interaction between objects

Example of Creational pattern:

  • Abstract Factory pattern: a class requests the objects it requires from a factory object instead of creating the objects directly
  • Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations
  • Builder pattern: separate the construction of a complex object from its representation so that the same construction process can create different representations
  • Dependency Injection pattern: a class accepts the objects it requires from an injector instead of creating the objects directly
  • Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed
  • Object pool pattern: avoid expensive acquisition and release of resources by recycling objects that are no longer in use
  • Prototype pattern: used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects
  • Singleton pattern: restrict instantiation of a class to one object

Example of Structural pattern:

  • Adapter pattern: ‘adapts’ one interface for a class into one that a client expects
  • Bridge pattern: decouple an abstraction from its implementation so that the two can vary independently
  • Composite pattern: a tree structure of objects where every object has the same interface
  • Decorator pattern: add additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes
  • Extensibility pattern: a.k.a. Framework – hide complex code behind a simple interface
  • Facade pattern: create a simplified interface of an existing interface to ease usage for common tasks
  • Flyweight pattern: a large quantity of objects share a common properties object to save space
  • Pipes and filters: a chain of processes where the output of each process is the input of the next
  • Proxy pattern: a class functioning as an interface to another thing

Example of Behavioral pattern:

  • Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing objects
  • Command pattern: Command objects encapsulate an action and its parameters
  • Interpreter pattern: Implement a specialized computer language to rapidly solve a specific set of problems
  • Iterator pattern: Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation
  • Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem
  • Memento pattern: Provides the ability to restore an object to its previous state (rollback)
  • Null object pattern: Designed to act as a default value of an object
  • Observer pattern: a.k.a. Publish/Subscribe or Event Listener. Objects register to observe an event that may be raised by another object
  • State pattern: A clean way for an object to partially change its type at runtime
  • Strategy pattern: Algorithms can be selected on the fly, using composition
  • Template method pattern: Describes the program skeleton of a program; algorithms can be selected on the fly, using inheritance
  • Visitor pattern: A way to separate an algorithm from an object