the Sourcerers Orchard

I often get grouchy at meetings. Often meetings are held for the sake of themselves. Sometimes you have meetings where you have a good purpose, but they don't lead to anything. You have all been on these pointless meetings. In these meetings you do not know what to say and often it is the same for everyone. Everyone tries to say wise things, but it's like trampling water, instead of getting somewhere You sit there and everyone talks about the problem instead of the solution. Do you listen to what people say you hear: Unspecified noun ("We" - Who we? "Help" - What help?) Unspecified verbs ("engages us" - in what way? How?) Generalizations (all, nobody, always, never) Rules (must, can not) Comparisons (better than, worse than) The participants repeat the same thing over and over again This is a symptom that the discussion does not solve the concrete problem. What we have to do is look for alternative methods to tackle the problem inst...

In the last post we looked at the std::list in C++ standard library. It was implemented as a linked list. The drawback with this is that we don’t have direct access to elements and that there is a memory overhead for the “links”. The benefits are that insertions in the list are at constant time. The vector is often a better alternative as it has direct access to specific elements without iterators and usually handles growth good. std::vector is a container that is similar to arrays in Pascal and to C-arrays. The C++ vector is not of fixed size and can grow and shrink runtime. Adding elements at the end are usually cheap, but not always constant time. std::vector:s use contiguous storage locations for their elements, which means that their elements can also be accessed using offsets on regular pointers to its elements, and just as efficiently as in C-arrays. But unlike C-arrays, their size can change dynamically, with their storage being handled automatically by the container. Internall...

There are a lot of different containers in C++. A container is a holder object that stores a collection of other objects (its elements). They are implemented as class templates, which makes them able to store almost any type of objects. The container manages the storage space for its elements and provides member functions to access them, either directly or through iterators. This makes them much more powerful and safe than the plain old C-arrays. Containers implements structures very commonly used in data science: dynamic arrays (vector), queues (queue), stacks (stack), heaps (priority_queue), linked lists (list), trees (set), associative arrays (map) and more. Each of these have their own characteristics. C++ have a lot of containers, but in this series of articles we will first look at the characteristics of each of the four ones you probably will need in your toolbox: std::list  std::vector  std:set  std::map  Today we will start with the list and la...

This is a a short introduction to the C++ memory model. In C++ the programmer has big control over how the program handles it memory, but you usually do not have to think a lot about it. Still it is good to know the basics to understand how things work under the hood. The memory a program uses is typically divided into different areas, called this is simple model of segments: The code segment , where the compiled program is stored in memory. The data segment where global and static variables are stored. The heap , where dynamically allocated variables are allocated from. The stack , where function parameters, local variables, and other function-related information are stored. The heap The heap segment (also known as the “free store”) keeps track of memory used for dynamic memory allocation. The heap is not automatically handled. You allocate memory and delete allocations yourself. In C++ you use the new operator to allocate memory in heap segment. You free the memory...

Weeds "Weed is a plant that has ended up in the wrong place. Either it got there through carelessness or it has been allowed to germinate and grow from being insignificant. "(New Farmers Handbook) Software is full of weeds. With weeds in this case I mean badly architectured software and not pure bugs. But, believe me: bugs arize from this later even if the are not there yet. This is not only from sloppy programmers and architects. In my last  blog post  I wrote about architecture in legacy software and with weeds I mean parts of the software not adhering to the architecture. Vines going between  layers in the chosen software model. When creating an architecture we often have high ambitions. Whichever framework we use: Domain Driven Design, Model View Controller or similar. Folders and modules created for the then current ways of working and separation of concern. Since starting work, the product owner has ordered thins and you have had to solve problems. You are...

The software developer has typically used the engineer as a model. This is obviously sprung out that we are dealing with technology. We build stuff! Our line of work grew out of electrical engineering and mathematics, hand in hand, it became a new profession. Development also has a soft side that you might not see from the outside and all developers not themselves discover. They become stuck in problem solving and happy that things are working. Programmers borrows many words from linguists. We have the language to describe what we do, languages have a grammar and helps us to communicate. Communication is not only between us and the computer, but also with other developers. Really well written programming code can be like poetry for those who understand it. Code is in many ways a cultural manifestation, almost art. Most books and articles we read about software development often describe an ideal stage. You get recipes on how to make the project design and how to write their code to...