Jak prakticky na vlastní AOS ?

kompjutrV jednom z dřívějších článků na WinPes se rozproudila nedávno vcelku pěkná diskuse. Jde o jakýsi vhled do technických možností pro stavbu AOS – jaký počítač vybrat a tak dále. Mě se ta diskuse líbí a mám s tím určité zkušenosti, takže bych se o ně dneska rád podělil. A možná se ta diskuse přenese pod tento – novější – článek. Poznámka: polemika je povolena a vítána, nemám patent na rozum.

Čili nyní ty neustále se opakující otázky a moje odpovědi k nim:

Obchodní platforma nebo vlastní skripty?

Určitým specifikem (a vítaným) tady na winpes.cz je fakt, že se tu sdružují lidi, co dávají přednost napsání vlastního engine na obchodování před zakoupením a provozováním nějaké prověřené platformy. Proč to tak je? Nevím, můžu se jen domnívat, že

  • jste nenašli obchodní platformu, co umí obchodovat více tickerů najednou (pro devadesátku kritické)
  • jste nenašli obchodní platformu, co umí obchodovat na konci obchodní seance, resp. v poslední minutě (opět, pro devadesátku kritické)
  • spíše věříte vlastnímu kódu než cizímu
  • profi platforma je drahá nebo zbytečná pro Váš styl obchodování
  • jste prostě hračičkové a chtěli jste se něco naučit

Myslím, že všechny tyto důvody jsou v pořádku. Můj názor je: pokud to alespoň trochu umím, je napsání vlastních skriptů pro obchodování tou správnou cestou.

Windows nebo Linux?

Upřímně? Tohle začíná být poslední dobou docela jedno. Oba systémy lze nastavit a vyladit tak, aby nepadaly, v obou lze programovat, stahovat z internetu data a provádět obchodní příkazy. Co víc si přát.

Podstatná výhoda je v ceně – Linux můžete mít legálně zdarma, čili tato varianta je na pořízení o kousek levnější. To může být rozhodující hlavně pro začátečníky bez většího vstupního kapitálu.

PC doma nebo virtuální server?

Zažil jsem obě fáze, ale virtuální profesionálně hostovaný počítač je z mého pohledu varianta lepší. Jednak Vám doma nehučí další stroj, ale hlavně ten hosting se postará o napájení bez výpadků a konektivitu bez výpadků.

Když nad tím přemýšlím, pak jediný důvod, který by mě opravňoval v současné době pouštět příkazy na burzu z domácího PC by mohla být paranoia – přece jen PC “někde” může vidět někdo další, že.

Jak počítat indikátory?

Ohledně klouzavých průměrů – tam je to asi jedno, ale pokud jde o (relativně) složitější indikátory, jako je RSI, tak si myslím, že trader by se do programování výpočtu hodnoty indikátorů neměl nějak nutit. jednak je tam možné udělat chybu, ale hlavně: existují na to knihovny – například TA-Lib.

Zapamatujte si motto:

Správný programátor je především líný. Vždy se vyplatí položit si otázku, jestli už stejný problém neřešil někdo přede mnou.

Python nebo zbytek světa?

Pokud vím, existují tady na webu čtenáři programující ve kde čem:

  • Python
  • C++
  • C#
  • Java
  • JS
  • PHP
  • Visual Basic
  • a asi i další

Protože obchodování není z hlediska tvorby programů ani nějak extrémně složité, ani není nutná nějaká super rychlá odezva systému, tak přísahám, že to je jedno.

Pokud tedy v něčem programovat umíte, tak to použijte, pokud ne, tak se budete (nejspíš) rozhodovat právě mezi Pythonem a C#. Předpokládám, že k tomuto bodu se strhne diskuse, tak jen do mně.

Excel, Google sheets, Libre Office?

Excel, pokud testujete nebo děláte něco “doma”. Google se hodí pouze na sdílení výsledků s kolegy. Ono je samozřejmě hezké, že Google má funkci pro vyplnění historické ceny akcie přímo do buňky v sešitu, kontingenční tabulku anebo hezký graf tam ale neuděláte.

