diff --git a/books/books-to-read.md b/books/books-to-read.md new file mode 100644 index 0000000..68ac282 --- /dev/null +++ b/books/books-to-read.md @@ -0,0 +1,21 @@ +1. The Almanack of Naval Ravikant +2. The choice +3. Atomic habits +4. The 48 Laws of Power +5. The Psychology of Money +6. Thinking, Fast & Slow +7. The Millionaire Fastlane +8. The Power of Now +9. The 4-Hour Workweek +10. Being mortal +11. Rich dad poor dad +12. You are a badass +13. Essentialism +14. How to win freinds and influence people +15. Man;s search for meaning +16. Meditations +17. Autobiography of a Yogi +18. Poor Charlie's Almanack +19. 12 Rules of life +20. How to fail at almost everything and still win big + diff --git a/books/building-event-driven-microservices.md b/books/building-event-driven-microservices.md new file mode 100644 index 0000000..c526bb4 --- /dev/null +++ b/books/building-event-driven-microservices.md @@ -0,0 +1,49 @@ +# Building Event Driven Microservices + +- [1. Why event driven microservices](#why-event-driven-microservices) + - [What are event driven microservices](#what-are-event-driven-microservices) + - [Introduction to domain driven design and bounded contexts](#Introduction-to-domain-driven-design-and-bounded-contexts) + - [Leveraging Domain models and bounded contexts](#leveraging-domain-models-and-bounded-contexts) + - [Aligning Bounded Contexts with Business Requirements](#aligning-bounded-contexts-with-business-requirements) + +## Why event driven microservices +- Network communnications, relational databases, big data developements and cloud computing have significantly altered how architectures are built. +- Have imapacted the way organizations, teams and people communicated with one another. +- Asynchromous events can now be persisted indefinitely at very large sccales and be consumed by any service as many times as necessary. +- compute resourcs can be easily acquired and released on demand, enabling the creation and mgmt of microservices (ms). + +### What are event driven microservices +- Message passing architectures use consumable events to asynchronously communicate with one another. Event based communication helps handling big data sets, at scale and in real time,and thus asks change in the old architectural styles. +- In event driven ms (EDM) system communicated by issuing and consuming events. **These events are not destroyed upon consumption as in message passing systems, but remain readily available for other consumers to read as they require.** +- Services are small, created to help fufill necessaty business goals. They consume events from input event streams; apply their specific business logic; and may emit their own output events, provide data for request-response access, communicate with a third-party API, or perform other required actions. +- Services can be stateful or stateless, complex or simple; and they might be implemented as long-running, standalone applications or executed as a function using Functions-as-a-Service + +### Introduction to domain driven design and bounded contexts +Some important terminology and defeinitions - + - Domain + + The problem space. Encompasses everything that the business must contend with, including rules, processes, ideas, business-specific terminology, and anything related to its problem space- regardless of whether or not the business concerns itself with. The domain exists regardless of the existence of the business. + + - Subdomain + + A component of the main domain. Each subdomain focuses on a specific subset of responsibilities and typically reflects some of the business’s organizational structure (such as Warehouse, Sales, and Engineering). A subdomain can be seen as a domain in its own right. Subdomains, like the domain itself, belong to the problem space. + + - Domain (and subdomain) model + + An abstraction of the actual domain useful for business purposes. The pieces and properties of the domain that are most important to the business are used to generate the model. The main domain model of an business is discernible through the products the business provides its customers, the interfaces by which customers interact with the products, and the various other processes and functions by which the business fulfills its stated goals. Models often need to be refined as the domain changes and as business priorities shift. A domain model is part of the solution space, as it is a construct the business uses to solve problems. + + - Bounded context + + The logical boundaries, including the inputs, outputs, events, requirements, processes, and data models, relevant to the subdomain. While ideally a bounded context and a subdomain will be in complete alignment, legacy systems, technical debt, and third-party integrations often create exceptions. Bounded contexts are also a property of the solution space and have a significant impact on how microservices interact with one another. + +1. Bounded contexts should be highly cohesive. +2. Connections between bounded contexts should be loosely coupled, as changes made within one bounded context should minimize or eliminate the impact on neighboring contexts + +#### Leveraging Domain models and bounded contexts +- The domain is broken down into subdomains—perhaps, for a technology-centric company, an Engineering department, a Sales department, and a Customer Support department. +- Each subdomain has its own requirements and duties and may itself be subdivided. This division process repeats until the subdomain models are granular and actionable and can be translated into small and independent services by the implementing teams. +- Bounded contexts are established around these subdomains and form the basis for the creation of microservices. + +### Aligning Bounded Contexts with Business Requirements +- bounded contexts should be built around business requirements and not technological requirements as it is common for the business requirements of a product to change during its lifetime. +- Aligning bounded contexts on business requirements allows teams to make changes to microservice implementations in a loosely coupled and highly cohesive way \ No newline at end of file diff --git a/books/designing-data-intensive-applications.md b/books/designing-data-intensive-applications.md index ca34231..11dd8d0 100644 --- a/books/designing-data-intensive-applications.md +++ b/books/designing-data-intensive-applications.md @@ -67,7 +67,18 @@ A data-intensive application is typically built from standard building blocks. T * **Scalability**. Reasonable ways of dealing with growth. * **Maintainability**. Be able to work on it _productively_. +A lot of tricky questions arise when designing a data system: +1. How do you ensure that the data remains correct and complete, even when things go wrong internally? +2. How do you provide consistently good performance to clients, even when +parts of your system are degraded? +3. How do you scale to handle an increase in load? +4. What does a good API for the service look like? + +One possible architecture of data systems + +![](img/designing-data-intensive-applications/1-1.png) ### Reliability +(Roughly speaking - continuing to work correctly even when things go wrong) Typical expectations: * Application performs the function the user expected @@ -103,6 +114,9 @@ Twitter main operations - Post tweet: a user can publish a new message to their followers (4.6k req/sec, over 12k req/sec peak) - Home timeline: a user can view tweets posted by the people they follow (300k req/sec) +![](img/designing-data-intensive-applications/1-2.png) +![](img/designing-data-intensive-applications/1-3.png) + Two ways of implementing those operations: 1. Posting a tweet simply inserts the new tweet into a global collection of tweets. When a user requests their home timeline, look up all the people they follow, find all the tweets for those users, and merge them (sorted by time). This could be done with a SQL `JOIN`. 2. Maintain a cache for each user's home timeline. When a user _posts a tweet_, look up all the people who follow that user, and insert the new tweet into each of their home timeline caches. @@ -132,6 +146,8 @@ It's common to see the _average_ response time of a service reported. However, t * _Median_ (_50th percentile_ or _p50_). Half of user requests are served in less than the median response time, and the other half take longer than the median * Percentiles _95th_, _99th_ and _99.9th_ (_p95_, _p99_ and _p999_) are good to figure out how bad your outliners are. +![](img/designing-data-intensive-applications/1-4.png) + Amazon describes response time requirements for internal services in terms of the 99.9th percentile because the customers with the slowest requests are often those who have the most data. The most valuable customers. On the other hand, optimising for the 99.99th percentile would be too expensive. @@ -153,6 +169,8 @@ When generating load artificially, the client needs to keep sending requests ind * _Scaling out_ or _horizontal scaling_: Distributing the load across multiple smaller machines. * _Elastic_ systems: Automatically add computing resources when detected load increase. Quite useful if load is unpredictable. +![](img/designing-data-intensive-applications/1-5.png) + Distributing stateless services across multiple machines is fairly straightforward. Taking stateful data systems from a single node to a distributed setup can introduce a lot of complexity. Until recently it was common wisdom to keep your database on a single node. ### Maintainability diff --git a/books/img/designing-data-intensive-applications/1-1.png b/books/img/designing-data-intensive-applications/1-1.png new file mode 100644 index 0000000..13d9ad3 Binary files /dev/null and b/books/img/designing-data-intensive-applications/1-1.png differ diff --git a/books/img/designing-data-intensive-applications/1-2.png b/books/img/designing-data-intensive-applications/1-2.png new file mode 100644 index 0000000..b4121e3 Binary files /dev/null and b/books/img/designing-data-intensive-applications/1-2.png differ diff --git a/books/img/designing-data-intensive-applications/1-3.png b/books/img/designing-data-intensive-applications/1-3.png new file mode 100644 index 0000000..3c48812 Binary files /dev/null and b/books/img/designing-data-intensive-applications/1-3.png differ diff --git a/books/img/designing-data-intensive-applications/1-4.png b/books/img/designing-data-intensive-applications/1-4.png new file mode 100644 index 0000000..8aae5f6 Binary files /dev/null and b/books/img/designing-data-intensive-applications/1-4.png differ diff --git a/books/img/designing-data-intensive-applications/1-5.png b/books/img/designing-data-intensive-applications/1-5.png new file mode 100644 index 0000000..0e04ebf Binary files /dev/null and b/books/img/designing-data-intensive-applications/1-5.png differ diff --git a/books/img/designing-data-intensive-applications/2-1.png b/books/img/designing-data-intensive-applications/2-1.png new file mode 100644 index 0000000..6da84ee Binary files /dev/null and b/books/img/designing-data-intensive-applications/2-1.png differ diff --git a/books/img/microservices-with-spring/1.1.png b/books/img/microservices-with-spring/1.1.png new file mode 100644 index 0000000..d30b1dd Binary files /dev/null and b/books/img/microservices-with-spring/1.1.png differ diff --git a/books/microservices-with-spring.md b/books/microservices-with-spring.md new file mode 100644 index 0000000..ccba6eb --- /dev/null +++ b/books/microservices-with-spring.md @@ -0,0 +1,34 @@ +## Introduction to Microservices + +Main aim is to build scalable, resilient and managaeable microservices. + +Look at C4 model https://c4model.com - it is a software architecture diagramming guide. + +The microservices architecture uses **autonomous software component** -> having own persistent data and only communicated with other components using well defined APIs + +![](img/microservices-with-spring/1.1.png) +We can see that each component has its own storage for persistent data and is not sharing DB with other components + +### Benefits of autonomous software components +1. Customer can deploy parts of the platform in its own system landscape. +2. Another customer can choose to replace parts of the platforms functionality with implementations that already exist in the customer system landscape, potentially requiring some adoption of the existing functionality in the platforms API. +3. Each component in the platform can be delivered and upgraded separately. Thanks to the use of well defined API. One component can be upgraded to a new version without being dependent on the life cycle of the other components. +4. Due to well defined APIs, each component in the platform can also be scaled out to multiple servers independently of the other components. Scaling can be done better to meet high availability requirements or to handle higher volumes of requests. It can be achieved by manually setting up load balancers in front of a number of servers each running in Java web container. + +### Challenges with autonomous software components +1. Adding new instances -> required manually configuring load balancers and many setting up new nodes. +2. Communication -> If a system stopped responding to request that was sent from the platform in a timely fashion, the platform quickly ran out of crucial resources. e.g., OS threads specifically exposed to large number of concurrent requests. -> hang or even crash. Synchronous communication can lead to cascading failures -> chain of failures. +3. Keeping the configuration in all the instances of the components consistent and up to date. +4. Monitoring the state of the platform in terms of latency issues in hardware usage. For example, you CPU, memory, disks and the network. +5. Collecting log files from number of distributed components and correlating related log events from the components. + +### Enter microservices +Some important terminologies +1. Vertical scaling (And more resources like CPU, RAM etc.) +2. Horizontal scaling. (Deploying a component on a number of smaller servers and placing load balance in front of it.If done in the cloud,the scaling capability is potentially endless. It is just a matter of how many virtual servers you can bring in.) + +Some open source projects that delivered tools and frameworks that prefer the developer of Microsoft Office and could be used to handle the challenges that come with micro services are as follows: +1. Spring Cloud, which wraps parts of Netflix OSS in order to provide capabilities such as Dynamic Service Discovery, configuration management, distributed tracing, circuit breaking and more. +2. Docker.Is great for minimising the gap between development and production.Packaging a component not only as deployable runtime artifact but as complete image ready to be launched as a container on a server running Docker. +3. A container engine is not enough to be able to use containers in a production environment.Some things needed that can ensure that all the containers are up and running and can scale out the containers on the number of servers providing high availability and increased computer resources.These type of product, known as container orchestrators.like Kubernetes, Apache Mesos, Mazon ECS, Hshicorp Nomad. +4. Service mesh - Complementary Container office Twitter. To further offload microservices from responsibilities to make them manageable and resilient. diff --git a/books/mircroservices patterns - examples in java.md b/books/mircroservices patterns - examples in java.md new file mode 100644 index 0000000..7684500 --- /dev/null +++ b/books/mircroservices patterns - examples in java.md @@ -0,0 +1,20 @@ +# Microservices Patterns - with examples in Java + +- [Escaping monolithic hell](#escaping-monolithic-hell) + - d + +- [Decompositoin strategies](#) +- [Interprocess communication in a microservicearchitecture](#) +- [Managing transactions with sagas](#) +- [Designing businesss logic in a microservice architecture](#) +- [Developing business logic with even sourcing](#) +- [Implementing queries in a microservice architecture](#) +- [External API parterns](#) +- [Testing microservices - Part 1](#) +- [Testing microservices - Part 2](#) +- [Developing production ready services](#) +- [Deploying microservices](#) +- [Refactoring to microservices](#) + +--- +## Escaping Monlithic Hell diff --git a/lifestyle/increase-productivity.md b/lifestyle/increase-productivity.md new file mode 100644 index 0000000..059b3ac --- /dev/null +++ b/lifestyle/increase-productivity.md @@ -0,0 +1,51 @@ + +## Increase productivity with the following tips +### Unnecessary fitness + +1. Fitness can take forever. +2. Work like a lion; also workout like a lion. +3. I do 20 min of high intensity cardio and 30 min of yoga every day. <1 hr all in. +4. And I’ve never felt healthier. + +Savings: 5-10 hrs/wk + + +### Unfruitful friendships + +1. Relationships can be the most rewarding thing in the world. +2. They can also be the most costly. +3. Ask yourself the question: “is this person helping me grow?” +4. If the answer is no, it might be time to move on. + +Savings: 5-15 hrs/wk + + +### Easy-to-outsource tasks +1. Whatever you can afford to outsource, do it. +2. Determine your hourly rate (ie what is your time worth?) +3. Anyone you can pay to do the tasks for you at a lower rate, do so. +4. Having a part time assistant, even virtual, goes a long way. + + + +> Here are some other quick tips: +1. Sleep at the same time every night +2. Audit your calendar daily +3. Prepare food in bulk +4. Automate everything + + +> And most importantly, + +*No multitasking*. + +*Focus focus focus... It’s everything.* + + +And that’s it folks! + +### Maximizing productivity means you can get more done with less time. + +### This gives you more time to enjoy other things in life outside of work. + +### Work with an insatiable focus, so you can unplug with that same focus \ No newline at end of file diff --git a/stockMarket/Formation of FTR.md b/stockMarket/Formation of FTR.md new file mode 100644 index 0000000..e69de29 diff --git a/stockMarket/README.md b/stockMarket/README.md new file mode 100644 index 0000000..e69de29 diff --git a/stockMarket/Setup1.md b/stockMarket/Setup1.md new file mode 100644 index 0000000..ed0f498 --- /dev/null +++ b/stockMarket/Setup1.md @@ -0,0 +1,28 @@ +This setup contains 4 parts. + +# If the BO happens in the same direction + +> Entry +1. Identify sharp turning points +2. Clear FTR should be made. If clear FTR is not made, no setup. Let the mkt go.. +3. Wait for a retrace to the FTR. +4. Buy on the retrace. (FTBs are the best) + +*DO NOT TAKE TUCHA-TUCHA TRADES (Take trades only with good R:R)* + +>Target + +>StopLoss + +> Problems that arise when using this setup +1. The FTR formaton may take some time. See FTR notes, how to get a ***tradable*** FTR + +>Some exampes are shown: +1. ![Setup1](img/setup1.png) +In this example, FTR took a lot of time to get finalized +2. ![Setup2](img/setup2.png) +In this example, see the momentum after on FTB +3. ![Setup3](img/setup3.png) +In this example, see the momentum after on FTB +4. ![Setup3](img/setup5.png) +In this example, market breached first FTR but pulled up due to fat FTR? \ No newline at end of file diff --git a/stockMarket/Setup2.md b/stockMarket/Setup2.md new file mode 100644 index 0000000..20b53b8 --- /dev/null +++ b/stockMarket/Setup2.md @@ -0,0 +1,19 @@ +This setup contains 4 parts. + +# If the BO happens in the same direction + +> Entry +1. + +*DO NOT TAKE TUCHA-TUCHA TRADES (Take trades only with good R:R)* + +>Target + +>StopLoss + +> Problems that arise when using this setup +1. The FTR formaton may take some time. See FTR notes, how to get a ***tradable*** FTR + +>Some exampes are shown: +1. ![Setup3](img/setup4.png) +A beautiful setup \ No newline at end of file diff --git a/stockMarket/img/Setup1.png b/stockMarket/img/Setup1.png new file mode 100644 index 0000000..8683bc8 Binary files /dev/null and b/stockMarket/img/Setup1.png differ diff --git a/stockMarket/img/Setup2.png b/stockMarket/img/Setup2.png new file mode 100644 index 0000000..849a577 Binary files /dev/null and b/stockMarket/img/Setup2.png differ diff --git a/stockMarket/img/Setup3.png b/stockMarket/img/Setup3.png new file mode 100644 index 0000000..399fad7 Binary files /dev/null and b/stockMarket/img/Setup3.png differ diff --git a/stockMarket/img/Setup4.png b/stockMarket/img/Setup4.png new file mode 100644 index 0000000..b183b18 Binary files /dev/null and b/stockMarket/img/Setup4.png differ diff --git a/stockMarket/img/Setup5.png b/stockMarket/img/Setup5.png new file mode 100644 index 0000000..e36ac5c Binary files /dev/null and b/stockMarket/img/Setup5.png differ