Munkanélküli ... "webfejlesztő" vagyok.

Programozás

Java
1% (9 szavazat)
PHP
6% (45 szavazat)
.NET
0% (0 szavazat)
Python
1% (10 szavazat)
Ruby
1% (4 szavazat)
több területen is kimagaslóan képzett
2% (11 szavazat)
(közbevág) Rám nem igaz ez a mondat!
40% (279 szavazat)
Egyéb, leírom a hozzászólásokban
1% (8 szavazat)
Csak az eredmény érdekel
48% (340 szavazat)
Összes szavazat: 706

( trey | 2009. 11. 06., p – 07:47 )

(ha több is igaz kérlek a fő vonalat jelöld be)

--
trey @ gépház

( airween v | 2009. 11. 06., p – 09:16 )

Igazából nem értem a szavazás lényegét: felsorol 5 programozási nyelvet, amiben _LEHET_ webes alkalmazásokat is fejleszteni, és értelemszerűen lehet más alkalmazást is. A kérdést úgy teszi fel, hogy "webfejlesztő", de ha már web és fejlesztő, akkor imho egy "sitebuilder" vagy "front-end-developer" kategória simán elment volna. Látom hogy van egyéb, de szerintem ez nem egyéb... :)

Cégünkben ezidáiglen PHP volt a fő fejlesztési irány, és szeretnénk valami értelmesebb nyelvet, környezetet,... választani. Munkatársammal a Java irányába mozdulnánk el, de a vezetőség "rettegg" a Javatól, mert hogy nehéz fejlesztőt találni. Egy pillanatképet szeretnék kapni, hogy mely technológiából tudnánk a leghamarabb mondjuk egy embert leakasztani a szögröl :) Tudom, hoyg nem lesz egy HR-es reprezentatív kimutatás, de mégis érdekel.

Ezt nem is vitatom, és itt nem is a pénz volt a kérdés. de sajna PHP-val is az van, hogy nem találunk olyan programozót, akit a próbafeladat után be lehetne hívni személyes cseverészésre. Ebből a szűk mintavételezésből azt gondolnám, hogy igaza van a vezetőségnek, hogy ha valamirevaló PHP fejlesztőt sem találunk, pl. Java-ra még nehezebb lesz.

Valami ilyesmit akartam írni, hogy úgy egyébként általában az IT-n belül minden területen hiány van. PHP-ra talán több jelentkezőt találsz - itt a hangsúly a jelentkezőn van, nem a megfelelőn :(. A többinél szerintem sokkal rosszabb a helyzet, a Java/.Net még talán, de Ruby-t Mo-on nem tudom hol találsz hipp-hopp. Python meg szokott lenni itt is, legutóbb Django-hoz kerestek embert, úgy tudom nem sok eredménnyel.

Kicsit komplexebb OOP-s feladatok esetleg néhány design patternnel megtoldva. Elméleti jellegűek, de itt el lehet véreztetni a "PHP programozók" nagy részét.

Másik rész a security.

Harmadik az SQL. (Nem, SQL-l márpedig tudni kell. .NET-esek részéről se szimpi, hogy sokan mindent megtesznek, hogy még csak véletlenül se kelljen adatbázishoz nyúlni, ld. LinQ)

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

El kell szomoritsalak, a vilag a perzisztencia retegek fele halad, vagyis egyre kevesbe kell tudni SQL-ul, hogy weboldalt kapjon az ember. A Rails is elegge elment ebbe az iranyba, tesznek meg mindent azert, hogy minel kevesebb SQL query-t kelljen irni. PHP-ba is van ilyen mar (CakePHP pl.), Python, Java mindenkepp (foleg Java).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Design pattern... viccelsz?? Mi eddig el sem megyünk, már annak is örülnénk, ha az oop szemlélet megvolna, xssről, sqlinjectionről ne is beszéljek. Volt konkrátan jelentkező, akik php generator 5-be írta csinálta meg a feladatot (még a generált kommenteket is bennehgyta) :D A legjobb jelölt az utóbbi félévben egy AS programozó volt, őt felvettük, de sajna megmaradt a saját területén, de jobb php kódot ír a legtöbb php programozónál. Talán mert AS-ben vannak osztályok, és tudja, hogy azok mifélék egyáltalán.

Szerintem semmi baj nincs a hirdetéssel.

--
Viszont, ha szeretnéd, hogy jobb legyen, akkor kevesebb lufi több konkrétum.
Több éves fejlesztési tapasztalat PHP területén.
Az Nektek mennyi?

Nagy forgalmú site-ok fejlesztésében szerzett tapasztalat.
Szintén. Mi a nagy? Index.hu-t vagy facebook.com-ot kevesen kódolnak.

Önállóság, elhivatottság.
Ezt pedig el is felejtheted. Azért van nálad, mert kell neki a havi fix. Semmi többért. Többet csak Te szeretnél hinni. Nem lesz önálló, a kontrollnak kell jónak lennie. Nem lesz elhívatott, de nem is baj, ha nem tőled megy nyugdíjba.

De ezek már extrák! Így is jó a hirdetés. Én írnék bele egy bruttót is, ha nem annyira ismert a cégetek, ha ismert, akkor nem.

Ha monnyuk megelégedtek a nem tapasztalt, de jólképzett webprogramozókkal, akkor egy felsőfokú OKJ-s képzést végzett osztály fog most végezni, és azok jobbak mint a webalkalmazásfejlesztők, ez elvileg töbet ad -mármint a webprogramozó. És Én itt tanulok, és tudom hogy jó a webprog oktatás. Én még majd két évig vagyok itt, de mindenképp érdemes felkeresni a sulit, hogy tudnak-e ajánlani valakit, biztos ők is örülnek ha adiákjaik elhelyezkednek. Na meg ott vannak a szakgyak-osok, akiknek el kell menni egy céghez, ha azokat alkalmazzátok, akkor tanulás közben, iskolai rendszerben lehetne orientálni. Jobb mintha maga tenné. Szerintem egy próbát megér, legalább megérdeklődni.

Ha mar ilyen okosnak tetszik lenni, mi a kulonbseg a "webprogramozo" es a "webalkalmazasfejleszto" kozt? Nem mintha barmelyik ertelmes fogalom lenne, de ha mar hasznalod ezeket a szavakat, mondd el, mit jelentenek.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"ha az oop szemlélet megvolna"

Ez valahol a mai oktatás hibája is. Elmondják, hogy léteznek alap vezérlési szerkezetek, utána elmondják, hogy van OOP, de nem vagy nagyon kis részt tanítják meg használni azt. Ha még tudja is használni, akkor is hiányzik mögüle a szemlélet, igaz ebben szerintem benne van az is, hogy nincs összehasonlítási alapja a legtöbb hallgatónak, hogy miért is más szemlélet ez.

Ez után különféle néven nevezett órákon elmondják, hogy hogyan is kellene elméletben működnie egy projektnek, de az viszont a legtöbb helyen kimarad, hogy egyáltalán milyen módon is építsenek fel egy alkalmazást, meg hogy léteznek design patternek, stb. Amikor meg arról lenne szó, hogy talán akkor be kellene venni a tananyagba, "nincs rá idő".

És ugye az egyetemeknek/főiskoláknak elvileg a piac számára kellene munkaerőt képezni...

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

Pont az ellentétét tapasztalom. 2004-ben tanultam először OOP-t (SZTE-TTK PTM Programozás I. Java), azóta minden kötelező programomat OOP-vel írtam (kivéve azokat a nyelveket, amiben nem lehet). 1.5 éve használok Zend Frameworköt, Doctrine-t. Most meg a cégnél mit kezdenek nyomatni? Drupalt. Komolyan mondom, elvárják, hogy visszafejlődjek.

A Drupal is OOP, csak nem használja a PHP objektum szintaxisát, mert amikor a 6-ost csinálták, akkor még támogatnia kellett a 4-es PHP-t, és akkor sok dolgot nem lehetne ilyen szépen megoldani, ahogyan meg van. A 7-es Drupalban már elég sok API-t átírtak úgy, hogy használja a PHP 5.2 által nyújtott OOP-s elemek szintaxisát.

További információk az object-flavored programming kulcsszóra.

Haha, drupal :) Egyszer utaztam a vonaton, nem volt jobb dolgom, így belenéztem a drupal kódjába. Első dolog, ami eszembe jutott, hogy ez tök olyan, mintha OOP-zni akarna a nyelvi elemek nélkül.

Mondjuk vannak még hasonló vicces dolgok, pl Quake 2-ben láttam még hasonló "ez olyan, mintha OOP-zni akarna, de nem teszi" dolgokat. Vagy az SDL-ben az SDL_RWops tűnt még a stream-k újraimplementálásának.

Mondjuk, az OOP-vel annyi a bajom még, hogy oké, hogy elvárják, hogy ismerjem az elméleti alapokat, de pl. a "Programtervezési minták" című könyvet mindenkinek kötelezővé tenném, aki szoftvert fejleszt. Számomra (és még 1-2 ismerősnek) ott jött ki igazán az, hogy miért is tud szép lenni az OOP.

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

Nekem a PHP OOP megoldasat megnezve mindig az jut eszembe, hogy a bolha szeretne, ha elefantnak hinnek, de valamiert a szurke szin meg az ormany nem akar osszejonni sehogyan se. Mindig csak egy dog nagy bogar jon ki a vegen.

Eleve az taszito, hogy evek ota nem kepesek megoldani, hogy az include-olt fajlokat ne kelljen mar <?php taggel kezdeni bakker. A budos eletbe senki nem fog rahivni, aki megis, meg is erdemli.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Haha, ha csak ez lenne vele a legnagyobb baj :)

__autoload() -s gányolásról inkább ne beszéljünk. Tényleg jó, hogy van valami autoloader megoldás, de a gyakorlatban használhatatlan ez így komolyabb célra, normálisan.

Jobban örülnék, ha komolyabb projekteket le lehetne egyben fordítani egy állományba, ezzel megspórolva az __autoload() bohóckodást, és az örökös parseolást is. Tudom, eAccelerator, xcache, zend optimalizer és társai, de nem ugyanaz.

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

No, ezt eddig nem ismertem, de így a doksit végigfutva, azt látom, a lényeg, megint elkerülte a PHP fejlesztők figyelmét.

Én arról beszélek, hogy a már értelmezett, opcode-kat pakoljuk egy fájlba és úgy, hogy ha behívok egy class-t, includeolja be a neki szükséges fájlt, ne kézzel kelljen. Gyakorlatilag, mint egy Java .jar vagy egy .NET Assembly.

Persze, ehhez le kellene szoktatni az "ott gányolunk bele, ahol éppen jól esik" fejlesztőket erről-arról ;)

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

Ilyen valóban nincs (legalábbis nem tudok róla), de valószínűleg azért, mert a PHP egy interpretált nyelv, szkript nyelv. A Javat és .NET-et eleve máshogy tervezték. De javíts ki, ha tévedek. Opcode cache megoldásokkal pedig rengeteg teljesítménynövekedés tapasztalható, nem tudom mennyivel lenne gyorsabb, ha az opcode nem memóriában lenne, hanem fájlban és azt olvasná be a PHP.

Miert kellene megkulonboztetni? Rails-nal csak es kizarolagosan a template-nel kotelezo a <% %> enclosing, a sima modulkodnal nem. Ugyanez Django-ra, JSP-re, meg mittudomen meg mire. Nekem az a bajom, hogy a PHP-ban nincs olyan allapot, hogy ne kellene enclosing, hanem a PHP magatol tudna, hogy akkor ez most csak pure kod. Akar azert, mert nem php a kiterjesztes, hanem mondjuk inc.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Munkatársammal a Java irányába mozdulnánk el, de a vezetőség "rettegg" a Javatól, mert hogy nehéz fejlesztőt találni. "

Hát igen, hallottam én is olyat, hogy a "Java EE" szó bemondása azt jelenti, hogy 5 milliótol indul a projekt :-)
De amíg vannak cégek, akik így gondolják, és ki is fizetik, ez nem is baj.

Az, hogy egy projekt mennyibe kerül, még egyáltalán nem jellemzi annak profitabilitását. Igen, egy JEE projektet elindítani több meló, ezért többe is kerül, mint mondjuk egy PHP-st.
JEE projektekben sokkal nagyobb a rizikó is, sokkal többet láttam elbukni, mint más technológiával készülteket...
--
Gabriel Akos

A hozzászólásodból az jön le, hogy a bukás kb a technológiának köszönhető. Egyébként nem értek egyet veled abban, hogy "elindítani több meló" mert egy komplexeb rendszer esetén ígyis-úgyis meg kell tervezni, az ugyanannyi idő nagyjából java-ban és php-ban is. A szervert beállítani sem tart tovább. A kódolást lehet egálnak nevezni, mert ugyan a java "nyakatekertebb" viszont rengeteg kényelmi funkciót tartalmaz, a perzisztencia menedzseléstől a webszervizek építésén át sorohatnám. Kifejtenéd kérlek, hogy miben mutatkozik meg a több meló elindítani?

J2EE alatt én EJB-s dolgokat értek, bocsánat, ez így pontos. Az EJB 3.0 már az annotációkkal elég kényelmes, de pl. fejlesztettem 2.1-es EJB alatt projektet, ahol volt egy óriási konfigurációs XML (az architekteknek nem volt annyi esze hogy összerakassák buildkor darabokból) és a 30 fejlesztő mind azt basztatta. Folyton emiatt kellett debugolni. A gépek se voltak elég erősek önálló instance-ok futtatására... El lehet képzelni...

Én arra válaszoltam, hogy 5M alatt nincs ilyen projekt, amivel egyetértek. Sőt igazából 50M alatti projektnél is lebeszélném az ügyfelet. Mert a bonyolult technológia sok buktatót jelent, akár maintenance akár performance téren. Tisztességes szállító ezeket lepróbálja (pilot) mielőtt konkrét architektúrát választ. Normális architektet is nehezen kapsz havi 1M költség (nem nettó fizetés!) alatt. Három hónapnál rövidebb projektet nem csinálunk EJB-vel, ez már mindjárt 3M.

