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

Teď se učím se němčinu čtením

Před nějakou dobou jsem psal, že se mi na učení němčiny líbí Duolingo. To už teď neplatí, Duolingo mě přestalo bavit. Asi hlavně proto, že věty, které tam překládáte, jsou někdy dost divné, a mají hodně náhodou obtížnost. Třeba mu zas někdy dám šanci, ale teď to chtělo něco jiného.

Když jsem vzpomínal, čím jsem si dřív posouval dál angličtinu, tak jsem si uvědomil, že už někdy v kvartě na gymplu (~9. třída) jsem si přečetl Harryho Pottera v angličtině. Byl to pátý díl, který v té době byl jen anglicky (fan překlady se rozjely až později). Sice jsem si docela dost slovíček musel hledat (HP je ještě specifický tím, že tam jsou slovíčka kolem kouzlení – kotlík, hůlka atd.), ale myslím, že to docela nastartovalo moje učení angličtiny. Pak jsem se pustil do dalších anglických knížek (třeba Hobit a Pán prstenů) a začal jsem poslouchat anglické audioknihy (Eragon + pokračování).

Rozhodl jsem se tedy podobnou věc naaplikovat na němčinu. Vzhledem k tomu, že německy teď umím pořád míň, než jsem tenkrát uměl anglicky, tak jsem usoudil, že na Harryho Pottera to zatím není. Jako v angličtině existují Penguin Readers knihy (převyprávěné knihy, aby na jejich přečtení stačila menší slovní zásoba a jednodušší gramatika), tak němčina má něco podobného. Pro začátek jsem si našel minidetektivky od Felix & Theo. Mají vždycky tak 20–30 stránek a relativně jednoduchou slovní zásobu.

Zatím jsem přečetl dvě – Oh Maria a Ein Mann zu Viel. Čtu je na Kindlu, kde mám i německý slovník, takže nemusím každé neznámé slovíčko hledat někde jinde. Aby mě to posouvalo dále, tak si slovíčka, která neznám, označuju. Po dočtení knížky si je projdu, upravím (1. pád/1. osoba, jednotné číslo), přeložím si je a dám do Quizletu (webová aplikace na flashcards). Odtamtud si je pak stahuju do telefonu (používám MemeCards, který si umí stáhnout sadu slovíček z Quizletu). Naučím se je a pak si znovu přečtu tu knížku – ale už bez toho, abych si musel ty slovíčka hledat.

Za cca 2 měsíce jsem takhle zvládl ty dvě knížky. Z první umím +170 slovíček, z druhé +130 dalších. To myslím není špatné – minimálně to je o 300 slovíček více, než bych se naučil bez toho. Když jsem teď byl pár dní v Linzi, tak jsem některá z těch nově naučených slovíček viděl někde na plakátech a měl jsem radost, že díky té troše učení rozumím nápisům, kterým bych dřív nerozuměl :-)

Plán je, abych byl schopný si v červenci přečíst alespoň jeden díl Harryho Pottera v němčině. Zároveň se chci pustit do čtení článků na Deutsche Welle a zas si z nich vypisovat (a učit se) slovíčka.

Takže když to shrnu, tak to je vlastně hrozně jednoduché

  1. Přečíst jednoduchou knížku německy
  2. Označovat si neznámá slovíčka
  3. Ty se pak naučit
  4. Přečíst knížku znovu, už bez hledání slovíček
  5. Znovu na bod 1.

Co na to říkáte? Nechcete to taky zkusit? Pokud někam dojíždíte MHD, tak je tohle ideální metoda, protože nezabere žádný čas navíc.

3MS Malé a střední podniky v tržním prostředí – zhodnocení

Občas se mě někdo ptá, jestli se mi líbila vedlejška, kterou jsem na VŠE studoval a jestli bych mu ji doporučil.

Nevím, jestli je koncept vedlejších specializací běžný i jinde než na VŠE. Každopádně funguje to tak, že si na magistru kromě svého oboru (hlavní specializace, major) vyberete a odstudujete další mini-obor (minor). Je na to vyhrazených 30 ECTS kreditů, tedy jeden semestr. A typicky si vedlejšku vybíráte z úplně jiného oboru, než je váš hlavní.

Já si jako vedlejšku vybral 3MS Malé a střední podniky v tržním prostředí

Výstupem mělo být: „Vedlejší specializace je koncipována jako samostatný program umožňující budoucímu absolventovi snazší zvládnutí a výkon řídicí funkce v malém a středním podniku nebo založení a řízení vlastní firmy.“, což mi dávalo smysl.

A jaké to teda vlastně bylo?

  • zajímavé, zábavné a inspirativní
  • náročné ?
  • užitečné ?
  • lišilo se to předmět od předmětu

Zajímavé, zábavné, inspirativní

Vzhledem k tomu, že naprostá většinu přednášek v celé VS mají na starosti hosté, většinou podnikatelé (Radim Jančura, Tomáš Březina, Martin Hausenblas, a další), tak to není o nějaké nalévárně teoretických znalostí, ale spíše o poznatcích z praxe. Na druhou stranu je otázka, kolik těch poznatků z praxe je přenositelných i pro moje použití. Ale vzhledem k tomu, že jsem na podobné přednášky občas chodil i dříve, tak tohle hodnotím jako plus.

Náročné?

