Příspěvky

601

Studium a uplatnění / Re:Právo vs. IT

« kdy: 02. 09. 2019, 19:23:06 »

Programovani je proste remeslo jako kazdy jiny. Chce to trochu teorie, hodne praxe a cim vic zkusenosti, tim lip. Predstava, ze nekdo, koho domaci bastleni celkem bavi, se tim muze i zivit, je asi tak stejna jako ze kdyz me bavi krouzek keramiky, tak na sobe trochu maknu a za pul roku si zalozim vlastni keramickou dilnu. No, mozna zalozim, ale do roka zkrachuju

Nelze zobecňovat, je dost příkladů i v ČR, kdy někdo dělal něco podomácku a bez předchozích zkušeností a postupně se tím začal živit, založil firmu apod. Takže v principu to možné je.

Nelze zobecňovat ani vliv vzdělání - v IT je sousta samouků a mají dramaticky odlišnou úroveň. Samotné IT vzdělání není žádnou velkou zárukou kvality programátora. Pro některé práce potřebujete teoretické vzdělání, jinde půjde o rutinní řemeslo s malými požadavky na rozhled. IMHO nejlepší je to prostě zkusit.

602

Software / Re:Konverze archivu ze zip do 7z

« kdy: 02. 09. 2019, 18:58:48 »

Jsou to stovky GB velke archivy a zip ma na rozdil od tar moznost rychle zobrazit obsah archivu a extrahovat jednotlive soubory/adresare bez cteni celeho taru od zacatku. Obavam se, ze nic jineho nez zip, to byt nemuze.

Tak tar asi taky nemusi nacitat .tar celý celý - to by odporovalo jeho použití na páskách, ne? Ale nevím, zda to funguje s kompresí.

Záleží taky co je obsahem těch archivů. Nadhodil bych ještě možnost komprimovaného filesystému, kde třeba v případě deduplikace můžete docílit značné efektivity využití úložného prostoru (v některých případech tedy to může vyjít lépe než u zip či 7z balíčků).

603

Server / Re:Který NFS cluster pro replikaci na více strojů?

« kdy: 18. 08. 2019, 18:46:39 »

Není to 100x pomalejší prostě proto, že je síťové úložiště pomalejší než přístup k samotnému hardware? Podle mě to všichni provozují s nějakou cache (možná bcache, dm-cache, ...??).

Jinak PHP generovalo také dost provozu i pro pouhou kontrolu, zda se php skript změnil a zda je potřeba jej načíst. I pokud se nezměnil tak include nebo require dost zdržoval. U autoloaderu to tolik nevadilo, nicméně na to byly založeny i nějaké issues a s hosterem jsme to tehdy řešili dost dlouho (stránky se načítali desítky sekund a to i při zapnuté opcache). Jak je to teď už nevím, PHP už nesleduji...

604

Sítě / Re:Jak naroutovat

« kdy: 18. 08. 2019, 15:39:30 »

Předně bych se ptal, co rozumíme downloadem a co uploadem? Například internetový prohlížeč provede request na server a v rámci toho requestu data posílá i přijímá. Přičemž může převažovat jeden nebo druhý směr a nejspíš ani nejde předvídat, který směr převáží, dokud ten přenos neproběhne. A i kdyby to předvídat šlo (podle hlaviček), nepůjde již existující tcp/ip spojení přerušit a transparentně přehodit za provozu na jinou linku, alespoň pokud moje omezené znalosti postačují. Anebo se pletu a na nějaké nižší vrstvě to možné je? Udělat nějaký bonding přes více poskytovatelů a rámci něj provoz nějak dynamicky řídit?

V praxi by podle mě mohlo fungovat rozdělení provozu dle protokolu anebo dle cílového serveru. Na základě analýzy stávajícího provozu by to šlo nastavit tak, aby byly linky průměrně vytíženy dle záměru (pokud se například ukáže, že většinu provozu představuje YouTube a to ve směru download, mohu jej nasměrovat na linku s neomezeným downloadem).

605

Vývoj / Re:Debugovani javascriptu v browseru: "proti smeru callstacku"

« kdy: 18. 08. 2019, 14:13:31 »

Klikejte na jednotlivé řádky toho callstacku a v kódu uvidíte, jak program dospěl do pozastaveného místa (místo, kde je breakpoint).

Pokud máte například dokument níže a dáte breakpoint na označené místo (ve funkci b), vidíte v callstacku, že byla funkce b volána z funkce a funkce a byla volána z globálního kontextu.

V Chrome je možné i opakovat vykonání příslušného frame, tj. opakovat vykonání určité části kódu, nicméně nejde o plnohodnotné cestování v čase, hodnoty proměnných se na předchozí stav nenastaví a samozřejmě se neprovede ani undo funkcí s vedlejšími efekty (výpis na konzoli, úpravy v DOM stromu apod.). Ve Firefoxu možnost restartu frame nějak nevidím.

Kód: [Vybrat]

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <script>
        var v = '';
        function a(){
          v = 'a';
          console.log('a');
          b();
        }
        function b(){
          v = 'b';
          console.log('b'); // <-- breakpoint
          c();
        }
        function c(){
          v = 'c';
          console.log('c');
        }
        a();
    </script>
