Archiv autora: Lukáš Francálek

Časté chyby v komunikaci: Potenciální vs. potencionální

Dalším jazykovým otazníkem na který často narážím, je rozdíl mezi slovy potenciální a potencionální. Mě vždy přišlo přirozenější a logičtější slovo potenciální. Proč? Protože znám slovo potenciál, ale slovo potencionál už ne.

V naprosté většině komunikací ale slyším resp. vidím výraz potencionální.

Jak je to tedy správně?

Po krátkém hledání na internetu můžete zjistit, že slovo potenciální je minimálně správnější, ne-li jediné správné. Je to dokonce často kladeno jako příklad častých chyb.

V podstatě všude, vč. pravidel českého pravopisu a slovníku spisovné češtiny, jsem našel potvrzení toho, že správně je potenciální. Nicméně v Internetové jazykové příručce je poznámka, že „lze použít i potencionální„. Smutným faktem je i to, že automatická kontrola pravopisu vás na tento nedostatek neupozorní. Slovo potencionál už vás ale napsat nenechá.

Výraz potencionální je jen nějaká zkomolenina.

Závěr

Stejně jako v případě sekundy vs. vteřiny bychom se mohli dohadovat, jestli je slovo potencionální (resp. vteřina) „povoleno“. Podle mě to ale nemá cenu. Správnější je jednoznačně potenciální (resp. sekunda) a nevidím důvod proč bojovat za další verze těchto slov.

Tip na další Časté chyby v komunikaci.

Časté chyby v komunikaci: CZ vs. CS

2 komentáře

Další chybou, na kterou často narážím, jsou chyby používání zkratek „CS“ a „CZ“. A protože jsem programátor webových aplikací, tak na to narážím často … hodně často. Nejčastěji je totiž tato chyba k vidění v URL webových stránek. Ale bohužel samozřejmě ne jen tam.

Tímto textem bych tedy chtěl apelovat především na webové vývojáře, ale i na lidi a firmy, vlastnící multijazyčné webové stránky a také na lidi, kteří dělají jazykové překlady.

Jak je to správně?

Tato chyba pravděpodobně vznikla, když byla dříve „CS“ Mezinárodní Poznávací Značka. To ale znamenalo Československo, takže to už od roku 1993 neplatí. Více jak dvacet let je podle mě dost času na přeučení. Takže:

CZ je označení státu (Česko) podle normy ISO 3166-1
CS, tedy přesněji řečeno cs, je označení jazyka (čeština) podle normy ISO 639–1

Na některých místech (např. v textu), je dobré si dávat pozor i na velikost písma. CZ se píše velkým a cs malým písmem. Takže věta „Udělej prosím CZ překlad těch titulků“ by měla znít spíše „Udělej prosím cs překlad těch titulků„.

Na některých místech (velké společnosti, někdy v URL a ve zdrojových kódech atp.), se uvádí pro označení jazyka i upřesnění státu. Pro češtinu to je cs-CZ a znamená to něco jako „česká čeština“. U češtiny to nemá moc smysl (protože češtinou se jinde než u nás nemluví), ale je to zavedeno pro jiné jazyky, které se používají ve více státech a v každém státu je trošku jiný dialekt. Určitě už jste slyšeli výraz „americká angličtina“ en-US nebo „britská angličtina“ en-GB.

To, že CZ a CS lidi mate, je vidět už na tom, že tento problém je pěkně vysvětlen i v FAQ české Wikipedie.

Kde je tedy problém?

Problém je v tom, že velmi často je např. v URL adrese multijazyčných webů zkratka „cz“ místo „cs“. Nemyslím národní doménu „.cz“, ale to „cz“ ZA prvním lomítkem.

Například adresa http://www.mujsuprweb.cz/cz/novinky.html by měla být spíše http://www.mujsuprweb.cz/cs/novinky.html.
„CZ“ v URL nemusí být ale špatně vždy. Třeba na http://www.htc.com/cz/ nebo http://www.apple.com/cz/ se vybírá stát a ne jazyk, takže CZ je v pořádku. Ale pokud jde o označení jazyka, správně by mělo být „cs“ nebo „cs-CZ“.

