Příspěvky

1

Vývoj / Re:Jaký jazyk bych se měl učit?

« kdy: 02. 11. 2022, 11:17:23 »

SQL je naopak skvělá volba. Snadný jazyk, který se naučí za rozumný čas. Vysokoúrovňový jazyk. Užitečný jazyk. A dokonce i ta aritmetika a funkce tam jsou. Já jej doporučuji jako první ideální volbu.

SQL je deklarativni jazyk a ma tedy tu nevyhodu, ze neni instruktivni.

2

Vývoj / Re:TIME_WAIT po ukončení socket-komunikace

« kdy: 09. 08. 2022, 21:29:14 »

Obvykle je to kvůli chybějícímu shutdown() .  Samotný close() nestačí, bo ten vzniká i automaticky se zánikem procesu a není jasné, jestli ještě něco odněkud nepřijde.

diky za obe odpovedi. To s tim shutdownem jsem u klienta uz zkusil, to zatim nic neprineslo. Ale jak jsem pochopil predrecnika, tak uplne silena situace to neni, takze jsem se uklidnil a zatim to necham bezet.

3

Hardware / Re:UPS - kotel + oběhové čerpadlo

« kdy: 09. 08. 2022, 21:25:37 »

Např. toto a k tomu baterie tak velká jak je potřeba.

https://www.discomp.cz/zalozni-zdroj-ups-adler-400w-230v-12v_d87870.html

Např. jeden "wifi" bod mě na to nedávno jel cca 7,5 hodiny při nahlášeném výpadku od ČEZu. Bohužel to bylo stejně o cca 40 minut bylo méně než bylo potřeba, takže jedna ze dvou baterií 45Ah bude vyměněna za větší. V každém případě utáhne to opravdu hodiny provozu. Máme třeba body kde k tomu je připojeno 2x 100Ah.

jo, to je alternativa. Kdyz se vezme 12 V / 125 Ah baterie, tak to dava  1500 Wh - t.zn, ze tech 150 W to muze teoreticky dodavat 10 hodin - ale vlastne jen 4-5, protoze pak je nebezpeci, ze i ta gelova baterka zdegeneruje. Takze skutecne ty 2 baterky na tech max. 10 hodin provozu pri tech 150 W. Protoze to topeni ale netaha ten plny vykon furt, tak by to mohlo vydrzet skutecne az den.
Ale pak uz nezbyva, nez ty baterky prubezne dobijet nejakym generatorem.

4

Hardware / Re:UPS - kotel + oběhové čerpadlo

« kdy: 09. 08. 2022, 20:10:45 »

On potřebuje sinusovku na výstupu, jinak to vrčí.

ten typ ktery jsem uvedl ma na vystupu cistou sinusovku

5

Hardware / Re:UPS - kotel + oběhové čerpadlo

« kdy: 09. 08. 2022, 17:28:41 »

spotreby jsou (odhadem) nasledujici:
kotel -elektronika ca 10 - 50W
obehove cerpadlo 30W (bezne se pocita 2 W pro radiator)
Vyrobci uvadeji ve svych podkladech vetsinou celkovou spotrebu vcetne cerpadel ca 100-200W

My nasazujeme u servru CyberPower. To je mozno dodatecne vybavit s LAN-kartou.
Pro orientaci:
CyberPower PR1500ELCD ma vykon 1500VA/1350W a udrzi permanentni 150 W zatez ca. 40 minut.
Zaver: pro celodenni vypadky podle me nema jen UPS cenu, v tom pripade je to treba kombinovat s nejakym
dieslovym/benzinovym generatorem.

6

Vývoj / TIME_WAIT po ukončení socket-komunikace

« kdy: 08. 08. 2022, 12:27:10 »

provozuji běžnou client-server-komunikaci přes AF_INET,SOCK_STREAM a myslím (doufám), že jsem všechno potřebné 'opsal' z internetu správně.
Pomocí 'netstat' vidím, že ještě 60 vteřin poté, co jak client tak server skončí, existuje záznam s TIME_WAIT pro již neexistující proces. Tento záznam neblokuje žádnou další komunikaci přes ten samý port k té samé IP adrese. Nemusím tedy používat nějake finty s SO_REUSEADDR a podobně. Jedině snad by mohly dojit porty, protože začínám od portu 50000 a každá další komunikace obsadí interně nový port ca. od 58000 , takže kdybych v průběhu té 1 minuty nastartovat 10000 nových spojení, tak pak by nebyl žádný port volný. S tím mohu (a zákazník)  žít.
Přes to bych se rád zkušených network-propgramátorů zeptal, zda je možno socket komunikaci naprogramovat tak, aby se ten TIME_WAIT vůbec neobjevoval.

7

Vývoj / Re:Zadávání údajů ve formuláři dnes a před lety

« kdy: 08. 04. 2022, 18:08:09 »

Samotne HTML podporuje ciselne inputy vcetne validace. Vic kmentovat nebudu. Otevrte si libovolny webovy formular, kde se zadavaji cisla.

ja ale nechci neco zadavat do nejakeho weboveho formulare. Ja potrebuji knihovnu.

Otevrel jsem tedy jqueryui.com/datepicker a v uvedenem prikladu se po me chtelo zadani datumu.
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.

8

Vývoj / Re:Zadávání údajů ve formuláři dnes a před lety

« kdy: 08. 04. 2022, 17:50:20 »

toho napsal hodne, dekuji

