Příspěvky

286

Vývoj / Re:Jaké použít Financial API s historii cen akcií a stavu indikátorů?

« kdy: 08. 06. 2019, 07:38:27 »

Diky vsem za odpovedi.

Takze situace je takova, ze Google i Yahoo stopli svoje API protoze i oni meli data asi placena od jinych instituci a z toho ze jim lidi tahali data pres API nemeli prachy.

Ja jsem se dival na volna data k dispozici a zadna ocividne nejsou, nikdy neobsahuji veci jako je Book value atp.

Takze kdybych si to chtel platit, tak me tahle sranda vyjde tak na 10000,- Kc. Coz dost vaham jestli do toho investovat, protoze ani nevim, jestli mi poskytnou ocekavanou hodnotu.


Interactive Brokers API jsem zkousel, ale Historicka data v tom pravem slova smyslu to neumi, je v tom nejaky hacek. ZBytecne promarneny cas.

287

Vývoj / Re:Jaké použít Financial API s historii cen akcií a stavu indikátorů?

« kdy: 07. 06. 2019, 21:08:43 »

Zkousel jsem Quandl. Nevim jestli jde o spatny vtip, ale poskytuji podle vseho jen historicka dta cen akcii.

Oproti tomu https://product.intrinio.com je jina kava - a taky drazsi. Muzu si stahnout stovky megabajtu historickych dat za X poslednich let, vsechno maji pripravene... akorat by me ty dtaa stala 600 dolaru. Pritom jeste pred 2 lety byla zdarma na Yahoo. Pise off.

288

Vývoj / Re:Jaké použít Financial API s historii cen akcií a stavu indikátorů?

« kdy: 07. 06. 2019, 19:50:25 »

Tvl co to je za API, takovy shit jsem uz dlouho nevidel. To snad raci fakt ne, na to nemam cas. Aspon teda to Javovske API, v Pythonu neumim.

289

Vývoj / Re:Jaké použít Financial API s historii cen akcií a stavu indikátorů?

« kdy: 07. 06. 2019, 18:56:40 »

Podival bych se na quandl a data od Zack Fundamentals. Osobni zkusenost nemam.
Mam zkusenost s Interactive Brokers API + python (podminka je mit u nich ucet).

Mam u nich ucet. Dovoli ti nacist si cokoliv z historie? A rychlost prenosu dat po API je solidni nebo je to pomala plecka?

PS: Intel nebo AMD?

290

Vývoj / Jaké použít Financial API s historii cen akcií a stavu indikátorů?

« kdy: 07. 06. 2019, 13:00:40 »

Chtěl bych si ze srandy pohrát s historickými daty akcií. Chci historická data přinejmenší k: Stock price, equity, debt, book value

Bohužel jsem paf z toho, kde takové API sehnat. Kolem roku 2012 to poskytoval Google Finance a přestal. Do roku 2019 lidi používali Yahoo a letos to taky utnuli.

Zkouším googlit, ale pocity z nabytýtch informací mám smíšené.

A proto jsem na Root.cz, protože je to tady radírna, a proto se tady jdu poradit.

Otázky:
1, Jaké API se dá k tomuto účelu použít? Může být i placené.
2. Proč Google i Yahoo utnuli svoje služby?
3. Nějaký tip na knihovnu k API, ideálně v Javě?
4. Jaká je cca velikost dat pro 10000 companies za posledních 15 let - můžu si to všechno někde stáhnout?
5. Nějaké osobní zkušenosti s prací s tím API?

291

Odkladiště / Re:iTunes požaduje extra platbu za některé písničky?

« kdy: 04. 06. 2019, 12:23:39 »

Ohooo, tebe se tyka jeste jedna vtipnost.
Strucne: Apple Music library != iTunes music library

Tak to je dobra ohryzkovina.

Some artists simply aren't smitten by the subscription internet streaming model. The Beatles are nowhere to be found in Spotify, for example, and Taylor Swift pulled her music from Spotify's service in 2014 because she didn't think music streaming services appropriately value her art.

Chudacci, jejich umeni neni dostatecne ohodnoceno. Uloz.to jim pomuze, ja jim to umeni ocenim, na 1 haler za megabajt. Myslite ze se jim to bude takto libit vic?

292

Odkladiště / Re:iTunes požaduje extra platbu za některé písničky?

« kdy: 04. 06. 2019, 10:23:19 »

Jenze ono jeste ke vsemu ja mam predplatne itunes, platim nejakych 180,- Kc mesicne a mel bych tim mit pristup ke vsem pisnickam. Pokud se toto rozmuze a ja si budu muset nektere pisnicky kupovat, tak proste kaslu na predplatne a jdu to znovu piratit. To je hezke ze je to rozhodnuti nejakych hudebnich spolecnosti, tak proste nebudou mit ze me vubec nic.

