Terraform - IAC

 

Lot of tools available if you search for infrastructure as code: 

• Chef
• Puppet
• Ansible
• SaltStack
• CloudFormation
• Terraform

But Cloudformation and Terraform are provisioning tools. Here we will discuss about Terraform.

Terraform is the infrastructure as code offering from HashiCorp. It is a tool for

• building, 
• changing, 
• managing infrastructure

 in a safe, repeatable way. 

Infrastructure as Code

It is the process of managing infrastructure in a file(s) rather than manually configuring resources in a user interface. A resource in this instance is any piece of infrastructure in a given environment, such as a virtual machine, security group, network interface, etc.

Terraform

• Terraform allows operators to use HCL to author files containing definitions of their desired resources.
• Almost any provider (AWS, GCP, GitHub, Docker, etc)

Workflows

A simple workflow for deployment will follow closely to the steps below.

• Scope - Confirm what resources need to be created for a given project.
• Author - Create the configuration file in HCL based on the scoped parameters
• Initialize - Run terraform init in the project directory with the configuration files. This will download the correct provider plug-ins for the project.
• Plan & Apply - Run terraform plan to verify creation process and then terraform apply to create real resources as well as state file that compares future changes in your configuration files to what actually exists in your deployment environment.

Advantages

• Platform Agnostic
• State Management
• Operator Confidence

Install Terraform

Follow Install terraform to install.

Install Terraform

 coming soon

ADOBE Sites Developer Preparation Questions

 

´Adobe Experience Sites Developer Exam Guide Exam- AD0-E103

´Get Official Exam guide for AEM developer sites here:

https://spark.adobe.com/page/pszIHVOp7KKuR/

´Exam Questions

•  Get 200+ Questions for preparation of AEM Sites developer certification.

•  Questions available in word/pdf format.

•  Questions with answers are available.

•  Helpful for AEM learning at both developer and lead developer level.

´Contact to Purchase

 Email Id: codingwithtea@gmail.com

 Refer Blogs: https://codingwithtea.blogspot.com/

ACID - DBMS

 

Atomicity Consistency Isolation Durability (ACID)

ACID refers to a database system’s four transaction properties: atomicity, consistency, isolation and durability.

Transactions: A transaction is a single logical unit of work which accesses and possibly modifies the contents of a database. Transactions access data using read and write operations.

In order to maintain consistency in a database, before and after the transaction, certain properties are followed. These are called ACID properties. It is a sequence of operations that satisfies these properties.

Let's go ACID properties in detail:

Atomicity: Nothing or All

Atomicity is a property that ensures that a database follows the all or nothing rule. In other words, the database considers all transaction operations as one whole unit or atom. There is no midway i.e. transactions do not occur partially.

It involves the following two operations.

Abort: If a transaction aborts, changes made to database are not visible.
Commit: If a transaction commits, changes made are visible.

Thus, when a database processes a transaction, it is either fully completed or not executed at all. If a single portion of the transaction fails, the whole transaction will fail.

For example, user X wants to withdraw $50 from his account and then transfer it to the account of user Y. Each transaction (withdrawing $50 from account X and transferring $50 to account Y) is counted as separate. If the first transaction (withdrawing $50) fails because (say) the server crashes during the transaction, user X cannot transfer the money to user Y.

Consider the following transaction T consisting of T1 and T2: Transfer of 50 from account X to account Y.

Initial Balance: X=100 , Y=200

T1 Transaction:

Read(X)

X= X-50

Write(X)

T2 Transaction:

Read(Y)

Y=Y+50

Write(Y)

If the transaction fails after completion of T1 but before completion of T2.( say, after write(X) but before write(Y)), then amount has been deducted from X but not added to Y. This results in an inconsistent database state. X has left $50 in his account as $50 has been deducted but Y has $200(same as before). Transaction got failed. What if Y doesn't get $50 and X's reaction would be😱

Hence, Atomicity is particularly important to mitigate damage in case of database server crashes. If a non-volatile database crashes in the middle of a transaction, all changes done will be discarded or rolled back to avoid sending partial results to the production database.

Hence we can say Atomicity is required. Transaction (T1+T2) takes place at once.

Consistency:

Consistency is key to maintain data integrity. Consistency is a property ensuring that only valid data following all rules and constraints is written in the database. When a transaction results in invalid data, the database reverts to its previous state, which abides by all customary rules and constraints.

For example, if user X wants to withdraw $1,000 from his account, but only has a balance of $500, consistency will prevent him from withdrawing money and the transaction will be aborted.

Current Balance: $500

Wants to withdraw: $1000

How?😳

"User X hasn't sufficient balance!"

Isolation:

Isolation ensures that multiple transactions can occur concurrently without leading to the inconsistency of database state. It is a property that guarantees the individuality of each transaction, and prevents them from being affected from other transactions.

For example, user X withdraws $100 and user Y withdraws $150 from user Z’s account, which has a balance of $1,000. Since both A and B draw from Z’s account, one of the users is required to wait until the other user transaction is completed, avoiding inconsistent data.

User Z Balance: $1000

User X wants to withdraw: $100

User Y wants to withdraw: $150

One user has to wait till other's transaction is being completed. For e.g. Y has to wait till X's transaction is in progress.  

Durability

Durability is a property that enforces completed transactions, guaranteeing that once each one of them has been committed, it will remain in the system even in case of subsequent failures.

If a transaction is successful, all changes generated by it are stored permanently.

Let's say in above example, user Y may withdraw $100 only after user X’s transaction is completed and is updated in the database. If the system fails before X’s transaction is logged in the database, X cannot withdraw any money, and Z’s account returns to its previous consistent state.

So, once the transaction has completed execution, the updates and modifications to the database are stored in and written to disk and they persist even if a system failure occurs.

Clean Code Principles Ideas

"Why should I care about writing clean code?” you may still be asking yourself.

There are many reasons to get into the clean code mindset. Some of the most important reasons are:

Better Use of Your Time

The first beneficiary of clean code is the programmer themselves. If you are working on a project for months, it’s easy to forget things you did in the code, especially when your client comes back with changes. Clean lines of code make it easier to make changes.

Easier Onboarding for New Team Members

Using clean code principles helps to get a new programmer onboard. There is no need for documentation to understand the code; the new programmer can directly jump into it. This also saves time for both trainings the new programmer as well as the time it takes for the new programmer to adjust to the project.

Easier Debugging

Whether you write dirty or clean code, bugs are inevitable. But clean code will help you to debug faster, regardless of how much experience or expertise you have.

More Efficient Maintenance

As any project grows, it will need new features or changes to existing features.

You feel Good!

I am going to select some of the ideas to write a clean code. So let's start...

Universal Principles: 

Follow standard rules: experiments always end in disaster.

• Avoid duplication in the code (DRY principle or Don’t Repeat Yourself ).
• We must apply The Boy Scouts rule to our profession: Leave the campground cleaner than you found it.
• Follow SOLID principles to write clean classes and well-organized APIs.
• Follow Code principles article for the detailed explanation.

Names Rules:

• Use searchable names.
• Make it easy to remember them.
• Use names according to the context.
• Choose descriptive and clear names.
• Use names that can be pronounced well.
• Use names that are consistent with each other. 
• Use the same language in the names of variables, functions: English, French, etc. 
• Avoid encodings and don’t append prefixes or type information.

Classes:

• Classes should be small.
• Use correctly package levels: public, protected, etc.
• Classes should have only one responsibility and only one reason to change (SRP).
• Keep utility methods and variables private. Exceptions are always there. for eg: for testing

Objects and Data Structures:

• Hide internal structure.

• If you can, call only your methods of your class, of objects you have created, and avoid call methods reachable through these objects (Law of Demeter).

• Improve the decoupling of objects.

• Variables should be private and manipulated by getters and setters, but remember, there is no necessity to add getters/setters to each variable to expose them as public.

• The base class should know nothing about their derivatives.

• Objects expose behavior and hide data. Conversely, data structures expose data and lacks of (significant) behavior.

Functions rules:

• They should be short and only do one thing. If your function is doing more than "one thing", it is a perfect moment to extract to another function.
• Keep the number of arguments as low as possible.
• Avoid side effects. Declare the arguments as final if you can.
• Functions should either answer something or do something, but not both.
• Prefer Exceptions to return error codes and extract error handling try catch into their function.
• Don’t return a null value. What is null? It does not provide any information. If you really want to then handle all exceptions which occur due to null values like Null Pointer Exception.

Design rules:

• You should declare local variables as close as you can to their usage.
• You should declare instance variables at the top of the class.
• Constants should be declared at the top of the class or in a Constants class by example.
• Follow the Law of Demeter: A class should know only its direct dependencies.
• Use dependency injection.
• Place methods in a top-down direction.
• If you use third-party libraries, wrap them, so if they change, only your wrapper implementation needs to change.
• It is a good idea to separate concepts vertically.

