Zprovoznění Ruby on Rails vývojového prostředí ve VirtualBoxu


Jednou z největších překážek začínajících Ruby on Rails programátorů je zprovoznění vývojového prostředí. Na začátku si musíte vybrat, ve které Linux distribuci budete pracovat. Je z čeho vybírat, ale nezapomínejte, že vám jde hlavně o uživatelsky přívětivé prostředí. Jste začátečníci a musíte se v něm brzy zorientovat. Přecházíte z Windows a nechcete, aby byla změna tak drastická. Proto se mně jako ideální jeví distribuce Ubuntu, nebo jakákoli jiná obnož stojící na Ubuntu – Linux Mint, Kubuntu, Xubuntu a další. Pro tento článek zvolím distribuci Linux Mint 17.3, ale pravděpodobně bude postup fungovat i na ostatní.

Instalace a nastavení VirtualBoxu

Pro ty, kdo neznají VirtualBox. Jde o virtualizaci plnohodnotného operačního systému. Pokud bychom VirtualBox neměli, potom by nám nezbývalo nic jiného než mít na pevném disku speciální oddíl na Windows a pracovní Linux OS. Jenže to je takové nic moc řešení, které má mnoho úskalí. Např. já mám při vývoji virtualizovaný Linux, ale emaily a jiná práce mimo vývoje mi zase běží ve Windows. Jednoduše si tak překlikávám dle potřeby.

Stáhněte si nejnovější verzi VirtualBoxu a nainstalujte ji. Pro vytvoření virtuálního počítače program otevřete a zvolte Nový. Do názvu napište co chcete, třeba Vývoj nebo RailsDev. Typ zvolte Linux a verzi Ubuntu 64 bit pokud budete alokovat dostatek operační paměti, pro 1 GB ram stačí 32 bit. Verzi Ubuntu volíme u všech Linux distribucí založených na Ubuntu, tzn. v našem případě i u Linux Mint. Dále zvolte, kolik operační paměti budete chtít při virtualizaci alokovat. Já automaticky dávám 4 096 MB, ale samozřejmě záleží kolik paměti máte k dispozici. Čím méně dáte, tím pomalejší virtualizace bude a o to hůř se v ní bude pracovat. Poslední krok je volba Hard Disku, kde vytvoříte nový virtuální disk. Tento virtuální disk bude soubor s koncovkou Virtual Disk Image (.vdi) uložený ve vašem počítači. Doporučuji zvolit pevnou velikost alespoň 30GB, protože nikdy nevíte, kolik prostoru budete ve vývojovém systému potřebovat. Dynamicky alokovaný HD se zvětšuje a zmenšuje dle potřeby, což je dobře, ale prý to zpomaluje virtualizaci. Teď už můžete dokončit tvorbu virtuálního počítače.

V seznamu se vám objevil váš nový virtuální počítač. Konfigurace ještě není dokončena, takže vyberte váš virtuální PC a klikněte na Nastavení. V levém menu vyberte Systém, v záložce Procesor zvolte alespoň dva procesory. Hodně to ovlivňuje rychlost. V záložce Akcelerace je dobré mít zaškrtnuto Povolit VT-x. Výrazně to zlepšuje běh virtuálního PC. Ne každý procesor to však podporuje. Pokračujte v levém menu na část Obrazovka, kde alokujte video paměť (já mám 64 MB) a povolte 3D akceleraci.

A máte hotové jednoduché nastavení, které vám bude pro začátek stačit. V budoucnu se k tomuto kroku můžete vrátit, a pokud vám virtualizace nepoběží plynule, můžete přidat ještě více systémovch prostředků. To poslední co chcete je, aby se vám pracovní prostředí sekalo.

Instalace Linux Mint 17.3 KDE

Linux Mint nabízí hned několik desktopových prostředí – KDE, MATE, Cinnamon a Xfce. Já vybral pro tento článek KDE. Linux Mint 17.3 KDE můžete stáhnout zde.

Vraťte se do VirtualBoxu do Nastavení vašeho virtuálního PC a jděte na záložku Uložiště. Měli byste tam mít Řadič SATA s vaším virtuálním diskem.vdi. Jenže my ještě nemáme nainstalovaný Linux, takže potřebujeme nabootovat iso Linux Mint, který jsme teď stáhli. Proto v části Řadič IDE klikněte na ikonku Add optical drive a vyberte Linux Mint 17.3 iso. Změnu uložte. Vyberte váš virtuální PC a dejte spustit. Nabootuje vám instalace Linux Mint, kde máte možnost systém vyzkoušet bez instalace, ale to nechcete. Zvolte tedy nainstalovat Linux Mint (ikona na ploše) a projděte instalací operačního systému. Vše se děje v okně VirtualBoxu zatímco můžete normálně používat Windows. Nezapomeňte si zapamatovat heslo do Linux Mint, které budete často používat. Pro dokončení je potřeba restartovat virtuální PC. Klikněte na OK, ale na nic nečekejte a rovnou zavřete křížkem okno VirtualBoxu, kde vyberte příznak Vypnout počítač. Jste zpátky v nabídce VirtualBoxu, kde opět zvolíte Nastavení. V části Uložiště Řadič IDE odstraňte Linux Mint 17.3 iso, jelikož jste ho již nainstalovali na virtuální disk a nepotřebujete dále bootovat. Změny potvrďte a operační systém opět spusťte. Momentálně se vám systém nabootoval již z virtuálního disku a pomyslné iso DVD Linux Mint už nepotřebujete.