Nejde ale samozřejmě jen o webové adresy. Tato chyba je k dohledání téměř kdekoli, kde se může označení českého jazyka vyskytovat. Například pokud hledáte nějaké dabované video na YouTube. Narazíte tam většinou na „CZ dabing“, což neznamená „český dabing“, ale spíše „dabing Česko“. Na text „CS dabing“ mám 474 výsledků a na „CZ dabing“ mám 151 000 výsledků. Britové přece taky nehledají „GB dubbing“, ale „EN dubbing“. Proč? Protože nehledají stát, ale jazyk. To samé je u českých titulků k filmům, českým překladům her atp.

Závěr

Není to vyloženě ostuda, ale pokud si budete dělat multijazyčný web, dohlédněte na to, aby váš programátor používal správné označení jazyka. A pokud děláte překlady, pojmenujte je „cs“ a nebo ještě lépe „cs-CZ“, aby je našli všichni a zároveň bylo označení správně.

Takže pamatujte! CZ je stát, cs je jazyk!

Tip na další Časté chyby v komunikaci.

Časté chyby v komunikaci

Napsat komentář

Už dlouhé roky sleduji, jak lidé dělají často v komunikaci (ať už mluvené nebo psané) pořád dokola stejné chyby. Proto už se začínám spíše soustředit na to, kdo tyto chyby nedělá. O těch nejčastějších chybách jsem se rozhodl napsat nějaké texty.

Seznam článků

Tak co? Nepatříte do skupiny chybujících také? 🙂

Pokud se v článcích něčemu přiučíte nebo vám naopak články z nějakého důvodu vadí, budu rád, když mi zanecháte v komentářích nějakou zpětnou vazbu, abych věděl, jestli mám články psát dál nebo je nějak vylepšit atp. Nebo myslíte, že už ani nemá cenu se snažit komunikaci lidí napravit?

Časté chyby v komunikaci: Kalorie vs. kilokalorie

Napsat komentář

Poslední roky se ve všech médiích často omílá téma hubnutí a v této souvislosti se často používá i výraz kalorie. Kalorie je jednotka energie [značka je cal] a dá se s ní vyjádřit např. kolik energie vám dá nějaká potravina nebo kolik energie spalujete třeba při sportu.

Jedna kalorie ale vyjadřuje velmi malé množství energie a proto se často používají násobky kalorií. Nejčastěji se můžete setkat s kilokaloriemi [kcal] (1 kilokalorie má 1000 kalorií).

Kde je tedy problém?

Problém je v tom, že drtivá většina lidí (mluvím pouze o ČR – jak je to v jiných zemích nevím) používá POUZE termín kalorie. Co mě ale trápí nejvíc je to, že tento termín se používá opět i ve sdělovacích prostředcích, čímž tuto chybu šíří dál mezi lidi. Nejvíce mě překvapuje to, že špatné používání termínu kalorie slýchám i v pořadech o potravě nebo např. o hubnutí. Snad jedinou výjimkou je pořad Jste to, co jíte, kde jsou termíny používány správně (ale pouze doktory a specialisty na výživu). Když jsem ale viděl nějaký zahraniční pořad o hubnutí, člověk který pořad daboval, také nepoužíval termín kalorie správně.

Jak je to tedy správně?

Když se podíváte v podstatě na jakýkoli obal od nějaké potraviny, najdete tam množství energie, které spotřebováním potraviny získáte. Toto množství je ale uvedeno v kilokaloriích a ne v kaloriích, což poznáte podle značky [kcal]. Pokud tedy mluvíte o energii v konkrétních potravinách, používejte termín kilokalorie.

Závěr

Pokud obecně mluvíte o energii v potravinách, můžete používat termín kalorie. Např. věta „Od té doby si hlídám kalorie“ je v pořádku. Ale pokud mluvíte o energii v konkrétních potravinách, měli byste používat termín kilokalorie a nebo násobit hodnotu na obalu tisícem a pak můžete používat i výraz kalorie. Ale věta „Ty oplatky mají pět set padesát tisíc kalorií“ nezní tak dobře jako „Ty oplatky mají pět set padesát kilokalorií“.

Naučte sebe i ostatní ve vašem okolí používat termín kilokalorie, aby se tato častá a zbytečná chyba nešířila.

Tip na další Časté chyby v komunikaci.

Časté chyby v komunikaci: Sekunda vs. vteřina

19 komentářů

Kdysi dávno, když jsem chodil na základní školu, nás učitelka z matematiky upozornila, ať si dáváme pozor na rozdíl mezi sekundou a vteřinou. Od té doby v tom mám jasno. Všiml jsem si ale, že drtivá většina lidí v ČR (hádám tak 90% určitě – spíš více) v tom jasno nemá, resp. asi právě má, ale špatně.

VŠUDE slyším jen vteřiny. Venku, v rádiu, v televizi i na internetu. V hovoru mezi lidmi bych to i pochopil, ale ve sdělovacích prostředcích? Tam by se mělo mluvit správně, ne? A právě proto, že výraz sekunda není téměř nikde slyšet (nebo vidět), se to lidi nemají jak naučit.

Jaký je v tom rozdíl?

Sekunda je jednotka času! Jak všichni víme, Je to šedesátina minuty.
Vteřina je ale jednotka úhlu! To už ne všichni vědí – je to šedesátina úhlové minuty.

Jak to vzniklo?

Dříve byl výraz vteřina synonymem pro sekundu, ale od roku 1980 už je to jinak. Já myslím, že 36 let není málo času na naučení se tohoto rozdílu.

Znáte sportovní zpravodajství České televize „Branky, body, vteřiny„? Ten byl někdy v (nebo po) roce 1980 přejmenován na „Branky, body, sekundy„. Jenže pak se bohužel přejmenoval zpět na špatný název, což je podle mě ukázka velké chyby.

Závěr

Prosím vás, neučte tuto chybu ostatní lidi. Naučte se používat výraz sekunda a pokud možno, opravujte i ostatní. Třeba se lidé jednou naučí termín sekunda používat.

Proč? Protože není důvod mluvit špatně! To už byste mohli rovnou říkat „Oběhl jsem to za 20 litrů.“

Takže ještě jednou, pokud mluvíte o jednotce času, použijte to slovo s vulgárním koncem. Zapamatujte si to prosím a naučte to i ostatní 🙂

Tip na další Časté chyby v komunikaci.

Sdílení Google kalendáře pomocí iCal – chybějící Soukromá adresa iCal

Napsat komentář

Výborný e-mailový klient Mozilla Thunderbird má od verze 38 integrovaný doplněk Lightning, díky kterému, je jeho součástí i kalendář s podporou mnoha užitečných funkcí.

Krom vytváření místních kalendářů lze do Thunderbirdu přidat (přihlásit) i vzdálený kalendář a to i Google kalendář.

Propojení Google kalendáře s Thunderbirdem

Chcete-li propojit svůj Google kalendář s Thunderbirdem, budete potřebovat Soukromou adresu Google kalendáře. Tu získáte tak, že si otevřete Google kalendář a v levé části, se seznamem vytvořených kalendářů, kliknete na malou šipku u názvu toho kalendáře, který chcete do Thunderbirdu přidat a vyberete možnost Nastavení kalendáře.

Na stránce která se vám načte, byste měli vidět sekci Soukromá adresa. Pokud tam tuto sekci nevidíte, řešení najdete níže v tomto článku. V této sekci (v sekci Adresa kalendáře NE) klikněte na zelenou ikonku ICAL a zkopírujte si do schránky adresu, která vám vyskočí.

