Na konci listopadu byla spuštěna v Česku vyvinutá služba WebShotter, která dělá navenek velmi jednoduchou věc – každý den vyfotí zadané URL a archiv screenshotů zpřístupňuje ve formě připomínající Time Machine z Mac OS. Přes jednoduchý vzhled se na implementací podílí poměrně hodně technologií a o zkušenostech s nimi se podělí Borek Bernard, autor a jeden z vývojářů celé služby. Předáváme slovo…
Mnoha lidem může znít věta v názvu článku „geniální nástroj“ nadneseně, ale já jsem, po téměř roce a půl každodenního používání, z Phabricatoru pořád jako na větvi. Phabricator jsem si jednoduše zamiloval.
Je v roce 2019 akceptovatelné, pokud není kód pokrytý testy? Pro velkou část vývojářů jsou testy pořád nutným zlem a pro manažery ztrátou času. Programátoři mají ale v rukou unikátní moc takovou praxi změnit a vyžadovat elementární standardy kvality.
IoT, vývoj hardware a JavaScript. To byla hlavní témata letošní konference Devel.cz 2019. Podívejte se na záznamy přednášek.
K Node.js
Díky za zajímavý článek. Služba se mi líbí a už jsem zvažoval, že bych ji používal:-)
Myslím si, že (místy) negativní zkušenost z výběru Node.js byla výraznou měrou způsobena tím, že jste Node.js použili poprvé a na projektu jste se ho učili. Pokud byste začali psát aplikaci třeba v .NET, aniž byste s ním měli předtím jakékoliv zkušenosti, vývoj by trval pravděpodobně výrazně pomaleji.
Jinak s poznámkami k Jade souhlasím, ze stejných důvodů preferuji jiné šablonovací systémy v Node.js.
Re: K Node.js
Seznamování s Nodem nás určitě zpomalilo, nicméně všechny body píšu s odstupem a nemyslím, že by to byly jen první dojmy.
Bylo by určitě zajímavé, kdybys k jednotlivým výhradám přidal svoje zkušenosti, které dost možná budou opačné než ty naše.
Re: K Node.js
Node je zvláštní, o tom žádná. Ona většina lidí neumí moc dobře myslet jinak, než v rámci klasických jazyků. Neznám zatím jiný nástroj, který dotáhl longliving procces, async a event driven do takové dokonalosti.
JS (v8) je luxusní sluha, ale snad nejhorší možný pán. Dobytek v tom klidně napíše něco, proti čemu se zdá inliner v Perlu jako krásně čitelný kód. Céčkař bude JS vždy nenávidět, a naopak. Oboje potřebuje úplně odlišný způsob myšlení.
Špatná debugovatelnost async kódu je způsobena spíše „špatným“ kódem, je jasné že debugovat callback callbacku v callbacku je šílenost. A do toho stavu se dostat není vůbec nutné. Stačí použít Async a prostě si člověk udělá frontu.
realizace záměru vs. technologické hračičkování
Na článku je vidět, jak to dopadá, když se nějakou službu rozhodnou spustit programátoři. Místo snahy o co nejrychlejší spuštění se utopí v technologickém hračičkování.
Dnes jsou například desítky služeb, které vám udělají screenshot přes API za naprosto směšný peníz.
Proto pozor! Jistě je hezké si všechno naprogramovat sám, ale ideální je jen poskládat hotové komponenty!
Většinou to dopadá tak, že super technologicky vymazlený web zkrachuje, zatímco jeho stupidní konkurent, který to splácal za odpoledne na Joomle, prosperuje :)
Re: realizace záměru vs. technologické hračičkování
Můžeš, prosím, jmenovat nějaké?
Re: realizace záměru vs. technologické hračičkování
Je to určitě dobrá poznámka a konkrétně u screenshotovacího backendu jsme zvažovali, jestli nepoužít nějakou stávající službu (odpověď pro Františka Hábu: mezi takové služby patří např. url2png nebo websnapr). Neudělali jsme to ne z důvodu, že jsme programátoři a musíme si všechno naprogramovat sami, ale:
1) Dopředu člověk neví, jestli bude náročnější vlastní implementace nebo integrace služby třetí strany, obojí má svoje rizika. Ze začátku se navíc nezdálo, že by rozchození nějakého vlastního screenshotovátka mělo být nějak obtížné (měli jsme svým způsobem smůlu, že nástroje typu Selenium nefungovaly tak, jak je inzerováno).
2) Když jsme koukali po konkrétních službách, byly pro naše účely buďto relativně drahé (třeba url2pgn snadno vyleze do tisícovek měsíčně) nebo funkčně nevyhovující (websnapr má např. omezení na velikost generovaných obrázků).
3) Screenshotování je jádro naší služby a obecně je riskantní takovou činnost svěřit třetí straně. Co když např. nějaký klient bude potřebovat fotit pluginový obsah, který služba třetí strany nezvládá? U vlastní implementace můžeme nové požadavky flexibilně řešit.
V našem případě tedy bylo jít do vlastní implementace vědomé rozhodnutí, ať už dobré nebo špatné :)
Re: realizace záměru vs. technologické hračičkování
dobry den p. bernard, zvazovali ste aj sluzbu http://www.screenshotmachine.com ? pri vacsich odberoch ponukame zaujimave zlavy.
Re: realizace záměru vs. technologické hračičkování
Dobrý den, konkrétně vaši službu jsme nezvažovali. Jak jsem ale odpovídal výše, od začátku jsme z různých důvodů inklinovali k vlastnímu řešení a nyní už pro nás přechod na SaaS mnoho smyslu nedává. Ale díky na upozornění na další službu z této oblasti.
Re: realizace záměru vs. technologické hračičkování
Jasne, rozumiem. BTW, tych „konkurencych API“ je viac. na http://snapcasa.com/ najdete (podla mna) kompletny zoznam „screenshotovacich API“. Osobne pokladam za najsilnejsich „hracov“ shrinktheweb a url2png. Rada na zaver: suhlasim s nazorom p. Martina Kučery. Aj ja som povodne planoval rozne technicke „prkotiny“ (ano, z pohladu zakaznika su to prkotiny) ale zo vsetkeho za najdolezitejsie povazujem: spustit to co najskor a pocuvat zakaznikov, t.j. implementovat to, co pozaduju a nie to, co si vyvojovy tim mysli, ze by mohli zakaznici ziadat. Prajem vam vela uspechov.
Re: realizace záměru vs. technologické hračičkování
Tento přístup se mi líbí a zdá se mi rozumný. V Joomle sice web naflákám za pár minut, ale jakmile třeba zákazník potřebuje něco specifického, tak joomla ztrácí svůj půvab a rychleji vyvinu něco sám. I proto mám vlastní redakční systém.
Re: realizace záměru vs. technologické hračičkování
Vlastní CMS? Já zírám! Příslušníky tohoto mizejícího programátorského druhu jsem už neviděl řadu let!
Re: realizace záměru vs. technologické hračičkování
Každý vývojář by měl mít svůj hobby projekt… proč by to nemohlo být CMS?
Archive.org
Ad „Do you own a blog, e-shop or any other website and would like to see how it evolves over time?“
Vím, že to muselo dát spoustu práce, ale mám pro vás špatnou zprávu – taková služba už tady je od roku 1996 – jmenuje se Wayback Machine (na Archive.org) a je dokonce ještě lepší – ukládá plné texty a jde v ní klikat na odkazy. Takže si člověk může zkopírovat část textu (není to jen obrázek) a taky se může podívat, jak kdysi vypadalo jeho HTML.
Re: Archive.org
Archive.org ale nedělá screenshoty každý den. ale +/- jednou za měsíc a také nejsou dostupné hned, ale až po nějaké době. Navíc neukládá větší obrázky.
Re: Archive.org
* oprava: prochází web jednou za čas
Re: Archive.org
Wayback Machine je chvályhodný počin a dokonce nám dobře posloužil při sestavování některých demo webů, ale zkuste si navštívit třeba http://web.archive.org/web/20110722012831/http://www.alza.cz/ a pak sám posuďte, jestli WebShotter skutečně nemůže mít pro někoho smysl :)
Re: Archive.org
No vidíte, další důvod, proč nemít zprasený web. Moje stránky se archivují přesně tak, jak vypadají ve skutečnosti :-)
Firefox Screenshoter
Překvapilo mě, jaké jste měli problémy s děláním snímků obrazovky.
K dělání screenshotů webů používám Screenshoter. Dlouhodobě a intenzivně k naprosté spokojenosti.
https://addons.mozilla.org/en-US/firefox/addon/screenshoter/
Po špatných zkušenostech s ukládáním webu, klasické Save As ve Firefoxu, dělám prakticky jen screenshoty. Každý online nákup nebo bankovní transakci si raději fotím. Obdoba online účtenky. A že weby leteckých společností jsou samá animace a reklama, zatím nebyl problém. Google Maps taky ne. Zatím mě nezklamal.
Nevíte co používají za technologie? Hádám JS a Firefox.
Před tím jsem používal Screengrab
https://addons.mozilla.org/en-US/firefox/addon/screengrab
..ale ten měl občas potíže s Java applety, což naštěstí reálně moc nevadilo.
Re: Firefox Screenshoter
Nějaký addon do Firefoxu jsme zvažovali taky, ale tam je zase výzva, jak takový kód zavolat zvenčí, z automatizovaného skriptu. Možná by to ve výsledku bylo jednoduché, ale nikdo z nás jsme s tím neměli zkušenosti, takže něco jako Selenium vypadalo jako lepší volba.
Re: Firefox Screenshoter
> Nějaký addon do Firefoxu jsme zvažovali taky, ale tam je zase výzva, jak takový kód zavolat zvenčí, z automatizovaného skriptu
Myslel jsem mu ten kód vybrat a upravit ho na plnohodnotný samostatný tool. Říkáte, že JavaScriptu slušně rozumíte. Určitě lepší než psát čistě vlastní.
Selenium je zase primárně testovací nástroj. Tam jste nemuseli upravit nic?
Re: Firefox Screenshoter
Pokud ten fotící kód vůbec je v JavaScriptu (mám pocit, že před časem jsem používal nějaký screenshotovací addon do Firefoxu a ten byl v Javě), tak i v tom případě si moc nedokážu představit, jak nebo co a kam by se mělo z addonu vykuchat. Naše představa spíš byla, rozchodit Firefox s nějakým takovým addonem a pak třeba přes nějaké API Firefoxu (existuje-li takové) ten addon k udělání screenshotu instruovat. Použití Selenia ale bylo skutečně jednodušší a tam se teoreticky skutečně nemusí nic upravovat – má API metodu pro uložení screenshotu do souboru.
Re: Firefox Screenshoter
> Pokud ten fotící kód vůbec je v JavaScriptu
Bezpečně je. Celý ten plugin jsou 2 kratší JS skripty a 2 XUL soubory.
Mrkněte na ff-overlay.js
Proč by proboha byla potřeba Java? Celá funkčnost je ve Firefoxu (Gecku). Stačí ji nějak inteligentně zavolat.
> ..jak nebo co a kam by se mělo z addonu vykuchat.
Udělal jsem to za vás. Je to v podstatě jedna klíčová metoda:
drawToCanvas : function(win, box) {
var canvas = document.createElementNS(„http://www.w3.org/1999/xhtml“, „html:canvas“);
canvas.style.width = box.width + „px“;
canvas.style.height = box.height + „px“;
canvas.width = box.width;
canvas.height = box.height;
var ctx = canvas.getContext(„2d“);
ctx.clearRect(0, 0, box.width, box.height);
ctx.save();
ctx.drawWindow(win, box.x, box.y, box.width, box.height, „rgba(0,0,0,0)“);
ctx.restore();
return canvas;
}
a
saveCanvas : function(canvas, file, mimeType) {
// create a data url from the canvas and then create URIs of the source
// and targets
var io = Components.classes[„@mozilla.org/network/io-service;1“]
.getService(Components.interfaces.nsIIOService);
var source = io.newURI(canvas.toDataURL(mimeType, „“), „UTF8“, null);
var target = io.newFileURI(file)
// prepare to save the canvas data
var persist = Components.classes[„@mozilla.org/embedding/browser/nsWebBrowserPersist;1“]
.createInstance(Components.interfaces.nsIWebBrowserPersist);
persist.persistFlags = Components.interfaces.nsIWebBrowserPersist.PERSIST_FLAGS_REPLACE_EXISTING_FILES;
persist.persistFlags |= Components.interfaces.nsIWebBrowserPersist.PERSIST_FLAGS_AUTODETECT_APPLY_CONVERSION;
// displays a download dialog (remove these 3 lines for silent download)
var xfer = Components.classes[„@mozilla.org/transfer;1“]
.createInstance(Components.interfaces.nsITransfer);
xfer.init(source, target, „“, null, null, null, persist);
persist.progressListener = xfer;
// save the canvas data to the file
persist.saveURI(source, null, null, null, null, file);
}
Podrobnosti:
https://developer.mozilla.org/en-US/docs/HTML/Canvas/Drawing_Graphics_with_Canvas#Rendering_Web_Content_Into_A_Canvas
Hádám že by to běželo dobře i s pouhým xulrunner
Napište si k tomu v JS minimalistické HTTP/REST rozhraní pro vzdálené volání a máte perfektní light weigth optimalizované řešení.
Re: Firefox Screenshoter
Tak Firefox to screenshotování přes canvasu nepodporovat vždy, dřívější verze onoho rozšíření to opravdu dělali přes Javu.
Re: Firefox Screenshoter
Potřebná funkcionalita je od Geko 1.9.1, které bylo použito poprvé ve Firefoxu 3.5, který vyšel někdy v červnu 2009. To mi přijde jako dostatečně dlouhá doba. Kdy že začali vyvíjet ten jejich WebShotter?
Odkazy:
https://developer.mozilla.org/en-US/docs/DOM/CanvasRenderingContext2D#drawWindow%28%29
http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29
http://en.wikipedia.org/wiki/Mozilla_Firefox_3.5
Čili renderování do canvasu je staré jako celé Node.js ;)
které si autoři tak nadšeně chtěli vyzkoušet.
Shodou okolností jsem začal screenshotovat přesně 25.11.2009, při koupi nového
mobilu, první screenshot stále ve svém elektronickém učetnictví mám. Co bylo před rokem 2009 skutečně netuším.
Mimochodem, podporu Javy pro browsery standardně neinstaluji, a to jsem Java programátor. Netěší se dobré pověsti co se týče bezpečnosti, bohužel.
Použité Selenium mi přijde jako kanón na vrabce. Ze Selenium WebDriver mám zkušenosti. Smíšené. Bugů je tam až až, je to stále bleeding edge technologie, založit na tom jádro on-line služby považuji za ještě šílenější nápad než použít Node.js.
Hehe, někdo mi srazil auru z 100% na 98%. Za dobrotu na žebrotu :)
Re: Firefox Screenshoter
WebShotter nemá „jádro“ a není na něčem fixně založený, je to služba jako celek a je možné, že backend šlo udělat nějak elegantněji. Každopádně jsem po zkušenostech skeptický k výrokům typu „stačilo těhle pár řádků a bylo by to“ – možné to je, ale takovou situaci jsme zkrátka zažili mnohokrát :)
Za kód každopádně díky, možná ho i v případě potřeby vyzkoušíme (ačkoliv ji zatím nemáme).
Re: Firefox Screenshoter
Díky, skvělý komentář – užitečnější než samotný článek a taky než všechny komentáře uživatele Hassman dohromady. Nechápu, proč se sem cpe a píše svoje bezduché poznámky…
Screenshotovaci sluzba pro inhouse pouziti
Potreboval bych sluzbu co udela z webstranky screenshot ale musela by bezet u mne, potrebuju zpracovavat hodne dat (desetimiliony stranek za den). Neprodavate to nekdo?
Vzdycky kdyz jsem si chtel nejakou sluzbu koupit pro inhouse pouziti tak mi ji neprodali. Nabizeli mi ze mi to rekneme za 60 tisic dolaru mesicne udelaji, pochopitelne bez zaruky kdyz to nepojede.
Re: Screenshotovaci sluzba pro inhouse pouziti
Radime, prosím ozvěte se mi na borekb@gmail.com.
Re: Screenshotovaci sluzba pro inhouse pouziti
To je opravdu hodne screenshotu webu. Muzu se zeptat, k cemu takova silenost slouzi? Samozrejme pokud to neni super prisne tajne :)
Re: Screenshotovaci sluzba pro inhouse pouziti
Samozřejmě že to bude přísně tajné :) Co kdyby mu někdo ten nápad ukradl? :)
Re: Screenshotovaci sluzba pro inhouse pouziti
Jak už tu několikrát v diskusi padlo, princip screenshotovače je poměrně primitivní záležitost, která spočívá ve spuštění instance browseru a jeho donucení k načtení stránky a uložení screenshotu.
Pomocí Selenia jde o trivialitu: http://stackoverflow.com/questions/3422262/take-a-screenshot-with-selenium-webdriver
Deset milionů za den je ale docela hodně. Pokud nechám 5 vteřin na načtení stránky a udělání screenshotu, stihnu jich za den pouhých 17 000! I kdybych to nechal běžet paralelně v deseti vláknech, pořád jsem řádově jinde než potřebujete.
I kdybyste vymyslel brutální optimalizaci screenshotovače, pod půl vteřiny na screenshot se těžko dostanete. Stále mi to vychází na maximálně jednotky milionů za den. Takže farma 100 počítačů? Ta cena $60 000, kterou vám nabízeli, je hodně podhodnocená! :)
Re: Screenshotovaci sluzba pro inhouse pouziti
Dostal jsem odpověď od lidí ze slovenska, který zde doporučovali v diskuzi, že jim to dělá zhruba 50 tisíc za den z jednoho počítače.
V naprosto ideálním případě bych potřeboval 80 mega denně abych měl všechny screenshoty čerstvý. Podle ceny řešení, kterou ještě neznám, to pak přizpůsobím rozpočtu a z ideálního stavu se spočítá řešení co si na sebe vydělá.
Počítače se dají sehnat u Amazonu hodně lacino, když jste velkoodběratel.
Re: Screenshotovaci sluzba pro inhouse pouziti
tak už mi to se Seleniem screenshotuje. Moc se to ale nepředře. No jsem zvědavej jakou mi nabídne Borek cenu za 1 screenshot a SLA.
Re: Screenshotovaci sluzba pro inhouse pouziti
S tím SLA opatrně – to má smysl u dodavatelů, kteří jsou schopní něco reálně zaručit a mají za sebou kapitál pro vykrytí případných průšvihů – tzn. firma velikosti např. I.CZ a větší, pak samozřejmě kolosy typu HP, IBM… U těch malých platí, že slíbit se dá cokoli, ale kde nic není, ani smrt nebere ;-)
V tomhle případě bych šel spíš do vlastního řešení (zdrojáky může dodat někdo jiný, ale prověřím si to a budu si to provozovat sám), případně do partnerství (více méně společný podnik, riziko i zisk sdílejí obě strany), ale ne do klasického dodavatelskoodběratelského vztahu.
Re: Screenshotovaci sluzba pro inhouse pouziti
Bez SLA nemá pro IT firmu cenu si kupovat saas od externí společnosti. Udělají si to sami a levněji.
Vývoj už mám hotovej. Zabralo to čtyři hodiny. Je to Selenium s integrací přes message broker -> Hadoop HDFS.