Správce schránky – Ditto Clipboard manager

Prozradím vám další střípek ze své mozaiky efektivity. Pokud vám následující věty jsou povědomé, tak je článek určen přímo pro vás:

Tyjo, vždyť jsem si to kopíroval, jaktože mi to nejde vložit?

Tyjo, tohle jsem si před chvílí někam kopíroval, kde to teď budu sakra hledat?

Pokud používáte schránku (CTRL+C, CTRL+V) na ukládání něčeho, co budete potřebovat až za chvilku, určitě se vám stalo, že jste si to omylem přepsali dalším kopírováním. Nebo když kopírujete víc údajů z jednoho místa do druhého, tak pořád musíte přepínat okna. Říkáte si, že by bylo fajn, kdyby si to pamatovalo víc věcí, co tam uložíte. A ono může…

Windows to neumí samy od sebe, je potřeba nainstalovat aplikaci Ditto (alternativně můžete vyzkoušet ClipX nebo CLCL, ale oba vypadají už dál nerozvíjené).

Ditto

Ditto je jednoduchá aplikace, která sleduje, co vložíte do schránky a pomocí klávesové zkratky vám umožní vložit i věci, které už z běžné schránky zmizely.

  1. Nejdříve si Ditto stáhněte (odkaz Download) a nainstalujte.
  2. Potom přejděte do nastavení a v záložce „General“ zaškrtněte „Start Ditto on System Startup“.
  3. Dále v záložce „Keyboard Shortcuts“ si klikněte do pole „Activate Ditto“ a zmáčkněte levý Alt + C (jako klávesovou zkratku).
  4. Ditto teď bude sledovat schránku a pamatovat si, co jste tam vložili.
  5. Až budete potřebovat něco, co jste měli v běžné schránce, ale už nemáte, tak stačí zmáčknout levý Alt + C a vybrat si:

Používáte Ditto? Nebo jiný clipboard manager? Nebo nic…a proč? Podělte se v komentářích!

Jak na levnější kontaktní čočky od VašeČočky díky Heuréce?

Když jsem začal nosit kontaktní čočky, tak jsem je nejdříve nakupoval u oční doktorky za 1 200 Kč na půl roku. Pak jsem zjistil, že se ty stejné dají kupovat na internetu skoro za polovinu, což je docela velká úspora. Od začátku jsem nakupoval na VašeČocky.cz, kteří zboží doručovali hodně rychle a bez problémů. (Teď už čočky nenosím, ale o tom budu psát až někdy jindy).

Náhodou jsem pak zjistil, že na Heuréce nabízejí stejné zboží za nižší cenu, která se vám aktivuje při prokliku z Heuréky.

Základní cena čoček je 539 Kč (proklik přímo na zboží):

Na Heuréce je mají za 487 Kč (proklik na Heuréku):

A pokud se z Heuréky prokliknete, tak jsou za tu cenu i na eshopu:

(dřív ten rozdíl býval třeba 649 → 530 Kč, což při dvou baleních už je docela dost).

Obdobně to funguje u roztoků na čočky, které to zlevní z 679 na 575 Kč.

Takže pokud jsem objednával dvoje čočky a roztoky, tak se dalo ušetřit tři stovky, což je docela příjemné (kdo vám to dá). Na jednu stranu jsem chápal, že pro získávání nových zákazníků musí bojovat cenou na Heuréce. Na druhou stranu to je celkem podraz na stálé zákazníky, kteří jdou rovnou k nim na web.

Pokud jim chcete ušetřit za prokliky z Heuréky, tak si stačí nastavit cookie ps_id=1 (Heuréka). Pro Zboží je to ps_id=2 (takže je možné, že některé věci mají ještě s rozdílnou cenou podle srovnávače, ale to už se mi zkoumat nechtělo).

VašeČocky určitě nejsou jediní, kteří cenově segmentují návštěvnost z Heuréky/Zboží. Víte o nějakých dalších?

Ruším účet u mBank

(proti mBank nic nemám, dotlačili do ČR módu účtů zadarmo, jen mi už jejich podmínky nevyhovují)

V mBank jsem byl relativně early-adopter – přišla do ČR v listopadu 2007, účet jsem si zřizoval v březnu 2008. Důvodem pro mBank pro mě bylo mít druhý účet s menším zůstatkem, ke kterému budu mít kartu na placení online. A v tu dobu tam myslím byl i výhodný spořící. Zároveň jsem ji různě doporučoval jako alternativu ke „starým“ bankám.