Dále stačí v Thunderbirdu přejít do sekce kalendáře a v levém sloupci se seznamem kalendářů kliknout pravým tlačítkem myši a vybrat možnost Nový kalendář. Dále vyberte možnost V síti a po potvrzení okna, vyberte možnost iCalendar (ICS). Do pole adresa vložte adresu, kterou jste získali v Google kalendáři. Hotovo.

Chybějící soukromá adresa

Pokud v Google kalendáři sekci se Soukromou adresou nevidíte, je potřeba ji povolit. Tuto možnost najdete v nastavení Google Apps ve správě domény.

Nemáte-li práva se přihlásit jako správce domény, budete muset o úpravu požádat někoho, kdo tato práva má.

Jako správce přejděte do správy domény (po přihlášení jako správce, najdete vpravo nahoře pod ikonou jakési tabulky ikonu Správa) a tam přejděte do nastavení Google Apps (opět vpravo nahoře pod ikonou se třemi tečkami – odkaz Nastavení). Poté klikněte v sekci Nastavení vašich aplikací -> Kalendář na odkaz Nová administrátorská konzole (tento krok časem asi odpadne). V konzole, v sekci Nastavení sdílení, vyberte položku Sdílet všechny informace a umožnit správu kalendářů a změnu uložte.

Od teď (resp. od příštího přihlášení) by měli mít všichni uživatelé domény v kalendáři sekci Soukromá adresa.

Reklamace pevného disku Western Digital v Německu

2 komentáře

Před časem mě můj NAS box Synology DS710+ upozornil, že jeden z disků (Western Digital (dále jen WD) model WD2003FYYS-02W0B0) má vadné sektory. Disk byl stále v pětileté záruce, takže jsem kontaktoval prodejce, že bych disk rád vyměnil. Ten mě však informoval, že svůj disk musím reklamovat přímo u výrobce – tedy ve Western Digital.

Po krátkém zjišťování jsem zjistil, že budu muset disk skutečně reklamovat u výrobce, který má ale sídlo v Německu. Dále jsem zjistil, že tento problém neřeším jako první, ale už více lidí se na reklamaci WD disků na internetu informovalo.

Informace existují

Bohužel až PO vyřešení své reklamace jsem našel službu externireklamace.cz, která by měla s reklamací pomoci (vyřešit za vás). Sice už při letmém prohlédnutí webu jsem narážel na drobné nevýhody této služby (před mým postupem), ale je možné, že výhod je více. Takže pokud potřebujete reklamovat nějaký hardware touto službou podporovaný, můžete zkusit i ji. Pokud se rozhodnete službu vyzkoušet, budu rád, když v komentářích napíšete své zkušenosti.

Dále jsem našel i sérii článků, popisující můj případ reklamace:

Články jsem bohužel našel rovněž až PO vyřešení reklamace své, takže jsem to celé nečetl, ale co jsem letmo viděl, tak zkušenosti má autor článků podobné jako já, až na odeslání balíku do Německa, které jsem myslím vyřešil lépe.

Přesto tu popíši i svůj případ – třeba to někomu pomůže…

Jak doručit disk do Německa?

To byl největší problém. Balík by se dal poslat Českou poštou, ale podle elektronické kalkulačky by zásilka včetně pojištění stála cca 550,- Kč. Na internetu jsem sice našel zmínky, že to lidi stálo kolem 200,- Kč, ale „zkoušet“ se mi to nechtělo. Museli by mi to evidovat ne jako balík, ale jako psaní a ještě k tomu bez pojištění.

Cena mi přišla dost vysoká, takže jsem doufal, že cena nějaké jiné zásilkové služby typu DPD, PPL, DHL atd. bude lepší. Nebyla – ceny se různí, ale nic výrazně výhodnějšího jsem nenašel.

Při hledání jsem ale narazil i na službu zaslat.cz, která mi na první pohled díky přehlednému a jednoduchému webu padla do oka.

