Monday, December 10, 2018

Programming brain by programming your own code

Programming brain by programming your own code


Can the masterpieces of the best painter change the brain and the way of seeing other things by other artists?
E.g. the masterpieces of Van Gogh?
Nothing will be the same after him...

Just as artistry can shape your mind in various ways, programming also impacts how we think and our mental models, perhaps in ways we may not have expected.

Last week I found an excelent articles about it:
https://www.makeuseof.com/tag/how-programming-affects-brain/
and
https://www.huffingtonpost.com/chris-parnin/scientists-begin-looking-_b_4829981.html?guccounter=1

Do You know these Inventors?  :-)

James Gosling = Java Creator
Bjarne Stroustrup = C++ Creator
Ken Thompson = UNIX Co-Creator
Linus Torvalds = Linux Kernel Creator
Tim Beners-Lee = HTML and WWW inventor
Richard Stallman = GNU Project Creator

Do You know that during programming your own code at the same time You are programming Your brain yourself?

Generally speaking, programming impacts on activation pattern of five brain regions, which are related to language processing, working memory, and attention.
These parts of the brain typically are associated with language processing and verbal oriented processing (ventral lateral prefrontal cortex).

Using fMRI scans to observe brain activity, while programmers tried to work through and comprehend code snippets,
five areas of the brain are involved in understanding source code:

  1. Middle frontal gyrus (Attention, language, working memory)
  2. Middle temporal gyrus (Semantic memory retrieval)
  3. Inferior parietal lobule (Working memory)
  4. Inferior frontal gyrus (Working memory)
  5. Inferior frontal gyrus (Language, working memory)

But sometimes programming are not only programming, but also:

  1. trying to understand the legacy code
  2. coding
  3. business analysing
  4. designing the architecture
  5. searching and identifying the problem (the diagnose in debug mode)
  6. designing the frontend
  7. designing the schema of database
  8. optimization of the SQL expression with multiple joins to search for data in the database.
  9. designing interfaces and the whole communication
  10. designing the set of complete tests
  12. preparation of test data to the identified production error.
  13. refactoring
  14. understanding current requirements and predicting future one
  15. defending the theory that simpler is better, but too simple is not the best


Deeper study - an excelent and innovative book:
Dr Kaja Nordengen "Your Superstar Brain: Unlocking the Secrets of the Human Mind"
In "Your Superstar Brain...", neuroscientist Dr Kaja Nordengen describes in detail how the brain works - both how it's physically constructed with neurones, synapses and the cerebral cortex, but also how it functions on a more abstract level.

Posted by at No comments:

Good programming courses

Good programming courses


Posted by at No comments:

PYTHON

PYTHON

Excelent language to learn and use...


Python is an interpreted, high-level, general-purpose programming language. Created by Guido van Rossum and first released in 1991, Python has a design philosophy that emphasizes code readability, notably using significant whitespace. It provides constructs that enable clear programming on both small and large scales.

 Python features a dynamic type system and automatic memory management. It supports multiple programming paradigms, including object-oriented, imperative, functional and procedural, and has a large and comprehensive standard library.

 Is it true that Python programmers think different than Java programers during programming?  :-)
Because of different mental models in such of these two languages?
Posted by at No comments:

GRASP in OOD

GRASP in OOD (object-oriented design)


General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consist of guidelines for assigning responsibility to classes and objects in object-oriented design, as we can read at wikipedia.

The different patterns and principles used in GRASP are: 
  1. controller, 
  2. creator, 
  3. indirection, 
  4. information expert, 
  5. high cohesion, 
  6. low coupling, 
  7. polymorphism, 
  8. protected variations, 
  9. and pure fabrication. 


All these patterns answer some software problems, and these problems are common to almost every software development project. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested programming principles in object-oriented design.


Posted by at No comments:

Evolution of adaptive software development

Evolution of adaptive software development

Agile, SCRUM and many iterations are trendy now.
Microservices are trendy...

Why?

Everything more important and more interesting becomes more changeable, fast and distributed...

Why?

In my opinion, because of advantages for business and maintanance matters of adaptive software development...