mBank byla první, která v ČR měla předčíslí účtu, takže třeba ještě na gymplu měla paní provozní v jídelně problém ho nastavit pro inkaso, protože na předčíslí neměla kolonku :-) (i když to byl asi ještě tátův účet)

mBank ze začátku byla cool banka, brzy zavedla bezkontaktní karty apod. Ale pak postupně zhoršili podmínky spořícího účtu (pro udržení úrokové míry byly nějaké další podmínky a bylo to celé nějaké složitější). Pak zrušili 3 výběry zdarma z jakéhokoliv bankomatu a zavedli je zdarma jen při dosažení objemu plateb kartou v daném měsíci. Jenže u těch plateb kartou nezáleží na tom, kdy byly provedeny, ale kdy byly zaúčtovány (což u off-line bezkontaktních plateb může být klidně i týden nebo dva), takže na nějaké sledování to je zbytečně složité. Třešničkou už byl nový e-banking, který mi moc nesedl.

od března 2015 mBank zavádí poplatek za vedení karty, pokud tou kartou nebude měsíčně zaplaceno (a zaúčtováno!) alespoň za 500 Kč. Což sice není nijak závratný objem, ale je to takové to, že když s ní budete hodně platit a pak měsíc ne, tak dostanete „pokutu“.

Na mBank se mi dříve líbilo, že nemusím řešit, jestli mi při běžných činnostech (převody, trvalé příkazy, inkasa, …) nenaúčtují nějaký poplatek, což teď už neplatí. A abych to nemusel řešit, tak účet zruším a přejdu k Fio – stejně jsem si tam chtěl účet zřídit, tak mě tohle je pošťouchnulo. (účet ve Fio jsem si dnes zřídil na pobočce za 15 minut)

Pokud mBanku moc nepoužíváte, ale nechcete rovnou ručit celý účet, tak by mělo stačit zrušit kartu v ebankingu. Ale než účet nechat ladem, tak ho doporučuji spíš zrušit úplně (kdo ví, třeba zavedou poplatek za nepoužívání účtu).

Na webu info o rušení účtu nemají, takže jsem se musel doptat na Twitteru:

Jsem zvědavý, jestli tímto mBank odradí klienty s málo používanými účty a ti je budou rušit. Protože klienti mBank už minimálně jednou ukázali, že změna banky pro ně není problém.

A co vy? Také ještě máte účet u mBank nebo už někde jinde?

Checking a custom coding standard with PHP_CodeSniffer

PHP_CodeSniffer is a tool for checking source code compliance with a defined coding standard. There are some predefined standards (PEAR, Zend, PSR1, PSR2, etc.), but the true power of PHP_CodeSniffer lies in the possibility of defining custom standards.

We've been using PHPCS on Shopio for a long time, but we've utilized just the Zend coding standard provided within the PHPCS distribution. I recently found some time to dig deeper into PHPCS and I played a lot with custom standards.

How can I define a custom PHPCS standard?

A custom standard is just an XML file (usually located in the project directory) which imports rules that already exist in PHPCS. It's usually better to import an existing standard and customize it with additional rules. And if there are some rules that you don't like, you can disable them (or reconfigure their parameters). The following example shows a custom ruleset that just imports the Zend coding standard:

<?xml version="1.0"?>
<ruleset name="My Custom Standard">
    <rule ref="Zend" />
</ruleset>

Using the custom ruleset is also simple, as you just need to pass the path to the XML file with the custom standard: phpcs --standard=ruleset.xml file.php.

As I've already mentioned, you can reconfigure the way that some of the rules behave. The first one I tried was the line length. We all use fullHD screens for development, so there is no need to limit the line length to 80 characters. With the following snippet, you can get errors and warnings only for extremely long lines (which usually indicates code-smell):

<rule ref="Generic.Files.LineLength">
    <properties>
        <property name="lineLimit" value="250" />
        <property name="absoluteLineLimit" value="300" />
    </properties>
</rule>

Other often-discovered issues are mixed indentation (tabs and spaces), and mixed newlines (you should always use Unix EOLs). It can be a tedious task to fix them manually, but I've got good news for you: there is a tool called SFK (Swiss File Knife) which can easily handle such changes in a second.