Jak to funguje? Maximálně jednoduše 😉 Vyplníte informace o místu vyzvednutí (můj domov), místu doručení (WD v Německu), pár informací o balíku (rozměry, hmotnost a pojištění) a po odeslání formuláře vám web vyplivne datum doručení a cenu a co je hlavní, dobrou cenu! Pokud s datem doručení a cenou souhlasíte, stačí objednávku potvrdit, zaplatit převodem (asi to jde i hotově, ale v době kdy jsem službu potřeboval já, tam byla (prý z technických důvodů) možnost pouze převodem). Služba zaslat.cz samotnou dopravu neřeší, pouze vám zajistí přepravu pomocí jiné služby (v mém případě GLS).

A jak je to s trasování zásilky? Dobře – na webu můžete sledovat jak je doručení daleko. A jak je to s pojištěním? Taky dobře – každý balík má pojištění do 6.000,- Kč v ceně a tam jsem se (ač docela těsně) vlezl i já. A kolik to tedy celé stálo? 249,- Kč. Možná se to dá sehnat i levněji, ale mě tato cena přišla dostatečně nízká na to, abych dál neztrácel čas hledáním jiných služeb.

Jak to celé probíhalo?

Web podpory firmy Western Digital je v češtině a je poměrně přehledný, takže vytvoření žádosti o reklamaci nebyl problém.

Jestli je váš disk skutečně v záruce, tak je potřeba se nejdříve na webu podpory zaregistrovat. Poté si zaregistrujte svůj produkt / disk a pak můžete jít na vytvoření RMA, což není nic jiného než žádost o reklamaci. Na detailu stránky RMA pak můžete vidět postup reklamace.

Po vytvoření RMA vložte disk do antistatického sáčku (ten, ve kterém disk dostanete v obchodě) a KVALITNĚ disk zabalte do dostatečně vyplněné (např. bublinkovou fólií) pevné kartonové krabice. Co by v balíku mělo být a jak by měl a neměl být zabalen najdete v premaileru, který vám po vytvoření RMA přijde e-mailem.

Jak budete mít balík hotový, vytiskněte si RMA štítek, na který najdete odkaz také v premaileru. Můžete si nadepsat adresy odesilatele a příjemce sami a pak jen vytisknout 3x malou verzi RMA štítku NEBO vytisknout velkou verzi RMA štítku i s adresami a k tomu ještě dvě malé verze RMA štítku a ty nalepit na další dvě strany balíku (to jsem udělal já). RMA štítek musí být nalepen na třech stranách krabice! Hotovo – je čas balík odeslat…

V pátek 21. 11. jsem se tedy rozhodl službu zaslat.cz zkusit a vytvořil objednávku. Po zaplacení 249,- Kč převodem jsem čekal na úterý 25. 11., kdy si měl pro balík přijet kurýr. Toho dne dopoledne se u mě skutečně zastavil kurýr a to od společnosti GLS. Vysvětlil jsem mu, že krabici potřebuji polepenou tak jak je (3x RMA štítek). S požadavkem neměl problém, svůj štítek nalepil na spodní stranu balíku, dostal jsem potvrzení o převzetí a za dvě minuty zmizel v mlze 🙂

Balík měl do Německa dorazit ve čtvrtek a to se také stalo. Ve čtvrtek jsem viděl na webu zaslat.cz stav „doručeno“.

Poté začalo čekání, než se na webu WD u mé RMA objevila informace, že byl balík přijat. To se stalo až 3. 12. Den na to už jsem u RMA viděl, že mi WD zasílá nový disk. Nešlo o stejný typ, ale o novější SATA III verzi toho mého – nic, co by mi vadilo 🙂

Doručení ke mně domů trvalo 2x tak dlouho jak cesta tam, ale nakonec se povedlo. Doručení proběhlo službou UPS. V pátek jsem na webu UPS viděl, že můj balík evidují. V pondělí jsem viděl pohyb v rámci Německa a v úterý v rámci ČR. Ve středu balík dorazil (bydlím na jižní Moravě, takže tam byl asi den navíc). Zabalen byl jednoduše, ale dostatečně. Disk už v RAIDu sviští se svým novým kamarádem v mém Synology 🙂

Závěr a harmonogram celé reklamace

