Export historie prohlížeče: proč to dělat jednoduše, když to jde složitě?

Stala se mi – slovy klasika – takový ošklivý a skoro bych řekl zlý, nepěkná věc. Zavřel jsem si okno prohlížeče se spoustou záložek (karet, panelů) a omylem si toto zavřené okno nahradil nově otevřeným prázdným. Po jeho zavření se tak „naposledy zavřeným“ oknem stalo toto nové, prázdné a to původní bylo nenávratně ztraceno. Leda, že bych vynalezl stroj času a vrátil se do chvíle, kdy jsem tyto mé stránky měl naposledy otevřené...

A tak jsem začal bádat, jak z prohlížeče Opera vydolovat historii v nějakém rozumném, tedy strojově čitelném formátu. První myšlenka byla prohledat domovský adresář a hledat vše, co by mohlo mít co dočinění s Operou (tedy ~/.config/opera a ~/.cache/opera ), jestli tam třeba nenajdu soubor history.xml. Bohužel nic takového a googlení mě akorát přivedlo k myšlence, že něco takového dost dobře není možné. (Fail #1: V závěru se ukázalo, že to tak úplně není pravda, ale k tomu se dostaneme.)

Prohlížeč Opera je vlastně Chromium. Teoreticky by tak mnohé z toho, zde uvedeného, mohlo fungovat i v Chromiu a tudíž i v Google Chrome a snad dokonce možná i v Microsoft Edge.

Pár sekund jsem také uvažoval o tom, že by to mohl umět nějaký plugin. Prohlížečové pluginy obecně ale nemám zrovna v lásce, kromě blokování reklamy (což ovšem Opera dělá nativně), mám pocit, že jen prohlížeč zbytečně zpomalují. Navíc je to další potencionálně škodlivý (resp. děravý či napadnutelný) kód, ještě navíc přímo v prohlížeči.

Trocha Javascriptu ještě nikdy nikoho nezabila …

Navíc, možná proto jsem inspirován youtubery jako colinfurze nebo Michael Reeves (#karanténa) začal uvažovat o nějakém šíleném a bláznivém řešení. Navíc, jsem (si) chtěl ukázat, že se Tom Scott mýlí a hackovat jde stejně dobře i na Linuxu. A v momentě, kdy jsem zjistil, že historie v Opeře je jen další „HTML stránka“, bylo rozhodnuto: Trocha Javascriptu ještě nikdy nikoho nezabila! (Upřímně se obávám, že asi ano, tím si ale nekažme tuhle chytlavou frázi.)

historie v Opeře
Historie v Opeře je jen speciální stránka

Verze 1.0: vize

Moje myšlenka byla tedy jednoduchá – budu-li si chtít zazálohovat historii prohlížeče, otevřu „stránku“ historie (dostoupnou mj. pod url about://history), otevřu vývojářskou konzoli (tu vám na této stránce Opera oficiálně neumožní rozbalit, ale Ctrl+Shift+I funguje), vložím tam nějaký kus kódu, odentruju – a pár vteřin či desítek vteřin počkám. (Fail #2: Je zajímavé, že mě celou dobu nenapadlo prostě pomocí Ctrl+S celou stránku uložit a pak si ji někde v klidu zpracovat.)

Samotný kód pak měl za úkol projít celou stránku, sesbírat záznamy historie a „uložit je“. Nastala tedy otázka, jak/kam data „uložit“. Prohlížečový Javascript nemá moc možností jak ukládat data – ten nejzákladnější, tj. localStorage, se v Opeře sype do nějakých „data“ souborů kdesi v konfiguraci. Navíc bych si troufl říct, že by na této stránce ani nefungoval.

Prohlížečový javascript
Původní myšlenka byla o tom, že uživatel do prohlížeče nakopíruje nějaký kód a zmáčkne Enter

A tak jsem si řekl, že když už bude nějaký Javascriptový kód běžet v prohlížeči, proč rovnou nevytvořit jednoduchou node.js webovou službu, které bude prohlížečový skript data posílat? Taková služba pak může data sypat třeba do sqlite databáze. #Too_much_javascript_to_handle

Tak třeba by nikoho nezabilo ani trochu víc Javascriptu …

Já o pár vteřin později

Teoreticky. Pustil jsem se tedy do toho. Hned první drobný zádrhel byl, že Opera záznamy v historii zobrazuje (resp. načítá a zobrazuje nové a nové) postupně jak člověk scrolluje dolů stránkou (ne moc překvapivě). Nestačilo tak pouze otevřít stránku a vyextrahovat záznamy – bylo nutné odscrollovat postupně až dolů a nechat postupně načíst všechny záznamy.

Verze 1.1: první krůčky

Řekl jsem si, že než listovat celou stránkou úplně dolů a pak odesílat na node.js službu tisíce záznamů, mohl bych sledovat změny ve stránce a „reportovat“ průběžně všechny přidané záznamy. Pochopitelně s automatickým scrollováním, jakmile by byly všechny nově přidané záznamy bezpečně zpracovány.

Dalo se totiž očekávat, že Opera nebude úplně nadšená z toho, že někdo listuje historií až na úplné dno. Dle mých odhadů se mohlo jednat klidně o 10 tisíc záznamů (Fail #3: aktuální odhad mám cca 100 stránek za den, za rok a kousek tedy téměř 50 tisíc) a s ohledem na to, jak titěrně vypadal posuvník (scrollbar) už po prvních pár scrollech dolů, kdy jsem projel historii za poslední dva dny, dalo se tušit, že to bude záhul. (Fail #4: Při hlubším zkoumání vyprodukované databáze, jsem zjistil, že scrollování se vždy zastavilo asi na 95. dnu a další historie už se nenačítala. Podařilo se mi dohledat, že Opera si totiž pamatuje historii jen asi tři měsíce zpětně. Ve výsledku tak stránka byla asi 10x menší, než jsem očekával.)

Vytvořil jsem tedy skriptík, který monitoroval změny v dokumentu a reportoval nově přidané záznamy. S ohledem na to, že záznamy se přidávají po určitém počtu (konkrétně po stovce) a nikoliv po celých dnech, bylo potřeba sledovat i to (záznamy jednotlivých dnů Opera zobrazuje na oddělených panelech, takže přibývají jak dny v panelu posledního dne, tak i nové panely se svými záznamy).

Přidal jsem i automatické scrollování po skončení zpracování (a pro jistotou i nějaké čekání, přecijen natažení a zobrazení stovky záznamů vteřinku, dvě, pět zabere). Vše fungovalo naprosto skvěle, jen s jedním drobným zádrhelem – po asi třech odscrollováních došlo k zřejmě internal erroru v Opeře (prostě spadl kód, který měl renderovat HTML na základě dat z backendu) a stránka přestala na scrollování reagovat. Vlastně se tak trochu celá rozbila a přestala reagovat tak nějak všeobecně.

Verze 1.2: jeden krok vpřed, dva vzad

To mi docela zhatilo plány a vzhledem k tomu, že nepomohlo ani navýšení čekání (pro případ, že by šlo o souběh) či trochu efektivnější/efektnější způsob zpracování přidaných záznamů, musel jsem se s tímto poměrně elegantním řešením rozloučit.

Došlo to tak daleko, že jsem se chvíli dokonce hrabal zdrojovými kódy Opery, snažil jej zprvu debuggovat a po neúspěchu studovat, jak vyvolat načítání nových záznamů ručně, tj. bez scrollování. To se mi nepodařilo, zato jsem našel přímo modul implementující dotazování nad historií. Tedy něco, co by mi vracelo záznamy přímo jako Javascriptové objekty, bez nutnosti parsování HTML, resp. proházení stromu dokumentu!

Funguje to perfektně, až na to, že vlastně vůbec…

Bohužel, ani to se mi, zcela nepřekvapivě, nepodařilo rozchodit (povětšinou jsem byl poslán do oněch partií různými vrstvami bezpečnostní politiky) (dává to smysl, kdyby si jen tak nějaký Javascript mohl takhle hrát s interními věcmi prohlížeče, asi by prohlížeč brzo doprohlížečoval) . Koneckonců, v jednu chvíli jsem si říkal, že dost možná i proto mi můj skriptík padal – Opera zkrátka možná blokovala automatizované zpracování stránky. (Když nad tím tak přemýšlím, tak to je asi hloupost, padalo to na něčem ohledně stylů, což moc nevypadá jako úmysl.)

Dospělo to až tak daleko, že jsem chvíli koukal na stránku dokumentace k Browser History API pro vývojáře pluginů. Ani pořádně nevím, jak jsem se tam vlastně dostal, ale s ohledem na to, že jsem si plugin nechtěl instalovat jako uživatel, natož si jej přímo vyvíjet, stránku i celou myšlenku jsem rychle opustil a lehce ustoupil z mých požadavků.

Verze 1.3: Tak už to zmáčkni!

Rezignovaně jsem opustil představu, že celý problém vyřeší jedna nodej.js služba a jeden kód prostě vložený do konzole prohlížeče, a vytáhl bazuku. Sáhl jsem totiž po prográmku xdotool, který emuluje, resp. „fejkuje“ primitivní akce uživatele, tj. pohyb nebo klikání myší a stisky kláves.

Scrollování jsem tedy vyřešil jednoduchým Bashovým skriptíkem, který do svého ukončení prostě pořád dokolečka mačká Page Down (pochopitelně, opět, s nějakým čekáním). Spolu s tím jsem také z mého prohlížečového kódu vyhodil celý ten problematický monitoring stránky a prostě jej nechal staticky a jednorázově projít celou stránku a naposílat všechny nalezené záznamy.

Tohle celé jsem zabalil do jednoduchého skriptu, který:

  1. Požádá uživatele, aby otevřel v prohlížeči historii (to by samozřejmě šlo udělat jedním příkazem, ale myslím, že to celému skriptu přidává na „dramatičnosti“)
  2. Řekne mu, aby si otevřel vývojářské nástroje (opět, i to by šlo udělat pomocí xdotools, ale chtěl jsem ponechat co nejvíc kontroly uživateli)
  3. Spustí skript na scrollování dolů
  4. Jakmile stránka dojede dolů (nebo kdykoliv si uživatel usmyslí), má jej ukončit
  5. Nahodí se node.js služba, založí se databázový soubor, vytvoří tabulka
  6. Uživateli je předložen částečně minimizovaný (tj. bez nadbytečných bílých znaků) Javascriptový kód, který má spustit v prohlížeči
  7. Po doběhnutí uživatel dá pokyn k odpojení od databáze a zrušení služby
  8. Na závěr je jen pro kontrolu vypsán počet záznamů v databází a skript končí.

Nezbývalo, než to celé spustit. Všechno klapalo, dokonce i reportování node.js službě. Akorát to spadlo po pár sekundách, protože prohlížeč nedokázal udržet tolik otevřených spojení současně – XHR požadavky se totiž v základu posílají asynchronně, tedy se nečeká na dokončení předešlého a tudíž je prohlížeč chtěl poslat prakticky všechny v jeden okamžik. Opraveno a nyní už celý skript proběhl a nasbíral skutečná data. Jenže …

insufficient resources, moc současných spojení
UUUPS! Opera evidentně nezvládne víc, než pár tisíc současných spojení …

Verze 1.4: Zrychlujeme

… jenže stále tam bylo několik „ale“. Tak zaprvé, kód, který měl uživatel zkopírovat do prohlížeče, jen slepě odstraňoval nadbytečné bílé znaky. Což, jak jsem záhy zjistil, mělo nedozírné důsledky v případě, že v kódu byl někde jednořádkový komentář. V takovém případě tedy zakomentoval zbytek celého kódu. Oukej, nějakým způsobem jsem tam doplnil odstraňování jednořádkových (a když už, tak už i víceřádkových (bo minimizace!)) komentářů.

Další problém, který mě trápil, byla rychlost nahrávání. Nebylo nijak zvlášť překvapivé, že vzít jeden JSON záznam, poslat ho přes XHR na node.js server a tam ho jedním dotazem vložit do databáze bude při tisících takovýchto záznamů docela neefektivní. Přidal jsem tedy dávkové zpracování.

K mému poměrně velkému překvapení se nahrání tisíce záznamů propadlo z dvou a půl minut na 14 sekund (při posílání po 10), resp. na 6 sekund (při posílání po 20) nebo necelé tři sekundy (při posílání po 50). Musel jsem kvůli tomu ale navýšit maximální velikost požadavku na 10MB (občas bylo zřejmě některé URL příliš dlouhé) (Fail #5: zřejmě to nebylo URL, ale favicona ve formátu data:uri). Nakonec jsem tedy nechal velikost dávky na 20 (při 50 by se zvyšovala šance že node.js odmítne celý balík 50 záznamů, o které bych tak přišel).

Pak už jen drobnosti jako odpojit se korektně od databáze při ukončování, a doplnit trošku informativních výpisů (jak do konzole v prohlížeči, tak při běhu hlavního skriptu).

Mimochodem, shruba v této době (když jsem při jednom testování nechápavě zíral, proč se scrollování zastavilo na datu někdy v únoru – a dál ani krok) zjistil, že Opera si pamatuje historii jen tři měsíce zpětně. Na jednu stranu docela šok a zklamání, na druhou stranu motivace mít skript připravený k opětovnému použítí. Ale o tom pozděj, teď jedna odbočka.

Odbočka 1.1: Primitivní ale funkční

Dobře, ale – říkáte si, co se sesbíraným seznamem navštívených stránek? Samozřejmě, až budu mít sesbíraných víc záznamů, než poslední tři měsíce, půjdou dělat docela zajímavé statistiky. Od nenajvštěvovanějších serverů přes opakovaně navštěvované přímo konkrétní stránky, až po histogram návštěv různých webů dle denní doby/dne v týdnu. #Science

A nebo si vytvořit obrázek se faviconkami všech navštívených stránek. Tedy tak trochu něco jako reddit place nebo The Million dollar homepage – jen sestavené mnou samotným.

První verze faviconek
Prvotní verze stránky faviconek, ještě bez jednotné velikosti.

Koneckonců, z tohoto důvodu již úplně první verze exportéru historie pracovala s cestou k faviconám stránek zobrazených v historii. Myšlenka tedy byla jednoduchá – skript vezme vyexporotovanou databázi navštívených stránek a vygeneruje jednoduchou HTML stránku s obrázkem (faviconkou serveru) pro každý záznam z historie.

Teprve v tento moment jsem se hlouběji podíval na favicony získané z historie. Zjistil jsem, že to vlastně vůbec nejsou adresy reálných ikonek, nýbrž jen odkazy do interní cache favicon Opery. Tedy nepoužitelné. Použil jsem tedy starý trik, nechal jsem si vylistovat jen názvy serverů a ve stránce vyjmenoval všechny obrázky s URL https://SERVER/favicon.ico. Samozřejmě ne všechny takové existují (typicky třeba mnou docela často navštěvované mapy.cz) a tak se u nich pomocí alternativního textu zobrazil křížek. (Asi by šlo na jednotlivé servery poslat požadavky, ty zparsovat a získat přímo konkrétní adresy faviconek, předmětem tohoto skriptíku ale bylo jen rychlé a plus mínus funkční řešení.)

Na odzkoušení hypotézy celkem cool, ukázalo se, že to může fungovat. Ale jak pravil klasik – not great not terrible.

Odbočka 1.2: Hloupé, ale ještě funkčnější

Napadlo mě ale, že favicony by si prohlížeč zcela určitě měl cachovat. A taky, že (bavíme-li se stále o Opeře) – ano! V sqlite databázovém souboru ~/.config/opera/Favicons se nachází parta tabulek obsahující informace o faviconách. Pak už stačilo jen nastudovat si jejich strukturu a napsat stručný dotaz, který vylistuje URL favicon pro všechny servery. K mému překvapení, prohlížeč si pamatoval všechny favicony pro všechny servery v nedávné historii. (#Fail 6: Historii? Ano, cache favicon je vlastně také historie. Pamatuje si seznam navšítených adres (pro každou z nich i faviconku) a datum a čas posledního přístupu. Nevýhodou ale je, že si u každé stránky pamatuje vždy jen poslední přístup. Teoreticky by to ale jako jednoduchá strojově čitelná historie mohlo postačovat.)

Tentokrát už by mi obyčejný Bashový skript nestačil, takže jsem sáhl po Pythonu. Prostě si pro každý záznam v historii pomocí jeho serveru najde odpovídající URL favicony a tu vypíše jako obrázek. Protože ale mám k dispozici informací víc, každá faviconka je klikatelná (vede přímo na patřičnou stránku) a s popiskem (tooltipem) (titulek stránky). (Fail #7: Vzhledem k tomu, že historie a cache favicon se nacházejí v různých databázích, mám jejich „spojení“ řešené až na straně v Pythonu. Sqllite samozřejmě umí i to, pak by se skript zkrátil a většinu práce by odvedl jeden SQL dotaz. Skript by pak šel napsat i přímo v Bashi bez nutnosti Pythonu.)

faviconky!
Faviconky! (výřez!)

Tento skriptík je tedy trochu víc promakanější, ale hlavně – zobrazí favicony všechny (pochopitelně, pokud v mezičase některá nebyla přesunuta), a to včetně tooltipů a vlastně i konkrétních URL (po přejetí nad odkazem se jeho adresa zobrazuje někde dole). Jedinou nevýhodou je, že při generování musí být zavřená Opera. Databáze je pochopitelně Operou hojně využívána a je tak tímto procesem blokovaná. To trošku kazí dojem z vygenerované webové stránky, ale myslím, že přínosy jasně vedou.

Verze 1.5: budoucnost

Dobře, ale zpět k exportéru historie. Jak jsem zmiňoval, nyní už je dokončen a plně funkční, aktuálně se již jen dolaďují některé detaily, které usnadní dlouhodobější používání.

Jeden z nich by určitě mělo být nevkládání duplicitních záznamů (když budu zálohovat každý měsíc, předposlední a předpředposlední měsíc budu vždycky dvakrát). S tím souvisí, že skript by neměl vyžadovat neexistenci databázového souboru při spuštění a – nejlépe cestu k němu nemít zadrátovanou napevno, ale na vyžádání od uživatele.

Také s ohledem na zkušenosti získané tvorbou generátoru stránky s faviconkami, odebrat z exportu favicony. Je to hodnota nicneříkající a tudíž zbytečná. Obdobně, datum a čas návštěvy stránky by asi taky bylo rozumné ukládat jako datum a čas a ne jako text natvrdo vystřižený ze stránky.

Zapracovat by se dalo i na generátoru stránky s faviconkami. Například ikonky rozházet, a zobrazovat jejich velikost podle návštěvnosti daného serveru (tj. něco jako tag cloud). Nebo je prostě a jednoduše jen náhodně zamíchat.

Závěr

Závěrem bych tradičně jen uvedl odkaz na GitHub projektu (pokud odkaz nefunguje, pak ještě nebyla dokončena verze 1.5). Nepředpokládám, že by se našel někdo, kdo si jej stáhne či na něm nedejbože bude dělat úpravy.

Vlastně celý tento článek vznikl jen jako výpis strastí, se kterými se člověk může při takovém tom domácím hackování setkat. Dá se očekávát, že s prvním redesignem Opery se minimálně ta prohlížečová část celá rozsype, ale třeba do té doby nasbírám alespoň nějaké informace o mé aktivitě na internetu. A nebo třeba ne. Možná mě přestane bavit pokaždé nechat dlouhé minuty (kolik je to celkem se mi ještě nepodařilo přesně určit, celkový export jsem spouštěl vždycky přes noc) čekat, než se odscrolluje stránka s historií.

A nebo se mi podaří dopátrat alespoň některé ze ztracených záložek (stránek, panelů, karet), kvůli kterým tohle celé vzniklo. Ale musím se přiznat, že na to jsem v průběhu vývoje tohoto udělátka úplně zapomněl.

Disketo: úklid fotek

Tento článek navazuje na předcházející článek, ve kterém jsem představil prográmek disketo. Ten slouží k vyhledávání souborů a složek na základě rozličných kritérií, jako je název složek či souborů v nich obsažených, počet souborů určitého typu, nebo počet shodných souborů ve dvou (a více) různých složkách.

V tomto článku se podíváme na trochu reálnější použití disketa – a to úklid ve fotkách. Fotek totiž často bývá hodně, bývají z různých zařízení – a často od různých lidí. Některé jsou poctivě roztříděné, některé méně, některé jen tak narychlo zkopírované. Občas je na čase sednout a projít si všechny místa, kde se fotky nacházejí (počítače, flashky, externí disky, paměťovky, cloudy, …) – a udělat v nich pořádek. Sesypat do jedné složky, smazat ty které už mezitím byly roztříděny a naopak případně roztřídit ty, které roztříděné nejsou.

Disketo může být v mnohém z toho poměrně nápomocné. Umožní vám najít celkem očividně zapomenuté či neroztříděné fotky – a to dokonce bez toho, aniž byste vůbec museli vidět jedninou fotku. Chcete to zkusit? Pojďme se do toho pustit.

Ještě než se do toho radostně pustíte, jen bych připomněl, že disketo asi není prográmek pro běžného uživatele. Pro jeho používání je vyžadována pokročilá znalost práce s počítačem na úrovni ovládání příkazové řádky a základů programování či skriptování.

Složky s fotkami (první způsob)

Základem každého třídění je sesbírat si všechny možné složky ze všech možných míst. Vezmeme disketo a vylistujeme se všechny složky, jež se jmenují např. foto či fotky. Jak už víme, disketo pracuje s regulérními výrazy, takže je možné názvy zkombinovat. Je tak možno použít např. vzor fot(o|ky). Pozor však na malá a velká písmena, ty disketo rozlišuje.

Předchozí vzory nám vylistují všechny složky, odpovídající (jejiž celá cesta odpovídá) zadanému vzoru. Tedy všechny složky foto a fotky a to včetně podsložek. Můžete se tak přesvědčit, jak strašně velké množství složek s fotkami doma máte. Nás ale na úvod bude zajímat jen ty samotné složky foto či fotky, bez jejich podsložek. Toho se naštěstí dá v disketu dosáhnout docela snadno, stačí říct, že cesta musí textem foto nebo fotky končit, tedy fot((o)|(ky))/?$ (volitelné lomítko na konci je jen pro jistotu).

Pak už stačí složky jen vypsat. Disketo skript slozky-s-fotkami-1.ds tedy bude vypadat následovně:

Skript spustíme se seznamem všech našich uložišť (v mém případě složky obrazky a zaloha přímo v počítači):

Složky s fotkami (druhý způsob)

Pokud však máte ve fotkách totální chaos a nemůžete ani říct, jak se vlastně jmenují všechny složky s fotkami, je tu druhá možnost. Můžete zkusit vyhledat složky obsahující fotky, tedy JPG soubory. Takových bude ovšem hromada (JPG soubory jsou jeden ze základních formátů obrázku, takže i bez fotek jich v počítači budete mít tisíce).

Prostý vzor (.*)\.jpg by tak našel zbytečně moc souborů. Lepší by bylo použít vzor například PICT_[0-9]{7}\.JPG, pokud váš foťák produkuje soubory ve formátu PICT_1234567.JPG. Samozřejmě, i zde se vzory dají kombinovat, takže můžete vytvořit vzor třeba (PCIT_[0-9]{7}\.JPG)|(Photo[0-9]+.jpg)|(fotka \([0-9]+\).jpg). Stejně jak v minulém případě je rozumné ukončit vzor znakem $ (lomítko už nyní opravdu nehrozí; pokud tedy nemáte na disku složku s názvem odpovídající vzoru).

Použijeme skript slozky-s-fotkami-2.ds, který prvně vyfiltruje podle názvu adresáře (podobně jako v předešlém případě, ale mírněj). To se může hodit např. pro vyloučení složky Windows, resp. omezení vyhledávání jen na uživatelské adresáře, ale není nic špatného nastavit tento parametr na (.*) (nebo rovnou celý řádek vypustit).

Dále provede filtraci podle souborů. A to tak, že sítem projdou všechny složky, které obsahují soubory dle vzoru výše, a to, pokud jich obsahuje alespoň uvedený počet. My tuto volbu ponecháme na uživateli. Čím nižší číslo, tím více falešně pozitivních složek disketo najde (např. grafika k programům), naopak čím vyšší, tím víc skutečných složek s fotkami bude ignorováno. Bude to chtít trochu experimentování, proto jej necháme uživateli zadat až při spuštění. Tedy:

A spustíme (budeme hledat složku s alespoň dvěma fotkami):

Zajímavostí je, že nyní jsme našli i fotky školního projektu, které nám předchozí skript nenalezl.

Jen tak mimochodem, při velmi vysokém čísle (stovky či třeba tisíc) pak můžete obdržet složky, které obsahují enormní množství fotek. Získáte tak přehled – jednak o tom na jaké akci (či v jakém časovém úseku) jste opravdu hodně fotili – ale zřejmě také o tom, která složka pravděpodobně obsahuje nevytříděné a nepromazané fotky.

Hledání duplicit – složky

Výborně, máme tedy seznam všech složek obsahující fotky. Ze by bylo fajn si jej ručně projít a zkontrolovat. Přecijen, v počítači můžete mít různé složky a vzoru tak může odpovídat i například složka Xbfotoxb20am, která ale zřejmě nebude obsahovat fotky.

Také se ukázalo rozumným shromáždit si všechny složky s fotkami na jedno místo. Založte si složku třeba UKLID_FOTKY a všechny si tam nakopírujte/přesuňte. Zjednoduší to práci i vám i disketu, který nebude muset pořád dokola prohledávat všechna uložiště (bohužel, disketo je v tomhle poněkud hloupý a tak prohledává pokaždé vše, bez ohledu na to, jestli se něco změnilo či ne).

Máte? Výborně. (Já tento krok v rámci jednoduchosti vynechávám.) Nyní se jen tak pro kontrolu podíváme, jestli některou ze složek s fotkami nemáte dvakrát (či dokonce vícekrát). Přecijen – často člověk zálohuje až moc – a některé zcela totožné fotky může mít na více místech – i když jsou to pokaždé tytéž. Necháme disketo, ať vám vyhledá duplicitní složky (v první fázi pouze takové, které mají shodný název). Použijeme následující skript:

Disketo vám vypíše všechny složky, které mají nějaké „dvojče“ (tj. jinou složku se stejným názvem). Jak si vypsat, která (či které, pokud je jich víc) to je, si povíme za chvíli.

V mém případě však žádné duplicitní složky nenalezl, takže jdeme pátrat dál.

Hledání duplicit – soubory

Když dva dělají totéž není to totéž – a stejně tak, když se dvě složky jmenují stejně, neznamená to, že jsou si věrnou kopií. Složky s názvem „dovolená u moře“ „vánoce u Nováků“ či „šedesátiny“ by mohly vyprávět.

Pomocí disketa můžeme i tyto hříšníky odhalit. Použijeme skript pro vyhledání složek s duplicitními soubory. Skript porovná všechny složky (včetně jejich obsahů) mezi sebou navzájem a pokud najde shodu (složka obsahuje víc než zadaný počet shodných souborů), složku vypíše.

A podle čeho je bude porovnávat? Nejjednodušší je porovnávání podle názvů souborů. Takový disketo skript bude vypadat následovně:

Pro případ, že by název souboru nebyl dostatečný (např. pokud foťák čísluje vždy od nuly a stejné názvy souborů by se tak často opakovaly) je možné porovnávat nejen podle názvu souborů, ale také podle velikosti. Minimálně u fotek je poměrně nepravděpodobné, že by dvě fotky měly stejný název i stejnou velikost. V takovém případě se namísto filter_directories_with_common_file_names použije filter_directories_with_common_file_names_with_size.

Teoreticky by také bylo možné porovnávat podle data poslední změny či vytvoření souboru. To však u souborů, které vznikly zkopírováním moc nedává smysl (soubor kopie vzniká až při kopírování, nemá tedy stejný čas vzniku jako původní soubor), takže v disketu není implementován a musel by se naprogramovat ručně (což ovšem není nemožné, disketo s tím tak trochu počítá).

Každopádně, my se budeme držet původního porovnávání dle jména souboru. Skript nám vypsal, které složky mají nějaké „dvojče“, ale nevíme jaké:

Abychom to zjistili, budeme změnit způsob, kterým se vypisují nalezené složky, tj. poslední příkaz našeho skriptu. Bohužel, teď už se neobejdeme bez aktivního programování, je potřeba naprogramovat vlastní „vypisovač“, tedy subrutinu, která vypíše, co přesně potřebujeme. V našem případě chceme vypsat u každého nalezené složky také ty, které jsou jejími dvojčaty (opět, může jich být víc). Bez dalšího vysvětlování:

Výsledek je mnohem informativnější (pro lepší přehlednost doporučuji zkrátit cesty, tj nahradit např. /home/martin/obrazky za O a /home/martin/zaloha za Z):

Vidíme tedy, které složky obsahují podezřele společné soubory. Je tu jistá šance, že se jedná o kopii téhož obsahu – v našem případě složka nafoceny-projekt poměrně pochopitelně obsahuje také soubory ze složky s fotkami, proto se nám vypsala. Často ale jen narazíme na složku, která jen obsahuje neprotříděné či nepromazané soubory oproti jiné – a přitom se nám vypíše jako duplicita.

Tomu asi úplně nejde zabránit, nicméně mohli bychom si vypsat, kolik souborů obsahuje první složka, kolik druhá – a kolik z nich mají společné. (Šlo by vypsat soubory všechny, ale to by bylo poněkud nepřehledné.) Něco takového najdeme v souboru scripts/find-common-directories.ds. Ten nám vypíše (první číslo je počet souborů složky na začátku řádku, druhé číslo počet společných souborů a třetí číslo počet souborů v druhé složce):

Pokud jsou všechna tři čísla stejná, pak jsou obsahy obou složek (zřejmě) totožné. Než ale jednu z nich smažete raději si je obě otevřete a obsahy zkontrolujte (jak jsem psal, porovnáváme pouze na základě názvů souborů).

Další poměrně pozitivní případ je typu 120/49/49 (a pochopitelně tedy i zrcadlový), tedy že všechny soubory z druhé složky se dají najít také v první složce. Soubory v druhé složce tak nejspíš oproti té první prošly promazáním či roztříděním. (A nebo se naopak část z nich ztratila při překopírování!)

Pokud budou čísla zcela rozdílná, pak se bude jednat o naprostý mišmaš a fotky bude bohužel potřeba projít ručně.

Hon na Otesánka

Máte-li odebrány všechny duplicitní fotky a stále máte pocit, že vám moc místa na disku neubylo? Můžete se zkusit poohlédnout po největších žroutech místa na disku. V případě fotek to budou pravděpodobně videa. Dost možná tam někde máte dvouminutový záběr vaší kamarádky, jak tančí v temném baru na stole. Ano, přesně ten typ videí, kde není absolutně nic vidět, zato je tam slyšet celá hospoda. Pominu-li fakt, že takováto videa by vůbec neměla vznikat, natož se dostat až do rodinného alba, tak mohou být taky poměrně pěkný Otesánek – jedno takové video vydá klidně z pár desítek fotek.

S odhalením podobných souborů může pomoct například unixový prográmek baobab, neboli Analyzátor využití disku, nicméně podobnou službu nám s trochou snahy poskytne také disketo. Začneme tím, že použijeme skriptík pro vypsání souborů fotek s jejich velikostí. Například skript:

Vypíše u každé fotky její velikost v (kilo)Bajtech:

A teď trocha hrátek s unixovým shellem. Následující příkaz spustí disketo s předchozím skriptem, u výpisu prohodí sloupce (aby byla velikost první), seřadí (tedy podle velikosti) a vypíše prvních 5 souborů:

Já ve složkách žádná videa nemám, ale je vidět, že fotky z loňska jsou víc, než dvakrát větší, než ostatní. Kdybych tedy potřeboval uvolnit místo, už bych věděl, na které fotky sáhnout jako první.

Kontrola zálohy

Posledním, co si ukážeme, je jednoduchá analýza záloh. To se může hodit třeba v případě, že někde najdete zapomenutou a dost možná nekompletní zálohu, a budete potřebovat zjistit, jestli náhodou neobsahuje nějaké cenné či ztracené soubory.

Vlastně je to docela jednoduché – pomocí disketa si vylistujeme všechny soubory jak na aktuálním, tak na záložním uložišti a oba seznamy souborů vypíšeme do souboru. Pak už jen soubory porovnáme, nejjednoduššeji pomocí comm (graficky pak např. pomocí meld). Pro vylistování souborů použijeme následující disketo skript:

a poté (sed je použit pro odstranění společné části cest):

vypíše soubory, které jsou ve složce se zálohou, avšak nikoliv ve složce obrazky.

Porovnání složek graficky pomocí aplikace meld

Závěrem

Jak je vidět, disketo dokáže být celkem užitečná hračka. Samozřejmě opravdový potenciál tohoto pidiprográmku ocení asi jen programátor na linuxu, který si rád hraje s příkazovou řádkou, ale třeba se jednou dokopu, dopíšu dokumentaci a přidám i dummy verzi pro běžného smrtelníka.

Udělejte si pořádek v PC s nástrojem disketo!

Víte, co udělá programátor, když si musí roztřídit fotky? Správně, napíše si na to program. A víte, co udělá informatik, když si musí roztřídit fotky? Navrhne si framework a spolu s ním i vlastní skriptovací jazyk. A napíše si na to program.

Co je to Disketo_Framework?

A teď vážně. Disketo_Framework, neboli zkráceně prostě disketo, je nástroj pro, řekněme pokročilé prohledávání diskových uložišť. Tedy všech pevných, nepevných, externích i interních disků, flash disků, pamětových karet a já-nevím-čeho-ještě. Zkrátka všeho, co obsahuje soubory a složky.

A proč? Nu, protože občas je nutné všechna tato uložiště projít a udělat si v nich pořádek. Ano, mluvím na vás, jež shraňují data roky, a pak jednou za čas, když jim začne docházet místo, tak vymýšlí co smažou. Ano, přesně na vás, jež jednou za dva roky zkopírují celý obsah svého počítače někam na externí disk a nazývají to záloha. Ano, na ty, co data ukládají raděj i vícekrát, a pak mají počítač přehlcený duplicitními daty.

Zkrátka asi na každého z nás, protože jen opravdu málo lidí se o svou IT techniku stará skutečně precizně. A takový člověk musí jednou za čas sednout, posbírat všechny externí disky, paměťové karty a flash disky a udělat si v nich pořádek. Vzít staré zálohy, a zálohy záloh, zálohy zálohy záloh, a buďto smazat, případně zaktualizovat. Vzhledem k tomu, že místa na disku je vždycky nedostatek, tak zálohy jsou stejně nekompletní a případně končí slovy: „no co, tak fotky jsem zálohoval loni a tak v nejhorším přijdu o fotky za letošek“.

Disketo neřeší žádný z uvedených problémů, to říkám rovnou. Ale může vám s nimi alespoň pomoct. Pomocí disketa si totiž můžete vyhledat
(a to je taky vlastně jediné, co disketo umí) různé soubory a složky podle různých kritérií.

A teď trochu techničtěji …

Aby člověk mohl disketo požívat musí se nejdříve ujasnit některé technické záležitosti. Disketo totiž původně tak trochu vzniklo pro programátory, protože některé věci si zkrátka naprogramovat musíte vy, i když chcete aplikaci jen používat. Ale v základu jej určitě může ovládat i trochu víc technicky zdatný uživatel.

Disketo je totiž kromě toho hodně orientován na linuxové operační systémy. To znamená jednak to, že se spouští z příkazové řádky, ale také to, že se nesnaží problémy vyřešit přímo, ale poskytnout data ve strojovém formátu, aby je mohly zpracovat další unixové nástroje jako např. less, grep, sed, find – nebo třeba i excel.

V neposlední řadě, pořád je disketo také programátorská platforma – chcete-li – knihovna, kterou je možné použít a dále její funkcionalitu rozvíjet. V takovém případě se očekává skutečně aktivní znalost Perlu. Ano, Perlu!

Základní myšlenka

Celé disketo totiž stojí na tom, že pro vyhledávání „problémových“ souborů či složek je třeba disketu říct, co hledáte. Na úvod třeba všechny složky, které obsahují fotky. Dále například všechny složky, které v názvu obsahují záloha a obsahují více než 90% shodných souborů. Nebo všechny páry složek, které mají alespoň jeden (dva, tři, …) společné wordovské dokumenty. A nebo prostě a jednoduše všechny složky, ze všemožných disků, flashek, cloudů a paměťovek, které obsahují něco, co se týká bakalářky.

Jak toho dosáhnout? Jednoduše a přitom složitě. Disketo toho umí relativně dost, ale je potřeba mu říct, co přesně je potřeba, aby našel. Na začátku (resp. na konci, ale k tomu se dostaneme) je vždycky seznam tzv. kořenových složek. Tedy složek, které chcete prohledávat. V praxi to většinou jsou přímo kořenové složky všech disků či uložišť (tj. na Windows C:\, D:\ a podob.). Samozřejmě, pokud hledáte třeba všechny fotky z léta 2016, asi nebudete nechávat disketo prohledat celý počítač, bohatě postačí jen Obrázky\fotky\.

Výstup z disketa může být zobrazen třeba ve formě adresářového stromu

Dalším krokem, je potřeba ujasnit si, co vlastně hledám. Hledám složky podle názvu? Hledám složky s určitými soubory? Hledám duplicity? A nebo ještě něco jiného? Operace je samozřejmě možné kombinovat. A k tomu slouží tzv. disketo skripty.

Disketo skripty

Disketo skript pak není nic jiného, než seznam právě těchto operací, příkazů, úkolů. Tak například příkaz filter_directories_of_same_name ze seznamu všech složek vyškrtne ty, které jsou v něm jen jednou. Jinými slovy, nechá jen ty složky, které jsou v uložišti dvakrát. Samozřejmě, asi bude vhodné nejdřív vybrat jen složky, které nás zajímají, tedy: filter_directories_by_pattern.

Tento příkaz vyžaduje uvést, jaké složky se mají ponechat a jaké vyhodit – na základě názvu, pochopitelně. Tedy například "fotky", "škola" nebo "zaloha". Je také možné uvést $$, v takovém případě bude hodnota zadána až při spuštění. To se hodí pro opakovatelně použitelné disketo skripty s jinak stejnou konfigurací.

Na závěr je slušnost přeživší složky vypsat – tedy příkaz print_directories_simply. Výsledný skript by pak vypadal následovně (první a druhý příkaz byly prohozeny, je rozumné nejdříve vyřadit složky, které nepasují názvem, až pak ty, které se neopakují):

Takto připravený skript uložíme do souboru, třeba slozky.ds a můžeme spustit. Protože obsahuje jedenkrát $$, bude při spuštění vyžadovat zadání jedné hodnoty – vzoru pro filtrování složek.

Spouštění

Disketo se spouští pomocí tzv. interpretu disketo skriptů, tedy prográmku run-disketo-script.pl. Jeho použití je následující:

Jeho prvním argumentem je název (cesta) souboru disketo skriptu. Následují argumenty skriptu a na konci je pak seznam (kořenových) složek, které má disketo prohledávat.

Vezměme si náš disketo skript slozky.ds. Budeme chtít prohledat složky skola a zaloha, a hledat v nich všechny duplicitní složky s názvem statnice. Spuštění se provede následujícím příkazem:

Výstup bude následující:

Jak vidno, disketo nám vypsal spoustu informací. Pokud nás nezajímají informativní hlášky o průběhu (hodí se vědět, jak dlouho která operace probíhala, můžou to totiž být i hodiny), můžeme je skrýt přesměrováním standartního chybového výstupu do /dev/null:

Nyní už vidíme jen seznam tří složek, které mají v názvu (resp. v celé cestě) statnice a současně mají shodný název s některou z jiných (zde všechny tyto tři současně). Když zkusíme vyhledat prijmacky, dostaneme:

Samozřejmě, disketo vyhledává slovo od slova. Při vyhledávání statnice nenajde ani státnice ani statnicove-otazky. Obecně, s češtinou (ve smyslu diakritiky) bude mít disketo zřejmě nemalý problém. Za to se omlouvám, řešení by bylo komplikované.

Další funkce

Například následující disketo skript vyhledá všechny složky, které mají zvolený název, a které obsahují alespoň jeden wordovský dokument:

Abyste si nemuseli pamatovat, jaké hodnoty skript kde vyžaduje (obzvlášť, pokud bude skript vyžadovat parametrů více), příkaz ./run-disketo-script.pl dokumenty.ds (tedy zavolání disketa jen s názvem skriptu, bez dalších hodnot a složek) vám požadované argumenty vypíše:

Co dělá který příkaz a co znamená každý z jeho argumentů by mělo být poměrně intuitivní, takže k nim není dodávána žádná další dokumentace. Zájemci mohou konzultovat zdrojový kód modulu Disketo_Extras, kde jsou implementovány.

Pro opětovné ozkoušení, jestli jste uvedli správné hodnoty lze použít přepínač --dry-run. Ten, klasicky, spustí disketo skript s reálnými hodnotami (ať už přímo ze skriptu nebo zadané při spuštění), ale nebude prohledávat disk (což ušetří čas). Tedy:

Pokud jej necháme skutečně proběhnout (tj. bez --dry-run), vypíše nám něco následujícího:

Jak vidíte, skutečně nám vypsal všechny (složky i podsložky), které v názvu obsahují otazky (a přitom obsahují alespoň jeden dokument *.docx).

Pár poznámek

Do disketo skriptů lze vkládat komentáře. Nijak neobvykle, řádek začínající # je ignorován až do svého konce.

Přepínač --dry-run už jsem zmínil. Vypíše, jaké příkazy disketo provede a s jakými hodnotami. Seznam všech příkazů a jejich parametrů se vypíše pomocí příkazu./run-disketo-script.pl --list-functions . Bohužel, nechtělo se mi psát se s dokumentací, takže případné informace o to, co patřičný příkaz dělá, vás odkážu na modul Disketo_Extras.

Disketo ve většině případů pracuje pouze s názvem souborů či složek. Předpokládá totiž, že chceme-li hledat složky s excelovskými tabulkami, budeme hledat soubory s příponou xls nebo xlsx, při hledání fotek jpg a podob.

S tím souvisí – pokud je některý z parametrů nazván pattern, pak ve skutečnosti očekává regulérní výraz, navíc case sensitivní, tedy rozlišující velká a malá písmena. Takže např. pro vyhledání fotek (malými nebo velkými písmeny) je třeba použít [fF][oO][tT][kK][yY] popř. (fotky)|(FOTKY). Pro vyhledání „fotky nebo foto“ pak třeba fot(o|ky).

Pokud se regulérní výrazy neznáte, mělo by být možné použít namísto nich běžný text. Je tedy třeba akorát hlídat si malá a velká písmena a vyhnout se použití speciálních znaků (závorky, pomlčky) (nebo před každý z nich dát zpětné lomítko). Pokud chcete vzor, který splňuje každý text, použijte např. (.*) (to se hodí, pokud je pro vás některý z filtrů zbytečný, nebo jej chcete jen rychle deaktivovat).

Obdobně, parametry jako printer nebo matcher musí být perlovské subrutiny, tedy funkce. Díky tomu je možné doprogramovat prakticky libovolný způsob, jak porovnávat, vypisovat, či vyhledávat soubory a složky. Tak například následující skript:

Vypíše:

Na závěr už snad jen – v instalaci disketa se nachází adresář scripts, který obsahuje pár základních skriptů. Asi nebudou úplně pro přímé použití, nicméně třeba poslouží jako inspirace.

Kde a jak?

Disketo najdete na mém GitHubu, není to samostatný repozitář, je součástí mého projektíku shell-utils.

Disketo – kromě perlu, pochopitelně, nemá žádné jiné závislosti nebo požadavky. Stačí mít jen v počítači perl a spustit ./run-disketo-script.pl, popř. perl run-disketo-script.pl.

V samostatném článku pak ukážu, jak si s pomocí disketa udělat pořádek ve fotkách.

Ruští hackeři v česku? Zatím ne …

Původně tento článek měl prezentovat šokující zjištění ohledně působení (ruských) hackerů v česku. Na(ne)štěstí se ale ukázalo, že se jedná jen o neškodnou shodu náhod. I tak bych ale má zjištění označil za zajímavá.

Nedávno jsem potřeboval dokoupit nějaké ztracené náhradní díly k nábytku. To se občas stane každému, žeano.

Sedl jsem tedy ke Googlu a celkem naslepo googlil „ten prapodivný divný šroubek IKEA“ a podobné. Trošku mě překvapilo, že mě google zavedl i na stránky na webech s doménou riverfoodfestival.cz, osobnidluhy.cz či elektrofolk.cz :

Ale říkal jsem si – proč ne – třeba River Food festival dělá reklamu některému ze sponzorů, prodejci nábytku. A nebo si jen dělá legraci a článek by měl podtitulek: „Také už máte plné zuby všech těch šroubků, desek a hřebíčků z IKEI? Tak se přijďte odreagovat na náš festival!“

Stejnětak jsem si dokázal představit, že portál osobnidluhy.cz bude jako jednu ze služeb přeprodávat přeprodávat náhradní díly na nábytek od registrovaných dlužníků. Prodávat jinak korunové položky, za řekněme 100x vyšší částky s tím, že zisk z prodeje by šel na boj s dluhovými pastmi, mi přišlo vyloženě jako super nápad. No a že prodejce elektroniky elektrofolk prodává také díly na nábytek je překvapivé snad ze všeho nejméně.

Nic nemohlo být dále od pravdy. Už z prvního webu jsem vytušil, že tohle nebude ta správná cesta. Web vypadal až moc profesionálně na to, aby nabízel šroubečky a panty. Zářily na něm na mě obrázky krásného moderního nábytku, o náhradních dílech však ani stopy. Obdobná situace byla i na dalších výše jmenovaných webech.

Co mě však zaujalo víc než obskurní doménová jména byla skutečnost, že weby vypadaly … noo, tak nějak podobně. Když si byl jeden podobný druhému, říkal jsem si, že se asi jedná jen o jiný brand stejné firmy – a tudíž i web mají podobný. U třetího mi to ale přišlo podezřelé – nu posuďte sami:

První 3 stránky
Ukázky z trojce nalezených stránek.

To už mi nedalo, tak jsem se na webu krátce pozdržel. Zjistil jsem, že ať kliknu kamkoliv, jsem odsměrován vždy na tutéž stránku. Ne moc překvapivě, daná stránka nefungovala.

Weby se odkazovaly vždy na stránku enter.php, která následně přesměrovávala na ww1.nabytek-fagus.cz nebo ww1.jisknabytek.cz . Ani jedna z těchto stránek však nefungovala.

Jednou jsem byl ale namátkou (zřejmě po vypnutí adblocku) přesměrován na stránky ww31.nabytek-fagus.cz nebo ww31.jisknabytek.cz , což byly klasické zaparkované stránky s reklamami.

Doplnění: O pár týdnů později weby přesměrovávaly také na http://ww38.exoticky-nabytek.cz . Navíc, ww1.nabytek-fagus.cz mezitím začal fungovat (a zobrazovat reklamy).

V ten moment mi to přišlo úsměvné, že si někdo platí evidentně několik domén, aby mu na nich visely webové prezentace – které všechny směřují na neexistující – zřejmě – stránky skutečného prodejce.

Nicméně, já jsem pokračoval v kobercovém náletu na internet. Ve výsledcích vyhledávání jsem narazil na stránku výsledků vyhledávání v (jak se ukázalo tak – značně pochybném) vyhledávači ZapMeta . Říkal jsem si – proč ne, beztak ve výsledcích Googlu, kde se akorát pere jedna reklama přes druhou, a ta zbylá pole obsazují moderní weby moderních výrobců/prodejců moderního nábytku, bude zajímavé vyzkoušet nějaký alternativní vyhledávač. Třeba se tak dostanu na nějaký 20 let neudržovaný web dvaašedesátiletého prodejce nábytkových dílů z okrajové části města …

Od tohoto momentu už jsem nehledal náhradní díly na nábytek. Pokud mi google našel tři, čtyři pochybně podobné weby, ve výsledcích vyhledávače zapmeta to byl prakticky každý druhý. Namátkou jsem si několik takových odkazů vypsal:

  • https://www.krmivalevne.cz/clanek/nahradni-dily-pro-sedaci-soupravy
  • https://www.plzen-lekarna.cz/clanek/pojezdy-vestavene-skrine
  • https://www.tenis-sokolov.cz/_.php
  • https://www.tecard.cz/pojezdy-sk-in
  • https://www.condor-reklamy.cz/pryzove-zatky-na-nohy-od-zidle
  • https://www.3sezonyvpekle.cz/levny-polsky-nabytek
  • https://www.mssochanova.cz/levny-nabytek-za-odvoz
  • https://www.alpanharmony.cz/clanek/kancelarsky-nabytek-za-odvoz
  • https://www.allowance.cz/daruji-stary-nabytek-ostrava-zdarma-za-odvoz
  • https://www.tecard.cz/nabytek-bazar-daruji-za-odvoz-postele
  • https://www.skodaeshop.cz/telo-potrebuje-hubnuti-bez-stresu-2/
  • https://www.lekarnauhute-ostrava.cz/nabytek/za-odvoz-uherske-hradiste
  • https://www.autodilymazacitechnika.cz/inzerce-ostrava-nabytek-daruji
  • https://www.czdent.cz/barove-zidle-emilio-cerne-barove-zidle
  • https://www.autobusovadoprava-ramball.cz/nabytek-za-odvoz-teplice
  • https://www.autobusovadoprava-ramball.cz/za-odvoz-stary-nabytek
  • https://www.czdent.cz/barove-zidle-emilio-cerne-barove-zidle
  • https://www.rozvozrokytnice.cz/nabytek/za-odvoz-vysocina
  • https://www.ohrivacevody.cz/stropni-svitidla-do-kuchyn
Výsledky vyhledávání vyhledávače zampeta
Výsledky vyhledávání vyhledávače zampeta: 5x fake nábytek a jeden pochybný ruský server mezi nimi …

Vzhledem k tomu, že zde prakticky nebyl pochyb o tom, že někdo evidentně rád skupuje různé domény (a to opravdu různorodé!) aby na nich provozoval líbivé weby (bez ohledu na URL stránky!!) prodejců nábytku, nedalo mi to, a jal jsem se situaci diagnostikovat.

Další stránky
Náhoda? Nemyslím si.

Ukázalo se, že většina z těchto domén je registrovaná na jistého soudruha (sic!) Todora Dimitrova z Prahy. Kromě něj jsem ale narazil na korejce, mexičana a dokonce i slováka. Ale neprověřoval jsem všechny domény.

DNS záznamy některých z webů
DNS záznamy některých z webů

Zdá se však, že tento případ má poněkud nečekané rozuzlení. Pan „soudruh“ Dimitrov (opravdu si tak nechává říkat!) je ve skutečnosti CEO společnosti TELE3, u které, zdá se, tyto weby běží. Zřejmě se tak jedná jen o zaparkované domény bez reálných provozovatelů.

Reálné reklamní stránky (pokud zrovna fungují), cíle odkazů na "podvodných" nábytkových webech
Reálné reklamní stránky (pokud zrovna fungují), cíle odkazů na „podvodných“ nábytkových webech

Že se nejedná o žádné weby ruských hackerů dokládá i například skutečnost, že zdrojový kód stránek není nijak obfuskovaný. Ba dokonce, můžete v něm najít i komentář některého ze slovenských vývojářů:

Slovenský komentář v kódu stránky
Slovenský komentář v kódu stránky

A pak je tu ještě jedna věc. Náhodou jsem zjistil, že některé z webů obsahují v patičce odkaz na jednoho ze svých bratrů. Tedy na další takový web. Jsem-li hacker provozující síť falešných webů s nábytkem, určitě nebudu chtít, aby se mezi nimi dalo v poklidu proklikávat. Dá-li se totiž někde proklikávat, dá se to poměrně snadno zautomatizovat.

Ano, skutečně jsem si napsal skriptík, který tento řetězec webů prochází. Skript se zkrátka podívá na zadaný web a pokud obsahuje odkaz na další, následuje ho. A situace se opakuje. Bohužel, odkazy na další obsahuje ani ne polovina webů, na které jsem narazil, takže moje původní vize, že se mi podaří nasbírat všech několik stovek těchto webů a po pár hodinách načítání se octnu na výchozí stránce, byla tedy lichá. I tak se mi ale u asi tak 5 webů podařilo „proklikat“ na v průměru 5 dalších. Mám tak seznam téměř 50 stránek s neexistujícím nábytkem…

Původně jsem chtěl jít ještě dál, a to tak, že bych si naprogramoval i klienta pro vyhledávač zapmeta. Tomu bych pak už jen předhazoval rozličné vyhledávací fráze a mohl tak síť falešných webů řádově rozrůst. Bohužel ale zapmeta není zrovna dvakrát developper friendly, takže to se mi nepodařilo. Nicméně, skriptík na procházení seznamu webů mám hotový a najdete ho na mém GitHubu.

Závěr je tedy asi takový, že téměř jistě se nejedná o invazi ruských hackerů, jež se snaží vydávat za prodejce nábytku a – v asi tom nejhorším případě – pomocí phishingu získávat osobní či platební údaje našich spoluobčanů.

Zřejmě šlo jen o akci doménového spekulanta. Se zálibou v prodeji nábytku. Jinak by totiž na své nakoupené domény nasadil prosté reklamní stránky tak, jak to bývá zvykem.

Takže působí tedy v česku ruští hackeři? Samozřejmě, ale tohle není ten případ.

Programování je vlastně skoro jako vaření

Už je tomu pár let, co jsem napsal poměrně zdařilý článek srovnávající platformy Windows a „Linux“. Už pár měsíců se mi hlavou honil způsob, jak podobným způsobem běžnému smrtelníkovi popsat programování popř. obecně vývoj software. Píši proto tento článek, který by měl snad každému tátovi, každé babičce a dokonce i kdejaké knihomolce, která o programování ví asi jako křováci v Africe o Terrym Pratchettovi, co to vlastně to programování je.

Úvodem: programování vs. vývoj software

Na úvod mi dovolte jedno malé rozseknutí. Asi nikoho nepřekvapí, že jak programování, tak vývoj software jsou činnosti, na jejiž konci jsou počítačové programy, popř. software. Rozdíl mezi programováním a vývojem software však přece jen nějaký je.

Vrátíme-li se do kuchyně, můžeme říci, že programování je něco jako vaření, zatímco vývoj software příprava večeře. Příprava večeře obvykle obnáší vše od nákupu surovin, jejich přípravy (např. omytí zeleniny, rozmrazení masa), přes samotné vaření, až po úklid kuchyně a následně servírování.

Velmi podobně, vývoj software je proces, který se sestává z mnoha podkroků, mezi které patří například volba vhodných technologií, vytvoření zázemí (spuštění vývojářských serverů, instalace vývojových prostředí), přes samotné programování až po nasazení do provozu, uživatelské testování a údržbu.

V tomto článku se budu zabývat pouze samotným programováním, poněvadž fakt, že je s tvorbou software nějaká práce navíc asi nikoho až zase tak moc nepřekvapí. Naopak, programování je něco, co trápí nočními můrami už i leckteré studenty středních škol.

Vařila myšička omáčičku …

Máme tedy nachystány suroviny a jdeme vařit. Vezměme si učebnicový příklad: nějaká, téměř libovolná, omáčka. Rajská, koprovka či jakákoliv jiná. A, z druhé strany, takový typický elektronický obchod, e-shop. Ono bohužel i toto srovnání není úplně fér, vzhledem k tomu, že uvařit – byť sebepoctivější – omáčku nezabere víc, než pár hodin, zatímco nad e-shopem programátor může strávit dobrých pár týdnů. Pro ilustraci nám to ale bude stačit.

Když vidím, jakej jsem programátor, tak se bojím jít k doktorovi do kuchyně.

Jak takové vaření obvykle vypadá? Zde je první důležitý moment, protože stejně tak, jako se každá omáčka dá udělat jednoduše, rychle a obyčejně, tak i počítačový program se dá zkonstruovat méně či více propracovaně. Je rozdíl, jestli vaříte omáčku jako rychlou večeři nebo ke svátečnímu obědu pro celou rodinu. A stejně tak, e-shop prodávající jeden produkt s minimem dodatečných funkcí může být určitě vytvořen daleko snáze než propracovaný interaktivní systém s obrovským počtem uživatelů.

Jíška a vývar

Pokud omáčku budete začínat jíškou, bude vhodné si nejdříve jíšku připravit. Pokud ji budete zalévat vývarem, bylo by vhodné si nejdříve „uvařit“ vývar. Je tedy vidět, že i ve vaření se často setkáme s tím, že pro uvaření jednoho pokrmu je třeba mít uvařený nějaký/é další. Obdobně, pro vytvoření e-shopu je vhodné si nejdříve naprogramovat (samostatný/é) modul(y) – například pro připojení k databázi, přihlašování uživatelů, propojení se skladem a podob.

Stejně tak, jako se vývar dá nahradit bujónem, dá se obvykle propracovaný samostatný programový modul nahradit něčím jednodušším. Pokud si však vývar opravdu uvaříme, můžeme si část zamrazit a použít někdy příště. V oblasti vývoje software toto mívá mnohem větší význam – software se totiž nedělí ani nemrazí, ale prostě kopíruje. Takže „vývar“, který programátor jednou „uvaří“ může používat prakticky donekonečna.

Proto je víc, než jasné, že každý programátor se snaží tyto znovupoužitelné programové suroviny vytvářet jak jen to jde. Ve velkém množství případů však tyto suroviny ani nevytváří sám, ale – prostě si je koupí (popř. stáhne, pokud jsou zdarma). Na tom vlastně také není nic překvapivého: Kdo by se dnes doma mlel se strouhankou? Nebo si doma vyráběl vlastní majonézu?

Eintopf? Nein, danke!

Mimochodem, dnešní programování se dělí na dva hlavní (znepřátelené) směry: funkcionální a procedurální. Podíváme-li se na to pohledem přípravy omáčky, tak funkcionální programování vypadá asi takto: Programátor si nejdříve velmi pečlivě přichystá vše potřebné pro přípravu omáčky. Tedy jíšku i vývar, obě důkladně ochutí tak, aby s nimi pak při samotné přípravě omáčky měl minimum práce a současně nehrozilo, že mu výslednou omáčku zkazí. K tomu pak už jen přidá něco na ochucení omáčky, velmi jednoduše to smíchá dohromady a má zaručeno, že omáčka bude velmi pravděpodobně poživatelná.

Oproti tomu omáčka vařena procedurálně vypadá jako takový jeden velký eintopf. Procedurální vaření totiž připomíná spíše přípravu kouzelného lektvaru. Procedurální přístup znamená provádění jednotlivých dílčích kroků postupně za sebou. V praxi tedy jeden hrnec, do kterého se postupně přisypávají jednotlivé ingredience. I vývar by se nějak prapodivně měl vařit v hrnci, ve kterém se zvesela převaluje právě usmažená jíška. Postupným přidáváním dalších surovin by na závěr vznikla požadovaná omáčka.

Je jasné, že takovýto přístup je v praxi naprosto nepoužitelný. Funkcionální programování se zde zdá mnohem použitelnější. Z různých důvodů se však neprogramuje ani funkcionálně (protože to by například znamenalo, že jíška by se musela uvařit v kompletně svém vlastním hrnci a pak se zbytečně přelít do hrnce na omáčku), ale oba tyto přístupy se kombinují.

Málo slaná, co?

Nedílnou součástí každého vaření je ochutnávání. (Poznámka: bavíme se o ochutnávání, ale u pokrmu samozřejmě záleží také na vůni, barvě, konzistenci, palčivosti, teplotě…) Dokážete si představit, že uvaříte omáčku a ani jednou jste ji neochutnali? Bohužel, programátoři, kteří něco naprogramují a za celou dobu si nezkontrolují, že udělali všechno naprosto správně, jsou víc než běžnou záležitostí.

Zde nám trošku nahrává funkcionální programování. Pokud smícháme ingredience, které jsme důkladně ochutnali a ověřili si tak, že opravdu chutnají, jak mají, výsledný pokrm nám nezkazí. Naopak, při čistě procedurálním vaření vlastně až do poslední chvíle nemáme něco, co by stálo za to ochutnávat („není ta jíška s vývarem a kořením málo slaná?“).

Zkrátka a dobře, ochutnávání je pro vaření klíčové – a stejně tak i pro programátory. Chybička (nebo obecně cokoliv, co nezvykle ovlivní chuť) se totiž může stát vždycky. Tři malé místo dvou velkých cibulí, nezvykle silný česnek, či obvyklé „ups, asi mi trošku ujela ruka“.

Pokud se nám zdá omáčka málo slaná, dosolíme ji. Pak ji, pochopitelně, přesolíme, takže ji musíme doředit. Pak ovšem musíme přidat další koření, protože by byla slabá. Zkrátka, při každém takovém ochutnání často zjistíme, že je s omáčkou něco špatně a je potřeba to spravit. Tomu se v programování říká testování a ladění. Problém s testováním a laděním, s věčným ochutnáváním a dochucováním, je však ten, že se může opakovat velmi dlouho a pořád to není ono. Ve výsledku nám tak může vzniknout nějaký nepoživatelný paskvil, který tak akorát „za stálého míchání lijeme do hajzlu“. Bohužel i programátor se často setkává s tím, že pořád není spokojen, pořád to není ono, a tak neustále upravuje a upravuje, až mu nakonec stejně nezbude nic jiného, než to celé smazat a začít nanovo.

A to ani neříkám, že když jídlu něco schází, dá se docela snadno určit co. Sůl, koření, zahustit. Ale programátor má dost často jen informaci „je to dobrý“ a „není to dobrý“. Teprve studiem toho, co tam všechno nasypal může vyhodnotit, co asi udělal špatně.

Supermáma

Při programování se občas setkáme i s dalšími pojmy, které najdete i v kuchyni. Například synchronní a asynchronní programování. Pokud byste vařili synchronně, a věřte mi, že to tak občas určitě děláte, znamená to, že než se vám dokončí určitá část vaření, do které není potřeba zasahovat, tak stojíte u sporáku a čekáte. Až se voda ohřeje, až se máslo rozpustí, až to vychladne. Prostě stojíte a čekáte.

Oproti tomu, asynchronní programování znamená, že dáte vařit vodu, a jdete dělat něco jiného. Až bude voda uvařená, vrátíte se k ní. Logické, ne? No, bohužel, pro programátora je snažší si počkat. Už jen proto, že v momentě, kdy se voda dovaří, tak dost možná může být přerušen z nějaké činnosti, u které by neměl být rušen. Člověk při vaření na to myslí, ale – programátor za počítačem má poměrně omezené možnosti.

Spoustu legrace si také každý programátor užije při paralelním programování. Tedy, že v kuchyni není sám. Velmi často se totiž poštěstí, že se lidí po kuchyni potuluje více. A zkuste se ubránit situacím typu: „Cože, tys tu omáčku taky solil?“, „Ale já ten nůž potřebuju teď hned!“, nebo „Teď, teď jsem si tu solničku sem položil. Kdo mi ji vzal?“. Opět – v kuchyni docela humorné situace, avšak pro programátora noční můra. Omáčku osolí sotva špetičkou soli – a je přesolená. Nebo chce něco ukrojit a zjistí, že nůž na stole neexistuje. A hledejte chybu, kterou jste nezpůsobili vy.

Noční můra každého programátora? Kdyby Láďa Hruška začal programovat …

Obdobně, jako v kuchyni, i většina programátorů občas používá tzv. „hacky“. Tedy něco, co je naprosto nepřípustné, ale – ono mu to prostě extrémně zjednoduší práci. Mezi takové „hacky“ patří například zahušťování omáčky moukou namísto jíšky, nahrazení vývaru bujónem či tomatové omáčky kečupem. Ano, přesně tak, takový Jirka Babica. (Opravdu si nedokážu představit, jak by vypadal jako programátor.) Jsou to prostě věci, kterým se každý slušný programátor snaží vyhýbat jak jen to jde. Bohužel, ne vždy to jde (nebo je to vyloženě nutné).

Dobrou chuť!

Pomalu se blížíme ke konci, omáčka je téměř hotova, poslední přisolení, zamíchání a je hotovo. Můžeme servírovat, chutná skvěle. Náš e-shop je hotov a může být spuštěn. Někdo nám ale hned první den píše, že se do něj nedá přihlásit. A další. A další. Jak je to možné? Jednoduše – i ta omáčka, která nám chutnala (nebo to s ní naše chuťové pohárky prostě vzdaly a začaly našemu mozku tvrdit, že je opravdu skvělá), nemusí chutnat všem. To se tak bohužel stává. U programátora to může být tím, že po všem tom ladění a testování je prostě jen něco úplně obyčejně přehlédl. A nebo – prostě je tam něco, mezi židlí a klávesnicí, co způsobilo, že to funguje jen jemu a nikomu jinému.

Věřím, že mé srovnání programování s vařením někomu nemusí být po chuti. Je fakt, že by se dalo najít hned několik disciplín, kde se to k sobě hodí asi jak vegan a řízek. Nicméně, stále platí, že i programování, obdobně jako vaření, je prostě věda. Opravdu velká věda. Avšak pro programátora je i docela obyčejná omáčka práce na dlouhé týdny či měsíce. Tak tedy dobrou chuť všem programátorům!

Generátor vánočních koled

Vánoce. Ten skvělý čas, kdy se všichni radují, veselí, slaví – a jsou šťastní. Co jiného jim také zbývá?

A o tom to je. Vánoce jsou vlastně taková docela kýčovitá záležitost. Nezdá se vám to? Všechny ty výzdoby, pohádky, dárky, písničky, atmosféra, filmy.

Podívejte se třeba do televizního programu: pohádky, rodinné komedie, romantické filmy. Mrazík, Sám doma, Láska nebeská? Ano, to je jen malý výčet toho, čím se vás televizní stanice snaží naladit na vánoční vlnu. To vše k Vánoční atmosféře zcela jistě patří. Ale – co mě už pár let překvapuje, šokuje a já nevím, co všechno, tak jsou rádia.

Asi to přišlo ze západu. Nebo se to zrodilo někde v hlavě některého z tuzemských hudebních producentů: máme tu letní hity, tak proč nenapsat nějaký vánoční? Ten nápad se docela ujal, a tak každoročně vznikne pár nových zaručených vánočních hitů. Pokud jste o nějakém hudebním interpretovi dlouho neslyšeli (nebo se mu naopak v poslední době daří a rád by své popularitě trochu napomohl), je docela pravděpodobné, že před Vánoci o něm určitě uslyšíte. V lepším případě o hudebním interpretovi. V tom horším se jedná o herce, moderátora či nedejbože politika.

Vzhledem k tomu, že rádia moc neposlouchám, tak informace ohledně nového vánočního hitu Vánoc 201x ke mě doputují zpravidla pouze pomocí sociálních sítí. Co si tak vzpomínám, z posledních let tu máme Vánoční čas od skupiny Nightwork, Štědrý večer nastal od XindlaX či dokonce parádní funky hit Santa Claus od bláznivé kombinace Gunčíková, Jandová, Suchánek a Genzer. Dokonce koukám, že i redakce rádia Evropy 2 si opět pro letošní Vánoce nazpívala svůj song. Chválu nebo naopak kritiku těch uměleckých děl ponechám odborníkům a jen dodám, že Hudební masakry by ve svých análech jistě vyhrabaly spousty daleko horších exemplářů.

A přesně v ten moment mě to napadlo. O čem to k čertu vlastně chtějí pořád zpívat? Ježíšek, cukroví, dárky, radost, purpura. Stromeček. Dobře, ještě kapr. A cukroví. Tak moment, to už tu bylo? Dobře, nejsem sice textař, ale – nemohu se zbavit pocitu, že takovéto „koledy“ jsou prostě pořád o tom samém.

A v ten moment mě napadlo, jestli by nešla práce takového textaře nahradit počítačovým programem. Tak jsem to zkusil a – no, posuďte sami:

Generátor vánočních koled (online)

Pokud by vás zajímalo, jak takový elektronický textař funguje, prostě a jednoduše za sebe skládá víceméně náhodné verše. Samozřejmě, nic není je tak. Verše se musí rýmovat a také mít nějaký rytmus (resp. alespoň stejný počet slabik v každém verši).

Zajímavější je, jak se generují jednotlivé verše. Základní idea spočívá v tom, že každý verš popisuje nějakou činnost. Tuto činnost může provádět určitá skupina osob/věcí. Například děti mohou psát dopis Ježíškovi, rodiče pít punč a zvířátka ležet u krbu. Verš se tedy sestavuje tak, že se vybere některá z těchto aktivit a k ní se pak už jen vybere některý z aktérů. V případě, že je tato kombinace moc krátká, tak se tam doplní pár slov typu: „zase po roce“ nebo „dnes celý den“.

náhled
Koleda s číslem 80147628.

Trochu odborněji řečeno, můžeme tak mluvit o (probabilistické) formální gramatice typu 2, tedy bezkontextové. Pochopitelně, s určitými restrikcemi, takže to čistě bezkontextová gramatika není. Nicméně, celá idea generování veršů je na principu gramatik od počátku založena.

Kdo by měl zájem, celou aplikaci mám nahránu na openshiftu, takže si ji (když mi dáte klíč) můžete naklonovat, nebo si ji proklikat přímo v testovací produkci pod touto adresou: xmasgen-martlins.rhcloud.com na clusteru někde v Kalifornii. Tímto bych chtěl také poděkovat studentskému spolku UP Crowd za hosting v Česku a koncekonců také za propagaci.

Tak vám přeji hodně zábavy při generování a hlavně zpívání (byť nepředpokládám, že by některé z koled snad byly zpívatelné) vygenerovaných koled. A samozřejmě Veselé Vánoce a štastný nový 2017 rok k tomu!

Prokletí informatika

Právě jsem se vrátil ze zkoušky. Dopadla – jak to tak u mě většinou bývá – víc než úspěšně. Místo bujarých oslav si však (opět) říkám, jestli je to vlastně v pořádku.

 

Než se však pustím do vyprávění toho, co se vlastně stalo a proč už v sobě nemám třetího panáka, dovolte mi jednu důležitou poznámku na úvod.

V názvu článku stojí „informatika“. Lidé, kteří mě znají, tak ví, že já mé spolužáky či kolegy rozděluji na ty, kteří jsou „informatik“ a na ty, kteří jsou „student informatiky“ (popř. „absolvent informatiky“). Tento na první pohled nenápadný rozdíl je však prakticky fatální.

Většina lidí si totiž myslí, že když studují (nebo již dostudovali) informatiku, stali se z nich informatici. To je však velký omyl. Vezměte si sebe – kolik z vašich spolužáků ze střední, kteří školu skutečně vystudovali, to skutečně umí (a případně dělá)? Když se zamyslím já, tak z mých spolužáků ze střední, elektrotechnické průmyslovky, se elektrotechnice věnuje možná tak polovina. Zbytek třídy, ač na to mají papír, bych jako elektrotechniky rozhodně nikdy nenazval.

A s informatiky je to podobné. Znám spoustu lidí (netvrdím, že přímo mých spolužáků; vzhledem k tomu, že nás aktuálně studuje 6, tak bych prakticky musel být konkrétní, což bych nerad), kteří studují informatiku stejně jako já a přitom informatiky nejsou. Ano, určitým způsobem třeba umí programovat, zadaný úkol nějak vyřeší, ale když se jich zeptáte, proč to řešili tak a tak, nebo jestli je třeba jakože nenapadlo použít to, co nás učili dva roky zpátky, tak neví. Neví, neznají, nenapadlo je to, už si to nepamatují.

Tito lidé prostě o informatice, no, dobře, nechci říkat, že neví nic, ale – z jejich práce je patrné, že prostě nejsou informatikové. Chodí do školy, učí se na zápočty a zkoušky, ale je vidět, že tomu, co se učí důkladně nerozumí a hlavně – neumí to použít v praxi. Takový člověk informatiku pouze studuje, nic víc. Jo – a samozřejmě na ni nadává. Že se musí učit teoretické nesmysly a zbytečnosti, které mu budou v praxi k ničemu.

Tak přesně o těchto lidech tento článek není. Tento článek popisuje smýšlení někoho, kdo na přednáškách přednášejícího neposlouchá, kdo na přednáškách slova přednášejícího hltá po kilech. Mluvím tu o člověku, pro kterého zabývat se teoretickou informatikou není odporná zbytečnost a ztráta času, ale něco zajímavého. Něco natolik zajímavého, že se nebojí tomu obětovat část svého volného času.

Takto nějak se vidím já. Přiznávám, že tato představa je poněkud idealizovaná, ale to koneckonců nevadí – ani já nejsem dokonalý informatik. Dobře, ale říkáte si, co je na tom tedy tak špatné?

No, první věc, která nejspíš napadne každého, je těžká integrace do praxe. Člověk zvyklý na přednášky a hluboké dumání nad rozličnými teoretickými problémy zpravidla velmi těžce nese fakt, že najednou nejhlubší problém, který ho čeká, je zjistit, proč zákazníkovi aplikace spadla.

Ale o tom jsem nechtěl mluvit. Toto totiž zjevně trápí kdejakého studenta či absolventa vysoké školy. To, proč píši tento článek pramení přímo z podstaty informatiky, resp. jejich aplikovanějších podob.

Jedním z úkolů informatiky totiž je něco, čemu já souhrnně říkám „teorie programování“. To je, zjednodušeně řečeno, sada informatických disciplín, které nám ukazují, jak by se mělo programovat. Pochopitelně, znalost teorie programování je jeden ze základních předpokladů každého informatika. Každý informatik totiž pak nejen, že něco nějak naprogramuje, ale je si vědom toho, co a jak vyřešil, že jeho řešení je nejlepší možné a pokud není, tak dokáže přesně popsat proč.

Pořád si říkáte, co je na tom špatné? Ukážu názorně: Informatik je postaven před úkol vytvořit jednoduchou databázovou aplikaci. Něco jako telefonní seznam nebo tak. Nu, aplikaci si kompletně navrhne, vytvoří si malý databázový framework, sadu GUI komponent a důmyslný systém jednotkových testů. Na závěr vše spojí dohromady a po dvou týdnech má hotovou perfektní aplikaci.

Když před tentýž úkol postavíte neinformatika, založí si projekt, vloží třídu, otevře hlavní metodu, do ní nabuší příšerné množství kódu, aplikaci spustí, prokliká a má hotovo. Za jedno odpoledne. I s pauzou na kafe. Hodinovou.

A na to, že to celé funguje jenom nějakým zázrakem a že se každý bojí v té aplikaci cokoliv změnit, protože je mu jasné, že by okamžitě odkráčela do křemíkového nebe (a ještě cestou sestřelila nějaké dopravní letadlo, prostě jen tak), se nikdo neptá. Obzvlášť v komerčním prostředí, kde každá minuta je drahá. A rozdíl třinácti a půl dne je v tomto případě značný.

Tuto situaci si asi dokážete představit. Ale pointou tohoto příběhu dvou programátorů není příšerná práce neinformatika, ale – naopak precizní práce informatika. Tady je totiž krásně vidět, že informatikovi naprosto vůbec nezáleží na tom, na jak rozsáhlém projektu pracuje, on je precizní vždy.

I když si jen píše v excelu vzoreček pro výpočet počtu sazenic na záhon, naprosto automaticky dokumentuje a testuje. A výpočet si dělí na dílčí kroky. A tak podobně. Prostě dělá vše, co je mu jakožto informatikovi vlastní.

A v tom je ten problém. Informatik je totiž takový detailista, puntičkář, chcete-li. Nedokáže se od toho odprostit. Ve všem musí mít dokonalý systém. A pokud ne, celé to zahodí a raděj to udělá celé znovu. Co naplat, že ztratí dva dny práce. Nedokázal by se smířit s tím, že vyprodukoval něco, co není podle jeho představ. Co se mu na 100% nelíbí. Co není ideální.

Tohle všechno stojí čas. To věčné zdokonalování, vylepšování, uhlazování. A vždycky se objeví nějaký další problém. Takže kus práce zahodit a zase znovu.

Zprvu je to skvělé, člověk má radost, jak se jeho dílo posouvá stále více a více kupředu. K dokonalosti. Ale časem začne sledovat, jak vždy, když má cíl na dosah, tak mu o kousek uskočí. A to začíná být frustrující. A únavné. A celé to skončí zpravidla tím, že to prostě vzdá a je nucen se spokojit s výsledkem, který rozhodně není dokonalý. Pořád je 1000x dokonalejší než to, co by vyplodil kdejaký neinformatik, ale – není to ono.

Takže zpravidla člověk, i když projekt zdárně dokončí, je totálně vyčerpán – jak fyzicky, po nekonečných dnech a nocích za počítačem, tak psychicky – žít s tím, že po tak usilovné práci a takovém množství času projekt stejně nedotáhl do konce. Ke kýžené dokonalosti.

Jedinou útěchou tak pro něj může být, když se zjeví problém. Neinformatikovo veledílo totiž v takovém případě havaruje a z neinformatika se stává hromádka neštěstí, zatímco informatik na to byl připraven a problém tak vyřeší velmi snadno. Toť teorie. V praxi se – bohužel – vždycky se objeví něco, s čím ani sebelepší informatik nepočítal a hromádka neštěstí se stává z něj. Podařilo se totiž najít (další) důkaz toho, že jeho dílo skutečně není dokonalé.

Takže zatímco neinformatikové si žijí ten svůj život smířeni s tím, že hold občas budou muset řešit nějaký ten problém, život informatika je jeden velký problém. A to je problém. Prokletí.

 

Koho by zajímalo, jak (nedokonale dokonale) vypadá jednoduchý překladač programovacího jazyka po dvou měsících informatické práce, mkrněte na github. Už je oficiálně odevzdán, takže jej, myslím, můžu veřejně uveřejnit.

 

Existuje 10 typů lidí …

Znáte ten starý známý ajťácký vtip? Myslím tento:

Existuje 10 typů lidí: ti, kteří rozumí binární soustavě a ti, kteří nerozumí.

A znáte také jeho upravenou variantu?

Existuje 10 typů lidí: ti, kteří rozumí trojkové soustavě, ti, kteří nerozumí a ti, kteří si mysleli, že toto je vtip o dvojkové soustavě.

Když se nad tím zamyslíte, jistě vás napadne, že tímto zdaleka nekončíme. Takovýchto vtipů může být vlastně docela dost. A to, přesně řečeno, nekonečně mnoho.

To je docela hodně, já vím. Ono i přečíst je všechny by nějaký ten čas zabralo. Nicméně, připravil jsem krátký seznam těch prvních:

Jen tyto dva

Prvních 5

Jak se píše v patičce stránky, počet vtipů, které chcete zobrazit, je dán parametrem stránky. Takže si ho můžete klidně změnit na téměř jakýkoliv (dobře, ve skutečnosti až do symbolických 64).

Vzorce, rovnice a výrazy přes internet? Pomocí mého Editoru rovnic Online!

Také už se vám někdy stalo, že po vás někdo chtěl, aby jste mu něco vysvětlili přes ICQ/facebook chat? Nějaký příklad, nebo tak něco?

Uplně vidím, jak mu tam píšete „a1 na2 + a2 na 2 / (a1 – a2) na2“, pak si uvědomíte chybu a doplníte „to a1 na2 + a2 na 2 mělo být taky v závorce“. Takhle s ním komunikujete pár desítek minut a hlava se vám div nezavaří při transformování z chatu do matematického zápisu a natož, aby jste uvažoval, co s ním a jak jej upravovat či počítat.






Tomu je nyní konec! (Fuj, zní to jak Horst Fuchs z Teleshoppingu, ale nemohu si pomoct ;-)).  Nyní přichází edrovonl, tedy Editor rovnic online, ve kterém si vcelku pohodlnně to, co jste předtím svému kolegovi posílali ručně přepíšete do speciálního jazyka (který není ninak těžký – velmi se podobá přirozenému jazyku) a vašemu kolegovi pouze pošlete odkaz na vámi zapsaný výraz/rovnici.






Jak snadné!

Tohle umí už jen Wolfram Alpha.

Nemusíte se bát, že by na vás byl edrovonl nedostačující. Je dimenzován pro potřeby jak těch nejjednodušších výrazů a rovnic (tak dobře, „měla babka čtyři jabka a dědoušek jen dvě“ edrovonl neumí :-)) tak až na úrověn základů vysokoškolské matematiky (operátory jako suma, limita, integrál, produkt, a podob.).

No a mě nezbývá nic jiného než vyvěsit odkaz na jeho spuštění:

 

Editor rovnic Online ZDE

Nejneužitečnější aplikace na světě

Na internetu se nachází spousty videí s takzvanými „naprosto zbytečnými“, „nejzbytečnějšími“, „nejneužitečnějšími“ či doslovně „nejméně použitelnými“ věcmi, jako je třeba tato:

Všechny tyto předměty mají stejnou funkci. Každý obsahuje nějaký vypínač, po jehož zapnutí se zařízení uvede do chodu a začne konat svou běžnou činnost. Jenže tou není nic jiného, než co nejrychleji onen vypínač znovu vypnout.

Když jsem to viděl poprvé, začal jsem s úžasem slintat, že takto geniální vynález musím mít. Ale nebyl čas, materiál, kapitál, podmínky a ani nějaká velká motivace – k čemu vám taky ta nejneužitečnější věc na světě taky bude, když vlastně nemá žádné užití, že?

Časem jsem však na tento magický předmět narazil znovu a zrovna jsem měl alespoň ten čas a hlavou mi problesklo: „Vždyť to půjde realizovat i softwarově!“.  A během pár vteřin jsem si zakládal html soubor a začal vzpomínat na html, css a jQerry (které jsem vlastně nikdy pořádně neuměl).

Hrál jsem si s tím asi 2 dny a tady je výsledek:

Nejneužitečnější aplikace online

A nebo v anglickém provedení:

The most unuselless app online