The 12 Factor App

12 factor app is a methodology for building software as a service apps. This methodology can be applied to any app, written in any programming languages. Below are my understanding about 12-app factors:

1. Code base: Code is always tracked in a version control system (like git). Some key points:

  • If there are multiple code bases, it\’s not an app, it\’s a distributed system.
  • Multiple apps should not share the same code. Instead, they should create shareable libraries.

2. Dependencies: All dependencies must be declared in a dependency manifest. It simplifies the set-up process for developers. 12 factor app also does not rely on implicit system tools. It\’s to avoid any risk of getting a tool or a feature decommissioned in the future.

3. Config: Configuration files must be separate from code. Store these into environment files. Config files must not be checked into repository.

4. Backing services: Backing services are the services that app consumes over the network as part of its normal operation. For example, an app uses a MySQL Database, or Amazon S3, or messaging services. Each backing service is a resource.

5. Build, release, run: Strictly separate build and run stages. Build is a stage that bundles the needed files into an executable package. Release is a stage to take build and combine it with the deploy\’s current config. Run runs the app in the executable environment.

6. Processes: The app is executed in one or more processes. Twelve-step processes are stateless and share-nothing. Any data that needs to be persists, must be stored in a backing service, like a database. Sticky sessions are violations of 12-step process.

7. Port binding: Export services via port binding. One app can also become a backing service to another app.

8. Concurrency: Scale out via the process model. Processes are a first class citizen.

9. Disposability: This means, 12-step processes can be started and stopped at any time. Processes should thrive to minimize the startup time.

10. Dev/prod parity: Keep development, staging, and production as similar as possible.

11. Logs: Treat logs as event streams.

12. Admin processes: Run Admin processes as one-off processes. For example, in my Laravel code, I ran process to create database tables as a one time setup.

Reference: https://12factor.net/

Technology Compatibility Kit (TCK)

Who should read it: It is for you if you are looking for a quick overview of this topic for a project, an interview, or in general.

What is the Technology Compatibility Kit (TCK): It is a suite of tests to check the compliance with Java Specification Request (JSR). It\’s also known as Java Compatibility Kit (JCK). This requires that all tests are implementation-independent. For a given platform to be considered \’conformant\’, all the TCK tests must pass and meet the testing requirements. 

Why TCK is important: TCK testing is important for below reasons:

  • It ensures that the Java technology does not become fragmented.
  • It helps developers to write code in a way that the solution is deployed to any platform, without any modifications.
  • It allows developers to write the code compliant to Java technology rather than to a particular vendor\’s implementation.
  • It allows application users to integrate their application to other applications with any environment.

Reference: 

Test Pyramid

Who should read it: It is for you if you are looking for an overview of this topic for a project, to conduct/appear in an interview, or in general. As we learn more, we will update this article.

What is Test Pyramid: Test Pyramid is a way to plan the testing efforts on an application. As per this concept, efforts are:

  • Highest in unit Testing
  • Middle level in Service testing
  • Lowest in UI testing

These are key points:

  • Write tests with different granularity.
  • The more high level we go, we should have less test cases.

Different types of tests:

Unit Tests: Stick to one test class per production class. Test the public interface of the class.We can ignore private methods.

Integration Tests: Testing the applications end-to-end.

Contract Tests: It means testing different services via certain interfaces. Contract testing is a way to ensure different services can communicate with each other. Some examples of contract testing tools are OpenAPI, Pact, Postman collections, RAML, and API Blueprint.

UI Tests:  Typically, it means a web interface in the context of web applications.

End-to-End Tests: User interface end-to-end tests. REST API end-to-end tests.

 

Reference: https://martinfowler.com/articles/practical-test-pyramid.html

OOP Concepts

Who should read it: It is for you if you are looking for an overview of this topic for a project, to conduct/appear in an interview, or in general. As we learn more, we will update this article.

In Java, below are OOP concepts:

1. Abstraction:  means hiding the details from the implementation. For example, we do not know details behind the gears of the car.

2. Encapsulation: Encapsulation is the concept to wrap the data under a single unit.