Celá reklamace trvala od OBJEDNÁNÍ odeslání vadného disku do přijetí nového disku celkem 19 dnů (13 pracovních). Veškeré náklady jsou pouze těch 249,- Kč za doručení balíku do Německa. Zpět do ČR to šlo z kapsy Western Digital.

Sice je to asi standard, ale co mě trošku mrzí je to, že na nový disk jsem nedostal novou pětiletou nebo alespoň dvouletou záruční lhůtu. Konec záruky nového disku se rovná konci záruky starého disku. Takže pokud se disk třeba za rok úplně poškodí, budu litovat, že jsem starý reklamoval, protože ten alespoň fungoval (měl pouze vadné sektory).

Pro přehlednost ještě uvádím celkový harmonogram celé reklamace:

pátek 21. 11. vytvoření objednávky (zaslat.cz)
úterý 25. 11. vyzvednutí balíku (GLS)
čtvrtek 27. 11. doručení příjemci
středa 3. 12. přijetí disku (dle RMA)
čtvrtek 4. 12. odeslání nového disku (dle RMA)
pátek 5. 12. převzetí zásilky (UPS)
pondělí 8. 12. pohyb balíku v rámci Německa
úterý 9. 12. pohyb balíku v rámci ČR
středa 10. 12. doručení balíku

Máte-li podobné nebo naopak rozdílné zkušenosti nebo máte-li tipy na další zásilkové služby popř. na co si dát pozor, budu rád za vaše komentáře 😉

Systém pro správu verzí GIT na Synology DSM

4 komentáře

Od doby, co vlastním Synology server (dříve DS207+, nyní DS710+), jsem na něm chtěl mít verzovací systém. Dříve Subversion, později GIT.

Dříve jsem našel na Internetu návody, jak na své DS207 Subversion zprovoznit, ale byl to docela drsný zásah do systému a ne každý by to zvládl nebo si do toho troufl. Navíc šlo o neoficiální cestu a případnou škodu bych nemohl samozřejmě reklamovat. Jednou jsem si dokonce svůj nynější DS 710+ skutečně znefunkčnil a od podpory, která mi s problémem pomohla, jsem dostal „vynadáno“, že tam byl neoficiální software (čímž určitě mysleli SVN).
Od té doby jsem raději takovéto metody instalace nepraktikoval 😀

Nyní ale můžete verzovací systémy GIT a Subversion najít v Centru balíčků přímo v Synology DSM. Systémy sice můžete jedním klikem nainstalovat, ale ne zprovoznit. Pro zprovoznění resp. vytvoření repozitáře bohužel není žádné GUI, takže budete muset sáhnout po SSH. Já jsem si na svůj DS710+ právě úspěšně doinstaloval GIT, tak si dovolím bodově popsat jak na to. SVN jsem nezkoušel, ale je možné, že postup bude podobný.

Jak na to

Otevřete si DSM svého Synology a spusťte Centrum balíčků. Tam najděte položku GIT Server a tu nainstalujte.

Pomocí okna Ovládací panel > Sdílená složka si vytvořte novou složku. Jestli chcete kořenovou složku pro více repozitářů nebo složku jednoho repozitáře už je na vás. Já jsem si vytvořil složku jediného repozitáře (víc jich potřebovat nebudu). V mém případě je to složka git. Zvolte si nastavení složky, jaké vám vyhovuje (já jsem si ji např. skryl v části Místa v síti a zakázal funkci koše).

Pokud nemáte vytvořeného uživatele, se kterým se budete chtít do repozitáře připojovat, učiňte tak v části Ovládací panel -> Uživatel. Do adresáře, který jste si v předchozím kroku vytvořili, novému uživateli nemusíte povolovat přístup. Já jsem uživatele nezakládal, protože chci používat svůj účet, který používám k připojení k Synology serveru.
Nyní spusťte dříve nainstalovaný balíček Git Server a tam vyberte ty uživatele, kterým chcete přístup do systému GIT povolit.

