Přejít k navigační liště

Zdroják » JavaScript » Zkušenosti z vývoje WebShotteru

Zkušenosti z vývoje WebShotteru

Články JavaScript, Různé

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…

Než začnu psát o jednotlivých technologiích a záludnostech s nimi spojených, měli byste vědět jednu věc – WebShotter vznikal v Agiliu jako „technologický sandbox“, tj. nejen že jsme chtěli udělat službu jako takovou, ale i jsme si chtěli při jejím vývoji vyzkoušet různé technologie a postupy. Článek proto rozhodně není z kategorie „jaké nejlepší technologie zvolit pro implementaci služby typu WebShotter“, ale spíš „to a to jsme zvolili a tady jsou naše zkušenosti“. Pojďme tedy na to.

Tři hlavní části WebShotteru

WebShotter (pokud jste ještě neviděli, pro představu se můžete mrknout na nějaké demo nebo si přečíst úvodní blog post na DevBlogu) se skládá ze třech hlavních implementačních celků:

  1. Screenshotovací backend
  2. Webový frontend
  3. Komponenta zobrazující screenshoty v 3D efektu („time machine“)

Každý z nich je vytvořený v poměrně odlišné technologii (.NET, Node.js, CSS3 + JavaScript) a okolo je použito pár dalších věcí pro deployment, samotné hostování apod. K popisu je toho tedy poměrně dost, začneme webovým frontendem…

Node.js + Express + Jade

Webový frontend je udělaný v Node.js, což bylo kontroverzní rozhodnutí a v kombinaci s dalšími faktory nás poměrně dost zbrzdilo. Proč jsme si chtěli zkusit Node? Ze dvou hlavních důvodů:

  1. Pro naše další projekty je na klientovi zásadní JavaScript, proto jsme chtěli tuto technologii zkusit i na serveru.
  2. Pokud člověk sleduje dění ve světě softwarového vývoje, nelze Nodu upřít značnou pozornost, které se mu dostává, a chtěli jsme na vlastní kůži zkusit, zač je toho loket.

Jaká byla realita? Skutečně taková trochu kontroverzní. Napíšu svůj pohled na věc, který se může lišit nejen od vašeho, ale i od názoru mých kolegů :)

  • Systém modulů a balíčkovací systém npm je naprosto skvělý. Na čistě technické úrovni v podstatě k npm nemám žádné výhrady a třeba ve srovnání s NuGetem ze světa .NETu byla práce s npm daleko sympatičtější.
  • Ekosystém modulů je silnou i slabou stránkou současně. Na jednu stranu se web dělaný v Node.js plní jako nákupní košík v obchoďáku – chcete přihlašování přes Facebook a Google? npm install everyauth. Placení přes PayPal? npm install paynode a tak dále. Na druhou stranu pro většinu věcí existuje balíčků hned několik, většina z nich v oblíbené verzi 0.0.1 a téměř se dá spolehnout, že s libovolným modulem bude dřív nebo později nějaký problém. Celý ekosystém jako takový je určitě skvělá věc, jen mi zatím připadá poměrně nezralý.
  • JavaScript jako jazyk stále považuji za ne zcela vhodný pro větší aplikace. Během těch pár měsíců vývoje jsme se s ním relativně sžili, nicméně skoro jakýkoliv jiný jazyk by mi přišel lepší (C#, ale klidně i PHP). Problémem JavaScriptu je dle mého především to, že si různí vývojáři stejné věci řeší jinak (JavaScriptu chybějí některé obvyklé konstrukty a klíčová slova), nástroje a IDE mají problém s pochopením kódu, kvůli všudypřítomným callbackům se relativně špatně dohledávají chyby atd. Z mého současného pohledu je tedy JavaScript na serveru pro běžné weby tolerovatelný, ale rozhodně ne nějak excelentní. (Poznámka: Node aplikace jdou psát i v něčem jiném, např. v TypeScriptu, nicméně s tím zkušenost nemáme – WebShotter je napsaný v čistém JavaScriptu. Poznámka č. 2: mluvím skutečně o běžném webu, je možné, že Node.js je skvělý na realtime věci apod., což nehodnotím.)
  • Jako nástroj jsme používali převážně WebStorm, který nám po letmém srovnání vyšel jako nejlepší volba mezi dalšími IDE a editory. I tak je to ale spíš jednooký mezi slepými a IDE pro konvenčnější jazyky / ekosystémy jsou o poznání dál.

Pokud vás zajímá, jaké moduly WebShotter používá, jsou to tyto:

  • express – základ pro většinu Node.js webů. U takto fundamentálního modulu překvapilo, jak relativně problematický byl upgrade z jedné verze na druhou (nic nepřekonatelného, ale u takto malého projektu každé zdržení o den nebo dva nepotěšilo).
  • jade – šablonovací systém. Podle mého názoru ne zcela vhodný, protože k tvorbě HTML struktury používá signifikantní whitespace (nemám to příliš rád ani u programovacích jazyků, ale u hluboce zanořených hierarchických struktur HTML elementů je to reálný problém). Se šablonovacím jazykem jsme se moc nevybírali, Jade byla defaultní volba pro nový Express projekt a na první pohled to nevypadalo špatně, takže nemůžu posoudit, nakolik lepší nebo horší jsou alternativy.
  • everyauth – řeší nám přihlašování vlastním heslem, Facebook a Google účtem. S tímto modulem jsme řešili pár záhadných problémů, celkově je ale velmi působivé, kolik služeb třetích stran pro přihlašování podporuje.
  • moment – dobrá knihovna na práci s časem.
  • cron – spouští některé naplánované úlohy, u nás hlavně rozesílání mailů.
  • plus několik modulů na komunikaci s okolním světem (msnodesql pro komunikaci s databází, paynode pro PayPal, nodemailer pro posílání emailů apod.)

Můj celkový názor na Node.js? Kdybych stál na začátku projektu znovu a měl se svými současnými zkušenostmi rozhodnout, jakou technologii pro webový frontend použít, bylo by dost těžké poskládat argumenty, proč Node.js použít namísto tradičních serverových technologií (my bychom tíhli k ASP.NET, ale i PHP plus třeba Nette by patrně nad Nodem vyhrálo). Node.js je určitě na serveru zajímavá alternativa, ale pokud už člověk zná něco jiného, nevidím moc důvodů, proč to opouštět. Na druhou stranu, aspoň jeden projekt jsme si v tom „cool“ Nodu zkusili :)

