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.


Příspěvky - L..

Stran: [1] 2 3 ... 15
1
Vývoj / Re:Zadávání údajů ve formuláři dnes a před lety
« kdy: 08. 04. 2022, 22:56:38 »
policko par milimetru
Ergonomie take znamena, ze se usetri misto a uzivatel ma na jeden pohled mhohem vice informaci.

Ne nutně, občas je to méně přehledné. A ne vždy je těch údajů tolik, aby se místem šetřit muselo. Prostě pokud to dává smysl, tak se použije malé políčko, ale ne vždy to smysl dává.

data na straně serveru kontrolovat musíte ... Na tom neco je. Drive (pred webem) se to vetsinou nedelalo a ty aplikace taky desetileti fungovaly.

Ano, na bezpečnost se dřív hodně kašlalo. Pak z toho byly telefonáty typu "A opravdu se váš syn jmenuje Pepa'; drop table users;?" :-D

Dnes se rika, ze si uzivatel otevre pres F12 vyvojove prostredi webu a muze udaje manipulovat i pote, co je client zkontroloval ... no ja nevim, kdyz se to udela pres webassembly, tak bych takoveho uzivatele chtel videt.

Útočník si hlavně může request komplet celý vytvořit a poslat sám, nic měnit nemusí.

Ja jsem myslel, ze cifry jsou v kazdem fontu vsechny stejne velke ...?

Jak se říká: "Myslet znamená houby vědět"

pro zaškolené uživatele co je používali velmi často.
ano, prave na takove aplikace myslim. Klasicke 'rich-client' aplikace

Pak ovšem nevím, proč řešíte běžné webové aplikace, které jsou určeny pro úplně jiné podmínky a podle toho vypadají. I webové aplikace pro zaškolené uživatele se dělají, ale k těm se samozřejmě běžně nedostanete, protože jsou interní.

na jo, to je pravda, jestlize se ma aplikace pouzivat soucasne na mobilu a na 50" obrazovce tak to chapu, ze se musi udelat nekde nejaky kompromis. A ten vede k tomu, ze efektivita prace musi byt nutne suboptimalni. Me skutecne prekvapuje, ze to jeste nikoho nenapadlo a hlavne ze zakaznici neprotestujou.

A proč by měli protestovat? Jistě by bylo možné optimalizovat aplikaci pro různá zařízení od mobilu po tu 50" obrazovku, ale vývoj by byl o dost nákladnější a to se jim prostě nevyplatí. Maximálně se občas dělá mobilní verze nebo webová a mobilní aplikace, kde je to fakt užitečné.

Nekdy kolem roku 1988 jsem pro nemeckeho zakaznika predelavali stavajici aplikaci, ktera byla novell-dosovska na unix a u prejimky ten sef posadil k terminalu po rade zamestnance z nakupu a odbytu a nechal je editovat ty zakazky a objednavky a meril stopkama kolik potrebujou casu.

To je další věc. V 80. letech se běžně zaměstnávaly armády makaků, kteří nedělali celý den nic jiného, než přepisovali věci z papíru do počítače. Tam byla samozřejmě efektivita zadávání naprosto kritická. Nicméně dneska se to už dělá jen výjimečně, buď se komunikuje elektronicky, nebo to nahradilo OCR.

Zadal jsem tedy '//////////////2345234523423////////456345634//////' a kdybych chtel, tak zadavam jeste ted, ale presto vsechno se mi nezda, ze to co zadavam vypada jako nejake smysluplne datum.

A proč byste něco takového zadával do datumu? Když by to byla aplikace, tak by vám po opuštění pole vynadala, že to není platné datum, takže cajk. Optimalizovat aplikaci, aby se při takovém nesmyslném vstupu chovala "co nejlépe" je zbytečná práce.

Mimochodem, právě dělám na jedné interní aplikaci, kde je rychlost zadání v nějakých UC kritická. Takže řešíme věci jako "A když sem kliknu se shiftem, tak bude ve zobrazeném dialogu aktivní druhé políčko a ne první, abych ho mohl rovnou přepsat a ušetřil stisknutí tabu." Ale vstupy čísel jsou normální inputy, do kterých mohou napsat cokoli, žádné filtrování, zarovnávání na desetinou tečku a podobné nesmysly, dokonce ani nejsou zarovnané doprava a uživatelé jsou s tím úplně v pohodě. Kdybych jim vysvětloval, že to tak podle nějaké socialistické normy musí být, asi by koukali, jestli jsem nespadl z Měsíce :D


