這是什麼?

程式週記主要內容如下:

Gihub project 介紹:

• 主要會貼一些github，但是會盡量寫上一些有用的評語（或是我容易想到的關鍵詞）幫助以後查詢

網路文章心得:

• 會寫些心得，強迫自己閱讀．

“程式週記”並且定期週期性更新．

大部分內容在我的twitter都會有，這邊只是將一些簡單的心得與感想註解一下．

本週摘要

最近有在歐萊禮買了一本電子書，也找了不少有趣的電子書要看．得花更多時間來看，也想花點時間來看Coursera，時間真的要好好想想．

本週專案部分，最近實在花太多時間在看NSQ的內部構造．反而比較少花時間去寫Code．這其中的取捨變得困難不少，可能也跟我了解得不夠紮實有關．這部分要努力學習．

Go

A complete, reliable, ircd written in Go.

• 用 go 寫的 ircd

xo is a command line tool to generate Go code based on a PostgreSQL, MySQL, SQLite, or Oracle, or Microsoft SQL Server database

• 只要給SQL的Schema，就可以長出Golang的model

Youtube: Comparing Erlang and Go Concurrency

• 可以參考看看一個session介紹關於Erlang跟Go的Concurrency．

licenses lists Go packages dependencies licenses

• 可以列出所有用到的Go project的License，算是很有用的工具．

  [Go projects and the BSD license

  ](http://misfra.me/2016/02/28/go-projects-bsd-license/)

• 從來沒有仔細思考過Go project 的license，只是簡單的把自己的專案都用MIT．看完才知道其中的關連…

One HTTP Request From Stardom: How Alan Shreve Built ngrok Using Go

• ngrok是一個可以讓你在防火牆內部的Server可以直接被存取的技術，這邊介紹如何透過Go來build ngrok．

Python

Android/JAVA/NODE.JS

Pretty unicode tables for the CLI with Node.JS

• 可以畫出很漂亮的unicode table在console mode．

Docker

iOS/Swift

奇点机智，用深度链接让 app 不再孤单

• Deep Link 在iOS9獲得了不少的加強功能，而在App的設計上其實Deep Link 已經佔有一定的地位．這邊有談到說一家公司奇点机智如何透過幫忙控制Deep Link來讓App更好而且更多人使用．

Swift @ LinkedIn

• LinkedIn裡面透過Swift開發的經驗，巔峰的時候有50人工程師參與開發．透過Swift開發App最大的瓶頸還是開發機器的能力．灣區日報有很精彩的評論．

網站文章

學術論文解放！將近五萬篇論文可透過Sci-Hub免費下載

• 當初Aaron Swartz 因從JSTOR 的學術期刊下載約400萬篇文章被停的Sci-Hub復活了．超過五萬篇論文可以下載．

Github: January 28th Incident Report

• 引用: IngramChen from kaif:
  • Github 內部發生了類似 不小心踢掉電源線 這種意外，然後 25% 的 server reboot，reboot 過程中 redis cluster 爛掉，造成 application server 啟動失敗。他們無奈只好先救 redis cluster，直到 redis 救好後，才重啟 application server… 看完後覺得 Github engineer 實在有點遜，這種 failure 不該是這麼強的公司該犯的… 一個子系統失效了，就造成 application server 完全不能啟動 (平常完全沒有模擬過這類型的失常)。然後子系統失效的原因是電源異常，這表示他們只用一個 Data center 囉？電源一斷就 1/4 server reboot… 有點遜。 我不是說我能做的比他們好，但 Github 已經不是 startup，也能吸收到世界最頂尖的開發者，這種等級的錯誤不是他們該犯的…

如何投资自己？

• 這一篇跟我最近在看的書籍Soft Skills後面的章節很類似．基本上就是討論如何訂定目標而努力學習的部分．書籍讀書心得會再出來．

網站收集

搜集一堆China 技術團隊使用Github issue當作blog

• 很值得好好follow的搜集資料網站，詳細心得看這裡．

Interview with Jay Kreps about Apache Kafka

• 採訪了Kafka的其中一個創始者-Jay Kreps 不僅僅有談到Kafka的設計理念，也有談到如果對分散式系統有興趣的人該如何開始了解． 裡面有不少有用的鏈結跟書籍推薦

APP 美工大捕帖

• 要各種APP美工圖案可以來這裡看看．

Code School特惠

• 線上學習網站 Code School 在2016/3/5 AM 6:00 到 2016/3/7PM 1:00 兩天半的時間內，開放全站所有課程都可以「免費」學習，只要累積分數在前 10 名者，還可以獲得額外一整年的免費學習帳號

“Software Engineering Radio”

• Scott Tsai推薦的這個podcast真的不賴，很值得投資時間來聽聽．

有聲書/影片心得

IT公論: #190-给建筑师用的 GitHub

• 這次請來了兩個建築師，一個是 Modelo 的創辦人Qi Su跟一個建築師事務所的黄璟璐．主要是來講解身為建築業使用的github:Modelo 的創業由來與其中設計的理念．
• Modelo (http://modelo.io/)提供了一個可以讓建築師可以線上透過WebGL的Rendering方式來即時查看整個3D設計的方式．本來是在哈佛設計學院(Graduate School of Design (GSD))的一個畢業論文．由於在學時間這個論文得了不少獎，於是Qi Su就把它當創一個新創產業來建立了Modelo．
• 透過這段談話，可以了解兩個產業間的用語不同與建築業界在意的事情．建築師們在意的是如何能夠快速地展現他的設計產品，並且能夠快速地得到反饋．根據得到的反饋能夠有儲存每個版本修訂間的變更，交互下能得到最大的效益．進而達到Modelo 的設計概念 Pain Less, Design More.

Paxos 發明者 Leslie Lamport 的採訪的 Podcast

• 詳細內容參考另外文章

Scale with NSQ: a realtime distributed messaging platform

• 一些基本介紹關於NSQ如何scale與處理．

本週專案

這邊會寫一些我的Project 52的成果.

本週專案: https://github.com/kkdai/rd

本來是想過透過RabbitMQ的RPC方式來實現，不過這樣實在不是很像RPC，而且這樣分隔也無法把Message Queue本身做得更加的泛用．

只好先試著做出一個簡單版的RPC Message Queue Server，不過這樣設計上就更加的狹隘．

基礎架構是把Diskqueue所建置的Pubsub機制弄在RPC Server上面．發現無法使用Channel來達到訊息的流通，於是只能做了一個Consume也就是會把目前該topic 的所有訊息拉下來，並且清除掉．在這個狀態上，這個RPC Server必須要有格外的loop來處理Pubsub的結果．

線上收聽的鏈結

起源:

最近有在聽Podcast的習慣，加上我一直有學習分散式系統的部分(尤其是Paxos跟Raft)．於是試著上去iTune來搜尋，竟然有找到Paxos作者Leslie Lamport受訪的podcast．

為何會做Paxos

裡面相當的有趣，除了有講到當初會做Paxos是因為一開始Lamport在做他的Time Clock論文的時候，正個論文的架構是在討論如何避免失敗．但是一個有趣的問題來了，如果真正的遇到失敗要如何去恢復與處理．當初在研究Time Clock也是主要專注在分散式資料庫的方面，但是Lamport發現其實可以適用到任何的分散式系統，於是就慢慢演化成Paxos．

Paxos發表經過

就如大家所熟知的，由於Lamport在當時相當喜歡透過哲學的方式來敘述事情．也就是大家所熟知的Paxos議會故事，以至於Paxos論文一出來，大家完全看不懂也就不注意，就這樣被擱置了好幾年(據說十年)．根據Lamport說，他認識的人也只有一個人聽得懂Paxos並且有幫助他宣傳，所以他又出了另外一篇廣為人知的Paxos Make Simple

最近的談話”Thinging For Programmer”

後來主持人又跟Lamport提到2014在MSFT Build “Thinking For Programmers的演說．裡面重要的概念就是每個程式設計師應該要先將你要寫的系統在腦中整個思考過，這邊講的思考建議是透過數學的方式來思考，因為這樣是最嚴謹的．透過嚴謹的思考，才能夠將整個系統的瓶頸跟問題找出來並且可以再發現之前來解決．

Lamport也提出一個範例，假設你要寫一個排序的程式．如果你沒有仔細思考要用哪種排序的方式而使用了Bubble Sort，不論你使用哪種程式語言，你使用哪種framework，你所建置的系統都不會快．因為他有先天性的限制，侷限了你的最佳速度，而這個是透過程式語言本身無法解決的．所以Lamport建議我們應該要先專注於”How should you do” 而不是 “What should you do”． 這邊提的”How” 代表你要用哪些方式，使用哪些演算法來解決問題． “What”才是你要用哪些語言來實現它．

最後也有提到UML或是透過繪圖方式來思考，不是不好．但是Lamport認為那些方式不容易清楚(precisely)而嚴謹的描述，容易造成混淆的區域．這樣就無法清楚的表達而思考整個系統的來龍去脈．

主持人提到會不會有人數學不好．而改用繪圖來思考？ Lamport認為身為程式設計師，要清楚的頭腦來思考是絕對的重要．而透過清楚而精準的表達方式來呈現自己的思考脈絡更是一個程式設計師基本的學習．他很建議使用數學得方式來表達．

心得

想不到Leslie Lamport接受訪問的時候用字遣詞很容易了解．讓我們可以很了解這位大師的整個思考脈絡．這篇採訪實在相當的精彩，不論對於思考問題與解決問題的方法論．都有相當的建議．

相關鏈結

• 第一版的Paxos
• Paxos Make Simple
• Leslie Lamport在2014的MSFT Build “Thinking For Programmers
• 之前寫的Paxos學習心得

Run Docker Postgres

docker run --name some-postgres -p 5432:5432 -v $PWD/psql-data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword -d postgres 

Find docker IP

docker inspect <CONTAINER_ID> | grep -w "IPAddress" | awk '{ print $2 }' | head -n 1 | cut -d "," -f1

PSQL commands

Check here

Useful commands here.

• \q quit psql
• \d list all instances
• \dt list all tables
• \connect Db_NAME
• \dl list all databases

psql connect to DB

psql -U postgres -h <IP>

Dump MySQL to SQL first

 mysqldump --compatible=postgresql --default-character-set=utf8 -r DB.mysql -u root -p DB

Migragte from sql -> psql by mysql-postgresql-converter

git clone https://github.com/lanyrd/mysql-postgresql-converter
cd mysql-postgresql-converter
python db_converter.py databasename.mysql databasename.psql

Create DB in psql first

CREATE DATABASE DB;

Refine PSQL

• remove all “COMMENT ‘KB’” in PSQL
• remove all default timestamp ‘“0000-00-00 00:00:00”’
• modify “mediumint” to int4

About phpPgAdmin

• Check php path on config /etc/apache2/conf-enabled add one here refer phpmyadmin
• restart apache2 service apache2 restart
• However it still need php to build with psql -> change to Windows UI PgAdmin

搜集一堆China 技術團隊使用Github issue當作blog

不論是熟知的阿里前端: 還是fouber都有，挺值得follow 來看看有沒有更多更新的…

其實有研究過用 github issue來做blog :

• TL;DR:
  • 懶得架站就用 github issue，不過記得多一份在md檔案中．
• 優點:
  • 易使用(不用搞jekyll/hugo)，highlight support，高互動(可以跟人討論)
• 缺點:
  • Google search 找不到 (不少團隊會複製一份到 github 當md來給google search)
  • 備份也是一樣． github issue 無法備份，需要另存檔案
  • 無法透過RSS來訂閱，對於我這種feedly高度用戶很麻煩．
• 其實像是fouber這樣兩份(一個放issue給討論，一份放檔案github 來搜尋) 也不錯．只是好像就有點太麻煩…
• 所以除非真的不想搞jekyll/hugo 不然還是乖乖弄blog方便點．

這是什麼?

程式週記主要內容如下:

Gihub project 介紹:

• 主要會貼一些github，但是會盡量寫上一些有用的評語（或是我容易想到的關鍵詞）幫助以後查詢

網路文章心得:

• 會寫些心得，強迫自己閱讀．

“程式週記”並且定期週期性更新．

大部分內容在我的twitter都會有，這邊只是將一些簡單的心得與感想註解一下．

本週摘要

這個禮拜花了太多的時間再弄自己的jekyll blog．本來想migrate到hugo去，但是因為hugo import jekyll有太多的問題（即便已經改了一些）還是有不少部分需要改． 後來還是把jekyll 3.0產生的樣板相關問題修復，也另外換了一個主題來使用． 好像jekyll又可以再戰十年？

本週持續NSQ的學習，先透過上週的Disk queue來改寫之前寫過的PubSub．

Go

Introduction Go 1.6

• Go 1.6剛在02/17正式release，Brad Fitzpatrick馬上在GopherCon India發表了這篇．裡面不僅僅有介紹了Go 1.6的功能也有順便預告了Go 1.7 ~ 1.10的產品規劃．當然也有一些笑話很有趣．

PlanB: a distributed HTTP and websocket proxy inspired by Hipache

• 透過Redis來架設的HTTP websocket proxy，可以拿來好好學習其中的作法與應用方式．

Google Cloud Vision API on Golang

• 在上週Google 總算開放Cloud Vision API給一般人申請使用，這篇文章有講解該怎麼做，當然也有提供他寫好的Golang Package

GOPHERCON INDIA 2016 Summary

• 2016最早開始的Gopher Con 有不少關於Go 1.6的相關議題．

nsq的使用與一部份介紹

• 最近幾週都在學習NSQ，這篇文章有不少的探討從技術層面跟他的設計理念都有提到．

Open-Source Phishing Toolkit

• 網路釣魚的工具給企業做測試與訓練用的．

Handling Database Migrations in Go

• 由gophish網路釣魚的package公司發的DB migration 介紹文．裡面使用的是goose，但是比較多人推薦migrate

goose: A database migration tool

• DB migration tool，可以在無痛的狀況下變更你得資料庫schema．並且查看有無任何問題也可以快速的rollback．

A Go library for carefully refactoring critical paths and code. lightweight port from github scientist

• 精簡版的scientist用在golang上面．

gago is a genetic algorithm written in Golang

• 基因演算法的golang套件，會隨機產生數個解法，評估後挑選最適解法．

Building binary executables for Android in Go

• 在Android系統上面跑go的excution，由於Go 1.6支援x86的Android系統，這篇文章的應用又更多了．

HOW WE BUILT UBER ENGINEERING’S HIGHEST QUERY PER SECOND SERVICE USING GO

• Uber 如何透過Go來打造高效率的查詢系統．不少架構與內容的討論．

Python

gRPC Practical Tutorial — Magic That Generates Code

• 這篇主要講解如何使用grpc．很詳細地講解從protobuf開始，到一些簡單的應用．

Ruby

scientist: A Ruby library for carefully refactoring critical paths.

• 由github出的可以將你的critical path做重構的工具，並且可以幫你的Ruby程式碼做更好的重構．

Android/JAVA/NODE.JS

Docker

iOS/Swift

Swift cygwin ported

• Swift Programming Language gained a Cygwin Port 在Windows上也可以用了

30 Days of Swift

• 每天寫一個Swift iOS App來學習Swift，真是厲害．

網站文章

产品经理，你真的有经理职权吗？

• 一般的產品經理(Product Manager）常常因為有掛著Manager的頭銜讓人誤為就是具有經理的職稱．其實這邊指的是對於產品本身的管理職權擁有．但是是不是真的PM都有這樣的職權？ 這篇文章有詳細介紹，並且從不同的層級來讓你更了解PM的工作內容．

IBM区块链技术(Blockchain)简介

• 一份由IBM提更的對於blockchain的基本介紹．

The Twelve Days of Crisis – A Retrospective on Linode’s Holiday DDoS Attacks

• Linode在去年聖誕節跟新年受到大規模的DDoS攻擊，這是一篇事後檢討文章．有清楚的介紹出事情的原因，經過與之後該如何防範．最近蠻喜歡看這類的文章，對於這種大規模出問題(Github, Linode)的檢討文章都有相當的深度．

網站收集

Become a Programmer, Motherfucker

• 超多各種語言的免費電子書跟相關連結

TIL: Today I Learn

• TIL (Today I Learn)是一個非常好的概念，透過github repo 來記錄．或許，也可以弄成一個TIR (Today I Read) 或是 TIB (Today I Browse)

What’s inside a PDB File?

• 微軟總算把PDB的資料格式開源，並且提供數個可以查看的工具．

有聲書/影片心得

USENIX Enigma 2016 - Several Horror Stories about the Encrypted Web

• 講解關於你認知的HTTPS其實沒有想像中的穩固．

本週專案

這邊會寫一些我的Project 52的成果.

本週專案:

https://github.com/kkdai/pd (PUBSUB) Publish-Subscrbe message broker with Disk queue in Golang

心得:

原本想到說PUBSUB跟DiskQueue應該要很簡單的整合，結果發現問題還真不少．首先要先定義DiskQueue本身是需要放在哪個部分，找過不少的地方之後，後來決定獨立出來一個Topic物件，並且讓他控制DiskQueue來存取所有Publish的資料．這樣的好處有:

• 當一個topic有太多的訂閱者(subscriptors)可以讓Publish不會有block
• 當Topic有太多資料要送，可以先放在DiskQueue之後再慢慢Queue出來．

這樣的設計有一點參照到原先NSQ的設計，不過相對的簡單．

接下來應該會多花一點時間來讓DiskQueue更加的細緻，也多花一點時間去了解整個檔案的多工控管的細節．

前言

主要是整理一下最近在一個學習領域的Line群組討論到關於網路廣告業界的一些名詞．主要的原因是在討論最近很紅的新聞”延攬台大「機器學習之神」林軒田，Appier 啟動產學合作計畫” 大家就在討論台灣的AD產業近況與大陸成熟的AD發展．

當然這種討論就有一堆名詞跑出來，其實最近應該也不少文章)有提到．我在這裡只是給自己筆記一下，那些名詞到底有什麼差異．

產業演化

• 原本由廣告主(Advertiser)跟發布商(publisher)買廣告．就像是某公司看上彎彎的人氣請他在他的人氣部落格上面放廣告一樣．
  • 問題:
    • 由於廣告主與發布商越來越多，不易管理．
    • 廣告主需要自己找發布商太麻煩．
  • 解決方式:
    • 有人出來搜集需求與供給成立AD Network
• “AD Network”來收集所有廣告主的需求與發布商的供給並且透過分類的方式（將發布商分類）來幫廣告主分發廣告．
  • 問題:
    • 重複付費，無法精準找到瀏覽者．
  • 解決方式:
    • 透過瀏覽者Cookie，開始精確的分類瀏覽者
• “AD Exchange” 來透過Cookie來仔細分析每個網路上的瀏覽者，並且精準的定位出該使用者有興趣的廣告．
• RTB(Real-Time Bidding) 是AD Exchange會提供的功能，透過競標的方式來讓廣告主針對潛在客戶來競標，價高的人可以投放他的廣告．
  • 問題:
    • 大部分廣告主都是透過中間商來跟AD Exchange溝通與購買廣告．無法找到最佳策略(舉例: 廣告商不知道該在Facebook投廣告，或是Google投廣告才能獲得最佳效益）
    • 廣告主可能自己是發布商，透過AD Exchange 可能會買到自己的廣告．
  • 解決方式:
    • 有個人專門來幫助需求端成立平台，廣告主可以透過該平台直接將需求下給各個不同的AD Exchange
• “DSP” (Demand Side Platform)需求方平台幫助廣告主成立一個平台可以將多個AD Exchange整合後給廣告主選擇與使用．並且DSP也提供RTB
• 同時在另外一方面發布商也有相關的聚合服務叫做SSP (Support-Side Platform)．SSP整合了DSP，AD Exchange與AD Network的需求，並且本身也提供RTB．讓發布商可以更容易地在他的媒體上面將廣告賣到正確的使用者身上．

目前幾個已經知道的名詞會形成以下的狀態．

(Pic: from orbitsoft)

• 這張圖表是另外一件事情就是: 廣告主透過DSP成為了RTB的client，而發布商透過了SSP成為了RTB的Server負責提供資訊給DSP．

• 當DSP越來越多的時候，ATD(Agency Trading Desk) 就是可以讓廣告主去挑選不同的DSP

• 回過頭來不論是ATD還是DSP，廣告主還是得面對去挑選不同的平台與方式來投放他的廣告．但是如何制訂自己的廣告客群是誰？就是得要透過DMP(Data Management Platform)．

  • DMP分析使用者偏好篩選出何者是潛在客戶．(資料來源: SSP)
  • 透過投放的效益報表來顯示最適合的投放平台．(資料來源: DSP)

應該就這些…..

角色舉例:

• Advertiser: 廣告主
  • Ex: 任何一家需要廣告的企業(Visa, Apple, 微軟…)
• Publisher: 發布商
  • Ex: 具有高瀏覽量的網頁或是App(彎彎的網站，Yahoo 新聞，蘋果新聞…)
• AD Network / AD Exchange
  • 具有廣告發佈與使用者追蹤能力(cookie)的廠商 (Facebook, Yahoo, Google Adsense)
• DSP(Demand Side Platform) 需求端平台
  • 具有多平台的媒體公司，就有會提供DSP．通常像是比較大媒體公司（ex: Yahoo)其實本身也做DMP．
• DMP (Data Management Platform) 能夠做資料分析，當然最重要的就是資料的個數．
  • TalkingData的Mobile DMP透過自己擁有的8億個App使用者搜集來的資訊可以分析，進行推薦進而讓廣告商能夠更精準的投入廣告．
  • 當然Facebook也是如此，透過不同使用者的Facebook ID可以追蹤使用者的喜好幫助他們分析進而找出更精準的廣告投放方式．

數據轉錄與心得

避免提到太多個人談話，盡量將數據找到網路上有的資訊．

• 根據Marketing Technology Landscape Supergraphic (2015)的報告．2015年的時候有1876個Advertising Vendor在市場中．
• Google在積極回到China的同時Google Double Click, AD Exchange/ GA / Google DMP看來都有機會回到China並且大舉徵才．（不過跟RD無關 :p)
• 負責公司內部管理AD策略與方向部門叫做Data Strategy，這裡有一些LinkedIn的Director Data Strategy相關履歷．也就是專門負責調配媒體成本到可編程的購買(shift media budget to programmatic buy)也就是透過DMP來買媒體廣告．
• AD Tech中對於技術與資源的要求都相當的高．其中技術不外乎是AI與ML，而資源就是$與媒體關係(不外乎財經關係）．就這幾點，其實台灣的廠商很難做到DMP，頂多就是DSP．
• 大媒體的DSP(ex: Yahoo）本身也會提供DMP的服務．

相關文章:

• Adpartner介紹RTB
  • 蠻推薦這篇的，雖然是公司的宣傳文宣．但是內容淺顯易懂．
• 什麼是RTB 實時競價廣告？他將是未來趨勢！
• Cookies, DMPs and Is “Big Brother” Watching You?
• 十大網路忽悠名詞第十名：RTB，過度重視這些事情才是讓你企業失敗的主因！
  • 這篇文章不錯，用幾個字馬上讓你了解各個名詞的作用．
• 行銷人都要知道的 DSP迷思求解7大守則: 從行銷人員的情境來瞭解網路廣告業的名詞
• RTB China: 不少關於網路廣告的系列文章部落格
• 技术解读 DMP：个性化推荐的基础，移动互联网最宝贵的数据资源

相關slide: