»

Wstęp

Jednym z pytań, które zazwyczaj sobie stawiamy rozpoczynając nowy projekt jest to dotyczące wyboru technologii. Nie inaczej było i tym razem –  każda technologia ma swoje plusy i minusy, swoje specyficzne smaczki, które powodują że dla pewnych zagadnień sprawdza się lepiej lub gorzej. Najlepszego języka/framework-a nie ma i być nie może, z tej prostej przyczyny że każdy zwraca uwagę na inne detale, co innego jest dla niego istotne, tak też framework-i skupiają się na różnych aspektach: szybkości tworzenia, elegancji, wydajności, itd. Pojawienie się idealnego języka/framework-a oznaczałoby koniec rozwoju, stagnację… na szczęście wygląda, że nam to nie grozi. Zadaniem tego postu jest pokazanie na co my zwróciliśmy uwagę i jaka decyzję finalnie podjęliśmy.

W zależności od naszej wiedzy, doświadczeń oraz ilości czasu jaki mamy na podjęcie takiej decyzji możemy podejść do tematu w różny sposób:

  • Wybór podyktowany technologiami, które już znamy. Z jednej strony dzięki temu minimalizujemy czas potrzebny na poznanie nowych technologii, minimalizujemy ryzyko wszelkiego rodzaju potyczek technologicznych, bo cześć z nich już stoczyliśmy i znamy gotowe rozwiązania. Z drugiej strony możemy w ten sposób utknąć przy rozwiązaniach, które na chwilę obecną z różnych względów nie są najbardziej optymalne,
  • Rozpoznanie bojem. Jedno z bardziej ciekawych i rozwijających podejść do tematu. Wybieramy N najbardziej rokujących naszym zdaniem rozwiązań, a następnie dla każdego z nich wykonujemy mały PoC („Proof of Concept”, nie mylić z „Pirates of the Caribbean” ;) ). Podejście to wymaga jednego założenia: mamy sporo czasu na takie prace, a z tym to już różnie bywa…,
  • Zapoznanie się z możliwie szeroką opinią innych ludzi. Możemy więc spędzić kilka wieczorów z Google-em i na podstawie tak ograniczonej ilości informacji podjąć decyzję. Z jednej strony pomysł może wydawać się ryzykowny, bo na temat każdej technologii znajdziemy zarówno psalmy pochwalne jak i posty o przeciwnym zabarwieniu (wystarczy wpisać w google-a wybrany język + sucks, np. „php sucks”). Z drugiej strony przy odpowiedniej dawce przeciwstawnych opinii i odrobinie intuicji, można podjąć naprawdę dobrą decyzję niskim kosztem.

Szranki i konkury1

Pierwszym moim podejściem było „znana technologia” — miała to być Java, jako że ostatnie kilka lat spędziłem tworząc aplikacje web-owe oparte o ten właśnie język (oczywiście plus framework-i jak Struts, Hibernate, itp.). Rozważałem także dodanie jednego czy dwóch framework-ów, z którymi nie miałem dużych doświadczeń (jak np. Spring), ale generalnie zamierzałem oprzeć się na znanych mi rozwiązaniach.

Jednak prace mimo wszystko nie posuwały się tak szybko, jakbym sobie tego życzył. Przy drugim podejściu, które nastąpiło jakiś czas później postanowiłem poddać weryfikacji swoją wcześniejszą decyzję. Jako, że na nadmiar wolnego czasu raczej nie mogę narzekać, stanęło na rozwiązaniu: „kilka wieczorów z Google-m”. Do szranków stanęły:

  • C#
  • Java
  • PHP
  • Python
  • Perl
  • Ruby

(oczywiście powyższa lista nie zawiera wszystkich dostępnych opcji, a tylko te, które w moim odczuciu były najbardziej rokujące)