</head>
<body>
</body>
</html>

606

Studium a uplatnění / Re:První interview jako student gymnázia

« kdy: 13. 08. 2019, 22:35:39 »

Hodně firem juniorní lidi ani z principu nepřijímá, protože i kdyby dělali zadarmo, tak se to nevyplatí.

To bych nechal s dovolením na těch firmách a nijak bych to nezobecňoval. Každá firma si jistě dokáže výhodnost spočítat sama. A schopnost pracovat s lidským potenciálem se může u jednotlivých firem opravdu dramaticky lišit - v kvalitě i metodice.

607

Studium a uplatnění / Re:První interview jako student gymnázia

« kdy: 12. 08. 2019, 21:30:34 »

Přesto bych mu doporučil, aby se ptal. Na co se chce ptát musí vědět on, uváděl jsem jen příklady.  Pointa spočívá v tom, že se může také sám ptát. A ta perspektiva? Ta spočívá v tom, že to je stabilnější než brigádník a ne že aspiruje na senior developera.

Ta firma očividně někoho takového potřebuje, když ho oslovila. Pokud dotyčný opravdu nic neumí a nikdy nic nedělal, tak tam bude opravdu mýt ty klávesnice. Ale to už je na něm, já bych nikoho nepodceňoval.

608

Studium a uplatnění / Re:První interview jako student gymnázia

« kdy: 12. 08. 2019, 15:47:15 »

Tak černě bych to neviděl, v každé firmě je dost práce do které se nikomu nechce - rutinní činnosti (evidence, dokumentace, testování, manuální kontrola nebo příprava dat...). Tyto práce zaslouží odměnu. Dohodněte se na časovém režimu a na tom, čím jim můžeš být užitečný ihned a co se chceš naučit do budoucna. Pokud je to solidně vedená firma, tak raději zaměstná potenciálního zaměstnance než jen nějakého brigádníka. Můžete si dohodnout třeba tři odpoledne v týdnu v nějakém brigádním režimu, k tomu si vybereš nějakou oblast, kterou budeš v rámci firmy studovat a dostávat drobné úkoly. Tomu se budeš věnovat i ve volném čase a podle progresu pak firma odhadne jak jsi perspektivní - a buď nabídne lepší podmínky nebo si najde někoho jiného.

Peněz si řekni abys vyšel s nákladama a se studiem, ber to jen jako přívýdělek. Zadarmo bych do toho určitě nešel, to je oboustranně nedůstojné. Jednal bych dost naférovku, bez zkušeností je lepší být upřímný než si hrát na machra... IMHO to je znak solidnosti.

Co můžu poradit: Připravit otázky na pohovor - budeš se ptát Ty (používané technologie, vývojový cyklus, množství zaměstnanců, projektů, typická délka projektů, zda se používají některé perspektivní technologie jako umělá inteligence apod., zeptej se na i na bolavá místa jako na přesčasy, zda a jak se zálohuje, jak se řeší absence, nemoc - cokoli Tě zajímá). Dobré otázky jsou známkou zájmu a z reakcí se ledacos pozná.

609

Server / Re:Upgrade verze PHP (CGI/FPM)

« kdy: 10. 08. 2019, 23:53:38 »

S ISPconfig nemám zkušenost.
Nicméně balíky pro starší verze PHP do Debianu udržuje Ondřej Surý, https://packages.sury.org/php/.

Nedoporučuju Vám ale přistoupit na hostování PHP 5.x, dokonce už i 7.0 je obsoletní. Budete řešit čím dál víc problémů - a obvykle si to klient nechce zaplatit. Bohužel, životní cykly všeho (včetně PHP) se povážlivě zkrátily a zákazníci to musí přijmout jako skutečnost.

To je sice pravda, ale dost webhosterů nabízí i dnes PHP 5.x Pokud je infrastruktura připravená na běh různých verzí PHP tak v tom zas takový problém nevidím (FGCI). Pokud to připravené není, je to investice, to je pravda. Co se týče těch balíčků od Ondřeje Surého - používám je doma a funguje to hladce.

610

Software / Re:Rozdělení PDF

« kdy: 10. 08. 2019, 23:44:09 »

Zkus použít PDFSam

Já používám taky PdfShuffler.

611

Software / Re:Obdelníkové označení textu ve webprohlížečích

« kdy: 10. 08. 2019, 19:29:47 »

Bohužel český i cizojazyčný text je tam vzájemně sdružený po slokách, takže v jediném jazyce označíte jen sloku a pak zase jen další sloku. Šel by napsat skriptík, který to popřehazuje. Každopádně bych to nahlásil jako chybu, jelikož je to zřejmý nedostatek v návrhu a člověk se zkušeností s vícejazyčnou sazbou by to určitě řešil s ohledem na možnost pracovat samostatně s jednotlivými překlady.

612

/dev/null / Re:Bývalý zaměstnavatel mi dělá ze života peklo

« kdy: 10. 08. 2019, 19:08:43 »

Každá mince má dvě strany, bral bych to jako příležitost se poučit a posunout. Taky bych zreflektoval, jak jsem v tom příběhu vystupoval já sám a co bych teď už udělal jinak.

613

Software / Re:Rozdělení PDF

« kdy: 09. 08. 2019, 23:22:27 »

Je potřeba zjistit, čím pdf nabobtnalo. Nemusí to být jen bitmapa, ale třeba taky fonty. Nebo objekty, které je potřeba ve více pdf opakovat zatímco v jediném pdf stačí jen jedna instance + odkazy na ni. Vektorová grafika také může nabobtnat, pokud má velkou přesnost - i ta se může teoreticky pro zpracování měnit. Ale první bych se zaměřil a fonty, zda u rozděleného pdf nezabírá většinu písmo, a pokud se ukáže, že nikoli, tak na bitmapy, zda nedošlo k převodu vektorů na bitmapy.

614

Software / Re:Čím prohlížíte logy při ladění? A jak se vám líbí moje prohlížítko?

« kdy: 08. 08. 2019, 22:37:27 »

Řazení není tak důležité, pokud by šlo lze vyhledávat dle sloupců. Umožnilo by to vyhledat například periodicitu určitého jevu. To je ale už smysluplnější ten log rozparsovat, vložit do databáze a pak nad ním spouštět sql dotazy.

615

Odkladiště / Re:Nový OS

« kdy: 08. 08. 2019, 13:35:33 »

Já bych si představoval pokrok desktopových OS v jiných věcech. Konrétně by se mi líbilo přenést podobný princip jako je u textového rozhraní, kdy mohu kombinovat programy a předávat si mezi nimi data pomocí rour a vytvořit si tak program s vlastní funkčností. Není to nic nového, měl už to NextStep, OpenStep a něco takého má tuším i OS X, různé další OS to také mají, snažil se o to Etoilé OS, Smalltalk se tomu také dost blíží, KDE má třeba svoje KParts apod. Ale není to masově užívané a funguje to vždy jen pro omezený ekosystém. Mě by se líbilo, pokud by to bylo něco univerzálně rozšířeného.

Funguje to pro omezený ekosystém, protože je třeba to stavět nad jedním univerzálním rozhraním. A čím univerzálnější to má být, tím víc protichůdných požadavků se tam potká. Od určité hranice se ta potřebná složitost už prostě přestane vyplácet.

Viz též debaty tady u  těchto, tří, blogů od Bystroushaaka.

Příklady: Mám program na úpravu obrázků (Darktable), z něj používám celkem asi 10% funkčnosti a z toho asi 2% pravidelně na jednotlivé obrázky. Líbilo by se mi, pokud by Darktable exportoval služby tak, abych je mohl volat přímo ze souborového manažera nebo abych si zobrazil jen určitý widget z Darktable a mohl jeho funkce aplikovat na vybraný obrázek. Nemusel bych tedy pracovat s celým UI Darktable a možná by ani nemusel startovat celý Darktable kvůli tomu, že chci vyvážit bílou barvu u jednoho obrázku.

Commandlinové nástroje na úpravu obrázků existují. Třeba ImageMagick. Stačí jen nainstalovat a použít. Funguje bez problémů na všech běžných současných OS. Stejně tak používám pluginy do souborového managera i na současných windowsech.

Další typický příklad je spellchecker, který bych mohl aplikovat na libovolný text, nebo služba na  převedení velikosti písem či překlad textu. Kdekoli v UI bych mohl označit text a aplikovat na něj tuto transformaci.

Webových spellcheckerových api už pár dostupných je. Stačí zaintegrovat. Jestli se nepletu, tak třeba prohlížeče už to docela běžně dělají.

Takové funkce bych si mohl zkombinovat tak, aby to ideálně zapadlo do mého vlastního workflow.

A co tomu brání?

A k čemu by tady byl nový OS? Všechny takové služby můžou bez problémů běžet v userlandu. Dokonce bych řekl, že by to bylo i žádoucí.

Pointa byla v tom, koncept commandliny rozšířit do GUI, aby si mohl sám uživatel svoje GUI poskládat, bez nutnosti programovat, a aby to mohl ovládat z GUI a aby to by standard pro všechny aplikace. To dnes dělat zpravidla nemohu, ačkoli tam, kde by šlo jen o zpracování vstupu a poskytnutí výstupu (bez složitějších vzájemných interakcí komponent) to vidím jako realizovatelné.

Jak jsem psal, nechal bych to běžet na existujícím jádru, šlo by tedy o vývoj v userland, možná že by šlo jen o desktopové rozhraní. Nešlo by o revoluci, ale evoluci. V praxi se to neprosadí, nebo neprosadí v dohledné době, protože to přesahuje možnosti běžných uživatel a protože to nepřináší okamžitý zisk. Může se to prosadit v omezené doméně, což se nejspíš už děje. Nějaké příklady jsem uvedl (GNU Radio...).

Ve výsledku je to jen takový prázdninové fantazírováni. Jako celé vlákno.