ugrás a tartalomhoz

Milyen technológiára érdemes specializálódni?

stan · 2013. Feb. 26. (K), 15.48
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

..

Greg · 2013. Feb. 26. (K), 15.55
A PHP keresett, de van belole kinalat is. de nemzetkozi szinten azert altalaban a jobbak jutnak at a szuron. En inkabb Ruby-t vagy Python-t tanulnek a helyedben. Azokra nincs akkora kereslet mint PHP fejlesztore, viszont programozo is keves van. Ruby/Rails fejlesztobol peldaul eleg nagy hiany van amennyire en latom. Legalabbis engem folyamatosan bombaznak ajanlatokkal.
2

Köszi

stan · 2013. Feb. 26. (K), 16.03
Köszi a választ. Mitől lesz valaki jobb PHP fejlesztő, mint az átlag?
A Ruby on Rails-ről én is sokat hallottam, de egyáltalán növekszik rá a kereslet, vagy mi van vele?
3

..

Greg · 2013. Feb. 26. (K), 16.27
Mitől lesz valaki jobb PHP fejlesztő, mint az átlag?

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

PHP vagy RUBY ON RAILS

stan · 2013. Feb. 26. (K), 16.40
A helyemben mit kezdenél el tanulni keményen, ha lenne sok szabadidőd? PHP vagy Ruby On Rails?
5

ha lenne sok szabadidőd Akkor

Poetro · 2013. Feb. 26. (K), 16.58
ha lenne sok szabadidőd

Akkor mindkettőt.
6

..

Greg · 2013. Feb. 26. (K), 17.01
En elfogult vagyok, mert amiota a Rubyval es Railsel megismerkedtem, azota belejuk szerettem :). Ugyhogy en a Ruby es a Rails tanulasaba vagnek bele. Nem tudom az angollal hogy allsz, mert magyarul keves leiras van hozza. Nehany cikket talalsz itt: http://dev.elopment.net/ de ezek nem kezdo leirasok. Talan a Railscast-okat es Michel Hartl konyvet erdemes kezdesnek elovenni: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
17

Tutorial

janoszen · 2013. Feb. 26. (K), 19.51
A Rubyval valo ismerkedesre ezt az interaktiv tutorialt ajanlom.
14

Köszi a választ. Mitől lesz

tgr · 2013. Feb. 26. (K), 19.39
Köszi a választ. Mitől lesz valaki jobb PHP fejlesztő, mint az átlag?

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

PHP fejleszto

janoszen · 2013. Feb. 26. (K), 19.52
En ennel meg alacsonyabbra tettem a mercet, irtam is egy blogpostot arrol, hogy kellene kineznie egy PHP-s alkalmazasnak.

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

404

Joó Ádám · 2013. Feb. 26. (K), 20.10
404
27

Nekem nem

janoszen · 2013. Feb. 26. (K), 20.50
Nekem nem. Ez az URL: http://www.janoszen.com/2013/01/08/writing-modern-day-php-applications/
32

Hát ez érdekes. Az imént még

Joó Ádám · 2013. Feb. 26. (K), 21.21
Hát ez érdekes. Az imént még 404 volt, esküszöm.
36

Tranziens

janoszen · 2013. Feb. 26. (K), 23.48
Tranziens bug, elofordul.
54

Az viszonylag természetes,

tgr · 2013. Feb. 27. (Sze), 20.38
Az viszonylag természetes, hogy egy komponens-gyűjteményben vannak kétes minőségű dolgok is, a minőségbiztosítás nem a komponensmenedzser feladata; a PEAR egyszerűen elavult, nehezen kezelhető, nincs jó dokumentációja, nem tud lokálisan installálni, bonyolult saját csomagokat definiálni stb. A Composerről szerintem illik tudni, micsoda, pláne ha opensource eszközt teszel közzé és kezelned kell a függőségeit valahogy.
7

PHP, Python, Java

janoszen · 2013. Feb. 26. (K), 17.20
A fobb webes nyelvek szetbontva:

  • PHP: Hatalmas piaca van, folyamatosan keresnek embereket, viszont erolkodni kell a tanulassal, fel kell fejlodni egy szintre. Rettenetesen sok a kontar.
  • Python: Nehez a kezdes vele, viszont nagyon jol kitalalt nyelv es szeretik is. A Python specialistak relative sokat keresnek es nem is hallottam senkirol, akinek elhelyezkedesi problemai lettek volna.
  • Java: Nem annyira csak webes nyelv, viszont regenteget kell tanulni. Ha az ember erti az OOP alapjait, akkor ez egy kellemes nyelv es eleg jo lehet vele keresni, van fejlodesi lehetoseg mivel vannak nagy es sokat fizetni hajlando cegek.
  • Ruby on Rails: A rapid prototyping jellege miatt a startupok szeretik, amikbol Europaban nem sok van. A memoria- es uzemeltetesi nehezsegek, valamint a keves elerheto fejleszto miatt a nagyobb, stabilabb hatterrel rendelkezo cegek nem szeretik.
  • .NET: Microsoft-only technologia. Baromi draga uzemeltetni es sok a kontar, kisebb a piac, viszont jol lehet vele keresni. Erdemes nemi penzt felretenni a vizsgakra, mert igen csak draga lesz.
  • NodeJS: Kiegeszito technologianak nem rossz, megint csak a startupok szeretik, de komplex alkalmazasokat kodszervezesi problemak miatt nehez vele irni.
  • Perl: Rendszergazdak szeretik, de manapsag ma mar nem nagyon hasznalatos, mert sok buktatoja van.


Relacios adatbazisok:

  • MySQL: Rengetegen hasznaljak, csomo nem szabvanyos dolga es bugja van.
  • PostgreSQL: Rendkivul stabil, kevesen hasznaljak a szigora miatt.
  • Oracle: Enterprise, sokba kerul, leginkabb Javaval hasznaljak. A tanfolyamok penzbe kerulnek, szoval erdemes kicsit tomottebb penztarcaval / mecenassal belevagni, ha komolyan gondolod.


NoSQL adatbazisok: (Amiket ismerek.)

  • MongoDB: Startupok nagyon szeretik, mert a sebesseg illuziojat kelti, de kb annyira biztonsagos adattarolasra, mint egy oroszrulett.
  • Redis: Jol kiforrott, rengetegen hasznaljak a relacios adatbazisuk tehermentesitesere.
  • Memcache: Jol kiforrott, rengetegen hasznaljak a relacios adatbazisuk tehermentesitesere. Csak memoriaban tarol.
  • Cassandra: Relative lassu, de jol/biztonsagosan tarol sok adatot. Sokan hasznaljak nagyobb rendszerekben.
  • ElasticSearch: Nem rossz, bar uzemeltetni kicsit nehez. Relative kevesen hasznaljak.


Remelem, segitett egy kicsit.
8

..

Greg · 2013. Feb. 26. (K), 17.28
Ruby on Rails: Startupok szeretik, amikbol Europaban nem sok. A memoria- es uzemeltetesi nehezsegek miatt a nagyobb, stabilabb hatterrel rendelkezo cegek nem szeretik.


Milyen memoria es uzemeltetesi nehezsegekre gondolsz?
9

Memory leak

janoszen · 2013. Feb. 26. (K), 17.45
Ezek csak az en megfigyeleseim kicsit uzemeltetoi oldalrol nezve:

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

re

Greg · 2013. Feb. 26. (K), 18.03
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.

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

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

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

Ezt lehet felreertem, de az ilyen maintanence taskoknak en szoktam egy adatbazis tablat csinalni, ahova logolom, hogy mikor futott. Mashol erre van jobb megoldas?
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.

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 :).
13

Valoban

janoszen · 2013. Feb. 26. (K), 19.36
Azt a problemat pedig nem oldja meg, hogy ROR uzemelteteshez erto rendszergazda talan meg kevesebb van, mint ROR-hoz erto fejleszto. Mindketto komoly hianyossag egy nagy cegnel, ahol a hosszu tavu strategia fontosabb, mint a gyors epitkezes.

Ezen felul pedig eljen a flamewar, had valaszoljak reszletesen. :)

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.


Ez orvendetes. En 1.8-as Rubyn futtatok Puppetet es kb. egy nap utan minden daemon memoriafogyasztasa 1 GB.

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.


Ha jol ertem, akkor ezzel elesel az oprendszer (automatikus/manualis) frissiteseitol?

Ezt lehet felreertem, de az ilyen maintanence taskoknak en szoktam egy adatbazis tablat csinalni, ahova logolom, hogy mikor futott. Mashol erre van jobb megoldas?


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.

Azert ha egy multi appos szerverrol beszelunk, akkor szerintem jobb ha apponkent kulon van a log, es nem egyben.


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

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


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

RoR-nál nem oldaná meg a

inf3rno · 2013. Feb. 26. (K), 19.47
RoR-nál nem oldaná meg a memória gondokat, ha bizonyos időközönként újraindítanád a daemonokat, mondjuk attól függően, hogy mennyi memóriát zabáltak fel?
16

Nem

janoszen · 2013. Feb. 26. (K), 19.50
Ha webes uzemeltetesrol beszelunk, alapvetoen megoldana, de eles uzemben nem rugdosunk csak ugy ujra daemonokat, mert lesz par masodperc kieses. A PHP-nak van erre megoldasa, hiszen tobb szalon fut es a szalak egy ido utan eltolva ujraindulnak. Mint irta a kollega, van most mar olyan ROR / futtato kornyezet, aminel ez meg van oldva, viszont rengeteg regi szoftver is letezik meg.

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

Aha, esetleg nem lehetne

inf3rno · 2013. Feb. 26. (K), 19.52
Aha, esetleg nem lehetne RoR-nál is úgy, hogy két ugyanolyan daemon fut párhuzamosan, aztán amíg az egyik újraindul, addig a másik átveszi a szerepét? (Nyilván ez egy kicsit gányolás így, de ha nincs más...) Nem is muszáj kettőt futtatni egyszerre, lehet olyat is, hogy amikor már sok memóriát megevett, akkor indítasz egy másik ugyanolyat, a jelenlegit meg lezárod, ha már átadtad az elérhetőségeit az újnak. Csak erlég homályos ismereteim vannak a daemonokról meg az üzemeltetésről, de szerintem ez megoldható lenne.
20

Van megoldas

janoszen · 2013. Feb. 26. (K), 19.55
Fent le van irva a megoldas, innentol kezdve szerintem targytalan a dolog. :)
21

Ok.

inf3rno · 2013. Feb. 26. (K), 19.58
Ok.
23

re

Greg · 2013. Feb. 26. (K), 20.15
Az ujabb Rails app szerverek pont igy csinaljak. Van master es worker process, es ujrainditasnal nincs kieses, mert elindit megegy workert es a regit akkor allitja le ha az uj mar teljesen felallt.
24

..

Greg · 2013. Feb. 26. (K), 20.18
Nem flamelni akarta, csak szivesen olvasom masok tapasztalatait, mert abbol tanulok :).
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.
28

GEM-ek

janoszen · 2013. Feb. 26. (K), 20.52
Es a GEM-ek? A Rubyban eleg ritkan van sechole, de a kismillio GEM-et kovetni azert nehezebb.
30

..

Greg · 2013. Feb. 26. (K), 21.01
A gem-ekkel ugyanez a helyzet. A ruby verziokezelok, kezelnek gemset-eket is. Az automatikus gem frissites szinten nem jo, mert lehet az appod felborul, ezert a teszteket mindenkeppen erdemes elotte lefuttatni.
A Rubyban eleg ritkan van sechole

Ritkan, de akkor nagy :). Most derult ki egy yaml sebezhetoseg ami nagyon sok rubygem-et erintett.
35

Arrol nem beszelve, hogy a

BlaZe · 2013. Feb. 26. (K), 23.31
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.)

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

ROR

janoszen · 2013. Feb. 26. (K), 23.50
A ROR alapbol elegge verbose es a konzolra verbose sajnos. A normalizalasarol itt talaltam egy leirast. Ami a Javat illeti, log4j-vel lehet confolni, bar azert ott is erolkodest igenyel, hogy a facilityk, log levelek, stb. normalisan atmenjenek syslogba.
11

Félreértés elkerülése végett:

kuka · 2013. Feb. 26. (K), 18.47
Félreértés elkerülése végett: nem civakodni akarok, csak érdeklődök.
PostgreSQL: Rendkivul stabil, kevesen hasznaljak a szigora miatt.
Ez alatt mit értesz? Nekem így hirtelen csak az ugrik be, hogy a PostgreSQL nem fogad el dátumtöredékeket mint a MySQL. De úgy érzem te ennél többre gondolhattál.
12

Igen

janoszen · 2013. Feb. 26. (K), 19.23
Igen, kb hasonloan mukodik a Post, mint a MySQL strict modeban. Egyebkent pont erre gondoltam a szigort illetoen. A stabilitas meg... szal a Post olyan adatmennyisegekkel megbirkozik, ahol a MySQL mar reg csodot mond.
25

„Strict mode” – köszönöm a

kuka · 2013. Feb. 26. (K), 20.31
„Strict mode” – köszönöm a kulcsszavat, holnap kiderítem miben áll. Lévén én inkább programozás szempontjából nézem őket, ez az adminisztrációs dolognak tűnő strict mode kimaradt. Ugyanezen nézőpontból a PostgreSQL tárolt eljárásai jobban megfogták a fantáziámat. (Főleg a Bash nyelvű tárolt eljárások lehetősége; természetesen nem valós használatra valóak, de amikor már olyant is lehet, akkor kevés van amit nem.)
26

Én is a pgsql hatására

inf3rno · 2013. Feb. 26. (K), 20.38
Én is a pgsql hatására fordultam az orm-ektől inkább a tárolt eljárások felé. Nagyon jó az a nyelv...
29

Strict mode

janoszen · 2013. Feb. 26. (K), 20.52
A strict mode-al az a baj, hogy az alkalmazasok 99.9%-a nincs felkeszitve ra, tehat kulon ugy kell fejleszteni.
33

Re:

Max Logan · 2013. Feb. 26. (K), 22.05
Mármint a MySQL „engedékeny módra” épülő alkalmazások (pl. holnap, webalkalmazás) hasalnak el a szigorú mód bekapcsolása után?
34

Igen, elég hamar. Nem

Hidvégi Gábor · 2013. Feb. 26. (K), 22.30
Igen, elég hamar. Nem vészesek a különbségek, egyszer majd írok róluk.
38

Error

janoszen · 2013. Feb. 26. (K), 23.56
Strict modeban a warningokbol error lesz. Igy peldaul ha egy mezobe ervenytelen adatot irsz (datum mezobe nem datum, tul hosszu string egy varchar mezobe), akkor a muvelet nem hajtodik vegre, hanem hibaval ter vissza. Itt egyreszt az erre fel nem keszitett alkalmazas adatot veszit, masreszt a belso mukodese felborul a varatlan hibatol. A mezohosszak miatt pl. plusz checkeket kell beepitened a programodba, stb.

Strict mode controls how MySQL handles input values that are invalid or missing. A value can be invalid for several reasons. For example, it might have the wrong data type for the column, or it might be out of range. A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition. (For a NULL column, NULL is inserted if the value is missing.)
39

Én eleve be szoktam építeni

inf3rno · 2013. Feb. 27. (Sze), 00.00
Én eleve be szoktam építeni validálást mezőhosszra, de szerintem mások is... Azt hittem normál módban is elszáll a mezőhosszak miatt...
56

MongoDB

gabesz666 · 2013. Feb. 28. (Cs), 00.09
a sebesseg illuziojat kelti

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.

kb annyira biztonsagos adattarolasra, mint egy oroszrulett.

Megmondom őszintén itt nem egészen értem mire gondoltál, de ami ezzel kapcsolatban eszembe jutott:
  • SSL-en keresztül is lehet mongohoz kapcsolódni
  • Az adatokat lehet titkosítani. Egyrészt nincs szétreklámozva a dolog, másrészt ez nincs benne alapból a mongoban.
  • (Ezen kívül van egy rakat tipp, hogy ne legyen az üzemeltetés annyira orosz rulett.)

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

Ami a legnagyobb előnye

Joó Ádám · 2013. Feb. 28. (Cs), 00.23
Ami a legnagyobb előnye szerintem az a schemaless doksi struktúra


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

Attól függ, hogy mi a

inf3rno · 2013. Feb. 28. (Cs), 00.48
Attól függ, hogy mi a feladat, van olyan, amihez jobb a mongo, mint a relációsak, meg van olyan amihez gráf adatbázis jó. Olyan is előfordulhat, hogy többet használsz egyszerre. Na mondjuk erről a témáról csak könyvet olvastam, gyakorlatban még ragaszkodom az sql-hez.
59

Értem én, de épp az volt a

Joó Ádám · 2013. Feb. 28. (Cs), 00.51
Értem én, de épp az volt a kérdés, hogy milyen konkrét feladatot oldott már meg vele valaki, aki elsőkézből számol be róla ;)
60

Huhh, na az jó kérdés :P

inf3rno · 2013. Feb. 28. (Cs), 05.57
Huhh, na az jó kérdés :P Egyik haverom fog most mérnöki tervet írni, ami erről szól, ott média adatbázist kell építeni azt hiszem. De még ő is csak az elején van. Éles mongodb alkalmazásról nem tudok. Neo4j-ről tudok, ami egy programozós cégen belüli projekthez tartozik, mondjuk azt meg nem lehet összehasonlítani egy mongodb-vel, mert teljesen más kategória...
61

Példa

Poetro · 2013. Feb. 28. (Cs), 09.57
Mi az Examiner.com hírportálnál használtuk a MongoDB-t, és igen szép teljesítményt nyújtott. A lényeg, hogy naponta több ezer cikk születik, és ezekhez több millió oldalletöltés történik. Egy cikket MySQL-ből felépíteni rengeteg JOIN illetve további lekérdezés alapján lehet csak, ugyanakkor Mongoból azonnal egy objektumot kapok, amiben minden benne van, amire szükség van a megjelenítéséhez. Természetesen ez sokszor redundáns tárolást is jelent, de áldozatokat kell hozni a sebesség oltárán. Akit érdekel az erről szóló előadás, amit akkori kollégám tartott, tekintse meg.
62

..

Greg · 2013. Feb. 28. (Cs), 10.09
Mi az Examiner.com hírportálnál használtuk

Ebbol arra kovetkeztetek, hogy mar nem hasznaljatok. Publikus a valtas oka, es hogy mire valtottatok?
63

Már nem vagyok ott, így nem

Poetro · 2013. Feb. 28. (Cs), 10.13
Már nem vagyok ott, így nem tudom mit használnak most. De valószínűleg nem váltottak.
65

Memcache?

janoszen · 2013. Feb. 28. (Cs), 10.37
Kerdes: miert nem hasznaltatok ehhez mondjuk Memcachet?
66

Használtunk

Poetro · 2013. Feb. 28. (Cs), 10.45
Használtunk memcached-et is, de az objektumok egyes tulajdonságai változtak, amiket vissza kellett írni adatbázisba, valamint még volt sok más szempont ami miatt nem lehetett mindent cachelni.
85

Ugyanez nem lett volna

Joó Ádám · 2013. Feb. 28. (Cs), 17.51
Ugyanez nem lett volna megoldható relációs adatbázisban denormalizált sémával?
88

Nem igazán

Poetro · 2013. Feb. 28. (Cs), 18.19
Elemenként tömböket és objektumokat nehéz tárolni szerializáció nélkül. Pl. lekérdezem a főoldalon megjelenő cikkeket. Ez ugye MongoDB esetén egy lekérdezés, ami visszaad cikkeket, amik objektumok. Vannak tömb tulajdonságú elemei, mint a címkék, objektum tulajdonságú elemei, mint a szerző. És természetesen ez minden cikkre, ami megjelenik.
91

..

Greg · 2013. Feb. 28. (Cs), 18.33
Relacios adatbazisnal ez egy join-al ugyanugy elerheto, ha jol ertem. A cimkeket postgres-el pl tudod array mezoben tarolni.
93

Lehet nem volt túl jó a

Poetro · 2013. Feb. 28. (Cs), 18.42
Lehet nem volt túl jó a példa. Egy cikknek tegyük fel, lehet több szerzője, akiknek van egynél több tulajdonsága. A cikkhez tartozhatnak képek, videók, amiknek van legalább 3 tulajdonsága. És a címkéknek is egynél több tulajdonsága van, ezt nem tudom kezeli-e a PostgreSQL.
95

re

Greg · 2013. Feb. 28. (Cs), 18.47
Postgres hstore-al lehetne a cimkeket menteni. A tobb szerzo az egy query-vel mondjuk nem oldhato meg amennyire en tudom.
83

Nem volt még

gabesz666 · 2013. Feb. 28. (Cs), 17.05
Nem volt még ilyen alkalmazás, de nekem sokkal szimpatikusabb ez az elv, azaz hogy objektumokat objektumonként is tároljunk. Tipikus példa és mindenhol felmerül egy blog posztjainak leképezése objektumokba. Persze ez nyilván megoldható sql-el is, ahogy szinte minden más is, ami mongo-val. Szóval szerintem ez erősen szubjektív téma, nekem objektumok tárolására valahogy természetesebbnek tűnik a mongo-s megközelítés a relációs megközelítéssel szemben.
86

Ha arra gondolsz, hogy egy

Joó Ádám · 2013. Feb. 28. (Cs), 17.54
Ha arra gondolsz, hogy egy objektum tipikusan csak hivatkozik a tulajdonságaira, és nem magában foglalja azokat, akkor a relációs megközelítés sokkal közelebb áll hozzá, mint a dokumentumalapú.
112

egy példa

blacksonic · 2013. Feb. 28. (Cs), 21.41
Ügyfeleknek vannak regisztrált felhasználóik, akik rendelkeznek alap tulajdonságokkal, mint név, város, ország stb. E mellé felvehetnek még tetszőleges számú egyedi tulajdonságot. Ha tulajdonságok és tevékenységük alapján szűrni akarsz az oldalon akkor jól tud jönni egy dokumentum alapú tárolás.
(olyan sok tulajdonság ami egy sorban nem fér ki, és 1M-10M nagyságrendű adattal ügyfelenként)
114

Erre való az EAV.

Joó Ádám · 2013. Feb. 28. (Cs), 21.51
Erre való az EAV.
136

lassú

blacksonic · 2013. Már. 1. (P), 13.20
nagyon lassú queryket eredményez a joinolások miatt
64

MongoDB

janoszen · 2013. Feb. 28. (Cs), 10.31
Azert ezt igy minden MongoDB rajongo figyelmebe ajanlom: Broken by Design: MongoDB Fault Tolerance

MongoDB v2.0 will consider a write to be complete, done, finito as soon as it has been buffered in the outgoing socket buffer of the client host.


Tehat ha szerencsed van, megvan az adatod.
68

Ez azért meredek. Nincs

BlaZe · 2013. Feb. 28. (Cs), 11.46
Ez azért meredek. Nincs valami kapcsolója ennek a viselkedésnek a megváltoztatására? Elég lábon lövős ez így...
69

Pont ez a baj

janoszen · 2013. Feb. 28. (Cs), 12.01
Pont ez a baj: A mongo attol "gyors", hogy szarik az adat biztonsagara. Az elmult evekben jonehany NoSQL gyartonak ra kellett jonnie, hogy a halozatnak es az elosztott rendszereknek van nehany torvenyszerusege, amit egyszeruen nem szabad figyelmen kivul hagyni. Ezt a helyzetet tovabb rontja a teny, hogy labor korulmenyek kozott egeszen maskepp viselkednek ezek a rendszerek, mint a valo eletben. Pl. ha a lokalis interfacen csinalsz kapcsolatokat (127.0.0.1), a TCP stack radikalisan maskepp fog viselkedni, mint egy remote gep eseten. (Nemreg fejlesztettem egy elosztott rendszert es igen kemeny kuzdelem volt.) Ennek eredmenyekepp az tortenik, hogy eles uzemben az ilyen torvenyszerusegeket figyelmen kivul hagyo rendszer az ido 98%-aban jol fognak viselkedni, az esetek 2%-aban meg nezel, hogy most WTF tortent.

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

Valóban így van... a 2.0-nál

gabesz666 · 2013. Feb. 28. (Cs), 12.13
Azért azt ne felejtsd el, hogy ez a 2.0-ra vonatkozik. Hamarosan a 2.4-es verzió jön ki. Az általad említett probléma a 2.2-es verziótól már nem létezik. Azt is vegyük figyelembe, hogy ez egy egész friss technológia (2009-ben volt az initial release) pl. egy mysql vagy postgresql-hez képest. Valóban van hova fejlődnie, de én nem írom le ilyen gyorsan a technológiát, mert van pár hiányossága/megkötése. Azt gondolom egyébként, hogy mindegyik adatbázisnak megvan a maga helye a piacon. Nem jó mindenre a mongo sem, de érdemes tudni róla, mert sok hasznos dolgot tud!
78

Friss

janoszen · 2013. Feb. 28. (Cs), 13.30
Akkor nekem egyetlen kerdesem lenne: Mi az a use case, amire ajanlanad a Mongo DB-t? En nem egeszen latom.
98

Ha sok olyan objektumod van,

inf3rno · 2013. Feb. 28. (Cs), 19.30
Ha sok olyan objektumod van, amiknek nincs egymással konkrét kapcsolata, pl cikkek, blog bejegyzések, felhasználók, stb... Az objektumokat nehéz úgy újrahasznosítani benne, mint mondjuk egy sql adatbázisban. Ha komplexebb kapcsolatrendszer van, akkor már jobb egy sql vagy egy gráf adatbázist használni.
104

Azért általában ezeket az

Joó Ádám · 2013. Feb. 28. (Cs), 19.59
Azért általában ezeket az önálló entitásokat összefüggéseikben kell kezeld (adott felhasználó cikkei).
106

Hasznaltad mar?

janoszen · 2013. Feb. 28. (Cs), 20.34
Hasznaltad mar erre a celra? Tesztelted azt, hogy mi tortenik gyenge halozat / hardveres kimaradas eseten? (Te hat pl. mi tortenik akkor, ha az egyik storage szerver diskjerol lehuzod menet kozben a SATA connectort mikozben masszivan sok adatot irsz bele?)
113

Az vicces lehet :d Egy dolog

inf3rno · 2013. Feb. 28. (Cs), 21.49
Az vicces lehet :d Egy dolog a gyakorlati alkalmazás egy meg, hogy elméletileg mire jó. Nem tudom, hogy mennyire kiforrott ez a technológia ilyen téren, de előbb, vagy utóbb biztosan az lesz.
124

Pont ezaz

janoszen · 2013. Már. 1. (P), 10.37
Van egy projekt itt nehany asztalra tolem, amiben kb 3000 merevlemez van. Na ebbol napi 2-3 megdoglik. Magyaran szolva a hardvermeghibasodas nem kulonleges esemeny, hanem napi rendszer.
137

állati

zzrek · 2013. Már. 1. (P), 13.35
Nagyon érdekes ezt hallani, ne válaszolj, csak magamnak mondom, hogy ilyen volumenű üzemeltetésnél biztosan az is jópofa lehet, hogy hogyan lehet megállapítani, hogy a meghajtó lett-e hibás, vagy a vezérlő, kábelérintkezés, esetleg valamilyen (meghajtó) szoftver(bug) okozza és írogat értelmetlenségeket a merevlemezre. Valamint kérdés, hogy megfelelő hardveres összeállítás (pl. raid) képes-e ezeknek a problémáknak a felsőbb szintekre jutását kiküszöbölni...
139

Szolgaltato

janoszen · 2013. Már. 1. (P), 15.07
Ezek tobbnyire meghajto meghibasodasok, szoftveresen meg lehet allapitani, hogy a SATA/SAS csatlakozas hibas-e vagy maga a disk. Mivel brand gepekkel dolgoznak a sracook, a disk csere hotswap keretben zajlik es a datacenter uzemelteto vegzi. Ellenkezo esetben minimum egy ember teljes munkaidejet elvinne a jatek.
142

Nem túl magas ez az egy

inf3rno · 2013. Már. 1. (P), 20.58
Nem túl magas ez az egy ezrelék per nap? 3 év alatt teljesen kicserélődik az összes vinyó?
144

Jo lenne

janoszen · 2013. Már. 5. (K), 15.38
Jo lenne, ha nem igy lenne, de a gyakorlat ezt mutatja. :)
146

Milyen típusú vinyók? Nekem

inf3rno · 2013. Már. 5. (K), 16.56
Milyen típusú vinyók? Nekem seagate barracuda hardver miatt még sosem ment tönkre, van belőle 10+ éves is, mondjuk sokkal kevesebb futott át eddig a kezem alatt, mint nektek... Lehet, hogy magasabb darabszámnál már nem lenne ennyire fényes a statisztikája ennek sem.
157

IO

janoszen · 2013. Már. 6. (Sze), 11.08
Nem tudom, ha tudnam se feltetlenul mondhatnam el. Az meg nem ekvivalens hasznalat, hogy Te otthon tartod rajta a cuccaidat meg az, hogy egy szerverben 50-80% IO terheles kozott megy folyamatosan.
158

Ja így már világos, akkor

inf3rno · 2013. Már. 6. (Sze), 14.15
Ja így már világos, akkor valszeg az állandó nagy terhelés ami miatt könnyebben beadják a kulcsot...
128

Szubjektív

gabesz666 · 2013. Már. 1. (P), 11.13
Akkor nekem egyetlen kerdesem lenne: Mi az a use case, amire ajanlanad a Mongo DB-t?

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

MongoDB

HunNomad · 2015. Feb. 15. (V), 07.46
Gyorsaság

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

A MySQL 23 mp alatt keres ki

Hidvégi Gábor · 2015. Feb. 15. (V), 09.29
A MySQL 23 mp alatt keres ki egy rekordot WGS84 (decimal) koordináta alapján, a mongó megteszi 0.012 alatt
Ez nekem így nagyon gyanús – rendesen le van indexelve az a tábla? Csodák nincsenek.

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

Én a saját (és a környezetem)

kacsandiz · 2013. Feb. 26. (K), 21.04
Én a saját (és a környezetem) tapasztalataimat írnám le, főleg a PHP vonallal kapcsolatban.
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.
40

A PHP-nak van jövője

stan · 2013. Feb. 27. (Sze), 02.32
A PHP-nak van jövője, én ezt vettem ki a hozzászólásaitokból. Ez azt jelenti, hogy érdemes vele foglalkozni, érdemes rászánni az időt, hogy az ember alaposan beleássa magát. Tehát úgy érzem, hogy a jó nyelvet kezdtem el tanulni.

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

Most olvastam a napokban,

Greg · 2013. Feb. 27. (Sze), 09.41
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).

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
42

Mivel a weben a HTML

Hidvégi Gábor · 2013. Feb. 27. (Sze), 11.17
Mivel a weben a HTML sajátosságai miatt a backend és a frontend között elég szoros a kapcsolat, érdemes a HTML-ben és a Javascriptben is elmélyedni. Van az a mondás, hogy annyi ember vagy, ahány nyelven beszélsz. Jellemzően mindenhol alacsony a belépési szint, de több év kell, amíg elég tapasztalatot gyűjtesz ahhoz, hogy profinak vallhasd magad.
43

Amerika

janoszen · 2013. Feb. 27. (Sze), 11.24
Mint Magyarorszagrol elkoltozott honfitarsad azt javaslom, hogy ha valahova koltozol, akkor ne a penz miatt tedd, hanem azert mert az adott helyen akarsz elni. Ha az 1.6M Ft brutto, akkor nem kell Amerikaig menni, itt a szomszedban is siman meg lehet ennyit keresni, ha jo vagy.
44

..

Greg · 2013. Feb. 27. (Sze), 11.52
Ezzel en is egyetertek. Angliaban peldaul jol lehet keresni, es igazabol az elet sem rossz, ha kibirod meleg nyar nelkul. En szeretem a nyarat, ugyhogy nekem ilyen szempontbol annyira nem jo.
Ha jol dolgozol, akkor pedig egy ido utan szinte barhol el tudod erni az anyagiakban tamasztott igenyeidet.
46

Összetett

Hidvégi Gábor · 2013. Feb. 27. (Sze), 12.00
úgy érzem, hogy Magyarországon nem igazán fizetik meg az embert
Ha jó vagy, (arányosan) minden országban jól megfizetnek, mert szerencsések vagyunk a szakmánkkal, itt jó pénzeket adnak még itthon is. Nem egy szakmabelit ismerek Magyarországon, akiknek millió körüli nettó keresete van, és még azt sem mondanám, hogy annyira különleges az, amit csinálnak.

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.
Sok földed, réted, malmod van és tömérdek jobbágyod, édes fiam. Ezeket mind ez a haza adta neked. Hát már most azon gondolkozz egész életedben, hogy te mit adtál azért a hazának? Törlessz, fiam, örökké törlessz, csinálj egy rovást a szívedben, és ha egyszer odajutnál, hogy te többet adsz neki vissza ezért, akkor az én porló csontjaim azt megálmodják.
Mikszáth Kálmán - Különös házasság
45

A jövőben valami nagy cégnél

kacsandiz · 2013. Feb. 27. (Sze), 11.53
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.


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 elég kitartó vagyok, és jól tudom a nyelvet, akkor előbb utóbb biztosan találok egy munkahelyet.


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.

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.


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

Ha a pénz számít, akkor én

inf3rno · 2013. Feb. 27. (Sze), 15.03
Ha a pénz számít, akkor én inkább java-t tanulnék a helyedben, többet lehet keresni vele, mint php-vel, igény meg állandóan van rá (nyilván mert nehezebb megtanulni, mint egy php-t).
49

Ehhez annyit tennék hozzá,

kuka · 2013. Feb. 27. (Sze), 15.31
Ehhez annyit tennék hozzá, hogy ha Java+pénzes állás kombinációra hajtasz, akkor számíts rá, hogy bizonyos szinten túl Oracle Certification elvárásokkal fogsz találkozni.
50

Én nem ismerek annyira sok

inf3rno · 2013. Feb. 27. (Sze), 15.34
Én nem ismerek annyira sok embert ebben a szakmában. Akiről tudom, hogy java-ban dolgozik, és sokat keres, annak már megvolt a pénzes állása mielőtt ilyesmiket megcsinált volna... Egyébként az a gyanúm, hogyha eljutsz egy olyan szintre, akkor ezek a vizsgák nem jelentenek akadályt.
52

Én ilyenről nem tudok. Biztos

BlaZe · 2013. Feb. 27. (Sze), 19.14
Én ilyenről nem tudok. Biztos örülnek neki mindenhol, de nem attól ért valaki valamihez, hogy van-e róla vizsgája. Ráadásul ezek a vizsgák brutál drágák tudnak lenni, nem mindenki akar annyit kifizetni érte. Tudni kell és kész. Azt megfizetik mindig, nyelvtől függetlenül. És olyan helyre kell menni dolgozni, ahol lehet tanulni, meg értékes tapasztalatot gyűjteni, akármelyik vonalat is válaszd. Van pár ilyen cég itthon azért.

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

A PHP-nak van jövője, én ezt

tgr · 2013. Feb. 27. (Sze), 20.28
A PHP-nak van jövője, én ezt vettem ki a hozzászólásaitokból.

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

Miért bizonytalan a PHP

kacsandiz · 2013. Feb. 27. (Sze), 22.49
Miért bizonytalan a PHP jövője?
67

A PHP egy "egydimenziós"

BlaZe · 2013. Feb. 28. (Cs), 11.32
A PHP egy "egydimenziós" nyelv. Értem ezalatt, hogy weben kívül igazán másra nem jó. A nagy áttörést az egyszerűsége, és gyakorlatilag az ellenfél nélkülisége hozta meg számára. Ez utóbbi az, ami kezd megváltozni. Lassan kinövik magukat a sokkal átgondoltabb és hatékonyabb, de még mindig nem pilótavizsgás webes fejlesztőkörnyezetek, a PHP pedig közben - érzésem szerint - rossz irányba indulva próbálja helyrehozni a nem épp jó nimbuszát. Ha nem jönnek ki hamarosan egy komoly redesignnal, szerintem nehéz helyzetben fogja találni magát a nyelv. Tény, hogy már vannak jó frameworkök hozzá, ez pl egy jó irány, de amíg pl egy minor verziófrissítéstől meg tud változni valaminek a működése, addig komoly rendszert én pl nem mernék rá építeni, legyen bármilyen rugalmas, és legyen bármilyen könnyű találni rá fejlesztőt.

Meg vannak az enginejében is buta hibák. Érdemes megnézni pl ezt:

<?php

class A{
	public function test(){
		var_dump( $this );
	}
}

class B{
	public function test(){
		A::test();
	}
}

echo 'PHP version: ' . phpversion();

echo '<pre>';

$a = new A();
$a->test();

A::test();

$b = new B();
$b->test();

echo '</pre>';

?>
Az eredmény:
PHP version: 5.4.6-1ubuntu1.1
object(A)#1 (0) {
}
NULL
object(B)#2 (0) {
}
Itt ugye kb egy "éjfél van, húzzál aludni, mert hülyeségeket csinálsz" exceptiont kéne kapni :) Ha már nem oszt ki az interpreter egy pörgőforgórúgást, hogy miért akarsz meghívni egy nem static metódust az osztályon... Ebbe egyszer belefutottam. Hajnalban végül rá is jöttem, hogy miért csinál tök mást a kód, mint szeretném. Azt most ide nem írom le, ami akkor kiröppent a számon :) Szóval vannak ilyen butaságai. Meg hát nem is egy kimondottan gyors nyelv... Tudom, hogy épülnek rá nagy rendszerek (sőt), ettől még ez tény.

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

Meg hát nem is egy

tgr · 2013. Feb. 28. (Cs), 12.08
Meg hát nem is egy kimondottan gyors nyelv...

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é.
72

gyorsaság

Hidvégi Gábor · 2013. Feb. 28. (Cs), 12.15
A node mennyivel volt gyorsabb átlagosan?
74

Nem gyorsabb

janoszen · 2013. Feb. 28. (Cs), 13.12
A Node nem gyorsabb de facto, hanem aszinkronabb. A mukodesebol adodoan egy szalon fut minden es amikor eppen nem hasznal CPU-t az egyik program, akkor a masiknak oda tudja adni. Ellene szol viszont, hogy amig egy felig kulturaltan megirt PHP/Java/stb programot tudsz tobb szerverre skalazni, a legtobb Node programot a memoriaban tarolas miatt nem.

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

Azért a szálindítás

Joó Ádám · 2013. Feb. 28. (Cs), 18.38
Azért a szálindítás és -váltás megspórolása és a natív kódra fordítás elég nyomós oka a sebességnek. A skálázás és a kódszervezés nehézségeivel viszont teljesen egyetértek.
76

Itt egy benchmark. Noha nem

BlaZe · 2013. Feb. 28. (Cs), 13.22
Itt egy benchmark. Noha nem korrekt :) Úgy volna illő, hogy nginx+php-val hasonlítsák, ne apache+php-val. Vagy a js-t a php-val, leválasztva az előtte lévő webszervert. Így azért megmérték, hogy egy WTC pályaautó csúnyán odaver egy sportos szedánnak a versenypályán :)

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

Az első, "Hello World"-ös

Hidvégi Gábor · 2013. Feb. 28. (Cs), 14.05
Az első, "Hello World"-ös példának semmi értelme, a másodiknak sem sok, nem valós életből vettek.

miszerint van-e értelme az asynchron megoldásoknak
Ott arról volt szó, hogy a node-féle aszinkron megoldásnak van-e értelme. Amit én megkérdőjeleztem, hogy minden feladatnál, ahol lehet, ott kell-e aszinkron módon programozni. Az mloc.js egyik előadása is pont erről szólt. Ahogy Janoszen Y Proclub is leírja a 74-ben, valamint én egy másik szálon, a node-ban az egyszálúság miatt a nagy projektek skálázhatósága nagyon problémás tud lenni.
82

Amit küldtem, az nem a

BlaZe · 2013. Feb. 28. (Cs), 14.19
Amit küldtem, az nem a problémáról szólt, és nem is a számokról. Amit érdemes észrevenni, az a kiegyensúlyozottság.

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

Teszt

Poetro · 2013. Feb. 28. (Cs), 17.47
Most találtam egy viszonylag friss tesztet, ami egy azonos szolgáltatást implementál MySQL kapcsolattal PHP és Node.js oldalon. Eléggé jelentős az eltérés.
96

Arról sajnos nincs

Hidvégi Gábor · 2013. Feb. 28. (Cs), 18.51
Arról sajnos nincs információ, hogy használ-e PHP gyorsítót, enélkül viszont nehéz ítéletet mondani.
100

Nem tartom valami sokra

inf3rno · 2013. Feb. 28. (Cs), 19.43
Nem tartom valami sokra ezeket a teszteket, láttam már nagyon sokszor olyat, hogy az egyik tesztben az egyik nyelvet hozták ki győztesnek, a másik tesztben meg a másikat, és mindig kb 10-100x -os eltérésekkel...
87

Illetve még annyi, hogy a

BlaZe · 2013. Feb. 28. (Cs), 18.04
Illetve még annyi, hogy a második elég valós életből vett példa, lefuttat egy queryt, és visszaböfögi jsonban :) Ilyet azért gyakran használunk. És mondjuk a korrektség kedvéért megjegyzi azt is, hogy itt inkább az apache volt a szűk keresztmetszet, nem a php. Szóval ez a grafikon a process-based és az event-driven webszerverekre volt igazából benchmark.

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

Skálázhatóság

Hidvégi Gábor · 2013. Feb. 28. (Cs), 18.43
Ott a két link, olvasd el.

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

Pont ez volt a lényege a

BlaZe · 2013. Már. 1. (P), 00.41
Pont ez volt a lényege a grafikonnak, amit linkeltünk Poetroval, hogy ez nem igaz. A process based cuccoknál van egy határ, ami fölött kb exponenciálisan kezd el nőni a terhelés, és a processek gyakorlatilag kiéheztetik egymást. Hiába adsz neki még procit, meg ramot, elfogy és kész. Mert kismillióan használják a limitált erőforrásokat. És zúzza a context switcheket, a lockokat stb. Abban igazad van, hogy nyilván egy darabig ez elég. De extrém terhelésnél az apache be fogja dobni a törölközőt, ahol egy event-driven cuccal még vígan elbír a vas, és még mindig ugyanazzal a sebességgel és megbízhatósággal működik.

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

Köszönöm

Hidvégi Gábor · 2013. Már. 1. (P), 11.18
Értem, tehát az Apache modell a context switchek erőforrásigénye miatt limitált. Akkor bizonyos esetekben jobb választás lehet az ngingx + php kombó, mert ott is legalább a webszerver és a kimenetet összeállító funkció el van választva, míg a node esetében nincs.

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

Értem, tehát az Apache modell

BlaZe · 2013. Már. 1. (P), 12.10
Értem, tehát az Apache modell a context switchek erőforrásigénye miatt limitált.

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

Egyszálúság

Poetro · 2013. Feb. 28. (Cs), 18.22
Az egyszálúságról meg annyit, hogy amikor én csináltam egy Node.js-es alkalmazást, akkor csináltam Node.js-ben egy load balancert, ami socketen keresztül kommunikált a további futó Node.js alkalmazásokkal, amik a tényleges választ szolgáltatták ezen a socketen keresztül. Ráadásul ez lehet Unix socket is, akár távoli gépen is, ami ugye a skálázódást segíti, valamint a stabilitáson is javít - ugyanis amíg megy a load balancer, addig az tudja figyelni, hogy az illető worker alkalmazás működik-e, és ha nem akkor indíthat egy újat.
97

Tobb melo

janoszen · 2013. Feb. 28. (Cs), 19.07
Azert ez jelentosen tobb melo, mint mondjuk egy FastCGI+PHP megoldas, ami hacsak nem hasznal lokalis fileokat, alapbol skalazhato sok szerverre. Plusz egy korrekt socket implementacio rengeteg melo (pl. dead peer detection, stb.)
101

http://lmgtfy.com/?q=nodejs+l

inf3rno · 2013. Feb. 28. (Cs), 19.47
http://lmgtfy.com/?q=nodejs+load+balancer
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.
107

HTTP

janoszen · 2013. Feb. 28. (Cs), 20.37
Bocsi, de ez nem oldja meg a problemat. HTTP load balancer millio van, de NodeJS-ben meglatasom szerint ket okbol szeretunk programokat irni:

  • Mert csak a JS-hez van szaktudasunk
  • Mert aszinkron kommunikaciot akarunk (pl. socket.io)


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

Nekem a google azt dobta erre

inf3rno · 2013. Feb. 28. (Cs), 21.59
Nekem a google azt dobta erre a socket.io-s témára, hogy redis-sel lehet skálázni:
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.
125

OK

janoszen · 2013. Már. 1. (P), 10.39
Nem azt mondtam, hogy nincs megoldas, de ez az alkalmazasod belso allapotanak a tobbi reszet meg nem viszi at. Ergo minden szinten vegig kell gondolnod (es tesztelned!), hogy nem felejtettel-e el valamit.
141

Ez miben más mondjuk PHP-ben?

tgr · 2013. Már. 1. (P), 18.42
Ez miben más mondjuk PHP-ben? Ha horizontálisan skálázol, ugyanúgy külső eszközre van szükség az állapot megosztásához (ha mazochista vagy és a default fájl-alapú sessiont használod, akkor NFS vagy valami hasonló, egyébként tipikusan memcached), és az ugyanúgy behozza a maga szopásait.
145

Default

janoszen · 2013. Már. 5. (K), 15.38
A PHP alapbol no-share elven dolgozik, nagyon keves dolog (pl. a session kezeles) az, ahol ossze fuggenek a szalak. Egy felig normalisan megirt PHP programot a session kezelo lecserelesevel ki tudod skalazni akar tobb szaz szerverre is. Ugyanez a NodeJS programok tobbsegere nem igaz, mert abbol indulnak ki, hogy egy fizikai szerveren futnak egyetlen processben, ahol mindenhez hozzafernek.
147

http://nodejs.org/docs/latest

inf3rno · 2013. Már. 5. (K), 17.03
http://nodejs.org/docs/latest/api/cluster.html

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

Ez nem jelenti azt, hogy

MadBence · 2013. Már. 5. (K), 17.48
Ez nem jelenti azt, hogy Neked is ebből kell kiindulnod.
156

Nyilvan

janoszen · 2013. Már. 6. (Sze), 11.07
Nyilvan nem, de plusz erolkodest kell beletenni a kodba, hogy eloszthato legyen. Nem tudom szebben mondani, NodeJS-ben ez (jelenleg) meg sok energiat kivani es a meglevo libraryket (socket.io, stb) sem lesz olyan egyszeru portolni egy majdani elosztott rendszert lehetove tevo API ala.
122

Since you want a push

inf3rno · 2013. Már. 1. (P), 01.23
Since you want a push application, you would probably use Socket.IO with RedisStore.

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

Vannak erre már kész

Poetro · 2013. Feb. 28. (Cs), 19.49
Vannak erre már kész megoldások, ha hazaérek összegyűjtök párat.
110

Kivancsi lennek

janoszen · 2013. Feb. 28. (Cs), 20.42
Kivancsi lennek, majd ha lesz egy kis idom, megizzasztom oket hogy egy szar halozaton mit produkalnak.
103

Plusz egy korrekt socket

Joó Ádám · 2013. Feb. 28. (Cs), 19.58
Plusz egy korrekt socket implementacio rengeteg melo (pl. dead peer detection, stb.)


Mit értesz socket implementáción? Illetve dead peer detection alatt?
108

Protokoll

janoszen · 2013. Feb. 28. (Cs), 20.38
Ha van egy hosszan tarto TCP kapcsolatod, ami nem lokalis gepen mukodik, akkor igen konnyen elofordulhat az, hogy a backend szerver ugy doglik meg, hogy Te errol semmilyen ertesitest nem kapsz, hanem csak irsz a socketbe, amig be nem telik a TCP window es utana varsz. Na erre az esetre vagy kell normalis timeout handling, vagy ha datastreamrol van szo, valamifele acknowledgement (last a socket.io protokolljat).
115

Ezt megkapom a kerneltől,

Joó Ádám · 2013. Feb. 28. (Cs), 21.59
Ezt megkapom a kerneltől, nem? Mind a timeoutot, mind például az E_PIPE-ot.
126

Haha

janoszen · 2013. Már. 1. (P), 10.42
Haha, ahogy azt elkepzelne az ember. Linux alatt lo interfacen megkapod az E_PIPE-ot. Halozaton nem E_PIPE-ot kapsz, hanem ha mazlid van, connection resetet. Ha nincs mazlid, varsz az RST packetra, ami nem jon meg mert elpusztult a tuloldal.
99

Már elég régóta lehet több

inf3rno · 2013. Feb. 28. (Cs), 19.41
Már elég régóta lehet több szálat használni nodejs-ben:
https://github.com/xk/node-threads-a-gogo
szóval én nem hivatkoznék az egyszálúságra...
105

Hajrá

Hidvégi Gábor · 2013. Feb. 28. (Cs), 20.15
Sok sikert kívánok hozzá! Helló, szemaforok, deadlockok és társaik!

The problem with threads
109

Link

janoszen · 2013. Feb. 28. (Cs), 20.41
Edit: Javitottam a linkedet.

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

Nem azért írtam, mintha

inf3rno · 2013. Feb. 28. (Cs), 22.02
Nem azért írtam, mintha kételkednék benne, hogy nodejs rosszul skálázható...
123

Találtam stackoverflow-on egy

inf3rno · 2013. Már. 1. (P), 02.21
Találtam stackoverflow-on egy ilyet:
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?
73

Az általam látott tesztekben

BlaZe · 2013. Feb. 28. (Cs), 12.23
Az általam látott tesztekben a node.js-t kivéve mindent ver.


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

Python?

janoszen · 2013. Feb. 28. (Cs), 13.13
pythonnál kicsit gyorsabb a php


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

Nem én mértem, erre utal az

BlaZe · 2013. Feb. 28. (Cs), 13.25
Nem én mértem, erre utal az írásom. Engem is meglepett kicsit, mert fordítva vártam. De ami igazán durva, az a scriptnyelvek futási sebességének aránya a c/java stb első pár nyelvhez képest.
79

Gyakorlati

janoszen · 2013. Feb. 28. (Cs), 13.50
Ezek a Benchmarkok semmilyen gyakorlati jelentosseggel nem birnak, mivel egyalgoritmus elvegzesenek teljesitmenyet merik. Ha webes szempontbol nezzuk, a PHP minden requestre bootstrapel, betolt, stb. amig a Python FastCGI modban futva eppen csak az oldalt szolgalja ki. Ha mas szempontbol nezzuk, akkor meg eleve nem relevans a kerdes, mert a PHP nem tud annyi fele feladatot elvegezni, mint a PHP.

Egyebkent ha erdekelnek az ilyen sebesseg / optimalizacio szeru jatszadozasok, ajanlom egy baratom szolgaltatasat, a beatmycode.com-ot.
80

Illetve egy kis infografika,

BlaZe · 2013. Feb. 28. (Cs), 13.55
Illetve egy kis infografika, ami a témához kapcsolódik, itt bár nem írja, hogy mi volt a teszt, de a python jött ki jobban belőle. Bő 1 éves, de azért érdemes átfutni.

Meg hát nyilván az ilyen laboratóriumi teszteket azért alapvetően a helyén kell kezelni...
159

nyelv vs. implementacio

dyuri · 2013. Már. 6. (Sze), 15.46
En nagyon nem szeretem egyebkent az ilyen osszehasonlitasokat, hogy melyik nyelv gyorsabb, a masiknal. Mert a nyelvnek nem tulajdonsaga a sebesseg, a VM-nek/forditott kodnak az.

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

Az általam látott tesztekben

Joó Ádám · 2013. Feb. 28. (Cs), 18.33
Az általam látott tesztekben a node.js-t kivéve mindent ver.


Az univerzális kvantor azért merész. Natív kódra fordított nyelveket is verne?
135

Mindent, amiben

tgr · 2013. Már. 1. (P), 13.20
Mindent, amiben webalkalmazást szoktak írni. Assemblyben biztos gyorsabb weblapokat lehetne csinálni, de valószínűleg mégse fognak.

(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.)
138

Azért C, C++, C#, Java-ban is

Poetro · 2013. Már. 1. (P), 14.48
Azért C, C++, C#, Java-ban is írnak webalkalmazást, amik azért jelentősen gyorsabbak, mint PHP. Több mint 10 évvel ezelőtt én is írtam C-ben.
111

Valóban vannak a nyelvnek

kacsandiz · 2013. Feb. 28. (Cs), 20.55
Valóban vannak a nyelvnek problémái, hibái, amelyek régebbi hozadékok. De a fejlesztők hajlamosak megfeledkezni egy dologról: alapvetően nem ők, a technológia, vagy a legújabb trendek határozzák meg az irányvonalat, hanem az üzleti oldal. A PHP jelenleg is egy egyszerűen tanulható és üzemeltethető nyelv, tele van PHP fejlesztőkkel a munkaerőpiac, rengeteg hoszting szolgáltató van, illetve kész megoldás, blogmotoroktól kezdve CMS-eken át ticket rendszerekig. Nem fogja ezeket senki hanyatt homlok eldobni számunkra belátható időn belül, hogy átálljon egy másik nyelvre.

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

Én sem tartom valószínűnek,

inf3rno · 2013. Feb. 28. (Cs), 22.04
Én sem tartom valószínűnek, hogy már meglévő php szolgáltatók csak úgy hirtelen átállnak egy másik nyelvre. Inkább azt a trendet látom, hogy az új nyelvek/technológiák támogatására új szolgáltatók jönnek létre.
119

De a fejlesztők hajlamosak

Joó Ádám · 2013. Feb. 28. (Cs), 22.18
De a fejlesztők hajlamosak megfeledkezni egy dologról: alapvetően nem ők, a technológia, vagy a legújabb trendek határozzák meg az irányvonalat, hanem az üzleti oldal


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 PHP jelenleg is egy egyszerűen tanulható és üzemeltethető nyelv


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.

tele van PHP fejlesztőkkel a munkaerőpiac, rengeteg hoszting szolgáltató van, illetve kész megoldás, blogmotoroktól kezdve CMS-eken át ticket rendszerekig. Nem fogja ezeket senki hanyatt homlok eldobni számunkra belátható időn belül, hogy átálljon egy másik nyelvre.


Milyen minőségben? Amint ez is fontossá válik, meglepően sokan dobják el hanyatt-homlok.

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.


Brainfuckban is, csak egyikünk sem akarja. Ez nem érv.

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.


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.

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?


Én például szoktam. Vagy már nem fontos a folyamatos fejlődés az IT-ban?
131

»A földből kinövő nyelvekről

Hidvégi Gábor · 2013. Már. 1. (P), 11.26
»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?«

Én például szoktam. Vagy már nem fontos a folyamatos fejlődés az IT-ban?
Amíg nincs konkrét megrendelés, addig szerintem nem érdemes túl sok energiát belefeccölni bármelyik újdonságba, főleg, amíg el nem éri az 1.0-t vagy le nem veszik róla a béta státuszt. Amíg a kezdeményezést mögött nincs meg a kritikus tömeg, addig játékszer marad, felelősen gondolkozva nem mondhatom a következő projektnél a megrendelőnek, hogy ezt a technológiát kell választani, mert ezzel az ő nyakába akasztom a felelősséget, ha egy-két éven belül megszűnik a támogatása a dolognak. Így max. marad a blogok olvasgatása, pár példaprogram futtatása, meg annak figyelemmel kísérése, hogy az, ami használható és terjed, és a megfelelő pillanatban váltani.
132

Kritikus tömeg?

Poetro · 2013. Már. 1. (P), 11.39
Az jelent valamit, hogy általában azonos mennyiségű, vagy több felhasználó van a Node.js IRC szobájában, mint a jQuery-jében?
133

Nem

Hidvégi Gábor · 2013. Már. 1. (P), 11.56
Számomra legalábbis nem mond semmit viszonyítási alap nélkül.
140

Nem az a lényeg, hogy tudod-e

Joó Ádám · 2013. Már. 1. (P), 17.07
Nem az a lényeg, hogy tudod-e majd a gyakorlatban hasznosítani. Minden nyelv tanít valami újat, formálja a szemléleted.
120

A példát amit írtál nem

BlaZe · 2013. Már. 1. (P), 00.00
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.

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

PHP

Hidvégi Gábor · 2013. Már. 5. (K), 12.04
Szerintem a PHP-ban két dolgon lehetne javítani, aminek nem lenne hatása a szintaktikára, a sebességre annál inkább:
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.
148

Én nem hiszem, hogy a null

BlaZe · 2013. Már. 5. (K), 17.34
Én nem hiszem, hogy a null terminated stringek miatt lenne lassú a php. A c is ezt használja, mégse tartjuk lassú nyelvnek :) Ez a "probléma" nagyjából ott jön ki, ahol hosszt kérdezünk le. A 255-ben limitált string hossz sokkal nagyobb gond lenne. Ha meg már több byte-on ábrázolod a hosszát, akkor a rövid stringeknél pazarolsz egy csomót. De szerintem egyik se igazán számít.

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?
150

Ez a "probléma" nagyjából ott

Hidvégi Gábor · 2013. Már. 5. (K), 18.39
Ez a "probléma" nagyjából ott jön ki, ahol hosszt kérdezünk le.
Amikor például két karakterláncot fűzöl össze, akkor le kell mérned a hosszukat, hogy tudd, hány bájt memóriát kell allokálnod. A jelenlegi tudásommal ez nagyon komoly problémának tűnik, hisz végülis a HTML (JSON, XML stb.) generálása csupa stringművelet.

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

+1

zzrek · 2013. Már. 5. (K), 19.29
Nekem sem tűnik túl okos dolognak a 0 terminated string, szerintem ezt még az ősidőkben találták ki, amikor a "string" az tényleg egy tetszőleges hosszú (szöveg)láncként volt értelmezve (távírók?). (A fájlok is hasonlóan voltak terminálva, gondolom a szalagos tároláshoz illeszkedve) További hátránya, hogy ugye null kódot nehézkesen tartalmazhat.
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.
152

Igazad van alapvetően,

BlaZe · 2013. Már. 5. (K), 23.14
Igazad van alapvetően, lassabb, ez nyilván nem kérdés. Heavy string műveleteket végülis c-ben se teljesen így csinálják.

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ú.
153

Ezt nem teljesen értem

Hidvégi Gábor · 2013. Már. 5. (K), 23.47
Mit és hogyan számol külön? Arra nem találtam utalást, hogy ha a változó típusa string, akkor a hosszát eltárolnák valahol, de persze ez nem jelenti azt, hogy nincs is.
154

Zend könyvtárát nézd a

BlaZe · 2013. Már. 6. (Sze), 00.30
Zend könyvtárát nézd a forrásnak.

zend.h

typedef union _zvalue_value {
	long lval;					/* long value */
	double dval;				/* double value */
	struct {
		char *val;
		int len;
	} str;
	HashTable *ht;				/* hash table value */
	zend_object_value obj;
} zvalue_value;

struct _zval_struct {
	/* Variable information */
	zvalue_value value;		/* value */
	zend_uint refcount__gc;
	zend_uchar type;	/* active type */
	zend_uchar is_ref__gc;
};

zend_operators.h

#define Z_STRVAL(zval)			(zval).value.str.val
#define Z_STRLEN(zval)			(zval).value.str.len
#define Z_STRVAL_P(zval_p)		Z_STRVAL(*zval_p)
#define Z_STRLEN_P(zval_p)		Z_STRLEN(*zval_p)
#define Z_STRVAL_PP(zval_pp)	Z_STRVAL(**zval_pp)
#define Z_STRLEN_PP(zval_pp)	Z_STRLEN(**zval_pp)
zend_builtin_functions.c

/* {{{ proto int strlen(string str)
   Get string length */
ZEND_FUNCTION(strlen)
{
	char *s1;
	int s1_len;

	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &s1, &s1_len) == FAILURE) {
		return;
	}

	RETVAL_LONG(s1_len);
}
/* }}} */
A többit már nem másolom be, mert túl hosszú lenne, a zend_API.c-ben találod meg a hiányzó részeket.

Azért azt meg kell hagyni, hogy ennél már láttam olvashatóbb kódot :)
155

Köszönöm

Hidvégi Gábor · 2013. Már. 6. (Sze), 08.51
Egy félreértés miatt máshol néztem.
160

Nem ugyanaz

Pepita · 2013. Már. 6. (Sze), 19.33
Azért ez távolról sem ugyanaz, mint a Pascal-féle megoldás.
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.
161

És ez miért jobb, mint a

Joó Ádám · 2013. Már. 6. (Sze), 22.24
És ez miért jobb, mint a fenti?
162

Mindennek van előnye és

BlaZe · 2013. Már. 7. (Cs), 11.48
Mindennek van előnye és hátránya is. A null terminated string előnye meg pl, hogy ha van egy stringed, amit szét akarsz darabolni, elég bevágni a nullákat a megfelelő helyekre és kész is vagy, a pascal féle megoldásnál meg foglalgatni kell, számolgatni stb. Illetve amit írtál is, hogy limitált a hossza. A foglalást meg lehet oldani értelmesebben is. Nyilván akkor meg a string műveletek sok allokációval járnak, de hát az élet kemény :)

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

Részben igaz

Pepita · 2013. Már. 8. (P), 03.12
null terminated string előnye meg pl, hogy ha van egy stringed, amit szét akarsz darabolni, elég bevágni a nullákat a megfelelő helyekre
Igen, ez igaz, viszont a null terminated string fontos tulajdonsága, hogy:
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.
a pascal féle megoldásnál meg foglalgatni kell, számolgatni stb.
Igen, kell foglalni. Egyszer, 256 (v. 65536) byteot (és persze nem neked, neki). Az általad idézett megoldásnál pedig ki kell számolni mindkét rész-string hosszát, ezeket az eredményeket is el kell tárolni, ugyanúgy le kell foglalni a szükséges terület+1 byte-ot (még egy increment művelet!), vagy fel kell szabadítani a csonka, helyben hagyott rész után következő területet.
Illetve amit írtál is, hogy limitált a hossza.
Ez így van.
de hát az élet kemény :)
Ezzel maximálisan és igen keményen egyetértek! :)

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.)
nem kell végigmászni a memórián, amíg megtalálod a nullát, hanem ott van szépen egy int-ben
Ezt nemigazán értem, akkor minek van ott a 0? Ha nincs, akkor ez nem null terminated string. Ha pedig nem kell felhasználáskor ellenőriznie a PHP-nek, akkor felesleges byte. (De ekkor is külön helyen van a hossz és az adat.)
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.)
164

Egy dolgot szögezzünk le. A

BlaZe · 2013. Már. 8. (P), 11.34
Egy dolgot szögezzünk le. A null terminatedséget nem a memóriában tárolás definiálja, hanem a függvények, amik ilyen változóval dolgoznak. Innentől kezdve a hozzászólásod nagyja szerintem nem aktuális :) Van egy pointere, meg egy száma, hogy a pointer mögött mekkora halom byte-tal kell foglalkozni. Ez a legtöbb esetben így működik.

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

Valóban

Pepita · 2013. Már. 8. (P), 19.35
Innentől kezdve a hozzászólásod nagyja szerintem nem aktuális
Így igaz, ma már csak azt jelenti, hogy nincs korlátozva... Bocsi.

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! :))
169

Ismerek olyat, akitől

BlaZe · 2013. Már. 9. (Szo), 10.27
Ismerek olyat, akitől interjún valószínűleg itt megkapnád a kérdést, hogy akkor vázolj fel egy olyan stringműveletet, amihez tudnod kell a hosszát, és megoldod 1 memóriaciklus alatt :)
170

No comment

Pepita · 2013. Már. 10. (V), 22.13
Ezt a végtelenségig lehetne folytatni, de nekem elfogyott a kedvem-időm rá, bocs.
165

Egyébként próbáltál már PHP

tgr · 2013. Már. 8. (P), 11.52
Egyébként próbáltál már PHP stringbe 0-ás bájtot beszúrni és megnézni, mi történik? Kb. 10 karakterleütés, lehet, hogy érdemes megtenni, mielőtt nagyobb volumenben elkezdi az ember osztani az észt, hogy mi hogy működik és mennyire hatékony.
166

Ido

janoszen · 2013. Már. 8. (P), 12.17
Basszus gyerekek, nektek tul sok idotok van. :D
167

+1, én sem értem, hogy ezen a

inf3rno · 2013. Már. 8. (P), 12.18
+1, én sem értem, hogy ezen a nullstring-en hogy lehet ennyit vitatkozni :D
47

Én úgy látom

prom3theus · 2013. Feb. 27. (Sze), 13.26
Én úgy látom, hogy itthon a senioroktól elvárt tudás és a fizetés mértéke nincsen összhangban már. Nem tudom, hogy ez külföldön mennyire tendencia, de úgy látom, hogy idehaza a cégek (a nagyobbak is) előszeretettel meglovagolják azt, hogy a munkaerőpiacon nagy a kínálat PHP fejlesztőből, ezért sok és komoly elvárásokat támasztanak míg a másik oldalon jellemzően nem honorálják ezt az elvárt szintnek megfelelően. Lényegében nagyon kevés olyan senior fejlesztőt ismerek itthon, akik az érzékelhetően nagyobb tudásuk és tapasztalatuk mellett érzékelhetően többet keresnének egy középhaladónál vagy haladónál (a senior a saját skálámban a haladó fölött van).
51

Igen, mondjuk az viszont már

kacsandiz · 2013. Feb. 27. (Sze), 15.48
Igen, mondjuk az viszont már egy másik téma, hogy a szakmai tudáson felül mennyire tudja magát eladni az ember.
127

Kapcsolódó link

BlaZe · 2013. Már. 1. (P), 11.03
Kapcsolódó link, bár kicsit más nyelveket hasonlít, mint az itt taglaltak. De kiemelném az utolsó 2 mondatot:
Being a true polyglot, meaning developing in multiple languages during the same project, may soon become a requirement. We will likely see more evidence of this when we look at the web and scripting languages in the next job trends installment.

És úgy az egész utolsó bekezdést érdemes megrágni.
130

Ez nem csak

inf3rno · 2013. Már. 1. (P), 11.22
Ez nem csak programnyelveknél, hanem adatbázisoknál is így van; a http://pragprog.com/book/rwdata/seven-databases-in-seven-weeks-ben legalábbis ezt írják.