3. Inheritance: Inheritance is the concept to allow an object to inherit properties or behaviors of the parent class into a child class. It creates a parent-child relationship between classes. This concept provides code re-usability and maintainability. Below are types of inheritances:

  1. Single Inheritance: A child class is derived from a single parent class.
  2. Multiple Inheritance: A child class is derived from multiple parent classes. Note: In Java, multiple inheritance was not possible till JDK 1.7. It\’s possible from JDK 1.8 onwards, via the default methods in interfaces. Multiple inheritance via use of interfaces is possible in Java.
  3. Hybrid Inheritance: It is a combination of multiple inheritances. For example, a class A extends another class B and it also implements an interface.

4. Polymorphism: Polymorphism simply means many forms. It is a concept to declare multiple functions with the same name. It is also referred as one name with many forms. For example, ‘+’ operator sums two numbers or concatenates two strings.

There are two types of polymorphism in Java:

  1. Overloading: Overriding is related to compile-time polymorphism. It is also referred as a static binding or early binding. For example, a Java class can have multiple sum() functions with varied number of parameters.
  2. Overriding: Overloading is related to run-time polymorphism. It is also referred as a dynamic binding or method overloading. Dynamic method dispatch is the mechanism by which a call to an overridden method is resolved at runtime. Overriding is the feature that allows a subclass to provide a specific implementation of a method which is already into the super class. It is the type of object being referred to, not the type of reference variable.
Here are some rules for polymorphism in Java:
  1. Final methods can not be overridden.
  2. Status method can not be overridden.
  3. Provide methods can not be overridden.
  4. The overriding method must have same return type as in the base class’s method.
Some key points:
  • Constructors are not members of the class. So, they are not inherited. Constructor of a class can be invoked from another sub-class’s constructor.
References:
Book: Java, The Complete Reference
Other sources on the web

SOLID Design Principles

Who should read it: It is for you if you are looking for a quick overview of this topic for a project, an interview, or in general. As I learn more, I will update this article.

What are SOLID Design Principles:

SOLID Design Principles stand for:

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion
Single-responsibility Principle:
It states that a class should have one and only one reason to change, meaning that a class should have only one job. For example, if a class has a function to calculate the area of the shape ( like circle, square, or a circle), it should focus only on it. If we want to output the result into a JSON or a TEXT format, it is advisable to use another class that forms the output in the desired format. Do just one thing in a class.
Open-Closed Principle:
It states that Objects or entities should be open for extension but closed for modification.
 
Liskov Substitution Principle:
It states that let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. Means, every subclass or derived class should be substitutable for their parent or base class.
Interface Segregation Principle:
It states that a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.
Dependency Inversion Principle:
It states that the entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions. This principle allows decoupling.
 

My list of knowledge sources: Books, Courses, and Other

I am sharing my list of knowledge sources that I liked. If I like a new material, I will add to the list.

Technical books:

  • Design: Art of Scalability, The: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
  • Java The Complete Reference
  • What is Serverless, by Mike Amundsen
  • The Complete Software Product Manager by Anna P Murray
  • Programming PHP, by Kevin Tatroe, Peter Maclntyre
  • Python Data Science Handbook, by Jake VanderPlas
  • NoSQL Distilled: A Brief Guide to the Emerging World of Polygot Databases, by Pramod J. Sadalage, Martin Fowler
  • Python Crash Course, by Eric Matthes

Non-technical books:

  • Elements of Style
  • The Exceptional Presenter
  • Time management: Getting Things Done by David Allen
  • Seven Habits of Highly Effective People by Stephen Covey
  • Influence, by Robert B. Cialdini
  • Sell with a story, by Paul Smith, Mike Weinbeg

Databases basics

Who should read it: It is for you if you are looking for an overview of this topic for a project, to conduct/appear in an interview, or in general. As we learn more, we will update this article.

Why we need distributed databases: 

  • Difficult to store entire data set into a single database
  • Single point of failure
  • Slow in performance
  • If we make a big computer, it will be more expensive

