Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ale zrovna v tom vašem případě by se stejného výsledku dalo dosáhnout i bez odečítání jedničky, stačilo by místo operátoru menší nebo rovno použít ostře menší:
words = ["dog","cat","hint"]
for word in words:
print(word + "!")
tak predpripravit pool vlaken a kdyz prijde pozadavek, tak vlakno z poolu vyuzit at udela ten pozadavek.
koukl bych do nginxu.
A co se vam jako nelibi na tom novejsim Qt GUI frameworku? Nemam ted namysli ten starsi co vypada jak Winforms, ale ten novejsi kde se vsechno modeluje ze ctvercu - co vam jako na tom nevhyvouje, to nechapu.
Jinak pokud ten UI bude bezet na stejne masine nebo siti jako backend, tak jednoznacne doporucuju pouzit Server-side rendering + a na dynamicky obsah JQuery. Co ma v repertoaru C++ na server side render nevim. Eventualne kdyby server side v C++ stal za pikacu, tak muzete pouzit Mustache - to v principu funguje velice podobne jako server side rendering, akorat se to odehrava na frontendu a na backendu vam staci mit k tomu rest. Vyhoda oproti React.js je, ze je to mnohem jednodussi. A kdyz tak nad tim premyslim, tak Mustache bude i pro C++, takze uz vite co muzete pouzit i na ten server side.
Moderni PHP pri zapnutem strictu a typehintama a Laravelem je uz rozumne pouzitelna zalezitost.
Je to defacto opajcovany Spring boot, maven se jmenuje composer. Templatovane pres blade a bootstrap
Delal jsem ted v tom nejake udelatka, jazyk byl dan zadavatelem.
A slo to celkem s vyuzitim VS Code rozumne pouzivat, rozhodne lip, nez treba Go.
Tohle by nepomohlo?
https://wordpress.stackexchange.com/questions/296836/stop-admin-ajax
Já na to kdysi viděl plugin ale teď ho nějak nemohu dohledat ...
Jinde než na sdíleném hostingu není důvod PHP používat.
PHP je moderním programovacím jazykem, používám ho i na VPS. Jeho filozofie mi vyhovuje, mohu kombinovat paradigmata jak potřebuji.
naopak nechápu striktní dělení na frontendisty a backendisty. Nejlepší backend vzniká organicky podle potřeb frontendu, když se backendista nepodílí na vývoji frontendu, nedopadá to dobře.
Tohle možná platí u nějakých hodně malých / amatérsky vedených projektů. U normálních projektů se rozhraní dělá na základě analýzy (která ty potřeby zohledňuje) a tedy není nutné, aby se backendista (přímo) podílel na vývoji frontendu. Naopak, vzhledem k rozdílu v technologiích a často i v programovacím jazyku je většinou to dost neoptimální.
návrh rozhraní podle analýzy jde proti agile metodice. Efektivnější je vyvýjet organicky podle požadavků frontendu, tam je nárůst režie, pokud jsou role backendistů a frontendistů striktně oddělené.
naopak nechápu striktní dělení na frontendisty a backendisty. Nejlepší backend vzniká organicky podle potřeb frontendu, když se backendista nepodílí na vývoji frontendu, nedopadá to dobře.
Tohle možná platí u nějakých hodně malých / amatérsky vedených projektů. U normálních projektů se rozhraní dělá na základě analýzy (která ty potřeby zohledňuje) a tedy není nutné, aby se backendista (přímo) podílel na vývoji frontendu. Naopak, vzhledem k rozdílu v technologiích a často i v programovacím jazyku je většinou to dost neoptimální.
Asi jsem lopata, ale ta frontend "moderna" v JS kde patla na jedno misto javascript, html i css to je humáč, k tomu kazda moderni vec je za tyden zastarala.
Pokud chcete dělat WebGL simulaci/animaci/hru, pak React ani Vue s ničím nepomůžou (pokud to není komplexní aplikace, kde canvas je jen jedna z komponent) jak píšete. Komunikaci si nějak uděláte přes websokety a UI si udělejte přímo v Canvasu přes něco jako imgui.
Nemusí to být ani v js, je možné transpilovat třeba z typescriptu a tím se špagetám vyhnout. Jak je na tom webassembly nevím.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2025 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.