PHP, Node.js, C#
Nasza obecność w podcaście DevEnv została przez ostatnie 1.5 roku mocno ograniczona. Pochłonęło nas życie prywatne, zawodowe oraz inny poboczny projekt. Wszystko to spowodowało mocne ograniczenie naszego uczestnictwa w projekt DevEnv./\r\n//\r\n/Na szczęście mamy grudzień 2022 r. i zapowiada się na reaktywację :)/\r\n//\r\n/Taką na spokojnie. Aby sił starczyło na kolejne 58 odcinków podcastu./\r\n//\r\n/W tym odcinku opowiadamy o tym, co się u nas wydarzyło oraz o naszych dalszych planach.
Budowanie multiplatformowych rozwiązań dla systemów Android, iOS, Linux, Mac, Windows oraz aplikacji webowych z wykorzystaniem jednego kodu. Brzmi abstrakcyjnie? Otóż nie. Właśnie tak przedstawiane jest rozwiązanie firmy Google o nazwie Flutter. Narzędzie oparte o język programowania Dart staje się interesujące nie tylko dla programistów. Czy to nie spełnienie, marzenia każdego inwestora, aby napisać tylko jeden raz aplikację, a cieszyć się jej dostępnością na mnogość urządzeń i systemów? Schodząc jednak na ziemie… Czym dokładnie jest Flutter i kiedy warto przyjrzeć się mu bliżej? W tym odcinku mamy możliwość zadawania pytań Szymonowi, programiście, który sporo czasu spędził przy tworzeniu produkcyjnych rozwiązań w oparciu właśnie o Fluttera.
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ę 👍
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.