ugrás a tartalomhoz

Váltás PHPról: Ruby vagy Python?

ors · 2013. Júl. 29. (H), 02.15
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?
 
1

Megadtad a választ magadnak

Pepita · 2013. Júl. 29. (H), 02.51
A tanulás része a legkönnyebb, lévén hogy mindkét nyelv könnyű
Akkor talán célszerű mindkettőt alaposan kitanulni, néhány ráépülő keretrendszerrel együtt.

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.
8

Akkor talán célszerű

ors · 2013. Júl. 29. (H), 11.15
Akkor talán célszerű mindkettőt alaposan kitanulni, néhány ráépülő keretrendszerrel együtt.


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.
2

Csak a magyar piac johet

Greg · 2013. Júl. 29. (H), 07.43
Csak a magyar piac johet szoba? Nemetorszag, Ausztria eleg kozel van es mindket helyen keresett a Ruby es Python is amennyire en tudom.
9

Sajnos német tudásom csak pár

ors · 2013. Júl. 29. (H), 11.19
Sajnos német tudásom csak pár szó erejéig terjed. Ha neki is fogok tanulni, egy év alatt nem leszek olyan szinten, hogy egy irodai társalgást le tudjak folytatni.

Egysült Királyság meg nagyon messze, én meg egyedül vagyok/mennék.
16

Nemetorszag+Ausztria elerheto

Greg · 2013. Júl. 29. (H), 14.27
Nemetorszag+Ausztria elerheto angol nyelvtudassal is. Esetleg meg Hollandia, ami szinten nincs annyira messze.
22

OFF

Pepita · 2013. Júl. 30. (K), 04.21
Sajnos német tudásom csak pár szó erejéig terjed.

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...
3

de nem szeretem a kultúrát

Hidvégi Gábor · 2013. Júl. 29. (H), 09.55
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.
Én benne vagyok nap mint nap, de nem különösebben érint a dolog. Bár szerencsésnek mondhatom magam, hogy mindent mi fejlesztünk, nem vagyunk rászorulva másokra, láttam már nem egy minőségi PHP keretrendszert és programot, mert azért van választék, nagyon nagy a támogatottsága, és semmi sem akadályoz meg benne, hogy jó szoftvert adj ki a kezed közül. Így nem igazán értem, mi a bajod a kultúrával, ha másra akarsz támaszkodni, alacsony színvonalat más nyelvekben is lehet találni ugyanúgy.

Ha váltani szeretnél, akkor agyő, én inkább a pythont javasolnám, mert legtöbbször azzal találkoztam eddig.
10

Hát, én 3 év alatt egyetlen

ors · 2013. Júl. 29. (H), 11.27
Hát, én 3 év alatt egyetlen egy projektet se láttam ami TDDvel volt fejlesztve (vagy volt unit tesztelve egyáltalán) más tesztekről nem is beszélve. Az emberek ezen kívűl nem ismerik a tervezési mintákat, nem tudják, hogy kell DRY kódot írni valamint nagyon elterjedt a "not invented here" szindróma. PHPnál csak most kezd elterjedni a dependency management fogalma stb.

Egyszóval, a PHP fejlesztés még mindig nem szoftver fejlesztés.
13

A TDD nem csodafegyver,

Hidvégi Gábor · 2013. Júl. 29. (H), 11.45
A TDD nem csodafegyver, anélkül is lehet jót alkotni, ráadásul nem is jó mindenre. Ki akadályoz meg benne, hogy a saját kódodban használd? Viszont továbbra sem értem, miért teszed magad függővé másoktól, a dependency managementről a dependency hell jut eszembe. Minél több minden(ki)re támaszkodsz, annál kiszolgáltatottabb vagy.
14

A TDD nem csodafegyver,

ors · 2013. Júl. 29. (H), 13.10
A TDD nem csodafegyver, anélkül is lehet jót alkotni, ráadásul nem is jó mindenre


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.

Viszont továbbra sem értem, miért teszed magad függővé másoktól

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 managementről a dependency hell jut eszembe


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.
19

TDD lassabb?

blacksonic · 2013. Júl. 29. (H), 14.34
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.

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 :)
18

TDD hiánya

blacksonic · 2013. Júl. 29. (H), 14.31
nálunk nincs annyira elterjedve, de külfödlön elég sok PHPst keresnek TDD BDD tapasztalattal
az hogy nem találkoztál vele,,,keresni kell, például mi TDD ben fejlesztünk PHPt (is).
21

Ez alapján úgy tűnik, te