For the distributed database architectures, we have a master database and can have multiple secondary databases. Single node databases are classic databases like PostgreSQL, MySQL, etc. Distributed databases are made of multiple nodes. These are fault tolerant. Database clusters means multiple database instances. In general, we have leader nodes and follower nodes. Leader node is in charge of returning the final data results. Followers receive the data. If the leader node fails, a follower node can become the leader node.

Types of distributed databases:

  • Big compute databases: Split data across multiple nodes. These are suitable for analytical workloads.
  • High availability databases: are extremely fault tolerant. Each node has a full copy of the data.

Some key points about distributed databases:

  • Imbalance node: the problem when a node has more data load. Moving the data between nodes is slow.
  • Asking data from hard disk is slow. Asking data from RAM is fast.
  • Leader node examines the query. Leader node distributes the jobs to different nodes.
  • Sharding: It is a model in that all database instances acts as the primary databases. We segment data into multiple instances. Problem is that if we have more load on one segmented database, it will cause problems. Also, if we have to join data with two databases, we will have network connections.

CAP theorem:

  • C stands for Consistency. If we write information, we want to get same data. That is the consistency. To maintain consistency, data in the primary and secondary databases should replicate asap.
  • A stands for Availability. If we have two databases, if one machine goes down, as a whole system, users should be able to read or write.
  • P stands for Partitions. Partition tells us that even if connections to two machines not working, we should still be able to read/write the data.
  • RBDMS databases provide strong consistency. NoSQL databases generally prioritize availability, partition tolerance, and provide eventual consistency.

As per CAP theorem, generally, databases can achieve up to two features out of three. For distributed databases, assume network failures will be inevitable. So, for distributed databases, we need to choose between C and A.

PACELC theorem:

As per CAPLEC theorem, if partition happens, choose Availability and Consistency. Else, choose Latency and Consistency.

Other theorems:

BASE: BASE stands for Basically Available Soft state Eventually Consistent. NoSQL is an example of a BASE.

  • Basically Available: The system is guaranteed to be available in event of failure.
  • Soft State: The state of the data could change without application interactions due to eventual consistency.
  • Eventual Consistency: The system will be eventually consistent after the application input. The data will be replicated to different nodes and will eventually reach a consistent state. But the consistency is not guaranteed at a transaction level.

Indexes:

Database index is a data structure that helps to retrieve data faster from a table. Indexes are like library catalog that helps to know the location of a book. For more about index, refer here.

Relational databases:

Relational databases store data in rows and columns. Some famous relational databases are MySQL, Oracle, and Postgres.

Advantages of relational databases:

  1. Well defined relationships and structured: data in relational databases is structured, with foreign and primary key constraints. It helps in organizing the data. Defined relationships and structure also helps in retrieving the data effectively.
  2. ACID (Atomicity, Consistency, Isolation, Durability): As relational databases support ACID properties, it’s helpful in ensuring the data changes for a transaction.

Disadvantages of relational databases:

  1. Rigidity due to structured data: As the data is well defined and structured, it’s not easy to store a new data set for that a structure is unknown. For example, to add a new column into a table, the table has to be changed, to support it.
  2. Difficult to scale: scaling means supporting more volume of data. For relational databases, scaling is difficult. For read-only operations, it’s easier to replicate the data. For write operations, a general approach is to add more capacity (vertical scaling) to the primary database server, which is costlier than replacing read-only databases.

NoSQL Databases:

There are multiple types of NoSQL databases like:

  • Key-Value storage type: Data is stored in key-value pairs in arrays. Some examples of such databases are Redis and Dynamo databases.
  • Document databases: In these databases, data is stored in the documents. A collection is a group of documents. Each document can have a different structure. An example of such a database is MongoDB.
  • Wide-column databases: In these databases, the number of columns can vary per row in the same table. We can consider it as a two dimensional key-value storage. Some examples of wide-column databases are Cassandra and HBase. For more, refer here.
  • Graph databases: These represent data in a form of a graph. Examples of such databases are Neo4J and Infinite graph.
  • Some NoSQL databases:
    • Couchbase: It is a NoSQL database that stores the data either in key/value pair or in JSON document format. In a traditional database model, we begin with a schema. We add tables and the columns in the tables.
    • MongoDB: MongoDB is an open source document database. It works on concept of collections and documents. A collection is a document which is equivalent to an RDBMS table. A document is a set of key-value pairs. It is a schema-less database. It is easy to scale. It is a good choice for a Big Data need.

