Temat: Pytanie w sprawie projektu portalu tematycznego.

WordPress czy Joomla mają tyle własnych dziwnych rozwiązań, że migracja potem do innego systemu będzie bardzo ciężka.

Poza tym, technologie są jednak zupełnie inne - Liferay to dość porządny twór w Javie, WordPress czy Joomla to słabo napisany PHP - dużo trudniej się to rozbudowuje.

Ja bym od razu startował z Liferayem - przecież też jest darmowy. Nie pracowałem z nim, ale słyszałem pochlebne opinie.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Nalezy sie trzymac z daleka, od wszystkiego co bazuje na Javie ;)
Zwlaszcza jesli to ma byc cos w rodzaju CMSow ;)

Temat: Pytanie w sprawie projektu portalu tematycznego.

Dziękuje za odpowiedzi, ale tak to właśnie wygląda..., dwie opinie dwóch specjalistów i dwie różne rady :)

Panie Andrzeju, prześledziłem Pański wątek związany z wyborem rozwiązania dla globalnego rozwiązania, miał być Drupal, a stanęło chyba na Typo3, bo zależało Panu na języku PHP, Liferay'a delikatnie Pan pomijał w wątku. Czy nie jest tak, że każdy radzi rozwiązania, do których ma przekonanie, na których pracuje.. ??

Jacek Romanowski:
WordPress czy Joomla mają tyle własnych dziwnych rozwiązań, że migracja potem do innego systemu będzie bardzo ciężka.

Poza tym, technologie są jednak zupełnie inne - Liferay to dość porządny twór w Javie, WordPress czy Joomla to słabo napisany PHP - dużo trudniej się to rozbudowuje.

Ja bym od razu startował z Liferayem - przecież też jest darmowy. Nie pracowałem z nim, ale słyszałem pochlebne opinie.

Ponieważ mam kłopot z rzetelną oceną na co postawić, musiałem przewertować temat i zapoznać się nieco z programowaniem i mam podobne odczucia jak kol. Jacek, boję się, że będzie kiedyś trzeba przenieść zawartość portalu do rozwiązania o większej skalowalności i ktoś mi nieźle za to krzyknie...

Z licznych opinii programistów wynika, że Liferay ma mnóstwo zalet, dlatego pracują na nim najwięksi, ostatnio VW zamienił Drupal'a na Liferay'a.

Jest kompleksowym rozwiązaniem portalowym rozpowszechnianym na licencji LPGL. Liferay to:

- Dojrzałe i wydajne rozwiązanie klasy enterprise, zweryfikowane w ponad 250 000 wdrożeń na
całym świecie
- Gotowe mechanizmy zarządzania treścią (CMS) zintegrowane także z Microsoft Office
- Otwarta platforma dla aplikacji - Liferay implementuje m.in. standardy JSR168/286 - Java Portlets
- Różnorodne funkcjonalności dostarczone razem z portalem, realizowane w standardowy sposób,
co przyspiesza budowanie oraz rozwój rozwiązań IT
- Komplet aplikacji dostarczany użytkownikom w zorganizowany sposób
- Spójny wygląd aplikacji oraz zarządzanie nim z jednego miejsca
- Możliwość zastosowania różnych arkuszy styli na konkretnych stronach portalu
- Powiązanie wszystkich aplikacji z profilem danego użytkownika
- Funkcje typu social (fora, wiki, integracja z facebookiem, itd.)
- Łatwe zarządzanie treścią oraz rozkładem stron widocznych dla użytkowników
- Sprawne udostępnianie nowych aplikacji użytkownikom
- Możliwość profilowania zalogowanych użytkowników

Liferay jest rozwiązaniem o architekturze standardowej dla aplikacji stworzonych w technologii Java. Pozwala to na wdrażanie portalu na różnych serwerach aplikacyjnych, silnikach baz danych oraz systemach operacyjnych.
Jednocześnie, architektura Liferay posiada dodatkowe zalety, wynikające z przyjętego modelu działania:

* Otwarty model na poziomie oprogramowania, łatwość modyfikacji, np. mechanizmów
autoryzacji i autentykacji
* Ustalone standardy aplikacji wymuszają przejrzystość architektury
* Model portalowy wymagający implementacji zgodnie z przyjętymi wzorcami i standardami
* Możliwość ponownego użycia (reuse) istniejących funkcji pomiędzy aplikacjami „SOA" z
poziomu interfejsu użytkownika
* Standaryzacja podstawowych mechanizmów aplikacji: uprawnień, uwierzytelniania, menu
nawigacyjnego

Portal jest nowoczesnym rozwiązaniem, które cechuje:

* Niski koszt - możliwe wdrożenia nawet w cenie konfiguracji i sprzętu
* Skalowalność - Liferay wspiera wiele serwerów aplikacyjnych J2EE oraz kontenerów servletów
* Możliwość łączenia aplikacji wykonanych w różnych technologiach
* Wiele dostępnych pluginów rozszerzających możliwości portalu
* Bardziej elastyczny - to odbiorca/użytkownik decyduje, która konfiguracja i mechanizm
zostaną użyte w danym rozwiązaniu
* Adoptowalność - rozwiązanie zbudowane dla jednego portalu, może być wykorzystane w
zupełnie innych warunkach
* Mniej skomplikowane - ponieważ Liferay dostarcza szereg funkcji w standardowy sposób,
rozwiązanie nie musi ich implementować. Dzięki temu można skupić się na kluczowych
zadaniach
* Tańsze w rozwoju i utrzymaniu - dzięki standardowym mechanizmom i prostej budowie Liferay

Skoro to rozwiązanie ma tyle zalet, dlaczego warto zainwestować w WordPress'a, Joomlę czy inny program napisany w PHP...? Ktoś zechce mnie naprostować.. ??

Pozdrawiam :)

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:

Krzysztof F.:
Programista ma racje. Grafik g. wie o projektowaniu pod web.

Co za bzdura. Graficy od weba znają się na tym raczej najlepiej właśnie. Jeżeli uważasz odwrotnie, to prawdopodobnie pracowałeś z gównianym "grafikiem".

Generalnie grafika powinna powstawać przed programowaniem, chociaż nie zawsze to jest możliwe (brak czasu, funduszy, niepełna wiedza o funkcjonalności systemu). Dobry grafik przygotuje dobry layout, w którym będzie się łatwo odnaleźć programiście. W drugą stronę jest gorzej. Jeżeli powstanie najpierw aplikacja, grafik będzie ograniczony jej strukturą w HTML (no chyba że zakładamy możliwość całkowitego przerycia systemu i przepisania HTMLi od nowa).

Graficy często liczą sobie więcej, kiedy muszą swój layout pociąć pod czyjś HTML (nie mówiąc o tym, że czasami się nie da).

Grafika na ogół powstaje przed programowaniem z uwagi na to że trzeba uzgodnić z klientem wygląd serwisu. I na ogół nie powstaje na tym etapie tylko parę głównych widoków.

W praktyce przed grafiką i programowaniem powstaję makiety. I to do makiet się pracuje.

1. Grafik ma pokazane wszystkie możliwe widoki z każdym potrzebnym elementem i adnotacją co robią te które mogą nie być jasne. Może pracować bez przeszkód.
2. Programiści tworzą portal na podstawie tych samych makiet robiąc bardzo prosty layout (kupa divów w odcieniach szarości). Mogą pracować bez przeszkód.
3. Na końcu webmaster składa to wszystko do kupy. Tzn bierze portal, bierze grafikę i podmienia tę istniejącą protezę. Grafik nie czeka nigdzie na programistów a programiści na grafika.