EJB-t oda választanak ahol nagy rendelkezésreállású rendszert akarnak, sok és sokféle tranzakcióval. Load balancer, cluster, etc. Itt a futtató hardverek is szokták verni a milliókat, különben nem érdemes. Szerinted ezt a környezetet triviális összerakni? Neki lehet menni mint vak boci az anyjának, neki is szoktak, de szerintem nem érdemes...

Licenszárakról csak azért nem beszélek, mert full open source alapon is össze lehet rakni EJB-s környezetet, bár bankokban nem ez a tipikus.

Persze találhatsz olyan projektet ahol a full-alap-konfigok is jók lesznek a végén, és mondjuk kijössz az 1-2M-s költségvetésedből pozitívra, de ugyanezt PHP-val egy esős délután összerakod. A user meg azért fog utálni mert sokkal nyűgösebb lesz bármi változtatás, meg bonyolultabb az üzemeltetés.

Persze akinek fent van a gépén az EE-s Eclipse, annak a "New EJB Project" az 2mp, ez igaz.

A Java semmivel nem nyakatekertebb mint a PHP, maximum a PHP-hoz szokottnak szokatlan. A rengeteg kényelmi szolgáltatást nyújtó mindenféle APIk meg libek meg mindenféle gyönyörű bugokat, inkompatibilitásokat tartalmaznak, amikkel akkor is szophatsz, ha se specifikációs, se algoritmikus hiba nincs a kódodban. És amikor azt hiszed, hogy mindent kivasaltál és elindítod az éles alkalmazásodat, akkor jönnek a userek és összedöntik egy félóra alatt, és akkor ismerkedhetsz a garbage collection rejtelmeivel, meg a különböző JVM bugokkal. Az adatbázisban addig fel-nem-fedezett lockolási szívásokról nem is beszélve.

Én maradnék annál amit mondtam: tomcat-spring-hibernate-struts2.
Ebben is van éppen elég marketing buzzword... :)

Ez egy sokmilliós tanács, és most ingyen kapod :P

--
Gabriel Akos

A PHP-val is jol el lehet szorakozni, foleg a misztikus hibak meg miszikusabb hibauzeneteinek ertelmenek a kitalalasaban. Stack trace altalaban nincs, jo esellyel fogalmad sincs, hogy valojaban mi futott zatonyra, csak talalgathatsz max.

Arrol nem beszelve hogy a PHP szerintem sem alkalmas egy intrawebes mindent-egybe CMS fejlesztesen tul, mert egyszeruen nem arra van kitalalva. Persze, lehet benne SOAP webszervizeket is fejleszteni ha nagyon muszaj, meg lehet mindenfele szines-szagos dolgokat csinalni benne - de amit nyersz a fejlesztesi koltsegeken, azt a karbantartason elveszted. Foleg ismerve a PHP fejlesztok agyondokumentalasi maniajat (ironia).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hát ezzel egyetértek, ezért nem soroltam a basic-et a listába :D de van sok olyan eset, hogy kb irreleváns, hogy milyen technológiával oldasz meg egy feladatot, hisz egy weboldal esetén mindegy hogy milyen nyelven íródott a cucc, ha szerver oldalon meg lehet hozzá teremteni a megfelelő környezetet. Legfeljebb erőforrás miatt nem mindegy, mert pl egy php megoldáshoz valszeg kevesebb erőforrás kell, mint javas társához, de javaban 3/4 annyi idő alatt megvan, és máris egál a dolog (természetesen leegyszerűsítve). Legalábbis eddig ez a tapasztalat.

Nagyobb rendszert nehezebb kódolni benne. PHP-ben könnyen el lehet gányolni a dolgokat, ha valaki nem figyel/szarik bele, ellenben egy OOP nyelvben sokkal gyorsabban visszaüt, ha valami nincs normálisan megtervezve.

Persze, lehet, kulturáltan, tervezetten, OOP-ül, többrétegű alkalmazást kódolni PHP-ben, csak ahhoz olyan emberek kellenek.

De akkor még mindig ott van az, hogy pl. komolyabb webservice-t hamarabb összekattintgatsz valami normálisabb IDE-ben, mint PHP-ben.

Egyébként meg csak úgy általánosságban: típusosság hiánya sokszor visszaütött már nálunk. Néha olyanok miatt szívunk, ami egy C#/Java alatt nem fordulhatott volna elő. Tény, hogy ezek általában tipikus elgépelések, de tegye fel az a kezét, aki x+n óra munka alatt egyszer nem gépel félre semmit.

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