První kroky s Linux Mint

Všechno je jinak. Pokud celý život fungujete na Windowsech, tak si teď musíte trošku zvyknout. Prvním váším krokem by měla být instalace aktualizací a seznámení s uživatelským rozhráním – kde jsou programy, terminál apod. Nebojte se používat Google a využijte toho, že máte Linux Mint ve virtualizaci. Chvíli vám např. zabere nastavení klávesové zkratky pro změnu z CZ na ENG klávesnici. U zadávání hesel v terminálu se nedivte, že při psaní nevidíte počet zadaných znaků.

Instalace Ruby, Ruby on Rails a PostgreSQL

Abyste mohli začít vyvíjet aplikace v Ruby on Rails, potřebujete mít nainstalovaný jazyk Ruby, framework Ruby on Rails a databázi, se kterou budete pracovat. PHPkaři používají hodně MySQL, já mám více v oblibě PostgreSQL.

Nejprve tedy nainstalujeme Ruby – v době psaní článku je nejnovější verze 2.3.0. Otevřete termínal (konzoli) a napište (zkopírujte) postupně tyto řádky:

sudo apt-get update
sudo apt-get install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev

Ruby lze nainstalovat samostatně, přes rbenv nebo rvm. Pokud Ruby nainstalujete samostatně, ztratíte výhodu jednoduchého přepínání mezi verzemi. Rbenv je verzovací systém pro jazyk Ruby, bez kterého se neobejdete. Rvm je to samé, ale starší. V návodu tedy budu používat právě rbenv.

Nainstalujte tedy rbenv:

cd
git clone git://github.com/sstephenson/rbenv.git .rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
exec $SHELL

git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc
exec $SHELL

git clone https://github.com/sstephenson/rbenv-gem-rehash.git ~/.rbenv/plugins/rbenv-gem-rehash

rbenv install 2.3.0
rbenv global 2.3.0
ruby -v

Příkazem rbenv global 2.3.0 nastavíte Ruby ve verzi 2.3.0 jako defaultní. Jelikož jde vývoj dopředu a vy pak budete mít v rukách projekty co používají různé verze, díky rbenv a příkazu global můžete měnit aktuální verzi, kterou k danému projektu potřebujete. Proto se vyplatí verzovací systém používat. Príkazem ruby -v si jen ověříte, která verze Ruby je aktivní. Mělo by to tedy vypsat ruby 2.3.0.

K dokončení ještě použijeme tyto dva řádky:

echo "gem: --no-ri --no-rdoc" > ~/.gemrc
gem install bundler

Tím nastavíme, aby Ruby neinstalovalo dokumentaci pro každou verzi, což nám ušetří místo. Poté nainstalujeme gem bundler.

Ruby, respektive rbenv máme nainstalované, a můžeme jít na Railse.

V době psaní článku je Ruby on Rails ve verzi 4.2.5, ale v betě je i Ruby on Rails 5, které brzy vyjde. Proto pak jen v návodu změňte příslušnou verzi Rails, postup by měl být stejný.

Nejdříve nainstalujeme NodeJS, které je pro práci s Railsama nezbytné:

curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs

A bez dalších řečí rovnou i Ruby on Rails:

gem install rails -v 4.2.5
rbenv rehash
rails -v

Příkazem rails -v vypíšete aktuální verzi Ruby on Rails. Příkaz rbenv rehash se stará o správné propojení Railsů s rbenv.

Nyní přejdeme k instalaci PostgreSQL. Opět nainstalujeme aktuálně nejnovější verzi 9.5.

sudo sh -c "echo 'deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main' > /etc/apt/sources.list.d/pgdg.list"
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql-common
sudo apt-get install postgresql-9.5 libpq-dev
sudo apt-get install postgresql-contrib-9.5

Databáze je nainstalovaná a funkční. Teď ještě zbývá vytvořit uživatele.

sudo -u postgres createuser nazev_uzivatele -s
sudo -u postgres psql
postgres=# \password nazev_uzivatele

2x vložíte heslo pro vašeho nového uživatele databáze a potvrdíte. Z psql zápisu se dostanete příkazem \q. Tohoto uživatele budete používat pro vaše projekty, takže heslo určitě nezapomeňte. Jinak pro Linux existuje vcelku dobrý grafický klient pgAdmin3, takže pokud si chcete pro začátek usnadnit práci, doporučuji ho nainstalovat.

Vytvoření první aplikace

Otestujte, jestli jste postupovali správně. Vytvořte vaši první aplikaci, respektive její kostru.

rails new prvni_aplikace -d postgresql

