PHP, Node.js, C#
Nowe osoby w projekcie i to takim trwającym już od pewnego czasu to niemałe wyzwanie. Baa, to cały proces, który może trwać dłuższy czas. Dotyczy nie tylko lidera zespołu ale także każdego członka zespołu. Różnorodność procesów, technologi, wzorców oraz rozwiązań typowych problemów sprawia, że łatwo przytłoczyć „nowego” ?? ilością informacji. Finalnie zapamiętując niewielki fragment. Co tak na prawdę jest niezbędne, aby zagłębić się w projekt? Kilkaset stron dokumentacji biznesowej, dostarczonej programiście w pierwszy dzień pracy, nie jest najlepszym zachęceniem do pracy. Jako programiści nasze pragnienia są zupełnie inne – interesuje nas kod, architektura oraz cała techniczna otoczka projektu nawet ta dotycząca utrzymywania legacy code. Podczas tego odcinka dzielimy się swoimi doświadczeniami i przemyśleniami z perspektywy lidera oraz osób zaczynających prace w istniejących projektach. Staramy się odpowiedzieć na czym warto się skupić i kto powinien być odpowiedzialny za onboarding. Chciałbym Cię poprosić o garść Twoich przemyśleń i doświadczeń: ? Czy pamiętasz jak wyglądało wdrażanie Cię w trwające projekty? ? Czy jest coś co szczególnie zapadło Ci w pamięć? ? Czego unikać podczas wdrażania nowych osób do trwającego projektu? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Odcinek specjalny z okazji ? Międzynarodowego Dnia Podcastów ? Jako twórcy polskich podcastów IT odpowiadamy na pytania Grzegorza Kotfisa (Devsession) - czym są podcasty, co dają nam osobiście, jakie są ich zalety i mówimy o kulisach ich realizacji. W tym wyjątkowym odcinku znaleźliśmy się także MY ? Co jest dla nas nie małą satysfakcją, że to co robimy staje się widoczne i doceniane przez innych ? W odcinku usłyszycie także wypowiedzi autorów podcastów: ▶️ Ostra Piła ▶️ Podcast "Porozmawiajmy o IT" ▶️ devstyle.pl - Maciej Aniserowicz ▶️ Javadevmatt - Mateusz Kupilas ▶️ Devsession - Grzegorz Kotfis Do usłyszenia!
My – programiści poświęcamy zbyt wiele czasu na sprawy o niskiej wartości biznesowej. Rozwiązujemy ? problemy, które mogą się nie wydarzyć. Przeciwdziałamy zapobiegawczo sytuacjom, których prawdopodobieństwo wystąpienia jest mniejsze niż 1% poświęcając na to olbrzymie pokłady energii, czasu oraz nadwyrężając budżet ? inwestora… Tytułowy overengineering może objawiać się na wielu płaszczyznach – definiując jednak najważniejsze trzy – może dotyczyć on: ▶️ rozwiązań funkcjonalnych, które nie są wykorzystywane przez klientów aplikacji, ▶️ architektury, która rozwiązuje lub „zapobiega” nie istniejącym problemom, ▶️ kodu, który przewiduje zmiany w obszarze, który się nigdy nie zmieni. Podczas tego odcinka podcastu, zahaczamy o tematy związane z praktykami Extreme Programming wspomagającymi rozwiązywanie problemów w łatwy i prosty sposób, starając się odpowiedzieć na pytanie: Kiedy nasze rozwiązania są zbyt przekombinowane? Wychwycenie odpowiedniej równowagi pomiędzy rozwiązaniem technicznym, a problemem biznesowym jest bardzie ciężkie. Podczas tego odcinka podcastu Dev:Cast ? staramy się określić co odbierane jest w sposób negatywny jako overengineering. Warto również poświęcić kilka minut na świetny artykuł "How To Accept Over-Engineering For What It Really Is". Mam do Ciebie jednak dodatkowe pytania: ? Spotkałeś się kiedyś z rozwiązaniami, które technicznie wyprzedzały wymagania projektu o lata świetlne? ? Kto powinien dbać o zachowanie równowagi pomiędzy dostarczaniem, a rozwiązaniem technicznym? ? Czy wszystko zawsze musi być w 100% doskonałe technicznie? Jeżeli chcesz, to podziel się swoją opinią, zostawiając nam krótki komentarz pod artykułem. Będziemy bardzo wdzięczni za rozpoczęcie konwersacji ? W końcu warto się wymieniać doświadczeniem – co nie? ?
Udostępnianie interfejsów programistycznych w formie WebAPI stało się pewnym standardem. Integrujemy ze sobą różne systemy – komunikując je w celu wymiany wymaganych danych. Popularne serwisy udostępniają swoje dane, by programiści mogli wykorzystać potencjał zagregowanych danych. ? Jak natomiast podejść do projektowania API, które będzie dostępne dla konsumentów? Na co zwracać uwagę? Na te pytania staramy się odpowiedzieć w nowym odcinku podcastu Dev:Cast ? Na koniec mam jeszcze do Ciebie trzy pytania: ▶️ Czy projektowałeś kiedyś WebAPI? ▶️ Na co zwróciłbyś jeszcze uwagę? ▶️ Jakie elementy muszą zostać dobrze zaprojektowane by w przyszłości nie utrudniały wykorzystywania WebAPI? Daj nam znać w komentarzu. Do usłyszenia ✌️
Zarządzanie zespołem składającym się z specjalistów w branży IT nie jest łatwe. Często osoby będące programistami zmieniają swoją ścieżkę kariery, stając się liderami zespołu. Czy jednak Team Leader musiał być wcześniej osobą techniczną? Czy musiał ukończyć studia informatyczne? Może jednak w branży potrzeba nam więcej humanizmu aby uzupełnić proces wytwarzania oprogramowania? Strasznie dużo pytań… ? Na część z nich staramy się odpowiedzieć w tym odcinku. Pytanie otrzymaliśmy od Marceliny w ramach konkursu Code Europe i jest zarazem jednym z pierwszych, które poruszać będziemy na łamach naszego podcastu Dev:Cast. Zapraszam do odsłuchu ? Jakie są Twoje doświadczenia? Lider zespołu, który nie posiada kompetencji technicznych nadaje się na zarządzanie zespołem IT? Czy może to totalnie nietrafiony pomysł? ⛔
Czy osiągnięcie pułapu Senior Software Developera to koniec programistycznego rozwoju kariery? Czy każdy dobry programista staje się po pewnym czasie Project Managerem? ? Może to gdzie zmierzamy zależy tak na prawdę od nas samych? Z Marcinem rozmawiam na temat kariery programisty na jego z życia wziętym przykładzie. Przykładzie, który pokazuje rozwój i przekształcenie do innej roli. Nie zawsze zostając programistą ⌨, jesteśmy nim do końca życia. Często szukamy nowych wyzwań – wcześniej dla nas niedostępnych ze względu na brak wymaganego doświadczenia. Zainteresowany jak wygląda kariera Marcina w świecie IT zapraszam serdecznie do jedenastego odcinku podcastu ? Dev:Cast. A Ty zostaniesz programistą do końca życia? … ja na razie nie wyobrażam sobie innej opcji ?
Sieć pełna jest porad dotyczących dobrych praktyk tworzenia oprogramowania. Możemy czytać o SOLID, DRY, KISS, Demeter, GRASP. Pytanie czy to jednak wszystko? Czy wyczerpujemy tym samym listę praktyk, które są warte uwagi. Z naszego punktu widzenia – ZDECYDOWANIE NIE! Jest jeszcze wiele elementów, które warto wykorzystywać podczas procesu wytwarzania oprogramowania. Dlatego, w 10-tym odcinku podcastu Dev:Cast zdecydowaliśmy się zebrać 10 zasad (nie bez przyczyny ?), które według nas są kluczowe aby fachowo wykonywać swoją programistyczną robotę – bez względu na wykorzystywany paradygmat, język czy ograniczenia biznesowe. ? Nasz TOP 10 dobrych praktyk tworzenia oprogramowania ? 1. Single Responsibility Principle 2. Nazewnictwo oddające intencję 3. Zasada małych kroków 4. Wybór odpowiednich narzędzi do rozwiązywanego problemu 5. Nie komplikuj – sięgaj po najprostsze rozwiązanie 6. Rozwiązuj, a nie generuj problemy 7. Znajdź równowagę pomiędzy wymaganiami, ograniczeniami, a implementacją 8. Analizuj => Planuj => Działaj 9. Jedyną stałą, jest zmiana 10. Dostarczaj działający kod Krążąc przy „zasadzie małych kroków” wspomnieliśmy o S.M.A.R.T., a rozmawiając o „nie komplikuj – sięgaj po najprostsze rozwiązanie” przewinął się wątek prześmiewczego rozwiązania zadania FizzBuzz. Na koniec czekała na nas mała niespodzianka… Podsumowując temat wyszło nam, że „matką” wszystkich zasad, która przynosi niesamowite korzyści, a jest często pomijana… Jest TECHNIKA TDD ? Więcej o niej możecie poczytać na stronie Dariusza Woźniaka, gdzie znajdziecie najfajniejszy, darmowy kurs TDD ? Czy dobre praktyki tworzenia oprogramowania zostały przez nas wyczerpane? Co dodałbyś od siebie? Co jest ważne w codziennej pracy programisty?
O Coding Dojo pisałem całkiem niedawno, w odniesieniu do działającej na śląsku inicjatywie. Tym razem jednak udało mi się porozmawiać z organizatorami Coding Dojo Silesia na temat Coding Dojo oraz samej inicjatywy. Tak aby dowiedzieć się więcej o wymaganiach, tego co można się nauczyć, grupie docelowej oraz formie spotkania. Marek oraz Michał organizują 28 czerwca kolejną edycję swojego wydarzenia, będzie dotyczyć ona języka PHP, gdzie my, autorzy DevEnv wystąpimy w roli wsparcia mentorskiego ? Spotkanie startuje o 18:00 i odbywa się w katowickiej siedzibie firmy Clear Code. Jak sami organizatorzy zapewniaj nie zabraknie pracy w parach, rozkminy nad kodem, networkingu z innymi programistami oraz czegoś dobrego na ząb i soku z gumijagód ? Wszelkie dodatkowe informacje uzyskacie na podstronie wydarzenia: "Coding Dojo Silesia #3 – PHP edition", a tym czasem zapraszam was do odsłuchu dziewiątego odcinka podcastu Dev:Cast!
Podział odpowiedzialności w zespołach często bywa bardzo jasno określony. Zdarzają się jednak sytuacje kiedy wymagania względem wykonywanej pracy nie mają za dużo wspólnego z faktyczną rolą projektową. Zdarzało mi się zastępować Team Leader, działać w roli Lead Quality Assurance – na tyle na ile pozwalała mi wiedza i umiejętności. Takie kołczingowe wychodzenie poza strefę swojego komfortu ;) Jednak nie jest to zadanie łatwe, obawy przed przejęciem odpowiedzialności bywają nieco paraliżujące – nie ma co się dziwić, chcemy pokazywać się tylko z dobrej strony, zapewniając, że jesteśmy profesjonalistami. Jednak bycie profesjonalistą oznacza czasem przekroczenie granicy, która definiuje nas właśnie w tym pojęciu. W ósmym odcinku rozmawiamy o tym dlaczego programiści, pracujący w interdyscyplinarnych (dodałbym pseudo) zespołach boją podejmować się zadań związanych z testowaniem dostarczonych funkcjonalności. Co robicie gdy w iteracji zaczyna brakować zadań dla programistów, a testerzy nie wyrabiają? Dodajesz kolejne zadania do todo czy jednak rozmawiasz z zespołem programistycznym, aby przetestował zadania czekające na fazę testów? Daj znać w komentarzu! Jingle Music by: www.bensound.com
Kontynuując wątek Legacy Code chcemy przedstawić wam sposoby na jego ujarzmienie. Praca z Legacy Code może stawiać nie lada wyzwania ale także być przyjemna. Nie zawsze także rozchodzi się o całościowe przepisywanie projektu – szanujemy swój czas oraz pieniądze naszego klienta. Czasem wystarczają proste zmiany w obrębie wybranych komponentów aby usprawnić sobie co dzienną pracę z systemem. W siódmym odcinku definiujemy sobie sposoby wdrażania usprawnień – większy oraz mniejszych w Legacy Code, wdrażając je „przy okazji” lub „planując z góry”. Wspominamy także o bardzo ważnym aspekcie, który często jest pomijany, a przynosi niesamowite efekty podczas badania odziedziczonego kodu tzw. spike. Jak wy pracujecie z odziedziczonym kodem? Jakie stosujecie praktyki? Jak radzicie sobie z planowaniem zmian? Jeśli masz coś dodania, to serdecznie Cię zapraszamy do zostawienia komentarza pod odcinkiem ? Jingle Music by: www.bensound.com
Gdy słyszysz Legacy Code dostajesz gęsiej skórki? Nic dziwnego. Jest wiele negatywnych elementów, które w odziedziczonym kodzie utrudniają dalszy rozwój oprogramowania. To chociażby spagetti code, duplicated code, czy nie deterministyczne testy jednostkowe. W szóstym odcinku podcastu rozmawiamy o tym czym jest tytułowy Legacy Code oraz co nas w nim denerwuje – jakie elementy sprawiają, że po dniu pracy mamy dość, a Bartek najchętniej siałby kukurydze na swoim polu ;) Chcemy kontynuować w kolejnych epizodach Dev:Cast tematykę utrzymywania oraz rozwoju odziedziczonego kodu, tak aby praca z nim stawała się łatwiejsza, a zarazem dostarczała nam frajdy i satysfakcji. Jakie elementy o których nie wspomnieliśmy wkurzając Cię najbardziej w utrzymywaniu Legacy Code? Podziel się z nami swoimi spostrzeżeniami w komentarzu :) Jingle Music by: www.bensound.com
Początkujący programiści często zadają pytanie jaki powinien być lub jaki wybrać pierwszy język programowania? W gąszczu dostępnych form komunikacji ze światem binarnym ciężko na początku się odnaleźć. Nie wiadomo jaki punkt zaczepienia chwycić, czym się sugerować. Bywa i tak, że ten pierwszy język programowania jest wynikiem wielu losowych czynników – studia, post na forum, znajomy programista. W piątym odcinku Dev:Cast rozmawiamy o wyborze pierwszego języka – jak się zabrać za wybór, czym się kierować. Dyskusja była na tyle obfita w ciekawe stwierdzenia, że przekroczyliśmy nasz umowny limit 20 minut. Mamy nadzieję, że nieco dłuższa forma nie będzie wam tym razem przeszkadzała. Jak myślicie na który z języków padł nasz typ? Co polecamy? Który według was język programowania warto wybrać na początek? Od czego Wy zaczynaliście? Jak ma się on teraz do waszej pracy? Zachęcamy do dyskusji w komentarzach. Jingle Music by: www.bensound.com
Czy automatyzując analizę kodu do maksimum, ciągle potrzebujemy przeprowadzać Code Review? Czy czynnik ludzki będzie jeszcze wtedy potrzebny? Czy nie jest to moment kiedy fundamenty przeglądu kodu nie mają racji bytu? W czwartym odcinku Dev:Cast rozmawiamy o sensowności procesu Code Review. Szukamy elementów, które ciężko będzie zastąpić nawet najbardziej wyrafinowanymi automatami. Zastanawiamy się i rozmawiamy o wymianie wiedzy poprzez Code Review. Pada również stwierdzenie, że junior developer powinien czytać kod tworzony przez bardziej doświadczonego programistę. Zgadzacie się z tym? Jakie jest wasze nt. przeglądów kodu? Stosujecie ten proces w praktyce? Jak wygląda on u was? Jak się u was sprawdza? Jingle Music by: www.bensound.com
Praca zdalna, nawet ta sporadyczna wymaga odpowiedniego przygotowania. Wszystko z pozoru wygląda na prostą sprawę, jednak nagle okazuje się, że pomimo 12 godzin przed komputerem nie ma namacalnego efektu. Tu coś nas rozproszyło. Następnie oderwaliśmy się od komputera dosłownie na minutę, a finalnie wpadliśmy w wir obowiązków domowych – sprzątając, porządkując czy wyjeżdżając na szybkie, 2 godzinne zakupy :) Aby nasza praca zdalna była efektywna, należy przygotować się na poziomie: - technicznym – który może obejmować konfigurację VPN, środowiska developerskiego, konfiguracji mikrofonu oraz słuchawek; - mentalnym – abyśmy faktycznie pracowali np. poprzez ustalenie konkretnego timeboxu; - przestrzennym – by móc usiąść w miejscu, gdzie jest nam wygodnie i bez przeszkód możemy wykonywać swoją pracę. Podczas rozmowy, poruszamy tematy związane z tym jak się przygotować do pracy zdalnej oraz na co zwracać szczególną uwagę. Tak aby nasza praca była bardziej efektywna i przede wszystkim, nie zaczynała się o godzinie 8:00 i trwała do późnej nocy – oczywiście mam na myśli, 8 godzinny dzień roboczy :) Lubisz popracować zdalnie, ale coś ciągle odwraca Twoją uwagę? Domownicy nie dają Ci spokoju? Zapraszamy do trzeciego odcinka podcastu Dev:Cast, może zaproponowane rozwiązania będą Ci pomocne. Jingle Music by: www.bensound.com
Nadeszła pora aby przedstawić drugi odcinek podcastu Dev:Cast. Tym razem dyskutujemy o temacie Tomasza, który brzmiał: "dlaczego developerzy boją się odbijania notek". Rozmawialiśmy o tym czemu boimy się popełniać błędy i co jest przyczyną strachu. Staraliśmy się szukać rozwiązania w oparciu o budowanie przyjaznego środowiska, które pozwala na popełnianie błędów. Błędów które powinny służyć nauce. Podczas rozmowy bardzo szybko okazało się, że każdy z nas ma doświadczenia z sytuacjami, gdzie popełniony błąd traktowany był w negatywny sposób. Nawet ten trywialny. Jeżeli w Twoim otoczeniu panuje przekonanie, że za błędy należy karać – ten podcast jest dla Ciebie. Może to jest powodem przeciągających się terminów realizacji zadań?
PHP, Node.js, C#
Na co dzień Software Engineer. Fascynat programowania, architektury, metodyk zwinnych i dobrych praktyk w szerokim ujęciu.
Polyglot Programer kochający poznawać nowe języki jednocześnie wykorzystując ich najlepsze strony. Założyciel DevEnv i współautor podcastu Dev:Cast.
After Hours czyli gdy nie pracuje i nie robi czegoś na DevEnv - podróżnik w miejsca zapomniane, pasjonat lokalnej historii. Mocno zajarany survivalem, urbexem i militariami. Jest jednym z opiekunów schronu bojowego WAWOK w Rybniku.