Zero code systems – Notatka z nauki

przez Karol Bocian | 12 czerwca, 2022
0 komentarzy

W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2018 – Maciek Próchniak – “Zero code” systems – hopes, myths and reality

Notatka z materiału: Zero code systems:

Zanotowałem z tego materiału:

  • Programiści z punktu widzenia biznesu są kosztem. Biznes znacznie chętniej rozwiązałby problem za pomocą oprogramowania, ale bez programowania (gotową aplikacją, no-code).
  • Możesz nauczyć innych pracowników (zarabiających mniej) lepiej obsługiwać swój system, aby IT nie był potrzebny (więcej zarabiający).
  • Spróbuj lepiej zrozumieć, co chce osiągnąć użytkownik, dlaczego, skąd bierze dane, a potem spróbuj zrobić to za niego (zautomatyzować).
  • Upraszczaj reguły.
  • Programuj reguły.
  • Pokaż użytkownikom Drools – tam niech zdefiniują reguły, a potem je importuj.
  • Importuj Excele.
  • Importuj BPMN.
  • Daj użytkownikowi narzędzia do wyklikania reguł procesowych.
  • Kto będzie utrzymywał reguły procesowe i sprawdzał, że dobrze działają?
  • UAT – może replikować dane z produkcji, ale akcje wykonywać już w bezpiecznym miejscu (nie mają wpływu na klientów).
  • Podsumowanie:
    • Poznaj swojego klienta – kim jest – czy są to programiści, czy są techniczni.
    • Kto będzie utrzymywał reguły biznesowe i kto będzie za nie odpowiedzialny?
    • Ile dać możliwości klientowi w ustawianiu reguł, a ile ich zaprogramować?
    • Bardziej skomplikowane reguły powinni budować programiści.