Advantages of NoSQL databases:

  • Flexibility with unstructured data: As the data in NoSQL databases is unstructured, these databases provide more flexibility to store the data.
  • Horizontal scaling: Horizontal scaling means distributing data into multiple server instances. Data in NoSQL databases are distributed, by using sharding. These databases support horizontal scaling for both, read and write operations.

SQL versus NoSQL databases:

  • Storage: Data in SQL databases is stored in rows. NoSQL databases have different data storage models like key-value or graph
  • Schema: SQL databases have a fixed schema. noSQL databases can have different schemas.
  • Querying: SQL databases use Structural Query Language (SQL), to retrieve the data. NoSQL databases uses UnQL (Unstructured Query Language). NoSQL are focused as a collection of documents.
  • Scalability: Horizontal scaling in SQL databases is difficult as compared to NoSQL databases.
  • Reliability: Most SQL databases are reliable and ACID compliant. Whereas, NoSQL databases may compromise reliability and ACID compliance.
  • Language: SQL databases use transactional SQL. They support core ANSI/ISO language elements. Whereas, NoSQL databases are not limited to one particular language. For example, MongoDb uses Javascript based query language.

 How to choose between SQL and NoSQL databases:

  • Consider SQL databases when:
    • Data is structured and structure is not changed frequently.
    • Supporting transaction-oriented use cases.
    • No need to scale the database.
  • Consider NoSQL databases when:
    • Data is not structured and the structure can change frequently.
    • A flexibility of dynamic schema is needed.
    • We anticipate the scaling of the database in the future.
    • Level of data integrity is not needed.

Other databases terms:

  • Purpose built databases: There are many options like relational database, key-value database, document database, graph database, in-memory database, time series database, and ledger database. Depending on the situation, today’s application developers need to pick a right database for the use case, by analyzing pros and cons of the situation.

Partitioning and Sharding: it is the process of splitting the data into columns or features. Vertical partitioning splits the data into the same database by columns or features within the same tables. Horizontal partitioning splits the table data to multiple shards ( e.g. multiple database locations). In case of sharding, a table may have a customer ID 1 on one server and customer ID 2 on another server. In case of partitioning, other customer Ids 1 and 2 are on the same database servers and in the same table.

Distributed transaction types:

  • Two-phase commit (2PC): In case of 2 Phase commit, there is a coordinator that prepares multiple transactions. Then, the coordinator either commits or rolls back all transactions together. While preparing each transactions, the database table rows (that to be updated in DB) are locked using local transactions. This prevents any updates during the 2-phase transaction. We also need to plan for a time limit for each transaction so that the coordinator is waiting to commit or rollback within a defined time period.
  • 3 phase commit: First phase is that the coordinator asks if it’s ok to commit. Second phase is to pre-commit the transaction. Third step is to commit a transaction. I’m yet to learn more and add more notes about it.
  • Try-Confirm/Cancel (TC/C): In the first phase, the coordinator asks all databases to reserve resources. In the second phase, the coordinator captures the replies from all databases. If the response is yes, the coordinator asks all databases to confirm the transaction. If any of the databases respond as no, the coordinator asks all databases to cancel the transaction.
  • Saga: It’s an asynchronous way to achieve the transaction. It’s an event driven process. Micro-services generally use Saga as their default choice. In Saga, all operations are executed in a sequence. When one operation finishes, then the next operation is executed. For the rollback purpose, we need to prepare double operations: one for execution and the another one for the rollback. To coordinate operations in Saga, there are two ways:
    • Choreography: All services do their jobs by subscribing to other services’ events. This is a decentralized coordination.
    • Orchestration: In this way, there is a single coordinator to instruct all services in a defined order.

