[Html5Rocks!] 最好的Html5學習以及參考網頁

今天google code blog上釋出了一個html 5的推廣網頁

包含了互動式的slide show, 可以測試新功能的 html5 playground , 還有教學.

這可以說是接觸html5最好的網站了

它把html5定義為 html5 + new JSapi + CSS3 這一套完整的技術
看得出來google在推動新的網路技術上付出很多心血

原本html5預估要十年才能夠普及,但是由於新一代的瀏覽器以及mobile browser,ipad/phone對html5的支援,
越來越多的人開始注意到html5的可能性了

現在看來只有微軟還在拖慢Web技術的發展,
趕快想辦法解決一下你們的ie6...
弄個像chrome frame一樣的windows update啦

更多參考:
html5Demo
html5gallery
47-amazing-css3-animation-demo
7個簡單易學的特效範例

[Joy of Engineering Leadership]如何失去友誼與離間他人

Google I/O 2010: How to lose friends and alienate people: The joys of engineering leadership

這是Google I/O 中一場有關於如何領導團隊的演講:

以下是Wave上的筆記翻譯:

Ben和Fitz來到台上
這個講題是關於軟體工程的人事方面，大部分是我們的意見，如果你有不同的看法的話，你也可以開一個自己的講題 :-)

這裡有誰是管理者的?很多人舉手…

我們要先定義問題是什麼…如果你有一堆工程師，指派他們去完成一個專案、而沒有指定任何領導人，有人就會成為領導人，去分配工作，解決衝突等等，他們將自己放到更高的角度來看專案。這種情形稱為意外型管理者。

管理者是過時而要被淘汰的，而領導者是最搶手的新玩意。他們從工業革命以來的生產線式管理進化而來。當你要管理的是一個固定的流程時，糖果和鞭子的管理方式是很有用。但是當你要管理的是創意相關的工作時，糖果和鞭子就是一個災難了。

這造成了衝突，也是為什麼大家都討厭管理者的原因。典型的呆伯特式管理者的形象是；缺乏安全感，不受尊重，被雇用來監視大家，關心自己的晉升勝於他的團隊。

在大多數的公司中，傑出的工程師晉升到了頂端後，他們就必須進入管理階層，他們是好的工程師，卻也是不好的管理者。

什麼是Engineering Leader?

- 團隊中去排除障礙，服務團隊的人。
- 團隊中能夠信任的來源。
- 必須要能處理人際，但不能只會處理人際關係，他必須要有足夠的技術能力來了解發生什麼事。
- 最好的領導不是能輕易看見的，而是感覺到的。

ANTIPATTERNS

• 當每個人的朋友
• 你不可能永遠都是每個人的朋友，你必須能告訴大家壞消息，做出決策
• 像小孩一樣對待他人
• 如果你像小孩一樣對待別人，他們就會表現得像小孩。
• 不要Micro manage
• 相信別人會表現得像個大人並作出正確的事
• 如果你micromanage別人,他們就會表現得像小孩一樣。
• 雇用聽話的人:
• 最後你會雇用到只會聽命令辦事的人。
• 你必須要雇用比你聰明的人，並把他們帶往正確的方向。
• 在徵才的時候妥協
• 不得已的雇用還可以用的人，或是只雇用幾個人,不論來的人有多好。
• 忽略表現低落的人
• 沒有事情比忽略他們…還會拖累團隊，他們會讓你最好的人才出走。
• 當你等待太久，情況已經難以回復的時候，你只能選擇讓他們離開。
• 忽略人的問題。
• 人的問題比技術的問題難多了。
• 一個純粹的技術領導人，無法滿足每一個人社交方面的需求。
• 要關心團隊的 “開心等級” - EQ

PATTERNS

