• 1 有bug → 解決解答回覆客戶 → 客戶無回覆 = bug已解決 (沒有QA或客戶明言: close或re-open)
• 2 維護案客戶2個月無來信 = 系統穩定 & 無重大bug (沒消息=好消息的另解?)
• 3 沒有git、已存的svn repo在主機issue下已損毀(前人的code history追不到)
  →自己用local git 控管新案(，在通常1案1工程師的情況下)。
  →也知道designer FTP上傳/更新了什麼
  →local git好處是，rebase anytime (雖然也沒有很多閒暇時間rebase說 (茶~) )
• 4 對於remote、outsourcing工程師的code沒有建構CVS workflow (只有FTP上傳)
  →(內部工程可以做linux command)每日或不定期在dev folder 做 git status，有變更就產生commit log
  →不能做linux command，每次要check變更時要下載全web code (占流量、占時間成本，不推)
• 5 沒有issue track、[PM/企劃/Boss/客戶] [不會/不想]用。
  →自己開google excel 分享給他們，並議定全issue放上面，不放上面不會有回覆。
  ps: 不是所有案子都這樣。短期、小案子直接email信件往來解決(「若沒有多案子卡時」，通常修bug時程也快)。
• 6 只有兩個主機環境，dev + live；而不是dev + test + release + live (或 私以為基本款為 dev + test + live)。
  →建議工程人員把live當release 或 test (對客戶當然稱liveXD)
  →當A案dev的features做完，接著做B案、C案、D案，此時A案將會空出時間把dev視為test(因為做別案時，使得原A案沒有短期沒更新程式(茶~) )

這應該是"無軟體工程公司"對於主機環境的"正確"理解(!!?)

→若在自己的電腦sandbox架起環境，則sandbox可視dev、dev可視test。

• 7 客戶不測試(有1個假設前提: 此案是被outsourcing。理論上，工程面最多可做到功能正確；是否完美符合需求只有客戶明白)。
  → 一切等上live(承上，其實是release或test) = 等客戶"有感"。

IIFE是我喜歡的定義 javascript module 方式

var MyModule = function(){
  var me = {}; // I don't like use that or self
  return me;
}();

這兩篇正好有側邊提到IIFE(兩篇的主角不是IIFE~)
http://ifandelse.com/its-not-hard-making-your-library-support-amd-and-commonjs
http://gregfranko.com/blog/jquery-best-practices/

若MyModule需要增減dependency object 且 不想要拉捲軸，上面兩篇有提供解法。

若不走上面解法，直接在module code直接使用/呼叫 dependency object 仍可達到目的(配合用local variables可避開效能問題)
& dependency module 不直觀(要read module code 或 直接跑故意undefined再補加載module)。

不成文的好處是:

• 更短的js code
• 快速增減dependency module
• 減少拉捲軸次數 (若用上述解法，這個可略)

JavaScript 深入精要 提到: IIFE會破壞javascript prototype特性。

• 個人覺得對於實用性來說無妨(自己目前用的結果)。
• 利用prototype特性的design pattern還是可以學(只用IIFE雖然可以打10個，但少認識了javascript特性不失一憾事?!)。

與一面試官聊技術聊到的，無絕對好壞(技術本無絕對好壞，看場景&應用找適當的用就是)

對方「都不要」的立意:

1. 當前browser的http request同時連線數、效能越來越好(同意。時代在進步...)
2. 依賴關係的可視性佳(半同意。對部分人/團隊來說，script src比較易讀)
3. script都放底部了，沒有UI可以non block (同意。弱化動態載入的優點)

我自己的立意:
4. HTML5 script有defer async

後來想的:
99. 有HTTP 2.0 SPDY (in the future?沒經歷過。若是，需要再等，不列入考慮點。)

我對 3 較感興趣

3a 大大幅減少了UI block的情形，但真的沒有block了(這裡: 沒有指0%)?
3b 不論3a是or否，個人開發仍選擇動態載入的原因是 - 用js管js dependency，不想用backend code管js dependency。(團隊/公司開發另議)

dependency logic不要寫在每個模塊上。

好處:

• 寫模塊時可以專心寫該模塊的事(不需管dependency了誰)
• dependency另外抽出一個logic區塊定義&設定
• refactor & 再次顆粒化時，不需再深入每個依賴的模塊logic，直接在dependency logic那邊做更改即可。

前言

大型網站指(以下符合一個即可):

• 真的很大(建議: 可以考慮分品牌或子品牌經營)
• 網站需求不可限縮性(視營運、競爭對手決定新功能)
• 想要可擴充的網站前端規劃(中型網站也建議規劃、小型網站可以考慮不用牛刀。)

近幾年工作關係，RequireJS、Browserify都沒用到實際工作上。
所以 --- RequireJS自己看；Browserify有空再看0.0。

然技術這事日異變遷 如--> Browserify: 取代 RequireJS ?

做為本業，評價並選擇"適合(畢竟: 沒有銀彈)"的工具用於專案/產品/業務的重要性不言而喻。

