DevEnv - O programowaniu bez kaca
Tworzenie oprogramowania w szerokim horyzoncie. Podejmujemy tematy związane z dobrymi praktykami, metodykami oraz procesami, które towarzyszą na co dzień programistom.
Masz pomysł na temat odcinka? Może chcesz zostać sponsorem odcinka?
Wyślij e-mail na adres: kontakt@devenv.pl
Kategorie:
Technologia
Technologia
#68 Własny produkt czy czyjeś legacy - co nas bawi, co nas męczy?
2023-07-12 22:20:08
Zastanawialiśmy się niedawno, co tak naprawdę wpływa na nasze dobre samopoczucie podczas wykonywania obowiązków zawodowych. Sprawa niby błaha, ale tak naprawdę, bez dobrego miejsca pracy, które nam odpowiada, ciężko dobrze realizować powierzone nam zadania. Dlatego postanowiliśmy porozmawiać, jak wygląda miejsce naszej pracy, czego oczekiwalibyśmy gdybyśmy byli zmuszeni do jej zmienienia i co nas tak naprawdę motywuje. ✅ Jak rozgraniczamy Legacy / Startup / Produkt z perspektywy programisty? ✅ Czy odpowiedzialność za pracę jest dla nas motywująca? ✅ Jak bardzo kod musi być dobry i czy czasem “DZIAŁA” jest wystarczające? ✅ Czy po 15 latach programowania zawodowego dalej się ma z tego frajdę? ✅ Co klocki LEGO mają wspólnego z tworzeniem oprogramowania? Jeżeli chcesz dowiedzieć się, na co po tylu latach pracy zwracamy uwagę i co jest dla nas ważne w miejscu pracy, to zapraszam Cię do tego odcinka. --- Najważniejsze linki: - Serwer Discord DevEnv - https://bit.ly/devenv-discord - Najnowsze materiały DevEnv - https://bit.ly/m/devenv --- W tym odcinku rozmawialiśmy o: (00:32) Wstęp do tematu odcinka (01:32) Różnice pomiędzy samymi startupami (02:44) Produkt, czy coś innego? (05:00) Granica pomiędzy startupem, a legacy (05:25) Poziom odpowiedzialności i motywacji podczas pracy (07:12) To co w kodzie jest ważne i to co może poczekać (08:24) W startupie często szybko coś musimy weryfikować (10:15) Nie zawsze jesteś zaangażowany full time (11:20) Dług technologiczny (11:58) Czas gra gigantyczną rolę (13:00) Czas jest ważny, pytanie, czy zawsze, czy czasem jest nieco inaczej? (14:44) Na co zwrócilibyśmy uwagę gdyby zmienialibyśmy dziś pracę? (19:40) Po 15 latach dalej można mieć frajdę z programowania (21:52) Co ma technologia do klocków Lego? (22:27) Rozwój i edukacja (23:49) Ludzie, komunikacja i współpraca (26:07) Odpowiedzialność (27:31) Zakończenie ---
Zastanawialiśmy się niedawno, co tak naprawdę wpływa na nasze dobre samopoczucie podczas wykonywania obowiązków zawodowych. Sprawa niby błaha, ale tak naprawdę, bez dobrego miejsca pracy, które nam odpowiada, ciężko dobrze realizować powierzone nam zadania.
Dlatego postanowiliśmy porozmawiać, jak wygląda miejsce naszej pracy, czego oczekiwalibyśmy gdybyśmy byli zmuszeni do jej zmienienia i co nas tak naprawdę motywuje.
✅ Jak rozgraniczamy Legacy / Startup / Produkt z perspektywy programisty?
✅ Czy odpowiedzialność za pracę jest dla nas motywująca?
✅ Jak bardzo kod musi być dobry i czy czasem “DZIAŁA” jest wystarczające?
✅ Czy po 15 latach programowania zawodowego dalej się ma z tego frajdę?
✅ Co klocki LEGO mają wspólnego z tworzeniem oprogramowania?
Jeżeli chcesz dowiedzieć się, na co po tylu latach pracy zwracamy uwagę i co jest dla nas ważne w miejscu pracy, to zapraszam Cię do tego odcinka.
---
Najważniejsze linki:
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- Najnowsze materiały DevEnv - https://bit.ly/m/devenv
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(01:32) Różnice pomiędzy samymi startupami
(02:44) Produkt, czy coś innego?
(05:00) Granica pomiędzy startupem, a legacy
(05:25) Poziom odpowiedzialności i motywacji podczas pracy
(07:12) To co w kodzie jest ważne i to co może poczekać
(08:24) W startupie często szybko coś musimy weryfikować
(10:15) Nie zawsze jesteś zaangażowany full time
(11:20) Dług technologiczny
(11:58) Czas gra gigantyczną rolę
(13:00) Czas jest ważny, pytanie, czy zawsze, czy czasem jest nieco inaczej?
(14:44) Na co zwrócilibyśmy uwagę gdyby zmienialibyśmy dziś pracę?
(19:40) Po 15 latach dalej można mieć frajdę z programowania
(21:52) Co ma technologia do klocków Lego?
(22:27) Rozwój i edukacja
(23:49) Ludzie, komunikacja i współpraca
(26:07) Odpowiedzialność
(27:31) Zakończenie
---
Dlatego postanowiliśmy porozmawiać, jak wygląda miejsce naszej pracy, czego oczekiwalibyśmy gdybyśmy byli zmuszeni do jej zmienienia i co nas tak naprawdę motywuje.
✅ Jak rozgraniczamy Legacy / Startup / Produkt z perspektywy programisty?
✅ Czy odpowiedzialność za pracę jest dla nas motywująca?
✅ Jak bardzo kod musi być dobry i czy czasem “DZIAŁA” jest wystarczające?
✅ Czy po 15 latach programowania zawodowego dalej się ma z tego frajdę?
✅ Co klocki LEGO mają wspólnego z tworzeniem oprogramowania?
Jeżeli chcesz dowiedzieć się, na co po tylu latach pracy zwracamy uwagę i co jest dla nas ważne w miejscu pracy, to zapraszam Cię do tego odcinka.
---
Najważniejsze linki:
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- Najnowsze materiały DevEnv - https://bit.ly/m/devenv
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(01:32) Różnice pomiędzy samymi startupami
(02:44) Produkt, czy coś innego?
(05:00) Granica pomiędzy startupem, a legacy
(05:25) Poziom odpowiedzialności i motywacji podczas pracy
(07:12) To co w kodzie jest ważne i to co może poczekać
(08:24) W startupie często szybko coś musimy weryfikować
(10:15) Nie zawsze jesteś zaangażowany full time
(11:20) Dług technologiczny
(11:58) Czas gra gigantyczną rolę
(13:00) Czas jest ważny, pytanie, czy zawsze, czy czasem jest nieco inaczej?
(14:44) Na co zwrócilibyśmy uwagę gdyby zmienialibyśmy dziś pracę?
(19:40) Po 15 latach dalej można mieć frajdę z programowania
(21:52) Co ma technologia do klocków Lego?
(22:27) Rozwój i edukacja
(23:49) Ludzie, komunikacja i współpraca
(26:07) Odpowiedzialność
(27:31) Zakończenie
---
#67 Czy mogę bezkarnie kopiować kod z Internetu?
2023-05-18 10:14:17
Podczas tworzenia oraz rozwijania kodu często sięgamy po typowe narzędzia, oraz przeglądamy różne kody źródłowe rozwiązań. Czasem czegoś potrzebujemy i ląduje metodą Copy&Pastiego w naszym finalnym kodzie, który dostarczamy do swoich produktów lub oprogramowania klienta. Kto pierwszy choć raz nie skopiował czegoś ze StackOverflow niech pierwszy rzuci kamień
Podczas tworzenia oraz rozwijania kodu często sięgamy po typowe narzędzia, oraz przeglądamy różne kody źródłowe rozwiązań. Czasem czegoś potrzebujemy i ląduje metodą Copy&Pastiego w naszym finalnym kodzie, który dostarczamy do swoich produktów lub oprogramowania klienta. Kto pierwszy choć raz nie skopiował czegoś ze StackOverflow niech pierwszy rzuci kamień
#66 REST API. Richardson Maturity Model.
2023-04-19 21:52:44
REST towarzyszy nam od ponad 20 lat. Stał się na tyle powszechnym standardem, że czasem zapominamy, czym tak naprawdę jest. Granice się zacierają, a dla większości programistów każde tworzone API to REST API. Rzeczywistość jest nieco inna, dlatego też dyskutujemy dzisiaj o definicji oraz panujących zasadach. Staramy się odpowiedzieć na pytania: ✅ Czym jest REST? ✅ Jakie 6 reguł definiuje REST? ✅ Czym są poziomy dojrzałości REST API? ✅ Ile ich jest i co konkretnie oznaczają? W tym odcinku opowiadamy czym jest REST i zdefiniowane poziomy dojrzałości Leonarda Richardsona. Jaki poziom naszym zdaniem jest wystarczający oraz czy kiedykolwiek implementowaliśmy wszystkie opisane poziomy? --- Najważniejsze linki: - Najnowsze materiały DevEnv - https://bit.ly/m/devenv - Serwer Discord DevEnv - https://bit.ly/devenv-discord - Mapa Myśli REST Poziomy Dojrzałości - https://devenv.pl/download/rest-poziomy-dojrzalosci.pdf --- W tym odcinku rozmawialiśmy o: (0:32) Wstęp do tematu odcinka (01:13) Czym jest REST? (03:13) 6 głównych reguł REST (03:17) Client-Server (03:50) Uniform Interface (04:25) Stateless (07:23) Cacheable (08:47) Layered System (11:38) Code-On-Demand (14:00) Model Dojrzałości Richardsona (14:55) Level 0 (15:35) Level 1 - Resources (17:28) Level 2 - HTTP Verbs (20:23) Level 3 - Hypermedia Controls (24:45) Swagger (25:17) Podsumowanie
REST towarzyszy nam od ponad 20 lat. Stał się na tyle powszechnym standardem, że czasem zapominamy, czym tak naprawdę jest. Granice się zacierają, a dla większości programistów każde tworzone API to REST API.
Rzeczywistość jest nieco inna, dlatego też dyskutujemy dzisiaj o definicji oraz panujących zasadach. Staramy się odpowiedzieć na pytania:
✅ Czym jest REST?
✅ Jakie 6 reguł definiuje REST?
✅ Czym są poziomy dojrzałości REST API?
✅ Ile ich jest i co konkretnie oznaczają?
W tym odcinku opowiadamy czym jest REST i zdefiniowane poziomy dojrzałości Leonarda Richardsona. Jaki poziom naszym zdaniem jest wystarczający oraz czy kiedykolwiek implementowaliśmy wszystkie opisane poziomy?
---
Najważniejsze linki:
- Najnowsze materiały DevEnv - https://bit.ly/m/devenv
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- Mapa Myśli REST Poziomy Dojrzałości - https://devenv.pl/download/rest-poziomy-dojrzalosci.pdf
---
W tym odcinku rozmawialiśmy o:
(0:32) Wstęp do tematu odcinka
(01:13) Czym jest REST?
(03:13) 6 głównych reguł REST
(03:17) Client-Server
(03:50) Uniform Interface
(04:25) Stateless
(07:23) Cacheable
(08:47) Layered System
(11:38) Code-On-Demand
(14:00) Model Dojrzałości Richardsona
(14:55) Level 0
(15:35) Level 1 - Resources
(17:28) Level 2 - HTTP Verbs
(20:23) Level 3 - Hypermedia Controls
(24:45) Swagger
(25:17) Podsumowanie
Rzeczywistość jest nieco inna, dlatego też dyskutujemy dzisiaj o definicji oraz panujących zasadach. Staramy się odpowiedzieć na pytania:
✅ Czym jest REST?
✅ Jakie 6 reguł definiuje REST?
✅ Czym są poziomy dojrzałości REST API?
✅ Ile ich jest i co konkretnie oznaczają?
W tym odcinku opowiadamy czym jest REST i zdefiniowane poziomy dojrzałości Leonarda Richardsona. Jaki poziom naszym zdaniem jest wystarczający oraz czy kiedykolwiek implementowaliśmy wszystkie opisane poziomy?
---
Najważniejsze linki:
- Najnowsze materiały DevEnv - https://bit.ly/m/devenv
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- Mapa Myśli REST Poziomy Dojrzałości - https://devenv.pl/download/rest-poziomy-dojrzalosci.pdf
---
W tym odcinku rozmawialiśmy o:
(0:32) Wstęp do tematu odcinka
(01:13) Czym jest REST?
(03:13) 6 głównych reguł REST
(03:17) Client-Server
(03:50) Uniform Interface
(04:25) Stateless
(07:23) Cacheable
(08:47) Layered System
(11:38) Code-On-Demand
(14:00) Model Dojrzałości Richardsona
(14:55) Level 0
(15:35) Level 1 - Resources
(17:28) Level 2 - HTTP Verbs
(20:23) Level 3 - Hypermedia Controls
(24:45) Swagger
(25:17) Podsumowanie
#65 Clean Code. Jak definiujemy czysty kod?
2023-03-22 22:46:49
Clean Code, czyli Czysty Kod. To tytuł książki, którą często polecamy młodym programistom. Ponieważ, jednym z etapów rozwoju rzemiosła programisty, jest tworzenie prostego w zrozumieniu kodu. Sztuka ta nie jest łatwa, jednak istnieje kilkanaście różnych reguł i podpowiedzi, których stosowanie może pozwolić na uzyskanie "wystarczająco czystego kodu". Pytanie tylko, które z nich wybrać i kiedy stosować? ✅ Czym jest Clean Code? ✅ Jak definiować i jakie reguły można zastosować przy Clean Code? ✅ Czy Clean Code może być uniwersalny i identyczny dla wszystkich naszych projektów? ✅ Jakie zasady stosujemy w projektach i na co uważamy? W tym odcinku podpowiadamy jak my patrzymy na Clean Code. Kiedy i po co stosujemy pewne zasady oraz dlaczego SOLID nie zawsze jest wymagany. --- Najważniejsze linki: - Serwer Discord DevEnv - https://bit.ly/devenv-discord - YouTube DevEnv - https://bit.ly/devenv-yt - Mapa Myśli Clean Code - https://devenv.pl/download/clean-code.pdf --- W tym odcinku rozmawialiśmy o: (00:32) Wstęp do tematu odcinka (00:45) Serwer Discord DevEnv (01:18) Kontekst aplikacji jest ważny (02:30) Implementacje na przyszłość (03:10) AHA Programming (04:08) Ustalenie poziomu “kod wystarczająco dobry” (06:55) Wszyscy powinni rozumieć wymagania względem kodu (07:20) Reguły Clean Code, które można zastosować (08:37) Gotowe reguły dla narzędzia SCA (09:02) Wspólny standard nazewnictwa (12:00) Standardy na wielu poziomach (15:05) Unikamy komentarzy bez uzasadnienia (16:02) Kiedy komentarze są zasadne (18:03) Zasada Skauta (19:22) Magic Numbers & String (21:47) Zasada DRY - Don't Repeat Yourself (24:05) Zasady SOLID* (25:45) Dług techniczny, zasady, a konsekwencje (26:32) W Definition of Done - “Zawsze Testy” (27:15) Nauka na błędach jako sposób na poprawę swojego kodu (27:55) Odpowiedni poziom satysfakcji (29:00) Jak mierzyć Clean Code? (35:17) Zakończenie + Najważniejsze miejsca DevEnv ---
Clean Code, czyli Czysty Kod. To tytuł książki, którą często polecamy młodym programistom. Ponieważ, jednym z etapów rozwoju rzemiosła programisty, jest tworzenie prostego w zrozumieniu kodu.
Sztuka ta nie jest łatwa, jednak istnieje kilkanaście różnych reguł i podpowiedzi, których stosowanie może pozwolić na uzyskanie "wystarczająco czystego kodu". Pytanie tylko, które z nich wybrać i kiedy stosować?
✅ Czym jest Clean Code?
✅ Jak definiować i jakie reguły można zastosować przy Clean Code?
✅ Czy Clean Code może być uniwersalny i identyczny dla wszystkich naszych projektów?
✅ Jakie zasady stosujemy w projektach i na co uważamy?
W tym odcinku podpowiadamy jak my patrzymy na Clean Code. Kiedy i po co stosujemy pewne zasady oraz dlaczego SOLID nie zawsze jest wymagany.
---
Najważniejsze linki:
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- YouTube DevEnv - https://bit.ly/devenv-yt
- Mapa Myśli Clean Code - https://devenv.pl/download/clean-code.pdf
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(00:45) Serwer Discord DevEnv
(01:18) Kontekst aplikacji jest ważny
(02:30) Implementacje na przyszłość
(03:10) AHA Programming
(04:08) Ustalenie poziomu “kod wystarczająco dobry”
(06:55) Wszyscy powinni rozumieć wymagania względem kodu
(07:20) Reguły Clean Code, które można zastosować
(08:37) Gotowe reguły dla narzędzia SCA
(09:02) Wspólny standard nazewnictwa
(12:00) Standardy na wielu poziomach
(15:05) Unikamy komentarzy bez uzasadnienia
(16:02) Kiedy komentarze są zasadne
(18:03) Zasada Skauta
(19:22) Magic Numbers & String
(21:47) Zasada DRY - Don't Repeat Yourself
(24:05) Zasady SOLID*
(25:45) Dług techniczny, zasady, a konsekwencje
(26:32) W Definition of Done - “Zawsze Testy”
(27:15) Nauka na błędach jako sposób na poprawę swojego kodu
(27:55) Odpowiedni poziom satysfakcji
(29:00) Jak mierzyć Clean Code?
(35:17) Zakończenie + Najważniejsze miejsca DevEnv
---
Sztuka ta nie jest łatwa, jednak istnieje kilkanaście różnych reguł i podpowiedzi, których stosowanie może pozwolić na uzyskanie "wystarczająco czystego kodu". Pytanie tylko, które z nich wybrać i kiedy stosować?
✅ Czym jest Clean Code?
✅ Jak definiować i jakie reguły można zastosować przy Clean Code?
✅ Czy Clean Code może być uniwersalny i identyczny dla wszystkich naszych projektów?
✅ Jakie zasady stosujemy w projektach i na co uważamy?
W tym odcinku podpowiadamy jak my patrzymy na Clean Code. Kiedy i po co stosujemy pewne zasady oraz dlaczego SOLID nie zawsze jest wymagany.
---
Najważniejsze linki:
- Serwer Discord DevEnv - https://bit.ly/devenv-discord
- YouTube DevEnv - https://bit.ly/devenv-yt
- Mapa Myśli Clean Code - https://devenv.pl/download/clean-code.pdf
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(00:45) Serwer Discord DevEnv
(01:18) Kontekst aplikacji jest ważny
(02:30) Implementacje na przyszłość
(03:10) AHA Programming
(04:08) Ustalenie poziomu “kod wystarczająco dobry”
(06:55) Wszyscy powinni rozumieć wymagania względem kodu
(07:20) Reguły Clean Code, które można zastosować
(08:37) Gotowe reguły dla narzędzia SCA
(09:02) Wspólny standard nazewnictwa
(12:00) Standardy na wielu poziomach
(15:05) Unikamy komentarzy bez uzasadnienia
(16:02) Kiedy komentarze są zasadne
(18:03) Zasada Skauta
(19:22) Magic Numbers & String
(21:47) Zasada DRY - Don't Repeat Yourself
(24:05) Zasady SOLID*
(25:45) Dług techniczny, zasady, a konsekwencje
(26:32) W Definition of Done - “Zawsze Testy”
(27:15) Nauka na błędach jako sposób na poprawę swojego kodu
(27:55) Odpowiedni poziom satysfakcji
(29:00) Jak mierzyć Clean Code?
(35:17) Zakończenie + Najważniejsze miejsca DevEnv
---
#64 Dlaczego warto uczyć innych? Co daje dzielenie się wiedzą?
2023-02-23 21:30:00
Praktycznie każdy dzień pracy programisty to możliwość zdobycia nowej umiejętności. Wiele z wykonywanych zdań wymaga od nas poznania czegoś nowego, eksperymentowania czy rozmowy z kolegą z zespołu. Czasem to my stajemy się źródłem wiedzy, mentorem czy ewangelistą jakiegoś rozwiązania. Pamiętam jak postawiono mnie przed nie lada wyzwaniem - stworzeniem szkółki dla młodych adeptów programowania. Musiałem nie tylko nauczyć innych pewnych aspektów, ale także dobrze poznać swoje braki wiedzy i je uzupełnić. Nauka kogoś to dla mnie najlepszy sposób na rozwój także swoich umiejętności. ✅ Jak zatem zacząć z przekazywaniem wiedzy? ✅ Kiedy wymiana wiedzy ma sens? ✅ Czy uczenie innych może być sposobem na wypalenie zawodowe? ✅ Czy każdy nadaje się do nauki innych? ✅ Jakie techniki wykorzystujemy, aby lepiej uczyć innych? W tym odcinku podpowiadamy jak zacząć, po co to robić i na co uważać. Niech ta forma przekazywania wiedzy, będzie źródłem inspiracji i zachętą do dzielenia się wiedzą. --- W tym odcinku rozmawialiśmy o: (00:32) Wstęp do tematu odcinka (02:00) Stand-up jako forma wymiany wiedzy (03:18) Muszą chcieć dwie strony (03:42) Kiedy wymiana wiedzy ma sens? (07:28) Hype na nowe rzeczy (09:34) Jaki jest cel wymiany wiedzy? (10:47) Stosunek korzyści do kosztu (12:32) Egoizm, a samorealizacja (14:02) Wymiana wiedzy, a wypalenie zawodowe (15:20) Inspiracja innych (16:25) Nie każdy musi dzielić się wiedzą (17:08) Dodatkowe korzyści (18:34) Czy każdy nadaje się do nauki innych? (20:07) Można zacząć działać "lokalnie" (23:07) Aby działać trzeba mieć na to czas (23:40) Bus Factor (25:20) Jak robić to dobrze? Technika Richarda Feynmana (28:04) Tłumaczenie za pomocą analogii (30:04) Różne techniki uczenia (31:50) Zakończenie ---
Praktycznie każdy dzień pracy programisty to możliwość zdobycia nowej umiejętności. Wiele z wykonywanych zdań wymaga od nas poznania czegoś nowego, eksperymentowania czy rozmowy z kolegą z zespołu. Czasem to my stajemy się źródłem wiedzy, mentorem czy ewangelistą jakiegoś rozwiązania.
Pamiętam jak postawiono mnie przed nie lada wyzwaniem - stworzeniem szkółki dla młodych adeptów programowania. Musiałem nie tylko nauczyć innych pewnych aspektów, ale także dobrze poznać swoje braki wiedzy i je uzupełnić. Nauka kogoś to dla mnie najlepszy sposób na rozwój także swoich umiejętności.
✅ Jak zatem zacząć z przekazywaniem wiedzy?
✅ Kiedy wymiana wiedzy ma sens?
✅ Czy uczenie innych może być sposobem na wypalenie zawodowe?
✅ Czy każdy nadaje się do nauki innych?
✅ Jakie techniki wykorzystujemy, aby lepiej uczyć innych?
W tym odcinku podpowiadamy jak zacząć, po co to robić i na co uważać. Niech ta forma przekazywania wiedzy, będzie źródłem inspiracji i zachętą do dzielenia się wiedzą.
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(02:00) Stand-up jako forma wymiany wiedzy
(03:18) Muszą chcieć dwie strony
(03:42) Kiedy wymiana wiedzy ma sens?
(07:28) Hype na nowe rzeczy
(09:34) Jaki jest cel wymiany wiedzy?
(10:47) Stosunek korzyści do kosztu
(12:32) Egoizm, a samorealizacja
(14:02) Wymiana wiedzy, a wypalenie zawodowe
(15:20) Inspiracja innych
(16:25) Nie każdy musi dzielić się wiedzą
(17:08) Dodatkowe korzyści
(18:34) Czy każdy nadaje się do nauki innych?
(20:07) Można zacząć działać "lokalnie"
(23:07) Aby działać trzeba mieć na to czas
(23:40) Bus Factor
(25:20) Jak robić to dobrze? Technika Richarda Feynmana
(28:04) Tłumaczenie za pomocą analogii
(30:04) Różne techniki uczenia
(31:50) Zakończenie
---
Pamiętam jak postawiono mnie przed nie lada wyzwaniem - stworzeniem szkółki dla młodych adeptów programowania. Musiałem nie tylko nauczyć innych pewnych aspektów, ale także dobrze poznać swoje braki wiedzy i je uzupełnić. Nauka kogoś to dla mnie najlepszy sposób na rozwój także swoich umiejętności.
✅ Jak zatem zacząć z przekazywaniem wiedzy?
✅ Kiedy wymiana wiedzy ma sens?
✅ Czy uczenie innych może być sposobem na wypalenie zawodowe?
✅ Czy każdy nadaje się do nauki innych?
✅ Jakie techniki wykorzystujemy, aby lepiej uczyć innych?
W tym odcinku podpowiadamy jak zacząć, po co to robić i na co uważać. Niech ta forma przekazywania wiedzy, będzie źródłem inspiracji i zachętą do dzielenia się wiedzą.
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(02:00) Stand-up jako forma wymiany wiedzy
(03:18) Muszą chcieć dwie strony
(03:42) Kiedy wymiana wiedzy ma sens?
(07:28) Hype na nowe rzeczy
(09:34) Jaki jest cel wymiany wiedzy?
(10:47) Stosunek korzyści do kosztu
(12:32) Egoizm, a samorealizacja
(14:02) Wymiana wiedzy, a wypalenie zawodowe
(15:20) Inspiracja innych
(16:25) Nie każdy musi dzielić się wiedzą
(17:08) Dodatkowe korzyści
(18:34) Czy każdy nadaje się do nauki innych?
(20:07) Można zacząć działać "lokalnie"
(23:07) Aby działać trzeba mieć na to czas
(23:40) Bus Factor
(25:20) Jak robić to dobrze? Technika Richarda Feynmana
(28:04) Tłumaczenie za pomocą analogii
(30:04) Różne techniki uczenia
(31:50) Zakończenie
---
#63 Debugowanie aplikacji w chmurze
2023-02-08 14:05:40
Chmura coraz częściej jest miejscem docelowym życia naszych aplikacji. Obsługujemy w niej wdrożenia testowe, stage i produkcyjne. Nie raz są to rozbudowane systemy składające się z wielu współpracujących ze sobą aplikacji. Byłem świadkiem sytuacji, gdzie aplikacja lokalnie działała bezbłędnie. Jednak po opublikowaniu nowej wersji użytkownikom, zaliczyliśmy wpadkę - przeglądarka użytkownika nie dostawała nawet odpowiedzi. Jak zatem radzić sobie z analizą błędów, które występują w takim środowisku? Czy wystarczy nam tzw. console.log na ekran i sprawa staje się prostsza? W tym odcinku poruszamy nasze doświadczenia i problemy, z jakimi spotkaliśmy się, pracując na co dzień z aplikacjami korzystającymi z usług chmurowych w każdej dostępnej postaci. --- W tym odcinku rozmawialiśmy o: (00:32) Wstęp do tematu odcinka (10:15) Unifikacja środowiska uruchomieniowego (03:30) Dlaczego podobne środowiska są ważne? (05:10) Końcowa infrastruktura też może być problemem (07:07) Aplikacja jest na końcu łańcucha wywołań (08:20) Debugowanie aplikacji w Docker (08:50) Chmura to nie zawsze Docker (09:28) Centralne logowanie i przeszukiwanie logów (10:30) Logi super, ale tu też musimy zadbać o porządek (11:57) Logi super, ale też mogą zakłócać działanie systemu (13:42) Wymagania i benefity narzędzi centralnego logowania (14:47) Monitoring oraz alerty (15:23) Reagowanie na nieprzewidziane - Sentry (16:50) Obsługa nieobsłużonych błędów (18:04) Narzędzia w chmurze wspomagające analizę problemów (19:40) Metryki techniczne (20:10) Testowanie na produkcji (21:00) Chmura uruchomiona lokalnie (21:36) Najpopularniejszy sposób debugowania wśród programistów (22:26) Odpowiedni dobór narzędzi do problemu (23:29) Szybkość rozwiązania błędu jest często najważniejsza (25:07) Podsumowanie ---
Chmura coraz częściej jest miejscem docelowym życia naszych aplikacji. Obsługujemy w niej wdrożenia testowe, stage i produkcyjne. Nie raz są to rozbudowane systemy składające się z wielu współpracujących ze sobą aplikacji.
Byłem świadkiem sytuacji, gdzie aplikacja lokalnie działała bezbłędnie. Jednak po opublikowaniu nowej wersji użytkownikom, zaliczyliśmy wpadkę - przeglądarka użytkownika nie dostawała nawet odpowiedzi.
Jak zatem radzić sobie z analizą błędów, które występują w takim środowisku?
Czy wystarczy nam tzw. console.log na ekran i sprawa staje się prostsza?
W tym odcinku poruszamy nasze doświadczenia i problemy, z jakimi spotkaliśmy się, pracując na co dzień z aplikacjami korzystającymi z usług chmurowych w każdej dostępnej postaci.
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(10:15) Unifikacja środowiska uruchomieniowego
(03:30) Dlaczego podobne środowiska są ważne?
(05:10) Końcowa infrastruktura też może być problemem
(07:07) Aplikacja jest na końcu łańcucha wywołań
(08:20) Debugowanie aplikacji w Docker
(08:50) Chmura to nie zawsze Docker
(09:28) Centralne logowanie i przeszukiwanie logów
(10:30) Logi super, ale tu też musimy zadbać o porządek
(11:57) Logi super, ale też mogą zakłócać działanie systemu
(13:42) Wymagania i benefity narzędzi centralnego logowania
(14:47) Monitoring oraz alerty
(15:23) Reagowanie na nieprzewidziane - Sentry
(16:50) Obsługa nieobsłużonych błędów
(18:04) Narzędzia w chmurze wspomagające analizę problemów
(19:40) Metryki techniczne
(20:10) Testowanie na produkcji
(21:00) Chmura uruchomiona lokalnie
(21:36) Najpopularniejszy sposób debugowania wśród programistów
(22:26) Odpowiedni dobór narzędzi do problemu
(23:29) Szybkość rozwiązania błędu jest często najważniejsza
(25:07) Podsumowanie
---
Byłem świadkiem sytuacji, gdzie aplikacja lokalnie działała bezbłędnie. Jednak po opublikowaniu nowej wersji użytkownikom, zaliczyliśmy wpadkę - przeglądarka użytkownika nie dostawała nawet odpowiedzi.
Jak zatem radzić sobie z analizą błędów, które występują w takim środowisku?
Czy wystarczy nam tzw. console.log na ekran i sprawa staje się prostsza?
W tym odcinku poruszamy nasze doświadczenia i problemy, z jakimi spotkaliśmy się, pracując na co dzień z aplikacjami korzystającymi z usług chmurowych w każdej dostępnej postaci.
---
W tym odcinku rozmawialiśmy o:
(00:32) Wstęp do tematu odcinka
(10:15) Unifikacja środowiska uruchomieniowego
(03:30) Dlaczego podobne środowiska są ważne?
(05:10) Końcowa infrastruktura też może być problemem
(07:07) Aplikacja jest na końcu łańcucha wywołań
(08:20) Debugowanie aplikacji w Docker
(08:50) Chmura to nie zawsze Docker
(09:28) Centralne logowanie i przeszukiwanie logów
(10:30) Logi super, ale tu też musimy zadbać o porządek
(11:57) Logi super, ale też mogą zakłócać działanie systemu
(13:42) Wymagania i benefity narzędzi centralnego logowania
(14:47) Monitoring oraz alerty
(15:23) Reagowanie na nieprzewidziane - Sentry
(16:50) Obsługa nieobsłużonych błędów
(18:04) Narzędzia w chmurze wspomagające analizę problemów
(19:40) Metryki techniczne
(20:10) Testowanie na produkcji
(21:00) Chmura uruchomiona lokalnie
(21:36) Najpopularniejszy sposób debugowania wśród programistów
(22:26) Odpowiedni dobór narzędzi do problemu
(23:29) Szybkość rozwiązania błędu jest często najważniejsza
(25:07) Podsumowanie
---
#62 Ulga IP Box dla programistów. Gość Aleksandra Borowska (PRAVNA.PL)
2023-01-25 00:14:08
Podatek liniowy z IP Box to opcja podatkowa, na którą zastanawia coraz więcej programistów. Ryczałt 12% jest oczywiście atrakcyjny, ale masz niższą zdolność kredytową, nie opłaca Ci się auto w leasing i nie możesz odliczyć kosztów. Z IP Box masz wyższą zdolność kredytową, możesz rozliczyć się za 3 poprzednie lata, ale na pewno słyszałeś też o tym, że to sporo formalności i ryzyko kontroli z urzędu. Ile w tym prawdy? O korzyściach, mitach i o tym, ile można zyskać na IP Box rozmawiałem w podcaście z Aleksandrą Borowską — ekspertem ds. ulgi IP Box w Pravna Group. Jakie wątki poruszyliśmy? Jak IP Box wypada na tle innych form podatkowych? Ile można zyskać na IP Box? Jak wygląda proces ubiegania się o ulgę? Jakie dokumenty są nam potrzebne? Czy IP Box = dużo formalności? Czy trzeba obawiać się kontroli z US? Pravna uzyskała dla mnie IP Box’a, a także rozliczyła 3 poprzednie lata. I to jeszcze zanim wpadliśmy na pomysł, by stworzyć wspólny materiał. --- Chcesz zostać sponsorem kolejnego odcinka podcastu? Wyślij e-mail na adres: kontakt@devenv.pl
Podatek liniowy z IP Box to opcja podatkowa, na którą zastanawia coraz więcej programistów. Ryczałt 12% jest oczywiście atrakcyjny, ale masz niższą zdolność kredytową, nie opłaca Ci się auto w leasing i nie możesz odliczyć kosztów.
Z IP Box masz wyższą zdolność kredytową, możesz rozliczyć się za 3 poprzednie lata, ale na pewno słyszałeś też o tym, że to sporo formalności i ryzyko kontroli z urzędu.
Ile w tym prawdy? O korzyściach, mitach i o tym, ile można zyskać na IP Box rozmawiałem w podcaście z Aleksandrą Borowską — ekspertem ds. ulgi IP Box w Pravna Group.
Jakie wątki poruszyliśmy?
---
Chcesz zostać sponsorem kolejnego odcinka podcastu?
Wyślij e-mail na adres: kontakt@devenv.pl
Z IP Box masz wyższą zdolność kredytową, możesz rozliczyć się za 3 poprzednie lata, ale na pewno słyszałeś też o tym, że to sporo formalności i ryzyko kontroli z urzędu.
Ile w tym prawdy? O korzyściach, mitach i o tym, ile można zyskać na IP Box rozmawiałem w podcaście z Aleksandrą Borowską — ekspertem ds. ulgi IP Box w Pravna Group.
Jakie wątki poruszyliśmy?
- Jak IP Box wypada na tle innych form podatkowych?
- Ile można zyskać na IP Box?
- Jak wygląda proces ubiegania się o ulgę?
- Jakie dokumenty są nam potrzebne?
- Czy IP Box = dużo formalności?
- Czy trzeba obawiać się kontroli z US?
---
Chcesz zostać sponsorem kolejnego odcinka podcastu?
Wyślij e-mail na adres: kontakt@devenv.pl
#61 Piekło zarządzania zależnościami w projekcie
2023-01-11 09:32:35
Zarządzanie zależnościami było wcześniej problematyczne. Odkąd pojawiły się npm, yarn, nuget i inne menadżery pakietów, wszystkie problemy programistów zniknęły. Wystarczy zaciągnąć bibliotekę i już nie musimy się przejmować. Ktoś to przecież napisał, przetestował. Wystarczy npm install i forget i tak jedna biblioteka za drugą. Pytanie, czy na pewno tylko tyle wystarczy? W dzisiejszym odcinku porozmawiamy sobie o naszych problemach z zależnościami. O ryzykach, które gdzieś tam czekają, oraz o tym, jak uniknąć potencjalnych problemów. Historia uczy, że średnio co 3 miesiące dzieje się, coś związanego z zależnościami co może wymagać naszej interwencji. Chcesz się lepiej przygotować na takie sytuacje? To zapraszamy do odsłuchania tego odcinka.
Zarządzanie zależnościami było wcześniej problematyczne. Odkąd pojawiły się npm, yarn, nuget i inne menadżery pakietów, wszystkie problemy programistów zniknęły. Wystarczy zaciągnąć bibliotekę i już nie musimy się przejmować. Ktoś to przecież napisał, przetestował. Wystarczy npm install i forget i tak jedna biblioteka za drugą. Pytanie, czy na pewno tylko tyle wystarczy?
W dzisiejszym odcinku porozmawiamy sobie o naszych problemach z zależnościami. O ryzykach, które gdzieś tam czekają, oraz o tym, jak uniknąć potencjalnych problemów.
Historia uczy, że średnio co 3 miesiące dzieje się, coś związanego z zależnościami co może wymagać naszej interwencji. Chcesz się lepiej przygotować na takie sytuacje? To zapraszamy do odsłuchania tego odcinka.
W dzisiejszym odcinku porozmawiamy sobie o naszych problemach z zależnościami. O ryzykach, które gdzieś tam czekają, oraz o tym, jak uniknąć potencjalnych problemów.
Historia uczy, że średnio co 3 miesiące dzieje się, coś związanego z zależnościami co może wymagać naszej interwencji. Chcesz się lepiej przygotować na takie sytuacje? To zapraszamy do odsłuchania tego odcinka.
#60 Monorepo czy Polyrepo? Nasze doświadczenia. Gość Dariusz Cichorski
2022-12-21 17:10:00
Kiedyś tworzyło się monolity, które składały się z wielu projektów. Potem nastąpiła era mikroserwisów, gdzie każdy, posiadał własne repozytorium. A co obecnie jest w modzie? Czy powinniśmy sięgnąć po monorepo, czy jednak po polyrepo? Które podejście bardziej pasuje dla zespołów rozproszonych, pracujących w różnych strefach czasowych? Czy można pracować w strukturze hybrydowej? Jak wyłapać granicę, po przekroczeniu, której warto migrować z jednego podejścia do drugiego? Jak pewnie się spodziewacie, na te pytania odpowiedź brzmi: to zależy. Natomiast naszym celem jest przedstawienie Wam od czego
Kiedyś tworzyło się monolity, które składały się z wielu projektów. Potem nastąpiła era mikroserwisów, gdzie każdy, posiadał własne repozytorium. A co obecnie jest w modzie?
Czy powinniśmy sięgnąć po monorepo, czy jednak po polyrepo? Które podejście bardziej pasuje dla zespołów rozproszonych, pracujących w różnych strefach czasowych?
Czy można pracować w strukturze hybrydowej?
Jak wyłapać granicę, po przekroczeniu, której warto migrować z jednego podejścia do drugiego?
Jak pewnie się spodziewacie, na te pytania odpowiedź brzmi: to zależy. Natomiast naszym celem jest przedstawienie Wam od czego
Czy powinniśmy sięgnąć po monorepo, czy jednak po polyrepo? Które podejście bardziej pasuje dla zespołów rozproszonych, pracujących w różnych strefach czasowych?
Czy można pracować w strukturze hybrydowej?
Jak wyłapać granicę, po przekroczeniu, której warto migrować z jednego podejścia do drugiego?
Jak pewnie się spodziewacie, na te pytania odpowiedź brzmi: to zależy. Natomiast naszym celem jest przedstawienie Wam od czego
#59 Reaktywacja. Zaczynamy sezon 02
2022-12-07 09:01:10
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. Na szczęście mamy grudzień 2022 r. i zapowiada się na reaktywację :) Taką na spokojnie. Aby sił starczyło na kolejne 58 odcinków podcastu. W tym odcinku opowiadamy o tym, co się u nas wydarzyło oraz o naszych dalszych planach.
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.
Na szczęście mamy grudzień 2022 r. i zapowiada się na reaktywację :)
Taką na spokojnie. Aby sił starczyło na kolejne 58 odcinków podcastu.
W tym odcinku opowiadamy o tym, co się u nas wydarzyło oraz o naszych dalszych planach.
Na szczęście mamy grudzień 2022 r. i zapowiada się na reaktywację :)
Taką na spokojnie. Aby sił starczyło na kolejne 58 odcinków podcastu.
W tym odcinku opowiadamy o tym, co się u nas wydarzyło oraz o naszych dalszych planach.