пропозиції роботи
Wypowiedzi
-
dałem odpowiedz jedną z możliwych do zastosowania nieważne czy użyty jest Spring czy inna architektura mającą swoje wady i zalety, nie wiem gdzie tu odejście od pytania,
-
z tego co pamietam red5 dziala w trybie tomcata lub w trybie wara w kontenerze zewnętrznym. W obydwu trybach jest możliwy hot deploy. Zmodyfikuj na war + spróbuj zastosować:
http://flashvisions.com/red5/deploy-applications-to-re...
wydaje sie to nieskomplikowane, -
"wkopiowanie" aplikacji do webapp? Hmm, czemu takie coś? Takie rzeczy widziałęm tylko przy użyciu embedded container do testowania gdzie jeszcze nie było ustalonej specyfikacji dla takich rozwiązań i każdy dostawca kontenera podchodzi inaczej do tej kwestii. Jeżeli nie daje Ci to żadnej korzyści istotnej (a mówisz że nawet nie obsługuje to hotdeploy) to bym używał oficjalnie wspieranej konfiguracji czyli EAR (nie polecam), WAR (polecam). Mają hot deploy / redeploy bez restartu a restart w zasadzie jest wymagany tylko przez błędy PermGen chociaż z wersji na wersje JDK / konkretnych kontenerów jest z tym coraz lepiej.
Generalnie niezależnie od tego co powyżej to stosowanie podmiany plików przy przekopowaniu plików lub budowaniu archiwum to ciągle ten sam pomysł tak samo skuteczny. -
moja rada zwróć też koniecznie uwagę na PermGen, ma to szczególne znaczenie w przypadku redeployu bez restartu tomcata.
-
co to znaczy "deployujue bezpośrednio do kontenera"?
-
z góry uprzedzam że dawno nie robiłem w springu, ale z tego co pamietam obsługuje on standardowy mechanizm import xml. Dziedziczenie to chyba nie najlepsze określenie tego co chcesz zrobić, o ile dobrze rozumiem to chodzi Ci zwyczajnie o rozbicie dużej konfiguracji na mniejsze łatwiejsze w zarządzaniu pliki. Sprawdz import xml:
<import resource="..." -
Osobiście prefereuję po prostu trzymanie oddzielnych plików i przy budowaniu war'a etc. wybieranie z odpowiedniego folderu. Podejścia typu transformacje xslt itp. teoretycznie mogą się sprawdzić ale chyba lekka armata. W aplikacjach z którymi miałem styczność zazwyczaj różnice pojawiały się w konfiguracji loggera, podstawowych ścieżkach (poniżej 10 zmiennych) + persistence.xml i bardziej zaawansowane mechanizmy nie były uzasadnione. Aczkolwiek zawsze samodzielnie należy ocenić dane podejście do projektu.
-
Przydałoby się się dokładnie dowiedzieć co jest wykonywane w postgresie bo to może dać najszybciej wskazówkę co jest nie tak. Zapuść logowanie postgresa:
czyli z tego co pamiętam (postgresql.conf)
log_statement = 'all'
log_min_duration_statement = 0
i dokladnie sprawdz jaka komenda wykonywana jest dla błędu, na tej podstawie będziesz mógł stwierdzić gdzie tkwi błąd na poziomie SQL. Dodatkowo porównać czym się różni sekwencja wywołania poleceń SQL gdy jest według Ciebie "nie ma błędu" i gdy "jest błąd". Dodatkowo (trochę mocno paranoicznie ale nie zaszkodzi) wyłącz lub upewnij się że masz wyłączony cache L2. Choć hibernate ma domyślnie wyłączony to jednak mogłeś skopiować skadś fragment konfiguracji i niechcący włączyć L2. -
3. aktywny cache L2 i obserwacja w krótkim czasie (między inwalidacją L2)
-
Hmm, nie wiem czy dobrze zrozumiałem "zażalenie" ale chodzi Ci o to że w springu wystarczy w "beanie" mieć reference do pola User (POJO) a w JSF w backing bean nie możesz uzywać POJO ale musisz skopiować i utworzyć dla każdego pola jedno pole do przechowywania wartości i tutaj jest ta nadmiarowość (konieczność bezpośredniego odniesienia jedna kontrolka JSF -> jedno pole w backing bean)?
Jeżeli tak brzmiała intencja to nie jest to prawdą. Możesz mieć następującego backing beana z jednym POJO dla > 1 kontrolek. W poniższym przykładzie jeżeli typ User ma 300 pól które maja być odzwierciedlone w widoku nie trzeba tworzyć 300 pól w backing bean.
@RequestScoped
@ManagedBean
public class UserBean{
private User user = new User();
// setter i getter dla pola user
}
a w widoku odwolywać się np.
<p:inputText value="#{userBean.user.firstname}"/>
itd.
nowoczesne IDE generuje getter i setter automatycznie dla pola user więc gdzie tutaj problem / nadmiarowość?
w powyższym przykładzie użyłem jawne zainicjowania zmiennej User pustym obiektem żeby przeciwdziałać NPE, oczywiście w realnej aplikacji w zależności od potrzeb (np. wspóldzielenie jednego backing beana do dodawania i edycji może zajśc potrzeba np. w @PostConstruct zainicjowania obiektu np. danymi z bazy, ale to już zboczenie z tematu). -
kurcze nie nadążam za tymi nowymi dialektami JVM ;)
-
Tak na pierwsze rzucenie okiem:
a) niepotrzebne pola:
private long idklienta;
private long idpracownika;
private long idlicencji;
do wyrzucenia lub oznaczenia (ich cel jest zbędny skoro masz relacje do tych pól):
@Transient
a najlepiej
@Transient
private transient long idklienta
b) pracownik, dlaczego w konstruktorze chcesz podawać id skoro jest to generowana wartość, mimo że specyfikacja jawnie nie określa zachowania gdy ustawiasz wartość dla pola generowanego to openjpa ci rzuci exceptionem (nawet jezeli wrzucić liczbę spoza zakresu sekwencji uzywanej przez jpa i nie bedzie zachodzić konflikt na poziomie unikalności krotek w tabaeli przez PK) i to raczej nie jest dobry pomysł a już na pewno nie jest to portable (choć eclipselink Ci chyba na to pozwoli o ile nie wejdziesz mu oczywiśćie w konflikt z jego zbiorem numerów identyfikujących), dorzuć setter do Id Pracownika
c) upewnij się że tabele są dropowane przy uruchamianiu i generacja schematu jest "na czysto",
d) sprawdziłeś co się w bazie dzieje ? jak wygląda zmapowanie utworzone? -
Przy debugowaniu i poczatkowym uruchamianiu polecam wybranie strategii dropowania tabel przy uruchamanianiu. Na poczatku gdy struktura się mocno zmienia to jest mocno zalecane tym bardziej ze nie pamietam na ile dobrze eclipselink radzi sobie z samodzielnym dokladaniem roznic do schematu już istniejącego (OpenJPA z tego co pamietam sobie z tym lepiej radzi). Ustawienie w persistence:
<property name="eclipselink.ddl-generation" value="drop-and-create-tables" /> -
Zdajesz sobie sprawie że pytasz o absolutne podstawy które w przeciętnym tutorialu są wyjaśnione na samym poczatku? Żeby dodać coś do bazy danych używasz metod EntityManagera. Żeby przypisać relacji uzywasz zwyczajnie setterów / getterów i zapisujesz encję która ma być utrwalona.
-
Dwie sugestie:
- polecam korzystać z liczby pojedynczej dla nazwy encji, zwiększa to czytelność dla niektórych relacji, jeżeli masz w nawyku / zwyczaju nazywać tabele od liczby mnogiej zostaw to tylko w nazwie tabeli.
- nie stosuje się @Entity połączonego z @MappedSuperclass, to raczej błąd logiczny, @MappedSuperclass stosuje się dla klas z których dopiero nastąpi dziedziczenie a zawierają pola wspólne między klasami taka klasa NIE zostanie zamieniona bezpośrednio na tabelę a dopiero klasy z niej dziedziczące i oznaczone @Entity zostaną zamienione na tabelę, @Entity to oznaczenie końcowej klasy która zostanie zastąpiona na tabelę. W sumie dosyć ciekawe że dostawca JPA nie wyrzucił Ci żadnego exceptiona gdy na jednej klasie masz dwie sprzeczne ze sobą adnotacje. -
Moje skromne uwagi do rzeczy które znajdziesz na sieci:
- jeżeli zaczynasz przygodę z wymienionymi rzeczami unikaj gotowych wygenerowanych z kreatorów aplikacji, czesto takich aplikacji nie bedziesz w stanie bez pokonania wielu przeciwności uruchomić na innym komputerze gdzie będzie inna wersja javy, jre/jdk itp., jeżeli nie miałeś doświadczenia z mavenem polecam na anta i jakiś najprostrszy skrypt build.xml, do zastanowienia się czy w jakiej postaci będziesz dystrybuował aplikacje i ją uruchamiał (wpłynie to głównie na położenie pliku persistence.xml)
- pamietaj przy czytaniu tutorialów na sieci że uruchamianie JPA na desktopie jest raczej rzadkością (nie ze względu że to zła kombinacja, raczej przez fakt rzadkości javy ogólnie na desktopie) i większość tutoriali odnosi się do serwerowych rozwiązań które różnią się głównie: technologią tranzakcyjności (JTA zamiast local), większość rozwiązan serwerowych korzysta z tranzakcji zarzadzalnych przez kontener (czego nie uświadczysz na desktopie z wiadomych przyczyn), entity managera typu transaction scoped (a nie extended scoped jak w aplikacji JSE), w aplikacji typu desktop troche więcej masz na głowie w zakresie zarządzania cyklem życia JPA
- na poczatku tez zwróć uwagę że bardzo istotne jest położenie pliku persistence.xml, to od niego się zaczyna skanowanie classpatha w poszukiwaniu informacji o JPA, jak plik będzie w niewłaściwym folderze jedynym znakiem o tym że masz go w złym miejscu / folderze / strukturze jar'a będzie null pointer exception, albo nie do końca zrozumiały komunikat w zależności od dostawcy JPA.
powodzenia, -
Flex standardowo wspiera pliki properties: http://livedocs.adobe.com/flex/3/html/help.html?conten...
-
Witam serdecznie,
jeżeli kogoś uraziłem zamieszczając poniższe ogłoszenie na tej grupie to z góry przepraszam.
Opis stanowiska: Programista będzie brał udział w tworzeniu warstwy GUI nowej platformy intranetowej i komunikacyjnej opartej o technologie Flex 4 komunikującej się z użyciem protokołów http / REST z aplikacją J6EE na serwerze Glassfish
Nasz cel: wyciśnięcie ostatnich soków z Flexa w celu stworzenia unikalnej architektury korzystając z dobrodziejstw OOP / IoC/ pureMVC i wzorców programowania.
Wymagamy:
- doświadczenia w tworzeniu aplikacji flex
- doświadczenia w używaniu języków obiektowych
- myślenia i projektowania kategoriami OOP
- dyspozycyjności w zakresie minimum 20 godzin tygodniowo w godzinach pracy biura (preferujemy pracę na pełny etat), praca na miejscu w biurze
Idealnie by było jakbyś:
- miał doświadczenie w pracy w zespole wieloosobowym na styku kilku technologii gdzie flex pracował z aplikacjami Server-side (Java / PHP itp.)
- miał doświadczenie w pracy nad projektami wielomodułowymi we flex / AS3
- znał i używał frameworków architekturalnych (np. PureMVC)
- sprawnie rozpoznawał możliwość zastosowania wzorców projektowych i skutecznie wykorzystywał ich możliwości
- miał doświadczenie w pracy wieloosobowej z użyciem SCM i serwerów CI
- rozumiał znaczenie ergonomii i użyteczności interfejsu użytkownika
- posiadał portfolio online prac, którym mógłbyś się pochwalić
- miał doświadczenie w tworzeniu testów jednostkowych z użyciem FlexUnit
Oferujemy:
- pracę pełną wyzwań i możliwości wykorzystania najnowszych technologii związanych z Flex
- wsparcie w zdobyciu certyfikatu Adobe Certified Expert
- konkurencyjny system wynagrodzeń
- pracę w miłej atmosferze we współpracy z normalnym Zarządem w centrum Poznania
- możliwość wyboru formy zatrudnienia (umowa o pracę / FVAT / um. dzieło)
UWAGA: oferty pracy zdalnej nie będą brane pod uwagę (niestety).
Zapraszamy na stronę http://www.efresh.com.pl.
cv + list motywacyjny + portfolio prac o ile dostępne prosze o przesłanie na adres: info@efresh.com.pl -
Ja ze swej strony mogę polecić puremvc jako framework MVC, zarówno wersji jednomodułowej i wielomodułowej. Jestem po używaniu cairngorma i aż dziw bierze że adobe wspiera coś takiego (cairngorm). Puremvc nadaje sie zarowno do wielkich aplikacji jak i małych, bardzo ładnie zachowuje się czystość podzialu funkcjonalnego w aplikacji, i jest bardzo spójny i zapewnia z miejsca obsługę modułów aplikacji ładowanych dynamicznie, czego nie mogę powiedzieć o cairngorm.
-
Witam serdecznie,
pozwole odniesc sie do stwierdzenia Pana Dariusza że po to użytkownik wybiera CMS zeby nie musiec pisac w php. Chcialbym zauwazyc ze to mocne uproszczenie rzeczywistosci. Dlaczego:
Użytkownikow samego systemu CMS mozna podzielić na dwojakiego rodzaju zazwyczaj:
- firme wdrażająca serwis (kompetencje: obsluga klienta, przygotowanie projektow, skrojenie html, utworzenie i skonfigurowanie mechanizmow niezbednych do tego aby klient koncowy mogl samodzielnie wykonywac takie rzeczy jak: edycja tekstow, menu, mediow, dodawanie nowych podstron, czytanie danych przeslanych przez formularze kontaktowe itp.)
- klient koncowy (kompetencje: wypelnienie trescia, edycja tekstow, mediow, dodawanie nowych podstron, czytanie danych przeslanych przez formularze kontaktowe itp.
Mało rozwiniete systemy cms koncentruja sie aby spelnic wylacznie wybrane postulaty klienta koncowego zazwyczaj z mocnymi ograniczeniami np. co do struktury serwisu i mozliwosci zmian w serwisie przez osobe nie posiadajaca umiejetnosci html/php/css. Z braku czasu nie koncentruja sie zazwyczaj na wymaganiach firmy wdrozeniowej (gdzie zazwyczaj liczy sie czas czyli im szybciej mozna przeprowadzic wdrozenie a jednoczesnie (co jest zazwyczaj sprzeczne z postulatem szybkosci) cms nie narzuca ograniczen co do struktury i projektu graficznego. Dlatego wracajac do poczatku postu mowienie ze po to wybiera sie cms aby nie pisac w php jest uproszczeniem ktore znieksztalca obraz cms'ow. Sa dwa zupelnie inne obszary kompetencyjne na ktore odpowiada cms. Dobry CMS to taki ktory wspiera dwa obszary.
Dlaczego wiec firmy ktore wdrazaja wybieraja CMS zeby jeszcze bylo jasniej CMS komercyjny czyli ze wsparciem i gwarancja producenta, poniższe dane opieram na doświadczeniach HYDRAportal choć zakladam ze w innych cms'ach komercyjnych jest podobnie:
- na 90 procentach serwisow malych i srednich wystarczy jedna osoba z umiejetnosciami css/javascript aby wdrozyc taki serwis. Nie potrzeba do tego php nawet gdy korzystamy z formularzy dynamicznych ktore maja dane sciagane od uzytkownikow wpisywac do panelu administracyjnego z mozliwoscia eksportu do csv
- bez umiejetnosci php mozna wdrozyc serwis, przygotowac serwis do samodzielnego dodawania podstron i wdrożyć praktycznie wszystkie funkcje
- gdy jest niestandardowa potrzeba gdy jednak nie da sie obejsc bez czegos "algorytmicznego" i nietypowego to dobry cms umozliwia firmie wdrazajacej uzycie php do wykonania niestandardowej akcji
- co jest bardzo istotne to to ze dobre cms'y dostarczaja gotowych narzedzi do obslugi serwisu takie jak edytory menu / tekstu / obrazkow / flashy. Gotowe narzedzia do importu html'a do cms'a, wsparcie SEO (np. linki) i wiele innych rzeczy. Zaden cms robiony "pod serwis" na zamowienie nigdy nie dorowna pelnemu systemowi CMS ktory rozwijany byl kilka lat z mysla o zaspokojenie potrzeb wszystkich uzytkownikow
- co wazne komercyjny cms to zawsze wsparcie firmy wdrazajacej i branie na siebie obciazenia wynikajacego z koniecznosci utrzymania ogromnej bazy kodowej - gwarancji jakosci (rozbudowane systemy cms śmiem twierdzić ze dorownuja poziomem zlozonosci prostszym systemom erp i innych wsparcia zarządzania), zadnej firmie robiacej "pod serwis" cms'a nie bedzie sie oplacalo utrzymanie tak bogatej bazy kodowej, szczegolnie jezeli mowimy o sektorze ktory wdraza cms'y do powiedzmy 10 tysiecy pln za calosc. Jezeli mowimy o hp to moge tylko powiedziec ze aby zapewnic oczekiwana jakosc oprogramowania utrzymywane jest odrebna procedura testow automatycznych ktora symuluje zachowanie uzytkownika serwisu. Jest to kolosalny wysilek (kazda nowa funkcja to nie tylko zaimplementowanie kodu w php / html ale stworzenie funkcjonalnych testow automatycznych) i tylko myslac przez pryzmat globalnego rynku mozna pozwolic sobie na utrzymanie takich procedur jakosciwych i rozwojowych.
Z punktu widzenia uzytkowinia koncowego cms'a jest on istotny gdyż:
- bez dzwonienia moga samodzielnie zmienic teksty / linki / menu / dodawac nowe strony itp.
Oczywiscie wszystko co powyzej napisalem jest subiektywne ale wszystko co napisalem wynika z obserwacji rynku interaktywnego.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