Mám to naschvál s otazníkem, protože je to diskutabilní. Obecně nemám moc rád předměty, kde se přes semestr nic moc neděje, ale je nutné se toho spoustu jednorázově naučit ke zkoušce. Většina vedlejšky byla opačná – jednotlivé zkoušky a testy byly docela jednoduché. V každém předmětu ale byla obrovská nálož různých seminárek, semestrálek, esejí a týmových projektů. Vzhledem k tomu, že mám docela zvládnutý timemanagement a jsem zvyklý věci řešit průběžně, tak mi to přišlo docela na pohodu. Ale chápu, že někdo preferuje nic moc neřešit a pak se nadrtit na zkoušku.

Užitečné?

Tohle je opět s otazníkem, protože nemám pocit, že by mi vedlejška něco moc dala, co bych mohl využít do praxe. Vzhledem k tomu, že už jsem něco o podnikání věděl a českou startupovou scénu sleduji, tak ty základní věci pro mě nebyly nové a zbytek je použitelný „až budu mít firmu s 50 zaměstnanci“. Ale třeba se nějaká užitečnost projeví později, nějak neočekávaně. Ale určitě pro mě bylo přínosné to, že se dělá spoustu týmových projektů, semestrálek a podnikatelských plánů, které se prezentují a prezentují, takže jsem si potrénoval prezentační dovednosti.

3MA544 Podnikání malých a středních firem 1 (LS 2012/13)

Přednášejí externisté, což je fajn (viz výše). Nicméně jako velký fail beru to, že přednášky jsou prezentované jako nepovinné, ale za každý napsaný feedback přednášejícímu (co si z přednášky odnáším) jsou 2b, za semestr tedy 20b (takže jsou de facto povinné „nemusíte tam chodit, ale za trest dostanete o stupeň horší známku“). Externí přednášející se pak diví, že i na přednášku v 18h je učebna plná. Dávalo by mi větší smysl, kdyby na přednášce bylo místo 40 lidí jen 15, které téma opravdu zajímá, než plná učebna, kdy většina lidí stejně řeší něco jiného. Cvičení byla středně k ničemu, po 3–4 členných týmech se postupně zpracovávala a prezentovala témata z učebnice.

3MA545 Podnikání malých a středních firem 2 (ZS 2013/14)

Podobné jako 3MA544, s tím že externisté jsou spíše odborníci na jednotlivé oblasti a mají na starosti i cvičení. A z toho co povídají, je potom test, na který neexistuje jiný rozumný zdroj než přednášky + cvičení + slidy, takže přednášky opět povinné. V LS 2012/13 to bylo tak, že zbytek VS byl po-út a tenhle předmět až v pátek, takže jsem si ho o semestr odložil.

3MA546 Strategie a podnikatelský plán v MSP (LS 2012/13)

Pro mě asi nejužitečnější předmět, jak už je jasné z názvu, tak se v předmětu řeší hlavně sestavení podnikatelského plánu (je to těžší, než by člověk na první pohled řekl). Fajn je, že podnikatelský plán vám pak okomentuje reálný investor. A také se trochu řeší strategie podniku (což už mi přišlo méně přínosné, protože to je abstraktnější a víc závislé na konkrétní firmě).

3MA547 Moderní trendy v malém a středním podnikání (LS 2012/13)

Hodně zábavný, zajímavý a inspirativní předmět. Přednášky opět externí, zajímaví lidé, kteří mají něco do činění s jednotlivými probíranými oblastmi – ale od 7:30 :( Cvičení byla jedna z mála za celou VŠE, na která jsem se těšil (ještě SoMaDo!).

3MA543 Podnikatelské praktikum (LS 2012/13)

Haluzný předmět, který zrovna v tom semestru, kdy jsem ho měl, epicky pivotoval. Na přednáškách se střídaly dvě zmatené nepříjemné dámy. Přednášky byly spíš workshopy, kde se měl řešit rozjet nějakého vlastního podnikání (povinně). A neumím si představit, že by někdo rozumný šel do podnikání s lidmi, které zná asi den. Vzhledem k tomu, že asi pivotovali nějak na poslední chvíli, tak cvičící byl překvapený, když jsme mu říkali, že je všechno jinak a pak se šel podívat na druhou přednášku, aby věděl, co se vlastně děje :D No, ještě že už to je za mnou (další semestr to prý nebylo o nic lepší).

Státnice

Byly víceméně o tom, co nejpřesněji odříkat, co je v knížkách. Tím, že jsem je měl o semestr později než většinu předmětů VS, tak se občas v předmětech něco změnilo Třeba 3MA546 se více zaměřilo na povídání o nějakých strategiích, které jsme v předchozím semestru moc neřešili – byl místo nich Lean Canvas (takže jsem strategie v knížce jen prolétl). Podobně 3MA547, na které existují skripta v PDF, ale ta mají v ISISu studenti přístupná jen v daném semestru, takže mezitím vyšla nová rozšířená edice :-/

Shrnutí

Vedlejší specializaci 3MS Malé a střední podniky v tržním prostředí bych doporučil někomu, kdo toho o podnikání mnoho neví. Případně plánuje v nejbližší době začít podnikat. V takovém případě by se z vedlejšky daly vytěžit užitečné kontakty a případně konzultace s lidmi z praxe, ke kterým je jinak mnohem těžší se dostat. Ale asi bych ji už nedoporučil jako oddechovou nenáročnou vedlejšku, protože těch věcí přes semestr byla fakt fůra a co jsem slyšel, tak poslední semestr toho ještě přibylo. Zároveň bych ji ani nedoručil těm, kteří už něco o podnikání a startupech vědí.

Doufám, že se článek nikoho nedotkne, ale dává mi smysl říkat věci na rovinu, protože jen tak se něco může posunout dále.

Co si tom myslíte? Studovali jste také tuhle vedlejšku? Nebo jinou a lepší?