Možná to chvíli potrvá. Jakmile terminál přestane pracovat, běžte se podívat do složky prvni_aplikace, která je hned v domovské složce. Vidíte celou strukturu rails aplikace. První, co potřebujete udělat, je jít do config/database.yml a v části pod development odkomentovat username a password. Tam budou patřit databázové údaje, které jste vyplnili při nastavení PostgreSQL – vámi vytvořený uživatel a jeho heslo. Připojení k databázi otestujete tím, že spustíte příkaz rake db:create. Nejdříve ale musíte jít v terminálu do složky vaší aplikace přes příkaz cd prvni_aplikace.

cd prvni_aplikace
rake db:create

A teď už jen spustit server.

rails server

V prohlížeči otevřete url http://localhost:3000. Jestli se vám zobrazí uvítací stránka Ruby on Rails, máte vyhráno. Pokud se vám zobrazí něco ve smyslu „Access denied for user ‚root’@’localhost‘ (using password: NO)“, tak máte špatně nastavené username a password v souboru config/database.yml.

Běh serveru v terminálu ukončíte klávesovou zkratkou CTRL+C. Jakmile server neběží, localhost se vám samozřejmě nenačte.

Nastavení GIT

Pokud mastíte kód sólo jen tak pro zábavu, tak GIT nepotřebujete. Jenže jakmile se rozhodnete vaši aplikaci nahodit online, tak GIT potřebovat budete. A jakmile budete v budoucnu pracovat v týmu, tak GIT také oceníte. Proto je lepší začít s ním co nejdříve. I při single programování má své výhody.

Nebudete zde popisovat jak GIT funguje, jenom vám poradím, že je dobré založit si účet na https://BitBucket.org. Oproti GitHubu nabízí BitBucket ve free verzi private repositories, takže vám do kódu nikdo nepoleze. Jakmile máte vytvořený účet, musíte nastavit GIT i v Linx Mint. Opět přes terminál.

git config --global color.ui true
git config --global user.name "Jméno Příjmení"
git config --global user.email "muj@email.cz"
ssh-keygen -t rsa -C "muj@email.cz"

Enter file in which save the key – odklikněte enterem. Potom se vás to 2x zeptá na passphrase, což je heslo pro SSH přístup. Opět si ho důkladně zapamatujte.

Následuje vypsání SSH klíče.

cat ~/.ssh/id_rsa.pub

Celý tento řetězec od ssh-rsa až po váš email zkopírujte a vložte do SSH Key v BitBucket účtu – vpravo nahoře klikněte na ikonku uživatele a vyberte BitBucket Settings -> v levém sloupci hledejte SSH keys -> Add key. Název je čistě orientační, protože jak jistě tušíte, do jednoho BitBucket účtu se můžete připojovat z více zařízení = více SSH keys.

Jakmile máte klíč přidaný, je dobré ověřit připojení. To provedete následovně.

ssh -T git@bitbucket.org

Mělo by se vás to zeptat na yes/no, potvrďte. Následně se vás budou ptát na passphrase, opět vložte a potvrďte. Výsledkem by měl být výpis něco jako „Logged in as nazev_uzivatele“. Tím máte propojení GITu s BitBucket hotové.

Základní nastavení Sublime Text

Už se blížíme ke konci. Každý používá pro psaní kódu něco jiného, ale já jsem si oblíbil Sublime Text 3. Velmi jednoduchý a přehledný editor, který si můžete velmi dobře připůsobit pro vlastní potřeby. Jinak mezi RoR programátory je velmi oblíbený i RubyMine. Nejlepší je vyzkoušet si zkušební verzi a na základě toho se rozhodnout.

Základem všech pluginů pro Sublime Text je Package Control. Nainstalujete ho dle pokynů na stránce. Pluginy pak instalujete přes klávesu ctrl + shift + p, kdy do vyhledávacího boxu napíšete install, a vyberete Package Control: Install Package. V tuhle chvíli stačí zadat do vyhledávání název pluginu a jenom ho vybrat – potom se již automaticky nainstaluje.

All Autocomplete – v základu Sublime Text našeptává pouze z aktuálně otevřeného souboru, ale díky pluginu All Autocomplete bere údaje ze všech otevřených souborů (většinou z celého projektu), což se samozřejmě velmi hodí.

Emmet – tak tohle chcete. Psaní základních html tagů dokáže zabrat čas, nebo vás nutí zbytečně kopírovat. Chcete udělat nečíslovaný seznam o 10 položkách? Vytvořte si kostru jednoduchým příkazem: ul>li*10 a máte hotovo. A to je jen kapka toho, co Emmet umí. Více najdete v dokumentaci.

GitGutter – nezbytnost pro všechny, kteří používají GIT. Zobrazuje žluté plusko před každým řádkem, který byl změněn oproti stávajícímu stavu v GITu. Strašně pomáhá zorientovat se v posledních změnách a commitech.

SaSS – zvýrazňovač syntaxe pro SASS a SCSS soubory

Settings – a ještě defaultní nastavení Sublime Text, které mi velmi vyhovuje a může to být dobrý odrazový můstek pro vás. Vkládá se do Preferences -> Settings – User.

{
  "auto_complete": true,
  "auto_complete_commit_on_tab": true,
  "copy_with_empty_selection": true,
  "ensure_newline_at_eof_on_save": true,
  "index_files": true,
  "rulers":
  [
    80
  ],
  "tab_size": 2,
  "translate_tabs_to_spaces": true,
  "trim_trailing_white_space_on_save": true,
}

