Scala Native
Który język programowania wybrać na początek - język natywny
Wiele osób pyta się, który język programowania wybrać na początek jako pierwszy język do nauki. Wiele jednak zależy od tego do czego chcemy użyć tego języka programowania. Dlatego wybrałem zwycięzców w czterech kategoriach: dynamicznie typowany język skryptowy ogólnego przeznaczenia statycznie typowany język korporacyjny używany do pisania długowiecznych aplikacji klasy enterprise język fullstackowy, który można używać do pisania frontendu i backendu szybki język natywny działający bez maszyny wirtualnej i interpretera
Konfiguracja fabryki loggerów z biblioteki slogging w Scali
W poście Biblioteki do logowania dla języka Scala skonfigurowałem logger slogging. Zapomniałem tylko wybrać fabrykę loggerów. Bez tego logger w ogóle nie działa.
Krótki opis konstrukcji kompilatorów GCC, LLVM i Clang
W dawnych czasach każdy dobry programista chciał napisać swój własny kompilator języka C. Co prawda te czasy już minęły i dziś większość z nas programuje w językach o wiele bardziej złożonych niż C. Dzięki czemu jesteśmy w stanie pisać szybciej kod. Ale nadal warto znać podstawy budowy kompilatorów. Na szczęście konstrukcja kompilatora jest prosta jak konstrukcja dzidy bojowej. Dzida bojowa składa się z: przeddzidzia dzidy bojowej śróddzidzia dzidy bojowej zadzidzia dzidy bojowej.
Scala - No Universal Equality
Ostatnim błędem zgłaszanym w kodzie projektu resentiment przez scalafix jest “No Universal Equality” wynikający z użycia operatora ==.
Biblioteki do logowania dla języka Scala
Chcąc dowiedzieć się co dzieje się wewnątrz naszej aplikacji mamy dwie drogi. Pierwszym sposobem jest debugowanie. Jednak im więcej wątków w aplikacji i im bardziej komunikują się one w sposób asynchroniczny tym trudniej jest debugować. Drugim sposobem jest logowanie informacji. Najprostszym sposobem logowania informacji w Javie jest System.out.println, a w Scali upraszcza się to do println. Ale jest to złe z dwóch powodów: Po pierwsze, jeśli piszemy aplikację “konsolową” (ang. command line interface, CLI) to użytkownik będzie niepotrzebnie widział nieinteresujące go informacje z wewnętrznego procesu przetwarzania. Tak wypisanych informacji nie można zapisać w bazie danych ani wysłać do innego systemu.
Ciągła integracja, ciągła kontrola, ciągła Scala
W poprzednich wpisach zbudowaliśmy ogromne polecenie do analizy statycznej i dynamicznej kodu projektu oraz generacji raportów. Jednak wykonanie tego polecenia trwa. A programiści nie lubią czekać.
Bardziej dynamiczna analiza kodu dla języka Scala - Property-based testing
Testy modułowe (jednostkowe) napisane w poście Dynamiczna analiza kodu dla projektu resentiment zawiodły. Mimo posiadania 100% pokrycia kodu dla klasy Calculator klasa ta nie działała w sposób poprawy.
Statyczna analiza kodu dla języka Scala w SBT - część 2.
Jest to kontynuacja posta Statyczna analiza kodu dla języka Scala w SBT - część 1.
Dynamiczna analiza kodu dla SBT - testy jednostkowe
Dynamiczna analiza programu to analiza oprogramowania komputerowego wykonywanego przez wykonywanie programów na rzeczywistym lub wirtualnym procesorze. Korzystanie z metryk testów, takich jak pokrycie kodu, zapewnia, że przetestowano odpowiednią ilość możliwych zachować programu. Aby analiza dynamiczna programu była skuteczna, program docelowy musi być wykonany z wystarczającą ilością danych wejściowych do testów, aby uzyskać interesujące zachowanie. Testy jednostkowe, testy integracyjne, testy systemowe i testy akceptacyjne wykorzystują dynamiczną analizę programu.
Przenośna Scala
Znajomy zajarał się językiem Rust. Opowiada mi jaki to wspaniały język i pokazuje przykłady kodu. Rust na pierwszy rzut oka wygląda jak skrzyżowanie C i języka Haskell plus kanały jak w języka Go. Czyni go to pretendentem do bycia najbardziej skomplikowanym językiem programowania na świecie. Pretendentem, bo istnieje wśród programistów JVM opinia, że najbardziej skomlikowanym językiem na świecie jest Scala. Scala jest skrzyżowaniem Javy i Haskella plus aktory z języka Erlang.