Posts

Head First Architecture Chapter-4

Image
In this chapter we discuss the logical components and how we would come up with them. The book suggests following the below flow chart to devise the logical components:  Step 1 : Identifying initial core components:   this is purely a guessing game and most likely we refactor the components we come up with into others, so we should not spend a lot of time thinking of how big or small our components are. The chapter shows two common approaches to get to the core components: 1- Work flow approach: By thinking about the major workflow of the system,or the journey the user might take through the system. 2- Actor/Action approach:  This is particularly if you have multiple users in the system.First we start by identifying the various actors , then identify the primary actions they might take and assign each action to a new or existing component. Th chapter then advises against having vague names for the components especially those with names like manager , controller or su...

Head First Architecture Chapter-3

Image
 This chapter is mainly about the fact that software architecture has a lot of tradeoffs. An Application Scenario: A scenario was given about an application for selling sneakers (this could be anything tbh), that helps people buy, sell, and trade collectible sneakers.  The initial architecture was simple a single service that responds to requests send by mobile app users. So there are 2 options we might get into the tradeoff between them , which are using queues or using topics for messaging : so we can do the tradeoff analysis for each approach of them: 1- Queue approach  Pros:  a- It is more secure as the publishing service is aware of the receivers as each new service would have a new queue and the publishing service would need to know about it to send to it. b- we can have a different format for each receiver. c- we can scale and monitor independently each queue.  2- Queue approach Cons: a- Higher degree of coupling which hurts extensibility. b- Require...

Head First Architecture Part-2

Image
 This is the second part of covering the book Head First Software-Architecture, in this second chapter the emphasis was on the Architectural characteristics which is the first dimension of the software architecture. What is it ? There is no standard term for Architectural characteristics, sometimes these are called non functional requirements which is not accurate as these are indeed functional requirement they are just not related to the domain.Sometimes it is called cross-cutting requirements. Architects break down structure design for software system into two types: 1- Logical components: this represents the domain of the application ,the motivation for writing the software system. 2- Architectural characteristics: these are the important parts of the construction process of the software system independent of the domain. Further more we can say that Architectural characteristics have 3 main points: a- They specify a non domain design consideration: while the requirement decides ...

Head First Architecture

Image
 I have found out that there is a new book that is under early release version on the O'reilly website  called Head First Architecture that is to follow on the great Head First series , as I have read the Head First Design patterns book and really liked it several years ago and the fact that Neal Ford  (One of the authors of Software Architecture An Engineering Approach) is one of the authors, I take a look on it and found that it really is adding a lot of value at least for me, so I am doing a brief summary of it in the next couple of posts hopefully. At first it draws an analogy between building houses and building software systems, in this analogy the building plan or the blueprint of houses is the equivalent of the software architecture, what might be the similar point between both: 1- Both specify the structure of the system, in the house case it defines the rooms, walls, stairs and floors, in the case of the software system it defines the databases, services, user-i...

Algorithms to live by -The optimal stopping problem

 I have read about this book for  a while now, before I have chosen to read it , it is about some algorithms that may have encountered most of us with some algorithms that may be helpful to solve them, so this pots would be mainly some brief notes about it.  for example the main hiring dilemma, when should we stop interviewing candidates and get the best so far, the same goes for the finding an apartment , or even for marriage seeking !!!. all of these had the same problems, that we may stop early so we are missing a better candidate/apartment that we have not see yet, or we can stop late , meaning we have already met the best candidate/seen the best apartment but we have bypassed this one in hope of finding a better candidate/apartment.  The optimal strategy is to find the balance between the two, which was introduced as look then leap rule, you do not choose anyone no matter how good/impressive are they . Then you are in the leap phase where you are to choose anyon...

The Culture Map -Some notes

Image
 I have been reading over the last few days  a book titled the Culture Map, it is extremely amusing and a clear eye opener for me . It is about the different culture contexts and how they can affect us in the work environment , implicitly and unintentionally sometimes. This also does not mean to follow  the different stereotypes as people from same country can different traits for sure, but also the cultural effect can have huge impacts on behaviors for sure. The Book Defines 8 Scales /Measurements that are needed in any business environment and how the cultural differences might affect them. 1- Communication: Low Context vs High Context : There are some cultures that start any communication without suggestion that there is a common context between different parties , that is why they tend to clearly document every step and  leave no space for speculation those are low context style of communication. While there are some other cultures that tend to assume an existing...

very brief Introductory notes On Microservices

Image
 This would be mainly some notes I have took 3- years ago when I first read Sam Newman's book building microservices, along with some points gathered along the time since then. Let's start with a definition , what are microservices: These are independently deployable small services build around a business domain.  a little bit of details, These Microservices needs to be: 1- Able to change independently of each other. 2- Be Deployed by  themselves without requiring the consumes to change. 3- All communications between the services are via network calls to enforce separation and avoid the perils of tight coupling. some other Key points to the core of the definitions and introduction: How small is small: a Microservice is something that could be rewritten in around 2 weeks. (I believe this might be debatable or controversial). Another suggestion is that it should be small enough that you can keep the structure in your mind another key notice from Sam Newman, was that it seem...