Závěr

Tak a jsme u konce. Ufff. V češtině žádný takto podrobný článek týkající se nastavení Ruby on Rails nenajdete, tak vám to snad pomůže.

 

Práce za podíl na projektu


Obecně nefunguje. Všímám si, že je to poslední dobou trend. Můžou za to pravděpodobně videa a články o úspěšných lidech. A každý chce být úspěšný. Takže se v hlavě zrodí nápad, ale co dál? Je mi dvacet, neumím programovat, neumím grafiku, neumím vlastně nic. Ale já to vymyslel! No tak si dám poptávku a půjdeme spravedlivě 50/50. Já budu řešit byznys + jsem vymyslel tenhle bezva nápad a ten druhý bude vyvíjet, dělat grafiku, co bude potřeba. Ideální start bez investice jediného floka. Opravdu se někdo ozval. A tak začíná naše partnerství. Postupem času zjišťuju, že dotyčný neumí o moc víc než já, programuje podle deníčku, grafiku stahuje z internetu. Po pár měsících se to nějak splácá a jedeme. Do teď jsme investovali hlavně náš čas, i když já zatím neinvestoval skoro ani ten čas. Projekt je spuštěn, jenže nikdo ho nepoužívá. Po krátkém spamování internetu se u nás otočilo několik lidí, ale nikdo nic neobjednává, nikdo náš projekt nechce. No jo, tak se nezadařilo, příště bude líp. Rozloučím se s lepičem kódu, se kterým se ještě stihnu pohádat a poslat ho do prdele a jdu dělat další velký byznys o dům dál. Happy ending story.

Velmi riskantní pro obě strany

Pokud budeme brát situaci, kdy do projektu vstupují kvalifikování lidé, projekt je profesionálně připraven a má budoucnost, tak i tak je to pro obě strany nesmírně velké riziko. Majitel projektu si se samotnou přípravou dal spoustu práce, projektu věří a ve své podstatě nechce dát 50% jen tak někomu. Má investice do dalšího rozjezdu a spíš koketuje s myšlenkou, že si vývojáře zaplatí. Bude mít 100%, i když prvotní vstup bude náročnější. Ten druhý, kdo do projektu vstupuje za podíl, zase vlastně vůbec neví, jak na tom majitel projektu je. Jak moc si s tím dal práci, jak moc se tomu bude věnovat, jak velké má investice, jaký je jeho soukromý život, jestli se zrovna nerozchází se svou životní láskou a nebude půl roku úplně mimo. Jsou to oba cizí lidé, kteří se neznají a mohou vycházet jen z informací, které si předají, přičemž není dáno, že komunikují v rovině pravdy. Jakože majitel projektu řekne, že na tom dře poslední dva roky, ale přitom ho to napadlo včera ve sprše. Tuhle informaci si prostě neověříte.

Vyjednávání podmínek

Další důležitý bod, na kterém se obě strany mnohdy nedohodnou. Těch scénářů jak bude jejich byznys vzkvétat je hodně. Není to jenom o to, jestli se to povede nebo nepovede. Záleží za jakých podmínek se to povede/nepovede, jaké budou zmařené investice, za jak dlouho se to povede/nepovede, kolik času do projektu každý z nich investuje. A jak se budou řešit investice (platí obě strany, nebo jen majitel projektu?) a jak se budou rozdělovat zisky? A co se stane, když jedna strana přestane komunikovat? Jaké budou rozhodovací pravomoci? Tyhle věci smluvně neošetříte. Nebo ano, ale smlouva bude natolik dlouhá a složitá, že si to obě strany radši rozmyslí.

Sebelepší úmysl nemusí znamenat úspěch

V roce 2013 jsem měl ambici spustit globální herní projekt. Byla to věc, na které jsem průběžně makal dva a půl roku. Funkcionalitu jsem měl připravenou na jedničku. Věděl jsem, jak bude nastavený obchodní model. Měl jsem zaplacenou a připravenou grafiku, některé potřebné programovací skripty. S tím, co jsem měl v ruce, jsem mohl jít klidně za investorama. Já ale investice měl, takže jsem nechtěl dávat % někomu jinému. Projektu jsem samozřejmě věřil a i v tom nejhorším scénáři jsem viděl solidní zisk. Takže jsem začal hledat programátora. Jednoho jsem našel a následovali debaty o ceně. Už nevím, jestli to byl on nebo já, ale někdo z nás navrhl podíl na projektu. Myslím si, že to byl on, ale to není zas tak důležité. Já si to nechal projít hlavou a moc se mi do toho nechtělo. Každopádně po dlouhých úvahách jsem byl nakonec rád, že netáhnu takto velký projekt sám, že nemusím řešit programátorskou část a mám čas na jiné věci.