policko par milimetru
je jiste trochu prehnane, ale pro zadavani jednoho , dvou znaku - to je bezne v podnikovych aplikacich napr. ruzne zktratky statu, meny, mernych jednotek ...
Ergonomie take znamena, ze se usetri misto a uzivatel ma na jeden pohled mhohem vice informaci.

To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte.
Na tom neco je. Drive (pred webem) se to vetsinou nedelalo a ty aplikace taky desetileti fungovaly. 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.

Tohle vyžaduje mít neproporcionální font ...
Ja jsem myslel, ze cifry jsou v kazdem fontu vsechny stejne velke ...?

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

Dnešní webové aplikace jsou pro dost jiné podmínky.
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.

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. Koukali jsme jak vrany a pan sef na sdelil, ze pozadavek pri zadani projektu byl, ze jiz pri zadavani dat musi byt uspora oproti predchozimu systemu minimalne 20% casu (coz nam nas management jaksi zapomnel sdelit). Nastesti jsme se do toho zadani vesli, jinak jsme mohli balit kufry.

To ze zakaznici dnes jsou asi spokojeni, kdyz aspon neco funguje je pro programatorske firmy asi OK, ale ja se presto citim nejak nesvuj. Ale chran buh, ze bych chtel delat revoluci.

9

Vývoj / Re:zadávání údajů ve formuláři dnes a před 40 lety

« kdy: 08. 04. 2022, 11:59:02 »

Mozete mi prezradit vyrobcu a model?

Sorry za rypnutie, dnes mi to zapaluje pomaly, vy ste nemal zrejme na mysli zadavanie, ale zarovnanie inputu vlavo,  ktory by pre zadavanie cisel mal byt zarovnany vpravo. To je mozne lahko upravit par riadkami v css, len dizajnerom to zrejme pride rozsypane ked polovicu poli mate zarovnanu vpravo a polovicu vlavo...

chyba je na moji strane. Nevyjadril jsem se presne, takze se o to pokusim.
Zadavani napr. ciselneho udaje (7.2f ... dve mista za desetinnou teckou a max. 4 mista pred vcetne znaminka) 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.
To vsechno melo ten smysl, aby uzivatel delal co nejmene chyb. K tomu byly prave ty ergonomicke studie.

Ja to nijak neobhajuji a akceptuji silu trhu. Muj pracovni étos mi to doposovad zakazoval, ale my jsme ve firme schopni se ucit dale :-)

10

Vývoj / Re:zadávání údajů ve formuláři dnes a před 40 lety

« kdy: 08. 04. 2022, 11:41:13 »

Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.

a kdyz si zakaznik objedna nejakou zjevnou hovadinu, ktera je sice technicky mozna ale treba mu ve vyslednem efektu vice skodi nez prospiva, tak to take dostane? To si nemyslim, ze to tak delate. 

11

Vývoj / Zadávání údajů ve formuláři dnes a před lety

« kdy: 07. 04. 2022, 16:08:28 »

v článku pana Tišnovského (PyWebIO) je ukázána tvorba formulářů ve webu a jak to dělat jednoduše. Existuje ještě milion podobných nástroju, různé frameworky, kde se pracuje se vstupími prvky podobně (a to následovně):
- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů
- 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
- čí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íš
- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky
- atd ...

Nechtěl bych si jako Sokrates teď stěžovat na mladou generaci a vykládat, jak bylo dříve všechno lepší, ale muím říct, že s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře. Proto jsem docela překvapen, co se dá dnes všechno jako software prodat.

Rád bych se tedy zeptal:

- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)
- bylo by to moc drahé?
- není efektivita práce dnes nutná, rozhoduje moderní vzhled?
- je to zákazníkům dnes jedno, jak budou každodenně pracovat? (v 80-letech existovaly ergonomické předpisy, jak má práce s daty na obrazovce vypadat - je ta ergonomie v rámci poptávek dnes vůbec vyžadována?)
- mohl by někdo doporučit nějakou knihovnu, kde je ta editace na solidní úrovni?

12

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 25. 03. 2022, 14:09:35 »

I řešení exotičtějších případů nepokrytých standardními commandline tooly směřuje spíš na znalost standardních knihoven na manipulaci paměti než na nějaké sofistikované algoritmy…

ano a proto si myslim, ze autor celeho threadu zcela spravne hovori o algoritmicke obsesi

A pan Sivak, ktery tu 'reverzi' do diskuze zanesl si urcite nemyslel, ze ta uloha je nejaky algoritmus, spis sem mel pocit, ze chtel ukazat priklad, jak on testuje kandidaty. Mimojine, pod panem Sivakem nebo Tomesem bych v projektu klidne delal, kdyby me vzali - nejakeho takoveho sefa projektu si predstavuji ze to ma smysl a ze clovek dostane nejaky prostor.

13

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 25. 03. 2022, 13:00:54 »

.... . To co tu předvádíte je pro zkušeného vývojáře obvykle signál, že by nechtěl.

jo, to mi taky hned napadlo 

14

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 25. 03. 2022, 12:57:51 »

kdyz tam je jen reverznuti/vypsani pozpatku tak je to bajt za bajtem.

Pan Sivak nekde nahore mimodek priznal, ze myslel na  'radku po radce'

15

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 24. 03. 2022, 23:02:06 »

Popravdě, moje zkušenost je taková, že stačí zadat něco triviálního jako načíst soubor a vypsat ho pozpátku v libovolném oblíbeném jazyce.

s tim bych mel problem, musel bych priznat ze to nedokazu, protoze to neni jednoznacne zadane.