293

Odkladiště / Re:iTunes pozaduje extra platbu za nektere pisnicky?

« kdy: 04. 06. 2019, 08:56:47 »

Nevim ktery predplatny mas na mysli, ale i pri klasickym nakupu jednotlivych skladeb se da narazit na skladbu, kterou nelze koupit samostatne (jako jen tu konkretni pisnicku), tu ziskas jen pri koupi celyho alba.

Hm tak to se mi doposud jeste nestalo. Vidim ze asi probehne konfiskace soukromeho majetku ve spolupraci s firmou uloz.to.

294

Odkladiště / iTunes požaduje extra platbu za některé písničky?

« kdy: 03. 06. 2019, 22:53:59 »

Nějak se stalo to, že jedno celé album co jsem měl (česká Lucie) a jedna písnička Paul McCartney Hope of Deliverance se mi v iTunes vybarvily šedě. Nejdříve jsem nevěděl co to má být, ale když jsem to začal zkoumat, tak iTunes po mně v podstatě chce, abych si k mému předplatnému ještě ke všemu tu písničku popř. celé album koupil! Doufám že mě jen šálí zrak. Nevímte co to sakra má být?

295

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 23:45:07 »

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.

Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.

u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)

Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.

Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.

V žádném případě nejsem příznivcem monolitů a proto se mi nelíbí, jak se toho zhostil autor zmíněného blogu. V každé třídě hezky 2-4 atributy a 3-7 metod. Víc není třeba. Skupinu tříd, která se stará o jednu doménu, dám do jednoho adresáře. Domény, které jsou logicky nad ní nebo pod ní, jsou v jiném adresáři na stejné úrovni. Můžeš to srovnat s hexagonální architekturou, která nevytváří zbytečnou hierarchii.

Specializaci tedy nedělám podle kategorie, ale podle domény. Pokladna, sklad, ceník, košík. V každé doméně je kompletní MVC, třídy hezky vedle sebe. Když vytvářím další doménu, například slevy, tak nemusím běhat po celém vývojářském stromu, ale mám celé MVC pohromadě v jednom adresáři. Pokud by mi měla vzniknout duplicita kódu s jinou doménou, tak tu část kódu refaktoruji do nové domény a ta si pak žije svým životem.

Adresář s názvem "domain" u mne postrádá smysl, neboť bych v něm měl všechno.

Tak tam mas ten design ocividne ovlivnen tim, ze to neni ciste backend a mas tam to MVC. To to UI ti prihodne definovalo rozdeleni balicku tak, jak to mas ted.

Kdyby to byl ciste backend a fontend by byl uplne oddeleny, treba v Reactu, tak bys mohl mit na backendu tohle:

domena
 Objednavka
 Uzivatel
 Produkt
 Dodani
 Platba

Na projektu jsem jeste MVC nikdy nemel a vzhledem k tomu, ze uz MVC moc nepouziva, se k tomu mozna uz ani nedostanu.

296

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 22:18:07 »

E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

Jestli ono to nebude tim, ze delas ocividne frontend. Ostatne, to uz se psalo nekde tusim v Unix Bible, kde se popisovalo na prikladu Applistu a Unixaku - kde Unixaci se staraji vic o to, jak ma fungovat mechanismus aplikace, kdezto Applisti vice o to, jak tu aplikaci bude chtit pouzivat jeji uzivatel. Coz vytvori 2 ruzne pristupy k veci a ruzne vysledky.

Ja jsem backend programator - me vice zajima poradnost mechanismu nez to, jak to bude pouzivat uzivatel. Kdybych delal frontend, asi me bude mene zajimat mechanismus a vice zpusob pouzivani uzivatelem. Budu psat aplikaci ze strany UI a co je v pozadi bude podrizeno UI.

Bylo by dobre, kdyby si to programatori uz konecne uvedomili a prestali na sebe navzajem kydat hnuj.

hmm, ja sa osobne považujem za full-stack programátora.... inak netuším podľa čoho si usúdil že riešim front-end.

Delal jsi nekdy v enterprise, napr. v bance? Kde business logika nejakeho typu objednavky je tak komplexni, ze jeji zpracovani trva nekolik dni nebo i tydnu, a vyzadje mit specializovanou komponentu ktera predstavuje stavovy stroj, protoze jinak by se v tom ani prase nevyznalo a bylo by to nereliablni? Kde centralni databaze ma 200 tabulek a kazda muze mit az 100 sloupcu? jestli ne, tak jsi u me frontendar 