.NET + Selenium

Snímky samotné fotí robot, což je exáč napsaný v .NETu a pravidelně spouštěný naplánovanými úlohami ve virtuální mašině. Jediná otázka byla, čím dělat samotné screenshoty, tj. jaký kousek kódu z .NETu spustit, aby výsledkem byl nějaký JPEG nebo PNG soubor uložený na disku. Zvažovali jsme následující možnosti:

Většinu z těchto věcí jsme vyzkoušeli, ale pro nás trochu překvapivě měla každá z nich větší nebo menší mouchy. Když si člověk fotí jeden konkrétní web, může třeba stačit něco jako wkhtmltopdf, ale ve chvíli, kdy začnete focení testovat na větším vzorku webů a cílem je vyfotit cokoliv, začíná se věc komplikovat. Tak například wkhtmltopdf neumí GIFy, komponenta WebBrowser se ukázala nedostatečně ovlivnitelná, PhantomJS neumí pluginový obsah, Watin fotí stránku po dílech a pak ji skládá do výsledného obrázku (problém pro animace), Selenium je pomalé a občas zabugované atd.

Takže co jsme nakonec použili? Po několika iteracích a prozkoumání skoro všech slepých uliček, které existovaly, na backendu běží Selenium doplněné o řadu podpůrných skriptů, které řeší jednak vzhled stránky samotné (určitá úprava před vyfocením, například schování scrollbarů), jednak určité technické problémy Selenia (někdy zůstane browser viset, ne vždy si po sobě uklidí dočasné soubory apod.) Browser, který zajišťuje vykreslování, je v našem případě Firefox.

Do vývoje robota šlo nakonec násobně více času, než jsme očekávali, ale jak jsem už zmiňoval, je rozdíl fotit jeden konkrétní web a nabízet univerzálně fungující službu. Byla to dobrá zkušenost.

Mimochodem, náhled se generuje taky bezprostředně při přidávání webu, a protože náš robot momentálně požadavky nezpracovává hned, ale ve frontě, museli jsme náhled na webu řešit jinak. Pokud se tedy dostanete na stránku /add-web, to, co vidíte, je ohackovaný iframe, který pouze vytváří dojem screenshotu. Chtěli jsme zde použít projekt html2canvas, ale ten nám nefungoval dobře. Zkrátka udělat screenshot webové stránky je pořád docela magie.

CSS3 transformace

Asi největší vychytávkou WebShotteru z uživatelského pohledu je procházení snímků v 3D efektu podobnému Time Machine na Mac OS. Screenshoty se samozřejmě daly uspořádat do nějaké běžné mřížky, jak je to obvyklé např. v galeriích fotek, nicméně 3D efekt jsme chtěli použít, pokud to jen trochu technicky půjde (a reakce prvních uživatelů potvrdily, že to byla dobrá volba).