References:

Serverless concept

Who should read it: It is for you if you are looking for an overview of this topic for a project, to conduct/appear in an interview, or in general. As we learn more, we will update this article.

I was curious to learn about serverless framework. Seems an interesting concept. Does it really work without a server? why to use it? Where to use it? In my notes below, sharing my learnings:

1. What is serverless:

Serverless does not mean there is no server involved. Serverless is an architectural approach to software solutions that relies on small independent functions running on transient servers in an elastic runtime environment. Let\’s break it to understand what it means:

  • Small independent functions: sometimes it\’s also called Functions as a Service.
  • Transient servers: Actual machines hosting it are temporary instances.
  • Elastic environment:  These virtual machines are spun up when needed and spun down when not needed. This elasticity helps in gaining better targeting of resources and better operational cost.

Finally these all (functions, virtual machines, and elastic runtimes) need an architectural approach.

2. Why serverless:

Using serverless reduces time to market an idea with a reduced cost. Below are some pros and cons of using Serverless architectures:

Pros:

  • Developers can focus more on coding for the business logic
  • We can more easily deal with scalability

Cons:

  • Spinning machines take time
  • Debugging is complicated
  • Vendor lock-in

Four characteristics of serverless platforms:

  • Event driven: Serverless has the ability to support event driven architectures.
  • Streaming data: Serverless architecture supports streaming data architectures.
  • Auto-scaling: Serverless architectures have ability to support the ability to scale the capacity of the the solution.
  • Fault-tolerance: For the solutions that needs a \’zero downtown\”, serverless can be a good option to consider.
3. How serverless platforms work:
Serverless architecture approach is to write small functions and link those with the API. So, solutions provide multiple programming options to code the functions. Amazon, Google, and Microsoft are three common and well established hosting platforms.
Serverless use case examples:
  • Small, simple, or complicated web applications
  • Backends
  • Data processing
  • Chatbots
  • IT automation
Reference:
Book: What is serverless, by Mike Andundsen, published by O\’Reilly Media, Inc.
Videos by Amazon Web Services (AWS)

Bootstrap

Who should read it: It is for you if you are looking for an overview of this topic for a project, to conduct/appear in an interview, or in general. As we learn more, we will update this article.

Introduction: Bootstrap is a popular front end framework for HTML, JavaScript, and CSS. It’s useful to build responsive, mobile first websites.

Main features: Bootstrap has really made life simple. Let’s look at some cool features of Bootstrap:

  • Mobile first philosophy: It’s built with the design of Mobile first. It helps to design websites for mobile, tablets, and desktops. It reduces extra efforts for the developers.
  • Responsiveness: Bootstrap grid design has four classes: xs for phones (<768px), sm for tablets (≥768px), md for desktops (≥992px), and lg for larger desktops (≥1200px). To achieve responsiveness, Bootstrap scales up to 12 columns according to the size of the device or a viewport.
  • Some great features of Bootstrap:
    • Forms
    • Images and Icons
    • Buttons and related items
    • Navbars
  • Other benefits of Bootstrap:
    • Faster development: Instead of developing elements from scratch, Bootstrap provides built-in elements and JS plugins
    • Less issues.
    • Extensive list of features.
    • Best styling.
    • Built-in templates for beginners.
    • Excellent support with the community of developers.
    • Browser compatibility with major browsers.
    • Easier to learn.
    • Supports fixed and fluid layouts.
    • Column adjustment features:
      • Offset features to adjust column positions.
      • push and pull options to order the column positions.
      • container function to wrap the content.
    • Built-in pagination support
  • Other similar frameworks:  YUI grids, 960 GS and blueprint.

Get started today with the Bootstrap journey.

A Java developer’s challenge in learning PHP/Laravel

Who should read it: It is for you if you are looking for a quick overview of this topic for a project, an interview, or in general. As I learn more, we will update this article.

As a Java developer of more than 15 + years, I came across a situation to learn Laravel application development. Laravel is a PHP based framework. I will go through my challenges of learning it and how I overcame it.