Mimochodem, vis jak vznikne databaze, co ma 200 tabulek se 100 sploupci? Vznikne postupne, bez planovani, tak jak byly jednotlive veci potreba postupne rostla - tzn. takovy shit ve kterem se neda dobre vyznat vznikne praveze metodologii, ktera se uplatnuje v javascriptu.



Obecne se da rict, ze dobra poskladanost aplikace vyzaduje cas a peci. A kdyz se do toho ten cas neinvestuje, tak proste vznikne shit. Neexistuje nejaka vsespasna metodologie nebo jazyk, ktera udela pekny design za programatora. OOP je neco, co umoznuje do programoveho kodu vlozit novy prvek/uroven poradku. Stejne tak staticke typovani. Ale oboje je samo o sobe jen prostredek - jestli tomu ten programator cas venuje, aby to ten prostredek vyuzil k dobremu designu a lepsi prehlednosti kodu, to je vec druha. Mozna i za pomoci dynamickeho jazyka se da dosahnout podobne miry poradku - ale neverim tomu, ze to bude jednoddussi a spise si myslim, ze to bude tezsi.

297

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 22:00:51 »

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

V tom blogu nepopisuje nic jiného, než blbě pochopené OOP. Java je v tom nevinně.

E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

Jestli ono to nebude tim, ze delas ocividne frontend. Ostatne, to uz se psalo nekde tusim v Unix Bible, kde se popisovalo na prikladu Applistu a Unixaku - kde Unixaci se staraji vic o to, jak ma fungovat mechanismus aplikace, kdezto Applisti vice o to, jak tu aplikaci bude chtit pouzivat jeji uzivatel. Coz vytvori 2 ruzne pristupy k veci a ruzne vysledky.

Ja jsem backend programator - me vice zajima poradnost mechanismu nez to, jak to bude pouzivat uzivatel. Kdybych delal frontend, asi me bude mene zajimat mechanismus a vice zpusob pouzivani uzivatelem. Budu psat aplikaci ze strany UI a co je v pozadi bude podrizeno UI.

Bylo by dobre, kdyby si to programatori uz konecne uvedomili a prestali na sebe navzajem kydat hnuj.

298

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 21:45:01 »

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.

Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.

u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)

Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.

Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.

299

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 20:57:30 »

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

300

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 20:08:02 »

Doteraz nikde som nevidel navrhovať Node aplikáciu spôsobom "a ako prvé si zadefinujeme doménový model". Ani definovaním data access objects. O čom točíte?

tak se programovalo před rokem 2000, v dobách nedokonalých verzovacích systémů dávalo smysl x vrstev abstrakce. Někteří tak programují dosud.

Jak to souvisi s verzovacim systemem? Ja mam za to, ze domenovy model je zaklad dobreho OOP designu.

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

Ten clanek je zajimavy, uz jsem ho cetl nekdy driv, ale v podstate mu chybi neco, co jeho hodnoto hodne devalvuje. A to je, v jakem enviromentu ten otycny clovek pracuje. Je totiz velky rozdil v designu komponent zvolenem v Enterprise a designu zvolenem nekde na mensich projektech. A nemysli si, Java se da taky skalovat - nemusis mit automaticky na vsechno byrokraticky napsanych nekolik vrstev abstrakci. Ackoliv nekteri lidi to maji tendenci delat - respektive mame to tendenci delat vsichni, ale projevuje se to ruzne intenzivne. Odpovida to gaussove krivce, programovani je ohromna zatez a zkouska na kognitivni schopnosti jedince.

O spravnosti OOP a toho, jak to dela Java, uz nepochybuju. Muzu srovnat uz 2 enviromenty, v jednom se bastlilo proceduralne (master Javista byl byvaly PHPkar), v druhem se dela OOP - OOP enviroment svou prehlednosti jednoznacne vede.

O spravnosti designu Javy (a C#) uz nepochybuju taky - kdyz to srovnam s Javascriptem. Celkova kvalita knihoven v Javascriptu neni moc dobra.

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Kdyz ctu tyhle clanky, kde nekdo rozporuje OOP, tak jedna z veci je, ze OOP neznamena Java. OOP je tady uz nekolik dekad. A kdovi, mozna bylo toto paradigma vymysleno jeste predtim, nez vznikly pocitace - jak uz to tak u nekterych veci byva, lidi se jimi zabyvaly driv, nez je vubec meli na cem implmentovat. A je vcelku vtipne, kdyz nejaky jednotlivec rozporuje desitky let vyvoje programovaich jazyku - cimz se zabyvali lide chytrejsi nez ja nebo autor clanku. A jak to dneska vypada v popularite jazyku je jasne videt, OOP jazyky vedou.