YinHong coding notes

如果不能從幫助團隊獲得滿足感，那麼就不要成為一名領導者 將自己視為其他開發人員的導師 隨時準備好回答團隊成員的問題 減少具體的編碼工作，但仍然要編碼 要謙遜 要誠實

在angular提供的ng-router或者third-party的ui-router中，在裡面這樣那樣的切換頁面過程中，瀏覽器的網址都會變更，但其實如果直接輸入那個網址，卻會 404 !! 應該是因為 angular在切換頁面的過程中，不希望刷新頁面，所以使用了類似partial view的概念，對需要更新的部分用http request去把需要的content拉出來，並且將網址列的內容更改為本身router的state對應到的url !! /*偷渡一段在這邊 angular默認會使用一個#符號來對url進行route 例如 http://tony.com http://tony.com/#/home http://tony.com/#/setting 如果不想要出現這個#的話 要用$locationProvider，並且設置相對連接的起點路徑 在app.config中加入 $locationProvider.html5Mode(true); 在index的head裡面加入 <base href="/"> */ 而這邊要提到的就是將網址列的內容改為本身router的state對應到的url，這是如何做到的呢～～ 這是使用了html5的history api來達成，可以透過window物件->history物件瀏覽瀏覽器的歷史，並且有提供一些方法讓你可以在歷史紀錄中前進以及後退要在歷史紀錄中往後移動，可以： window.history.back(); 同樣的，你也可以往前移動window.history.forward(); 你可以用 go() 方法來從頁面的 session 歷史記錄中載入特定紀錄， 以目前頁面的相對位置而定（目前的頁面想當然爾是 index 0） 往前一頁（等同於呼叫 back()）：window.history.go(-1); 往後一頁（等同於呼叫 forward()）：window.history.go(1); 你可以查看 length 這個屬性來取得目前瀏覽歷史的總數 ： var numberOfEntries = window.history.length; 加入和修改歷史紀錄 HTML5 加入

Some considerations: Do you name your URL objects you create explicitly, or let the server decide? If you name them then use PUT. If you let the server decide then use POST. PUT is idempotent, so if you PUT an object twice, it has no effect. This is a nice property, so I would use PUT when possible. You can update or create a resource with PUT with the same object URL With POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object. /* idempotent 的意思是如果相同的操作再執行第二遍第三遍，結果還是一樣。 根據 HTTP 的規格，GET, HEAD, PUT 和 DELETE 是 idempotent 只有 POST 和 PATCH 不是 idempotent */ 1.若該物件為自定義傳輸的則為PUT, 由server決定則是POST 2.PUT是 idempotent（冪等），若重新PUT兩次則沒有影響 3.PUT可以更新以及新增，只需使用同一個URL 4.POST可以同時接受多筆request進入並修改不同處

10/08今天開始做這個練習，今天的進度是成功的讓手機可以送音訊到VLC PLAYER上 notes: 需要指定sender&receiver的ip，所以如果要可以隨意手機安裝就可以連線講的話，需要從sender透過web session傳輸media data 再透過web session傳輸給receiver!! 取得手機IP public  String getLocalIpAddress() {              try  {                  for  (Enumeration<NetworkInterface> en = NetworkInterface                         .getNetworkInterfaces(); en.hasMoreElements();) {                     NetworkInterface intf = en.nextElement();                      for  (Enumeration<InetAddress> enumIpAddr = intf                             .getInetAddresses(); enumIpAddr.hasMoreElements();) {                         InetAddress inetAddress = enumIpAddr.nextElement();                          if  (!inetAddress.isLoopbackAddress()) {                              return  inetAddress.getHostAddress().toString();                         }                     }                 }             }  catch  (SocketException ex) {                 Log.e( "WifiPreference IpAdd

在Youtube常常看到許多直覺且合理的網址連結，但自己的網址卻像是一條亂碼，想要找到怎麼改卻....各種難 自訂一組簡單好記的網址，能讓觀眾輕鬆找到您的 YouTube 頻道 (像是 youtube.com/c/creatoracademy)。可供挑選的網址是依據您的顯示名稱、YouTube 使用者名稱、現有的別名網址，或是連結網站的名稱而定。有時候您可能要再加幾個字母和數字，才不會和其他人的網址重複。 重要提醒：自訂網址一旦建立之後就不能更改，請務必三思而行。 資格規定 如果要設定自訂網址，您的帳戶必須保持良好狀態並符合下列條件：  訂閱者人數達 500 名以上  頻道存在時間至少已達 30 天  已上傳相片做為頻道圖示  已上傳頻道圖片  如果您將自己的官方網頁與您的頻道或 Google+ 專頁 建立連結並完成驗證 ，也可以設定自訂網址。 符合自訂網址的資格後，就會在 進階帳戶設定 中看到通知。此外，您也會收到電子郵件通知，創作者工作室也可能會顯示通知訊息。 設定自訂網址的步驟如下： 登入 YouTube 並瀏覽至 進階帳戶設定 。 在 [頻道設定] 處找到取得自訂網址的通知，按一下其中的連結。 系統將引導您申請自訂網址。 畫面上會顯示系統核准您使用的網址。您無法更改這組網址，不過可能需要外加幾個字母或數字，避免與他人重複。 請勾選「我同意《服務條款》」旁的核取方塊，再按一下左下角的 [變更網址]。 新網址會連結到您的 YouTube 頻道和 Google+ 身分。網址獲得核准後，就無法申請變更。確認各項設定後就能按下 [確認選項] 。 Reference:https://support.google.com/youtube/answer/2657968?ref_topic=3024172&hl=zh-Hant

『你的問題是甚麼？』 『你要用甚麼方法來解決問題？』 ※ Unit Test 確保程式想寫的和你想的一樣 『說明文件往往過時無參考意義、程式出錯了不知道錯在哪裡、需求異動常常改東壞西』，因此你需要 Unit Test，透過單元測試可以讓你快速發現問題之所在，雖然初期會花費時間與成本在撰寫看似毫無意義的程式，但是在系統由開發進入維護後，效益就會慢慢顯現出來。 那 Unit Test 有甚麼特性呢？ 最小的測試單位 外部相依性為零 不具備商業邏輯 測試案例之間的相依性為零 一個測試案例只測試一件情 要達到這些特性，程式碼重構還是必須的，過去在撰寫程式的時候，我們往往讓物件與物件之間十指緊扣、緊緊相依。這時我們就應該使用介面 Interface，斷開物件與物件糾結的鎖鏈。 過去我們在撰寫程式的時候，常常一個函式數十行或長達數百行，讓程式不僅無法閱讀也無法達到可測試性，這時我們就必須要重構，將各別處理的邏輯獨立開來，這樣我們才能夠讓這所謂的『黑箱』慢慢變成『白箱』。 但是對於已經發臭到不行沒人敢維護的程式碼，到底該怎麼樣重構才好呢？我們可以透過黑箱的測試先錄製測試的結果，比方說用 Firefox Plugin Selenium 來錄製測試案例，再來進行程式碼的重構。 當有了這樣的測試案例來輔助，讓你的程式碼即便再『黑』，擦上 SKII 也能夠讓你『白』回來！ ※ TDD 確保你先想清楚才動手寫 當你會寫單元測試後，接下來就可以朝著 TDD 的步伐邁進！ 所謂的 TDD 就是 Test-Driven Development 測試驅動開發。 這樣的開發方式對我來說算其實是相當的陌生，過去的開發方式我們 習慣先以需求為主 ，然後構思這個需求需要那些功能，再針對這些功能進行開發。在這樣的過程中往往會過度發散所需要的功能，常常會考量東、考量西的做了一堆例外的過濾。 而 TDD 就是以 用『測試』來輔助『開發』 ，我們先寫好 Test Case，才進行功能的開發，讓 Test Case 從紅燈變成綠燈，才繼續撰寫下一個 Test Case。透過這樣的 『 輔助』 ，可以讓你更 『專注』 在 Test Case 的處理，才不會過度發散浪費不必要的時間在無謂的功能上面。 就跟安西教練

因為測試的原因我不得不要學會關於Promise的相關知識啊～～ 偏偏中文相關文章又很少很難懂＝＝～ Propagation Promise 中 then return 的東西大有玄機，有三種情況 Promise: 下一個 then 會是一個全新的 Promise Value: 這個 Promise 已經被滿足了，之後串接的 then 都會是此 Value Throw exception: 這個 Promise 發生問題，之後的 then 都不會執行，會改執行 fail 的 callback Chaining 就是上述第一點，可以改善 Callback Hell ，讓 nested 的 callback 少一點return getUsername() .then(function (username) { return getUser(username); // new promise }) .then(function (user) { }); Combination 當有多個 Promise ，而你想要等這些 Promise 都執行完(fulfilled)，才要執行下一步的話，可以使用這個非常 awesome 的用法Promise.all([promiseA, promiseB, promiseC]).then(function () { console.log "A, B, C has done!" }); Handling Errors 除了 then 之外，還有 catch 的 method 來接 chaining 過程中有發生的 exception ，用 done() 會讓未處理的 exception 噴出來 Promise Creation 假設我們要把 readFile 包裝成 Promise ，可以這麼做var deferred = Promise.defer(); FS.readFile("foo.txt", "utf-8", function (error, text) { if (error) { deferred.reject(new Error(error)); } else { deferred.resolve(text);

在安裝好 1. VS2015 RC 2. iTunes最新版 之後～～ -->開啟iTunes並接上裝置 -->開啟VS2015RC   -->新增專案   -->選擇"Javascript"-->"Apache Cordova Apps"   -->輸入專案名稱後按ＯＫ   -->編輯專案中config檔，在 Application Id 中輸入**************（這邊找我），並儲存   -->在上方欄位中選擇 "Tools" --> "options" --> "Tools for Apache Cordova"   -->選擇 " Remote agent Configuration "，並將內容修改如下圖（IP也找我）   -->將建置設定改為這樣，即可開始建置！   -->建置完成後在iTunes中的手機資訊畫面進入app區塊   你會看到這個畫面    選擇你所建置的app並且 按下旁邊的按鈕（剛建置完會顯示"更新"ＯＲ"安裝"） ，最後按下下面的同步即可將應用程式安裝進手機裡了！！！    有任何建議請跟我說，我會馬上修改！

若iTunes非最新版，則更新到最新 1. 在裝置管理員中，找到Apple iPhone，右鍵>內容 2. 上方選單 驅動程式>更新驅動程式 3. 選擇"從清單或特定位置安裝(進階)">下一步 4. 選擇第一個"在這些位置中尋找最好的驅動程式"，並勾選"搜尋時包括這個位置"     然後瀏覽選取以下路徑：C:\Program Files\Common Files\Apple\Mobile Device Support\Drivers     然後下一步>完成！

----E2E 可以幹麻～ 確認畫面的引導以及協調性，提升使用者體驗 模仿使用者行為 記錄行為供使用 必要性～ 確認使用者與開發者間認知的一致性 確保第一印象 bug越修越錯 ～單元間有獨立性，也有疊加的部分（獨立性的共通性 容易越改越錯 ～只測個人的部分，沒有協調 工具 selenium等等～～ E2E可在開發後期在寫 ----Backend 測試要～～ 1.Define Requirement 2.Define Flow 3.上啊！！ 規格分成 1.文字 2.腦 3.可被執行的規格 方法 -->RED-->GREEN-->Refactor CI(持續整合 -->有變就build-->測試是否正常-->馬上修 CI Tool -->Jenkins   or  strider

What - 什麼是 BDD BDD  的全名為 Behavior-driven development  BDD 是透過 DSL (  Domain-specific language  )來描述系統的行為。 Why - 為什麼要使用 BDD 因為使用者的需求，要轉變成系統的程式碼，中間的落差相當大。 BDD 的效益在於，能讓使用者、測試人員與開發人員，可以用一樣的方式來描述與了解需求。 由我自己來說的話：若需求文件就是一個可執行的程式碼，那麼只要執行需求文件就能確定開發的內容是符合需求的！！ When - 什麼時候使用 BDD 當撰寫好驗收測試案例，建立好系統雛形。開始準備著手開發實際的程式碼前，使用 BDD 來描述「驗收測試案例」所對應的「系統行為與腳本」 。 Who - BDD 該由誰來撰寫 建議由開發人員主導，測試人員輔助，確定這樣的 Scenario 是否為測試人員所預期的，是否滿足了驗收測試案例。但測試案例是由 user story 而來，因為第一層的 acceptance test cases 就是用來定義 user story 要滿足哪些 scenarios 才算完成。 確認完畢後，開發人員就可以直接從 code template 著手進行 TDD 。 Where - BDD 的腳本該放在哪裡 BDD 的腳本，也就是 scenarios，其實就是產生測試程式的骨架，只是是使用 DSL 來描述罷了。 而 BDD 的內容，其實就是 TDD 的測試案例，可能包含了整合測試與單元測試的範疇。 所以 BDD 的專案，可直接視為整合測試專案或單元測試專案，建議這兩者要分開，以便開發時可以迅速執行單元測試，在持續整合的 server 上，則可以執行到完整的測試程式。而 scenarios 可以透過一些工具，掛載在持續整合 server 的 report 上，進而成為一種 live documents ，既透明、又即時，而且每個人都可以看得懂。 最後補充敏捷的四條宣言 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration

所謂跨站HTTP請求(Cross-site HTTP request)是指發出請求所在網域不同於請求所指向之網域的 HTTP 請求，例如網域A(http://domaina.example)的網頁載入一個<img>元素向網域B(http://domainb.foo)請求影像資源(http://domainb.foo/image.jpg)。這種作法在現今各網頁相當常見，網頁常常會載入其他網站資源，像是CSS樣式表、影像、程式碼等等資源。 基於安全性考量，程式碼所發出的跨站HTTP請求受到相當限制，好比說用 XMLHttpRequest 物件所發出的請求受限於 同源政策(same-origin policy) ，只能發送HTTP請求到和其所來自的相同的網域，不過開發者也希望能發展出安全的跨站請求方法來開發更好、更安全、搭配多種資源的網頁應用。 恩... 上面都是節錄自MDN的HTTP access control (CORS) 這篇 W3C 下轄的 網頁應用工作小組(Web Applications Working Group) 建議採用 跨來源資源共享(Cross-Origin Resource Sharing, CORS) 來達成安全的跨站資料傳輸。CORS提供網頁伺服器支援跨站存取控制方法，另外，這份規範是用於API容器，例如以XMLHttpRequest作為調解機制，好跳脫同網域限制；也因為客戶端瀏覽器會多出新的跨來源共享元件，包括標頭和政策施定，所以說，伺服器也必須相應地處理這些新增機制，也就是處理新標頭以及用新標頭發送資源。本文內容主要和網站管理員、伺服器端開發者和網站開發者有關，然後關於伺服器部分請參閱 伺跨來源共享:從服器觀點出發(以PHP為範例) 補充文章。 跨來源資源共享標準 可用來開啟以下跨站HTTP請求: 用XMLHttpRequest API進行跨站請求，如前所述。 網頁字體(跨網域CSS的@font-face的字體用途)， 所以伺服器可以部屬TrueType字體並只允許授權網站進行跨站載入使用 。 WebGL紋理 用drawImage畫到畫布上的影像

今天幫賈賈查個東西 要怎麼把curl 的action轉成js或者jquery的ajax code 恩.... 看起來是完全可行的（畢竟我是個菜鳥 但我從六點多開始試到凌晨一點多都是失敗的....不論各種debug, 自己開web api比對resource, response 後來利用了"postman cross domain" 以及 "curl cross domain" 查到了 Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions. Ajax calls can only be made to URLs within the same domain. 然後有一篇神文說“你可以用jquery ajax 做到cross domain"，他的方法是利用jquery ajax傳給一個php頁面，再讓php用curl的方式把remote data吐回來，好複雜啊這～ 文章的最後，到底為什麼postman可以cross domain而我就不行呢？ https://developer.chrome.com/extensions/xhr google developer的文章中有寫道 （非拿不可的話，似乎可以用JSONP或者CORS來解