+
+ A causal loop diagram of coffee cup cooling, where a balancing loop is trying to bring the discrepancy between coffee’s temperature and room temperature to zero.
+
+
+
+
+
+ A causal loop diagram of Interest bearing bank account, where a reinforcing loop is in place which enables the growth of the money in the bank account as a constant fraction of itself.
+
+
+
+With the help of causal loop diagrams, we can map out the structure of these systems and identify what is keeping the system functional and archetypes, which are the problem-generating structures in the systems.
+
+In this blog, we will explore a common archetype in a system and pinpoint strategic points for intervention within the system.
+
+## Policy Resistance archetype
+
+In a multinational enterprise
+
+- For consistency, the enterprise architect has issued a standard to use DDD for all development.
+- The development team is slow in adopting, complaining that this is a bottleneck that reduces delivery speed.
+- The architect tries to fix it with.
+ - Automated compliance checking.
+ - Spend more time on architecture review.
+ - Ask everyone to follow design specifications.
+
+This is a common system trap called “Policy Resistance” occurs when the actors within the system “resist” the rules or laws imposed on them. The goals of the policy do not align with the goals of the actors.
+
+ To achieve the desired consistency, the architect has introduced a policy to allocate more time to architecture reviews. However, developers are not pleased with this policy because it is adversely affecting delivery speed. In this system, when architects introduce new policies aimed at ensuring consistency and they prove to be effective, it tends to divert developers from their primary goal of speedy delivery.
+
+### **The way out of the Policy resistance trap by using leverage points**
+
+1. **Improve information flow:** Communicate the mission; provide education on DDD.
+2. **Change the rule and authority:** Relax standards to focus on interoperability, introduce optional guidelines, and change the review process to consultation.
+3. **Increase self-organization:** Create a community of practice where individuals from development teams can provide input to standards and guidelines.
+4. **Change goals and purpose:** Elevate the purpose from “consistency” to goals that help development teams: delivery speed.
+5. **Shift the paradigm:** Redefine the development team’s perception of architecture.
+
+## Where to apply Systems Thinking?
+
+- Not everywhere!
+- Issues that won’t go away
+- Issues that get worse the more you try to fix them
+- “Paradigm shifting” changes in technology or approach
+
+## Key Takeaway
+
+By identifying patterns and problem-generating structures, we can strategically intervene and make more effective changes. It is a valuable approach for addressing persistent issues and driving paradigm-shifting changes in technology or approach.
+
+## Follow the below resources to learn more about Systems Thinking
+
+- [Thinking in Systems by Donella H. Meadows](https://en.wikipedia.org/wiki/Thinking_In_Systems:_A_Primer)
+- [Leverage Points](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/)
+- [Keynote: Systems Thinking — Kent Beck & Jessica Kerr](https://www.youtube.com/watch?v=z8bL_V9in9o)
diff --git a/content/blog/learnings-from-clean-coder.md b/content/blog/learnings-from-clean-coder.md
index 6148d7271..692921e84 100644
--- a/content/blog/learnings-from-clean-coder.md
+++ b/content/blog/learnings-from-clean-coder.md
@@ -71,11 +71,11 @@ Writing tests is often seen as something which takes a lot of time and doesn’t
However, that’s far from the truth, writing tests unravels many aspects we would have not uncovered otherwise.
A good test suite could be a challenge to write, but the F.I.R.S.T. principle can help us out:
-* Fast – Tests should run fast. If they are slow, nobody would want to run them.
-* Independent – Each test should be independent of other tests, and they should be isolated enough to be run individually.
-* Repeatable – They should be environment-independent. Should run on dev, prod, QA, etc.
-* Self-Validating – The test should either pass or fail. Anything in between means more time would be wasted on reading log messages.
-* Timely – Unit tests should be written before writing the production code. Tests serve their purpose only when written in a timely manner.
+- Fast – Tests should run fast. If they are slow, nobody would want to run them.
+- Independent – Each test should be independent of other tests, and they should be isolated enough to be run individually.
+- Repeatable – They should be environment-independent. Should run on dev, prod, QA, etc.
+- Self-Validating – The test should either pass or fail. Anything in between means more time would be wasted on reading log messages.
+- Timely – Unit tests should be written before writing the production code. Tests serve their purpose only when written in a timely manner.
Core learning: Having a good test suit is important.
@@ -85,12 +85,12 @@ Coding is hard enough without concurrency.
It has its unique challenges – complexity, overhead, non-repeatability of bugs, etc. and as such it requires a fundamental change in the design strategy.
That being said, some principles must be followed if we want to include concurrency in our system:
-* Single Responsibility Principle – Keep concurrent code separate from non-concurrent code
-* Encapsulation – Limit access to the shared data
-* Know the Library – Understand the concurrency library inside-out
-* Keep It Simple, Silly – Make sure that non-concurrent code runs and functions properly first
-* Platforms – Run your concurrent code on different platforms
-* Go back to the basics – Problems like Consumer-Producer, Dining Philosophers, and Reader-Writers are a good start for selecting an execution method for concurrent code
+- Single Responsibility Principle – Keep concurrent code separate from non-concurrent code
+- Encapsulation – Limit access to the shared data
+- Know the Library – Understand the concurrency library inside-out
+- Keep It Simple, Silly – Make sure that non-concurrent code runs and functions properly first
+- Platforms – Run your concurrent code on different platforms
+- Go back to the basics – Problems like Consumer-Producer, Dining Philosophers, and Reader-Writers are a good start for selecting an execution method for concurrent code
Core learning: Follow best practices.
diff --git a/content/blog/learnings-from-terraform.md b/content/blog/learnings-from-terraform.md
index 144ab1843..652a5e371 100644
--- a/content/blog/learnings-from-terraform.md
+++ b/content/blog/learnings-from-terraform.md
@@ -11,21 +11,24 @@ categories = ["Playbook", "Software Craftsmanship", "Learnings", "Terraform", "I
type = ""
+++
-
## Preface
+
Terraform is infrastructure as a code. I know it is a fancy word but here is the meaning.
If you want to create one virtual machine in AWS, you go to their website and click a few buttons, and it creates the instance. What if there are 15 such VMs and all have some security configuration, doing it manually is not only tedious but erroneous as well.
Terraform provides a nicer way to manage infrastructure in code. The following example creates a virtual machine in AWS
+
```terraform
resource "aws_instance" "app_server" {
instance_type = "t2.micro"
}
```
+
It will create, update, or delete resources using simple commands
## Goal
+
After using terraform in multiple projects, here are my learnings from experience.
It can be used as a best practice as well.
@@ -33,6 +36,7 @@ It can be used as a best practice as well.
Feel free to add yours.
## State in cloud
+
Terraform stores its 'state' in a local file. The state is a list of created resources using Terraform.
In the above example, it will make an entry in the state file with `aws_instance` with ID generated by AWS. So when we try to `apply` the configuration again, it won't create already created resources.
@@ -42,6 +46,7 @@ Since the default way of storing the state is in a local file, most beginners do
We should always store the state in **cloud file storage**. For example, AWS store the state in 's3', for Azure store in 'Azure Blob Storage'. The reason behind that is, if your local machine got crashed, the state is always stored in the cloud, somewhere safe.
## Store and run as a pipeline
+
Always run the Terraform commands from the pipeline and not from your local machine.
At least transactional commands like `apply` (to create/update) and `destroy` (to delete!)
@@ -49,9 +54,11 @@ At least transactional commands like `apply` (to create/update) and `destroy` (t
The idea behind Terraform is to have 'infrastructure as code'. Since it is a 'code' it needs to be committed inside a repository.
## Version number is mandatory
+
Always specify a version number for any resource you create.
Following is an example for creating one AWS RDS MySQL instance,
+
```terraform
resource "aws_db_instance" "default" {
db_name = "mydb"
@@ -59,6 +66,7 @@ resource "aws_db_instance" "default" {
instance_class = "db.t3.micro"
}
```
+
Here we are not defining a property called `engine_version`. It is taken by default as the `latest`. Suppose now the latest is 5.7 but after a few months, the latest becomes `8`. The version change might have breaking changes introduced. The application will start breaking.
The biggest issue is, nobody would know why the app is crashing without any code change.
@@ -66,6 +74,7 @@ The biggest issue is, nobody would know why the app is crashing without any code
MySQL might be a poor example because the version number is very important in that, however, things like the docker image version, helm chart version are often taken/used as the latest
## No manual changes in managed services
+
We might face some important issues or requests that require immediate fixes. Or we might be trying to play around with resources to do POC or want to check capabilities. In these cases, instead of updating resources using Terraform, we often go to the web console and update the resources there.
This is a big no-no. Don't manage the resources that are managed by Terraform.
@@ -77,6 +86,7 @@ The problem with this example is, Cognito does not support field deletion. So th
If you want to play around, do it using Terraform or create a separate resource.
## Think about the environments
+
When we get a requirement to create resources, we jump into the task, create a bunch of resources, and declare that the task is done. The developers start using those resources and are happy.
As soon as we have to create a 'test' or a 'staging' environment, we are stuck because we only created resources for 'dev' environment, we have to now replicate the whole code chunk to create other environments.
@@ -86,17 +96,21 @@ Always create the resources in such a way that when we have to duplicate the res
There are multiple ways to manage the environments like modules, variable files, or ENV variables. It might require a separate post to weigh the pros and cons. But think about the reusability at the start.
## Think about duplication of resources
+
Let's assume you thought about environments and now creating templatized resources.
For example, here is the code to create one role
+
```terraform
resource "aws_iam_role" "reader" {
name = "reader"
}
```
+
The problem with this approach is, since the naming is static, if you create two environments from the same account, it will try to create the role `reader` in the same account. Roles have a validation that its name cannot be duplicated.
Always define the name of the resources dynamically like below. So for each environment, it creates a uniquely identifiable resource
+
```terraform
resource "aws_iam_role" "reader" {
name = "${clustername}-${env}-reader"
@@ -104,9 +118,11 @@ resource "aws_iam_role" "reader" {
```
## Think about enabling and disabling a feature
+
Always think about enabling or disabling a feature, in other words, most of the resources should be created optionally, preferably using variables.
It might be possible that one of the environments does not require RDS MySQL instance. Here is the code to create one MySQL
+
```terraform
resource "aws_db_instance" "default" {
db_name = "mydb"
@@ -114,7 +130,9 @@ resource "aws_db_instance" "default" {
instance_class = "db.t3.micro"
}
```
+
Since you now want to make this optional, you will introduce a variable that will create the resource only if the variable is `true`, for example as below
+
```terraform
resource "aws_db_instance" "default" {
count = var.is-mysql-required ? 1 : 0
@@ -123,11 +141,13 @@ resource "aws_db_instance" "default" {
instance_class = "db.t3.micro"
}
```
+
The problem with this transition is, since we introduced a `count` property, it will destroy the old instance and try to recreate a new one.
It might not be a problem for cattle type of resources (a resource that does not persist in any state and can be destroyed and recreated at any time). However, resources like MySQL have data and if we recreate it, we might lose the data.
## Think about the availability of managed services
+
This is not specifically for Terraform but can be applied to any cloud architecture.
When you are trying to create a resource that is the managed service of that cloud provider, always make sure it is available in all the regions you are intending to create environments in.
@@ -139,6 +159,7 @@ There are two problems here, if we didn't have the resources as optional using v
Another thing is, when we are choosing services, always think about alternatives and don't rely too much on one specific service. (this is subjective and use your judgement)
## Think about how to pass a value instead of creating a resource
+
This is loosely related to the previous two topics, if a resource is not created, then try to think if there is a way to pass a value instead of creating that resource.
For example, AWS Cognito is not available in Indonesia Jakarta as well. Since that resource is optional, we are not creating it. The problem is, there could be some other resources, that might require the `issuer URL` of the Cognito. Now we choose to use Cognito from some other environment. So if we keep a provision to provide the `issuer URL` directly in case a resource is not created, that would be helpful.
@@ -146,6 +167,7 @@ For example, AWS Cognito is not available in Indonesia Jakarta as well. Since th
Another example is, if we don't want to terraform to create a security group but want to reuse an existing one, we might provide the id of an existing security group.
## Common things
+
Don't keep everything under the template boundary.
For example, one time thing like `ECR` (it is a repository for docker images), you would want to create that only once and all the environment needs to access the same repository.
@@ -153,15 +175,17 @@ For example, one time thing like `ECR` (it is a repository for docker images), y
If that resource is inside the template then it would be created multiple times, which is a waste of money as well as creates issues of unnecessary duplication.
## Think about account separation
+
This is again more related to the cloud instead of Terraform. However, when you create multiple environments, think about how you want to separate them.
Some options are:
+
- Create in the same account
- Create in the different account
- Create in separate the resource group (Azure).
## Cross access
+
Since some resources should be accessible from any environment, think about how will you provide cross env access.
For example, ECR (Container registry - docker image repository) needs to be accessed from any authorized env.
-
diff --git a/content/blog/managing-remote-working.md b/content/blog/managing-remote-working.md
index 527ce255c..64bc95262 100644
--- a/content/blog/managing-remote-working.md
+++ b/content/blog/managing-remote-working.md
@@ -8,14 +8,6 @@ title = "Managing Remote Working Teams"
+++
-
Born in the Covid-19 era, we are a sappling in a hailstorm. Having been remote since day-1 we can honestly say that there are two sides to the coin.
The biggest pro to being totally remote helps us hire talent irrespective of their geographical location and this lets us access the perfect people who have the right tech skills as well as the cultural core values that we hold oh so dear.
-
-
-
-
-
-
-
diff --git a/content/blog/monkey-patch.md b/content/blog/monkey-patch.md
index 49bd822fd..262921900 100644
--- a/content/blog/monkey-patch.md
+++ b/content/blog/monkey-patch.md
@@ -31,9 +31,11 @@ sound = Sound.new
sound.car #=> honnnnnk...
sound.bike #=> peep-peep
```
+
In the above code snippet, we reopen Sound class to add a new method. This way we can override the existing method of the original class.
#### When to Use Monkey Patching
+
Usually, programmers implement this technique when they need to add a quick fix. This could be adding functionality to existing code or replacing code for testing when modifying source code is impractical.
1. When you encounter a bug in a gem or library without an available patch or fix, you can temporarily address it within your own codebase using monkey patching.
@@ -47,11 +49,12 @@ Monkey patching can make code more difficult to understand and maintain, leading
```ruby
class String
def upcase
- # do nothing
+ # do nothing
end
end
```
-In the above example, we modify the built-in String class by redefining the behavior of its `upcase` method to return nothing. This alteration has unintended consequences, as it will affect the outcome whenever the `upcase` method is invoked.
+
+In the above example, we modify the built-in String class by redefining the behavior of its `upcase` method to return nothing. This alteration has unintended consequences, as it will affect the outcome whenever the `upcase` method is invoked.
While monkey patching offers flexibility, it also introduces potential drawbacks:
@@ -71,7 +74,6 @@ While monkey patching offers flexibility, it also introduces potential drawbacks
#### Conclusion
-Monkey patching has gained popularity as a power tool in Ruby because of the havoc it can wreak if misused. While monkey patching offers flexibility, it should be considered a last resort due to its potential risks.
+Monkey patching has gained popularity as a power tool in Ruby because of the havoc it can wreak if misused. While monkey patching offers flexibility, it should be considered a last resort due to its potential risks.
Meanwhile, it doesn't hurt to be a good samaritan and contribute to open source. When a bug is discovered in a third-party library, raise an issue, fix it, and get the pull request merged.
-
diff --git a/content/blog/notalltestsarethesame.md b/content/blog/notalltestsarethesame.md
index 1b3596818..c848d18fc 100644
--- a/content/blog/notalltestsarethesame.md
+++ b/content/blog/notalltestsarethesame.md
@@ -11,8 +11,7 @@ title = "Not All Tests are the Same"
+++
-
-On multiple occasions, I have worked on projects where I learned how critical testing is and that not all tests are the same.
+On multiple occasions, I have worked on projects where I learned how critical testing is and that not all tests are the same.
They differ from each other in at least two ways, speed of execution and risk of failure.
@@ -49,4 +48,3 @@ This scoring finally should be arranged in a matrix like the following image.
{{< figure src="/images/2021/01/Pasted-image-20210123205213.png" >}}
The product of these two measures gives you a _Risk Score_ for each of the test cases. For example, you may decide to prioritize every test case that gets a score of 12 and higher. These test cases are the high impact, high likelihood ones that must pass even before the alpha version of a product comes out, giving the alpha version a certain basic stability while ensuring an early rollout.
-
diff --git a/content/blog/one-year-of-incubyte.md b/content/blog/one-year-of-incubyte.md
index 548acae7a..8cb99c97c 100644
--- a/content/blog/one-year-of-incubyte.md
+++ b/content/blog/one-year-of-incubyte.md
@@ -10,9 +10,6 @@ tags = ["Playbook"]
title = "One Year Of Pandemic & One Year Of Incubyte"
+++
-
-
-
It all started when— unbeknownst to the world, a series of lockdowns changed the way India Inc. operated. The world hit a big fast-forward button to the future of remote work. And right around that time, in February of 2020, a small team that called itself Incubyte set out on its own mission in this new normal.
A common goal to create well-crafted software and promote better coding practices in India is what brought the team together. This blog commemorates our first anniversary, but more than that, it is a tribute to Incubyte’s wonderful journey and the individuals who have contributed to it.
@@ -47,12 +44,12 @@ We have teammates from tier 2 and tier 3 cities like Guwahati, Udaipur, Rajkot,
Here are some benefits we experienced ourselves in this new normal:
-* Work from the comfort of our own homes
-* No commute stresses
-* Impact on sustainability
-* Cuts additional costs of working away from home
-* Re-distribution of the workforce
-* More time to pursue other hobbies/pet projects
+- Work from the comfort of our own homes
+- No commute stresses
+- Impact on sustainability
+- Cuts additional costs of working away from home
+- Re-distribution of the workforce
+- More time to pursue other hobbies/pet projects
### Work Flexibility as Work Stability
@@ -64,15 +61,15 @@ One of our teammates, Akshay, went on a month-long work-cation to remote Uttarak
Some of our tactics to make remote working fun and sustainable:
-* Encouraging our people to take vacations
-* Enabling flexible hours
-* Unlimited leaves
-* No attendance or time tracking
-* Access to a professional health & nutrition consultant at any time
+- Encouraging our people to take vacations
+- Enabling flexible hours
+- Unlimited leaves
+- No attendance or time tracking
+- Access to a professional health & nutrition consultant at any time
This is an area where there is so much, we can do – we are learning and trying to get better at it every day!
-> ___“I’ve always been a working mom. Worked through my pregnancy and barely took maternity leave. This is the first time in my child’s life that I’ve been around him so much and our happiness quotient (both his and mine) is so much higher. It is possible to run a company and be there for a kid!”___ -Rushali Parikh
+> **_“I’ve always been a working mom. Worked through my pregnancy and barely took maternity leave. This is the first time in my child’s life that I’ve been around him so much and our happiness quotient (both his and mine) is so much higher. It is possible to run a company and be there for a kid!”_** -Rushali Parikh
### Team Building and Team Bonding
@@ -80,23 +77,22 @@ As a remote-first company, bridging the gap between co-workers has been our bigg
In addition to following the usual Agile practices, other efforts in this direction include:
-* 4-6 hours of pairing daily
-* Mob code reviews
-* A flat hierarchy
-* Imbibing a strong feedback culture at every level
-* Regular retrospectives
-* Lightning talks
-* Inter and Intra team brainstorming sessions and huddles
-* Not having long email chains
-* Practices to indulge in healthy work-life routine
+- 4-6 hours of pairing daily
+- Mob code reviews
+- A flat hierarchy
+- Imbibing a strong feedback culture at every level
+- Regular retrospectives
+- Lightning talks
+- Inter and Intra team brainstorming sessions and huddles
+- Not having long email chains
+- Practices to indulge in healthy work-life routine
### Celebrating one year
We’re happy about how we’ve grown this year and set a high bar for the year to come. We feel our growth this year was at a sustainable pace and that has helped us set the foundation right.
-> ___“When you are on a growth trajectory you are often only reacting, and when you react, you end up making mistakes. When you are acting, you can strategize and plan time without cutting corners.”__ _
+> **\_“When you are on a growth trajectory you are often only reacting, and when you react, you end up making mistakes. When you are acting, you can strategize and plan time without cutting corners.”** \_
We have grown as a team of enthusiastic people sharing core principles and values, working towards the shared goal of delivering high-quality software.
We're always learning about new ways to facilitate opportunities, promote clean coding techniques, create scalable decoupled systems, and provide constant incremental value to our clients. We head into year two with much anticipation, excitement, and a continued commitment - to our people, that we will always strive to be a better employer and a commitment to our clients that we will always look out for their best interests.
-
diff --git a/content/blog/origins-of-graphql.md b/content/blog/origins-of-graphql.md
index ee80e7209..baf4a39c9 100644
--- a/content/blog/origins-of-graphql.md
+++ b/content/blog/origins-of-graphql.md
@@ -37,7 +37,7 @@ A GraphQL schema is an acyclic-directed graph containing types(node), representi
Invention arises from idleness, possibly also from laziness to save oneself from trouble - Agatha Christie
-But, every invention is attributed to the need of the context of its times.
+But, every invention is attributed to the need of the context of its times.
Had people been both idle and lazy, GraphQL would have been developed long time before facebook had faced the challenge of transferring large amount of data between client and server, with its mobile application.
@@ -46,10 +46,10 @@ Had people been both idle and lazy, GraphQL would have been developed long time
**SOAP**(Simple Objects Access Protocol) — It was developed in late 1990s as an alternative for RPC. Supports only XML for sending and receiving requests and responses with large file sizes of XML the bandwidth required is large. Built in security can add to its complexity can make it slow.
**REST**(Representational State Transfer) — It was first introduced in 2000 by Roy Fielding. The REST architectural style was designed to be a more flexible and scalable alternative of SOAP. REST provides server-side data available in the simple format of JSON with standard HTTP methods(GET, POST, PUT, DELETE). Although it is widely used for its decoupled, stateless, cache-friendly architecture it has few strain points.
- 1. Over fetching — It takes a lot less time to fetch the 3 fields we need than to fetch the object with all the 20 keys.
- 2. Under fetching — Hit more endpoints and make many requests rather than fetching everything in a single request.
- 3. May add new route — Dev time may increase in doing so instead of adding a type or field as in GraphQL
+1. Over fetching — It takes a lot less time to fetch the 3 fields we need than to fetch the object with all the 20 keys.
+2. Under fetching — Hit more endpoints and make many requests rather than fetching everything in a single request.
+3. May add new route — Dev time may increase in doing so instead of adding a type or field as in GraphQL
**GraphQL**: GraphQL is a query language for your APIs. It’s also a runtime for fulfilling queries with your data. The GraphQL service is transport agnostic but is typically served over HTTP. With GraphQL, our clients can get all the data they need in one request.
diff --git a/content/blog/our-remote-manifesto.md b/content/blog/our-remote-manifesto.md
index d024a13b9..de5bd89ea 100644
--- a/content/blog/our-remote-manifesto.md
+++ b/content/blog/our-remote-manifesto.md
@@ -8,14 +8,13 @@ title = "Our Remote Manifesto!"
+++
-
Born in the Covid-19 era, we were a sappling in a hailstorm, but we came out on the other side - Stronger, Tougher and Smarter. Having been remote since day-1 we can honestly say that though majority people believe that there two sides to the remote coin, we are behind remote working 100%
The biggest pro to being totally remote helps us hire talent irrespective of their geographical location by letting us access the perfect people who have the right tech skills as well as the cultural core values that we hold oh so dear.
The other major advantage apart from cost saving on office space, is that it offers so much more flexibility in employees daily lives and gives them power over their own time and schedules, we believe this is empowering for our employees. A number of studies from the likes of [Google](https://www.forbes.com/sites/abdullahimuhammed/2019/05/18/5-important-takeaways-from-googles-two-year-study-of-remote-work/#1a536957439a), [Buffer](https://buffer.com/state-of-remote-work-2019), [FlexJobs](https://www.techrepublic.com/article/why-remote-work-has-grown-by-159-since-2005/), and [IWG](http://assets.regus.com/pdfs/iwg-workplace-survey/iwg-workplace-survey-2019.pdf) show that driven individuals who place a high degree of value on autonomy and flexibility can experience new levels of joy and productivity in an all-remote environment.
-It’s important for employees to truly take advantage of the freedoms and possibilities enabled by remote, rather than simply remaining where they are and switching an office desk for a room in their home. This is the core benefit of ****remote****as compared to ****work-from-home****.
+It’s important for employees to truly take advantage of the freedoms and possibilities enabled by remote, rather than simply remaining where they are and switching an office desk for a room in their home. This is the core benefit of \***\*remote\*\***as compared to \***\*work-from-home\*\***.
In the home, aim to create a dedicated working space (or work from a coworking space, external office, or cafe). It’s vital to intentionally separate work and life to prevent [burnout](https://about.gitlab.com/company/culture/all-remote/mental-health/). Moreover, don’t stop engaging with people. You may not fill your social quota entirely from work interactions, which enables you to pay closer attention to family, neighbors, and community opportunities.
@@ -37,6 +36,3 @@ Be intentional about replacing your recovered commute time. Whether it’s fitne
14. Eating at home is better (sometimes) and cheaper.
15. Taxes can be cheaper in some countries.
16. Work clothes [are not required](https://about.gitlab.com/blog/2019/07/09/tips-for-working-from-home-remote-work/).
-
-
-
diff --git a/content/blog/pair-programming.md b/content/blog/pair-programming.md
index 24d6da155..e4d6a06c0 100644
--- a/content/blog/pair-programming.md
+++ b/content/blog/pair-programming.md
@@ -11,7 +11,6 @@ categories = ["Software Craftsmanship", "Best Practices", "SDLC"]
type = ""
+++
-
Have you ever come across a bug that had complex logic, and was incredibly hard to fix? You are trying to chase this bug for more than several hours, but all you have is frustration and a bit of self-doubt. Now imagine you find another developer to work with you, possibly the original authors! You request her to pair with you and, swoosh, the bug gets fixed!
Two brains are (obviously) better than one and getting ideas from one another increases your chances of producing more effective solutions. You would believe this while working on complex or highly escalated issues then why not when creating and innovating new software?
@@ -140,7 +139,7 @@ Similar to Ping-Pong approach this also prevents disengagement while also allowi
### Strong Style Pairing
-"_For an idea to go from your head into the computer it \*must\* go through someone else's hands - [_Llewellyn Falco_](http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html)_"
+"_For an idea to go from your head into the computer it \*must\* go through someone else's hands - [\_Llewellyn Falco_](http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html)_"
This quote very briefly sums up Strong Style pairing. In this approach the navigator will explain her/his ideas for the solution, in higher levels of abstraction. The driver will interpret these and implement it. If the driver has her/his own ideas, roles are switched and the process continues.
diff --git a/content/blog/planning.md b/content/blog/planning.md
index c1c7b7a3f..8b4ad3028 100644
--- a/content/blog/planning.md
+++ b/content/blog/planning.md
@@ -11,7 +11,6 @@ title = "Planning & Communication"
+++
-
One of our primary process goals is to make frequent, small releases of our working software. We do this through regular communication and bi-weekly iterations on a product.
Communication helps our team achieve this goal by spreading knowledge, and creating a sense of a team, collaboration, and co-operation without the frequent releases would not be possible. Many times, solutions to problems emerge from within our team when we huddle to brainstorm together.
@@ -30,4 +29,3 @@ Few visible benefits we pass on to our client by communicating well inside and o
2. Effective communication with all stakeholders helps us get quicker feedback, thus providing the opportunity to fine-tune our team's direction and the project as per the evolving requirements.
3. Familiarity in the team within the team and our clients ensures that all the stakeholders are always on the same page, and there is little left open to assumptions.
4. Our teams harness the individual's complementary skills, and effective communication ensures that there is knowledge transfer, and the whole group grows in multiple directions simultaneously.
-
diff --git a/content/blog/product-roadmap-with-azure-devops.md b/content/blog/product-roadmap-with-azure-devops.md
index bca19714b..1feac3720 100644
--- a/content/blog/product-roadmap-with-azure-devops.md
+++ b/content/blog/product-roadmap-with-azure-devops.md
@@ -18,9 +18,9 @@ Creating a product roadmap is an integral part of the product development proces
A product roadmap is a generic document that changes as the product evolves, or the market changes. As it is a written or visual summary of the objectives for a product, it typically includes
-- A product plan
-- Dependencies
-- A list of features and epics
+- A product plan
+- Dependencies
+- A list of features and epics
The complexity of the product roadmap varies depending on the target audience. Incorporating regular and continuous feedback from end users is a must when refining a product roadmap. Hence it is a living, breathing document constantly evolving based on user feedback and the changing business scenario.
@@ -30,10 +30,10 @@ As mentioned, a product roadmap is a tool that requires regular review from all
The objectives of a product roadmap include the following —
-- Bringing stakeholders and team members to an agreement on the direction and priorities of a product
-- Communicating and tracking progress toward achieving them
-- Helping the product team stay focused on the right goals
-- Ensuring stakeholders are aware of the rationale behind decisions
+- Bringing stakeholders and team members to an agreement on the direction and priorities of a product
+- Communicating and tracking progress toward achieving them
+- Helping the product team stay focused on the right goals
+- Ensuring stakeholders are aware of the rationale behind decisions
## A Product Roadmap is an Outcome of Agile Ceremonies
@@ -41,8 +41,8 @@ The product roadmap is constantly evolving based on Agile ceremonies. These coul
Iterations include
-- Moving stories based on the changes in priorities
-- Adding new stories to the backlog
+- Moving stories based on the changes in priorities
+- Adding new stories to the backlog
For instance, a team adding new stories to the product roadmap further extends its timeline.
@@ -52,9 +52,9 @@ Acquisition and retention are also some stages of a product that lead to the evo
A product roadmap undergoes changes based on the—
-- Constant feedback from the end users
-- Stage of product development
-- Organization-level decisions
+- Constant feedback from the end users
+- Stage of product development
+- Organization-level decisions
Regardless of the stage of development, a product roadmap should be flexible enough to adapt to changes in the market or product itself.
@@ -66,24 +66,24 @@ Many tools are available in the market to help configure a product roadmap. Some
We have been using Azure DevOps for almost three years, and this is how we define product roadmaps with Azure DevOps (ADO).
-- ADO offers features such as Epic Roadmap and Feature Timeline.
- You can access the roadmap feature by navigating the backlogs or boards.
+- ADO offers features such as Epic Roadmap and Feature Timeline.
+ You can access the roadmap feature by navigating the backlogs or boards.
-- In ADO, stakeholders can create roadmap using queries, tags, and proper definitions of features and associating stories.
+- In ADO, stakeholders can create roadmap using queries, tags, and proper definitions of features and associating stories.
## Step-by-Step Guide on How to Define Product Roadmap using Azure DevOps
-- Create high-level Epics with Features under it.
+- Create high-level Epics with Features under it.
- Features can be labelled with tags. Tags are best suited for work allocation, and they differentiate different high-level features from each other.
+ Features can be labelled with tags. Tags are best suited for work allocation, and they differentiate different high-level features from each other.
-- Each Feature will have corresponding User Stories as child links.
+- Each Feature will have corresponding User Stories as child links.
- These stories are achievable goals in the short term. Stories prioritized for release will be set with a 'Production Release Date' field.
+ These stories are achievable goals in the short term. Stories prioritized for release will be set with a 'Production Release Date' field.
-- Another way to track work items is using the sprint view.
+- Another way to track work items is using the sprint view.
- Filtering on the sprint view is an efficient way to look at tasks.
+ Filtering on the sprint view is an efficient way to look at tasks.
1. Create a new query where the work item type is 'Feature,' and the tag is the common tag you want to filter with.
This query is our initial filter to get all the related features of the team.
@@ -102,9 +102,9 @@ We have been using Azure DevOps for almost three years, and this is how we defin
The same query can be—
-- Used at the features and epics level while talking to business stakeholders about goals and vision.
-- Used at the features and stories level while talking to the internal development team.
-- Shared with end users at the features level to discuss the releases and milestones.
+- Used at the features and epics level while talking to business stakeholders about goals and vision.
+- Used at the features and stories level while talking to the internal development team.
+- Shared with end users at the features level to discuss the releases and milestones.
## Azure DevOps is a Beneficial Tool for Building Product Roadmap
diff --git a/content/blog/project-kickstart-checklist.md b/content/blog/project-kickstart-checklist.md
index 9a42a9277..d6e802052 100644
--- a/content/blog/project-kickstart-checklist.md
+++ b/content/blog/project-kickstart-checklist.md
@@ -11,9 +11,10 @@ title = "Project Kickstart Checklist"
+++
-The [Checklist Manifesto](http://atulgawande.com/book/the-checklist-manifesto/) by Atul Gawande, walks us through the benefits of the humble checklist. He talks about how checklists of "dumb stuff" can save us from disasters in life and death situations. We developers, too, can use such a checklist when we start a new project.
+The [Checklist Manifesto](http://atulgawande.com/book/the-checklist-manifesto/) by Atul Gawande, walks us through the benefits of the humble checklist. He talks about how checklists of "dumb stuff" can save us from disasters in life and death situations. We developers, too, can use such a checklist when we start a new project.
### 1. Is your code in the source control?
+
Source control has become a litmus test of a good development workflow. SCM is the first item in Joel Spolsky's "[The Joel Test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/)." Though typical mistake developers make is they use source control only for code. Make sure that you use SCM systems for all of the following.
1. Code
@@ -25,9 +26,11 @@ Source control has become a litmus test of a good development workflow. SCM is t
7. Any infrastructure-related scripts. Ex dockerfile, docker compose, terraform etc
### 2. Do you have an automated database versioning tool?
+
Tools like Flyway and, Liquibase stores your database migrations in a text file. Once the database changes are captured in a text file, they can become part of the SCM and be versioned!
### 3. Did you start with a unit test?
+
Practices like TDD or TCR(Test Commit Revert) are a few of the best practices for development workflow, but if you don't do it, at least make sure that high-quality test cases are part of your codebase. And they should execute often and preferably before you merge the code in your mainline.
### 4. Have you chosen a build tool? Is your build automated? Think Gradle, Maven, PyBuilder, or others.
@@ -38,7 +41,6 @@ Having your build configuration and dependencies as text files in the codebase h
### 5. Did you choose a logging framework?
-
While it's is very tempting to defer choosing the logging framework and keep using console logging, it's not a good idea.
Make this decision early on. You will be writing cleaner code by avoiding console printing like `print()` and `System.out.println()`.
This decision will become helpful when you want to integrate a monitoring system like Sentry, Datadog, ELK, etc.
@@ -48,12 +50,15 @@ This decision will become helpful when you want to integrate a monitoring system
Many code linters exist today, ranging from open-source PMD to Sonar or Snyke. These linters can catch code-style issues as well security vulnerabilities early in the SDLC. Make it part of your IDE as well as CI/CD pipelines.
### 7. Do you have quality gates as part of the CI/CD pipeline?
+
Configure your CI/CD pipelines in such a way so that your code repositories reject any code change which has issues. These issues can range from unit test failure to static code analysis issues in the build.
### 8. Do you have a fully automated release and deployment process without manual steps?
+
Does your code automatically deploy upon successful merge in the pipeline? Does it require manual release approval? Whatever it may be, it has to be part of the fully automated pipeline. You are doing something severely wrong if you need to SSH somewhere or FTP files manually.
### 9. Did you deploy a walking skeleton?
+
Once you have the smallest working piece of your software along with a framework that can do all of the above, deploy it. This will require you to set up a build tool, database, migration tool, CI/CD pipeline, code scan, and test execution.
And finally, validate all of it by pushing small code changes that gets tested and deployed automatically and succesfully.
diff --git a/content/blog/psychological-safety.md b/content/blog/psychological-safety.md
index 2d9cea913..3bb68ad43 100644
--- a/content/blog/psychological-safety.md
+++ b/content/blog/psychological-safety.md
@@ -46,7 +46,7 @@ Once you can see others making mistakes, you feel safer making mistakes too!
Pairing, a practice in extreme programming and a type of co-creation allows team members to collaborate in coding activities, simultaneously seeing and accepting each other's mistakes. It has a high impact on psychological safety.
-> When you co-create more, you start to feel psychologically safer.
+> When you co-create more, you start to feel psychologically safer.
{{< figure src="/images/2023/psych-safety-1.jpg" >}}
@@ -57,12 +57,12 @@ The diagram above shows this cycle:
- **The more you accept mistakes,** own and of others, the more everyone feels psychologically safe
- **The more everyone feels safe,** the more they co-create. The loop continues.
-
## Reduce Batch Size to Increase Safety!
Kent Beck famously said, **“Make it work, make it right, make it fast.”** (In that order!).
A piece of code evolves as follows:
+
1. It first solves a specific problem.
1. It is then refactored to be maintainable.
1. If necessary, it is changed to perform better.
@@ -79,7 +79,6 @@ By draft PRs, teams are encouraged to see how code evolves from mediocre to “p
{{< figure src="/images/2023/psych-safety-2.jpg" >}}
-
The diagram above shows this cycle:
- **The bigger the size of the failure,** the less safe someone feels
@@ -97,12 +96,11 @@ Combining both system diagrams gives you a better understanding of the levers or
- Higher psychological safety leads to a willingness to receive mentorship and improve technical competency.
## Conclusion
+
Overlooking psychological safety leads to many consequences in different areas of a company. Unsafe employees feel unfulfilled and contribute to work poorly, affecting an organization's quality of work and customer happiness.
As a first step, team leaders can lead by example. Acknowledging mistakes and actively seeking and implementing feedback is how you instill confidence in others to do the same.
This slowly moves the needle towards creating a productive and harmonious work environment where nobody feels penalized for making mistakes or restricted from sharing what's on their mind.
-
-*Thanks to [Dragan Stepanovic](https://www.linkedin.com/in/dstepanovic/) for the inspiration for this blog.*
-
+_Thanks to [Dragan Stepanovic](https://www.linkedin.com/in/dstepanovic/) for the inspiration for this blog._
diff --git a/content/blog/rails-restapi-outside-in-tdd.md b/content/blog/rails-restapi-outside-in-tdd.md
index 72c87c765..506498a7f 100644
--- a/content/blog/rails-restapi-outside-in-tdd.md
+++ b/content/blog/rails-restapi-outside-in-tdd.md
@@ -25,7 +25,7 @@ Over breakfast, while chewing on a piece of bread I remember thinking to myself
I quickly set up the Rails API only project.
-*Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.*
+_Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern._
```bash
To start a new rails api only project
@@ -150,6 +150,7 @@ I did not want to revisit the realization of it being "too late".
Never underestimate the impact just a few minutes of planning can make.
Did some research and found out the basic checks my code was supposed to pass for optimum results.
+
- [x] Fulfill Requirements without errors.
- [x] The code should be maintainable and scalable.
- [x] The code should adhere to the Single Responsibility Principle(SRP).
@@ -250,7 +251,9 @@ class Repository
end
end
```
+
### Simplicity is key
+
Where should I start first? Model specs, Controller specs, Runner specs, or Repository Specs? This question has to be responded to every time a new resource or functionality is addressed.
In 1952, William Edmund Hick and Ray Hyman a pair of psychologists experimented to examine the relationship between the number of stimuli present and an individual’s reaction time to any given stimulus. The result was obvious, the more options the user had to choose from, the longer it took them to decide on which one to interact with.
@@ -279,10 +282,10 @@ $ rspec
running the above specification resulted in the error
RED:
- 1) Todos with valid request attributes will create a Todo and return 201
+ 1) Todos with valid request attributes will create a Todo and return 201
Failure/Error: post '/todos', params: {title: "Todo-1", description:'First todo' }, as: :json
- ActionController::RoutingError:
+ ActionController::RoutingError:
I need not ponder what to do next as the spec failure suggested what needed fixing.
@@ -301,7 +304,7 @@ Running the test after fixing it resulted in another error that reads
ActionController::RoutingError:
uninitialized constant TodosController
- ```
+```
The fix would be to add a new controller but according to Test driven development, we need to have the test file before the Controller itself.
I created a new folder in the spec directory and named it `controllers` and added a spec file and named it `todos_controller_spec.rb`
@@ -338,6 +341,7 @@ GREEN:
end
end
```
+
Run the tests
```ruby
@@ -385,6 +389,7 @@ GREEN:
@runner.create_todo
end
```
+
```ruby
$ rspec
@@ -406,11 +411,12 @@ GREEN:
end
```
+
```ruby
$ rspec
RED:
- 1) Todos with valid request attributes will create a Todo and return 201
+ 1) Todos with valid request attributes will create a Todo and return 201
Failure/Error: @runner.create_todo(todo_params)
NoMethodError:
@@ -476,6 +482,7 @@ GREEN:
Created new file todos_runner.rb in runners folder of app directory.
```
+
```ruby
$ rspec
RED:
@@ -490,6 +497,7 @@ GREEN:
end
```
+
```ruby
$ rspec
@@ -508,6 +516,7 @@ GREEN:
end
```
+
```ruby
$ rspec
@@ -604,6 +613,7 @@ GREEN:
@repo.save_todo(todo)
end
```
+
```ruby
Failing Test Case:
it " calls save_todo to save initialized todo and returns created" do
diff --git a/content/blog/remote-onboarding-and-immersion.md b/content/blog/remote-onboarding-and-immersion.md
index 75f038dbc..cddbc4842 100644
--- a/content/blog/remote-onboarding-and-immersion.md
+++ b/content/blog/remote-onboarding-and-immersion.md
@@ -11,14 +11,13 @@ title = "Remote Onboarding & Immersion at Incubyte"
+++
-
Employee onboarding is the important process of introducing newly hired employees to the organisation. It is everything that leads up to the employee's total immersion into the organisation's culture. An effective onboarding process helps the new employee relate better with the company values and helps them get up and running quicker. Immersion is the process of creating a common future and common purpose for all employees by aligning expectation, values, purpose, mission and goals.
Rather than an onboarding checklist, we believe that a successful onboarding process covers three broad areas:
-* Operational
-* Technical
-* Cultural
+- Operational
+- Technical
+- Cultural
These together, help provide a holistic understanding of the company and the employees' role within the company.
@@ -44,13 +43,13 @@ They talk to their Buddy about what a typical day looks like, including getting
### Day Three to Five
-In the first week, we encourage the new employee to do regular one-on-one meetings with each person in their team to get to know them, their role in the team and just in general, say hello. They also dive deep into learning the ropes of the product they're working on. The long-term goal of this exercise is to make sure communication remains open and hierarchies flat despite being part of remote teams.
+In the first week, we encourage the new employee to do regular one-on-one meetings with each person in their team to get to know them, their role in the team and just in general, say hello. They also dive deep into learning the ropes of the product they're working on. The long-term goal of this exercise is to make sure communication remains open and hierarchies flat despite being part of remote teams.
### Week Two and Three
This is when the new employee starts dipping their feet into actual work and starts seeing their name on the agile board. Domain knowledge sharing continues at each and every stage as they start pairing and participating in day-to-day activities and projects.
-At the end of the second week, the People Success Team checks in on how they're doing and that onboarding has been effective. This also helps us continuously improve and evolve our onboarding and hiring process!
+At the end of the second week, the People Success Team checks in on how they're doing and that onboarding has been effective. This also helps us continuously improve and evolve our onboarding and hiring process!
### Week Four
@@ -63,4 +62,3 @@ Towards the end of week four, we do one-on-ones with the founders and the People
We hope that through this process of remote onboarding, we are able to set clear expectations and immerse new hires in the Incubyte culture. We aim to provide them with the tools, context, information, connections and other key details they need to get started.
Employees are our most valuable asset, and we're committed to doing everything we can to ensure a seamless start to our exciting journey together!
-
diff --git a/content/blog/ruby-on-rails-dup-vs-deep-dup.md b/content/blog/ruby-on-rails-dup-vs-deep-dup.md
index aff023426..6bc0a23d5 100644
--- a/content/blog/ruby-on-rails-dup-vs-deep-dup.md
+++ b/content/blog/ruby-on-rails-dup-vs-deep-dup.md
@@ -78,4 +78,3 @@ Understanding the distinction between `dup` and `deep_dup` is vital for avoiding
While `dup` creates a shallow copy, retaining references to nested attributes, `deep_dup` ensures a complete duplication, safeguarding against unintended side effects.
Choosing the appropriate method based on the depth of your data structure is key to maintaining the integrity of your objects.
-
diff --git a/content/blog/salesforce-vs-in-house-custom-development.md b/content/blog/salesforce-vs-in-house-custom-development.md
index 3f2d168cb..53e09830e 100644
--- a/content/blog/salesforce-vs-in-house-custom-development.md
+++ b/content/blog/salesforce-vs-in-house-custom-development.md
@@ -10,7 +10,6 @@ tags = ["Case Study"]
title = "Is there a more economical and efficient alternative to Salesforce?"
+++
-
Choosing a direction when redefining your organization's technical backbone is never easy. In this case study, we had the unique opportunity to observe the implementation of both - a Low-code/no-code CRM and tailored software solutions over two years. The outcome? When done right, tailored software solutions can bring more value to an organization, faster!
## The client
@@ -52,11 +51,11 @@ Redefining tech solutions for the banking industry has unique challenges. It is
## Progress in two years: Salesforce vs Custom Software Solution
-| Salesforce | Metamorphosis |
-| --- | --- |
-| Needed a lot of upfront planning before onboarding any users | Genie increased the number of users by slowly and steadily improving the system iteratively and consistently. |
+| Salesforce | Metamorphosis |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Needed a lot of upfront planning before onboarding any users | Genie increased the number of users by slowly and steadily improving the system iteratively and consistently. |
| Agencies specializing in niche areas had to be engaged since the low-code implementation still required professional services in MuleSoft, Cloud Data Migration, etc. | The cross-functional team at Incubyte owned the entire stack from discovery to deployment, reducing communication overhead and dependencies across teams |
-| ~100 users onboarded | 900+ users onboarded. |
+| ~100 users onboarded | 900+ users onboarded. |
## How we did it
@@ -71,7 +70,7 @@ _Metamorphosis was always release-ready._
## Scoreboard
| Salesforce Scoreboard | Metamorphosis Scoreboard |
-|------------------------------------------|----------------------------------------------------|
+| ---------------------------------------- | -------------------------------------------------- |
| Total Users Onboarded - 100 | Total Users Onboarded - 900+ |
| Operational CTC for 100 users = 270,000$ | Operational CTC per year for 900+ users = 100,000$ |
| Typical Lead Time to Release = Undefined | Typical Lead Time to Release = 3 Weeks |
@@ -85,8 +84,7 @@ Genie started saving 1000 hours a day across 225+ daily active users.
- **Saved 1200 hours a day.** Team members onboarded by the Metamorphosis project have a seamless workflow that resulted in time saving
- **Over 900 users onboarded** by maintaining smaller, stable, consistent releases
- **It's a tailored solution**, it is more than customization, because Incubyte developed a solution with the end user and the customer's use cases in mind
-- **By being fast, economical, and agile**, Metamorphis started adding value from the very beginning
-
+- **By being fast, economical, and agile**, Metamorphis started adding value from the very beginning
## Where Salesforce works
@@ -101,6 +99,7 @@ When it comes to adopting solutions like Salesforce, a company would need to pay
Consider your requirements and choose wisely. Will your end users absolutely benefit from the CRM or could they do more with a custom tool?
## The power of Metamorphosis, a.k.a. Custom Tailored Development
+
- **Built per the needs of business, client and employees** in mind from day one
- **Cost shifts from opex to capex** once built there is no additional expenditure to onboard new users
- **Can be faster cheaper and better** if done right
@@ -109,4 +108,3 @@ Consider your requirements and choose wisely. Will your end users absolutely ben
Choosing a direction to tackle a system overhaul is never easy. There are no simple decisions, and every action has long-lasting consequences. We hope this study helped you understand your options better and what they ultimately translate to for your business. Contact us if you want to know how tailored digital products can uplift your business and enable your employees.
**Reach out to us at hello@incubyte.co if you are considering tailored digital products vs Salesforce to uplift your business. We would love to help you with your Metamorphosis.**
-
diff --git a/content/blog/softwarecraftsperson.md b/content/blog/softwarecraftsperson.md
index 9f9879cd4..5f76a5a32 100644
--- a/content/blog/softwarecraftsperson.md
+++ b/content/blog/softwarecraftsperson.md
@@ -10,21 +10,19 @@ title = "Why we call our developers - 'Software Craftspeople'"
+++
-
We’re looking to hire software craftspeople, who believe in and are evangelists of extreme programming principles and who have a real thirst for learning and up-skilling themselves. High quality, motivated and passionate people who make great teams. We heavily believe in being a DevOps organization, where developers own the entire release cycle and thus get to work not only on programming languages, but also on infrastructure technologies in the cloud.
Coding
-* Test Driven Development is second nature during the coding lifecycle.
-* Good design principles, such as SOLID, while we develop software, however as our experience grows, we look wider and go to first principles such as simplicity, coupling and cohesion to a point where we have an intuitive understanding.
-* We love to pair program and see it as an opportunity to learn from each other.
-* We take an active interest in subjects like Domain Driven Design, Architectural Patterns, Security and other more holistic characteristics of the software product.
+- Test Driven Development is second nature during the coding lifecycle.
+- Good design principles, such as SOLID, while we develop software, however as our experience grows, we look wider and go to first principles such as simplicity, coupling and cohesion to a point where we have an intuitive understanding.
+- We love to pair program and see it as an opportunity to learn from each other.
+- We take an active interest in subjects like Domain Driven Design, Architectural Patterns, Security and other more holistic characteristics of the software product.
Automation & Operations
-* We aspire to become skilled in crafting effective continuous delivery pipelines and systems that are easy to operate in production.
-* We aspire to a DevOps culture. Most of us are skilled, to a good level, on the coding side and consider infrastructure as code as an important skillset.
-* We enjoy working with cloud offerings such as Amazon Web Service, Microsoft Azure, and Google Cloud Platform.
-* We find technologies such as Docker, Kubernetes, Terraform, Puppet, etc to be extremely valuable to achieving effective delivery pipelines and reliable platforms.
-* Whilst we refrain from over engineering, we also aspire to use modern technologies to increase the efficiency, productivity and reliability of our software development process and eventually our software product
-
+- We aspire to become skilled in crafting effective continuous delivery pipelines and systems that are easy to operate in production.
+- We aspire to a DevOps culture. Most of us are skilled, to a good level, on the coding side and consider infrastructure as code as an important skillset.
+- We enjoy working with cloud offerings such as Amazon Web Service, Microsoft Azure, and Google Cloud Platform.
+- We find technologies such as Docker, Kubernetes, Terraform, Puppet, etc to be extremely valuable to achieving effective delivery pipelines and reliable platforms.
+- Whilst we refrain from over engineering, we also aspire to use modern technologies to increase the efficiency, productivity and reliability of our software development process and eventually our software product
diff --git a/content/blog/standup.md b/content/blog/standup.md
new file mode 100644
index 000000000..b3fbb3fe2
--- /dev/null
+++ b/content/blog/standup.md
@@ -0,0 +1,214 @@
++++
+title = "Standup Meeting Playbook"
+slug = "standup"
+date = 2023-12-28T17:48:58+05:30
+image = "/images/2023/12/meeting.jpg"
+draft = false
+authors = ["Akshay Vadher"]
+description = "Playbook to conduct effective standup meeting"
+tags = ["Playbook", "Software Craftsmanship", "Meeting", "Daily Scrum"]
+categories = ["Playbook", "Software Craftsmanship"]
+type = ""
++++
+
+The "Standup meeting" or "Daily Scrum" that everyone does religiously just for the sake of calling themselves "Agile."
+
+The name does not matter; you can call it anything. I like to call it a “Huddle.”
+
+### Intent
+
+If we look at the [Agile Manifesto](https://agilemanifesto.org/), it does not describe how to manage your project.
+However, two methodologies come to our mind:
+
+1. [Scrum](), which is the most popular; The "Daily Scrum" comes from that.
+2. [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) is considered to be the best implementation of Agile.
+
+Although terms like "Standup meeting," "Daily Sync meeting," "Daily Scrum," and others may have distinct definitions, we should
+focus on the meeting from the Agile perspective instead of religiously following each one’s process and definition.
+
+Over the years, as “conventional” project managers converted to the Agile way, Agile lost its core value, and so did standup
+meetings. Agile transformed into just another project management process, and developers found themselves increasingly detached from its original essence.
+
+### Values
+
+If we look at Agile values, it focuses on “Interactions,” “Collaboration,” “Delivery,” and “Change.” Remember these
+while creating your own rules for standup meetings.
+
+### FAQs
+
+##### Q: What is the ideal frequency?
+
+Usually, every day. However, if all the stakeholders interact frequently and do not need to know the status, you can meet less.
+
+##### Q: Where?
+
+Anywhere the whole team is comfortable. Physical or remote, does not matter.
+
+If you are conducting it remotely, always have videos on.
+You want to talk to humans, not animated figures!
+
+##### Q: When?
+
+Ideally at the start of the day. However, if everyone is not available or working remotely in different geographies, you
+can do it anytime.
+
+##### Q: What content?
+
+- What did I do towards the iteration goal?
+- What will I do next?
+- What is inhibiting me from achieving my goals?
+
+##### Q: How granular?
+
+Remember, it is for the team. Your updates should be at the right level, so everyone can understand and contribute to the project goal.
+
+##### Q: Duration?
+
+Ideally, a maximum of 15 minutes. Every team member should speak for only 2 or 3 minutes. If there are too many participants, and the meeting cannot be concluded in a 15-minute timeframe, it is a different problem. Ideally in such cases, divide the
+team instead of shortening individuals' time or increasing the duration of the standup meetings.
+
+##### Q: Should I be standing up?
+
+Since the goal is to keep the meeting short, adopting a psychological approach, standing up tends to lead to brevity. If your standup meetings consistently exceed the allotted time, you should definitely transition to standing meetings.
+
+##### Q: Should we hire a scrum master?
+
+If you are married to the process of Scrum, then sure. But, if your focus is on Agile values, you don't need to.
+
+I disagree with the concept of having a Scrum master. The word master is terrible anyway.
+It also brings all the micromanagement, like tracking the burndown chart like a hawk.
+I have seen very bad standups where a "scrum master" will go through all the issues on the board and ask everyone for a status.
+
+People who are going to talk should take charge of their own work,
+from updating tickets to delivering and updating others in the team about it.
+
+We should rename that to Agile mentor/coach, even if we want someone to teach Agile principles.
+
+##### Q: Should we hire an Agile coach/mentor?
+
+If you observe that the team is not doing what they need to do or doing what they shouldn't be doing, then
+an Agile coach can help streamline that. Also, in this case, don't make the Agile coach your process.
+
+##### Q: What should be the Agile coach's role?
+
+They teach the team to follow the practice and create other Agile coaches.
+Remember, Agile coaching is not a permanent process.
+It is just an initial push.
+These are just the people who know how to conduct the meeting effectively.
+
+##### Q: What is a facilitator?
+
+After the Agile coach/mentor moves on, one of the team members steps up as the facilitator, playing a role akin to an internal Agile coach/mentor. They kick things off and ensure a smooth exchange of the baton. Avoid sticking with a single facilitator; keep the rotation going among team members.
+
+This goes without saying, but you don't need a facilitator if you think your team is mature enough to handle things.
+
+##### Q: What order?
+
+Choose whatever suits you.
+
+Some like the alphabetical order, some like the current position they are sitting in, some like facilitator assigning,
+some like the last person nominating the next person.
+
+You can be creative as far as meetings are short and effective.
+
+##### Q: Do I need a burn down chart? Or any chart or board?
+
+That is a great way to visualize the status. However, status is not the goal; action item is the goal.
+Anything that helps the project.
+It helps identify whether you need to organize yourself and the team better.
+
+Another way is to have just sticky notes or cards in a dashboard.
+Identify how many cards should have been moved and their current status.
+
+Any tool that publishes data is good enough.
+
+Many teams don't even use any! (These are very mature teams. I would recommend having some visual representation.)
+
+### What not to do
+
+##### Too granular
+
+"I worked on the order class and implemented that method", "I worked on liquibase scripts", nobody cares and should care about that.
+Make it abstract enough as if the recipients are non-developers.
+The meeting is for the project, not yourself. Don't go too technical.
+
+Focus on the task or story's completeness or challenge.
+
+This is one of the reasons the meeting becomes boring.
+Because nobody understands what the other person really means, so they stop paying attention to the other person.
+
+##### Cutting each other
+
+Only one person speaks!
+
+This is one reason why the meeting continues after the designated time and lasts for even an hour!
+
+##### Everyone addressing one person
+
+The meeting is not a project status report meeting! It is a sync up call.
+Everyone should address the team, not the team lead or project manager.
+
+Non-developers or attendees who are not directly working with the team should be quiet or give their updates to
+everyone like any other person but never be a receiver.
+
+##### Slip in other things
+
+"Let me show the demo of what I did", "Hey, if you are facing this issue, then do this to solve it", "Why don't you do
+this?", "Why don't we do this?".
+None of this should happen. Everyone should focus on only strictly updates. Nothing else.
+
+Did I say nothing else?
+
+If you want another conversation, meet after the meeting and have a separate meeting with a smaller group.
+Even if the next meeting will have the same participants, don't do it now—organize a separate session for that purpose.
+
+Now you might have a question-
+
+##### But we work only remotely, and this is the only time the whole team is together; I would want it to last a little longer and combine other things.
+
+Even in that case, keep the standup time shorter. Do other things after officially concluding standup. You can wear a different hat after that.
+
+Remember, the standup should be completed on time in a short duration.
+The meeting or call can be extended with the same or different participants.
+
+##### Too many updates
+
+"I worked on setting up that server then talked to Bob then talked to Yoda about order detail then talked to Groot about
+invoice preparation" — How does this help the project? Why should anyone care?
+
+Number of updates or time you take to update others is not a measure of success or hard work.
+
+##### Absence of context
+
+"I worked on ABC-549 and ABC-588 and will keep working on that". Although this looks good enough, not everyone may have the context for what "ABC-549" represents. Consider saying, "I've been working on the order detail screen." This provides clearer information for everyone involved.
+
+##### Not using burndown chart or team board because it is not updated
+
+If you have another way to get the project status, then it is okay to not have a board.
+However, having incorrect status for tasks/stories is not a good reason not to have a board.
+
+Always keep your tasks/stories updated with the latest status as soon as you make progress.
+Don't wait for standup to update those.
+
+It is always better to have some visual representation than not having any.
+
+##### Sticking to one process
+
+Don't make your standups boring. Standup is a practice; its effectiveness must be questioned, and ways of improving must be part of retro discussions.
+
+### Honorary addition
+
+Lately, some teams have started introducing non-project related and team-related talks in the meeting.
+Those are not bad. Those help team building. Some examples are as follows,
+
+- How was your weekend?
+- What did you learn recently?
+- What books are you reading?
+- How are you feeling?
+- Do you want to thank anyone?
+- Anything you are excited about this week?
+
+These additions are great at creating a more connected and collaborative work environment.
+
+Photo by Igor Omilaev
+on Unsplash
diff --git a/content/blog/structurizr-dsl-step-by-step.md b/content/blog/structurizr-dsl-step-by-step.md
index 1595c6a56..dfc7b555a 100644
--- a/content/blog/structurizr-dsl-step-by-step.md
+++ b/content/blog/structurizr-dsl-step-by-step.md
@@ -9,7 +9,6 @@ title = "Structurizr DSL Step by Step"
+++
-
In this tutorial, we will go through a step by step instruction of building architecture diagram of a very simpleeCommerce system.As we build the diagrams, we will also familiarize ourselves with four "Cs" of C4 diagrams.Let us start with creating a free account of Structurizr. Once you have done that, Structurizr will create one free workspace for you. To get started quickly, you can navigate to the URL that looks like the following._https://structurizr.com/workspace/6***7/dsl_
The hidden number is your workspace ID. The screen will look something like the following.
@@ -208,4 +207,3 @@ workspace "Getting Started" "This is a model of my software system." {
```
The 4th `C` of the system is `Code` and we are not going to jump into it in this tutorial. Now you are ready to go to your dashboard and navigate to your diagram's presentation mode. This will start displaying the diagram in full screen, and note that you can interact with the diagram components. Try double-clicking on the blue box of the eCommerce software system, and the diagram should navigate to a new page to display the containers.This tutorial should now get you started to develop your own diagrams with the help of the [DSL references documentation](_docs/language-reference.md_).
-
diff --git a/content/blog/tdd-assessment.md b/content/blog/tdd-assessment.md
index b9cb34b7b..755310b6d 100644
--- a/content/blog/tdd-assessment.md
+++ b/content/blog/tdd-assessment.md
@@ -39,35 +39,35 @@ With that, let's jump right in! Follow the instructions below, take your time to
1. Create a simple String calculator with a method signature:
- ```java
- int Add(string numbers)
- ```
+ ```java
+ int Add(string numbers)
+ ```
- The method can take up to two numbers, separated by commas, and will return their sum.
+ The method can take up to two numbers, separated by commas, and will return their sum.
- For example `""` or `"1"` or `"1,2"` as inputs. (for an empty string it will return 0)
+ For example `""` or `"1"` or `"1,2"` as inputs. (for an empty string it will return 0)
- Hints:
+ Hints:
- - Start with the simplest test case of an empty string and move to one and two numbers
- - Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
- - Remember to refactor after each passing test
+ - Start with the simplest test case of an empty string and move to one and two numbers
+ - Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
+ - Remember to refactor after each passing test
2. Allow the Add method to handle an unknown amount of numbers
3. Allow the Add method to handle new lines between numbers (instead of commas).
- - The following input is ok: `"1\n2,3"` (will equal 6)
- - The following input is NOT ok: `"1,\n"` (not need to prove it - just clarifying)
+ - The following input is ok: `"1\n2,3"` (will equal 6)
+ - The following input is NOT ok: `"1,\n"` (not need to prove it - just clarifying)
4. Support different delimiters
- - To change a delimiter, the beginning of the string will contain a separate line that looks like this: `"//[delimiter]\n[numbers…]"` for example `"//;\n1;2"` should return three where the default delimiter is `";"`
- - The first line is optional. all existing scenarios should still be supported
+ - To change a delimiter, the beginning of the string will contain a separate line that looks like this: `"//[delimiter]\n[numbers…]"` for example `"//;\n1;2"` should return three where the default delimiter is `";"`
+ - The first line is optional. all existing scenarios should still be supported
5. Calling Add with a negative number will throw an exception `"negatives not allowed"` - and the negative that was passed.
- If there are multiple negatives, show all of them in the exception message.
+ If there are multiple negatives, show all of them in the exception message.
> Want more? Check out [TDD Kata 1](https://osherove.com/tdd-kata-1/) for the full version. **Extra points** for completing all the steps!
diff --git a/content/blog/team-oriented-business-culture-and-why-it-is-importa.md b/content/blog/team-oriented-business-culture-and-why-it-is-importa.md
index 0751e0cd3..99eb0f358 100644
--- a/content/blog/team-oriented-business-culture-and-why-it-is-importa.md
+++ b/content/blog/team-oriented-business-culture-and-why-it-is-importa.md
@@ -8,10 +8,9 @@ title = "Team-oriented business culture, and why it is important"
+++
+Every manager likes to think of their team as being a big, happy unit. After all, everyone gets along well and is collaborative **most** of the time. But the thing is, there’s more to having a team-oriented culture than Friday drinks and good banter on the office [chat app](https://www.typetalk.com/): It’s more complex than you might think. \***\*It’s an interplay between leadership, teamwork, and communication\*\***, and how successful your team is depends on how well each of these play out.
-Every manager likes to think of their team as being a big, happy unit. After all, everyone gets along well and is collaborative __most__ of the time. But the thing is, there’s more to having a team-oriented culture than Friday drinks and good banter on the office [chat app](https://www.typetalk.com/): It’s more complex than you might think. ****It’s an interplay between leadership, teamwork, and communication****, and how successful your team is depends on how well each of these play out.
-
-It’s also about recognizing the strengths and qualities of a team player and nurturing them while encouraging collaboration and communication between everyone as a whole. __Let’s take a closer look at how to create a team-oriented business culture.__
+It’s also about recognizing the strengths and qualities of a team player and nurturing them while encouraging collaboration and communication between everyone as a whole. **Let’s take a closer look at how to create a team-oriented business culture.**
## **What is a ‘team-oriented culture’**
@@ -21,7 +20,7 @@ Being team-oriented is about working well with others. And ‘workplace culture
Being team-oriented as an individual is a [soft skill](https://www.thebalancecareers.com/list-of-soft-skills-2063770). It’s about working well with people, and, as a manager, this translates into focusing on motivation and wellbeing as opposed to completing tasks and deadlines.
-If you’re a team-oriented manager, you still care about tasks, but you put your energy into helping people achieve those goals from a more human perspective. To give you an idea of the differences between the two, a team-oriented manager might ask an employee __how__ they’re feeling and whether they feel confident with their workload, whereas a task-oriented manager will ask when they can expect the work to be delivered.
+If you’re a team-oriented manager, you still care about tasks, but you put your energy into helping people achieve those goals from a more human perspective. To give you an idea of the differences between the two, a team-oriented manager might ask an employee **how** they’re feeling and whether they feel confident with their workload, whereas a task-oriented manager will ask when they can expect the work to be delivered.
Team-oriented leadership shares some similarities with a [bottom-up style of management](https://backlog.com/blog/top-down-approach-or-bottom-up-smart-project-managers-choose-both/): leaders and team members are considered more equal. This contrasts with a [top-down style of management](https://backlog.com/blog/top-down-approach-or-bottom-up-smart-project-managers-choose-both/), which is more about hierarchies.
@@ -62,4 +61,3 @@ If you’re used to top-down working, trusting others to take the reins can be t
Teamwork and communication go hand-in-hand. [Online collaboration tools](https://nulab.com/products/)like chat apps and project management software can help managers stay in control and up-to-date, while automation handles repetitive tasks leaving leaders with more time to focus on employee motivation and wellbeing. These are also perfect for when face-to-face communication isn’t an option — something that’s becoming increasingly common as more businesses embrace the benefits of remote work.
Invest in tools that help employees communicate and collaborate from wherever they are, in a way they enjoy, and a team-oriented way of working will soon follow.
-
diff --git a/content/blog/technical-assessment-evaluation-criteria.md b/content/blog/technical-assessment-evaluation-criteria.md
index 19b3ff831..3755d7550 100644
--- a/content/blog/technical-assessment-evaluation-criteria.md
+++ b/content/blog/technical-assessment-evaluation-criteria.md
@@ -27,6 +27,7 @@ A typical interview process at Incubyte involves 5 stages:
Once your application is shortlisted, you will receive an email with a list of resources and short videos. This email is meant to help prepare you for the interview process and set you up for success. The suggested learning in the email is self-paced and there is no time limit for you to complete it - we're perpetually hiring!
Some of our favourites:
+
- [Test-Driven Development](https://www.youtube.com/watch?v=qkblc5WRn-U)
- [Software Craftsmanship](https://www.youtube.com/watch?v=c07uQGBZl0A)
- [Clean Code](https://www.youtube.com/watch?v=zV079g7Irks&feature=emb_imp_woyt)
@@ -45,11 +46,10 @@ A 30-minute discussion focused on your technical background and journey so far.
This round is where the fun begins! Fire up your IDE with the language of your choice, have a working Hello World project pre-opened, and be ready to get your hands dirty. We will solve a short Kata together as a team! Consider this round as a pairing exercise, in which an Incubyte Craftsperson will partner with you and act as a navigator. It is fine to look stuff up on the internet, we Google things while working on production projects ALL the time - it's the thought process that matters!
-*It is important that you have a good Wi-Fi connection since we'd want to have your video on during both these technical rounds.*
+_It is important that you have a good Wi-Fi connection since we'd want to have your video on during both these technical rounds._
This brings us to the end of our interview process. Expect to walk away with an offer once you have cleared all these rounds. We've even put together some additional information to help you crack it! You're welcome. ;)
-
## Cheat Sheet (a.k.a. how to crack interviews at Incubyte)
We have broken this down into two parts:
@@ -81,5 +81,4 @@ Our interview process helps us not only identify the interviewees’ technical s
We look for people with hunger for knowledge and a passion for mastering their craft. If you think you have the perfect blend of skills and expertise (or know someone who does) for this, drop us a note at [careers@incubyte.co](mailto:careers@incubyte.co)
-
> Go to [current openings](https://incubyte.co/careers).
diff --git a/content/blog/techniques-for-an-agile-team.md b/content/blog/techniques-for-an-agile-team.md
index 1d7e46c97..2fec50fe2 100644
--- a/content/blog/techniques-for-an-agile-team.md
+++ b/content/blog/techniques-for-an-agile-team.md
@@ -27,12 +27,12 @@ A feature owner steps up when there is new functionality to implement. The featu
The feature owner works closely with the product owner to:
-- Get a clear understanding of the feature from the stakeholders
-- Craft stories for the feature
-- Keep track of timelines and ensure timely delivery
-- Escalate blockers that impede timely delivery
-- Own the feedback-iteration loop through sprint review
-- Be the go-to person for the feature domain knowledge
+- Get a clear understanding of the feature from the stakeholders
+- Craft stories for the feature
+- Keep track of timelines and ensure timely delivery
+- Escalate blockers that impede timely delivery
+- Own the feedback-iteration loop through sprint review
+- Be the go-to person for the feature domain knowledge
## 2) Story Analysts:
@@ -42,10 +42,10 @@ It is always better to perform story mapping before it gets picked up in the nex
Below are the points we can consider for story analysis
-- Are the acceptance criteria specified such that there is no ambiguity?
-- Is there any technical debt related to the story?
-- Is there a need to split the story into thinner slices?
-- Does the story need a spike?
+- Are the acceptance criteria specified such that there is no ambiguity?
+- Is there any technical debt related to the story?
+- Is there a need to split the story into thinner slices?
+- Does the story need a spike?
The outcome of story analysis is that the story is ready to be picked up in the next IPM.
@@ -87,9 +87,9 @@ The responsibility of a team member here is two-fold - to transfer gained knowle
To avoid knowledge hoarding, the following things can be done:
-- Pair Rotation: If a story is taking a few days to complete, one of the developers from the pair can roll out, say after 2 days, and the new developer can join in. The developer already working on the story will ensure that the new folk joining gets all insights into work done so far, and what needs to be done next.
+- Pair Rotation: If a story is taking a few days to complete, one of the developers from the pair can roll out, say after 2 days, and the new developer can join in. The developer already working on the story will ensure that the new folk joining gets all insights into work done so far, and what needs to be done next.
-- Sessions: Conduct sessions within the team showcasing the architectural implementation/discussion, new feature integration, and its design decision, sharing domain knowledge of the feature, what are the requirements from the product owner, etc.
+- Sessions: Conduct sessions within the team showcasing the architectural implementation/discussion, new feature integration, and its design decision, sharing domain knowledge of the feature, what are the requirements from the product owner, etc.
## 6) GO-TO Person:
diff --git a/content/blog/technology-platforms-2.md b/content/blog/technology-platforms-2.md
index a142d47af..617784c8f 100644
--- a/content/blog/technology-platforms-2.md
+++ b/content/blog/technology-platforms-2.md
@@ -11,18 +11,16 @@ title = "Technology Platforms & Business Economics"
+++
-
Early in a project, we have to decide which platforms we'll use. Which platforms depend on our ideas for solving the users' problems. After considering what's best for users, the best tools for us have a strong community, make us happy, and help us create and iterate quickly. Our developers are highly versatile with their choice of tools and integrate the tools' ideologies into their development process.Some of the tools we use and platforms we work with (and highly recommend) are/Some of the ideologies that our choice of tech platforms abide by are:
-* Having an **Integrated Development Environment (IDE)** that supplements the developers' ability to achieve maximum efficiency. This can be achieved in many ways. Some people are vim pros and emacs hackers, some are into a full-blow IDE experience like IntelliJ, while some just prefer a no-nonsense VS Code/Atom setup.
-* A **Build tool** and Scripting for automating a lot of the grunt work that developers would have to do daily – hence leading to the effective utilization of time and resources. At Incubyte we start our projects with walking skeleton pattern, where we focus on fully automated CI/CD from the very early stage of the SDLC.
-* A **Code Linter** ensures that the utmost quality of code is being used in the product. It also helps our team identify security issues early on in the process.
-* In today's **Cloud Services** era, many pre-packaged or off-the-shelf utilities are available for our teams to use in the DevOps process. Using cloud providers, we ensure that our teams are engaged in solving the clients business problems and have a focus on the delivery of the actual application rather than focusing on maintaining servers i.e. not solving an already solved problem.
-* Continuous Integration and Continuous Deployment help us achieve our primary process goal of making frequent, small releases by enforcing automation in building, testing, and deploying applications. **CI/CD** also helps bridge the gaps between development and operation activities and teams by enforcing automation. Modern-day DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring of software applications throughout its development life cycle. The CI/CD practice or CI/CD pipeline forms the backbone of our modern-day DevOps operations.
+- Having an **Integrated Development Environment (IDE)** that supplements the developers' ability to achieve maximum efficiency. This can be achieved in many ways. Some people are vim pros and emacs hackers, some are into a full-blow IDE experience like IntelliJ, while some just prefer a no-nonsense VS Code/Atom setup.
+- A **Build tool** and Scripting for automating a lot of the grunt work that developers would have to do daily – hence leading to the effective utilization of time and resources. At Incubyte we start our projects with walking skeleton pattern, where we focus on fully automated CI/CD from the very early stage of the SDLC.
+- A **Code Linter** ensures that the utmost quality of code is being used in the product. It also helps our team identify security issues early on in the process.
+- In today's **Cloud Services** era, many pre-packaged or off-the-shelf utilities are available for our teams to use in the DevOps process. Using cloud providers, we ensure that our teams are engaged in solving the clients business problems and have a focus on the delivery of the actual application rather than focusing on maintaining servers i.e. not solving an already solved problem.
+- Continuous Integration and Continuous Deployment help us achieve our primary process goal of making frequent, small releases by enforcing automation in building, testing, and deploying applications. **CI/CD** also helps bridge the gaps between development and operation activities and teams by enforcing automation. Modern-day DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring of software applications throughout its development life cycle. The CI/CD practice or CI/CD pipeline forms the backbone of our modern-day DevOps operations.
## Business Economics
Having talked about the platforms we use, we acknowledge that software developed with the best architecture is a failed product if it does not recognize the economic risks and the clients' market positioning. We understand this principle and are aligned with our clients' specific needs. Our teams strive to deliver continuous value, meet the business goal, and keep our clients' best interests at heart while providing the best quality technologies suited to their specific needs.
Our teams understand that a dollar earned today is better than a dollar earned tomorrow. Paired with Incremental Design and DevOps practices, our teams try to help clients make money sooner than later!
-
diff --git a/content/blog/testing-with-java-1-intro.md b/content/blog/testing-with-java-1-intro.md
index 3728995c9..8c6d372eb 100644
--- a/content/blog/testing-with-java-1-intro.md
+++ b/content/blog/testing-with-java-1-intro.md
@@ -123,4 +123,4 @@ In TDD, we write a test first, run it, see that it fails, then write the correct
**Read the next part of the series on [TDD](https://blog.incubyte.co/blog/testing-with-java-tdd/)**
-
\ No newline at end of file
+
diff --git a/content/blog/testing-with-java-2-tdd.md b/content/blog/testing-with-java-2-tdd.md
index e2c0bb947..8a5250a8d 100644
--- a/content/blog/testing-with-java-2-tdd.md
+++ b/content/blog/testing-with-java-2-tdd.md
@@ -10,146 +10,142 @@ tags = ["Software Craftsmanship", "Testing With Java", "TDD"]
title = "Testing With Java - Part 2 : TDD"
+++
-In the annals of software development, there exists a cautionary tale from the year 1996, when the European Space Agency (ESA) launched its ambitious Ariane 5 rocket. Alas, what was meant to be a triumph turned into tragedy a mere 40 seconds after liftoff, as the rocket met a fiery demise, along with its precious cargo. The cause of this catastrophe? A software glitch, specifically an integer overflow issue, lurking within the rocket's flight control system.
+In the annals of software development, there exists a cautionary tale from the year 1996, when the European Space Agency (ESA) launched its ambitious Ariane 5 rocket. Alas, what was meant to be a triumph turned into tragedy a mere 40 seconds after liftoff, as the rocket met a fiery demise, along with its precious cargo. The cause of this catastrophe? A software glitch, specifically an integer overflow issue, lurking within the rocket's flight control system.
The flight control software, repurposed from its predecessor, Ariane 4, failed to account for the vastly different flight trajectory and accelerated speed of Ariane 5. As a consequence, the program generated unforeseen numbers that exceeded the limits of a variable, causing the rocket to veer off course and meet its untimely end.
+This catastrophic event highlighted the importance of thorough testing, particularly in software engineering. To prevent such incidents and ensure code reliability, Test-Driven Development (TDD) emerged as a powerful methodology. By diligently writing tests before implementing production code, developers can detect issues early, improve code quality, and avoid costly failures.
-This catastrophic event highlighted the importance of thorough testing, particularly in software engineering. To prevent such incidents and ensure code reliability, Test-Driven Development (TDD) emerged as a powerful methodology. By diligently writing tests before implementing production code, developers can detect issues early, improve code quality, and avoid costly failures.
-
-Had the developers embraced Test-Driven Development (TDD) and diligently written tests encompassing various scenarios and edge cases, this calamity might have been averted. Through TDD, they could have uncovered the integer overflow bug before it wreaked havoc on the rocket's journey.
+Had the developers embraced Test-Driven Development (TDD) and diligently written tests encompassing various scenarios and edge cases, this calamity might have been averted. Through TDD, they could have uncovered the integer overflow bug before it wreaked havoc on the rocket's journey.
This article delves into TDD, its step-by-step process, and the significant benefits it offers to the software development landscape.
-## Understanding Test-Driven Development (TDD):
+## Understanding Test-Driven Development (TDD):
-Test-Driven Development (TDD) is a development practice that advocates writing tests before diving into production code. It follows a structured cycle known as Red-Green-Refactor. This iterative process entails creating tests that are designed to fail (Red), implementing the minimum code required to pass those tests (Green), and subsequently refining the code's design and maintainability (Refactor).
+Test-Driven Development (TDD) is a development practice that advocates writing tests before diving into production code. It follows a structured cycle known as Red-Green-Refactor. This iterative process entails creating tests that are designed to fail (Red), implementing the minimum code required to pass those tests (Green), and subsequently refining the code's design and maintainability (Refactor).
-
-## Why Use TDD?
+## Why Use TDD?
**TDD provides several compelling advantages that enhance the software development process:**
-1. Early Error Detection: By writing tests upfront, TDD helps identify errors in the early stages of development. It encourages developers to carefully consider requirements and design, leading to the discovery of potential issues and oversights.
-
-2. Bug Reduction: TDD's comprehensive test suite, which covers various scenarios and edge cases, aids in the detection of bugs that may not be immediately apparent during initial implementation. This proactive approach fosters a higher quality codebase.
+1. Early Error Detection: By writing tests upfront, TDD helps identify errors in the early stages of development. It encourages developers to carefully consider requirements and design, leading to the discovery of potential issues and oversights.
-3. Reliable and Maintainable Code: With TDD, testing and validation assume a pivotal role from the beginning. This approach instills confidence in the code, facilitating easier maintenance and future enhancements over time.
-
+2. Bug Reduction: TDD's comprehensive test suite, which covers various scenarios and edge cases, aids in the detection of bugs that may not be immediately apparent during initial implementation. This proactive approach fosters a higher quality codebase.
-## The TDD Process: Step by Step
+3. Reliable and Maintainable Code: With TDD, testing and validation assume a pivotal role from the beginning. This approach instills confidence in the code, facilitating easier maintenance and future enhancements over time.
+## The TDD Process: Step by Step
**Let's walk through the TDD process by examining the code examples below:**
-### 1. Writing the First Test:
-```java
-import org.junit.Test;
-import static org.junit.Assert.*;
-public class LeapYearTest {
- @Test
- void test_is_leap_year_divisible_by_4() {
- assertTrue(LeapYear.isLeapYear(2020));
- }
-}
+### 1. Writing the First Test:
+
+```java
+import org.junit.Test;
+import static org.junit.Assert.*;
+public class LeapYearTest {
+ @Test
+ void test_is_leap_year_divisible_by_4() {
+ assertTrue(LeapYear.isLeapYear(2020));
+ }
+}
```
-
-### 2. Running the Test:
+### 2. Running the Test:
-After writing the test, it's crucial to execute it. Since the corresponding production code is yet to be implemented, we anticipate the test to fail initially.
+After writing the test, it's crucial to execute it. Since the corresponding production code is yet to be implemented, we anticipate the test to fail initially.
-### 3. Implementing the Production Code:
+### 3. Implementing the Production Code:
-Now, it's time to write the minimum code necessary to make the test pass.
+Now, it's time to write the minimum code necessary to make the test pass.
-```java
-public class LeapYear {
- public static boolean isLeapYear(int year) {
- if (year % 4 == 0) {
- return true;
- }
- return false;
- }
-}
+```java
+public class LeapYear {
+ public static boolean isLeapYear(int year) {
+ if (year % 4 == 0) {
+ return true;
+ }
+ return false;
+ }
+}
```
-
-### 4. Rerunning the Test:
+### 4. Rerunning the Test:
-After implementing the production code, let’s rerun the test and ensure that it passes successfully.
+After implementing the production code, let’s rerun the test and ensure that it passes successfully.
-### 5. Expanding Test Coverage:
+### 5. Expanding Test Coverage:
-To augment test coverage, we add more tests to encompass additional cases and edge conditions. Upon running all tests, we expect the newly added tests to fail initially as the updated logic to handle these cases hasn’t been implemented yet.
+To augment test coverage, we add more tests to encompass additional cases and edge conditions. Upon running all tests, we expect the newly added tests to fail initially as the updated logic to handle these cases hasn’t been implemented yet.
**Test is leap year divisible by 100 but not by 400:**
-```java
-@Test
-public void test_is_leap_year_divisible_by_100_but_not_by_400() {
-assertFalse(LeapYear.isLeapYear(1900));
-}
+
+```java
+@Test
+public void test_is_leap_year_divisible_by_100_but_not_by_400() {
+assertFalse(LeapYear.isLeapYear(1900));
+}
```
**Test is leap year divisible by 4 but not by 100:**
-```java
-@Test
-public void test_is_leap_year_divisible_by_4_but_not_by_100() {
-assertTrue(LeapYear.isLeapYear(2008));
-}
+
+```java
+@Test
+public void test_is_leap_year_divisible_by_4_but_not_by_100() {
+assertTrue(LeapYear.isLeapYear(2008));
+}
```
**Test is not a leap year:**
-```java
-@Test
-public void test_is_leap_year_not_divisible_by_4() {
-assertFalse(LeapYear.isLeapYear(2017));
-}
+
+```java
+@Test
+public void test_is_leap_year_not_divisible_by_4() {
+assertFalse(LeapYear.isLeapYear(2017));
+}
```
-### 6. Updating the Production Code:
-
-Let’s Refactor the production code to accommodate the new test cases and ensure that all tests pass.
-
-```java
-public class LeapYear {
- public static boolean isLeapYear(int year) {
- if (year % 400 == 0) {
- return true;
- } else if (year % 100 == 0) {
- return false;
- } else if (year % 4 == 0) {
- return true;
- }
- return false;
- }
-}
+### 6. Updating the Production Code:
+
+Let’s Refactor the production code to accommodate the new test cases and ensure that all tests pass.
+
+```java
+public class LeapYear {
+ public static boolean isLeapYear(int year) {
+ if (year % 400 == 0) {
+ return true;
+ } else if (year % 100 == 0) {
+ return false;
+ } else if (year % 4 == 0) {
+ return true;
+ }
+ return false;
+ }
+}
```
-
-### 7. Rerunning All Tests:
-We re-run all the tests to verify that the code handles all scenarios correctly.
+### 7. Rerunning All Tests:
-## Benefits of Test-Driven Development:
+We re-run all the tests to verify that the code handles all scenarios correctly.
-**By embracing Test-Driven Development (TDD), developers can unlock numerous benefits:**
+## Benefits of Test-Driven Development:
-* Improved Code Quality: TDD promotes the creation of reliable code by catching defects early and preventing regressions.
-* Efficient Debugging: Early issue detection facilitates quicker debugging, reducing troubleshooting time.
-* Guided Design and Modularity: Writing tests upfront influences the design process, leading to more modular and easily testable code.
-* Enhanced Confidence in Code: A comprehensive test suite fosters confidence in the correctness and robustness of the code.
-* Reduced Technical Debt: TDD encourages prompt issue resolution, averting the accumulation of technical debt.
+**By embracing Test-Driven Development (TDD), developers can unlock numerous benefits:**
-## Conclusion:
+- Improved Code Quality: TDD promotes the creation of reliable code by catching defects early and preventing regressions.
+- Efficient Debugging: Early issue detection facilitates quicker debugging, reducing troubleshooting time.
+- Guided Design and Modularity: Writing tests upfront influences the design process, leading to more modular and easily testable code.
+- Enhanced Confidence in Code: A comprehensive test suite fosters confidence in the correctness and robustness of the code.
+- Reduced Technical Debt: TDD encourages prompt issue resolution, averting the accumulation of technical debt.
-The Ariane 5 disaster stands as a poignant reminder of the devastating consequences that can result from inadequate testing practices. Test-Driven Development (TDD) emerges as a potent solution to mitigate such risks and construct robust software with unshakeable confidence. By diligently writing tests before diving into code implementation, developers can detect issues early, ensure code quality, and deliver software that withstands the test of time.
+## Conclusion:
-As software development continues to evolve, embracing TDD can provide developers with a solid foundation for building robust and dependable software systems. By investing time and effort in testing early and consistently, let’s embark on this journey to shape a future of exceptional software craftsmanship with less risks, enhanced code quality and reliable software solutions to meet user expectations, empowered by the magic of Test-Driven Development.
+The Ariane 5 disaster stands as a poignant reminder of the devastating consequences that can result from inadequate testing practices. Test-Driven Development (TDD) emerges as a potent solution to mitigate such risks and construct robust software with unshakeable confidence. By diligently writing tests before diving into code implementation, developers can detect issues early, ensure code quality, and deliver software that withstands the test of time.
- **Read the previous part of the series on [Introduction to Testing](https://blog.incubyte.co/blog/testing-with-java-intro/)**
+As software development continues to evolve, embracing TDD can provide developers with a solid foundation for building robust and dependable software systems. By investing time and effort in testing early and consistently, let’s embark on this journey to shape a future of exceptional software craftsmanship with less risks, enhanced code quality and reliable software solutions to meet user expectations, empowered by the magic of Test-Driven Development.
-
\ No newline at end of file
+**Read the previous part of the series on [Introduction to Testing](https://blog.incubyte.co/blog/testing-with-java-intro/)**
diff --git a/content/blog/the-battle-of-source-control.md b/content/blog/the-battle-of-source-control.md
index 6b19a4e47..73608b22a 100644
--- a/content/blog/the-battle-of-source-control.md
+++ b/content/blog/the-battle-of-source-control.md
@@ -11,7 +11,6 @@ title = "The Battle of Source Control"
+++
-
```shell
git pull origin develop
git checkout -b feature/shiny-new-branch
@@ -19,7 +18,7 @@ git checkout -b feature/shiny-new-branch
It's the start of a sprint, and you have picked up a new User Story.
-```Given there is no spillover When you are working on a new story Then create a branch from develop to work on the latest code```
+`Given there is no spillover When you are working on a new story Then create a branch from develop to work on the latest code`
And with that, begins the great quest of implementing a new feature. On the adventure, you will pick up many new skills like crafting new abstractions, fresh-off-the-grill language/framework features, and knowledge of the business domain. You shall encounter great friendlies in the kingdom of StackOverflow, through the valley of GitHub, and on the mountaintops of Reddit. That sounds awesome, you think to yourself, but no adventure is complete without SKIRMISHES!
@@ -37,4 +36,3 @@ git push origin feature/shiny-new-branch
All's well that end's well. So you think, and prepare to make a PR, only to be greeted by `MERGE CONFLICTS`. FINAL BOSS! Turns out, your quest has not yet finished! As you try to figure out, what to accept and what to decline, you start the question the basic fabric of reality. The big twist is, the final boss doesn't even reward you with XP or Gold. All said and done, you finally fix them all and click on merge. Into develop the code goes, to embark on another adventure in prod. A subject that we shall cover some other time.
Bonus: There is a hidden mechanic in the game which will make you proof of ever facing the final boss. What is it? It can be many things, but in the end, it can be reduced to a problem of parallelism and concurrency. Merge Conflicts are nothing but your everyday concurrency problems. How to fix them? You don't, you want to avoid those because by nature Human beings are highly async without an event loop. So always frame your stories in a manner that they can be parallelized rather than concurrent.
-
diff --git a/content/blog/think-like-architect.md b/content/blog/think-like-architect.md
index 60d15b670..162839cb1 100644
--- a/content/blog/think-like-architect.md
+++ b/content/blog/think-like-architect.md
@@ -23,6 +23,7 @@ In this article, we dive deep into key principles and strategies that will help
The foundation of architectural thinking lies in understanding that everything in software architecture involves trade-offs.
Architectural decisions require careful consideration of competing factors, such as
+
- Performance vs. Readability
- Modularity vs. Reusability
- Flexibility vs. Simplicity
@@ -80,22 +81,22 @@ Here's a breakdown of these two dimensions:
To enhance technical breadth, commit at least 20 minutes each day to expand your knowledge.
Here are some resources that you can use to stay updated and explore new ideas:
-- [InfoQ](https://www.infoq.com/)
-- [Dzone Refcardz](https://dzone.com/refcardz)
-- [Thoughtworks Radar](https://www.thoughtworks.com/radar)
-- [Hacker News](https://news.ycombinator.com/)
+- [InfoQ](https://www.infoq.com/)
+- [Dzone Refcardz](https://dzone.com/refcardz)
+- [Thoughtworks Radar](https://www.thoughtworks.com/radar)
+- [Hacker News](https://news.ycombinator.com/)
## Tips for Thinking Like an Architect
To enhance your architect's mindset, keep the following tips in mind:
-- **Architecture is an iterative process,** just like software development.
-- **Collaborative decision-making and communication are crucial in effective architecture**.
- Involving developers and business stakeholders provides a broader perspective and considers multiple viewpoints.
-- **Be mindful of the context when making decisions**
- Consider the specific project requirements, constraints and objectives to avoid falling into out-of-context traps.
-- **Avoid over-evangelizing a particular solution or technology**.
- Architectural decisions should be driven by a project's unique needs rather than personal preferences or biases.
+- **Architecture is an iterative process,** just like software development.
+- **Collaborative decision-making and communication are crucial in effective architecture**.
+ Involving developers and business stakeholders provides a broader perspective and considers multiple viewpoints.
+- **Be mindful of the context when making decisions**
+ Consider the specific project requirements, constraints and objectives to avoid falling into out-of-context traps.
+- **Avoid over-evangelizing a particular solution or technology**.
+ Architectural decisions should be driven by a project's unique needs rather than personal preferences or biases.
By embracing the principles of architectural thinking, you can cultivate a mindset that enables you to approach software design and decision-making like an architect.
This perspective empowers you to create well-balanced, effective, and successful architectures.
diff --git a/content/blog/to-repl-or-not-to-repl.md b/content/blog/to-repl-or-not-to-repl.md
index 40aff2fd2..44c01e377 100644
--- a/content/blog/to-repl-or-not-to-repl.md
+++ b/content/blog/to-repl-or-not-to-repl.md
@@ -8,7 +8,6 @@ title = "To REPL or Not To REPL?"
+++
-
For those who do not know what is a REPL: an Intro to Read-Eval-Print-Loop REPL.
The move from Python to Java ecosystem. The discovery of `jshell`, comparison with `IPython`.
@@ -18,4 +17,3 @@ The evolved REPL i.e. Jupyter Notebook. The amalgamation of various ecosystems i
How would Java work in a Jupyter Notebook.
The power of Debuggers. Are they equivalent approaches to solve the same problem?
-
diff --git a/content/blog/why-incubyte.md b/content/blog/why-incubyte.md
index e6f0505cf..8d32002ef 100644
--- a/content/blog/why-incubyte.md
+++ b/content/blog/why-incubyte.md
@@ -11,7 +11,6 @@ title = "Why Incubyte?"
type = "featured"
+++
-
Quality is usually an implicit requirement when it comes to developing software. Users ask for a beautiful UI, outstanding performance, and the functionality they need, but quality is never on the list - it is just expected! And because it is so, it is often overlooked. Users end up getting only what was explicitly stated.
Incubyte's goal is to focus equally on the implicit aspects of software development, that include better scalability, maintainability, testability and security.
@@ -29,4 +28,3 @@ Most developers end up developing software for machines. When they start develop
None of the quality we talk about is possible without continuous learning and upskilling. People that acknowledge this, make a conscious effort to grow the depth and breadth of their skillset. This not only reflects in the work done, but also in more effective pairing sessions, educative lightning talks and stimulating conversations.
These are the teams and the people at Incubyte and they help create quality products, happy users and satisfied clients.
-
diff --git a/content/blog/working-at-incubyte.md b/content/blog/working-at-incubyte.md
index 8cc002cab..d1d77219e 100644
--- a/content/blog/working-at-incubyte.md
+++ b/content/blog/working-at-incubyte.md
@@ -11,7 +11,6 @@ title = "Working at Incubyte"
+++
-
At Incubyte we strongly believe in finding the right talent, helping them to unleash their maximum capacity, and then getting out of their way to let them do what they do best.
The people who make us what we are, are a group of super-passionate individuals who are proud of the way they work. These highly driven individuals own the whole DevOps pipeline and are evangelists of extreme programming principles.
@@ -63,4 +62,3 @@ The Company holds each one of its employees to an extremely high standard on per
11. Laptop hardware is provided to all our employees as per their configuration need
12. Welcome Kit with Incubyte merchandise
-
diff --git a/static/images/2023/12/meeting.jpg b/static/images/2023/12/meeting.jpg
new file mode 100644
index 000000000..e48e400ad
Binary files /dev/null and b/static/images/2023/12/meeting.jpg differ
diff --git a/static/images/2023/cypress-guide/header-image.jpg b/static/images/2023/cypress-guide/header-image.jpg
new file mode 100644
index 000000000..175f7af0d
Binary files /dev/null and b/static/images/2023/cypress-guide/header-image.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/architecture.jpg b/static/images/2023/introduction-to-systems-thinking/architecture.jpg
new file mode 100644
index 000000000..fd46e28cf
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/architecture.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg b/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg
new file mode 100644
index 000000000..2ea79cb54
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/banner.jpg b/static/images/2023/introduction-to-systems-thinking/banner.jpg
new file mode 100644
index 000000000..cea8148c7
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/banner.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg b/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg
new file mode 100644
index 000000000..fc69e7a14
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg b/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg
new file mode 100644
index 000000000..f6d6c0a36
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg differ
diff --git a/themes/bigspring b/themes/bigspring
index 248923a6c..bec36f774 160000
--- a/themes/bigspring
+++ b/themes/bigspring
@@ -1 +1 @@
-Subproject commit 248923a6c7e0a6853b560412be81cffc36f0c373
+Subproject commit bec36f77483fbf5dfb04f8df733cee98319335cd
diff --git a/content/authors/arohi-parikh/_index.md b/content/authors/arohi-parikh/_index.md
index ce932a47a..3503f193d 100644
--- a/content/authors/arohi-parikh/_index.md
+++ b/content/authors/arohi-parikh/_index.md
@@ -1,6 +1,6 @@
---
title: Arohi Parikh
image: '/authors/arohi-parikh/arohi.jpg'
-
---
+
Operations [@incubyte_co](https://twitter.com/incubyte_co) | Community Builder [@swcraftindia](https://twitter.com/swcraftindia) | Conscious Human | Words: "Leave the world better than you found it"
diff --git a/content/authors/jaymin-shah/_index.md b/content/authors/jaymin-shah/_index.md
index 97253c9eb..6d8ec8481 100644
--- a/content/authors/jaymin-shah/_index.md
+++ b/content/authors/jaymin-shah/_index.md
@@ -1,7 +1,7 @@
---
title: Jaymin Shah
-image: "/images/favicon.png"
-subtitle: "Software Craftsperson in Training at Incubyte"
+image: '/images/favicon.png'
+subtitle: 'Software Craftsperson in Training at Incubyte'
---
To be added soon.
diff --git a/content/authors/karishma-shah/_index.md b/content/authors/karishma-shah/_index.md
index a67cecb2a..154422285 100644
--- a/content/authors/karishma-shah/_index.md
+++ b/content/authors/karishma-shah/_index.md
@@ -1,7 +1,7 @@
---
title: Karishma Shah
-image: "/images/favicon.png"
-subtitle: "Handles Finance at Incubyte"
+image: '/images/favicon.png'
+subtitle: 'Handles Finance at Incubyte'
---
To be added soon.
diff --git a/content/authors/pranita-aitwadkar/_index.md b/content/authors/pranita-aitwadkar/_index.md
new file mode 100644
index 000000000..26651cfa4
--- /dev/null
+++ b/content/authors/pranita-aitwadkar/_index.md
@@ -0,0 +1,5 @@
+---
+title: Pranita Aitwadkar
+image: '/images/favicon.png'
+subtitle: 'Quality Craftsperson at Incubyte'
+---
diff --git a/content/authors/rushali-parikh/_index.md b/content/authors/rushali-parikh/_index.md
index a340cb598..af9842ce6 100644
--- a/content/authors/rushali-parikh/_index.md
+++ b/content/authors/rushali-parikh/_index.md
@@ -2,4 +2,5 @@
title: Rushali Parikh
image: '/authors/rushali-parikh/rushali.jpg'
---
+
Co-founder of [@incubyte_co](https://twitter.com/incubyte_co) | Co-organizer of Software Craftspeople - India | Product Enthusiast | Dedicated to making clean coding practices accessible
diff --git a/content/authors/sapan-parikh/_index.md b/content/authors/sapan-parikh/_index.md
index b7f900bbb..e1cd16dea 100644
--- a/content/authors/sapan-parikh/_index.md
+++ b/content/authors/sapan-parikh/_index.md
@@ -1,6 +1,7 @@
---
title: Sapan Parikh
-image: "/images/favicon.png"
-subtitle: "Co-founder and Software Craftsperson at Incubyte"
+image: '/images/favicon.png'
+subtitle: 'Co-founder and Software Craftsperson at Incubyte'
---
-A tech evangelist and mentor, Sapan has been fuelled by two things in his 15+ year professional career; coffee and his love of designing self-motivated, high-performing and passionate software engineering teams. Being a software craftsperson at heart, he has created and coached teams of over 500 software developers spread across the US and India with the sole objective of forging exceptional software products with an unfettered focus on quality.
\ No newline at end of file
+
+A tech evangelist and mentor, Sapan has been fuelled by two things in his 15+ year professional career; coffee and his love of designing self-motivated, high-performing and passionate software engineering teams. Being a software craftsperson at heart, he has created and coached teams of over 500 software developers spread across the US and India with the sole objective of forging exceptional software products with an unfettered focus on quality.
diff --git a/content/authors/sutirtha-das/_index.md b/content/authors/sutirtha-das/_index.md
index 05188adfd..ed02dcc7e 100644
--- a/content/authors/sutirtha-das/_index.md
+++ b/content/authors/sutirtha-das/_index.md
@@ -1,5 +1,5 @@
---
title: Sutirtha Das
image: '/authors/sutirtha-das/sutirtha.jpg'
-subtitle: "Software Craftsperson @Incubyte | Reader | Writer | Developer"
+subtitle: 'Software Craftsperson @Incubyte | Reader | Writer | Developer'
---
diff --git a/content/authors/utsav-parmar/_index.md b/content/authors/utsav-parmar/_index.md
index 9243819c1..b3a19d74e 100644
--- a/content/authors/utsav-parmar/_index.md
+++ b/content/authors/utsav-parmar/_index.md
@@ -1,7 +1,7 @@
---
title: Utsav Parmar
-image: "/images/favicon.png"
-subtitle: "Software Craftsperson at Incubyte"
+image: '/images/favicon.png'
+subtitle: 'Software Craftsperson at Incubyte'
---
Developer | Co-organizer at [@swcraftindia](https://twitter.com/swcraftindia) | Trying to change the world one PR at a time
diff --git a/content/blog/_index.md b/content/blog/_index.md
index b3f1b3b76..ce07de2c8 100644
--- a/content/blog/_index.md
+++ b/content/blog/_index.md
@@ -1,5 +1,5 @@
---
# meta description
draft: false
-url: "/"
+url: '/'
---
diff --git a/content/blog/a-developers-daily-checklist.md b/content/blog/a-developers-daily-checklist.md
index d91351040..5260b496c 100644
--- a/content/blog/a-developers-daily-checklist.md
+++ b/content/blog/a-developers-daily-checklist.md
@@ -16,40 +16,47 @@ But what about little things you can do to improve your daily work? All you need
Ask yourself these questions at the end of the day every day.
### 1. Did I create an item in the todo list?
+
You have completed your morning errands, and your hands are itching to start coding, but wait! Are you supposed to reply to some emails? Or complete that blog that you were writing? Or summarize last night's call and make some technical decisions based on it? All of these things are the ones that fall through the cracks. As a developer, it's essential to be organized. There are a zillion things "you will do later." Make them part of your todo list, and then mark them off. Give Todoist a try. There is a rumor going that checking things off of your todo list releases Dopamine :-)
### 2. Did I check my calendar?
+
Thank god you are past your todos, and you are all ready to start coding that shiny new feature. But you are not done yet. You have to check your calendar and see if you have any important events. If you have, then you have to make sure that you are on the right track.
Checking and organizing the calendar along with your TODO list should be the first thing as you start your day. It's crucial in the world of remote working, there will be people waiting for you on calls, or you will miss something vital because you could not join a call. Make a mental note of how your day is going to look based on your calendar.
If your calendar is primarily empty, then go ahead and book your lunchtime on it!
### 3. Did I write a test?
+
For many, writing tests and writing production code has no difference. Production code gets written alongside tests. But if you don't do it already, try it.
It will make your life stress-free in the long run, and seeing your tests pass one by one will give you the pleasure of success every time.
### 4. Did I think before naming my variables, classes, functions?
+
Now you have done it. You have reached the point where you start coding. You are in your flow, adding lines after lines of code. But you can't be sure that you have thought before naming each of the variables, classes, functions.
No matter how small it may sound, this one thing will make you and your teammates extremely happy. See, this is what makes you a better human being :-) you are already thinking about others, people who will read your code.
This principle is just a tiny part of clean coding practices and signifies just one of them, but the point is to learn and apply all of them to your code.
-
### 5. Did I automate something that I did three or more times?
+
One trade-off of being a developer is getting caught in a spiral of monotonous, repetitive tasks. That leads to general unhappiness about your work. You have an opportunity to change that. Ask yourself, "Have I done this already three or more times?" If the answer is yes, then think about ways of automating it. Automation can range from sending emails to encapsulating code you find yourself writing over and over again.
Believe it or not, you can send emails automatically by using Zappier or Microsoft Flow. We do it, and you should too!
### 6. Did I make a note?
+
Wait, what! Notes? Isn't that something managers do? They do, but capturing the details of what you need to do, like thoughts on architecture while coding or even an execution plan, goes a long way. Numerous things come to our mind, either as part of team meetings or simply during showers. If you didn't note that thought down, it would be part of those thousands of things you thought of but never got to.
Often, you may take shortcuts while coding, note them down, revisit the notes, create work items from there, and fix the technical debt you created!
### 7. Did I commit and push something?
+
Now you have created the new shiny feature with the cleanest possible code, the Monalisa! Were you able to commit and push it?
Understandably, you can't push something every day. But as developers, we must strive to create stories so small that we can do commits and push every day. These practices will promote frequent releases, smaller changes, and lower risks. Of course, all of this works well if you have looked into our [project kickoff checklist.](https://blog.incubyte.co/blog/kickstart-checklist/)
### 8. Did I create a diagram?
-Creating diagrams can help you clear your thoughts in terms of software architecture or simply workflows. One more advantage, others can refer to it!
+Creating diagrams can help you clear your thoughts in terms of software architecture or simply workflows. One more advantage, others can refer to it!
### 9. Did I read a book?
+
Finally, your day is over, and you are ready to go to bed. How about squeezing 10 minutes of reading?
You are consuming content all the time, blogs, videos, tweets, though books are different. It allows you to choose what you want to learn deliberately. Also, the book got printed and made in your hand, which may mean the author has some authenticity on the subject and can deliver some value instead of some random tweet pushed to you.
Sure, you can not read a book every day, but we mean spending 10 to 15 minutes every day doing so. Once again, 1% investment in yourself every day.
diff --git a/content/blog/acclerate-metrics.md b/content/blog/acclerate-metrics.md
index 4b699f4f8..79a1308e6 100644
--- a/content/blog/acclerate-metrics.md
+++ b/content/blog/acclerate-metrics.md
@@ -9,7 +9,6 @@ tags = ["Modernization", "Book Review"]
title = "Accelerate: Metrics that Define High-Performance Software Delivery"
+++
-
Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim was released in 2018, and it changed how I think about software delivery.
Who really is responsible for the software delivery business or engineering? The book summarizes years of research of the State of DevOps Reports and presents four key metrics to measure software delivery performance. Each measure balances the other in such a way that an organization can perform well only if business and engineering work hand in hand, and it's hard for someone to cheat the system!
diff --git a/content/blog/angular-provider.md b/content/blog/angular-provider.md
index 1e7bf2b63..5aef3da57 100644
--- a/content/blog/angular-provider.md
+++ b/content/blog/angular-provider.md
@@ -1,4 +1,3 @@
-
+++
title = "Angular Provider"
slug = "angular-provider"
@@ -15,7 +14,7 @@ type = ""
Angular Provider is like a command to Angular Dependency Injection system regarding how to get an object/instance for a particular dependency.
-This helps us to register dependencies, like classes or functions or even values with the Angular Dependency Injection system.
+This helps us to register dependencies, like classes or functions or even values with the Angular Dependency Injection system.
**Now you must be wondering what on earth is the Angular Dependency Injection system**
@@ -28,84 +27,102 @@ Let's first see what is a Dependency.
[Dependency injection](https://en.wikipedia.org/wiki/Dependency_injection), or DI, is a design pattern in which a class requests dependencies from external sources rather than creating them.
### Example
+
We have a `CarFactory` in which `Car` object is created.
-````typescript
+
+```typescript
class CarFactory {
- car: Car = new Car();
+ car: Car = new Car();
}
-````
-And here is our `Car`
-````typescript
+```
+
+And here is our `Car`
+
+```typescript
export class Car {
engine: Engine;
-
+
constructor() {
this.engine = new Engine();
}
}
-````
-````typescript
+```
+
+```typescript
export class Engine {}
-````
+```
In the above example, in order to create a `Car`, we first need to create an `Engine`.
+
+
The flight control software, repurposed from its predecessor, Ariane 4, failed to account for the vastly different flight trajectory and accelerated speed of Ariane 5. As a consequence, the program generated unforeseen numbers that exceeded the limits of a variable, causing the rocket to veer off course and meet its untimely end.
+This catastrophic event highlighted the importance of thorough testing, particularly in software engineering. To prevent such incidents and ensure code reliability, Test-Driven Development (TDD) emerged as a powerful methodology. By diligently writing tests before implementing production code, developers can detect issues early, improve code quality, and avoid costly failures.
-This catastrophic event highlighted the importance of thorough testing, particularly in software engineering. To prevent such incidents and ensure code reliability, Test-Driven Development (TDD) emerged as a powerful methodology. By diligently writing tests before implementing production code, developers can detect issues early, improve code quality, and avoid costly failures.
-
-Had the developers embraced Test-Driven Development (TDD) and diligently written tests encompassing various scenarios and edge cases, this calamity might have been averted. Through TDD, they could have uncovered the integer overflow bug before it wreaked havoc on the rocket's journey.
+Had the developers embraced Test-Driven Development (TDD) and diligently written tests encompassing various scenarios and edge cases, this calamity might have been averted. Through TDD, they could have uncovered the integer overflow bug before it wreaked havoc on the rocket's journey.
This article delves into TDD, its step-by-step process, and the significant benefits it offers to the software development landscape.
-## Understanding Test-Driven Development (TDD):
+## Understanding Test-Driven Development (TDD):
-Test-Driven Development (TDD) is a development practice that advocates writing tests before diving into production code. It follows a structured cycle known as Red-Green-Refactor. This iterative process entails creating tests that are designed to fail (Red), implementing the minimum code required to pass those tests (Green), and subsequently refining the code's design and maintainability (Refactor).
+Test-Driven Development (TDD) is a development practice that advocates writing tests before diving into production code. It follows a structured cycle known as Red-Green-Refactor. This iterative process entails creating tests that are designed to fail (Red), implementing the minimum code required to pass those tests (Green), and subsequently refining the code's design and maintainability (Refactor).
-
-## Why Use TDD?
+## Why Use TDD?
**TDD provides several compelling advantages that enhance the software development process:**
-1. Early Error Detection: By writing tests upfront, TDD helps identify errors in the early stages of development. It encourages developers to carefully consider requirements and design, leading to the discovery of potential issues and oversights.
-
-2. Bug Reduction: TDD's comprehensive test suite, which covers various scenarios and edge cases, aids in the detection of bugs that may not be immediately apparent during initial implementation. This proactive approach fosters a higher quality codebase.
+1. Early Error Detection: By writing tests upfront, TDD helps identify errors in the early stages of development. It encourages developers to carefully consider requirements and design, leading to the discovery of potential issues and oversights.
-3. Reliable and Maintainable Code: With TDD, testing and validation assume a pivotal role from the beginning. This approach instills confidence in the code, facilitating easier maintenance and future enhancements over time.
-
+2. Bug Reduction: TDD's comprehensive test suite, which covers various scenarios and edge cases, aids in the detection of bugs that may not be immediately apparent during initial implementation. This proactive approach fosters a higher quality codebase.
-## The TDD Process: Step by Step
+3. Reliable and Maintainable Code: With TDD, testing and validation assume a pivotal role from the beginning. This approach instills confidence in the code, facilitating easier maintenance and future enhancements over time.
+## The TDD Process: Step by Step
**Let's walk through the TDD process by examining the code examples below:**
-### 1. Writing the First Test:
-```java
-import org.junit.Test;
-import static org.junit.Assert.*;
-public class LeapYearTest {
- @Test
- void test_is_leap_year_divisible_by_4() {
- assertTrue(LeapYear.isLeapYear(2020));
- }
-}
+### 1. Writing the First Test:
+
+```java
+import org.junit.Test;
+import static org.junit.Assert.*;
+public class LeapYearTest {
+ @Test
+ void test_is_leap_year_divisible_by_4() {
+ assertTrue(LeapYear.isLeapYear(2020));
+ }
+}
```
-
-### 2. Running the Test:
+### 2. Running the Test:
-After writing the test, it's crucial to execute it. Since the corresponding production code is yet to be implemented, we anticipate the test to fail initially.
+After writing the test, it's crucial to execute it. Since the corresponding production code is yet to be implemented, we anticipate the test to fail initially.
-### 3. Implementing the Production Code:
+### 3. Implementing the Production Code:
-Now, it's time to write the minimum code necessary to make the test pass.
+Now, it's time to write the minimum code necessary to make the test pass.
-```java
-public class LeapYear {
- public static boolean isLeapYear(int year) {
- if (year % 4 == 0) {
- return true;
- }
- return false;
- }
-}
+```java
+public class LeapYear {
+ public static boolean isLeapYear(int year) {
+ if (year % 4 == 0) {
+ return true;
+ }
+ return false;
+ }
+}
```
-
-### 4. Rerunning the Test:
+### 4. Rerunning the Test:
-After implementing the production code, let’s rerun the test and ensure that it passes successfully.
+After implementing the production code, let’s rerun the test and ensure that it passes successfully.
-### 5. Expanding Test Coverage:
+### 5. Expanding Test Coverage:
-To augment test coverage, we add more tests to encompass additional cases and edge conditions. Upon running all tests, we expect the newly added tests to fail initially as the updated logic to handle these cases hasn’t been implemented yet.
+To augment test coverage, we add more tests to encompass additional cases and edge conditions. Upon running all tests, we expect the newly added tests to fail initially as the updated logic to handle these cases hasn’t been implemented yet.
**Test is leap year divisible by 100 but not by 400:**
-```java
-@Test
-public void test_is_leap_year_divisible_by_100_but_not_by_400() {
-assertFalse(LeapYear.isLeapYear(1900));
-}
+
+```java
+@Test
+public void test_is_leap_year_divisible_by_100_but_not_by_400() {
+assertFalse(LeapYear.isLeapYear(1900));
+}
```
**Test is leap year divisible by 4 but not by 100:**
-```java
-@Test
-public void test_is_leap_year_divisible_by_4_but_not_by_100() {
-assertTrue(LeapYear.isLeapYear(2008));
-}
+
+```java
+@Test
+public void test_is_leap_year_divisible_by_4_but_not_by_100() {
+assertTrue(LeapYear.isLeapYear(2008));
+}
```
**Test is not a leap year:**
-```java
-@Test
-public void test_is_leap_year_not_divisible_by_4() {
-assertFalse(LeapYear.isLeapYear(2017));
-}
+
+```java
+@Test
+public void test_is_leap_year_not_divisible_by_4() {
+assertFalse(LeapYear.isLeapYear(2017));
+}
```
-### 6. Updating the Production Code:
-
-Let’s Refactor the production code to accommodate the new test cases and ensure that all tests pass.
-
-```java
-public class LeapYear {
- public static boolean isLeapYear(int year) {
- if (year % 400 == 0) {
- return true;
- } else if (year % 100 == 0) {
- return false;
- } else if (year % 4 == 0) {
- return true;
- }
- return false;
- }
-}
+### 6. Updating the Production Code:
+
+Let’s Refactor the production code to accommodate the new test cases and ensure that all tests pass.
+
+```java
+public class LeapYear {
+ public static boolean isLeapYear(int year) {
+ if (year % 400 == 0) {
+ return true;
+ } else if (year % 100 == 0) {
+ return false;
+ } else if (year % 4 == 0) {
+ return true;
+ }
+ return false;
+ }
+}
```
-
-### 7. Rerunning All Tests:
-We re-run all the tests to verify that the code handles all scenarios correctly.
+### 7. Rerunning All Tests:
-## Benefits of Test-Driven Development:
+We re-run all the tests to verify that the code handles all scenarios correctly.
-**By embracing Test-Driven Development (TDD), developers can unlock numerous benefits:**
+## Benefits of Test-Driven Development:
-* Improved Code Quality: TDD promotes the creation of reliable code by catching defects early and preventing regressions.
-* Efficient Debugging: Early issue detection facilitates quicker debugging, reducing troubleshooting time.
-* Guided Design and Modularity: Writing tests upfront influences the design process, leading to more modular and easily testable code.
-* Enhanced Confidence in Code: A comprehensive test suite fosters confidence in the correctness and robustness of the code.
-* Reduced Technical Debt: TDD encourages prompt issue resolution, averting the accumulation of technical debt.
+**By embracing Test-Driven Development (TDD), developers can unlock numerous benefits:**
-## Conclusion:
+- Improved Code Quality: TDD promotes the creation of reliable code by catching defects early and preventing regressions.
+- Efficient Debugging: Early issue detection facilitates quicker debugging, reducing troubleshooting time.
+- Guided Design and Modularity: Writing tests upfront influences the design process, leading to more modular and easily testable code.
+- Enhanced Confidence in Code: A comprehensive test suite fosters confidence in the correctness and robustness of the code.
+- Reduced Technical Debt: TDD encourages prompt issue resolution, averting the accumulation of technical debt.
-The Ariane 5 disaster stands as a poignant reminder of the devastating consequences that can result from inadequate testing practices. Test-Driven Development (TDD) emerges as a potent solution to mitigate such risks and construct robust software with unshakeable confidence. By diligently writing tests before diving into code implementation, developers can detect issues early, ensure code quality, and deliver software that withstands the test of time.
+## Conclusion:
-As software development continues to evolve, embracing TDD can provide developers with a solid foundation for building robust and dependable software systems. By investing time and effort in testing early and consistently, let’s embark on this journey to shape a future of exceptional software craftsmanship with less risks, enhanced code quality and reliable software solutions to meet user expectations, empowered by the magic of Test-Driven Development.
+The Ariane 5 disaster stands as a poignant reminder of the devastating consequences that can result from inadequate testing practices. Test-Driven Development (TDD) emerges as a potent solution to mitigate such risks and construct robust software with unshakeable confidence. By diligently writing tests before diving into code implementation, developers can detect issues early, ensure code quality, and deliver software that withstands the test of time.
- **Read the previous part of the series on [Introduction to Testing](https://blog.incubyte.co/blog/testing-with-java-intro/)**
+As software development continues to evolve, embracing TDD can provide developers with a solid foundation for building robust and dependable software systems. By investing time and effort in testing early and consistently, let’s embark on this journey to shape a future of exceptional software craftsmanship with less risks, enhanced code quality and reliable software solutions to meet user expectations, empowered by the magic of Test-Driven Development.
-
\ No newline at end of file
+**Read the previous part of the series on [Introduction to Testing](https://blog.incubyte.co/blog/testing-with-java-intro/)**
diff --git a/content/blog/the-battle-of-source-control.md b/content/blog/the-battle-of-source-control.md
index 6b19a4e47..73608b22a 100644
--- a/content/blog/the-battle-of-source-control.md
+++ b/content/blog/the-battle-of-source-control.md
@@ -11,7 +11,6 @@ title = "The Battle of Source Control"
+++
-
```shell
git pull origin develop
git checkout -b feature/shiny-new-branch
@@ -19,7 +18,7 @@ git checkout -b feature/shiny-new-branch
It's the start of a sprint, and you have picked up a new User Story.
-```Given there is no spillover When you are working on a new story Then create a branch from develop to work on the latest code```
+`Given there is no spillover When you are working on a new story Then create a branch from develop to work on the latest code`
And with that, begins the great quest of implementing a new feature. On the adventure, you will pick up many new skills like crafting new abstractions, fresh-off-the-grill language/framework features, and knowledge of the business domain. You shall encounter great friendlies in the kingdom of StackOverflow, through the valley of GitHub, and on the mountaintops of Reddit. That sounds awesome, you think to yourself, but no adventure is complete without SKIRMISHES!
@@ -37,4 +36,3 @@ git push origin feature/shiny-new-branch
All's well that end's well. So you think, and prepare to make a PR, only to be greeted by `MERGE CONFLICTS`. FINAL BOSS! Turns out, your quest has not yet finished! As you try to figure out, what to accept and what to decline, you start the question the basic fabric of reality. The big twist is, the final boss doesn't even reward you with XP or Gold. All said and done, you finally fix them all and click on merge. Into develop the code goes, to embark on another adventure in prod. A subject that we shall cover some other time.
Bonus: There is a hidden mechanic in the game which will make you proof of ever facing the final boss. What is it? It can be many things, but in the end, it can be reduced to a problem of parallelism and concurrency. Merge Conflicts are nothing but your everyday concurrency problems. How to fix them? You don't, you want to avoid those because by nature Human beings are highly async without an event loop. So always frame your stories in a manner that they can be parallelized rather than concurrent.
-
diff --git a/content/blog/think-like-architect.md b/content/blog/think-like-architect.md
index 60d15b670..162839cb1 100644
--- a/content/blog/think-like-architect.md
+++ b/content/blog/think-like-architect.md
@@ -23,6 +23,7 @@ In this article, we dive deep into key principles and strategies that will help
The foundation of architectural thinking lies in understanding that everything in software architecture involves trade-offs.
Architectural decisions require careful consideration of competing factors, such as
+
- Performance vs. Readability
- Modularity vs. Reusability
- Flexibility vs. Simplicity
@@ -80,22 +81,22 @@ Here's a breakdown of these two dimensions:
To enhance technical breadth, commit at least 20 minutes each day to expand your knowledge.
Here are some resources that you can use to stay updated and explore new ideas:
-- [InfoQ](https://www.infoq.com/)
-- [Dzone Refcardz](https://dzone.com/refcardz)
-- [Thoughtworks Radar](https://www.thoughtworks.com/radar)
-- [Hacker News](https://news.ycombinator.com/)
+- [InfoQ](https://www.infoq.com/)
+- [Dzone Refcardz](https://dzone.com/refcardz)
+- [Thoughtworks Radar](https://www.thoughtworks.com/radar)
+- [Hacker News](https://news.ycombinator.com/)
## Tips for Thinking Like an Architect
To enhance your architect's mindset, keep the following tips in mind:
-- **Architecture is an iterative process,** just like software development.
-- **Collaborative decision-making and communication are crucial in effective architecture**.
- Involving developers and business stakeholders provides a broader perspective and considers multiple viewpoints.
-- **Be mindful of the context when making decisions**
- Consider the specific project requirements, constraints and objectives to avoid falling into out-of-context traps.
-- **Avoid over-evangelizing a particular solution or technology**.
- Architectural decisions should be driven by a project's unique needs rather than personal preferences or biases.
+- **Architecture is an iterative process,** just like software development.
+- **Collaborative decision-making and communication are crucial in effective architecture**.
+ Involving developers and business stakeholders provides a broader perspective and considers multiple viewpoints.
+- **Be mindful of the context when making decisions**
+ Consider the specific project requirements, constraints and objectives to avoid falling into out-of-context traps.
+- **Avoid over-evangelizing a particular solution or technology**.
+ Architectural decisions should be driven by a project's unique needs rather than personal preferences or biases.
By embracing the principles of architectural thinking, you can cultivate a mindset that enables you to approach software design and decision-making like an architect.
This perspective empowers you to create well-balanced, effective, and successful architectures.
diff --git a/content/blog/to-repl-or-not-to-repl.md b/content/blog/to-repl-or-not-to-repl.md
index 40aff2fd2..44c01e377 100644
--- a/content/blog/to-repl-or-not-to-repl.md
+++ b/content/blog/to-repl-or-not-to-repl.md
@@ -8,7 +8,6 @@ title = "To REPL or Not To REPL?"
+++
-
For those who do not know what is a REPL: an Intro to Read-Eval-Print-Loop REPL.
The move from Python to Java ecosystem. The discovery of `jshell`, comparison with `IPython`.
@@ -18,4 +17,3 @@ The evolved REPL i.e. Jupyter Notebook. The amalgamation of various ecosystems i
How would Java work in a Jupyter Notebook.
The power of Debuggers. Are they equivalent approaches to solve the same problem?
-
diff --git a/content/blog/why-incubyte.md b/content/blog/why-incubyte.md
index e6f0505cf..8d32002ef 100644
--- a/content/blog/why-incubyte.md
+++ b/content/blog/why-incubyte.md
@@ -11,7 +11,6 @@ title = "Why Incubyte?"
type = "featured"
+++
-
Quality is usually an implicit requirement when it comes to developing software. Users ask for a beautiful UI, outstanding performance, and the functionality they need, but quality is never on the list - it is just expected! And because it is so, it is often overlooked. Users end up getting only what was explicitly stated.
Incubyte's goal is to focus equally on the implicit aspects of software development, that include better scalability, maintainability, testability and security.
@@ -29,4 +28,3 @@ Most developers end up developing software for machines. When they start develop
None of the quality we talk about is possible without continuous learning and upskilling. People that acknowledge this, make a conscious effort to grow the depth and breadth of their skillset. This not only reflects in the work done, but also in more effective pairing sessions, educative lightning talks and stimulating conversations.
These are the teams and the people at Incubyte and they help create quality products, happy users and satisfied clients.
-
diff --git a/content/blog/working-at-incubyte.md b/content/blog/working-at-incubyte.md
index 8cc002cab..d1d77219e 100644
--- a/content/blog/working-at-incubyte.md
+++ b/content/blog/working-at-incubyte.md
@@ -11,7 +11,6 @@ title = "Working at Incubyte"
+++
-
At Incubyte we strongly believe in finding the right talent, helping them to unleash their maximum capacity, and then getting out of their way to let them do what they do best.
The people who make us what we are, are a group of super-passionate individuals who are proud of the way they work. These highly driven individuals own the whole DevOps pipeline and are evangelists of extreme programming principles.
@@ -63,4 +62,3 @@ The Company holds each one of its employees to an extremely high standard on per
11. Laptop hardware is provided to all our employees as per their configuration need
12. Welcome Kit with Incubyte merchandise
-
diff --git a/static/images/2023/12/meeting.jpg b/static/images/2023/12/meeting.jpg
new file mode 100644
index 000000000..e48e400ad
Binary files /dev/null and b/static/images/2023/12/meeting.jpg differ
diff --git a/static/images/2023/cypress-guide/header-image.jpg b/static/images/2023/cypress-guide/header-image.jpg
new file mode 100644
index 000000000..175f7af0d
Binary files /dev/null and b/static/images/2023/cypress-guide/header-image.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/architecture.jpg b/static/images/2023/introduction-to-systems-thinking/architecture.jpg
new file mode 100644
index 000000000..fd46e28cf
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/architecture.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg b/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg
new file mode 100644
index 000000000..2ea79cb54
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/balancing_loop.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/banner.jpg b/static/images/2023/introduction-to-systems-thinking/banner.jpg
new file mode 100644
index 000000000..cea8148c7
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/banner.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg b/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg
new file mode 100644
index 000000000..fc69e7a14
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/policy_resistance.jpg differ
diff --git a/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg b/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg
new file mode 100644
index 000000000..f6d6c0a36
Binary files /dev/null and b/static/images/2023/introduction-to-systems-thinking/reinforcing_loop.jpg differ
diff --git a/themes/bigspring b/themes/bigspring
index 248923a6c..bec36f774 160000
--- a/themes/bigspring
+++ b/themes/bigspring
@@ -1 +1 @@
-Subproject commit 248923a6c7e0a6853b560412be81cffc36f0c373
+Subproject commit bec36f77483fbf5dfb04f8df733cee98319335cd