пропозиції роботи
Wypowiedzi
-
Jakub Grabowski:
Ogólnie takie duże uproszczenie funkcjonuje (Tomcat = servlet container) na wikipedii, na stronie Glassfish'a (informacja o forku tyczy sie Tomcata), ale zgadzam się, modułem odpowiadającym za servlety/JSP jest Catalina.
Robert K.:
No nie do końca ;-) W Glassfishu jest fork enginu Catalina, używanego w Tomcat, ale jest on już mocno zmodyfikowany. Trochę jest w tym stwierdzeniu prawdy, ale stwierdzenie że Tomcat, jest servlet containerem Glassfisha jest dużym uproszczeniem.
Tak dla porządku: web serwer: Tomcat, serwer aplikacji: JBoss lub Glassfish (w obu jako servlet container jest Tomcat). Jeśli decydujesz się na JBoss'a to tutaj są pluginy (JBoss Tools): https://www.jboss.org/tools.
Poza tym jeśli już mamy być tacy dokładni to nie powinno być JBoss, ale JBoss AS, etc. ;-).Robert K. edytował(a) ten post dnia 23.02.13 o godzinie 12:24 -
Tak dla porządku: web serwer: Tomcat, serwer aplikacji: JBoss lub Glassfish (w obu jako servlet container jest Tomcat). Jeśli decydujesz się na JBoss'a to tutaj są pluginy (JBoss Tools): https://www.jboss.org/tools.
-
Dominik Sienkiewicz:
Jeśli miałby być to portal dla umiarkowanej liczby użytkowników trzymałbym się Twoich założeń - łatwy rozwój, zarządzanie, etc.
"Chyba że pisząc Managed Beans miałeś na myśli komponenty CDI ;-)." - głównie tak. W bebechach pewnie oparł bym się na springu a skoro nie ma jeszcze flow faces to użył bym web plow springa. Boli mnie tylko w JSF (aktualnej wersji) brak możliwości użycia HTML5 (albo czegoś nie wiem).
A ty jaki framework byś wybrał ?
Robienie konkurencji dla FB/G+ nie byłoby takie łatwe i chyba oparłbym wszystko na jakimś autorskim, dedykowanym rozwiązaniu. Tutaj jest link do technologii użytych przy tworzeniu G+. -
I jeszcze jedna uwaga: jeśli już popuszczamy wodze fantazji i mielibyśmy robić coś a'la FB/G+ w Javie to trzeba wziąć pod uwagę docelową liczbę użytkowników. Poczyniłbym ogólne założenie, że im więcej użytkowników tym prostsze technologie powinny być użyte tzn. czysty ajax (via jquery)/web sockety a nie mechanizmy JSF (z całym bagażem walidacji etc.). Oczywiście nie można popadać w paranoję i zacząć pisać w asemblerze, ale nie można też bagatelizować tego czynnika. Istotna jest również optymalizacja ruchu przeglądarka - serwer, jak również optymalizacja obliczeń po stronie serwera. W przypadku dużej liczby użytkowników każda niepotrzebnie wykonana operacja może iść w miliony.
Reasumując więc oprócz wybranych technologi ważniejsza może okazać się wybrana architektura. -
Jako że zaproponowałeś użycie CDI to usunąłbym Managed Beans (JSF) - oba rozwiązania mocno się duplikują (abstrahując od tego, że CDI jest dużo bardziej zaawansowane) i wprowadzają lekką schizofrenię. Chyba że pisząc Managed Beans miałeś na myśli komponenty CDI ;-).Robert K. edytował(a) ten post dnia 22.02.13 o godzinie 09:19
-
Dla przykladu Hibernate zaleca uzywanie referencji bi, argumentujac to tym, ze latwiej po nich nawigowac. Swojego czasu dosc nagminnie z nich korzystalem, az pojawil sie problem: optimistic lock exc. Jako ze przy dodawaniu dziecka zmienia sie wersja rodzica, to przy jednoczesnym dodawaniu wielu dzieci pojawil sie problem z OLE. Referencje bi zamienilem na uni, w rodzicach pozostawiajac odpowiednie metody dostepowe i sprawa sie rozwiazala: mialem funkcjonalnosc bi, ale dzialanie uni. W przypadku Hibernate mozna skorzystac z adnotacji OptimisticLock, jednak takie rozwiazanie nie jest JPA friendly :-).
Dodatkowym mankamentem w przypadku bi jest dla mnie koniecznosc ustawiania dwoch stron referencji (p.getChildren().add(c) lacznie z c.setParent(p)). To jednak tez zostalo rozwiazane poprzez odpowiednia implementacje seta i opakowanie listy: nie wazne z ktorej strony programista ustawial powiazanie zawsze druga strona zostala ustawiona. Bylo to o tyle dobre, ze nawet jak ktos zmienil rodzaj ref. z uni na bi lub odwrotnie to nie bylo potrzeby zmiany kodu, jedynie metod dostepowych, z ktorych korzystano.
To samo tyczylo sie delete: programista wolal delete a implementacja metody (tworzona na podstawie modelu danych) usuwala co trzeba (rowniez dzieci z referencji uni, jesli takowe istnialy, a o ktorych nie mozna sie bylo dowiedziec analizujac tylko rodzica). -
Dzieki za odpowiedz, myslalem, ze watek umarl ;-).
Wlodzimierz M.:
Wydaje mi sie, ze tutaj porównujemy jabłka do ananasów - ja pisze o kombajnach typu Visual Paradigm, czy Rational Rose, Ty opisujesz customowe narzędzie wykrojone specjalnie pod Wasze potrzeby.
Ale jeśli faktycznie stworzyłeś coś, co można porównać z tymi aplikacjami - to daj komuś sie pobawić, zbierz feedback; potem jakaś beta i zacznijcie trzepać na tym mamonę :-)
Wlasnie jestem w fazie przygotowania takiej wersji, jednak poziom wyrozumialosci pracownika, ktory na co dzien korzysta i wie jak obejsc pewne "schody" jest nieporownywalnie wyzszy od osoby, ktora nie wie co i jak w narzedziu, musi wiec to byc porzadnie "otutorialowane".
Kilka luźnych uwag:
- Twój user (dla którego chciałbyś przeznaczyć to narzędzie) musi być prawdziwym superuserem, żeby pamiętać o "duperelach", które dla programisty (czy nawet analityka) są równie naturalne jak kawa na początek dnia. Prosty przykład: idź do pani Jadzi z księgowości i poproś, żeby Ci rozrysowała na kartce algorytm bloczkowy wybrania największej liczby z trzech (zadanie z informatyki, gdzieś z początków gimnazjum). Prawdopodobnie zanim załapie o co chodzi, z czym to się je i jak to w ogóle ma być zrobione, zabierzesz jej kartkę i sam to jej rozrysujesz ;-)
Poki co nawet nie myslalem, zeby dac pani Jadzi tego typu narzedzie, chyba, ze z tlumaczem ;-).
To co dla Ciebie wydaje się trywialne, może doprowadzić do przepalenia zwojów mózgowych u osób z bardziej humanistyczna wiedza. Popatrz na stronę WWW dowolnej malej firmy spoza branży - ile z nich było robione przez właścicieli? A przecież teoretycznie wystarczy ściągnąć Wordpressa, poklikać i już! Jednak prawie każdy decyduje się na wydanie tego tysiąca (czy ile teraz kosztuje strona) i zlecenie tego zewnętrznej firmie. Aplikacja webowa z jakąś zaszyta logika biznesowa jest o kilka poziomów bardziej skomplikowana. Właśnie po to takie rzeczy zleca się innym - żeby samemu SIĘ NIE MĘCZYĆ
Tak jak wyzej - koncowym uzytkownikiem nie moze byc klient, tylko analityk/programista, ktory tlumaczy jezyk klienta na jezyk modelu.
Czyli MDD jako pomoc dla developera - ok, ale jako narzędzie dla "endusera" - nie wyobrażam sobie.
Co do bebechów:
- Wygenerowane "rozwiązanie optymalne" będzie optymalne tylko dla ogólnego przypadku. Zawsze będzie jakiś odsetek przypadków, gdzie inne rozwiązanie będzie lepsze, może się nawet zdarzyć, ze w pewnym szczególnym przypadku wygenerowane rozwiązanie będzie tak fatalne, ze zaczyna pękać szkliwo na zębach. I właśnie wtedy użytkownik zaczyna Cie nienawidzić ;-)
Jesli bedzie mial mozliwosc adaptacji kodu generowanego lub czas zmiany kodu generowanego bedzie szybki to nie bedzie tak zle. Przez pewien czas pracownicy mnie nie nawidzili, pozniej bylo juz tylko lepiej :-).
- Porównywanie XML'i to zabawa dla kogoś, kto tego XML'a zna od podszewki - np. go pisał. Dla całej reszty będzie absolutnie niestrawny. Czasami dostaje do porównania diffy XMLi wygenerowanych w Install Shieldzie. To co dla gości od instalek jest oczywiste ("przecież to widać") - dla mnie często jest zagadką.
Nie bawimy sie w porownywanie XMLa - sa narzedzia zamieniajace je w drzewo zgodne z konwencja modelu, tzn. porownywane sa dwa modele w formie drzewiastej, XMLa nie widac.
- Jeśli znajdę błąd w VP czy RR, mogę co najwyżej zgłosić to i mieć nadzieje że kiedyś, w przyszłości ktoś to naprawi. Jeśli Tobie ktoś zgłosi błąd - otwierasz repozytorium, poprawiasz i dzień albo dwa dni później sprawa jest rozwiązana. Podobnie ma sie pewnie z nowymi wersjami bibliotek. Stąd różnica pomiędzy moimi 6 miesiącami a twoimi dwoma tygodniami :-)
Trafna uwaga - zadowolenie uzytkownika jest wprost proporcjonalne do szybkosci reakcji (i sktutkow tej reakcji). W moim przypadku nie moglem sobie pozwolic na 6m, bo projekty by nie szly, sprawa sie sama rozwiazala :-). -
Wlodzimierz M.:
Jestem na nie. Początki zazwyczaj sa bardzo przyjemne, ale potem...
Nie wiem, jakiego narzędzia planujecie użyć, ale ze swojego doświadczenia mogę wymienić takie minusy:
Pytanie miało na celu porównanie tego, co mamy w firmie z podobnymi rozwiązaniami obecnymi na rynku oraz rozeznanie się jak często używa się podobnych "praktyk". Ogólnie z takiego podejścia korzystamy z dużym powodzeniem i zależy mi na tym, aby porównać rozwiązanie z już istniejącymi.
Zacznijmy jednak od początku :-). Wszystko wzięło się od tego, że to co robimy (czyli programowanie) to jest modelowanie pewnej rzeczywistości. Innymi słowy (w pewnym skrócie) ktoś siada (klient), wymyśla coś w swoim języku, później analityk przekształca to w język zrozumiały dla programisty, który to z kolei przekształca to w język zrozumiały dla maszyny (a tak naprawdę to dla kompilatora, który przekształca to w język zrozumiały dla JVM, itd.). Kiedyś pisano w języku maszynowym/asemblerze (pamiętam te czasy...), ponieważ kompilatory nie były na tyle dopracowane, żeby w rozsądnym czasie wytworzyć kod wynikowy o podobnej wydajności. Poźniej pojawiło się C, później Java (tu było porównywanie do C), aktualnie z JITem mamy nawet niezłą wydajność. W dobie asemblera jednak ciężko było myśleć, że odejdzie on do lamusa (oczywiście ma zastosowanie w pewnych rejonach, ale to nie to samo co w okresach świetności).
Nasuwa się więc pytanie, czy przy obecnych mocach obliczeniowych nie można pokusić się o skrócenie tej drogi (klient - narzędzie lub ewen. klient - analityk - narzędzie), a całą moc przerobową programistów (lub jej lwią część) skierować na stworzenie "kompilatora modelu klienckiego"? Pytanie retoryczne, bo pokusić się zawsze można.
No i się pokusiłem, pierwszy raz w przypadku tworzenia aplikacji standalone (kompletne narzędzie, definiowało się UI oraz całą maszynę stanów odwzorowującą działanie aplikacji, bez kodowania można było "wyklikać" aplikacje), teraz próbuje odnieść to do aplikacji klient-serwer (web).
Odpowiem na uwagi odnosząc się do tego, co udało się wytworzyć.
- Większość narzędzi to aplikacje "klikane". Modele zazwyczaj sa zapisywane w postaci binarnej, oznacza to brak kontroli nad zmianami - nie jesteś w stanie powiedzieć, kto, co i kiedy zmienił.
- Oznacza to, ze nie jesteś w stanie w sensowny sposób wycofać części zmian.
Kontrola jest nawet w przypadku zapisu binarnego, wystarczy odpowiedni komparator. Używamy XMLowego opisu i istnieje możliwość automatycznego generowania zmian, wraz np. z sugestiami co należy zmienić (prosty przykład: dodano prymityw, należy ustawić wartości domyślne). Jeśli chodzi o zmiany to te można wycofać korzystając z komparatora modelu.
- Odpada tez praca równoległa - tylko jedna osoba może pracować nad modelem w danym momencie. Teoretycznie rożne wersje "enterprise" pozwalają na prace zespołową, ale jakoś tego nie widzę (ale tu nie mam doświadczenia). Często jest to wąskie gardło w przypadku większego zespołu.
Narzędzie umożliwia rozbicie modelu na mniejsze pliki (luźno ze sobą powiązane) - tutaj można pokusić się o analogię do plików Java - na projekt składa się ich X, Y ludzi nad nimi pracuje, wszystko zależy od narzędzi, z których korzystają do porównywania wersji.
- Zazwyczaj nawet drobne zmiany w modelu powodują radykalne zmiany w kodzie - bo np. model jest trzymany w mapach i za każdym razem metody sa generowane w innej kolejności. Nie jesteś w stanie powiedzieć jaki impakt ma twoja zmiana na kod wynikowy, bo diff pokazuje Ci np. 500 zmian.
Z reguły kodu generowanego się nie analizuje - zakłada się, że jest gotową biblioteką. Z pkt. widzenia programisty jest to black box, a jeśli on nie działa znaczy, że dał ciała ktoś od generacji.
- Nie ma mowy o szybkim poprawianiu błędów. Tu nie wystarczy poprawić "3" na "7", czy dołożyć "catch". Po znalezieniu błędu w kodzie musisz znaleźć miejsce w modelu i dopiero tam poprawić. Nie możesz tego zlecić jakiemuś praktykantowi, bo jak coś pomyli w modelu to aplikacja posypie sie w miejscu, którego absolutnie nie jesteś w stanie przewidzieć. Co więcej nawet taka drobna zmiana musi przejść przez "wąskie gardło".
Sam model nie zawiera kodu, jedynie opis aplikacji (model danych, procesy, maszyna stanów). Dodatkowo jest nałożona walidacja, która uniemożliwia wprowadzenie błędnych danych (np. pustej nazwy). Znowu analogia do Javy: walidacja modelu vs kompilacja klas.
Prawdziwe schody zaczynają sie, gdy okaże sie, ze twój tool nie jest w stanie wygenerować jakiegoś fragmentu kodu albo generuje go źle (bo aplikacja ma błąd, bo w docelowym języku jest błąd, bo w przeglądarce jest błąd). Wtedy generujesz kod i poprawiasz wygenerowany kod - właśnie założyłeś sobie na szyje pętlę, bo teraz za każdym razem, gdy generujesz kod, będziesz musiał go poprawiać. Najpierw w jednym pliku, potem w dziesięciu, potem okaże sie, ze po wygenerowaniu kodu będziesz musiał poświęcić dwa dni na wprowadzenie twoich zmian (i raczej nie zrobisz tego automatycznie). Co prawda można to obejść (puste metody pre-, post-, aspekty etc.) ale poświęcisz na to mnóstwo czasu.
Tutaj jest to standardowa procedura: jeśli nie jest w stanie wygenerować, to wtedy taką funkcjonalność się dodaje do generacji, jeśli jest błąd i trzeba go poprawić w generatorze.
Jeśli chodzi o zmiany w kodzie wygenerowanym, to można to robić w kodzie (adnotacje, wtedy generator omija adnotowane metody klasy) lub poprzez takie zaprojektowanie systemu, aby rozszerzenia były tworzone osobno.
Wygenerowany kod jest daleeki od optymalnego. Czasami będziesz chwytał sie za głowę, jak zobaczysz jakie potworki może wygenerować takie narzędzie.
Dlaczego jest daleki? Wyobraźmy sobie zagadnienie i dajmy je do realizacji 10 osobom. Z dużym prawdopodobieństwem można założyć, że jedno będzie najbardziej optymalne (w najgorszym przypadku wszystkie będą takie same) - reszta będzie gorsza.
W przypadku kodu generowanego to właśnie to najbardziej optymalne (ze znanych) jest aplikowane. A jeśli pojawi się nowe to zmianie ulegnie generator i zyskają pozostali (wystarczy wygenerować model).
Niezależność od zmian tez jest iluzoryczna. Napisanie kodu (parsera?), który przekładałby model na kod źródłowy w danym języku to nie jest prosta sprawa - licz sie wiec z tym, ze nowa wersja biblioteki/języka/standardu będzie obsługiwana w twoim narzędziu po 6-12 miesącach od premiery.
Mając model w ciągu dwóch tygodni powstał parser na Androida (generacja intentów, dostępu do danych, definiowanie maszyny stanów).
Podsumowując: generowanie kodu z modelu jest fajne, ale zastosowanie ograniczyłbym do naprawdę małych projektów/modułów, ew. do wygenerowania kodu pod pierwsza iteracje, gdzie masz już ogólny zarys, jak będzie wyglądała aplikacja. Wtedy trzaskasz model, klikasz i dość szybko można zacząć development.
Aktualnie na jedną z aplikacji składa się kilkaset tabel, wszystko co można jest opisane w modelu.
Ogólnie nie chodzi mi o odwiedzenie mnie od tej idei (aczkolwiek z chęcią wysłucham wątpliwości :-) ), ale o zorientowanie się czy (i jeśli tak, to w jakim stopniu) MDD jest wykorzystywane.
Dodam jeszcze, że podejście do rozwijania narzędzia jest ewolucyjne: jeśli coś można przerzucić do modelu (np. walidacja w OCLu, opis struktury menu, flow) to jest to robione, jeśli nie to zbierane są doświadczenia i robione jest to później.
Tak czy siak (czy tam inaczej ;-) ) - na każdym etapie tworzenia oprogramowania narzędzie jest wykorzystywane. -
Witam
Czy mieliście jakiekolwiek doświadczenia z frameworkami umożliwiającymi projektowanie aplikacji webowych w oparciu o MDD i generujących kod na różne platformy (np. JEE/PHP/Android)?
Chodzi mi o możliwość kompleksowego opisu modelu danych, procesów biznesowych oraz opis logiki modułów klienckich wraz z możliwością lokalizacji/dokumentacji/kontroli wersji modelu danych/etc.
i uniezależnienie się od docelowej platformy lub od zmian technologicznych (nowa wersja serwera aplikacji, etc.).
Z góry dziękuję za odpowiedzi
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
