Příspěvky

61

Software / Re:BTC peněženka: přechod z BTC CORE do Electrum

« kdy: 19. 05. 2017, 21:10:04 »

No ten seed je dost kritický. Papír má tu výhodu, že je relativně trvanlivý. Ještě trvanlivější je cryptosteel.

Nejhorší nápad je dávat ten seed do cloudu. Je třeba taky myslet na to, že i fleshky se občas pokazí a nejdou načíst. Ten papír je opravdu zatím asi nejlepší záloha. Pokud nechceš papír, můžeš použít třeba knihu a seed napsat perem na nějakou prázdnou stranu. Knihu zas tak často člověk nevyhodí.

Samozřejmě ani kniha nepřežije požár a bude mít problém s povodní.

Zapomeň na Bitcoinovou adresu. Vůbec zapomeň na nějaké adresy. Adresa v bitcoinu jako místo, kde máš prostředky je největší omyl. Adresu si představ jako variabilní symbol. S každou vyžádanou platbou bys měl nechat vygenerovat novou adresu v peněžence. Z hlediska třeba nějaké organizace plateb lze pak adresu použít do nějaké databáze v účetnictví, prostě jako variablní symbol.

Bitcoiny jsou uloženy pod seedem. Jak je to technicky implementovaný by uživatele nemělo zajímat.

62

Odkladiště / Re:Prodej bitcoinů – daň z příjmu

« kdy: 19. 05. 2017, 01:42:44 »

Jako fyzická osoba - ostatní příjmy. howg

63

Software / Re:BTC penezenka prechod z BTC CORE do Electrum

« kdy: 19. 05. 2017, 01:36:11 »

V dnešní době je nejlepší zálohou 24 slov napsaných na papír, nebo odolnějším způsobem uložená v cryptosteel (viz google).

Přesun blockchainem = transakce, jo, nějaké feečko to stojí. Jde o to, že současné peněženky často neumí importovat klíče k existujícím adresám. V zásadě už ani není možné privátní klíč z peněženek vytáhnout. Vše je deterministické , odvozené od seedu, tedy od těch 12-24 slov. Čistě teoreticky jde ještě do vícero peněženek vložit ta samá slova, a to platí i o Trezoru a pak ty peněženky sdílejí stejné Bitcoiny. Ale přesun prostředků mezi různými peněženkami jen jako transakce.

64

Software / Re:BTC penezenka prechod z BTC CORE do Electrum

« kdy: 18. 05. 2017, 16:24:33 »

Když tam nemáš bitcoiny tak co řešíš? Založ si v Electrum novou peněženku.


Kdybys tam měl bitcoiny, tak se to dělá tak, že si založíš novou peněženku, bitcoiny přesuneš do nové pěněženky a po 6 potvrzení starou peněženku smažeš

NIKDY, OPAKIJI, NIKDY, nepřesouvej prostředky tak, že někde šoupáš soubory. Je lepší přesouvat BTC blockchainem.

65

O serveru Root.cz / Root: Proč nemohu vidět palce u svých komentářů

« kdy: 10. 05. 2017, 13:40:10 »

Palce u ostatních komentářů vidím, u svého mám jen možnost svůj komentář sledovat nebo se nahlásit jako spammer (což nevím, proč bych dělal).

Když chci vidět, jak můj komentář hodnotí ostatní, musím se odhlásit. Je to trochu nepohodlné

66

Server / Re:Http na backendech a čím jej nahradit (a zda vůbec)

« kdy: 06. 05. 2017, 21:31:39 »

Na http se mi líbí hlavně to, že nemusím psát speciálního klienta na přístup ke službám backendu.

Benefit binárního http/2 nechápu jako výhodu. Klasické http má jen pár řádek hlaviček a pak payload. Otázkou je, zda náklady na provoz multiplexu, tedy kouskování dat, přidávání binárních rámců, rozdělování dat jednotlivým listenerům na straně backendu není ve výsledku mnohem náročnější a nepřinese větší datové náklady, než pár textových nezkomprimovaných hlaviček.

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

