Przejdź do głównej zawartości

Posty

Code Kata: the card game of war

The card game of war is a very old, but still popular game. I used to play it when I was a child. The game is very suitable for small kids, because it has simple rules and the players don't need to make any decisions - it's enough to follow the rules. In this article, we will try to go through the process of modeling the game of war as a computer program. And as we will see later, the modeling may have some very practical uses. Let's start.

The game is usually played with 24 cards of four colors. The cards are as follows, next to each card there is a single letter that will represent the card for us.
Ace - AKing - KQueen - QJack - J10 - T9 - N The colors do not matter in the basic version of the game. The 24 cards are distributed randomly between two players. Each player starts with 12 cards. The player who loses all the cards loses the game. Main steps of the game will be executed by the function:

nextMove (cardsA, cardsB)

The game then can be started by invoking: nextMove …
Najnowsze posty

Requirements discovery

Requirements have a long history in software industry. We all have heard or read terms like: requirements definition, requirements management, requirements decomposition... tons of books, trainings and requirements themselves have been created for software all over the world.

Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.

Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.

In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably mis…

Dwie parafie

This is the only post in Polish, it would not be easy to understand in English, as it is strongly based in Polish context.

Ten post dedykuję Mariuszowi Francuzowi, który pokazał mi, że Kanban to o wiele więcej niż tablica stanów.

Pewnego razu były sobie w Polsce dwie parafie. Żeby ukrócić plotki przyjmijmy, że jedna z nich nazywała się W a druga A. Obie parafie stanęły przed problemem: trzeba wyświetlać podczas Mszy Świętej teksty pieśni na ekranie.


Parafia W podeszła do problemu w następujący sposób. Zebrała kilkanaście mądrych i doświadczonych osób, aby zrobić zestawienie pieśni na cały rok. Parafia zadbała o to, aby w tym gronie bylo zarówno wierni jak i duchowni. Debatowanie nad listą pieśni zajęło trzy miesiące. Uzgodniona lista tytułów została przesłana do Kurii w celu konsultacji. Po trzech miesiącach Kuria odpowiedziała, nakazując wyłączyć ze spisu dwie pieśni, a z kolei dołączyć siedemnaście innych.

Na nowo zenergetyzowane grono parafii W zaczęło spisywać pełne teksty pieśni, …

Attitude is more important than skills

I was fortunate to work with a few development teams that were truly cross-functional. Every developer was able to perform several types of tests, build and deploy the product and develop code in layers of the product. Not many teams are like that.

More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.

This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact w…

An illustrated analogy to carpentry

Code is like a building material. Imagine the code you work with is wood.

Just like wood and wooden appliances, it can have different structure.



Just like wood, it is exposed to external forces and to the pass of time.


Just like wood, it requires different tools to work with it and turn it into something usable and beautiful. Humans devoted many past years to the invention and enhancement of these tools. It would be foolish not to use them.




In both coding and carpentry, we need to learn to use each tool. Otherwise we are likely to cause damage.



Depending on the craftsmanship applied to woodworking, it is either harder or easier to maintain and repair a wooden appliance months and years after somebody started using it. Same is with code.



Different types of wood have been recognized as particularly good for different uses. And our OS kernels aren't coded in Javascript.



The code that you are developing today - which piece of furniture is more like it?




My favorite kind of Waterfall

Be a human, not a compiler

A recent reading inspired me to make an observation on programming skills and differences between those the masters and the laymen.

This is not the kind of information you will learn at university or a conference. This can change your professional attitude, so read on.

From the very beginning of our programming education we are talked into thinking like a compiler. We gradually develop the thinking that in order to write a decent piece of code we need to ask ourselves questions like these below:
how is this thing going to be evaluated by the computer?will this index ever go out of array boundary?can this variable overflow under any circumstances?will this statement correctly modify / concatenate / process these numbers / strings?is it then this pointer that is going to point at the result when the function returns? After years of doing that, we are even inclined to judge others at job interviews by how they are able to answer these questions. The funny (and upsetting, at the same time…