пропозиції роботи
Wypowiedzi
-
Świetny język dla "drążących" osób, bogata składnia i bardzo wysoka eksperymentalność/innowacyjność. Jednak trochę z tych samych powodów moim osobistym zdaniem ciężko będzie Scali zastąpić javę w mainstreamie:
- Znacznie wyższe bariery wejścia i okres nauki języka żeby osiągnąć podobną produktywność co w javie -> o wiele trudniej o dobrego speca od Scali niż o dobrego speca od Javy
- eksperymentalność i zmienność języka/biblioteki nie wpływa dobrze na jego percepcję przez poważny biznes no i dochodzi większa liczba potencjalnych błędów / regresji z wersji na wersję
- znacznie mniejszy wybór bibliotek / frameworków, są odpowiedniki bibliotek w javie ale jest ich po prostu mniej
Osobiście uważam że w nowych projektach / zespołach wejście w scalę jako jedyny jezyk dla całych projektów ma sens gdy można zbudować cały team osób na conajmniej dobrym poziomie. Wtedy ryzyko strzelenia sobie w stopę jest małe a korzyści ze scali będzie w stanie taki team wyciągnąć. Gdy nie da się spełnić tego warunku, to moim skromnym zdaniem java się lepiej sprawdzi z biznesowego punktu widzenia (możliwość znalezienia przyzwoitego zastępcy dla odchodzących, ryzyko pozostawienia kodu nienadającego się do pracy itp.). -
zakładając że to nie jest post kryptoreklamowy ;). Moim zdaniem:
1. aktualnie duża część aplikacji to bogaty klient gdzie redeploy nie jest specjalnie istotny bo praca (rest vs gruby klient) jest / może być rozdzielona
2. jeżeli używasz MVC gdzie widokiem jest generowany html zwracany przez servlet istnieją już frameworki / podejścia minimalizujące konieczność redeploya np. użycie języków interpretowanych dla kontrolera, a w warstwie szablonu to już bardzo popularne że szablon jest umieszczony poza pamięciowym kontekstem aplikacji. Także to tylko kwestia chęci żeby mieć albo tylko szablony / js / css redeployowane lub podejście absolutne czyli także kontrolery.
Moim skromnym zdaniem nejlepiej z punktu widzenia projektu po prostu poprawnie używać TDD na mvc wtedy znaczenie badania live wyników maleje a pozostają korzyści długoookresowe gdy przyjdzie do refaktoringu / dodania nowej funkcjonalności. -
Singleton jest uważany generalnie za przestarzały głównie ze względu na utrudnienia w testowaniu aplikacji gdzie utrzymanie kontekstu globalnego w singletonach a nie izolowanego mocno utrudnia / zwiększa koszt testowania automatycznego. Jednym z potencjalnych zastępników jest użycie singletonu na poziomie "logicznym" a nie na wykorzystując statyczny dostęp. Mam na myśli np. bean typu singleton w Springu itp. który bardzo prosto można podmienić w testach / zmienić na mocka Oczywiście można sobie wyobrazić jakieś tematy w których nie można tego dokonać (np. brak DI), wtedy to już jednak trzeba indywidualnie się przyglądać wymaganiom.
-
Przetestuj czy prawidłowo przechwytuje SIGTERM (lub jakkolwiek jest to nazwane pod winapi) i przekazuje do procesu potomnego javy. Niestety nie wszystkie wrappery prawidłowo implementują przechwytywanie tego sygnału na windowsie co powoduje że przy stopowaniu usługi brakuje możliwości "czystego" zamknięcia usługi.
-
-
czy to wątek filozoficzny czy techniczny?
-
Kolejny wątek który z merytorycznej dyskusji czysto programistycznej (ciekawej) spadł do wątku promującego usługi Pana naprawiającego robotę tych złych programistów...
-
Jarosław Ż.:
zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)
a dlaczego niby są to wykluczające się rzeczy? -
dodatkowo:
- czy preferowana jest wysoka przepustowość systemu jako całości a "latencja" systemu jest na drugim miejscu? -
Czy można to zadanie uprościć do:
- zleć robotę do obliczenia i zwróć do klienta potwierdzenia odbioru zlecenia do obliczenia
- co jakiś czas zwracanie statusu obliczenia
- gdy zadanie jest "skonczone" zwrócenie do klienta jakiegoś rezultatu?
- czy poszczególne "zlecenia" w jakiś sposób zależa od siebie? czy też są zupełnie niezależne?
czyli że głównym przewidywanym problemem do rozwiązania jest skalowalność?Ten post został edytowany przez Autora dnia 26.11.13 o godzinie 17:46 -
Piotr J.:
Moze Cie do czysto javowego zastosowania zainteresowac cos takiego jak Akka - maja ciekawy sposob dzielenia zasobow na innych maszynach tak, ze powstawie hierarchia wykonania i mamy w efekcie wirtualny klaster bez wiekszej spiny.
nie byłbym takim optymistą z akką ;):
- to nie tylko "framework" czy "biblioteka" tylko zupełnie inna architektura niż OOP lub proceduralne przetwarzanie, więc przestawienie się na dobre praktyki i myślenie aktorami jest nie mniej trudne niż nauczenie się drugiego języka programowania
- dokumentacja do akki jest jeszcze mocno uboga i nawet example dołaczone do Akki (szczególnie te w javie, bo w scali mam wrażenie lepiej się przyłożyli) mają błędy logiczne (np. moduł sieciowy I/O miał / ma błąd w examplach)
- z automatu jest znacznie łatwiej z nieblokującymi rzeczami w akkce w kwestii skalowania, ale już gdy dochodzi do blokujących wywołań (jdbc / większość io itp.) + konieczności trzymania "współdzielonego stanu między aktorami" łatwo jest się "poślizgnąć". W związku z tym nie każdy rodzaj biznesowych problemów dobrze się będzie skalował na akkce, czasami może być prościej tak jak mówisz napisać bezstanowe nody w klasycznych frameworkach + dodać load balancer / failover przy aplikacjach mocno opartych o blokujące wywołania zewnętrzne.
a tak poza tym to akka rulez ;) -
1. Czy dane są składowane w MS Access? jeżeli tak to spróbuj skompaktować plik mdb
2. Jeżeli to co powyższe czyli plik mdb udostępniany po otoczeniu sieciowym trzeba by zweryfikować czy po prostu nie jest to wina długiego ustanawiania połączenia udostępniania plików przez otoczenie sieciowe -> najprościej przenieść bazę na ten sam komputer i porównać czasy. Ewentalnie zmierzyć czas otwarcia tego właśnie udziału sieciowego na świeżo uruchomionym komputerze. -
Michał Z.:
Ja mówię o zestawie pytań, które sprawdzają podstawowe umiejętności. Kierowanie takich pytań do kogoś, kto pracuje w danej technologii 5+ lat to raczej nieporozumienie. Owszem nie jest to kompletnie bez sensu, bo jest szansa, że ktoś czegoś nie wie.
miałem niedawno okazję być na rekrutacji gdzie był człowiek z 10 letnim doświadczeniem który przeszedł przez chyba wszystkie firmy tworzące w Javie w moim regionie. Miał prawie cała stronę A4 wypełnioną frameworkami / narzędziami itp. jakimi "zna".
W praktyce:
- nie wiedział do czego służy hashcode w kontekście HashMapy
- nie wiedział co to jest propagacja i izolacja transakcji
- wiele innych elementarnych braków o których aż szkoda gadać
Gdyby czytać CV + historię zatrudnienia, człowiek powinien być co najmniej architektem a w praktyce miał wiedzę juniora po studiach który po prostu wypisał wszystkie frameworki i technologie które były podczepione w projektach.
Konkludując:
1. uważam że nie ma znaczenia ile się ma latek czy startuje się na juniora czy architekta. Pytania "z podstaw" potrafią ocenić czy ktoś nie blefuje. Myślę ze dobrze jest takiego kandydata o ile startuje na pozycję ciut wyższą po sprawdzeniu podstaw przedstawić przed jakimś problem rzeczywistym i zbadać co będzie kombinował i jak połączy dotychczasową wiedzę. Gdy przejdzie te dwa tryby wydaje mi się że ryzyko zatrudnienia "czarnej owcy" jest relatywnie małe.
2. Mamy rynek pracownika w IT, i dużo jest ludzi przeciętnych którzy widząc relację wysiłku do zdobywania wiedzy / płacy nie specjalnie garną się do rozwoju i po prostu nie wyskakują poza bardzo początkowy poziom wiedzy w związku z czym posługiwanie się samym kryterium doświadczenia jest w dużej części niemiarodajne przy ocenie wartości danego pracownika. -
To nawet nie chodzi o to żeby koniecznie się związać z jakąś firmą w sytuacji kiedy ta nie chce pracownika (sposób na niechcianego pracownika zawsze się znajdzie choćby nie przedłużając okresu próbnego) mimo że wcześniej twierdziła inaczej. Ale czasami uczestniczy się w kilku rekrutacjach i trzeba wybierać między dwoma równie atrakcyjnymi ofertami. Mając "glejt" można dochodzić odszkodowania wynikającego z odrzucenia oferty firmy X bo firma Y powiedziała ze nas zatrudnia, wrócić do firmy X często nie ma możliwości bo firma przestaje w krótkim okresie cenić "niechętnych". Osobiście nie słyszałem takich przypadków wśród znajomych ale scenariusz prawdopodobny. Masz rację sama nazwa "list intencyjny" nie ma specjalnej mocy prawnej ale wystarczy mieć list intencyjny z określeniem stanowiska, miejsca pracy, wysokości zarobków i zakresu obowiązków i w zasadzie ma to moc umowy przedwstępnej.
-
Piotr P.:
Z Waszych doświadczeń wynika, że trzeba przygotować jakąś umowę dla nowego pracownika.
List intencyjny a najlepiej umowę przedwstępną zależnie od oczekiwanej "siły" dokumentu. -
Konrad B.:
Wiecie może, jak wygląda sprawa jakości kodu w innych krajach? Tak źle jest wszędzie czy tylko w Polsce? Europie?
A czemu wiążesz pisanie testów lub nie z konkretnym krajem? I w USA / Polsce / inny kraj są firmy / ludzie którzy olewają dobre praktyki jak i takie które od nich zaczynają. -
Łukasz W.:
Wydaje mi się, że owy spring w obecnej wersji bardziej "skłania" się ku DDD. Takie projekty jak spring data, gdzie zmieniła się filozofia podejścia do utrwalania danych, zamiast dao -> repositories.
to że pojawiają się jakieś prezentacje na temat jak zrobić DDD z użyciem springa nie jest dowodem na to że autorzy springa "odwracają" się od koncepcji anemicznego modelu jako czegoś złego. Kilka przykładów:
(JDBC) http://spring.io/guides/gs/relational-data-access/
(JPA) http://spring.io/guides/gs/accessing-data-jpa/
(MONGO) http://spring.io/guides/gs/accessing-data-mongo/
(GEMFIRE) http://spring.io/guides/gs/accessing-data-gemfire/
nie jestem specem od DDD ale powyższe jak dla mnie to zwykłe encje anemiczne których stan zarządzany jest poza nimi samymi.
Nie mówiąc już o innych projektach springintegration, czy spring reactor które z pewnością pomagają zaprojektować aplikację w oparciu o DDD.
ja bym raczej użył sformułowania nie przeszkadzają w DDD dla tych którzy chcą użyć DDD. Znakomita większość literatury na temat spring, hibernate używała i używa encji anemicznych. -
Jarosław Ż.:
http://en.wikipedia.org/wiki/Anemic_domain_model
znam ten antywzorzec... dlatego go przywołałem
Ten "antywzorzec" jak go nazywasz często świetnie się sprawdza w praktyce w bardzo dużej części projektów, a dowodem jest sukces takich frameworków jak Spring, Hibernate itp. które promowały / promują model anemiczny i są kamieniami milowymi w developmencie IT. -
Jarosław Ż.:
gdzie ORM powstał (jak sama nazwa wskazuje) głównie do mapowania obiektowej logiki na relacyjne utrwalanie, jest to jeden z głównych zabójców wydajności i rozszerzalności (modyfikowalności) aplikacji
pozwolę się nie zgodzić, a przynajmniej nie na tak "radykalne" wnioski. Aplikację bazodanową w ORM zamiast w SQL tworzy się z reguły szybciej (w czystym JDBC trzeba i tak zrobić "swoje mapowanie" na obiekty DTO / encje i dorobić operacje zapisu / odczytu) i z mniejszą błedogennością niż w JDBC. Dodatkowo konserwacja jest znacznie prostsza przy dużej liczbie relacji mapowanej na JOINy itp. bo zmiana jest w jednym miejscu a nie w kilku/nastu/dziesięciu, automatycznie "propagowanie" zmian w mapowaniu są znacznie prostsze niż w JDBC. To są zalety. Co do wydajności to jest to też trochę kontrowersyjna teza. Jest narzut dodatkowy z ORM'a i czasami jest wymagane podpatrywanie ORM'a jak tłumaczy sobie zapytania, ale też są cache L1 i L2 które przy bogatym grafie encji mocno potrafią pomóc. Według mnie nie powinno się generalizować na temat JDBC vs ORM co do wydajności, bo jak to w wielu innych miejscach w technologii "to zależy". -
Jarosław Ż.:
Jarosław S.:
Dodając od siebie że DDD to kolejny promowany ustrój w praktyce może skłania się ku lepszej izolacji poszczególnych obiektów ale wiąże się że sporymi kompromisami (zeby nie powiedzieć wprost antypatternami) na warstwie technologicznej przynajmniej w typowej aplikacji JEE z JPA.
jakimi?
encje anemiczne wynikają z zalecanego przez JPA sposobu oddzielenia operacji zmiany stanu na encjach od operowaniu na EntityManagerze (który w modelu anemicznym występuje gdzieś w warstwie serwisowej). O ile dobrze pamiętam moje podejście do DDD jakiś czas temu to każda "gruba encja" z DDD może i ma obowiązek sama operować na zachowaniu stanu czyli bezpośrednio na EntityManagerze. A więc zaczyna być świadoma wszelkich technicznych rzeczy jak atrybuty transakcji, jej zasieg, strategią lockowania itp. Według specyfikacji JPA jest to antypattern.
Więc DDD wedlug mnie wcale nie jest kluczem do sukcesu, raczej w pewnych określonych (i moim zdaniem wcale nie czestych sytuacjach) lepszy od innych podejść w tym klasycznego operatego o przetwrzanie proceduralne na encjach anemicznych któe wedlug mnie świetnie sie sprawdza w developerce do określonego poziomu skomplikowania procesów biznesowych + rozmiaru zespołu developerskiego.
czym tu są owe anemiczne encje?
http://en.wikipedia.org/wiki/Anemic_domain_model
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
