пропозиції роботи
Wypowiedzi
-
-
Java nigdy nie była "sprzedawana" przez możliwości GUI i nie traktowanie na równym poziomie co w .NET w kwestii innowacji GUI. Po pierwsze nie nazwałbym Swinga porzuconym, po prostu przestano w niego specjalnie mocno inwestować, co nie znaczy że nie można w nim fajnych rzeczy robić. Najbardziej rozbudowanym, dojrzałym i kompleksowym "podejściem" do budowania aplikacji opartych na Swingu jest netbeans platform:
https://netbeans.org/features/platform/Ten post został edytowany przez Autora dnia 08.06.13 o godzinie 19:24 -
Sebastian M.:
A mimo to przy nawet dużych projektach nadal nie poświęcają na to czasu. Czasami naprawdę nie jestem w stanie zrozumieć zachowań ludzkich. Takich tym bardziej, bo przecież powinny opierać się na kalkulacjach, statystykach i cyfrach, więc tym rozsądniejsze powinny być.
Jak widać, zazwyczaj jest jednak inaczej.
hmm, nie chce tutaj zgadywać ale wydaje mi się że chyba nie uczestniczyłeś w większym zakresie w procesach sprzedaży typowego software house. Gdybyś uczestniczył lub porozmawiał z działem sprzedaży nie miałbyś takiego czarno-białego obrazu rzeczywistości. Tak jak wcześniej powiedziałem duża część przyczyn niekompletności dokumentacji wynika z przyczyn leżących poza firmą (klient i słaba dostępność do wiedzy po jego stronie (wiedzy może dostarczyć kluczowy pracownik klienta, który jest zaangażowany w mega kluczowy proces biznesowy u klienta i można wyżebrać tylko pół godziny dziennie jego czasu - wcale nie rzadki przypadek gdy wchodzimy w rzadką wiedzę domenową), konkurencja drepcząca po piętach, działanie w warunkach przetargu?) a nie z problemów wewnątrz niej (niekompetencja kierownictwa, "burdel" jak to określiłeś). I to jak sobie dana firma w tej sytuacji "niepewności" radzi niejednokrotnie decyduje o jej sukcesie rynkowym. To jest ryzyko prowadzenia działalności gospodarczej.
Można stworzyć prototyp. Jedyne o czym nie można jednak zapomnieć, to żeby taki prototyp nie trafił do finalnego produktu.
no chyba że zbliża się deadline a Twój team nie ma innego wyjścia niż włączyć jakiś słabo napisany kod dla celów prototypowych do kodu produkcyjnego bo jak nie to lecą kary umowne które zmieniają rentowny projekt w projekt do którego dokłada firma. Tylko proszę nie mów mi że to wynika ze słabego kierownictwa / braku właściwego agile itp. Takie rzeczy zdarzają się najlepszym i bardzo doświadczonym ludziom i wynika min. ze złożoności procesu wytwórczego oprogramowania,
I to jest przyczyna zderzania się przy projektach z przypadkami gdzie trzeba ogarniać luki w rozumowaniu / analizie a nie dlatego że ktoś stwierdził że taniej jest rzucić X programistów niż poświęcić czas product ownera. W dużej części przypadków nie ma możliwości przeprowadzenia analizy lepszej po prostu i to się toczy siłą rozpędu.
W to nigdy nie będę w stanie uwierzyć. Firma nie ma możliwości poświęcić czas, ale jest skłonna wyrzucać duże pieniądze w błoto? Bo niestety tym są niektóre wydatki dotyczące tworzonego oprogramowania, jeżeli wcześniej nie poświęci się czasu.
problem opisałem wcześniej -> przyczyny w dużej mierze poza kontrolą firmy, sprzedawca może nie wchodzić w dany deal i zostać z niewykorzystanymi etatami w firmie które kosztują nie mało i dopłacać do stanowisk lub wejść w proces w którym oszacować można z jakimś przybliżeniem kosztochłonność. Niestety polska rzeczywistość jest taka:
- zdecydowana większość kontraktów to fixed price a firma konkuruje z innymi głównie przez pryzmat oszacowanej ceny za wykonanie, tylko niewielka część kontraktów to kontrakty z płaceniem za "konsulting IT" gdzie w pełni świadomy klient płaci za godzinę pracy pracowników software house
- klienci w zdecydowanej większości przypadków nie chcą płacić za analizę biznesową która by drastycznie zmniejszyła ryzyko szacowania kosztów implementacji tego co początkowo chciał klient
Można z tym się nie zgadzać i odrzucać kontrakty (i dopłacać z kieszenie właścicieli do firmy) lub pogodzić się z rzeczywistością. Gdy się połączy powyższe to wcale nie dziwi człowieka dlaczego to tak działa w większości przypadków. -
Maciej N.:
Oczekujesz odpowiedzi szczerej, czy politycznie poprawnej? Bo obawiam się że często-gęsto tak to właśnie wygląda. Wiecie, taka wariacja na temat agile ;)
ja tylko polemizuje z generalizującymi tezami wyciągniętymi na podstawie uogólnienia. Nie można napisać prototypu jak nie wiadomo z jakiej dziedziny jest. Można w ten sposób pracować gdy łupie się standardowe i powtarzalne projekty i na podstawie hasłowego przedstawienia informacji można np. skonfigurować jakieś oprogramowanie (typu wdróż mi naszego CRM'a ze standardowym zestawem ról i aktywnymi modułami) ale to chyba nie ma za dużo wspólnego z dostarczaniem spersonalizowanego kodu. Natomiast rzucanie tezy że można napisać działający kod bez jakiejkolwiek specyfikacji bo mamy super fajne języki programowania jest co najmniej kontrowersyjne chyba że autor postu ma zdolności czytania w podświadomości innych osób i ma do nich dostęp. To wcale nie znaczy że w praktyce biznesowej kompletność specyfikacji (cokolwiek formalnego / nieformalnego mamy tutaj na myśli) nie mieści się w przedziale od kilku do 99 %. A już bym mocno polemizował przy stwierdzeniu że taniej jest kodować niż pisać specyfikację. Koszt kodowania liczony w roboczogodzinach * koszt godziny pracy (w rozumieniu analizy technicznej + architektury + implementacji + TDD w jakimś stopniu) jest w większości znacznie większy niż koszt przygotowania specyfikacji. Problem w tym że w praktyce specyfikację powinni pisać ludzie (odpowiednik product ownera) którzy mają najmniej czasu na to, nie są dostępni w danym momencie, lub nie ma świadomości odpowiedniego poziomu szczegółowości wymagań u sponsorów projektu lub trzeba pokazać pierwszy milestone sponsorowoi projektu jak najszybciej żeby przekonać że ma się zdolność do wytworzenia projektu (co częstwo wprowadzana dodatkowe koszty niepotrzebne ale zmniejsza to poczucie ryzyka u sponsora wiec jest uzasadnione z jego punktu widzenia). I to jest przyczyna zderzania się przy projektach z przypadkami gdzie trzeba ogarniać luki w rozumowaniu / analizie a nie dlatego że ktoś stwierdził że taniej jest rzucić X programistów niż poświęcić czas product ownera. W dużej części przypadków nie ma możliwości przeprowadzenia analizy lepszej po prostu i to się toczy siłą rozpędu. Można sobie tylko życzyć mieć super dostępność product ownera, dowolnie długi czas na analizę. -
Sylwester R.:
Obecne językiprogramowania są tak ekspresyjne, że napisanie (sensownej) specyfikacji kosztuje więcej czasu i energii niż napisanie działającego kodu.
rzekłbym że mocno kontrowersyjna teza. Czyli według Ciebie obecnie pisze się prototypy (skąd wiadomo co ma robić taki prototyp i czy ma reprezentować zarządzaniem chłodzeniem elektrowni atomowej czy też zarządzaniem pocztą www?) a dopiero później się je przerabia na X sposobów dochodząc do tego co Klient oczekuje? -
Według mnie kwestia nie jest jednoznaczna. Z jednej strony jezyki skryptowe dają bardzo szybkie rezultaty w pokazaniu pierwszej działającej wersji, szczególnie widoczne przy tworzeniu kodu dla frontendu (gdzies na warstwie kontrolerów / modelu gdy używany jest MVC) + szybkie obserwowanie zmian i szybka możliwość dojścia do "pierwszej działającej wersji". Z drugiej strony takie szybkie działanie prowadzi do pewnego niechlujstwa, skoro szybko można coś napisać to na drugi plan idzie zastanawianie się jak to będzie w przyszłości rozwijane, gdzie jest ryzyko błędów wynikłych z "mutability" itp. Podobnie kwestia testowalności, skoro mogę szybko zobaczyć efekt i teoretycznie sprawdzić czy działa to nie skupiam się na pisaniu testowalnego kodu. Jezeli musiałbym czekać na wynik dłużej poświęciłbym więcej czasu na analizę kodu przed odpaleniem czasochłonnego testu integracyjnego itp. Z praktycznych kwestii z którymi ja osobiście miałem problem używając integracji z jednym z jezyków na JVM to kwestia profilowania i debugowania stanu. To był akurat python. Można zapomnieć o ładnych i czytelnych stacktraceach, Wydajne jezyki na JVM czesto korzystają z dodatkowej warstwy abstrakcji (np. antlr), profilowanie takiej aplikacji staje się praktycznie niemożliwe z użyciem tradycyjnego podejścia po prostu czytelność proceduralnego przejścia zupełnie się rozmywa gdy zamiast jasnych i czytelnych nazw metod mamy przed sobą niskopoziomowe wywołania danej warstwy tłumaczącej, która jest między JVM a językiem wysokiego poziomu.
Podsumowując osobiście uważam że sprawa czasu redeploya jest drugorzędna w sytuacji kiedy projekt rozwijany jest w oparciu o TDD i tworzy się testy jednostkowe i integracyjne z dużym poziomie pokrycia. Jeżeli nie ma TDD to zalety skryptowości oczywiście są bardziej widoczne ale też koszty maintenance / obsługi długu technicznego moim zdaniem są wyższe w dłuższej perspektywie niż przy TDD (manualne testy zawsze będą droższe niż nawet rozbudowane ale automatyczne). Oczywiście nie należy lekceważyć rozwoju języków alternatywnych opartych na JVM ale nie oczekiwałbym rewolucji, raczej ewolucji. -
Andrzej C.:
Zainteresowany tą wypowiedzą wziąłem się za stworzenie aplikacji JPA (Toplink)+EJB3+JSF. Dotychczasowe bóle i męki dla osób korzystającej z Hibernate i Spring:
-brak Criteria API, a co za tym idzie ciężko o dynamiczne generowanie odpytań do bazy (potrzebne chociażby na komponencie DataTable)
jak koledzy wcześniej wspomnieli jest Criteria API w JPA z 3 poziomami "type-safe"w tym compilation time validation jeżeli użyje się generacji metamodelu:
http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html...
podobny do querydsl -
Grzegorz G.:
Od siebie mogę dorzucić jeszcze jooq, czyli SQL sprawdzany przez kompilator Javy. Trochę nieładnie ze Springiem się integruje, ale używam i mocno chwalę. Szczególnie do odziedziczonych baz danych.
to z takich wynalazków warto spojrzeć na:
http://www.querydsl.com/
lepsza wersja Static JPA Metamodel -
Marek K.:
Michał P.:
Hmm, a czy spring nie jest częścią EE? Tzn. w projektach open-source nie można tego używać... Muszę doczytać o tym...
spring jest alternatywa dla EE - w zalozeniu lzejsza (chociaz staje sie coraz ciezszy), niepotrzebujaca
"ciezkiego" serwera. Wystarczy tomcat, czy jetty i hula.
Ja preferuje rozwiazania lekkie, wiec spring to postawa
lekki offtop ale najwyższy czas przestać traktować standardową J6EE jako "ciężką" (EJB / JPA / CDI itp.). Aktualnie jej jedyna "ciężkość" wyraża się tylko tym że kontener w którym aplikacja działa dłużej wstaje (choć z tym jest coraz lepiej np. mikroarchitektura Glassfisha, lub Apache Tomee, choć ten ostatni nie osiągnał moim zdaniem jeszcze gotowości produkcyjnej na poziomie innych kontenerów). Liczba deskryptorów i konfiguracji niezbędnej do działania aplikacji w kontenerze aplikacji EJB3 / JPA2 / REST jest niejednokrotnie znacznie mniejsza niż w Springu.
Z całym szacunkiem do autorów springa ale pod FUD podpada wykazywanie głównej wartości springa jako lekkości we wprowadzeniu do książki Spring in Action (ostatnie wydanie z 2011) używając porównania do EJB 2 i wcześniejszych, kiedy od 2007 a wiec od 4 lat przed napisaniem Spring in Action jest dostępna EJB3 która jest oparta na zwykłym POJO. Moim zdaniem główna zaleta Springa to wielorakość wyboru sposobu osiągnięcia danego rozwiązania + pewne "gemy" w określonych dziedzinach (np. aspekty). Daną aplikację można zrobić na mnóstwo sposobów korzystając z tego co Spring daje.
Dla zainteresowanych "ciężkością" standardowej J6EE polecam:
http://download.java.net/general/podcasts/real_world_j... -
Na tak ogólnikowe pytanie może być tylko ogólnikowa odpowiedz:
1. desktop - tutaj raczej nic sie nie dzieje, java raczej tu nieczesto spotykana, eksperymenty typu JavaFX wnoszą nowe koncepcje ale raczej nie zwiększają one swojej popularności, java na desktopie ma pod górkę i nie zanosi się na zmianę tego trendu, jak coś na desktop i nie musi być crossplatformowe to chyba lepiej w C# / WPF
2. web - tutaj jak zwykle bardzo dużo się dzieje. Z jednej strony w mainstreamie kanon się nie zmienia Spring / Hibernate (JPA), najwięcej dzieje się w warstwie prezentacji. Ostatnio coraz modniejsze / trendy jest budowanie apek REST komunikujących się z grubym klientem w JS (backbone, angular.js itp.). Aplety umarły śmiercią naturalną podobnie Java Web Start mają bardzo niszowe zastosowania (mają sens praktycznie tylko gdy coś z weba ma mieć dostęp do dysku lokalnego). Oprócz tego relatywnie się dużo dzieje w innych niż java językach uruchamianych na JVM (Scala itp.) -
Moim osobistym zdaniem wynagrodzenie flexowców bedzie paradoksalnie w krótkim okresie rosło z uwagi na coraz mniejsza grupę aktywnych developerów flexa, a koszt maintenance systemów już napisanych we flexie będzie rósł (coraz mniej ludzi coraz gorszy ratio umiejętności / koszt programisty) aż dojdzie do momentu gdy bardziej się będzie opłacało przepisać frontend w JS lub zrezygnować z grubego klienta ale wydaje mi się że to kwestia 3-4 lat, w krótszym czasie jeszcze nie ma tego ryzyka i flexowcy mogą wykorzystać trend małej liczby doświadczonych flexowców na rynku. W dłuższej perspektywie może to niekorzystnie wpływać na decydentów którzy dotychczas inwestowali we flexa (banki, firmy finansowe itp.), już teraz jest to w tej grupie traktowane jako technologia legacy raczej. Ryzyko inwestowania w tą technologie ze strony programistów (szkolenia, samodzielnie przeznaczanie swojego czasu na rozwój w tej technologii) przynajmniej wyłącznie w nią jest coraz wyższe i niestety jest to trochę samonakręcająca się spirala.
-
Darek Z.:
Apache-Commons to nie tylko porównywanie Stringów, zawiera więcej ciekawych klas. A dlaczego akurat użyć StringUtils? Bo to zawsze łatwiej, choćby nie trzeba myśleć o NPE (np. optionSelected.equals(SAVE_OPTION) , gdzie optionSelected będzie null), używając StringUtils dostaniesz false. używając zwykłego porównania NPE.
dlatego zalecaną metodą porównywania zmiennej do stałej jest
STAŁA.equals(referencjaKtóraMozeByCNullem)
tak jak wczesniej koledzy polecam wpierw refleksję przed ściąganiem i używaniem bibliotek do prostych rzeczy dostępnych w samym języku. -
Patryk Zientek:
Działać działa, a tak w teorii to jeszcze ciekawiła by mnie taka opcja, mamy zdefiniowanych 10 slavów, 2 mastery.
Założmy że jeden slave nam padł to nasze zapytanie by poszły do drugiego a nie ze aplikacja się wysypie.
Jeśli wszystkie slavy by padły to by się połaczył z masterem.
hmm, może AOP wychwytujący wyjątki na warstwie odpowiedzialnej za commitowanie tranzakcji? -
W teorii (nie sprawdzałem w praktyce) są następujące możliwości:
http://blog.springsource.com/2007/01/23/dynamic-dataso...
pytanie w jaki sposób można decydować o tym który datasource użyć, jedno z możliwych rozwiązań to użycie:
IsolationLevelDataSourceRouter + na podstawie deklaracji poziomu izolacji sterować z którego datasource poleci SQL
trzeba mieć też świadomość że:
- mysql ma domyślnie autocommit ale to na pewno wiesz
- chyba nie da się użyć transakcji lokalnych albo może być mocno niewskazane ich użycie i trzeba skorzystać z JTA (żeby transakcja objeła operacje w ramach dwóch źródeł danych), z drugiej strony nie wiem czy można mieszać JTA w springu z użyciem sterowania pozioami izolacji transakcji, ale to temat drugorzędny.
daj znać czy się udało, temat dosyć ciekawy -
Nie do końca fajne ale jednak się powoli dzieje. Top inżynier od AVM zmienia się w człowieka od JS (szczegóły w komentarzach do postu):
http://www.bytearray.org/?p=5197 -
z innej beczki zdaje się że powstaje jakiś thiller o javie :)
http://www.filmweb.pl/film/Java+Heat-2013-637218 -
Krzysztof K.:
Grzebanie w konfiguracji serwera dalej nie uważam za dobre rozwiązanie, bo - poprawcie mnie jeśli się mylę - jak będę miał gotową aplikację i znajdę odpowiedni hosting, to chyba nie będę miał możliwości indywidualnych ustawień serwera, tylko konfiguracja będzie jednakowa dla wszystkich?
Nie do końca prawda. W tomcacie masz możliwość osadzania w ramach war'a plików Context.xml a w nich precyzowania paru rzeczy:
http://tomcat.apache.org/tomcat-7.0-doc/config/context...
uriEncoding jest jednak ustawiany na poziomie konfiguracji connectora więc wydaje mi sie że z contextu nie można zmienić ustawien connectora a w konsekwencji uriEncoding globalnego dla serwera. -
chyba nie unikniesz ustawienia URIEncoding, prawdopodobnie utrzymują ze względu na wsteczną kompatybilność takie zachowanie (bodajże ISO-8851-1 jako domyślne). Dodatkowo wydaje mi się że w Tomcacie bedziesz czasami musial i tak dodać filtr na requestach wszystkich ustawiający:
response.setCharacterEncoding("UTF-8");
request.setCharacterEncoding("UTF-8");
żeby działały Ci servlety które jawnie nie ustawiają kodowania resp/req a polegają na tym że "za nich" serwer ustawi kodowanie. -
Trochę mi to przypomina teorie z dziedziny zarządzania, ciekawostki prawdziwych sklasyfikowanych jako metodyki praktyk zarządzania:
- zarządzanie przez zastraszanie
- zarządzanie przez chaos
nikomu chyba nie życzę zderzenia się z tymi metodykami :) -
dzięki za odpowiedz, ja z primefaces (używałem już wersji 2.3 / 2.4) też spotkalem kilka bugów ale dało się je obejść. Natomiast używałem primefaces na Apache Tomee i raczej odradzam używanie tego serwera do JSF'a 2. Możliwe że nie jest to wina primefaces tylko dostawcy faces (w tym wypadku apache myfaces) z tego co kiedyś sprawdzałem to Apache Tomee wydania są testowanie tylko pod kątem JSF 1 a to wiadomo jest inna para kaloszy niż JSF 2.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