Jeżeli grafik jest ograniczony "strukturą HTML" to gdzieś na etapie tworzenia aplikacji coś poszło nie tak. Poza tym na ogół mało która firma przy zdrowych zmysłach za każdym razem buduje rozwiązanie od zera. Na ogół ma się gotową aplikację do której ewentualnie trzeba dorobić jakieś moduły. Więc grafika powstaje już pod aplikacje i istniejącą strukturę. Jeżeli są jakieś ograniczenia nałożone przez system to po prostu daje się dodatkowe wytyczne grafikowi.

To chyba tyle jeżeli chodzi o to co jest wcześniej. Jajo czy kura :-)Dariusz Półtorak edytował(a) ten post dnia 07.05.12 o godzinie 08:40

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:

Krzysztof F.:
Programista ma racje. Grafik g. wie o projektowaniu pod web.

Co za bzdura. Graficy od weba znają się na tym raczej najlepiej właśnie. Jeżeli uważasz odwrotnie, to prawdopodobnie pracowałeś z gównianym "grafikiem".

Generalnie grafika powinna powstawać przed programowaniem, chociaż nie zawsze to jest możliwe (brak czasu, funduszy, niepełna wiedza o funkcjonalności systemu). Dobry grafik przygotuje dobry layout, w którym będzie się łatwo odnaleźć programiście. W drugą stronę jest gorzej. Jeżeli powstanie najpierw aplikacja, grafik będzie ograniczony jej strukturą w HTML (no chyba że zakładamy możliwość całkowitego przerycia systemu i przepisania HTMLi od nowa).

Graficy często liczą sobie więcej, kiedy muszą swój layout pociąć pod czyjś HTML (nie mówiąc o tym, że czasami się nie da).

Chyba nigdy nie słyszałeś o http://en.wikipedia.org/wiki/Website_wireframe

Poza tym to, o czy piszesz, owszem może być prawdą... jeżeli robimy layout pod bloga Cześka z Szamotuł, a nie duży, dynamicznie zmieniający się projekt.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Napisałem, jak byłoby najlepiej, żeby było.

Pełne makiety 1:1, tak samo jak skończona grafika przed startem programowania, to mit - podobno ktoś kiedyś pracował przy takim projekcie, ale nie wiadomo gdzie i kiedy ;)

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:
Napisałem, jak byłoby najlepiej, żeby było.

Właśnie chodzi o to, że tak zupełnie nie byłoby najlepiej, bo to po prostu strata czasu i pieniędzy.

W projekcie nad którym pracuję zaczynamy od wireframe'ów zawsze - jak zostaną zatwierdzone i idą do produkcji, to nie mogą już zostać zmienione (chyba, że dokona się nowej estymacji).

Później dopiero powstaje grafika, przeważnie w tym samym czasie co funkcjonalności, aby można było w krótkich iteracjach robić releasy. Wygląd UI to akurat najmniej ważna rzecz, którą można z czasem dopieszczać.

Temat: Pytanie w sprawie projektu portalu tematycznego.

A czym się różni praca na zatwierdzonych ostatecznych wireframeach od zatwierdzonej ostatecznej grafiki? Poza tym, że w drugim przypadku tworzysz ostateczny z wyglądu projekt od ręki?

Temat: Pytanie w sprawie projektu portalu tematycznego.

przy projektach z klientem nie ogarniającym np uml'a makietowanie na podstawie "ostatecznej" grafiki jest częstym zjawiskiem, pozwala to uniknąc wielu nieporozumień w fazach implemetacji.
Jesli masz opisane i zatwierdzone przez klienta przynajmniej usecase'y i zakładaną wydajnośc to kolejność nie ma znaczenia.
Można robic jednocześnie, co w praktyce sprowadza sie do tego że grafika powstaje prędzej ze wzgędu na czas niezbędny do skodowania aplikacji ;-)
ale:
ponieważ grafika portalu <u>musi</u> opierać sie na jakimś sensownym systemie templatów (przynajmniej własnym) a najlepiej sprawdzonym i lubianym przez programistów i/lub projektanta, to sama implemntacja designu jest jednym z ostatnich kroków sensownego wdrożenia.
"Grafika" jest jak ktoś wcześniej zauważył dla end userów portalu, więc koderzy (czyli programiści ) z wrodzoną im skłonnością do "chodzenia na skróty" nie powinni brać udziału w jej projektowaniu.
Oczywiście w przeciwieństwie do analityka/projektanta czy project managera.