If you are still getting hundreds of coding standards violations, I would suggest that you disable some rules by setting their severity to 0 and fix the remaining errors. When you have more time for codebase cleaning, enable some of previously disabled rules and repeat the process until you get 0 errors with all ‚sniffs‘ (rules) enabled.

<rule ref="Generic.Files.LineLength">
    <severity>0</severity>
</rule>

Ignoring some of the errors

You can exclude specific parts of the source code from being scanned by PHPCS by wrapping the problematic part with //@codingStandardsIgnoreStart and //@codingStandardsIgnoreEnd comments. You should reach for those as a last resort, such as when the piece of the code cannot be refactored or rewritten. It is also good to include a reason for exclusion in the comment.

Adding more rules to the ruleset

When you (and the whole team) are comfortable with writing code according to specified coding standard and the PHPCS is run regularly (typically as a part of a Jenkins CI build), you can be more strict and add more rules to the ruleset. It can be easily done by checking some already existing standards and choosing some rules from them. You can do it incrementally – choose one rule that looks good, add it to your ruleset and see what happens after you run PHPCS.

You can check out the coding standard we use for Shopio.cz to see everything that can be checked by PHPCS.

Enable realtime PHP_CodeSniffer checking in PHPStorm

PHPStorm (great IDE btw.) has integrated support for PHP_CodeSniffer. It can work easily with standards predefined in PHP_CodeSniffer. But it can also check the code with your custom standard. The only thing you need to do is to select the „Custom“ standard, which allows you to select the directory where the standard definition file is located. You can select your project directory (you have to have your custom standard file called ruleset.xml) and it will load the standard automatically!

See the detailed guide, Using PHP Code Sniffer Tool

Conclusion

Are you using PHP_CodeSniffer for your projects? Do you want to show off your ruleset file? Or if you are not using PHP_CodeSniffer, I would be happy to hear why.

Návrh REST API se Symfony Rest- a ApiDoc bundle

V poslední době se hodně mluví o správném návrhu API a o jeho dokumentaci. V souvislosti s tím se často skloňuje český startup apiary, který se přesně na to zaměřuje. Apiary slouží jak k dokumentaci API, tak k jeho testování. Zároveň umí vytvořit „mock API“, kdy už na základě té dokumentace jde API trochu „používat“. Takže je možné například vyvíjet mobilní aplikace bez toho, aby serverová část vůbec existovala. Když jsem vymýšlel API pro mobilní aplikace ZmapujTo.cz, tak jsem nejdřív apiary zkoušel, ale nebylo to tak sluníčkové, jak jsem čekal. (Ale možná jsem ho používal špatně). (EDIT: Testoval jsem ho na podzim 2013, takže dnes už je dál a třeba by to sluníčkové už bylo)

V tomhle článku bych chtěl ukázat, jak to jde dělat jinak a možná v dané situaci efektivněji. Předpokladem, aby popisovaný postup byl efektivnější, je, že nepotřebujete jazykovou nezávislost. Apiary má dokumentaci API v upraveném Markdown, a samotné API pak můžete implementovat v čem chcete. Tady jste víceméně dopředu rozhodnutí, že API budete implementovat v Symfony.

Jako příklad ukážu zdokumentování Github API pro gisty, které má Apiary jako ukázku. Článek dále předpokládá znalost Symfony (případně hledání jinde), nebudu zde popisovat vytvoření Symfony aplikace ani základní věci.

Ukázkový kód si můžete po commitech prohlédnout na githubu

Základní kostra (Commit na Githubu)

První krokem je vytvoření běžné Symfony aplikace a nějakého Bundlu, pro API. Potom si nainstalujeme FOSRestBundle, který nám pomůže s vytvářením API.

Aby se nám na /gists zobrazil JSON s výpisem pak už stačí vytvořit GistsController.php s tímto obsahem:

<?php

 namespace Mhujer\ApiDemoBundle\Controller;

 use FOS\RestBundle\Controller\FOSRestController;
 use Symfony\Component\HttpFoundation\JsonResponse;

 class GistsController extends FOSRestController
 {
     public function getGistsAction()
     {
         return new JsonResponse(['list' => 'foo']);
    }
}

getGistsAction() je nutné pojmenování, díky němu pak FOSRestBundle už rovnou ví, že na ní má routovat GET požadavek. Detailní popis, jak pojmenovávat metody je k dispozici v dokumentaci.

Zdokumentování API (Commit na Githubu)

