Jakie są najlepsze biblioteki Haskell do operacjonalizacji programu? [zamknięte]

Jeśli mam wprowadzić program do produkcji, jest kilka rzeczy, które muszę zrobić, aby uznać go za "operacjonalizowany" – to znaczy, uruchomiony i utrzymywany w sposób mierzalny i weryfikowalny zarówno przez inżynierów, jak i personel operacyjny. Dla moich celów program operacyjny musi:

  • możliwość logowania na wielu poziomach (np. debugowanie, Ostrzeżenie itp.).
  • być w stanie zbierać i udostępniać metryki/statystyki dotyczące rodzajów pracy, którą wykonuje program i jak długo ta praca trwa. Idealnie, zebrane metryki są dostępne w formacie zgodnym z powszechnie używanymi narzędziami monitorującymi, takimi jak zwoje, lub mogą być tak zmontowane.
  • być konfigurowalne, najlepiej poprzez system, który pozwala na aktualizację skonfigurowanych właściwości uruchomionych programów bez ponownego uruchamiania tych programów.
    • Być wdrażane na zdalnych serwerach w sposób powtarzalny.

W świecie Scali są dobre biblioteki do radzenia sobie przynajmniej z pierwszym trzy wymagania. Przykłady:

Jeśli chodzi o wdrażanie, jednym z podejść w świecie Scali jest połączenie bajtowego kodu i bibliotek, które składają się na program za pomocą czegoś w rodzaju assembly-sbt , a następnie wypchnięcie otrzymanego pakietu ("fat JAR") na zdalne serwery za pomocą narzędzia typu Capistrano , które wykonuje polecenia równolegle przez SSH. Nie jest to problem, który wymaga narzędzi specyficznych dla języka, ale jestem ciekaw, czy takie narzędzie istnieje w społeczności Haskell.

Prawdopodobnie istnieją Biblioteki Haskella, które dostarczają cech, które opisałem powyżej. Chciałbym wiedzieć, które z dostępnych bibliotek są uważane za "najlepsze"; to znaczy, które są najbardziej dojrzałe, dobrze utrzymane, powszechnie używane w społeczności Haskell i wzorowe Haskell best praktyki.

Jeśli są jakieś inne biblioteki, narzędzia lub praktyki związane z tworzeniem kodu Haskella "gotowego do produkcji", chciałbym wiedzieć o nich również.

Author: Jonas, 2011-04-27
Source

3 answers

To jest świetne pytanie! Oto pierwsze cięcie.

Możliwość logowania na wielu poziomach (np. debugowanie, Ostrzeżenie itp.).

Hslogger jest łatwo najpopularniejszym frameworkiem logowania.

Być w stanie zbierać i udostępniać metryki/statystyki dotyczące rodzajów pracy wykonywanej przez program i jak długo trwa ta praca. Idealnie, zebrane metryki są dostępne w formacie zgodnym z powszechnie używanymi narzędziami monitorującymi, takimi jak zwoje lub potrafi być taki zmiękczony.

Nie znam żadnych standardowych narzędzi raportowania, jednak wyodrębnianie raportów ze strumieni +RTS -s (lub poprzez profilowanie FLAG wyjściowych) było czymś, co robiłem w przeszłości. 

$ ./A +RTS -s
64,952 bytes allocated in the heap
1 MB total memory in use
 %GC time       0.0%  (6.1% elapsed)
 Productivity 100.0% of total user, 0.0% of total elapsed

Można to również uzyskać w formacie do odczytu maszynowego: 

$ ./A +RTS -t --machine-readable

 [("bytes allocated", "64952")
 ,("num_GCs", "1")
 ,("average_bytes_used", "43784")
 ,("max_bytes_used", "43784")
 ,("num_byte_usage_samples", "1")
 ,("peak_megabytes_allocated", "1")
 ,("init_cpu_seconds", "0.00")
 ,("init_wall_seconds", "0.00")
 ,("mutator_cpu_seconds", "0.00")
 ,("mutator_wall_seconds", "0.00")
 ,("GC_cpu_seconds", "0.00")
 ,("GC_wall_seconds", "0.00")
 ]

