In fact, it is thanks to firmware that:

• Printers work
• Defibrillators work
• Car radios works
• and more …

Based on the examples above, you probably already have some idea of what firmware is. But you don't have a clear definition of it.

In order to truly understand what firmware is, we must first understand software, then hardware, and finally we can jump into firmware.

In this tutorial, I'll explain each topic with an analogy. By doing so, everyone can understand.

It doesn't matter if you're just getting into technology!

With that, I would like to make sure that everyone understands what software, hardware, and firmware is. I will not elaborate on the technical terms.

In this article we will explore:

• What exactly is software?
• What exactly is hardware?
• What exactly is firmware?

What is Software?

_Photo by [Pexels](https://www.pexels.com/@kubra-dogu-80605500?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">Kübra Doğu from <a href="https://www.pexels.com/photo/food-wood-dawn-coffee-9222655/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

Imagine, if you will, that you have no idea what to make for dinner today.

Luckily, you find an old cookbook you have and decide to cook one of the recipes in it.

The cookbook has many recipes. Each of these recipes has its own instructions.

In the cookbook, a recipe can be seen as a set of steps (or instructions) that together make a meal.

Photo by Luis Quintero on Pexels

You can also create your own meals based on your experience in cooking many different recipes, right?

Software is no different.

Software programs can be seen as a set of instructions that work together to form a program.

 global  _main
    extern  _printf

    section .text
_main:
    push    message
    call    _printf
    add     esp, 4
    ret
message:
    db  'Hello, World', 10, 0

Then, applications are a big sets of instructions that perform specific tasks.

Operating systems are big sets of instructions that coordinate software and hardware resources.

• Cookbook = software
• Dinner cookbook = type of software (application or operating system)
• Recipe = program

You need a recipe to make dinner. You must follow each step in the cookbook to create a recipe.

Once you have completed all the steps, your dinner is ready.

You need software to accomplish a particular task. A computer has to follow all instructions for the software to function.

Therefore, the software is running either while the instructions are being followed or after they have been completed.

What is Hardware?

_Photo by [Pexels](https://www.pexels.com/@elevate?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">ELEVATE from <a href="https://www.pexels.com/photo/chef-preparing-vegetable-dish-on-tree-slab-1267320/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

In order to make dinner, you need a series of steps from the cookbook that tell you how to make a particular meal.

You also need various tools to cook with - like pots and pans, knives, and the food itself. This is like hardware.

So a cookbook gives you instructions that allow you to cook.

For hardware to work, it needs software (a set of instructions) to tell it what to do.

Software then, gives instructions to hardware that lets it work.

• Meal prep tools = hardware
• Recipe = software

Without software, you can't make hardware work.

Without a recipe, you won't know what to do with your various tools and ingredients to make a meal.

Like hardware without software, you can also eat a meal with just uncooked food. Gross.

In the same way that there are various types of meals, there are also various types of computer hardware.

For example:

• CPU
• RAM
• GPU
• and so much more…

Comparison of processes

What is Firmware?

_Photo by [Pexels](https://www.pexels.com/@ella-olsson-572949?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">Ella Olsson from <a href="https://www.pexels.com/photo/close-up-photo-of-chocolate-mousse-3026810/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

A program is a set of instructions read by a computer.

Let's say you just want to make a snack or dessert. You probably don't need as many ingredients as when making a dinner for your family, right?

Let's say you want software that runs on a microwave. You don't need all the hardware the computer has to make the microwave work, right? You just need that specific to making the microwave work.

Or say you want software running on a printer. You don't need all the hardware the computer has to make the printer work right? Just the software for the printer.

• Microwave software = firmware
• Printers software = firmware

So this means that firmware is nothing more than software, but in a hardware device. Not in a computer.

Firmware lets very specific hardware complete very specific tasks.

Wrapping up

Thanks for reading! Now you know more about:

• Software
• Hardware
• Firmware

Microprocessor photo by Pok Rie from Pexels

Learn the answers to these questions and more from a group of experienced developers and technical course creators.

We just published a video on the freeCodeCamp.org YouTube channel where experienced developers answer the top questions asked by people new to the software field.

You will get wisdom from the following people:

• Gerald Versluis, Senior Software Engineer at Microsoft
• Mama Samba Braima Nelson, Software Engineer
• Gwendolyn Faraday, Principal Software Engineer at Relevize
• Ania Kubow, Software Developer and Course Creator
• Marius Espejo, Senior Software Engineer
• Ave Coders, ML Engineer
• Jack Herrington, Principal Web Developer
• Nana Janashia (TechWorld with Nana), DevOps Engineer & Trainer
• Gift Egwuenu, Frontend Developer & Content Creator
• Jesse (codeSTACKr), Developer Advocate
• James Perkins, Developer Advocate
• Gio (ProgramWithGio), Full-Stack Web Developer
• Delia Lazarescu, Software Engineer at Google
• Islem (CoderOne), Full-Stack Developer and Content Creator

Watch the video below or on the freeCodeCamp.org YouTube channel (1-hour watch).

Software is synonymous with the terms program and application.

Software can describe an operating system like Windows 10 or macOS, or their underlying processes. Software can also describe things like Microsoft Word or Adobe Photoshop.

The term software is often contrasted with hardware.

Computer hardware, is physical or "hard", and is difficult to change once it's produced.

Software runs on computer hardware, and is "soft", or easy to change in comparison to hardware.

Related Tech Terms:

• Hardware Definition
• Macintosh Definition
• PC Definition

By the end of the project, you will code your own LED light, have the knowledge to manipulate the LED to on/off in intervals you choose, and learn basic principles of hardware.

The Elegoo Uno starter kit has all the hardware as well as instructions you need to make a simple LED Light. The LED Light is the first project offered with their kit.

Elegoo Uno comes with many other projects and takes you through from beginner to advanced projects. Each project in the box advances your skills in a simple, easy to follow way.

Components You'll Need

Elegoo Uno R3

Elegoo Uno R3

The Elogoo Uno R3 is a microcontroller board. Microcontrollers are embedded inside devices to control the actions and features of a product. They are compact integrated circuits designed to control operations.

The microcontroller that is included in the Elogoo Uno R3 has 14 digital input/output pins, 6 analog inputs, a USB connection, a power jack, and a reset button. This board has everything you need to support the microcontroller. Simply plug in the USB Cable to turn the microcontroller on.

USB Cable

USB Cable

You need a USB Cable to connect the Elegoo Uno R3 to your computer and turn it on. USB stands for Universal Serial Bus. The USB is used to connect your computer to devices such as digital cameras, printers, scanners, and external hard drives.

In our project, we will use a USB cable to connect our microcontroller to our computer.

LEDs

LED Light

LED stands for light emitting diode. It has a positive and negative lead. The longer side is the positive lead.

How to assemble the components

In this project, we are only going to make the LED blink.

First, we need to plug in the USB Cable to the board and then the computer.

Then we need to plug in the LED to GND (GND is the reference point in an electrical circuit from which voltages are measured, and is a common return path for electric current) and the 13 input on the board.

Code to make the LED flash on/off:

After the microcontroller board is plugged into the computer and the LED is on the board itself, we need to write some simple code to make the LED blink.

// the setup function runs once when you press reset or power the board

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on 
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off
  delay(1000);                       // wait for a second
}

The code above basically turns the LED on for 1 second and then turns it off for one second.

This function is in a continuous loop. The digitalWrite is a function that takes in 2 parameters, LED_BUILTIN and HIGH || LOW . The loop basically takes in the LED, and then turns the volt to HIGH which turns it on. Then after 1 second it turns the same LED off by turning the volt to LOW .

Here's the Final Product:

The goal of this little LED Light Coding project was to introduce you to elementary principles of how hardware and software can be combined. I hope you enjoyed it!

Kanban was invented in the Japanese automotive industry in the first half of the 20th century. Inspired by how supermarkets stock their shelves based on demand, Toyota's goal was to reduce inventory and to improve the flow throughout their whole production system.

In his book Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson described how to apply the Kanban principles to software development. These principles are:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities, and titles

What does that mean for agile software development?

In my training courses, I ask the attendees what they already know about agile software development. Common answers are: "Work in Sprints", "There's a product owner", "Manage user stories in a backlog." People are influenced by the arguably most popular agile framework today, Scrum.

Scrum comes with its own predefined roles, events and artifacts. Scrum requires you to follow the rules defined in the Scrum Guide, if you want to call what you're doing Scrum. Kanban is different.

Kanban starts with the process that you follow in your company now. Visualize the steps on a Kanban board. They can include everything you do, from idea to delivery.

Each step becomes the title of a column on the board.

To track your day to day work, it's best to break it down into small items. Maybe user stories that can be implemented in, at most, 2 days. Write each item on a stickie note, and hang it on the board. You can use the vertical order on the board for prioritization.

The cards move from left to right. The people doing the work pull items that have been finished by the previous process step. When they have capacity to do so. So the developers in the example pull the Upload Image card into Dev when they have the capacity to implement it.

Pursuing incremental, evolutionary change

So you have created a Kanban board that shows your process? You are making your work visible, which is a great start!

To get the benefits of Kanban, you need to do some more things. You need to:

• Limit work in process and queues
• Observe and improve flow
• Collaborate effectively

Limit work in process and queues

Limiting work in process means: you set a maximum for the number of items you work on. That's called the Work-in-Process limit, or in short WiP limit. Here's the Kanban board with a WiP limit for some process steps.

The developers can work on 5 items at a time. At most. If their column contains 5 items, they are not allowed to pull items any more. This has two consequences.

First of all: it encourages people to finish their work, instead of starting more work. Started work that isn't finished bears risks. How happy will your customers be when you can't release your software as planned? Because you started to work on all these great ideas, but you didn't go through with them?

The second consequence of limiting work in process: bottlenecks become visible. When a process step starts work that it can't finish, people will feel it immediately. Because the next process step won't be able to pull items.

Apart from limiting the work in process, you should limit queue sizes, too. In the board above, they are shown as the dotted lines between the columns. It works the same way as limiting the work in process.

In summary: Stop starting, start finishing is the motto. From concept to delivery in as little time as possible.

Observe and improve flow

Observing a bottleneck can be painful at first. But at least you know where the major problems are in your process. And Kanban encourages you to improve the flow by removing the bottleneck. A consistent flow enables you to deliver more reliably, and that's good for all stakeholders, including developers.

To observe the flow, you record the time at which a card enters a process step. And the time at which you complete the process step. So you know how much time the card spends in each step, and in each queue between the steps.

Based on the data, you can set up metrics that help you to improve the flow. Common metrics include:

• Cycle time: the time a card takes from the moment a team starts working on it (i.e. Dev) to delivery (i.e. Release). Improving this metric can help you improve your time to market.
• Throughput: the number of cards that move through the system in a given time. Improving this metric can help you improve the performance of your delivery organization.

A common way to get an overview of how many cards are in which process step over time is a cumulative flow chart. Ideally, the number of cards in each step but the last stays roughly the same over time. The number of released cards should mount. When the chart deviates from that, you might have a bottleneck.

Collaborate effectively

The Kanban metrics are a powerful tool to analyze and improve what you're doing. But they are worthless without the people doing the work. Everybody involved in the process steps should be open to the transparency that Kanban creates.

People should work together constructively to remove bottlenecks, instead of blaming individuals. Look at the current state regularly. Are there any bottlenecks? Is there too much or too little work available for a certain process step? Is throughput sufficient? Are there other sources of discontent? What needs to be improved?

Agree on experiments that try out small changes to the system. Realize the changes. Later, look if the experiments worked out as expected. To be able to implement the changes, management support is often crucial.

When to use Kanban

Kanban is very flexible. It can be used in combination with Scrum, which is called Scrumban. It can be used outside of product development. You can even use it to plan a trip or organize what you do in your free time.

I found it especially helpful when working in Scrum Sprints is not possible or is difficult. Example: two companies where one is customer, and the other is supplier, and a hand-off is inevitable. Another example is when you're working on a product that involves both software and hardware, and multiple engineering disciplines are involved.

Kanban can also be used inside your company when development works in an agile fashion, but not all of the rest of the company does. It can be used to facilitate the cooperation between strategic planning and software development.

Don't think that just because you have trouble implementing Scrum, there's no way to become more agile. Kanban starts with what you do now. And if you take it seriously, it will help you improve. One small step at a time.

To learn more about agile software development, visit my online course. To keep up with what I’m doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

• What is agile?
• What are some concepts you should know?
• Stories
• Epics
• Sprints

What is agile?

Agile is a software development methodology that stems from the idea of breaking up large amounts of work into smaller pieces. This gives product managers, developers, and any stakeholder a better understanding of the work.

Historically, software development was a slow process where major changes to requirements could put large strains on teams.

When following the agile methodology, the smaller chunks of work help teams become more flexible, and dare I say agile. And in the process it helps them deliver features faster and respond to changes quicker.

Example Jira project board from atlassian.com/software/jira

These ideas have been broken up into different frameworks of approaching this methodology. Two of the common ones are Scrum and Kanban.

For this walkthrough, most of these concepts follow along the Scrum framework, but there are certainly concepts that apply to both and others.

What are some concepts you should know?

I'd argue half of being productive as a developer in an agile world is simply understanding the terms. Typically the project manager runs the show, so if you can be on the same page with what they're talking about, it will make the process a lot easier.

There are books, courses, and certifications based around learning the nuances of the agile methodology. I'm not going to go deep into some of the philosophical aspects or some of the deeper parts, but I'm going to cover a good set of key concepts that will help you hit the ground running when you start your new job with an agile team.

Stories

A story is typically the smallest defined piece of work. This usually comes in the form of a new ticket that you create in the project tool you're using whether it's Jira or even Github Issues.

Expressing stories

When working on a project, you'll probably run into a variety of ways people express stories. But a good guideline is to work through the concept of the word "story" itself and explain the work that needs to be done in that way.

For instance, if you would like to provide the ability for the people who use your website to share a blog post on Twitter, you may want to write the story as: As a reader, I want to share the post I just read to Twitter.

Creating a new story in Jira

Using that pattern of "as a [person], I want to [action]" helps provide context as what state somebody may be in when visiting their site and what they're trying to achieve. This can be particularly helpful if you're developing features for people who are logged in that are different from guests.

Details and requirements

While the title of a story is an important representation of the work, you'll also want to provide additional specifics.

At a minimum, that should be done by adding a thorough description and a set of acceptance criteria that can help give the developer context and requirements. Depending on the team, this can also include tools like tags or categorizations that make it easier for the team to visualize groups of work.

Providing a strong set of requirements helps both the developer working on the story and the person reviewing it have a measurement to determine if it's actually complete. Without it, everyone's just guessing.

A good way to phrase these are: verify [requirement]. Back to my example of sharing a post on Twitter, maybe some of the requirements to that story would be:

• Verify when clicking the share button a new tweet is created
• Verify the tweet includes a link to the current blog post

Amount of work or level of difficulty

Each story is represented by a number of points. Those points are a way to express how much effort a team of developers expects one story to be. That effort can mean a variety of things though whether it's simply how difficult the team expects the work to be or the amount of risk or uncertainty a particular story has.

One way teams represent this is with the fibonacci sequence, where the amount of points can be 1, 2, 3, 5, 8, etc. Where a negligible text update might be 1 point, adding a new form to a page could be 3 points.

Typically you'll want to avoid pointing stories too high, as you get above 5 points, there's more than likely a way you can break up the work to make it more manageable. While you could easily create a massive 13 point story to accomplish all aspects of a feature, it usually makes sense to tackle the work in smaller, more focused chunks.

Either way, these points all add up together to give your team a rough estimate of how much work a group of stories would take to complete.

Epics

While stories have a goal of defining a bite-sized piece of work, epics are a way to group those pieces of work together to represent a feature.

Defining stories as a feature

A good way to explain this is with another example. If you're working on an application that requires the integration of authentication, you may want to create a new epic simply called "Authentication".

Inside that epic, you could find stories like:

• As a guest, I want to sign into the application with my email address
• As an authenticated user, I want to change my password
• As the security team, I want to prevent spam and abuse of user authentication

Example of an Authentication epic in Jira

With your epic defined, you're giving your team a path to calling a feature complete while also understanding the entire scope of that work. This is important when it comes to planning out the work to be done.

Defining your stories in your epic gives you a sense of how much work something takes, but it doesn't help you figure out how long it would take, which is where sprints come in.

Sprints

Sprints are a way of planning out how the work will actually get done. While similar to epics in that they are a way to group chunks of work, sprints typically represent a period of time in which a particular chunk of work will be done.

Time per sprint

A common way of defining a sprint is two weeks of work. During those two weeks, your team will have a particular velocity, or average amount of work you can complete, for an individual sprint. This velocity is represented by a number of points that is a sum of the average velocity of each of the developers working on that sprint.

Points per sprint

Though many fiercely argue you shouldn't use time to represent that velocity, points will roughly translates to an average amount of time of work for each developer. While 1 point for an experienced developer could be 1 hour, that same 1 point could mean 3 hours for a less experienced developer.

Example project roadmap from atlassian.com/software/jira

But once you have this number of points that your team averages in a sprint, you'll know how many story points you can expect to plan to be completed. This planning goes sprint to sprint as you spread out a group of stories or an epic so you can predict when a feature will be complete.

How agile fits with your team

Try to remember that the Agile methodology through Scrum, Kanban, or any other framework is just that – a framework. While it's probably a good idea to follow the process when you first start out, listen to your team and try to mold it to your own experiences.

Each team works a little bit differently and forcing a process onto that team can cause more harm than good, but there will always be a learning curve for any process. Fight the eye rolls until everyone gets the hang of it and have frequent retrospectives to see what works and what doesn't.

At the end of the day, the processes your team follows should mostly be invisible, working for you instead of against you. Find what works best for your team and share your experiences for others to learn!

What's your teams process?

Share with me on Twitter!

Believe it or not, some organizations still rely on legacy software to carry out operations even though newer and more versatile options are available. We know that “old is gold”, but legacy applications cannot glitter forever. As such, these old and outdated programs have become hard to maintain.

Recently, the U.S. Government Accountability Office (GAO) gave a report that pointed out the most critical federal legacy systems that need to be modernized. This is because they are based on antiquated programming languages, are prone to security loopholes, and are difficult to maintain.

Are you in the same shoes?

In this article, I’m going to talk frankly about the challenges you'll face when maintaining legacy software applications, and how you can overcome them.

Legacy systems are inefficient

Software maintenance is important – it helps enhance the efficiency of the product and narrows the margin for error. Without sufficient maintenance, an application can become inefficient and difficult to operate.

First of all, maintaining a legacy system can be difficult because the code used is old when compared to the code used in any modern software. Old code usually tends to be bulky, lengthy, and incompatible with most modern systems.

For example, JavaScript arrow functions, which were introduced in ES6 in 2015, offer developers a way to write shorter and cleaner function syntax, which is easier to maintain.

let total = (x, y) => x + y;

/* This arrow function is a shorter form of:
let total = function(x, y) {
  return x + y;
};
*/

console.log(total(5, 2) ); 
// 7

High maintenance costs

Another challenge facing most legacy systems is the high cost of maintenance, which may be out of reach for most enterprises.

For example, according to the GAO report mentioned above, the U.S. government planned to spend more than $90 billion in 2019 on IT services, most of which went towards maintaining aging systems.

Furthermore, as technology is evolving, compliance is becoming a major issue for the protection of consumer-facing applications. Achieving compliance with legacy systems is time-consuming and expensive. It will not happen as quickly compared to new applications who are often compliant by default. It also requires a lot of testing to ensure a legacy infrastructure is compliant with the given regulations.

The cost of maintaining a legacy system often increases with time, as it slowly becomes obsolete due to technological enhancements. Also, modification of an existing system is a risky venture, which requires a lot of time and resources.

Lack of sufficient skill sets

For legacy software to be maintained, you need a developer conversant with its operations. However, most developers are future-proofing their applications with new technologies. So, getting someone who can work with an old system can be a challenge.

In some cases, you might need to re-train developers on how the legacy system works, which increases a company’s operating costs.

Furthermore, managing and controlling changes occurring in the software can be difficult. A lot of time and effort is required to keep the systems operational, which is expensive and time-consuming.

Incompatibility with other IT solutions

Currently, there are modern tools that can be used to enable fast and smooth maintenance of software. However, most legacy IT infrastructure is incompatible with such solutions, which complicates their maintenance.

If the features in a legacy system are not compatible with those of new IT solutions, developers may find it difficult to integrate them into their environments.

The difficulty of introducing new features to legacy systems also adds to the challenges in their maintenance. Since most legacy systems break easily, trying to restructure and make them more maintainable may not work as expected.

Solutions to the challenges

To compete favorably in today’s dynamic IT landscape, legacy technologies need modernization. Updated legacy applications lead to more user productivity, reduced maintenance costs, and more helpful experiences.

According to recent research by Avanade, modernizing IT systems can lead to a revenue growth of about 14%. Therefore, choosing different software modernization options could lead to significant benefits to your business.

It’s important to note that software should not be declared obsolete just because it’s old. Some of the ‘old’ software may still contain rich features, which can be useful to the optimal functioning of an application.

Therefore, to overcome the challenges of maintaining aging software, developers can opt to refactor the source code of the system. This way, they can use clean and modern code that is reusable and easy to debug.

In refactoring, you alter your software system to enhance its internal structure. But you don't interfere with the external behavior of the code. This way, the features of the software are optimized due to the code's internal improvements.

When refactoring legacy code, updates and modifications should be sufficiently tested to avoid breakages and poor functioning of the application. For example, regression tests can be done to ensure that everything is working as desired.

Additionally, where resources permit, developers can opt to rewrite the entire source code of the software, while employing modern programming approaches.

If you want to continue maintaining your legacy code without breaking it, you can use any of the following three methods:

1. Identifying change points in the code
2. Isolating your code
3. Wrapping the code

Let's talk about each of the methods.

Identify change points in the code

As pointed out earlier, maintaining legacy code can be challenging. Sometimes the issue can be caused by a section that has been poorly programmed. Therefore, you can overcome this by identifying a location that can allow you to change the application's behavior without altering the source code.

For example, let's say you have the following JavaScript code in a legacy application that connects to a database:

export class DataConnection {
     //some code here

  connector() {
    // some code to connect to database
  }
}

If you want to run some tests on the above code but the the connector() method is causing problems, you can identify where to modify the code behavior without affecting the source code.

In this case, you can extend the DataConnection class and stop it from establishing a connection to an actual database:

class FakeConnection extends DataConnection {

    connector() {
    // solve the issues of making calls to DB

    console.log("Establishing a connection")
  }
}

Consequently, after modifying the code behavior without affecting the source code, you can run tests on the code and maintain it without any problems.

Isolate your code

Another technique that can allow you to maintain your legacy code easily is to isolate and make any changes on a different environment. You just need to identify an insertion point where you can call that changed code from the existing legacy code.

Here is an example:

class BooksData {
  // some code here

  addBooks(books) {
    for (let book of books) {
      book.addDate()
    }

    // some code here

    booksRecords.getNumberOfBooks().add(books)
  }

  // some code here
}

Let's say you want to optimize the books reference in the above legacy code, but addBooks() is giving you problems.

So, you can isolate the code in another new method, like newBooks().

Then you can run tests on this new method successfully because it is separate from the rest of the code. Afterwards, you can include a call to the new method in the existing, non-changed code. This way, there'll be minimal changes and minimal risks to the legacy code.

Here it is:

class BooksData {
  // some code here

  newBooks(books) {
    // some smart and testable logic to optimize books
  }

  addBooks(books) {
    const newBooks = this.newBooks(books)

    for (let book of newBooks) {
      book.addDate()
    }

    // some code here

     booksRecords.getNumberOfBooks().add(books)
  }

  // some code here
}

Wrap the code

If you want to make changes that should take place before or after the existing code, wrapping it can also be another solution.

You can achieve this by giving the old method you intend to wrap a new name, adding a new method with the same name and signature just like the old method, and calling the new method from the new method. Lastly, you should place the new logic before or after the previous method call.

With the new logic, you can run tests or make any changes you want – without affecting the source code.

For example, here is the code we used previously:

class BooksData {
  // some code here

  addBooks(books) {
    for (let book of books) {
      book.addDate()
    }

    // some code here

    booksRecords.getNumberOfBooks().add(books)
  }

  // some code here
}

Here is how to solve the problem through wrapping:

class BooksData {
  // some code here

  addBooks(books) {
    // some smart logic to get books
    this.addMoreNewBooks(moreBooks)
  }

  addMoreNewBooks(books) {
    for (let book of books) {
      book.addDate()
    }

    // some code here

    booksRecords.getNumberOfBooks().add(books)
  }

  // some code here
}

Conclusion

Although modernizing antique software is complicated, demanding, and risky, the results are usually worth the risk. Continuing to rely on legacy IT systems is the same as continuing to use the post office to send an urgent message, while an email could do the trick at the click of the button.

Furthermore, as a programmer, do you equip yourself with modern coding skills? Or, do you still rely on old approaches?

For example, in the exciting world of JavaScript programming, we’ve witnessed a surge of frameworks, like React and Angular, which are defining the future of the language. Spending some time learning about them could prevent you from falling into obsoleteness.

Do you agree?

When I decided to teach myself how to code almost four years ago I had never heard of, let alone thought about, the software development life cycle.

As a brand new developer I was focused on learning the technologies that would help me land that coveted first developer job, not the nuances of how those teams operated.

When I did learn of them, I thought they would be useless to me because I considered myself a web developer not a software developer.

I've since learned that this couldn't be further from the truth and these principles/practices play a large role in my day-to-day activities (whether I realize it or not).

I'm fortunate enough to see how the code I write, the features I build, and the bugs I inadvertently introduce (more than I care to admit) affect the end user and their experience. That experience has helped shape how I think about the process of building products and solving problems for my users.

I've had some time to think about the differences (and similarities) each of these approaches offer. At their core, each is focused on delivering high quality software as efficiently and as cost effectively as possible.

Professionally, I've only used one or two of these methodologies. But I still find value in at least a basic understanding of all of them.

All of these methodologies follow a series of phases similar to this diagram:

Requirement Analysis -> Design -> Implementation -> Testing -> Evolution

So, here are the software development life cycle methods (in no particular order):

• Lean
• Agile
• Waterfall
• Iterative
• Spiral
• Dev Ops

Let's dig in to the differences and similarities of each method.

Lean

The Lean methodology relies heavily on and is comprised of seven principles.

In no specific order they are:

1. Eliminate Waste
2. Amplify Learning
3. Decide As Late As Possible
4. Deliver As Fast As Possible
5. Empower The Team
6. Build Integrity
7. See/Optimize The Whole

Each principle has a specific purpose with benefits that compliment each other.

Eliminating waste (extra features, incomplete work, managerial engagements, etc) creates more value for the customer which, in turn, enhances satisfaction.

Amplifying learning allows teams to reinvest in their ability to deliver products to customers.

Deciding as late as possible refers to all major decisions, giving teams an option based or a set based approach. This allows teams to gather facts rather than opinions to help influence decisions when made.

Delivering as fast as possible is self explanatory - build the product as quickly as possible to deliver it to customers for evaluation/iteration.

In a typical scenario, the managers dole out assignments/work to the developers. In the Lean methodology developers "teach" managers how to listen to the "people in the trenches" thus influencing the decisions/choices of management.

This helps teams feel more empowered to speak up about ides and solutions.

Making integrity a rule instead of an exception means that the customer is confident in the system being built. The customer knows the system is being built to withstand the appropriate amount of growth and "stretching" if need be.

I like to think of the integrity part along the same lines as sitting in a chair. When you sit in the chair you believe it was constructed with the best material that will hold you up every time you sit in it for the life of the chair. The customer needs to that same confidence in the product being built.

Lastly, seeing and optimizing the whole refers to the entirety of the system being built. By optimizing for the whole we look at software not as a sum of many components, but as one large entity that is optimized for efficiency.

This means that during development, the product is broken into manageable pieces and that inadvertent bugs are not only discovered but resolved swiftly.

Agile

This is the "fail fast" approach to building software.

It places emphasis on small, incremental releases with on-going release cycles. With each iteration teams strive to identify and address small issues before they become big problems.

This also means that the teams must engage stakeholders (people/organizations that the code can ultimately affect such as managers, technical leads, CTOs, and customers) to get their feedback.

If you're a freelance, your stakeholder(s) would be your customers - ultimately you need to ensure their satisfaction with the work before moving on.

Agile is technically an offshoot of the Lean methodology with some notable differences - mainly it prioritizes customer satisfaction from the outset and allows teams to respond quickly to customer feedback.

Although it is beyond the purview of this article, there is another more complex framework within Agile that is called SCRUM. This methodology is used for large, extremely complex projects and has even been used outside of software development.

Waterfall

The waterfall methodology is, by most accounts, the oldest one in the list. It was never meant to be a model for software development and got its start in the construction and manufacturing worlds.

This approach is simple in its structure - finish all parts of a phase before moving on to the next phase with more momentum building towards the project finish as stages are completed. Each stage's beginning (except for the first) and completion is contingent on the previous stage's completion/transfer of information.

Under the waterfall approach each stage has its own rigid project plan that finishes off with testing for previously completed work. It should be noted that this approach is not recommended for larger/longer lasting projects because of the aforementioned rigidity.

Think about the genesis of this methodology and you'll understand it more. It came from the construction/manufacturing world where it is common to complete one phase at a time. During the building of a house you wouldn't start putting in the plumbing before the frame has been put up.

That's not the way software development works generally. As we all know it sometimes becomes necessary to revisit a phase that was previously thought to be finished.

Iterative

This is known as the "repetitive approach" or the "make it better the next go around" approach because of the different opportunities it provides to improve the product with each cycle iteration.

I'm biased (as we all are :D) but this happens to be my favorite life cycle for development. I believe it works best for my current situation both in my freelance and career path because it allows me to constantly "move forward while making things better."

With the iterative approach, teams implement a solution, test that solution, evaluate its effectiveness/throughput, and then pinpoint further areas for improvement. This happens for each cycle (iteration) of the development process.

With each version released comes another iteration until the final product is completed and ready for rollout to users.

One of the great features of the iterative approach is you and your team get a working version of software early on in the development process. This can be especially useful to show to stakeholders to gauge their response/feedback.

One of the big drawbacks to this approach is it can consume a large amount of resources very quickly. Imagine all of the people, hours, bug fixes and wages that go into each iteration of the development cycle and you'll get a good picture of the resource usage.

Within this approach is a subset of principles developed by Rational Software Corporation (bought by IBM) called the Rational Unified Process (R.U.P.) which consists of 4 phases:

• Inception
• Elaboration
• Construction
• Transition (product release)

This set of principles is meant to be flexible and tailored to the needs of each team using it.

Spiral

The spiral methodology is likely the most flexible out of the six. It's a methodology built on risks - identifying and negating them. Risk (identification & aversion) drives every decision in this model. It is broken into four sub-phases:

• Planning (objectives)
• Risk Analysis (identify possible roadblocks)
• Develop & Test (current & next version)
• Evaluation (review of current phase & plan for next phase)

Each iteration of each phase begins with planning for the next phase. This way potential risks are identified before they are encountered. This also allows for a plan of action when said risks arise.

During phases teams also work to mitigate these risks and their impact on future iterations of the spiral development.

As the development process continues, each of these four sub-phases is repeated in spiral fashion. This allows for multiple rounds of refinement for each sub-phase until completion.

Dev Ops

If you do a quick search, you will find no shortage of information on this development life cycle method. It is the new kid on the block that brings software development and information-technology operations teams into the same fold.

These teams work in conjunction to provide small, but impactful, updates to products that come at a frequent pace. In turn, this creates a continuous feedback and improvement loop that drives development.

This particular methodology is known for automating the manual parts of development as well (think deployment).

The overall goal of this methodology is, like most others, the shorten the development life cycle and provide quality products.

One of the drawbacks to this methodology is the significant mindset and culture changes within an organization. Teams that may have been accustomed to working on many things find their tasks narrowed to only one or two.

For example, a general purpose developer may find they are now being tasked with only the testing portion or the end-user experience portion.

Bringing It All Home

_Photo by [Unsplash](https://unsplash.com/@clever_visuals?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Clever Visuals on <a href="https://unsplash.com/s/photos/bright-idea?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

I hope you can now see the importance and the benefits of each of these methodologies. Each of these possess their own strengths and weaknesses.

They are, at their most basic level, a set of guidelines and principles that seek to deliver high quality, efficient work to stakeholders.

When I first started learning to code I didn't have a mentor. By sharing what I've learned I hope to help those who are learning to code when/where they can.

I want to share as much information and experience as I possibly can with other developers. If you are teaching yourself to code or if you're a seasoned developer I hope this article helps, even if in a small way.

Check out my blog where I frequently post articles about web development.

While you're there why not sign up for my newsletter? You can do that at the top right of the main blog page. I like to send out interesting articles (mine and others), resources, and tools for developers every now and then.

If you have questions about this article or just in general my DMs are open -- come say hi on Twitter or any of my other social media accounts which you can find below the newsletter sign up on the main page or on my profile here :)

Have an awesome day and happy coding, friend!

Skills-based Volunteer Organizations:

• FindCollabs
• Give Camp
• Volunteer Match
• Catchafire
• Anyone Can Have A Website

Building a website:

• How to build and deploy a website without writing any code for free
• Wix
• Square Space
• WordPress
• Imcreator.com

Donor and Volunteer Management Systems:

• Cause Signal
• The Data Bank
• Donor Snap
• Donor Perfect
• E Tapestry
• Z2 Systems
• Reg Packs
• Sumac
• Volgistics

Inventory Management Systems:

• Ordoro
• Unleashed Software
• EZ Office Inventory

E-Learning platforms:

• Dokeos
• E Front Learning
• Moodle
• Sakai Project

Community Management:

• CiviCRM
• Total Community Manager

Electronic Forms:

• Typeform
• Google Forms

If your website takes longer than 3 seconds to load, you could already be losing nearly half of your visitors.

Yes this is a fact, proven by several research studies. Long loading times can have a devastating impact on your application’s conversion rates. On the other hand, optimising page load time leads to noticeable improvements in customer experience, conversion rates, SEO and ultimately, your product’s success.

So let’s say that you have recently built a website or a frontend application using a modern JS framework (Angular, React, VueJS etc.). How can we make sure that performance is not going to hold it back from success?

First things first. We have to somehow gather some data. When it comes to measuring a frontend application’s performance, the tools I trust the most are:

• Google chrome’s Lighthouse
• Speedcurve

Both tools can help you keep track of all the major performance KPIs (Pagespeed Index, Time to Interactive, First Contentful Paint, etc.).

Lighthouse is included in your Chrome’s dev-tools, and by analysing your website/web-app, it can give you some really useful hints on how to boost it up.

Chrome’s lighthouse can give you some really helpful hints

With Speedcurve you can have all these KPIs, plus the ability to monitor them across time.

So now that we are able to measure our success, let’s move on with optimising the parts of our website that play the biggest role.

Images

Images are a key part of every website. On average, images make up for more than 60% of data that are loaded on web pages. Being such a critical component of almost all websites, image optimisation is, in my opinion, the most important, and perhaps the lowest hanging fruit.

1. Resize your images and make them responsive.

The most important thing to check is that you are not using a bigger resolution than the one you really need. So you have to resize your images to fit exactly the requirements of your layout.

Responsive layouts need responsive images

Furthermore, you have to make sure that your images are as responsive as your layout is. There is a great tool that I have been using lately, which can help you generate all the different versions of the images that you might need and also generate the HTML5 code that can utilise them. It’s called Responsive Image Breakpoints Generator. I usually prefer generating 8–10 different images.

Of course you can use the generated HTML5 code in any frontend app or website. In addition, if you are into gulp, you could automate this process with the gulp-responsive plugin.

2. Make sure they are lazy loaded.

Lazy loading basically means that we defer the loading of images that are not required immediately. Typically, any image that is not visible to the users on their current viewport, can be loaded at a later point in time, when the image enters or is about to enter the viewport.

No matter which framework you are using, you can find a plugin that can lazy-load the images for you (e.g. v-lazy-image in VueJS), however you could build your own implementation too. Just make sure that you are utilising the modern way to detect when an element enters or exits the browser’s viewport, the IntersesectionObserver API.

Bonus: Use a CDN for image delivery

If you have already optimised the size and the number of images that your website loads, and especially if it’s going to be available globally, you could also use a content delivery network (CDN) to serve them.

In a few words, a CDN caches your images on its globally distributed network of servers. So if a user from Australia requests an image from your website, instead of retrieving that image from your server in Europe, the CDN is going to deliver it from another one, closer to that user in Australia. This cuts down the round trip time needed to load the image.

CSS, JS and HTML

All modern frameworks optimise your code during the production build time (code-splitting, tree-shaking, minification, etc.). What you can do on top of that?

1. Optimise the main HTML document

HTML is the backbone of nearly every web app. When it comes to referencing resources within your HTML document there are a few best practices you should follow. It is recommended to:

• Place CSS references at the top of your HTML document’s header in order to ensure progressive rendering.
• Place JavaScript attributes at the bottom of your HTML body and prefer async script loading. This will prevent any <script> tags from blocking the HTML rendering process.

2. Make sure you only load what you need

Lazy loading components and modules

Angular, React, and VueJS all provide you with lazy-loading features. You only have to split your code properly, according to your own needs and load only the modules that you need, as soon as you really need them. For instance, if you have an e-commerce app, you have to make sure that the Basket module or the Payments module are not loaded when the user is in the home page.

Compression & Caching

In general, for all the assets that are essential to your frontend (images & code) you should apply compression and cache them properly.

File compression will make your app’s assets a bit lighter and decrease the round trip time needed to serve them. One of the most commonly used file compression methods is Gzip, an excellent method for shrinking code chunks, documents, images and audio files.

Brotli is another file compression algorithm, and it’s growing in popularity. This open source algorithm is regularly updated by software engineers from Google and other organisations. It has proven itself to compress files at a much better ratio than other existing methods.

You can enable your preferred compression method on nginx, apache or whichever server you are using, by modifying their configuration files (enabling brotli on nginx or enabling brotli on apache).

When it comes to caching, the most commonly used caching technique (also recommended by Lighthouse) is called Leverage Browser Caching. Again, you can enable it by modifying your server’s configuration files (enabling Leverage Browser Caching).

Summary

When it comes to websites and frontend applications, performance is a huge topic and we should take it seriously.

I hope this article helped you understand and enabled you to tackle some of the most important things that we need to take care of when we want to improve an application’s performance.

For a detailed checklist, make sure that you check out the Front-End-Performance-Checklist.

Cheers! ?

If you’ve ever wondered what Kafka, Heron, real-time streaming, SQS or RabbitMQ are all about, then this article is for you. I’ll discuss in detail why we need a queue for today’s modern software architecture, what are some common technologies used, and how queues are commonly used in the industry. If you enjoy this article, I have a course on scaling distributed systems where I discuss these topics in more detail.

OK, let’s get into it!

A Dummy’s Guide to Queues

First and foremost, why do you need a queue/message broker?

The story of how a queue saved the lemonade stands

Imagine that you are running a lemonade ? stand, and you built out a nifty little web-app that keeps track of how often your clients return to your lemonade stand.

Your web-app has an endpoint, say yourlemonade.com/traffic, and every time you click on a button, the traffic count goes up by 1. Beautiful.

As the traffic to your lemonade stand increases, you click the button more and more. Well, since you’re living in a relatively small neighborhood, you only get 10–20 people per day. Your sales proceed as usual, the web-app handles the traffic just fine, and everything is fine and dandy. Perfect.

Your lemonade stand web-app

The nightmare of a booming business

Now that your lemonade stand has made a name for itself, people from across the city are flocking in to get a taste of your famous lemonade. And on a beautiful Sunday morning, the local news decided to promote your stand, and the traffic EXPLODES.

As you can imagine, the traffic to your lemonade stand increases from 10–20 people per day to 10,000 per day. You’re tapping the traffic button furiously, which in turns triggers a call to yourlemonade.com/traffic, and your web app keeps incrementing the amount of traffic.

Lemonade stand business runs into bottleneck

Unfortunately, your web-app is hosted on an 8-bit, 128MB RAM server in your house garage. With the booming business and increased traffic, your web-app cannot handle the scale of traffic any longer.

Eventually, your server dies. ☠️

With that, your entire web app is brought down. You can’t keep track of traffic anymore. People are rushing in, orders are piling up, yet your web-app is down and you can’t handle any transactions until you can start logging the traffic again.

Traffic brought down your web-app, and business too.

What do you do?

Queue to the rescue

A moment of brilliance strikes you, what if I place a box in front of the counter where each client can just drop a note saying they were there?

Every time a client walks through the door and places an order, you ask them politely to drop their order sheets in a small box placed in front of the payment counter. Outstanding! You have essentially introduced a mechanism to keep track of arrivals while still allowing your business to function as usual.

This is what we call asynchronous processing, and, welcome to the world of queues. ?

Hero to the rescue!

When you start out building software, much like the lemonade stand I mentioned above, it is common for a task to

1. call a service, then
2. wait for the service to finish, and then
3. move on to the next task.

This is what’s called synchronous processing. Asynchronous processing, on the other hand, allows a task to call a service, and move on to the next task while the service processes the request at its own pace. That’s why a queue is a beautiful, elegant way to unblock your systems because it puts a layer in front of your services and allows them to tackle the tasks at their own pace.

If a queue is so powerful, why don’t we just put it in front of everything?

_Image courtesy of [imgflip.com](https://imgflip.com/i/2xylc5" rel="noopener" target="blank" title=")

As anyone who has dabbled in distributed systems can attest to, scaling a distributed system is extremely tricky and complicated. There are a few things to know about queues that might make a queue an unattractive proposition for your system.

Some questions I’d ask before deciding if a queue is the right solution for you:

• Is your service having issues due to high traffic? If it’s not, maybe you should look into what the bottleneck is before jumping into queues. As Donald Knuth famously said, premature optimization is the root of all evil.
• Do you have in-house expertise in managing a queue? Or do you need to potentially hire a team to do it for you? Maintenance costs, like scaling the queue, can skyrocket if you’re not careful. There are services like Amazon SQS (Simple Queueing Service) which offer a managed solution (i.e. you don’t need to maintain anything on your own).
• Is it possible to have duplicate entries in the queue? If so, is that acceptable?
• Do you need to keep a record of all transactions, in case a queue goes down?
• In the case that a queue goes down, does the queue need to be able to replay all the entries? What are your backup options?

There are many more concerns that might be specific to your use case, but hopefully, I’ve made my point that adding a queue isn’t as easy as snapping your fingers.

How Queues Are Used in Modern Architecture

Queues are ubiquitous in today’s modern distributed systems architecture — adopted across various industries for different use cases, and there are more novel use cases every day.

Here are some of the real-world use cases for queues:

Real-time streaming

When MapReduce came around, it was a huge phenomenon in the industry because it allowed mere mortals to process petabytes of data in a reasonable amount of time, anywhere from days to hours. This might seem absurd today when data’s available in almost seconds, but pre-MapReduce, it wasn’t easy to extract usable data from extremely large data sets.

The appetite for data analytics has grown, and we’re now looking at processing data within hours, and sometimes, milliseconds.

To achieve low-latency analytics and performance in a continuous fashion, the concept of real-time streaming was conceived.

A useful example here is to think of ads: ads on Twitter, for example, are shown to millions of people per day. Yet in order to make sure users don’t see the same ads multiple times within a set period of time, Twitter needs to somehow know the last time a user was exposed to a certain ad.

If we had relied on MapReduce to perform this action, it would not even be considered a solution because it’ll take upwards of hours to process all that data. Instead, real-time streaming allows us to process ad impressions as they arrive. This is all made possible because of queues that allow data to be continuously streamed and processed in real time.

Some technologies you’ll often hear about in real-time streaming use cases are Kafka, Kafka streams, Redis, Spark Streaming (which is different from Spark) and so on.

Event-driven architecture

Queues are used as a critical component of an event-driven architecture, or colloquially known as Pub(lisher)-Sub(scriber). Event-driven architecture is, according to Wikipedia:

Event-driven architecture (EDA), is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.

I’d like to think of this as subscribing to a newsletter: as a producer of a newsletter, you know who’s subscribed to your newsletter and who’s not. You write the content, and then you send it to your subscribers.

On the other hand, as a subscriber, you might be subscribed to multiple newsletters, but you don’t know who the other subscribers are. But you don’t really care about that. This is a really nice feature because you can now write software that listens to a bunch of events and only responds to the ones you’re interested in.

RabbitMQ and Amazon SQS (Simple Queuing Service) are some of the technologies often used for these types of use cases.

Distributed, fault-tolerant, scalable infrastructure

Distributed systems are prone to errors, and a queue is one of several ways to increase resiliency in the architecture. In a microservice architecture (or service-oriented architecture), multiple microservices communicate with each other through queues as shared interfaces.

When a microservice fails unexpectedly, a queue is still able to accept messages. This essentially provides a buffer for our microservice to recover. Once the microservice comes back online, it can pick up the messages from the queue and process them again.

Think of it as your mailbox. While you’re out on vacation in Hawaii, the mailperson will still deliver your mail into the mailbox. Once you return from vacation, you can pick up the mail and process them at your leisure.

Thank you for reading! I hope you’ve learned a thing or two about distributed queues from my article. If you enjoyed reading this, please leave a clap, and feel free to join my newsletter here where I write about software and technical interviews!

Resources I Recommend

To further your understanding of queues and various topics mentioned above, I would highly recommend these resources below. Or join my course on scaling distributed systems to learn more about queues :)

• Designing Data-Intensive Applications: Awesome book for learning about scaling distributed systems! Highly recommended.
• Kafka the Guide: I used this book as a reference guide, and enjoyed it for the high-level description.
• Kafka Streams: This is an informative article from Confluent that talks in some high-level detail about Kafka’s implementation of stream processing.
• Elements of Programming Interviews: Great for solving coding problems.
• Cracking The Coding Interview: Great for covering foundational CS coding problems.
• Daily Coding Problem.com: This is a free-to-try website that offers free daily coding problems. You can sign up for interesting daily coding challenges, and you can pay for solutions if you’d like. If you use my referral link (dailycodingproblem.com/zhiachong), you get $10 off!

(FYI, I share more resources on my website: zhiachong.com where I’ve personally tried and tested, and recommend for software engineers of all levels.)

Cheers!

Installing the Ethereum node client on a machine can be a tedious process. There is a simpler way this can be done using a Docker client. This is a guide for running the GETH (Ethereum-Go) node client from inside a Docker container. GETH is the GoLang implementation of the Ethereum protocol. There is an image available to pull from the Docker hub repository that can run the environment.

The GoEthereum website lists the following available images with descriptions.

• ethereum/client-go:latest is the latest develop version of Geth
• ethereum/client-go:stable is the latest stable version of Geth
• ethereum/client-go:{version} is the stable version of Geth at a specific version number
• ethereum/client-go:release-{version} is the latest stable version of Geth at a specific version family

The following ports are opened by default when running from the container.

• 8545 TCP, used by the HTTP based JSON RPC API
• 8546 TCP, used by the WebSocket based JSON RPC API
• 30303 TCP and UDP, used by the P2P protocol running the network
• 30304 UDP, used by the P2P protocol's new peer discovery overlay

The Docker client software must be installed on the machine you are going to run the container from. Containers can only run if you have the Docker client installed. Depending on your operating system, the correct version of the client will be needed.

There are separate versions for Windows, Linux and the MacOS. The container can even be run on a Linux instance running on AWS, like a typical Linux installation. Once the Docker client is installed, the underlying platform doesn’t matter. The commands will be the same for all.

Getting The Image

Open a terminal on Linux or MacOS, or PowerShell command prompt from Windows. In the CLI prompt, type the following command:

docker pull ethereum/client-go

This pulls the Docker image from the hub repository where it was uploaded by the Ethereum developers. Once you have issued this command, the following verbose or similar should be displayed:

I have already pulled the image, so the verbose may look different. When you issue the pull command it will always download the latest image available, which is good practice.

Running The Node

Now you can start the node by issuing the following command:

We want to run the node with the flag options -i and -t to display information from our container. The -p indicates the use of a port number, in this case 30303. Likewise, the command can be run without the flags and it will simply use the default ports and settings from inside the container.

The following information should appear from the terminal.

The INFO line that shows the config reveals what the node client software has installed. The node client is running the latest (as of this posting) version of the Ethereum software which is Constantinople that is a user activated hard fork at block height 7280000.

When running in JSON-RPC API:

Take note that running the option rpcaddr “0.0.0.0” is not secure, since you are opening up your node to all traffic. If your ETH wallet were unlocked, a hacker can get to your node in this way and take your coins. I don’t cover security in this article, but you can read more about that here (securing your GETH node’s RPC ports). Always abide to safe and best practices.

If the node displays the following in the INFO line, there will be a problem:

config=”{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: Engine: ethash}”

The Constantinople: indicates the software was not updated. There is also no line for ConstantinopleFix, which appears in the correct configuration.

Persistent Data

For persistent blockchain data, Docker data volumes should be used with the option -v. The /path/on/host should be replaced with the location you specify. For this the following command must be used:

Checking Node Status

You can check the container’s status using the following command:

docker ps

This will display the Container ID with the image name, status and ports used.

#These are the commands to run from the Docker CLI to run the Ethereum Go node client

#GETTING THE IMAGE

docker pull ethereum/client-go


#RUNNING THE NODE

docker run -it -p 30303:30303 ethereum/client-go

#RUNNING NODE USING API

docker run -it -p 8545:8545 -p 30303:30303 ethereum/client-go --rpc --rpcaddr "0.0.0.0"

#Note, warning about using --rpcaddr "0.0.0.0" in a live environment. It is an insecure way of opening your node.
#There are different ways to secure your ports, but this is one thing to take note of if you plan to use the API.


#PERSISTENT DATA

docker run -it -p 30303:30303 -v /path/on/host:/root/.ethereum ethereum/client-go

Running GETH from a Docker Container

Take note that this does not automatically mine ETH. That is a different process. For getting quick access to the Ethereum blockchain, this is the purpose for running GETH.

For full code source, visit: https://github.com/Play3rZer0/GETHDocker.git

Here I’ll tell you my story how I completed 100 days of code, how I started, how I keep it going, and how I finally finished it.

What I have produced in my 100 days of code

Starting Point

About a year ago I actually heard a lot about the 100 days of code challenge, but I had never thought of doing it. The very sound of one hundred days felt so intimidating for me back then that I was not sure that I could actually finish it.

Then one day I read this article, and after reading so many inspiring stories from people doing 100 days of code on Twitter, I finally decided that the time for me to start was now or never. And I finally started doing my 100 days of code, about 100 days ago from when I am writing this article.

Managing and Planning my work

First things first, I planned on what coding I would do and I decide that I would contribute to the GitHub open-source community. I would spend each day coding for about 1 hour and I would try to keep it to that timeframe — because I have got my me-time too ;)

My main challenge for this was actually finding out what to do every single day. For that, I always prepared two kinds of notes on my phone:

The first type of note was a list of my progress in 100 days of code, each and every day. Not only that, but this note also served as my note on what to do the next day. I always planned on what I was going to do at night. Then the next day I would know what to work on, so I would not waste my time thinking of what to do when I should have been coding.

made it into two notes since there is actually a limit in android Memo App

My second note is was list of what open source things I wanted to make, something like a bucket list or a wish list, but instead it is a code list.

I named this open source wish list

Finding an idea for what to do was also a difficult task to do every day. That’s why I always spent my days reading Medium articles to find inspiration for what I should be exploring.

Since my expertise is in Android mobile application development, I started most of my repositories based on Android applications with Kotlin. Then after I started getting used to it, I finally started making repositories based on other things such as Serverless with go and nodejs, Flutter and Rust.

Nearing the day that I finished my 100 days of code, I also made another note which listed my leftover tasks that usually had something to do with refactoring.

refactor job, everyone loves clean code

Keeping myself going

100 days is quite a long time. You might wonder if there were actually days where I was thinking of quitting.

Yes, there actually were — there have been several days where I doubted myself. Was I actually doing the right thing or was I just wasting my time doing this thing?

But I always kept myself going because of everything I have learned. Living in this Technology Era as a Software Engineer, I must always strive to learn new things and never stop. The moment I stop learning is the moment I stop growing as a Software Engineer. And seeing the stories about how people are finishing 100 days of code and even 360 days of code made me feel challenged since there were so many people out there doing it. If they could do it and even do more, why couldn’t I finish it?

It’s very important to push yourself as much as you’re able. But don’t forget to limit yourself and give yourself a break sometimes. If you reach your limit, you can then call it a day and continue on tomorrow. There were also days when all I did was refactoring and making a new repository. It is always important to keep up, but do not forget to give yourself a break.

And also, the most important part of keeping myself going: Consistency.

Completing my 100 days of code

When I finally finished my 100 days of code, the first two things I felt were feelings of accomplishment and relief.

People may ask me why I did it. I didn’t gain things from it — no profit, no one is looking at my mediocre GitHub repositories, no forks or stars. But of course I learned a lot of things from a technical point of view. Also, most of the people that saw me doing this 100 days of code acknowledged me for being consistent and continuing to do it.

One thing I always believe is that people may betray you, but hard work will not betray you. Keep sharpening yourself. At the end of the day, you will see yourself reaping the good things that you have sown.

Feel free to check out my GitHub! I will be very thankful for any issue opened or any PR. I have produced several android components which are usable and tested.

So then, this ends my story on my first 100 days of code. Where is your story?

“Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” -Jamie Zawinski

For some people, using regular expressions can be a problem. But it doesn’t have to be a problem for you. This article is a full course on Regular Expressions.

1. Introduction

Regular Expressions, or just RegEx, are used in almost all programming languages to define a search pattern that can be used to search for things in a string.

I’ve developed a free, full video course on Scrimba.com to teach the basics of regular expressions.

This article contains the course in written form. But if you would prefer to watch the video version with interactive lessons, you can check it out on Scrimba. The sections in this article correspond to the sections in the Scimba course.

This course follows along with the RegEx curriculum at freeCodeCamp.org. You can check that out for coding challenges and to earn a certificate.

These lessons focus on using RegEx in JavaScript, but the principles apply in many other programming languages you might choose to use. If you don’t already know basic JavaScript, it could be helpful if you cover it a bit first. I also have a basic JavaScript course that you can access on Scrimba and on the freeCodeCamp.org YouTube channel.

So let’s get started! You’ll be saving the day in no time. ?

_From [https://xkcd.com/208/](https://xkcd.com/208/" rel="noopener" target="blank" title=")

2. Using the Test Method

To match parts of strings using RegEx, we need to create patterns that help you to do that matching. We can indicate that something is a RegEx pattern by putting the pattern between slashes /, like so /pattern-we-want-to-match/.

Let’s look at an example:

// We want to check the following sentencelet sentence = "The dog chased the cat."

// and this is the pattern we want to match.let regex = /the/

Notice how we use /the/ to indicate that we are looking for “the” in our sentence.

We can use RegEx test() method to tell if a pattern is present in a string or not.

// String we want to testlet myString = "Hello, World!";

// Pattern we want to findlet myRegex = /Hello/;

// result is now truelet result = myRegex.test(myString);

3. Match Literal Strings

Let’s now find Waldo.

let waldoIsHiding = "Somewhere Waldo is hiding in this text.";let waldoRegex = /Waldo/;

// test() returns true, so result is now also truelet result = waldoRegex.test(waldoIsHiding);

Note that in this example waldoRegex is case sensitive, so if we were to write /waldo/ with a lowercase ‘w’, then our result would be false.

4. Match a Literal String with Different Possibilities

RegEx also has OR operator which is | character.

let petString = "James has a pet cat.";

// We can now try to find if either of the words are in the sentencelet petRegex = /dog|cat|bird|fish/;

let result = petRegex.test(petString);

5. Ignore Case While Matching

So far, we have looked at patterns when the case of the letters mattered. How can we make our RegEx patterns to be case insensitive?

To ignore case we can do it by adding the i flag at the end of a pattern, like so /some-pattern/i.

let myString = "freeCodeCamp";

// We ignore case by using 'i' flaglet fccRegex = /freecodecamp/i;

// result is truelet result = fccRegex.test(myString);

6. Extract Matches

When we want to extract the matched value we can use match() method.

let extractStr = "Extract the word 'coding' from this string.";

let codingRegex = /coding/;

let result = extractStr.match(codingRegex);

console.log(result);

// Terminal will show: // > ["coding"]

7. Find More Than the First Match

Now when we know how to extract one value and it’s also possible to extract multiple values using theg flag

let testStr = "Repeat, Repeat, Repeat";

let ourRegex = /Repeat/g;

testStr.match(ourRegex); // returns ["Repeat", "Repeat", "Repeat"]

We can also combine theg flag with thei flag, to extract multiple matches and ignore casing.

let twinkleStar = "Twinkle, twinkle, little star";

let starRegex = /twinkle/ig;// writing /twinkle/gi would have the same result.

let result = twinkleStar.match(starRegex);

console.log(result);

// Terminal will show: // > ["Twinkle", "twinkle"]

8. Match Anything with Wildcard Period

In RegEx . is a wildcard character that would match anything.

let humStr = "I'll hum a song";

let hugStr = "Bear hug";

// Looks for anything with 3 characters beginning with 'hu'let huRegex = /hu./;

humStr.match(huRegex); // Returns ["hum"]

hugStr.match(huRegex); // Returns ["hug"]

9. Match Single Character with Multiple Possibilities

Matching any character is nice, but what if we want to restrict the matching to a predefined set of characters? We can do by using [] inside our RegEx.

If we have /b[aiu]g/, it means that we can match ‘bag’, ‘big’ and ‘bug’.

If we want to extract all the vowels from a sentence, this is how we can do it using RegEx.

let quoteSample = "Beware of bugs in the above code; I have only proved it correct, not tried it.";

let vowelRegex = /[aeiou]/ig;

let result = quoteSample.match(vowelRegex);

10. Match Letters of the Alphabet

But what if we want to match a range of letters? Sure, let’s do that.

let quoteSample = "The quick brown fox jumps over the lazy dog.";

// We can match all the letters from 'a' to 'z', ignoring casing. let alphabetRegex = /[a-z]/ig;

let result = quoteSample.match(alphabetRegex);

11. Match Numbers and Letters of the Alphabet

Letters are good, but what if we also want numbers?

let quoteSample = "Blueberry 3.141592653s are delicious.";

// match numbers between 2 and 6 (both inclusive), // and letters between 'h' and 's'. let myRegex = /[2-6h-s]/ig;

let result = quoteSample.match(myRegex);

12. Match Single Characters Not Specified

Sometimes it’s easier to specify characters that you don’t want to watch. These are called ‘Negated Characters’ and in RegEx you can do it by using ^.

let quoteSample = "3 blind mice.";

// Match everything that is not a number or a vowel. let myRegex = /[^0-9aeiou]/ig;

let result = quoteSample.match(myRegex);// Returns [" ", "b", "l", "n", "d", " ", "m", "c", "."]

13. Match Characters that Occur One or More Times

If you want to match a characters that occurs one or more times, you can use +.

let difficultSpelling = "Mississippi";

let myRegex = /s+/g;

let result = difficultSpelling.match(myRegex);// Returns ["ss", "ss"]

14. Match Characters that Occur Zero or More Times

There is also a * RegEx quantifier. This one matches even 0 occurrences of a character. Why might this be useful? Most of the time it’s usually in combination with other characters. Let’s look at an example.

let soccerWord = "gooooooooal!";

let gPhrase = "gut feeling";

let oPhrase = "over the moon";

// We are trying to match 'g', 'go', 'goo', 'gooo' and so on. let goRegex = /go*/;

soccerWord.match(goRegex); // Returns ["goooooooo"]

gPhrase.match(goRegex); // Returns ["g"]

oPhrase.match(goRegex); // Returns null

15. Find Characters with Lazy Matching

Sometimes your pattern matches can have more than one outcome. For example, let’s say I’m looking for a pattern in a word titanic and my matched values must begin with a ‘t’ and end with an ‘i’. My possible results are ‘titani’ and ‘ti’.

This is why RegEx has a concepts of ‘Greedy Match’ and ‘Lazy Match’.

Greedy match finds the longest possible match of the string that fits the RegEx pattern, this is a default RegEx match:

let string = "titanic";

let regex = /t[a-z]*i/;

string.match(regex);// Returns ["titani"]

Lazy match finds the shortest possible match of the string that fits the RegEx pattern and to use it we need to use ?:

let string = "titanic";

let regex = /t[a-z]*?i/;

string.match(regex);// Returns ["ti"]

16. Find One or More Criminals in a Hunt

Now let’s have a look at a RegEx challenge. We need to find all the criminals (‘C’) in a crowd. We know that they always stay together and you need to need to write a RegEx that would find them.

let crowd = 'P1P2P3P4P5P6CCCP7P8P9';

let reCriminals = /./; // Change this line

let matchedCriminals = crowd.match(reCriminals);

You can find me walking through the solution in this Scrimba cast.

17. Match Beginning String Patterns

RegEx also allows you to match patterns that are only at the beginning of a string. We’ve already talked about ^ creating a negating set. We can use the same symbol to find a match only at the beginning of a string.

let calAndRicky = "Cal and Ricky both like racing.";

// Match 'Cal' only if it's at the beginning of a string. let calRegex = /^Cal/;

let result = calRegex.test(calAndRicky); // Returns true

let rickyAndCal = "Ricky and Cal both like racing.";

let result = calRegex.test(rickyAndCal); // Returns false

18. Match Ending String Patterns

What about matching a pattern at the end of a string? We can use $ for that.

let caboose = "The last car on a train is the caboose";

// Match 'caboose' if it's at the end of a string.let lastRegex = /caboose$/;

let result = lastRegex.test(caboose); // Returns true

19. Match All Letters and Numbers

Earlier in parts 10 and 11 I showed you how we can match ranges of letters and numbers. If I asked you to write a RegEx that matches all the letters and numbers and ignore their cases you probably would have written something like /[a-z0-9]/gi and that’s exactly right. But it’s a bit too long.

RegEx has something called ‘Shorthand Character Classes’, which is basically a shorthand for common RegEx expression. For matching all letters and numbers we can use \w and we also get underscore _ matched as a bonus.

let quoteSample = "The five boxing wizards jump quickly.";

// Same as /[a-z0-9_]/gi to match a-z (ignore case), 0-9 and _let alphabetRegexV2 = /\w/g;

// The length of all the characters in a string// excluding spaces and the period. let result = quoteSample.match(alphabetRegexV2).length;

// Returns 31

20. Match Everything But Letters and Numbers

If we want to do the opposite and match everything that is not a letter or a number (also exclude underscore _), we can use \W

let quoteSample = "The five boxing wizards jump quickly.";

// Match spaces and the periodlet nonAlphabetRegex = /\W/g;

let result = quoteSample.match(nonAlphabetRegex).length;

// Returns 6

21. Match All Numbers

Ok, what about if you want only numbers? Is there a shorthand character class for that? Sure, it’s \d.

let numString = "Your sandwich will be $5.00";

// Match all the numberslet numRegex = /\d/g;

let result = numString.match(numRegex).length; // Returns 3

22. Match All Non-Numbers

Would you like the opposite and match all the non-numbers? Use \D

let numString = "Your sandwich will be $5.00";

// Match everything that is not a numberlet noNumRegex = /\D/g;

let result = numString.match(noNumRegex).length; // Returns 24

23. Restrict Possible Usernames

So far so good! Well done for making it this far. RegEx can be tricky as it’s not the most easily readable way to code. Let’s now look at a very real-life example and make a username validator. In this case you have 3 requirements:

• If there are numbers, they must be at the end.
• Letters can be lowercase and uppercase.
• At least two characters long. Two-letter names can’t have numbers.

Try to solve this on your own and if you find it difficult or just want to check the answer, check out my solution.

24. Match Whitespace

Can we match all the whitespaces? Of course, we can use a shorthand for that too and it’s \s

let sample = "Whitespace is important in separating words";

// Match all the whitespaceslet countWhiteSpace = /\s/g;

let result = sample.match(countWhiteSpace);

// Returns [" ", " ", " ", " ", " "]

25. Match Non-Whitespace Characters

Can you guess how to match all non-whitespace characters? Well done, it’s \S!

let sample = "Whitespace is important in separating words";

// Match all non-whitespace characterslet countWhiteSpace = /\S/g;

let result = sample.match(countWhiteSpace);

26. Specify Upper and Lower Number of Matches

You can specify the lower and upper number of pattern matches with ‘Quantity Specifiers’. They can be used with {} syntax, for example {3,6}, where 3 is the lower bound and 6 is the upper bound to be matched.

let ohStr = "Ohhh no";

// We want to match 'Oh's that have 3-6 'h' characters in it. let ohRegex = /Oh{3,6} no/;

let result = ohRegex.test(ohStr); // Returns true

27. Specify Only the Lower Number of Matches

When we want to specify only the lower bound, we can do it by omitting the upper bound, for example to match at least three characters we can write {3,}. Notice that we still need a comma, even when we don’t specify the upper limit.

let haStr = "Hazzzzah";

// Match a pattern that contains at least for 'z' characterslet haRegex = /z{4,}/;

let result = haRegex.test(haStr); // Returns true

28. Specify Exact Number of Matches

In the previous section I mentioned that we need a comma in {3,} when we specify only the lower bound. The reason is when you write {3} without a comma, it means that you are looking to match exactly 3 characters.

let timStr = "Timmmmber";

// let timRegex = /Tim{4}ber/;

let result = timRegex.test(timStr); // Returns true

29. Check for All or None

There are times when you might want to specify a possible existence of a character in your pattern. When a letter or a number is optional and we would use ? for that.

// We want to match both British and American English spellings // of the word 'favourite'

let favWord_US = "favorite";let favWord_GB = "favourite";

// We match both 'favorite' and 'favourite' // by specifying that 'u' character is optionallet favRegex = /favou?rite/; // Change this line

let result1 = favRegex.test(favWord_US); // Returns truelet result2 = favRegex.test(favWord_GB); // Returns true

30. Positive and Negative Lookahead

‘Lookaheads’ are patterns that tell your JS to lookahead to check for patterns further along. They are useful when you’re trying to search for multiple patterns in the same strings. There 2 types of lookaheads — positive and negative.

Positive lookahead uses ?= syntax

let quit = "qu";

// We match 'q' only if it has 'u' after it. let quRegex= /q(?=u)/;

quit.match(quRegex); // Returns ["q"]

Negative lookahead uses ?! syntax

let noquit = "qt";

// We match 'q' only if there is no 'u' after it. let qRegex = /q(?!u)/;

noquit.match(qRegex); // Returns ["q"]

31. Reuse Patterns Using Capture Groups

Let’s imagine we need to capture a repeating pattern.

let repeatStr = "regex regex";

// We want to match letters followed by space and then letterslet repeatRegex = /(\w+)\s(\w+)/;

repeatRegex.test(repeatStr); // Returns true

Instead of repeating (\w+) at the end we can tell RegEx to repeat the pattern, by using \1. So the same as above can be written again as:

let repeatStr = "regex regex";

let repeatRegex = /(\w+)\s\1)/;

repeatRegex.test(repeatStr); // Returns true

32. Use Capture Groups to Search and Replace

When we find a match, it’s sometimes handy to replaced it with something else. We can use replace() method for that.

let wrongText = "The sky is silver.";

let silverRegex = /silver/;

wrongText.replace(silverRegex, "blue");

// Returns "The sky is blue."

33. Remove Whitespace from Start and End

Here’s a little challenge for you. Write a RegEx that would remove any whitespace around the string.

let hello = "   Hello, World!  ";

let wsRegex = /change/; // Change this line

let result = hello; // Change this line

If you get stuck or just want to check my solution, feel free to have a look at the Scrimba cast where I solve this challenge.

34. Conclusion

Congratulations! You have finished this course! If you’d like to keep learning more, feel free to checkout this YouTube playlist, that has a lot of JavaScript projects you can create.

Keep learning and thanks for reading!

You are now ready to play regex golf. ?

_From [https://xkcd.com/1313/](https://xkcd.com/1313/" rel="noopener" target="blank" title=")

An overview with monads and Kleisli arrows

A few words on the traditions ?

If you have not written about monads are you even a programmer?

It is a well-known fact that any respectable programmer who blogs about tech must at least once in their life write a tutorial on monads. Most of the times it starts from functors and builds all the way up. The difficult comparisons are drawn here and there with the short snippets of code sprinkled around to demonstrate a couple of applications — all seem completely orthogonal, of course.

The problem is that there is a gigantic conceptual gap between “What is a monad?” and “How is a monad used in programming?”

The main reason for this gap is that people don’t usually think of their programs in such a way that they would need a monad in the first place. If you come from the imperative background — and most of us do — even when you finally go functional, it usually takes a while to see the entire picture and understand the correct way of doing things. We often preach referential transparency and purity. We often have a general idea of what these things mean separately, but it takes some time to piece them together in one coherent concept.

This article is not about monads but instead about writing composable functions and correct programs. The monads appear as the by-product of this goal. The following discussion also, hopefully, will facilitate bridging the aforementioned conceptual gap.

It’s all about that composition ?‍

In programming, the interesting and important problems are usually too complex too to deal with as a whole. Programmers break them up into smaller comprehensible pieces that they solve one-by-one and then bring the solutions to these subproblems into a clear picture. There are many ways of doing it, but there can be clearly defined two schools of thought — declarative and imperative approaches.

The imperative approach views a program as a sequence of computations in time, and the unit of a program is a statement. A statement does something. For example, it can print output to a console, assign a value to a variable, or compute a result.

The declarative approach is global. It cares only about the initial and final state of the system, and a unit of a program is an expression. The expression always evaluates to a value. In general, it’s harder to reason about a statement rather than about an expression because a statement is far too broad and unbounded, while an expression always deterministically evaluates to the same value for all the programs it can potentially appear in.

If you are a functional programmer and you follow a declarative paradigm, you see a program as a composition of functions, and functions are just the expressions. You can think of a composition as just a fusion of two or more functions into one.

If you have a function f that takes an argument of type A and it returns a result of type B and another function g that takes an argument of type B, and it returns a result of type C, you can compose them by passing a result of f to g. What you get is a new function that accepts an argument of type A and produces the result of type C. Do a couple of these, and you get a working program. This is similar to deductive reasoning, which is just a composition of logical steps, that follow from premises to the conclusions.

The problem is that in real programming it’s not so simple, and many functions do not evaluate to the same value all the time even if their arguments do. These functions do network calls, they read from files and databases, they write to them, they process a lot of different data, they print to a console, etc. Functions become context-dependent, and the more context-dependent they are, the more difficult it is to compose them. So if you have to deal with functions where each one of them introduces some of this complexity here and there, you better find a way to compose them.

The ever-lasting problem ?

As I have already mentioned, writing useful code entails dealing with the chaos of the outside world — a problem of handling effects and state. By effect, I mean an effect on the outside world, like writing to a database or printing to a console. Even a simple beaten-to-death HelloWorld program produces an effect.

Many situations are traditionally solved by abandoning the purity of functions, including but not limited to:

• computations that access/modify a state outside of the context of a program.
• computations that may fail or never terminate
• computations whose result might be only known sometime in the future, aka asynchronous computations
• console input and output

As you can imagine, the functions that behave like this are not so easy to compose. Let’s say a function, given some username in the form of an input string, reads from a file, finds the given user, and then passes their last name to the next function for later processing. How do you represent a function like that? String => String? But that would not be entirely correct, as you do get a string and you do return one, but you also do something else in between and it depends on the context — a file system and a file.

In functional programming, we usually encode this information in the function’s return type. We place the result of a computation in a box, so to speak, and our function turns from A =>; B to A => Box[B].

Whatever happens inside this box is implementation-specific. But the definition of a function now describes what it does and allows to handle the function's behavior and compose it, much better.

Let’s look at the situations above and try to come up with a box for every one of them.

Box all the things ?

Disclaimer: In this article, I will be using Scala to express my ideas, as it’s arguably one of the mainstream functional programming languages out there. But the same concepts can be easily translated into any functional programming language with a strong static type system and type constructors (like Haskell and OCaml).

A function that reads but does not modify the external state can be thought of as a function that also accepts this external state as an argument and, given some input parameter, produces a result. An example is reading from a database or config file.

We also supply a run function to materialize a reader and compute a result. The classic use case would be to:

• provide a configuration file
• stack the readers to set up an application
• execute the run function in the end on the instance of the config file.

In the OOP world, a similar approach goes by Dependency Injection.

Functions that carry along the state of a computation accept two arguments — a regular one, that participates in the actual computation, and the state that will be propagated all the way through the composition.

We supply a run function that yields the result which a current writer holds. A typical use case of Writer is to propagate messages and errors during the program execution, and extracts the log alongside the final result. Another use case would be to record the sequences of steps in a multi-threaded environment. Since the result of a computation is tied to a particular log, the messages don’t get intertwined.

A function that never terminates (for example a long running process) is lifted to a bottom type of Nothing. If you expect that your computation might either return a value or run forever, you can model it as a disjoint union of a result type and Nothing. An example would be a stream consumer that processes data indefinitely until some event makes it yield.

A function that might fail can be modeled as a partial function — the one that’s not defined for some values. So we do just that — for some cases return nothing and, for others, an actual value. If you want the information regarding the failure and to interop with Java APIs that throw exceptions, you can carry the information of an error with you in the disjoint union.

Asynchronous computations do not execute on the current call-stack or a main flow of the program. They can be modeled as a function that accepts a handler, or callback. When this handler eventually is called — for example by some other thread or a web server — the result is produced.

ExecutionContext manages the details of the asynchronous execution. On JVM it is a thread-pool, but it does not have to be threads that deal with asynchrony. Function run takes it implicitly because callbacks need to be called asynchronously. Every function that calls run needs to have an implicit ExecutionContext in its signature as well. ExecutionContext also makes recursive asynchronous calls stack-safe because you introduce an asynchronous boundary every time you call a function. As I mentioned earlier, asynchronous computations do not execute on the same call-stack. Pretty neat.

Console input can be modeled as a two-phase process. In the first phase we describe the computation and a result that a console input might produce. In the second phase, we run or interpret this computation. The data type that holds the outcome of this computation is called IO. So our function takes a singleton and produces the result inside of an IO.

Notice, since I mentioned that we describe the computation first, we pass call-by-name parameters =>; A. They execute only when we need them to.
Console output can be modeled through IO as well, with our run function producing a singleton type of Unit.

So, now what ? ?

We, of course, implemented all the boxes with a type parameter to account for variability in types. We transform, or map, from some stuff to other stuff by supplying a function. A mapping between a category of some things to a category of other things is called a functor.

Functors are cool because they allow us to transform stuff inside, while preserving the structure of the original category, without messing things up. When using a functor, following the functor laws proves that things work as expected. It will get clear later in the article why these laws in particular.

Let’s define a map method that does transformation for each of the derived data types:

Notice that here we have defined a function pure that permits us to lift a pure computation into an asynchronous value.

Cool, now we can map things inside of the boxes. The problem is — it’s not useful because, although we can sequence computations within a functor, we can’t compose functor-producing functions:

F1: A -> Functor[B] ==> F2: A -> Functor[B] ==> F3: A -> Functor[B]

Each of F1, F2, and F3 may do something completely different. We need to account for that, we need to compose them. Fortunately, there is an excellent way of doing this.

Oh no, it’s that guy again! ?

Ok, I need to write a function that composes the functions for each of the functors in A => Functor[B]. The mathematical definition of composition is:

If A =>; B and B => C then A => C

So in our case:

If A => Functor[B] and B => Functor[C] then A => Functor[C]

Let’s start with a reader. Again, just follow the types:

We defined composition as andThen . We also defined pure , which lifts a value into a functor.

Composition in any category follows two simple laws.

1. It is associative:

2. There exists such a function, called identity, that, when composed with any function from left or right, produces that function again:

You can take a pen and a piece of paper and try to draw these two laws. Substituting entities with circles and connections between them as arrows, you can visually prove to yourself that this is the case. Remember functor laws earlier? It’s the same thing. These laws establish the composability in every category.

As programmers, we mostly deal with a category of sets — objects are sets or types, and arrows are functions. Not all mathematical structures need to have an identity, but category certainly does.

Identity, for example, can be used to show whether two objects, “sets,” are isomorphic, or equal. It can also provide guarantees in certain instances as we will see later in the article.

Category only has two properties — simple enough.

A functor that participates in A => Functor[B] and follows these composition laws, and hence composes for all the objects in the same category is not a burrito. It’s a monad.

Accordingly, the functions that we try to compose are actually A => Monad[B] . A wrapper around them, a category that is naturally associated with a Monad[B], is called a Kleisli category. A => Monad[B] or Kleisli arrows is just a way to compose these sort of functions, nothing more.

Kleisli has the same objects as the original category but arrows between a and b in Kleisli correspond to the arrows between a and Fb, where F is a functor.

Compose all the things! ?

We replace Java-like andThen with an arrow >==> . This is called a fish operator because it looks like a fish ?. We also define a function flatMap that, given a Monad[A] and A => Monad[B], produces A =&gt; Monad[B]. This will make implementing arrows easier:

Monoids

For a writer to be a monad, a second type should be composable too, and it’s composable only if it’s a monoid. Something is a monoid only if it can be associatively combined and has an empty element, which is an identity element.

For example, integers that sum up are a monoid with an identity element of 0. Strings that concat are a monoid with identity element of an empty string. Sets that union are a monoid with an identity element of an empty set. Sets that intersect form a semigroup and not a monoid. Intersecting a non-empty set with an empty one produces an empty set. You see why identity is useful?

Every other monad is easy to implement:

We will go into detail why IO looks like this and have a discussion about Free probably in another article.

When to use which? ?

Kleisli and Monad are two sides of the same coin. Many functional languages support them natively, but for Scala, at least in the current version 2.12.8, you can get them from the libraries like Cats and Scalaz. They have type classes for Kleisli and Monad: Kleisli[F[_], A, B] and Monad[A] respectively.

Monads are better at expressing the sequencing of the computations that happen within some context. In Scala, we do this contextual sequencing usually by utilizing for comprehensions.

Fun fact: If you compose Kleisli arrows for IO monad, you will get a description of your computer program. Your computer program is essentially one gigantic Kleisli arrow, with some input and output of Unit that acts as a description, and a runtime environment that executes this program works as an interpreter.

So every program, by default, has an IO context. If you have a function that produces an error, it creates a context of Option or Either. So every subsequent function should have a signature of A => Option[A] or A => Either[A, B]. Within an IO program it’s A => IO[Option[A]] and A => IO[Either[A, B]]. You decide when to collapse this context or nest it even further. Monad transformers can help with the sequencing of the nested contexts, but that is material for another article.

Asynchronous computations are only sequenced with the help of monads because monads explicitly solve the problems of synchronization and ordering in time. If you use Future combinators, for example, it is within a monadic context.

Kleisli is better when the arrow combinator is more suitable. For example, we can have a bunch of effectful or impure functions, and we can fuse them without wrapping the result into IO. You can also create a bunch of individual programs and combine them into one Kleisli in the end and run if you want, of course.

Reader[A] is better expressed with Kleisli than with monadic compositions because we can easily compose small local Kleisli arrows into a Kleisli arrow that represents our program’s global configuration. The large Kleisli arrow depends on some environment, let’s say a configuration file for production and development. Then we can run this at the very end, and configure the entire app.

This approach mimics the concept of dependency injection. Here we demonstrate KleisliIO, an effectful Kleisli from ZIO that performs a reader functionality to configure the application (error type omitted to save some space):

End ?

Whew, that was a blast. I hope you enjoyed this article and now understand what’s going a little bit better :).

Here are some useful links to learn more about Kleisli and composition:

• www.cse.chalmers.se/~rjmh/Papers/arrows.pdf
• https://www.youtube.com/watch?v=qL6Viix3npA