Monday, December 10, 2018

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:
Subscribe to: Posts (Atom)