Určitě jste si všimli, že zatím vlastně spíš vytváříme API a nic nedokumentujeme. Hned to napravíme. Nainstalujeme si a nastavíme NelmioApiDocBun­dle (nebudu rozepisovat detaily, jsou vidět v dokumentaci a případně commitu na githubu)

Dalším krokem je doplnění anotace @ApiDoc k metodě getGistsAction(). V článku ještě ukážu další možnosti @ApiDoc anotace, ale zase je nejlepší se podívat rovnou do dokumentace na kompletní přehled možností.

/**
 * List the authenticated user’s gists or if called anonymously, this will return all public gists:
 *
 * @ApiDoc(
 *      parameters={
 *          {
 *              "name"="since",
 *              "dataType"="string",
 *              "required"=false,
 *              "description"="A timestamp in ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ. Only gists updated at or after this time are returned."
 *          }
 *      }
 * )
 */

Z takto rozšířeného dokumentační komentáře nám pak NelmioApiDocBundle v prohlížeči vygeneruje krásnou interaktivní API dokumentaci: 

A kromě dokumentace je tam k dispozici i možnost si přímo API volání vyzkoušet 

Podobně můžeme popsat i složitější metody:

/**
 * Create a gist
 *
 * Files parameter example:
 * ```
 * {
 *   "description": "the description for this gist",
 *   "public": true,
 *   "files": {
 *     "file1.txt": {
 *       "content": "String file contents"
 *     }
 *   }
 * }
 * ```
 *
 * @ApiDoc(
 *      requirements={
 *          {
 *              "name"="files",
 *              "dataType"="hash",
 *              "description"="The keys in the files hash are the string filename, and the value is another hash with a key of content, and a value of the file contents."
 *          }
 *      },
 *      parameters={
 *          {
 *              "name"="description",
 *              "dataType"="string",
 *              "required"=false,
 *              "description"="A description of the gist."
 *          },
 *          {
 *              "name"="public",
 *              "dataType"="boolean",
 *              "required"=false,
 *              "description"="Indicates whether the gist is public. Default: false"
 *          }
 *      }
 * )
 */
public function postGistAction()
{
    return new JsonResponse(
        json_decode(file_get_contents(__DIR__ . '/../Data/Gists/postGist.json')),
        201,
        [
            'Location' => 'https://api.github.com/gists/1',
            'X-RateLimit-Limit' => 5000,
            'X-RateLimit-Remaining' => 4999,
        ]
    );
}

Výsledek?

Na výsledný kód controlleru se můžete podívat na github, případně si projít jednotlivé commity.

Výsledná dokumentace vypadá takto:

A případně ji jde vygenerovat i jako statické HTML (prohlédnout) nebo Markdown (prohlédnout).

php app\console api:doc:dump --no-sandbox --format html > apidoc.html
php app\console api:doc:dump --no-sandbox --format markdown > apidoc.md

Závěrem

V článku jsem se snažil ukázat jiný postup k návrhu a dokumentaci API. Velkou výhodou tohoto přístupu je, že si v rámci návrhu a testování API můžete v kódu už vytvořit nějaké podmínky, které by se ve statickém Markdown zapisovaly těžko. Zároveň API můžete postupně začít implementovat bez toho, aby bylo nutné udělat jedno velké přepnutí z mock implementace na reálnou.

Jak navrhujete a dokumentujete API vy? Používáte apiary? Nebo jiný postup?

Jak spojit fotky/obrázky do jednoho PDF

Určitě jsem už někdy potřebovali z více fotek nebo obrázků udělat jedno PDF (pro tablet nebo Kindle). Je to docela jednoduché. Jde to více způsoby, které jsou různě rychlé. Mně se nejlépe osvědčila kombinace IrfanView + PDFCreator (oproti Průvodci tiskem fotografií přímo ve Windows je výrazně rychlejší).

Instalace

Prvním krokem je instalace PDFCreatoru – o tom jsem už psal a pak IrfanView.

Obrázky

Samotné obrázky je potřeba mít ideálně v jedné složce a pojmenované tak, aby byly podle názvu seřazené tak, jak je chcete mít ve výsledném PDF (takže pokud je máte z foťáku a fotili jste knížku popořadě, tak už tak budou).