以下借用 josephj.com/entry.php?id=394 的側重點
review自己刻/已用/已驗證被QA 2年(上線營運1年+)的css/js載入規劃。
見「-->」符號。

正題

Browserify 的好處

設定單純、語法簡單，會 Node.JS 就會 Browserify
-->自己刻，無此面向/考量。
Shim 比較直覺
-->也有shim的logic code，只是我只管它叫module dependency config/setting (方便懂就好)
套件比 RequireJS （因為是 npm）
-->自己刻沒套件，不要開發上需要的都有寫(不多 - 像 自動生成css sprite 就(還)沒做)。
支援 SourceMap、支援 CoffeeScript（這好像也是很基本的事情）
-->SourceMap沒用，一方面已module化、chrome有斷點debug，要找到trace自己的code不難(trace 3rd-party的code? 土法是: 換成un-compress的版本→設斷點倒也還過得去)。
-->自己不潮，沒用CoffeeScript(還是喜歡寫什麼是什麼，怕被陰到 -- 雖然機率很低，不知是不是0%就是)。
Node.JS 內建的模組例如 events, stream, path, url, buffer, util, querystring, http... 都可以使用
-->可以用現成的很好! 是說想要的func/tool/util自己寫或copy後改也不難。
開發環境與佈署環境一致（因為全部都壓成一個 bundle）
-->我這邊的規劃是「sandbox環境」不、「開發環境/整合測試環境/佈署環境」 是。
-->不喜好100% bundle(全js合成1個) (我選擇<100%的bundle)，不能滿足大站、超大站site的個人需求( IE有但書 )。

Browserify 的壞處

不適合直接用在大型專案、得整合其他非同步的函式庫。
-->前者因為bundle? 後者理解不足，略過。
難以在舊的瀏覽器做 Debug：因為不支援 SourceMap。
-->略過。
非純前端函式庫：需要伺服器端支援，隨時監控並重新編譯 bundle。
-->自己的規劃是: 編譯不發生在每次存檔ctrl+s時，而是commit前。
工作流程是: repeat(改/加code→測試)→編譯(不走100% bundle)→再一次測試→ok才svn commit/git push。

「再一次測試」是因為「編譯不發生在每次存檔ctrl+s」換過來的。
若「編譯發生在每次存檔ctrl+s」，就不用「再一次測試」。

正題2(補充)

CSS

css 我走「非100%全站bundle」，有分
page、page group、page groupN來個別自動化bundle；
full site會占1個http request、
page、page group、page groupN 占第2個。
雖然沒有css cache(每次每一頁對應的page、page group、page groupN bundle不同)，
但我能享有「不需css framework + 有file split做為css命名空間」的不擾人開發流程。

Javascript

Javascript 也能如此(「非100%全站bundle」)，
但因Javascript動態載入機制方便(且無css @import的效能問題)，
所以只有全頁使用 & 3rd-part有bundle成1個。
第2個是該頁面需用的Javascript。
其它靠第2個去動態載入即可。

補充RequireJS

易入門的slideshow:
http://gregfranko.com/requirejs-talk/ by http://gregfranko.com/

我想找:
A) IE8以上 (隨著xp不見，這點可略。但眼下還要n年(?) 或 你的customer族群特性可以決定不理IE8)
B) 至少瀏覽器環境穩定可用 B2)能好用更好但不是must
C) 瀏覽器載入錯誤率<0.01%， C2) = 0%更好
D) 載入時不block UI thread ( 非worker的js執行時目前我認知是一定會block UI )

放< /body>正上面的js同步載入可以滿足A B C(並讓D的缺點減小 -> 加入defer 或async可減更小 -> 我想是最小了)，
但非同步載入的情況是?

或，這個命題在非同步是不成立的?
Ans: 目前我經驗到是 有IE是不成立，沒有IE的話B/B2/C/C2可以全滿足(<--誘人的result)。

requireJS看起來不是answer，雖然它現下是主流(?)，
幾個點:

官方說明 Catching load failures in IE
-->有IE8的問題

RequireJS 使用筆記

r.js

不小心 或 不自限的往full-stack developer (可能還要一點DevOps，看未來機遇)，
多元職場可能不能再front-end N+ year。

以不自限的前提，front-end可遇，full-stack可求。

上一間專職front-end，目前專職php back-end (10% front-end，designer改不動的； 5% Actionscript，看案子)

以下紀錄待習技(土)術(亢) - 2014Q3~2015Q1:

• SQL - 重新省視SQL並筆記(base on MySQL)
• MongoDB - 真正從頭到尾看過(去年只看CRUD)並筆記
• Javascript - N本(必看的2~3本)
• AngularJS - Frontend潮物、待學E2E自動測
• Ruby
• Ruby on Rails - 成熟的ActiveRecord、RSpec
• NodeJS

NodeJS + Ruby on Rails 擇一，因為未來時間不多，目前還沒入很深，所以(可能)還有選擇空間，持續評估中(職場狀況/語言特性/應用面/效能/適用場景)。應該不會不小心把這兩個就這麼學成?