2
Zadavani se drive resilo tak, ze caret se pri vstupu do policka posadil na desetinou tecku a zacala se zadavat ta celociselna cast toho udaje. Pritom se caret nepohyboval a jednotlive cifry se v policku objevovaly zprava jak na kalkulacce.  Pote uzivatel zmacknul znak desetinne tecky a caret se presunul do prvniho desettineho místa za tou teckou a uzivatel zadal nyni to nejvyssi  desettine misto. Od desetinne tecky se to editovalo tedy jako text. Samozrejme, ze byly blokovany ty sipky a jine 'zle' znaky.

Vždycky, když něco takového potkám, tak mám chuť autorům provést něco strašného. Třeba pomazat medem a přivázat do mraveniště. Nebo jim zlámat obě ruce nadesetkrát, aby už nikdy nenapsali ani řádek kódu. Nebo ještě něco děsivějšího - donutit je ten jejich neergonomický paskvil denně používat.

3
Vývoj / Re:Zadávání údajů ve formuláři dnes a před lety
« kdy: 08. 04. 2022, 09:55:46 »
Toto sa da vyriesit tak, ze na pozadi js odosle request na server, ktory vykona validaciu - presne tu istu, ktoru robi aj on a posle odpoved. Cize ziadna nekonzistentnost, validuje to jedna a ta ista funkcia.

Nechtěl jsem ze svého příspěvku dělat román výčtem úplně všech možností, ale asi budu muset :-)

Tohle se samozřejmě udělat dá. Ale má to několik nevýhod:

- Je to pracné
- Validace probíhá až se zpožděním, tedy se člověk musí tak jako tak do pole vracet
- Zatěžuje to server (občas to nevadí, občas ano)

Takže se to obecně moc nepoužívá, respektive se to používá jen na validaci nějakých specifických polí, třeba při registraci se takhle asynchronně kontroluje, zda není uživatelské jméno obsazené.

Nie, pises normalne, ale v inpute je to zarovnane doprava.

Aha, to bylo napsané tedy dost zvláštně. No, to je většinou proto, že pokud jsou ve formuláři pod sebou různě řetězce a čísla, tak vypadá blbě, když je každé zarovnané jinak. A na zadávání čísla zarovnaného doleva není nic extra neergonomického. Smysl je zarovnávat doprava má tehdy, pokud se zadává víc delších čísel pod sebou.

4
Vývoj / Re:Zadávání údajů ve formuláři dnes a před lety
« kdy: 08. 04. 2022, 09:13:07 »
- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů

Pár milimetrů? To není ani jeden znak. Co zadáváte v tak malém poli? Jinak ano, políčka jsou občas o dost širší, než by bylo potřeba, což je většinou proto, aby formulář nějak rozumně vypadal. Ony "schody" přesně podle potřebných délek ztěžují orientaci ve formuláři a jsou tak neergonomické.

- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to  koriguje

To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí. Občas se vyskytují knihovny, které se snaží nějak řešit, že by server dokázal předávat metadata na klienta, ale nevím o ničem obecně použitelném. Takže typicky se kontroluje povinnost, občas typ (číslo / řetězec) nebo pattern, ale složitější kontroly většinou probíhají až na serveru. Také některé věci mohou vyžadovat kontrolu v DB atp., což je další komplikace.

Pokud máte na mysli tzv. maskované inputy, tak ty byly populární v devadesátkách, ale pak se od nich upustilo. Já jsem jejich hodnotu moc neviděl ani jako uživatel. Plus musíte řešit, co když do nic uživatel zkusí něco pastnout, atp.

- čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš

Jako že by se měly zadávat nejdřív jednotky, pak desítky, pak stovky... Proboha, kdo takovou šílenost vymyslel?

- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky

Tohle vyžaduje mít neproporcionální font, jinak to stejně vypadá blbě. Plus je to hodně crcání za malý efekt, input ve webovém prohlížeči by člověk musel dost znásilňovat.

... s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře.

Jako že v roce 1982? Za socíku? No, když by i vyrazili, tak pak by neměli nic, protože konkurence jaksi neexistovala :-D

Pokud jste fakt tehdy nějaké aplikace dělal, tak to byly aplikace na lokálním počítači (ne-webovém), na obrazovce o přesně daných rozměrech s neproporcionálním písmem a pro zaškolené uživatele co je používali velmi často. Dnešní webové aplikace jsou pro dost jiné podmínky.

- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)

Část je zodpovězena výše. Nějakou rozšířenou JS knihovny vyloženě na vstup dat asi nevím. Co píšu jsou React aplikace, které mají knihovnu obstarávající business logiku formulářů (final-form, formik) a UI knihovnu (Material UI, bootstrap, ...) nad kterými jsou vlastní knihovny. To je interaktivní dost :-)