W tym przypadku, skoro o to pytasz najlepiej zrobić wszystkie screeny wstępnej grafiki na początku oraz uzgodnienie ich z klilentem i użycie ich jako makiety funkcjonalne.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Dariusz Rojek:
Skoro to rozwiązanie [Liferay] ma tyle zalet, dlaczego warto zainwestować w WordPress'a, Joomlę czy inny program napisany w PHP...? Ktoś zechce mnie naprostować.. ??

Wordpress to nie jest system portalowy, Joomla to jeden kręgów programistycznego piekła ;) (przynajmniej w linii 1.5.x).

Jedyne, co można porównywać, to Drupal vs. Liferay. Ja nie będę silił się na jakieś porównanie, bo znam tylko ten pierwszy framework (z premedytacją używam tutaj słowa framework). Jedno jest pewne - koszty wdrożenia Liferay będą większe, ponieważ:
- nie jest to popularna platforma, trudniej znaleźć fachowców,
- programista Javy zarabia więcej od programisty PHP,
- mogą dojść koszty zatrudnienia admina, jeśli Liferay wymaga dedykowanego serwera,
- baza pluginów Liferay jest bardzo licha, więc dużo funkcjonalności będzie pewnie trzeba napisać od zera.

Koszty wdrożenia mogą się potem zwrócić w postaci mniejszych kosztów na późniejsze utrzymanie, niż w przypadku Drupala.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:
A czym się różni praca na zatwierdzonych ostatecznych wireframeach od zatwierdzonej ostatecznej grafiki? Poza tym, że w drugim przypadku tworzysz ostateczny z wyglądu projekt od ręki?

Tym że
1. w momencie jak masz makiety, graficy i programiści mogą pracować RÓWNOCZEŚNIE a w trakcie jak oni pracują Ty możesz jeszcze dogrywać z klientem ostateczny wygląd grafiki bo zawsze gdzieś kolor niebieski dla klienta nie będzie wystarczająco niebieski a te kanciaste rogi chciał by bardziej zaokrąglone itp...
2. mając makiety w momencie jak klient wymyśli w widoku dodatkową opcję po prostu weźmiesz i paroma ruchami myszy przy nim ją dodasz.
3. mając makiety w dobrym programie który może je łączyć po elementach (tzn kliknięcie w element przenosi cie do innej makiety) możesz "przeprowadzić" klienta po programie, uniknąć nieporozumień i dograć szczegóły
4. makiety robi się bardzo szybko

Jak pracujesz na oryginalnej grafice to
1. na ogół graficy i programiści nie mogą pracować równocześnie bo trzeba poczekać na poszczególne widoki.
2. jak klient wymyśli dodatkową opcję to musisz to przekazać grafikom i czekać na zmiany. Jak się rozmyśli to właśnie stracili czas itp. Dodatkowo musisz zakładać że masz rację bo dopóki nie będzie grafiki ciężko być pewnym tego że się zrozumieliście wszędzie. Dodatkowo wszystkie zmiany powtarzają cykl klient -> menedżer projektu -> graficy -> klient zamiast (menedżer projektu -> klient -> menedżer projektu > klient [pewnie przy stole tego samego dnia]) -> graficy
3. można przeprowadzić klienta przez program mając grafikę ale jest to szalenie niewygodne. Bawisz się w slajdy albo coś...
4. Na grafikę się deczko czeka więc całość się wydłuża ze względu na ewentualne zmiany, pomyłki i czas potrzebny na przygotowanie grafiki

Temat: Pytanie w sprawie projektu portalu tematycznego.

Dariusz, chyba nie rozumiesz określenia "zatwierdzone ostatecznie", którego używałem.