Ale jinak dík, zůstanu u http.

67

Server / Re:Http na backendech a čím jej nahradit (a zda vůbec)

« kdy: 06. 05. 2017, 13:03:38 »

S nástupem Http/2.0 a snahou vytlačit HTTP z prohlížečů

Asi jste mylně informován. Nikdo se z prohlížečů nesnaží vytlačit HTTP, dokonce ani prohlížeče neimplementují žádnou náhradu, která by mohla HTTP vytlačit. HTTP je pro prohlížeče stále ten nejdůležitější protokol, některé prohlížeče vedle něj jako doplněk nabízejí třeba FTP.

Poslední vývoj chrome i firefoxu hodně šlapou na http a snaží se vnutit aspoň https. Protokol http má výhodu také v tom, že během vývoje mohu použít i prohlížeč na prezentaci výsledků backendu. Stačí mi třeba mít webovou administraci na intranetu jen v http a už na mě bliká, že to je nezabezpečný a nedejbože abych tam měl okénko s heslem.

Nevidím důvod, proč bych na backendu měl používat http/2.0, už kvůli tomu, že nevyužiju ani multiplexing ani šifrování, ale spíš honím maximální rychlost při přenosu dat z backendu na webserver.

Zrovna multiplexing využijete ještě víc, než prohlížeče, protože jedním spojením přenesete mnohem víc požadavků, než jeden prohlížeč. Díky komprimaci hlaviček také můžete ušetřit objem přenášených dat. Nevidím žádný důvod, proč by přenos přes HTTP/2 byl pomalejší, než HTTP/1.1 – naopak má potenciál být rychlejší.

Multiplexing je vždy pomalejší než několik otevřených konekcí. Na backend nemá smysl už proto, že často padá jedna konekce na klienta, jelikož statické stránky obslouží sám webserver, na backend pak už padá tak jeden až dva requesty na stránku. Na rychlých sítích je přenos dat menší problém, než jejich zpracování. Například šifrování a náklady na správu multiplexu mohou být mnohem dražší a co se týče hlaviček tak opět, jejich množství lezoucí mezi webserverem a backendem může být významě redukováno.

Co se používá v jiných firmách a projektech?

Například HTTP.

Dík

68

Server / Http na backendech a čím jej nahradit (a zda vůbec)

« kdy: 06. 05. 2017, 11:27:39 »

S nástupem Http/2.0 a snahou vytlačit HTTP z prohlížečů opět řeším problém, jaký protokol používat na komunikaci mezi webserverem a nějakým pokročilým backendem. Doposud jsem si vystačil s proxypassem přes protokol http. Nevidím důvod, proč bych na backendu měl používat http/2.0, už kvůli tomu, že nevyužiju ani multiplexing ani šifrování, ale spíš honím maximální rychlost při přenosu dat z backendu na webserver.

Uvažoval jsem také o fastcgi, ale po prostudování dokumentace jsem ty úvahy znechuceně opustil. Je to protokol ze staré školy, podle mě moc komplikovaný a necítím to jako inovaci (spíš jako krok do historie). Zatím mi zpravidla http protokol přes proxypass postačoval, byť na můj vkus ukecaný. Obávám se ale, že zejména z pohledu managerů tlačených mainstreamem bude snaha věci zbytečně komplikovat.

Co se používá v jiných firmách a projektech?

69

Vývoj / Re:C - deklarace metod ve stukturach s definici bokem

« kdy: 30. 04. 2017, 03:12:27 »

A nebo použít C++. Můj život má limitovaný čas.

70

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 26. 04. 2017, 23:28:38 »

K čemu jsou v C++ hlavičky? No  každá kompilační jednotka  (cpp soubor) je kompilována samostatně oddělené od ostatních. Musí tedy být kompletní a samostatná. Překladač pro prohnání zdrojáků preprocesorem se zabývá jen tím jedním souborem a ničím jiným. To třeba umožňuje překládat na jiném stroji (distcc).

