пропозиції роботи
Wypowiedzi
-
Jarosław Ż.:
AMD do DDD ma się jak pieść do nosa, AMD to javascript czyli głownie (tylko) GUI a DDD to zestaw wzorców dla Modelu Dziedziny (w MVC) czyli na pewno nie GUI.
myślę że koledze chodziło o anemiczne encje + "proceduralne" przetwarzanie danych w "serwisach" a nie jak w skrajnie odmiennym DDD. 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. 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. -
Jarosław Ż.:
- kosztu każdej przyszłej kolejnej nowej funkcjonalności (z podzialem na CRUD, standard i złożone)
hmm, możesz wyjaśnić co przez to rozumiesz? bo mnie aż swędzi żeby się dowiedzieć w jaki sposób określasz "każdą przyszłą nową funkcjonalność"? i jak to można oszacować?
jak ktoś nie potrafi to mu dziękuję, to prosty miernik jakości projektowania.
-
jeżeli chodzi o nazwa.pl to mocno zalecam sprawdzenie czy już zrezygnowali ze skandalicznej polityki naliczania liczby zapytań sql na godzinę i odrzucania nowych zapytań / połączeń jeżeli w ciągu godziny przekroczy się X zapytań.
-
Łukasz W.:
Bazy NoSql czy Obiektowe nadają się zdecydowanie bardziej dla Javy. Problem polega na tym, że wiele firm się ich "boi" jeśli chodzi o transakcje i ACID. Zwłaszcza jeśli mają być zastosowane do finansowych zagadnień.
no i nic dziwnego, nosql nie powstał żeby zastąpić RDBMS ale żeby zapełnić lukę między pełnym tranzakcyjnym RDBMS a bazą typu plik CSV. Moim zdaniem nosql świetnie się nadają do przechowywania dokumentów i wyników obliczeń do raportów do późniejszej prezentacji itp. Za to dane źródłowe do obliczeń raportów pozostawiłbym trzymane w chronionej RDBMS. -
Łukasz W.:
Swoją drogą myślę, że w dużej mierze za taki stan rzeczy ponosi Relacyjna Baza Danych. Co z tego, że piszemy w obiektowym języku (JAVA), jak tak naprawdę w fundamencie (warstwie integracji) mamy relacyjną bazę. Sama relacyjna baza ma się nijak do programowania obiektowego. To jak ogień i woda, stąd ORM - hibernate, jpa itd.
trochę nie na temat ale jako ciekawostka spójrz na ORM bez RBDMS, nie używałem ale koncepcyjnie bardzo ciekawe:
http://www.objectdb.com/ -
Czemu pomijasz technologie grubego klienta web w JS / Dart / TypeScript komunikujące się z backendem po REST / JSON?
-
Andrzej B.:
Z tego co czytałem, ma większe możliwości niż SWT, choć wymagana jest duża biblioteka. Moim zdaniem może sprawdzić się w dużych projektach.
dopóki nie wykorzystasz w dużym projekcie tego się nie dowiesz ;)
PS. a czemu usilnie szukasz wrapperów do bibliotek w C++. Ja bym się mocno zastanowił czy nie wykorzystać Swinga / javafx który bezpośrednio ma dostęp do akceleracji 2D i nawet za 10 lat nie bedzie zależny od określonej wersji dll w systemie + znacznie mniejsze problemy po tym jak ktoś zacznie zechcieć używać apki pod innymi OSami. Błędy w twojej aplikacji = błędy Win32 (przestarzałe!), + błędy SWT(lub innej blbioteki wrapującej) + błędy Twojej apki + uzysk perfomance przez mniej odwołań do OS. Może łatwiej w Swingu jest początkującemu sknocić (głównie przez błędne używanie wątków) niż w innych bibliotekach ale osobiście wybrałbym Swinga, a w określonych przypadkach Netbeans platform. -
Miałem styczność z projektem który był konwertowany do osgi (web application). Używany był Apache Felix. Moim zdaniem więcej jest minusów niż plusów użycia OSGI. Z plusów: teoretyczna możliwość mega łatwego deployu / undeployu. W praktyce jednak są dwa poważne minusy stosowania OSGI:
- osgi jednemu osgiowi nie równy, jesteś bardzo zalezny od konkretnej platformy osgi w kwestii obchodzenia róznych "haków" np. obsługi jsp.
- niestety moim zdaniem osgi daje bardzo duży narzut na dodatkowy kod który trzeba napisać, spędzić czas na debugowaniu, znajdywaniu rozwiązania, osgi powinien być transparenty dla aplikacji a prawda okrutna jest że jest wręcz przeciwnie.
Podsumowując moim zdaniem narzut jaki jest związany z OSGI wyrażony w dodatkowych godzinach pracy na obejście problemów z nietrywialnymi aplikacjami OSGI zwrócić się może tylko jeżeli jest uzasadnione użycie jego (limity pamięci, prawidziwa i uzasadniona potrzeba hot-deploy). POczytaj troche artykułów na sieci, ale nie tych od autorów którzy blogują o nowinkach ale o ludziach którzy próbowali użyć OSGI w dużej "realnej" aplikacji, np:
http://blogs.mulesoft.org/osgi-no-thanks/
jeżeli chodzi o spring dm, to gdzieś w sieci kiedyś był post że spring de fakto jako firma także zrezygnowała z wdrażania we springu OSGI na większą skalę właśnie przez skomplikowanie i narzuty OSGI. -
Piotr J.:
Gradle tez niektorzy uzywaja.
Moim subiektywnym zdaniem, Gradle powinien być używany przez doświadczonych użytkowników mavena którzy zderzyli się z jego limitami. W przeciwnym razie można dzięki elastyczności Gradle'a sobie poodbnie namieszać w projekcie jak w ant'ie. Z drugiej strony nieważne jaki system buildów, nawet ant będzie lepszy niż tworzenie projektu który można zbudować tylko w Eclipsie (z określonymi wtyczkami w określonych wersjach). -
One tool to rule them all: Maven.
PS: decyzję oczywiście kazdy podejmować sam co do UI ale jesteś na pewno pewien że chcesz zaczynać nową aplikację w SWT? -
Michał Z.:
Co chciałem uzyskać? A no dowiedzieć się jak inni łapią równowagę między wieloma obszarami, na które można wydać kasę w projekcie. Nie chodzi o to, czy testować a jak to robić, żeby było efektywnie.
nie można było tak od razu precyzyjnie się wysławiać tylko się zaraz obrażać ;), moja subiektywna hierarchia "efektywności" poświęconego czasu / budżetu na testy (zakładając typową aplikację server side) od najbardziej efektywnych (w rozumieniu więcej czasu na testy => mniejsza ilość bugów = wieksza satysfakcja klienta) do mniej:
testy integracyjne / akceptacyjne wysokiego poziomu (Selenium? BDD?)
dopiero gdy budżet pozwoli oprócz testów akceptacyjnych / integracyjnych na coś więcej to warto zaplanować w większym stopniu w testy jednostkowe (idealistyczne TDD), tak wiem że to kontrowersyjna teza ale jak jest nóż na gardle to wolę mieć większe pokrycie testami akceptacyjnymi niż jednostkowymi
testy jednostkowe -> przydają się głownie gdy inwestycja będzie długoutrzymywana (lata) i będzie często refaktorowana, najbardziej przydatne dla własnych produktów lub przy długofalowej współpracy z klientem
Stawianie sprawy, że testy mają byćtraktowane jak kod produkcyjny - nie jest efektywne. No, przynajmniej ja to tak widzę. Sporo zależy od projektu, klienta... Co najwyżej - może się okazać, że przy sprzyjających okolicznościach będzie efektywne.
na krótką metę zgadzam się, wydłużają czas dostarczenia funkcjonalności. Na dłuższą metę jednak umożliwiają pracowanie w warunkach jako takiej przewidywalności i kontrolowanego poziomu jakości przynajmniej w większości typowych aplikacji biznesowych. Nie wspominając o samopoczuciu członków zespołu. -
Michał Z.:
Nie mam ochoty na udowadnianie komukolwiek czegokolwiek. Podyskutować, czegoś się dowiedzieć - bardzo chętnie.
...
Były czasy, że pisanie testów jednostkowych nie było jakoś specjalnie na porządku dziennym. Systemy powstawały, działały. Ba działają do dziś. Czy to ma sens? Ciężko powiedzieć. Obaj patrzycie na świat z perspektywy posiadania testów. Ich brak to ZŁO :)
Chyba jednak niczego się nie dowiem, będzie udowadnianie. A tego właśnie chciałem uniknąć...
hmm, no ale co w mojej (bo rozumiem ze jestem w tej grupie) odpowiedzi było nie na miejscu. Każdy myśli przez pryzmat własnych doświadczeń, moje są takie: nikt nie chce pracować w projektach bez testów automatycznych, brak testów nie jest ZŁEM. Ale niemożność weryfikacji swojej pracy, spędzanie 95 procent czasu na analizie i zgadywaniu jak działa kod (z 80 procentowym prawdopodobieństwem złego zinterpretowania czyjegoś algorytmu a w rezultacie kolejnych zwrotów systemu z produkcji, naciągania budżetu kosztowego / czasowego / frustracji klienta) bo nie ma testów, jest ZŁEM. Poddałeś tezę że po co pisać testy skoro klient i tak wywróci funkcjonalność. Jakiej odpowiedzi / wiedzy spodziewałeś się od innych po takim stwierdzeniu? Ze ktoś przyklaśnie i powie masz rację, wystarczy silna motywacja zespołu do nie robienia błędów itp. Nie staram się Ciebie atakować po prostu ustosunkowałem się do Twojej tezy przez podanie skrajnego przykładu (wcale nie nierealnego). Jeżeli dyskusja nie idzie w kierunku oczekiwanym przez Ciebie to doprecyzuj o czym chciałeś podyskutować? -
Michał Z.:
Najpierw trzebadokładnie dowiedzieć się co jest do zrobienia, potem to zrobić, przygotować testy, na bieżąco utrzymywać metryki - długość metod, wielkość klas itp. Jak już użytkownik dostanie i tak wywali do góry nogami całą koncepcję. I tak z 10 razy...
Tak się tylko zastanawiam. Proszę nie krzyczeć, nie denerwować się. Tym razem nie mam ochoty na długi wątek, w którym na wzajem sobie będziemy udowadniać :D
zapytam odwrotnie: pracowałeś nad odziedziczonym kodem legacy który był bardzo skomplikowany od strony dziedziny biznesowej (bez dostępu analityka nie rozumiesz celu metody), brak javadoców, bez dobrych praktyk (DI, design patterns) z stopniem pokrycia testami jednostkowymi rzędu 1-2 procent. Bez możliwości odpalania testów integracyjnych (o ile takie istnieją w danym projekcie) w środowisku dev? Pilnowanie długości metod / klas, dodawanie unit testó itp. to pikuś, Pan Mały Pikuś przy konieczności pracy z legacy codem. A stał się legacy codem bo pierwsi developerzy olali dobre praktyki / wiedzieli lepiej że pilnowanie długości metod, klas, pisanie testów jednostkowych jest nie geek. Następni przyszli, popatrzyli i dodali to samo, bo jak pierwsi się nie musieli starać to przecież oni też nie będą... Motywacja typu "użytkownik i tak wywali do góry nogami całą koncepcję" dlatego nie ma sensu TDD / korzystanie ze statycznych analyzerów, jest hmm wymówką? ;). KAŻDY soft będzie zmieniany na skutek zmian potrzeb użytkowników, lepiej pisać soft zmieniany bo taki oznacza że produkt odniósł sukces (a więc programista się do tego sukcesu w jakimś stopniu przyłożył), niż napisać raz zakomitować i zapomnieć bo taki oznacza że produkt nie odniósł sukcesu. Jak nie dostrzegasz zalet takiego myślenia to docenisz przy legacy codzie każdą linijkę javadoca, odpowiednią wielkość kodu, każdy test jednostkowy. -
Z darmowych polecam jeszcze sprawdzenie IntelliJ Idea community edition, tak dla posiadania materiału porównawczego.
-
Różnica między AS2 a AS3 jest jak między JavaScript i Java / C#. Jeżeli będziesz pisał nowsze rzeczy a nie konserwował stare w AS2 (nawet wrogom nie życzę) to absolutnie nie ma sensu uczenia się as2.
-
1. Co to za aplikacja? servlet, jsp, jsf...?
2. Co wyświetlasz: zasób statyczny czy rezultat servletu?
3. Co mówią logi access?
4. Jaki jest kod odpowiedzi http (tej odmownej)
5. Czy wykluczyłeś ze zwyczajnie nie chodzi tylko o czas inicjalizacji aplikacji?
6. Co to znaczy że "może ją pingować"? Czy jesteś pewien że rozumiesz różnicę między protokołami ICMP a HTTP?
7. Używasz jakiegoś proxy / cache LAN?
8. Masz na pewno wyłączone proxy systemowe w Windowsie? -
Piotr L.:
Większość (jeśli nie wszystkie) z systemów szablonów które poznałem używa jakichś dziwnych znaczków do zawarcia dynamicznej części strony. Smarty wybrało akurat jeden znak zamiast 3 - co jest bardziej czytelne.
są systemy templatów zgodne z xml / xhtml np. Thymeleaf. Oczywiście nie mają możliwości przeplotki kodu dynamicznego a raczej są do typowego MVC. Co akurat według mnie wychodzi tylko na dobre projektom,
@Michał: AFAIK JSP to najprostsze rozwiązanie do webdev w Javie.
Jednocześnie bardzo "nieświeże", jasne że można od tego zacząć ale jeżeli nie będzie się konserwować systemów legacy to raczej nie jest już zalecana technologia do nowych projektów -
Michał P.:
Przeczytałem ten wątek jeszcze raz i nie znalazłem odpowiedzi na takie bardzo noobistyczne pytanie... Jaki framework (albo i technologię...) należy zastosować, żeby stworzyć minimalistyczną, najprostszą stronę w Java? Tomcat + JSP? Wszyscy piszą o JSP, JSF natomiast nie da się po prostu zmusić Tomcata żeby "rozumiał" Javę tak jak sam Apache dogaduje się z PHP?
Daj spokój JSP niech spoczywa w pokoju. Weź sobie springa + jakąś warstwę wyświetlania (z ostatnio ciekawych np. thymeleaf) i jedziesz. A jak chcesz robić "stronki" to zrób to w php, może być szybciej i mniej frustracji posuwania się po początkowej skali krzywej nauczania. -
podpięcie się pod zdarzenie załadowania body / embedowania flasha + overlay (javascriptowy) nad flashem (oczywiście flash musi mieć wmmode pozwalający na operację przykrycia obiektem html ale skoro masz flasha pełnoekranowego to nie masz dużych ograniczeń związanych z wmmode.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
