HOVD 2010 - Kedvenc web framework

HUP

cakephp
7% (24 szavazat)
catalyst
3% (10 szavazat)
cherrypy
1% (2 szavazat)
django
23% (76 szavazat)
dwr
1% (5 szavazat)
geddy
0% (0 szavazat)
ruby on rails
28% (94 szavazat)
symfony
11% (38 szavazat)
turbogears
0% (1 szavazat)
zend framework
26% (87 szavazat)
Összes szavazat: 337

( enpassant v | 2010. 12. 01., sze – 10:41 )

Elég szomorú a felhozatal.
Nem mondom, hogy ezek rosszak, de, ha 3-4 python és php framework ide tudott kerülni, akkor egy-két Javas nagyágyú is ide kerülhetett volna (a dwr-t nem nevezném annak).
Így sajnos én (és gondolom még jó páran) kimaradok(unk) ebből a szavazásból.

Mivel 24 óra van egy ilyenre, ezért sokan nem tudnak időben ezen részt venni. Sajnos én is így jártam.
Nagy forradalom tényleg nem volt, így jogos az észrevétel.

Ott egyébként Tyra3l hozzászólása azért elég markáns volt.

Ha már ott a Spring kapott 3 szavazatot, akkor én még adok plusz egyet.
Szívesen láttam volna még a felsoroltakon kívül ezeket: (ZK, AribaWeb, Wicket, GWT, Cocoon)

utolag visszanezve:

ki akartam szedni:
- cakephp -> bent maradt, de a php-s frameworkok kozul a legkevesebb szavazatot kapta, de az aranyaiban meg mindig jelentos.
- codeIgniter -> kikerult
- sinatraandroid -> kikerult
- turbogears -> bent maradt, 0 szavazat
- geddy -> bent maradt, 0 szavazat
- cherryPy -> bent maradt, 1 szavazat

amit be szerettem volna rakni
+ Grails -> nem kerult be
+ sinatra -> nem kerult be
+ Struts -> nem kerult be
+ Zend Framework -> bekerult
+ symfony -> bekerult
+ spring -> nem kerult be.

Igy a top10es listaban az alabbi nyelvek kepviseltetik magukat:

* PHP: 3 (cakephp, symfony, zend framework)
* python 2.5 (django, cherrypy, turbogears*)
* ruby 1 (ruby on rails)
* perl 1 (catalyst)
* java 1 (dwr)
* node.js 1 (geddy)

mint latszik a nyelvekre adott szavazatokbol:
http://hup.hu/szavazasok/20101201/hovd_2010_kedvenc_programnyelv

php 20% (128 szavazat)
java 18% (117 szavazat)
c++ 16% (101 szavazat)
c 13% (86 szavazat)
python 12% (80 szavazat)
perl 9% (57 szavazat)
c# 4% (28 szavazat)
ruby 3% (21 szavazat)
haskell, erlang, caml, ... (funkcionális nyelvek) 2% (15 szavazat)
javascript 2% (11 szavazat)

ha innen kiszorjuk azokat a nyelveket, amik nem voltak kepviselve a framework szavazason, akkor ez marad:

php 20% (128 szavazat)
java 18% (117 szavazat)
python 12% (80 szavazat)
perl 9% (57 szavazat)
ruby 3% (21 szavazat)
javascript 2% (11 szavazat)

- a php lett a legnepszerubb nyelv, szoval indokoltnak tunik, hogy harom frameworkkel indult az itteni szavazason.
- a java szorosan koveti, itt nagyon latvanyos szerintem, hogy a frameworkok versenyeben legalabb egy struts meg egy spring kellett volna...
- harmadik a python, az aranyok alapjan szerintem a django eleg lett volna neki, a tobbi nem kapott szavazatot
- negyedik a perl, itt szerintem latszik, hogy weben nem annyira nepszeru a nyelv, mint egyebkent, valoszinuleg ez a magyarazat arra, hogy a nyelvek kozti versenyhez kepest gyengebb itt a catalyst(es nem is hiszem, hogy a barmelyik masik perl framework felvetele a listaba jelentosen megvaltoztatta volna az eredmenyt)
- otodik a ruby, ami latszolag paradoxon, hiszen a rails vezeti a framework versenyt, bar ez szerintem nem meglepo, leven hogy a rails egy nagyon jol osszerakott eszkoz, nagyon nagy hype van korulotte, nagyon gyorsan fejlodik, illetve nincs annyi kozel egyforman nepszeru framework rubyban (meg a merbl is beolvadt/visszaolvadt a railsbe, Sinatra talan meg bekerulhetett volna, szerintem az is kapott volna szavazatot), mint mondjuk php-ban, nem annyira megosztott a kozosseg.
- hatodik a javascript, a 2%os eredmeny alapjan erdemes elgondolkozni, hogy erdemes volt-e a frameworkok koze berakni egy node.js eszkozt, mikor a javascript-ben fejlesztok nagy resze is inkabb kliens oldalon hasznalja a js-t, nem szerveren.