My TOP 7 choice:
https://www.makeuseof.com/tag/basic-programming-principles/

http://blog.shippable.com/why-you-should-adopt-microservices

http://blog.shippable.com/7-things-to-consider-while-moving-to-microservices

http://blog.shippable.com/topic/microservices

http://blog.shippable.com/what-is-modern-application-delivery

https://dzone.com/articles/devops-trends-2019-what-you-need-to-know

https://dzone.com/articles/the-future-of-devops-is-assembly-lines


Is there any chaos in current adaptive software development?

Maybe programmers search something as the supersymmetry in the theory of strings, in order to classify and categorise better...

Are the similarities between the theory of strings and HTML tags (https://www.w3schools.com/tags/) in concept?

Are the similarities between the M-theory and microservices (in programming approach)?

And by the way: is the M-theory the same as string theory?

A theory of strings that incorporates the idea of supersymmetry is called a superstring theory.
There are several different versions of superstring theory which are all subsumed within the M-theory framework.

But where is "here" the elephant?
Is it escaped with Schrödinger's Cat?  :-)

At low energies, the superstring theories are approximated by supergravity in 10 spacetime dimensions. Read more at:

Posted by at No comments:

OOPS

OOPS

It is not the abbreviation of making mistakes...  :-)

OOPs stands for Object-Oriented Programming System:
Object means a real-world entity such as a pen, chair, table, computer, watch, etc. 
Object-Oriented Programming is a methodology or paradigm to design a program using classes and objects. 
An object is a kind of classification of matters used by our minds and brains...

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.