Projekt se pár měsíců vyvíjel, ale nakonec úspěšně. Dotáhli jsme to do beta testování, nahodili na server a běželo to. Začal jsem s propagací, která měla horší odezvu než jsem čekal. To ale nebylo nejhorší. Do pár dnů mi dokonce přišel email od samotného Blizzardu, že to, co jsme spustili, odporuje jejich podmínkám a ať to okamžitě zrušíme. Neměli jsme nelegální server na World of Warcraft, ale sázkový systém pro hráče jedné hry. Mohli jste si vytvořit účet, vložit peníze, hrát a když jste vyhráli, obrali jste o peníze protivníka. Vcelku jednoduché, ale dost zábavné. Po prvotní kritice projevilo hned několik hráčů zájem, bohužel Blizzard byl nemilosrdný a mně došlo, že se pohybujeme na tenkém ledě a že jsem to vlastně celý posral. Kdybychom celý tento kolotoč spustili o fiktivní body, neporušili bychom nic. Jakmile jsme zakomponovali cash systém, bylo to riziko. Jenže o fiktivní body by to nikoho nebavilo. Vcelku banální věc, kterou jsem řešil na začátku projektu. Dokonce jsem psal i Blizzardu, jenže ti mi při přípravě projektu neodpověděli. Takže jsem vycházel z toho, co jsem našel na netu. A když jsem to vše sesumíroval, vyšlo mi to v pořádku.

Celý tento příběh má upozornit na jediné – projektu jsem 100%, měl jsem ho připravený po mnoha stránkách a nikoho jsem jako podílníka nechtěl. Nakonec jsem programátora přijal za podíl na projektu, ale ne kvůli úspoře peněz, ale kvůli většímu počtu osob v projektu. Takto velkou věc nemůže táhnout jeden člověk. A v tom jsem měl určitě pravdu. Každopádně jsme doplatili na legálnost celého projektu a vše šlo do kytek. Programátor z toho vyšel úplně nejhůř, protože tomu věnoval dost času. To mě na tom celém štvalo asi nejvíc, i když samozřejmě věděl, že to nemusí vyjít. S tím do toho projektu šel. Ať už byly moje úmysly jakkoli dobré, tak to stejně skončilo neúspěchem.

V čem vidím možnost

První možností je, že se s dotyčným dobře znáte a jdete do projektu od začátku spolu. Scházíte se a řešíte vše společně. I zde je mnoho rizik, ale už jen to že vše vymýšlíte spolu od začátku, je dobrý start. Ať už jste vývojář nebo ten koho projekt napadl, na tom nezáleží. Oba byste o projektu měli vědět vše a oba byste měli hledat řešení. Být v tom namočení spolu. Špatný přístup je ten – já mám tady tohle a ty programuj. To vás samo o sobě odlišuje – vy jste ten hlavní, co vše vymýšlí a ten druhý to jen vyvíjí. Tenhle přístup je špatně. Běžte to spolu vymyslet, a vy pak dělejte propagaci a programátor bude vyvíjet, ale pracujte na tom společně.

Druhá možnost je ta, že projekt rozjedete sami. Vytvoříte si tým lidí, které platíte. Po třech měsících můžete zjistit, že jeden člověk z vašeho týmu váš produkt žere a dejchá za něj. A to je ideální šance navrhnout mu, jestli do toho nepůjde s váma. Víte, jakou práci zvládne. Víte, že se mu produkt líbí a chce se na něm podílet. A to je dost dobrý předpoklad k tomu, aby se stal partnerem.

V těhle dvou možnostech vidím naději toho, že to může celé fungovat.

 

Největší zabiják konverzního poměru


Hledal jsem dárky na Vánoce a úplně mě zarazilo, jak jsou firmy ochotné investovat do PPC nebo optimalizace určitých kategorií, přitom mají v nabídce jen pár produktů. Hledám svetr, kliknu na PPC a dostanu se do eshopu, a najednou vidím v nabídce jen 3 svetry. Šance, že se mi jeden z nich bude líbit, je hodně malá. Přitom eshop utratil za moji návštěvu nejméně 6 Kč, spíš víc. Dost mě to zarazilo, tak si projedu odkazový profil eshopu a dokonce jsem našel některé odkazy vedoucí přímo na kategorii pánských svetrů. Nebylo pochyb, že šlo o placené odkazy. Nevím, jestli si to dělá majitel eshopu svépomoci, nebo má agenturu na linkbuilding, ale tohle řešení je vyhazování peněz z okna. Optimalizovat kategorii, kde skoro nic není, a ještě utrácet za PPC, je známka absolutní neprofesionality.

Chtěl jsem nakoupit, potřeboval jsem svetr, a jestli by bylo tlačítko koupit velké nebo malé, jestli by byl eshop přehledný nebo ne, by mě v nákupu asi neodradilo. Malá nabídka byla v tu chvíli největším zabijákem konverzního poměru. Trošku mi přijde, že lidé hodně čtou a málo přemýšlí. Velký výběr je základ u eshopu s oblečením.

Proč začit programovat v Ruby on Rails?


Když jsem se na začátku roku 2015 rozhodl opustit pozici freelancera v segmentu internetového marketingu a vrhnul se na vývoj aplikací, tak si někteří moji kamarádi klepali na čelo. Skoro 5 let budovaná pozice na trhu, dobré jméno, kvalitně odvedená práce, poptávka větší než jsem byl schopen zvládat a plat, na který budu asi dlouho vzpomínat. Ten příběh mohl pokračovat minimálně ještě několik let.