Pro Open/Libre Office jsem z hlediska vývoje AOS opravdu zatím žádné využití nenašel. Můžu se samozřejmě plést.

Smyčka nebo plánovač?

Když už “to” běží, existují v podstatě dva přístupy, jak zajistit obchodování v určitý čas (nebo při splnění podmínek):

  • buď jakýsi program běží neustále – ve smyčce – a hlídá ten čas (nebo ony podmínky) a pokud je potřeba, něco udělá (obchod, notifikaci přes SMS či email a podobně).
  • nebo se použije systémový plánovač (cron na Linuxu, Plánovač úloh ve Windows) a program se spustí periodicky v předem daném čase

Já mám upřímně řečeno zkušenost s oběma přístupy a nemůžu říct, že by jeden nebo druhý byl nějak lepší či horší. Tady to bude asi o osobních preferencích.

Co je ale správné – a co v diskusi zaznělo – je pravidelně kontrolovat funkčnost systému nějakou nezávislou aktivitou. Například “hlavní” program zapíše něco každou minutu do logu a “kontrolní program” po dvou minutách kontroluje, jestli bylo něco zapsáno. Pokud ne, je jasné, že ten “hlavní” program vytuhnul a je dobré jej restartovat. O což se ten “hlídač” v ideálním případě postará sám.

Interactive Brokers Gateway nebo cokoliv jiného?

Interactive Brokers Gateway plus hlídač, jestli běží. Tohle se osvědčilo mě a asi i spoustě čtenářů. Pokud někdo obchoduje přes jiné rozhraní, pochlubte se.

Data od IB, IQFeed, IEX nebo jinde?

Logika tak trochu velí mít data od stejné firmy přes kterou obchoduji, ale může to být

  • komplikované (omezení v počtu dotazů na data za nějakou časovou jednotku)
  • drahé (když chci sledovat stovky tickerů například)
  • pomalé (pokud broker nepočítal s takovým využitím dat které já potřebuji)
  • nestabilní (když se pokouším data zároveň stahovat a do toho obchodovat)
  • těžké na naprogramování

Dovedu si docela dobře představit, že klidně někdo vystačí (pro devadesátku) jen s daty od IEX nebo Alphavantage; v tom případě pochopitelně ušetří.

Jinak na to vyhraněný názor nemám.

Databáze MySQL nebo jiná?

Informace, které jsou potřeba k obchodování je samozřejmě potřeba někam ukádat. Možností je přitom celá řada, ale nejčastější dvě – a nejuniverzálnější – jsou uložení do souboru nebo uložení do databáze.

Já jsem pro uložení do databáze. Jednak kvůli tomu, co v komentáři napsal Tomas, a jednak kvůli optimalizaci přístupu do databáze při jejím vícenásobném použití. Česky a zjednodušeně – když se do souboru pokusí zapsat dva programy najednou, tak to selže na nějaké chybě, kdežto databáze dokáže tento konflikt řešit (oběma způsoby, buď že zvítězí rychlejší, nebo pomocí fronty).

Databáze MySQL nebo jiná?

Samozřejmě data je potřeba někam ukládat. Při například 100 tickerech a potřebě počítat 200-denní průměr skončíme s potřebou někam uložit 20000 řádků dat. To je z hlediska dnešních databázových systémů tak málo, že to zvládne prakticky jakákoliv databáze, včetně těch zadarmo.

Dobré zkušenosti mám v tomto ohledu s

  • MySQL a jejími klony
  • Firebirdem
  • PostgreSQL
  • MSSQL

Jen malá poznámka – Microsoft uvolnil verzi svého SQL serveru pod Linux – včetně té bezplatné verze Express. Je to tak.

Závěr

Toto tedy byly nejčastější otázky a moje názory na ně.

Pokud by Vám tady chyběla nějaká otázka, tak ji prosím napište do diskuse, já přidělám příslušný odstavec, napíšu svůj názor a můžeme debatovat Mrkající veselý obličej

Příspěvek byl publikován v rubrice Nezařazené. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

