Budowanie rusztowań

Dziś na LinkedIn ktoś zadał pytanie co by ludzie zrobili mając do wyboru dwie alternatywy:

• duża podwyżka i praca z Cobolem,
• średnia pensja i praca z nowoczesnymi technologiami

Dla mnie oczywista była bramka numer 3 ;-) czyli średnia pensja z nowoczesnymi technologiami jako sposób na zdobycie wiedzy by móc za jakiś czas szukać lepiej płatnej pracy.

Mój cel tu to "dobrze zarabiać i robić fajne rzeczy" i jak nie ma takiej opcji to wybieram "najkrótszą drogę" do tego celu z krokiem pośrednim. Wybór średniej pensji z nowoczesnymi technologiami to taki bootcamp gdzie mi jeszcze zapłacą za nauczenie się czegoś co mi pozwoli na kolejny krok. 
Ale to nie jest nawet tak, że ja ten cel "dobrze zarabiać i robić fajne rzeczy" mam jakoś jasno określony, on mi tu naturalnie wychodzi z opcji i że nie jest osiągalny wprost to myślę o tym jak go osiągnąć etapami.

To samo gdy buduję coś to za naturalne uważam robienie tego wersjami, mogę mieć oczywiście ideę jak to ma wyglądać na końcu, ale zwykle nie mam pojęcia i dlatego zaczynam od wersji minimum, od MVP i dodaję do tego rzeczy i przebudowywuję.

Buduję raz na jakiś czas rusztowania, które wspierają całą budowlę w czasie gdy to jest potrzebne.

Gdy w poprzedniej firmie budowaliśmy nasz produkt to zamiast wybierać bazę danych, projektować struktury danych i tak dalej, zaczęliśmy od prostego narysowania drzewa, później zrobiłem in-memory wersję "bazy danych" i kodowaliśmy resztę.
Wsparcie dla prawdziwej bazy danych zrobiłem siedząc w hotelu w Warszawie, ale przez blisko 2 miesiące kodowaliśmy wszystko bez bazy danych i działało.

Ten in-memory coś to było takie rusztowanie, które pozwoliło nam developować, sprawdzić koncepcję i w końcu wystarczyło dodać konkretną implementację. Co ciekawe to coś pozwoliło nam przeskoczyć później jedno z założeń, które okazało się błędne. 

Z drugiej strony nieraz nie mogłem dojść do porozumienia z kimś kto zakłada, że jak coś jest to ma być. Nie wiem, coś w stylu, mamy nowe API i proxy które tłumaczy nowe API na stare... starego API używa masa ludzi i będzie używać przez wiele lat w przyszłości. Dla mnie jakby naturalne jest uznanie, że "OK, klientów nie zmusimy, więc weźmy to na klatę" i wrzucenie tego proxy z czasem do codebase głównego API (bo proxy napisał inny team, w innej technologii). Ale słyszałem stwierdzenia w stylu "nie po to płaciliśmy za zrobienie tego proxy żeby teraz to włączać do naszego kodu" i ogólnie narzekanie, że "to takie nieporządne będzie". 

Podobne posty^beta
Pierwsza zasada wyboru pracodawcy - rozumieć co robi jego firma ;-)
Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)
Raport z emigracji ;-)
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
O wyższości aplikacji natywnych nad tymi w HTML5 - od strony developera

Najwięcej kodu != najlepszy developer

Z serii prawdy nieoczywiste ;-)

A wiesz, że jak masz w zespole developera, który pisze kodu więcej niż inni to jest duża szansa, że jest ten developer najmniej potrzebnym developerem? ;-)

W tej branży wszyscy lubimy pisać kod. Programiści, architekci, managerowie, nawet niektórzy PMowie.

Kodowanie jest fajne... ale sam fakt tego, że pisze się dużo kodu niczego nie dowodzi. Tzn. tak ma się lepszą technikę pisania, ale to tyle.

Jeśli w zespole jest ktoś kto pisze dużo kodu to często jest tak, że ten ktoś "pisze pod siebie", pisze dużo i inni muszą się do tego jakoś dopasowywać. 
Większość ludzi chce współpracować i nie ma tendencji do przepisywania "cudzego kodu", więc próbują się dopasować. Mamy wtedy sprzężenie zwrotne. X pisze na początku dużo kodu, narzuca swój styl, który jest "dziwny", inni próbują się przystosować więc piszą wolniej... a X pisze jeszcze więcej i szybciej.