Už v patnácti letech jsem vykřikoval do světa, že programování je práce budoucnosti. Ne právník, ne lékař, ale programátor. Teď o 10 let zpátky se moje slova jenom potvrzují. Kvalitních vývojářů je málo a nevypadá, že tomu bude v příštích několika letech jinak. Když jsem hledal kvalitního programátora pro svoje vlastní projekty, tak to vždy skončilo neúspěchem, nebo ne úplnou spokojeností. Např. mě nebavilo aplikaci pořád dokola procházet a nahlašovat chyby, které již dávno měly být opravené. Když vám programátor napíše – „je to opravené, zkuste to“. A vy následně zjistíte, že to opravené není a vracíte to zase zpátky. On to opraví a směle vrátí opět s komentářem – „no jo, zapomněl jsem středník, zkuste to teď“. Ta lepší varianta je, že už to opravdu běží. Když se ale stane, že ne, tak už to vytočí i mě – a to jsem hodně velkej kliďas. Platíte si programátora, ale vy jste v roli přičmrdovače, který všechno testuje a kontroluje. Bere vám to čas, který by vám to brát nemělo. Idea, že si děláte svoji práci a během večera zkontrolujete pokrok programátora a aktuální stav s úsměvem, byla hodně vzdálená. Ať to byl ten, nebo onen. Nebo programátoři, s kterýma jsem přišel do styku během své marketingové činnosti. Jo pamatuju si jednoho super, ale ten si odboural záda a nevím, jestli ještě dělá.

Výsledkem bylo, že jsem měl v Trellu spoustu nápadů co chci tvořit a jak to chci tvořit, jenže jsem neměl vývojáře. A když už jsem se do něčeho pustil, šlo to velmi pomalu a musel jsem u toho 100% asistovat, takže jsem neměl čas vydělávat peníze na druhé frontě internetového marketingu, kde jsem měl práce tolik, že jsem nestíhal. Logickým krokem bylo najmutí člověka i na internetový marketing, jenže to mělo spoustu proti – hlavně kompletní zaučení, které by mohlo trvat několik měsíců s rizikem toho, že se na to dotyčný potom vykašle.

Začnu programovat. Ale v čem?

Všechny pro a proti vyústily v jediné – začnu programovat. To totiž bude řešit všechno. Jenže v čem? Dříve jsem programoval v PHP, ale to bylo ještě funkcionálně a 10 let zpátky. Za poslední roky jsem občas něco málo dělal opět v PHP. Zkoušel jsem Codeigniter, Nette a Laravel. Jenže jsem začal hodnotit situaci – PHP je asi nejrozšířenější, ale podle posledních průzkumů nemá tak slibnou budoucnost. Druhou nevýhodu jsem viděl ve velkém množství frameworků, což strašně štěpí trh. I když jednotlivé frameworky vychází z PHP, tak se více či méně liší. Tzn. není to o tom dělat v PHP, ale vybrat si jeden, maximálně dva frameworky v PHP a v nich dělat. PHP se tak dostalo do fáze „když nic lepšího nenajdu, tak u něj zůstanu“, což není zrovna moc přesvědčivý začátek.

Začal jsem tedy hledat. Javascript si pamatuju ještě z dob, kdy to byl čistý javascript. Dneska už jsou frameworky, na kterých můžete postavit celou aplikaci. Jenže mi přijde, že je na trhu JS tak trochu chaos. Vývoj jde hodně dopředu a věci se až moc rychle mění. Backend bych na tom nestavěl už jen z důvodu obav o kompatibilitu v budoucnu.

Chvílema jsem zavadil i o Javu, ale neznám webovky, který běží na Jave. Těžko tedy můžu něco hodnotit, navíc škola mi ji vcelku znechutila.

Pak jsou jazyky jako C, C++, Perl, Visual Basic, o kterých nemám moc přehled. Ale na první pohled to nejsou primárně webové jazyky, a tím pádem mi nevyhovují. Byl by to hodně velký skok do neznáma s nejistým výsledkem.

Pak nám tu všeho všudy zbyl už jen Python a Ruby. Začal sběr materiálů, mnoho a mnoho přečtených článků a porovnávání syntaxe. Ruby nakonec zvítězil, ale kdybych si měl vybrat mezi PHP a Pythonem, volil bych Python. Z mnoha různých důvodů, které v tomto článku rozebírat nebudu, vyšly Python a Ruby lépe než PHP.

Takže jsem se nakonec ustálil u jazyka Ruby, respektive jeho frameworku Ruby on Rails. První kroky vedly na TryRuby.org, kde okamžitě zjistíte, jak moc super jazyk Ruby je. Doporučuju starší Intro do jazyka Ruby na blogu Karla Minaříka. Co musím vyzdvihnout je asi nejlépe napsaná kniha o programování, kterou jsem kdy četl. Jedná se o RailsTutorial.org. Celých 12 kapitol je podrobně rozebraných na konkrétních projektech. Oproti oficiálním Rails Guides je to mnohem detailnější zdroj a řekl bych i více aktualizovaný. Některé problémy bych v současnosti řešil jinak, ale nejde o to programovat podle autora, ale osvojit si Railse, což kniha dokonale splnila. A navíc je v online verzi zdarma.