tgr · 2013. Júl. 29. (H), 18.40
Ez alapján úgy tűnik, te igazából munkahelyet szeretnél váltani, nem nyelvet.
23

+1

Pepita · 2013. Júl. 30. (K), 04.25
Azért a kettő nem zárja ki egymást...
24

Mint mondtam, a PHP körüli

ors · 2013. Júl. 31. (Sze), 13.13
Mint mondtam, a PHP körüli kultúra csak az egyik ami zavar, maga a nyelv is förtelmes.
4

Symfony2

Práger Ádám · 2013. Júl. 29. (H), 09.58
Ha van pár szabad napod próbáld ki a smyfony-t. A PHP-t is lehet profin csinálni, és közösség/kultúra is nagyon jó :)

Nagyon sokan vagyunk úgy, hogyha nem jött volna a symfony2, már nem PHPznánk.
5

Nód?

vbence · 2013. Júl. 29. (H), 09.59
A szerveroldali JavaScript is népszerűsödik mostanában. Egyre többet hallani NodeJSben készült projektekről. Ehhez például nagyon logikusan kapcsolódhat egy MongoDB (persze nem leváltani az SQL adatbázist, hanem kegészíteni). - És persze ott vannak az előnyei, hogy ugyanazt a neyelvet beszéli a szerver és a kliensoldal.

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.
6

És persze ott vannak az

Hidvégi Gábor · 2013. Júl. 29. (H), 10.51
És persze ott vannak az előnyei, hogy ugyanazt a neyelvet beszéli a szerver és a kliensoldal
Ezt az érvelést sosem értettem, mivel a két réteg fizikailag elkülönül, minimális vagy nincs kódszinten átjárás. Innentől kezdve teljesen mindegy, mi megy szerveroldalon, nem? Csak azért kérdem, mert sokan kritizálják a javascriptet mint nyelvet úgy, hogy más nyelvekből vonnak be szintaktikát (.extend() függvények) vagy más nyelvből fordítanak js-be (pl. coffeescript és növekvő számú társai).
7

Én éppen ilyenbe ütköztem

kuka · 2013. Júl. 29. (H), 11.01
Én éppen ilyenbe ütköztem bele: írok egy kis alkalmatosságot ahol a formázást Markdownra bíznám. De 1) szeretnék élő előnézetet az éppen készülő hozzászólásról – ehhez a betűnkénti AJAX elkerülése végett JavaScriptet használnék; 2) a régebbi hozzászólásokat a lapokba már HTML formázással szúrnám be – ehhez pedig PHP-t használnék.

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.
12

Ok, ez most fontos számodra,

Hidvégi Gábor · 2013. Júl. 29. (H), 11.39
Ok, ez most fontos számodra, de azért összességében nem túl nyomós érv.

The V8JS Class, ha már tényleg nagyon erre van szükséged.
15

Több okból is

vbence · 2013. Júl. 29. (H), 13.53
Ahogy az előttem szóló említette ott vannak az alkalmazáslogikához kapcsolódó algoritmusok. Képzeljünk el egy getter metódust, ami több más mezőből számol ki egy értéket. Ezt a logikát karbantarthatóan kezelni a kliensen és szerveren nem könnyű, hibalehetőségeket hordoz és nyilvánvalóan duplikáljuk a ráfordítást. (Egy élő projektben gyakran átdefiniálódnak ezek a fogalmak/kategóriák).

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.
17

A formok validálása szerintem

Hidvégi Gábor · 2013. Júl. 29. (H), 14.28
A formok validálása szerintem nem a legjobb példa, mert nem igazán lehet jó megoldást írni rá. A kliensoldalon csak korlátozottan lehet bármit is csinálni (legfeljebb annyit és olyan szinten tudsz megállapítani, hogy a kapott adat megfelel-e egy formulának, de minden ennél bonyolultabb esetben már adatbázishoz kell fordulni), így nagyon kevés az igazi átfedés, vagy pedig a közös kódba mindenhol bele kell írni, hogy "ez az ellenőrzés nem futhat kliensen"; most akkor egyszerűbb lesz a kód vagy sem?

É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.
20

Form

vbence · 2013. Júl. 29. (H), 15.17
Nem feltétlenül ezt a példát szántam a legfontosabb mondanivalónak.

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.
11

Őszintén kétlem, hogy a Node

ors · 2013. Júl. 29. (H), 11.34
Őszintén kétlem, hogy a Node elterjedtebb, mint egy Rails/Django, elsősorban, mert nagyon korlátozott dologra igazán jó (real time applikációk), másodsorban nagyon fiatal az ökoszisztéma és nagyon sokszor te kell megírj mindent.

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.
26

meggyőzés

blacksonic · 2013. Aug. 1. (Cs), 13.59
és végül mivel győzted meg?
é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
27

Szerintem aki írt már 30-40

MadBence · 2013. Aug. 1. (Cs), 16.47
Szerintem aki írt már 30-40 sornál hosszabb jQuery kódot, azt egész könnyen meg lehet győzni :)
28

jQuery

Hidvégi Gábor · 2013. Aug. 1. (Cs), 18.53
Miért, pontosan mi a probléma a jQueryvel? Tényleg kíváncsi vagyok rá, mert eddig talán egyszer használtam (azóta azért nem, mert jobban szeretem az olyan kódot, ahol pontosan tudom, mi történik, az ilyen rendszerek számomra fekete dobozok).
29

Ugyan csak tutorialt

H.Z. · 2013. Aug. 1. (Cs), 19.01
Ugyan csak tutorialt böngésztem, de számomra többek közt ez volt az egyik zavaró tényező: a javascriptet csak egy a html dinamikusabbá tételére kitalált eszköznek tartom, ezért nem érzem jó ötletnek, ha "feketedoboz" van az oldalban.
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. :)
30

nincs vele gond

blacksonic · 2013. Aug. 1. (Cs), 21.32
a jQuery arra amire kitalaltak nagyon jo, de csak egy tool, ami segiti a munkadat
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
31

Alma vs körte

MadBence · 2013. Aug. 1. (Cs), 21.52
A jQuery vs Backbone eléggé értelmetlen összehasonlítás, hiszen teljesen más dologra valók :). A jQuery a különböző böngészők tetejére ráépülve nyújt egy egységes API-t a DOM-hoz. Ennyit tud. Aminek a 80%-t mellesleg az ~1 évnél fiatalabb böngészők natívan tudnak már. A maradék 20%-t pedig senki sem használja :) (most őszintén, 90%-ban az ember ezt a formulát ismételgeti csak: $('#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.
32

+1

bamegakapa · 2013. Aug. 2. (P), 09.58
Leírta a lényeget. Ha valaki csavarhúzóval veri be a szöget, az továbbra sem a csavarhúzó hibája. Igazából nincs is olyan, hogy valaki jQuery kódot ír, a jQuery egy egyszerű függvénykönytár. Amiről itt szó van, az inkább spagettikód Javascriptben, a jQuerynek ehhez semmi köze.
33

Probléma

Poetro · 2013. Aug. 2. (P), 10.33
A probléma az, hogy a jQuery nagy, lassú, és nem ad semmiféle szemléletet. Vagyis amit ad, az nem alkalmas igazából szoftverfejlesztésre, mert pont ezeket a spagetti kódokat szorgalmazza. A használóinak túl kell lépni rajta, mert a saját életüket nehetzítik meg a jövőben. Ráadásul a jQuery-s példák és "csodálatos" pluginek is csak ezt a rossz szemléletet növelik. Nem azt mondom, hogy jQuery-vel nem lehetne jó alkalmazásokat fejleszteni, inkább azt, hogy sokkal több kell, mint egyszerűen jQuery-t használni, és sajnos sokan ezt nem látják.
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.
34

plugin

Hidvégi Gábor · 2013. Aug. 2. (P), 10.44
A pluginekkel nekem az volt a bajom, hogy egyrészt egy csomó idő volt megtalálni, ami leginkább igazodik az igényekhez, de még több a testreszabás, hogy úgy nézzen ki és úgy is működjön pontosan, ahogy kérték. Ennyi erővel ugyanott lettem volna, ha nulláról lefejlesztem.
35

Lehet jól használni

Drawain · 2013. Aug. 2. (P), 10.57
Szerintem nincs semmi gond a jQuery-val ha jól használja az ember. Kevés kivételtől tekintve minden plugint én írok hozzá a projektjeinkben - a jQuery-t csak azért használom, mert egy kényelmes, crossbrowser interfészt ad a DOM-hoz és az Ajax műveletekhez, illetve nagyon jó eseménykezelője van.

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).
25

A PHP védelmében

Drawain · 2013. Aug. 1. (Cs), 01.52
Nagyjából a tavalyi év közepére én is eljutottam oda, hogy a pokolba kívántam a PHP-t, a következetlenségeit és a hibáit, a fejlesztői közösség diverzitását (a túl sok és sokszor ellentmondó információból nehéz volt kihámozni a hasznosat). Ekkor már túl voltam több TDD-s, EP-s könyvön és szerettem volna olyan nyelvvel foglalkozni, ahol mindez eleve adott és támogatott.

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.