Názory k článku PHP 8: trojnásobný výkon díky JIT a užitečné novinky pro programátory
-
Hezke a je fajn, ze se na tom maka a posouva dal. Na php jsem kdysi davno zacinal a tak je to moje srdcovka nicmene mam pocit, ze je na tom dnes podobne jako byla java pred 10ti lety - legacy systemy se na tom udrzuji protoze je jeste porad dost lidi, kteri v tom pisou, ale neco noveho na tom nikdo dnes uz asi stavit nebude :)
-
Já bych opravdu chtěl slyšet nějaký rozumný důvod proč na PHP stavět něco nového. Napadají mě v podstatě jenom dva:- PHP umím
- PHP developer je levnější
-
3. PHP umí všechny levné webhostingy.
Což je i odpověď na otázku, jakou výhodu má PHP proti Java, Python, Ruby, Go nebo C#. Jestli budete platit 30 Kč měsíčně za webhosting nebo 300 Kč měsíčně za VPS plus X Kč za administrátora je u spousty projektů rozdíl. Ne všechny projekty jsou tak velké, že se vyplatí je nasazovat do cloudu.
-
Java, C# a Go cielia na trochu iné kategórie systémov, typickí konkurenti PHP sú podľa mňa hlavne Python, Ruby, Perl a taktiež JavaScript.
Ruby a Perl majú problém, že sú v porovnaní s ostatnými oveľa menej rozšírené, pričom žiaden špeciálny benefit neprinášajú. No a rozhodovanie medzi Python, PHP a JS na BE je potom hlavne otázkou programátorského štýlu, ktorý preferujeme.
Ak preferujeme klasický OOP prístup, tak ani Python ani JS rozhodne nemá tak pokročilé OOP ako PHP. Rovnako aj typové kontroly sú v PHP už na veľmi slušnej úrovni a hlavne sa ďalej zdokonaľujú každou vydanou novou verziou, oproti Pythonu tu má PHP značný náskok.
Taktiež z hľadiska syntaxe je PHP najbližšie ku "klasickým" jazykom ako C či Java, najmä Python je v tomto smere tak trochu "hypsterčina", ktorá nemusí každému vyhovovať a nie každý sa je ochotný ju učiť, keďže podobné syntaktické špeciality ako určovanie scope podľa úrovne odsadenia či všetky tie "underscore konvencie" sa v iných jazykoch bežne nenachádzajú.
PHP dnes už nemá žiaden fundamentálny problém, prečo by sa v ňom nedal robiť kvalitný kód a kto chce jazyk syntaxou a vlastnosťami podobný Jave, ale viac "lightweight" a s jednoduchším deploymentom, tak určite bude PHP zvažovať.
Na druhej strane, ak si niekto obľúbil Python syntaktickú hypsterčinu alebo potrebuje riešiť doménu, kde sú pre Python dostupné lepšie knižnice, tak sa rozhodne pre Python. No a kto chce na BE rovnaký jazyk ako na FE alebo kladie dôraz na asynchrónne spracovanie, tak ten asi bude zvažovať najmä JavaScript.
-
Ale to je přesně co si myslím. Pokud je projekt velký tak PHP nepoužiji a pokud je zas malý s FE, tak použiji JS i na BE. Proč bych psal FE v JS a BE v PHP? U malého projektu je mi OOP celkem šumák a to, že je PHP podobné C mi už tuplem přijde nepodstatné. Navíc PHP se skoro nikde než na webové aplikace nepoužívá, narozdíl od JS a Pythonu. Je mi celkem šumák, že Python syntaxe je podle někoho hipsterská, protože ho můžu využít od AI až po MicroPython a nejedná se jenom o okrajové projekty, které používá pár lidí. Tohle mi u PHP naprosto chybí.
4. 12. 2020, 22:49 editováno autorem komentáře
-
- JS na BE pro malý projekt je pořád o VPS. Sdílený hosting ho nabízí sporadicky.
- I malý projekt může narůst, a kvalitní architektura je imho vždy základ.
- PHP z těch "malých" jazyků nabízí největší paletu nástrojů, jak toho dosáhnout.
- Osobně mám radši jazyky i projekty, co dělají hlavně to, na co jsou navržené, a dělají to dobře. O mnohých "hipsteřinách" se to říct nedá a zrovna JS je často špartným příkladem. "Nativní aplikace" z Elektronu s "hello world" kolem 80 MB. Jako ukázka možností dobrý, ale když v tom někdo vyvine něco, co by v pitomém Céčku s pitomýma knihovnama z roku začínajícího jedničkou, běželo i na kalkulačce, a ona mi ta supermoderní bestie sežere celou paměť, tak nevím...
- konec PHP se předvídá už od doby Flashe, co pamatuju. A kde je Flash:-) Na backend prostě dobrý a s určitým solidním vývojem, jinam ale netahat. -
PHP z těch "malých" jazyků nabízí největší paletu nástrojů, jak toho dosáhnout.
PHP má paletu nejširší, ale taky někdy dost pitomě zpracovanou. Např. hojně používané CURL funkce, které jsou "nejlepší", ale taky nejpitomější a k tomu v PHP implementovány nešikovně - např. skvěle Vás vypeče závislost na proměnné ARG_MAX, může být dost malá když serializujete.
Image magick funkce jsou taky "velká radost", zejména když se potkají s poškozenými obrazovými daty.
Osobně mám radši jazyky i projekty, co dělají hlavně to, na co jsou navržené, a dělají to dobře.
Což je naopak obrovská slabina PHP. Na každý požadavek se sestavuje kompletní prostředí od nuly a na konci zaniká. PHP-FPM je nalepenec, který hodně pomohl, ale problém jen oddálil - nevyřešil.
PHP je naopak velmi nešťastně navržené na to, na to se používá. Jeho popularita je dána opravdu tím, že out-of-box nabízí velkou šíři funkcí (knihoven) a tuto pozici si vybudovalo v době, kdy mělo opravdu pramálo konkurence. V době, kdy jsme mohli volit mezi CGI/perl, CGI/cokoliv a vše si nalátat od nuly (od hlaviček odpovědi), bylo PHP opravdu velký posun vpřed. Dnes je to koule u nohy.
-
Což je naopak obrovská slabina PHP. Na každý požadavek se sestavuje kompletní prostředí od nuly a na konci zaniká. PHP-FPM je nalepenec, který hodně pomohl, ale problém jen oddálil - nevyřešil.
To, že sa takto z dôvodu jednoduchosti chová PHP defaultne ešte neznamená, že to je jediná možnosť. Už v ére PHP 5 existovali veci ako Opcache či APC a od verzie 7.4 máme aj PHP preloading.
Ak sa správne použije preloading + APCU tak tvrdenie o zostavovaní kompletného prostredia od nuly pri každej požiadavke nemôže byť vzdialenejšie od skutočnosti.
-
Už v ére PHP 5 existovali veci ako Opcache či APC a od verzie 7.4 máme aj PHP preloading.
Jasně, ale to všechno jsou narovnáváky na ohejbáky. Dotahují designovou slabinu. Opcache či APC trpí tím, čím veškeré cache: buďto riskujete neaktuální data, nebo musíte pokaždé kontrolovat (což jsou cenné iopsy). Preloading je fajn, pokud máte na každou aplikaci svůj FPM pool (což může být problém v případě hostingů).
Ak sa správne použije preloading + APCU tak tvrdenie o zostavovaní kompletného prostredia od nuly pri každej požiadavke nemôže byť vzdialenejšie od skutočnosti.
Ale jistěže se sestavuje pokaždé znovu, jen využívá přednatažených dat.
-
Ale to je přesně co si myslím. Pokud je projekt velký tak PHP nepoužiji a pokud je zas malý s FE, tak použiji JS i na BE. Proč bych psal FE v JS a BE v PHP? U malého projektu je mi OOP celkem šumák a to, že je PHP podobné C mi už tuplem přijde nepodstatné.
To je ale čiste subjektívne hodnotenie, nie nejaká objektívne platná skutočnosť. Takže to čo platí pre teba, nemusí platiť pre iných a nedá sa na základe toho tvrdiť, že PHP nemá zmysel pre nikoho.
Tebe je napríklad OOP "celkem šumák", niekto iný ho považuje za klúčové ... a tak by sme mohli pokračovať.
-
Zvladnes v necem jinem nez PHP (z tech co jsi jmenoval) udelat za vikend kvalitne postaveny CMS se spravou uzivatelu a opravneni, flexibilni strukturou entit a jejich vlastnosti, spravou medii, i18n a l10n apod. , s out-of-box exportem pres GraphQL ci JSONAPI? Pokud ano zvladnes pak pridavat nove polozky do entity na par kliknuti? Ja to s Drupalem zvladnu uplne v pohode a nebude to zadny extra sprint. (a frontend mi udela frontendak v Gatsby)
Mas v pythonu, perlu nebo ruby nejaky takovy hezky hotovy CMS ktery dokazes fakt jednoduse upravovat pokud jde o strukturu dat?I mimochodem v tomhle pripade ti to za vikend udelam i s kompletnim CI pres Docker a GitLab pipelines vcetne toho, ze se ti na nove git branch nahodi nove prostredi na vlastni subdomene...
5. 12. 2020, 09:49 editováno autorem komentáře
-
To je prece uplne nesmyslny argument.
Delam v PHP pres 20 let, a to co pisete nahore v PHP skutecne jde udelat. Ale to s tim musite mit dobrych par let zkusenosti, znat "ten svuj" framework, znat "ty sve" knihovny atd.
A mimochodem zaroven pracovat na fakt jednoduchem projektu, kde vlastne neni co programovat!Problem je v tom, ze lidi co delaji Jave to umi zrovna tak. A v C# taky. V pythonu. V javascriptu.
Proste profik to da dokupy rychle a efektivne, protoze o nic nezakopne.
Pokud zakopne, trva mu najit chybu stejne dlouho v PHP jako v Jave. Zna framework, zna deployment atd.Proste to co popisujes neni otazkou programovaciho jazyku, ale otazkou zkusenosti s nim a jeho "tooly".
-
Na to ja odpoved nedam, to se ptej pythonistu.
A stejne jako v PHP to neni jeden konkretni tool, ale nejaky set na ktery jsi zvykly, lze to stejne ocekavat i u ostatnich jazyku.
Nabyvam dojmu, ze protoze ty delas v PHP je vsechno ostatni na nic.
Ale faktem je ze - a to rikam jako PHPckar - opak je mozna pravdou. -
Moje srdcovka to není, ale je fakt, že se nad PHP někdo zamýšlí a snaží se ho posunout dále. Když čtu novinky z PHP 8, tak to konečně začíná vypadat jako jazyk. Ale souhlasím s vámi i když jen částečně. Podle mě by nebyl problém v tom, že by se všude používal lagacy věci. Rozhodně je hodně firem, které používají nové verze PHP, tak i FW. Problém spíše vidím ve dvou věcech: 1) hodně programátorů prostě "zakrnělo" v době PHP 4/5, 2) i když se použijí moderní přístupy a FW, lidi píší stále spaghetti. Obojí je prostě v lidech a to nijak nezměníme, ikdyž nabídneme úplně nejvíc nejdokonalejší FW.
Bohužel znám dost programátorů, pro které je MVC / MVP / MVVM architektura sprosté slovo, nedej bože po nich chtít nějaké ORM atd. Obecně je dost lidí, kteří se neradi učí nové věci, ať už jde o syntaxi, features atd, prostě si jednou na svém píšečku, který je technologicky starý 15 let. Další věcí je i to, že staré projekty se nepřepisují a důvodů je hned několik.
-
to ano, to je pravda. Ale i tak si myslím, že je stále hodně webů, které používají PHP jako vyložene server side. Přeci jen je tu Symfony, Nette, Laravel atd.
Na druhou stranu, záleží na tom, k čemu bude web fungovat. Nemá cenu používat FE framework, pokud půjde jen o statické stránky. Ale i tohle je otázkou, kdo to chce, jak to chce atd.
-
PHP je prave na REST uplne v pohode, pokud zvolite spravne tooly.
A tim mam namysli kompletni reseni od samotneho kodu vcetne TDD, CI atd.
Celkem snadno se skaluje na vetsi objem, microservices atd.Nikdy nebude nejrychlejsi, nikdy nebude nejefektivnejsi, ale pro relativne jednoduche male kousky je v pohode. A REST endpointy jsou presne o tom, ze jsou to male jednoduche kousky.
-
je to jen úhel pohledu... :-D Osobně, bych Javu nepoužil.
S kamarádem jsme psali v PHP crypto exchange, response byla v průměrně do 8ms. Každý uživatel má vlastní kontejnery za HAProxy a loadbalancerem. Existuje plno řešení.
Osobně mě spíše áráží, jak si lidé myslí, že v PHP nelze udělat rychlé weby. Z praxe vím, že to jde a výsledek je mnohdy o dost lepší, než jiné rádoby "skvělé" jazyky ;-)
-
samozřejmě že není, tedy pokud by jste chtěl použít K8s. A ne na vše se kubernet cluster hodí. Ono je to dnes takové zaklínadlo, říkat máme Kube, jsme skvělí.
Už jsem viděl, že se dekerizovala opravdu velká monolitická aplikace a protože to bylo napsáno v Javě a ještě blbě, raději se nasadil Kube cluster a brutálně se škálovalo. Což je špatně.
Napsat špatně jde vše, stejně tak použít kanón na vrabce jde skoro také vždy. Osobně mi to přijde jako žabomyší války o ničem, to jestli je PHP špatné nebo skvělé. Dobří programátoři jsou jak v PHP, Javě, .NET a dalších jazycích. Samozřejmě jsou také špatní. Podle mě je to vše jen o lidech. Z praxe vím, že chyby je z 99.9% mezi jazykem a klávesnicí, tj. programátor. samozřejmě, jsou konstrukce, které třeba jdou v jiném jazyku udělat lépe, rychleji, ale zase narazíte na jiná úskalí.
-
PHP je etablovaný jazyk, kde je zažitý styl vývoje, který vyhovuje relativně velké skupině vývojářů. GO vyhovuje úplně jiné sortě lidí a o NodeJS nemluvě (totéž platí pro Python, Javu). Tady si myslím, že je situace poměrně stabilizovaná - a není důvod si myslet, že by se mohlo něco nějak razantněji změnit v následující dekádě.
Technologie samotné určitým způsobem konvergují, ale to jak se používají (kultura kolem nich), to se nemění. Hezky je to vidět třeba na MySQL a na Postgresu. Funkčně tam dochází k určité konvergenci - kulturně ani náhodou (ty jednotlivé kultury neporovnávám, nehodnotím - tak jak se nedívím z patra na někoho, kdo má Renaulta, protože já mám škodovku). Jen konstatuji, že ty kultury přes technologickou konvergenci nekonvergují.
-
To je pravda, on se častěji hodnotí jazyk a zapomíná na vliv té kultury. Ta ovlivňuje celý vývoj. Mě třeba kultura PHP moc nevyhovuje, ale na druhou stranu se mi ani nezdá, že by bylo jednodušší vyvíjet v PHP oproti třeba Javě. Ta technologická konvergence totiž pomáhá, aby se dalo všude vyvíjet +- solidně a aby si šlo +- poradit s technologickou zátěží z minulosti, kterou si většina letitých technologií s sebou nese.
-
Me nejvice vadi ze PHP integer je ruznej podle platformy - nekde je 32bit, nekde je 64bit. A pak to, ze 32bit verze PHP nevidi a ani neotevre soubor ktery ma >2GB, i kdyz 32bit C binarka to samozrejme zvladne.
Nejvice by se me libilo mit tohle:
./configure --with-int-always-64bit
Takze pak nemusim resit v skriptech gmp_ zhovadilost. Bohuzel stejne pri pozadavku plnych 32/64bit jako unsigned hodnot, to musim enkodovat jako hex string nebo pouzit ono gmp_ :/
Ma nekdo nejakou lepsi radu?
(skriptuji ruzne analyzatory kodu, kde holt jsou nejbeznejsi ty U32/U64 hodnoty.. a zatim preferuji hex string, nez gmp objekty) -
Python ma podporu poli nativnich integeru, to je asi nejcastejsi pripad, kdy chcete pevnou velikost.
https://docs.python.org/3/library/array.html
2. 12. 2020, 10:05 editováno autorem komentáře
-
Tyhle debaty me vzdy pobavi.
Ono totiz zalezi co delate.Ja programuju uz dlouho a byly i situace, kdy bylo treba resit velikost integeru nebo floating point errors a tak. Jsou to extremni vyjimky i ve velice komplikovanych programech.
Jsou samozrejme situace, kdy takove veci musite hlidat od rana do vecera - nevim placnu treba neco v letectvi - jenze pak jiste nepouzivate PHP.
A tak mi nezbyva nez se zepatat - co je obsahem vasi prace, ze by vam bezne vadila velikost integeru a ostatni veci ktere jste zminil?
-
Vyhoda skriptovanych jazyku je, ze je pustite odevsad, bez nutnosti kompilace!
Typicky mam sdilene NFS skrze ruzna zarizeni, skript je tedy jedinej/spolecnej (zadny deploy se nekona, vse je hot & live), ale prostredi kde bezi je ruzne (32/64bit, x86/arm/power/sparc).
Ocekaval bych tedy moznost nakonfigurovat interpret tak, aby se choval pro skripty stejne, i kdyby to obnaselo degradaci vykonu. Protoze degradace vykonu resena runtime, v ramci skriptovaci strany je jeste horsi.
-
Pouzivam stejne interprety - php-cli, od stejneho "vyrobce". V cem se to podle vas lisi?
Napr. BASH se v aspektu, ktery kritizuji u PHP chova predikovatelne, matematicke vyrazy se pocitaji vzdy v 64-bit signed, nezavisle na tom, zda jde o 32bit nebo 64bit interpret:
$ file /bin/bash /bin/bash: ELF 32-bit LSB pie executable, ... $ let "a = 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 7 " ; echo $a 8070450532247928832 $ let "a = 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 8 " ; echo $a -9223372036854775808 $ let "a = 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 16 " ; echo $a 0
-
jasne ze ne, ale delat treba docker kontejner pro kazdej web co ma dve navstevy denne, neni proste, kdyz nic jineho, resource friendly
krom toho mas v CR min dva hostingy, co python nabizej, zjevne to k pokryti poptacky staci.
Vetsina lidi chce hotove reseni pro web, v php mas wordpress, joomlu, drupal a tisic dalsich. V pythonu co vim ani jeden. Rozhodne ne ve styly na instaluj na dve kliknuti, jako je tomu ve svete php zvykem.
Takze s tema hejtama opatrne. -
Vacsina tych webov, co ma dve navstevy denne si vystaci so statickym hostingom a generatorom statickych stranok typu Hugo, Nikola alebo nieco co tu cast upravovania poskytne ako sluzbu. (Squarespace, Weebly a podobne)
Pouzivat pre kazdy taky web kompletny CMS typu Wordpress alebo Joomla kde musi clovek casto prevadzkovat aj databazu nie je proste, ked uz nic ine, resource friendly. Okrem toho to zvycajne dopadne tak, ze taky web nikto neudrzuje a kazdu chvilu tam bezi nejaky mallware.
-
"Výhodou může být například jejich podpora v reflection API."
AFAIK tohle slo uz s docstringy
https://www.php.net/manual/en/reflectionclass.getdoccomment.php
-
Kdo si uz chce PHP8 testovat, tak zde je navod jak jednoduse nainstalovat na linuxovy server ruzne verze PHP vcetne verze 8:
https://www.youtube.com/watch?v=R96qFZlJf34 -
FPM je fajn na hraní ale vůbec není fajn na pořádné monitorování toho co se děje. Apachovský "fullstatus" řekne jak dlouho se který požadavek zpracovává, což se dá následně v monitoringu alertovat. Pokud se připojujete k nějaké službě (SQL databáze a podobně) a máte chybu v timeoutech, tak díky tomu můžete rychle diagnostikovat problém. Navíc ještě v php7 bylo (a možná ještě stále je, nesleduju to) race condition, která shodí master fpm proces když se workeři často restartujtou. Prostě apache2-mod-php je prověřená časem, fpm má stále ještě porodní bolesti.
-
Ono to může být zajímavé. Je "tradiční" programátorskou prasárnou v PHP dělat scripty, co běží sekundy, desítky sekund i minuty. To způsobuje spoustu problémů, instancí PHP není na serveru nevyčerpatelně. Programátory nezměníte (aspoň ne rychle), takže pokud tomu trochu pomůže urychlení PHP, tak jen dobře - jakkoliv je to narovnávák na ohejbák.
-
Každý, kdo si zkoušel dělat nějaké úlohy třeba pro Project Euler, brzy zjistí, že vejít se do časového limitu výpočtu není věcí zvoleného programovacího jazyka, ale vhodně napsaného algoritmu. Jinými slovy, pokud je programátor nezkušený a/nebo neví co dělá, optimalizace interpreteru je slabá náplast.
2. 12. 2020, 10:59 editováno autorem komentáře
-
Jinými slovy, pokud je programátor nezkušený a/nebo neví co dělá, optimalizace interpreteru je slabá náplast.
Pokud by programátor věděl co dělá, nikdy by PHP na webu nepoužil. To, že se musí celé prostředí s každým scriptem od nuly sestavit a počet procesorů není nevyčerpatelný, by PHP dopředu odsuzovalo k neživotu. Ale jak vidíme, tak žije, a s (nemalými) problémy funguje ke spokojenosti.
Každá náplast je pak dobrá. JIT, preloading tříd, ... Můžeme tu hodiny filozofovat nad tím, že existuje spousta vhodnějších technologií, ale tím programátory nezměníme. Ti si budou dál bastlit své PHP scripty, data zpracovávat ve smyčkách programu místo znalosti SQL, a nad to budou lepit zázračné cache mechanismy, preloading a JIT. Toť realita.
-
Miroslave, ono je docela často o dost snažší pročíst pár-řádkovy foreach než dešifrovat co autor myslel tím překomplikovaným SQL.
Ano, dělá se to z lenosti a neznalosti SQL, to chápu. SQL příkaz není o nic méně čitelný, navíc dáte stroji možnost práci s daty značně zoptimalizovat. Což už se pak špatně dohání v interpretovaném jazyce - JIT tomu může maximálně trochu pomoct.
-
To vůbec nesouvisí s interpretovaným jazykem. Pokud datové schéma nenavrhoval nějaký matlal, jsou data v databázi uložena tak, aby se dala rychle získat. Tj. nepotřebná data se pokud možno vůbec nenačítají z disku, případně nějaká menší část zbytečných dat se alespoň neodesílá po síti. Když data budete zbytečně načítat z disku, nezachrání to pak ani kdybyste je filtroval programem napsaným přímo ve strojovém kódu.
-
Prerekvizitou takového stavu ale je, aby databázové schéma a všechny query dělal databázový architekt a ne programátor. To jsou totiž dva dost rozdílné obory.
Ale popravdě - u většiny projektů se dnes nevyplatí investovat čas do větších optimalizací, je jednodušší a levnější použít knihovny co query do databáze vygenerují sami ( ostatně výsledek je často i tak lepší, než když se tu query pokouší napsat někdo, kdo to moc neumí ). Až u opravdu velkých projektů má smysl to optimalizovat víc .... ale to až ve chvíli kdy vynaložené náklady mají nějakou návratnost. HW je v porovnáním s nákladem na vývojáře většinou levnější.
Z druhé strany - je to zvláštní doba. My co pamatujeme jak se na řešilo jak dostat turbo pascal na jednu 360kb disketu a jak naprogramovat aplikaci, aby se i se systémem vešla do 640kb paměti, je z dnešního přístupu dost smutno.
-
Tohle je diskutabilní. Máte 90% projektů, které nevyrostou, a které budou obsluhovat pár desítek uživatelů. Pak máte ale projekty, které shodou okolností uživatelé začali používat a vyrostly - případně projekty, které mají šílený datový model a při malém počtu uživatelů jsou neskutečně pomalé. Samozřejmě, že obvykle je za tím práce s databází - bohužel v řadě případů výkonnostní problémy nepořešíte žádným dostupným hw a ani jednoduchým sw fixem - protože je to naprosto debilně navržené.
Takhle problémových projektů je minimum, ale jsou - a do jisté míry je to důsledkem toho, že jsou programátoři od technologie odizolováni, a jednak netuší, co dělají, druhak ani nemají šanci, kde se to naučit.
Osobně si nemyslím, že by databáze nebo dotazy nemohl navrhovat programátor - není to nic komplikovaného. Ale vyžaduje to určité základní znalosti a zkušenosti. A už i v lepších firmách jsem viděl takové blbosti, že nechápete.
Problém je, že ve chvíli, kdy zjistíte, že máte vážný problém s výkonem větší aplikace, tak s tím už prakticky nemůžete nic moc dělat. Banality typu chybějící index nepočítám. Je minimum prográmátorů, kteří vůbec dokáží identifikovat, že mají problém a ještě méně, kteří by dokázali zjistit, v čem ten problém mají.
-
Takhle problémových projektů je minimum, ale jsou - a do jisté míry je to důsledkem toho, že jsou programátoři od technologie odizolováni, a jednak netuší, co dělají, druhak ani nemají šanci, kde se to naučit.
Problémy vznikají ne na projektu jako jednotlivém, ale ve chvíli, kdy se X podobně "neproblematických" projektů provozuje na sdíleném hostingu. Tam pak dochází k výkyvům, kterým se dá předcházet jen kompromisem mezi předimenzováním výkonu a zpomalením ve špičkách.
Mimochodem, dost častý problém i u malých projektů jsou rozhraní pro správu. Na rozdíl od webového frontendu pro uživatele, kde se pracuje buďto s jednotlivými nebo naopak až s agregovanými údaji, v administraci se pracuje se všemi záznamy. Zákazník se pak nestačí divit, proč mu (skoro) nejede web, když někdo administruje, nebo když zrovna běží nějaký "chytře" napsaný cron job.
Obvykle ty problémy přijdou až po chvíli provozu, až když se zvětší datová nálož.
To odizolování programátorů od technologií je podle mě škoda, ale je to tak. Programátorovi se ještě jakž takž vysvětlí locky v databázi, ale opravdu už velmi obtížně se vysvětluje, co to je FPM pool, že není nevyčerpatelný, a proč je potřeba dbát na to, aby úloha trvala maximálně jednotky sekund (v nejhorším), nebo jinak že je potřeba ji oddělit do jiného poolu a trochu se zamyslet na DB operacemi.
Pokud se bavíme o PHP, není to samozřejmě stoprocentní pravidlo, ale celkové know-how, které se šíří internetem, i způsob, jakým jsou leadovány nejznámější frameworky, vedou právě do těchto pastí. Druhotná potíž je i v tom, že když už problém identifikujete a navrhnete řešení, tak mnohdy zjistíte, že by se celá aplikace musela překopat a spoustu frameworkové magie, na kterou se spoléhá, přepsat úplně jinak.
-
- - (neregistrovaný)
@Miroslav Šilhavý
Takže podle Vás třeba tvůrci Symfony nebo i samotného PHP či např. D. Grudl neví co dělají?
Viděl jsem spoustu zmatlanin i ve slavné Javě, lepení skryptů je časté táma i supr čupr ultimátním mega Pythonu. Dále si asi neuvědomujete, že programátoři ve většině případů ani nemají na výběr a "patlají" na termín, protože manažeři házeli hračkama na Zoomu dvě hodiny a rozhodli se, že to co bylo včera předěláno na kolo by nakonec přece jenom mělo do zítřka být soudek. -
@87vdf4vg82
Symfony i Nette vědí, co dělají. Jen to naráží ve chvíli, kdy ta aplikace začne pracovat s většími daty, nebo kdy je přístupů hodně. Tam to má pak strop, který se dá oddálit leda ohejbáky.
Dále si asi neuvědomujete, že programátoři ve většině případů ani nemají na výběr a "patlají" na termín, protože manažeři házeli hračkama na Zoomu dvě hodiny a rozhodli se, že to co bylo včera předěláno na kolo by nakonec přece jenom mělo do zítřka být soudek.
Myslím, že i to jsem zažil.
-
- - (neregistrovaný)
Ale mluvíte, jako byste to nezažil. Nikdo netvrdí, že je PHP nejlepší na všechno out of the box, ale v případě extrémních řešení mají i alternativy své limity a na řadu přichází spíš infrastrukturní řešení.
Symfony i Nette vědí, co dělají.
Aha, takže najednou tady máme developery kteří vědí co dělají, na rozdíl od Vašeho paušalizujícího moudra ....
-
Aha, takže najednou tady máme developery kteří vědí co dělají, na rozdíl od Vašeho paušalizujícího moudra ....
Ti co tyto frameworky používají, ti mnohdy nevědí, co dělají. Mockrát jsem viděl, že se z databáze vezmou nevyfiltrovaná data, fetchAll se všechna přenesou do PHP a tam se kouzlí ve smyčkách. A když se přijde na to, že data už jsou moc velká, dojde paměť a/nebo iterace trvají moc dlouho, najednou docvakne, že správný SQL dotaz by to vyřešil. Tady by stačila obyčejná erudice programátorů - a ta prostě velmi často chybí.
-
Stejný důvod, opačný problém: ti co zaslechli něco o SQL tak to najoinujou přes osm tabulek, pokud možno tak aby se pořádně ani nedaly přidat indexy, a celé to použijou pro UPDATE nebo DELETE. Výsledek: celá databáze locknutá než operace běžící minuty doběhne. Skvělé pokud to má zároveň odbavovat (relativně) standardním způsobem uživatele (požadavek na webserver -> několik sql dotazů i při zobrazení úvodní stránky (dashboardu).
-
Nazývať PHP "jazykom na tvorbu webov" je už dávno prekonaný a neaktuálny pohľad, podľa mňa.
PHP má "newebové" CLI SAPI už od verzie 4.3, vydanej v roku 2002 a najneskôr od verzie 7.0, vydanej v roku 2015, je úplne očividné, že sa vyvíja ako oveľa univerzálnejší programovací jazyk (používaný napríklad na tvorbu backendov rôznych druhov).
Myslím, že s výnimkou legacy systémov typu Wordpress v PHP už dnes málokto bude programovať webový frontend.
-
Pokud je to naprostý a očividný nesmysl, tak to ostatní poznají sami a netřeba to komentovat vůbec. Ale on to zas tak očividný nesmysl není. Je to jen subjektivní zhodnocení toho, kam se ten jazyk posouvá. Rozhodně mi to na rozdíl od vašich příspěvků něco řeklo.
Když nenapíšete, čím je podle vás vedle, tak nevím ani jestli nejste vedle spíš vy. -
Rozchádzame sa v terminológií. V mojom chápaní, ak niekto robí frontend použitím Twig-u, tak to nenazývam, že ho programuje v PHP, keďže Twig má vlastný jazyk (syntax, funkcie, cykly ...) a PHP kód sa pri tom spravidla moc nepíše. To, že samotný Twig je naprogramovaný v PHP, je nepodstatné.
Alebo inak - v dnešnej dobe, ak je niekto frontend developer, tak používa pravdepodobne predovšetkým Javascript a / alebo nejaký template engine s vlastnou syntaxou, ako je napríklad Twig. PHP ovládať takmer nemusí, to sa používa na backend funkcie.
Avšak v dobách minulých, keď bolo ešte PHP "jazykom na tvorbu webov", by bola jeho primárna voľba medzi PHP a ASP, prípadne JSP či SWF. Ale dnes je už doba niekde úplne inde a predpokladám, že programovacie štýly typu "vkladanie PHP kódu priamo do HTML" či "vypisovanie HTML priamo PHP kódom" budú už len naozaj okrajovou záležitosťou, pri nových projektoch.
-
no, tomu rozumim. Ale to same se prece tyka napriklad data. A toho se tato zmena pokud dobre ctu netyka. Takto se potvrzuje jen PHP schiza, kdy neco se chova tak a neco jinak. Pokud je to chtena zmena, cekal bych, ze obecne echo zacne kaslat na locales - ne jen pro integery.
Stejne tak pokud potrebuju machine-machine, tak se da argumentovat stejne. Si to zformatuju. Stejne machine-machine vetsinou nekomunikuji echem, ale mam nejaky format jako json/xml/protobuf/...Ale rikam, z PHP jsem pryc dlouho, tak jsem fakt pryc od problemu, ktere ho a jeho vyvojare trapi. Jen me to prekvapilo, tak jsem chtel znat nazor lidi, co jsou PHP bliz
-
- - (neregistrovaný)
V php AFAIK vždy když vypisujete Date/Time/DateTime nějak datum formátujete. Navíc formáty data a času až zas tak nesouvisí s locale a běžně se jich používá několik, např. "Y-m-d\TH:i:s" spolu s "d/M/Y" či "d M Y" atd. zatímco u desetiné čárky používáte striktně podle locale a tedy by to mělo být také předmětem formátování. Vidím to prostě jako Single Responsibility principle.
2. 12. 2020, 13:20 editováno autorem komentáře
-
tak teď to moc nechápu. To mi chcete říci, že datum posíláte z PHP např. ve formátu d/M/Y a číslo se pak ještě nějak formátuje, takže ho čech vidí jako "1,24" a američan "1.24". Nechce se mi věřit, že toto myslíte vážně...
Všechno souvisí se vším, přeci. Pokud má být web / app lokalizována, musíte správně zapisovat jak datumy, tak čísla. Texty se také lokalizují ne? Nebo máte na webu: "Dnes být středa, 12/2/20. Kredit je: 1.323 CZK"? Na druhou stranu je pravdou, že lidi často ani neumí zapsat správně česky datum a čas, takže se raději úchýlí z "poamericko-databávovým" formátům ;-(
-
- - (neregistrovaný)
V php přece pracujete s nějakými datetime strukturami, které musíte formátovat na správný formát minimálně při převodu do textové podoby, případně při definici. Číslo ne. Tedy teď už ano. Ale číslo není objekt aby mělo metodu jako např. DateTime::format() nebo date(format), tak se použije tuším je to format_number nebo něco takového.
Pointa je, že při práci s datatime formát dříve či později definujete. Při práci s čísly ne. Teď už ano. Toť můj názor.2. 12. 2020, 15:30 editováno autorem komentáře
-
nesouhlasím :-)
Jsou dvě možosti, tak jak to vidím já:
1) server side - komplet HTML se připraví přímo PHP a pak se jen vyplivne. To ale znamená, že čísla datumy MUSÍ využívat locales, resp. v HTML. Pokud s ním pracujete v PHP, rozhodně nemáte čísla ani datumy lokalizované. Data jsou třeba v UNIX timestampu nebo UTC nebo v tom co vám vyhovuje. Čísla jsou s tečkou.2) pokud PHP slouží třeba jako API, posíláte data, ať už datumy, čísla atd v nějakém výchozím formátu. Vlastní převod do locales provádíte až na klientu.
-
- - (neregistrovaný)
Těch možností je daleko více, můžete např. přelívat data z db do db s nějakým pomocným requestem na různá API ... a je to úplně jedno.
Podle mě jde o "Single responsibility principle". Struktura drží data, formátování výstupu provádí jiná, k tomu určená funkce. U DateTime atd. to tak je, u float to tak nebylo.
Jak to vidím já, tak výstup z takové "echo" by měl být vždy stejný, protože nejde o to, jestli se nějaký programátor zrovna rozhodl to použít pro wep app, ale mělo by to vracet string reprezntaci float tak, jak s ním pracuje php. S tečkou. A pak se taky ten string dá lehce přetypovat zpět, s čárkou už ne, musíte změtit čárku na tečku. Možná to dělají jako přípravu na další změny.2. 12. 2020, 20:14 editováno autorem komentáře
-
-> 87vdf4vg82
Mícháte dohromady 3 věci - vnitřní kódování data a čísel, jejich prezentaci a prostředek k jejich převodu z a do tisknutelné podoby:
Vnitřní kódování na nejnižší úrovni může být v nějakém vlastním binárním formátu nebo jako číslo (unixový čas, jak píše Hurvínek) nebo v nějak kódovaném řetězci (nejlépe ISO 8601), to samé pro čísla či další typy dat, ale vždy jednotně bez vlivu prostředí, v kterém SW pracuje či z jaké oblasti data zpracovává, tudíž je vyloženě nevhodné pro kódování řetězcem volit některý lokalizovaný formát.
Teprve v okamžiku, kdy data potřebuju zobrazit uživateli nebo naopak od něj přijmout, dochází ke konverzi, a je úplně jedno, zda jsou data uložena v primitivním typu, nebo objektu, podstata je pořád stejná.
Že to takhle v SW často není řešeno, je věcí jinou. -
- - (neregistrovaný)
@SB
Ne, ne, to do toho mícháte Vy. Na nějakém vnitřním kódování nezáleží, celé je to o tom, že funkce jako "echo" mají vypsat co je jim dáno a nestarat se o nějaké locale nebo kdoví co ještě. No, maximálně tak převést hodnoty primitivních datových typů, jako např. float, do textové podoby takové, jako je vždy daný jazyk schopen opět přečíst. Jaká to je, je celkem jedno. Jelikož php pužívá u float tečku, jeví se jako vhodné použít .... famfára ... tečku. Kdyby to byla čárka, tak asi čárku - minimálně to usnadní čtení výpisů errorů a taky to tak nějak dává smysl.
Formátování do locale a kdoví čeho dalšího má dělat nějaká úplně jiná funkce.
Jinak víceméně opisujete to, co tady bylo řečeno již několikrát - funkce pro výpis nemá nahrazovat funkci pro formátování. Co s tím má společného nějaké vnitřní kódování na nějaké vnitřní úrovni moc nechápu ...
-
Datum je taky jen číslo. Že může být obaleno objektem je implementační detail. Dokud hodnotu (ať už číslo, datum nebo cokoli jiného) neserializujete do textu, nemá žádný formát. Tedy ani číslo. Systémová locales právě proto umožňují měnit formát výpisu - čísla i datumu. Při deserializaci máte pak logicky problém, protože potřebujete znát formát, abyste hodnotu správně načetl. V PHP je to mimochodem ukázka diletantsví, není v tom ale samo, jinde není také situace zrovna růžová.
-
Tak bud byl kod davno optimalni, nebo naopak - pisu jako prase, ale u me tedy zadnej rozdil - pod PHP 7.3 i PHP8.0 cli bezi skript zhodne - 55 sec (15893 LoC). Mozna by to chtelo urcit kolik casu se ceka na DB, neco jako "time" utilita pro PHP-CLI neni? :-)
Po oprave na cca 20 mistech, nejcasteji {} na [], a jednoho (unset) pretypovani, je muj 400K radkovej debug vystup z obou behu nastesti identicky.
Objevil jsem ale dve historicke praseni ve svem kodu, ktery vznikli jaksi neumyselne (skript delal svoji praci dobre):
class::$static = FALSE; $var = class::$static['ID'] ;
- v php7 to bylo taky null/false, v php8 je warning na nemoznost indexovani boolu
A pak v PHP7 volani mysqli_query proslo s prazdnym $sql argumentem, v PHP8 uz takto prazdny dotaz neprojde a vyhodi exception.
-
Problém PHP je, že je to upadající technologie. Osobně bych v něm nedělal už jenom kvůli pracovním a platovým podmínkám v oboru, nezávisle na tom, jestli je to dobrý jazyk nebo ne, prostě se dá jinde snadněji vydělat více, často i dělat zajímavější věci, proto pro mě php ne.
Bavil jsem se o tom s jedním personalistou a říkal jsem, že v PHP se víc než 100k (a to ještě jestli) udělat nedá, zatímco lidi na IČO v Javě už dělají za 9.000 Kč / MD, s čímž souhlasil. Ale není to jen Java, ale třeba i Javascript je líp placený.
A pro mě prioritní otázka je, když už budu dobrý programátor, proč ten čas investovat do PHP, když to nikdo nezaplatí?
Čímž úplně beru stranou technologickou vyspělost a moderní architektury, které jsou dnes založené primárně na API, Serverless, GraphQL a cloudu a programování už dnes zdaleka není o nějakém ťukání kódu, ale spíše skládání lego skládačky z funkčních celků.
-
Upadajici je leda schopnost dnesnich lidi programovat.
Lepici kodu za 9K/MD maji u me stejnou povest, jako autorizovany servis ktery vam v ramci opravy vymeni cele zarizeni a nauctuje silenou cenu. Jiste, pro nekoho je takovy stav akceptovatelny, ale neni to zdrava situace.
Jsem zvedav kam jeste povede tato profesni degenerace.
-
9k/MD platí jen korporáty a je jedno pro jaký jazyk, klidně i pro to php. Tam to ale nemá nic společného s programováním, spíše lepením něčeho do časového limitu, ti dobří tam dlouho nevydrží, prostředí je dost depresivní.
Každopádně odmítat php, protože v něm víc než 100k nedostanu (podle personalistů) je také dost ujeté. I těch 100k je velice dobrý příjem.
-
Jirko, musíte vzít v úvahu i druhou stranu průměru, a to je průměrný zaměstnanec, který se našprtá učivo na škole, po vystudování se do konce života nevzdělává, a po práci to zapíchne v místní putyce, na vše má skvělý názor, nic nechce slyšet, a pokud do něj nepérujete, tak celý den v práci stráví na FB.
Lidi, kteří mají nějaký drive, schopnosti a pracují na sobě a posouvají se po pár letech praxe opravdu za 30k nepracují, ani v jiných oborech než IT.
-
Tohle je taková esoterika, tady nejde o to dělat co vás baví, i když to je samozřejmě bonus, ale to, po čem je poptávka, a ty prachy nemusíte mít zdaleka jen v Praze, a zdaleka ne jen v IT nebo manažerství, dobré peníze lze vydělat i v obchodu, marketingu nebo třeba klidně i stavebnictví i manuálních pracech, a že ty lidi znám.
A můj osobní názor je ten, že když vám něco sype a je potom poptávka a lidi vás potřebují, často vás to začne i bavit, a často věc, která by vás jinak bavila, ale nikdo o ní tolik nestojí, tak vás začne štvát.
-
toto z mého pohledu pravda jen částečně. Za mě, je hlavní problém v tom, že je plno lidí, jak já říkám garářistů, kteří udělají web za pár korun. Obecně je lidí se "znalosti" PHP. Ale je pravda, že sehnat místo, kde v PHP platí hodně, je docela potíž, ale není to nemožné. Osobní zkušenost před 2 lety - MD rate 7k.
Pokud jsi expert, tak člověk najde dobře placené místo i v PHP. Ale uznávám, že v jiných jazyku je to jednodušší.
-
PHP žije, představte si to, a dokonce se vyvíjí velmi slibným směrem. Chápu, že se na něj budou utrhovat lidi z Javy/Kotlinu a podobných sfér, proti nim je to jazyk dosti primitivní a velmi úzkoprofilový, ale nechápu, co si tu leští fanoušci Pythonu. Už dostali do svého jazyka zapouzdření a vůbec použitelný OOP, nebo je to pořád nastavovaný zprasek architektury z 90. let? :-)
-
Už dostali do svého jazyka zapouzdření
naštěstí ne a doufám že svuj geniální 'podtžítkovej' koncept nebudou měnit :D ;D
Zapouzdření je zlatý tele určitý skupiny ani ne tak programátorů jako ideologů a nepřináší žádej praktickej užitek, jenom metráky zbytečnýho zdrojáku navíc.
ruku nahoru kdo se někdy musel prohackovat nebo prodědit k nějaký pitomě použitý protected proměný v nějakým oop jazyku :D ;D
-
Ano, ale při nastupování si musíte vždy uvázat kravatu, protože pak při jízde vypadáte lépe. Jinak se auto ani nerozjede. Co na tom, že v některých (extrémních) případech kravata škrtí. (Copypaste kódu do jinak odindentovaného bloku.)
A krom toho zjistíte, že pokud nemáte poslední verzi, tak třeba světla svítí pouze minimálním předepsaným výkonem, a musíte si namontovat přídavný světlomet (použít IDE nebo linter) abyste něco viděl (překlep v atributu objektu při přiřazení)...
(K php se vyjadřovat nebudu, to mě v době 5.3 znechutilo nekonzistencí natolik, že ho od té doby nesleduju)
2. 12. 2020, 23:41 editováno autorem komentáře
-
Co to plácají za kraviny? Když už chtějí používat přirovnání, měli by se naučit správně vyjadřovat. Píchlé není to kolo, ale pouze obal z tvrzené gumopryže vynalezený jistým Dunlopem, který pro fungování kola není nezbytný. Pokud si nevšimli, tak o nahrazení této nedokonalé části se pokouší lidstvo již docela dlouho.
-
- - (neregistrovaný)
@SB
:-D
A co je to pak "skrytá vlastnost objektu"?
A co je pak "rozvalené"Jinak "prodědit" bude asi znamenat to, že se k nějakému stavu objektu uchovanému v nějaké proměnné nedostanete jinak, než děděním, protože autor udělal minimálně protected všechno, co zrovna on tehdy hned nepotřeboval a nyní se kvůli nějaké jedné debilní hodnotě musí podědit a přepsat několik tříd, jejihž ostatní funkce jsou potřeba, ale je v nich zapouzdřená nějaká jiná proměnná jiného objektu.
Typicky, používáte z nějakého balíčku např. třídu A, jejíž atribut je třída B, která má protected proměnnou "p".
Při použití potřebujete nastavit "p", jenomže je protected a tak musíte rozšířit třídu B do B', jenomže někdo geniálně napsal do konstruktoru A třídu B natvrdo, takže musíte podědit i A do A', do ní injektovat B' připadně interface B', přepsat několik metod a dále používat třídu A'.
Tedy musíte vytvořit A', B' abyste se dostal k p, přestože např. uchovává jenom nějakou blbost, kterou vlastně ani není potřeba zapouzdřovat, jenom je to "best practice" z internetu. Super. Výraz prodědit je k tomu řekl bych ideální3. 12. 2020, 14:18 editováno autorem komentáře
-
- - (neregistrovaný)
To víme. To je jasné. Jenom mi připadlo zvláštní, že se pohoršujete nad "prodědit" a pak máváte nějakým "skrytým" ... ;-)
Ano, je to špatná závislost uvnitř knihovny. Ne, není často zas tak na výběr a zas takový průser to nakonec nebyl, jenom trocha práce navíc a pár sprostých slov jako ocenění tvrdé práce autora. Daleko víc mě rozesmutněla medoda na asi 800 řádcích. No co už, nedivím se mu, refaktoring té prasečiny reálně ... nereálný.
Tady nebylo chybějící zapouzdření, ale spíš přepouzdření. Resp. pokud má třída nějakou vlastnost, není špatné se zamyslet nad tím, jestli by neměla být přístupná pro nastavení.
-
To jsou tedy silná slova.
1. Python má "private" atributy. Dá se k nim dostat "oklikou", ale nikdo to nedělá a pokud to udělá, pozná se to (pylint atd.). V praxi není problém.
2. Python má "protected" atributy. Dá se k nim dostat přímo, ale pylint automaticky varuje.
Kde je jaký problém V PRAXI? Neřeším svaté knihy OOP, to mě nezajímá. Python má spíš problémy ve slabém typovém systému a přespřílišné dynamičnosti, ale to je nešvar běžný v OOP.
-
Zabývat se OOP už my přijde jako dávná minulost. Připomnělo mi to tabulky z této stránky https://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html a vojáky z první světové :D . Tím zpraskem z 90tek myslíte OOP :D?
IMO jako Java/Kotlin vývojář, je moje zkušenost, že OOP je nejlepší co nejvíce minimalizovat. Příjde mi, že v Jave je/byl dost OOP fašismus a dnes to míří více k používání dynamických struktůr (pole, mapy), které jsem dřive pythonu záviděl. Dneska lze už vše napsat IMO lépe, čitelněji v Kotlinu. Ale to je věc tak posledních 4 let max. -
Pardon nepřesně jsem se vyjádřil. Reagoval jsem na příspěvek a chtěl jsem říct, že pošťuchovat jiný jazyk za OOP mi přijde jako minulost.
OOP pužívám. Určitě požívat všude funkce smysl nedává. Jde o to že nepotřebujete x pravidel, principů, návrhových vzorů atd. Jinak řečeno je to jednoduší, méně problematické, méně prostoru pro chyby.
Místo toho abyste udělal balíky funkcí se stavem / bez stavu, tím myslím objekty, tak začnete rovnou se vším rozkouskovaným a poskládáte to dohromady. Složitost měnění/rozkládání objektů oproti funkcím je se složitostí úplně někde jinde. -
Ten odkazovaný článek obsahuje tolik nepřesností až demagogií, že nemá smysl brát vážně jej ani jeho závěry (pravda, nedočetl jsem to do konce, nemělo to smysl).
OOP vůbec nemusí být minulostí, jestliže se nestalo ani přitomností. Zrovna Java není dobrým jazykem pro pochopení a využití možností OOP, pravděpodobně jste jedním z mnoha, kteří si to myslejí.
Váš jazykový projev je zoufalý.
-
- Obchodní konzultant/ka pro prodej služeb T-Mobile K. Vary
- TECHNIK (JUNIOR/SENIOR) VÝSTAVBY INTERNETOVÉ SÍTĚ
- Senior/Medior Java Developer
- JAVA DEVELOPER HPP i IČO
- IT Service Manager (m/ž)
- Vedoucí týmu Corona pro 3ds Max (C++)
-
- Mentoring: Nechte si poradit a odbrzděte kariéru
- Jak efektivně vyhledávat pomocí Google
- Anglické idiomy II
- Jak se efektivně učit online
- Zkušenosti generála tajné služby: Leadership
- Autenticita jako cesta k úspěchu s Adelou Vinczeovou
-
- Obchodní konzultant/ka pro prodej služeb T-Mobile K. Vary
- TECHNIK (JUNIOR/SENIOR) VÝSTAVBY INTERNETOVÉ SÍTĚ
- Data specialist | Znáte Python a SQL?
- OBCHODNÍK PRO CLOUDOVÉ SLUŽBY (hybrid)
- JAVA DEVELOPER HPP i IČO
- Vedoucí týmu Corona pro 3ds Max (C++)
-
- Peníze pod kontrolou: průvodce osobními financemi pro každého
- Vyjednávání I: Přemýšlejte a jednejte jako vyjednavač
- Jak efektivně vyhledávat pomocí Google
- Jak se efektivně učit online
- Zkušenosti generála tajné služby: Leadership
- Autenticita jako cesta k úspěchu s Adelou Vinczeovou
