@TMBRK: SHA jest funkcją hashującą ogólnego przeznaczenia. Do haseł lepiej jest wykorzystać dedykowaną ku temu funkcję hashującą, np. BCrypt (który będzie dodawał sól do hasła i pozwoli trzymać to w jednej kolumnie w bazie danych). Tutaj więcej info.

@zakopiak: Blowfish sam w sobie jest algorytmem szyfrującym, wobec czego nie nadaje się do przechowywania haseł. Zamiast niego potrzebna jest funkcja hashująca, np. BCrypt (który swoją drogą jest oparty o Blowfisha, ale w sposób transparentny dla użytkownika).

@secret_passenger:

1) jest przekomplikowana

Tak można powiedzieć w zasadzie o każdym języku. Przydałyby się jakieś konkrety.

2) scala z Catz i scala z scalaz to prawie dwa

Pokaż całość

@vytah:

Jest to język skomplikowany

Jak wyżej: tak można powiedzieć w zasadzie o każdym języku. Przydałyby się jakieś konkrety.

pozwalający na dużą

Pokaż całość

@Scaab: @hitherto Napisałeś że robienie CRUD-ów to gównorobota i uraziłeś dumę wykopków xD I jeszcze te argumenty które się tutaj pojawiły, że przecież na tym polega ta branża xD Niestety Twoje spostrzeżenia są słuszne: wiekszość ofert to absolutne szambo. Dobrze płatne, ale szambo. Taka praca polega wówczas na utrzymywaniu jakiegoś legacy molochu, napisanego przez ludzi którzy nie mieli ambicji żeby sięgnąć po coś bardziej ambitnego niż książki Wuja Boba.Pokaż całość

@luxkms78: Różnice pojawiają się również w tym jaki styl pisania aplikacji promują community tych języków. W przypadku Kotlina to nadal będą aplikacje mocno w stylu Javowym (z tym że do ich napisania będziesz używał dużo wygodniejszych konstrukcji językowych niż te Javowe), natomiast w przypadku Scali to często jest zmiana całego paradygmatu: od hybrydy programowania funkcyjnego z obiektowym, do programowania mocno opartego o FP.

@Adaslaw: Tę Scalę to wywal, bo w niej Spocka akurat używa się bardzo rzadko. Zamiast tego jest ScalaTest lub Specs2, które potrafią to samo co Spock, ale robią to w statycznie typowany sposób.

@Adaslaw: Różnica między ScalaTest/Specs2 a JUnit jest ogromna. To że jedno i drugie jest statycznie typowane, to chyba jedyna wspólna cecha ;)

@Adaslaw: Zdefiniuj zwinność :P Pokaż jakiś przykład czy coś.

@olektrolek: Ta wygoda jest bardzo pozorna. W rzeczywistości takie rozwiązanie przynosi więcej szkód niż pożytku.

@SharkyShark: Jak najbardziej mogę rozszerzyć myśl. No więc przede wszystkim odnosiłem się do mechanizmu Spring DI, a niekoniecznie do samego Springa (aczkolwiek jego fanem również nie jestem). To dlatego że ten mechanizm jest oparty o runtime reflection, a więc graf zależności jest budowany dopiero w czasie działania aplikacji. To z kolei jest źródłem kilku poważnych problemów:
* nie jesteś w stanie w łatwy sposób zobaczyć jak wygląda graf zależności TwojejPokaż całość

@panczekolady: Dla Springa czy dla runtime dependency injection?

@panczekolady: Podejście, które moim zdaniem się sprawdza, to ręczne budowanie grafu zależności. Masz jakieś jedno miejsce w aplikacji, w którym inicjalizujesz wszystkie niezbędne komponenty do działania. Dzięki temu masz pełny wgląd w to co jest inicjalizowane i gdzie jest przekazywane. Do tego masz pełne wsparcie kompilatora, który nie pozwoli żebyś zapomniał o przekazaniu jakiejś zależności. Ponadto sprawia że bardziej pilnujesz się z tym gdzie trafia jakaś zależność, i czy przypadkiemPokaż całość

@farmaceut: Przekształć te klasy na niemutowalne. Nie będziesz musiał przejmować się getterami, setterami, polami prywatnymi itp.

@Kresse: W tym rozwiązaniu z niemutowalnością, dobrze by było żeby pola były final.

@inquis1t0r:
- Konfitura: https://www.youtube.com/watch?v=2EHNfvKKWGI
- Spiżarnia: https://www.youtube.com/watch?v=bqFyEYXh7s0