Milyen technológiára érdemes specializálódni?
Lassan végzek az egyetemmel és ki kellene találnom, hogy mi lesz az a technológia, amihez a legjobban érteni fogok. Azt vettem észre, hogy azok, akik egy bizonyos programozási nyelvhez vagy technológiához nagyon jól értenek, azok sokkal jobban el tudnak helyezkedni mint azok, akik sok mindenhez értenek, de mindenhez csak egy kicsit.
1. kérdés:
Mik azok a technológiák a webfejlesztés keretein belül, amikre érdemes specializálódni, mert el lehet vele helyezkedni nemzetközi szinten is?
2. kérdés:
Engem a webfejlesztés érdekel a legjobban, azon belül a backend fejlesztés, azon belül a PHP és az adatbázisok. Mennyire keresettek a PHP fejlesztők nemzetközi szinten? Érdemes-e erre specializálódni?
■ 1. kérdés:
Mik azok a technológiák a webfejlesztés keretein belül, amikre érdemes specializálódni, mert el lehet vele helyezkedni nemzetközi szinten is?
2. kérdés:
Engem a webfejlesztés érdekel a legjobban, azon belül a backend fejlesztés, azon belül a PHP és az adatbázisok. Mennyire keresettek a PHP fejlesztők nemzetközi szinten? Érdemes-e erre specializálódni?
..
Köszi
A Ruby on Rails-ről én is sokat hallottam, de egyáltalán növekszik rá a kereslet, vagy mi van vele?
..
Ismer par MVC keretrendszert, es legalabb egyben gyorsan dolgozik. MVC az alapkovetelmeny szerintem. A TDD-vel ki lehet tunni a tomegbol, mert php alapokon meg csak most kezd el elterjedni a teszteles.
A Railsre amennyire en latom iszonyat novekszik a kereslet, viszont inkabb mid-level fejleszoket vagy seniorokat keresnek. En az angol piacot ismerem inkabb, es itt nagyon sok RoR melo van.
PHP vagy RUBY ON RAILS
ha lenne sok szabadidőd Akkor
Akkor mindkettőt.
..
Tutorial
Köszi a választ. Mitől lesz
Tudja, mire való a htmlspecialchars, külön fájlba teszi az adatbáziskezelő logikát és a HTML-t, tudja, mi az az osztály :-) PHP-ben az "átlag fejlesztő" eléggé alacsony mérce.
Jó fejlesztő attól lesz, ha egyrészt jól érti az OOP-t (valódi objektumok pszeudo-névtérnek alkalmazott, statikus függvényhegyeket tartalmazó osztályok helyett, kivételek használata, alapvető design patternek), másrészt van valami köze az automatizált teszteléshez (nem feltétlenül TDD, de mondjuk PHPUnitot látott már, tudja, miért nem szabad singletonokkal teleszórni a kódot, ilyesmi), harmadrészt ismer egy SQL és egy NoSQL adatbáziskezelőt (utóbbi a PHP világban tipikusan a memcached), negyedrészt tisztában van az alapvető sebezhetőségekkel (SQL injection, XSS, CSRF, password hashing, remote file inclusion etc.), ötödrészt ismeri a kód szervezésének és karbantartásának alapvető módszereit (MVC, verziókezelők, phpdoc). Az se árt, ha tisztában van a trendekkel (komponensre bontható frameworkok, dependency injection, PSR, Composer, ilyesmi).
A PHP: The Right Way elég jó áttekintést ad arról, hogy mivel illik tisztában lenni.
PHP fejleszto
Egyebkent a PHP: The Right Wayhez annyit azert hozzafuznek, hogy vannak igen komoly szakemberek, akik mind a PEAR, mint a Composer hasznalatat ellenzik. A PEAR-t azert, mert igen ketes minosegu kodok vannak benne, a Composert pedig azert, mert nagyon sok felhasznalasi teruletbe nem illik bele. Szerintem a fejlesztok tudasaban inkabb a modszertani oldalon vannak hianyossagok, mint sem a cikk altal felsorolt eszkozok hasznalataban.
404
Nekem nem
Hát ez érdekes. Az imént még
Tranziens
Az viszonylag természetes,
PHP, Python, Java
Relacios adatbazisok:
NoSQL adatbazisok: (Amiket ismerek.)
Remelem, segitett egy kicsit.
..
Milyen memoria es uzemeltetesi nehezsegekre gondolsz?
Memory leak
A PHP-hoz, Pythonhoz hasonloan igen csak memoriaigenyes, cserebe a PHP a request utan eltakaritja magat, a Python meg alapjaraton nem leakel. Alig latok olyan ROR programot, ami 100 MB RAM fogyasztas alatt elindulna es tapasztalat szerint az osszes ROR alkalmazas nagyon szereti a RAM-ot, neha egy egyszeru feladatot vegzo daemon is felcuppant egy ido utan tobb gigat, vagyis leakel.
Ami az uzemeltetest illeti, rendszergazdai oldalrol sokkal tobb munkat igenyel egy ROR-os appot korrektul bekonfiguralni, mint PHP, Python, stb. appot. (apt-get install-al feldobni nyilvan barmit lehet, de az nem egy jovobe mutato dolog.)
Gondolok itt arra, hogy a rake 1.8 es 1.9 onmagaval sem kompatibilis, igy ha ket appod van, ami mas rake verziot kovetel, mar kicsit meg vagy love es tekerheted veg nelkul, hogy elinduljon.
Ott van az is, hogy rengeteg maintenance taskot ugy kell ROR appokban vegrehajtani, hogy valamilyen rake taskot inditasz el, viszont nem tudod ellenorizni, hogy mar vegre lett-e hajtva az adott task, igy nehez konfiguracio menedzsment szoftverbe integralni.
Aztan ott van a logolas problemaja is, hiszen a ROR default mukodese az, hogy a konzolra okadik. mod_passengerrel ezt valamelyest meg lehet kerulni, de a hibak syslogba kuldeset masszivan hianyolom belole. (Ebben egyebkent a tobbi nyelv is bunos valamelyest.) Mindenfele gemekkel termeszetesen lehet ezen javitani, de noveli a szukseges tobblet melot.
Osszegezve: a ROR baromi jo, ha rapid prototypingot akarsz, de ha nagy rendszert kell vele skalazni, akkor vagy kell olyan fejleszto, aki baromira belemaszott a lelkivilagaba es tudja, hogyan kell a footprintet csokkenteni es uzemeltethetove tenni, vagy tolhatod ala a vasat mint az orult, az pedig sokba kerul. A neten rengeteg blogpost szol ezekrol a problmakrol, cserebe keves a fejleszto a piacon, igy aztan nagyobb cegek csak odzkodva hajlandoak bevezetni.
re
En Ruby 1.9 es mostmar 2.0-at hasznalok, es a memoriaigeny az valos, viszont a memory leak-et en nem tapasztaltam. A memoriaigenyhez pedig meg annyit, hogy pl egy puma app szerver worker process elfut kb 80Mbyte memoriaval es ez eleg sok latogatot ki tud szolgalni. Ez a 80Mbyte 1.9 es adat, a 2.0 memoriaigenye kevesebb, de azt meg nem figyeltem mennyi memoriat eszik.
Felraksz egy nginx-et, meg az adatbazis motort, amit a tobbihez amugy is felraknal, es innentol mar csak egy ruby verziokezelo hianyzik. Szerintem nem komplikaltabb mint egy php/phyton.
Szerintem ruby 1.8 es 1.9-re gondolsz, mert a rake-nek nincs ilyen verzioja. Ott 0.9 es 10.0 sorozat van. A backward compatibility az valoban nem divat a ruby vilagaban, viszont vannak nagyon jo verziokezelok. rvm es rbenv a ket legelterjedtebb. Ezek segitsegevel a kulonbozo ruby es gem verziok gyonyoruen elszeparalhatoak, es az appjaid hasznalhatnak kulonbozo verziokat barmibol.
Ezt lehet felreertem, de az ilyen maintanence taskoknak en szoktam egy adatbazis tablat csinalni, ahova logolom, hogy mikor futott. Mashol erre van jobb megoldas?
Azert ha egy multi appos szerverrol beszelunk, akkor szerintem jobb ha apponkent kulon van a log, es nem egyben.
En ugy latom, hogyha valaki beleassa magat, akkor az uzemeltetes nem nehezebb mint egy php app eseteben. Persze megvannak a dolgok amikre figyelni kell, mert itt nem a feltoltom a fajlt es fut cimu musor van :).
Nekem egyebkent a phyton uzemeltetes tunik neheznek, mert egyaltalan nem ertek hozza :).
Valoban
Ezen felul pedig eljen a flamewar, had valaszoljak reszletesen. :)
Ez orvendetes. En 1.8-as Rubyn futtatok Puppetet es kb. egy nap utan minden daemon memoriafogyasztasa 1 GB.
Ha jol ertem, akkor ezzel elesel az oprendszer (automatikus/manualis) frissiteseitol?
Hat ez esetben a Te hozzaallasod orvendetes, de sajnos azt tapasztalom, hogy a Rubys/ROR-os szoftverek nagy resze ezt vagy nem teszi, vagy nem dokumentalja ugy, hogy a rendszergazda erre tudjon checket irni.
Ez egeszen addig tok jo, amig a) nem kell tobb szervert uzemeltetned es kozpontositanod a logokat b) nem hal bele a gep a buffereles nelkuli logolasba. Arrol nem beszelve, hogy a konzolra valo meglehetosen verbose okadas nem nevezheto logolasnak, fel kell dolgozni utolag, hogy mi kell belole, ami megint csak nem konnyiti meg a munkat. (Itt egyebkent a Javanak is a jo edes felmenoit.)
Nekem egyebkent a phyton uzemeltetes tunik neheznek, mert egyaltalan nem ertek hozza :).
A Python uzemeltetesrol rengeteg informacio van a neten, dokumentaciok, konyvek formajaban. Plusz a Python hagyomanyosan eros a hihetelen melysegu dokumentacioban, igy meg nem nagyon talalkoztam olyan szoftverrel, amirol ne lenne dokumentacio az uzemelteteshez.
Az alapveto problema az, hogy nincs eleg szakember, minden mas megoldhato. Ha csak Magyarorszagot vesszuk, ismerek jopar rendszergazdat es senkitol nem hallottam meg, hogy Rubyt mekkora kiralysag uzemeltetni. Anyazni annal tobbet. Ez egy hosszu tavra tervezo cegnek igen nyomos erv, ha technologia mellett kell donteni.
Becslesem szerint a Ruby on Rails jelenleg a Gartner Hype Cycle Slope of Enlightenment pontjan tart, ami orvendetes, de meg sok munka van hatra (doksi iras, stb), hogy kelloen sok szaktudas gyuljon ossze mind fejlesztesi, mind uzemeltetesi teren, hogy nagy cegek merjek hasznalni. Hatraltato tenyezo itt, hogy rengeteg ceg megegette magat az elso fazisban azzal, hogy ROR-ra epitett es utana nem talalt hozza eleg szakembert, igy sajnos sok manager rogton elveti, ha valaki felhozza a ROR-ra valo atallast.
RoR-nál nem oldaná meg a
Nem
Ha nem webes uzemeltetesrol beszelunk, a Puppetet en nem akarom ujrainditani, mert ha nem indul el utana, akkor jo nagy szarban vagyok. Jelenleg cronjobbol fut, viszont igy nehany featuretol elesek, pl. a puppet kick hasznalatatol.
Aha, esetleg nem lehetne
Van megoldas
Ok.
re
..
Ha ruby verziokezelot hasznalsz, akkor az automata rendszerfrissitesektol elesel(legalabbis amennyire en tudom rvm meg nem implementlat ilyesmit), de egy rails app alatt a ruby verziot, csak ugy nem frissiti le az ember. Elotte a fejleszto sajat gepen lefutattja a teszteket es ha minden ok, akkor mehet productionbe a frissites.
GEM-ek
..
Ritkan, de akkor nagy :). Most derult ki egy yaml sebezhetoseg ami nagyon sok rubygem-et erintett.
Arrol nem beszelve, hogy a
Azoknak a programozóknak a jó édes felmenőit, akik szerint oké a konzolra okádás :) Meg ex.printStackTrace() és társai (üres catch block). Egy code reviewn ezek a megoldások nem hiszem, hogy átmennek. A lényeg, hogy tudsz syslogba logolni javaból is. Nyilván értelmesen kell megírni a programot, hogy ne konzolra hányjon, hanem valami logger frameworkbe, amit aztán oda teszel, ahova akarsz. A RoR-t nem ismerem, de szerintem abból is lehet valahogy syslogba tolni az okádmányt.
ROR
Félreértés elkerülése végett:
Igen
„Strict mode” – köszönöm a
Én is a pgsql hatására
Strict mode
Re:
Igen, elég hamar. Nem
Error
Én eleve be szoktam építeni
MongoDB
Azért az nem csak illúzió :) Egyre több komoly cég kezdi el használni a Mongo-t és nem véletlenül. Tudomásom (és tesztjeim) szerint pl. egy mysql-nél jobb sebességet lehet elérni. (persze nyilván ez rengeteg dolog függvénye) Ami a legnagyobb előnye szerintem az a schemaless doksi struktúra.
Megmondom őszintén itt nem egészen értem mire gondoltál, de ami ezzel kapcsolatban eszembe jutott:
És hogy az elhelyezkedési lehetőségekről/fizuról is szót ejtsek: az index szerint egész jó helyen szerepel amerikában a mongodb-s szaktudás a legkeresettebb "szaktudások" listáján.
Ami a legnagyobb előnye
Valódi érdeklődés: milyen alkalmazás az, ahol te ezt érdemben ki tudtad használni? Én nemrég használtam Couch-ot egy projekthez, de még így, gyakorlati tapasztalat birtokában sem látom, hogy mi az előnye egy nemrelációs modellnek. A közbeszéddel szemben úgy érzem, hogy sokkal inkább az atipikus alkalmazások igen kis százalékánál lehet ez hasznos.
Attól függ, hogy mi a
Értem én, de épp az volt a
Huhh, na az jó kérdés :P
Példa
..
Ebbol arra kovetkeztetek, hogy mar nem hasznaljatok. Publikus a valtas oka, es hogy mire valtottatok?
Már nem vagyok ott, így nem
Memcache?
Használtunk
Ugyanez nem lett volna
Nem igazán
..
Lehet nem volt túl jó a
re
Nem volt még
Ha arra gondolsz, hogy egy
egy példa
(olyan sok tulajdonság ami egy sorban nem fér ki, és 1M-10M nagyságrendű adattal ügyfelenként)
Erre való az EAV.
lassú
MongoDB
Tehat ha szerencsed van, megvan az adatod.
Ez azért meredek. Nincs
Pont ez a baj
Egyebkent ha jo adatkonzisztenciat akarsz, ott van a Cassandra. Igaz, nekik is hosszu evek (es tobbek kozott a Docleres K+F csapattol kuldott patch) kellett ahhoz, hogy stabil legyen. A MongoDB meg... elmeleti es gyakorlati tapasztalat szerint ontokondofes.
Valóban így van... a 2.0-nál
Friss
Ha sok olyan objektumod van,
Azért általában ezeket az
Hasznaltad mar?
Az vicces lehet :d Egy dolog
Pont ezaz
állati
Szolgaltato
Nem túl magas ez az egy
Jo lenne
Milyen típusú vinyók? Nekem
IO
Ja így már világos, akkor
Szubjektív
Nem merek ilyen ajánlásokat tenni, komoly gyakorlati tapasztalat hiányában. Illetve amit korábban is írtam: ez a projektek nagy hányadánál elég szubjektív, mivel a különböző adatbázisok funkcionalitásának van egy metszete (azaz az adott feladat mindegyikkel megoldható).
Másrészt azt gondolom, hogy tök mindegy, hogy én milyen use case-re ajánlanám. Ha ez egy olyan technológia, amire igény van - hogy okkal vagy csak hype miatt az mindegy -, és aminek az ismeretét megfizetik (és ez volt az alap kérdés), akkor érdemes kiképezni magad belőle. Persze nyilván csak akkor, ha van jövője a technológiának, de MongoDB-nél szerintem ez nem kérdés.
MongoDB
Nekem van MySQL-ben és MongoDB-ben egy 8.2 millió rekordot tartalmazó adatbázisom. A MySQL 23 mp alatt keres ki egy rekordot WGS84 (decimal) koordináta alapján, a mongó megteszi 0.012 alatt.
Biztonság
Valóban, ott az SSL-kapcsolódás. Továbbá ugyan úgy van userkezelés benne, szerintem jobb, mint a MySQL-ben. Valamint nem nyitod ki a világba a Mongót, hanem Stunnellel kapcsolódsz. Ennyi....
A MySQL 23 mp alatt keres ki
MySQL-ben is van SSL, sőt, akár saját authentikációs modult is adhatsz hozzá. MySQL-ben mezőszintig lebontva adhatsz jogosultságokat a felhasználónak.
Én a saját (és a környezetem)
Külföldön viszonylag gyorsan el lehet helyezkedni vele, még alap PHP tudással is forintban átszámolva millió körül lehet keresni havonta (Anglia).
Itthon rengeteg az álláshirdetés/cég, de rengeteg a PHP fejlesztő is. Viszont olyan kevés van, aki tényleg mélyrehatóan ismeri a nyelvet, illetve a hozzá kapcsolódó technológiákat, eszközöket. Elég sokan írják, hogy rengeteg PHP-s van itthon, de ezek nagyrészt leragadnak a kis webes stúdióknál, a nagy cégeknél viszont én úgy látom hiány van rendes fejlesztőből, folyamatosan keresik az új embereket.
Ha webfejlesztésre adod a fejedet, első körben a következőket ajánlanám (nyelvtől függetlenül):
- légy tisztában a HTTP alapjaival, és minimális szinten a webes protokollokkal
- objektum orientált programozás alapjai
- SOLID alapelvek
- UML
- adatbázis tervezéssel kapcsolatos ismeretek
- tervezési minták ismerete
- valamilyen verziókezelő ismerete
- Linux alapismeretek
- szoftverfejlesztési metodológiák ismerete
Nyelvfüggő, PHP, MySQL:
- PHP minél mélyrehatóbb ismerete (javaslom a Zend Certificate hivatalos tananyagát)
- XDebug, debugolás, profilozás
- PHPUnit, unit tesztelés, TDD
- PHPDoc
- kód metrika, analitika, stb: PHPCodeSniffer, PHPloc, PHPCodeCoverage, PHPCopyPasteDetector, PHPMessDetector, Jenkins (CI), ...
- MySQL, SQL alapok
- storage engine-ek közötti különbségek
- tranzakciókezelés
- ne legyél megijedve ha írnod kell egy tárolt eljárást, vagy triggert
- tudd a lekérdezéseidet optimalizálni, ismerd az ezt segítő eszközöket (EXPLAIN)
Jó ha hallottál már róluk, de még jobb, ha már van is tapasztalatod velük:
- Memcache
- Redis
- valamilyen fulltext search engine (Sphinx, Solr, ElasticSearch)
Plusz persze (X)HTML, CSS, Javascript, még ha backend fejlesztő vagy, akkor is.
A PHP-nak van jövője
Viszont sok olyan dolog is van azok között, amiket írtatok, amiket nem ismerek, így úgy érzem, hogy még rengeteget kell tanulnom. Viszont legalább tudom, hogy mi az irány.
Szóval az egyik kérdésem az volt, hogy mire érdemes specializálódni, azok között ott volt a PHP. A másik kérdésem az volt, hogy mennyire keresettek nemzetközi szinten, és erre is az a válasz, hogy a minőségi PHP programozóra van igény. És a harmadik kérdésem pedig, hogy érdemes-e erre specializálódni, a válasz igen.
A jövőben valami nagy cégnél szeretnék dolgozni, és megpróbálok az USA-ban elhelyezkedni, mert úgy érzem, hogy Magyarországon nem igazán fizetik meg az embert. Most olvastam a napokban, hogy az USA-ban egy BSC diplomával rendelkező programozó átlagosan 1,6 - 1,8 millió forintnak megfelelő dollárt keres havonta (ezeket a számokat nem én találom ki). Azért ha ehhez hozzávesszük azt, hogy Magyarországon ugyan ezzel a végzettséggel egy programozó kezdő fizetése kb. 215.000 forint, akkor igazából szomorú látni, hogy 7-8 szoros különbségek vannak a fizetések között. Le merném fogadni, hogy a költségek nem 7-8 szorosak odakint. Persze ez jól hangzik, de tudom, hogy nagyon sok a szakember. Ezért döntöttem el, hogy szakértője leszek valamilyen programozási nyelvnek, és magas szintre fejlesztem a tudásom, hogy kiemelkedjek a munkaerő piacon. Befejezem az egyetemet, és elhúzok külföldre. Ha elég kitartó vagyok, és jól tudom a nyelvet, akkor előbb utóbb biztosan találok egy munkahelyet.
Hát ez a terv, persze ehhez akkor el kell döntenem végre, hogy mi az az irány, amire specializálódok. Úgy érzem, hogy a PHP és a hozzá kapcsolódó technológiák magas szintű ismerete lesz az irány, amennyiben ez az USA-ban (vagy legalábbis Európán kívül) is értelmes és hosszútávon jövedelmező szakterület.
Most olvastam a napokban,
Azert ha megnezed az allashirdetesek rajossz, hogy ez inkabb a csucs, mint az atlag. Viszont teny, hogy par ev utan ezt a fizetest el tudod erni egy nagy cegnel. Nameg brutto, de en peldaul angliaban elek es dolgozok, es valoban jobban megagyok fizetve, es az alberleten es autobiztositason kivul nem igazan dragabbak a dolgok. Amerika egyes reszei meg olcsobbak mint anglia.
Viszont ha amerikaval tervezel akkor en inkabb python vagy ruby mellett voksolnek: http://www.indeed.com/salary?q1=ruby&l1=&q2=phyton&l2=&q3=php&l3=&tm=1
Mivel a weben a HTML
Amerika
..
Ha jol dolgozol, akkor pedig egy ido utan szinte barhol el tudod erni az anyagiakban tamasztott igenyeidet.
Összetett
Az átlaghoz képest a kezdőfizetések is jobbak az informatikában, és pár év alatt lehet többszörözni, ez általában csak rajtad múlik, ha jó céget választasz. Lehet itthon is jót csinálni, lásd Prezi, Ustream, Jázmin.
Külföldön biztosan jobban lehet keresni, ott viszont más problémákkal kell megküzdeni: az elején nehéz, mert nem ismersz senkit, nincs ott a családod, a barátaid, az egészségügy és a lakhatás drágább (saját lakásról, házról ne nagyon álmodozz Nyugat-Európában), valamint a lányok csúnyábbak.
Továbbá hiányolom, hogy az ingyenes oktatás és egészségügyi ellátás miatt panaszkodsz, amit életed első húsz évében igénybe vettél, szóval nem fair. Nekünk, akik itt maradunk, ez sokba kerül, ráadásul többet is kell fizetnünk, ha sorban mennek el az emberek.
A jövőben valami nagy cégnél
Vagy csak rossz helyen keresed. :) Van jópár cég itthon is, akik megfizetik rendesen az embert, ha tud. Persze ezek nem a kis webstúdiók, hanem tényleges fejlesztőcégek. Én sem hittem a fülemnek, de bővebb ismerettségi körömben van egy PHP fejlesztő, aki 600 körül keres itthon.
Ha nem vagy biztos a nyelv- és szakmai tudásodban, akkor szerintem egyelőre ne nagyon erőltesd a külföldet. Húzz le egy évet egy itthoni cégnél, gyűjts némi tapasztalatot, pénzt, és erősíts rá a nyelvre.
Alapvetően mindegy mire specializálódsz. Akár PHP, akár Ruby, akár Python, akár Java, ha megvan a megfelelő tudásod, kapkodni fognak utánad.
Ha a pénz számít, akkor én
Ehhez annyit tennék hozzá,
Én nem ismerek annyira sok
Én ilyenről nem tudok. Biztos
Janoszen külföldes tanácsával analóg módon én a specializációra is azt tanácsolnám: olyan területet, nyelvet válassz, ami érdekel és szívesen töltöd vele az időd. De főleg területet.
A PHP-nak van jövője, én ezt
Jelenje van neki, a jövője azért bizonytalanabb. Másfél éve szerintem a legtöbb ember azt mondta volna, hogy a PHP kiöregedő nyelv, azóta a core közösség eléggé felszívta magát, meg a nagy frameworkok felől is jöttek bíztató dolgok (komponens-alapú frameworkok, Composer, PSR); ezzel együtt nem árt a PHP-n kívül még legalább egy nyelvet ismerni (amúgy sem árt, nagyobb rálátást ad).
PHP programozóból egyébként rengeteget keresnek, könnyű elhelyezkedni (illetve más nyelvekkel is könnyű elhelyezkedni, de PHP-ben sokkal több lehetőség közül válogathatsz), viszont valamivel kevesebbet is fogsz keresni vele valószínűleg.
A másfélmilliós kezdőfizetéssel én kicsit szkeptikus vagyok, de tény, hogy jóval magasabbak a fizetések küföldön (én gyakorlatilag nulla kereséssel találtam munkát EU-n belül háromoszoros pénzért).
Miért bizonytalan a PHP
A PHP egy "egydimenziós"
Meg vannak az enginejében is buta hibák. Érdemes megnézni pl ezt:
Ha az ember webes rendszerek fejlesztésével akar foglalkozni, érdemes jól megismerni a PHP-t, mert (jelenleg) általában jó választás. De érdemes tudni a korlátait, és hogy vannak alternatívák.
Én azt mondom, hogy mindentől függetlenül érdemes általánosabb nyelveket is viszonylag jól megtanulni (C/C++, Java, C#). Könnyebb onnan átnyergelni egy lazább erkölcsű scriptnyelvre, mint fordítva :) Már ha aztán akar az ember. Tény, hogy a ráfordítandó energia is alapvetően nagyobb, de hát valamit valamiért.
Szóval összegezve azért bizonytalan, mert alapjaiban átgondolatlan, lassú, és nőnek ki a földből olyan nyelvek és környezetek, amik jobbak ezeken a térületeken, és egy átlagosan képzett programozónak is befogadhatóak.
Meg hát nem is egy
Az általam látott tesztekben a node.js-t kivéve mindent ver.
A hibakezelése viszont tényleg gyalázatosan rossz, keveredik benne a kivételkezelés, a callback alapú hibakezelés és az egyedi megoldások (mysql_error és társai), nehezen kezelhető fatal errort dob olyan hibákra, ahol abszolút nem indokolt (pl. metódushívás null-on), nem mindig hívódik meg a shutdown handler, nem dob hibát olyan esetekben, ahol elvárná az ember (pl. nem tömböt tartalmazó változó tömbként használata)...
És általában, véletlenül keletkezett programnyelvként (ugye eredetileg sablonnyelvnek szánták) tele van olyan átgondolatlanságokkal és hiányosságokkal, amik miatt a modernebb és jobban megtervezett vetélytársai (Ruby, Python) sokkal jobb fejlesztői élményt nyújtanak. A PHP-nek jelenleg sokkal nagyobb a momentuma (többen ismerik, több host támogatja, több szoftver van rá), de az ilyen előny nem tart örökké.
gyorsaság
Nem gyorsabb
Nem ugyanarra valo a ketto, szoval olyan osszehasonlitani oket, mint almat a kortevel. A Node elsodlegesen egyszerubb, de gyors reakciot igenylo muveletekhez valo (pl. message queue, chat, egyszeru webszerver), az egyeb nyelvekkel/kornyezetekkel sokkal bonyolultabb uzleti igenyeket is ki lehet elegiteni. JS-el bonyolult uzleti logikakat megvalositani kb olyan, mint egy teherautonyi fonalgombolyagot legorgetni es utana ujra felgorgetni.
Azért a szálindítás
Itt egy benchmark. Noha nem
Ami már sokkal érdekesebb, az itt van. Ez egyben mehetett volna egy korábbi szálba is, ahol a php és a node.js volt terítéken, miszerint van-e értelme az asynchron megoldásoknak. Érdemes megnézni a 2 grafikont, hogy reagálnak a terhelésre CPU load és response time vonatkozásában. Az a vízszintes kék vonal elég impresszív :)
Az első, "Hello World"-ös
Amit küldtem, az nem a
Egyébként meglepődnél, hogy milyen komoly nagy terheltségű rendszerek futnak 1 szálon, és ez nem véletlen. De ez azért kicsit más téma, mint amiről a topic szól, nem feltétlenül kell idecitálni.
Aszinkront meg ott kell használni, ahol van értelme, mindenhol nyilván hülyeség.
Teszt
Arról sajnos nincs
Nem tartom valami sokra
Illetve még annyi, hogy a
A skálázhatóságot visszaolvasva viszont nem biztos, hogy jól értem, hogy mire gondolsz valójában, amikor az egyszálúságnál ezt ellenérvként hozod fel.
Skálázhatóság
A node-ban a programod egy szálon fut, ami számomra azt jelenti, hogy ha egy kérés nettó feldolgozási ideje (IO nélkül) 20ms, akkor egy másodperc alatt 50 klienst tudsz legfeljebb kiszolgálni. Ha elfogy a proci, akkor csinálhatod azt, amit Poetro írt a 89-es hozzászólásban, vagy írhatsz/használhatsz saját processz-kezelőt, aztán az olyan lesz, amilyen, szóval ott vagy, ahol a part szakad. Egy Apache ebben biztosan hatékonyabb, ott beraksz még egy procit, még egy kis memóriát, és egy ideig elég lesz.
Pont ez volt a lényege a
Illetve amit janoszen írt, az nem a single-threaded működésre utalt, hanem hogy a node.js nem tudja az állapotát replikálni node-ok között, tehát macerás load balancolni. Ez attól függetlenül igaz, hogy 1, 2, vagy 32 szálon fut. De pl stateless szolgáltatásokra jó.
A single-threadedhez: durva terheltségű (100K+ TPS) tőzsdei kereskedési rendszer működik "ugyanezzel" az aszinkron event-driven technikával, 1ms latencyvel(!). Mindezt Javaban. Nincs lock, nincs context switch, rá van aggatva egy cpu-ra az üzleti logika, és az darál. Csak db legyen a talpán, ami leírja, ami kijön egy ilyen gépből :)
A multithread jó dolog, de nem arra van kitalálva, hogy extrém terhelést szolgáljanak ki vele thread/request alapon.
Elmentünk egyébként nagyon node.js vs php irányba, holott ez csak a nyelvek sebessége miatt került elő. Senki nem gondolja itt szerintem, hogy a node.js a jelenlegi formájában át tudná venni a php helyét. Több szempontból sem. De mindenképpen egy figyelemreméltó megoldás a jópárból, ami piacot hasíth(g)at magának a php tortájából.
Köszönöm
A node versus php-t nem én hoztam fel, de ha már feljött, szeretném megérteni, miért kell akkor hasonlítgatni bármi máshoz, ha ennyi problémával küzd, meg miért akarnak mégis olyan sokan alkalmazásokat fejleszteni a segítségével (az mloc.js is részben erről szólt).
Értem, tehát az Apache modell
Meg még sok más miatt is. Lockolások, memóriakezelés stb. Nyilván ha 2 ember kérdésére kell válaszolgatnod párhuzamosan, akkor jut időd válaszolni, és ők is meg tudják várni a másik kérdésére adott válaszodat, a beszélgetés folyamatos tud lenni. De ha eléd áll 200 ember és kérdezget párhuzamosan, akkor ott már nem tudod kielégíteni a kérdezők kíváncsiságát, próbálsz mindenkinek motyogni valamit, de gyakorlatilag vége lesz a beszélgetésnek. És igen, a context switch is drága dolog tud lenni, főleg ha full cpu cache-miss-el jár, akkor alaposan megnő a latency, mert a memóriához kell nyúlni. De azért azt gondolom, hogy amikor php-ban egy nem realtime rendszert fejlesztünk, mint pl egy weboldal, nem biztos, hogy van értelme ilyenekkel foglalkozni. Legyen jó a kód, ez sokkal fontosabb, mint ilyen dolgokon rágódni. Csak azért hoztam fel, mert ez pl előnye a single-threaded modellnek. És érdemes tudni, hogy ha az apache alatt vörösen izzik a vas, akkor van más megközelítés is (nginx pl).
A node.js még egy kialakulóban lévő platform, szerintem le fogja küzdeni a gyermekbetegségeit, lásd pl a többszálú workerek, state replication. Szóval érdekes megközelítést használ, és ma az event-driven megvalósításának hála komoly népszerűségnek kezd örvendeni. De nyilván nem jó mindenre ez sem.
Egyszálúság
Tobb melo
http://lmgtfy.com/?q=nodejs+l
Senkinek sem kell feltalálni a spanyol viaszt... Js témában nagyon kevés olyan dolog van, amit saját kezűleg meg kéne írni, inkább az szokott gond lenni, hogy a már kész implementációk közül melyiket válassza az ember, mert általában van 5 lehetőség.
HTTP
Ha megnezed a masodik pontot, a socket.io pl mar nem kepes normalisan mukodni load balancer mogott mert nem stateless es a state nincs megosztva a ket instance kozott.
Ugyanez termeszetesen barmilyen daemonkent futo, allapotokat (pl. sessiont) memoriaban tarolo kornyezetre igaz, nem csak a NodeJS-re.
Nekem a google azt dobta erre
http://www.ranu.com.ar/2011/11/redisstore-and-rooms-with-socketio.html
Ez mondjuk nem valami sok. Egyébként nem értek ehhez a témakörhöz, szóval google kereséseknél többet nem tudok felmutatni.
OK
Ez miben más mondjuk PHP-ben?
Default
http://nodejs.org/docs/latest
Futhat az több process-ben is, szóval egy szerveren több magon simán elmegy, arról nem írtak, hogy több szerverre is kirakható e.
Ez nem jelenti azt, hogy
Nyilvan
Since you want a push
By using this combination, the data for all the connections is kept in Redis (in-memory database), so you can scale outside a process. Another use of Redis here is for pub-sub.
Na most ez nekem gányolásnak hangzik, de javíts ki, ha tévedek...
Vannak erre már kész
Kivancsi lennek
Plusz egy korrekt socket
Mit értesz socket implementáción? Illetve dead peer detection alatt?
Protokoll
Ezt megkapom a kerneltől,
Haha
Már elég régóta lehet több
https://github.com/xk/node-threads-a-gogo
szóval én nem hivatkoznék az egyszálúságra...
Hajrá
The problem with threads
Link
Egyebkent ha emelle esetleg meg valaki processeket is indit mindenfele feladatok vegrehajtasara, akkor lovi magat igazan labon. Arrol nem beszelve, hogy ezzel meg mindig csak egy fizikai vasig tud skalazni.
Nem azért írtam, mintha
Találtam stackoverflow-on egy
http://stackoverflow.com/questions/2387724/node-js-on-multi-core-machines
amiben azt írják, hogy nodejs-ben nagyjából megoldódtak a skálázással kapcsolatos gondok. Mi a véleményetek róla?
Az általam látott tesztekben
Scriptnyelvek közül, és szerintem úgy igaz, hogy még veri őket. Nagyságrendileg pythonnal és rubyval egy szinten vannak, ahogy én láttam tesztekben, illetve pythonnál kicsit gyorsabb a php. De pl a node.js elég komoly ellenfél kezd lenni. Szerintem egyébként főleg az architekturális felépítés miatt, nem feltétlenül az interpreter veri agyon, de még az is lehet. Ha valakinek van kedve, próbálja ki :)
Meg elvileg ilyet nem illene, de ha valami nem scriptnyelvvel hasonlítod össze (java, c#), akkor már horror lassú, és ilyen szempontból értelmetlen választásnak tűnik egy komolyabb terhelés alatt lévő rendszer alá.
A hibakezeléssel meg nagyon egyetértek...
Python?
Ezt kifejtened? Eleg eselyes, hogy rosszul volt megirva az adott Python kod vagy a teszt volt hibas. A PHP a klasszikus peldaja a lassusagnak mert erosen szuboptimalis a kodja.
Nem én mértem, erre utal az
Gyakorlati
Egyebkent ha erdekelnek az ilyen sebesseg / optimalizacio szeru jatszadozasok, ajanlom egy baratom szolgaltatasat, a beatmycode.com-ot.
Illetve egy kis infografika,
Meg hát nyilván az ilyen laboratóriumi teszteket azért alapvetően a helyén kell kezelni...
nyelv vs. implementacio
A CPython kb. egy referenciaimplementacio, sosem volt kifelyezetten gyors, nem is igazan celja. Tipikusan hosszan futo, sokszor ismetlodo dolgoknal (pl. weboldal kiszolgalasa) erdemes valami JIT-es VM-et hasznalni, itt nagysagrendekkel jobban teljesit a PyPy. Es a python vilagban is vannak a node.js-hez hasonlo, aszinkron dolgok, pl. a Twisted.
A javascript-be atforditott JVM-en barmilyen java kod lassan fut, hiaba java.
Az általam látott tesztekben
Az univerzális kvantor azért merész. Natív kódra fordított nyelveket is verne?
Mindent, amiben
(A natív fordítás egyébként önmagában nem tesz csodát, a HipHop pl. gépikódra fordítja a PHP-t, ehhez képest nem jelent óriási sebességnövekedést.)
Azért C, C++, C#, Java-ban is
Valóban vannak a nyelvnek
A példát amit írtál nem próbáltam ki, de igazából nem is lényeges. Vannak a nyelvben hibák (egyébként más nyelvekben is vannak), de ettől függetlenül ugyanúgy meg lehet benne csinálni szinte bármilyen webes dolgot. Javaslom egyébként egy debugger használatát.
A gyorsaságról szerintem már írtak kicsit lentebb (vagy fentebb), de én is hozzáteszem, hogy de, egy viszonylag gyors nyelv. Azaz 1-2 ms amit nyelvenként megspórolhatsz igazából nem oszt, nem szoroz, se a usert nem érdekli, se a megrendelőt, se senkit. Hozzáteszem, lassú alkalmazásoknál az esetek nagy részében a kliens oldali kód van elrontva (vagy nincs optimalizálva), vagy az adatbázisszerver oldalán kell keresni a bibit.
Szóval összegezve a PHP egy viszonylag gyors, valóban nem teljesen átgondolt nyelv, amit könnyű megtanulni (átlag alatt képzett programozóknak is könnyen befogadható), rengeteg ráépülő alkalmazás van, rengeteg fejlesztő, sok-sok dokumentáció és könyv, rengeteg tapasztalt szakember, hosztingszolgáltatók, stb. A földből kinövő nyelvekről pedig annyit, hogy te bevállalnád egy új nyelv megtanulását úgy, hogy nem tudod befut-e vagy sem? Arról nem is beszélve, hogy kell vele egy-két év, amíg komoly tapasztalatot szerez velük az ember.
Megjegyzés: mielőtt még valaki megvádol, nem vagyok elvakult PHP fan, sőt, azt vallom, hogy a feladathoz kell eszközt választani.
Én sem tartom valószínűnek,
De a fejlesztők hajlamosak
Az üzleti oldalt nem igazán érdekli, hogy előbb a haystack vagy a needle, szóval akár javítani is lehetne (igen, visszafele kompatibilisan, mielőtt valaki lecsapná, hogy az üzletet továbbra se érdekelje [igen, ez csak szimbolikus volt, és nem ez a nyelv egyetlen vagy legnagyobb baja, mielőtt valaki lecsapná]).
A következetlenségek nehezítik meg a legjobban egy nyelv megtanulását, főleg egy kezdőnek, ugyanúgy, ahogy egy gyermeknek is a rendhagyó alakok jelentik a nehézséget az anyanyelve tanulásakor, mert a szerencsétlen logikusan gondolkodna, ha hagynák. A PHP üzemeltetéséről szerintem nálam ékesebben tudnak szólni azok, akik többet foglalkoztak vele, de én nem úgy látom, hogy a rendszertörp élete csak játék és mese.
Milyen minőségben? Amint ez is fontossá válik, meglepően sokan dobják el hanyatt-homlok.
Brainfuckban is, csak egyikünk sem akarja. Ez nem érv.
Te mint felhasználó meg vagy elégedve azokkal a töltési időkkel, amiket a Weblabor produkál? Mert én már rég anyázó leveleket írnék a szerkesztőségbe, csak hát érted.
Én például szoktam. Vagy már nem fontos a folyamatos fejlődés az IT-ban?
»A földből kinövő nyelvekről
Én például szoktam. Vagy már nem fontos a folyamatos fejlődés az IT-ban?
Kritikus tömeg?
Nem
Nem az a lényeg, hogy tudod-e
A példát amit írtál nem
Vannak, persze. De egyrészt igyekeznek javítani, másrészt ez azért nem egy átlagos hiba. Meg TUDSZ hívni nem static methodot osztályon. És kussol. Képzeld el, hogy A-nak és B-nek van közös interface-e, ami definiál egy businessMethod()-it, és A-ban $this->businessMethod()-ot hívsz. Ha épp ezt a részt nem fedi le JÓ teszt, akkor ebből übernagy szopás lehet. És mindezt úgy, hogy simán lehetne azt mondani, hogy nem static methodot nem hívunk meg osztályon. Pont.
A gyorsaságról: Kérdés, hogy mihez képest gyors nyelv. Van pár év tapasztalatom php-ban, és az én tapasztalatom az, hogy nem gyors. Különösen akkor nem, ha bonyolultabb üzleti logika van mögötte. Benchmarktól függetlenül.
Nyilván nem arról van szó egyébként, hogy holnap eltűnik a PHP, mert jön egy jobb nyelv. De az egyértelműen látszik, hogy trónkövetelők vannak. És ez szigorúan az én véleményem, de ha a PHP nem csinál egy nagy huszárvágást az elkövetkező években, akkor a fejlesztők több éves időtávon át fognak nyergelni egy átgondolt, nem össze-vissza patkolt nyelvre, amihez ugyanezek az eszközök kifejleszthetők.
A PHP baja egyébként szerintem pont az, ami az erőssége. Túl gyorsan elterjedt, nem tudták kijavítani a gyermekbetegségeit, mielőtt ráépítették volna a webes világ nagy részét. Így pedig már valóban nehéz azt mondani, hogy sorry gyerekek, de php6-tól új világ jön. Marad a patkolás.
Én se vagyok egyébként elvakult php ellenfan. Sőt, szeretem is a php-t.
PHP
1, átnéztem a PHP forráskódját, bár közel sem bitről bitre, de nekem úgy tűnik, hogy a C stringkezelését használják, ami ugye annál lassab, minél hosszabb a karakterlánc; ha például a Pascal módján oldanák meg, jóval hatékonyabb lenne minden, ami erre épül (elég sokminden),
2, a böngészők JS motorjaiban kőkemény optimalizáció folyik, figyelik a változók, paraméterek értékeit, és ezektől függően más és más bájtkódot generál: ha egy ilyet be lehetne vezetni PHP-ban, megőriznék az előnyüket.
A magam részéről mást nem változtatnék, mert a meglévő szintaktikai eszközökkel mindent meg tudtam eddig oldani.
Én nem hiszem, hogy a null
A menet közbeni durva kódoptimalizáció elég sok kérdést felvet. Alapvetően jó dolog, de pl a memory footprintet biztos növeli. Meg ezt hogy? Processenként? Vagy rántsunk fel egy php vm-et? Ebbe az utcába már nem olyan triviális bemenni úgy, hogy a php meg is őrizze az egyszerűségét. Illetve kérdés, hogy a php valóban azon a pályán focizik-e, ahol ezekkel a problémákkal kell foglalkozni.
A hiphopot amúgy már nézted?
Ez a "probléma" nagyjából ott
Joel On Software is írt a problémáról egy cikket.
A hiphopot szerettem volna kipróbálni, de a hozzá szükséges szoftverkörnyezetet még nem tudtam összehozni, mert nem szántam rá elég időt.
+1
Véleményem szerint ma már végképp semmi értelme. Sem az adatátvitelben, sem az adattárolásban nem jó, ha nem tudjuk előre, hogy mekkora cuccról van szó. A kis stringek sem okoznak gondot, ha mégis, akkor pedig van rá modell, lehet többfajta stringtípust kitalálni.
Igazad van alapvetően,
Na mind1, ennek kapcsán el is gondolkodtam, mert gyanús volt, meg nem is hagyta nyugodni a kíváncsiságomat, úgyhogy megnéztem: külön számolja a string hosszát a php. Szóval nem ettől lassú.
Ezt nem teljesen értem
Zend könyvtárát nézd a
zend.h
Azért azt meg kell hagyni, hogy ennél már láttam olvashatóbb kódot :)
Köszönöm
Nem ugyanaz
Abban mindig egy helyen van a lefoglalt 256 byte, amiből az első mondja meg, hogy melyik az utplsó. Ha assembly-ben írod meg a kezelését, nem tudsz ennél gyorsabb tárolási/műveleti megoldást kitalálni, de talán még ugyanilyen gyorsat sem (alap-iteráció).
Hátránya, hogy mindenképp el kell foglalja a 256 bájtot, függetlenül a tényleges hossztól.
Nagytestvére a
widestring, ami 65534 hasznos hosszúságú, kétbájtos indexszel.És ez miért jobb, mint a
Mindennek van előnye és
Itt ami a lényeg, hogy nem kell végigmászni a memórián, amíg megtalálod a nullát, hanem ott van szépen egy int-ben, hogy mekkora is az a string. Gábor ezt a problémát hozta ide.
Részben igaz
1. "0" karaktert nem tartalmazhat;
2. Kötelezően az egymást követő karakterek egymás után vannak a memóriában.
Ez utóbbi miatt nem elég "beszúrni" a 0-ás byteot, hanem a mögötte lévő részt "odébb" kell menteni, legalább 1 byteal, vagy tetszőleges helyre.
Végül: igen, ott van szépen egy int-ben, mégis: ez az int (többnyire) egész máshol "lakik", mint maga a string. Emiatt 2 db memóriaelérés kell, továbbá ellenőrizni is kell u.úgy a 0 véget. Ha nem kéne, akkor máris felesleges a 0 vég. De akkor is maradt a 2 címzés, 2 olvasás. Míg a Pascal-os esetben (minden hátránya mellett) egyetlen, egybefüggő 256 v. 65536 bytenyi területet kell elkezdeni olvasni, az első 1 v. 2 byte értékének megfelelő mértékig (ez egy egyszerű loop, szemben a 0-végű byte-onként végrehajtott
jump if zero-val). Tehát 1 címzés, 1 olvasás. (Az igazsághoz hozzá tartozik, hogy a widestring esetén külön olvasó progirész van, ha jól emlékszem.)Azt gyanítom (de a PHP belső "lelkivilágát" annyira nem ismerem), hogy ez a külön tárolt hossz olyasmi célokat szolgál, mint az
strlen, stb. függvények gyors eredmény-visszaadása. Viszont konkrét műveleteknél ezt csak beállítja, de a 0 véget használja. Ha ez igaz, akkor egy felesleges plusz műveletet iktat be egy helyre azért, hogy egy másik helyen gyorsabb lehessen. Ezt én logikátlannak tartanám, de a PHP esetében nem ez lenne az első.Ádám: azt hiszem, itt kellőképpen kifejtettem a véleményemet. :)
Egy szóval sem mondtam, hogy ez jobb (ecseteltem is hátrányait), viszont gyorsabb. Elsősorban azért gyorsabb, mert kevesebb műveletből-címzésből áll. (Ha kell, írok rá assembly-t, de nem most.)
Egy dolgot szögezzünk le. A
Ha a php belső stringműveletei izgatnak, ott írtam hol tudod megnézni. De én nem hinném, hogy azt a len-t csak szórakozásból tárolják ott :) Nyilván vannak pluginek, meg függvények, amik a c strlenét használják, de nem erre a structra.
Illetve ebbe az utcába nem nagyon akarok belemenni, de pl egy szálon belüli heavy string manipulációt ideális esetben a cpu cache-ből old meg, nem memóriából, az meg azért elég gyors. Nyilván ki kell olvasni, meg vissza kell írni, amivel dolgozik, de azért okosan van ez kitalálva :)
És végezetül én nem érvelek se a c féle, se a pascal féle megoldás mellett. Mindkettőnek van előnye, hátránya. A személyes véleményem az, hogy a mai világban egy 256, vagy 64k limit nagyobb hátrány, mint stringenként külön tárolni a hosszát 2 memóriacímen. De ez nem jelent egyenesen null terminatedséget. Na uff :)
Valóban
A cache utca nem jó utca, azt megint csak mindkét esetben kéne vizsgálni, ott is a két cím / egy cím játszik "főszerepet". De tényleg hagyjuk, más a kettő, én sem mondom, hogy melyik jobb. (Majd ha feltalálom a századikat, az lesz a legjobb! :))
Ismerek olyat, akitől
No comment
Egyébként próbáltál már PHP
Ido
+1, én sem értem, hogy ezen a
Én úgy látom
Igen, mondjuk az viszont már
Kapcsolódó link
És úgy az egész utolsó bekezdést érdemes megrágni.
Ez nem csak