Egészegyszerűen szeretnénk végre kultúrált környezetben dolgozni. És ne mondd, hogy a php egy kultúr nyelv, mert azt fogom hinni, hogy még sosem dolgoztál vele komolyabb projecteken :D Pl php esetén megtervezed a projectet (sokszor hiányos tervező eszközökkel), majd megvalósítasz olyan alap dolgokat, mint keretrendszer, adatbázisburkoló, stbstb, (tudom lehet letölteni, meg vannak mindenféle csodalibek) mindezt olyan IDE-n teszed, ami nem nyújt teljes támogatást a nyelvhez amivel dolgozol (Netbeans elégjó, de nem tud rendesen szinkronizálni, ha svn projected van, és azt meg ugye nem akarjuk, hogy a webszerver összeszemetelje a working copy-t, eclipse pdt / zendstudio, elég jó, bár gyakran nem parsol remndesen, és a kódkiegészítés sem megy minde esetben, includolt könyvtárakról ne is beszéljek viszont van hozzá mindenféle plugin, Komodo edit sajna szintén nem az igazi, a többi meg nem IDE kb ;)) az IDE max syntaxis elemzést tud, az egész fejlesztést olyan nyelven kell implementálni, ahol még azt se tudták megbeszélni a fejlesztőlk, hogy melyik parancs paraméter sorrendjét követi a másik, hanem ahány parancs annyi szokás, ahol oop szemlélet egy szálse, csak rá van erőltetve, de végülis csak a saját osztályaid osztályok, a többi primitív típusú funkcionális dolog. Ahol 1 normális profiler létezik (xdebug), de még jó hogy van. Hát nagyjából ez a baj a jelenlegi felállással. Nem magasztalni akarok itt semmit, és tudom mindennek megvannak a maga hátrányai meg előnyei, de rövid Javas pályafutásom alatt az utóbbi időben olyan dolgokat tapasztaltam az itt elhangzottakhoz képrest, amiről a phpsok még álmodni sem mernek.

Igazad van abban, amit írsz. A php one-man-show jellegű dolgokra alkalmas és hatékony.
A Javas környezetek sok szép dolgot adnak, de a lusta, buta programozók Javában is szart csinálnak. A jó programozó meg PHPban is tud szépet és jót csinálni, ez inkább szakmai igényesség kérdése.

Tapasztalatom az, hogy a PHPs programozók között több a gányolós lusta jószág, éspedig azért, mert alacsonyabb a léc amit meg kell ugrani, hogy valami működőt hozz össze, ezért a gyengébb képességűek/rosszabb hozzáállásúak is képesek valamire jutni.

--
Gabriel Akos

Értelmes nyelv szerintem:
- Objektum orientált, és nem csak lehet benne objektumokat csinálni
- Típusos, vagy legalábbis nem olyan furin csinálja a típuskényszerítéseket mint a php (nem tudod egy feltétellel leviszgálni, hogy egy változó int értéke 0, mert 0, vagy 0 mert nem értelmezhető intként, vagy volt már eset, hogy $x == "1" így ette csak meg a feltételt)
- A funciók paraméterezése valami tervezést sugall, nem ahogyesikúgypuffan
- Használ névtereket (tudom 5.3 használ de ott meg vannak kompatibilitás problémák, szóval van, hogy nem lehet hiba nélkül migrálni egy már megírt class-t)
- Az alapfunkciók is használnak kivételeket, hogy ne csak a saját kódjaimban tudjak kivételkezelést megvalósítani
- Nem változik meg a használat verzióról verzióra

Hát hirtelen ezek jutottak az eszembe.

Tudom, kicsit sok a reklambol, de itt is csak ajanlani tudom a Rails-t.
- A ruby objektum orientalt, class-ok, fuggvenyek, module-k (aka namespace) mindenfele'
- Gyengen tipusos, de a PHP-nal strict-ebb, pl kulonbseg van a 0 a "0" es a nil kozt.
- Mivel OOP, ezert alap, hogy jobban tervezettek a fuggvenyparameterek. Ketfele van, ami szimbolum-hasheket var, es ami normal parametereket. Illetve eleg sok olyan fuggveny is van, ami a ketto kevereket varja, de ott is teljesen logikus az elrendezes.
- Mint nevter olyan a ruby-ban igazabol nincsen, modulok meg osztalyok vannak, de a modulok tkp. nevterek, semmiben sem kulonboznek toluk.
- Mindenfele kivetelek vannak, begin, rescue, end a kivetelelkapas, van tovabbdobas is ugy tudom
- Megmarad a tamogatas a regi verziokhoz, bar erdemes lekovetni a valtozasokat. Aprobb dolgok szoktak eltorni 3-4 verzio tavolabol, amiben egyebkent igazuk is van, annyi ido azert eleg a valtashoz. Viszont a ruby gem taroloja lehetove teszi, hogy egy modulbol akar 5-6 verzio is fenn legyen, tehat irrelevans a verziovaltas, mert amig te az appodban azt nem mondod, hogy akkor most innentol nem 2.2.3 hanem 2.3.2 addig a ruby a regebbi rails gemet tolti be es ennyi. Ettol meg tudsz az uj rails ala fejleszteni.

