- Technologie konteneryzacji z pozoru wyglądają dosyć magicznie - no bo jak to się dzieje, że w ramach systemu startuje i działa tak wyizolowane środowisko bez narzutów rodem z maszyn wirtualnych? Okazuje się, że stoi za tym o wiele mniejsza magia, niż by się wydawało, szczególnie w przypadku Dockera - artykuł przygląda się dokładnie procesowi tworzenia i działania kontenerów w praktyce.
- Z ciekawostek: nie jest to tylko bierne przejście procesu startowania - autor zadał sobie trud, żeby zajrzeć do repozytoriów dockera z jego samych początków. Bonusy są dwa - po pierwsze, w zrozumiały sposób pokazane są różnice w architekturze Dockera, które zaszły przez lata, a po drugie, można na własne oczy zobaczyć jak prostym narzędziem na samym początku był Docker.
Technical debt by Martin Fowler
- Czym jest dług techniczny i z czego wynika? Czy analogia długu zaczerpnięta z rynku finansowego jest zasadna przy wytwarzaniu oprogramowania?
- Skoro analogia długu sprowadza decyzje projektowe do czystej arytmetyki na poziomie inwestycji w spłatę vs bieżący koszt rozwoju, to dlaczego uważamy, że dług to coś złego?
- Martin podpowiada, dlaczego liczby nie zawsze się sumują, nie każdy dług jest zły oraz dlaczego implementacja zaplanowana na kredyt tak często zawodzi.
- Dla dociekliwych - warto poszerzyć opinię o komentarze w powiązanych tematach: koniecznie sekcja Further Reading oraz artykuły CannotMeasureProductivity, DesignStaminaHypothesis.
- U Warda Cunninghama szczególnie warto wyłapać fragment rozróżniający sensownie zaciągany dług techniczny od wymówki do pisania miernego kodu.
- Debt Metaphor by Ward Cunningham
- Historia sukcesu wdrożenia w którym dług pozwolił uzyskać pozycję lidera
- Design stamina hypothesis by Martin Fowler
- A Mess is not a Technical Debt by Uncle Bob
Google wybiera Kotlina jako wiodący język programowania dla Androida
- Poziom adaptacji Kotlina wśród profesjonalistów przekroczył już 50%! Kotlin jest też jednym z cieplej przyjętych języków ostatnich lat, o czym świadczą np. ankiety Stack Overflow.
- Co to oznacza? Kotlin będzie faworyzowany, jeśli chodzi o prędkość wprowadzania zmian, materiały edukacyjne będą skupiały się na Kotlinie.
- W praktyce to nadal JVM, co z jednej strony ogranicza trochę powagę ruchu, a z drugiej zachęca do spróbowania samemu!
- W największym skrócie - jak naprawić błędy przeszłości :wink:
- W nieco mniejszym skrócie, jeśli zepsułeś commit, niekoniecznie najnowszy, to git jest Twoim przyjacielem i pozwoli Ci odkręcić narobiony bigos W prostszych przypadkach wystarczy amend, w trudniejszych interaktywny rebase.
- Na podobnej zasadzie, jeśli w ferworze walki narobiłeś bałagan w branchach i commitach, to i tutaj git przyjdzie z pomocą - interaktywny rebase pozwala to ładnie wyprostować.
- Ogólnie warto się zaprzyjaźnić z interaktywnym rebasem, bo jest to zaskakująco wszechstronne narzędzie.
- Oczywiście przepisywanie historii niesie za sobą też ryzyko - nietrudno się rozpędzić i w ogóle wymazać część zmian. Ale ze spokojem - git tak naprawdę nigdy niczego nie zapomina i nawet jeśli po drodze coś sobie wymażecie, to z dużym prawdopodobieństwem da się to odkręcić, używając innego narzędzia gita - refloga. W praktyce reflog jest niezależnie przechowywaną historią wszystkich wykonanych zmian. Więcej na ten temat znajdziecie tutaj.
- A jeżeli nie macie czasu na zgłębianie tajników rebase'a i refloga, to tutaj jest bardzo podręczy zbiór quick fixów na sytuacje awaryjne.
GitHub wprowadza nową możliwość wspierania projektów/twórców open source - przez bezpośrednie dotowanie ich z poziomu GitHuba.
