W każdym tygodniu czytamy setki artykułów dotykających świata Javy i tematów powiązanych. Każda osoba w Consdacie może przesłać wpis, który uznała za szczególnie interesujący, do dedykowanej grupy, w której następnie odbywa się ostateczna selekcja najciekawszych i najbardziej wartościowych wpisów, a ich znaleziska mogą docierać również do Ciebie! Od solidnej dawki wiedzy dzieli Cię tylko kilka kliknięć.

Docker anti-patterns     

- Wejście w technologie konteneryzacji wymaga sporej zmiany w postrzeganiu deploymentu - trzeba zacząć "myśleć kontenerami".

-Przede wszystkim należy poczuć różnicę pomiędzy kontenerami, a maszynami wirtualnymi - kontenery są tylko (i aż) wyizolowanymi procesami na systemie hosta, a nie emulacją pełnego środowiska. Powinny być lekkie, efemeryczne i robić jedną, dobrze sprecyzowaną rzecz.

- Jedną z większych zalet obrazów dockerowych jest przenaszalność pomiędzy środowiskami. Budowanie obrazów per środowisko ignoruje tę właściwość i prowadzi do zaprzeczenia zasady odtwarzalności - nie mamy pewności, że pomiędzy środowiskami testujemy to samo oprogramowanie.

- Lista anty-patternów jest oczywiście dłuższa. Warto się zapoznać. 

 

The reduce ({...spread}) anti-pattern

- Sedno sprawy jest takie, że operator spread w JSie wykonuje pod spodem iterację, co w pewnych warunkach wprowadza spory narzut wydajnościowy. 

- Na pierwszy rzut oka autor opisuje jeden bardzo konkretny przypadek - iterację w operatorze spread w kontekście operacji reduce. Robi to jednak na tyle dobrze, że warto się w niego zgłębić ponad samo sedno sprawy - wchodzi w szczegóły implementacji silników JS, podchodzi do tematu od strony badania złożoności obliczeniowej, porównania wydajności równoważnych funkcjonalnie rozwiązań, skończywszy na nieco ogólniejszych rozważaniach nt. premature optimization oraz programowania funkcyjnego.

- Wychodzi z tego pozornie oczywisty wniosek - unikając premature optimizations, można wpakować się w premature de-optimization.

- O ile z samym przykładem można dyskutować (odnośnie: czytelność kodu vs analiza złożoności dla problemów o znanym pomijalnym rozmiarze), o tyle metodologia i pragmatyzm autora zasługują na szacunek! Czapki z głów!