• 誠實
• 讚美三明治 : 在讚美中夾著壞消息。直接提供建設性的回饋會比較好,不過要委婉並保持同理心。
• 成為一個睿智的禪學大師
• 保持冷靜，保持專注，當問題發生時，和團隊一起工作並幫助團隊討論問題。
• 大多數的時候，團隊並不是真正的想要解決問題，你需要成為探測器，幫助他們冷靜下來討論問題。
• 放開自我。
• 這不代表要失去自信，而是要拋開自大的想法，團隊知道的比你更多。
• 相信你的團隊。
• 感謝別人的詢問，不要有什麼事情是我的範圍的想法，要保持宏觀的視野。
• 如果有人問你在做什麼，可能是因為他們有興趣，而不是在挑戰你。
• 道歉。
• 要人性化，保持謙虛。
• 謙虛 != 擦腳墊。 要有自信，不要成為獨行俠。
• 弄髒自己的手
• 到現場並且作事，這樣會幫助你了解團隊的問題。
• 委派
• 請求他人幫助，不要獨攬大權
• 找方法來替代自己，讓團隊成為運作良好的機器，不需要你就可以完成任務，這是領導很好的例子。
• 給別人更多責任，然後他們就會開始自己負責。
• 做出行動:
• 如果你看到了一個問題，你希望它會消失，那忽略它是一個很誘人的選擇，但你必須跳下去並做出行動，面對這個問題。
• 保護團隊免受高層或公司的政治影響。
• 當有人搞砸，大家都知道了，就不需要在團隊面前再羞辱他們一次。和他們談談，了解發生了什麼事，在公開場合稱讚，私底下評估失敗。
• 建立共識
• 當一個老師或是導師
• 當有新人加入團隊，讓他們去犯錯，犯錯是一種選擇，只要他們不會重複犯同樣的錯。
• 設定明確的目標。
• 除非妳定義了明確的目標，不然每個人都會對要做什麼，要完成什麼有不同的意見。
• 追蹤快樂度，有一個快樂指標。
• 問別人快不快樂。
• 問別人可以為他做什麼事，或他需要你提供什麼。

總結

工程師就像植物 – 他們有不同的需要。你的工作就是找到他們需要什麼，提供給他們。
散漫-> 有目標. 無趣 -> 有熱情.

內在與外在動機

- 外在動機來自外部，內在動機是最好的一種動機，讓人們能主動的去關心。
三種最好的內在動機:
• 自我管理 – 讓人們自己去了解問題，並相信他們能夠解決。
• 專精 – 讓人有機會學習並成長，我們都希望雇用最好的人才。要雇用最好的人才，就要讓他們能不斷成長，而不是拼命去燃燒他們，叫他們只做他們擅長的事。
• 目標 – 給別人一個目標意識，歸屬感，讓他們有自己的意見，想法，而不是聽命行事的齒輪。

管理你的管理者

工程師要怎麼幫助管理者?以下是幫助你更好被管理的方法:
• 表現得像個成人，沒有人監督你你也可以完成工作，不要表現得像是希望有人來監督你。
• 追求責任，表現你的成長，冒可接受的風險，允許犯錯。
• 與他人溝通，讓別人知道你在想什麼。
• 指出障礙，但不要一天到晚都在指出問題
• 主張自己的意見.

3 Walkaways

• 管理者服務他人。而不是讓其他人服務你。
• 所有的Pattern都與尊重有關
• 激勵別人，而不是用鞭子與糖果
• 停止做個管理者，開始做個領導者。

問題

Q: 如果你有很好的人才, 而別人想要你的人才, 要如何鼓勵他們留下?

A: 想辦法扭轉這個情形，並專心在對你們團隊有益的事. 如果有人離開, 那不是妳的錯.

Q: 在管理自願性的專案上有什麼不同?

A: 在有薪水的環境下比較難, 自願性專案裡, 參與者是自己決定來參加的,他們有足夠的動機與興趣, 只是需要一些方向. 在公司裡,人們需要更多的內在動機.

Q: 當你的朋友要向你回報事情時,你如何處理?

A: 這可能會有點尷尬.當你需要傳達壞消息時,可能會很困難.

Q: 你如何處理你團隊成員在工作外的私人事務?

A: 以關懷與同理心處理是一個很好的界線, 如果你可以簡單的把他們換到另一個團隊, 你可以先觀察一下. 你可以和他們開誠佈公的談談這些事情.

Q: "每月最佳員工" 摧毀了團隊

A: 你也可以有”同事獎金”, 讓每個團隊成員有機會可以獎勵別人. 在團隊與個人的獎項之間,需要一些平衡.

[JQuery] 如何判斷元素是否存在

最近遇到了一個bug,
是因為jQuery沒有將事件綁定到指定的物件上所產生的

所以加上了檢查Html元素是否存在的邏輯:

if($("#obj") != null){...}

可是結果還是一樣,括弧內的邏輯一定會執行到.

打開debugger檢查之後,發現Jquery使用了Null Object
就是即使找不到元素,JQuery還是會回傳一個空的JQuery物件.
讓對物件的操作不會因為null reference而產生錯誤.

但是Null Object的缺點就是,如果其他程式設計師不知道使用了Null Object,
就會寫出錯誤的檢查...像我一樣.

所以這裡應該檢查元素的length屬性,如果是空值的話就會傳回0:

if($("#obj").length > 0){...}

由於javascript的boolean判斷會將0判斷成false,1以上的值判斷成true,
所以也可以這樣寫:

if($("#obj").length){...}

參考文章:http://www.aaronrussell.co.uk/blog/check-if-an-element-exists-using-jquery/


同場加映:

於內嵌的PDF IFrame讀取時使用jquery.blockUI:

$(function() {  
    var iframe = $("#PDFiframe");
    if(iframe.length){
        //ie在綁定Iframe事件的時候會產生錯誤,必須要用windows.frames[]來取得iframe
        //另外如果直接用jquery接frames物件的話,於判斷length時一定會傳回true...
        if($.browser.msie){
            iframe = $(frames["PDFiframe"]); 
        }
        $.blockUI();
        iframe.load(function() { $.unblockUI(); });
    }
});

[Hollywood Principle] Dependency Injection Pattern

今天讀了Agile上面有關DIP的段落，乘機把它拿出來再複習一下:

首先，為什麼要用DIP呢?

書上舉了一個很好玩的例子來說明，叫"Hollywood Principle"
意思是"Don't Call me, I'll Call you"
好萊塢的經紀人不希望面試者主動聯絡他們，而是當他們決定要用你的時候才會主動聯絡。

以程式來說，就是讓物件自己決定要如何呼叫其他物件,而不是依賴於其他物件。

假設說今天我們要設計一個可以讀取Book資料的Reader

class Reader{
    private Book book = new Book("Harry Potter");
    public void read(int page){
        book.read(page);
    }
}

Reader依賴於book這個class的函式,
所以當我們要為這個程式增加可以閱讀EBook功能的時候,我們必須加入邏輯判斷來區別
第一個想到的就是新增TypeCode判斷,
於是醜陋的程式碼就產生了...

class Reader{
    static final int BOOK = 1,EBOOK = 2;
    public void read(int page, int bookType){
        if(bookType = BOOK){
            Book book = new Book("Harry Potter");
            book.read(page);
        }else if(bookType = EBOOK){
            EBook book = new EBook("Harry Potter");
            book.read(page);
        }
    }
}

使用Dependency Injection Pattern,能使Reader這個Class不會被book這個class綁死,
相反的,Reader可以先宣告自己會使用的介面,等於是告訴其他Class
"我會用這個方式來呼叫你,如果你想讓我用的話,就先實做這個介面":

class Reader{
    private IBook book;
    public void read(int page){
        book.read(page);
    }

    public Reader(IBook book){
        this.book = book;
    }
}

class Book implement IBook{...}
class EBook implement IBook{...}

使用介面,或是abstract class來宣告使用的介面,
讓Reader這個class可以不被單一的Book class所綁死
只要是實作IBook這個介面的Class,Reader都可以使用

public Reader(IBook book){
        this.book = book;
    }

而這段程式碼在呼叫Reader的建構式時傳入它要使用的Book
這就是Dependency Injection(控制反轉)的一種
是當你要使用物件的時候才傳入物件之間的依賴關係,而不是在一開始就在程式碼中指定
這樣可以保持物件之間彼此的鬆散偶合,增加擴充性.

另外,在作單元測試時,DI也是很有用的一個Pattern
如果我們要測試Reader的Read()這個函式,但是Read這個函式又會呼叫到Book,
然後Book會連接到背後的資料物件...這樣我們無法知道說測試的成功或失敗,
是因為Reader的關係,還是Book,或是背後的資料庫的問題.

這個時候我們就可以使用Dependency Injection的特性,將Book與Reader之間的關係給切開,
先寫一個測試用的Book,實作IBook的介面,並且紀錄是否被呼叫:

public class TestBook implement IBook(){
    public bool readed = false;
    public void read(int page){ 
        readed = true;
    }
}
//測試案例:
    public void ReaderTest(){

        TestBook book = new TestBook()   
        Reader reader = new Reader(book);
     
        reader.read();

        assertTrue(book.readed);
    }

利用這個方式,我們可以只測試我們想測試的邏輯.
也可以寫一個假的Data Access Class,將資料庫的部分先抽換掉,
來測試系統的介面與流程是否ok.

more:
Martin Flower提出的DI概念
良葛格對DI的詳細說明