Back to top

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 - szacowanie i planowanie.

Garść wniosków z obserwacji SCRUMa w praktyce - no, może nie odnośnie całego frameworka, a jedynie dwóch jego aspektów - estymacji i planowania. Zacznę od krótkiego SCRUMowego przypomnienia - otóż, jak wszyscy doskonale wiemy, jednym z artefaktów SCRUMa jest Backlog (lista zaległości produktu) - to lista zmian, które mają zostać wprowadzone w produkcie przez pracujący nad nim zespół deweloperski (bądź zespoły). Widniejące na takiej liście zmiany (zadania) zespół deweloperski omawia w trakcie spotkań nazywanych "refinmentem" (doskonaleniem), czyli w trakcie spotkań porządkowania listy zalogłości produktu (choć należy zauważyć, iż "refinement" przez Scrum Guide jest opisywany jako "proces ciągly", więc podejście do "porządkowania" może wyglądać różnie w różnych zespołach; w zespołach, w których ja miałem okazję pracować przyjęta była akurat zasada organizowania raz w tygodniu spotkania w celu omawiania zadań z backloga). Tak więc, w trakcie "refinementu" zespół stara się oszacować (wyestymować) ilość pracy potrzebną na realizację zadań (usuwanie zaległości) spisanych w backlogu. Szacunki dotyczą oczywiście poszczególnych zadań, a nie całości backloga, który może być oszacowany jedynie bardzo... ogólnie (przynajmniej w teorii). I tutaj pojawia się pierwszy problem: jak szacować ilość pracy potrzebą na realizację określonego zadania?

Strony