Blackbing Playground

發表於 |

##這是老掉牙的問題吧？
其實這個題目很常見，但我覺得一路走來的心路歷程也算是有些經驗，
而瀏覽器進步的快速，也讓網路上充斥着各種不同的解法，
初學者很容易就掉進這個深淵。回頭看看這幾年走過的路，
也可以由這個問題看出開發者不斷地在跟瀏覽器的能耐做角力，
然後隨著技術的進步，終於讓我有比較理想的解法。
決定記錄下來。

如果只是要找解法的話可以直接看「preview image before upload(html5篇)」。

閱讀全文 »
Blackbing Playground

發表於 |

今天來聊聊我的工作環境，其實之前就想寫一篇來記錄了，
只是一直都很懶。

OK，準確一點的說是我使用電腦的「工作環境」。
最近覺得自己的配置明顯加速了我的開發時間，
因此也順便做個記錄。

###虛擬機器
一開始是申請AWS的服務，instance放在最便宜的美西，AWS真的很便宜，
但AWS設定多，操作相對複雜，而且美西的速度實在太慢。
比起來Linode就直覺多了，而且可以申請在東京的instance，速度很快。

閱讀全文 »
Blackbing Playground

發表於

自從換了工作之後，換了Mac來使用，
後來也愛上它了。
認識我的朋友都知道，
我以前罵apple罵的要死，結果現在卻用Mac當做我的開發工具了，
這之間揪竟有什麼愛恨糾葛呢？
讓我們繼續看下去。

####窮酸學生時期
當然只能用盜版windows，當時對apple的印象就是，設計很漂亮，但那是給有錢人用的，因此對一個窮酸學生而言，
apple對我就是有錢人的玩具，而他獨樹一格的規格設計，也是讓我嫌棄到爆炸的主因。

閱讀全文 »
Blackbing Playground

發表於

最近用requirejs用的很頻繁，因此把平常開發的架構拉出來成一個project template，
若以後要開發就只要fork出來，或者是move a repo。

由於require.js 的架構很容易擴充，因此非常適合模組化的開發，模組化的開發優點就是可大可小，
對於程式的相依關係也可以處理的很清楚，
非常建議在開發初期就導入模組化的開發方式。要接手或者維護都可以很快速的轉換。

分享一下我自己的開發流程：

閱讀全文 »
Blackbing Playground

發表於

####Migration wordpress to Jekyll

用了Wordpress幾年了，最初的動機是不喜歡外面的blog server綁手綁腳，限制一堆，
要什麼沒什麼，於是就自己架自己的wordpress，
另外一個原因也是想要練習管理server，熟悉一下各種設定。
而中間隨著一些時間的演進也搬了好幾次主機，基本上對於這些可以做自定義的功能也還算滿意。

但隨著年紀的增長也越來越懶，越來越不想要再做這麼多客制化，
看到大家紛紛都改用Jekyll，
並且直接host在github pages上，
讓我蠻心動的。
不過之前一直沒有花時間去搞懂這個東西，也因為這樣，讓我更懶得寫文章，
因為一直想說要換掉wordpress，所以懶得寫在wordpress上面。
每次想寫點東西一開啓wordpress就又放棄了，真的是很懶。

最近終於花點時間研究了一下，並且成功的轉換過來了，關於網址之類的部分就之後再慢慢轉換吧。
Migrate的部分我要求不多，因此只有參考BLog Migrations作轉換，網址什麼的就不管了，
我想反正以後放在免費的server上也是我主要的考量。

參考資料：

Blackbing Playground

發表於

Charles Web Debugging Proxy是個非常好用的debugging tool，我很常用的功能是Map-Local，Map-Remote，以及監看Http的request/response。甚至修改request or response的內容，這在debug上非常的有用，也能很快釐清到底是哪一層的問題。不過我一直以為他只能run在某個系統上，所以我在每個VM上都要安裝一次Charles，結果強者我同事看到說不用這麼麻煩，只要指定proxy就什麼都解決了，所以你只要在Local安裝好，每個VM裡頭指定好Proxy，就可以錄到所有的request/response，尤其是在debug IE，因為IE6/7/8沒有Net 監控，所以用Charles可以幫忙除錯，非常好用，特此記錄一下。

閱讀全文 »
Blackbing Playground

發表於

在開發時常常會需要用console來除錯或是檢查流程，但推到production上必須要將這些log清除，雖然console很好用，但適當的log可以輔助除錯，如果推到production就強制將console.log都從code裡頭移除也不一定是好事，因此常常會看到會有一個管理log的global function，例如：

1
2
3
4
5
var log = function(s) {
    if (typeof console !== 'undefined' && console !== null) {
          return console.log(s);
    }
};

不過這樣簡單的function就不夠彈性，結合大家的想法，希望這個logger至少能夠handle幾種情況

  • 可以直接呼叫Logger(‘foo’)
  • 也可以擁有console api 的功能，例如warn, info, group等等特殊功能
  • 快速切換production or dev環境
  • 就算有人不小心寫了console.log，只要我切換到production環境，就不會印任何東西
  • 萬惡的IE也要能運作正常，而不是強制關掉log(例如開啟開發人員工具還是可以看到log)

於是，Logger.js 就誕生了，由於現在都用http://coffeescript.org/ 寫js（用了就回不去了），因此js是coffee產生出來的。也順便做了http://requirejs.org/的require版本，若在專案有用到 require.js 可以直接require。
雖然只是很簡單的 code，不過對我來說很實用，跟大家分享。

###Get the sourcecode(Github): http://github.com/blackbing/logger.js/

實作上遇到幾個問題，原本構想是希望像jQuery一樣，可以直接呼叫，也可以呼叫function處理，例如：

1
2
3
$('#main')
  $.ajax()
  $.bind()

原本我以為要用覆寫prototype的方式來處理，繞了一大圈纔知道根本不用（真是暈了我），javascript原本就是「物件」導向，所有變數都可以是物件，因此function其實也是物件。犛清了這個觀念之後，實作就很容易了，首先宣告為function，接著再一一指派，大功告成。有興趣的就再研究 http://github.com/blackbing/logger.js/吧。乾杯。

###http://github.com/blackbing/logger.js/

Blackbing Playground

發表於

在URMAP的日子竟然匆匆過了四年，回想起來真是不可思議，在這兒，我學到不少東西，也是個很好發揮的地方，URMAP畢竟還是台灣少數的圖資應用廠商之一，舉凡LBS相關的服務、車隊系統、定址系統、導航系統、地圖API等等，都是台灣少數可以跟Google Map相抗衡的地方，研發團隊一直都很堅強，這也是我一直很樂此不疲的地方，在這裡有不定時的宅宅分享會，大家一起分享討論新的技術，看看是否可以應用在新的地方。


URMAP很特別，因為LBS的領域其實是有點專門的領域，能夠接觸到GIS相關的知識，這也是我一直很感興趣的地方，而各個領域都有很棒的同事在負責，我們用到的技術、創新服務也非常多，在這兒，真的是一個很好發揮的舞台。


時間過得非常快，四年好像一轉眼就過了，臨走前，我在宅宅分享會分享了最後一個主題：「Web Developer不可忽視的瀏覽器擴充元件」，主要是我認為隨著Google Chromium的發展，瀏覽器擴充元件會成為Web application中很重要的一環，除了web的know how，web Developer一定要知道browser extension可以做到什麼，或許也可以帶給網站一些有趣的應用。並且用我在閒暇之餘做過的Download FB album當作例子以及code review。


投影片請按此


投影片裡頭的特效是用HTML5 + CSS3來完成，由於時間有點趕，因此我沒測試過Firefox，所以只能用Chrome來開啟，另外由於公司投影機測試的解析度問題，所以也會有點小誤差。除了Extension的概念之外，其實我主要想分享的概念是「熱情」。


投影片裡頭的所有特效，除了slide的框架，其他都是自己寫出來的，看起來好像沒什麼，但是卻是花了很多時間在處理一些小細節，有同事問說：「為什麼要自己寫？也太閒了吧！」，我當時回答說：「因為爽」，不過其實我想分享的是一個「熱情」的精神，因為有熱情，你才會投入，哪怕是這個細節需要花你很多時間來做，事實上，所有的工作都是這樣的，「魔鬼藏在細節裡」，你不實做，永遠都不知道細節是什麼。


之前看過一篇文章：「什麼是重要的」，裡頭講到幾句話另我深有感觸：



  1. 追寻这些新技术，很容易让人有种走在技术前沿很牛逼的虚荣感。

  2. 以为走在前沿，其实只是凑个热闹，迟早成为舞台下的观众。

  3. 对于武林高手，内功最重要。招式套路，只能街头赚个掌声。

  4. 对于程序员，真正的核心竞争力是基本功。

  5. 永远不要舍本逐末，否则你学的新东西越多，被淘汰的可能性反而越大。


事實上，我認為中國大陸的前端技術能力非常堅強，已經不輸給國外的技術了，我常常找資料都找到大陸的技術博客，雖然大陸clone的文化還是有，但他們就是有能力做出一個一模一樣的技術，這不是也令人刮目相看？


總歸一句話，熱情才會創造出更有趣的應用，否則技術永遠只是死的，Programer 最有價值的地方就在於，能夠發揮創意並且實做出來，最怕的就是在看某個應用，然後說：「哦～這個不就是XX再加上OO，這我之前也想過」，那麼，你有實做出來嗎？在WEB當道的時代，創意已經不值錢了，值錢的是，將他實做出來。


「熱情，才能成就你自己」。共勉之。

Blackbing Playground

發表於

Download_FB_new_feature之前做了這個下載照片的小工具Download FB album，說真的，我沒想到會有這麼多人下載，雖然是chrome Extension，但隨著Chrome瀏覽器成長的快速，使用者與開發者也成長的非常快速，代表只要你的產品有碰到使用者，是真的能夠有這個市場，而且在chrome Web Store也已經有付費機制，也就是說你能夠透過web strore來跟使用者收取費用，讓開發人員更有興趣來Rock the World。

話說回來，Download FB album的目的只是要下載整個相簿的照片，而原本的概念也僅僅只是要替換縮圖與原圖的URL而已，然而，發佈之後才發現很多人反應沒辦法下載原始大小的圖檔，於是我再檢查是否可以取到相對應的原始大小圖檔，但結論是沒辦法，就連每一張圖片的高解析尺寸，FB都是重新發request來取得，而且包含html一起回來，這代表FB為了防止抓圖機器人大量抓圖（指）而採行的策略，於是我雙手一攤，那我就沒辦法囉～各位使用者，Sorry～（逃～）

但在這期間，我收到好幾個使用者直接寄信來反應是否可以提供下載高解析度照片，並且很認真的跟我討論實做的方法，大部分使用者一開始都提到只要改一個字元而已，仔細討論之後才發現真的沒那麼簡單，所以最後都不了了之。但隨著使用者下載的次數越來越多（目前已經38000以上人次下載），我的責任感卻增加了，於是我開始很認真的思考我該如何取得high resolution的圖片。歸納出以下結論：

facebook的圖片共分為三種格式

  • 預覽縮圖(120*160)px
  • 播放縮圖(960*640)px
  • 高解析尺寸(2048*1536)px
    • 高解析尺寸的URL需要發AJAX來取得（每一張圖片都要）。
    • 回傳的格式是JSON，但內容卻是一份HTML字串。因此需要parse HTML才能得到高解析尺寸的連結。

兩種尺寸的縮圖URL只差一個字元，因此知道縮圖連結之後，進行簡單的替換即可，然而高解析度的圖片URL需要一張一張跟server問。首先是想到的是流量問題，如果相簿裡頭有上百上千張圖片，那就要在短時間內發送上百上千的查詢，會不會引起FB的注意也是個問題。之前當我發布這個工具之後，碰巧與photojacker的作者聊到，他有提到之前因為流量太大被FB注意到並要求強制移除，當時他非常憤怒。並提醒我要注意這一點。不過為了解決這個問題，我暫時就不管這件事了。我只是想解決問題而已(抱頭～)。

另外一個問題則是Chrome Extenstion架構限制，在官方文件上寫到：

However, content scripts have some limitations. They cannot

  • Use chrome.* APIs (except for parts of chrome.extension)
  • Use variables or functions defined by their extension’s pages
  • Use variables or functions defined by web pages or by other content scripts

These limitations aren’t as bad as they sound. Content scripts can indirectly use the chrome.* APIs, get access to extension data, and request extension actions by exchanging messages with their parent extension. Content scripts can also make cross-site XMLHttpRequests to the same sites as their parent extensions, and they can communicate with web pages using the shared DOM. For more insight into what content scripts can and can’t do, learn about the execution environment.

你可以進行跨域的AJAX請求，並且禁止存取該頁的任何變數和function。而既然是不同的domain，當然就無法進行AJAX的溝通。然而他們卻可以「Communication with the embedding page」，這就有趣了，既然我可以access DOM，我就可以進行該頁面的任何動作，包括進行AJAX攻擊請求。是否？是否？細節不多提啦，有興趣的再私底下討論，這篇文章只是想說明Download FB album做了突破性的更新，不管會不會被Facebook阻擋，分享就是Rock the world的精神阿阿阿～

另外Chrome Store的評論和討論的互動性機制還蠻差的，所以我弄了一個Facebook粉絲頁（Face book Page for Download FB album）如果在操作或使用上有任何問題請別客氣的進來鞭我吧。

Blackbing Playground

發表於
友邁科技多筆地址輸出系統

重寫舊系統

URMAP 有一個很實用的系統「地址轉經緯度」，可以 parse 台灣的地址，轉成 WGS84 經緯度或 TWD97 座標，並且API化，可以使用AJAX的方式來做查詢，會將地址做正規劃，查詢到最靠近的點。由於是HTTP的方式，因此很容易實做，就算要做批次的查詢，只要會寫程式都可以很快速的做出批量做座標轉換。然而對於某些公司而言，他們不想要為了這個功能而花時間寫程式，希望能夠提供直接做查詢的使用方式，於是早期就有一套轉換系統，用JAVA撰寫之後包成jar檔，直接在windows或linux下command line，指定讀取的file，就會輸出成指定的CSV檔案。由於大家也懶，因此這樣的程式就流傳下來，連自己都覺得這樣的方式很不方便，而且每次都要指定參數，操作方式並不是很友善。後來看到 node.js event io 的概念才有 IO 存取的概念，類似像這種批量查詢的需求，一般來說都是以同步的概念下去執行，也就是一個查詢完成之後再做下一個查詢，查詢一百次、一千次就要同步的等待每一個request完成。有沒有辦法讓查詢更快？可以用多執行緒來解決，無奈程式不好寫，除錯不容易，因此一直沒有實做。

Clinet端的檔案輸入與輸出

於是我用node.js來實做這種批次查詢功能，利用Event IO的概念來實做，的確可以很快速的做回應，但通常要批量轉換的地址資料都會很大，若在本機執行還沒什麼大問題，但若做成web系統，就還要讓使用者上傳、解析文件等等，非常麻煩，因此這樣的方式也不理想。最後我把腦筋動到 HTML5 FileReader，稍微試了一下，可以讓使用者選擇檔案，並直接透過javascript來讀取檔案內容，parse正確資料之後就可以在client端做AJAX批次的查詢。然而有輸入，就要有輸出，html5 FileWriter API幾乎沒有瀏覽器實做，因此Writer無法使用，不過我找到兩種方式來做文字檔的輸出：

萬事具備，只欠Coding。那就來實做吧。

javascript根本就是天生拿來做這種事情的，不費吹灰之力就完成了批次輸出系統，由於是用非同步的ajax來做查詢，因此同時發出ajax查詢之後等待回傳結果，而查詢的效能也非常的快，完全取決於server端給不給力的傳回資料。用說的實在是不過隱，分享片段的程式來瞧瞧。

試用連結

友邁科技多筆定址輸出系統，歡迎企業有大量需求申請使用。

讀取檔案

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//讀取檔案
function read() {
    var files = $('#filesInput')[0].files;
    if (!files.length) {
        alert('請輸入');
    }
    var file = files[0];
    var fileName = file.fileName;
    var fileSize = file.fileSize;
    var info = ['檔案名稱：' + file.fileName, '檔案大小：' + (file.fileSize / 1024) + 'k'];
    if (file.lastModifiedDate) {
        info.push('最近修改日期：' + file.lastModifiedDate.toLocaleDateString());
    }
    var infoHTML = info.join(' <br>');
    $('#d2-info').html(infoHTML);
    var reader = new FileReader();
    reader.onload = function() {
        $('#d2-content').text(reader.result);
        $('#d2').dialog('open');
    };
    var encoding = $('#encoding option:selected').text();
    reader.readAsText(file, encoding);
}

匯出成CSV

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
//匯出成CSV
function exportCSV() {
    //    console.log('export');
    var data = [];
    for (var i = 0; i < addressCallback.length; i++) {
        var line = [];
        var addressLine = addressCallback[i];
        line.push(addressLine.address);
        line.push(addressLine.formal_address);
        line.push(addressLine.city);
        line.push(addressLine.area);
        line.push(addressLine.longitude);
        line.push(addressLine.latitude);
        line.push(addressLine.xcoor);
        line.push(addressLine.ycoor);
        line.push(addressLine.level);
        line.push(addressLine.position_result);
        data.push(line.join(','));
    }
    var exportData = data.join('\n');
    //var newDoc = window.open( "data:application/x-download;charset=utf-8,"  , 'address_export.csv', '', '');
    //newDoc.document.write(data);
    Downloadify.create('downloadify', {
        filename: function() {
            var ts = +new Date();
            return 'address_export' + ts + '.csv';
        },
        data: function() {
            return exportData;
        },
        onError: function() {
            alert('You must put something in the File Contents or there will be nothing to save!');
        },
        transparent: false,
        swf: './downloadify/downloadify.swf',
        downloadImage: './CSV.64.png',
        width: 64,
        height: 64,
        transparent: true,
        append: false
    });
    $('#downloadify').show();
}

心得

值得一提的是，利用 jQuery.getScript 的方式比 jQuery.ajax 的方式要快，我想是用 getScript 的方式來直接執行 javascript 更快速。同樣的概念我想可以應用在所有需要批量輸入輸出的系統上，只要打開 browser，不需要安裝任何東西，也不需要上傳檔案到 server 端處理，完全透過 client 端解決所有的事情，javascript 的應用真是越來越廣泛了，有需要使用這個好用的系統請洽 友邁科技客服，會有親切的小姐跟您聯絡XD。