První kroky s Ruby

Učit se úplně něco nového od píky je vždycky výzva. Já měl výhodu, že jsem s programováním nezačínal. Analytické a logické myšlení, znalost MVC a další věci jsem měl osvojené, takže šlo o to naučit se syntaxi Ruby a koncept Railsů.

Ruby on Rails vychází z jazyka Ruby. A teď zpětně musím konstatovat, že je to opravdu krásný jazyk. Pojďme si dát pár základních příkladů.

'Tohle je můj pes'.include? 'pes'
#=> true

Jak vidíte, Ruby syntaxe funguje více ve větách než v rovnicích. Kód se dá do češtiny přeložit takto – obsahuje řetězec ‚Tohle je můj pes‘ řetězec ‚pes‘? Ano, výsledek true. Další příklad.

['pes­­', 'kocka', 'hus­a', 'krav­a', 'ovce­'].sort.last.upcase.include? "PE"
#=> true

Tento příklad je složitější, ale i laik bez znalosti syntaxe ví, o co jde. Vezmeme pole s pěti zvířaty, seřadíme je podle abecedy (sort), načteme poslední (last), obsah tohoto pole uděláme velkými písmeny (upcase) a zeptáme se – obsahuje toto pole (include?) řetězec „PE“? Ano, obsahuje. Vše se nám krásně vejde na jeden řádek. V praxi většinou máme pole uložené v proměnné, např. zvirata, takže kód pak vypadá takto:

zvirata.sort.last.upcase.include? "PE"
#=> true

Pokud budeme funkci volat vícekrát a s proměnným vstupním polem, pak je lepší vytvořit funkci. Ruby nás navádí k tomu, aby kterýkoli kód, který se opakuje minimálně jednou, byl automatizovaný přes funkci. Ve zkratce je to DRY neboli Don’t Repeat Yourself.

def je_posledni_pes(pole)
  pole.sort.last.include? "pes"
end

domaci_zvirata = ["kocka", "pes", "andulka", "slepice"]
je_posledni_pes(domaci_zvirata)
#=> false

Funkce je_posledni_pes() hledá v posledním chlívku vstupního pole řetězec „pes“. A jelikož máme v daném příkladu slepici, která je po seřazení jako poslední a řetězec „pes“ neobsahuje, je výsledkem false.

Kombinace Ruby a Rails je mnohem silnější

I když je jazyk Ruby kompletně objektový, pořád by nám tvorba běžné aplikace (např. redakčního systému) trvala zbytečně dlouho. Proto byl vyvinut framework Ruby on Rails, který nám usnadňuje práci. Pokud dodržujeme konvence a styl Ruby on Rails, potom nás konfigurace v podstatě nezajímá a vše pojede dle očekávání. Rails ví, co chcete udělat, a jak to chcete udělat. A podle toho vše nastaví. V praxi vám to šetří spoustu času. A největší výhodou je, že lze zakomponovat jakoukoli nestandartní věc. Rails vám to dovolí, jen je potřeba větších znalostí než těch základních.

Vaším hlavním nástrojem při programování v Railsech je OS na bázi linuxu, textový editor (např. Sublime Text) a příkazová řádka. Linux je problém, který hodně lidí odradí. I mě to zpočátku odrazoval a pokoušel jsem se Railse rozchodit na Windowsech. Po asi 14 dnech pokusů jsem to vzdal. Zjistil jsem totiž, že aktuální verze ještě nebyla dostatečně zkompilovaná pro Windows a něco v ní nefungovalo. Takže jsem nainstaloval VirtualBox, Ubuntu 14.04 a šel do neznámého prostředí. S použitím manuálu na GoRails.com jsem zprovoznil vývojové prostředí do 1 hodiny. Nevadí, že jsem nevěděl, co jednotlivé řádky při instalaci znamenají. Proč tam jsou instalační cesty takové, jaké jsou. Pro vás jako programátory je to vlastně jedno, minimálně do začátku. A nakonec, když vývojové prostředí funguje, začnou fungovat i ostatní věci a to hodně rychle. Najednou máte spuštěné Hello World a jste nadšení. Je to jen o něco málo náročnější než instalace balíčku PHP+Apache+Mysql na Windows. Jen než si zvyknete na příkazovou řádku, chvíli to potrvá.

O RoR se toho dá napsat hodně a jednotlivé věci třeba shrnu v dalších článcích, ale pokud jste na začátku a rozhodujete se, jestli se RoR naučit, pak tu pro vás mám můj názor na silné a slabé stránky.

