# Lambda days Krakow 2022

Being a nodeJS developer at the functional programming conference is not easy. First of all, you are constantly being mocked for not programming in the real language (looking at you Roman!) and you often do not know if the speaker is cursing or describing some esoterical Haskell concept. But none of the difficulties should scare you from attending. Seven hours on the train means plenty of time for beers and reading. Our train even had a working air-conditioner... but working maybe too well so some of us had to shake off the hoarfrost before leaving the train. Nevertheless, We overcome all the difficulties, arrived in Krakow, and enjoyed the event.

## Day 1

### [KEYNOTE: Building a Haskell-to-Hardware compiler: Theory & Practice](https://www.lambdadays.org/lambdadays2022/christiaan-baaij)
Two things I do not know anything about Haskell and the design of microchips... Cannot tell anything other than that the speaker was well prepared and with the knowledge of at least one I could see that it would be very interesting. I do not think that the topic was well suited for a keynote.

### [Attack Of The Clones: Multiplayer Online Game in Clojure](https://www.lambdadays.org/lambdadays2022/mey-beisaron)
Introduction to Clojure that was not an introduction to Clojure. Walk through game code that runs on the backend. Well-chosen snippets and level of detail. Compared to the previous talk this one was really easy to grasp but on the other hand nothing new for me. I can imagine changing the talk to be a great introduction to Clojure. Nice talk nevertheless.

### [Debugging for math lover](https://www.lambdadays.org/lambdadays2022/michal-j-gajda)
With reduced complexity, you reduce the time and effort needed to debug the issues. This rather simple idea was spread into talk that covered different types and kinds of errors, debugging "strategies" and how they differ. Little too much Haskell(ish) but with takeaways even for us simple JavaScript programmers. I would be glad if the talk was more practical but the questions from the audience kind of fixed that. My takeaway is that there is to think more about the number of loops/ifs the speed of growth for them is not linear!

### [Teaching Functional Programmers Logic and Metatheory](https://www.lambdadays.org/lambdadays2022/frederik-krogsdal-jacobsen)
Talk about a course at the university where they used a FP to teach the format logic concepts. I appreciate that he presented the results and feedback which was not that positive. I really, really appreciate that.

### [An Enigma Machine in Elm](https://www.lambdadays.org/lambdadays2022/ju-liu)
Nice talk. Not really about elm but about cryptography and enigma itself. Well-spoken, funny, clear. The implementation was two slides but it showed the strength of simplicity in functional programming. This talk would make an awesome keynote.

## Intermezzo

So that was the end of day one. But not really because, you guessed it, after party! The venue was nice but the highlight was the 1 am kebab with a bottle of whiskey in the park. Great night, tough morning.

## Day 2

### [Keynote: What every programmer should know about cognition](https://www.lambdadays.org/lambdadays2022/felienne-hermans)
Do you know that you cannot teach teenagers programming in scratch? They just do not want to use something looking like a toy. The talk, based on the experience of teaching kids programming, was full of similar gems. A little reminder that we should think more about how we teach programming topics. Useful clear, great keynote! Note for me read the programmer's brain!

## [The work done by something else](https://www.lambdadays.org/lambdadays2022/attila-egrinagy)
Talk damaged by technical problems. The main idea was that the line between declarative and imperative is blurrier than we might think. Nice examples in Clojure. I liked the idea of Clojure in one slide, neat. Unfortunately, there was not possible to hear anything in the first third so I am sure I missed some ideas.

### [KEYNOTE: Sonic Pi - past, present & future](https://www.lambdadays.org/lambdadays2022/sam-aaron)
What an ending! Great, great talk with awesome delivery. Through teaching kids to program using music creation, principles of music the language itself... The only talk that forced me to download the software and play with it at the hotel.

## Bitching about things
I did not write about all talks I attended (so my manager does not know how many I skipped :P ) and also because there were a few talks that were bad and writing that would help no one. Instead, I wrote down what mistakes I saw most frequently to avoid them myself.
- Not good talk structure
	- The structure gives your talk rhythm, you can grab the audience's attention longer and it enables the listener to catch up if he/she gets distracted
-  BIG FONTS!!!
	- I cannot stress this enough. If you have code on your slides it must be big. It leaves you with just a few lines you can show at the time but nobody wants to read you 50 lines of code. If you want to show a larger portion of code do it step by step.

## TLDR
The conference was great. Cool venue, nice catering, stable wifi. The talks were interesting and I am bringing home some motivation and ideas. Thanks, CN for letting me go and the whole crew attending for the great atmosphere.
Thank you Lambda Days!


Lambda days Krakow 2022


I think we all agree that we developers should know why we do things. We usually know why we like our language of choice, why choose fp over oop, and why the legacy code we are rewriting is really terrible. But with DevOps, I often feel that for all the shiny toys (trees) we miss the whole DevOps forest. So let me take you on the walk through the DevOps forest.

In the first part, we will look at what DevOps is, how it came to be and what benefit it brings to us, and how to measure it. In the second part, we will look into tools and practices that can help us.

## Short history of DevOps

It all started when [Patrick Debois](https://twitter.com/patrickdebois?lang=cs) was fed up with the way of creating software at the time. It usually worked like this: You would first write the code, hand it to the QA and wait for a response. Then you would fix the bugs they found and send the code back. You would continue with the ping pong until the QA said that it is ok or, more often, the management says that time is up. After that, the Ops take over and try to run the mess. The time between you write your code and the code running in production could be in months. Every deployment was an event worth celebrating (or drowning the failure in beer). So Patrick formed an Agile systems administration group together with Andrew Shafer and started the revolution. It all got traction in 2009 with one of the most famous talks in DevOps history the [10 deploys per day Dev & ops cooperation at Flickt](https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr). It is still incredibly fresh so check it out.

# What is DevOps

What is DevOps? This question does not have an easy answer. Some will say that it is about developers running their own code, for some companies it is a move to the cloud, and for some, it is about using Kubernetes (you cannot run Kubernetes without DevOps, right?). But in reality, DevOps does not have much to do with the tools we use. DevOps scope ranges from continuous integration and delivery through testing automation all the way to the design of teams. Here is my favorite definition of DevOps:

> The DevOps philosophy builds upon the Agile Principles. You can look at it as a combination of cultural philosophies, practices, and tools that increases a company’s ability to deliver applications and services faster... (https://www.bunnyshell.com/blog/how-netflix-does-devops)

## It is all about speed

Ok now we get an idea of what DevOps is but for all companies, the goal is to make money. How will DevOps help with this? Imagine two companies. From the outside, both of them look similar. They have an e-shop and sell the same product. They even have a similar number of developers employed. Now let's imagine that the first one have DevOps practices in place and the second don not, which one should be more successful?
If you said the first one great, but do you know why?
It is all about speed. What DevOps brings us in the first place is **increase in the number of useful features delivered**. And it is not because the developers work more hours. It is because the features go faster into production and the company can **learn faster**. Developers will not spend hours building something nobody wants. We will discover the bugs in our code faster and we will learn about those bugs that we would not find otherwise (production is a wild space)

## How do we do in terms of DevOps

Old managers telling says that what we do not measure we do not control. So how to tell if your project has good DevOps? There are 4 basic metrics called DORA that can help us to measure our "devOpsiness". Those are:

- Lead time - How long it takes from commit to production,
- Deployment frequency - how often do we deploy to production,
- Change failure rate - How many changes end up with an issue in production,
- Mean time to recovery - how long it takes for failure in production to be mitigated.

Those four metrics are connected so if you get better at one the domino effect will kick in and you will get better at the rest. Let's say that you start the DevOps journey by shortening the lead time. It will mean that you will make smaller changes to your product. With smaller changes, you will have to deploy more frequently to have the same velocity. Smaller changes mean easier spotting of mistakes and easier testing. So the change failure rate goes down. And with the smaller changes, the revert of changes and ideally code fixing gets also easier.

> give developer two lines change and he will find 10 mistakes, give him 2000 lines change and he will say "looks good"

## Conclusion

Now we should see the forest and we know what purpose it has and also know if we have some issues and what metrics to use to spot them. Next time we will look into practices that will help with DevOps practices.


In the first part, we will look at what DevOps is, how it came to be and what benefit it brings to us.

Intro to DevOps part one

## The DevOps handbook - summary

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.


Summary of the best DevOps book i red so far.

The DevOps handbook - summary


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.



how to start with devOps?

# Habits to build
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.


A little meditation on habits that help me most as a developer.

Habits to build

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 ](https://numinous.productions/ttft/ ). 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](https://andymatuschak.org/prompts/) about this topic which helped me a lot. 


## Zettelkatsen
I discovered the zettelkatsen from Eliska Sestakova and her awesome [blog](https://eliskasestakova.cz/) (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](https://commoncog.com/blog/accelerated-expertise/) 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.

In this article, I describe my current experiment with an efficient learning technique based on zettelkatsen, accelerated expertise, and mnemonic medium.

Learning tech stuff

# 2021 Year in review
Last year I wrote my [2020 review](https://rejmank.com/post/2020-review). Today I would like to look back on my plans for last year to see what went well and what did not, and also plan a little bit for the next year. 

## Sport 
My biggest goal for 2020 was to lose some weight... Which I definitely managed. During the first quarantine, I lost about 13 kilograms which I did not gain again. I stopped eating sweets for the first three months but I started to eat them again in moderation. I still have problems managing the amount of sugar I eat but it gets better and learning how to manage food better is more valuable than crossing all sweats or junk food from my life. **I still have about 5-7 extra kilograms to ideal weight, that I would like to lose next year** but overall I check this one as a success. I continued with BJJ with the same enthusiasm as last year, that is something I will be continuing. The last thing is that I would like to **finally beat my long-term goal and run a half marathon in under 2 hours. With my current form, it should be no problem so the goal for me is one hour forty-five minutes.** 

## Work
Last review my goals was to learn a new functional language, start some bigger side project and focus on security or architecture. From those goals, I finished none. I tried a few new languages during quarantine, read some books about architecture, etc. In the end, my work pushed me into the DevOps direction. Although I did not accomplish any of my goals the DevOps direction gave me a lot of opportunities, I started organizing our internal DevOps talks and started with AWS. DevOps is a thing I would like to work on next year. **The goal for me is to finish AWS certified architect next year and continue organizing our internal DevOps talks.**

## Blog
The blog is my biggest regret of last year. Since lockdown ended I wrote exactly 0 articles. This is something I want to change. Since the start of the next week **I would like to publish a weekly article with one week off each month**. I feel that I need to make my writing better and I have a ton of new stuff to learn and for me writing is learning.

## Books
This year I read 30 books, most of them in audio form. I am still writing them down into my google sheet and there is **nothing I would like to change**. I read not 7 but 5 technical books. The only big change for me is that I started to use Instapaper for reading articles and most importantly readwise to make notes and review them. Both are great reading additions and well worth their price. 

## Conclusion
Overall 2021 was a good year for me. I lost weight, enjoyed BJJ, had a great vacation, and found what to focus on in my work. Next year will be a year of change in my personal life but if I will endure with everything I do I think that the year will also be awesome!

### Goals list
This goals list includes only "[SMART](https://en.wikipedia.org/wiki/SMART_criteria)" goals.
- Write 3 articles a month
- Lost at least 5kg
- Organize 9 DevOps indeeds
- Be a certified cloud architect
- Half Marathon under 1:45

2021 Year in review


# Why I started to fall in love with go

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](https://dusted.codes/dotnet-for-beginners) 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](https://sw-samuraj.cz/2018/09/golang-micro-services-prvni-ohlednuti) 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.


I finally try golang and i liked it! This sumarizes my first thougths and feelings about the language.

Why I started to fall in love with go


# The usefulness of currying

In the [last article about pipe](https://rejmank.com/post/functional-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:

```javascript
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.

```javascript
// 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:

```javascript
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:

```javascript
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:

```javascript
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.

```javascript
// 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.

```javascript
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.

```javascript
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](https://2ality.com/2011/09/currying-vs-part-eval.html)

```javascript
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.

This is third article in functional javascript series:

- [The beauty of pure functions](https://rejmank.com/post/pure-functions)
- [The benefits of pipe](https://rejmank.com/post/functional-pipe)
- [**_The usefulness of currying_**](https://rejmank.com/post/uselfuness-of-currying)


What to do if your functions do not fit together in pipe? How to make composition easier? Read the article and you get the answer.

The usefulness of currying


# The benefits of pipe?

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](https://rejmank.com/post/pure-functions). And you want to call them all, in sequence on one piece of data. Something like this:

```javascript
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.

```javascript
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.

```javascript
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.

```javascript
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.

This is second article in functional javascript series:

- [The beauty of pure functions](https://rejmank.com/post/pure-functions)
- [**_The benefits of pipe_**](https://rejmank.com/post/functional-pipe)
- [The usefulness of currying](https://rejmank.com/post/uselfuness-of-currying)


Pipe is a magica door to the world of functional programming, why?

The benefits of pipe


# Why I use date-fns

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:

```javascript
// 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:

```javascript
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](https://date-fns.org/) or [this awesome repository](https://github.com/you-dont-need/You-Dont-Need-Momentjs#quick-links) that compares other options for working with dates.


Why I use date-fns


# The value of feedback

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 allows 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](https://www.amazon.com/Mindset-Updated-Changing-Fulfil-Potential/dp/147213995X) by Dr. Carol Dweck and [Creativity inc.](https://www.amazon.com/Creativity-Inc-Overcoming-Unseen-Inspiration-ebook/dp/B00GUOEMA4/) 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.


Feedback is one of the most valuable learning tools.

The value of feedback


# Fundamentals of software architecture - review

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.


Review of book Fundamentals of Software Architecture by Mark Richards and Neal Ford

Fundamentals of software architecture - review


# 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

### https://github.com/leonardomso/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

### https://github.com/goldbergyoni/nodebestpractices

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

### www.frontendmasters.com

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

### https://github.com/getify/You-Dont-Know-JS

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

### https://github.com/getify/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

### https://www.roadtoreact.com/

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

## https://epicreact.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. 



Collection of books, courses and articles i used, and would use again, to learn javascript.

Javascript learning resources


# 2020 a year in review 

For me the year 2020 was pretty good. This is a look back at the last year with an evaluation of my goals and setting up some goals for next year. 

## Sport 

The year 2020 for my sport and fitness goals was kind of strange. *I completely failed my goal of running three half marathons*. Partly because of the pandemic and partly because I failed to prepare because of extra weight and problems with knees. On the other hand, I started with a new sport that I completely fell in love with Brazilian Jiu-Jitsu. Firstly I wanted to just try it to add something else to my strength routine but I became a total maniac. I spend every possible minute on the tatami **and it is something I will continue to do next year**. 

The biggest problem is my weight. *I, once again, failed to lose some weight*. I feel like I need to do something radical. **I will be cutting the sweets next year**. I have quite a sweet tooth and I feel that I do not eat that bad but coca-cola, cakes and other shit prevents me from finally cutting some weight. By cutting sweets I mean **completely**. For me the middle road never works and I feel like an alcoholic I can stick to something (like whole30) for a month but then I come back to normal and ultimately find myself eating tons of sugar once again. So for 2021, the goal is to stop eating sweets no sweets from time to time I mean complete cut like an alcoholic on rehab.

## Work 

Regarding work my Year was awesome. A new job found me, I can work with a bunch of great developers on an interesting project and I have a feeling that this is a place where I would like to work for several next years. Feeling I newer had so far. *I focused on node.js, was trying some Clojure and F# while learning the basics of machine learning, and get interested in rust in the end*. 

I also started blogging which is something I thought of a lot but this year I finally did it. 

Next year I would like to **continue learning about fp and typed languages (rust!)**. 

**I would like to also do some bigger side project. I thought of creating a course on ramda but nothing is set to stone**. 

**The last thing I would like to do next year is getting a little bit more into security and software architecture and pursue one of those**. 

## Books 

This year was good for reading. I read or listened to 24 books this year. It was the year of Neil Gaiman. I discovered him through the American goods (which I am listening to for the third time) and he immediately becomes one of my favorite authors. *I read a little bit less technical literature this year than I wanted*. I have quite a pile to read next year so **I would like to read at least 7 of them**. Also **writing down the books I read into the google sheets** is something I would like to continue with.

## Blog

**I would like to publish one technical article a month.** Nothing crazy but learn how to write well is not a top priority for me.

## Conclusion

It was a good year for me. I hope that next year will be good for everyone. Especially those who are suffering during the pandemic. To summarize it the only big goal for me the next year is to cut the sweets. The rest is to continue doing what I am doing and have fun doing it.


How was 2020 for me? And what I would like to do in 2021?

2020 a year in review


# The beauty of pure functions

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](https://www.freecodecamp.org/news/what-is-a-pure-function-in-javascript-acb887375dfe/).

## 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:

```javascript
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.

```javascript
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 helps 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 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.

This is first article in functional javascript series:

- [**_The beauty of pure functions_**](https://rejmank.com/post/pure-functions)
- [The benefits of pipe](https://rejmank.com/post/functional-pipe)
- [The usefulness of currying](https://rejmank.com/post/usefulness-of-currying)


Is pure functions the most beautifull concept in programming?