Teoretycznie aplikację tego typu można napisać w każdym z wymienionych języków (oraz w sporej ilości niewymienionych), ale jak przychodzi już do pisania trzeba się zdecydować na ten jeden konkretny, który w naszym odczuciu do danego rodzaju aplikacji będzie najodpowiedniejszy. Na początek postanowiłem przyjrzeć się następującym kryteriom:

  • otwartość rozwiązania, rozumiana głównie jako otwartość źródeł,
  • szybkość tworzenia kodu oraz łatwość jego późniejszego rozwoju i utrzymania,
  • popularność danego języka a tym samym łatwość późniejszego pozyskania na rynku developerów posługujących się nim,
  • szeroko rozumiana zasobo-żerność i wynikająca z niej wydajność przy określonej ilości sprzętu,
  • dostępność zewnętrznych bibliotek (najlepiej freeware-owych),
  • składnia języka,
  • dojrzałość framework-ów służących do tworzenia aplikacji web-owych w danym języku, najlepiej opartych o model MVC.

Mając to wszytko na uwadze rozpocząłem swoje wieczory sam na sam z Google-m. Prawdę mówiąc wybór był już dokonany (Java) i tak naprawdę chciałem tylko potwierdzić jego słuszność. Trzeba przyznać, że trochę byłem zaskoczony (tak to jest, gdy człowiek skupi się tylko na korporacyjnych rozwiązaniach), gdy już po kilku godzinach poszukiwań okazało się, że Java delikatnie mówiąc, nie jest najczęściej wybieranym rozwiązaniem — z większych serwisów wypatrzyłem tylko FeedBurner (który oparty jest na Java+JS+Tomcat+MySQL. Z naszego rodzimego podwórka serwis Grono.net początkowo napisany został w oparciu o język Java, jednak po dwóch latach został on przepisany, wykorzystując tym razem Python+Django — swoją drogą chętnie spytałbym się osób odpowiedzialnych za tą decyzję, co spowodowało tak poważną decyzję i co ważniejsze jak tą decyzję oceniają z perspektywy następnych kilku lat.

Otwartość rozwiązania

Na tym etapie odpadł C#, w zasadzie bez większego zgłębiania tematu. Język ten na pewno ma mnóstwo ciekawych rozwiązań, jednak fakt ograniczenia się do produktów Microsoft-u zadecydował o jego dyskwalifikacji. Wszystkie inne rozwiązania w mniejszym lub większym stopniu oparte są o otwarte rozwiązania.

Szybkość tworzenia / łatwość utrzymania aplikacji

Nie są to rzeczy łatwo mierzalne, jednak ze wszystkich znaków na niebie i ziemi (czyli dziesiątków postów) wynika że znacząco szybciej tworzy się kod przy użyciu języków interpretowanych, dynamicznie typowanych. Jeśli chodzi o łatwość utrzymania kodu, to tak postawione pytanie jest jednym z wielu wywołujących niekończące się dyskusje w stylu: które języki są lepsze dynamicznie, czy statycznie typowane, KDE czy GNOME, Ruby czy Python, święta Bożego Narodzenia, czy Wielkanocne. Dotąd też byłem zwolennikiem języków statycznie typowanych i taki Smalltalk wydawał mi się onegdaj bardziej ciekawostką, niż językiem do tworzenia dużych systemów. Jednak wydaje się, że w przypadku serwisów internetowych języki dynamiczne lepiej się sprawdzają ze względu na zwiększenie produktywności. A wady takie jak trudniejszy refactoring, czy też możliwość, że pewne błędy zostaną wyłapane dopiero w czasie testów (a nie kompilacji) są akceptowalnym kosztem. W swoim czasie Bruce Eckel (tak ten od „Thinking in Java”, „Thinking in C++”) popełnij następujący post Strong Typing vs. Strong Testing, traktujący o tym że w dobie TDD zysk ze statycznej kontroli typów stał się znikomy.

W tym konkretnym konkursie postanowiłem więc przyznać punkty językom dynamicznie typowanym, tj. Perl/Python/PHP/Ruby. Jeśli kogoś zainteresowało porównanie mocnych i słabych strony języków typowanych statycznie versus dynamicznie, to odsyłam do małej prezentacji Contrasting java and dynamic languages. Interesujące porównanie jest także tutaj C++ vs Java vs Python vs Ruby (i od razu oczywiście krytyka takiego podejścia).

Popularność danego języka

Jednym ze sposobów weryfikacji popularności języka może być: TIOBE Programming Community Index lub Programming Language Popularity. Innym weryfikacja na swoim ulubionym portalu z pracą, ile jest ofert związanych z określonym językiem programowania. W zależności od wyboru takiego portalu (polski/zagraniczny) wyniki mogą się trochę różnić. Wydaje się jednak że ze znalezieniem programistów Java lub PHP nie powinno być problemu. Choć w przypadku PHP należałoby pewnie zadać sobie także dodatkowe pytanie: Jak wielu z nich jest obeznanych z programowaniem obiektowym, zna i docenia zalety modeli typu MVC.

A może jeśli na lokalnym rynku nie ma za dużo programistów znających język, który chcemy użyć jesteśmy w stanie stworzyć odpowiednie community? Czy są blisko uczelnie informatyczne, które używają danego języka programowania w trakcie nauki studentów? Jeśli nie, to czy byłyby skłonne zacząć i jeszcze lepiej współuczestniczyć w tworzeniu community?

Wydajność

Dość trudno odpowiedzieć na to pytanie. Z jednej strony te same algorytmy napisane w Java wydają się być szybsze niż ich odpowiedniki w Python/Ruby. Z drugiej strony, jak się spojrzy ile pamięci potrzebuje Tomcat, aby rozsądnie działać versus np. moduł mod_python, to sprawa nie jest już taka oczywista. Można w internecie znaleźć setki takich porównań a chwilę potem tyle samo komentarzy przekonywujących czemu dany test nie ma specjalnie sensu. Przykładowe posty: Ruby on Rails vs. Django performance, Framework Performance, The performance test of 6 leading frameworks (choć ten już trochę leciwy, bo z 2007 roku).

Osobiście byłbym skłonny dołączyć się do głosów, że 20-30% różnicy w takich testach nie jest specjalnie znaczące, a większość optymalizacji dotyczy bazy danych.

W kategorii tej nie został wybrany jednoznaczny zwycięzca.

Zewnętrzne biblioteki

Wydaje się, że wszystkie z wymienionych języków mają dość bogatą ofertę zewnętrznych bibliotek.

Więc także brak jednoznacznego zwycięzcy.

Składnia języka

Jeden język został na tym etapie zdyskwalifikowany — Perl, rozumiem, że są zadania gdzie świetnie się sprawdza, ale do mnie jego składnia nie trafia i już. Także PHP nie popisał się na tym polu, w internecie aż roi się od postów wytykających bałagan dotyczący składni, np. PHP Sucks, But It Doesn’t Matter.

Framework-i

Każde z tych rozwiązań dorobiło się już dojrzałych framework-ów. Dla PHP są to m.in. CakePHP, Symfony, Zend, dla Ruby Ruby on Rails, a także ostatnio Merb. Dla Python-a będą to chociażby: Django, TurboGears, Pylons, o Javie nie wspominając, bo ciężko byłoby je wszystkie wymienić.

Tak więc i w tej kategorii nie ma jednoznacznych wygranych, czy też przegranych.

Podsumowanie

Wybór w dużej mierze sprowadza się do zagadnienia „języki typowane statycznie versus dynamicznie”. Te drugie pozwalają szybciej kodować, oczywiście jakimś kosztem. Wydaje się jednak, że w naszym przypadku zastosowanie ich jest całkowicie uzasadnione.

And the winner is…

Które więc z rozwiązań PHP/Python/Perl/Ruby. Perl odpadł w związku z jego składnią. PHP jakoś mimo swojej dużej popularności do mnie nie przemawia — zresztą nie tylko do mnie (jedna z wielu dyskusji o wyższości jednego języka nad drugim). Może jest to kwestia różnych korzeni – moje są obiektowe, jego nie specjalnie. Pozostają Python i Ruby — oba obiektowe, oba mające swoich zwolenników i przeciwników.

Schodząc na poziom framework-ów oznaczało wybór pomiędzy: Django/Pylons/TurboGears/Ruby on Rails/Merb. Tu wybór nie był już wcale oczywisty i każdy z nich prawdopodobnie świetnie by się spisał. Jednak decyzję trzeba podjąć — Merb wydaje się trochę za świeży, RoR ma trochę za dużo magii, Pylons&TurboGears z jednej strony integrują w całość najlepsze komponenty, z drugiej strony czas potrzebny na to, aby stać się produktywnym jest siłą rzeczy większy, no i ta nie najlepsza dokumentacja. Django za to sprawdził się w boju, okrzepł (ostatnio dorobił się wersji 1.0), ma doskonałą dokumentację i nawet jeśli w pewnych miejscach jest trochę słabszy — zdaje się być najlepszym wyborem dla nas. Dodatkowo Python jest jednym z trzech głównych języków używanych w firmie Google, a ichni Google App Engine pozwala uruchamiać aplikacje w okrojonej wersji Django, co nawet jeśli nie zamierzamy tego wykorzystywać o czymś świadczy.

Tak więc wybraliśmy zestaw: Python + Django.

Jeśli ktoś ma ochotę na więcej, poniżej inne ciekawe posty w temacie wyboru technologii:

Założenia z grubsza mieliśmy podobne, jednak jak widać decyzje podjęliśmy inne. Czy któraś z nich była lepsza/gorsza? Moim zdaniem nie, po prostu są one inne. Co więcej, za pół roku mając te same założenia można by podjąć inną decyzję.

1 Szranki i konkury – zbieżność tytułów całkowicie przypadkowa

This entry was posted by Mikolaj Kmita on 11 listopada 2008 at 23:54 under Technologia. Tagged , . You can leave a response, or trackback from your own site. Follow any responses to this entry through the RSS 2.0 feed.

8 Comments

  1. Michał Orzechowski says:

    Na początku wielkie podziękowania, za to, że chciało Ci się tym wszystkim podzielić :-) . Nie ze wszystkim się zgadzam ale po kolei ..
    Wymieniłeś parę kryteriów wyboru technologii, ja od siebie dorzuciłbym jeszcze: odbiorcę docelowego (i istniejące środowisko klienta lub jego brak). Często jest tak, że technologię narzuca po prostu klient (np opcja hostingu którą dysponuje), o czym doskonale wiesz. Oczywiście, jeżeli zaczynamy projekt od zera i jest on w 100% zależny od naszych decyzji to wspaniale, ale pamiętajmy że nie zawsze rzeczywistość jest tak piękna.
    Piszesz o zaskoczeniu faktem, że w Javie nie pisze się serwisów webowych. Dokładnie to samo przeżyłem w okolicach lipca obecnego roku. Niesiony pytaniem znajomego, w czym najlepiej zrobić taki serwis pomyślałem „.. hmm no Java”. Zerknąłem do googlarki i … wielkie zdziwienie ;-) . Króluje oczywiście PHP (łatwy i brzydki język, masa gotowego kodu, tani jak barszcz hosting), poza tym Ruby. Czyli ogólnie języki typowane dynamiczne. Zastanawiałem się długo dlaczego tak jest i wyszło mi, że główne powody to: szybkość developmentu, koszty hostingu, łatwość znalezienia „kadry” (w naszym kraju dotyczy tylko PHP ;-) ). Java a w szczególności Java EE to ogromna platforma. Mimo iż piąta odłona korporacyjnej wersji wprowadziła wiele uproszczeń, pisanie małego lub średniego serwisu www w oparciu o tą platformę to jak strzelanie z armaty do muchy.
    I do tego miejsca właściwie się zgadzam, dodatkowo poczytam sobie chętnie przywołane przez Ciebie teksty. Punktem z którym muszę się niezgodzić jest wydajność. Piszesz o tym, że Tomcat potrzebuje dużo ramu a mod_python zdecydowanie mniej. Hmm.. mod_python moze i tak, ale jeżeli spojrzysz na to, musisz go opakować Apachem to sprawa wygląda inaczej. Nie jestem eksperem od wydajnośći serwerów www ale ludzie których za takich mogę uważać nie używają Apache’a, bo … jest zasobożerny i wolny. Moim zdaniem cała dyskusja jezyki dynamicznie typowane vs języki statycznie typowane jest zupełnie jak ta rozmowa o świętach (Boże Narodzenie vs Wielkanoc). Po stronie języków dynamicznie typowanych leży większa elastyczność, po stronie języków statycznie typowanych mamy wydajność (gratuluję każdemu kto napisze serwis www w assemblerze ;-) ). Ale większa elastyczność może (nie musi!) równać się większy bałagan i trudniejsze utrzymanie. A innej strony, język statycznie typowany jest językiem kompilowanym i jako taki stoi o krok przed językami interpretowanymi (niezależnie jak szybki interpreter mamy). Dlatego odpowiedź nie jest prosta, a wszystkim, którzy chcą się o tym przekonać jak trudne może być wiarygodne oszacowanie problemu wydajności, polecam: http://www.ibm.com/developerworks/java/library/j-jtp02225.html
    Kończąc dodam, że ciekawi mnie Wasz wybór, i chętnie dowiem się jakie są Wasze doświadczenia i przemyślenia z perspektywy czasu. Zdecydowanie się na coś z czym nie mieliśmy do czynienia jest nie lada wyzwaniem i przygodą zapewne :-) . Dlatego trzymam kciuki za sukces i kolejne wpisy dotyczące Waszej walki. Myślę, że to co jest najistotniejsze to , wybierać technologię świadomie, uciekając od przyzwyczajenia, mody czy czegokolwiek innego co nie ma nic wspólnego z tworzeniem wydajnych i elastycznych rozwiązań. Czego Wam i sobie życzę :-) . Pozdrawiam.

    15 listopada 2008, 17:30

  2. Lukasz says:

    Czy to nie jest tak, ze zawsze wychwalamy cos czego nie znamy? Zawsze wszystkim sie wydaje, ze na zachodzie jest lepiej, bo w Polsce kazdy juz wie jak jest. W naszym zespole znamy sie na Javie, PHP, a mimo to wybralismy Pythona. Cos o czym nie mamy zupelnie pojecia. :) W moim przypadku nie naciskalem na PHP, bo chetnie naucze sie czegos nowego. Wydaje sie, ze jest to swego rodzaju ‘przygoda’ i moglo to przewazyc nad decyzja Mikolaja. Bo moglibysmy zrobic to samo w PHP i z 10x szybciej. A to, ze PHP nie do konca obsluguje obiektowosc jak C++ no to co? Bez obiektowosci przynajmniej zyskalibysmy na wydajnosci. :) Koncowy efekt bylby taki sam. A co nas czeka z Pythonem tego jeszcze nie wiemy, okaze sie w praniu. Zatem czemu wybralismy Pythona, a nie np. PHP, skoro wydluzy nam to czas pracy nad projektem a prawdopodobny efekt bedzie taki sam? Przygoda, przygoda … ;)

    16 listopada 2008, 14:33

  3. Marcin Wojda says:

    Myślę, że chyba jednak trochę za wcześniej „skreślamy” języki statycznie typowane. To prawda, że statyczna kontrola z regułami typowania daje bardzo często złudne poczucie poprawności kodu programu, ale zaryzykuję tezę: w statycznym typowaniu statyczne typowanie wcale nie jest najważniejsze… ;-) Najważniejsze jest jawne określenie typów na poziomie interfejsu programistycznego (a cechę tą mają chyba tylko języki statycznie typowane, choć mogłaby występować również w językach o dynamicznych systemach typów).

    W przypadku większego systemu (kilka tysięcy klas) jawne określanie typu ułatwia poznawanie nieznanych fragmentów i chroni przed wątpliwościami typu czy pole Termin zawiera liczbę dni, czy datę graniczną. Typ pola w klasie trwałej to przecież nic innego jak element logiki biznesowej, z którego można korzystać na przykład przy tworzeniu interfejsu użytkownika. I tu wielki plus dla Django, że typy pól określane są na poziomie modelu w sposób jawny, i że framework potrafi z tych informacji skorzystać generując UI.

    Ponadto określanie typów pozwala na uniknięcie całej masy błędów, wobec których testy jednostkowe nie sprawdzają się najlepiej. Mam tu na myśli sytuację, w której funkcji zostanie przekazany parametr nieprawidłowego typu, bądź w polu obiektu pojawi się wartość innego typu niż spodziewany. Oczywiście możliwe jest dodanie kodu sprawdzającego parametry funkcji, czy też wartości przypisywane do pól obiektów, jednak oznacza to po części własną iterpretację funkcjonalnego odpowiednika statycznej kontroli typów. No ale w końcu DRY nie zakazuje powtarzania rozwiązań wymyślonych przez innych… ;-)

    Trzymam kciuki za powodzenie projektu!

    16 listopada 2008, 19:24

  4. Mikołaj Kmita says:

    Dzięki wszystkim za cenny feedback :)

    @Michał
    Oczywiście zgodzę się z Twoimi dodatkowymi kryteriami wyboru – co więcej zgodziłbym się jeszcze ze sporą ich ilością. Moim celem było opisanie naszych kryteriów… a tu na szczęście nie mamy żadnych specjalnych zewnętrznych ograniczeń – sky is the limit ;)
    Zgadzam się także, że Apache to pamięciożerne stworzenie, ale są alternatywy w postaci lighthttpd, nginx i nawet testy porównawcze ich wydajności – choć po lekturze linka, którego zapodałeś, do tego rodzaju testów podchodzę z jeszcze większą rezerwą niż dotychczas. Tym samym napisanie miarodajnych testów porównawczych Tomcat versus lighthttpd+fcgi+python nie wydaje się być trywialnym zadaniem… więc może poprzestańmy na stwierdzeniu, z którym się zgadzamy, tj. „szybkość developmentu” przemawiająca za językami typowanymi dynamicznie.

    @Lukasz
    Zgodzę się z tezą wychwalania tego czego jeszcze nie znamy, ale pozwolę sobie nie zgodzić się z częścią pozostałych tez.

    Być może napisalibyśmy to szybciej w czystym PHP-ie (ale IMHO nie byłyby to 10x, ani nawet 5x). Jednak problem jest gdzie indziej – pisanie w samym PHP-ie (czy też w JSP ze skrypletami sięgającymi bezpośrednio do bazy – co na początku też było nagminnie stosowane), bez użycia żadnego framework-a, który m.in. wymusi separację warstw, nie najlepiej się sprawdza, w momencie jak aplikacja zaczyna się rozrastać. Jej utrzymanie i dalszy rozwój stają się coraz bardziej kosztowne: próba zmiany struktury jakiejś tablicy może oznaczać konieczność przekopania dziesiątków plików, próba dołożenia jakiegoś standardowego sprawdzenia dla każdego żądania to samo, że o testach jednostkowych nie wspomnę… przykłady można by mnożyć.

    W związku z tym, uważam że warto ponieść koszt wdrożenia framework-a, bo w dłuższej perspektywie taka inwestycja się zwraca (no, chyba że mamy noc na napisanie programu na zaliczenie i nigdy więcej nie zamierzamy go oglądać ;) ) Stąd też w naszej sytuacji tak czy inaczej z jakimś framework-iem powinniśmy się zapoznać – więc dlaczego nie z Django/Python, które zdają się mieć zdrowe podstawy :)

    Co do przygody, to jak najbardziej masz rację… na pewno miało to swój wpływ na decyzję – ale cóż byłoby warte hobby/praca, ba życie, które nie jest jedną wielką przygodą (że pozwolę sobie na odrobinę filozofii :) )

    @Marcin
    Cóż… pozostaje mi się zgodzić z każdym zdaniem, które napisałeś, ale… ;)
    Przyjrzyjmy się aplikacją webowym, one nie mają tysięcy klas biznesowych… jeśli chodzi o logikę biznesową są one dużo prostsze od ich tak zwanych „korporacyjnych” odpowiedników.
    Jedyne więc co chciałem zasygnalizować, to fakt że w przypadku pisania pewnych (np. webowych) aplikacji języki typowane dynamicznie wydają się lepiej sprawdzać.

    Jeszcze raz dziękuję wszystkim za feedback – na pewno nie omieszkamy podzielić się naszymi przemyśleniami za jakiś czas, gdy nabierzemy więcej doświadczeń w tej materii…
    Zapraszamy więc do śledzenia dalszych losów naszej było, nie było przygody :)

    17 listopada 2008, 23:04

  5. Tomasz Borzyszkowski says:

    Tak sobie czytam ten wątek i:

    - Mikołaju fajna analiza, brak tendencyjności Javowej w ocenach:)

    - piszecie o doborze optymalnego narzędzia do wykonania/osadzenia serwisu; narzędzie zwykle dobiera się do parametrów zadania, które nie wynikają z kontekstu; Michał pisze o „armatach i muchach” – armaty przeanalizowane, tylko jaka jest ta mucha:)

    - co do wyboru Pythona i Django, to wydaje się niezłym zestawem do średniej wielkości serwisów; problemem może być znalezienie programistów „z doświadczeniem”, jeżeli projekt ma się rozwinąć aż tak; od jakiegoś czasu uczę Pythona na MFI ale pewnie na rynku lekkich rozwiązań wciąż królują „fachowcy” od PHP; oczywiście porównanie Pythona z PHP nie ma sensu … chociaż jako parametr analizy warto wziąć łatwość integracji z innymi rozwiązaniami

    - prócz doboru „armat”, trzeba jeszcze zrobić dobry projekt, niby oczywistość, ale widziałem już kilka projektów, które przestawały sobie radzić z własnym rozwojem; skutki opłakane choć rozciągnięte w czasie :(

    To tyle moich 3gr.
    Fajnej przygody z Pythonem.
    Będę trzymał kciuki, Tomek

    18 listopada 2008, 23:54

  6. Michał Orzechowski says:

    @Tomek
    Z tym „szacowaniem rozmiaru much” zawsze jest problem ;-) . Moim zdaniem sztuka w tym zeby dobrac optymalne narzedzie. I tym chyba własnie pisal Mikolaj – to chyba coś takiego co pozwala zmaksymalizować wydajność pracy, narzędzie które bardziej pomaga niż przeszkadza. Ale czesto to bardzo subiektywna ocena …

    26 listopada 2008, 10:19

  7. Mikołaj Kmita says:

    @Tomek, @Michał
    „Szacowanie rozmiaru much” zawsze jest dyskusyjne i stwierdzenie „średniej wielkości serwis” tak naprawdę dalej niewiele mówi ;)
    Na zagadnienie można by spojrzeć choćby z takich dwóch punktów:
    - poziom skomplikowania aplikacji – tylko jak to mierzyć? Ilością klas? Ilością kodu?
    - spodziewany ruch (ilość odwiedzin) – tu już można by się pokusić o podanie konkretnych liczb.

    Co do szukania programistów Python-owych, to mam nadzieję, że jak już do tego punktu dotrzemy, to współpraca z MFI pomoże nam zaadresować ten punkt :)

    Zgadzam się także, że w temacie tego rodzaju aplikacji web-owych królują „PHP-owcy” (w temacie hostingu zresztą też), ale część z nich zaczyna dostrzegać ograniczenia tego języka i rozglądając się za czymś dojrzalszym migrują w stronę Ruby lub właśnie Python-a.

    Tego typu ciekawych punktów do dyskusji jest mnóstwo – może za jakiś czas, jak uzbieramy bardziej pokaźny bagaż doświadczeń, porównać i przemyśleń pokusimy się o jakąś prezentację na SPIN-ie (bo na JUG-a to temat chyba nie specjalnie by się nadawał).

    A co do języków do tego rodzaju aplikacji, to wydaje się że duo: Groovy+Grails też byłoby warte bliższej analizy.

    7 grudnia 2008, 23:18

  8. Piotr Lewalski says:

    Witam,

    bardzo ładne podsumowanie.
    Z jednej strony jestem nieco zawiedziony, że trafiłem tu już w momencie kiedy ów wybór mam za sobą, z drugiej szalenie miłym zaskoczeniem był fakt, że zupełnie niezależnie, w rezultacie podobnej analizy dokonałem tego samego wyboru.

    To czego mi we wpisie zabrakło, to nieco większe rozwinięcie tematu frameworków. Wybór odpowiedniego bynajmniej nie jest to banalną sprawą, a tymczasem mam wrażenie, że autor po tak długim wpisie potraktował sprawę nieco po macoszemu.
    Może jest to potencjalny materiał na kolejny wpis? :)
    Jedno z podstawowe pytanie, przy frameworkach powinno IMHO dotyczyć ilości i przede wszystkim jakości wdrożeń o nie opartych. Nie na darmo mówi się, że lepiej uczyć się na cudzych błędach, a co za tym idzie raczej nie warto opierać projektu o rozwiązanie, które nie sprawdziło się jeszcze w produkcyjnych warunkach na dużą skalę.

    BTW Pod kryteriami dla których odpadł Perl podpisuję się z całym przekonaniem :-)

    Czekam na kolejne informacje z frontu :)

    6 kwietnia 2009, 21:20

Leave a Reply