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.
Když se tabulka jmenuje sallary, nazvěte klíč sallary_id. Když je tabulka company, nazvěte klíč company_id. Jinak se v tom ztratíte velice lehce. Ať se stejná hodnota v databázi jmenuje stejně ať je to primární nebo cizí klíč nebo cokoliv jiného. Berte to jako "must do"
Tohle především nemají řešit lidi, ale stroje a nástroje (eslint, checkstyle,...) - ideálně nastavené napříč organizací. Jejich (opodstatněné) porušení pak řešit anotací/při code review.
Počet znaků je pak přímo úměrný velikosti monitorů které vyfasujete
Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)
Trochu si rypnu. Ten if (device.Type == "android") je stoprocentne pouze na jednom miste v programu :-)
To jsem si vymyslel za chodu, to neni z zadneho programu. Normalne by byl android nejaky enum, ale pro citelnost teto kratke ukazky jsem tam nechal "android" aby jakoze bylo jasne, co se oproti cemu kontroluje.
if (device.IsAndroid) ...tento přístup jde zrovna pro záznamy typu logy, kde člověka zpravidla zajímá blízká budoucnost, dobře a funkčně implementovat s filtrováním jen na klientovi. A to máš s dobrým widgetem v podstatě zadarmo, popř. musíš napsat jeden malej JS helper apod. Takže Ti to naopak často práci ušetříVidím, že načíst si celou tabulku do paměti a pak záznamy filtrovat a řadit na serveru v PHP, už není v módě. Teď se celá ta tabulka rovnou přestěhuje až na klienta.
i když je dat tolik a usecase je takové, že je potřeba součinnost filtrování na klientu a serveru, tak ta námitka je úplně mimo, protože doplnit do serverového api filtrování je práce tak asi na čtvrt hodiny. Takže za malej kus práce získáš svižnější aplikaci (nemusí si v mnoha případech říkat serveru o data)Ony existují i aplikace, které zpracovávají větší objem dat, než je nějaký blogísek. Filtrovací logika může být dost komplikovaná, např. se do SQL dotazu připojují další tabulky, které tam nejsou, když příslušný filtr není použit. Když to budete chtít řešit na klientovi, nebudete k němu po síti stěhovat jen celou tabulku, ale rovnou celou databázi.
(samozřejmě, tento přístup přestane bejt vhodnej v okmažiku, kdy bude tad tolik, že budou k rozumné práci potřeba indexy).
která ovše s Tebou původně navrhovanou technologií, kterou jsme kritizovali:Řeč byla o tom, zda se rychleji zobrazí HTML → nativní HTML parser → DOM, nebo JSON → nativní JSON parser → JavaScript → DOM. Na tomto příkladu je to dobře vidět, protože ta komplikace se SSG a SSR se dělá právě proto, že první cesta je pro zobrazení výrazně rychlejší. No a princip je úplně stejný, jako s tím mým příkladem – z hlediska rychlosti je prohlížeči jedno, zda parsuje celé HTML, nebo jen HTML fragment.CitaceTak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky....nemá společného vůbec nic.
Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML.Jo, ty špičaté závorky se v tom procesoru zasekávají, složené projdou mnohem líp… Na tohle se fakt nedá nic jiného napsat…
Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.Nějak mi uniká, co jste touhle větou chtěl říct.
Pokud se html generuje na klientovi a interakce s ui je také řešena na klientovi, ušetří se výpočetní výkon serveru který je pak k dispozici pro obsluhu dalších požadavků. Část výpočetního výkonu se tedy distribuuje mezi klienty. Data se ze serveru přenáší typicky pomocí JSON. Co k tomu víc dodat?Ten JSON se podle vás vezme kde? Nebo myslíte, že když bude server generovat {"jmeno": "Jiří Novák"} místo <td>Jiří Novák</td>, ušetří se tím nějak výrazně jeho výkon?
xmlstarlet ed -s "/main/groups/group[name='group2']/members" -t elem -n user -v newUser <data.xmlMoje preferovana varianta pro strojovou operaci "SET" je:Vychazim totiz z predpokladu, ze soubor nemusi obsahovat dany parametr, nebo ho muze obsahovat jinak napsanej. A pak se hodi videt historii zmen / customizaci nastave na konci souboru na jednom miste, nez abych musel delat diff vuci distribucnimu default configu.
- smazat vsechny radky obsahujici case insensitive verzi: ^\s*KeyWord\s.*
- append na konec, KeyWord NewValue
Něco na tom bude, protože původní parametr nejraději zakomentuji a hned pod něj uvedu s novou hodnotou.
Jsou ještě dva přístupy k tomuto problém:
- generovat konfigurační soubory ze šablon
- dělat změny ručně + verzovat ve verzovacím systému + aplikovat patche
Verze 2 je IMHO nejpokročilejší, drží i historii a je decentralizovaná. Existují na to i hotové systémy (nemám zkušenost).
Moje preferovana varianta pro strojovou operaci "SET" je:Vychazim totiz z predpokladu, ze soubor nemusi obsahovat dany parametr, nebo ho muze obsahovat jinak napsanej. A pak se hodi videt historii zmen / customizaci nastave na konci souboru na jednom miste, nez abych musel delat diff vuci distribucnimu default configu.
- smazat vsechny radky obsahujici case insensitive verzi: ^\s*KeyWord\s.*
- append na konec, KeyWord NewValue
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.