[TIL]關於BlockChain的學習整理

前提: 主要是在Line上面的討論,有人覺得像是Bitcoin中blockchain把資料全部分散放在各個client裡面是很不好的做法.這樣所有資料都redundancy. 於是再把一些相關spec拿出來看.. 快速整理一下.. Blockchain 架構速記: Bitcoin 最好的 blockchain 1.0 應用 喧賓奪主的應用,大概非Bitcoin莫屬. 沒太多人(一般民眾)注意到blockchain的精髓. 只記得這個應用.. 不過隨著幾個大廠商(ex: IBM) 也在開發自己的blockchain 應用. 這一塊早已在新創產業不是話題了… bitcoin 被稱為是blockchain 1.0的應用,而現階段在新創產業與一些大公司在推廣的就稱為是blockchain 2.0 (smart contract) . 簡單架構 Bitcoin wallet: 一個記錄所有交易紀錄(以下皆成為block)的資料庫(使用Google LevelDB) 每筆交易紀錄(block)平均大小是250bytes,其格式包括了: Block Size: 4 bytes, 來敘述block大小. Block Header: 80 bytes, Block header 包括 version, previous hash, timestamp.. (還有其他的) Transaction Counter: 1~9 bytes (可變) 有多少交易在這個block. Variable: 大小不定, 交易內容.. 每筆記錄(block)與前一筆是串接在一起的(ordering),透過Hash value作為唯一的識別(using SHA256). Bitcoin miner: (所謂的挖礦機) 負責尋找最新的block hash value,並且確保該hash value 還沒有被產生過. 產生block會先加在最後,並且獲得一定的bitcoin作為獎勵.由於SHA256有其限制,所以能產生的bitcoin被限制在21000k bitcoin. 取得新的Hash後,需要以下的兩者擇一成真,才能獲的bitcoin: 取得大多數的wallet的同意(大於1/2 的 computing power) 連續取得6個新的Hash (表示你的機器速度大於全世界的miner六倍以上) Bitcoin的特性與展望: 特性: 去中心化 安全(透過其他P2P的審議機制) 所有端點會記錄大部分資料(或全部資料) 未來展望: 除了金流的bitcoin之外,可能有以下的應用: 電子簽約(Smart Contract) 將所有的簽約內容當成錢幣來存放,所有相關人都必須存放所有內容. 存放雙方資料,商品名稱與單位量. 挑戰: 如何計算營收? 如何避免透露過多商業資訊? 證券交割 將股票單位作為blockchain 交易的單位. 遊戲幣 這邊沒有太多特別地方,就是把遊戲中的貨幣改成透過blockchain.可以讓民眾私下交易遊戲幣. 專利與商品證明 bitproof.io 想到透過blockchain來保護智慧財產權.他可以透過檔案(將你的專利或是文章作成檔案後,上傳來取得特定的標記),透過該標記來證明你是第一版的擁有者. 其他: 朋友在討論中談到: “Blockchain 機制會造成資料的重複嗎?” 經過我尋找,一些資料如下 每筆交易資料 平均是 250 bytes (包含多筆交易資料) 平均每筆交易資料為 26 bytes (參考bitcoin wiki) 透過Google LevelDB 大小會被壓縮.. 其實儲存可能不會超過一半以上,因為機制上只要一半以上通過就可以. 不過當網路順暢時還是會儲存全部. 相關鏈結: Google LevelDB How bitcoin use LevelDB 押宝比特币?错,IBM看重的只是Blockchain未来 Amazon Book: Mastering Bitcoin: Unlocking Digital Cryptocurrencies bitproof.io透過bitcoin的專利機制 Bitcoin Wiki: Transaction
繼續閱讀

[影片心得]Steve Jobs遺失的採訪: 人才與創意管理的內功

