While TAR files and segments are a coarse-grained mechanism to divide the repository content in more manageable pieces, the real information is stored inside the segments as finer-grained records. Here I zoom in the segments and show the binary representation of data stored by Oak in the segments. It is not strictly necessary to know how segments work in order to understand the content of this post, but if you feel lost you can refer to my previous entry describing segments in greater detail.
I recently started working on a big, monolithic project. In my opinion, this project is a good candidate for an aggressive modularization effort. Let’s imagine that someone is arguing against this effort, and let’s analyze his statements. Are all of these statements true? Can modularization really provide some benefits to users and developers?
Here is described the phisical layout of a TAR file as used by Apache Oak. First, a brief introduction of the TAR format is given. Next, more details are provided about the low level information that are written in TAR entries. Finally, I describe how Oak saves a graph data structure inside the TAR file and how this representation is optimized for fast retrieval.
Sooner or later everyone needs a cache in its application. There are many caching strategies available to the wise developer: least recently used (LRU), most recently used (MRU), least frequently used (LFU), and a lot more. In this post I want to discuss about Magazine, a Node module implementing a flexible LRU cache.
to an array to create a new output array with desired properties. While this is
a well known approach, this may not be the most efficient one. In the first
place, the input array must already be in memory. This also means that the array
must be known in advance: abstractions like infinite arrays or infinite
sequences are not possible out of the box. Here I present a simple abstraction,
inspired by pure, lazy, functional languages, to model a list and some high
level operations on it.