DEV Community: Jiří Rejman

The DevOps handbook - summary

Jiří Rejman — Tue, 15 Feb 2022 10:04:38 +0000

DevOps handbook is one of the most important DevOps books on the market. It combines the most important DevOps ideas, examples from known companies, and best practices. It does not have any code so it is an ideal book for non-technical readers that would like to know what their teams are talking about. Bellow, you find a summary with the ideas that stick with me the most.

Flow and Feedback

The first thing we want to accomplish in DevOps is to have fast feedback on our work. The first frontier, before the ultimate testing on production, is a set of well-written fast tests. Those tests should be able to run in parallel and they should be run on each commit automatically. Tests that are not run are useless, and the only way to enforce running those tests is using automation. This allows us to have basic confidence in our code and the fast feedback provided by fast pipeline should not break the flow. The testing should be not limited to unit tests but it can (and should) test also security, integration, and other aspects of our application. Important is to run different tests on different occasions (run slow tests less often) to not break the developer`s flow.

...a small number of reliable, automated tests are almost always preferable over a large number of manual or unreliable automated tests.

Get it out!

You will never test everything. In production, someone will always do something you do not expect, try to hack you, or will not use your shiny feature at all. And the only way to test this is to go to production as fast as possible. This is the only way to test (almost) every possible scenario and see the outcomes. Of course, going fast to production have its dangers but we can mitigate them using tools such as shadow releases, canary testing, or blue-green release pattern. With frequent releases, we generally get smaller release sizes which is associated with a higher deployment success rate.

...when we increase our deployment batch size, our change success rates go down and our incident counts and MTTR go up—the opposite of the outcomes we want.

Observer and learn

If we put our code into production we need to have a way to observe the code running. Other than standard metrics such as CPU and Memory usage, percentage of a cache hit, and other technical measures we should also have business metrics available. Does our new feature that is promoted everywhere have poor usage? It might be caused by a technical issue such as poor performance or distorted render on some browsers. The second case can be that we simply build the wrong thing. Both outcomes are valuable for us developers so we should have access to those metrics to be able to learn from them.

...business metrics create context for our infrastructure metrics, enabling Development and Operations to better work together toward common goals.

Involve everyone

One of the most important lessons for me was how important is to make everyone more exposed to other team's problems. In the end, we all work toward a common goal. By being more exposed to problems of developers, testers, or ops we can often find better solutions to problems, fix the problems earlier, cheaper and build empathy for other teams.

...how to make Dev work more visible to Operations. To accomplish this, we explored three broad strategies, including creating self-service capabilities to enable developers in service teams to be productive, embedding Ops engineers into the service teams, and assigning Ops liaisons to the service teams when embedding Ops engineers is not possible.

Conclusion

The DevOps handbook is one of the technical books that will fill your head with ideas. It will not teach you how to create an ideal pipeline, nor it will give you the answers to all problems but it will tickle those parts of your brain that know that our job can be done better.

Our call to action is this: no matter what role you play in your organization, start finding people around you who want to change how work is performed. Show this book to others and create a coalition of like-minded thinkers to break out of the downward spiral.

If you like the post, consider subscribing to my substack

how to start with devOps?

Jiří Rejman — Tue, 25 Jan 2022 15:56:04 +0000

The internet is filled with tutorials for technologies and road maps with the premise of learning DevOps but in my opinion, the DevOps is less about technology and more about processes and mindset.

What is DevOps?

To start with DevOps we first need to know what DevOps is. Amazon defines DevOps as a

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity

This is a pretty good summary but see that it does not mention any particular technology. It is because it does not matter what technologies you use (but it can help), DevOps is about delivering high quality at high velocity. You don't need to use AWS, Kubernetes, and state of the art pipeline to do DevOps. The only requirement for DevOps is to be focused on the ability to deliver great products with high velocity. The tools and practices we use are just things that proved themselves to be the most efficient way to accomplish this.

So how to start with DevOps?

To start with DevOps start to think not about which technology to use but rather how to enable faster delivery and more quality. Take your project and look where most of the issues are. Is it non-existing tests? Start there. Do you have old branches that are a pain to merge? Introduce short-lived branches. Do you have a problem with ops being slow to respond? Try to embed them into your daily work. The most important thing is to know why. Will it save any money? Will It make any money? With answers to these questions, you will have more support from the managers to grant you the time and resources needed to start with DevOps, the technologies will follow.

If you like this article, subscribe to me on substack to get notified when next article arrive.

Habits to build

Jiří Rejman — Sun, 16 Jan 2022 18:32:41 +0000

The topic of habits is mentioned in almost every self-help book. And it is no wonder why. If I look back at what helped me last year it was just a few habits that had a tremendous impact on me. And the same seems to be true for my work as a developer.

Note-taking

For me, note-taking was an ad hoc thing that was painful, but over time I managed to get better at it and even be able to have a system. The more projects, places to do things, and how to you will have the more you appreciate good note-taking systems. You will stop to ask your colleagues for that link to documentation and googling how to connect to that strange DB your backend is using, you just open your notes and there it will be.
I use zettelkatsen combined with a second brain system but there are endless options.

Commit clean up

Before each commit, I go through the diff, file after file, and fix all the small issues I found. Forgotten console.logs, commented code you name it I take care of this mess before it will go public. Doing this allows your coworkers to focus on important things during the code review, instead of focusing on where you left commented code.

Reading

We work in an ever-changing environment, with new frameworks, libraries, languages... Regular reading will allow you to have an overview of the emerging technologies. Pick a few quality sources (Twitter accounts, newsletters...) and regularly check them. But have in mind that you do not need to learn everything you will read about.

Overcoming Resistance

Resistance is a concept from Steven Pressfield and his book war of art. For me regularly reminding myself that the reason why I want to "just check Twitter before I start to code that functionality" is just because I do not want to fight the resistance.

Automate

You will break all your habits. Even the most bake in. So why not automate them? Running test before commit? Automate it, linting your code? The same. We have tools for all of this so take advantage of them and make your life easier.

Conclusion

Those are the most important habits that help me with my work. There is nothing magical about them and building them hurts, but working without them would hurt me much more.

If you like this article follow me here or on twitter https://twitter.com/rejmank1. Thanks!

Learning tech stuff

Jiří Rejman — Mon, 10 Jan 2022 18:06:11 +0000

I was facing a problem. I need to learn Kubernetes... and I need to do it fast. Fortunately, I managed to learn a few other technologies so far but this time I wanted to make the learning as efficient as possible. To achieve this I connected several Ideas I get from reading about effective learning, together with my experience, and created a system that allowed me to get all my tasks done and be able to speak about Kubernetes in our internal conference in three months.

Mnemonic medium

The biggest influence on me so far had Andy Matuschak and Michael Nielsen with their article about mnemonic medium . It is an idea of creating books combined with spaced repetition, which kind of forces the reader to engage with content repeatedly and think about it. This is a great way to remember facts and think about the material in a long run. The biggest problem is to create good prompts, fortunately, there is a great long read about this topic which helped me a lot.

Zettelkatsen

I discovered the zettelkatsen from Eliska Sestakova and her awesome blog (CZ only) and the biggest treasure of this system for me is the connection. I write notes about the topic that I am learning using short paragraphs and linking the paragraphs together to create a graph connecting the ideas across the document. Reading this feels more like a gliding between topics and exploring rather than a sequential flow of information.

Accelerated learning

I stumbled across accelerated learning through this article by Cedric Chin. The article gave me a pretty good sense of how knowledge learning differs from skills learning. We often hear that the best way to learn is using spaced repetition, this is great for knowledge but we have no clue if this works the same way for skills.

...spaced repetition has mostly been shown to work for knowledge retention, not skill retention; second, in general, studies tell us that skills tend to be retained for a longer period than knowledge. The authors note that we currently lack a good empirical base for skill retention.

The article (book) offers a way to better teach skills. It is not that revolutionary but I think it is often underused. The article advises to create a set of hard simulations based on input from domain experts and letting the learners practice. The task for me should be an exciting quest that sends me on the learning journey. The only problem with quests is that they are often not that easy.

Together

Putting those three concepts together I created an article about Kubernetes which started with a difficult task. The article contained paragraphs with a description of a single concept, as a pod, accompanied with a few flashcards with the most important concepts, names, etc. Those paragraphs were interconnected. Learning using this format felt explorative. I usually started with the task and used the article as a guide through the exercise. During the tasks I did a ton of notes and since I am the one creating the article for myself, correcting mistakes I found out. I use the spaced repetition "cards" in the evening as a habit. The evening practice takes a few minutes but it often showed me where my blind spots were. The process of learning was more difficult than just reading a book but the amount of information I really understand was beyond comparable.

Where to continue?

The last thing that remains to explore is if using the format itself is useful or the learning is in the creation of the whole workbook. I will definitely explore the area and will be back, either with publishing one of my learning workbooks or with some results on a quinea pig. To get notified when this happens subscribe to my substack.e results on a quinea pig. To get notified when this happens subscribe to my articles or to my twitter.

Why I started to fall in love with go

Jiří Rejman — Tue, 23 Mar 2021 16:47:31 +0000

I am a JavaScript developer by soul. In school, I have had java classes and before the first job I played with some python but since I switched to JavaScript I newer looked back. I could build a frontend in it and after I learned node even server-side things. The language has its shortcomings and quirks but overall it is a nice, simple language that gives you a lot of power at your fingertips with a huge ecosystem of libraries. But I felt that I need to have a second tool under my belt so recently I started to search for my second language.

What do I want from a second language?

The reason I wanted to learn a second language, other than a pure curiosity, was that I want to have something that can be used for some heavy lifting. I also wanted to learn a language that is using static typing to see the benefits and drawbacks myself. A nice benefit would be if there are some jobs using the language.

What I tried so far?

I tried F# and Rust so far but non of them hook me for a long time.

F# is a great functional language. In my opinion, there is no better place to learn typed functional programming. After some tutorials and exercises, I hit the ecosystem wall. I just was not willing to learn about the ecosystem. This article summarizes my experience pretty well. If you add that the F# community seems to prefer frameworks over libraries, it was something that I simply did not have enough grit for.

Rust was a little bit different. I finished the rustlings but I was not able to write anything. It was just too many new concepts for me to learn. The power of language is huge, immutability first, and support for functional programming is also great but for someone who never worked with typed language much, it was just too hard.

Just to be clear, those objections against languages say more about me than about languages. I would be more than happy to use them in my job. But for my side projects and as a second language I just did not have the grit.

Go

Then I read an older article by sw-samuraj about his experience using GO in his job. He mentioned many positive aspects and one of them was that he felt using go was similar to writing code in clojure. This got my attention. I explored the language a little bit and after a week I spend learning to Go I am hooked.

The main reason I am excited is simplicity. I was able to start coding fast. The language itself is small and has a really good standard library. Standard library have you covered for most of the day-to-day tasks from writing basic server to CSV parsing. The only thing I am missing is map, filter, and reduce. But there are libraries that can help with this and with the generics coming I expect a lot of FP libraries to pop up.

The type system was easy to learn. It kind of surprised me after my experience with rust where most of my learning was how to do the types correctly. This might change with the generics but I would not expect a huge rise in complexity.

Goroutines is another nice thing. I did not use them much so far but they influenced clojure core.async library and also is one of the selling points of language so I expect them to be great.

With Go, you have enough speed that you can tackle almost anything from image processing to machine learning. This makes go universal language and a big plus for me.

Conclusion

So far I have had a pretty good experience with go. I was amazed at how fast I created some simple scripts. The learning curve is smooth and the community and resources are great. It is hard not to fall in love with go.

The usefulness of currying

Jiří Rejman — Sat, 20 Feb 2021 17:06:24 +0000

In the last article about pipe I wrote that while using a pipe to compose functions, those functions start to look like lego pieces. But what would you do if the pieces don't fit together? In a functional toolbox, there is a tool for that, it is called pipe and it is something that every functional programmer should have under their belt.

What is curry?

Currying allows us to create a new function by providing some parameters for that function ahead of time. Let me show you this on some code:

import { curry } from "ramda";

// we have one general function that counts the discount
const countDiscound = curry((discountInPercent, originalPrice) => {
  originalPrice * ((100 - discountInPercent) / 100);
});
// Here we have single purpose function that we want to use somwhere in program
const countSeventyPercentDiscount = (originalPrice) => 0.75 * originalPrice;

// There is easier way to create the specific functions, because we curried general
// function we can use it to create the same functions as above, while using the
// original multipurpose function
const countSeventyPercentDiscount = countDiscound(70);
const countSeventyPercentDiscount = countDiscound(80);

You can see the difference yourself, the functions we created with curry use less code, do not repeat the same logic and thus it obey the DRY (don't repeat yourself) principle.

Specific functions

Curry allows us to create single-purpose functions from generic functions.

// parse imported from date-fns/fp is already curied
import { parse } from "date-fns/fp";

// we create new function that help us parse some internal date string
// we can now use it in the rest of our program
const parseInternalTimeString = parse(new Date(), "h:mmaa");

const parsedInternal = parseInternalTimeString("06:30AM"); // 2021-02-19T05:30:00.000Z

Other than saving some lines of code, this approach also has another, not so obvious benefit, it increases readability. If you encounter the parse function used like this:

const parsedDate = parse(new Date(), "h:mmaa", "06:30AM");

It does not exactly tell you that the parsed string is some company internal format and it also reveals the detail you don't necessarily need to know, the format for parsing. Every time you want to parse the internal time string you need to remember or search for parse string. On the other hand, using the curried function the name itself reveal that you can use it on internal time strings, and to use it you do not need to know anything. This technique is beneficial if you do domain-driven design.
Currying has also a huge benefit for composition. Recently I needed to parse the date that was included in the filename I used composition as follows:

import { parse } from "date-fns/fp";
import { split, prop, pipe } from "ramda";

const getDateFromFileName = pipe(
  split(".csv"),
  prop(0),
  parse(new Date(), "h:mmaa")
);

getDateFromFileName("06:30AM.csv"); // 2021-02-19T05:30:00.000Z

Curry, in this case, allowed me to create a simple function that parses the filename. All three functions benefit from curry, without curry we could not use Pipe and without pipe our code would be much less readable. It would look like this:

import {parse} from 'date-fns/fp'
import {split, prop, pipe} from 'ramda'

const getDateFromFileName = (filename) => {
    const parse(new Date(), 'h:mmaa', prop(0, split('.csv', filename)))
}
getDateFromFileName('06:30AM.csv') // 2021-02-19T05:30:00.000Z

If you have at least a little bit of experience with pipe, you red the first function without any problems. The second version on the other hand takes at least a little bit of effort and switches reading order from left to right to right to left.

How does curry work?

When I was learning about closures, understanding how curry works internally was really helpful for me. So let's take a look at one, naive implementation.

// this implementation requires the first argument in the time we curry it
const curryOne = (func, parameter) => {
  // the function returns new function, it remembers the first parameter using closure
  return (secondParam) => {
    // after we call the returned function, it calls the original function with all
    // parameterers and return the result
    return func(parameter, secondParam);
  };
};

function add(a, b) {
  return a + b;
}

const addFive = curryOne(add, 5);

addFive(6); // 11

This implementation of curryOne (it can help to curry only one parameter) works by using closure to remember the first parameter. And this is all the magic that closures have. Although this code is a nice example of using closure do not use it in production or as your curing solution, rather use ramda.

What if the parameters are in the wrong order?

There is often the situation that you want to curry some function but the parameters are in the wrong order. Luckily we have a solution for this in our functional toolbox. The first one is a flip function. What flip does is that it takes a function, switches parameters order, and returns the function.

import { flip } from "ramda";
const subtract = (a, b) => a - b;

R.pipe(
  getSomeNumber,
  // now we want to substract 10 from number we got
  // we first flip the parameters order and then curry the function
  R.curry(R.flip(subtract))(10)
);

If we have already curried function we can use __ function t*o skip some of the parameters*. For example, we can use ramda map function and create a function that accepts a function and apply it to predefined data.

import { __, map } from "ramda";

const applyFunctionOnArrayOfNumbers = map(__, [1, 2, 3, 4]);

Partial

Another function that allows us to do a similar thing as curry in ramda is partial. The difference between currying and partial application is subtle and rather academic. In ramda the difference is that using partial you can provide an array of parameters to a function, instead of supplying the parameters as one after another. If you are interested in the differences between curry and apply I recommend this article from 2ality.com

import { partial } from "ramda";

const addThree = (a, b, c) => a + b + c;

const addToThree = partial(addThree, [1, 2]);

addToTrhee(4); // 7

Conclusion

Currying is one of the most practical things that functional programming can offer you. It gives you the flexibility to create small single-purpose functions, allows you to create better compositions, and profit from the functional paradigm even more. Combined with pipe you will be amazed at the beauty your fingers will produce.

Why use pipe?

Jiří Rejman — Mon, 15 Feb 2021 20:01:47 +0000

I would describe pipe as a magic door into functional programming. At the first sight, I didn't get the pipe. It seemed so obsolete, but since I started to write them all other functional concepts suddenly started to clicking together. So how to start opening the doors into the ~~Narnia~~ functional programming world?

What does pipe do?

The pipe is just a function that creates other functions by composing them. Okay, this didn't help. Let me try it again. Imagine that you have three pure functions. And you want to call them all, in sequence on one piece of data. Something like this:

import { splitData, fromatItems, filterItems } from "./myModule";

function format1(data) {
  return filterItems(formatItems(splitData(data)));
}

This is called composition and it is a cornerstone of functional programming. But functional toolkit has a way to write this nicer the mighty pipe.

import { pipe } from "ramda";
import { splitData, fromatItems, filterItems } from "./myModule";

const formatWithPipe = pipe(splitData, formatItems, filterItems);

const data = formatWithPipe(data);

The pipe just takes all the functions and spits out a new function. When you call the new function with data those data go through all functions in pipe.

The readability benefit

Let's look at the code we have above once again, try to read all three functions.

import { splitData, fromatItems, filterItems } from "./myModule";

function format1(data) {
  return filterItems(formatItems(splitData(data)));
}

function format2(data) {
  const splited = splitData(data);
  const fomatedItems = formatItems(splited);
  return filterItems(fomatedItems);
}

const format3 = pipe(splitData, formatItems, filterItems);

If you examine the first function it seems ok, this is an example of nice composition, but it has one problem, you need to read it from right to left. We are not used to reading out programs right to left so it breaks the reading flow.
The second version does not force you to switch the reading order but it is lengthy and the reading order is zig-zag so not ideal either.
At first sight, the pipe does not help that much but with time you will simply read the function from the top to bottom and immediately get an idea about what the function does. Reading flow, in this case, is the same as with other code and the function is nicely compact.
TIP: There is often a question about how to do logging inside pipe. Although we should strive to have our pipes pure during the development the console.log is one of the most helpful things. So how to do it? Just use R.tap, it allows you to log anywhere in your pipe. The other option is to create a log function, where you can specify other parameters like what to print before data.

import {pipe, curry} from 'ramda'
import {splitData, fromatItems, filterItems} from "./myModule"

const _log = curry((message, value) => {
    console.log(message, value)
})

const format3 = pipe(
    splitData,
    _log('some string'),
    formatItems,
    R.tap(console.log) // logs the data after formatItems
    filterItems
)

const data = format3(data)

A better understanding of functional tools

Other than looking good and increasing readability, the pipe has other benefits that are not apparent at the first sight. The pipe helps you understand the purpose of other functional concepts like curry, flip, map, etc. When I started to use pipe all the other functions started to make sense. With pipe functions become lego pieces that from time to time do not fit together. Functional tools often help you transform your legos that it fits together nicely.

Pipe pushes you to write better functions

Another benefit of piping is that it pushes you to write better functions. You will find out that your functions suddenly have fewer inputs, they are pure and when you start to write a bigger function, you start to think about how to split it so it would compose nicely.

Conclusion

In the beginning, pipe seems like just syntactic sugar with no value-added. But the readability benefit and the way it pushes you to write your code start to be apparent as soon as you write a few of them. Try it out, once you get used to it you will never look back.

If you like this post check out other posts on my website.

Why I use date-fns

Jiří Rejman — Fri, 05 Feb 2021 14:25:25 +0000

For a long time, momentjs was almost a standard for working with dates in JavaScript. It had several drawbacks such as size, no support for tree shaking, mutations... and it was also abandoned recently. So the natural question arose, what to use instead? For me, the answer is clear date-fns.

Why not use native functions?

You can be almost sure that modern JavaScript date object have all you need in order to work with dates. There were always several drawbacks for me. For example, subtract the specified number of days from date looks like this in native JS and date-fns:

// Native JavaScript
new Date(new Date().getTime() - 1000 * 60 * 60 * 24 * 7);
// date-fns
import subDays from 'date-fns/subDays';
subDays(new Date(), 7);

When I encounter a native version in the code I need to stop and think about what it actually does. Looking at date-fns version I just know what the code does.
Another factor is that in order to work with dates I often need to use regex to parse the date from string or recount the number of days to milliseconds which is both things that I can easily make mistake in, or forget to test some edge cases.

Functional

Date-fns have great support for functional programming. In module 'date-fns/fp' you can find all functions already curried and with switched order of parameters. If you don't know what currying is no worries, I am preparing a series about ramda and FP, or check out functional light javaScript. This makes usage with Ramda or Lodash breeze.
Another big benefit is that all functions in date-fns are pure. In this case, the main benefit of purity is that if I supply the function date, the date itself remains unchanged and a new date is returned instead.
Just look at the beauty:

import * as R from 'ramda'
import {addYears, format} from 'date-fns/fp'

// we create new function that add five years and format the output
const addFiveYearsAndFormat = R.pipe(
  addYears(5),
  format('y-M-dd')
)

const date = new Date()
// we can call the function anywhere with any date object
addFiveYearsAndFormat(date) // '2026-2-04'
// addYears is pure function so it did not change the input
date.getFullYear() // 2021

Great documentation and completeness

The documentation for date-fns is great. For each function, you will find a bunch of examples, what the function returns and what exceptions it can throw. The only thing that I miss is some kind of playground similar to Ramda documentation.
That level of documentation is even more impressive if you take into account how many functions does the library provides. So far I did not encounter anything that the library does not have. From parsing to working with ranges, comparing to formatting the date-fns have it all.
Great is also support for tree shaking that can save you a bunch of kilobytes from your bundle.

Conclusion

Date-fns is a great library. If you need to work with dates this library provides everything you need and a bunch of extra things on top. If you are still not convinced check out the documentation or this awesome repository that compares other options for working with dates.

The value of feedback

Jiří Rejman — Wed, 03 Feb 2021 18:20:38 +0000

Writing software is a complex job full of learning. We learn not only new technologies but also domains and avoiding disasters in production. From my experience, the best learning tool is fast feedback. Embracing it in all aspects of your development process will make your progress skyrocket.

Feedback as a tool

Feedback is a tool to make your output and you better. If you submit your code to a colleague, to do a code review he will point out the mistakes you did and, in the best scenario, he will help you understand the issues and fix your code. Both of you are gaining from this situation. Bad code was not pushed to production, you learned how to write better programs and next time there will be a third of the issues. If you would not get the feedback you might to found out the issues later either as a bug or as technical debt and the cost of learning will be much higher.

Feedback and current development practices

If you look at the current trends in software development, you can see that a lot of what is an everyday practice for us is some form of getting fast feedback. For example, writing tests. Without them, it is like playing a musical instrument without hearing it. You are almost sure that you are playing the right notes, but you cannot be sure. There is no better way to get fast feedback than by running a suite of good tests (okay, maybe Clojure and its repl driven development). Continues integration and continuous delivery allow us to ship software faster to get feedback from users and real-life situations as fast as possible.

The problem with receiving feedback

Receive and accept feedback is tough. Ego, fear, and expectations get in the way of receiving it. But I have some good news for you, as with everything you get better at it. You learn how to separate yourself from the feedback and take what is going to move you forward. For me, there were a few books that helped me with this namely mindset by Dr. Carol Dweck and Creativity inc. by Ed Catmull. Giving someone feedback is maybe an even bigger problem but I do not feel like having enough experience to write about it.

Conclusion

Getting feedback is an often big step out of your comfort zone. You may show someone something terrible but if you don't put your skin in the game it stays terrible. If you get feedback, you have the opportunity to make it better.

If you like this article follow me on Twitter https://twitter.com/rejmank1

Fundamentals of software architecture - review

Jiří Rejman — Wed, 27 Jan 2021 18:16:43 +0000

One of my resolutions for 2021 is to get more into software architecture. As an entry point for this topic, I chose fundamentals of software architecture by Mark Richards and Neal Ford. It was a great starting point and in this review, I will tell you why.

The great

The bread and butter of this book is a middle part that describes eight architecture styles. Each one is described in enough detail but without any unnecessary clutter. Great are practical examples that point out the weaknesses and strengths of each described architecture. The architecture styles also come with a handy table that can serve as a quick overview of the strengths and weaknesses of each architecture style. We will see how quickly will this part get old but until that, it will be a go-to resource for me when doing initial research on how to approach a problem from an architectural point of view.

The mind-bending

The book, in the first part, goes over basic architectural knowledge such as modularity, coupling, components... What was completely new for me was the introduction of formal methods of evaluating architecture characteristics. This part of the book is on my bucket list to read again in the hope to understand it better than during the first read. This part was also the hardest to read but for me, that is always a good sign of learning, so be prepared and take your time, it is worth it.

The not so good

The last part of the book focuses mainly on softer parts of the architect job. There are good parts (I enjoyed the risk analysis part and Architecture decision records) but overall I had a feeling that this is something "extra". If this is what you would like to get from architecture book, look somewhere else.

The Conclusion

The fundamentals of software architecture was a great introduction to the topic of software architecture. The technical parts are excellent with great examples. The book is worthy of your time, you get a great overview of the discipline and a great handbook for everything architecture related.

JavaScript learning resources

Jiří Rejman — Thu, 21 Jan 2021 16:11:35 +0000

Javascript learning resources

This article is a compilation of resources I would use again while learning a node.js or react. It contains everything from free articles, paid courses to books. There are not sorted in any particular order.

33 JS concepts

What is great about this collection is that it sums up all the things that you should be at least familiar with while using JavaScript. I would focus mostly on the understanding call stack, function scope, block scope, lexical scope, Message Queue, and Event loop, closures, map, reduce filter.

Node best practices

Another git collection. This time of best NodeJS practices. I cannot say that I agree with everything on 100% but it is a great starting point when you try to do your next project the right way.

Frontend masters

This is an awesome company producing awesome content. The price is a little higher than usual but it is worth every penny. The courses are recorded lections from practitioners and the quality of content is high. I would recommend courses from Kyle Simpson, Scott Moss, and Brian Londsdorf, but in the end, I did not encountered a bad course so pick what you are interested in.

You don't know JavaScript

If you want to go deep in JavaScript this is a go-to source for me. What I like about this series is that id does not leave out the quirky parts of JavaScript (looking at you JavaScript the good parts!) but forces you to understand them. Kyle Simpson has the unusual talent to describe difficult topics approachable.

Functional light JS

Another book by Kyle Simpson. This time introduction to functional programming focusing on the important topics that you can apply immediately. I recommend pairing this book with his course on the same topic from frontend masters.

The road to React

I learned to react to this eBook. I remember it was a really good introduction. I build some basic react app alongside this book as a reference source.

Other

Epic react dev

If I would like to go deeper in React or need to refresh it I would grab the epic react dev from Kent C. Dodds. I received a pretty good impression from everyone who bought the course, even senior react devs so this would be the choice for me.

If you liked this article follow me on twitter https://twitter.com/rejmank1

The beauty of pure functions

Jiří Rejman — Sat, 16 Jan 2021 17:15:37 +0000

Starting with functional programming is hard. There is a ton of new concepts to learn, new terms, and sometimes even a new language. But there is one simple concept that can make your programs better immediately. Pure functions. These functions are easy to understand, easy to write but they will have a tremendous impact on your code.

What are pure functions?

In short pure functions are functions that have no side effect and for each combination of parameters they return the same output. In reality, that means that you cannot request a database, make HTTP requests, use random inside them, or call functions that do so. No side effect means that they cannot change anything, not event their inputs. If you want to know more about pure function this is a good start.

Pure functions are guide to better architecture

Using pure function means that you restrict yourself. That restriction forces you to think of better solutions for your problems. Recently I wrote an app that needed to work with a date. The first solution I think of was something like this:

function doingDirtyThings() {
  // do something
  let result = workWithDate();
  // do something else
}

function workWithDate() {
  const date = new Date();
  // work with date...
  return someData;
}

If you look at the functions, none of them is pure. the creation of date is a side effect and it makes the workWithDate function hard to test. I would let the code like this if part of my brain would not scream IT IS INPURE! The solution, in this case, is to move the creation of the date to doingDirtyThings function. This way we can easily test the workWithDate function just by supplying the created date as input. In the end, I needed to reuse the date later in the program so this change made everything easier.

function doingDirtyThings() {
  // do something
  let date = new Date();
  let result = workWithDate(date);
  // do something else
}

function workWithDate(date) {
  // work with date...
  return someData;
}

Pure functions improve testability

I started to like writing tests since I started to write pure functions. The reason is that with pure functions the tests take almost no effort. You just import the function, throw some values at it, and look at the results. There is no mocking, no setup just values. Of course, you have to test the dirty parts of your app too, but the dirty parts are usually significantly smaller.

Pure functions help keep functions small and focused

Writing big bloated functions that are also pure is hard. I often find myself wondering how to avoid mutation and often the answer is: split the function! This gives you the benefit of better composability and it is much easier to reason about a small function that has single responsibility rather than a big bloated function.

Using pure functions helps to reason about code

There are simply fewer moving parts. That means that fewer things can be broken. In pure functions, the only thing that can be broken is function logic.

Conclusion

If there is one concept from functional programming you should know it is pure functions. As soon as you write a few of them you will encounter other benefits as easier composability etc. I hope that this article encouraged you to write more pure functions, the world needs it

You can this and more articles from me at https://rejmank.com/post/pure-functions