黑皮考町

  錯誤訊息 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 原因 因為 docker 的設計是走 client-server 的架構,  如果少裝了 server 的部分就會出現以上的錯誤訊息 解決方法 因為 docker daemon 需要使用 linux kernel 上的某些功能, 所以若想要在 mac 的 OS X 上使用 docker 必須額外起一台 linux VM 給 docker daemon 用  Step 1. 安裝 virtual box $ brew install virtualbox --cask   Step 2. 安裝 docker machine $ brew install docker-machine --cask   Step 3. 設定 使用 docker-machine 建立 VM 跑容器 $docker-machine create --driver virtualbox default $docker-machine restart   輸出環境變數 $docker-machine env default 如果執行以上的指令出現錯誤訊息 Error checking TLS connection: ...  可以執行以下指令重新產生憑證 $docker-machine regenerate-certs 最後套用環境變數, 讓 docker 知道要怎麼去跟這台 VM 溝通  $eval $(docker-machine env default)   測試 若做完以上的步驟沒噴錯誤訊息的話, 可以跑個 hello-world 看看 docker daemon 有沒有起來 $docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 0e03bdcc26d7: Pull complete Digest: sha...

  前言 在這個資訊爆炸的時代, 資料的產生速度飛快, 面對這些海量的資訊, 若以傳統的方法做資料分析或是分析前的資料處理(Extract Load Transform, ETL), 勢必會面臨到硬體資源不足(記憶體不夠)或是資料處理速度太慢的問題 記憶體不夠時, 將虛擬機做垂直擴展 scaling up 就能夠暫時解決, 但若要加快資料處理的速度, 就會需要一個分散式的資料處理引擎 Spark 或是 Cloud Dataflow, 透過動態的水平擴展 Scaling out 的方式來增加資料處理的 worker 去消化大量資訊 Apache Beam 2016 年時 Google 開源出一套分散式資料處理框架, 定義在 Spark, Flink 以及 Cloud Dataflow 等等分散式資料處理引擎的上層, 讓開發者可以輕鬆地設計資料處理的 pipeline 並運行在分散式的環境裡 它有以下的優點 開源 背後社群龐大, 容易找到資源 移植性 同一個資料處理邏輯可以跑在各大分散式資料處理引擎上 (Flink, Spark, Dataflow...) 擴充性 除了使用 built-in 的 I/O Connector 之外, 開發者也可以自由地實作客製化版本的 Connector 模組 Cloud Dataflow Google 完全託管式的(Fully Managed) 分散式資料處理引擎, No-Ops 的服務特色強調不需要額外的維運人員來維護底層的基礎設施 Dataflow 的上層主要是運行 Apache Beam 的程式碼, 並支援在 Runtime 時動態的彈性擴充底層的運算資源, 因此使用 Dataflow 的開發人員可以更專注地開發資料處理的邏輯以及 pipeline 的設計 開始寫 Apache Beam 程式 Step 1. 建立實驗環境 為了簡化說明, 接下來的示範會跑在 Jupyter Notebook 的環境裡 因此首先會需要在 GCP 上用 Dataflow 的 Notebook 功能建立一個可以跑 Jupyter Notebook 的環境 建立完成後選擇 Open Jupyterlab 進入筆記本 接下來 Step 2. & Step 3. 的程式碼可以直接複製貼到筆記本上執行 Step 2. import 必須的套件 ...

  GitLab flow 採用 upstream first policy, 只有一個主要的分支  "master", 當要開發新功能時, 就是從 master 開一條新的分支出來修改, 最後再透過 Merge Request (MR) 把分支合併回 master 發布時, 針對不同的環境建立不同的分支像是 pre-production 以及 production 分支, 透過 cherry-pick 的方式, 將要發布的內容先從 master 合併到 pre-production 的分支上,  當pre-production 測完沒問題後再做一次 cherry-pick 把這些更動內容從 pre-production 合併到 production 的分支上作正式的發布  簡單的說, 所有的更動都是從 master 開分支出來改, 然後才合併到下游分支中 (master > pre-production > production) 結論 GitLab flow 相較於 Git flow 來說不會太過複雜, 沒有一堆分支需要維護, 即使是新進人員也能夠快速地上手, 而相對於 GitHub flow 來說在軟體發布的方面也比較有彈性, 不會被侷限在主分支 master 上, 因此 GitLab flow 等於是集結了 Git flow 以及 GitHub flow 兩者的優點 推薦閱讀 淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part I) 淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part II)

  前言 先前  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part I)  介紹過 Git flow 的分支策略非常複雜, 開發過程中會需要管理許多種不同的分支 develop/feature/hotfix/release/master, 對於需要在短時間內作持續發布的團隊來說並不是很適合 GitHub flow 相反的 GitHub flow 就非常的簡單, 只有兩種分支:  feature 分支跟 master 分支 feature 用來開發新功能 master 用來發布 開發新功能時會從 master 分一條 feature 分支出來改, 改完沒問題後再提交 Pull Request (PR) 到共用的遠端儲存庫, 當審核的人覺得沒問題後,  提交的修改內容就會被合併到 master 上保存 結論 Github flow  非常適合做持續發布, 缺點是因為 master 只會保存最新的版本, 但在某些情況下我們可能會不希望最新的版本馬上被發布出去 下一篇  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part III)

  Git flow 最早被提出的分支策略 由兩個主要分支  master, develop 和三個支援性分支 feature, hotfix, release （暫時性）所構成 基本上, develop 分支會放軟體的最新版本 而 master 分支則是用來放最穩定的版本, 所以軟體要發布正式版本時也會用 master 分支來發布 Feature 在開發的過程中如果要加新功能, 會從 develop 額外拉一條新的 feature 分支出來作新功能, 等功能完成後再合併回 develop 分支裡, 在合併完後 feature 分支會被刪除 Hotfix 當軟體在發佈之後若被發現有 bug, 通常會從 master 分一條 hotfix 分支出來作 bug 修復, 等問題修復完後, 這條 hotfix 分支會被合併到 master 以及 develop 上, 當合併完後也會被刪除 Release 在軟體正式發佈前, 通常會先將軟體預先發布到一個準生產環境中讓 QA 團隊進行測試, 當通過測試之後, release 分支會被刪除 缺點 Gitflow 太複雜了, 有太多的分支需要管理, 不適合對於需要在一天內作多次持續部署的團隊使用 下一篇  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part II)

前言 相信大家都有以下這個經驗 如果想要在一個獨立且乾淨的環境裡跑 Machine Learning 的實驗,  通常會使用 Anaconda  來建立虛擬環境, 然後當需要的模組都安裝進去後 再執行 activate 將環境給套用進來 但如果是想要在 Jupyter Notebook 裡使用 Anaconda 建立的環境, 那該怎麼做呢！？ 首先 Step 1. Create conda env $ conda create --name mycondaenv python=3.7 Step 2. Enter the environment $ activate mycondaenv Step 3. Install required package $ pip install ipykernel Step 4. Install a new kernel $ python -m ipykernel install --user 以上的動作做完之後 就可以在選擇 Kernel 的清單裡刊到剛剛新增的 mycondaenv