Back to top

IT

Linux Namespaces

My first encounter with containers in the Linux edition was greatly "burdened" with the previous experiences with virtualisation. The containers were another, after paravirtualisation, step towards making the visualization even "lighter" and less resource consuming! I thought they were. When my colleagues experimented with the duet vagrant + virtualbox I tried to experiment with Lxc and I was not especially interested with how the Lxc works – it was just "a virtual environment". A moment of "enlightenment" came after the Linux autumn 2016. I participated in workshop concerning Linux Namespaces – it was really interesting! However after the conference I put this subject aside. Sometime in 2017 I looked through the recordings from DockerConf 2015 where I found a recording called: Cgroups, namespaces, and beyond: what are containers made from? – it reminded me of the Linux Autumn and one of my post-autumnal resolutions: to look at Namespacom more closely!

Linux Namespaces

Moje pierwsze spotkanie z kontenerami w linuksowym wydaniu było mocno "obarczone" wcześniejszymi doświadczeniami z wirtualizacją. Kontenery to był kolejny, po parawirtualizacji, krok w kierunku uczynienia wirtualizacji jeszcze "lżejszą" i mniej zasobożerną! Tak do tego podchodziłem. Gdy koledzy eksperymentowali z duetem vagrant + virtualbox ja skłaniałem się bardziej do eksperymentowania z Lxc, przy tym niespecjalnie interesowało mnie to, jak dokładnie Lxc działa - było to po prostu "środowisko wirtualne". Chwila "oświecenia" nadeszła podczas linuksowej jesieni w 2016 roku. Uczestniczyłem tam w warsztatach dotyczących Linux Namespaces - to było bardzo interesujące! Po konferencji temat jednak odłożyłem. Gdzieś w 2017 przeglądałem nagrania z DockerConf 2015 a wśród nich nagranie o tytule: Cgroups, namespaces, and beyond: what are containers made from? - to przypomniało mi o Linuksowej Jesieni i o jednym z moich po-jesiennych postanowień: przyjrzeć się bliżej Namespacom!

SCRUM - estimation and planning.

A bit of practical observations of SCRUM – well, maybe not relating to the whole Framework, but only two of its aspects – the estimation and planning. I will begin with a short SCRUM reminding – well, as we all know, one of the main SCRUM artifacts is Backlog (the list of product backlogs) – this is a list of changes that are to be implemented in the product by the development team (or teams) working on it. The changes (tasks) on this list are discussed by the development team during the meeting called “refinement”, so during the meetings of ordering the list of product backlogs (however we should notice that the “refinement” is described by Scrum Guide as the “continuous process”, so the attitude towards the “ordering” can look differently in different teams; in teams that I worked with the meetings were organized once a week to discuss the backlog tasks). So, during the “refinement” the team tries to estimate the amount of work needed to implement tasks (removing the backlogs) written in the Backlog. Of course, the estimates concern the particular tasks, not the whole backlog that can be estimated only… generally (at least in theory). Here the first problem appears: how can we estimate the amount of work needed to implement a particular task?

Strony