Organizacja błędów aplikacji w środowisku produkcyjnym
Jako osoby odpowiedzialne za tworzenie oprogramowania powinniśmy dążyć do tego aby w naszym kodzie występowała jak najmniejsza ilość defektów. Czas i koszt ich naprawy rośnie wraz z tym jak późno je wykrywamy oraz jak wielkie zawiłości posiadamy w kodzie. Zdarza się, że są błędy których się nie poprawia, ponieważ koszt ich naprawy wielokrotnie przekracza wartość dodaną do aplikacji – uznając, że da się z tym żyć.
Dev:Cast – Unit Tests – Dobre praktyki
Testy jednostkowe to temat, który nie raz poruszaliśmy podczas naszego podcastu. Wspominaliśmy o ich wartości, głównych zasadach ale także zachwalaliśmy technikę Test-driven development. Z naszych rozmów jednoznacznie wynika, że praca bez Unit Tests jest dla nas ciężka i tak na prawdę zwiększa ilość pracy…
Tym razem skupiliśmy się na definicji kilku dobrych praktyk wspomagających tworzenie testów jednostkowych. Takich testów, które dobrze weryfikują implementacje, zapewniają jakość oraz łatwo jest je utrzymywać.
#devenv #devcast #programowanie #dobrepraktyki #unittests #technicalblog
Terraform wprowadzenie
Terraform to narzędzie służące do zarządzania infrastrukturą, pliki terraforma tworzone są w języku HCL (HashiCorp configuration language). Dzięki temu że zmiany w infrastrukturze są przechowywane jako kod, można je wersjonować, przeprowadzać code review lub też łatwo dzielić się z zespołem informacjami co dokładnie zostało zmienione.
Siema, wracamy z kolejnym postem o #RUST. Tym razem na tapet bierzemy Moving Ownership. Zapraszamy! ;)
Przez jakiś bug nie mogę zmodyfikować mojego postu, a wypadałoby dorzucić inną ważną informację: każda struktura w Ruście ma z góry określony, znany w trakcie kompilacji rozmiar (w odniesieniu do pierwszego cytowanego przeze mnie wyżej fragmentu). Typami odbiegającymi od tego są jedynie traity i slice'y (https://doc.rust-lang.org/nomicon/exotic-sizes.html).
Dzięki @Patryk27.
W Rust nie ma słówka kluczowego class, ale jakoś struktura, która implementuje traity lub własne funkcje jest dla mnie klasą. Reprezentuje dane wraz z zachowaniami.
Trait to jest deklaracja interfejsu podobna do tych z C# lub Javy, ale nie identyczna.
Miałem to rozdzielone, bo to o czym wspominasz czyli implementacja trait Copy opisana była poniżej. Podkreśliłem to bardziej.
Typy proste to prymitywy. Typy złożone to struktury.
Co macie na myśli poprzez wykorzystać dziedziczenie? Zmieniłem by było jasno wypisane, że chodzi o implementacje konkretnego traita a nie o całe zjawisko dziedziczenia.
W kolejnych częściach planuje opisać: Borrowing, wpływ mutowalności, slice. Nie chciałem naraz wprowadzać dużej ilości pojęć. Dodałem zdanie zapowiadające by czytelnik wiedział.
Rc, Arc, Mutex planuje wprowadzić dopiero w późniejszych częściach, bo to są mechanizmy skierowane na współbieżność.
Dzięki za feedback i pomoc :)
Rust – Ownership – Po co nam ta własność?
Ownership jest głównym mechanizmem języka Rust, który umożliwia uzyskanie gwrancji bezpieczeństwa pamieci już na etapie kompilacji. Co jest w nim takiego unikalnego? Jak może nam pomóc w codziennej pracy programisty? Co nam tak naprawdę gwarantuje?
Dzięki za pomoc i uwagi
@cerrato: niezamierzona literówka.
@Patryk27: Faktycznie chodziło mi o typ :) Faktycznie użycie stwierdzenia "własny" jest niefortunne, bardziej odpowiednie byłoby unikalny.
Co do stwierdzenia "nie zwalnia programisty z konieczności posprzątania" bardziej chodziło mi o dobrą praktykę i fakt, że może dojść do sytuacji wycieku pamięci w tych językach. Zbytnie uproszczenie. Przeformatuje to.
Ze względu na charakter tekstu nie chciałem odnosić się do usingów, Disposable oraz unsafe. GC w większości przypadków w końcu się aktywuje lub mu w tym pomożemy robiąc to ręcznie lub skończy się pamięć :)
W Ruście faktycznie występuje mechanizm bazujący na zliczaniu odwołań. Nie chciałem wrzuczać tego do wora GC znanego mi z C# i Javy.
@Dregorio: Niestety to jest wstęp za tydzień wrzucę drugą część z kilku. Ownership okazał się bardziej złożonym tematem, na więcej niż jeden artykuł.
Dev:Cast – Dlaczego (nie?)powinno się robić wdrożenia w piątek popołudniu?
Jest piątek, wybija godzina 15:00. Pozostała zaledwie godzina do końca pracy. Do Twojego zespołu dociera informacja, że koniecznie teraz musicie wdrożyć na produkcję zmiany, które w ostatnim czasie wprowadziliście. Wdrożenia w piątek = istny koszmar? 😲
Zapraszamy do odsłuchu naszego podcastu, w którym tym razem poruszamy temat wdrożeń na produkcję.
Ups! Właśnie do ciebie dotarło, że wraz z twoimi zmianami, do serwera powędrowało twoje hasło, zapisane gdzieś w kodzie! Natychmiastowo usuwasz hasło z plików źródłowych, tworzysz nowy commit i ponownie: push. Uff… już po sprawie…
Kiedyś zgłaszałem autorom https://github.com/RestComm/R[...]50e7679f089a0994c6907cc23f74f Hasło zmienili, ale czy audytowali swoje prywatne repo to już nie wiem ;-) Z ciekawości zapuściłem google po: site:github.com "sshpass -p" filetype:sh i po przejrzeniu iluś tam stron trafiają się np. https://github.com/europeana/[...]lob/master/deployPublisher.sh
Cześć, kilku odcinków tutaj nie było, ale wydaje się, że ten temat będzie dla was ciekawy.
Dev:Cast – Nadgodziny w IT. Tak czy nie?
Dotychczasowa praca zawodowa wielokrotnie pokazała nam, że estymacja projektów i dostarczanie ich na czas to element układanki, który często nam nie wychodzi. Zamiast szukać rozwiązań tych problemów posługujemy się dociskaniem projektów w ramach nadgodzin. 🕗 Jakie inne elementy sprawiają, że w realizowanym projekcie jesteśmy zmuszeniu lub chcemy realizować coś więcej kosztem swojego wolnego czasu?
Żyjemy w erze, kiedy nowe języki, frameworki, miodne biblioteki pojawiają się jak grzyby po deszczu. Nauka nowego języka wymaga inwestycji czasu. Jak w kontekście powyższego przedstawia się RUST? Czy i kiedy warto po niego sięgnąć?
Ayy - jak na artykuł techniczny, sporo w nim nieścisłości.
Rust jest językiem funkcyjnym
Rust jest językiem wieloparadygmatowym.
kompilator zadba o brak występowania wyścigów.
Nie do końca - Rust zapewnia bezpieczeństwo przed data race, co nie oznacza, że nie można w nim zrobić np. deadlocka (bo można i nie jest to specjalnie trudne).
Jeśli programujesz w językach takich jak C# czy Java, mających wbudowany mechanizm garbage collector (..)
https://words.steveklabnik.co[...]d-the-generational-hypothesis
Struktury nie mogą dziedziczyć po innych strukturach. Nie ma sposobu, aby zdefiniować strukturę, która dziedziczy pola i implementację metod struktury nadrzędnej.
W takim razie w jaki sposób działa Box? :-)
Minusem może być, że język nie wymusza struktury, więc każdy programista może sobie zdefiniować, rozszerzyć cokolwiek potrzebuje w dowolnym miejscu.
Nieprawda: https://doc.rust-lang.org/stable/error-index.html#E0116.
Jest optymalizowany pod kątem architektury, na której działa kompilator.
Nieprawda: Rust (wykorzystujący pod spodem LLVM) jak najbardziej umożliwia cross-compiling, gdzie np. binarka ARM produkowana i optymalizowana jest na hoście x86.
Kompilator podobnie (jak w przypadku ownershipu) nie pozwoli, by aplikacja się skomplikowała, jeśli może dojść do jakichkolwiek negatywnych zjawisk.
Nieprawda: w runtime może dojść np. do deadlocka (liczy się jako negatywne zjawisko, prawda?).
Hej @Patryk27 Dzięki za pomoc ;-) Jak najbardziej masz rację. Niektóre z tych rzeczy to były skróty myślowe, a niektóre to moje zaniedbania lub niewiedza ( czytałem LLVM, ale dzięki tej wskazówce będę mógł pogłębić wiedzie w tym zakresie, a E0116 to moja niewiedza ). Dzięki tobie będę mógł ulepszyć artykuł.
Aventus
@danek: pierwsze słyszę o takiej idei testów jednostkowych. No ale nie będę się czepiał szczegółów, domyślam się o co Ci chodzi. Natomiast nie wierzę w to że przy bardziej rozbudowanej logice wszystkie testy jednostkowe wykonują się w 1-2 sekundy. Faktycznie, testy które opisałem są wolniejsze, ale nieznacznie. To nie są pełnoprawne testy integracyjne a kompromis- coś za coś. Ponadto, jestem przekonany że znacznie zaoszczędza się na czasie przy pisaniu nowych testów, ponieważ nie muszę się rozdrabniać dla każdej nowo napisanej "jednostki". Jeśli nowa funkcjonalność jest w ramach już istniejącej, pokrytej testami to w ogóle nie ma potrzeby na pisanie nowych testów.