最近在幾篇文章裡看到了Rockstar Developer這個字眼（似乎有點LAG了），如果要翻的話就是『搖滾開發人員』這樣？ 就我的認知，指的可能是在技術社群內很活躍的名人；在一個團隊內類似『技術總監』的角色；或是簡單的說，就是你很崇拜的那種程式人員。

來看看別人怎麼看這種人XD （以下加一點個人嘴砲）

十大特質

出處：Top 10 Traits of a Rockstar Software Engineer By Alex Iskold

1. Loves To Code
   – 這不用說了，要有freak-out的精神！
2. Gets Things Done
   – 這需要一定的毅力，如《人月神話》所說：滿足了我們潛藏於內心創造事物的渴望；但專案時程和過程中的種種瓶頸可是很難熬的。另外最近scrum等等agile methodology也是很熱的議題，對尋找最佳實務提供很多的創新解法。
3. Continuously Refactors Code
   – 看了幾本書之後就很HIGH的去改以前的code
4. Uses Design Patterns
   – NPC表示：去找在那屋子裡的GoF先知吧(?)
5. Writes Tests
   – 要寫得夠廣，也要考慮以後方便做regression test。目標是coverage 100%
6. Leverages Existing Code
   – Apache Commons之類的，做之前先google準沒錯
7. Focuses on Usability
   – 與其被嫌了之後還要改，不如(ry
8. Writes Maintainable Code
   – 架構要設計得好，還是要先去看Design Patterns
9. Can Code in Any Language
   – 更廣義的說應該是快速pickup的能力?
10. Knows Basic Computer Science
    – 囧 快忘光了

最近突然接到一個消息：我們部門將為另外一個處（division）開設一系列的SharePoint Sharing課程（有點拗口）。而我負責的兩個主題其中一個是關於UI Design & Branding，於是便寫了這篇文節錄一些我比較有心得的部分。

SharePoint 2010這東西，是大約去年的五月，我被徵召當UI救火隊時候開始碰的。說實在的，在這之前對於微軟的企業端solution、CMS、還有ASP.NET都完全沒有任何的接觸；不過也是因為這個task，我才算真正進入CSS以及jQuery的大門（算是一個蠻神奇的進入點orz）。

首先簡介一下我們系統。它本身是跨公司內外的網站，但並不是一個內容取向的網站；而是主要由一個個partner-collaboration性質的AP（在這邊當然是web part形式）所構成 －－看起來純粹是因為政治及某些人的KPI等等不關我事的因素而採用此solution。先說說我負責的範圍：

1. 整體UI設計及Branding：意思就是把它變成完全不像SharePoint，並且可以讓客戶留下好印象、每個畫面截圖都可以拿來發press release的站。
2. 首頁中所有功能：跟user談了首頁layout、carousel（圖文輪播）、登入框、還有額外的佈告系統。
3. 實作其中一個AP：使用ASP.NET加上DevExpress套件的報表/圖表系統。

而今天要講的就是看似最簡單，但實際上最難上手的UI這部分。當時是處於前一個assignee開天窗，進度正火燒屁股的狀態。首先，我們整個UI救火團隊一共有3人：我老闆（負責coordinate）、我（萬用programmer）、還有從其他部門借調來part-time support的美工（也是剛工作不久的）。以下是我們大略的工作流程（沒錯幾乎就是waterfall，或是你可以叫他always-sprint的一人scrum）：

更新4.1b3之後，發現在某些grid中會出現HTML亂掉的情形如下圖。

建立獨立test case之後整理出bug detail如下：

1. 建立一grid，設定具有dataindex的簡單template column如下
   {

    xtype: 'templatecolumn',
    tpl: '<div data-qtip="{name}">{abbr}</div>',
    dataIndex: 'abbr',
    text: 'abbr'
   

   }

2. 以該欄grouping之後，會出現上述之亂碼情形。
3. 若將dataindex移除，則不會有此情形，但將失去sorting等功能。

已向sencha回報

最近想寫一個增進工作效率的add-on，自用之餘也打算寫好之後拿來送禮餽贈同事(XD)。 不過我希望對各種不同瀏覽器可以只maintain一支code，有點類似瀏覽器版的PhoneGap的概念。 （好像真的有BrowserGap這東西，不過似乎已經沒有再maintain？） 稍微survey了一下， 目前community有推薦的cross-browser add-on framework大概有幾種選擇：

• Kynetx：免費的，算是主力開發extension的公司所提供的工具(有在號召developer加入，code在github)，支援IE/FF/Safari/Chrome。但是開發出來的擴充元件相依於Kynetx extension。另外，需要用他們自家的Kynetx Rules Language進行開發。
  
• Forge：他本身是跨平台的App Framework。除了支援iOS跟Android之外，瀏覽器部分也支援了IE/FF/Safari/Chrome，但是瀏覽器是需要付費的(目前每月$299)。
  
• CrossRider：免費的，支援IE/FF/Chrome。他主打用jQuery開發跨瀏覽器擴充，乍看之下是有點吸引我。試用了之後覺得他設計得還不錯，也有web的開發介面。如果這市場夠大的話看似未來也會有很好的發展性跟community。最大的缺點是開發中、完成後，都要透過他們的網站發布及安裝(不然就得自己..想辦法XD(?)
  
• KangoExtensions： 免費的，支援IE/FF/Chrome/Safari/Opera。本身是一個python小程式(目前使用2.7)。稍微看了一下覺得似乎是個不錯的選擇(至少code可以自己maintain，感覺起來彈性也比上面幾個高)。目前打算先用它來試試看，之後再補心得囉。
  

承上篇，Sencha果然在昨天台灣時間早上七八點發布了Ext JS 4.1 beta 3，於是我也從善如流(?)的把原本專案4.0.7的lib直接換成新的來測試。很麻煩的是，電腦只有IE9 (我很希望IE的F12切換瀏覽器版本功能可以連JS Engine都切換一下，造福一下developer；或是把這東西做在新的MS Expression Web SuperPreview也不錯) 所以要一直跑到同事座位借電腦測orz

之前官方預估4.0.7至4.1的舊版IE效能提升

以下是測試小結：

1. 4.0.7直接升級至4.1.0b3後，對原有的程式及畫面幾乎沒影響。


• 但是community表示，afterrender事件已經不會被trigger，對某些人影響似乎很大。
• 對我們畫面有一個impact：舉例來說，有很多component我有設長寬，但是他外面container的layout是設成”fit”。在4.0.7他還是會乖乖占滿整個container；在4.1他大小就真的是我們設的長寬。不過這很好改，一下就全都改好了。
  (As for the layout. Height and Width are obeyed in 4.1, where there were ignored in 4.0)
  

  Ext.onReady(function() { 
      var form = Ext.create('Ext.form.Panel', {
          title: 'panel',
          renderTo: Ext.getBody(),
          width: 600,
          height: 400,
          layout: 'fit',
          items: [
              {
                  xtype     : 'panel',
                  title: 'subpanel',
                  height: 100,  // ignored in 4.0, obeyed in 4.1
                  width: 100 // same
              }
          ] 
      });
  });

• Grid中如果用其中一欄的dataindex分群，而該欄又是template column的話會讓HTML大亂。
• 剩下還有一些是我自訂css class做一些customization的，有些behavior會跟原本不一樣，在這就不詳述了。
• 講些正面的，之前 combo box picker 很嚴重的在IE錯位到左上角問題(當時是用這個work-around)、還有loading mask一直不消失問題，在4.1已經完全解決了。另外4.1的scroll bar也由原本很多bug的自作聰明版改成瀏覽器原生，應該就不會有tree panel scroll消失的問題了。
2. 在程式完全不改的情況下，IE8的效能似乎有『非常微幅』的提升。(微幅到不想幫同事裝fiddler測了；不知道有沒有更好用像YSlow的測效能工具？)
3. 於是，進行了以下IE8效能調校嘗試
• 把所有的store取消 autoload  (原本有設autoload的大部分是如combobox的common component等等的store)，想辦法減少占用的記憶體
• 結果：效能大幅提升，但是離流暢操作還是有一大段距離。更令人遺憾的是，以目前的architecture操作到最後，該load的store還是會全load，到時候一樣會很慢。
• 因為有使用Ext 4.0的dynamic loading，我儘量想辦法讓我UI的JS (主要是Ext Designer的component hierarchy)都在該用到的時候才load進來 (這是上一篇sencha support說值得嘗試的方法)
• 結果：根本沒差=_______= (我的東西其實沒複雜到哪去，JS都那麼短，有差也感覺不出來orz)
• 用他上次給我們的範例(裡面就是一個combo box複製很多份，然後吃一個靜態的json)來測試當資料多、元件多時對效能的影響
• 結果：載入一個我認為可能是兇手的store之後(我們系統裡面的)，整個IE真的馬上變烏龜
4. 在各瀏覽器的效能依舊是
• Chrome(非常順，無時無刻超級順，不愧是V8) > Firefox(有時候會頓) = IE9 (有時候會頓) >> IE8 (還是根本無法接受)

至於為啥要這麼辛苦地為一個爛browser煩惱呢？

….orz

題外話，今天早上google到了一篇簡體文章「 ExtJS 4 Beta 2預覽：Ext.Brew包 」。興致勃勃的直接看文章內附的範例程式之後覺得霧煞煞想說：這是甚麼鬼阿，於是點了原文連結。

靠北，這是愚人節笑話阿，這位426是認真了嗎orz (雖然我LAG了XD)

P.S. Sencha的確是煎茶的英文音譯

Our project is an Ext 4 application built with Ext Designer 1.2.2, with the 4.0.7 library. Inevitably, we faced the performance issue in IE8, while firefox and chrome work just fine and smooth. (the bad news is our company is IE8-dominating) 
We’ve tried out the latest ExtJS 4.1 beta 2, beside dozens of layout distortions, we still find no performance improvement. 

oh and the support period is gonna expire

Here are the questions I’ve asked Sencha for support:

1. Does the beta 2 really cover any slight or significant performance improvement? How was the benchmark and the community feedback about this? 

2. Is it still far from 4.1 GA? Could we expect more improvements in the future beta/GA releases, or that’s almost all? 

3. I use the Ext 4 dynamic loading. However for our current program, it almost loads every /store/.js, /view/.js and /view/ui/*.js upon initializing the main application (except the ones for pop-up windows and other run-time-created things). Regarding IE8 performance optimization, will it help if we try to eliminate the not-yet-used components as best as we can? (I wonder who makes the entire IE8 incredibly slow) Or there’s any other related threads or suggestions that would help? 

Here’s the first response, within 2 hrs! So prompt!

Thank you for the report. Hopefully we can resolve this issue. 

1) We are constantly trying to improve the performance of 4.1 with every release. There should be a new BETA release very soon, so hopefully this may help. IE is always a challenge. 
2) 4.1 GA is scheduled for mid-late March depending on the results from the prior releases. As mentioned, speed improvements are always a priority. 
3) As you mention, anything you can do to delay, or eliminate the loading of unused items will be a plus for rendering. 

The issue of what is the cause of slow rendering can be a number of things. 
We had a case the other day where a customer was having slow rendering issues in IE7/8 and it turned out to be customer code and custom CSS. 

To provide an accurate answer, we would need to see a small working example that display the problem that you see. 
One thing that you may try, is to create generic form that has numerous controls (including populate combos, array driven) to see if you have the same problem. 

I have attached an example that you can use as a template. Please see how this renders on IE8, Please make sure to update the path to Ext in the html file. 

If you have any further questions, please let us know. 

I’ll try to cope with that anyway

The mysterious Sencha Designer 2.0 announced in last year’s SenchaCon has finally released the Beta version last week (without trial period limitation!) Besides the Sencha Touch support, which has been their focus, what really attracts me is it finally supports ExtJS 4 MVC, and in-line event definition.

M, V, C, and S (Store)

For this time, I’m gonna share how I integrated Ext Designer to my Eclipse web project in the 1.2.2 era.

Ext Designer hands-on

This video from Sencha Learning covers all its features in a nutshell.