Ačkoliv bych byl jako Flex / Flash vývojář schopný požadovaný efekt naimplementovat poměrně rychle, jasným zadáním bylo, že se to musí podařit v čistě webových technologiích, už třeba proto, aby se WebShotter v budoucnu dobře zobrazoval na tabletech a podobných zařízeních (technicky nám tam služba běží už dneska, ale zatím bez různých optimalizací, které budou pro dobré UX nutné). Otázka tedy zněla, půjde v současných technologiích udělat efekt Time Machine tak, aby nejen fungoval, ale byl i použitelně rychlý?

Zvažovali jsme tři přístupy k implementaci:

Vyloučit jsme hned za začátku museli jQuery animace (ty základní), které sice byly rychle hotové, ale také příliš pomalé. Implementace v Canvasu by nejspíš fungovala, a třeba jsme zvažovali, že použijeme Haxe, aby šel jeden kód zkompilovat jak pro web, tak pro Flash Player (dalo by nám to dobrý fallback pro starší browsery), ale nejrychlejší a pro web nejpřirozenější bylo nakonec použít CSS3 transformace doplněné rozumným množstvím JavaScriptu (řádově několik set řádků).

Implementace tak ve výsledku používá nejnovější prostředky dostupné na webu, což má za nepříjemný následek, že třeba Internet Explorer 9, stále aktuální verze, není plně podporována (stejně tak Chrome na Linuxu a trochu problematická je i Opera). Je to poměrně velký kompromis, ale šli jsme do něj, protože aspoň nějakou implementaci máme pro všechny browsery (když nejsou dostupné 3D transformace, použijeme pomalejší 2D, a když ani ty nejsou dostupné, obrázky se staticky napozicují a animace se nekonají) a do budoucna předpokládáme, že podpora 3D transformací bude rychle narůstat.

Windows Azure

Kompletně všechno hostujeme v microsoftím cloudu Windows Azure. Používáme tyto služby:

  • Virtual Machines (robot na dělání screenshotů)
  • Cloud Storage (vygenerované PNG soubory)
  • Cloud Service (frontend)
  • Azure SQL Database (databáze, do které přistupuje jak robot, tak webový frontend)
  • Azure Websites (administrační rozhraní)

Azure jsme zvolili z několika důvodů, pár racionálních i pár subjektivních. Především se nám líbilo, že v Azure jde hostovat skutečně všechno – soubory, databáze, weby, libovolné VM apod. Teoreticky přitom nezáleží, v jaké technologii člověk vyvíjí – Node.js aplikace jsou oficiálně podporované zcela stejně jako ASP.NET. Potom se mi subjektivně líbí, v jak jednoduchém balení Microsoft svůj cloud nabízí – management portál Azure jsem dokázal používat dřív, než bych se vůbec zorientoval v nabídce AWS, a vůbec celý ekosystém Azure se Microsoft snaží dělat rozumně „přístupně“. No a na závěr bylo důležité, že pokud člověk používá MS technologie, může startup přihlásit do programu BizSpark a v rámci něj má určitý objem Azure služeb zdarma.

Potud zní vše dobře, v praxi jsme bohužel měli smůlu, protože jsme WebShotter vyvíjeli zrovna v době, kdy záhadným, ale rovněž podstatným způsobem nefungoval oficiální microsoftí Node modul pro připojení k SQL databázi. Kdybychom WebShotter dělali o dva měsíce později, na problém bychom už nenarazili, ale takto nás bohužel řešení problémů kolem databáze stálo hodně času (nebyli jsme daleko od toho, abychom celý frontend přepsali do něčeho jiného, už na to radši ani nechci vzpomínat :). Narazili jsme i na pár dalších drobnějších problémů, například nefunkční přepínače PowerShell příkazů (pomocí nich děláme deployment) apod., ale to byly spíš drobnosti, nic nepřekonatelného.

Ačkoliv nám tedy některé aspekty Azure daly pocítit, proč u sebe stále mají nálepku „Preview“, celkově jsme s touto hostovací platformou spokojeni.

Další střípky