Widziałem to 2 razy i 2 razy nie było to dobre. Reszta teamu się robiła smutna, byli sfrustrowani, zniechęceni, ale nie do końca wiedzieli czemu. 

Oczywiście to nie jest tak, że każdy taki przypadek jest zły.... ale zwykle o czymś mówi.

Jak masz zespół nierówny bo kogoś z dużym doświadczeniem i reszta ludzi jest młoda to to jest możliwe, i usunięcie tej osoby nie przejdzie bez problemów.... ale lepiej takiego kogoś zachęcić do oddania części pracy, bo inni będą mogli urosnąć, a ten ktoś zajmie się większymi rzeczami.
Jednak jak masz zespół, który jest w miarę równy jeśli chodzi o lata doświadczenia i nie ma tam jednej osoby, która wyraźnie odstaje umiejętnościami na plus, to masz duże szanse na problem. 
To nie jest wina tej osoby, pewnie team nie jest dopasowany. W dopasowanym teamie ludzie sobie patrzą na ręce i sobie pomagają. Jak ktoś się obsuwa to mu pomagają, jak ktoś umie coś nowego to uczy innych. Jak team jest niedopasowany to osoba, która ma najmniejsze opory przed pisaniem kodu (czyli jest najmniej podatny na bycie perfekcjonistą (w tej branży chyba wszyscy mają problem, tylko różni się intensywnością ;-)) zaczyna pisać tego kodu więcej, jeśli reszta teamu jest taka bardziej w trybie follow niż lead to się nie stawiają... 
Tu się przydaje radical candor, idealnie w wersji "Hej X, daj się innym bawić", też dobrze w wersji "X, weź k... zostaw ten kod i daj nam coś napisać, bo znów spartolisz"... niestety często jest mówienie managerowi "nie ma ticketów, bo X bierze".... albo jeszcze gorzej zamknięcie się w sobie.
Dodajmy do tego nietechnicznego PO, który chce szybko zbudować produkt i problem się będzie nakręcał... aż X się znudzi i postanowi sobie poodpoczywać i wtedy spada wydajność całego zespołu, bo inni się przyzwyczajali do wyjadanie resztek po X.... X nic nie je i jest problem.

Stąd ja zawsze próbuję zrobić test ważności przez "a co będzie jeśli Y zniknie z zespołu". I ten test dziwnie często potrafi wskazać, że osoba pisząca najwięcej kodu swoim zniknięciem może zrobić nawet więcej dobrego bo w jej miejsce wskoczą inne osoby.. To widać np. jak X jest na urlopie i nagle za kodowanie biorą się inni ludzie i fajnie to wychodzi.

Podobne posty^beta
Nie lenistwo, a strach. Prawdziwe źródło długu technicznego
Kiedy zmieniać pracę i po co? (w IT)
Kwietniowe książki
Głosowanie korespondencyjne jest tak dziurawe, że aż szkoda gadać - z perspektywy IT
Nie lejmy betonu na kod....

Nie lejmy betonu na kod....

Jak można zdefiniować gentlemana? Jako mężczyznę który jest w stanie opisać piękną i zgrabną kobietę nie używając rąk...

Jak można zdefiniować dobrego inżyniera? Jako kogoś kto potrafi opisać złożony system bez machania rękami ;-)

Mnie się wydaje, że sztuka polega na tym by widząc problem dokonać jego rozebrania na mniejsze problemy i patrzeć na te problemy jak klocki, z których można budować rozwiazanie. 

Może niektóre klocki są niepotrzebne, a znów inne przydadzą się do czegoś jeszcze? Wtedy nie budujemy ficzera X, budujemy środki do osiągnięcia tego co ma robić ficzer X i zwiększamy ilość dostępnych klocków.

W komputerach zwykle nie rozwiązujemy za każdym razem nowych problemów, a raczej inną wersję tego samego problemu.

Nagle celem staje się nie tyle tworzenie tych klocków, a używanie tych klocków do budowania czegoś większego.

Nie znasz pełnych wymagań? Nie musisz na nie czekać, identyfikujesz kluczowe problemy i je rozwiązujesz tak, że w razie czego chociaż część z nich z niedużymi modyfikacjami pozwoli rozwiązać prawdziwy problem.

Przeszedłem w życiu przez kilka firm ;-) i widzę, że często popularne jest budowanie ficzera w którym sam ficzer staje się ważny. Wydaje mi się, że ja od pewnego momentu patrzę na kawałki i znając historię umiem mniej lub więcej przewidzieć, że ten kawałek przyda się jeszcze w innych miejscach. 

Patrzę na kod (bo kod jest wg mnie nadal ważny) ale bardziej patrzę na powierzchnie styku. Co jest w środku to szczegół implementacyjny. Ważne jest co jest na zewnątrz, jaki jest interfejs. 

Do tego patrzę na kod i staram się myśleć jak on się będzie mógł zmienić, większej zmiany nie zrobimy "na raz" ale na raty się może udać. Nawet nie wiedziałem, dowiedziałem się, że to jest Strangler Fig Pattern ;-)

Żeby nie było ja potrafię napisać brzydki kod ;-) ale zwykle potrafię też zbudować coś co można dalej modyfikować i rozwijać, nie zalewam tego betonem. Zawsze gdzieś można włożyć "coś pomiędzy" i ukryć zmianę przed resztą kodu... fakt czasem jest to trudne, ale zwykle się daje.

Ogólnie lubię robić to tak, żeby komponenty zbytnio o sobie nie wiedziały.... i też nie piszę jednak za bardzo OOP kodu bo u mine class members jako zmienne to głównie jakieś "serwisy" czyli instancje klas robiących coś... zwykle jak spojrzeć to moje klasy są takie semi-bezstanowe.... choć fakt nie jest idealnie bo zdarza mi się, że metoda może modyfikować swój input.... to jest jednak inżynieria nie religia ;-)

To samo podejście próbuję stosować do większych komponentów. W moim idealnym świecie zmiana jednego komponentu jest niewidzialna dla pozostałych... Tak, to znaczy, że może jak gdzieś jest np. pipeline który dostaje format A, pierwszy kawałek przerabia na B, drugi pracuje na B i go ulepsza i w końcu publikuje...  to ja bym wolał wejście A, ale pierwszy robi (A,B) i drugi pracuje na (A,B) i produkuje A... więc z czasem mogę funkcjonalności z pierwszego przenieść do drugiego i go później zabić.

Czyli ogólnie architektura czy kod to jest tylko snapshot całego rozwiązania tu i teraz. Nie musi być doskonały, musi robić tylko to czego od niego na dziś wymagamy, a do nowych wyzwań zawsze może urosnąć.

Podobne posty^beta
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
Rozdzielanie dwóch światów ;-)
Tagowanie postów MLem - trzeba to przepisać ;p
Struktury danych vs algorytmy
Najwięcej kodu != najlepszy developer

Zaczynam się przekonywać do agentów AI....

Używając Google Antigravity próbuję sobie zbudować coś do Agentów AI.

Teraz poprosiłem to coś o zrobienie kodu do monitorowania strony autora książek o Bobiverse... i agent (mój, używający qwen2.5-coder:32b poległ... napisał kod, ale się wywalił na pip install ;-).

To jest właśnie ciekawe, że wpadł na to by użyć pip install.

Byłem sceptyczny... tzn. widziałem i widzę moc w Copilot'cie i podobnych, ale nie dostrzegałem potencjału w agentach.

Potencjał jest taki, że teoretycznie rzeczywiście można sobie wyobrazić tworzenie softu jako zarządzanie zespołem agentów ;-)

Już mi się zdarzało w roli Team Leada/PO pisać historyjki techniczne i robić grafy które pokazywały zależności. Robiłem to dla zespołu. Zespołu człowieków.

Tak każdy członek mojego zespołu był wielokrotnie sprytniejszy i mądrzejszy od takich agentów, ale i tu jest hipoteza - możliwe, że istnieje "kaskada" głupich agentów, które przez swoją syntezę będą ciut mądrzejsze ;-)

No bo ludź może napisać instrukcję, którą jeden model/Agent przerobi na implementation plan i zleci zadania innym agentom.... i jeśli im to wyjdzie...

Nadal tu jest wg mnie takie wielkie "IF" czy bardziej "JEŚLI".... Ale wydaje się to być ciekawy obszar...

A tak pod koniec stycznia sam zacznę nowy rozdział pracując z agentami ;-)

