YinHong coding notes

YO! ElasticSearch 1.x 升級 2.x 的一些小心得 來一段多餘的前言 為了不寫半行程式碼的方式完成學校的作業，我還是選擇了用ELK中的E跟K來偷懶一下，做一下資料的統計啊～ 數量長條圖啊～ 之類的 不過因為裝了新版的Kibana，跟老師提供的ElasticSearch 1.x不合，所以花了很多時間在處理升級的事...，這之中實在充滿雷啊！！ 升級ElasticSearch 1.x --> 2.x https://www.elastic.co/guide/en/elasticsearch/reference/2.4/restart-upgrade.html 最簡單就是參考這篇，不過我參考了還是弄了老半天 先來講解一下裡面每個步驟  1. Disable Shard allocation shard 就是一個 Lucene index，至於Lucene，應該算是個檢索引擎 ElasticSearch平時會把資料分成多個shard然後再分別分在你所運行的node裡面 阿既然要升級，就先把shard allocation關掉，專心對付每個node PUT / _cluster / settings { "persistent" : { "cluster.routing.allocation.enable" : "none" } } 2. Perform a Synced flush (optional) 這步主要是讓接下來shard在recover的時候快一點 POST / _flush / synced 3. Shutdown and upgrade all node 這邊就比較麻煩了 你可以選擇 安裝一個新版本的ElasticSearch，然後把conf跟data路徑指向舊版的位置 解開新版壓縮檔，然後把除了data, config的都蓋過去 安裝一個新版本的，然後把舊版的config跟data拉到新版的資料夾下 在1.x --> 2.x 的時候，要注意舊版的config裡有一行 http.cors.enable

