Every time you release a public (API) software you must update his version number.
The (public) version is universally composed by 3 numbers separated by a point:
Each version number has a semantic representation
The pattern is
Ex: in version number
10 is the Major version
2 is the Minor version
5 is the Patch version
All of these 3 numbers are always
Positive starting by 0
It is incremented each time the release is about fixing some bug without affecting the already existing public interface
So if you see a version number like: 1.1.5 it means the last 5 releases were about fix bugs.
As opposed to Patch, Minor means that they have been released new (interesting) public feature, without impacting old ones.
When there is a new Minor release the Patch number is restarted to 0. Of course, together to new feature, it’s possible that also some bug fixes have been released (even though the Patch number is 0)
When the Major number is incremented the release contains new (fantastic) features, buuuut it means that all the old features are not anymore compatible! So if you depend on those, pay attention.
If you think about it, these versioning rules could be applied also to humans.
Each 1st of January we always have new proposals for our self, so it’s like we “would” change our Major version. Or whenever we learn something new we could upgrade our Minor version.
But when do we change our Patch Number? Maybe each time we have makeup?
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
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.
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 …
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
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
Node.js and or Java (Spring it’s enough).
API Rest WS (Ok with Spring).
But there is good news. All Network layer is simple to manage now, thanks to different infrastructure-as-service like AWS, Firebase
If you know all above things, well, you can continue sleep 30 minutes more!
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:
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
Example of Creational pattern:
Example of Structural pattern:
Example of Behavioral pattern:
A domain, in weblogic world, is a set of weblogic (WL) instances that can be managed by the same administration console.
That’s why they are call managed servers.
Each WL instance can run on the same machine of the administration server or remotely
It is just an ip and port address where the single weblogic listen
If you have different weblogic servers that you need to manage (remotely for example) you can create a domain that includes them.
Or/And, if you need a cluster of instances then you must before add all cluster instances in a domain and then you can create your cluster
So you can have two types on WL instances in a domain: Standalone (which don’t belong to any cluster) and Clustered
In weblogic console, in Environment==> Servers you can add you weblogic instances. You have just to know the ip and port address of each weblogic instance you want to add in the domain
A cluster is a subset of a weblogic domain, where each WL instance of the cluster has the same goal: allow load balancing and fail over for the fantastic (same) applications they host.
Of course, as you manage a set of instance for the same application(s), when you deploy the application you do it just one time for all WL instance in the cluser, and the WebLogic Administration is in charge of update all instances in the cluster.
Just a thing good to know: all the WL in a cluster must have the same WL version
From a client point of view the cluster is transparent. The client doesn’t know how many WL instances there are behind that ip address
Advantages of a cluster are the same of LoadBalancing and Failover.
Scalability (Load Balancing): The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service, the application continues to run without impact to clients and end users.
High-Availability (Failover): In a WebLogic Server cluster, application processing can continue when a server instance fails. You “cluster” application components by deploying them on multiple server instances in the cluster so, if a server instance on which a component is running fails, an other server instance on which that component is deployed can continue application processing.
You can manage WL instances for a cluster in just two steps:
To debug with eclipse to remote server follow below instructions
In the menu Run –> Debug configurations…
In the window popup select Remote Java Application
Right click, then select New
On the right a new fieldset appears
In the Project field browse the java project to attach
In the Connection Type field:
The listening port, in both case (local and remote), must be preconfigured setting, as jvm parameters, the following:
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000
The JDWP protocol is the protocol used to debug with a remote debugger.
For example, in WebLogic server, to allow a debug socket listener, in the file “startWebLogic.cmd” add to the JAVA OPTIONS:
set JAVA_OPTIONS=-<others params> Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n
The -Xnoagent parameter disables the default sun.tools.debug debug agent
Just a little notice: if you want to debug clustered application, you have to attach the debug ide to all clustered servers, otherwise you need to be lucky to get the request to your debugged server
Curiosity: default debug port on weblogic 12.1.3 is 8453