Každopádně, hlavičky jsou potřeba, aby se společné definice vložily všude tam, kde jsou třeba. Nechceš je tam snad pořád dokola přepisovat. Když mám například dva soubory cpp, které používají jednu třídu, je třeba tu třídu strčit do nějakého společného souboru, který se vloží do každého cpp, aby tu třídu překladač viděl v každém tom cpp. Tomuto souboru se říká hlavičkový soubor.

71

Vývoj / Re:Musí webdesigner znát základy Linuxu?

« kdy: 25. 04. 2017, 20:59:09 »

Když to tu tak čtu, tak si asi ten frontend k tomu backendu vyvinu sám i s grafickým návrhem.

72

Vývoj / Re:Musí webdesigner znát základy Linuxu?

« kdy: 25. 04. 2017, 18:05:11 »

já jsem asi spíš myslel webdevelopera, protože se v těchto termínech už moc nevyznám. Většinou je to ten chlap "co udělá stránky proti backendu". Rozsah prací může být různý. Někdy k backendu vzniká přímo i JS knihovna, aby se zamaskovaly technikálie kolem spojení a komunikace s backendem. Webdeveloper pak už jen volá příkazy knihovny a dobře se i řeší případné změny v protokolu.

Nějak si nemohu dovolit zaměstnat webdesignera a webdevelopera současně, ale tak nějak jsem si myslel, že webdevelopeři/designeři se rekrutují hlavně z té části lidí, co umí spíš malovat než kódit, nebo kódit umí, ale malování zvládají líp. Člověka čistě na design to mi v mém případě příjde trochu jako overkill

73

Vývoj / Musí webdesigner znát základy Linuxu?

« kdy: 25. 04. 2017, 11:48:49 »

Zdar musím si postěžovat

Chápu, že nemohu po některých web designerech chtít programovat, byť by dneska základy JS měl asi každý zvládnout, nebo aspoň umět pomocí JS skrýt element na obrazovce, nebo vyplnit položky v select boxu. Ale někdy se setkávám se základními neznalosti, které mi stěžují práci s nimi.

Valná většina serverů běží na linuxu. Občas bych potřeboval, aby web designer věděl minimálně
 - co je to ssh veřejný klíč
 - co je to sftp protokol
 - co je to proxypass a jak si ho nastavím na svém lokálním serveru
 - co je to git a jak si z něho stáhnu projekt k sobě na disk
 - co je to konzole
 - proč je špatný nápad na server instalovat ftp
 - jak vypadá http request a jak response a co zhruba každá položka znamena (a kde to ve webové konzoli najdu)
 - proč není divný že /aaa/bbb  vrací 404 když /aaa/bbb/ccc funguje

Chci toho moc od člověka, který si řekne půl litru za hodinu? Nebo jsem se zbláznil a mám přehnané požadavky? Nebo jsem narazil na obyčejného grafika, který občas udělá i webovou stránku (ve wordpressu)

74

Odkladiště / Re:Týká se EET vývoje SW?

« kdy: 13. 03. 2017, 11:58:44 »

"Platba prostřednictvím příjemce" v zákoně je hodně vágní a spadá do toho kde co. Třeba platební portály různých bank, eKonto, Fio brána, atd, všechno to jsou převody z účtu na účet, ale je iniciován prostřednictvím příjemce (což je iniciována jakákoliv platba, i manuální, nejprve dostanu promofakturu, kterou zaplatím převodem)

75

Studium a uplatnění / Re:Nesouhlas s nadřízeným

« kdy: 21. 02. 2017, 22:48:24 »

Já jsem zásadní nesouhlas s nadřízeným řešil odchodem z firmy (velká IT firma). Po půl roce jsem se dozvěděl, že byl stejně odejit, ale i když s tím nic neudělám, do firmy se nevrátím, aspoň mám z toho dobrý pocit.