Exception handling:

• Throwing errors makes code cleaner than checking for status values throughout the code.
• Provide enough meaning to determine the cause and location of an error.
• Wrap third-party libraries APIs to remap their exceptions as required.

Concurrency:

• Concurrency, although it may improve the performance of the program, is difficult, so use it wisely and only when required.
• Keep concurrency control separate from other code.
• Know basic concepts and programming models like mutual exclusion, starvation, or deadlocks.
• Create locked sections small.

Tests:

• Fast: Unit tests should be fast and being executed in a short time.
• Independent: Tests should not depend on each other.
• Repeatable: Tests should be reproducible in any environment.
• One assert per test.
• TDD: Build your software using tests that guide your development.
• Cover all test cases. You can use jacoco to check if you have covered each test case of the class.
• Make a standard: to set coverage of Junits. for eg: 80% coverage you can set for running unit test cases. 

Clean tests should follow F.I.R.S.T principles:

• Fast: ⏩ Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently
• Independent: 🆓 Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like.
• Repeatable: 🔁 Tests should be repeatable in any environment. They should run in the production environment, the QA environment, and even on your laptop while riding home on the train without a network.
• Self-Validating: ✅ The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass.
• Timely: ⏲The tests need to be written in a timely fashion.

Comments:

• Comments are difficult to maintain and don’t tell the truth about the code, so try to avoid it. 
• Use only as a clarification of code.
• The code is the best documentation.
• Don’t be redundant.
• Avoid unnecessary comments.

Formatting:

• Avoid too-long files.
• Good files have a heading, the critical stuff first, and details later.
• Avoid lines get too long (80 or 120 is perfect). You will get used to being more concise, and your code will be more readable.
• Be consistent with the rules of your team and better define rules before the start of the project. (in sprint 1 😉)

Follow these rules and make sure your code will be robust and will adapt to changes more quickly.

Clean Code Principles - Must Know

 

Good Software system begins with Clean Code that is easy to understand and easy to change. It’s the idea that your code should be precise and as close to perfect as possible. 

How to Implement Clean Coding Design

So, how does one create a clean code? Well, first of all, you can’t think of your project as a coding project; you have to think of it as a designing and planning process. Developers often rush into the code because they feel pressure from their managers or whomever to get the job done quickly. In contrast, a clean coder makes sure he fully understands the problem before beginning to code. There are some principles that we can follow before writing actual code.

Universal Principles to follow:

DRY (Don't Repeat Yourself):

As the name suggests DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. 

If you have a block of code in more than two places consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. The benefit of this Object-oriented design principle is in maintenance.

In short Avoid duplication in the code.

How to Achieve DRY

To avoid violating the DRY principle, divide your system into pieces. Divide your code and logic into smaller reusable units and use that code by calling it where you want. Don't write lengthy methods, but divide logic and try to use the existing piece in your method.

KISS: Keep It Simple, Stupid

No matter what your style of coding is, it should follow one rule: Keep It Simple, Stupid!

The KISS principle is descriptive to keep the code simple and clear, making it easy to understand. After all, programming languages are for humans to understand — computers can only understand 0 and 1 — so keep coding simple and straightforward. Keep your methods small. Each method should never be more than 40-50 lines.

Each method should only solve one small problem, not many use cases.

If you have a lot of conditions in the method, break these out into smaller methods. It will not only be easier to read and maintain, but it can help find bugs a lot faster.

How to Achieve KISS

To avoid violating the KISS principle, try to write simple code. Think of many solutions for your problem, then choose the best, simplest one and transform that into your code.

YAGNI: You Aren't Gonna Need It

Sometimes, as developers, try to think way ahead, into the future of the project. We do code for some extra features "just in case we need them" and overthinking. Eventually, we need them". Just one word for that: Wrong!

You didn't need it and you don't need it and sometimes "You Aren't Gonna Need it"

YAGNI is a principle behind the extreme programming (XP) practice of “Do the Simplest Thing That Could Possibly Work”.

How to Achieve YAGNI

To avoid violating the YAGNI principle, try to write code that is required right now. Make everything simple. Don't write code unnecessarily.

So make your code granular and write only the required code.

We also have SOLID principles that help to write clean code. For design and architectural perspective, we should follow SOLID principles.

I will write another blog for SOLID principles.

Conclusion:

It is not possible to follow every rule but if developer try to implement these things from the beginning then at some level, code cleaning can be achieved.