Silné stránky

  1. Jazyk Ruby – je přehledný, šetří kód a nepoužívá středníky, což vede k menší chybovosti.
  2. Nadprůměrně dobrá dokumentace, asi nejlépe napsaná kniha o programování a nadprůměrně dobrá komunita.
  3. Framework Ruby on Rails je vhodný jak pro malé, tak i velké projekty. Dobře navržená aplikace, ke které vás RoR vede, je dobře škálovatelná do budoucna.
  4. Konvence mají přednost před konfigurací – a to je alfa omega všeho. Zvyšuje to produktivitu práce. Při přebírání projektu je velké šance, že předchozí programátor pracoval správně.
  5. Generátory v příkazové řádce – velmi oblíbený nástroj. Jakmile si příkazovou řádku osvojíte, tak nebudete chtít manuálně vytvářet .html a .rb dokumenty v Sublime Textu. Navíc k přístupu do databáze se používá hlavně příkazová řádka. Při spuštění příkazu rails generate scaffold animal type:string legs:integer se nám vytvoří kompletní struktura (databáze s 2 atributy + automatickým id, created_at a updated_at) + model Animal + AnimalController + všechny příslušné soubory Views včetně SCSS + základní operace jako index, show, edit, create a update. Bez jakékoliv znalosti když naroutujeme index, vypíše se nám seznam zvířat.
  6. Gemy – proč znovu vymýšlet ukládání a nahrávání obrázků? Tohle už někdo dávno vyřešil, dokonce mnoha odlišnými způsoby. Stačí jen vybrat ten správný gem, implementovat ho a jedete dál. Jen se snažte aplikaci nezaplnit zbytečnými gemy.

Slabé stránky

  1. Linux – musíte začít pracovat v Linuxu, což je pro neznalé další část, kterou se musí naučit ovládat. Nemusíte být mistři na Linux, ale už jen samotný pohyb v novém prostředí, instalace a otevírání souborů, to vše jsou věci, které dokážou odradit.
  2. Hosting – několik českých hostingů existuje, ale já si vybrat nedokázal (např. railshosting.cz nepodporuje Postgresql databázi).
  3. Deploy produkčního serveru – to navazuje na bod 2. Musíte umět spravovat vlastní server nebo VPS, což znamená umět nastavit produkční server se vším všudy. Opět se dá najít spoustu návodů, ale chce to vysedět.
  4. Málo českých vývojářů – těch, co dělají v RoR, u nás moc není. To znamená, že se bez angličtiny neobejdete.
  5. V Čechách je malý trh pro RoR. To je samozřejmě způsobené popularitou. Možná mnoho lidí uvažuje mít aplikaci postavenou v RoR, ale nenajdou programátora, nebo firmu. Mnohem jednodušší je poptat PHP. Tam najdete někoho hned. A fungovat to bude taky, tak co. Každopádně v zahraničí je poptávka obrovská a RoR programátoři si přijdou na mnohem větší peníze než PHP programátoři.

Finish

Na závěr bych dodal, že Ruby není kouzelný jazyk. To, co uděláte v Ruby, uděláte pravděpodobně v jakémkoli jiném jazyce. Otázkou spíš je, jaká řešení se nabízejí, jak vypadá výsledný kód, jak obtížné bylo kód vymyslet a kolik systémových prostředků kód bere. Např. dle posledních testů rychlosti PHP frameworků můžete vidět, že rozšířené a oblibené frameworky jako Zend, Symfony, Cake a Laravel jsou na tom skoro nejhůř. Ale než aby se vývojáři snažili přesedlat, radši investují více peněz do výkonu serveru (nebo jejich klienti).

Největší boom propagace RoR je dávno pryč. Současně je to stabilizovaný framework, který se stále vylepšuje. Silné a slabé stránky jsem popsal ze svého pohledu. Co vadí mně může naopak jinému vyhovovat. Ale pokud si všimnete, tak na samotném frameworku RoR nevidím nic negativního. Všechny slabé stránky vychází z malé rozšiřitelnosti v Čechách a z Linuxu. Pokud se s tímhle smíříte, potom vám nebrání nic v tom, abyste začali se studiem.

Jak funguje lišta „souhlasím s cookies“ v praxi?


Do 30. září museli všichni webmasteři vydělávající na Adsense nasadit lištu souhlasím s cookies na svoje weby. S touhle blbostí přišla EU. Ale Google nechtěl riskovat, a tak to začal vyžadovat po svých partnerech. Kdyby to Google nevyžadoval, tak to pravděpodobně nevidíme na žádném webu. Nikdo samozřejmě neví, jak se Google k situaci postaví, pokud na webu lištu nemáte. Jenže kdo chce riskovat svůj Adsense účet, že? A tak můžete dnes vidět masivně na každém webu souhlas s cookies. Nahoře, dole nebo floating okno – ať jdete kam jdete. Otravuje to v podstatě všechny a zakázat to jde pohodlně adblockem. Mě osobně tohle otravuje ještě víc než reklama, protože to zakrývá obsah.

Pokud by ten zákon smysl dával, tak současná implementace lišty nic neřeší. Dokud uživatel neklikne na Souhlasím, tak by web neměl sbírat žádné údaje. Jenže se tak neděje. Je to jen další divadlo a nesmyslné nařízení, které se tak nějak obešlo. Lištu na web dáte, ale nemá vliv na funkčnost webu. Uživatele, které má tohle nařízení chránit/informovat, namísto toho otravuje. Měl jsem možnost vidět jak k tomu přistupuje velký laik a ten si mimochodem lišty ani nevšiml. Prostě web používal bez souhlasu.

Na tomhle příkladu je jasně vidět, že když je debilní myšlenka, tak je i debilní řešení.