Pokud nemáte povolen přístup k serveru přes SSH, povolte jej: Ovládací panel -> Terminál -> Povolit službu SSH.

Nyní jdeme vytvořit repozitář. K tomu se ale budeme muset připojit k serveru pomocí SSH a to s administrátorským účtem. Učiňte tak (pokud jste na Windows, použijte třeba Putty). Po přihlášení přejděte do dříve vytvořeného adresáře. V mém případě:

cd /volume1/git

pokud chcete vytvořit více repozitářů, můžete si tu vytvořit podadresářů kolik chcete, např:

mkdir repo1

Nyní si v každém adresáři (tedy: cd repo1), kde chcete mít repozitář spusťte příkaz pro inicializaci repozitáře a nastavení práv:

git --bare init chmod -R g+ws * chgrp -R users *

A to je vše! 🙂 Teď máte vytvořen repozitář (nebo repozitáře), ke kterému se můžete připojovat pomocí vybraných uživatelů. U klienta nastavte pro synchronizaci následující formát adresy:

ssh://{uzivatel}@{IP_serveru_nebo_hostname}/{absolutni_cesta_do_repozitare}

Já jsem si navíc do rootu vytvořil symlink git, který ukazuje na můj repozitář /volume1/git/

ln -s /volume1/git/ git

Takže místo adresy ssh://lukas@mujsyno.cz/volume1/git mohu použít adresu ssh://lukas@mujsyno.cz/git 😉

Při pokusu naklonování u klienta budete vyzváni k zadání hesla uživatele. Pokud chcete GIT provozovat na Windows, určitě doporučuji GIT pro Windows v kombinaci s Tortoise GIT.

Snad se vám podařilo dle mého návodu repozitář nebo repozitáře vytvořit. Pokud ne, můžete mi napsat v komentářích a pokusím se pomoci.

Obnovení Facebook cache, náhled odkazu pro Facebook a Google

1 komentář

Při vývoji webu často potřebuji vědět, jak bude daná stránka nového webu vypadat, pokud ji nasdílím na Facebooku. Nejjednodušším řešením je samozřejmě vložit požadovaný odkaz do textového pole určeného k založení nového postu na Facebooku a počkat, než si Facebook načte data a náhled zobrazí. Tato varianta je sice skutečně nejjednodušší, ovšem jen na jedno použití.

K urychlení načítání informací o nějakém odkazu používá Facebook cache. To funguje tak, že pokud někdo vloží do postu na Facebooku odkaz, Facebook se podívá, jestli už informace o odkazu (titulek, popis a náhledový obrázek) nemá uložen ve své interní cache a pokud ano, použije tato data pro zobrazení náhledu. Pokud potřebná data nemá, zjistí si je přímo z uvedeného odkazu a zároveň si je do té cache uloží, aby je mohl použít příště.

Z výše uvedeného faktu plyne, že pokud si vytvořím na Facebooku náhled, poté na webu udělám nějaké změny (např. pozměním popis stránky) a půjdu opět zkusit jak vypadá náhled, načtou se mi stará data a poslední změnu v náhledu neuvidím.

Z tohoto problému vás může dostat Object Debugger. Pokud po provedené změně vložíte odkaz na stránku do tohoto nástroje, můžete si zkontrolovat jaká data stránka obsahuje a hlavně tento nástroj obnoví cache Facebooku, takže při příštím vytvoření náhledu, už obsahuje aktuální data. Tento krok je samozřejmě nutné udělat po každé změně, která může náhled ovlivnit.

Podobný nástroj vlastní i Google. Jde o Google Structured Data Testing Tool, který rovnou vytváří i vlastní náhled toho, jak bude vypadat web ve výsledcích vyhledávání.

Pozn.: Jakou má životnost cache Facebooku a Googlu bohužel netuším.

Redirect Checker, kontrola přesměrování URL adres

Napsat komentář

Služba Redirect Checker slouží ke kontrole přesměrování URL adres. Je určena spíše pokročilejším uživatelům Internetu nebo vývojářům software, ale využít ji může i běžný uživatel. K čemu je to tedy dobré?