Na WebShotteru se použila řada dalších technologií, které zmíním už spíš letem světem, protože to byly spíš drobnosti nebo podpůrné záležitosti:

  • ASP.NET Dynamic Data – dobře posloužily pro rychlou tvorbu administrace (zvažovali jsme ještě Adminer, ale tam byl problém s rozchozením proti Azure SQL Serveru a radši jsme použili něco, co fungovalo hned).
  • Loggly – příjemná služba pro logování. Zvažovali jsme ještě Papertrail a Splunk Storm, ale s Loggly bylo nejjednodušší začít (samotné procházení logů bohužel nemají udělané moc komfortně, takže pro větší projekty bych určitě zvážil alternativy).
  • PowerShell – děláme pomocí něj build a deploy.
  • Git, BitBucket – BitBucket nabízí privátní repozitáře zdarma.
  • Google Apps – náš současný SMTP server, brzy přejdeme na SendGrid pro spolehlivější doručování.
  • JIRA – dělba práce nám velmi dobře fungovala přes JIRU. Ten software jsem ještě tak rok, dva zpátky doslova nenáviděl, ale ušel ohromný kus cesty a společně s GreenHopperem (virtuální nástěnka) je to překvapivě dobře použitelný a užitečný nástroj.

Pár netechnických poznámek závěrem

Na WebShotteru bylo pro mě osobně nejpoučnější, jak velký rozdíl může být mezi původním odhadem a reálným časem potřebným k implementaci. WebShotter měl být původně projekt na dvoudenní hackaton, ale když se má služba odladit a dotáhnout až do produkce, je to skutečně o něčem jiném. S WebShotterem se nám stalo, že jsme téměř od začátku měli „90 % hotovo“, ale těch zbývajících „deset“ procent ne a ne přijít. I dnes máme poměrně dlouhý backlog a řadu nápadů, co by se dalo vylepšit, ale produkt někdy ven musel a platí staré známé done is better than perfect.

Prosba závěrem – pokud WebShotter zkusíte používat a narazíte na něm na jakékoliv problémy, dejte nám prosím vědět (třeba na borekb@gmail.com nebo přes feedback form). V tomto článku jste viděli, že je služba poskládána skutečně z mnoha různých kostiček a zazlobit může každá. :)

Komentáře

Subscribe
Upozornit na
guest
35 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jakub Mrozek

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.

Tany

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.

Martin Kučera

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 :)

baggz
Dnes jsou například desítky služeb, které vám udělají screenshot přes API za naprosto směšný peníz.

Můžeš, prosím, jmenovat nějaké?

marek

dobry den p. bernard, zvazovali ste aj sluzbu http://www.screenshotmachine.com ? pri vacsich odberoch ponukame zaujimave zlavy.

marek

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.

liborse

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.

Martin Kučera

Vlastní CMS? Já zírám! Příslušníky tohoto mizejícího programátorského druhu jsem už neviděl řadu let!

Čelo

Každý vývojář by měl mít svůj hobby projekt… proč by to nemohlo být CMS?

Futrál

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.

Jakub Mrozek

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.

Jakub Mrozek

* oprava: prochází web jednou za čas

Futrál

No vidíte, další důvod, proč nemít zprasený web. Moje stránky se archivují přesně tak, jak vypadají ve skutečnosti :-)

espinosa_cz

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.

espinosa_cz

> 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?

espinosa_cz

> 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.crea­teElementNS(„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.getCon­text(„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.clas­ses[„@mozilla­.org/network/io-service;1“]
.getService(Com­ponents.inter­faces.nsIIOSer­vice);
var source = io.newURI(can­vas.toDataURL(mi­meType, „“), „UTF8“, null);
var target = io.newFileURI(file)

// prepare to save the canvas data
var persist = Components.clas­ses[„@mozilla­.org/embeddin­g/browser/nsWeb­BrowserPersis­t;1“]
.createInstan­ce(Components­.interfaces.nsI­WebBrowserPer­sist);

persist.persis­tFlags = Components.in­terfaces.nsIWeb­BrowserPersis­t.PERSIST_FLAG­S_REPLACE_EXIS­TING_FILES;
persist.persis­tFlags |= Components.in­terfaces.nsIWeb­BrowserPersis­t.PERSIST_FLAG­S_AUTODETECT_AP­PLY_CONVERSION;

// displays a download dialog (remove these 3 lines for silent download)
var xfer = Components.clas­ses[„@mozilla­.org/transfer;1“]
.createInstan­ce(Components­.interfaces.nsI­Transfer);
xfer.init(source, target, „“, null, null, null, persist);
persist.progres­sListener = xfer;

// save the canvas data to the file
persist.saveU­RI(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í.

Martin Hassman

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.

espinosa_cz

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 :)

Futrál

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…

HSN

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.

koudejak

To je opravdu hodne screenshotu webu. Muzu se zeptat, k cemu takova silenost slouzi? Samozrejme pokud to neni super prisne tajne :)

Čelo

Samozřejmě že to bude přísně tajné :) Co kdyby mu někdo ten nápad ukradl? :)

Ondřej Kučera

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á! :)

HSN

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.

HSN

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.

Futrál

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 dodavatelskood­běratelského vztahu.

HSN

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.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.