Ami pluszt meg el lehet mondani rola
- Hihetetlen innovativ framework
- Borzaszto mod segiti a hasznalatot, mindent alad tol amit csak a szadon ki tudsz ejteni
- Amit nem tud az alaprendszer, azt egy plugin/gem megoldja
- A ruby nyelv merhetetlen dinamikussaga elkepeszto sokat tud segiteni.
- A rails alapjai legfeljebb 2-3 nap alatt elsajatithatok, ha dolgoztal mar valamilyen OOP programnyelvvel (de legalabbis lattal mar ilyent kozelrol). Es a tutorialok nem hazudnak, tenyleg 15 perc egy alap blogot letrehozni. Egy bonyolultabbat harom ejszaka. Loginnal, kommentekkel, formazassal, es tanulassal egyutt.
- Nem tudom mennyire relevans, de a regularis kifejezes motorjuk borzasztoan hasonlit a Perl-ehez, nagyon sok mindent tud.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A J2EE-vel tenyleg az a gond, hogy keves az olyan ember, aki igazan melysegeiben erti a Java-t, raadasul hostolni eroforrasigenyes sajnos. Kulonbseg van egy PHP/Rails app es egy Glassfish terhelese kozt.

Viszont, azok a kontenerek, amik J2EE-t ki tudnak szolgalni, ki tudnak Rails appokat is szolgalni a JRuby reven, szoval miert nem probaljatok ki egyszerre mindkettot? A webfelulethez mehetne a rails, a business logik meg mehetne j2ee-be.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

IMHO nagyon-nagyon kevés helyre, kis cégekhez meg egyáltalán nem kell full J2EE alkalmazás. Springgel, Hibernate-tel, Struts2-vel szépen meg lehet oldani a problémák nagy részét.
Ehhez meg egy tomcat is elég, ha fullosat akarsz, akkor jboss.
A mai alap szerverek is elvisznek közepes terhelésű Java alapú oldalakat simán.
Szarul megírt alkalmazás persze bármit megeszik, ilyen szempontból jobb a brutál terhelés, mert hamarabb összedől, ki kell javítani.

A glassfish meg egy fos.

--
Gabriel Akos

"Mi" nem volt, "en" volt, es igazabol mar nem nagyon emlexem (> 2 eve volt, sry), csak tudom, hogy amikor elkezdtem ismerkedni a JSP-k es a szervletek vilagaval, akkor legeslegeloszor tomcat-et telepitettem, es csak szivas volt vele, raadasul egyaltalan nem volt kezenfekvo a menedzselese, vegul ott is hagytam az egesz temat, mert nem volt kedvem veszodni vele. XML-t turkalni egy egyszeru jelszovaltasert... Brrrrrr. Ha jol emlexem, egy komplett hetvege kellett ahhoz, hogy egy ruhes netrol letoltott helloworld szervlet rendesen elinduljon alatta. Es nem a szervlet volt bugos.

Mostansag kezdtem el ujra ezt az egeszet, akkor mutatta meg NagyZ a GF-et valami okbol, es nekem egybol megtetszett, elkezdtem hasznalni, es most GF fan vagyok. Engem meggyozott a kezelhetosege, es amire kell, arra teljesen jo, nem futottam meg bele olyan problemaba, ami ne az en hulyesegem lett volna (pl. elfelejtettem a custom jelszot).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem a halado fejlesztonek is jol tud jonni, hogy egyszeruen telepitheto es menedzselheto. Olvastam a masik topikban a deploy problemakat, illetve nagy webappoknal biztos elojonnek mas problemak is, de szerintem a GF-nek megvan a maga helye. Egy kis ceges CMS-t biztos nem egy nagy kontener ala tennek. Raadasul szerintem eleg sok problema orvosolhato ha az ember idot szan arra, hogy megoldja.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Tényleg nem védeni akarom a PHP-t, a legtöbb esetben igazad van, csak észrevétel szinten:
- sok nyelvben fejleszthetsz pusztán tisztán funkcionálisan; a PHP a Perl-ből nőtt ki anno, ezen változtatni nehezen fognak, vagy ha fognak annak kompatibilitási ára lesz. IMHO (az általam ismert nyelvek közül) a Ruby-t tartom igazán objektumorientáltnak. Pl vö akár Java-ban: Math.abs(a) (asszem' így van :)) Ruby: a.abs() - nem elegánsabb? :)
- a pontos verzióra nem emlékszem, mikor került be, de a === operátor erre való...
tehát $x === 1, és ha nem csak értéket, hanem típust is vizsgál. Nem tudom mit értesz "furi" típuskényszerítésen, de működik a C-féle cast is: (int)$x == 1
- a 3. pontot nem értem, ez inkább - ahogy írod - tervezés kérdése
- lásd Perl származék
- lásd OOP alapvető hiánya
- ez van :)

A kötekedéseim ellenére megértem az aggályaidat, és kíváncsian várom mire juttok - esetleg a végeredményt oszd meg lcci. PHP fejlesztő több van, még azzal a megalkuvással is jobban jártok, hogy esetleg "kineveltek" magatoknak néhányat. Java és .Net esetében már nehezebb lesz embert találni, a többi (Python, Ruby) sajnos nem játszik.
És akkor még ott vannak a megrendelői igények: hiába írod oda követelménynek h Jboss/Rails/akármi, ha a megrendelő nem tudja majd üzemeltetni, mert nincs rá embere - de ez már másik szál imho...

Szerintem a Ruby-nál nagyon jól érzékelteti a fenti példa az OOP szemléletet. Az abszolút érték szerintem igenis egy objektumhoz köthető, már amire lehet értelmezni, pl. komplex szám, nem numerikus típus. A logaritmus meg egy függvény. Csak azt szeretném ezzel mondani, hogy amit egyértelműen az objektum típusával függ össze, az legyen metódus, nekem tetszik ez a megközelítés.
(de ezek részben szubjektív dolgok, nem nagyon akarok ezen sem lovagolni, sem vitázni :))

Az abszolut ertek az a valos szamok halmazan ertelmezett egy norma, ami egy bizonyos felteteleket teljesito fuggveny. Normat sokfelekeppen lehet definialni teren, igy aztan az abszolut ertek, mint olyan, nem kotheto objektumhoz, hasonloan a logaritmushoz. Az abszolut ertek is ugyanugy egy fuggveny, mint a logaritmusfuggveny.

ok, jogos, az abs() is fv - és a Ruby is fv-ként értelmezi, csak egy objektum metódusaként, nem pedig egy könyvtár egy függvényeként.
Ha sarkítani akarok, nagyon jól írtad az iskolai példát: abszolút érték jelölése: |a|, exp. fv jelölése: exp(a).
De ezen remélem nem veszünk össze, nekem ez jobban tetszik. :)

( lzrd | 2009. 11. 06., p – 09:41 )

Hivatalosan regisztrált álláskereső státuszban vagyok. Közben összerakok pár portált. PHP(néha drupal), MySQL, Apache2 estébé.
--
unix -- több, mint kód. filozófia.
Life is feudal

( btamax | 2009. 11. 06., p – 10:00 )

CGI programozók (perl(Catalyst)) kihaltak, vagy azoknak mindig van munkája?!?

nagyon off, de a Perl más területen is kezd visszaszorulni, talán nem véletlen: a fenti nyelvekkel összehasonlítva a Perl-ben lehet a legnagyobb kókánymunkát véghez vinni, és inkább ez nem divat mostanában :)
(akinek nem inge ne vegye magára, nem azt írom hogy minden Perl programozó úgy dolgozik)

( agolon | 2009. 11. 06., p – 11:05 )

A szavazás alakulás mutatja, hogy ennek nem sok értelme volt. Főleg nem a főoldalon.

( agolon | 2009. 11. 06., p – 11:35 )

Webfejlesztésben is ennyire vacak amúgy a helyzet? Pedig úgy nézem ilyen cégekkel Dunát lehet rekeszteni.

Ha egységnyi munkakínálatot (munka, mint megrendelés a cég felé) nézünk, akkor: több cég => nagyobb verseny => keservesebb küzdelem => az átlag cég szemszögéből nézve kevesebb lehetőség, ha be is jön, nincs belőle sok növekedés.

Ha feltételezzük, hogy azért sokasodnak a cégek, mert sok a munka, akkor úgy kellene legyen, ahogy írod.

De ha szűkülő munkakínálatot feltételezünk, akkor is biztos tud valaki magyarázatot kitalálni mondani arra, hogy miért szaporodnak a cégek.

"De ha szűkülő munkakínálatot feltételezünk, akkor is biztos tud valaki magyarázatot kitalálni mondani arra, hogy miért szaporodnak a cégek."

Mert most minden hülye a webfejlesztésre van ráizgulva, és nem érti, hogy neki nem web meg could computing kell, hanem desktop app, mert az használható is.

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

nálunk épp azt erőltetik hogy csak egyre több webes munka lesz mert mindent át fognak költöztetni browserekre