不知是不是因為近年來潮物四起關係，不負責任猜測:
full-stack php developer 式微
full-stack nodejs developer(MEAN) 起 - 還有kaojs更潮(?)
full-stack rails developer 起
full-stack python developer 漸漸微(早年rails/nodejs還不很潮或剛潮時，python是比php潮...)

full-stack php developer 可能沒有想像中那麼快式微(ex: 近5年) - 一些非技術面因素(有勞大家觀察)。
php的優點也是病點是:
很好上手、透明(很少的Rails CoC)，
若phper沒注意 或 沒學習一些受用的soft concept，會誤用或濫用php language。

以我個人，就學習的角度，just try to learn RoR / NodeJS。

所以PHP or RoR or NodeJS(若無特殊機遇，應該不會就(←動詞)Python)，
目前無必須要擇一的議題 for me。

後者不會很難理解，如下

var M = ({
  publicVar: 5,
  publicMthd: function(param1){ ... },
  init: function(){ ... }
}).init();

這個方式:
在logic劃分上，會受限於物件實字語法格式( - 拿什麼換什麼的concept)。
+-- 不能保證M.init();只執行一次 - 當作者預期只想讓M.init()執行一次，且呼叫的人不是作者(多人協作or作者轉職時，需要另文件規範或在init處註解)。
+-- 當有兩個public method以上的logic很長時，會中斷目視public methods的視線
+---- 其中一個很長的public method 可以想見已是init，所以等於不能再有很長的public method。
+------ 若用_methodname: function(){} 去仿製private method，不能100%避免private method被call/apply(不推薦)。

在不會被很長的public method logic卡住時，
var M = ({...}).init() 可以用。

其實~「被很長的public method logic卡住」也不是一種100%缺點
(多少%，依個人/團隊/公司自取了)。

templateUrl 會多一個http request，
若以「多一個http request去換團隊的maintain性增加」，還是值得的選項。

但可以思考的是能不能兩個優點同時擁有(有maintain性 + 不多一個http request)。

目前的想法是可(待有project實作)且不難(相對於註1)，
做一個單機程式:
讀入每個template_file的內容
→內容壓成一行
→找出每個js files中，templateUrl之處
→取代成「template:"一行內容"」
→完成。

是否確定100%可行，待有project實作機會 或 有人做了，就可結論出來 XD。
(或結論什麼情況下可&不可)

註1:
2012年在找前端css/js/html模組化的solution。
當時首當其要面對的現實是: "css/js模組化(為了reuse code)會增加http request"。
後來借入pre process的想法，寫了單機程式，
讓整個product可以實現css/js/html模組化(為了code reuse)在功能增加/重構下，停止http request會增加的情況。
(維持停在2個css+2個js - 視product與個人選擇而定)。

網站營運畢竟(很大部分)是要賺錢的 + 向管理者/上級負責的(if have)。

我喜好 TDD DDD 概念與方法，也納入平時的工作切入點&思考對象(不過沒有100%導入，畢竟首重精神&也需因應場景 - 時間/人力/團隊屬性/業務性質…等)。

只是，TDD DDD 不是最後的目的，
後頭還需QA通過 + 滿足UX/Spec需求(UX/Spec有logic設計有誤不提)。
(再後頭營運順利)

當意職到 QADD, PMDD，雖不是"黑貓白貓"，但能抓老鼠就是好貓了~!

為了non block UI，一般推薦 Javascript 皆放在body前。
( ps: Javascript 皆放在body前不是non block UI的唯一考慮的面向 - 本文暫不聊這個 )

然有些還是要考慮放在頂部，個人經驗有這些:

1. css-browser-selector // 為了不讓user看到某視覺元件裸奔或閃跳一下
2. swfobject // 剛好此產品api會直接response (string)flash embeded code，而這個api存在很久，有歷史/政治因素&跨部門使用，要改response不是易事 --- 營運1年後實務上，這塊也是唯一的inline script (一憾事?)
3. window.onerror // 為了盡可能抓到所有onerror

PS: 不論上述有幾個，仍可以mini成一個anyname_you_want_for_top.js file
(所以頂部的js http request為0或1)

真的很想要放底部也不是0%可能:

1. 用backend code判斷 或 接受「裸奔或閃跳」
2. 改api response 或 另開api 或 你的網站/產品/專案不需要flash 或 flash embeded code是你控制(also, 傳給flash的parameter value也是由你傳入)
3. 當1+2都在底部時 & 確定全頁面沒有inline script(有best practice可以做到)，就可以放底部了(然後放在底部的第一個)

底部的規劃

個人經驗是:
a. window.onerror
b. javascript 3rd-party code
c. current page javascript seed code (dependency code 放 javascript code內不放 html script src)

a+b可以合併成 anyname_you_like.js 可再減1個http request

var MyModule = function(){
  var me = {};
  return me;
}();

用me而不用that、self

1. that自己看不習慣(語意不合(?))
2. self未來可能會變保留字
3. me只要打兩個字

me是VB6的桌面Form開發的保留字，
我想ECMAScript不會想拿VB6保留字當自己的保留字吧 :))