Steve Jobs - The Lost Interview from Daniel Wagner on Vimeo. ##前提 最近MOD送我電影199 偶爾看到.. 覺得實在很棒… (雖然是20年前訪問… 而且結果大家都知道(爆雷)) ##內容 完美的創意與完美的產品的差異 — 在於大量完美的工藝 “There is just tremendous amount of craftsmanship in between a great idea and a great product.” “問題在於優秀的創意到產品之間存在著大量完美的工藝” “And as you evolve the great idea, it changes and grows, it never comes out like it starts.” 實現創意的過程中…當你了解的越多…想法會變化甚至面目全非. “Because you learn a lot more, you get into th subtleties, you also find the… There’s tremendous trade-off that you have to make.” 你不得一次次權衡利弊..做出讓步與調整. ##相關鏈結 賈伯斯遺失的訪問-70-分鐘完整影片心得 Youtube: Steve Jobs 遺失的訪談
繼續閱讀

[Docker] 跟朋友的Docker使用的Q&A

起因: 有個朋友看我貼了篇docker swarm的文章,於是跟我討論了一些docker的用法. 覺得整個討論相當有意義,於是徵求同意後把文章記錄一下. 整個討論: 討論應用的情境 朋友: 你也有在玩docker嗎? 我: 當然… 朋友: 剛入門一週 在指點一下XD 朋友: 我目前只會裝跟build自己的image,打算把開發環境跟 production都換成docker. 我: dockerize your all service 是個蠻好的課題 朋友: 目前還不是很知道deploy怎麼做比較好,不過我看他還有一堆有的沒的功能 太底層我不太會. 我: deploy 就透過docker-compose 一個設定檔 db/web browser/service 都搞定. 至於Docker也不用看的太底層啦,你先搞懂基礎 docker,在看docker-compose 就已經出師了. 朋友: 所以我local 開發環境要deploy正式環境 用compose就可以,dockerfile有些指令我還看不太懂. 我: 喔… 你是要deploy dev-> prod 我: 沒關係.沒有人記得起來所有docker指令.docker console 大概是我覺得最討厭的指令集了. 朋友: 想要找個比較簡單的做法 我: 那你看看我剛剛貼的swarm 朋友: 每次裝aws環境 裝到我快吐了 解釋Docker Compose 跟 Swarm應用差異 朋友: 所以compose是幹嘛的,swarm我看很多人在講分散式系統,我的需求很簡單 就是想要dev -> 多台production. 我: 簡單的說 docker-compose 可以一次呼叫一群的docker container 並且設定串接在一起. swarm 可以將全世界的container歸類在一起..你在local 就可以操控跨網路的container 朋友: 所以compose必須在同一台主機上 我: 對…基本上. 但是docker-compose可以跟swarm混用 朋友: 就是一台很強電腦跑很多台東西 恩,混用我可以理解.那我應該要去看swarm. 我: 一個docker-compose 例子.不過,你的方向是swarm. 然後我貼的那篇經驗談 好像就有提到 DEV->PRE PROD->PROD 的控制 拆解Services方法的討論 朋友: 所以你docker-compose在使用上有把 application / db / web server三個都要分三個container喔.自己dev環境也這樣搞嗎? 我: 能拆成這樣 到時候要換任何一個不用重啟container 朋友: 我是很懶 全部裝一起,production才會拆開. 我: 現在不拆之後拆就會出問題…那就失去docker的好處 朋友: 不過local如果分開 production會比較輕鬆一點 我: 而且重build 跟跑也快 才能節省時間啊. 朋友: 所以你這樣需要三個image嗎 我: 對,就docker microservice 概念 基本上一個service 就應該要是一個image.之後才方便抽換. 關於Mac上使用boot2docker VM可能造成的問題 朋友: 這樣硬碟就爆了XD 我: 你們不都是MBPR? 我128G,都沒講話 XD. 朋友: 我現在不知道為啥256g一直滿,打算把整台重灌. 然後全妝成docker,以後要砍環境比較快. 我: 我docker都用windows 桌機跑 VM,然後MAC連過去. 你硬碟會爆應該是xcode,可以看看我這篇文章. 記得經常去清一下 有是幾十G. 此外,MAC docker 跑VM 就算image 砍掉…空間一樣算喔 所以你又要看另外一個指令 docker-machine 把VM重啟 清理一下 朋友: 有這回事?...
繼續閱讀