UX的五大成分 主要分為 心理學 可用性 設計 文案撰寫 分析 心理學 使用者為什麼要來這裡 必須做多少事才能達到目的 使用多次後，會有什麼習慣 對於這個東西的期待是什麼 設計前是否有先入為主的假設 他們會多常做這件事 可用性 能否使用較少的輸入來完成 有什麼方法防止使用者端的錯誤嗎(防呆 是清楚直接還是聰明過頭 好找 v.s. 不錯過 v.s. 自然就會這樣做 流程有符合使用者假設嗎 有提供使用者必須的資訊嗎 有更簡單的方法嗎 如果沒有讀說明的話，有辦法使用嗎 設計 看起來如何，是否可藉由外觀獲得信任 如果沒有文字說明，能否傳達目的 表現品牌的風格? 設計上是否能引導目光，進而化為流程 顏色、形狀、排版來讓使用者找到他們想要的東西 可點擊 v.s. 不可點擊 文案撰寫 內容明確自信 鼓勵使用者完成目標嗎?我們想要他完成目標嗎? 最重要的內容佔了最多的篇幅嗎? why not? 告知或者假設他們已明白 減少使用者的思考、焦慮 分析 用資料證明你是對的，或者說明其真實意義 搜尋的是主觀意見還是客觀事實 使用者行為的原因? 體驗上的設計是絕對的數字還是相對地改善 如何衡量? 測量的是正確的東西嗎? 何不也尋找一下壞的結果 如何利用分析改善

前陣子團隊因內部的混亂 ( 或者是跟風 ) 所以想導入最近很紅的agile 剛好我在學校就是在學Scrum的 雖然稱不上高手，但基礎還是有些的 為了跟團隊成員介紹這套流程框架 就順手作了個投影片丟上了slideshare http://www.slideshare.net/ssusered87b5/scrum-64316142 後話是... 最後因為種種原因，團隊中的流程變成了扒皮拆骨、東湊西湊的類Scrum XD

今天在試著用ELK作為Monitor的工具 身為一個 懶人 Devops的愛好者 就選用了Docker作為快速建起這些服務的工具 (不得不說，這實在是很方便阿<3) 不過其中有不少小問題是要研究一下才會動的 Docker的container都是獨立的個體 通常在run的時候你會自己指定好container跟local的port對應 > -p 8080:8080 之類的 但是有時候多個服務之間會有需要彼此溝通的情況 比如說在 1. ELK的時候logstash要跟elasticsearch溝通 2. Kibana要跟elasticsearch溝通 這時候就要用到--link的option 通常會這樣使用 > docker run -it -link 'container_name':'alias' 'image_name' 然後再使用的時候，如果原本要使用 localhost:8080 就要改成 alias:8080

1 .將「安全性較低的應用程式存取權限」設為「啟用」 找到 Google 帳戶內找到「安全性較低的應用程式存取權限」的設定 或是直接開啟此網頁 https://www.google.com/settings/security/lesssecureapps 登入後設為「啟用」。 2.解除人機驗證鎖定 直接開啟此網頁 https://accounts.google.com/b/0/DisplayUnlockCaptcha 點下「繼續」。 3.啟用兩步驟驗證，再設定應用程式專用密碼 直接開啟此網頁 https://accounts.google.com/b/0/SmsAuthConfig?hl=zh_TW ，啟用兩步驟驗證。 不過要注意的是，以後在尚未信任的裝置上用email跟密碼登入 Google 帳號，會變成無法使用，一定還要再次透過電話或簡訊驗證，才能登入帳戶。 開啟此網頁 https://security.google.com/settings/security/apppasswords?pli=1 ，讓它產生一組應用程式專用密碼，然後把寄件程式內的 google 密碼換成這組應用程式密碼。 注意哦！這組應用程式專用密碼只能登入一個地方，如果把這組密碼先拿來當smtp寄信，又再拿去登入其他東西，後來那個是無法登入的。

今天AWS上的ip又換位置了阿 想要ssh上去一直失敗才發現這件事 然後問了我們老大 他說: 阿你就自己反查阿 這我才想起來domain name對應回ip就好了 使用指令：nslookup 然後會出現 ">" 在後面打上要反查的DNS, 就可以得到其IP address.

經常在軟體開發過程中提到Unit Test 但我發現好像其實很多人不太懂什麼是Unit Test 所以來稍微談一下，不過這網誌主要還是在打我自己的筆記~ Unit Test幾個原則 FIRST Fast Isolated Repeatable Self-Validating Timely 3A Arrange (對應到一般測試框架，大概會叫做Before/Setup) Act (TestCase) Assert (驗證階段) Unit Test的定義 首先，這必須是個白箱測試 對象是程式中最小的邏輯單元 e.g. function/method 對於function的interface(也就是輸入/輸出)做檢查/測試 Unit Test幾個障礙 心理層面--- Product code 我寫，Test code也我寫？不是應該給QA嗎？！(物件的設計和使用的人都是developer，所以要自己寫)  自己的測試自己寫啊混蛋 已經手動測過都對了，還有必要寫 Test code？(未來重構或者新增功能的時候都可以在跑喔-->Repeatable) 寫 Test code 好麻煩！(你自己手動測個幾次會更麻煩der ) 技術層面--- 要怎麼寫測試？(根據用的程式語言找對應的測試框架來用摟 e.g. Java-->JUnit/Javascript-->Mocha) 寫著寫著就變成整合測試了(Integration Test)，咦！？(這就是違反了Isolated的原則了，在程式碼中有些相依的物件，所以就需要mock/stub/fake這類的偽物來協助你) 到底測了多少勒？(這是個Code Coverage的問題，有些工具會幫你檢查出你所寫的測試到底達到多少覆蓋率 ) 帶來的好處呢？ 在程式交接時，將測試作為說明書來看，可以快速瞭解每個單元的用途，當然也要記得加上一些註解 在新增了新的功能後，將過去的單元測試都跑一次，以確保新增這個功能後，過去的功能沒有壞掉 (這叫做 Regression Test 回歸測試 ) 秀下限之最近遇到的困難     最近在測Android的libarary的

在編輯器中，換行有分 CRLF ---> \r\n CR ---> \r LF ---> \n Linux和Window預設的是不一樣的 autocrlf = false  ATOM 相關TAB設定 show Invisibles 可以顯示隱藏的元素，like \r, \t, \n Tab Type : 用soft是空格 用hard是\t