szoval szerintem a framework szavazasnak a java lett a legnagyobb vesztese, jelentosen modosult volna az eredmeny, ha bekerul 1-2 nev a nagyok kozul.

ps: a nyelvekkel allitott parhuzamnal figyelembe kell venni, hogy a script nyelvek kozol pl. a perl felul vannak reprezentalva a szavazasban, mivel a linux rendszergazdak kozul sokan hasznaljak ezt, viszont ok webre nem annyira fejlesztenek, ha megis, akkor nem jellemzo hogy OOP-s MVC frameworkoket kezdenenek tanulni, hanem spagettikodban osszedobnak valami monitoring feluletet. :)
szoval ennek is betudhato, hogy a perl tobb szavazatot kapott, mint amire a frameworkok kozott kiosztott szavazatok alapjan kovetkeztetni lehetne.

ps2: es az is latszik, hogy a django lefedi a pythonban webfejlesztok nagyreszet.

Tyrael

( saxus | 2010. 12. 01., sze – 11:24 )

Saját.

----------------
Lvl86 Troll

Arról bugreportoljak nekik hogy tessék újraírni az egészet? Arról hogy az eseménykezelést (hook-okat) talán nem kretén elnevezési konvenciókkal meg egy rakat function_exists() hívással kéne megoldani hanem épkézláb observer pattern implementációval? Esetleg arról hogy az aktuális felhasználót talán nem egy globális $user változóban kellene tárolni amit egy elbaszott modul bármikor null-ra állíthat? Vagy arról, hogy a 4000 soros procedurális index.php-nél valami kulturáltabb formát is adhatnának a bootstrap-nek?

Hagyjuk már. Tőből el van baszva az egész rendszer. Nem érdekel hogy mennyit tud és az se, hogy hányan használják. Ez nem komoly platform. Ez gányolás.

Mikor néztél bele utoljára a kódjába és az általa követett elvekbe? Megnézted, hogy az adott dolgok miért pont úgy vannak benne, ahogy? Vagy csak egyszerűen neked így nem tetszik, ami ettől kezdve egy erősen szubjektív dolog?

De mondjuk ha még ott tartasz, hogy a Drupal "csak" CMS, akkor nem valószínű, hogy túl mély rálátásod van.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

1,5 éve néztem utoljára és nem hiszem hogy a közeljövőben újra megnézem. Jó, biztos kéne, meg biztos csak akkor mondhatnék véleményt ha ismerném a legutóbbi stable-t töviről hegyire, csak az a baj, hogy azoknak a technológiákból sem tudok mindig up-to-date lenni, amiket használok melóhoz. Azokét se, amik érdekelnének, vagy rajta vannak a "meg kéne nézni" listán.

Ettől függetlenül nem hiszem, hogy ennyi idő alatt a nagyon szarból nagyjából jót csináltak volna.

Igenis lehet issue-t küldeni róla, hogy nem jó a hook_rendszer.
Megcsinálod az observer pattern-t, feltöltöd patchként, leméred a teljesítményt, megmutatod 3 sor kódon, hogy nem macera használni és úgy lesz benn a Drupal 8-ban. A Fehér Ház meg az összes zenei kiadó (a kedvenc zenészed) is te kódodat fogja használni ;)

Azért 22 évesen (nickből sejtem) már ennél messzebbre is láthatnál, mint hogy procedurális meg gányolás. Hát kit érdekel? A kérdés az, hogy mennyi erőfeszítésbe azaz pénzbe kerül egy biztonságos, skálázható, karbantartható, használható website-ot megcsinálni. Jelenleg a világ egyre nagyobb része úgy véli hogy a Drupal erre a leginkább költséghatékony eszköz. Hogy ez PHP-ban van írva az majdnem lényegtelen (lehet néhány cég akik PHP-t nem akarnak futtatni) de az hogy milyen OOP van benne, nos azt döntéshozói szinten senkit nem érdekel.

