琉璃網站
CommunityServer 中文討論區-琉璃網站
mirror » 所有標籤 » 我的作品 (RSS)

依標籤瀏覽

  • 生產者 vs 消費者 - BlockQueue 實作

    過去寫了 好幾篇跟執行緒相關的文章 ，講的都是如何精確控制執行緒的問題。不過實際上有在寫的人就知道，那些只是 "工具"，最重要的還是你該怎樣安排你的程式，讓它能有效率的用到執行緒的好處，那才是重點。大部份能有效利用到多執行緒的程式，大都是大量且獨立的小動作，可以很簡單的撒下去給ThreadPool處理，不過當你的程式沒辦法這樣切，就要想點別的辦法了。 開始看 code 前先講講簡單的概念。這篇要講的是另一種模式: "生產者 v.s. 消費者"。這是個很典型的供需問題...

  • 該如何學好 "寫程式" #3. 進階應用 - 資料結構 + 問題分析

    接續前文: 該如何學好 "寫程式" ?? 該如何學好 "寫程式" #2. 為什麼 programmer 該學資料結構 ?? 這類文章還真不好寫，想了好幾天，才擠的出一篇文章。第一篇已經講了一堆教條了，第二篇也舉了簡單的例子，說明挑對資料結構的重要性，接下來這篇會把主題放在更複雜的例子上，到底那些地方該注重技術，而那些地方該把重點放在基礎的資料結構及演算法身上。 這次不囉唆半天了，先來回顧一下第一篇，我出的題目是這樣: 以台灣高速公路為題 (中山高、北二高、國道二號...

  • 得獎了 :D~~~

    雖然 上禮拜就知道了 ，不過 獎品 還沒拿到，當然要忍一下再發表... 哈哈! 花了幾個晚上拼了 猜數字的程式 ，運氣不錯，順利拼到冠軍了。除了寫程式，把心得貼到 BLOG 也花了不少時間.. 主要貼的這四篇: Thread Sync #1. 概念篇 - 如何化被動為主動? Thread Sync #2. 實作篇 - 互相等待的兩個執行緒 [C#: yield return] #1. How It Work ? [C# yield return] #2. 另類的應用 - Thread Sync 替代方案...

  • 該如何學好 "寫程式" #2. 為什麼 programmer 該學資料結構 ??

    自從貼了上一篇 [ 該如何學好 "寫程式" ] 一文，原本以為這種老生常談的內容沒什麼人會看，沒想到還有人給我回應.. :D 原來這種文章還是市場的。接下來這篇，是延續上一篇，來談談要成為合格的 programmer, 我認為應該要俱備的 "內功" 是什麼。上篇我提到，我認知的 programmer，就是要有實作 (CODING) 的能力。要有能力把技術規格 (像是輸入格式，操作介面等等) 具體的寫成可以執行的程式碼。當然是要寫的又快又好，穩定不當機又沒 BUG...

  • [C# yield return] #2. 另類的應用 - Thread Sync 替代方案

    繼 上篇 ，講了一些 yield return 編譯後產生的 Code, 說明了 C# compiler 如何用簡單的語法替你實作了 IEnumerator 介面，而完全不會增加程式的複雜度，這是我認為 C# 提供最讚的 Syntax Sugar ...。 不過無意間我想到了 yield return 還有另一種應用方式。靈感來自之前 Darkthread 舉辦的 [ 黑暗盃程式魔人賽 ]。因為參賽題目 [xAxB猜數字遊戲] 原本就是考驗演算法，邏輯就不大簡單了，加上要配合 GameHost 的呼叫方式...

  • BlogEngine Extension: Secure Post v1.0

    因為家裡大人開出條件，除非新的 BLOG 系統 (就是我在用的 BlogEngine 啦) 有特定文章要輸入密碼才能看的功能，否則她就不想換系統了 (原來是用 CommunityServer 2007)。要弄密碼其實很簡單，不過過去試過 IIS 加上整合式驗證... 弄到最後該看的人看不到，也沒擋到該擋的人而作罷...。 仔細想了想大人的需求，要的就是簡單的控制機制。不需要先建立帳號，也不需要登入，就是特定幾篇文章要輸入暗號才能看到內容，就這樣而以。無耐 BlogEngine 還算很年輕，替它寫的...

  • Bot... Bot Checker 回來了!

    哈哈，終於加回來了 :D 為什麼原本在 CS 上很簡單就加上去的 Bot Checker, 在 BE 上弄到現在才好? 原因只有一個，就是 BE 在張貼回應時用了不少 AJAX 的機制，變的要插一段 CODE 進去要追半天 @_@... 很諷刺的是，AJAX 其實是 Community Server 用的比較兇，到處都要來一下... 反而 BlogEngine.NET 就中規中舉多了，很多地方就都乖乖的用 PostBack.. 唯讀回應的地方很突兀，感覺好像是特別要現一下回應的那個 TEXT EDITOR...

  • Bot Checker 回來了!

    哈哈，終於加回來了 :D 為什麼原本在 CS 上很簡單就加上去的 Bot Checker, 在 BE 上弄到現在才好? 原因只有一個，就是 BE 在張貼回應時用了不少 AJAX 的機制，變的要插一段 CODE 進去要追半天 @_@... 很諷刺的是，AJAX 其實是 Community Server 用的比較兇，到處都要來一下... 反而 BlogEngine.NET 就中規中舉多了，很多地方就都乖乖的用 PostBack.. 唯讀回應的地方很突兀，感覺好像是特別要現一下回應的那個 TEXT EDITOR...

  • 又被盜文了... :@

    該說人紅嘛? 看起來也不是，就是正好我貼的文章又被盜用了。除了上次 [ 這篇文章 ] 被 盜貼 到 BLOGGER 上之外，這次又發現另一篇被盜貼了。這次被盜貼的是我之前發表一篇 [ 原來 System.Net.Mail 也會有 Bug ] 的文章，說明我碰到 Microsoft .NET Framework 的 BUG 及我挖掘問題真相的技術文章...。 這次無意間用 GOOGLE 找相關文章找到的，兩篇都是在對岸的網站，一個是照文全貼，唯獨 "忘" 了註明出處。至少他還很忠實原味...

  • 又被盜文了... :@

    該說人紅嘛? 看起來也不是，就是正好我貼的文章又被盜用了。除了上次 [ 這篇文章 ] 被 盜貼 到 BLOGGER 上之外，這次又發現另一篇被盜貼了。這次被盜貼的是我之前發表一篇 [ 原來 System.Net.Mail 也會有 Bug ] 的文章，說明我碰到 Microsoft .NET Framework 的 BUG 及我挖掘問題真相的技術文章...。 這次無意間用 GOOGLE 找相關文章找到的，兩篇都是在對岸的網站，一個是照文全貼，唯獨 "忘" 了註明出處。至少他還很忠實原味...

  • FlickrProxy #4 - 修正同步上傳的問題

    寫到這，越寫越拖抬了... 這次沒有加上任何 "新功能"，有的只是修正使用上的一些問題而以... 首先，還是要感謝愛用者 小熊子 的回報，照片初次被下載時會觸發上傳到 Flickr 的動作，上傳完成才重新引導 Request 到 Flickr 存取照片。如果在這一連串動作尚未完成前，就有第二個 Request 跑來的話，那這張照片就會被傳到 Flickr 兩次...。Orz，枉費我還 投搞 這些並行處理的文章，怎麼可以犯這種錯... 就跟很多 BUG 一樣，難在沒想到，難在沒發現...

  • FlickrProxy #3 - 終於搞定大圖網址錯誤的問題

    由於在使用 Flickr API 時, 老是碰到上傳成功後, 結果拿到的照片 URL 不能看的問題... 被它整了好久, 不過總算解決了 @_@... 原來 API 拿到的資料是錯的, 嘖... 說來話長, 不過既然花時間解決了就要記錄一下... 問題大概是這樣. 上傳照片完成之後可以拿到 photoId, 代表某一張放在 Flickr 上的照片. 之後透過 PhotosGetInfo(photoId) 這個 API 可以取得這張照片的相關資訊, 當然也有 MediumUrl, LargeUrl...

  • FlickrProxy #2 - 實作

    整個進度算是很順利，初版已經可以運作了，而且也成功的套用在 小熊子的 BLOG 上... 因為過去已經有幾個 類似的 HttpHandler 的 code 可以直接拿來改了，反而真正的瓶頸是在瞭解如何操控 FlickrNet 這個 .NET 版的 Flickr API 身上 Orz。FlickrNet 碰到的問題後面再說明，先來看一下整個 Project 的源頭: system design。 這個程式的目標很明確，就是我不想改變任何的使用習慣，我要讓 blogger (比如我家大人) 完全不用理會...

  • FlickrProxy #1 - Overview

    久久沒動手寫 code，手又開始癢了... 前陣子跟 小熊子 聊的時後想到一個新的 IDEA，就順手記下來。像我們這種自己用ADSL架的小型網站，瓶頸都是卡在頻寬。愛拍照的 小熊子 最在意的當然就是網站擺照片所需要的頻寬... 解決方式其實有一堆，像是 Live Writer 就有個很有名的 PLUGIN ，可以直接插入你放在 Flickr 的照片... 其實這類的 solution 很多，但是用起來就覺的不大喜歡，怎麼說? 倒不是說軟體不好用，而是它的作法。這類 plug-ins 都是幫你一次把事情作好...

  • Canon CR2 --> .JPEG 速度加倍.. 該換 Core2 Quad 了嘛?

    看來是換四核心CPU的時機到了 之前弄了半天的歸檔程式，效能都卡在 .CR2 -> .JPG 這段。雖然祭出了 ThreadPool，也想盡辦法把獨立的工作湊在一起，盡量提升 CPU 的利用率，不過得到的效果有限，因為最後都是剩下 .CR2 的檔案轉不完啊，其它拿來填空檔的工作早就做完了，實在不成比例... 整體效能還是卡在最慢的 Canon Codec 身上... 這次無意間想到，單一 process 內，Canon Codec 有過多不能重複進入的問題 (不能同時利用到兩顆CPU)，那麼拆成兩個獨立的...
1 2 下一頁 >
Copyright 2008 ruri.com.tw , .Net DCP partner