Scala Native

Opis powstawania projektu resentiment w języku programowania Scala, Scala.js i Scala native.

Biblioteki do logowania dla języka Java i platformy JVM

6 minut(y)

W artykule Konfiguracja fabryki loggerów z biblioteki Slogging w Scali autorytarnie stwierdziłem, że Logback dla JVM jest najlepszym silnikiem do logowania. Czytając artykuł Programowanie w Rust: The Good, The Bad and The Ugly zszokowała mnie informacja, że programista nie wie która biblioteka logowania dla Javy jest najlepsza. Prawdziwa klęska urodzaju. I programista nie wie co wybrać

Scala - No Universal Equality

6 minut(y)

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

9 minut(y)

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

12 minut(y)

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ć.

Flagi kompilatora Scalac

8 minut(y)

Nie bójmy się tego powiedzieć, Scala to nowy Perl. I tak jak w Perlu, w Scali obowiązuje zasada TIMTOWTDI (ang. There is more than one way to do it), czyli “Można to zrobić na różne sposoby”.

Statyczna analiza kodu dla języka Scala w SBT - część 1.

5 minut(y)

Statyczna analiza programu to analiza oprogramowania komputerowego wykonywanego bez faktycznego uruchamiania programów, w przeciwieństwie do analizy dynamicznej, która jest analizą wykonywaną na programach podczas ich wykonywania.

Dynamiczna analiza kodu dla SBT - testy jednostkowe

7 minut(y)

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

5 minut(y)

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.

Wróć do góry ↑