To co piszesz oczywiście jest prawdą, ale to co ja próbuję przekazać, to to, że kodowanie aplikacji na gotowych, ostatecznych htmlach jest lepsze, niż kodowanie aplikacji na podstawie makiet. Nie wnikajmy w to, jak często coś może być ostateczne i czy klient będzie chciał poprawki.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:
Dariusz, chyba nie rozumiesz określenia "zatwierdzone ostatecznie", którego używałem.

To co piszesz oczywiście jest prawdą, ale to co ja próbuję przekazać, to to, że kodowanie aplikacji na gotowych, ostatecznych htmlach jest lepsze, niż kodowanie aplikacji na podstawie makiet. Nie wnikajmy w to, jak często coś może być ostateczne i czy klient będzie chciał poprawki.

Nie za bardzo rozumiem tutaj o co Ci chodzi. Żeby grafika była "zatwierdzone ostatecznie" trzeba... no wiesz... przygotować z klientem koncepcję projektu, dać to grafikowi do zrobienia, później przy konsultacji z klientem nanieść różnorakie poprawki, zmiany itp a jak to już wszystko się zrobi to wtedy grafika jest "zatwierdzona ostatecznie".

Pewnie że na gotowych html'ach i grafikach pracuje się o niebo lepiej ale jakoś tworząc cokolwiek mało kiedy trafiała mi się sytuacja że grafikę już miałem na starcie (dodatkowo pociętą i okodowaną). Jeżeli cały zespół zaczyna pracę nad projektem równocześnie - makiety zawsze idą w ruch.

Po twojemu właściwie cała reszta pracy stoi w miejscu bo do ostatniego momentu nie jesteśmy pewni czy nie pojawi się nowa opcja, czy jakaś nie zniknie, czy jakiś widok nie zostanie zastąpiony lub czy przypadkiem menedżer z klientem się nie zrozumieli i coś w ogóle powinno działać inaczej.

W wypadku kiedy używamy makiet ten problem znika. Makiety robi się bardzo szybko. To kwestia otworzenia dokumentu, naniesienia gotowych elementów wg wytycznych i ewentualnym połączeniu widoków. Wszystkie zmiany można nanieść dosłownie siedząc z klientem korzystając z laptopa albo tabletu jeżeli zmiany nie są znaczące.

Tak jak rozdziela się HTML i CSS czyli strukturę dokumentu od widoku, makiety pozwalają rozdzielić strukturę aplikacji od jej wyglądu. Dzięki temu cała funkcjonalność zostaje przygotowana bardzo szybko, zespół programistów robi swoje a później zmienia się ich szablon-protezę na właściwą grafikę.

Jeżeli mówisz że owe makiety to mit który ktoś kiedyś może widział (tak jak ja mówię o dokumentacji projektu) to ja Ci powiem że o ile dokumentacja to dodatkowa praca która wydłuża cały proces (i nie dziwię się że małe zespoły często ją pomijają bo każdy zna cały projekt - w przeciwieństwie do sytuacji jak mamy do czynienia z dużym zespołem i dużym projektem gdzie dokumentacja jest niezbędna) o tyle makiety ów proces przyśpieszają więc rezygnowanie z nich to tylko utrudnianie sobie życia.Dariusz Półtorak edytował(a) ten post dnia 08.05.12 o godzinie 10:33

Temat: Pytanie w sprawie projektu portalu tematycznego.

@Dariusz - Jackowi chodzi o sytuacje gdy wszystko jest już ustalone, podpisane i koniec dyskusji z klientem, tudzież klient przynosi swoje.
Problem w tym, że jeżeli w layoucie można pominąć konkretne widoki.
W makietach, które sobie linkujesz już jest trudniej.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Dalej filozofujesz. Napisałem, że to byłaby idealna sytuacja, że tak byłoby najlepiej, a Ty dalej swoje, że tak się nie da, że się czeka, że coś stoi...