5
Za mě jsou smysluplné otázky jednoznačné plus, u kandidáta na seniora je dokonce očekávám.

Přesně tak. Dobré otázky znamenají, že ten člověk má nějaký rozhled, zkušenosti a není to jen tupý bušič kódu.

Můj oblíbený citát: "Není až tak těžké dávat správné odpovědi, těžší je dávat správné otázky".

6
testovaci ukol znel jasne, reverznout soubor.

Takovýchhle jasných zadání jsem už v praxi viděl tuny. A většinou čím víc zadavatel tvrdí, že je to jasné, tím spíš po nějakém zvídavém dotazu (mám heslo, že když mi něco není jasné, tak se zeptám) dostanu odpověď: "No, vlastně, ehm, počkat, to by ...".

7
je otazka co bych si o tom cloveku myslel, ze je od neho pekne, ze se dokaze zeptat na doplnujici informace,
nebo naopak, ze je natvrdly a potrebuje k tomu dalsi omacku.

To záleží. Pokud se ptá na věci jako "A jak načtu soubor?", tak je to samozřejmě špatně. Zdeněk Tomeš tu dal pěkné příklady smysluplných otázek.

Za mě jsou smysluplné otázky jednoznačné plus, u kandidáta na seniora je dokonce očekávám. Nejhorší jsou lidi, co tři dny kódí podle zadání a pak se zjistí, že ten jejich kód je na vyhození, protože to zadání pochopili blbě (bylo jim něco divného, ale nezeptali se). Nebo naopak stráví den nad něčím, co by se dalo napsat za hodinu, protože oni dělají obecné řešení, zatímco my to potřebujeme pro nějakou podmnožinu případů.

8
Ale stále zůstává nezodpovězena otázka, jak ty architektonické dovednosti ověřit v rámci 1-2 hodin.

To je právě pointa moje a dalších tady: nijak. Nejde to. Někteří si nalhávají že jakoukoliv směrodatnou indicii o kandidátově vhodnosti vydestilují z toho, jak rychle nebo elegantně napíše na papír ...

Jenže ono nejde o to "jak rychle / elegantně napíše", ale o ten proces, jak k tomu dospěje. Bylo to tu popsáno už hodněkrát, třeba hned ob příspěvek níže:

Algoritmicke otazky su o tom, ze uvidim, ako clovek uvazuje.

Ale schopnost porozumění psanému textu se u některých lidí evidentně limitně blíží nule.

Žádným pohovorem nezajistíte stoprocentně, že uchazeč bude vhodný, ani referencí. Vždycky je to nějaké přiblížení.


9
Čas za jaký kandidát uběhne 100m sprint se taky ojebat nedá a přesto se shodneme že to je u softwarového inženýra irelevantní metrika :-)

Ono při sprintu hraje nějakou roli logické uvažování?

A přitom to jak přistupuje vývojář k architektuře software a jak pracuje se systémovými frameworky je pro jeho práci daleko podstatnější než jak z hlavy dovedně řeší školní úlohy.

Ale stále zůstává nezodpovězena otázka, jak ty architektonické dovednosti ověřit v rámci 1-2 hodin.

10
A jak by sis představoval "zajímání se o soft skills"? Že se tě zeptají "Umíte se domluvit se zadavatelem, pokud vám je něco nejasné?"? Soft skills se testují špatně a pokud, tak nepřímo z tvých reakcí během pohovoru, například na ty "nesmyslné HR otázky", proti kterým se tu často brojí.

U architektury je o to tom, že nějaké komplexnější architektonické rozhodování vyžaduje poměrně dost kontextu a ten je těžké v omezeném čase pohovoru předat a hlavně pro kandidáta vstřebat. Takže se testuje spíš jak člověk myslí. A jednou z možností je právě to "obsesivní řešení algoritmů". Ve skutečnosti vůbec nezáleží na tom, jestli řešení znáš nebo neznáš z hlavy (dokonce je spíš lepší, když neznáš), nebo zda ho nakonec najdeš, ale jak při jeho hledání postupuješ.

Stesky na "HR wall" občas slýchám i v IT, shodou nešťastných okolností jsem za uplynulé 2.5 roku třikrát měnil práci, takže mám dost docela dost čerstvých zkušeností, ale ani v jednom případě jsem na něco takového nenarazil, (snad až na jeden případ?) jsem na pohovoru mluvil rovnou s případným budoucím nadřízeným nebo kolegy.

11
/dev/null / Re:Pravnické důsledky cenzury na českém webu
« kdy: 15. 03. 2022, 07:17:27 »
"Trikolora." To mi stačí.