Výroba PDF

  1. Otevřeme IrfanView a zvolíme FileThumbnails
  2. Najdeme složku s fotografiemi
  3. Vybereme všechny a z menu zvolíme FilePrint selected files as single images 
  4. V okně, které se zobrazí vybereme tiskárnu PDFCreator 
  5. Nic dalšího není potřeba nastavovat, potvrdíme tedy tlačítkem Print a nějakou dobu počkáme (IrfanView teď jednotlivé obrázky odesílá na virtuální tiskárnu PDFCreatoru)
  6. Zobrazí se okno PDFCreatoru , kde dokument můžeme pojmenovat a dáme Save
  7. Vybereme, kam chceme výsledné PDF uložit a pak nějakou dobu počkáme, než se PDF vytvoří (trvá nejdéle z celého procesu)
  8. Hotovo. PDF se uloží tam, kam jsme zadali a zároveň se nám otevře.

Pokud by se vám PDF podle postupu nedařilo vytvořit, tak se určitě ozvěte v komentářích.

ZmapujTo aneb Co vlastně děláš jako diplomku?

Už od podzimu pracuju na diplomce, ale ještě na ni ani nemám založený dokument. Takže když jsem v březnu zjistil, že jsou dva měsíce na napsání a ještě jsem neměl ani doprogramováno, tak jsem se rozhodl radši studovat o semestr déle, než to zbytečně odfláknout.

A co teda vlastně děláš?

To, že docela rád běhám, jste už určitě zaznamenali. S tím souvisí to, že když běhám po lesích, tak dost často potkám nějakou černou skládku.

A to mně docela vadilo, takže jsem řešil, co s nimi. I ukázalo se, že je jde nahlásit na městský úřad na odbor životního prostředí a oni je budou řešit a buď je v dohledné době uklidí nebo vyzvou vlastníka pozemku, aby je uklidil. Postupně jsem podobně zkoušel nahlásit ještě pár věcí (třeba ulomenou značku nebo strom přes cestu) a všechno se celkem rychle vyřešilo. Ale posílat jednotlivá hlášení takhle ručně je docela hodně práce (je potřeba místo najít na mapě, vyznačit a udělat krátký odkaz, stáhnout fotku z telefonu, najít kontakt na správného člověk na webu úřadu).

Vzhledem k tomu, že jsem zrovna v té době v práci dělal na mobilní aplikaci, tak mě napadlo, že by bylo fajn mít aplikaci, kterou nějaký takový problém vyfotím, zaměřím jeho polohu a odešlu úřadu k řešení. (A zároveň jsem si říkal, že bych to mohl mít jako diplomku, u které se neúprosně blížil čas volby tématu).

Při zběžném zkoumání jsem zjistil, že taková aplikace už bohužel existuje (i když jen na mapování černých skládek). Takže jsem z toho byl nějakou dobu smutný, ale pak jsem se jim ozval, jestli to neplánují rozšířit i na mapování dalších věcí. A ono jo, takže jsme se domluvili na spolupráci. No a to je ZmapujTo

ZmapujTo jsou mobilní aplikace (iOS, Android, WP8) na hlášení problémů (černé skládky, zlomené značky, rozbité lavičky, …) ve městech. Aplikace umí problém zaměřit, vyfotit a odeslat na web. Tam si hlášení buď zapojené obce řeší přímo samy a těm ostatním se to pošle e-mailem (a jejich odpovědi se zobrazí jako komentáře).

A co jsi na tom dělal?

Já jsem dělal ty tři mobilní aplikace, serverové API, kam se hlášení odesílají a mailing (posílání notifikačních e-mailů jednotlivým obcím). Web dělal Mirek Kubásek, který vytvářel původní ZmapujTo.

Jak a na čem to funguje?

  • mobilní aplikace jsou postaveny na Sencha Touch a Apache Cordova
  • API je postavené na PHP: Symfony + Doctrine ODM + MongoDB
  • na Mailing používáme Mandrill
  • web je vytvořený v AngularJS a na backendu Node.js

Zapojte se!!

  1. Nainstalujte si mobilní aplikaci
  2. (dejte vědět, jestli vám funguje správně)
  3. Hlaste problémy ve svém okolí, ať ten svět máme hezčí :-)

Clean up your Sass with SCSS Lint

As you may have already noticed, I'm a little obsessed with code quality, particularly its automatic checking and monitoring (Czech only, sorry). In this article, I want to show you how to ensure that your SCSS files have consistent formatting style. And it may even help you to detect some mistakes!