Wszystkie posty związane z notatkami z nauki:

    Źródła

    Obraz główny

    Materiał: Zero code systems:

    Bogaty albo biedny po prostu różni mentalnie — T. Harv Eker

    przez Karol Bocian | 15 lipca, 2022
    0 komentarzy

     

    Przeczytałem ostatnio kolejną książkę: Bogaty albo biedny po prostu różni mentalnie — T. Harv Eker. W tym wpisie dzielę się informacjami, które w niej znalazłem oraz które wdrożyłem w swoim życiu. Staram się z każdej książki wdrażać minimum jedną rzecz.

    Wdrożyłem:

    1. Brać odpowiedzialność za swoje działania i swoją sytuację.
    2. Ograniczyć narzekanie.

    Książkę możesz kupić tutaj:

    Notatki:

    Najważniejszym narzędziem jest Twoja głowa, a przede wszystkim Twoje przekonania i sposoby myślenia.

    Największą przeszkodą nie jest brak wiedzy, lecz nieprawdziwa wiedza.

     

    Jeżeli próbujesz coś zmienić, zastanów się, jakie masz do tego podejście. Jeżeli złe, to najpierw zacznij zmianę od swojego myślenia. Uświadom sobie swoje przekonania na dany temat, zrozum je. Następnie oddziel przekonania od faktów, a na końcu zbuduj prawdziwe deklaracje i wypleń kłamstwa.

     

    Jeśli jesteś na coś nastawiony, to tak zazwyczaj będzie. Jeżeli jesteś nastawiony na zarobki na poziomie X, to bez zmiany nastawienia, nie przeskoczysz tego, ponieważ nie będziesz miał motywacji, wiary oraz będziesz sabotował swoje działania.

     

    Ludzie, zamiast wziąć odpowiedzialność za swoją sytuację, to przyjmują postawę ofiary.

    Narzekanie jest najgorszą rzeczą, którą możemy robić sobie i innym.

     

    Chcesz osiągnąć prawdziwy dostatek? Zapisz sobie dwa cele finansowe:

    1. Dochody roczne
    2. Majątek netto

    Nałóż sobie realistyczne ramy czasowe na realizację tych celów, a jednocześnie pamiętaj, by „sięgać do gwiazd”.

     

    Pamiętaj, że bogaci są zdeterminowani, aby być bogatymi. A do czego Ty jesteś zdeterminowany? Bogaci myślą na dużą skalę, a nie na małą.

     

    Twoje wynagrodzenie będzie wprost proporcjonalne do wartości (podaż, popyt, jakość i ilość), którą wnosisz na rynek.

     

    Naucz się sprzedaży i promocji — to bardzo potrzebne umiejętności.

     

    Dbaj o jakość swoich produktów i usług — wszystkich. Jeżeli jedno robisz słabo, to z ogromnym prawdopodobieństwem inne też robisz słabo.

     

    Wybieraj wynagrodzenie za wyniki pracy, a nie za pracę. I nie ustalaj górnego limitu wynagrodzenia.

     

    Koncentruj się na swoim majątku netto, a nie na dochodzie z pracy. Śledź, jak on się powiększa.

     

    Określ, co jest dla Ciebie najważniejsze, skup się na tym i regularnie to monitoruj.

    Jeżeli chcesz być bogatszy, to skoncentruj się na tych czterech elementach:

    1. Zwiększanie dochodu.
    2. Zwiększanie oszczędności.
    3. Zwiększanie inwestycji.
    4. Zmniejszanie kosztów.

     

    Regularnie poświęcaj określoną kwotę na przyjemności i nagrody — nie za mało i nie za dużo, ale zacznij już teraz zaznawać przyjemności z bogactwa.

     

    Dwa źródła biernego dochodu:

    1. Pracujące pieniądze (czynsz, dywidendy, odsetki).
    2. Biznes (zautomatyzowana firma, tantiemy, patenty, prawa autorskie).

     

    Jeżeli chcesz gdzieś dotrzeć, musisz być wojownikiem i nie pozwolić się powstrzymać. Walcz o swoje marzenia! Aby najlepiej zarabiać, musisz być najlepszy. Jeśli inni mogą (być szczęśliwi, bogaci, piękni), to Ty też możesz.

    Wszystkie posty związane z książkowymi wdrożeniami:

      Źródła

      Obraz główny

      Materiały

      • Bogaty albo biedny po prostu różni mentalnie — T. Harv Eker

       

      Linki oznaczone (*) są linkami afiliacyjnymi. Jeżeli uważasz, że czerpiesz korzyści z mojej pracy, to kup coś korzystając z powyższego linku. Sprawi to, że dostanę prowizję z afiliacji.

       

      Bezpieczne programowanie – Notatka z nauki

      przez Karol Bocian | 6 czerwca, 2022
      0 komentarzy

      W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2017 – Borys Łącki – Bezpieczne programowanie — świat pełen błędów

      Notatka z materiału: Bezpieczne programowanie:

      Zanotowałem z tego materiału:

      • Twoje oprogramowanie może przestać działać dobrze lub zostać przejęte, ponieważ:
        • Nie ma prądu.
        • Nie ma internetu.
        • Spaliła się serwerownia.
        • Jest atak DDoS.
        • Przejęto urządzenia, na którym działa Twoja aplikacja.
        • Ktoś wykradł dostęp do Twojej firmy i komputera.
        • Ustawiłeś łatwe hasło do złamania.
        • Są ustawione hasła domyślne.
        • Włamano się w bezprzewodową sieć.
        • Ktoś podejrzał hasła wpisywane przez użytkownika.
        • Domyślne ustawienia dają zbyt wiele uprawnień.
        • Włączono podsłuchiwanie w innej aplikacji / urządzeniu, co pozwoliło włamać się do Twojego oprogramowania.
      • Każde elektroniczne urządzenie, mające procesor, łączące się z internetem jest dziurą bezpieczeństwa.

      Wszystkie posty związane z notatkami z nauki:

        Źródła

        Obraz główny

        Materiał: Bezpieczne programowanie:

        Learning Software Development – Notatka z nauki

        przez Karol Bocian | 30 maja, 2022
        0 komentarzy

        W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2019 – Mariusz Gil – Learning Software Development The Hard Way

        Notatka z materiału: Learning Software Development:

        Zanotowałem z tego materiału:

        • Błędy w robieniu oprogramowania:
          • Zaczynani ode bazy danych – szukanie rzeczowników w historyjkach użytkowników.
          • Mieszanie w kodzie elementów domenowych z architekturą.
          • Tworzenie konfiguracji wyklikując ją, zamiast tworzyć ją za pomocą kodu.
          • Pomijanie testów.
          • Robienie Code Review tylko w celu poprawy jakości, a pomijanie aspektu przekazywania wiedzy (bus factor).
          • Nie robienie automatyzacji (deploye, konfiguracja środowisk).
          • Sprawdzanie nie tylko zalet danej technologii i popularności, ale również wad i kosztów.
          • Brak zrozumienia i skupienia na domenie oraz otoczeniu projektu (biznesie). Zbytnie skupienie na technologiach.
          • Wybór zbyt skomplikowanego rozwiązania.
          • Zastanawianie się, jaki problem ma rozwiązać dana historyjka użytkownika / zadanie programisty i skupianie się na rozwiązaniu problemu, a nie na samej implementacji podpunktów z zadania.
          • Co można zrobić lub zmienić, aby ten projekt popchnąć do przodu? Jak dać wartość?
        • Najważniejsze jest, po co robisz to oprogramowanie.

        Wszystkie posty związane z notatkami z nauki:

          Źródła

          Obraz główny

          Materiał: Learning Software Development:

          Doskonała obsługa klienta — Ted Johns

          przez Karol Bocian | 26 sierpnia, 2021
          0 komentarzy
          Doskonała obsługa klienta — Ted Johns

           

          Przeczytałem ostatnio kolejną książkę. W tym wpisie dzielę się informacjami, które w niej znalazłem oraz które wdrożyłem w swoim życiu. Staram się z każdej książki wdrażać minimum jedną rzecz.

           

          Wdrożyłem:

           

          1. Zwracać większą uwagę na obsługę klienta, jakość kontaktu z nim i rozwiązywanie jego problemów.

           

          Notatki:

           

          Jakość możesz poprawić głównie słuchając swoich klientów. Daj im możliwość poskarżyć się. Niech wyleją swoje żale, a Ty wysłuchaj ich i wykorzystaj do poprawy swoich usług. Jeżeli jesteś szefem, zazwyczaj informacje są przed Tobą ukrywane. Jedynym rozwiązaniem jest osobisty kontakt z klientami i uzyskanie informacji z pierwszej ręki. Słuchaj i obserwuj swoich klientów.

          Klienci w większości nie skarżą się na sam produkt czy usługę, lecz całą resztę. Jakość dla klienta to nie tylko produkt, lecz całe doświadczenie zakupu, sprzedaży, korzystania z produktu i kontaktu z firmą. Można tutaj wymienić wiele elementów, np. 

          • Niezawodność produktu/usługi.
          • Konsekwencje.
          • Szybkość dostaw, przyjazność i forma.
          • Dokładność materiałów informacyjnych.
          • Uprzejmość pracowników.
          • Renomę firmy transportowej.
          • Pozytywną postawę personelu.

          Serwis (naprawy) działa skutecznie, jeżeli wykonuje mało pracy. Nie powinien być w ogóle zauważany przez klienta, ponieważ to produkt powinien być tak dobrej jakości, że nie powinno być mowy o jego serwisowaniu. 

          Pamiętaj, że Twoje problemy nie interesują klienta. On ma swoje problemy. Rozwiąż je i nie zawracaj głowy swoimi problemami (trudnością znalezienia pracowników, brakiem prądu, etc.). Nie można zignorować oczywistych potrzeb klienta.

          To klient uznaje jakość klienta, a nie wewnętrzne wytyczne czy standardy branżowe.

          Zarządzając ludźmi pamiętaj, że ludzie robią to, za co są nagradzani. Przykład dobrej obsługi klienta idzie z samej góry, od szefa po kierowników. Cała struktura firmy, jej organizacja i kultura muszą wspierać dobrą obsługę klienta. Poprawiając ją, skup się naprawdę na jej poprawianiu, a nie tylko na działaniach pozornych (np. poprawa wystroju biura). Dbaj o swoich pracowników, a oni zadbają o klientów.

           

          Wszystkie posty związane z książkowymi wdrożeniami:

           

             

            Źródła

             

            Obraz główny

             

            • Praca własna
            • https://www.pexels.com/ 

             

            Materiały

             

            • Doskonała obsługa klienta — Ted Johns

             

            Linki oznaczone (*) są linkami afiliacyjnymi. Jeżeli uważasz, że czerpiesz korzyści z mojej pracy, to kup coś korzystając z powyższego linku. Sprawi to, że dostanę prowizję z afiliacji.

             

            Continuous Delivery w projektach Open Source – Notatka z nauki

            przez Karol Bocian | 23 maja, 2022
            0 komentarzy

            W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2017 – Marcin Zajączkowski – Continuous Delivery w projektach Open Source

            Notatka z materiału: Continuous Delivery w projektach Open Source:

            Zanotowałem z tego materiału:

            • Problemy z ręcznym wgrywaniem wersji:
              • Łatwo o pomyłkę przy ręcznym wykonywaniu kolejnych kroków budowania paczki.
              • Długi czas robienia paczki.
              • Czas poświęcony na robienie paczki można poświęcić na coś innego.
              • Robienie paczki jest nudne.
              • Jeżeli mówimy o oprogramowaniu robionym jako hobby, to często kolejne wersje są wydawane rzadko, bo nikomu nie chce się wydawać kolejnej wersji ręcznie, bo jest to nudne i pracochłonne.
            • Zalety Continous Delivery:
              • Każda wersja jest możliwa do wdrożenia.
              • Wersje są sprawdzone, bo robi je zautomatyzowany i przemyślany proces.
              • Wdrożenia są szybsze i częstsze.
              • Programiści mogą programować, a nie tracić czas na robienie paczek.
              • Taki proces może automatycznie odpalać testy oraz sprawdzać wsteczną kompatybilność.

            Wszystkie posty związane z notatkami z nauki:

              Źródła

              Obraz główny

              Materiał: Continuous Delivery w projektach Open Source:

              Pair programming – sposób na lepszy kod i mocniejszy zespół – Notatka z nauki

              przez Karol Bocian | 19 maja, 2022
              0 komentarzy

              W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2017 Krzysztof Jończyk – Pair programming – sposób na lepszy kod i mocniejszy zespół

              Notatka z materiału: Pair programming – sposób na lepszy kod i mocniejszy zespół:

              Zanotowałem z tego materiału:

              • Pair programming to technika programowania, gdzie dwie osoby siedzą przy jednym komputerze i razem rozwiązują problem.
                • Supervisor style:
                  • Jedna osoba programuje (skupienie na technologii), a druga przygląda się (skupia się na szukaniu błędów).
                  • Regularnie trzeba się zmieniać i odpoczywać.
                  • Można wprowadzić technikę Pomodoro (można zmienić długość pracy i przerw).
                • Zadanie podejmowane w Pair Programming’u:
                  • Tworzenie architektury.
                  • Refaktoryzacja starego kodu.
                • Należy pamiętać, aby regularnie wykorzystywać Pair Programming – np. 20% wszystkich zadań w sprincie.
                • Jeżeli robicie Code Review, które jest jak ping-pong, lepiej jest zrobić Pair Programming.
              • Zalety Pair Programming:
                • Code Review.
                • Wymiana wiedzy.
                • Krótszy czas na feedback.
                • Wzmacnianie więzi zespołu.
                • Szybszy feedback – od razu podczas programowania.
                • Szybsze wdrożenie do projektu i zespołu.
                • Mniej błędów.
                • Lepszy kod.

              Wszystkie posty związane z notatkami z nauki:

                Źródła

                Obraz główny

                Materiał: Pair programming – sposób na lepszy kod i mocniejszy zespół:

                W co grają ludzie. Psychologia stosunków międzyludzkich — Eric Berne

                przez Karol Bocian | 30 maja, 2022
                0 komentarzy
                W co grają ludzie

                Przeczytałem ostatnio książkę: W co grają ludzie. Psychologia stosunków międzyludzkich — Eric Berne. W tym wpisie dzielę się informacjami, które w niej znalazłem oraz które wdrożyłem w swoim życiu. Staram się z każdej książki wdrażać minimum jedną rzecz.

                Wdrożyłem z książki: W co grają ludzie. Psychologia stosunków międzyludzkich:

                1. Zastanawiam się, którą postawę przyjął mój rozmówca i próbuję odpowiedzieć postawą, która nie tworzy przecięcia relacji.

                Notatki z książki: W co grają ludzie. Psychologia stosunków międzyludzkich:

                Ta książka jest głównie dla psychologów. Ja przeczytałem jej tylko połowę. Pominąłem całkowicie część: Skarbiec gier. Pierwsza część tej książki jest jednak bardzo pouczająca.

                Przedstawia ona najpierw analizę strukturalną oraz to, że nasze ego może być w stanie (nie zawsze wyłącznie jednym):

                • Dziecko
                • Dorosły
                • Rodzic

                Każdy ze stanów określa inny zestaw potrzeb i funkcji. W swoim życiu cały czas przeplatamy bycie w tych stanach.

                 

                Ciekawie zaczyna być, gdy mamy kontakt dwóch osób. Obie z nich mogą przyjąć któryś z powyższych stanów. Ich dialog tworzy graf.

                 

                Transakcja komplementarna

                Możemy wyróżnić prostą relację komplementarną, gdy mamy z jednej strony bodziec, a z drugiej reakcję. Prześledzenie grafu może powiedzieć nam, czy relacja jest ok, czy jest z nią coś nie tak. Zasada jest prosta: wszystko jest ok, jeżeli relacje się nie przecinają.

                W co grają ludzie. Transakcja komplementarna

                 

                Przykład 1:

                1. Dorosły->Dorosły:
                  1. Może powinniśmy zastanowić się nad tym, dlaczego ostatnio więcej pijesz?
                2. Dorosły->Dorosły:
                  1. Może powinniśmy. Bardzo chciałbym to wiedzieć.

                Przykład 2:

                1. Dorosły->Dorosły:
                  1. Nie wiesz, gdzie są moje spinki do mankietów?
                2. Dorosły->Dorosły:
                  1. Na biurku.

                Transakcja skrzyżowana

                Źle jest, gdy relacja się przecina.

                W co grają ludzie. Transakcja skrzyżowana

                 

                Przykład 1:

                1. Dorosły->Dorosły:
                  1. Może powinniśmy zastanowić się nad tym, dlaczego ostatnio więcej pijesz?
                2. Dziecko->Rodzic:
                  1. Zawsze mnie krytykujesz, jak kiedyś mój ojciec.

                Przykład 2:

                1. Dorosły->Dorosły:
                  1. Nie wiesz, gdzie są moje spinki do mankietów?
                2. Dziecko->Rodzic:
                  1. Ty zawsze coś gubisz!

                Transakcje podwójne

                Nie zawsze jest jednak tak prosto, że mamy tylko jeden poziom relacji. Zdarzają się sytuacje, gdy mamy drugi poziom (ukryty) – jeden jest społeczny, a drugi psychologiczny. Możemy tutaj wyróżnić dwie dobre transakcję: transakcję kątową i transakcję podwójną.

                 

                Transakcja kątowa:

                W co grają ludzie. Transakcja kątowa

                 

                Przykład Sprzedawca – Gospododyni:

                1. Poziom społeczny: Dorosły -> Dorosły. Poziom psychologiczny: Dorosły -> Dziecko:
                  1. To jest lepsze, ale pani na to nie stać.
                2. Poziom społeczny: Dorosły -> Dorosły. Poziom psychologiczny: Dziecko -> Dorosły:
                  1. Właśnie to biorę!

                Transakcja podwójna:

                W co grają ludzie. Transakcja podwójna

                 

                 

                Przykład: Kowboj – Dziewczyna:

                1. Poziom społeczny: Dorosły -> Dorosły. Poziom psychologiczny: Dziecko-> Dziecko:
                  1. Chodź, obejrzymy stodołę!
                2. Poziom społeczny: Dorosły -> Dorosły. Poziom psychologiczny: Dziecko -> Dziecko:
                  1. Od dzieciństwa uwielbiam stodoły.

                Nauka z tego jest jedna: chcesz się z kimś nie dogadywać lub mieć konflikty, odpowiadaj postawami, które generują przecięcie relacji.

                Chcesz się zgadzać, unikaj przecięć!

                Wszystkie posty związane z książkowymi wdrożeniami:

                  Źródła

                  Obraz główny

                  • https://www.pexels.com/

                  Materiały: książka: W co grają ludzie. Psychologia stosunków międzyludzkich:

                  • W co grają ludzie. Psychologia stosunków międzyludzkich — Eric Berne

                   

                  Linki oznaczone (*) są linkami afiliacyjnymi. Jeżeli uważasz, że czerpiesz korzyści z mojej pracy, to kup coś korzystając z powyższego linku. Sprawi to, że dostanę prowizję z afiliacji.

                   

                  Wybór architektury – Notatka z nauki

                  przez Karol Bocian | 8 maja, 2022
                  0 komentarzy

                  W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: How does architect know? Łukasza Szydło – Wybór architektury.

                  Notatka z materiału: Wybór architektury:

                  Zanotowałem z tego materiału:

                  • Jaką architekturę wybrać? Która jest najlepsza?
                    • Trzeba poznać:
                      • Klienta.
                      • Cel architektury.
                      • Kontekst użycia.
                      • Kontekst tworzenia i dostępne zasoby wytwórcze.
                      • Czas i cykl życia produktu.
                      • Strukturę systemu.
                    • Czy produkt ma być:
                      • Łatwo testowalny.
                      • Łatwo utrzymywalny.
                      • Szybki do rozwijania.
                      • Niezawodny.
                      • Szybki.
                    • Wychodź z projektu i:
                      • Obserwuj otoczenie produktu.
                      • Obserwuj biznes.
                      • Oglądaj inne architektury.
                      • Rozmawiaj z klientami Twojego produktu.
                      • Rozmawiaj ze współpracownikami.
                    • Ustal najważniejsze miary dla aplikacji i procesu wytwórczego.
                    • Zrozum, co produkt ma zrobić. Nie tylko, co robi, ale też, dlaczego to robi.
                    • Praca architekta:
                      • Narzędzia.
                      • Building Blocks (pakiet funkcji zdefiniowanych w celu zaspokojenia potrzeb klienta).
                      • Cel.

                  Wszystkie posty związane z notatkami z nauki:

                    Źródła

                    Obraz główny

                    Materiał: Wybór architektury:

                    Nailing down bugs in distributed systems – Notatka z nauki

                    przez Karol Bocian | 1 maja, 2022
                    0 komentarzy

                    W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałem: Boiling Frogs 2018 – Kamil Szymański – Nailing down bugs in distributed systems

                    Notatka z materiału: Nailing down bugs in distributed systems:

                    Zanotowałem z tego materiału:

                    • Zbieraj wszystkie błędy i logi z nimi związane.
                    • Wykrywaj nowe błędy, reaguj na nie i naprawiaj (jeżeli jest to problem) lub dodaj do listy akceptowalnych błędów.
                    • Wrzucaj wszystkie logi w jedno miejsce, np. do Kibany.
                    • Nadaj ID do transakcji, aby śledzić łatwiej błędy związane z daną akcją.
                    • Są błędy, które można naprawić kiedyś, bo mają mały wpływ na biznes i takie, które generują duże straty!
                    • Zbuduj system wdrażania poprawek, który w bardzo krótki czasie (mniej niż 3 godziny) buduje aplikację, testuje i wdraża.
                    • Rób backupy (poprzednie wersje aplikacji), aby wdrożyć szybko poprzednią wersję aplikacji.
                      • Pamiętaj jednak o robieniu bazy danych wstecznie kompatybilnej.
                    • Używaj Feature Toggle (a dokładniej Release Toggle) oraz usuwaj stare i nieużywane przełączniki.

                    Wszystkie posty związane z notatkami z nauki:

                      Źródła

                      Obraz główny

                      Materiał: Nailing down bugs in distributed systems: