Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: Martin 05. 09. 2018, 20:44:10
-
Dobrý den,
pracuji nyní na pozici PHP programátora. Na to, že je to moje první práce mám celkem slušné podmínky. Ale psát dnes rozsáhlejší projekty v čistém PHP je myslím celkem masochistické. Navíc se zabývám myšlenkou jakým směrem se dál vyvíjet abych měl do budoucna na trhu práce co nabídnout. Moje myšlenky tedy celkem logicky zamířily směrem k frameworku.
Jako první u nás člověka samozřejmě napadne Nette. To napadlo i mě a tak už v něm mám hotové i dva menší projekty. Jsou to projekty typu osobní web + nějaká jednoduchá administrace. Takže vážně umím jen základy a to ještě musím i hodně běžných věcí stále googlovat. Takže pokud tyhle "zkušenosti" nevyužiji v praxi tak mě to moc mrzet nebude. Taky jsem prošel asi dvěma kapitolami v ASP.NETu. Ten mě ale neoslovil vůbec.
Teď jsem ve fázi, kdy zjišťuji že těch frameworků je nějak hodně :D Začal jsem tedy hledat nějaké jejich srovnání, ale nic moc jsem nenašel.
Nejvíc mě zatím láká se konečně pořádně naučit Python. Něco už jsem v něm dělal a docela mě to bavilo. Taky je to myslím o dost univerzální jazyk a tak bych se třeba časem mohl od webových aplikací posunout někam dál (tedy pokud je kam - vůbec nevím. Zatím to ani nemám v plánu). Frameworků nad Pythonem je ale taky celkem hodně a tak mi to výběr moc neusnadnilo.
Ať bych si ale vybral cokoli, stejně bych nakonec pochyboval jestli je to správná cesta. Nemám zkrátka ještě zkušenosti z praxe a tak nevím co má před sebou lepší budoucnost, s jakými znalostmi seženu práci snáze, případně se dostanu na lépe ohodnocenou pozici atd...
Ani nečekám že by zde byla nějaká jednoznačná univerzální odpověď. Nakonec si stejně budu muset odpovědět sám, co je pro mě nejideálnější. Zajímají mě ale názory lidí z praxe. Co má jaké výhody, co nemá třeba vůbec smysl zkoušet...
Děkuji za odpovědi :)
-
Taky je to myslím o dost univerzální jazyk a tak bych se třeba časem mohl od webových aplikací posunout někam dál (tedy pokud je kam - vůbec nevím. Zatím to ani nemám v plánu).
Tohle jsi trefil. Posunout se někam dál dost možná chtít budeš a to dřív než si myslíš - vlastní zkušenost. Po delší době webařina není zrovna zajímavá práce.
Výběr PHP frameworku bych nepřeceňoval. Vyzkoušej si co ti sedí a v tom pracuj.
-
PHP přece není programování. První krok je teda začít dělat pořádný jazyk. Dneska asi jedině Java, ale záleží na tom, jak velké projekty chceš dělat. Malé skriptíky jdou i v tom Pythonu a dobře, ale proti PHP to zase tak moc velký skok není.
-
určtě zkus i asynchronní frameworky, oproti klasickým je to zase něco jiného.
Např. aiohttp nebo něco s node.js.
-
V PHP som programoval 10 rokov, pracoval som za tú dobu s týmito frameworkami:
- Nette 1, 2
- Zend Framework 1, 2
- Symfony 2, 3, 4
- Laravel 5
- CodeIgniter 2, 3
V Nette som spravil portály, e-shopy. Všetky zdroje boli len v češtine, problémy sa riešili na fóre. Jedná sa o lokálnu záležitosť, je používaný hlavne v ČR a v SR. Pracovalo sa v ňom dobre, ale kvôli tomu, že jeho autor (David Grudl) sa pravidelne "vyhráža", že celý projekt "zahodí do koša", tak ho neodporúčam.
V Zend Framework som spravil menšie weby a jeden väčší e-shop. Dokumentácia podľa môjho názoru nič moc. V Zend Framework 2 sa mi pracovalo horšie ako v Zend Framework 1. Neodporúčam.
V Symfony som spravil najviac projektov - menšie weby, väčšie portály, menšie e-shopy. Dokumentácia je výborná, má veľkú komunitu, nie je problém nájsť riešenie problémov. Na LinkedIn mi chodilo relatívne veľa ponúk z Nemecka, ČR a SR na Symfony takže nemal by byť problém v ňom nájsť prácu.
V Laravel som začal robiť jeden projekt, ale keď som zistil, že čo je to za shit framework, tak som sa na to vykašlal. Je to framework pre lepičov kódu, ktorí nemajú šajn o architektúre, neodporúčam.
V CodeIgniter som spravil pár menších projektov. V súčasnosti je to už podľa mňa mŕtvy projekt, neodporúčam.
-
Dobry den, vyrabim cihly z hliny, nekdy z blata, nekdy i s trochou slamy. Chtel bych se profesne posunout a mit lepsi dum, treba jako soused z cihel, ale neumim se rozhodnout jestli mam pouzit blato s primesi slamy, nebo tam dat spise listi, nebo treba slupky z brambor. Co mi poradite?
::)
Je pravda, ze i mcdonalds pouziva php (treba jejich mcnazor), ale jinak je to jazyk bastlicu a lepicu a pokud se chces nekam karierne posunout, rozhlidni si po nekterem jinem jazyku. Java, go, c...
;)
-
Ruby on Rails
-
Ruby on Rails
Neni tohle uz tak 20 let out ?
-
Ruby on Rails
Neni tohle uz tak 20 let out ?
Zalezi na tom, jak moc date na modu.
-
Dneska asi jedině Java, ale záleží na tom, jak velké projekty chceš dělat. Malé skriptíky jdou i v tom Pythonu a dobře, ale proti PHP to zase tak moc velký skok není.
V současné době se obrovským tempem rozvíjí javascriptové frameworky, zkusil bych cokoliv z trojky Angular, React, Vue.
PS:
Alternativou k Jave je taky .NET core ASP.
-
Ruby on Rails
RoR je možno z programátorského hľadiska boží (neviem posúdiť, nikdy som v ňom nerobil), ale z hľadiska nasadzovania na server som väčšie peklo ako webové projekty v Ruby nezažil. Spravte svojmu administrátorovi radosť a odbočte od Ruby preč.
-
Ještě se mrkni na nejpoužívanější Frameworks, Libraries and Tools (https://insights.stackoverflow.com/survey/2018/#technology-frameworks-libraries-and-tools) na Stack Overflow:
První 4 jsou:
Node.js 49.6%
Angular 36.9%
React 27.8%
.NET Core 27.2%
-
Každý pořádný programátor (tj. ne lopata) používá zásadně a pouze svůj vlastní framework, co si sám napsal.
-
Hele, v CR bych se python na programovani webu vubec neucil - zatimco v zahranici je python v podstate jeden ze standardnich jazyku na backendu, tak v CR je na web python naproste minimum nabidek oproti ostatnim resenim (hlavne php, nasleduje java a .net) a to v takovem smyslu ze v Praze najdes tak 5 mist kde neco aktualne delaji v nakym python web frameworku.
Ohledne samotnych frameworku (Django, pyramid, flask) - Django ma sice jako mnozi tvrdi spickovou dokumentaci ale neni absolutne dobre pro zacatecniky, django je extremne overengineered coz by nevadilo kdyby django tlacilo jednu cestu jak to neco udelat, ale vono vzdy tech cest nabizi 5. Na uplne posledni blbost je v djangu nejaka utilitka ktera se casto chova jako magicky blackbox. Dalsi problem je ze Django si vymyslelo svuj pristup k MVC - takze vetsina business logiky zustane rozhazena po forms, managerech, modelech s tim ze django tam archaicky nabizi OO postupy ve stylu inheritance jak za krale klacka. Z pohledu OO se v tom pracuje jak v roce 2007. django se snazi v posledni dobe dohnat dobu ale zatim to je porad v plenkach.
flask je v pohode ale je to microframework a tedy problemy klasickych microveci.
pyramid sem nepouzival.
-
Každý pořádný programátor (tj. ne lopata) používá zásadně a pouze svůj vlastní framework, co si sám napsal.
Je pravda, že takového programátora nemůže nikdo vyhodit, protože ten jeho framework nikdo neumí a nikoho už na to prostě neseženou. Další otázka jsou bezpečnostní aktualizace a celková kvalita návrhu, udělat kvalitní framework je náročný úkol i pro velké firmy jako je Google nebo Facebook, natož pro jednoho člověka.
-
Ruby on Rails
Neni tohle uz tak 20 let out ?
Out to ještě není, stále je to velmi kvalitní framework pro rychlý vývoj webových CRUD aplikací a spousta firem ho používá, i když v ČR se, AFAIK, moc neprosadil.
Komunita railsařů se už ale pomalu začíná odklánět směrem k elixir+phoenix, mj. z důvodu velice nízkého výkonu ruby+rails.
-
Drupal 8. Postavene na vecech ze Symfony(services, DI atd), ale mas vyreseno bambilion veci coz proste setri praci (zkus si jen napsat svoji spravu uzivatelu...).
Kdyz budes nemocnej prijde k tomu nekdo a dokaze to relativne rychle ovladnout a spravovat.
- posledni dobou vyladeny procesy v pripade security issues.
- velka komunita
- Acquia do toho sype prachy horem-dolem (coz ma zase tu nevyhodu, ze tam akcentujou LBGTFXYZ politicky sracky)
- Spousta nastroju (Drush, Console...)
- Integrace se standardnima testovacima nastrojema (PHPUnit, Behat, ted nevim co na JS)
- velmi silne pro headless reseni (mas administracni CMS a appkam vystavujes data pres JSONAPI nebo GraphQL)
- slusna poptavka za dobre penize (zejmena ze zahranici)
-
Já bych asi do úvah o frameworku zahrnul to, k čemu to má být: spíš SPA nebo víc multipage (blog, e-shop, aj.).
-
Dalsi problem je ze Django si vymyslelo svuj pristup k MVC - takze vetsina business logiky zustane rozhazena po forms, managerech, modelech s tim ze django tam archaicky nabizi OO postupy ve stylu inheritance jak za krale klacka.
Django má spoustu problémů, ale s tímhle nesouhlasím. Kde by měla být business logika podle vás?
-
TurboGears 2
-
PHP přece není programování. První krok je teda začít dělat pořádný jazyk. Dneska asi jedině Java, ale záleží na tom, jak velké projekty chceš dělat. Malé skriptíky jdou i v tom Pythonu a dobře, ale proti PHP to zase tak moc velký skok není.
Je pravda, ze i mcdonalds pouziva php (treba jejich mcnazor), ale jinak je to jazyk bastlicu a lepicu a pokud se chces nekam karierne posunout, rozhlidni si po nekterem jinem jazyku. Java, go, c...
;)
Poradím vám, pokud o PHP a programování nic nevíte, pak se nechoďte do zdejší diskuze ztrapňovat. Každé malé děcko ví, že PHP je napsané v C a vychází z C a Javy. V takovém případě někomu doporučit Javu a k tomu Python ("malé skriptíky"), který je totálně odlišný (hlavně syntaxí), je opravdu nápad malého děcka.
Kombinace znalostí C (C++, C#), Java a PHP je logická a velmi použitelná (na něco se hodí to a na něco jiného zase ono)
Nechápu, proč mají zamindrákovaní lidé problém s PHP. Protože je populární? Protože ho například používá jeden z nejúspěšnějích a nejvýdělečnějších projektů poslední doby Facebook? Nechápu, kde se v lidech diskutujících na root.cz bere ten dar diskutovat na úrovni de..ntích Novnikářů z Novinky.cz?
Zkuste si někdy práci s PHP7 (včetně typové kontroly, skalárních datových typů, návratových hodnot, atd.) a MySQL8. Pokud jste někdy pracovali s PHP 3/PHP 4, budete překvapeni, o čem dnes PHP je. I když u vás pochybuji, že jste kdy v životě programovací (speciálně pro vás skriptovací) jazyky viděli. :-(
-
nejvýdělečnějších projektů poslední doby Facebook?
muzes tohle nejak ozdrojovat?
-
Poradím vám, pokud o PHP a programování nic nevíte, pak se nechoďte do zdejší diskuze ztrapňovat. Každé malé děcko ví, že PHP je napsané v C a vychází z C a Javy.
PHP vychází především z Perlu. A pak PHP jako když pejsek s kočičkou vařili dort - neustále vycházelo a inspirovalo se něčím jiným. Tu C, tu Javou.
Mimochodem, Python je také napsaný v C. Jak ví každé malé dítě. To, v čem je jazyk napsaný je irelevantní věc.
Problém PHP je, že je to naprosto nekonzistentní jazyk typu každý pes jiná ves. Má četné problémy a nedostatky. PHP se drží spíše z historických důvodů - kdysi to byla jediná rozumná a open source konkurence ASP. Tím se rozšířila. Nicméně nelze než souhlasit, že pokud je to možné, je lépe z PHP utéct.
Kombinace znalostí C (C++, C#), Java a PHP je logická a velmi použitelná (na něco se hodí to a na něco jiného zase ono)
Programovacích jazyků se naučíte kolik chcete. Protože programovací jazyk je jen nástroj, nic jiného. To podstatné, co programátor umí je algoritmizace a řešení problémů - a to je málo závislé na programovacím jazyku.
Stejně jako si vybíráte při práci dobrý šroubovák, tak se snažíte si vybral dobrý programovací jazyk.
Nechápu, proč mají zamindrákovaní lidé problém s PHP. Protože je populární? Protože ho například používá jeden z nejúspěšnějích a nejvýdělečnějších projektů poslední doby Facebook? Nechápu, kde se v lidech diskutujících na root.cz bere ten dar diskutovat na úrovni de..ntích Novnikářů z Novinky.cz?
Protože PHP je objektivně zamotaný a špatný jazyk z mnoha důvodů. Na to člověk nemusí mít mindráky aby k tomuto závěru došel.
Navíc neexistuje ani žádný standard PHP. Existuje jedna implementace, a co je v ní je de facto standard. V každé verzi PHP se provedou nekompatibilní změny, které nutí všechny opravovat zdrojové kódy, pokud chtějí přejít. Proto také při změně major verze PHP trvá 3-4 roky než se nová verze rozšíří. Protože to autoři a vývojáři jazyka/interpretru PHP vedou velice špatně.
Dodnes jazyk PHP - po 23 letech - nedotáhl ani do toho, aby měl datový typ "textový řetězec".
Protože PHP nenabízí ani kompilaci do binárního/p-kódu, při každém HTTP requestu se znovu a znovu kompiluje jako u pitomců. Protože základní PHP balíček nenabízí ani tak samozřejmou věc, jako je debugging. Srovnejte to s tím, co dostanete u většiny balíčků jiných jazyků za nástroje už v základu.
Zkuste si někdy práci s PHP7 (včetně typové kontroly, skalárních datových typů, návratových hodnot, atd.)
Že by už měla datový typ "textový řetězec"? Bylo by to záhodno, protože web je hodně o práci s textovými řetězci. Ne, to stále nemá - možná ve 28. století bude mít PHP tak záklandí věc, jako je typ "textový řetězec". Po 23 letech se v PHP 7 zmohli jen na to, že umožnili vyrobit bajtovou sekvenci s UTF-8 pomocí hexadecimálních konstant kódových pozic.
Že by už konečně umožňovala přeložit zdrojáky do binární podoby, aby se konečně zvýšil výkon PHP aplikací?
Že by už konečně byl v základě rozumný debugging?
Ne, PHP 7 se rozhodla změnit tak záklandí věci, jako jsou výjimky. Už výjimky nevycházejí z \Exception, ale z \Throwable. Když vznikne chyba, už to není PHP error, ale výjimka.
Pokud jste někdy pracovali s PHP 3/PHP 4, budete překvapeni, o čem dnes PHP je. I když u vás pochybuji, že jste kdy v životě programovací (speciálně pro vás skriptovací) jazyky viděli.
O tom, že v Javě, Pythonu a dalších jazycích jsem schopen na stejném serveru udělat mnohonásobně vyšší výkon webového sídla než v PHP. O tom to je.
PHP neexceluje ani v té množině problémů, pro které je určeno.
-
nejvýdělečnějších projektů poslední doby Facebook?
muzes tohle nejak ozdrojovat?
Mark Zuckerberg je 5. nejbohatší muž na světě, protože:
a) vyvážel popelnice za Prahou
b) si při psaní svého projektu nechával poradit hatery z fóra root.cz
c) protože použil PHP a napsal v něm revoluční aplikaci/službu, kterou používá přes 2 miliardy uživatelů (a samozřejmě hateři, co nikdy nic nedokázali vám budou tvrdit, že použití čehokoliv jiného je lepší, něco jako když Franta Pepa příjde na pracák a paní úřednici tam tvrdí, jak ten Facebook je špatně napsanej a on by ten Facebook napsal v něčem jiném a jak by to úplně jinak šlapalo, ...)
Ale co je to Facebook, to ti nehodlám "ozdrojovávat". To už si najdi sám.
-
Dalsi problem je ze Django si vymyslelo svuj pristup k MVC - takze vetsina business logiky zustane rozhazena po forms, managerech, modelech s tim ze django tam archaicky nabizi OO postupy ve stylu inheritance jak za krale klacka.
Django má spoustu problémů, ale s tímhle nesouhlasím. Kde by měla být business logika podle vás?
Django ma logiku nejen tam kde ji ma mit (modely) ale mimo to ji ma rozhazenou v dalsich filech, a oficialni dokumentace se dokonce ani neobtezuje ji vyndat z controlleru.mimo to django defaultne nema servisni vrstvu (ta logika je rozhazena ve 3 jinych filech a managerech), kterou si tam sice jo muzete doudelat ale pak tim rozbijite django konvence. Django ma problem s tim ze neumi o sobe samo rict jak chce abys to delal. napriklad spring ktery je taky overengineered tenhle problem nema.
-
c) protože použil PHP a napsal v něm revoluční aplikaci/službu, kterou používá přes 2 miliardy uživatelů (a samozřejmě hateři, co nikdy nic nedokázali vám budou tvrdit, že použití čehokoliv jiného je lepší, něco jako když Franta Pepa příjde na pracák a paní úřednici tam tvrdí, jak ten Facebook je špatně napsanej a on by ten Facebook napsal v něčem jiném a jak by to úplně jinak šlapalo, ...)
Existuje firma, která v historických začátcích vydělala velké jmění na technologiích děrných štítků a věcí kolem toho. Podle stejné logiky by se to mělo následovat. Kdo chce vydělat, měl by používat děrné štítky.
-
nejvýdělečnějších projektů poslední doby Facebook?
muzes tohle nejak ozdrojovat?
Mark Zuckerberg je 5. nejbohatší muž na světě, protože:
To, ze se napakoval tvurce prece neznamena, ze je ta vec nutne ziskova. Takze jeste jednou: dokazes nejak relevatne podlozit, ze se jedna o jeden z nejvydelecnejsich projektu?
(pravda, pri uplne prvnim mem dotazu na zdroje jsem si popletl FB a Twitter)
-
Pane Ponkráci, máte dobře sepsané argumenty a s některými nelze než souhlasit, ale dle mého názoru také dobře manipulujete.
Příkladem:
V každé verzi PHP se provedou nekompatibilní změny, které nutí všechny opravovat zdrojové kódy, pokud chtějí přejít. Proto také při změně major verze PHP trvá 3-4 roky než se nová verze rozšíří
Já v přechodu mezi PHP 5 a PHP 7 neměl nějaký zvláštní problém, PHP 7 jsem nasazoval celkem brzo a dle statistik jsem nebyl sám. A nevzpomínám si, že bych nějak výrazně předělával projekty. O zpětné kompatibilitě bychom mohli polemizovat roky, já měl například větší problémy mezi Pythonem 2 a 3 než mezi PHP 5 a PHP 7. Zpětná komatibilita, to rozhodně není u PHP tak výrazný problém (v porovnání s ostatními projekty).
Existuje firma, která v historických začátcích vydělala velké jmění na technologiích děrných štítků a věcí kolem toho. Podle stejné logiky by se to mělo následovat. Kdo chce vydělat, měl by používat děrné štítky.
Já přece nikde netvrdím, aby někdo něco následoval. Podstatou mých příspěvků je poukázání na problém v tom, že někdo klade otázky ohledně PHP nebo se o PHP zmíní (jako v tomto vlákně) a hateři PHP se do toho vlákna vtírají a otravují ostatní tím, že vytrubují do světa nesmysly o PHP.
Sám moc dobře víte, že každý jazyk má své slabiny a že pro každý se dá udělat seznam věcí, které prostě nefungují dobře.
-
To, ze se napakoval tvurce prece neznamena, ze je ta vec nutne ziskova. Takze jeste jednou: dokazes nejak relevatne podlozit, ze se jedna o jeden z nejvydelecnejsich projektu?
(pravda, pri uplne prvnim mem dotazu na zdroje jsem si popletl FB a Twitter)
Nepsal jsem o tom, že je ta věc zisková, psal jsem o tom, že je to jeden z nejvýdělečnějších projektů poslední doby a ano je to tak, pokud se tvůrce napakoval, znamená to, že projekt byl výdělečný. Mě nezajímá jakým způsobem se nakonec napakoval, pro mě je důležitý výsledek a to co k tomu vedlo:
Zuckerberg napsal něco v PHP a výsledek je takový, že je 5. nejbohatší muž na světě. Jeho projekt v PHP byl a je výdělečný. Tečka.
Netvrdím, že kdyby si najal Chrise Sawyera, který by to napsal v assembleru, že by to nebylo lepší, ale to je prostě kdyby. Napsal to v PHP.
-
Já v přechodu mezi PHP 5 a PHP 7 neměl nějaký zvláštní problém, PHP 7 jsem nasazoval celkem brzo a dle statistik jsem nebyl sám. A nevzpomínám si, že bych nějak výrazně předělával projekty. O zpětné kompatibilitě bychom mohli polemizovat roky, já měl například větší problémy mezi Pythonem 2 a 3 než mezi PHP 5 a PHP 7. Zpětná komatibilita, to rozhodně není u PHP tak výrazný problém (v porovnání s ostatními projekty).
Python provedl za posledních 10-15 let provedl jednu jedinou nekompatibilní změnu, z Pythonu 2 na 3. Nutno říci, že jazyk byl značně pročištěn a vylepšen, byť změna nebyla zcela nutná. Já sám jsem to komentoval nelibě.
K PHP jsem se dostal někde na rozhraní PHP/FI, PHP 3. Od té doby je to jedna nekompatibilní změna za druhou. Největší průšvih byl asi přechod PHP 4 na PHP 5. To byl takový průšvih i pro autory PHP, že sami ztratili odvahu. Přechod trval obrovskou spoustu let.
Aby ospravedlnili další změny, slíbili že v příští verzi PHP 6 bude konečně ten datový typ "textový řetězec" (věc, kterou má Python či Java od samého začátku, ale PHP dodnes chybí). Dopadlo to tak, že žádný "textový řetězec" není dodnes. A verze PHP 6 byla přeskočena, protože autoři jazyka dali k dispozici tuny a tuny materiálů, jak bude vypadat PHP 6 - že vyšlo tisíce knih na téma PHP 6.
V každé verzi mizí řada knihoven, takže přepisům zdrojového kódu se nejde vyhnout.
... hateři PHP se do toho vlákna vtírají a otravují ostatní tím, že vytrubují do světa nesmysly o PHP. Sám moc dobře víte, že každý jazyk má své slabiny a že pro každý se dá udělat seznam věcí, které prostě nefungují dobře.
Já hlavně nemám rád nálepkování "hateři" a "nesmysly", aniž by byly věcné argumenty.
Tazatel se ptal, jaký webový framework zvolit, že dělá PHP a láká ho Python. Pak je naprosto přirozené, že mu lidi radí přechod od PHP k tomu Pythonu. Protože po všech stránkách je to lepší řešení - na web i jinam.
PHP jazyk těžce zaspal. Python nabízí zcela základní a samozřejmé věci, které na web potřebujete:
1) Má textový řetězec jako datový typ, a propracovanou práci s textovými řetězci přímo v jazyce. Web je o práci s texty.
2) Python se překládá do binární podoby jen jednou, nikoli při každém spuštění. Nesnižuje se tedy drasticky výkon webového serveru jen proto, že každý request znamená nový překlad zdrojáků.
3) Python má ladící nástroje už v základním balíčku. Zato PHP v základním balíčku vypadá spíše jako standard IT roku 1950 podle své vybavenosti.
4) Python může běžet tak, že nemusí nutně končit všechny objekty s requestem. U PHP kromě persistentního database connection a serializovaného ukládání bajtového řetězce někam nic takového.
Atd. atd. atd.
PHP ani ve verzi 7 neřeší základní problémy webového vývoje, tedy toho, na co je určen. Ono je hrozně fajn, že každá další verze je rychlejší než předchozí, když to zároveň PHP výkonově zatluče překladem zdrojových kódů při každém requestu, a nutností budovat všechny objekty znovu od začátku při každém requestu. V roce 2018 už je to výsměch do očí programátorům, to se na mě nezlobte.
Ve své podstatě PHP frameworky do značné míry řeší nedostatečnosti PHP jazyka.
Zuckerberg napsal něco v PHP a výsledek je takový, že je 5. nejbohatší muž na světě. Jeho projekt v PHP byl a je výdělečný. Tečka.
Protože v roce 2004 byla PHP verze 4 docela dobrá volba. Dnes by zvolil něco jiného. To je to základní umění, zvolit dobré nástroje vhodné pro daný cíl a danou dobu.
Zuckerberg nakonec musel svou nevhodnou volbu řešit. Takže si buďte jist, že žádný facebook na současném PHP interpretru, který si stáhnete z www.php.net neběží.
-- PHP je tak nevhodný, že každý větší projekt, který PHP použil musel řešit těžké a drastické problémy zejména s výkonností.
1) Facebook je řešil tak, že si napsal vlastní překladač ze své verze PHP do C++. Takže nakonec přeložil zdrojáky kompilátorem C++, a tak to dnes běží. Tím mimo jiné vyřešil i to, že mu autoři PHP neustále přepisují PHP jazyk pod rukama, což už Zuckerberga nemusí trápit.
2) Wikipedii si nakonec napsala vlastní optimalizovaný PHP interpretr. Ale i tak potřebuje mnohonásobek serverů, než kdyby wikipedii běžela v rozumnějším nástroji než PHP.
-
neslysel jsi o opcache a fpm?
EDIT: a ne kazdy projekt je velikosti FB/wikipedie
-
a to v takovem smyslu ze v Praze najdes tak 5 mist kde neco aktualne delaji v nakym python web frameworku.
Jasně, a proto pravidelně chodí na pražské PyVo kolem stovky lidí.
Jen v Praze se Django používá např. v CZ.NICu, v několika startupech (např. https://www.twisto.cz/kariera/django-vyvojar/ , https://www.cocuma.cz/job/backend-developer/ , https://tech.showmax.com/open-positions/1295946-python-developer/, https://stackoverflow.com/jobs/companies/energomonitor), mnoha agenturách a dokonce jsem byl nedávno osloven 2 velkými společnostmi (1.000+), že u nich teď mají nějaké projekty v Djangu.
Pokud bychom to zobecnili na Python, tak už těch firem je tolik, že to nemá smysl vyjmenovávat, v čele s např. Seznam.cz
Django ma sice jako mnozi tvrdi spickovou dokumentaci ale neni absolutne dobre pro zacatecniky, django je extremne overengineered coz by nevadilo kdyby django tlacilo jednu cestu jak to neco udelat, ale vono vzdy tech cest nabizi 5.
Přesně naopak, Django se drží Zen of Python "There should be one-- and preferably only one --obvious way to do it." Naopak na to narážím při školení lidí z jiných frameworků a jazyků, kteří se na něj snaží napasovat svůj navyklý přístup k věci, místo aby přijali, že Django je "opiniated framework" a věci s v něm dělají určitým způsobem. Ostatně proto bych ho tazateli doporučoval, protože ho ten framework rovnou vede k určitým návykům (které jsou imho dobré).
Naopak v javascriptových projektech, na kterých jsem se podílel (Node.js nebo React), se dost naráželo na to, že existuje příliš mnoho možností a není jasné, kterou z nich zvolit (pro někoho to samozřejmě může být výhoda).
-
budete překvapeni, o čem dnes PHP je.
...
Sám moc dobře víte, že každý jazyk má své slabiny a že pro každý se dá
udělat seznam věcí, které prostě nefungují dobře.
Súhlasím s tým, že PHP urobilo veľký kus práce dopredu: opravili sa mnohé nedostatky, je tu composer, frameworky ako Symfony a Laravel, PHP sa výrazne zrýchlil. PHP je veľmi jednoduché nasadiť.
Pretrvávajú však početné nedostatky. Väčšina vznikla preto, lebo sa jazyk vyvíjal hurá štýlom, bez akéhokoľvek plánovania. Veď PHP pôvodne vzniklo ako súbor Perl scriptov, čož teda rozhodne nie je dobrý začiatok. :)
Spomeniem zopár PHP podivností: FALSE, false, true, TRUE. FALSE a TRUE sa dajú predefinovať (!?),
echo true vypíše 1, echo false nevypíše nič. Väčšina jazykov má rôzne typy kolekcií, trebárs zoznamy, slovníky, množiny a pod. PHP má všetko v jednej kolekcii array. Nikdy som nepochopil rozdiely medzi require, require_once, include, include_once.
PHP má nekonzistentné názvoslovie funkcií (Laravel kvôli tomu vytvára špeciálne svoje knižnice), nekonzistentné poradie argumentov funkcií.
Je to veľká škoda, lebo inak by to bol omnoho lepší jazyk.
-
No, je to zajímavé, jak PHP funguje na některé lidi jako červený hadr na býka, nechtěl bych vidět ty lidi, co dělají v případě Javascriptu a jeho momentální oblíbenosti (frontend, server, mobilní aplikace), to jim asi při veškerém tom chaosu, co se kolem Javascriptu děje, musí prasknout srdce.
-
Pretrvávajú však početné nedostatky. Väčšina vznikla preto, lebo sa jazyk vyvíjal hurá štýlom, bez akéhokoľvek plánovania. Veď PHP pôvodne vzniklo ako súbor Perl scriptov, čož teda rozhodne nie je dobrý začiatok.
Ty nedostatky jsou tu proto, že PHP nemá psaný standard jazyka.
Programovací jazyk C byl nic moc, dokud nepřišel jeho psaný ANSI standard. Programovací jazyk C++ byl nic moc, dokud se neustanovil standard C++98. Atd. Java/Python má také své standardy, jinak se nic v jazyce neděje.
Spomeniem zopár PHP podivností: FALSE, false, true, TRUE. FALSE a TRUE sa dajú predefinovať (!?),
echo true vypíše 1, echo false nevypíše nič.
To je historická záležitost. Byly doby, kdy neexistoval v PHP ani datový typ "boolean" ani "null". Z historických důvodů byl false prázdný řetězec a true celé číslo s hodnotou 1. Echo tuto věc dodnes emuluje.
Pamatuji si doby, kdy null hodnota v MySQL tabulce se vracela v PHP jako false.
Väčšina jazykov má rôzne typy kolekcií, trebárs zoznamy, slovníky, množiny a pod. PHP má všetko v jednej kolekcii array.
V PHP je všechno řízeno jako "array". Autoři si to prostě zjednodušili ad absurdum.
1) Datový typ "array" je asociativní pole, kde klíč je int/string.
2) Objekt je to samé asociativní pole.
3) Funkce je zase asociativní pole, které nese proměnné.
Nikdy som nepochopil rozdiely medzi require, require_once, include, include_once.
PHP má nekonzistentné názvoslovie funkcií (Laravel kvôli tomu vytvára špeciálne svoje knižnice), nekonzistentné poradie argumentov funkcií.
Require udělá fatální chybu, když vkládaný soubor neexistuje - a zastaví celý program. Include při neexistenci souboru vyvolá jen warning a program pokračuje.
Cokoli s _once ignoruje vložení, pokud už byl soubor někdy předtím vložen.
Je to veľká škoda, lebo inak by to bol omnoho lepší jazyk.
Chybí mu málo k dokonalosti. Ale zřejmě jim chybí vývojáři.
-
Tak zatím nejlépe mi z toho vychází node.js. Sice je pravda že nasazení JS na serveru se mi zdá dosti zvláštní, ale většinou o tom všude čtu samou chválu. Python bych ale ještě taky úplně neodepisoval.
O PHP jsem se toho dozvěděl trochu víc než jsem chtěl :D a tak bych byl rád kdyby mi zde raději někdo porovnal Python a Node.js (a to jak z technické stránky tak i po stránce uplatnění těch technologií v praxi apod...)
Případně navhrněte i nějakou další alternativu.
-
Tak ono záleží, co od toho člověk chce... Nicméně pokud jsi doteď dělal v php, tak doporučuji ten JavaScript/Nodejs. Je to zase něco jiného - asynchronní - a jako programátora tě to zase trošku posune. :)
-
Tak zatím nejlépe mi z toho vychází node.js
Tak si přečtěte pár článků o node.js a případně komentáře pod nimi. Javascript na serveru je mnohem kontroverznější téma než PHP, Python, atd. :-)
-
Tak zatím nejlépe mi z toho vychází node.js
Tak si přečtěte pár článků o node.js a případně komentáře pod nimi. Javascript na serveru je mnohem kontroverznější téma než PHP, Python, atd. :-)
To je mi jasné a pár článků jsem o tom již přečetl. Jejich autor je často z node.js bezmezně nadšen. V komentářích se pak objevují zmínky o tom že JS na server nepatří a že celý node je vlastně úplně k ničemu. Myslím že pravda bude někde uprostřed.
-
Require udělá fatální chybu, když vkládaný soubor neexistuje - a zastaví celý program. Include při neexistenci souboru vyvolá jen warning a program pokračuje.
Cokoli s _once ignoruje vložení, pokud už byl soubor někdy předtím vložen.
Tomu chápem, akurát to pozajtra zabudnem. Python má jeden import, PHP má na výber štyri možnosti, a teraz programátor musí uvažovať, ktorú si má zvoliť. Je to čo mu sa tuším hovorí zbytočný mental burden.
Ďalšia vec, ktorú som si včera všimol. PHP má podobne ako JavaScript dva operátory na porovnanie, == a ===.
Operátor == má množstvo problémov, napr:
<?php
$x = '12a';
$y = 12;
echo ($x == $y) ? 'equal' : 'not equal';
Príklad vypíše equal. Číslo 12 a string '12b' sú podľa tohoto operátora rovnaké.
Operátor === sa odporúča používať, má odstraňovať problémy ==. Pritom prináša ďalšie problémy, trebárs:
<?php
$x = 100;
$y = $x + 0.0e0;
echo ($x == $y) ? 'equal' : 'not equal';
echo ($x === $y) ? 'equal' : 'not equal';
Pri pripočítaní nuly s desatinnou čiarkou dôjde k situácii, kde operátor === vráti 'not equal'.
-
No, je to zajímavé, jak PHP funguje na některé lidi jako červený hadr na býka...
Ja nehatujem PHP, teraz si robím svoj projekt z vlastného rozhodnutia v Symfony. Ako PHPčkar, skús nám radšej povedať, čo s nasledovnými problémami:
a) Máme Symfony controller a v ňom sa pripájame cez DBAL na databázu. Je potrebné nejako explicitne
uzatvoriť objekt connection? Vraj netreba, lebo PHP má všetko na konci cyklu request/response uzavrieť, ale nejako sa mi to nezdá. V Jave poctivo voláme na objekte connection close metódu.
/**
* @Route("/getdata", name="getdata")
*/
public function data(Connection $conn)
{
$data = $conn->fetchAll("SELECT * FROM countries LIMIT 5");
return $this->json([
'data' => $data
]);
}
b) Nasledujúci kód je populárnej PHP knihy od Robina Nixona,
https://www.amazon.com/Learning-PHP-MySQL-JavaScript-Javascript/dp/1491978910/ref=dp_ob_title_bk
<?php
$fh = fopen("testfile.txt", 'r') or die("File does not exist or you lack permission to open it");
$line = fgets($fh);
$fclose($fh);
$echo $line;
Žiadne ošetrenie chybových stavov. Prepokladám, že die() funkciu nebudeme volať pri webovom projekte, v CLI by to šlo. Zrejme treba ošetriť chybové stavy testovaním návratových hodnôt funkcií fopen, fgets, a fclose. Ako z toho urobiť kóšer príklad?
c) Používať try/catch v kotrolleri alebo nie? Podľa PHP delusions https://phpdelusions.net/delusion/try-catch treba
použiť try/catch len v zriedkavých prípadoch, inak to treba nechať doplávať do systémového kódu, ktorý by mal vygenerovať error page.
$fs = new Filesystem();
try {
$pd = $this->get('kernel')->getProjectDir();
$content = file_get_contents($pd . '/templates/' . $filename);
return $this->render('admin/edit_article.html.twig',
['aid'=> $aid, 'title'=>$title, 'slug'=> $slug, 'filename'=>$filename,
'tags'=> $tags, 'content'=>$content]);
} catch (IOExceptionInterface $ex) {
$ermsg = "Cound not find the file to edit" . $ex->getPath();
return new Response($ermsg, Response::HTTP_CONFLICT,
['content-type' => 'text/plain']);
}
Ja som primárne Javista. V Java sa viem obvykle dopátrať ku best practices, v PHP sa mi to zdá viac zamotané .
-
a to v takovem smyslu ze v Praze najdes tak 5 mist kde neco aktualne delaji v nakym python web frameworku.
Jasně, a proto pravidelně chodí na pražské PyVo kolem stovky lidí.
Jen v Praze se Django používá např. v CZ.NICu, v několika startupech (např. https://www.twisto.cz/kariera/django-vyvojar/ , https://www.cocuma.cz/job/backend-developer/ , https://tech.showmax.com/open-positions/1295946-python-developer/, https://stackoverflow.com/jobs/companies/energomonitor), mnoha agenturách a dokonce jsem byl nedávno osloven 2 velkými společnostmi (1.000+), že u nich teď mají nějaké projekty v Djangu.
Pokud bychom to zobecnili na Python, tak už těch firem je tolik, že to nemá smysl vyjmenovávat, v čele s např. Seznam.cz
Django ma sice jako mnozi tvrdi spickovou dokumentaci ale neni absolutne dobre pro zacatecniky, django je extremne overengineered coz by nevadilo kdyby django tlacilo jednu cestu jak to neco udelat, ale vono vzdy tech cest nabizi 5.
Přesně naopak, Django se drží Zen of Python "There should be one-- and preferably only one --obvious way to do it." Naopak na to narážím při školení lidí z jiných frameworků a jazyků, kteří se na něj snaží napasovat svůj navyklý přístup k věci, místo aby přijali, že Django je "opiniated framework" a věci s v něm dělají určitým způsobem. Ostatně proto bych ho tazateli doporučoval, protože ho ten framework rovnou vede k určitým návykům (které jsou imho dobré).
Naopak v javascriptových projektech, na kterých jsem se podílel (Node.js nebo React), se dost naráželo na to, že existuje příliš mnoho možností a není jasné, kterou z nich zvolit (pro někoho to samozřejmě může být výhoda).
Jo ja si prosel nedavno vetsinu mist kde se nabizi delat Django (flask nikde nedelaj) - nabizi delat ne dela, o pythonu se vubec nebavime, ten se dela "vsude" jako doplnek jinych veci.
jak sem vyse psal a vy ste to nasledne potvrdil peti linkama, nad vice nez 5 mist se nedostanete, a to je pri vyberu prace zalostne malo, opet to napisu znova, v php/jave/.netu je tady toho "NASOBNE" vice a proto delat v CR (WEB!!!!!) python je uplny nesmysl pro karieru.
Python jako jazyk povazuju za skvelou volbu obecne, ale o tomhle debata vubec neni.
Pokud si jen letmo projedete net, tak vsude se NAOPAK pise ze Django neni VUBEC pythonicke, a s tim naprosto souhlasim. KDYBY existoval klasicky moderni MVC framework v pythonu (napriklad v hodne ohledech podobny railsu) ktery by byl popularni a battletested, pak se tady nebavime co za webovy framework, pac volba by byla jasna.
Django nabizi 5 cest jak udelat hello world. 2 z tech cest jsou archaicke, 1 cesta wannabe unopinionated (vetsinou v dokumentaci), 1 cesta opinionated, 1 cesta na ktere se za roky vyvoje shodla komunita a vy to musite vyvestit z kristalove koule.
to je to srandovni - djano o sobe pise ze prave je opinionated (souhlas), nacez v dokumentaci se snazi mlzit a nabizet nejake unopinionated pristupy. Opet napisu co jsem psal vyse - Django neumi rict jak to samo chce abys to delal.
Zjistit to trvalo nekolik mesicu a prolezeni nekolika desitek projektu, kde byly ty veci samozrejme uplne jinak nez v dokumentaci (ok, docs jsou schvalne jednoduchy) ale hlavne ty "spravne" veci v dokumentaci vubec ani zminene nejsou, kdybych nasledne mel v dokumentaci vyhledat nejaky komplexni postup na reseni ABC podle vzoru toho jak to maji v nejakem profesionalnim projektu, tak to v te dokumentaci absolutne nenajdu.
Django je psane stylem "ahoj, ty delas 5 roku django? tady mas dokumentaci, urcite uz spoustu veci znas", to je velmi spatne.
-
jo a samozrejme se bavime o tom ze clovek pise naprosto standardizovany kod, zamenitelny s kazdym jinym django projektem na svete aby se dalo vubec leveragovat to ze je to framework.
Naprasit v tom nejakou mrdku, kterou nikdo jiny nez jeden dva lidi z jednoho teamu v jedne firme v jednom projektu nerozumi, to umi kazdej lopata, je snad zrejmy ze se bavim o tom jak psat Django idiomaticky.
-
Operátor === sa odporúča používať, má odstraňovať problémy ==.
Předpokládám, že to bude jako v JavaScriptu. "Používejte ===, pokud nevíte, co děláte." Samozřejmě nejlepší je vědět. Nicméně ten druhý příklad je wtf! To se jim moc nepovedlo (v JS s tím problém není). :o
-
to je to srandovni - djano o sobe pise ze prave je opinionated (souhlas), nacez v dokumentaci se snazi mlzit a nabizet nejake unopinionated pristupy. Opet napisu co jsem psal vyse - Django neumi rict jak to samo chce abys to delal.
příklad?
-
.....
Zkuste být konkrétnější. Jinak to vypadá, že jen opakujete, co jste se někde dočetl.
-
jak sem vyse psal a vy ste to nasledne potvrdil peti linkama, nad vice nez 5 mist se nedostanete, a to je pri vyberu prace zalostne malo, opet to napisu znova, v php/jave/.netu je tady toho "NASOBNE" vice a proto delat v CR (WEB!!!!!) python je uplny nesmysl pro karieru.
Tak snad si nečekal, že tady pošlu 100 linků? Dal jsem 4 na ukázku, zmínil pár dalších obecně, zbytek si dohledáš.
Nebudu popírat, že v php/java/.net je násobně víc pozic, ale proč by to mělo vadit? Já měnil práci dost nedávno a to že jsem silně preferoval Django vůbec neomezilo nabídku. Lidi sháněj všude a programátor si může vybírat podle čeho chce, klidně podle použité technologie.
Zbytek příspěvku jsem subjektivní, nepodložené výkřiky.
-
a tak bych byl rád kdyby mi zde raději někdo porovnal Python a Node.js (a to jak z technické stránky tak i po stránce uplatnění těch technologií v praxi apod...)
Případně navhrněte i nějakou další alternativu.
Mám čerstvou zkušenost z firmy, kde se postupně použily všechny 3 zmiňované technologie.
Začalo to 2 vzájemně propojenými projekty v Nette (web a api zvlášť, ale nad stejnou db), které z různých (i netechnických) důvodů doiterovaly do hrůzy, kterou nikdo neuměl dát do kupy. Kromě jiných faktorů tam ale hrálo i roli to, že Nette je takové trochu nedodělané a věci, které jiné frameworky (nejen Django, ale třeba i Laravel) mají vyřešené, se řešily ručně.
Tým na to reagoval tak, že začali tlačit Node.js. Vzniklo dost microservices, které se nasekaly rychle, ale problém byl ve dvou věcech:
1) neexistence jasných standardů vedla k tomu, že každá služba byla udělaná jinak
2) velká rychlost jakou se proměňuje JS ekosystém - zažili jsme přechod npm -> yarn, kterým se rozbilo pár věcí nečekaným způsobem, callbacky -> Promise (různými způsoby: es6-promisify, bluebird a já nevím co ještě) -> async/await. i neustálé náhrady nějakých knihoven (node-uuid -> uuid, apod.).
Výsledkem bylo to, že na můj vkus se příliš energie věnovalo neustálým přepisům a refaktorům místo přidávání fíčur.
Nakonec jsme se dostali k tomu, že jsme jak zastaralé Nette, tak progresivní Node.js nahradili Pythonem, kde databázová a webová část se udělala v Djangu, na což se velmi hodí a to, co se hodilo řešit pomocí microservis se udělalo v asynchronním Pythonu (aiohttp).
Neříkám, že tahle zkušenost se dá doslova zobecnit, ale pát poučení bych si z ní vzal:
1) Na web použít vyspělý framework, jedno ve které jazyce (RoR, Django nebo Laravel mi přijdou ok), Nette má jedinou výhodu, že je v Česku populární
2) Node.js vyžaduje disciplínu, aby se člověk neutopil v možnostech, které nabízí a je třeba počítat, že se neustále mění
3) Použití nejnovějších technologií nevede k lepším výsledkům než staré, ale osvědčené nástroje (třeba nasazením GraphQL jsme si dost užili a vše se zlepšilo návratem k trapnému RESTu)
-
3) Použití nejnovějších technologií nevede k lepším výsledkům než staré, ale osvědčené nástroje (třeba nasazením GraphQL jsme si dost užili a vše se zlepšilo návratem k trapnému RESTu)
Což je zkušenost, kterou by vám řekl každý vývojář s praxí 20+ let , protože viděl x podobných módních vln. :)
-
Ďalšia vec, ktorú som si včera všimol. PHP má podobne ako JavaScript dva operátory na porovnanie, == a ===.
Operátor == má množstvo problémov, napr:
<?php
$x = '12a';
$y = 12;
echo ($y == $x) ? 'equal' : 'not equal';
Príklad vypíše equal. Číslo 12 a string '12b' sú podľa tohoto operátora rovnaké.
To je vcelku jasné, viz dokumentace o porovnávání pomocí "==" + chování převodní funkce intval v PHP:
"If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically."
intval: string "12b" => int 12
Operátor === sa odporúča používať, má odstraňovať problémy ==. Pritom prináša ďalšie problémy, trebárs:
<?php
$x = 100;
$y = $x + 0.0e0;
echo ($x == $y) ? 'equal' : 'not equal';
echo ($x === $y) ? 'equal' : 'not equal';
Pri pripočítaní nuly s desatinnou čiarkou dôjde k situácii, kde operátor === vráti 'not equal'.
Ani tady v tom nevidím žádné překvapení - $x je int, $y bude kvůli druhému operandu ve sčítání float (typ výsledku se určí podle typů operandů, ne výsledné hodnoty). A "===" pak samozřejmě porovnává i typ, ne jen hodnotu.
PHP si s typy prostě dělá co sám chce podobně jako JS a je na to potřeba si dávat pozor - pokud si nejsem jistý, doplním před výpočtem nebo porovnáváním konverzi na stejný typ.
Třeba C# je daleko striktnější (předpokládám i java) a pokus o porovnávání stringu a čísla pomocí == mi vůbec nedovolí.
-
Tomu chápem, akurát to pozajtra zabudnem. Python má jeden import, PHP má na výber štyri možnosti, a teraz programátor musí uvažovať, ktorú si má zvoliť. Je to čo mu sa tuším hovorí zbytočný mental burden.
Programátor uvažovat nemusí. Na include může rovnou zapomenout. Pro vkládání knihoven může používat pouze require_once, a dál uvažovat nemusí.
Python používá import v podobném duchu jako require_once. Python řeší moduly, PHP pouze vkládá soubory - i když to ve výsledku dopadne podobně.
-
Ďalšia vec, ktorú som si včera všimol. PHP má podobne ako JavaScript dva operátory na porovnanie, == a ===.
Operátor == má množstvo problémov, napr:
Oba operátory pracují tak jak mají.
1) Operátor === a !== vyžadují pro rovnost 1) oba operandy musí být stejného typu, 2) oba oerandy musejí mít stejnou hodnotu. V případě objektů se za stejnou hodnotu považuje pouze to, že se jedná o stejné objekty.
2) Operátory == a != se naproti tomu snaží nejdříve provést typové konverze.
a) Všechny null operandy převede na prázdný string.
b) Pokud je alespoň jeden operand boolean, převede i druhý operand na boolean.
c) Pokud je alespoň jeden operand číslo, převede i druhý operand na číslo.
A pak teprve porovnává. S tím, že:
a) Při porovnávání objektů se porovnává rovnost typu objektů a rovnost všech astributů (proměnných) třídy.
b) Porovnávání pole s jakýmkoli jiným typem dopadne tak, že pole je vždy větší než to druhé.
c) Porovnávání objektu s čímkoli jiným - objekt je vždy větší.
d) Řetězce a čísla se porovnávají očekávaně (po typové konverzi).
Číslo 12 a string '12b' sú podľa tohoto operátora == rovnaké.
Protože jeden z operandů je číslo. Takže PHP převede i druhý operand "12b" na číslo. PHP bohužel řetězce na čísla převádí velkoryse, bere zepředu všechny číslice, dále to ignoruje. \intval("12b") je tedy 12.
Po typové konverzi pak PHP porovná 12 == 12, a to je "rovnaké".
-
Operátor === sa odporúča používať, má odstraňovať problémy ==. Pritom prináša ďalšie problémy, trebárs:
$x = 100;
$y = $x + 0.0e0;
echo ($x == $y) ? 'equal' : 'not equal';
echo ($x === $y) ? 'equal' : 'not equal';
Pri pripočítaní nuly s desatinnou čiarkou dôjde k situácii, kde operátor === vráti 'not equal'.
V každém programovacím jazyce platí, že:
a) Celá čísla jsou čísla přesná, tudíž jejich porovnávání dopadne vždy správně.
b) Reálná čísla (v plovoucí čárce) jsou čísla nepřesná, tudíž jejich porovnávání nemusí dopadnout správně.
V každém programovacím jazyce platí, že porovnávání dvou stejných reálných čísel může nebo nemusí ukázat rovnost. Je to proto, že reálná čísla nejsou přesná.
Právě tento fakt je jediným důvodem, proč se zavedla celá čísla v programovacích jazycích. Protože celá čísla se chovají předvídatelně, reálná čísla nikoli. Reálná čísla se nikdy, zdůrazňuji nikdy, neporovnávají přímo - protože nelze zaručit jak to dopadne.
Pokud už je nutné porovnávat reálná čísla, dává se tomu tolerance.
Namísto
if ($x == $y) echo "Reálná čísla jsou stejná";
se píše něco jako
if (\abs($x - $y) < 1e-5) echo "Reálná čísla jsou stejná";
-
PHP si s typy prostě dělá co sám chce podobně jako JS a je na to potřeba si dávat pozor - pokud si nejsem jistý, doplním před výpočtem nebo porovnáváním konverzi na stejný typ.
Vím, co máte na mysli, ale aby to někdo špatně nepochopil, PHP si s typy prostě nědělá co chce, pokud si to nepřejeme.
declare(strict_types=1);
function sum(int $a, int $b) {
return $a + $b;
}
try {
var_dump(sum(1, 2));
var_dump(sum(1.5, 2.5));
} catch (TypeError $e) {
echo 'Error: '.$e->getMessage();
}
Výsledek:
int(3)
Error: Argument 1 passed to sum() must be of the type integer, float given, called in - on line 10
http://php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration
Nikdo nikomu v PHP nezakazuje, aby si strikně dodržoval nějaká stanovená pravidla.
-
[a) Máme Symfony controller a v ňom sa pripájame cez DBAL na databázu. Je potrebné nejako explicitne
uzatvoriť objekt connection? Vraj netreba, lebo PHP má všetko na konci cyklu request/response uzavrieť, ale nejako sa mi to nezdá. V Jave poctivo voláme na objekte connection close metódu.
/**
* @Route("/getdata", name="getdata")
*/
public function data(Connection $conn)
{
$data = $conn->fetchAll("SELECT * FROM countries LIMIT 5");
return $this->json([
'data' => $data
]);
}
Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.
-
c) Používať try/catch v kotrolleri alebo nie? Podľa PHP delusions https://phpdelusions.net/delusion/try-catch treba použiť try/catch len v zriedkavých prípadoch, inak to treba nechať doplávať do systémového kódu, ktorý by mal vygenerovať error page.
Pro výjimky platí to co všude.
a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.
b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.
c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.
Ja som primárne Javista. V Java sa viem obvykle dopátrať ku best practices, v PHP sa mi to zdá viac zamotané.
Best practices jsou na 99 % společné mezi všemi jazyky.
V PHP je pouze více možností. A také se v PHP pohybují méně zkušení programátoři - takže se často dělají věci, které nejsou příliš dobré.
-
PHP si s typy prostě dělá co sám chce podobně jako JS a je na to potřeba si dávat pozor - pokud si nejsem jistý, doplním před výpočtem nebo porovnáváním konverzi na stejný typ.
PHP má jasně definováno, co se děje s typy. Dělá tedy přesně to, co má předepsáno.
Ochotnější automatické přetypování v PHP je důsledkem toho, že PHP vychází z Perlu.
-
Operátor === sa odporúča používať, má odstraňovať problémy ==. Pritom prináša ďalšie problémy, trebárs:
$x = 100;
$y = $x + 0.0e0;
echo ($x == $y) ? 'equal' : 'not equal';
echo ($x === $y) ? 'equal' : 'not equal';
Pri pripočítaní nuly s desatinnou čiarkou dôjde k situácii, kde operátor === vráti 'not equal'.
V každém programovacím jazyce platí, že:
a) Celá čísla jsou čísla přesná, tudíž jejich porovnávání dopadne vždy správně.
b) Reálná čísla (v plovoucí čárce) jsou čísla nepřesná, tudíž jejich porovnávání nemusí dopadnout správně.
V každém programovacím jazyce platí, že porovnávání dvou stejných reálných čísel může nebo nemusí ukázat rovnost. Je to proto, že reálná čísla nejsou přesná.
Právě tento fakt je jediným důvodem, proč se zavedla celá čísla v programovacích jazycích. Protože celá čísla se chovají předvídatelně, reálná čísla nikoli. Reálná čísla se nikdy, zdůrazňuji nikdy, neporovnávají přímo - protože nelze zaručit jak to dopadne.
Pokud už je nutné porovnávat reálná čísla, dává se tomu tolerance.
Namísto
if ($x == $y) echo "Reálná čísla jsou stejná";
se píše něco jako
if (\abs($x - $y) < 1e-5) echo "Reálná čísla jsou stejná";
Ano, obecně to pro floaty platí. Jenže tady je zrovna důvod jiný. 100 je ve floatu exaktní, nedošlo tam k žádnému zaokrouhlení. Takže to porovnání vrací false z jiného důvodu. Podle popisu === bych tipoval, že je to proto, že integer a float to bere jako různé typy.
-
Ano, obecně to pro floaty platí. Jenže tady je zrovna důvod jiný. 100 je ve floatu exaktní, nedošlo tam k žádnému zaokrouhlení. Takže to porovnání vrací false z jiného důvodu. Podle popisu === bych tipoval, že je to proto, že integer a float to bere jako různé typy.
To máte naprosto pravdu. Jsou to různé typy.
-
Ani tady v tom nevidím žádné překvapení - $x je int, $y bude kvůli druhému operandu ve sčítání float (typ výsledku se určí podle typů operandů, ne výsledné hodnoty). A "===" pak samozřejmě porovnává i typ, ne jen hodnotu.
PHP má jasně definováno, co se děje s typy. Dělá tedy přesně to, co má předepsáno.
Z dokumentácie sa to dá pochopiť, aký je tam rozdiel. Ale existuje tiež niečo ako zavedené postupy v programovaní, štandardné správanie.
int x = 100;
double y = x + 0.0e0;
System.out.println(x == y);
Java vráti true.
int x = 0;
double y = x + 0.0e0;
Console.WriteLine(x == y);
C# vráti True.
#!/usr/bin/perl
$x = 100;
$y = $x + 0.0e0;
print($x == $y);
Perl vráti 1.
#!/usr/bin/ruby
x = 100
y = x + 0.0e0
puts x == y
Ruby vráti true.
#!/usr/bin/python3
x = 100
y = x + 0.0e0
print(x == y)
Python vráti True.
let x = 100;
let y = x + 0.0e0;
console.log(x == y);
console.log(x === y);
JavaScript vráti true true.
-
jano7: Ano, a přesně takový bordel vzniká, když jazyk nemá svůj standard. Pak se vyvíjí pouze stylem nalepovák na nalepovák, a ve výsledku je jazyk plný nelogičností a nekonzistence.
-
int x = 100;
double y = x + 0.0e0;
System.out.println(x == y);
Java vráti true.
C# vráti True.
Perl vráti 1.
...
JavaScript vráti true true.
Pro "==" vrátí true i PHP.
Celou dobu šlo o "===" sledující shodu hodnoty i typu operandů.
Javascript se u "===" zachová jinak než PHP, protože pro čísla zná pouze jediný datový typ Number, na rozdíl od PHP rozlišujícího int a float.
Takže vše se chová dle očekávání příslušného jazyka.
-
Jen tak pro zajímavost (Javascript)
typeof NaN === 'number'
/*
true
*/
-
Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.
Áno, to je rozumný predpoklad. Nedá sa však na neho spoliehať vždy. Napríklad Java a databázové drivery. Tie by sa mali správať podľa nejakého štandardu, ale v praxi to často neplatí. Našiel som v zdrojáku Spring JdbcTemplate (nadstavba nad JDBC) takýto koment: We don't trust the JDBC driver: It might throw RuntimeException or Error. Preto som chcel nájsť niekde explicitne proste napísané -- netreba uzavierať connection object. Nič také som nenašiel.
Pro výjimky platí to co všude.
a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.
b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.
c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.
V mojom prípade by to malo byť a. Ale mne sa jednoducho nepáči kód "zasvinený" try/catch blokmi. Preto by som rád to nechal plávať vyššie. Neviem či sa dajú priamočiaro preniesť best practices z Javy to PHP; Java zásadne vždy robí všetko komplexne a zložito. Rád by som našiel aj k výnimkám niečo ako the PHP way, ale nepodarilo sa. Pozdával sa mi názor z PHP delusions, ktorý som uviedol, avšak to je názor len z jedného zdroja a tak som opatrný.
-
Jen tak pro zajímavost (Javascript)
typeof NaN === 'number'
/*
true
*/
<?php
echo FALSE == NULL;
ECHO FALSE == NULL;
eCHo FALSE == NULL;
Vypíše 111.
-
Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.
Áno, to je rozumný predpoklad. Nedá sa však na neho spoliehať vždy. Napríklad Java a databázové drivery. Tie by sa mali správať podľa nejakého štandardu, ale v praxi to často neplatí. Našiel som v zdrojáku Spring JdbcTemplate (nadstavba nad JDBC) takýto koment: We don't trust the JDBC driver: It might throw RuntimeException or Error. Preto som chcel nájsť niekde explicitne proste napísané -- netreba uzavierať connection object. Nič také som nenašiel.
Pokud nic nenajdete, tak nic nezavírejte. Pokud máte něco zavřít, tak to bude zmíněno.
Je dost neobvyklé, aby podprogram likvidoval objekty a zdroje, které dostane jako parametr. Patří to ke špatným způsobům. Pokud je to nutné či účelné či očekávané, aby podprogram zavřel/zlikvidoval objekt, většinou se o tom píše, protože to intuitivně nikdo nečeká.
-
Pro výjimky platí to co všude.
a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.
b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.
c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.
V mojom prípade by to malo byť a. Ale mne sa jednoducho nepáči kód "zasvinený" try/catch blokmi. Preto by som rád to nechal plávať vyššie. Neviem či sa dajú priamočiaro preniesť best practices z Javy to PHP; Java zásadne vždy robí všetko komplexne a zložito. Rád by som našiel aj k výnimkám niečo ako the PHP way, ale nepodarilo sa. Pozdával sa mi názor z PHP delusions, ktorý som uviedol, avšak to je názor len z jedného zdroja a tak som opatrný.
PHP si samo se sebou neví moc rady. Doporučuji prostě přenést obecné best practices, jen tak dáte PHP štábní kulturu.
Java některé věci dělá dobře, jinými věcmi zase spíše kompenzuje to, že jazyk nic neumí, je příliš jednoduchý. Ale ve výjimkách to dělá spíše dobře.
Osobně se nevyhýbám kódu plnému try/catch, když to má smysl. Myslím, že nejlepší co se dá udělat je vyřešit chybu/výjimku co nejblíže místu, kde vznikla. Tedy, pokud umím na nějakém místě ošetřit chybu/výjimku, tak to udělám.
1) Pokud mohu šíření výjimky zcela zastavit a převést program do stabilního stavu, je to moje první snaha.
2) Pokud chytám výjimku, jejíž typ a popis je příliš low level, a směrem nahoru se nehodí, tak výjimku zachytím a vyhodím vhodnější. Například pro funkci getCachedImage() se příliš nehodí vyhodit výjimku FileNotFoundError(), ale je lépe ji změnit na CachedImageNotFoundError(). Funkce výše nemusejí vědět, jak je kešovaný obrázek uložen, je zajímá, že ho nelze získat.
Cílem je posílat nahoru co nejméně chyb a výjimek. Pokud je možné něco vyřešit na místě, nechť je to vyřešeno. Ošetřování chyb je vždy "nehezké", nehledím proto na počet try/catch, či počet if/elseif či dalšího. Nejlepší možný stav je mít kód, který generuje co nejméně chyb směrem nahoru, a posílá chyby/výjimky jen tehdy, když to nejde řešit jinak.
Dalším cílem je posílat nahoru (volajícím) chyby, kterým "hořejšek" (volající) rozumí. Viz ad 2).
Každý framework/program by měl mít na úrovni funkce main() zachytávač všech nezpracovaných výjimek, které převede do nějakého rozumného hlášení uživateli a případně zaloguje. To je ale věc frameworku, to by uživatel řešit neměl.
***
Co by se nikdy dít nemělo, je zachycovat všechny výjimky bez ošetření. Toto je prasárna hrubého zrna, za kterou by měl jít programátor klečet na hrách:
try { ... } catch (Throwable/Exception $e) {} # PHP 7 = Throwable, PHP 5 = Exception
***
Nejtěžší je u projektu vymyslet vlastní strom tříd výjimek, aby byl logický a dobře, přitom jednoduše, vyjadřoval možné chyby v kódu.
-
Už výjimky nevycházejí z \Exception, ale z \Throwable.
Výjimky stále vycházejí z \Exception. Throwable je jen interface, které \Exception implementuje.
Protože PHP nenabízí ani kompilaci do binárního/p-kódu, při každém HTTP requestu se znovu a znovu kompiluje jako u pitomců
To není pravda už od verze 5.5 (před 6 lety). Načtení, parsování a kompilování php skriptu proběhne jen při prvním požadavku na něj. Při každém dalším požadavku Zend Engine už jen provádí zkompilovaný opcode z opcache - obrázek (https://p14.zdusercontent.com/attachment/7280/9e2vlmtvjxpijbv?token=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..N89ayccxC30krV9YIzcb_w.QlATLlJR7mWtFjnSpzj6c6xZb91cv7pFTihrsdHuGKFYZWEl_xqw6eVfvhx6EI1mTpLwFgHicSPidAtGsx7dRS-NlZ5lrS9YtXqjb6N6bpoTfMmIYdu2LsbZAypG4o6_D4i25Q139n8tXtB24bOWCBxX3Ev-vDhHuj7hIzdtep-zgVIJMyJWsQKTU6XnIs814DvQ2DOIYHWLYLfiE3V3g5-zPpRcwyUUHN3DV4699HjwrV0MvQQx3BiplfaBdTbJbox7MqN5t4fTbypHMpXWfg.tX6b3Y4qW7eL7h7DYQwMJA).
-
Výjimky stále vycházejí z \Exception. Throwable je jen interface, které \Exception implementuje.
A proto existuje v PHP 7 řada tříd výjimek, které nejsou potomky třídy \Exception. To je velice skvělé, doporučuji tyto kraviny dělat tvůrcům PHP co nejčastěji. PHP je historicky první programovací jazyk, který programátorům pod rukou změnil prapředka tříd výjimek.
Zvláště je třeba ocenit, že PHP udržuje bdělost programátorů. Změnit tak rozsáhle způsoby oznamování chyb v jazyce i knihovnách - to je na popravčí četu.
To není pravda už od verze 5.5 (před 6 lety). Načtení, parsování a kompilování php skriptu proběhne jen při prvním požadavku na něj. Při každém dalším požadavku Zend Engine už jen provádí zkompilovaný opcode z opcache
Aspoň jedna pozitivní zpráva. Třeba to příště na druhý pokus dokáží kompilovat do souboru jako běžné programovací jazyky.
-
a tak bych byl rád kdyby mi zde raději někdo porovnal Python a Node.js (a to jak z technické stránky tak i po stránce uplatnění těch technologií v praxi apod...)
Případně navhrněte i nějakou další alternativu.
Mám čerstvou zkušenost z firmy, kde se postupně použily všechny 3 zmiňované technologie.
Začalo to 2 vzájemně propojenými projekty v Nette (web a api zvlášť, ale nad stejnou db), které z různých (i netechnických) důvodů doiterovaly do hrůzy, kterou nikdo neuměl dát do kupy. Kromě jiných faktorů tam ale hrálo i roli to, že Nette je takové trochu nedodělané a věci, které jiné frameworky (nejen Django, ale třeba i Laravel) mají vyřešené, se řešily ručně.
Tým na to reagoval tak, že začali tlačit Node.js. Vzniklo dost microservices, které se nasekaly rychle, ale problém byl ve dvou věcech:
1) neexistence jasných standardů vedla k tomu, že každá služba byla udělaná jinak
2) velká rychlost jakou se proměňuje JS ekosystém - zažili jsme přechod npm -> yarn, kterým se rozbilo pár věcí nečekaným způsobem, callbacky -> Promise (různými způsoby: es6-promisify, bluebird a já nevím co ještě) -> async/await. i neustálé náhrady nějakých knihoven (node-uuid -> uuid, apod.).
Výsledkem bylo to, že na můj vkus se příliš energie věnovalo neustálým přepisům a refaktorům místo přidávání fíčur.
Nakonec jsme se dostali k tomu, že jsme jak zastaralé Nette, tak progresivní Node.js nahradili Pythonem, kde databázová a webová část se udělala v Djangu, na což se velmi hodí a to, co se hodilo řešit pomocí microservis se udělalo v asynchronním Pythonu (aiohttp).
Neříkám, že tahle zkušenost se dá doslova zobecnit, ale pát poučení bych si z ní vzal:
1) Na web použít vyspělý framework, jedno ve které jazyce (RoR, Django nebo Laravel mi přijdou ok), Nette má jedinou výhodu, že je v Česku populární
2) Node.js vyžaduje disciplínu, aby se člověk neutopil v možnostech, které nabízí a je třeba počítat, že se neustále mění
3) Použití nejnovějších technologií nevede k lepším výsledkům než staré, ale osvědčené nástroje (třeba nasazením GraphQL jsme si dost užili a vše se zlepšilo návratem k trapnému RESTu)
z toho co pisete, to zni jako kdyby ste tam byla parta 20 letych programatoru, kteri se snazi implementovat jakoukoliv novou cool vec jen proto ze je to cool. pouzivat yarn misto npm, k tomu neni absolutne zadny objektivni duvod, mohl bych pokracovat....
-
z toho co pisete, to zni jako kdyby ste tam byla parta 20 letych programatoru, kteri se snazi implementovat jakoukoliv novou cool vec jen proto ze je to cool. pouzivat yarn misto npm, k tomu neni absolutne zadny objektivni duvod, mohl bych pokracovat....
Tak fakt je, že většina týmu byla o dost mladší než já, někde 22-26, ale největší propagátor tady těch JS novinek a přepisů do nových frameworků měl blíž ke 40 než 30.
Na druhou stranu, zrovna přechod na yarn, v době kdy se objevil, přinesl zrychlení buildu v řádu minut, což bych jako objektivní důvod bral (to že npm se potom taky zlepšilo je další věc).
-
mojo https://mojolicious.org/
-
mojo https://mojolicious.org/
Odpověď na
Navíc se zabývám myšlenkou jakým směrem se dál vyvíjet abych měl do budoucna na trhu práce co nabídnout
asi nebude perl.