As an established Java developer, these were my challenges in learning Laravel:

 

Challenge 1: Why Laravel, why not Java based: I love Java based technologies. Why should I deviate from Java technologies and learn Laravel out of the way? Why should I learn PHP and Laravel when I am already experienced in multiple Java frameworks like Struts and Spring?

Challenge 2:  Why to invest my time in a secondary skill set? I primarily like Java based skills. Do not I already have many things to learn in the Java world? Instead of learning Laravel, what if I spend time in further learning more about Java frameworks? Will there be any long term benefit of learning Laravel?

Challenge 3: Will I be accepted as an experienced Laravel professional?  A genuine concern. I have been working on Java skills for more than a decade. How will I be respected in the Laravel community? Am I changing my career path? I always loved Java skills. Why should I deviate from my Java career?

 

Challenge 4: How long will it take to learn Laravel? If I really have to learn, how long will it take to learn it?

 

Challenge 5: How long will it take to develop expertise in Laravel?

I went through many such self-talks. It took few weeks for me to even consider deviating from my existing Java skills set. Here is how I overcame these challenges:

Challenge 1: Why Laravel, why not Java based? Reason is a need and the curiosity. I can understand the need in the project, but let’s explore curiosity. I was so curious to know why the a community of developers prefers Laravel or a similar PHP framework over another skills set like Java. I researched it for few weeks. I also inquired from my friends who are using the PHP/Laravel framework. They all argued that the development speed is faster and cheaper in Laravel, as compared to a Java based framework. Also, the quality of development is great. I challenged them that as an experienced Java developer. I argued I can lead developers to develop Java based applications very fast. But their point of view was the learning curve that Java has. Per them, if a new programmer learns PHP/Laravel in two months, it needs six months to be equally good in a Java based framework. This argument made me more curious to explore Laravel framework.

Challenge 2:  Why to invest my time in a secondary skill set?

In my Java  development  career, many times, I got job offers because of my additional/secondary skills like Epiphany CRM, SAP ABAP, Corda dashboards, Shell, or other skills. Many times, I benefitted by combining a primary and few secondary skills set. I recall a project in that I was the lead developer. In the eco-system, majority of applications were in Java but one application was built in PHP. So, I concluded that it’s a unique skills set to combine Java skills with another demanding skill set. So, I won’t be wasting my time learning Laravel as my secondary skills set.

Challenge 3: Will I be accepted as an experienced Laravel professional? Probably not, but let’s look at some common skills in Laravel and in Java frameworks:

    • Business goals
    • Design principles
    • Web UI skills
    • Database skills
    • Testing strategies

Now, let’s look at some skills that are not common into Java application world:

    • Laravel framework itself
    • Laravel related unique utilities like tinker
    • Laravel specific testing data seed concept

Though we have uncommon things, it’s helpful to learn uncommon skills. It broadens the perspective of knowing new possibilities and for Java frameworks in the future. It can open the perspective of Java developers to come up new features into Java frameworks.

Challenge 4: How long will it take to learn Laravel?

My research indicates that learning Laravel is relatively easier as compared to Java frameworks. But PHP as a pre-requisite. If I spend 3 – 5 hours a week, I calculated about 3 months to learn Laravel. Some would argue it is a long time, but I respectfully disagree with them.

Challenge 5: How long will it take to develop expertise in Laravel?

As per my opinion, no one can really claim being knowledgable in a framework without creating a working application. I planned to spend another 2 months with 3 – 5 hrs/week efforts.

It is been pretty challenging for me to pick up Laravel framework because of the learning curve in it. But so far, I am really enjoying Laravel framework. I really impressed Laravel’s Eloquent Model ORM tool. Throughout my journey, I also realized how challenging it’s been for me to pick up a new technology, which is completely irrelevant to my current skills set. That made me come up with a new upcoming article: How to learn a new technology when you’re already expert in a technical skills set. Stay tuned to read my upcoming article.
I’m looking forward to my journey of learning Laravel.