Jelenleg a világ egyre nagyobb része úgy véli hogy a Drupal erre a leginkább költséghatékony eszköz.

Tapasztalataim szerint a php fejlesztők egyik fele isteníti a drupalt, másik fele szerint nem való alkalmazásfejlesztésre.

Az "egyre nagyobb része" kijelentéssel kapcsolatban pedig nagyon remélem hogy nem így van, ezzel kapcsolatban érdemes ezt elolvasni. A dzone szerintem elég jelentős portál ahhoz, hogy reprezentatívnak tekinthessük a felmérést.

Sikerült linkelned egy olyan komoly cikket amiben még a kérdés sem volt benne :) Ráadásul semmit nem értettél meg abból amit írtam ha egy developer portalt linkelsz... megpróbálom máshogy: az hogy Te utálod a procedurális kódot meg a Drupalt az a Te zsebedre megy mert a Drupal kóderek most sok pénzt tudnak keresni és nincs gondjuk a munkakereséssel.

Ps. a dzone.com is Drupal :D

Vegulis a szavazas nem koti ki, hogy alkalmazasframeworkrol beszelunk-e. A CMS mint fogalom felfoghato egyfajta frameworkkent. Tudom, hogy a megfogalmazas moge bujtatom a dolgot, de... nem tudnam megmagyarazni, valamiert ugy erzem, elfer itt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

elnevezesi konvenciok: convention over configuration tervezesi mintarol mar hallottal? eppen az a trend, hogy minden ket soros valtoztatasert ne kelljen mar letrehozni egy subclasst, es aztan valahol kulon regisztralni meg egy esemenykezeloben... nem tul praktikus.

globalis $user: errol eppen folyik a diskurzus (lasd butler csoport), hogy nem igy kellene. A jovoben (Drupal 8 valoszinu) valtozni fog (csak ez nem olyan egyszeru, mint amilyennek elsore latszik).

az index.php az 22 sor jelenleg (Drupal 7 RC1). A bootstrap.inc az 3000 sor felett van, de szet van szedve nem tul nagy fuggvenyekre.

proceduralissag: a Drupal vegyes paradigmaju rendszer. Hasznal OOP elemeket, de nem sokszor hasznalja fel a PHP nyelvi elemeit (fokent a 6-os verzio). Ennek az az oka, hogy a Drupal 6-nak kompatibilisnek kellett maradnia a PHP 4-gyel (a kozosseg igenye volt, mert akkor, amikor kijott meg nagyon sok hosting nem valtott PHP 5-re), es csak bonyolitottak volna a kodot, ha a PHP 4 OOP szintaktikajat hasznaljak. Drupal 7-nel meg nem volt arra kapacitas, hogy varazsszora rajojjenek, hogy hol eri meg OOP szintaxist hasznalni, es mindent atdolgozzanak. Ahol nagyon kellett, ott megtettek, es hamarosan kiadjak. Egy csomo ember elkezdi hasznalni, varhatoan lesznek jo otleteik, aztan rajovunk kozosen, hogy mit kell meg gyurni ahhoz, hogy jobbak legyunk. Nem lesz esz nelkul agyonoopsitve az egesz (abstract class abstract class hatan). Vannak olyan rendszerek (theme rendszer), amit csak nagysagrendekkel rondabban es lassabban lehetne OOP-re atvinni. Van olyan, ami bar nagyon OOP-nek latszik, de valahogy nem akar idomulni a PHP OOP rendszerere (Form API). A fo csapasvonal jelenleg a hard dependency-k csokkentese, ezzel a flexibilitas tovabbi novelese, es a tesztelhetoseg javitasa. Itt is vigyazni kell, mert ha mozdulunk egy iranyba, azzal sertunk egy masikat, tehat at kell gondolni.
Olvasnivalo:
http://www.garfieldtech.com/blog/architectural-priorities
http://www.garfieldtech.com/blog/language-tradeoffs