Dostanete od někoho URL z nějakého zkracovače adres nebo jinak „podezřelou“ adresu a chcete před navštívením odkazu zjistit, kam směřuje.
Potřebujete zjistit, jestli adresa kterou máte, je koncová nebo po jejím navštívení dojde k přesměrování na jinou adresu (třeba i např. seznam.cz -> www.seznam.cz). Proč např. na svém webu uvádět odkazy s přesměrováním, když můžete uvádět odkazy cílové (navštívení koncové adresy je samozřejmě rychlejší).
Jste programátor nebo pokročilejší uživatel Internetu a chcete z nějakého důvodu zjistit jakou HTTP odpověď nějaká adresa vrací (např. vámi naprogramovaná aplikace).
Jste autorem nějaké webové aplikace nebo programu, do kterého uživatelé vkládají nějaké URL adresy a chcete mít jistotu, že např. adresa existuje / vrací správnou HTTP hlavičku (HTTP/1.1 200 OK) nebo zkrátka potřebujete získat cílovou adresu.
Podobných využití by se dalo najít více, ale myslím, že takto by to mohlo stačit 🙂

Pokud vás napadá, že taková služba už asi bude existovat, tak máte pravdu. Podobné služby existují a není jich málo. Každá z těch, které jsem našel, však měla nějakou vadu na kráse. Jedna kontrolovala jen jedno přesměrování, druhá neuměla rozpoznat meta-refresh, další vypadala dobře, ale nebylo možné ji použít jinak než ručně a nevracela nic než koncovou URL atp.

Redirect Checker nabízí tyto možnosti:

Sleduje celou cestu až ke koncové URL
Podporuje meta-refresh element
Podporuje IDN (tedy adresy se speciálními znaky jako např.: http://háčkyčárky.cz)
Umožňuje uživateli pozměnit výchozí nastavení. Například změna jména User-Agenta, ignorování meta tagu refresh, omezení kontroly na určitý počet přesměrování atp.
Nevrací pouze koncovou URL adresu, ale poměrně detailní informace o celé cestě přesměrování včetně HTTP hlaviček a curl_getinfo() dat.
Tato data může vracet krom přehledného webového prostředí i v různých formátech (momentálně to je JSON formát, serializované PHP pole a XML dokument).
Krom ruční kontroly nabízí i API URL, vracející potřebná data pro použití ve vašich programech. K vygenerování API URL je k dispozici webové rozhraní, kde si můžete potřebná nastavení „naklikat“.

Služba má samozřejmě i pár stinných stránek. Není na výkonném serveru, takže odezva může při vytížení serveru trvat déle. Není nijak duplikovaná, takže při pádu serveru bude služba nedostupná. Navíc je to „novorozeně“, takže nepochybně obsahuje nějaké skryté chyby, které se budu snažit v následujících týdnech odhalit.
V plánu je několik dalších vylepšení, které zatím nebudu prozrazovat. To je ale v plánu až bude služba pořádně odladěna.

Koho Redirect Checker zaujal, může jeho vývoj sledovat formou luštění otřesné angličtiny na těchto sociálních sítích:

Službu jsem udělal pro své potřeby, ale je v ní dost úsilí, takže budu rád, když ji využije i kdokoli jiný. Proto vás prosím o pomoc s šířením povědomí, že tato služba existuje. Každý lajk, Google +1, Tweet a sdílení na kterékoli sociální síti mi pomůže a potěší. Děkuji.

Máte-li tipy na vylepšení nebo nálezy chyb, můžete mi je psát do komentářů k tomuto článku, na výše uvedenou Facebook stránku nebo na mail, který najdete na adrese služby v zápatí.

Pozn.: Ptáte-li se, jestli bude tato služba zpoplatněna, tak nevím, ale určitě ne její ruční použití. V nejhorším případě využití přes API a to jen v případě silného vytížení serveru (např. aby si služba vydělala na lepší „železo“).