Dariusz Półtorak:
Jeżeli mówisz że owe makiety to mit który ktoś kiedyś może widział

I wszystko rozumiesz na swój sposób. Nie pisałem, że makiety to mit, który ktoś kiedyś może widział, tylko że *pełne* makiety 1 do 1 (zgodne z ostateczną wersją) są mitem.

Temat: Pytanie w sprawie projektu portalu tematycznego.

Jacek Romanowski:
Dalej filozofujesz. Napisałem, że to byłaby idealna sytuacja, że tak byłoby najlepiej, a Ty dalej swoje, że tak się nie da, że się czeka, że coś stoi...

Dariusz Półtorak:
Jeżeli mówisz że owe makiety to mit który ktoś kiedyś może widział

I wszystko rozumiesz na swój sposób. Nie pisałem, że makiety to mit, który ktoś kiedyś może widział, tylko że *pełne* makiety 1 do 1 (zgodne z ostateczną wersją) są mitem.

Ja wiem o co Ci chodzi. Zresztą cytując wyżej z mojego postu:

"Pewnie że na gotowych html'ach i grafikach pracuje się o niebo lepiej ale jakoś tworząc cokolwiek mało kiedy trafiała mi się sytuacja że grafikę już miałem na starcie (dodatkowo pociętą i okodowaną). Jeżeli cały zespół zaczyna pracę nad projektem równocześnie - makiety zawsze idą w ruch. "

Po prostu uważam że taka sytuacja to jest właśnie mit. Co śmieszne mamy odwrotną sytuację. Bo ja z makietami 1 do 1 spotykam się dość często. Zresztą wg nich rozliczam się z klientem.

@Michał, jak jest wszystko podpisane, ustalone itp to pewnie że łatwiej. Tylko powiedz mi ile razy trafiła Ci się taka sytuacja ? O to że makiety musisz robić wszystkie raczej martwić się nie trzeba. W końcu nikt przy zdrowych zmysłach nie zaczyna pracy mając na papierze połowę aplikacji. Chyba że budujemy większy system pełny niezależnych modułów ale tutaj też problemu nie ma bo się robi zestaw widoków per moduł.

Temat: Pytanie w sprawie projektu portalu tematycznego.

@Dariusz - kilkukrotnie. Można by policzyć na jednej ręce.
Co ciekawsze - zawsze w takiej sytuacji były braki - brakowało konkretnych widoków lub wskazywany widok był... błędny :)

BTW. ale już niebawem, napiszę do ciebie i może się ucieszysz z wiadomości :)

Temat: Pytanie w sprawie projektu portalu tematycznego.

Michał Wachowski:
@Dariusz - kilkukrotnie. Można by policzyć na jednej ręce.
Co ciekawsze - zawsze w takiej sytuacji były braki - brakowało konkretnych widoków lub wskazywany widok był... błędny :)

BTW. ale już niebawem, napiszę do ciebie i może się ucieszysz z wiadomości :)

O tym mówię. Dodatkowo makiety mają jedną piękną zaletę. ZERO braku zrozumienia z grafikiem. Ile razy zdarzało się że grafik sam zapomniał jakiegoś elementu lub coś zrobił nie tak to nawet nie policzę. Makiety i ten problem rozwiązują.
Po pierwsze grafik ma strukturę widoku a po drugie jak o czymś zapomni to nie ma wymówki.
To rozwiązuje problem o którym wspominasz - że "zawsze w takiej sytuacji były braki".

BTW rozumiem że masz na ukończeniu to o czym myślę ? :-) Bosko.Dariusz Półtorak edytował(a) ten post dnia 08.05.12 o godzinie 11:51

Temat: Pytanie w sprawie projektu portalu tematycznego.

Tomasz K.:

Dariusz Rojek:
Skoro to rozwiązanie [Liferay] ma tyle zalet, dlaczego warto zainwestować w WordPress'a, Joomlę czy inny program napisany w PHP...? Ktoś zechce mnie naprostować.. ??