12
Windows a jiné systémy / Re:Kontrola práce na home office
« kdy: 01. 03. 2022, 13:19:47 »
Pokud dovedu to, co ty řešíš celý den za hodinu, není důvod, proč bych potom nemohl hrát celý den hry. Co je za metriku, že má někdo celý den pracovat?

No, pokud se s někým domluvíš, že budeš "celý den" (*) pracovat a neděláš to, tak porušuješ dohodu.

*) Předpokládám, že to původně bylo myšleno "celých osm hodin" a samozřejmě datlit osm hodin v kuse se stejně nedá, ale snad si rozumíme.

13
Windows a jiné systémy / Re:Kontrola práce na home office
« kdy: 28. 02. 2022, 20:03:02 »
Pokud řeším problém, tak nedatluju, ale čumím do zdi.

Tady se bavíme o programování, ne o vypalování díry do zdi pohledem :D

Čumět do zdi můžu i v kanlu.

Jenže to drtivou většinu lidí velmi rychle omezí. Zato doma si mohou zařizovat spoustu soukromých věcí.

A. Neřešit záseky, protože je stejně zákazník nezaplatí. B. zaplatit chytřejší lidi.

Jako že je teda danému člověku nezaplatíš? No, to asi nebude moc populární řešení. A i chytrý člověk má občas prostě zásek.

Pracnost bez záseků je úměrná velikosti zdrojových textů.

No, úplně není. Když třeba přejmenuju nějakou používanou propertu, tak to v IDE mám za pět sekund a vygeneruji klidně desítky řádků změn.

Dám jeden příklad z praxe: Jistý můj kolega měl za úkol udělat featuru do jednoho produktu. Ten produkt jsme převzali poměrně krátce předtím, takže nikdo neměl přesnou představu, kolik to tak zabere. On stále reportoval, že na tom dělá, že už to skoro má ... a jéje, zjistil jsem, že ten přístup nakonec nepůjde, budu to musel udělat trochu jinak ... jo, dobrý, už to skoro mám ... a jéje, zas to úplně nefungovalo, no tak ještě jinak ... Tak nás tahal za nos asi dva týdny, až byla situace opravdu kritická, tak jsem se na to mrknul sám. Za dvě hodiny jsem to měl hotové.

I po tom tvrdil, že na tom fakt dělal a že měl prostě smůlu, že žádné jeho řešení nefungovalo. Samozřejmě jsme si byli skoro jistí, že se flákal, ale důkaz samozřejmě nebyl. Na hodinu vyhozený nebyl, další měsíc mu končil kontrakt, takže mu nebyl prodloužen, jen s námi ještě ten měsíc něco dělal. To už trochu dodával, ale vždycky až večer. Podle mě měl prostě druhé zaměstnání. Kdyby byl v kanceláři, tak by mu to neprošlo, ale vzdáleně na homeoffice to dělat klidně mohl a nebyla šance, jak mu to dokázat.

14
Windows a jiné systémy / Re:Kontrola práce na home office
« kdy: 28. 02. 2022, 15:57:25 »
Nie je podstatnejsie to, ze ta praca je hotova v termine a kvalite podla zadania?

Tohle funguje tak někde v pásové výrobě, která se dá jasně normovat. U SW těžko budeš vědět, jestli ten problém řešil dva dny, jak tvrdí, nebo to měl za dvě hodiny hotové a zbytek doby pařil hry. Samozřejmě je možné každý problém sám prozkoumat, odhadnout jeho časovou náročnost a pak sledovat, jak se s tím dotyčný popasuje, ale to už si to pomalu můžeš udělat sám.

(Disclaimer: Tím neříkám, že sledování zaměstnance je dobrá volba, jen že "práce hotová kvalitně a včas" může být v SW poněkud problematická metrika.)

15
/dev/null / Re:Přepísknutý marketing ?
« kdy: 23. 02. 2022, 10:30:46 »
Že ty sis dneska zapomněl nasadit alobalovou čepičku? Sháněl jsem tiskárnu před Vánoci a situace byla podobná - levnější modely zhusta vyprodané. Našel jsem takovou, jaká mi vyhovovala (měl jsem dost specifické požadavky), ale než jsem se rozhoupal, byla vyprodaná taky. Tak jsem si na ní dal hlídání dostupnosti. Za pár dní mi v jedenáct večer přišel mail, že je na skladě. Rychle jsem ji objednal a když jsem se koukal za půl hodiny, už zase byla vyprodaná.

Žádný marketingový trik, prostě nejsou. Kdyby to byl trik, tak je prostě koupíš u konkurence.

Stran: [1] 2 3 ... 15