Podobne posty^beta
Żenada....
Programowanie nie jest jak jazda na rowerze ;-)
macOS 26 ma swoje problemy
Czy Brillo czeka los tagów NFC?
"Arystokraci" od siedmiu boleści

Wiedźmin +, Heweliszu ~ ;-)

Obejrzałem Wiedźmina i Heweliusza.

Wiedźmin nie był zły, te 2 lata temu przeszedłem przez wszystkie książki i OK, Sapkowski to nie jest mój ulubiony autor ;-)

Ale poza pewnymi rzeczami jak Yennefer która wszędzie lata portalami i obrona zamku to wydaje mi się, że blisko książkowego oryginału. Jeszcze Szczury były bardziej antypatyczne i z tego co pamiętam Jeż od początku chyba wiedział, że to nie jest Ciri... i nawet ją polubił? 
Stąd Wiedźmin na plus.

Heweliusz... technicznie świetny. Aktorsko świetny. Scenariusz wciąga.

Ale, jakoś tak mi brakuje. Jak go porównuję do Wielkiej Wody i Czarnobyla to to nie jest to...

W Wielkiej Wodzie miałem bohaterów za których trzymałem kciuki, tutaj nie. Najciekawsze są postaci poboczne, pani doktor w Niemczech, syn żony kierowcy, nawet ksiądz. 
Ale poza synem żony kierowcy żaden bohater "nie rośnie", nie rozwija się.
Smutne wszędzie.

Do tego po co ten wątek teoriospiskowy? Jak rozumiem w teorii spiskowej to broń mogła być na rumuńskich wagonach, ale tutaj dodano że na ciężarówce. Po co w ogóle Polskie Wojsko z WSI miały przemycać broń do Szwecji w 1993 roku? Czemu mieliby spowodować wypadek ławnika, skąd w ogóle wiedzieli o taśmach? Skąd wiedzieli, że się spalą? No i po co mieli tuszować to, że tam mógł byc niemiecki kuter? 

Stąd Heweliusz jest pierwszym serialem na Netflix, który obejrzałem, podobał mi się i nie dałem mu żadnej oceny ;-)

Za to nie mogę się zmusić do oglądania reszty Last of Us 2, ani 3 sezonu Fundacji i utknąłem (podobnie jak w Last of Us) w połowie Alien Earth.... ale zbliża się Stranger Things 5 :-)

Podobne posty^beta
Wiedźmin mnie pokonał ;-)
"Dziennikarze"
3 sezon Wiedźmina był jak narazie najlepszy ;-)
Kto sieje wiatr
Książkowy wrzesień

_ w Java'ie :-)

Ha! dziś się naumiałem, że w końcu w Java'ie (może od 21, ja to 25 sprawdziłem) _ jest zmienną "throw away" :-)

O co chodzi?

Np. jeśli robimy coś takiego:

m.computeIfAbsent(key, k -> new ArrayList<>()).add(val);

to to k jest zmienną, jak na zewnątrz jest zmienna k to mamy problem i się nie skompiluje:

var k = 7;
m.computeIfAbsent(key, k -> new ArrayList<>()).add(val);

bo będzie sie pluło w k ->, że k jest już zadeklarowana w scope'ie...

Teraz można użyć _ zamiast k:

m.computeIfAbsent(key, _ -> new ArrayList<>()).add(val);

co niby nie robi różnicy (chociaż od pewnego momentu taki kod się nie kompilował), ale teraz można mieć coś takiego:

var _ = 7;
m.computeIfAbsent(key, _ -> new ArrayList<>()).add(val);

i się skomplikuje bo to _ jest throw away... więc np. takie coś:

var _ = 7;
System.out.println(_); // <--- Using '_' as a reference is not allowed
m.computeIfAbsent(key, _ -> new ArrayList<>()).add(val);

to kompilator zakrzyknie, że ej, nie wolno.

Mała rzecz, a cieszy :-) 

Podobne posty^beta
Java 8 + lambdy = wolno ;-)
Zaczynam woleć Map nad Map ;-)
Javozagadka ;-)
Który kod (nie kot! ;-)) lepszy?
"Nowy" java.net.http.HttpClient jest cool :-)

LLM LLMowi nierówny jeśli chodzi o kod :-)

Tak sobie znów robię zadanka koderskie i tym razem odwołuję się do LLMów z prośbą o ocenę... i nawet nie wiecie jak to boli jak Ci pisze taki LLM, że Twoje rozwiązanie jest złe, bo niedość że ma błąd to nawet jakby było bez tego błędu to i tak jest dużo lepszy algorytm ;-)

Ale ciekawa sprawa, jak w takim codziennym użyciu LLMów wydaje się, że Gemini jest lepsze od ChatGTP, to tutaj ChatGPT zdecydowanie bardziej ogarnia.

Gemini twierdzi, że kawałek kodu jest błędny, Ty sprawdzasz i Tobie pasuje, pytasz ChatGPT, mu też pasuje... dyskutujesz z Gemini. W końcu Gemini Ci pisze TWÓJ kod jako prawidłowy i upiera się, że Twój jest nadal zły, choć potrafi oba przedstawić jeden pod drugim....

Tym razem w nauce próbuję postawić też na optymalne rozwiązania ;-) bo kiedyś umiałem tak pisać, późnej mi się w głowie porobiły skróty i jak widzę "zadanko" to często wiem jak je rozwiązać niemal od razu, ale często idę algo które nie jest optymalne.

Stąd sprawdzam czy ta nowa metoda mi pozwoli zresetować mój mózg ;-)

Chciałbym jeszcze czytać The Algorithm Design Manual, albo Introduction To Algorithms, ale jakoś tak mi one ostatnio nie wchodzą... urok słabszego wzroku ;p i małej czcionki w książce i na iPadzie ;-)

Gemini ma też swoje plusy, w tym tygodniu robiłem prezentację jednego z naszych API, i dość nudno tak robić taką prezentację używając PostMana czy Bruno... więc popełniłem małe tałatajstwo, które używa fetch. Wyglądało brzydko, to dałem to Gemini... i Gemini wypluł śliczną stronkę, z guziczkami i checkboxami, do tego później dodał parsowanie JSONa tak, że go formatuje (i niektóre rzeczy są np. linkami :-)), a do tego apiKey potrafi zapisać w localStorage :-)

Podobne posty^beta
Przydałby się "reset" w głowie ;-) Dlaczego powtórka algorytmów męczy bardziej niż nauka.
ChatGPT i Gemini (ogólnie LLMy) to są jednak nowe wyszukiwarki
Bawię się GPT4All
Kopernik i zasada kopernikańska, później Darwin i Teoria Ewolucji... co będzie kolejne? Silne AI czy synetyczne życie?
ChatGPT - do czego i do czego nie ;-)

Nadal jestem zachwycony moim Macbookiem Air z M4 :-)

Macie tak, że zakup który robicie tak trochę "a nie wiem czy dobrze robię", albo kupujecie na próbę okazuje się być świetny, a taki wyczekiwany takim sobie?

Ja mam teraz tak z Macbookiem Air z M4.

Jak go kupowałem te ~2 miesiące temu to nie było we mnie tej pewności, że to będzie super zakup. Było ciągle takie "a czy on podoła zastąpić mojego Macbooka Pro z 2018 roku? To ma tylko 24 GB RAM, nie 32", albo "a kolor taki dziwny trochę" i podobne.

A od dnia kiedy przybył chyba nie mam momentu żeby nie było "rany boskie, ale to jest fajna zabawka".

Niemal każda minuta używania tego Macbooka Air z M4 to jest przyjemność :-)

Przyznam, że już prawie nie używam mojego starego MBP z 2018, ani MBA z 2020... oba miały Intele.

W tym MBA mi się też bardzo, ale to bardzo podoba bateria. To ma baterię. Zawsze, od pierwszego laptopa, którego miałem (w 2002 roku kupiłem pierwszego), zawsze miałem to, że chciałem przebywać blisko gniazdka bo bateria się wyczerpuje.

Teraz pierwszy raz mam tak, że nie myślę o baterii... Kiedyś jak bateria była w okolicach 20% to było "rany boskie, trzeba szukać prądu", a teraz jest "OK, za jakiś czas dobrze będzie podpiąć drania do baterii".

No zachwyt mam i tyle :-)

Z zakupów w drugą stronę to np. Nintendo Switch, czy Steam Deck ;-) jakoś to nie są cosie, których nagminnie używam... w Switchu telewizor zawsze był za mały, a znów w Steam Deck (mam tego z OLED i 1 TB) mam wrażenie jakby nie było baterii ;-)
Chociaż może być po prostu tak, że jednak konsola to nie jest coś dla mnie.... Mam 4 konsole ;-)