Viszont ezek nem annyira egeto gondok. A legtobb webes technologiat a Drupal tamogatja elsokent (RDFa pl), biztonsag tekinteteben sincs szegyellnivalonk, contrib modulok szamaban es minosegeben vezeto CMS vagyunk. Skalazhatosagban folyamatosan javul a Drupal, hatalmas oldalakat is vigan kiszolgal. Szamos olyan technologiank van (Fields, regebbi neven CCK, vagy eppen a Views), amik komoly elonyt jelentenek mas CMS-ekkel vagy frameworkokkel szemben. SEO-rol mar nem is beszelve. A parancssor szerelmeseinek pedig ott a drush, amivel egy csomo dolgot lehet automatizalni.

Amikor egy komoly helyre valasztanak platformot, akkor nem csak azt nezik, hogy hany abstract class van benne, hanem a fenti szempontokat is figyelembe veszik. Kisebb helyeken pedig olyan aprosagok dontenek, hogy fields+views segitsegevel pillanatok alatt ossze lehet pakolni egy kozepes oldalt, akarmilyen csicsas adatprezentacioval. Ebbol a features modul segitsegevel 2 klikk modult gyartani, tehat verziozhato is nagyjabol rendesen. Ha mar jo akar lenni a ceg, akkor ir egy install profile-t hozza, aztan aegir-rel akar tobb szaz site-ot is deployolhat vele.

tyű de sokat írtál :)

convention over configuration fogalom megvan de én struts-cal kapcsolatban olvastam róla és ott erősen mást jelentett (azaz mindennek jó defaultot adunk hogy gyorsan lehessen fejleszteni, de mindent át lehet konfigolni szükség esetén, így megmarad a flexibilitás is)

global $user: örülök neki, csak ha nem most diskurálnának róla hanem 4 éve tették volna akkor jobban örülnék

contrib modulok szamaban es minosegeben vezeto CMS vagyunk

a mennyiséget elhiszem, a minőséggel kapcsolatban én erősen más véleményt szoktam hallani de most nem fogok nekiállni forráskódokat turkálni úgyhogy hagyjuk

http://www.joelonsoftware.com/articles/fog0000000069.html

We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds.

...

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

http://www.girldeveloper.com/2010/07/your-code-sucks.html

So, when I hear that someone has looked at someone else's code base and determined that it sucked I smile and remember what it was like to be so new and sure of myself. So sure that I was an amazing developer, and that I knew what was best in every problematic situation. I miss that swagger, but I appreciate what I have learned, and that is the only person's code that sucks is my own, and the reason why it sucks is I just haven't learned how to make it better yet.

szoval szerintem konnyu talalni egy akkora rendszerben, mint a drupal szuboptimalis megoldasokat, viszont jobbat csinalni altalaban pont azok nem tudnanak, akik osztjak az eszt. :)
de azt el kell ismerni, hogy mind a wordpress(azt a kodbazist lattad mar? borzaszto.), mind a drupal el tudta erni azt, hogy a sajat teruleten piacvezeto legyen, ami azert nem kis szo, es ezt gondolkodas nelkul lesoporni az asztalrol olyan indokokkal, hogy nincs benne Event Observer pattern olyan formaban alkalmazva, ahogy te a Fowler fele konyvekben olvastad (ahol persze kulon ki van emelve, hogy a patternek nem kulcsrakeszek, es amugy is neked kell eldontened, hogy hova melyik a megfelelo) az szerintem kicsit ciki.

Tyrael

( crystal88 | 2010. 12. 01., sze – 16:42 )

még mindig kohana :P amúgy tényleg össze lehetett volna szedni, nem hiszem h a javaslatok alapján ez volt a top10

( suti | 2010. 12. 01., sze – 19:14 )

GWT? ez meg hova lett?

_______
16,67 %

( felyx | 2010. 12. 01., sze – 19:58 )

CodeIgniter? Yii? Ez a lista így eléggé vérszegény.

( ssikiss | 2010. 12. 01., sze – 20:52 )

Jelentkezzen a másik Catalyst rajongó! :)

( Tyra3l | 2010. 12. 01., sze – 22:29 )

nem ertem hogy jott ossze ez a tizes lista. :/

Tyrael

( lazly | 2010. 12. 04., szo – 13:48 )

Drupal miert nincs itt? :( :( Tudom, sokan csak CMkent tekintenek ra, akik meg nem neztek meg jobban mi hogy mukodik benne es mit hogy lehet atvarialni. Ha cakephp framework akkor a drupal is az. :(

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

( keriati | 2010. 12. 04., szo – 13:57 )

Codeigniter hiányzik a listáról, és arra szavazok.