Wordpress to nie jest system portalowy, Joomla to jeden kręgów programistycznego piekła ;) (przynajmniej w linii 1.5.x).

Jedyne, co można porównywać, to Drupal vs. Liferay. Ja nie będę silił się na jakieś porównanie, bo znam tylko ten pierwszy framework (z premedytacją używam tutaj słowa framework). Jedno jest pewne - koszty wdrożenia Liferay będą większe, ponieważ:
- nie jest to popularna platforma, trudniej znaleźć fachowców,
- programista Javy zarabia więcej od programisty PHP,
- mogą dojść koszty zatrudnienia admina, jeśli Liferay wymaga dedykowanego serwera,
- baza pluginów Liferay jest bardzo licha, więc dużo funkcjonalności będzie pewnie trzeba napisać od zera.

Koszty wdrożenia mogą się potem zwrócić w postaci mniejszych kosztów na późniejsze utrzymanie, niż w przypadku Drupala.

Oczywiście zdadzam się, że popularne platformy open source trudno porównywać z portalem takim jak Liferay, jednak chodzi o to dlaczego wybrać rozwiązanie oparte np. o Joomlę (która ma opinię zbieżną do Pańskiej), zamiast dojrzalszego rozwiązania, które w przyszłości np. ze względu na skalowalność pozwoli na duże oszczędności ?

- Co do specjalistów, to jest ich niewielu ale nie aż tak mało...
- Owszem programista pracujący w języku Java jest droższy, ale rozwiązanie portalu pozwala na
szybszą budowę w oparciu o gotowe portlety, co chyba przełoży się na znacznie krótszy czas
pracy, czy się mylę...??
- Wg. opinii firm wdrażających to rozwiązanie nie potrzebny jest serwer dedykowany, w każdym
razie nie na moim etapie.
- --> * Wiele dostępnych pluginów rozszerzających możliwości portalu

Temat: Pytanie w sprawie projektu portalu tematycznego.

Dariusz Rojek:
Oczywiście zdadzam się, że popularne platformy open source trudno porównywać z portalem takim jak Liferay, jednak chodzi o to dlaczego wybrać rozwiązanie oparte np. o Joomlę (która ma opinię zbieżną do Pańskiej), zamiast dojrzalszego rozwiązania, które w przyszłości np. ze względu na skalowalność pozwoli na duże oszczędności ?

Skalowalność można uzyskać na wielu poziomach. Na system internetowy składają się: serwery web, reverse proxy, aplikacyjne, bazodanowe, przetwarzania wsadowego, itp. Można każdy z tych elementów poddać optymalizacji i jest to niezależne od wybranej aplikacji. Dużo zależy od schematu bazy danych, efektywności zapytań SQL, nałożonych indeksów, itd. W przypadku klasycznych portali, gdzie jest dużo czytelników, optymalizację można łatwo uzyskać obsługując requesty bezpośrednio z RAM, zamiast z dysku oraz bez potrzeby odpytywania bazy danych.

- Co do specjalistów, to jest ich niewielu ale nie aż tak mało...
- Owszem programista pracujący w języku Java jest droższy, ale rozwiązanie portalu pozwala na
szybszą budowę w oparciu o gotowe portlety, co chyba przełoży się na znacznie krótszy czas
pracy, czy się mylę...??
- Wg. opinii firm wdrażających to rozwiązanie nie potrzebny jest serwer dedykowany, w każdym
razie nie na moim etapie.

Widzę, że się Pan sam przekonał ;) Tak naprawdę to cały czas mamy wróżenie z fusów, bo wybór technologii powinien nastąpić po etapie analizy wymagań. Tu żadnych konkretnych wymagań Pan nie przedstawił.

- --> * Wiele dostępnych pluginów rozszerzających możliwości portalu

Co znaczy wiele? Na stronie Liferay widzę ok. 200 dostępnych pluginów i kilkadziesiąt motywów (themes). Drupal ma ponad 10000 pluginów i ok. 1000 motywów.