- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nem is tudtam, hogy volt Microsoft által támogatott PHP kiadás. Ezekszerint volt olyan is, aki PHP-s szörnyet Windowson hosztolt? Hogy ebben a kombinációban mi a jó, azt fel nem foghatom, de azért szomorú vagyok, hogy csökken a diverzitás már megint.
- A hozzászóláshoz be kell jelentkezni
Rengeteg ilyen van. Ha jol emlekszem a joomla-ba is toltak penzt meg regen. De valoban fura :)
- A hozzászóláshoz be kell jelentkezni
Annyira nem. Van egy csomo olyan PHP cucc, hogy OLAP kockakkal kell dolgozzon, es az majdnem kizarolag Windowsrol erheto el csak, a Linuxos MS SQL kliens (par eve meg) nem (volt) alkalmas ezek kezelesere sajnos. Ezen felul van egy jo kazal win-only tool, amihez igy relative konnyen lehet egy JSON/XML/SOAP API-t biztositani. Lattam mar sok ilyet, ha nincs C/C# tudas a cegben, ez a legkonnyebb ut.
- A hozzászóláshoz be kell jelentkezni
Akkor mashogy mondom: en sok ilyet lattam, fokent kis cegeknel. De van 1-2 nagyobb hosting ceg is ahol igy mukodnek, pl a forpsi-nal.
- A hozzászóláshoz be kell jelentkezni
Vagy Windowson fejlesztett.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Ezt most vesszek meg, ha értem. Mi a baj a PHP-vel? Főleg a 7.4-gyel, ami egyáltalán nincs elavulva, meg a megjelenő 8.0-val? Nem hogy örülnének, hogy valaki még a szutyok nyílászárós rendszerükön használná. Nyilván eddig is linuxon, BSD-n volt érdemes használni, ez nem vitás, de így csak egyszerűen megszüntetni a támogatását egy ilyen modern és népszerű nyelvnek, az agyrém kategória. Ennyi erővel a webszervereket se támogassák, mert minek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Szerintem játssz el úgy egy fél évet a C#/.NET Core combo-val (igen, megy linuxon is, mi több fejleszthetsz is rá, Pl. egy Visual Studio Code-dal), aztán utána visszatérünk erre a modern és népszerű nyelv dologra. Rég fejlesztettem PHP-re, de azért hírekből követem a nyelv fejlődését, és egy-egy mérföldkő után mindig az jut az eszembe, amikor anno még a szocializmusban a Trabant 6 voltos helyett 12 voltos akkumlátort kapott. :-)
- A hozzászóláshoz be kell jelentkezni
Kösz, de inkább passzolom az MS technológiákat, még akkor is, ha mennek Linuxon. Azt értem, hogy a saját platformukon a saját szutykukat próbálják inkább tolni, ez valahol érthető, de kicsit túlzás, hogy ekkora nyelvet, mint a PHP nem támogatnak. Mert értem, hogy most a JS frameworkök meg a Rust, stb. a menő, aköré van hype építve, de azért a PHP még mindig van annyira népszerű, hogy nem lehet leírni. Trabanthoz hasonlítani szerintem elég durva.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Rühellem, hogy ezt leírom, de az igazság az, hogy C# és a VS jó. Ettől függetlenül webre maradok a a LAMP-nál.
- A hozzászóláshoz be kell jelentkezni
A C# nem annyira webre valo. Ha valami, akkor inkabb a VB.NET valo arra, de inkabb az se. A PHP-nak way alacsonyabb a beleposzintje.
- A hozzászóláshoz be kell jelentkezni
A C# nem annyira webre valo. Ha valami, akkor inkabb a VB.NET valo arra, de inkabb az se.
???
Ezt fejtsd ki, légyszi. :D
- A hozzászóláshoz be kell jelentkezni
Toroltem a hozzaszolas veget, mert nem tudom PC modon megfogalmazni, de az a lenyeg, hogy a PHP-hoz kepest a .NET sokkal nehezkesebb, sokkal tobb kod egy hello world-nel barmennyivel is bonyolultabb oldal osszerakasa. Nem konnyebb mondjuk nullarol C#/ASP.NET -et tanulni, mint mondjuk Java/Springet, cserebe az utobbi lenyegesen tobb szabadsagot ad a futtato platform tekinteteben. Felre ne ertsd, a C# onmagaban egy nagyon jo kis nyelv, de szemely szerint sokkal inkabb hasznalnam mikroszervizek, userland toolok, jatekok, barmi egyeb fejlesztesere, mint webalkalmazasok keszitesere. Nyilvan itt elsosorban a "standardizalt" okoszisztema teszi nehezkesse, nem maga a nyelv. A VB.NET nyelvkent es okoszisztemakent is picit konnyebben tanulhato, sokkal kifejezobbnek erzem, cserebe persze nem olyan elegans, mint a C#, de valahol kompromisszumokat kell kotni. ASP.NET szinten csak par peldat lattam ra, szerintem meltatlanul alulertekelt nyelv.
Johetnek a kovek.
- A hozzászóláshoz be kell jelentkezni
Hát, én nem értem, mit mondasz. Elég sok dolgot sikerült szerintem most összekeverni, eddig arról volt szó, hogy a VB.NET alkalmasabb a webes fejlesztésre, mint a C#. Hogy jön ide a Java? :)
- A hozzászóláshoz be kell jelentkezni
Toroltem a hozzaszolas veget, mert nem tudom PC modon megfogalmazni,
Szerencsére itt MÉG nem kell erre törekedni, de persze, sose lehet tudni, hogy mit hoz a jövő.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egészen pontosan 0 különbség van a használt API-kban, ha C#-ban vagy ha VB.NET-ben írsz ASP.NET (Core) alkalmazást.
És a tapaszalat meg pont az, hogy amennyivel nehézkesebb, annyival megbízhatóbban tudsz haladni egy statikusan típusos nyelvben, szemben a PHP-vel. (3 éve ASP.NET Core-s microservicek írásával foglalkozok, előtte sok-sok évig PHP-ban ítam webalkalmazásokat. Kössz, nem sírom vissza.)
Megjegyzem, egyik kolléga, aki Pythonban írt mindenféle számolgatós dolgot, jutott ugyanerre a következtetésre, hogy hiába egyszerűbb az elején gyorsan haladni a Pythonnal, hosszú távon jobban járt volna karbantarthatóság és miegyéb szempontjából egy .NET-tel (Vagy Java-val).
- A hozzászóláshoz be kell jelentkezni
Ez a passzolom a MS technológiákat dolog, úgy 20 éve még menõ volt, ma inkább ciki. A Rust pedig soha nem volt, és szerintem nem is igen lesz a PHP versenytársa. Viszont nem árt, ha az ember nem ragad be nyakig egy-egy nyelvbe, platformba, technológiába, és nem köt vérszerzõdést egyik programnyelvvel vagy platformmal sem.
- A hozzászóláshoz be kell jelentkezni
20 évvel ezelőtt forradalmi tisztánlátás volt. Ma már bárkinek alap, aki nem szemellenzős. A Rust-ot csak példának írtam, mert most nagy a hájpja. Azzal egyetértek, hogy sose szabad leragadni egy nyelvnél, ha elavul, haladni kell a korral, nem szabad hozzá a végtelenségig ragaszkodni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Úgyis jönni fog valaki, hogy ezért meglincseljen, de a PHP-nál csak jobb technológiák jutnak eszembe MS ökoszisztémán belül és kívül is. Mondom ezt úgy, hogy C-ben írt CGI alkalmazáshoz is kellett már nyúlnom. :)
- A hozzászóláshoz be kell jelentkezni
A C-ben írt CGI legalább ötvözi a nehezen fejleszthetőt a rosszul teljesítővel :-).
- A hozzászóláshoz be kell jelentkezni
Miközben egyébként mást nem is lett volna szabad elterjedni hagyni.
- A hozzászóláshoz be kell jelentkezni
Mert minden egyes kéréshez egy új processt indítani nem bloat és erőforrástakarékos megoldás. Bravo. :)
- A hozzászóláshoz be kell jelentkezni
Alá tudnád támasztani?
- A hozzászóláshoz be kell jelentkezni
Nem. Csak vicceltem.
Najó: IMHO a CGI minden egyek query kiszolgálásához új processzt indít. Az azért eléggé költséges, nem? Ha egyszerű a lekérés, akkor a teljes kiszolgálással összemérhető, akár több is lehet a processzindítás/lezárás költsége.
A nehezen fejleszthető részből annyi igaz, hogy ha tényleg C, akkor annak a magasabb szintű nyelvekhez képest van egy 2-3-szoros lassító tényezője. Viszont legalább nem rejti 85 réteg el a fejlesztő elől azt, hogy mi történik valójában :-)
Ha az oldalak között állapot (session) vagy kommunikáció is van, akkor valami IPC mechanizmus is kell. Ez megint lassabb és komplexebb lesz, mint ha egyetlen szerver processznek a memória állapotában lenne minden oxigén eltárolva.
- A hozzászóláshoz be kell jelentkezni
"IMHO a CGI minden egyek query kiszolgálásához új processzt indít. "
True
IMHO a php is alabol ezt teszi/ ezt tette.
Ha valami accelarator van akkor persze nem feltetlen..
Ahogy manapsag elnezem a webappok teljeseitmeny adatait, egy hatrannyal indulo CGI C nyerhet sebessegben,
es erroforras nem zabalasban.
De inkabb FastCGI -t javasolnek, vagy webserver extension irasat ,
vagy from scratch service ..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
> vagy webserver extension irasat
Jó kis C-ben írt aszinkron IO-val, green threadekkel vagy korutinokkal megvalósított nyers template-eken alapuló weboldal. Meg tudnám közelíteni a processzor RAM sávszélességét :-) Néha álmodozom ilyenről, de eddig nem jött szembe a feladat, ahol szükség volna rá...
- A hozzászóláshoz be kell jelentkezni
"IMHO a CGI minden egyek query kiszolgálásához új processzt indít. "
TrueIMHO a php is alabol ezt teszi/ ezt tette.
Atlagos config: pre-forkolt apache processzek amiben be van mar toltve a PHP apache modul es arra var, hogy csinalhasson vegre valamit.
- A hozzászóláshoz be kell jelentkezni
Ha a CGI jól teljesítene, akkor nem létezne a FastCGI protokoll.
- A hozzászóláshoz be kell jelentkezni
VB6.0? IE? Azert a PHP-t meg nagyon sokaig kene visszafejleszteni, hogy ezeket alulmulja. (ha aktualis tech kell, akkor VB .Net mar csak korlatozottan valo kukaba)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
A PHP legfrisebb verzióját hasonlítjuk össze a 98-as VB 6.0-al?
- A hozzászóláshoz be kell jelentkezni
Az még so-so, de a PHP-t hasonlítjuk össze az IE-vel? :)
- A hozzászóláshoz be kell jelentkezni
MS okoszisztemanak az is resze, es elegge hulladek. Amugy odairtam, hogy ha aktualis kell, akkor VB .Net, elvileg maig fejlesztik.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
De a VB .NET-nek köze nincs már a 6.0-ás Visual Basichez. Az már csak egy pimpelt C#, maximum sötétben messziről nézve két liter whisky után hasonlít a két nyelv. :)
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
- A hozzászóláshoz be kell jelentkezni
Epp azert irtam, hogy az mar csak korlatozottan szar. Keszseggel elismerem, hogy meg az is fejlodik.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ejnye, kolléga!
A PHP-t már legalább 10 éve le kéne sajnálnod, mert bár még támogatott, de rég elavult™ technológia és vannak sokkal modernebb™, trendibb alternatívái, amikben nem kell annyi kódot írni és jóelőre átgondolni, hogy mit akarsz csinálni, elég csak egy kényelmes babzsákon agilisan pötyörészni az idealista menedzsered által feltervezett feladatot. A megspórolt munkát pedig majd sokszorosan megfizetik helyetted a felhasználók +1 CPU maggal, +8 GB memóriával és a villanyszámlában. Dehát az kit érdekel, sőt jót is tesz az innovációnak™ és a fejlődésnek™, amire ugye mindenképpen™ szükség™ van, amúgy is a fejlesztés drága™, a hardver olcsó™.
- A hozzászóláshoz be kell jelentkezni
" A megspórolt munkát pedig majd sokszorosan megfizetik helyetted a felhasználók +1 CPU maggal, +8 GB memóriával és a villanyszámlában. "
Attól függ, mi az alternatíva. A PHP gyorsabb mint a python vagy a ruby, kb. hasonló a javascripthez, viszont jóval lassabb mint a java vagy a .NET.
Mondjuk ez még PHP 4.7, a 8.0 gyorsulhatott. De a PHP-t szerintem leginkább azért szeretik, mert olcsó hozzá a fejlesztõ, és egy tányér levesért kapsz hozzá szervert, plusz ott van egy rakás CMS és kész webshop, hogy lehetõleg az olcsó fejlesztõre se kelljen költeni.
- A hozzászóláshoz be kell jelentkezni
A stílus miatt nyomtam egy plusz 1-et, de annyit súgnék, hogy a gyengén típusos nyelvek - amilyen a PHP is - egyáltalán nem annyira hatékonyak.
A statikusan típusos nyelvek esetén végrehajtható egy rakás optimalizálás, ami miatt közel natív sebességű program fordítható belőlük. Ilyen a .NET (C#), Java, illetve tudtommal a Rust is. És természetesen ilyen a C és a C++ is, sőt ott még Garbage Collector sem áll a fejlesztő útjába :-).
A dinamikusan típusos nyelvek esetén, amilyen a Python, Ruby, JavaScript, stb viszont ezt nem lehet megtenni. Lényegében az van, hogy a legtöbb esetben a metódushívások, mező elérések esetén nem lehet elkerülni a név szerinti map-ből keresgetést. Sajnos ennek elvi korlátja van, hiába tettek bele közel végtelen sok munkaórát a JavaScript engine-ek optimalizálásába, ez a hátrány soha nem dolgozható le. (Ha be van vezetve a típusosság, és azt következetesen betartják a fejlesztők, és azt ki tudja aknázni a JIT compiler az más, de a projektek nagyon kis része ilyen.)
Ja, és a PHP alatt is Garbage Collector van, tehát ebből a szempontból sem jobb, mint a Java, vagy a .NET.
Ebben az esetben tehát a babzsák a PHP fejlesztőknél van, az ő programjuk lesz az erőforráspazarló™ modern™ megoldás™.
Ettől még igaz lehet, hogy a Java, vagy .NET fejlesztők gyakran óriási bloat-tengert állítanak elő, ezzel nem akarok vitatkozni. De a hiba nem a nyelvben van, hanem abban amit az eszközzel létrehoztak.
Hogy anekdotikus érvelést is adjak: egyszer írtam egy kis Java+Jetty alapú mini-weboldalt, amiben egy mini webchat-et valósítottam meg, illetve egy képre tudott több felhasználó egyszerre rajzolni. A PHP fejlesztő ismerősöm csak kamillázott, hogy hogy tudtam ilyen gyorsra csinálni? Pedig nem is gondolkodtam optimalizáláson, csak éppenhogy összeütöttem egy példaprogramot.
Valójában a nyers PHP is lehetett volna hasonlóan gyors, csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét. És ez is minden nyelvre igaz.
És igen, hallottam, hogy a Facebook is PHP-ban íródott. Éppen ezért ők is vért hugyoztak, hogy az interpretert részben compiláltra cseréljék, és optimalizálják. Ez csak azt mutatja, hogy az eszköz adta 1-10-100x-os nagyságrendő lassulás még mindig ellensúlyozható azzal, ha maga a program jól van megírva és nincsen benne skálázódási probléma (amikor a tárolt adatok számával rosszul szorzódik a végrehajtási idő).
- A hozzászóláshoz be kell jelentkezni
sőt ott még Garbage Collector sem áll a fejlesztő útjába
Azért hidd el, egy pár millió soros szerver app esetén már örülni fogsz, ha az "utadba áll"
A dinamikus típuskezelés sem azért fáj elsõ sorban mert hogy lassú, hanem mert az egy határozottan szárazabb, biztonságosabb érzés,
ha tudod hogy a függvényed product paramétere egy termék osztály és nem egy termék id, mert 3 éve egy külföldi kolléga aki anno fejlesztette
nem teljesen tartotta be a névkonvenciókat. Vagy nincs olyan, hogy 24 helyrõl osztállyal hívják, de a 25. helyrõl id-val. És az sem hülyeség, amikor a típusra kattintva el tudsz menni a definíciójához, és már látod is, hogy mibõl is áll az a nyomorult Product osztály. A legszebb persze az, amikor az ORM annotációkat generált az entitáshoz, hogy az intellisense tudja, hogy mibõl kell(ene) állnia az entitásnak. Ami szép, az szép...
csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét
Csak a helló világon túl elõbb-utóbb mindenhol összefúj a szél valamiféle frameworköt, hogy ne kelljen a kereket állandóan feltalálni. Ennek aztán sok elõnye van: a nagy frameworkök azért eléggé battle-tested cuccok, ami a Pityuka bété egyedi keretrendszerére nem biztos, hogy igaz. Másrészt, ha a Pityuka bétének kell egy újabb ember, az egyedi keretrendszerét sok-sok hónap alatt fogja csak betanulni az új polgár, és olyat szinte biztos, hogy nem fog találni a piacon, aki az egyedi keretrendszerét ismeri. Ez az egyik véglet. Középen van a PHP ahol minden fûcsomó mellett fejlsztenek egy frameworköt, és nyilván nem sok van aki mindet profi szinten ismeri, így vagy kisebb a felhozatal, vagy ismét csak te fizeted amíg az illetõ megtanulja az általad használtat. És van a .NET vagy a Java a fix framework-kel, ahol ha felveszel egy programozót akkor az a keretrendszert már tuti ismerni fogja, csak a te kódodat kell megtanulnia.
Ilyen apróbb különbségekbõl több havi fizu megspórolható, abból pedig sok-sok áramot lehet venni.
- A hozzászóláshoz be kell jelentkezni
Azért eléggé leegyszerűsített ez a PHP vs .NET. Pontosabb lenne a PHP5.6 vs PHP7.x vs .NET vs .NET Core.
A PHP7.x-ben a típusok kezelésének lehetősége sokban változott. Szerintem mindegyik nyelv közelít egy kicsit a másikhoz, a jó bevált dolgokat átemelik egyikből a másikban.
- A hozzászóláshoz be kell jelentkezni
>> sőt ott még Garbage Collector sem áll a fejlesztő útjába
> Azért hidd el, egy pár millió soros szerver app esetén már örülni fogsz, ha az "utadba áll"
Félig vicc akart lenni :-). Normál alkalmazások esetén csakis segít a GC, imádom. Webes környezetben nem tudok olyat elképzelni, ahol útban lenne. Mondjuk úgy hallottam, hogy volt egy átmeneti időszak, amikor nagyon nagyok voltak a RAM méretek, de nem tudott párhuzamos működést a GC, és akkor probléma volt a stop-the-world működés. (Engem nem érintett, nem foglalkoztam ilyen méretű alkalmazásokkal, most meg már tudtommal sokat javult a helyzet.)
De fejlesztek néha statikus allokációval működő kiszámítható válaszidejű, illetve kiszámíthatóan soha nem leakelő dolgokat is C-ben, annak a területnek is megvan a szépsége. Ott útban volna a GC.
- A hozzászóláshoz be kell jelentkezni
> A dinamikus típuskezelés sem azért fáj elsõ sorban mert hogy lassú, hanem mert az egy határozottan szárazabb, biztonságosabb érzés,
100%-ban egyetértek, a fentebbi kommentemben csak a teljesítmény aspektusra fókuszáltam.
- A hozzászóláshoz be kell jelentkezni
> csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét
> Csak a helló világon túl elõbb-utóbb mindenhol összefúj a szél valamiféle frameworköt, hogy ne kelljen a kereket állandóan feltalálni.
Ez is igaz, de az állításomat nem cáfolja. És biztosan vannak teljesítményben is jól teljesítő keretrendszerek is, a tipikus esetre általánosítottam, amikor egyetlen "Hello World!" oldal betöltéséhez egy teljes keretrendszer összes osztályát meg kell mozgatni, és valamiért 10-100x tovább tart, mint egy bare-metal megvalósítás.
- A hozzászóláshoz be kell jelentkezni
feladathoz az eszközt.
ha egy 'hello world' oldalhoz valaki zend, symphony, laravel vagy akármi keretrendszert használ, az idióta.
ha egy ennél bonyolultabb feladathoz nem használ ilyesmit, az mazohista .)
de így sem fenékig tejfel az élet; pl a smarty eleinte borzasztóan nem állt kézre. a symphonyban most a twig nem áll kézre: nem hasonlít a smartyhoz és nem hasonlít a nyers phphez sem. A sima php html template meg ilyesztően hasonlít a 20 évvel ezelőtti - ma már üldözendő - zsinór php cuccokhoz, egy kis html, egy kis php, megint egy kis html; egy bazi nagy katyvasz az egész. De legalább nosztalgikus érzésket kelt bennem :)
- A hozzászóláshoz be kell jelentkezni
En mostanaban gondolkodtam, hogy valahogy kene egy kis PHP template alapu template motort irni, ugyanis bekapcsolt short_open_tags mellett a PHP-ban mukodik a <?= $foobar ?> jellegu megadas is, ami mar majdnem Smarty szintjere viszi a dolgot. Csak persze megint nincs idom semmire se.
- A hozzászóláshoz be kell jelentkezni
> PHP template alapu template motor
Dobpergés... Ami maga a PHP :-)
- A hozzászóláshoz be kell jelentkezni
Ez 5.4 ota hasznalhato short_open_tags allapotatol fuggetlenul!
- A hozzászóláshoz be kell jelentkezni
"Ja, és a PHP alatt is Garbage Collector van, tehát ebből a szempontból sem jobb, mint a Java, vagy a .NET."
Mármint, amikor véget ér a script futása?
- A hozzászóláshoz be kell jelentkezni
Úgy tudtam, hogy van benne. Nincs?
- A hozzászóláshoz be kell jelentkezni
Elsősorban referencia számolgatás van, a ciklikus hivatkozásokra van egy GC: https://www.php.net/manual/en/features.gc.collecting-cycles.php
Kikapcsolható, ha nagyon akarod, de egyébként csak akkor fut, ha már túl sok dolog [darabszámra] van a heapen, amiket refcountinggal nem sikerült felszámolni.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
Ami ugye a legnagyobb problema a nyelvvel, hogy request-response alapon mukodik, es ezt kikuszobolendo mindenfele dologgal kell korbe hackolni. Persze ezert is szeretik/hasznaljak sok helyen, mert barmelyik nem teljesen agyhalott tud benne kodot irni, mert a szamitogepekhez nem igazan kell erteni. Az allapot kerdese meg le van tolva a db-be, oszt amig a db birja szabadon lehet skalazni. nincsenek szalak, memoria-kezeles, allapotok, stb.
- A hozzászóláshoz be kell jelentkezni
Ertem, hogy mit akarsz mondani, de ez nem a nyelv hibaja, hanem az angoloke :)
- A hozzászóláshoz be kell jelentkezni
A webbel semmi gond nem lenne, ha nem alkalmazásplatformként akarnák használni, hanem annak, aminek szánva lett.
- A hozzászóláshoz be kell jelentkezni
Igen, ez misuse ... De van, hogy orulok ennek.
Bar en a csak a kolleganak akartam kiemelni, hogy ez nem a PHP hibaja, amit irt.
- A hozzászóláshoz be kell jelentkezni
Hat ki mase? Erdekes Javaban is lehet HTTP protokollon HTML-t kiszolgalni. De attol meg nem inditunk uj processzt minden kereshez. A nyelv designek semmi koze a transport layerhez vagy a kimenet tartalmahoz (marmint PHPnal van koze, de errol nem az angolok tehetnek :D). Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme. De, hogy azota mi szol mellette?? Azon kivul, hogy eldobsz egy kovet es eltalalsz egy PHP fejlesztot meg, hogy felpattintasz egy wordpresszt es a vilag osszes problemajara megtalalod a megoldast a pluginek kozott. Szerintem meg Chuk Norris sem tudta megszamolni a plugineket pedig mar visszafele is elszamolt vegtelentol.
- A hozzászóláshoz be kell jelentkezni
De attol meg nem inditunk uj processzt minden kereshez.
Ezt nem tudom honnan vetted. Kb. mindenki Apache prefork + mod_php -t hasznal, igy nem indul minden egyes requestnel uj process.
Ami ugye a legnagyobb problema a nyelvvel, hogy request-response alapon mukodik
A nyelv designek semmi koze a transport layerhez vagy a kimenet tartalmahoz (marmint PHPnal van koze, de errol nem az angolok tehetnek :D). Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme.
Nem ertem mit akarsz mondani, hogy mi a konkret problemad... HTTP-n jon egy keres szerver atadja a szerencsetlen PHP-nak majd a visszakopott valaszt a szerver visszadja a kliensnek. Mi az a nagy nyelvi design hiba a mirol beszelsz? Mi az, hogy a nyelv request-response alapon mukodik? Az a problemad, hogy a response utan megy a levesbe minden?
Lattam mar kezdoket Spring Boot + Hibernate-el jatszadozni. Koklerek mindenhol vannak :)
Ha a WP javaban lenne megirva es jottmentek irnanak plugineket hozza, ugyanolyan szar lenne mint most.
- A hozzászóláshoz be kell jelentkezni
Szerintem rosszul tudod. Nagy terhelésű helyeken inkább az fpm a preferált. Főleg, hogy ilyen oldalaknál az Apache helyett is gyakran nginx van, plusz az fpm működése sokkal jobban finomhangolható.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Szerintem rosszul tudod.
De mit? Ha az Apache mod_php vs nginx-re gondolsz, a statisztikak szerint meg nem vette at az uralmat, de valoban nem sok kell neki. Atlag user telepit maganak egy LAMP-ot.
FPM eseten is alapbol dinamikusan vannak kezelve a processek, ha jol emlekszem alap configban amit a php szallit 10 process indul.
- A hozzászóláshoz be kell jelentkezni
Kb. mindenki Apache prefork + mod_php -t hasznal, igy nem indul minden egyes requestnel uj process.
Erre reagáltam, hogy nem mindenki azt használ.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Valoban, az picit tulzas volt :)
- A hozzászóláshoz be kell jelentkezni
Nem, az konkretan hulyeseg volt. Ma mar apache moge is inkabb FPM-et raknak, csak hat a statisztikaban az is Apache-nak latszik, es olyan 2000 ota sulykolja mindenki, hogy a ServerSignature az Off legyen, vagy valami minimalis, az expose_php meg fixen off, emiatt persze nagyon torzul a statisztika, sok szervernel nem lehet megallapitani a mod_php jelenletet egyertelmuen.
A legjobb pelda erre, hogy a cPanel is suPHP-rol FPM-re valtott a tobb PHP verzio tamogatas erdekeben, noha a frontenden ugyanugy Apache fut.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy igazad van. De nem ez volt a mondanivalo lenyege. Plesk is pl. nginx-et proxynak hasznalja apache fele, asszem.
- A hozzászóláshoz be kell jelentkezni
"nem indul minden egyes requestnel uj process" van valamifele ujrahasznositas. De pl megnezed az FPM configot talasz benne ileneket:
static - a fixed number (pm.max_children) of child processes
dynamic - the number of child processes are set dynamically based on the following directives. With this process management, there will be always at least 1 children.
Szoval lehet hangolgatni, meg jatszadozni vele. Ebben megkovetem magam, nem _feltetlen_ indul uj process. De van amikor igen, beallitas kerdese valoban.
"Az a problemad, hogy a response utan megy a levesbe minden?" Igen, hogy nincsenek shared resourcek requestek kozott. Ami jo buli amig mywebpage.php-t kell kiszolgalni shared hostingrol, de amint bonyolultabb a domain lehet minden requestnel ORM-et epiteni, meg classokat loadolni (a leglassabb komponenserol a szamitogepnek), (syntaxist ellenorizni, bytekodot forditani,) db kapcsolatokat epitgetni, meg fetchelni a db-bol mindent, stb.
Aztan mindenfele hackolassal/modszerrel persze ezeket meg lehet kerulni, de azok mar mind a hibas koncepcio hozomanyai.
Mennyivel egyszerubb, amikor megvannak a db kapcsolatok, fel van epitve az ORM, be van toltve a diskrol minden ami az alkalmazasnak kell, bejon egy keres, ha kell indiunk egy _szalat_ (nem processt!) es csak ugy siman kiszolgaljuk a kerest.
Es akkor eloszottt tranzakciokrol, utemezett feladat vegrehajtasrol, tobbszalusitasrol, non blocking io, async, event driven dolgokrol meg nem is beszeltunk (igen vannak megoldasok, de mikor kinyitoda motorhaztetot vegul kulon processeket fogsz talani szalak helyett).
"Koklerek mindenhol vannak" igen, es nem allitotam az ellenkezojet, es a WP-t is mint elonyt hoztam fel :D
- A hozzászóláshoz be kell jelentkezni
"Az a problemad, hogy a response utan megy a levesbe minden?" Igen, hogy nincsenek shared resourcek requestek kozott. Ami jo buli amig mywebpage.php-t kell kiszolgalni shared hostingrol, de amint bonyolultabb a domain lehet minden requestnel ORM-et epiteni, meg classokat loadolni (a leglassabb komponenserol a szamitogepnek), (syntaxist ellenorizni, bytekodot forditani,) db kapcsolatokat epitgetni, meg fetchelni a db-bol mindent, stb.
Mennyivel egyszerubb, amikor megvannak a db kapcsolatok, fel van epitve az ORM, be van toltve a diskrol minden ami az alkalmazasnak kell, bejon egy keres, ha kell indiunk egy _szalat_ (nem processt!) es csak ugy siman kiszolgaljuk a kerest.
Abszolut igazad van, szebb es jobb, de ennek ugye ara van. Illetve azt is gondolom, hogy van ennek sok elonye is, peldaul az, hogy nem hasznaljak esz nelkul. Az nem veletlen, hogy a joomla, wp es baratai PHP-ban irodtak.
Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme. De, hogy azota mi szol mellette??
Ez megint a szerszam a feladathoz esete. Arra kell hasznalni amire valo. Ha kvantifikalhato elonyt hoz valami (akarmilyen szinten technikai, HR, penzugy, license, support, lifespan ...), akkor azt a technologiat kell hasznalni. Sok szemszogbol lehet megvizsgalni a dolgot. Lehet peldaul azt mondani, hogy az esetek tobbsegeben nem zabal annyit. Olcsobb olyan fejelsztesekhez, ahol tudod, hogy a project 4 ev mulva megy a kukaba.
Ha csak annyi az elony, hogy XY jobban erzi magat, mert ugy "szep" az keves.
- A hozzászóláshoz be kell jelentkezni
true, ezert nem mindegy az ember melyik platformot valasztja megtanulasra. Es nyilvan ha az a PHP, akkor olyan projekten fog dolgozni, ami a PHP adottsagaira van optimalizalva, olyan emberekkel fog egyutt dolgozni, akik szinten ezeket az adottsagokat kedvelik/ertik, olyan lesz a fizetese, es ennek megfeleloen alakul a piaci versenyhelyzete. Es persze van ertelmes engineering PHP korul is, sot a nagy PHP sikersztorik is vannak (mondjuk azok nem is vanilla PHPt hasznalnak egyebkent de mindegy), de a nagy atlagban.
En pl PHProl valtottam par ev utan tortenetesen Javara. Es a hol hostuljuk kerdes atalkult a hany gepen fusson-ra (es nem a hitvany teljesitmeny miatt, hanem a magas req/sec miatt), ami rengeteg fejlodesre adott lehetoseget. Vagy pl rogton akkora projekteken talaltam magam, hogy minden nap mast kellett csinalni, es megszunt a (uj projekt, regisztracio, blog, forum, hirek, cms admin) loop. Sajnos a 20adik regisztracios form fejlesztesbol mar nem tudtam annyit tanulni mint szerettem volna.
- A hozzászóláshoz be kell jelentkezni
Valoban. Szerintem is a PHP-t ez a hozzalas lengi korul. PHP vs Java dologba azert nem erdemes belemenni szerintem, mert a PHP egy script nyelv a Java meg egy oriasi software platform, mas kategoria.
Egy bank valoszinuleg nem fog hasznalni mondjuk PHP-t a banki feluletehez. Ha valamit hosszu tavon fenn kell tartani, mission critical akkor ott megfizetik a tervezest, a tudast es a jol elvegzett munkat.
Van aki marad a PHP-nal es kiszolgalja azt a reteget, nincs azzal semmi baj.
- A hozzászóláshoz be kell jelentkezni
"lehet minden requestnel ORM-et epiteni, meg classokat loadolni"
Nem tudom olvastad-e a 7.x, 8.x lehetőségeit, sok új szolgáltatást kapott. Preloading, JIT, Type Hint, Strict type mode, ...
- A hozzászóláshoz be kell jelentkezni
Ezekrol hallottam, nem most vitazok eloszor ebben a temaban :D
A class reloadingrol ennyit
- In order to preload files, you need to write a custom PHP script
- Changes made to preloaded files won't have any effect, until the server is restarted
"Strict type mode" gyakorlatilag eltorli a visszafele kompatibilitast, mert ahhoz mindent az elejetol ugy is kell megirni vagy futas kozben kapcsolgatni, raadasul runtime derulnek ki a turpiszsagok (fixme)
"JIT" experimental
En hiszem, hogy a PHP nagyon jo volt valamikor, meg azt is elhiszem, hogy nagyon jo lesz valamikor.
- A hozzászóláshoz be kell jelentkezni
> Az allapot kerdese meg le van tolva a db-be, oszt amig a db birja szabadon lehet skalazni. nincsenek szalak, memoria-kezeles, allapotok, stb.
Ugye nem mostanaban kodoltal PHP-ben? Erdemes lenne utananezni, a shared resource-ok problemajat az APCu megoldja (nem annyira nativ, mint egy SHM, de az ORM-es szornyetegektol, amit emlitettel, fenyevekre van), vannak benne szalak (az persze mas kerdes, hogy webes kornyezetben mennyi ertelme van hasznalni). A memoria kezeles kb az egyetlen, amivel nehezebb vitatkozni, minosithetetlen fos sajnos az a resze a runtime-nak.
Nem mondom, hogy a PHP hibatlan, de nem teljesen ertunk egyet a hibak listajaban.
> amig a db birja szabadon lehet skalazni
Ez kb minden nyelven irt alkalmazasrol elmondhato, es en ezt nem latom feltetlenul rossznak. Nagyon sok esetben pont az a problmea, hogy az alkalmazasfejlesztok nem kepesek felkeszulni a horizontalis skalazasra, feltve orizgetnek mindent a memoriaban, aztan ha a load balancer miatt a user sessionje hirtelen masik gepre kerul (barmiert), akkor csodalkoznak, hogy nem allapot, hanem konkretan lofasz sincs rola, de jott egy ervenyes session. Az a legjobb, ha minden DB-ben van, abbol kevesebb baj szarmazik, amit raadasul nem a fejleszto dolga kezelni.
- A hozzászóláshoz be kell jelentkezni
Kicsit utannaneztem, es talaltam is egy ticketet magatol a szerzotol:
krakjoe commented on 15 Feb 2019
|
Sok joval kecsgtet, foleg a broken by design resz :) https://github.com/krakjoe/pthreads/issues/929 Na ennyit a PHProl meg a tobbszalusagrol. A tobbi szar extension meg kb mindd processzekkel operal.
"de nem teljesen ertunk egyet a hibak listajaban" ami nem is baj. Szerintem egy hibaja van a PHPnak, hogy letezik meg 2020ban.
"abbol kevesebb baj szarmazik" nem tudom biztos hallottal mar elosztott cachekrol, meg hasonlo finomsagokrol, amikkel nem kell minden keressel megkuldeni az adatbazist. Amit emlitesz az a tipikus hozzaallas a PHPn nevelkedett szakertokhoz. Inkabb hagyd az egeszet, te ne foglalkozz semmivel, mert abbol csak a baj lesz. Szoval megbocsass, de jol skalazodo stateless alkalmazast mindenki tud fejleszteni (mar ameddig a db birja, aztan hivjak a kulsos mysql szakertot, hogy csinaljon valamit a db-vel, mert megdoglik az egesz cucc. lattam ilyen nem egyszer meg ketszer).
- A hozzászóláshoz be kell jelentkezni
.NET (CLR) és Java (JVM) ugyanúgy JIT-telt, mint bármilyen dinamikusan típusos nyelv. A nyelv amiből a bytecode fordult lehet statikusan típusos, de az azt futtató runtime dinamikusabb, lásd pl. InvokeDynamic, illetve A First Taste of InvokeDynamic.
Ezzel párhuzamba állítva a mai JS runtimeok is JIT-telik a kódot, valamint típusinformációkat rendelnek a dinamikus adatstruktúrákhoz, lásd pl. Shapes and Inline Caches, illetve The story of a V8 performance cliff in React.
- A hozzászóláshoz be kell jelentkezni
A bytekód is statikusan típusos, legalábbis C# alatt biztosan.
Vegyünk egy ilyen kódot:
int i = 0;
while(i<10)
i++;
Ebből ez az IL kód lesz:
IL_0000: ldc.i4.0 // Push 0 of type int32 onto the stack as int32.
IL_0001: stloc.0 // Pop a value from stack into local variable 0
IL_0002: br.s IL_0008 // Brach to target
IL_0004: ldloc.0 // Load local variable 0 onto stack.
IL_0005: ldc.i4.1 // Push 1 onto the stack as int32.
IL_0006: add // Add two values, returning a new value
IL_0007: stloc.0 // Pop a value from stack into local variable 0
IL_0008: ldloc.0 // Load local variable 0 onto stack.
IL_0009: ldc.i4.s 10 // Push 10 onto the stack as int32, short form.
IL_000b: blt.s IL_0004 // Branch to target if less than, short form.
IL_000d: ret // Return from method, possibly with a value.
Na, ez így nem túl szép, viszont elég típusos.
Viszot a belőle fordított assembly:
xor eax,eax
loop0: inc eax
cmp eax,0Ah
jl loop0
ret
Más kérdés hogy a C#-ban lehet olyasmit csinálni ami nem ilyen szép, de bizony a dolog elég statikusan típusos.
- A hozzászóláshoz be kell jelentkezni
Nem úgy értettem, hogy teljesen eltűnnek a típusinformációk. Inkább a referenciatípusok kezelését érdemes megnézni, a linkelt A First Taste of InvokeDynamic bejegyzés is ezt teszi.
- A hozzászóláshoz be kell jelentkezni
Ritka jó hozzászólás az, amit írtál. Persze a mostani OKJ-s "egértologatós programozók" sosem fogják érteni.
- A hozzászóláshoz be kell jelentkezni
Ez most melle ment hajbazer. :(
Egyreszt azert vannak framework-ok PHP-ra is (Zend), hogy ne kelljen ugyanazt a komponenst (authentikacio, authorizacio, perzisztencia, stb.) ujra es ujra feltalalni vagy ahogy te irod atgondolni. Atgondolni ugysem fogod, mert hataridod van es a feladatra fogsz ezek helyett koncentralni ami egy csomo hibalehetoseget es kevesse hatekony kodot fog eredmenyezni.
Masreszrol a Java/.NET-hez kepest a PHP kanyarban sincs ha performanciarol van szo.
- A hozzászóláshoz be kell jelentkezni
Nincsen baja az MS-nek a PHP-val.
A 7.4-et támogatni is fogják EOL-ig.
Itt arról van szó, hogy az MS nem fog külön erőforrásokat fektetni abba, hogy a PHP Windows-os verziójába fejlesszen. Attól még lesz a PHP-nak Windows-os kiadása, csak az MS nem ad hozzá támogatást, nem fogják javítani a Windows specifikus dolgokat. Ezt mind rábízzák teljesen a közösségre, akik szeretnék még Windows-on használni a PHP-t.
Nincs itt most különösen látnivaló.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
pont ugyanígy látom. egy vállvonással kezelhető a dolog.
- A hozzászóláshoz be kell jelentkezni
> Nincsen baja az MS-nek a PHP-val.
vs
> lesz a PHP-nak Windows-os kiadása, csak az MS nem ad hozzá támogatást
Itt azert erzek nemi ellentmondast. Eleve, az IIS is tartalmazott tobbe-kevesbe nativ PHP supportot egy ideje, azzal, hogy visszaleptetik a nyelv tamogatasat, siman bekerult a lehetosegek korebe az, hogy megint lehet majd hakkolni mint regen, hogy mukodjon IIS-en is a PHP-s webalkalmazas.
Raadasul a Microsoftnak vannak a legkepzettebb Windows mernokei, a Microsoft neve a contributorok/tamogatok kozott rengeteget jelentene.
En egyebkent komolyan nem ertem, egyfelol a MS probal nyitni az opensource vilag fele, de masfelol meg ilyen lepeseket foganatosit. Nagyon ambivalens az uj OSS politikajuk, nem latom at.
- A hozzászóláshoz be kell jelentkezni
Mármint azon kívül, hogy igazából 0 előnyt ad, cserébe rengeteg hátrányt hoz egy Java, ASP.NET (Core), stb.-höz képest, ha egy pistuka ottlapján túl is akarod használni bármire?
- A hozzászóláshoz be kell jelentkezni
"modern" ezen jot mosolyogtam. Sok mindent el lehet mondani rola, de pont, hogy modern?? Melyik resze egeszen pontosan?
- A hozzászóláshoz be kell jelentkezni
Ez csak annyit jelent, hogy az IIS (Microsoft Support) nem fog hivatalos támogatást nyújtani rá.
Ettől függetlenül természetesen továbbra is használható lesz.
Valószínűleg annyira marginális volt a fizető ügyfelek száma, hogy nincs értelme supportálni.
- A hozzászóláshoz be kell jelentkezni
WSL alatt ha kell ,megkapod. :) Igy a support ratolodott a kozossegre, az MS oldalon meg felszabadult nemi humán kapacitás amit gondolom a WSL alá toltak.
---
Szijarto Zoltan
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
- A hozzászóláshoz be kell jelentkezni
Ez is biztos ilyen "Ez már a KDE5" érzés, de mindig öröm látni, hogy a PHP/Javascript-s postok alatt jönnek a C#/Java huszárok, akik aztán jól megmondják, mennyire szar a PHP/Javascript. Persze a legtöbb C#/Java kispista életében nem nyúlt hozzá egyik scriptnyelvhez sem, max csak bottal bökdöste 5 percig. Aztán meg csak kamillázik, amikor egy Angular/Ngrx fejlesztő többet keres, mint ő Java-val. (Azt hiszed, hogy nem, pedig de. :D) PHP-vel olyan nagy rendelkezésre állású rendszereket is kiszolgálnak, amivel itt a legtöbb ki-ha-én-nem C#-os sosem fog dolgozni.
Láttam már sok rendszer kódját, láttam és dolgoztam sok szoftverfejlesztővel. Volt már dolgom olyan szarul megírt Java kóddal is, amit már csak a köré épített vas és infrastruktúra tartott egyben. És minden releasekor imára kulcsolhattad a kezed, hogy a deploy ne szálljon el az alkalmazásszserveren. A PHP-ben írt Joomla/Wordpress ahhoz képest egy csodálatosan megírt rendszer volt.
Gányolni minden nyelvben lehet. Minden programnyelvet/scriptet arra kell használni, amire való. Azért ettől függetlenül remélem, hogy azok, akik itt annyira használhatatlannak tartják a PHP-t, azok az egyoldalas portfóliójukat/honlapjukat is Java-ban írják meg, JSF-fel! Vagy annyira okosak, hogy írnak hozzá saját scriptnyelvet... ;) :D
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
Mutass itt egy hozzászólást, ami használhatatlannak tartja a PHP-t. A mai igények hatékony kielégítésére vannak jobb alternatívák, Windows világán túl is - ez az állítás.
- A hozzászóláshoz be kell jelentkezni
Igazabol attol fugg, mire optimalizalsz. Ha a fejlesztesi koltsegre, a PHP eleg jol all. Ha arra, hogy egyetlen shared hosting 1000 alacsony latogatottsagu weboldalt ki tudjon szolgalni, arra megint eleg jo (ugyanez Java/C# alapon megenne a memoriat mielott az elso keres beerkezik, mert mindig fut). A Facebook C++-ra fordito hackjevel magabol a nyelvbol (es nem az interpreterbol) sokkal tobbet ki lehet hozni ezen tul is, szoval nagyobb forgalmu oldalakra is jo lehet. Ahol a DB limital, ott meg mindegy mi van az oldal alatt, akar lehet PHP is, ahhoz konnyebb embert talalni (es elvileg olcsobb is). A nyelv amugy alkalmas lenne arra is, hogy a webservert kivaltsa, es tovabb fusson a egy-egy keres kiszolgalasa utan is. Bar nem igy hasznaljak (biztos van ra okuk). Meg beepitett webserveruk is van (php -S 0.0.0.0:8080 -t www/ parancs elinditja, www konyvtarral, mint roottal, 8080-as porton).
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ha van pénz vasra, van pénz emberre, cserébe teljesítmény kell, ott nem a PHP a nyerő.
- A hozzászóláshoz be kell jelentkezni
Igen, ha ezekre a parameterekre optimalizalsz, akkor valoban van jobb. Vagy ha mar annyi penzed van, mint a Facebooknak, es egy csomo legacy kodod van, akkor a Hiphop kifejlesztese meg lehet megoldas.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Azért a mai PHP már teljesítményben is elég jó, a 8-as pedig még jobb lesz.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Pontosan!
Az a PHP utálat, ami folyik az abból fakad, hogy aki terjeszti a hülyeséget az talán életében egyszer PHP-zott, de akkor is csak maximum 5-ös verzióval, de jobban valószínű, hogy korábbi verziót látott. Azóta a PHP nagyon sokat fejlődött, minden téren.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Konkrétan 1000%-kokban mérik a gyorsulását az 5-tös (!) verzió óta. Most épp nem találom a forrást, de a Facebook hop-hop-ját is már kenterbe veri a 7.0 out of the box. A JIT-elt 8-cas pedig még ki sincs próbálva jóformán.
És itt még csak szimplán a performancia kérdést feszegetjük, a szintaxisról még szó sincs. Simán működik még a PHP a maga kategóriájában, 2020-ban is.
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
Azért az 5-ös verzió tényleg nem volt egy speedy gonzales, szóval volt hova gyorsulnia. Szívtam vele eleget.
- A hozzászóláshoz be kell jelentkezni
2020-ban a szoftverfejlesztés egyik legnagyobb problémája, - a bőség zavarában - hogy nagyon nagy százalékban, inkompetens emberek hoznak döntéseket arról, hogy milyen infrastruktúrát válasszanak egy rendszer üzemeltetéséhez. Ilyen és ehhez hasonló hozzászólások, a rendszer ismerete nélkül is jönnek-mennek. :)) Ha van pénz, akkor szórjuk is rendesen.
Ilyenekből szokott az lenni, hogy lőjjük ágyúval verébre vagy vice-versa:
- könyvelőszoftver 50 fős személyzetnek? --> Naná, hogy Angular, a RESTapi backendjét pedig megírjuk Java-ban. Swagger sem kell, megírjuk nulláról. A vas majd elhajtja valahogy, ha szar lesz a kód, veszünk még bele RAM-ot. Ha nem vagyunk képesek jól kezelni a logot, veszünk tárhelyet...
- 1500 darabszámú terméknek webshop, magyar piacra ~10 user / perc terheléssel --> Persze, hogy Magento! :D Tökéletes választás lesz. Bár nincs a fejlesztőcégnél senki, aki értene egyáltalán a cache-lés kezeléséhez, de nyomjuk csak! Majd lekezeli a redis.
- Portfólió a fotósnak a Facebook profil mellé? --> statikus html, a db-vel meg majd jQuery tartja a kapcsolatot ajax-szal. Mindezt egy windows szerveren, ssl kapcsolat nélkül, mer' minek az. Pistike megcsinálja.
Áh, hagyjuk.
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
Sokkal tovabb tart megtanulni egy nyelvet/keretrendszert, mint letolteni es telepiteni a hozza szukseges dolgokat. Szoval az, hogy a cegnel a fejlesztok mihez ertenek (es mit hajlandoak megtanulni) egy komoly erv/limitacio, amikor a projecthez eszkozt kell valasztani.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Szerintem a kolleganak inkabb a felelossegvallalassal van gondja. Az ilyen elbaszasokkal nem az a gond, hogy nem latjak elore, hanem az, hogy nem tudnak vele mit kezdeni ha elojonnek.
Igy elobb-utobb masnal kotnek ki es ilyenkor az ugyfel a "kezelest" varja el es nem a teljes re-design-t.
- A hozzászóláshoz be kell jelentkezni
2020-ban a szoftverfejlesztés egyik legnagyobb problémája, - a bőség zavarában - hogy nagyon nagy százalékban, inkompetens emberek hoznak döntéseket arról, hogy milyen infrastruktúrát válasszanak egy rendszer üzemeltetéséhez. Ilyen és ehhez hasonló hozzászólások, a rendszer ismerete nélkül is jönnek-mennek. :)) Ha van pénz, akkor szórjuk is rendesen.
En a clean-code huszarokat es a gold platereket nem szeretem. Az egyik az ajanlasokat szabalykent alkalmazza a masik meg soha nem lesz kesz, mert eppen onmegvalosit. Jelentektelen, merhetetlen dolgokon megy a vitatkozas.
Pistike megcsinálja.
Ez nem neked szol, de altalanos hozzallas, hogy Pistiket mindenki utalja, pedig mindenki volt mar Pistike egy idoben. A PHP korul meg sok Pistike van, PistikeHelpsPistike, ezert szar az egesz PHP.
- A hozzászóláshoz be kell jelentkezni
Persze értem én. Pontosan ezért hígul minden szakma először ott, ahol a legegyszerűbb bekapcsolódni. A legveszélyesebb ma már nem a PHP Pistike, hanem a Javascript Janika, aki a böngésző DevTool-jában beírt
console.log('Hello world')
után, már rögtön backendet írna nodejs-ben, mert ő szoftverfejlesztő lett.
Illetve most feltörekvőben van a Python Péterke is (akkor már maradjunk a neveknél :D) mert a raspin ugye ezzel kezdenek már a kisiskolások. Ami amúgy teljesen rendben is van.
Mindenki volt egyszer kicsiítőképzős, szoftverfejelsztőcske. Csak nem mind1, hogy ezt 10+ év tapasztalatával mondhatja el magáról, vagy 13 évesen, amikor az első programját megírta.
Szóval a "ezert szar az egesz PHP."-vel nem értek egyet, mert nem a nyelv hibája mindez.
Illetve, ha engem kérdezel, egy clean-code mániás még mindig jobb, mint az, aki szarik az egészre magasról. Persze ettől még mindent túlzásba lehet vinni.
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
Szóval a "ezert szar az egesz PHP."-vel nem értek egyet, mert nem a nyelv hibája mindez.
Ezzel en sem ertek egyet, csak ironia volt.
Illetve, ha engem kérdezel, egy clean-code mániás még mindig jobb, mint az, aki szarik az egészre magasról. Persze ettől még mindent túlzásba lehet vinni.
Pontosan! Egy jo fejleszto tudja amikor valami eleg jo.
- A hozzászóláshoz be kell jelentkezni
A mai igények hatékony kielégítésére vannak jobb alternatívák, Windows világán túl is - ez az állítás.
Egyetertek mindenben s7stM kollegaval. Ezen felul erdemes mindent vizsgalni (szakmai, HR es penzugy stb...). Ha a teljes kepet nezed, nem ilyen fekete-feher a dolog. Igy ezen is lehetne vitazni napokig (Mercedes vagy BMW vagy ...)
A hasznalo eleri a celjat vele, ez a lenyeg! Mindenki a sajat maga szempontjabol a legegyszerubb utat probalja valasztani... Mindenhol megy a takolas, keves helyen van meg a penz arra, hogy spontan magomles kovetkezzen be egy code review soran.
- A hozzászóláshoz be kell jelentkezni