星期三, 8月 30, 2017

[CSS] All property 筆記

All 是 CSS 的用來重設樣式的屬性的簡化方法(shorthand), 重設範圍不包括 direction 跟 unicode-bidi。
瀏覽器支援度http://caniuse.com/#search=css%20all
All Value
  • initial: 重設樣式到 CSS spec 的初始值
  • inherit: 樣式會從parent element 的樣式繼承下來,包括一些 Non-inherited 的屬性,例如 border
  • unset: 一些可繼承的樣式會從 parent element, Non-inherited 的樣式將會回到 CSS spec 的初始值。




Ref.1: https://developer.mozilla.org/en-US/docs/Web/CSS/inheritance

星期三, 8月 16, 2017

[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 下 讀書會筆記

上一篇[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 上整理了讀書會的速記,這一篇來記錄一下心得跟團隊的回顧。

自從 TenMax 公司副總 Richard 在 Daily Scrum 說到他今年的目標是要讓團隊進化成一個自主、學習的研發團隊,其實團隊就可以感受到一直在朝這方向前進。

自主,就是成年人自己找方法,在面對廣告科技這複雜的生態圈,遇到問題騰學在台北新竹的開發同仁第一件想的事情,通常是我能提供什麼能力協助團隊去解決這個問題 ,不針對人去究責,而是思考著怎樣解決問題。

學習,因為這個生態圈演化相當快速,不斷的增加自己的技能樹的廣度跟深度也是重要的。我們其實固定都有讀書會,從一開始的廣告科技的基礎理論書-計算廣告,接著是如何思考產業的正向成長的平台經濟學,後來接了一本硬技術底子的 Clean Code。以及在下來跟產品設計相關的 Product Design for the Web

不得不說大家在讀書會的選書都很有連貫性,環環緊扣著怎樣充實自己,怎樣規劃開發出有價值的產品,怎樣把平台滾大。

這次讀書會 Clean Code 對我而言最大的收穫,就是在 Plan Meeting、開發的時候大家會不斷問,這段程式碼有沒有 Clean Code 阿?另外大家是分小組的方式進行,其中在 Unit Testing 的團隊更是用心的準備了許多線上範例教材給大家一起練習,非常用心。



上圖是我們讀書會後的檢討( Retro ),當然有優點,也有值得改善的地方,團隊跑敏捷開發跑了一段時間了,這次讀書會也以敏捷的精神來跑,不免俗的就是最後會檢討一下。

但是這邊檢討不是那種針鋒相對的說誰做的不好,這種指責性的檢討。大家都有一個觀念就是誠實的面對問題,並且思考下一次要如何改善問題。

其實之前讀書會計算廣告大家覺得後面的章節太多數學公式,大家再討論流於形式,這次 Clean Code 讀書會就把後面一些章節捨去,但是其實很可惜的,後面有蠻多值得大家討論的實做。


[Angular] Directive Isolate Scope Note


enter image description here


@ – one way binding
In directive:
   scope : { name : "@name" }
In view:
   name="{{nameFromParentScope}}">
= – two way binding
In directive:
   scope : { name : "=name" },
   link : function(scope) {
     scope.name = "Changing the value here will get reflected in parent scope value";
   }
In view:
    name="{{nameFromParentScope}}"> 
& – Function call
In directive :
   scope : { nameChange : "&" }
   link : function(scope) {
     scope.nameChange({newName:"NameFromIsolaltedScope"});
   }
In view:
    nameChange="onNameChange(newName)">



星期六, 8月 12, 2017

2017 走吧!尋找最棒的自己 觀看事件紀錄

今天2017/08.12下午兩點半帶小朋友去中山堂由風潮音樂主辦的 2017 走吧!尋找最棒的自己,感覺非常之差。

因為我們買了3000元的票,卻因為小朋友場地怕黑大哭而被請出去外面看螢幕。首先我要說,我們對這個親子音樂會努力很久,包括對小朋友做心理建設,讓他網路上先聽了謝欣芷老師的youtube影片。

只要小朋友一哭我們立刻都是安撫他,我老婆一開始他哭了就帶他出去,但是上半場我們出去劇場我們沒有被告知就不能再進來了,所以上半場只好在外面看螢幕。

下半場前我們不斷給孩子心理建設,但是中間還是被告知因為小朋友哭鬧希望我們離開,實際上中間有表演的時候小朋友都是安靜地在看的,只有過場燈光熄掉會大哭,但是我們絕對立刻安撫,但是大約下半場第二首歌我們就被請出去了。

小朋友在外面心情平復了之後,他看著電視指著跟我們說他還想進去看,但是工作人員說已經是最後一首了,等結束才能再進去了。

聽著場上表演者不斷表演,小朋友要做你自己,最棒的就是你,不要哭泣。但是或許他們不能容許一個兩歲的孩童在一個短暫的黑暗時間的哭泣。我們身為家長也不知道是做錯了什麼,但是我們會在他害怕的時候永遠守護著他。


星期四, 8月 10, 2017

[讀書] Clean Code: A Handbook of Agile Software Craftsmanship 上


最近公司 TenMax 的研發團隊完成了 Clean Code 這本書的讀書會,我自己覺得這本書很有趣,尤其在一個成熟的研發團隊正在開發或維護大型軟體,裡面有很多好的準則常常會在Plan Meeting 或是隊友在討論開發細節的時候常常聽到,「這個寫法有沒有 Clean Code 阿?」。

趁熱筆記一下個章節的速記

第1章 無瑕的程式碼 - Clean Code
  • 簡介一些大師眼中何謂 Clean Code。
第2章 有意義的命名 - Meaningful Names
  • 命名是程式中最難的事情,提供了一些避免跟建議的命名方法。
第3章 函式 - Functions
  • 簡短,只做一件事情原則,才能算是好函示。
  • 降層原則,讓閱讀函示像是閱讀文件。
  • 函示的參數小於等於2最理想。
第4章 註解 - Comments
  • 註解的目的
    • 快速回憶上下文
    • 瞭解開發者意圖
    • 最好的註解就是程式本身
第5章 編排 - Formatting
  • 編排是團隊的一個共同溝通方式
  • 每一段程式碼都代表一個完整的思緒,可用編排( ex :空白行)來分隔思緒。
  • space or tab?
  • function { } carriage return ? 
第6章 物件及資料結構  - Objects and Data Structures
  • 資料的抽象化
  • 結構化的程式碼難以添加新的資料結構,因為必須改變所有的函。
  • 物件導向程式碼難以添加新的函示,因為必須改變所有的的類別。
  • 物件還是資料結構
    • 物件(Object): 暴露行為並隱藏內部資料
    • 資料結構(Data Object): 暴露資料但不會有行為
  • 德摩特爾法則 (The Law of Demeter)

假設下面的程式碼
Result result = myObject.myMethod(ctxt)

myMethod應該只能用到
  1. 自己: myobject
  2. 傳進來的參數: ctxt
  3. 回傳的結果: result
  4. 自己所持有的物件: myobject.ooo
第7章 錯誤處理 - Error Handling
  • 讓錯誤的意圖變的明顯
  • Checked Exception vs Unchecked Exception
  • 在不正確的地方寫錯誤處理,導致邏輯混亂,例如該正確運行的地方還加上處理
  • 錯誤處理,依照撰寫者意圖應該要有兩種形式
    • 嚴重錯誤
    • 應該要被完整處理的情況

第8章 邊界 - Boundaries
  • 探索與學習邊界: 常見案例,整合第三方軟體
  • 學習性測試:
  • 不要在產品程式實驗新的東西,而是額外撰寫程式程式來探索第三方軟體

第9章 單元測試 - Unit Tests
內容很多,尚待補充

第10章 類別 - Classes
  • 類別就是一種封裝的方式
  • 類別要夠簡短,命名是一個判斷的方式,如果無法取一個簡明的名稱,他負責的東西可能太大了。
  • 是否能用簡短的方式敘述一個類別的目的。
  • 單一職責原則(Single Responsibility Principle SRP), 主張一個類別或一個模組應該有一個,而且只能有一個修改的理由。
  • 保持類別的凝聚性,可能會得到許多小型的類別。
  • Open To Change
  • 利用抽象化隔離修改



星期日, 8月 06, 2017

[React] constructor bind this or Component event bind this?

最近在跟公司的團隊還有朋友再深入討論 React 的效能細節,有討論到 React 的 function bind this 要寫在constructor 還是使用 arrow function ?
後來實驗出來我個人推薦在 constructor bind ,並且使用 props 把所需參數傳入。
原因是因為如果是在 Component 的事件裡面 bind,或是使用 arrow function auto bind ,實際上在 React Render 裡面的 function 都是新產生的,而 constructor bind 則會同一個 function,當一個畫面 render 久了前者就有效能議題了。