Idealnie można dołączyć do uruchomionego środowiska GHC przez gniazdo i spojrzeć na te statystyki GC interaktywnie, ale obecnie nie jest to bardzo łatwe (wymaga wiązania FFI do "RTS / Stats.H " interfejs). Ty można dołączyć do procesu za pomocą ThreadScope i monitoruj zachowanie GC i threading.

Podobne flagi są dostępne dla przyrostowych, rejestrowanych czasu i przestrzeni profilowania, które mogą być używane do monitorowania (np. te wykresy mogą być budowane stopniowo).

hpc gromadzi wiele statystyk dotyczących wykonania programu, poprzez jego typ Tix, a ludzie mają napisane narzędzia do logowania przez time-slice jaki jest kod wykonuję.

Być konfigurowalne, najlepiej poprzez system, który pozwala na aktualizację skonfigurowanych właściwości uruchomionych programów bez ponownego uruchamiania tych programów.

Dostępnych jest do tego kilka narzędzi, możesz przeładować stan w stylu xmonad lub przejść do hotswappingu kodu poprzez plugins* paczki lub hint. Niektóre z nich są bardziej eksperymentalne niż inne.

Powtarzalne wdrożenia

Galois niedawno wydany cabal-dev, który jest narzędziem do wykonywania powtarzalnych kompilacji(tzn. zależności są zakresowane i kontrolowane).

 54
Author: Don Stewart,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-28 02:53:06
  • Jeśli chodzi o konfigurację, znalazłem plik ConfigFile jako przydatny dla moich projektów. Używam go do wszystkich moich demonów w produkcji. Nie aktualizuje się automatycznie.
  • używam cabal-dev do tworzenia powtarzalnych kompilacji w różnych środowiskach (local, dev, collaboration-local). Naprawdę cabal-dev jest niezbędny, szczególnie ze względu na jego zdolność do obsługi lokalnych, łatanych wersji bibliotek w katalogu projektu.
  • jeśli to ma jakieś znaczenie, wybrałbym przeładowanie stanu w stylu xmonad. Czystość Haskell czyni to banalnym; migracja jest problemem, ale i tak jest. Eksperymentowałem z hspluginami i podpowiedzią dla mojego IRCd i w pierwszym przypadku był problem z uruchomieniem GHC, a w drugim błąd segmentacji. Zostawiłam gałęzie na Githubie na później: https://github.com/chrisdone/hulk

Przykład Pliku ConfigFile: 

# Default options
[DEFAULT]
hostname: localhost
# Options for the first file
[file1]
location: /usr/local
user: Fred
 9
Author: Christopher Done,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-28 09:42:08

Powtórzę wszystko, co powiedział Don i dodam kilka ogólnych rad.

Na przykład dwa dodatkowe narzędzia i biblioteki, które warto rozważyć:

  • QuickCheck do testowania na podstawie właściwości
  • hlint jako rozszerzona wersja -Wall

Oba są ukierunkowane na jakość kodu.

Jako praktyka kodowania, unikaj leniwych IO. Jeśli potrzebujesz streamingu IO, skorzystaj z jednej z bibliotek iteratee, takich jak enumerator . Jeśli spojrzysz na Hackage zobaczysz biblioteki takie jak http-enumerator, które używają stylu enumerator dla żądań http.

Jeśli chodzi o wybieranie bibliotek na hackage ' u, czasami może pomóc przyjrzeć się, ile pakietów zależy od czegoś. Łatwo zobaczyć odwrotne zależności pakietu można użyć tej strony internetowej, która mirrory hackage:

Jeśli twój wniosek kończy się robiąc ciasne pętle, jak serwer WWW obsługujący wiele żądań, lenistwo może być problemem w postaci wycieków przestrzeni. Często jest to kwestia dodania dokładności adnotacji w odpowiednich miejscach. Profilowanie, doświadczenie i czytanie to główne techniki, które znam w walce z tego typu rzeczami. Najlepsze odniesienie do profilowania, jakie znam, to Rozdział 25 zprawdziwego Haskella .

 9
Author: Jason Dagit,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-05-31 23:10:33