程式設計週記[2016/03/11]: 要會寫分散式系統,得先找到溝通的方法

這是什麼? 程式週記主要內容如下: Gihub project 介紹: 主要會貼一些github,但是會盡量寫上一些有用的評語(或是我容易想到的關鍵詞)幫助以後查詢 網路文章心得: 會寫些心得,強迫自己閱讀. “程式週記”並且定期週期性更新. 大部分內容在我的twitter都會有,這邊只是將一些簡單的心得與感想註解一下. 本週摘要 本週花太時間在追如何使用etcd/raft.本來是打算用NSQ的管理方式,但是看了許久還是找不到他使用的方式.回過頭來使用raft. Go writ: A flexible command and option parser for Go 有點像是cobra,不過可以直接透過name tag 直接讓go structure 直接套入command option. A command line client for Dropbox built using the Go SDK CLI tool for droxbox in Golang,這邊還有新的API An UNOFFICIAL Dropbox v2 API SDK for Go kati: Google GNU make clone which is written by golang 可以透過kati來將makefile轉換成ninja用的檔案. A repository for plotting and visualizing data 可以拿來換圖用的套件. Stochastic flame graph profiler for Go programs 隨機產生火焰顯示profile你的go程式的結果. Python Android/JAVA/NODE.JS Building Android Apps — 30 things that experience made me learn the hard way — Medium 作者分享在開發Android App裡面踩到的雷,這種經驗分享的文章,永遠都是我的最愛. Yahoo Deep Learning Engine: CaffeOnSpark Yahoo最近開源的Deep Learning Engine,主要可以將Hadoop/Spark Cluster的資料抓取來使用.更多部分可以看他們的文章 Cross-platform Linux without the suck 可以讓你在Windows下面使用unix的console,而且又不像Cygwin那麼大.重點是用JS ES6寫的 Docker Kafka (and Zookeeper) in Docker Spotify 開源docker image可以讓你快速架設kafka跟zookeeper. One+ year feedback of using Docker and Swarm in DEV and QA environments — Medium 使用swarm經驗談文章.. 挺不錯的. 有教導如何透過swarm在dev <-> pre-prod <-> prod 之間切換的方法. iOS/Swift 網站文章...
繼續閱讀

[TIL] Today I Learn 2016/03/10

Run docker container as default system services Start docker daemon when ubuntu launch. Add conf on service as follow description "cAdvisor" start on filesystem and started docker stop on runlevel [!2345] #respawn # @see https://github.com/google/cadvisor/blob/master/docs/running.md#standalone script docker rm -f cadvisor || true docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:rw \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --publish=8080:8080 \ --detach=true \ --restart=always \ --name=cadvisor \ google/cadvisor:latest end script For more detail, check here. Automatically start containers
繼續閱讀

[TIL] 2016/03/08

ETCD Architecture study. Some study note about survey how Raft work in ETCD. Something more about official architecture from digging code. Data storage in etcd/storage/backend. The file structure as follow: topic/sub_topic/data Data Exchange type using protobuf with grpc BTW: NSQ using http.handle. So, no RPC data exchange issue, no protobuf required. NSQ about how to elimiate SPOF Refer to slide. Seems the SPOF means of client side failure handle, not server side. (TBC) Every server response to dedicate topic (no redudent) (p.22) Client use this to add more consumer and handle it as load balance. (Refer topology_pattern) quote: Assuming you have some sort of load balancer in front of these two hosts you can now tolerate any single host failure. Need more check about this gist about use NSQ on K8s
繼續閱讀