Váltás PHPról: Ruby vagy Python?
Sziasztok, jelenleg "full stack" webfejlesztőként dolgozom kábé 3 éve.
Szerver oldalon PHPt (különböző keretrendszerekkel) használok, és szeretnék váltani valami más nyelvre/keretrendszerre.
Több okom is van, elsősorban mert nagyon nem szeretem a PHPt mint nyelv, de nem szeretem a kultúrát (jobban mondva, annak hiányát) se, ami körülveszi. És sorolhatnám, aki benne van tudja.
Nagyon szeretnék vagy Rubyval vagy Pythonnal dolgozni (hobbiként játszadoztam mindkettővel), mert ahogy elnézem úgy nyelvi, mind kultúra szempontból szöges ellentétben állnak a PHPvel, ráadásul mindkét nyelvvel írtak komoly webes keretrendszereket is.
A tanulás része a legkönnyebb, lévén hogy mindkét nyelv könnyű, azonban a gondom az, hogy nem tudom melyikkel lenne érdemes foglalkoznom.
Ugyanis, Magyarországon egyik se valami népszerű (már a Indeed, Profession, Jobline és egyéb online álláshírdetős oldalakból ítélve) és félek, hogy ha nem jól választok, maroknyi állások után kell rohangáljak az ország különböző részeibe.
Szeretném ezért kérdezni, hogy tapasztalatotok szerint, melyik nyelv illetve a hozzá tartozó keretrendszerek (mint pl. a Rails, Sinatra, Django, Flask, web2py) elterjedtebb a magyar piacon?
■ Szerver oldalon PHPt (különböző keretrendszerekkel) használok, és szeretnék váltani valami más nyelvre/keretrendszerre.
Több okom is van, elsősorban mert nagyon nem szeretem a PHPt mint nyelv, de nem szeretem a kultúrát (jobban mondva, annak hiányát) se, ami körülveszi. És sorolhatnám, aki benne van tudja.
Nagyon szeretnék vagy Rubyval vagy Pythonnal dolgozni (hobbiként játszadoztam mindkettővel), mert ahogy elnézem úgy nyelvi, mind kultúra szempontból szöges ellentétben állnak a PHPvel, ráadásul mindkét nyelvvel írtak komoly webes keretrendszereket is.
A tanulás része a legkönnyebb, lévén hogy mindkét nyelv könnyű, azonban a gondom az, hogy nem tudom melyikkel lenne érdemes foglalkoznom.
Ugyanis, Magyarországon egyik se valami népszerű (már a Indeed, Profession, Jobline és egyéb online álláshírdetős oldalakból ítélve) és félek, hogy ha nem jól választok, maroknyi állások után kell rohangáljak az ország különböző részeibe.
Szeretném ezért kérdezni, hogy tapasztalatotok szerint, melyik nyelv illetve a hozzá tartozó keretrendszerek (mint pl. a Rails, Sinatra, Django, Flask, web2py) elterjedtebb a magyar piacon?
Megadtad a választ magadnak
Tudod: annyi embert érsz, ahány nyelven beszélsz. Talán a mi szakmánkban inkább számít a szint is, de alap- vagy középszintig érdemes, ha tényleg könnyen tanulod. Aztán amire nagyobb lesz az igény, azt komolyabban.
A PHP-nek azért sok hibája mellett van egy fontos előnye: rendkívül elterjedt. Nem véletlen, hogy olyan CMS-eket is PHP-ben fejlesztenek, mint a Drupal. És szerintem nem is fog túl sokat veszíteni népszerűségéből, mert olcsóbbak is jóval a PHP-s tárhelyek.
Akkor talán célszerű
Ezen én is gondolkoztam, de nem lehet szerintem mindkettőben (plusz keretrendszerekben) ugyanúgy elmélyülni. Ha csak nem programozok napi 16 órát ami kizárt.
Csak a magyar piac johet
Sajnos német tudásom csak pár
Egysült Királyság meg nagyon messze, én meg egyedül vagyok/mennék.
Nemetorszag+Ausztria elerheto
OFF
Az enyém is, és még hejjjesírni sem tudom:
Guten tag! "Cváj" beer bitte!
És jól is jönne, de a 22 már nem tudom hogy van...
de nem szeretem a kultúrát
Ha váltani szeretnél, akkor agyő, én inkább a pythont javasolnám, mert legtöbbször azzal találkoztam eddig.
Hát, én 3 év alatt egyetlen
Egyszóval, a PHP fejlesztés még mindig nem szoftver fejlesztés.
A TDD nem csodafegyver,
A TDD nem csodafegyver,
A TDD/BDD webfejlesztésre szerintem kitünő. Tény, hogy nem old meg mindent, de mindenképp megkönnyíti egy nagyobb projekt karbantartását.
Mert nem egyedül dolgozom egy projekten. Függök attól, amit más csinál, mert én is kell majd használjam esetleg tovább fejlesszem. S mivel nincs egy teszt keret, nagyobb projektek esetén már refaktorálás és kisebb módosítások is időigényesek a meg nem írt tesztek miatt.
Ráadásul a TDD/állandó tesztelés valamennyire lassúbb fejlesztéshez vezet, azonban sokkal jobb szoftvert eredményez. Fáraszt, hogy ezt mindegyre el kell magyarázni projekt managereknek.
Dependency hell pont a dependency management hiánya miatt lép fel. Ha csak persze nem ágyazol bele minden funkcionalitást/plugint/könyvtárat az alkalmazásodba.
TDD lassabb?
Erről egész oldalakat lehetne regélni, de elején biztos az az érzésed hogy lassabb, mert hát több sort kell leírni...de hosszútávon sokszorosan megtérül a befektetett munka
Tisztább kód, kevesebb bug...és nem utlsó sorban nyugodtan tudsz refaktorálni is :)
TDD hiánya
az hogy nem találkoztál vele,,,keresni kell, például mi TDD ben fejlesztünk PHPt (is).
Ez alapján úgy tűnik, te
+1
Mint mondtam, a PHP körüli
Symfony2
Nagyon sokan vagyunk úgy, hogyha nem jött volna a symfony2, már nem PHPznánk.
Nód?
Szvsz kis haszánkban már ma többet érsz vele, mint Pythonnal vagy Rubyval. Ha szerveroldalon nem is annyira eltejedt, az az előnye megvan, hogy közben a JS csinnyátbinnyát megtanulod, ami kliensoldalon még kb ezer évig használható lesz.
És persze ott vannak az
Én éppen ilyenbe ütköztem
De a Markdown nem szabvány, több kiegészítőt is gyártottak hozzá. Konverter bőségesen akad, de jól utánanézve többségük valamit picit másképp csinál mint a többi. (Beleértve az esetleges bugokat is.)
Ebben az esetben sokat segítene ha mindkét oldalon ugyanazt a konvertert használhatnám, hogy biztosan ugyanazt az előnézetet kapjam mint amilyen a végső formázás lesz.
Ok, ez most fontos számodra,
The V8JS Class, ha már tényleg nagyon erre van szükséged.
Több okból is
Egy lokalizáltabb példa a form validálás. Vannak szabványok persze ennek az egységesítésére, mint az XForms (ami leginkább XPath-t használ validálásra), de erre elég nehéz megbízható implementációkat találni kliens és szerveroldalra, meg nem túl elterjedt az eszköt (XPath) ismerete. - Ezzel szemben egy JS-ben írt form objektum, aminek a "validate()" metódusa meghívható bármely oldalon egy nagyságrenddel olcsóbb megoldás.
Egy általánosabb aspektus viszont a szabadabb kód-hordozhatóság kliens és szerver között. - Ha csupán kódért fodulunk a szerverhez (egy művelethez, amihez a kliensoldalon is elegendő információ áll rendelkezésre, csupán azért mert az illető algoritmus a szerveroldalra lett megírva) az megkérdőjelezhető módja a felhasználó erőforrásaival való gazdálkodásnak. (Nézte valaki a UPC regisztrációs formját mostanában?)
A projekt élete során tolódhat az a határ, amit kliensoldalon éri meg tárolni vagy inkább egy gyors HTTP kérés keretében hozzájutni. Tervezéskor nem is áll mindig rendelkezsére az egyes segédtáblák majdani mérete. Gyakran megtörténik, hogy ami megbeszélések idején 10-20 tagú listának (táblának) tűnik az valójában (amikor a megrendelő végre megkapja az ő megrendelőjétől) ezres nagyságrendű. Ilyenkor nem árt, ha rendelkezünk a flexiblitással egy gyors átcsoportosításra.
Sokmindent írhatnék még, de a mondandóm lényege, hogy egy új szabadságfokot kaphat így a rendszer, ami szinte minden aspektusban hordoz kisebbnagyobb előnyöket.
A formok validálása szerintem
Épp emiatt jelen pillanatban azon a véleményen vagyok, hogy egyszerűbb egyben, például AJAX segítségével elküldeni az űrlap adatait, és mindent a szerveroldalon ellenőrizni. Ha nincs fájlfeltöltés, akkor pedig párszáz bájtról beszélünk, amit küldözgetni kell, így mobilneten sem számít igazán.
Form
Az én értelmezésemben az, hogy "ez a usernév már foglalt" nem feltétlenül a form validáció része, tipikusan olyan dolgokra gonsolok, mint "az indulási időpont nem lehet később az érkezése időpontnál", vagy "felőtt síléc" csak 35-ös cipőmérettől van (viszont gyerek, mondjuk 15-től), ahol az adott adatstruktúra belső összefüggéseknek kell megfeleljen.
Őszintén kétlem, hogy a Node
Ezzel párhuzamosan vannak az kliens oldali MVC keretrendszerek (Angular, Ember) amik szintén nyernek teret külföldön, de itthon ha felhozod úgy néznek rád, mintha kínaiul beszélnél. Jelenleg fejlesztek egy oldalt Ember.js-el és szószerint egy hétig kellett győzködjem a felettesem, hogy ne jQueryből rakosgassuk össze az amúgy tiszta JS funkciókra támaszkodó oldalt.
meggyőzés
én most éppen Backbone nal fejlesztek, itt volt egy jQueryből összepakolós projekt ami elég okot adott rá hogy ne úgy csináljuk
Szerintem aki írt már 30-40
jQuery
Ugyan csak tutorialt
A másik ami engem szintén zavar, az olvashatóság, ami kb. a perl tömör változatáéval vetekszik, ha jól sejtem. :)
nincs vele gond
ha webalkalmazast irsz (pl. Gmail) onmagaban a jQuery nem ad strukturat a kodnak (ehhez kellenek mas frameworkok pl. Backbone), nem konnyiti meg a repetitiv dolgokat (pl. formok, eventek oda vissza bindelese stb), igy callback hegyekben kotsz ki
Alma vs körte
$('#id').on('click', /* ... */);
)A Backbone alapvetően alkalmazások írásához nyújt egy egységes, jól definiált felületet (modell, nézet, stb).
A baj olyankor van, amikor az ember nem arra próbálja használni a jQuery-t, amire való, és alkalmazást akar építeni vele.
+1
Probléma
Más rendszererek megismerése, használata pont ezen tudna javítani. Akik megragad a jQuery-nél, az nehezen fog tovább lépni, még akkor is, ha az általa fejlesztett alkalmazás igényli a továbblépést.
plugin
Lehet jól használni
A jQuery egyébként nem feltétlenül lassú, ha jól használja az ember, ismeri, hogy mit, hogyan és mikor szabad (itt pl. selector optimalizálásra gondolok).
A PHP védelmében
Több, mint fél éven át kerestem azt a nyelvet, amivel a cégünknél le tudnám váltani a PHP-t, így tanulmányoztam Scala-t, Ruby-t Rails-el, szerveroldali JS-t és egy kis Pythont is. Az eredmény az lett, hogy maradtunk a PHP-nél :) Persze ez nem azt jelenti, hogy a többi nyelv nem lett volna jó vagy jobb, viszont idővel kiderült, hogy a mi projektjeinkhez még mindig leginkább a PHP illik (sok kis projekt, egymástól függetlenül ugyanazon a szerveren futtatva, nagyon gyors releasekkel). Ráadásul ahogy egyre inkább belemélyedtem az új programozási módszertanokba, kezdtem máshogy látni a dolgokat.
A coding dojo-nkban és a CodeRetreateken gyakoroltam, illetve a saját szakállamra is kísérletezgettem a TDD-vel, és végül meggyőződtem arról, hogy marhára nem számít a programozási nyelv ahhoz, hogy jó kódot írjon az ember. A közösségi kódolásoknál kiderült, hogy az aktívan TDD-ző emberek jelentős része PHP-zik, a CodeRetreateken szerintem ezt a nyelvet választották a legtöbben, de a dojo-nkban sem volt még olyan, hogy ne lett volna PHP-s páros. Sőt. Én most úgy látom, hogy (főleg a kezdő TDD-seknek) a PHP egy kitűnő nyelv az EP módszereinek használatára/gyakorlására. Először is, szkriptnyelv lévén egyszerűbb/rugalmasabb, mint a Java - másrészt a TDD irodalma talán 90%-ban Java példákkal él, és mivel ehhez nagyon hasonló a PHP, így könnyen adaptálható a szakirodalomból szerzett tudás. Én párhuzamosan kísérletezem vele PHP-ben és JavaScriptben, és nem mondanám, hogy az utóbbiban annyival nehezebb, azonban mégis sokkal inkább át kell gondolni, hogy mit és hogyan csinálok. A nyelv stílusa más, mint a szakirodalomban olvasott, az átfordítása nem mindig egyértelmű. Engem egyébként meglepett, hogy az utóbbi időben mennyien TDD-znek itthon PHP-ben, lépten-nyomon ezt hallani.
A kérdésedre egyébként röviden válaszolva: én a Ruby-t ajánlanám (vagy a Scala-t!), mivel a Rails-hez szerintem ma már nem létezik olyan funkció, amit ne fejlesztett volna le valaki, ráadásul most jelent meg az új változat a nyelvből és a keretrendszerből is, ami egy rakás jó újdonságot hozott. Szerintem itthon azért elég keresettek a Ruby fejlesztők, itt Pécsen is ismerek egy-két céget ahol ezzel foglalkoznak, és persze ez hatványozottan igaz a fővárosra.