W tym tygodniu było kilka interesujących problemów i ciekawych nauk na przyszłość. Trochę mięsa jak i trochę architektury. Zapraszam do szybkiej lektury. Zrymowało się przypadkowo.
Sugestia architektoniczna (testy)
Testy są dobre, ważne i każdy to wie, ale testów i tak nie piszę się tyle, ile trzeba, bo czasem ciężko je napisać itd. Ciekawą myśl usłyszałem.
Jeśli w systemie jest dobrze przeprowadzony proces deploy, to znaczy, że po commicie zmiana znajdzie się szybko na produkcji to część testów można nie pisać, bo jeśli wyskoczy błąd to szybko będzie można go naprawić i zaktualizować produkcję.
Jest to o tyle ciekawe, że czasem sporo czasu idzie na pisanie testów, które jak by się przyjrzeć z boku nie są krytyczne z perspektywy biznesu, który obsługujemy. Oczywiście warto później napisać testy ale tak jak mówiłem, nie staje się to krytyczne.
Sugestia architektoniczna (błędy)
Tą myśli też usłyszałem, że są 2 typy błędów, te które dotyczą wyjątków, które rzuca aplikacja i te, które nie rzucają wyjątków, te najczęściej są w logice.
Pierwszy typ błędów jest dość oczywisty i bezpieczny. Jeśli wyskoczy wyjątek to klient to zgłosi, proces się cofnie, bo pewnie był w transakcji itd. Takie błędy raczej szybko się naprawia i nie powodują wielkich problemów z biznesem. Dodatkowo takie błędy, nie są krytyczne pod względem testowania (patrzy akapit wyżej) co powoduje, że możemy je pominąć (może nie całkowicie ale przełożyć na inny etap)
Drugi typ jest jednak gorszy. To błędy w logice. Czyli takie błędy, które nie rzucą wyjątku tylko przejdą linijki kodu gładko ale stan w aplikacji będzie nie pożądany. Takie błędy są drogie w naprawie, bo zamieniamy się w archeologa kodu aby znaleźć błąd, gdy już znajdziemy błąd, to samo cofanie zmian, które błąd wywołał jest nie lada problemem i wyzwaniem. Taką logikę warto testować i to dokładnie. Niestety kolejna przeszkoda to taka, że czasem testy jednostkowe nie dają jakieś dobrej ochrony i bez testów integracyjnych nie mamy szans osiągnąć bezpiecznego minimum.
Automatyka tworzenia build-ów w środowisku ciągłej integracji
Pod słyszane na konferencji ale dość ważne mi się wydaje. Każdy z Nas w firmie, której pracuje używa jakiegoś środowiska do ciągłej integracji (TeamCity, Jenkins). Można w nich tworzyć buildy, które testują nasza aplikację robią deploy i inne ważne rzeczy.
I teraz patrząc na konfigurację, najczęściej jest tego bardzo dużo, sporo różnych konfiguracji, różnych środowisk. Najczęściej taką konfigurację wyklinujemy.
Często zmiany w konfiguracji, trzeba modyfikować w każdym build-ie. To powoduje, że ktoś musi dużo poklikać aby zmiany wprowadzić. Pomysłem na to jest trzymanie konfiguracji w skryptach. Tak, żeby w każdej chwili móc stawiać serwer od początku i wykonać skrypty z konfiguracją automatycznie.
Daje nam to:
- brak potrzeby posiadania backup-u, bo zawsze w każdej chwili możemy stawiać sobie środowisko ciągłej integracji
- szybie zmiany parametrów do build-ów, bez potrzeby żmudnej pracy
Edytowanie wierszy w SQL Management Studio
Domyślnie w SSMS można tylko edytować wiersze w pojedynczych tablach. Czasem jednak chcieli byśmy edytować tylko wybrane wiersze (używając WHERE) w danej tabeli. Możemy to zrobić poprzez zainstalowanie dodatku ale czasem nie ma jak albo jesteśmy na produkcji i nie chcemy tego robić.
Aby edytować wiersze używając dowolnego wyrażenia WHERE w SSMS należy:
- Wybrać tabelę i zrobić Edit Top 200 Rows
- Następnie na tabeli, która się wyświetli wybrać PPM opcję Pane a następnie SQL
- Następnie w oknie mamy dostęp do SQL-a, który możemy modyfikować zgodnie z naszymi załażeniami.
- Następnie aby uruchomić zmodyfikowane zapytanie wybieramy PPM opcję Execute SQL lub Ctrl + R. Nie używamy F5, bo to nie zadziała.
- Następnie możemy już edytować te wiersze, które zwróciło zapytanie. Edytujemy i Enter
Jedyny minus, że nadal nie można edytować wierszy, które w swoich zapytaniach używają JOIN-ów.
Log Points – chrome – narzędzie dla deweloperów
Krótka piłka. Zamiast pisać świętą instrukcję w js console.log() i sprawdzać w konsoli logi ze skryptów, to można teraz wstawić odpowiednik
console.log() bezpośrednio z chorm-a. Wystarczy na skrypcie na numerze linij kliknąć PPM i wybrać Add logpoint
Opis dokładny jest tutaj:
https://developers.google.com/web/updates/2019/01/devtools#logpoints
Live Expressions – chrome – narzędzie dla deweloperów
Co prawda to już się pojawiło jakiś czas temu (Chrome 70) ale jakoś wtedy nie pisałem o tym. Od teraz można tworzyć żywe wyrażenia JavaScript w zakładce „console” przy użyciu jQuery, które będą monitorowane przez chrom-a.
Działa to tak, że można wstawić dowolne wyrażenie i chrom będzie je monitorował i sprawdzał jaką ma wartość przez cały czas bycia na stronie (jakiejkolwiek), dodatkowo wystarczy wpisać raz takie wyrażenie i chrome do końca życia będzie je pamiętał. W zakładce console można wtedy widzieć na żywo zmianę tej wartości. Bardzo przydatne i mocno przyspiesza pracę i debugowanie.
Opis dokładny tutaj:
https://developers.google.com/web/updates/2018/08/devtools#watch