Ale ten MBA jest wielki. Szczerze mógłbym nawet go używać do pisania kodu. Co prawda wolę do tego jednak mojego Maca Mini (z M4 Pro i 64 GB RAM ;-)), ale nawet to maleństwo by dało radę.

Podobne posty^beta
Steam Deck OLED po 24h :-)
Bestyjka - nowy mac podróżny ;-)
Ostatni Rammstein... przynajmniej w 2024 ;-)
Umykający postęp
macOS 26 ma swoje problemy

macOS 26 ma swoje problemy

Coś nie do końca pewne apki z nim lubią działać.

Bartender 5 w ogóle poległ, niby nic, tylko górny pasek potrafi dostać hopla i ciągle kraść kursor. Więc de facto nie da się tego używać.

Bartender 6 wcale nie jest dużo lepszy, działa, działa... i nagle przestaje działać.

Yoink! lubi znikać, a nawet jak nie znika to się trzyma jednego workspace'a.

Chciałem jeszcze dodać CopyQ, ale nie to na poprzednim macOS mi szwankuje, na macOS 26 akurat działa w miarę dobrze.

Większość tych problemów jest taka nie do końca oczywista, nie zawsze je widać, trzeba na nie czekać, ale tak parę razy w ciągu dnia się potrafią zdarzyć.

Widziałem je tak na Macu Mini (M4 Pro z 64 GB RAM) i Macbooku Air (M4 z 24 GB RAM), więc to nie jest do końca coś związanego ze sprzętem.

Podobne posty^beta
Za "mądry" system
Życie artysty jest trudne - System Extensions na macOS z ARMem...
Nadal jestem zachwycony moim Macbookiem Air z M4 :-)
OpenOffice.org2GoogleDocs v1.0.0 :-)
Zaczynam się przekonywać do agentów AI....

Zacznę dodawać do swoich prywatnych projektów NEXT_STEPS.md

Będę od dziś próbował do moich projektów dodawać sobie plik NEXT_STEPS.md ;-) w którym będę próbował zapisać co ostatnio zrobiłem i dlaczego, oraz co chcę zrobić w przyszłości.

Na razie zaczynam, więc to są luźne myśli. Ale zawsze mi brakowało takiego miejsca i próbowałem w różnych Obsidianach i innych... tym razem spróbuję w kodzie ;-)

Bo gdy dzień się kończy, człowiek kończy zmiany w kodzie to ma w głowie jakieś pomysły, a jak wraca do kodu to te pomysły mogą już być dawno zapomniane.... jak to jest kod pracowy to się zwykle doń wraca dość szybko, więc taki dokument nie jest potrzebny, bo się zwykle pamięta, ale w prywatnych projektach to może być przydatne.

Dla firmowych przydatny mógłby być dokument, który tłumaczy czemu coś zrobiono tak, a nie inaczej. Nie chodzi mi o ADRy, które próbują udawać obiektywność, a o coś co dokumentowałoby "tak, trzymamy wygenerowane credentiale w postaci niezaszyfrowanej, to może być problem, na razie trzymamy je w bazie pod kluczem "UGLY_HACK", w przyszłości jeśli do tego wrócimy bo np. okaże się, że to łamie zasady bezpieczeństwa, to idea jest taka by pod tym samym kluczem (bez UGLY_HACK) trzymać obiekt w którym będą zaszyfrowane credentiale i id klucza użytego do szyfrowwania, WAŻNE klucz powinien być trzymany w AWS Secret Managerze i pobierany leniwie, id klucza może być z kropką do oddzielenia głównego klucza z wersją" i jak ktoś znajdzie w kodzie to co go niepokoi to mógłby przeczytać czemu i od razu wiedziałby jaki był zamysł.

Zobaczę czy będę to stosował, na razie dodałem do 1.5 projektu ;-)

Podobne posty^beta
Strasząca książka - Extinction: The Thriller
Generowanie plików ePub z OpenOffice.org :-)
Mam milion rzeczy na głowie... co robić?
Żenienie Todoist z Obsidian przy pomocy Pythona ;-)
Nie lenistwo, a strach. Prawdziwe źródło długu technicznego