nem tudom hogy a tanár vesszőparipája, vagy tényleg így van, de normális példákat nem igazán mondott a dologra, csak kijelentette hogy x éven belül minden online módon browserben fog futni a játékoktól az office cuccokon át az utolsó biztonsági kamera vezérléséig

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Elég nagy bajnak tartom, hogy ez a trend. Üzleti döntésben még megértem, hogy ez tök jól hangzik, azonban aki fejlesztett már komplexebb rendszert, az tudja, hogy mennyivel rugalmasabban, szebben, jobban és gyorsabban lehet célrendszert fejleszteni, mint böngésző alattit. Gondolok itt például a web-startra.

Hidd el, mi is sipákolunk felfele, hogy nem webre kellene fejleszteni ügyviteli rendszereket (legalábbis nem mindent), de legfelülről meg az jön vissza, hogy ezt rendelték és a megrendelő szava szent. Ami egy felől igaz, másfelől nagyon nem. SZVSZ.

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

Ez valójában szerintem inkább így néz ki: a Sales-es eladja webre, mert az jól hangzik, hogy bárhonnan elérhető, ugyanúgy kezelhető...stb. Az meg már más dolog, hogy célrendszerrel is ugyanazt meg lehetne csinálni, de aki nem ért hozzá (management, sales), annak ezt nehéz elmagyarázni. Laikus annyit lát, hogy a böngészőhöz nem kell semmit telepíteni, pöccre megy. És az, hogy kétszer annyi idő alá fejleszteni, nehéz neki bizonyítani. :(

Mas oldalrol nezve viszont meg lehet erteni a tendenciat, mert mig az nincs biztositva, hogy az alkalmazas utanfejlesztes nelkul is el fog futni tiz ev mulva, amikor mar aki fejlesztette ceg sehol nincs, addig egy bongeszo alapu cucc sokkal nagyobb varhato elettartammal rendelkezik, hiszen a szerver rendszereket nem kell olyan gyorsan valtogatni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ja és némely böngésző szembef**sa a szabványokat. Még verziók közt se ugyanúgy viselkednek. Ebből mégis hogy lesz időtálló alkalmazás? :D Kijön egy új böngésző és máris borul minden. Míg egy webstartos megoldás vagy applet vagy mit tudom én az ugyanúgy fog futni mindig, ha jól írták meg.

Max. akkor lenne megoldás, ha JavaScript-re is lenne ilyen szabvány. Másrészt sajnos nem én határozom meg, milyen böngészőn kell működnie, hanem a megrendelő és itt bukott is a böngésző előnye szvsz. Persze ezen vitatkozhatnánk még, de felesleges. Én is értem, miért erőltetik, csak nem értek vele egyet.

Olyan biztos nem fog tortenni, hogy egy bongeszo hirtelen elkezdje nem tamogatni a HTML-t, oprendszerrel detto nem fog ilyen tortenni.
A felhasznalok elvarasaibol ketfele van: van ami kozvetlen a szoftver "magjahoz" kapcsolhato, es van ami a felulethez. A maghoz kapcsolodo elvarasokat desktop alkalmazasokon is vegig kellene verni, a felulethez kapcsolodoakat meg egyreszt szerintem html-ben konnyebb megcsinalni masreszt nem feltetlen kell minden "ez a label legyen innentol rubintpiros hatteru hupikek betukkel" tipusu igenyt rogton gondolkodas nelkul kielegiteni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( andrasf | 2009. 11. 07., szo – 02:44 )

és mi van, ha valaki webfejlesztő, nem pedig "webfejlesztő"?

Másik kedvenc kategóriám a mindenhez jobban értő SEO szagértő, akinek fogalma sincs, hogy hogyan épül fel egy rendszer, ellenben azt hiszi, hogy jobban tudja, hogy hogyan működik a google, mint a fejlesztői. Meg hogy nem fogja fel, hogy ameddig nincs normális tartalom, humbug az egész.

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

( nhw | 2009. 11. 09., h – 10:05 )

És aki munkavállaló az nem is szavazhat... :D

( Belanyil | 2009. 11. 10., k – 15:26 )

3.5 órája munkanélküli programfejlesztő vagyok !
Nekem nyolc évi meló, főnökségnek lóvé eltüntetés. :-/
Igaz, nem web, de azért igy is sz@r elhihetitek.

( vOrOn | 2009. 12. 21., h – 20:12 )

Több területen is kimagaslóan képzett!

Egyszer valami phassom nagy kozmetikai kenceszmog nyúlnyuvasztó cég qrva nagy managgajá kért tőlem, hogy aszondja - "legyen leendő oldalunk vidám, passzoljon színileg termékeink mindent lefedő palettájához, mozogjon minden rajta mint egy igazi meseországban és szóljon nem e világi zene! Jah, és szólítson meg mindenkit, 6 és 99 között!". Válaszom perceken belül készen vót, elvégre vérprofi lennék!

Vuála! A precíziós nanó hajtek pórfóliánsom legújabb gyöngyszeme! Ez kérem a Gyézájn, sőt maga a MŰVÉSZET!
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/