43 komentářů u Jak prakticky na vlastní AOS ?

  1. Petr napsal:

    Jaké máte zkušenosti se stabilitou IB GW na Win? Mě pravidelně po několika dnech spadla, typicky třeba přes víkend kdy se nedokázala připojit na IB servery a v pondělí už to nerozchodila. Teď to řeším automatickým rebootem každý den, což sice fachá, ale není to úplně nejhezčí řešení. A ani ten reboot není 100%, už jsem musel nahazovat VPS i ručně. Daleko víc by se mi líbil systém s „nekonečným“ uptimem, ale ta GW mi to kazí.

  2. mety napsal:

    Já jako začátečník jsem databázi prozatím vynechal. Data ukládám do .txt ve formátu json a pak je načítám. U databáze jsem nějak nepochopil kde ty data vlastně jsou, tak mi pro uchopení problému přišlo jasnější ten soubor přímo vidět, popř. stáhnout. Historie 100 tickerů pro počítání indikátorů má asi 8 mb, což si nemyslím, že by nějak systém zatěžovalo. Ale počítám s tím, že časem na databázi přistoupím (postgreSQL).

    • Tomas napsal:

      Pri pouziti databaze mas mnohem vetsi moznosti jak s daty pote nakladat – predevsim muzes na databazi posilat ruzne dotazy a pote zpracovat ocekavany vysledek. Napriklad pro devadesatku – stahnu data, ulozim do databaze, pote pomoci kontrolniho skriptu provedu serii dotazu – pocet radku v tabulce (mam vsechna data co potrebuju?), pocet tickeru v databazi, pocet historickych cen pro jednotlive tickery (mam stahnutou cenu pro kazdy den?), komparace cen mezi jednotlivymi poskytovateli (stahuju data ze 3 ruznych sluzeb a porovnavam ceny, tolerance 5%). Jednoduse tak muzes reagovat na ruzne situace a nechavat si treba posilat report na mail.
      Dalsi vyhoda je ze do databaze muzes ulozit prakticky vsechno (i ruzne objekty) a provest rychly backup/restore.

      • admin napsal:

        Díky za koment. Tohle plus zmínku o paralelním přístupu zapíšu rovnou do článku – pro začátečníky bude určitě přínosné.

  3. jb5 napsal:

    Zdravím všechny,
    předně bych rád poděkoval autorovi tohoto inspirativního blogu. Objevil jsem ho asi před 1,5 rokem a nakoplo mě to, abych se začal učit programovat v C# (kdysi dávno jsem ve škole programoval v Pascalu a pak si hrál v PHP, ale to je skoro 15 let zpátky). Začátky v C# byly krušné, nicméně časem jsem se do toho dostal a podařilo se mi Devadesátku rozchodit. Jak už zde na blogu bylo zmíněné, nejtěžší bylo propojení s IBGW a hlídání všemožných chyb, správnosti dat atd. Ale jelikož jsem nebyl zvyklý psát objektově, tak jsem to programoval klasicky procedurálně. Jak programu přibývalo, začalo se množit opakování toho samého kódu a tak jsem se začal zajímat o objekty. Poslední týdny tak trávím (když je čas a nálada) tím, že přepisuju Devadesátku do objektů. Na tom je nejtěžší správný návrh objektů a vazeb mezi nimi, s čímž nemám žádné zkušenosti a tak objekty neustále vylepšuju a dokola přepisuju :-) Ale vypadá to, že cíl je už na dohled. Tolik tedy k programování – dá se to naučit, ale není to za týden.
    A teď se podělím s tím, jak to mám řešené já – třeba to někomu pomůže nebo mi naopak někdo poradí, jak něco udělat líp. Týká se to hlavně programování Devadesátky, ale některé postupy lze určitě aplikovat obecně. Programovací část jsem už uvedl – C# a Visual Studio 2017 (verze Community zdarma). Databáze MySQL (jednak jsem ji znal z dřívějška a zkoušel jsem i MSSQL, ale nevyhovovalo mi jejich Management Studio). V databázi mám tabulku tickerů, tabulku cen, kalendář obchodních prázdnin a zkrácených obchodních dnů, tabulku obchodních příkazů, tabulku pozic a log celého systému. Systém je postavený na samostatných konzolových aplikacích, které se spouští podle Plánovače úloh ve Windows. Snažím se kontrolovat všechny možné vstupy a správnost dat. Někdy mi to připadá, že jdu s kanónem na vrabce, ale je kriticky důležité, aby aplikace dělala přesně to, co má, nepadala a dokázala vypořádat s chybami. Loguju, co to jde :-) A pracuje to následovně:
    Watchdog – spouští se každý den v 5, 7, 9, 11, 13 a 15 hodin (zapomněl jsem uvést, že časové pásmo počítače je nastavené na EST, abych nemusel řešit přechody na letní/zimní čas). Watchdog zkontroluje připojení k databázi a k IBGW, zkontroluje pozice v IB a porovná se záznamy v databázi a spustí stahování dat. Navíc při prvním spuštění v 5 ráno zjistí, jestli je obchodní den (bere v úvahu obchodní prázdniny a zkrácené obchodní dny z databáze), podle toho nastaví v Plánovači úloh spuštění obchodování na 15:59, 12:59 nebo vůbec. Dále porovná seznam tickerů v databázi se seznamem S&P100 na ishares.com. Případný rozdíl pak řeším ručně. Pokud je něco v nepořádku, pošle mi mail.
    Další část je stahování dat. To řeším v cyklech po jednom tickeru. Nejprve si vytvořím seznam posledních 199 obchodních dnů (jedu od dnešního dne zpět a vynechávám víkendy a obchodní prázdniny). Potom zjistím, pro které tickery nemám data (při prvním spuštění to jsou všechny, u dalších se už stahují jen pro ty, které v přechozích průchodech nebyly úspěšně staženy). Jako hlavní zdroj beru IB, záložní pak IEX, Barchart, Quandl a AlphaVantage. Ty poslední dva moc nedoporučuju, mívají celkem často vynechané dny, ale poté, co přestaly být použitelné Yahoo Finance a Google Finance to byly první alternativy, co jsem naprogramoval, tak je mám v systému doteď. A princip je takový, že pokud mám data z IB, uložím je do databáze (to by měla být nejběžnější varianta), pokud ne, použijí se data z IEX, pokud je chyba i v nich, použije se Barchart atd. Výsledkem je ideálně tabulka cen, kde každý ticker má 199 záznamů. Nakonec pošle mail s reportem.
    Poslední částí je samotné obchodování – v 15:59 (nebo 12:59) se podle Plánovače spustí obchodní část – tu mám rozdělenou na dvě samostatné aplikace – ta první načte ceny z databáze, načte aktuální ceny z IB, spočítá indikátory, vybere kandidáty, uloží obchodní příkazy do databáze a spustí tu druhou, která pošle příkazy a vypořádá se se záplavou zpráv z IB a podle toho upraví příkazy a pozice v databázi. Na závěr pošle mailem report.
    To je co se týče systému asi vše. Další nezbytnou věcí pro mě je IBController, který používám pro ovládání IBGW. Jak už bylo zmíněno, na Windows po nějakém čase může IBGW přestat pracovat, tak to jako ostatní řeším každodenním restartem stroje. Docela užitečné je zálohovat si databázi – každý den po skončení obchodního dne se skriptem uloží databáze do zkomprimovaného souboru a nahraje na OneDrive (časem to ještě třeba posichruju odesláním na mail). Co se týká vzdálené správy, používám Teamviewer (ale to je spíš kvůli tomu, abych věděl, co se děje s Windows – po aktualizacích atd.). Poslední poznámku bych měl k monitoringu samotného počítače. Osvědčila se mi služba Pulseway, pro dva počítače je zdarma, dá se nastavit spousta alertů, mají aplikace pro mobil a zatím jsem se nesetkal s problémem. Toť asi vše.
    Zatím jsem ve fázi ladění a průběžného testování, ale už to začíná být použitelné a snad to co nejdřív překlopím na ostrý provoz (samozřejmě po pečlivém otestování). Třeba to někomu pomůže, případně budu rád, když někdo přidá lepší řešení a popostrčí mě i ostatní správným směrem. Tož tak

    Honza

    • admin napsal:

      Ahoj Honzo,

      moc díky za inspirativní příspěvek. Jak je vidět, máš to velice promyšlené. Kdybych to měl nějak připomínkovat, pak bys dostal jedna mínus ;-), ale ber to jako subjektivní názor.

      Proč jedna mínus?

      * „Jako hlavní zdroj beru IB, záložní pak IEX, Barchart, Quandl a AlphaVantage“ – střílím teď z hlavy, ale nejsou data IEX a AlphaVantage tytéž?
      * Databáze MySQL (jednak jsem ji znal z dřívějška a zkoušel jsem i MSSQL, ale nevyhovovalo mi jejich Management Studio – to je samozřejmě o preferencích, já to mám třeba naprosto naopak
      * „Co se týká vzdálené správy, používám Teamviewer“ – zbytečné, RDP by měo stačit.

      ALE!!! Žádná z těchto věcí neovlivní výsledek, tzn. máš to „správně“, rozhodně do toho nevrtej například změnou databáze – to by byla spousta práce za málo muziky

      Ještě jestli můžu dotaz: Čím loguješ? Vlastní udělátko, nebo něco hotového ?

      • jb5 napsal:

        Děkuji za reakci,
        že IEX používá data AlphaVantage jsem nevěděl. Nicméně IEX jsem přidal asi před měsícem a zatím jsem problém nezaznamenal (navíc je to záložní zdroj, takže v 99,9% procentech případů se ani nepoužije). Dřív, když jsem ještě neměl účet u IB a tím pádem ani data, tak jsem pro testy používal právě AlphaVantage a Quandl a poměrně často byl problém – u Quandl občas chyběl některý den napříč (skoro) všemi tickery, za čas to spravili, u AlphaVantage se zase stávalo, že u některého tickeru nepřidávali několik dní zavírací ceny, pak se to zase spravilo. Je možné, že IEX bude dělat to samé… Pak by bylo lepší změnit prioritu a jako druhý použít Barchart. Ideální je samozřejmě profi poskytovatel dat jako používáš ty, ale to je pro samotnou Devadesátku asi zbytečný luxus.
        S databází souhlas – je to o tom, kterou kdo zná, která komu vyhovuje – účel splní každá.
        RDP samozřejmě stačí, výhoda Teamvieweru je, že nepotřebuje veřejnou IP a promapovaný port, tak jako RDP (pokud se nepletu) – zatím nemám virtuál a tak mi to běží na samostatném počítači doma.
        Co se týká logování – mám vlastní jednoduchou třídu Message a každá třída, která má něco logovat, si vytvoří její instanci a když je třeba něco zalogovat, tak volá metodu InsertMessage, která vloží do databáze záznam. Každá zpráva má svojí důležitost (info, warning, error) a text zprávy. Např. „INFO“,“Connected to IBGW.“

  4. VM napsal:

    Ahoj, mě by třeba zajímalo, zda používáte pro výpočet indikátorů adjusted data pro real obchodování nebo ne? Když tu vidím, že se tu zmiňuje IEX tak asi ano, protože neadjustovaná data na IEXu nevidím. Díky.

    • jb5 napsal:

      Ano, adjustovaná a stahují se každý den znovu, nenechávám je pro další použití.

      • VM napsal:

        Když jsem volil zda použít adjusted (myslím i o dividendy, což dělají skoro všichni) nebo ne, tak sem našel takový příklad, který mě přesvědčil, proč je nepoužívat:
        – Mám obchodní systém, který kupuje když Cena>SMA(3)
        Akcie se obchodovala za poslední dny za 4,5,4. Tedy průměr 4,33 a není nákupní signál. Firma dá dividendu 2 a data se adjustují na 2,3,2. Čtvrtý den se obchoduje opět za 4. Při neadjustovaných datech je SMA(3) stále 4,33, ale při použití adjustovaných je SMA(3) = 3 a systém nakoupí.
        Jak jsou na tom ostatní?

        • Tom napsal:

          Podle me jsou v tomhle pripade adjustovany data spravne. Pokud je ctvrty den po dividende cena 4, tak to prakticky znamena, ze cena ty akcie stoupla o 100% a ten system by to mel reflektovat.
          U 90ky je s adjustovanymi daty problem, ze typicky mas ulozenou cenu posledniho nakupu, ktera by se spravne mela po dividende adjustovat (dela to nekdo?). Stava se, ze 90ka po divi dokoupi, i kdyz realne cena akcie neklesla (klesla jen o cenu divi). Ale to je celkem drobnost, ktera nema na vykon moc vliv.

  5. Michal napsal:

    Je nějaký free zdroj dat dividend pro S&P500, nebo jde to nějak stáhnout z IB?

  6. nemozny napsal:

    Excel, Google sheets, Libre Office?
    Pro začátek je Excel dobrý, CSV se dá lehce vygenerovat a dá se posílat jako příloha mejlu a třeba Gmail to zobrazí jako tabulku, ale na nějaké kontingenční tabulky bych se vykašlal. Lepší je se naučit trochu Pythonu, pandas a pyplot a dokážu vizualizovat cokoli a jakkoli. Nebo použít rovnou https://github.com/quantopian/pyfolio

    Databáze MySQL nebo jiná?
    SQL databáze jsou přežitek. Pokud začínáte vytvářet AOS od nuly, pak se naučte raději NoSQL.
    Když si vzpomenu, jak jsem kdysi dávno 100x měnil strukturu tabulky, přejmenovával sloupce, přejmenovával proměnné, aby seděly s názvy sloupců… to nechcete.
    S NoSQL vezmu objekt – {date: „20180101“, ticker : AB, open : 1, high : 2, low : 3, close : 3} – a jak leží a běží ho vložím do (prázdné) databáze a zase vyselektuju. Nic víc.
    Overhead nula, performance asi stejná jako u SQL (ne, že by na tom záleželo).

    Momentálně mám v jedné DB komplet Quandl WIKIP (https://www.quandl.com/databases/WIKIP), dělá to celkem 15,377,198 dnů všech tickerů.
    Query na kompletní historii jednoho tickeru
    db.Quandl.find({ticker : „A“})
    trvá 92 milisekund. Vrátilo se mi 4611 dnů.
    Ale je pravda, že v takovém objemu už je potřeba vytvořit index na ticker a date.

  7. nemozny napsal:

    Ještě jsem chtěl říct, abych zahájil flame ohledně toho jazyka, že bych si v prvé řadě udělal obrázek, jaký je stav knihoven pro výpočty indikátorů, stahování EOD dat, práci s DB, případně už hotové obchodní systémy na githubu, od kterých by se dalo odpíchnout, a podle toho se rozhodnul pro libovolný jazyk. Osobně si myslím, že naučit se další programovací jazyk (pokud už nějaký znám a znám tedy základní principy) je otázka práce s googlem, stackoverflow a RTFM.
    (Flame) Podle mého názoru nemá valný smysl psát AOS třeba v Basicu, Pascalu (jauvajs) nebo C++ jen proto, že jej znám. Protože absence hotových knihoven znamená neskutečně víc práce, než se naučit třeba Python (používá hlavně akademická sféra, takže je dělaný pro blbce).

    První odkaz na guglu
    Python and Ruby are well established as easiest programming languages for beginners due to their simple and readable syntax. Java, C, C++, and JavaScript are also recommended due to their widespread use and tons of support material. Learning programming isn’t an easy task.

    • zolo napsal:

      To je jedna stránka mince. Na druhú stranu práve python a ruby nie sú strongly typed jazyky, tak je v nich omnoho viac miesta na nasekanie rôznych ťažko odhaliteľných chýb ako napríklad v jave, alebo c#. Programuje sa v nich síce možno ľahšie a rýchlejšie, lebo vynucujú menej pravidiel, ale má to svoju cenu a treba väčšiu disciplínu na dosiahnutie kvalitného výsledku.

      • nemozny napsal:

        Díky, absolutní souhlas. Mám k C# respekt (narozdíl od zastaralého C a C++), a chápu, že deklarace datových typů a podobné obstrukce jsou nutné pro compiler, a díky tomu běží binárka jedna radost (narozdíl od Javy).

        JS, Python, Ruby jsou moderní jazyky, ve kterých se opravdu příjemně píše, ale v určitém okamžiku člověk dojde k jejich omezením, která u C z principu neexistují.

        • nemozny napsal:

          Co se třeba stalo s Perlem? Že o něm už není vůbec slyšet? Před 10 lety to byl starší bratr Pythonu, který se teprve odněkud zjevil.

          Perl má tuny knihoven, friendly kód (dle vkusu), absolutní výkon (spustit složitější pandas kód v Pythonu je zoufalost), používal jsem i threading, no problem.

          Teď už je to jen samý python s těmi svými tabulátory, což je btw naprostá zhovadilost.

          • misch napsal:

            Co by se s ním stalo? Já ho například používám na všechno :). AOS i backtesty mi v perlu fungují hezky, a vlastně jediné co mě lehce irituje je nemožnost použít jednoduše API přímo od IBčka.

            A s těmi knihovnami souhlas.

            Kdybych se učil programovat dnes, tak si to už navrhnu v pythonu, ale jinak mi přijde nejrozumnější použít ten jazyk, ve kterém člověk denně pracuje.

            • nemozny napsal:

              Seš dobrej! Thumbs up! Perl je best.
              Vždycky se říkalo, než se Python spustí a začne žvýkat kód, tak Perl už je hotový. Pořád to platí.

              A jak to API řešíš?

  8. mety napsal:

    Je nějaký rozdíl ve stabilitě při provozu paper a live GateWay? Minimálně jednou denně mi GW spadne nebo ztratí připojení na IB API server a IBController to sám neopraví. Nemůžu přijít na důvod, proč to dělá. Je to problém poslední doby? Netestuju dlouho, ale mám pocit, že před pár týdny to jelo bez problému.

    • Cubecoop napsal:

      Já už jedu víc jak měsíc bez restartu čehokoliv. IB gateway 963 (live), moje appka, Windows Server 2016 v Azure (msdn). Přes noc gw ztratí spojení, ale moje appka to detekuje a snaží se z toho zotavit, tj. shodí připojení a zkusí to znova (několikrát za noc, možná zbytečně, ona i gw se z toho umí zotavit sama). Ráno je vše ok. Dřív jsem restartoval preventivně každý víkend, teď zkouším, co to vydrží na novém virt severu. A je to zatím úplně bezúdržbové, radši to zaklepu.

      • Petr napsal:

        Můžu se zeptat jak to vychází cenově na Azure, a na parametry VPS?

        • Cubecoop napsal:

          Cenově to vychází draho, skoro $53 měsíčně. 1 vcpu, 1.75 GB RAM, Server2016, public IP adresa, 128 GB úložiště. Mám to ale v rámci MSDN z práce, takže to neřeším.

          Před tím jsme měli nejpomalejší VPS z coolhousingu a jak jsem zmiňoval, tam jsem restartoval 1x týdně. Ale kvůli tomu, že se to celý nějak zpomalovalo, vlákna se mi probouzela čím dál později a vše trvalo déle. Výpadky spojení jsem ale neřešil. GW vždy v noci ztratí spojení, do rána jej obnoví. Moje appka pro jistotu zahazuje connectionu a znovu vytváří pokaždé, když dostane od gw takovýto error. Z tohoto hlediska to bylo stejně stabilní i na tom pomalém vps z coolu.

          • Petr napsal:

            Tak to je slušný, já mám $65 na rok, 4GB RAM, 40GB SSD. Je pravda že tam je MS SQL, apku mám nenažranou, data mi jedou realtime, má to GUI, takže jsem chtěl trochu prostoru. Je to ale lowcost, takže jak jsem psal, už se mi stalo že po rebootu VPS nenaběhla, a admini to řešit nechtějí, můj boj. Azure je určitě kvalitou jinde, ale ta cena, to bych vydělával jen na Microsoft.

            • admin napsal:

              Kde to máš, jestli to není tajný? 65 USD za rok je hodně slušný …

              • Petr napsal:

                http://virmach.com/ a vygooglil jsem si nekonečnou 50% slevu, takže za tuhle cenu už točím druhou sezónu…ale kde jsem ten kód našel, to už bohužel nevím, je to dávno. Mám pocit že teď už to tam taková pecka není, ale lowcostů je dost, určitě se dá najít jinde v těchto relacích.

  9. mety napsal:

    Zřejmě to má v rámci předplatného MSDN. Jinak 1xCPU 2GB RAM + MS server 2016 je asi za 18 EUR. Hodinová cena by měla být o chlup nižší než u AWS. Oproti Forpsi s Ubuntu za 1USD/měsíc je to o dost víc, ale asi se tam časem potkáme, protože rozdíl v práci s headless Ubuntu a MS se vzdálenou plochou je pro mně značný.

    • myk napsal:

      Vzdálená plocha je pohodlnější, ale:
      – za 3Eura za měsíc můžeš mít 3 servery – testovací, produkční, a jeden pro databázi
      – k databázi přistupuješ potom přes nějakého klienta (do PostgreSQL např. lezu pomocí PGAdmin) ze svého kompu, takže ke kontrole stavu pozic , historie tradů nepotřebuješ remote desktop
      – nové verze programů nahraješ pomocí FTP třeba v total commanderu
      – logy může číst přes ftp nebo si nahodíš webserver a budeš si je číst přes web
      – jediné, k čemu potřebuješ se připojit na server je spustit script/killnout script

      • mety napsal:

        Že se můžu k databázi připojit vzdáleně, mě nějak vůbec nenapadlo:D. Trapas. Z databáze jsem byl právě nejvíc nejistý. Čtení přes web mě napadlo taky. Momentálně používám putty, filezillu a vnc pro vizualní kontrolu GW.

        Přesto mi ale RD vychází jako jednodušší. Všechno to můžu dělat na jednom místě, ale je pravda, že poměr cena/výkon bude pro každého asi velmi individuální.
        Uvidíme, třeba si na stávající setup zvyknu.

  10. mety napsal:

    Zajímalo by mě jedno téma, které tu ještě nebylo zmíněno, zabezpečení. Například do modulu gateway controller se vkládají přihlašovací údaje do IB a do skriptu co ovládá databázi musím vložit přihlašovací údaje do databáze. Všechno to mám nahrané na virtuálním serveru, takže pokud se na něj někdo dostane, tak k tomu má přístup.

    • Honza napsal:

      A proto bys:
      – na IB mel mit pro tento ucel vytvoreny poducet s osekanymi pravy a omezeny jen na IP tveho VPS
      – VPS by mel mit co nejmene otevrenych portu
      – pokud uz mas nejake porty publikovane ven, mel bys je mit omezene jen na tve IP
      – na VPS bys nemel pristupovat z backup serveru ale opacne
      – VPS by mel pravidelne backupovat data nekam ven (RIP savana ci jak to bylo)
      – SSH pristup pomoci privatniho klice
      – appky by mely jet na non root uctu
      – pokud pouzivas VNC nebo jiny remote desktop protokol, tak jen pres SSH tunnel – protunelujes si na VPS zablokovany port s VNC na tvuj pocitac pomoci sifrovaneho spojeni a pak se pripojis s VNC klientem k sobe a ono to pristoupi skrz tunel na server
      – logy a vyhodnocovani logu – napr. fial2ban
      – monitoring – pro jednoduchost treba uptimerobot, deep monitoring aplikace?
      – updaty programu a os
      – notifikace – treba notka emailem pri prihlaseni na VPS
      – atd..

      • mety napsal:

        No potěš. To je teda zase další nálož na naučení. A když bych měl VPS s windows serverem? Tak to řeším stejně?:)

    • AnybodyElse napsal:

      co se týče IB Gateway, řeším to tak, že mám druhého uživatele s omezenými právy (může víceméně pouze investovat, ale nemůže ovládat účet u IB).
      Tyhle přístupové údaje mám uložené v databázi. Když spouštím controller, vytvořím BATku, kterým ho spustím a následně ji vymažu.

      Samozřejmě to není ideální, ale lepší, než mít jméno a heslo v souboru na disku.

Napsat komentář

Vaše emailová adresa nebude zveřejněna.