DiscoverDevEnv - O programowaniu bez kaca
DevEnv - O programowaniu bez kaca

DevEnv - O programowaniu bez kaca

Author: Adrian Piętka, Bartłomiej Michalski

Subscribed: 117Played: 1,927
Share

Description

Rozmawiamy o procesie wytwarzania oprogramowania bez kaca. Podejmujemy tematy związane z dobrymi praktykami, metodykami oraz procesami, które towarzyszą na co dzień programistom.
59 Episodes
Reverse
Koncentracja, brak rozdrażnienia, motywacja i chęć działania, to praktycznie niezbędne narzędzia sprawnego programisty. To one pomagają realizować nam codzienne wyzwania. Zmęczony programista to swego rodzaju producent błędów i niezbyt udanego kodu. Ja to nazywam programowaniem na odwal sie. W dobie pędzącego życia łatwo popaść jest w sytuację opisaną powyżej, dlatego w tym odcinku naszym gościem jest Kamil Lelonek, który tłumaczy…Jak wspomagać swój organizm w poprawieniu skupienia i efektywności?Sporo rozmawiamy czym jest biohacking, suplementacja, mikrodawkowanie, jak działa kawa. Kamil wymienia między innymi trzy suplementy, którymi warto się zainteresować. Dzięki temu CDP Cholina, L-Teanina czy Kordyceps nie jest już dla mnie niczym tajemniczym 🙂Początkowo myślałem, że Cytochrom P450, to rodzaj trunku, bo taka odpowiedź pojawiła się, po tym jak zapytaliśmy o wpływ alkoholu na nasze samopoczucie. Na szczęście Kamil wytłumaczył nam rolę tego enzymu.Ale to nie wszystko, bo na koniec pojawia się fajna anegdota na temat myszki komputerowej, interfejsu graficznego oraz copy&paste.
Rozwiązania, które umożliwiają nam tworzenie gotowego oprogramowania, stron internetowych czy witryn, bez większych umiejętności programistycznych towarzyszą nam od dawna. Front Page, Drupal, jPortal, WordPress – długo by wymieniać oprogramowanie, które nazwaliśmy dość luźno pierwowzorami dzisiejszych Low-Code i No-Code. Dziś to tylko niewielka część tego co możemy wykorzystać.Kolejny sklep internetowy, kolejny landing page, kolejna strona firmowa czy newsletter. To wszystko, a nawet i więcej biorąc pod uwagę narzędzia automatyzujące procesy, możemy stworzyć bez znajomości wymaganych technologii. Powstały rozwiązania, które za pomocą przyjemnego i prostego interfejsu użytkownika możemy w łatwy sposób wykorzystać, aby dostarczyć wartość biznesową. Czy to jednak znaczy, że w niedalekiej przyszłości…Rozwiązania Low-Code / No-Code zastąpią większość programistów?W podcaście dyskutujemy ze znawcą tematu – Szymonem Paluchem, o przyszłości programistów. Podejmujemy także temat tego, czy czasem rozwiązania Low-Code, No-Code nie są czasem łatwym wejściem w świat IT?Jaka jest rola programistów w dobie oprogramowania, rozwiązującego częste problemy biznesowe? Czy po raz kolejny, Bartek musi implementować newsletter? Czy łatwiej skorzystać z rozwiązań typu MailerLite?
Pamiętam, kiedy pierwszy raz moja serdeczna koleżanka z zespołu, zaprosiła mnie na rozmowę z klientem. Byłem młodym, 19-letnim programistą, który od roku pracował jako programista. To było dla mnie nie lada przeżycie – stres i obawa czy wypadnę w miarę przyzwoicie.Dreszcz emocji do dzisiaj pojawia się podczas pierwszych rozmów z nowym klientem. Natomiast, późniejsza praca na co dzień staje się pewnego rodzaju rutyną. Wszystko to jednak efekt wielu lat pracy, nie tylko z klientem, ale głównie nad sobą.W tym odcinku mówimy o swoich doświadczeniach podczas pracy z klientem i o wypróbowanych modelach.Czy praca i rozmowa z klientem powinna być stresująca dla programisty?Udzieliliśmy także, kilku drobnych wskazówek, które pomogły nam w lepszej komunikacji z klientem. Może warto się z nimi zapoznać?
Temat wzorców projektowych pojawia się w ramach DevEnv dość często. To za sprawą tego, że widzimy w nich pozytywny aspekt, wpływający na kod. Natomiast jak ze wszystkim – zdecydowanie z dawką rozsądku i umiaru. Dlatego staramy się przekazać, co o nich wiemy oraz dzielimy się doświadczeniami w ich stosowaniu.Tym razem poruszyliśmy bardzo otwarty temat, ponieważ zastanawiamy się co dalej w momencie, gdy poznamy podstawowe wzorce projektowe. Jak się odnaleźć i na co zwracać uwagę podczas ich stosowania.Na co uważać w pracy ze wzorcami projektowymi?Czy łatwo jest rozróżniać zaimplementowane wzorce w kodzie od siebie? Czy wzorce z reguły można by było nazwać antywzorcami?
Chmura publiczna na dobre zagościła w naszych projektach. Wykorzystywana w większym i mniejszym zakresie ułatwia osiągać wyznaczone cele projektowe. Niestety jak każde narzędzie, niesie ze sobą pewną pulę nowych problemów. Dlatego postanowiliśmy porozmawiać z Wojtkiem Gawrońskim, specjalistą AWSa o tym, co niesie ze sobą chmura publiczna.Jakie korzyści zyskują programiści podczas pracy z chmurą?Na co uważać podczas pracy z chmurą? Jak chmura publiczna może przyśpieszyć dostarczanie rozwiązania biznesowego?Konkretne przykłady, to coś, co w tym odcinku podcastu zostało nie raz poruszone. Jednym z nich jest projekt, o którym opowiada Wojtek, który został dostarczony szybciej, niż standardowo zakładano, dzięki właśnie, znajomości usług chmurowych.
QA, BA, PM, PO, Scrum Master. Wszyscy mają wspomagać zespół programistów w lepszym realizowaniu zadań. W pewnych firmach, nawet dostajemy w zespole projektowym „zestaw” tych wszystkich ról. Natomiast programuje dosłownie jedna osoba.Czy potrzebujemy tych wszystkich ról zawsze? Czy część kompetencji nie może być, częścią pracy programisty?Jak radzić sobie, gdy tych ról/kompetencji brak?W tym odcinku podcastu rozmawiamy o tych wszystkich rolach pomocnych podczas tworzenia oprogramowania. Pytanie tylko, czy niezbędnych?
Programowanie zawsze wzbudzało we mnie skrajnie pozytywne emocje. Gdy zacząłem zawodowo pracować jako programista, było jeszcze lepiej. Nie robiłem już tylko projektów do szuflady, ale były one publicznie dostępne – setki osób mogło, korzystać z tego, co stworzyłem. To było świetne. Niestety wraz z upływem czasu, zaczęły pojawiać się pierwsze negatywne odczucia co do wybranej kariery zawodowej. Pierwsze pytania i zastanawianie się, czy to na pewno to. W końcu dotarłem do momentu, w którym dostarczenie jakiegokolwiek kodu było dla mnie niesamowitym wyzwaniem. Po prostu nie chciało mi się programować. Każda kolejna linia kodu powodowała wewnętrzne wkurzenie.Skąd w ogóle taki stan emocjonalny? Co poszło nie tak? Teraz gdy analizuję te sytuacje (bo było ich parę) można określić, że to, co robiłem, nijak miało się do tego, co rzeczywiście chciałbym robić. Przykład? Chciałem rozwijać się w technologiach backendowych, a 9 miesięcy musiałem spędzić po stronie frontendowej, tworząc UI w Angularze. Starałem się zmieniać środowisko, aby pojawić się w nowym i świeżym dla mnie miejscu, niestety nie zawsze tak szybko, jak bym tego chciał. Finalnie nie skończyło się jeszcze na wypaleniu, ale na pewno były to pierwsze kroki w jego kierunku.Jak poradzić sobie z pojawiającą się niechęcią do programowania?W tym odcinku rozmawiamy o naszych sposobach na radzenie sobie z tytułowym „mam dość programowania”. Jakie metody nam pomogły wyjść z dołka oraz jak dalej czerpać przyjemność z tworzenia oprogramowania.
Czy zdarzyło Ci się kiedyś zrobić taki błąd, po którym miałeś wrażenie, że wyrzucą Cię z pracy?Czy był to na tyle duży fuckup, że prawie zapadłeś/aś pod ziemie? A może to była idealna szansa do nauczenia się czegoś co zapamiętasz do końca życia?Błędy są czymś naturalnym w trakcie rozwoju. Niektóre musisz sam/a popełnić, a w niektórych przypadkach możesz uczyć się na błędach innych osób.50 jubileuszowy podcast zrobiliśmy w trochę inny sposób. Oddaliśmy głos naszym gościom, by mogli Ci opowiedzieć o swoich błędach oraz o tym czego się z nich nauczyli. Dlatego byś Ty już nie musiał/a ich popełniać 🙂Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Który z omówionych fuckupów jest Ci najbliższy? ;D➡️ Jaki był Twój największy fuckup podczas pracy w IT?➡️ Czego się dzięki niemu nauczyłeś?
Jest tyle niesamowitych rzeczy, które jako programiści na początku swojej drogi musimy poznać. Nowe technologie, nowe biblioteki, nowe techniki. Ciągle coś nowego. Jednak to dopiero stożek ogromnej góry lodowej, którą zaczynamy z biegiem czasu dostrzegać. Dochodzą do tego umiejętności miękkie, komunikacyjne, które są niezbędne do pracy w zespole.Bądź programistą, który zrobi to, co potrzebne jest zrobić.Drogi JUNIOR DEVELOPERZE, zebraliśmy kilka naszych luźnych rad, które pomogą Ci lepiej pracować w zespole. To nie nasze „widzi mi się” ale obserwacje siebie i naszych młodszych kolegów. Wszystko po to, abyś szybciej niż my, zrozumiał, że kod to nie wszystko 🙂Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ O czym powinien pamiętać JUNIOR DEVELOPER?➡️ Co powiedziałbyś samemu sobie w przeszłości?➡️ Jaka jest jedna najważniejsza rzecz, którą powinien wiedzieć JUNIOR DEVELOPER?
Deadline często kojarzy nam się w sposób pejoratywny. Natomiast często ustalamy sobie pewny zakres czasu, aby zrealizować pewne cele lub zadania – nie mając w tym, złej intencji. Podczas pracy w projektach, nie jednokrotnie spotkaliśmy się z ograniczeniami czasowymi, które wyznaczały dostarczenie zdefiniowanej funkcjonalności. Czy zatem możemy zadać pytanie:Deadline = Timebox?No właśnie. Czy deadline może posiadać pozytywny wydźwięk w zespole programistycznym?Skupiliśmy się podczas tego podcastu na odpowiedzeniu sobie, kiedy deadline jest sztywny i nie można go przesunąć oraz jak radzić sobie z ustalaniem scope, który ma zostać zrealizowany w określonym terminie. Bartek wspomina także o sytuacji, gdy osoba z zespołu chcąc dociągnąć rzeczy na czas, wylądowała na OIOM (Oddział Intensywnej Opieki Medycznej).Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się kiedyś z deadlinem w projekcie?➡️ Czy deadline często wiązał się z nadgodzinami?➡️ Jak sobie radzić w negocjacjach na temat, tego co dowieźć na określony czas?
Konteneryzacja, a zarazem jedna z najważniejszych implementacji w postaci Docker staje się powoli standardem w programistycznym świecie. Dlatego też postanowiłem porozmawiać z Damianem, specjalistą tego tematu. Jednym z najważniejszych pytań podczas naszej rozmowy było:W czym może pomóc DOCKER programiście?Jednak nie tylko na ten temat dyskutowaliśmy. Pojawiło się także kilka ważnych punktów, na które należy uważać podczas przygotowywania aplikacji do działania w postaci kontenera. Sporo także mówimy o tym, jak uruchamiać aplikację produkcyjnie, która zamknięta została do postaci artefaktu Docker Image.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się wcześniej z konteneryzacją?➡️ Czy wykorzystujesz Dockera w swojej pracy?➡️ Czy aplikacja nad którą pracujesz, posiada swój Docker Image?
W kanonie obowiązkowych narzędzi, które powinien znać każdy programista, spotykamy takie określenie jak WZORCE PROJEKTOWE. Niczym mityczna postać. Wszyscy słyszeli, a nawet kolega żony najlepszego przyjaciela nawet zastosował kiedyś SINGLETONA 😀Śmiechy i żarty, ale prawda jest taka, że wielu programistów wykorzystuje ograniczoną ich ilość. Ponieważ nie mają potrzeby stosowania innych lub je stosują, nie wiedząc o tym. Formy wzorców i ich zastosowanie jest różne. Czasem na siłę próbujemy, je upchać w miejsca, gdzie nie pasują. Czasem ich nie używamy pomimo, że istnieje ku temu zasadność.Jaką wartość dają WZORCE PROJEKTOWE?Luźno dyskutujemy o wzorcach – ich zaletach i wadach. Dyskutujemy o tym, czy faktycznie służą do ułatwienia komunikacji pomiędzy programistami, czy nie. Jaka jest ich inna rola?Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy wzorce projektowe są potrzebne programiście?➡️ Jakie wzorce projektowe według Ciebie są przydatne?➡️ Czy kiedykolwiek wzorce utrudniły Ci rozwój kodu?
Na początku marca tego roku w wielu firmach IT zapadła decyzja o rozpoczęciu w pełni zdalnej pracy. My, czyli osoby przyzwyczajone do pracy w biurze, musieliśmy sobie poradzić z nowym wyzwaniem. Zmieniła się forma komunikacji, miejsce pracy, a czasem też i sprzęt na którym wykonywaliśmy swoje obowiązki.Jak poradziliśmy sobie z wymuszoną pracą zdalną?Mając na uwadze nasz jeden z pierwszych podcastów – dobre praktyki pracy zdalnej, mogliśmy zastosować kilka zawartych w nim porad. Czy się przydały? Czy pomogły? O tym w najnowszym odcinku podcastu.PS. Jest też o tym czego nam brakuje, co pojawiło się pozytywnego oraz co nas irytuje 🙂Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy było Ci ciężko zmienić tryb swojej pracy?➡️ Jakie problemy pojawiły się podczas przejścia na pracę zdalną?➡️ Jak Ci się podoba długotrwała praca zdalna?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Czy istnieją jakieś zasady, które sprawią, że łatwiej będzie nam żyć z Legacy Code? Dokładnie nad tym zastanawialiśmy się ostatnio. Okazało się, że w swoim rękawie, jako programiści posiadamy trochę nabytych nawyków, które w sposób świadomy ułatwiają nam rozwój kodu. Nawet tego, który cuchnie stęchlizną.Jakie dobre praktyki warto stosować w Legacy Code?Podczas odcinka mówimy o swoich zasadach "Minimal Development Quality", które staramy się wdrażać tam, gdzie się pojawiamy. Oczywiście – z wiedzą, że nie zawsze mogą pasować one do sytuacji. Krzysztof zarzucił również ciekawą tezą, że to w Legacy Code najwięcej się można nauczyć? Zgadzasz się z tym?Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Lubisz kopać w starym kodzie nadając mu nowy kształt?➡️ Masz zestaw swoich praktyk, które starasz się stosować podczas tworzenia oprogramowania?➡️ Brownfield czy Greenfield?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Event Storming pomaga skomunikować zespół techniczny i część biznesową. Dzięki pewnym założeniom możemy opisać występujące procesy tak, aby obie strony w pełni je rozumiały. Tablica, kolorowe karteczki – czy to pomysł na rozwiązywanie problemów komunikacyjnych? No i inne pytanie, które coraz częściej sobie zadajemy jako świadomi programiści…Kiedy Event Storming przyniesie nam wartość?O podstawach Event Storming, Mariusz bardzo dużo opowiedział w podcaście Maćka Aniserowicza – DevTalk #110. Zachęcam do jego przesłuchania, bo tam usłyszycie o świetnie omówionych podstawach.My natomiast skupiliśmy na dalszych rozważaniach. Jakie wartości jako programiści możemy wyciągnąć z sesji Event Stormingowej, co może być artefaktem takie sesji oraz kiedy ES się nie sprawdza.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się wcześniej z Event Stormingiem?➡️ Czy miałeś okazję wypróbować w praktyce sesje Event Storming?➡️ Jeśli tak, to czy spełniła wasze oczekiwania?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Z chmury wielu z nas programistów korzysta na co dzień. Wdrażamy swoje aplikacje w ramach mikroserwisów, w środowiska skonteneryzowanych. Jest kilka zasad, które musimy przestrzegać aby było to możliwe. Czasem podążamy za wytycznymi z dokumentacji danego rozwiązania. Natomiast istnieje metodologia tworzenia aplikacji o nazwie Twelve-Factor App, która definiuje pewne założenia dla naszej aplikacji. Dzięki temu będziemy mogli z łatwością nie tylko uruchamiać aplikacje w chmurach tj. AWS, Azure, GCP, ale także wykorzystywać możliwość skalowania.Jakie są plusy 12 Factor App?Podczas odcinka dyskutujemy o tym kiedy warto zastosować metodologię Twelve-Factor App, czego nam brakuje w definicji oraz co nie zawsze się sprawdza.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się z 12 Factor App?➡️ Czy stosowałeś 12 Factor App podczas tworzenia aplikacji?➡️ Jakie widzisz problemy z stosowaniem tej metodologii?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Każdy lub prawie każdy w życiu miał taki moment, że dostawał takie zadanie, że chciał rzucić wszystko i wyjechać w Bieszczady. Pojawiały się myśli, że to nie jest dla mnie, że jestem po prostu za słaby.Takie sytuacja pojawiają się i będą się pojawiać zarówno w życiu młodego jak i bardzo doświadczonego programisty. W pewnym momencie utkniesz nad jakimś zadaniem i będziesz musiał sobie z nim jakoś poradzić.Moglibyśmy to spuentować stwierdzeniem „Sorry taki mamy klimat” albo „Takie jest życie! Handluj z tym„, ale my wolimy inaczej podejść do sprawy.Jak realizować zadania na pierwszy rzut oka nierealizowalne?W tym podcaście dzielimy się swoimi sprawdzonymi sposobami po jakie można sięgnąć w takich momentach. Sposobami pozwalającymi Tobie, poradzić sobie psychicznie z ciężkimi zadaniami, które mogą wydawać się przeszkodą nie do przejścia.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Jak radzisz sobie z przemęczeniem w pracy nad jednym zadaniem?➡️ W jaki sposób dekomponujesz swoją pracę?➡️ Co było kiedyś dla Ciebie zbyt ciężkim zadaniem do ogarnięcia?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Podczas organizacji swojej pracy i życia co dziennego coraz częściej sięgamy po oprogramowanie. Są i tacy (cześć, mam na imię Adrian 😎), którzy porzucili zeszyty z notatkami, standardowe kalendarze czy nawet papierowe książki, na rzecz elektronicznych rozwiązań. Teoretycznie i praktycznie lepszych, bardziej dostosowanych z większymi możliwościami.Gdy zaczynamy badać teren okazuje się, że mamy potężny wachlarz oprogramowania do wyboru. Z czego korzystać? Co wybrać? Być może nasze historie pomogą Ci w dokonaniu odpowiedniego wyboru lub chociaż zachęcą do testowania innych rozwiązań.Jakich narzędzi używają na co dzień autorzy DevEnv?W tym odcinku dzielimy się narzędziami bez których ciężko byłoby nam funkcjonować w wirtualnej rzeczywistości, uzupełniającej tą normalną.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Jakie oprogramowanie wykorzystujesz na co dzień?➡️ Które z narzędzi najbardziej usprawnia Twoją pracę?➡️ Czy można żyć bez smartfona?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
UWAGA! DevEnv YouTube => http://bit.ly/devenv-ytProgramowanie funkcyjne w ostatnim czasie mocno zaznaczyło swoją pozycję w świecie developmentu. Pojawiają się takie języki jak m.in. F#, które fascynują. Programiści języka Java coraz chętniej spoglądają w kierunku języka Scala. Ekstremalni natomiast próbują Erlanga czy Elixira.Dlatego tym razem postanowiłem sprowadzić do podcastu osobę, która na co dzień programuje w języku uważanym za funkcyjny, aby zdradziła mi więcej szczegółów.Co powinieneś wiedzieć o programowaniu funkcyjnym?Podczas podcastu wypytuję Krzysztofa o najważniejsze elementy związane z programowaniem funkcyjnym. Pytam, czy na co dzień spotykamy się z rozwiązaniami funkcyjnymi w innych językach, czy istnieją wzorce projektowe podobne do tych znanych z OOP oraz jakie są różnice między tzw. obiektówką?Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy wykorzystujesz paradygmat programowania funkcyjnego na codzień?➡️ Co Ci się podoba, a co nie w programowaniu funkcyjnym?➡️ Erlang, Haskel, Clojure, Scala, Elixir?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Jakość wytwarzanego oprogramowania zależy od wielu, często zmieniających się czynników. Na jakość wpływa – ilość posiadanego czasu na wytworzenie programu, jego skomplikowanie, doświadczenie zespołu czy też procesy sterujące pracą. W 38 odcinku podcastu DevEnv skupiliśmy się dosłownie na jednym elemencie.Odpowiadaliśmy na pytanie:Czy kompetencje QA potrzebne są w projekcie?Dyskutujemy na temat naszego zrozumienia roli Quality Assurance Specialist. Mówimy o tym, czy programiści i duże pokrycie testami automatycznymi może zastąpić QA. Zmagamy się z naszymi doświadczeniami kiedy musieliśmy wziąć na swoje barki obowiązki QA.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy w Twoim zespole pracuje QA?➡️ Czym zajmuje się QA w Twoim projekcie?➡️ Czy wyobrażasz sobie pracę bez QA? Dlaczego tak/nie?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
loading
Comments 
Download from Google Play
Download from App Store