OOPs simplifies the software development and maintenance by providing some concepts (https://www.javatpoint.com/java-oops-concepts) at the following order:

  1. Object
  2. Class
  3. Inheritance
  4. Polymorphism
  5. Abstraction
  6. Encapsulation


Any objects could be related to basic "elements" and "experience" (of perceiving some object, event, or scene):
the experience of "mental image" or "mental picture", which is the representation in a person's mind of the physical world outside that person.

Such elementary "objects" can be dynamically self-organized by the mind all the time, and adaptively re-organized...
How?
The mind is a set of cognitive faculties including consciousness, perception, thinking, judgement, language and memory. 
It is usually defined as the faculty of an entity's thoughts and consciousness.
It holds the power of imagination, recognition, and appreciation, and is responsible for processing feelings and emotions, resulting in attitudes and actions...
Posted by at No comments:

DRY KISS and BUZI rules

DRY KISS and BUZI rules...

DRY

DRY stand for "Don't Repeat Yourself," a basic principle of software development aimed at reducing repetition of information. The DRY principle is stated as, "Every piece of knowledge or logic must have a single, unambiguous representation within a system."

Generally "Don't repeat yourself (DRY)" is a principle aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.


KISS

KISS, a backronym for "keep it simple, stupid", is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided.


At wikipedia we can read that the phrase has been associated with aircraft engineer Kelly Johnson. The term "KISS principle" was in popular use by 1970. Variations on the phrase include: "Keep it simple, silly", "keep it short and simple", "keep it simple and straightforward", "keep it small and simple".

The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication available to repair them.


BUZI (Polish)

Popular translation of KISS rule:
BUZI = "Bez Udziwnień Zapisu, Idioto".


YAGNI


YAGNI (https://deviq.com/yagni/), or “You Aren’t Gonna Need It” (or “You Ain’t Gonna Need It”), emerged as one of the key principles of Extreme Programming. In other words:

“Always implement things when you actually need them, never when you just foresee that you may need them.”

In some ways, you can think of YAGNI as being similar to Just-In-Time manufacturing. 
It follows that YAGNI is closely related to te KISS, Keep It Simple, Stupid principle.  By avoiding adding features and complexity until it’s actually needed, the overall design of the system can remain simpler, longer. And another principle related to YAGNI is Refactor, refactor, refactor...


See this and many more at:
https://www.makeuseof.com/tag/basic-programming-principles/

Posted by at No comments:

My own Docker image

My own Docker image

Here is the format of the Dockerfile:
# Comment
INSTRUCTION arguments
The instruction is not case-sensitive. However, convention is for them to be UPPERCASE to distinguish them from arguments more easily.
Docker runs instructions in a Dockerfile in order. A Dockerfile must start with a `FROM` instruction. The FROM instruction specifies the Base Image from which you are building. 

Parser directives (e.g. "# directive=value") are optional, and affect the way in which subsequent lines in a Dockerfile are handled. 
Parser directives are written as a special type of comment in the form "# directive=value". 
A single directive may only be used once.
Examples:
1.
FROM microsoft/nanoserver
COPY testfile.txt c:\\
RUN dir c:\

2.
FROM busybox
ENV foo /bar
WORKDIR ${foo}   # WORKDIR /bar
ADD . $foo       # ADD . /bar
COPY \$foo /quux # COPY $foo /quux
Environment variables are supported by the following list of instructions in the Dockerfile:
  • ADD
  • COPY
  • ENV
  • EXPOSE
  • FROM
  • LABEL
  • STOPSIGNAL
  • USER
  • VOLUME
  • WORKDIR

 See more:

Posted by at No comments:

Docker bulid

Docker bulid


I would start the game with creating my own Docker image with dockerfile...

The docker build command builds an image from a Dockerfile and a context. 
The build’s context is the set of files at a specified location PATH or URL. 
The PATH is a directory on your local filesystem. 
The URL is a Git repository location.

$ docker build .

Traditionally, the Dockerfile is located in the root of the context. 
You use the -f flag with docker build to point to a Dockerfile anywhere in your file system.

$ docker build -f /path/to/a/Dockerfile .

You can specify a repository and tag at which to save the new image if the build succeeds:

$ docker build -t kris/awesome-app .

To tag the image into multiple repositories after the build, add multiple -t parameters when you run the build command:

$ docker build -t kris/awesome-app:1.0.1 -t kris/awesome-app:latest .

Before the Docker daemon runs the instructions in the Dockerfile, it performs a preliminary validation of the Dockerfile and returns an error if the syntax is incorrect.

An example of content of sample Dockerfile:


   FROM ubuntu:18.04

    RUN apt-get update

    RUN apt-get install -y curl nginx


Posted by at No comments:

SOLID

SOLID


At wikipedia we can read that SOLID is a mnemonic acronym for 5 design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C. Martin. 

Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.


SOLID concepts are as follows:

Single responsibility principle, SRP

= a class should have only a single responsibility (i.e. only changes to one part of the software's specification should be able to affect the specification of the class).


Open/closed principle, OCP

= "software entities … should be open for extension, but closed for modification."
Example of "Immutable Class in Java":

  1. Declare the class as final so it can't be extended.
  2. Make all fields private so that direct access is not allowed.
  3. Don't provide setter methods for variables.
  4. Make all mutable fields final so that it's value can be assigned only once.
  5. Initialize all the fields via a constructor performing deep copy.
  6. Perform cloning of objects in the getter methods to return a copy rather than returning the actual object reference.

See deeper if You want at https://www.journaldev.com/129/how-to-create-immutable-class-in-java


Liskov substitution principle, LSP

= "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also "design by contract"...
Simply said, any object can be replaced by an object of its child class.
Animal animal = new Cat();
animal.getSpeed();
animal = new Tiger();
animal.getSound();


Interface segregation principle, ISP

= "many client-specific interfaces are better than one general-purpose interface."
ISP states that no client should be forced to depend on methods it does not use.
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
Such shrunken interfaces are also called role interfaces.
ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
ISP is one of the five SOLID principles of object-oriented design, similar to the High Cohesion Principle of GRASP.


Dependency inversion principle, DIP

= one should "depend upon abstractions, [not] concretions" what means:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend on details. Details should depend on abstractions.

This is a specific form of decoupling software modules...
When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.
By dictating that both high-level and low-level objects must depend on the same abstraction this design principle inverts the way some people may think about object-oriented programming (OOP)...

Posted by at No comments:

Dockerization on AWS

Dockerization on AWS (AMAZON)

Very usefull pages as follows:

AWS with cloud formation:








https://github.com/docker/labs/blob/master/security/


Amazon Elastic Container Service (ECS) is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. Amazon ECS eliminates the need for you to install, operate, and scale your own cluster management infrastructure. With simple API calls, you can launch and stop container-enabled applications, query the complete state of your cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes and IAM roles. You can use Amazon ECS to schedule the placement of containers across your cluster based on your resource needs and availability requirements. You can also integrate your own scheduler or third-party schedulers to meet business or application specific requirements.
Posted by at No comments:

REACTive programming

REACTive programming

Reactive Programming is an asynchronous programming paradigm concerned with data streams and the propagation of change, as we can read at wikipedia.

It's often concerned on the ideologies of the Observable Pattern, Iterator Pattern, and Functional Programming...

See more at the example of REDUX:
https://medium.freecodecamp.org/an-introduction-to-functional-reactive-programming-in-redux-b0c14d097836

Redux is an open-source JavaScript library for managing application state. It is most commonly used with libraries such as React or Angular for building user interfaces. Similar to (and inspired by) Facebook's Flux architecture, it was created by Dan Abramov and Andrew Clark.
Posted by at No comments:

Tuesday, December 4, 2018

Fargate pricing on AWS

Fargate pricing on AWS

Fargate cluster doubles costs, because it is cluster (e.g. two "legs"/nodes):

https://aws.amazon.com/fargate/pricing/

vCPU = $0,05 per hour * 700 hours (25 days) * 2 nodesOfCluster = $70 per 1 month (25 days) = $70
Posted by at No comments:

Friday, October 5, 2018

Reflection in Java

Reflection in Java


In computer science, a Reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime:
https://en.wikipedia.org/wiki/Reflection_(computer_programming)#Java

The following snippet is an example of a Reflection in Java:

// Without a Reflection
Book eBook = new Book();
eBook.readLoudly();

// With the Reflection
import java.lang.reflect.*;
(...)
Object eBook = Class.forName("eu.microwebservices.awesomeappproject.model.Book").newInstance();

// Alternatively: Object eBook = Book.class.newInstance();
import java.lang.reflect.*;
(...)
Method meth = eBook.getClass().getDeclaredMethod("readLoudly", new Class[0]);
meth.invoke(eBook);

Class book = Class.forName("eu.microwebservices.awesomeappproject.model.Book")

int bookMods = book.getModifiers();

assertTrue(Modifier.isAbstract(bookMods));
assertTrue(Modifier.isPublic(bookMods));

Posted by at No comments:

Important Principles with creating microservices

Important Principles with creating microservices


Important Principles with creating microservices...


As we can read at
https://dzone.com/storage/assets/3259596-dzonerefcardz-gettingstartedmicroservices.pdf
both architectures: a monolith one and microservices should be designed following good software architecture principles. So before our BIG EXCHANGE from old architecture to microservices we must consider following principles:

1. Separate your concerns. 
Use MVC and well-defined APIs for high cohesion and low coupling.

2. Use Convention over Configuration (CoC). 
Keep configuration to a minimum by using or establishing conventions.

3. Follow the Law of Demeter. Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends.
Do not talk to strangers! Only talk to your immediate friends.

4. Use Domain-Driven Design. 
Keep objects related to a domain/component together.

5. Focus on Automation. 
Automate testing and fully automated deployment pipeline.

6. Design to Interfaces / APIs.
Classes shouldn’t call other classes directly just because they happen to be in the same archive. Such group of friendship could be later one microservice...

7. Group code by functionality, not by layer. 
Monoliths usually have a layered architecture, and it’s common to group classes by layer. Instead you should break up your code into packages separated by functionalities to allow easier splitting into future microservices. It also makes easier to see the dependencies between your future microservices.

8. Make your code stateless and externalize your application’s state. 
One cannot rely on static variables or global variables as the source of your application’s state. Use external data sources such as key-values stores or databases to maintain state.

Known problems:

  1. Sharing
  2. Asynchronicity
  3. Security
  4. Simplicity
  5. Evolution
  6. Health

How can we create a docker image?
Fast... 
from dockerfile.

Where can we create a docker image from dockerfile?
On AWS.

Ready, steady, go!

The docker container with 3 main "beasts": Java, Tomcat and Alpine/Centos Linux... - very useful information we can read at:
Posted by at No comments:

Discovery service for microservices

Discovery service for microservices

.

Posted by at No comments:

"The hell" of accounts, permissions, IAM roles and grants on AWS

"The hell" of accounts, permissions, IAM roles and grants on AWS

"The hell" of accounts, permissions, IAM roles and grants on AWS...

1.
IAM stands for Identity & Access Management. 

2.
How do I add users to AWS?
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
In the navigation pane, choose Users and then choose Add user.
Type the user name for the new user. ...
Select the type of access this set of users will have. ...
Choose Next: Permissions.

3.
Simply speaking:

We may have many Users on AWS Account.
A User may have policies.
A policy uses IAM service role.
We can add IAM permissions to a User and grant access in order to allow to run actions on AWS services...

See more:
4.


Amazon Elastic Container Service (ECS) is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. Amazon ECS eliminates the need for you to install, operate, and scale your own cluster management infrastructure. With simple API calls, you can launch and stop container-enabled applications, query the complete state of your cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes and IAM roles. You can use Amazon ECS to schedule the placement of containers across your cluster based on your resource needs and availability requirements. You can also integrate your own scheduler or third-party schedulers to meet business or application specific requirements.

Posted by at No comments:

Kubernetes vs. Docker

Kubernetes vs. Docker



only root has permitions:
/usr/bin/kubectl

/usr/bin/dockerd

--

docker pull gerardorosiles/amazonlinux-tomcat85

from:
https://hub.docker.com/r/gerardorosiles/amazonlinux-tomcat85
integrates tomcat 8.5.24 to amazonlinux with jdk8_152

(a modification of https://hub.docker.com/r/bpatterson/centos7-tomcat85/ )


docker pull gerardorosiles/amazonlinux-tomcat85

docker images

docker run gerardorosiles/amazonlinux-tomcat85

internal:
docker run -it gerardorosiles/amazonlinux-tomcat85

Posted by at No comments:

Kubernetes orchestrations

Kubernetes orchestrations

.

Posted by at No comments:

Microservices are awesome

Microservices are awesome

A Microservice architecture (MSA) is a logical structure for the design of a software program involving loosely-coupled modular components known as microservices.

Microservices (https://en.wikipedia.org/wiki/Microservices) are a software development technique - a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. 

In a microservices architecture (MSA), services are fine-grained and the protocols (based on HTTP methods) are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. 

This makes the application easier to understand, develop, test, and become more resilient to architecture erosion than it is possible ...with Monolithic applications.
It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.

Microservices have a lot of advantages with a large "statistical scale", but...
there is also a criticism of the microservices approach for a number of issues e.g.:
  • Testing and deployment are more complicated.
  • The whole complexity (from monolithic one) is moved to the architectural organization, a larger amount of interfaces and network traffic.
  • Microservices require a lot of additional software to control and react with failures and errors, because of distributed business goals and autonomous (loosely coupled) services.
  • Information barriers occurs in processes.
  • Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process.


See more:



Posted by at No comments:

The meaning of AWS abbreviations EC2 S3 etc.

The meaning of AWS abbreviations EC2 S3 etc.

AWS = Amazon Web Services = 
the Amazon.com's cloud-computing platform

EC2 = Amazon Elastic Compute Cloud (Amazon EC2) =
a web service that provides secure, resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers. It forms a central part AWS, by allowing users to rent virtual computers on which to run their own computer applications.

Route 53 = Amazon Route 53 =
a scalable and highly available Domain Name System (DNS) service. 
The name is a reference to TCP or UDP port 53, where DNS server requests are addressed.

S3 = Amazon Simple Storage Service (Amazon S3) =
a "simple storage service" offered by AWS that provides object storage through a web service interface. Amazon S3 uses the same scalable storage infrastructure that Amazon.com uses to run its global e-commerce network.

SQS = Amazon Simple Queue Service = 
fully managed message queues for microservices, distributed systems, and serverless applications






Posted by at No comments:

Docker twin copies, not replicas

Docker twin copies, not replicas

.

Posted by at No comments:

Technology pack and stack with microservices

Technology pack and stack with microservices


Can we create a docker image from dockerfile?
Yes, we can.

Can we create a docker image from dockerfile on Amazon cloud (AWS)?
Yes, we can.

Ready, steady, go!

The docker container with 3 main "beasts": Java, Tomcat and Alpine/Centos Linux... - very useful information we can read at:
Posted by at No comments:

How to separate the monolith to microservices?

How to separate the monolith to microservices?


How to separate the monolith to microservices?
This is not a trivial problem... But it is worth its price.

Thanks God we have DZONE.com :-)

As we can read at
https://dzone.com/storage/assets/3259596-dzonerefcardz-gettingstartedmicroservices.pdf
before we can start breaking up a monolith, it’s important to make sure the monolith is designed following good software architecture principles.

Some common rules are:
1. Separate your concerns. 
Consider using Model-ViewController (MVC) for front-end abstraction.
Use welldefined APIs for high cohesion and low coupling.
Separate interfaces/APIs and implementations.

2. Use Convention over Configuration (CoC). 
Keep configuration to a minimum by using or establishing conventions.

3. Follow the Law of Demeter. (similar to "Single Responsibility Principle" = SRP) Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends. Do not talk to strangers! Only talk to your immediate friends.

4. Use Domain-Driven Design. 
Keep objects related to a domain/component together.

5. Focus on Automation. 
Automate testing and fully automated deployment pipeline.

6. Design to Interfaces / APIs.
Classes shouldn’t call other classes directly just because they happen to be in the same archive. Such group could be later a microservice...

7. Group code by functionality, not by layer. 
Monoliths usually have a layered architecture, and it’s common to group classes by layer. Instead you should break up your code into packages separated by functionalities to allow easier splitting into future microservices. It also makes easier to see the dependencies between your future microservices.

8. Make your code stateless and externalize your application’s state. 
One cannot rely on static variables or global variables as the source of your application’s state. Use external data sources such as key-values stores or databases to maintain state.

Known problems:

  1. Sharing
  2. Asynchronicity
  3. Security
  4. Simplicity
  5. Evolution
  6. Health
Posted by at No comments:

Billing and TCO calculator on AWS

Billing and TCO calculator on AWS
Sometimes it is very hard to predict on AWS all the costs of our service.

In my opinion, the TCO calculator is too easy and not complex and it does not allow to calculate useful ideas :-(

Useful sites:







Posted by at No comments:

Docker images on AWS

Docker images on AWS


At the very begining we should create docker image from dockerfile...

The docker container with 3 main "beasts": Java, Tomcat and Alpine/Centos Linux... - very useful information we can read at:
https://dzone.com/articles/performance-patterns-in-microservices-based-integr-1


Amazon Elastic Container Service (ECS) or on Fargate cluster...


Amazon Elastic Container Service (ECS) is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. Amazon ECS eliminates the need for you to install, operate, and scale your own cluster management infrastructure. With simple API calls, you can launch and stop container-enabled applications, query the complete state of your cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes and IAM roles. You can use Amazon ECS to schedule the placement of containers across your cluster based on your resource needs and availability requirements. You can also integrate your own scheduler or third-party schedulers to meet business or application specific requirements.
Posted by at No comments:

Spring Boot App

Spring Boot App




Spring Boot is Spring's "convention-over-configuration" solution for creating stand-alone, production-grade Spring-based Applications that you can "just run".

It is preconfigured with the Spring's "opinionated view" of the best configuration and use of the Spring platform and third-party libraries so you can get started with minimum fuss. 
Most Spring Boot applications need very little Spring configuration...

See more at:
Posted by at No comments:

FARGATE cluster on AWS

FARGATE cluster on AWS

AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers as Docker with Tomcat and Java...

But pay attention with billing with Fargate on AWS!

Fargate cluster doubles costs, because it is cluster (e.g. two "legs"/nodes):


Example:
vCPU = $0,05 per hour * 700 hours (25 days) * 2 nodesOfCluster = $70 per 1 month (25 days) = $70

Posted by at No comments:

Sharding in the Blockchain

Sharding in the Blockchain


Sharding is a relatively new concept in the Blockchain.

Sharding: a solution to the scalability, latency and transaction throughput issues. 
Sharding is a concept that's widely used in databases, to make them more efficient. 

 In case of the blockchain, each node will have only a part of the data on the blockchain, and not the entire information, when sharding is implemented.

A blockchain (https://en.wikipedia.org/wiki/Blockchain), originally block chain, is a growing list of records, called blocks, which are linked using cryptography.
Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash).

 In cryptography and computer science, a hash tree or Merkle tree is a tree in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes.

 By design, a blockchain is resistant to modification of the data. It is "an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way". For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. 

 See more about implementations of blockchain in Java:

Posted by at No comments:

LinkedBlockingQueue vs ConcurrentLinkedQueue

LinkedBlockingQueue vs. ConcurrentLinkedQueue


Why and when do we use Blocking Queues and Non Blocking Queues with working with streams and media? Unbounded or not? What is when the best choice?

Once upon a time, in a galaxy far, far away, there was a beautiful young Queue...  :-)



Following operations are allowed e.g.:

bqueue.take() to take form a stream...

What are the advantages/disadvantages of unbounded queue?
With an unbounded queue, a producers can get far ahead of the consumers. Pay attention for OutOfMemoryError! How can we signal a producer that the queue is full?

ASPECTS:




  • speed
  • concurrency 
  • time to access last element
  • blocking
  • unbounded

LinkedBlockingQueue

A LinkedBlockingQueue is a good choice for many pools (depending on the pool management strategy):
https://www.geeksforgeeks.org/linkedblockingqueue-class-in-java/
https://www.geeksforgeeks.org/java-8-linkedblockingqueue-spliterator-method-with-examples/

The LinkedBlockingQueue is an optionally-bounded blocking queue based on linked nodes. It means that the LinkedBlockingQueue can be bounded, if its capacity is given, else the LinkedBlockingQueue will be unbounded. The capacity can be given as a parameter to the constructor of LinkedBlockingQueue.

This queue orders elements FIFO (first-in-first-out). It means that the head of this queue is the oldest element of the elements present in this queue. The tail of this queue is the newest element of the elements of this queue. The newly inserted elements are always inserted at the tail of the queue, and the queue retrieval operations obtain elements at the head of the queue. Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications.

ConcurrentLinkedQueue

The ConcurrentLinkedQueue is good as well in many cases:
 https://www.javacodex.com/Concurrency/ConcurrentLinkedQueue-Example

ConcurrentLinkedQueue is an unbounded thread-safe queue based on linked nodes. This queue orders elements as a FIFO (first-in-first-out). The head of the queue is that element that has been on the queue the longest time. The tail of the queue is that element that has been on the queue the shortest time. New elements are inserted at the tail of the queue, and the queue retrieval operations obtain elements at the head of the queue.

A ConcurrentLinkedQueue is a good choice when many threads share access to a common collection. Like most other concurrent collection implementations, this class does not permit the use of null elements.


A limited capacity of BlockingQueue 

(https://www.javacodex.com/Concurrency/BlockingQueueExample) is also helpful if you want to throttle some sort of request.

Useful sites to learn it deeper:

https://www.javacodex.com/Concurrency/

https://dzone.com/articles/a-specialized-high-performance-concurrent-queue







Posted by at No comments:

Microservices on Amazon AWS

Microservices on Amazon AWS


Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

Useful page:
https://aws.amazon.com/microservices/

We need to have or create an account on AWS to try building the Microservices on AWS...:
https://aws.amazon.com/
AWS Accounts Include 12 Months of Free Tier Access.
Posted by at No comments:
Subscribe to: Posts (Atom)