At w3w we've been using SASS for quite a while. Shopio's new responsive template is based upon Twitter Boostrap (we are using an unofficial Sass version of Twitter Boostrap v2.3.2 – we used the it before it was cool!). We are using Sass together with Compass framework. Apart from that, I also worked on two mobile apps based upon Sencha Touch. It is a HTML5+JS+CSS framework for cross-platform mobile app development, with styling powered by Saas.

Demo

See this code snippet (demo.scss file):

$highContrastMode: true;

@if ($highContrastMode) {
  body {
    background: black;
    color: yellow;
  }
} else {
  body {
    background: white;
    color: gray;
  }
}

If we have the $highContrastMode variable set to true, we want to render yellow text on black background; if not, we don't care about those with poor vision. Would it work as described? No! We missed the @ character before the else keyword! Compass compiles it without complaint as the code is completely valid SASS. And we will have a cute else body selector in the compiled css.

How could we have prevented this? By using scss-lint!

If we had scss-lint as part of our CI build process, we would have been notified immediately. When you run scss-lint on the code snippet above (scss-lint demo.scss), it complains about a lot of things, including the else error:

demo.scss:8 [W] Rule declaration should be preceded by an empty line

Custom style

At Shopio, the SCSS coding style is not the same as the default coding style in scss-lint. When we ran it for the first time, unsurprisingly, we got a few thousand errors and warnings.

Luckily, scss-lint allows you to configure custom settings that will then be used for checking. So I asked Stuart questions such as, „Do you use 2 or 4 spaces for indentation?“, „Do you prefer single or double quotes?“ or, „Do you use colour names or hex codes?“. After receiving the answers and doing some testing I was able to come up with a .scss-lint.yml file, which suits our needs (there are many more options in the docs!). It still results in a few hundreds warnings, which we are fixing continually.

Continuous integration

scss-lint offers a XML output option (with --format=XML) which can be consumed by Jenkins or similar tools. But for some strange reason, the XML output does not work on my Windows machine. (I hope it would work on our Jenkins machine)

Conclusion

It's not hard to setup the scss-lint to check SCSS files and the benefits are obvious. It will ensure that you use a consistent coding style and it may even prevent some errors. And if your coding style is different from the default one, then you can simply redefine the rules.

Thanks Stuart for language and technical review.

Pár postřehů z Linze (Rakousko)

Kolem Velikonoc jsem byl týden za Ivčou v Linzi a i když to je na poznání nějaké kultury hrozně krátká doba, tak mám pár zajímavých postřehů, o které se chci podělit.

Kouření

Občas se objeví nějaká tendenční mapka, kde ČR je poslední země EU, kde se může v restauracích kouřit a kde je Rakousko označeno jako „v restauracích kouření zakázáno“. A to není pravda. V Rakousku se provozovny pod 50m2 mohou rozhodnout, jestli budou kuřácké nebo nekuřácké a ty větší musí být nekuřácké nebo mít stavebně oddělené prostory pro kuřáky (takže žádný zákaz, ale spíš skoro stejně jako v ČR). (zdroj)

Pocitově se tam na veřejnosti kouří víc než v Praze. Automaty na cigarety na ulicích a popelníky na stolcích přes McD mě docela překvapily.

Obchody s potravinami

V Rakousku jim zřejmě hodně záleží na tom, aby potraviny, které kupují, byly z rakouské produkce. Téměř všechno má na sobě nějakou variaci na nápis „Qualität aus Österreich“.

Mají v nabídce výrazně víc věci s popiskem BIO.

Zajímavé je, že na rozdíl od ČR, kde je ve městě spíše méně větších obchodů s potravinami, tak v Linzi je spíše více menších (rozlohou). Takže spíš menší SPAR, Tesco, Billa, Hofer – ale ne obrovský Kaufland.

A většina obchodů má zavřeno v neděli a ve svátek. A také zavírají večer výrazně dříve (třeba ve 20h)

Peníze

Samozřejmě je všechno po přepočtu v Rakousku dražší. Ale zase na druhou stranu, když jsme byli na burgeru (menu €10), tak tam měli vyvěšený inzerát, že hledají někoho na pečení burgerů. Za €1500.

Tím, že nejsem moc zvyklý používat eura, tak mě také překvapilo, že se platí i jednotlivými centíky (= 27 haléřů).

Co se jinam nevešlo

  • Spousta cyklistů. Fakt spoustu.
  • V Linzi jsem potkával mnohem více různě zahalených žen (od šátku na hlavě, až po jen mezeru na oči)
  • Světla na semaforech blikají, když se blíží přepnutí barvy