podcasting buzz

昨天貼了 mediatuner這個小軟體後，看了一下它的spec，結果提到一個 podcasting的字眼兒，原先以為這是某種ipod的延伸產品或服務，經過小小調查得到以下結果：

wiki的解釋
介紹1
介紹2

簡單說明：

其實這根本不是什麼新玩意，就跟大家之前把音樂檔放上blog給人聽或下載，或是像自架server做廣播(例如pushpush.org推推音樂網)，唯一的不同只在於它結合 rss 2.0可享受到所有 rss的好處。

因此 mediatuner這個軟體可以說是一個 podcasting reader，它除了可以讀 text blog外，也可以收聽 podcasting裏面播放的audio檔案。

我的疑問只有一個：

在自已的站台上放龐大的audio檔案供人下載，請問頻寬成本誰要付？

目前身邊朋友有在玩 個人廣播 的，通常都有辦法找到免錢的大水管架server，例如朋友正好在isp上班，或某學校的免錢機器，因此 個人 只要將訊號送進這台server，其餘的聽眾都是跟那台server要audio，這樣不論多少人都能應付的了。

但 podcasting的玩法卻是把audio檔放在自已的server上，例如你租的空間(通常會有數千Gb的流量限制)，如果不幸真的人聲濎沸萬頭鑽動，每個人下載一首歌就是4mb，1000人下載你這個月頻寬就爆了，而這還只是一首歌，並且限定每次只下載一次(如果我在公司抓一次，家裏抓一次，咖啡館上網時用notebook再抓一次….呼呼呼)

這裏面怎麼想都有些也方不對勁啊~

不過看來 blogger創辦人到是很有信心，他把blogger賣掉後弄了個新公司 odeo.com 準備搭上這股 podcasting風，還上了 NY times(要登入會員才能閱讀)。

我對他創辦blogger的眼光是很配服，但不知他是否也有認知到 text content 與 audio content 的根本差異性，還有產製這些內容的技術需求是完全不同的啊，畢竟買ipod只要會掏錢或信用卡就好，但要做 digital audio recording/editing/publishing就不是兩三句話的功夫了。

longhorn clone 介面

下載

note:這是一個windows shell pack，會完全改變你的視窗外觀(顏色、造型、icon等)

看起來跟蘋果大貓像的神奇啊~
如果是這樣，那還是真的比較好 :p

由這點可以得到幾個不負責結論：

1、aqua式的task bar(可游移放大縮小)將成顯學，雖然我覺得三層式的比較讚

2、放大toolbar的圖像並且一律採用半透明反光式設計也將成為標準

3、刷淡 titlebar 與 toolbar間的分隔並縮小右上方的控制鍵也成為潮流

所以，更簡單的結論是：大家直接去下載一本免錢的 Apple GUI guide然後銘記在心即可~

bsd各版本小註解

最近剛搬完家，忙了兩星期終於可以回到桌前專心工作了。

今天開始要重裝一些系統，順便翻了幾本關於bsd的書，將心得速記如下。

1、AT&T Unix 是最早的unix，後來傳到西岸berkley產生了 BSD 版本(Berkley System Distribution)

2、有人將BSD移植到可在個人電腦(386處理器)上執行，名為 386/BSD，從unix脫離高檔昂貴大型主機的世界。

3、386BSD之後衍生出許多類似的版本，例如FreeBSD, NetBSD, OpenBSD….

4-1、FreeBSD以最穩定著稱，許多isp都愛用
4-2、NetBSD相容性最高，幾乎各種裝置、平台都可執行，有人曾經笑稱乾脆在鬧鐘或鉛筆盒裏也裝一個NetBSD
4-3、OpenBSD號稱最安全，其網站上之tagline為: 八年來只發現一個hole。

5、但BSD不是唯一可在386個人電腦上執行的unix系統，其它如Solaris, Darwin等也都已port到pc上了。Solaris最近也採open source策略希望可捥回生機，而最近火紅的mac os x則是以 darwin為基礎，這個darwin也是386BSD的分支之一，但其採用的kernel為Mach，所以簡單來說不論 xxxBSD, solaris, darwin等都是unix系列的一種，基本上指令、程式都是相容的。

6、從發展的血源關系來看，BSD系是走比較正統的unix路線，而linux系列則是另起爐竈仿效unix寫出的系統，因此不理性的推估是BSD應該會比linux穩定、安全一點，但易用度、親和性就不見得那麼高。

7、基於上述的歷史發展與考量，很多人還是愛用FreeBSD做為server的作業系統，這也是為什麼我現在正努力安裝中的原因

當然linux也沒什麼不好，接下來我會重裝redhat 跟 debian/ubuntu同時跑三個系統，開發環境也非常有可能還是在linux上，但日後會慢慢轉移到FreeBSD。

C#的命名由來

C -> C++ -> C++++

但 C++++太長，就變成 C#

這是今晚聽朋友講的，據她說千真萬確真有其事 orz.
但我到這裏查了一下並沒有收穫。

persistent layer 第二擊

因為是懶人，所以尋找能順利將object < -> database 轉換的framework就一直是high priority task，
尤其是那些可能可以跟actionscript搭在一起合作愉快的方案更是吸引人。

當然如果你很忙沒時間繼續看下去，那先知道結論就好：目前沒有一個可以直接跟flash配合。

當然由於flash的工程師user base太小，一開始我也不指望會有這種東西，因此直接是從.net與java下手看能不能改過來用。

最初我找到一些關於 O/R mapping的書與文章，裏面教授的是過去二十年來工程師們一直用的手法(也就是雙手萬能的手工藝技巧)，而其中最令我心驚膽顫的一句話就是：

as stated before, 40-60% of the project time were used to handle OR mapping

當然手工藝並不是真的那麼萬惡不赦，很多中小型的案子自已動手或許真的比較快。

但由於類似O/R mapping這樣每天都得處理的routine實在是很煩索的可以，因此java界開始出現一個名為Java Data Object (JDO)的概念，也就是提供一個object 與 database的中介層，這原本只是sun提出的一個spec，但由於很受歡迎，因此很快市場上就出現一狗票的實作商品，理論上可以讓工程師完全不用再手動處理O/R mapping這件事。在所有的JDO-alike的實作裏，OJB算是open source圈內最響叮噹的一個方案。

而這幾年從JDO的概念又衍生出一個更新的persistent 技術，叫做 Hibernate，這個字實在是用的巧妙，讓人發出會心微笑。它有趣的地方在於hibernate原本是指電腦用完但不想關機時，可以按下休眠將ram裏的東西dump到disk上暫存，下次開機時只要把資料讀回ram裏就可以迅速回到可操作狀態(當然現在大家隨便都裝1、2GB的ram，這招不見得會快很多)；而這個字用在persistent方面，很明顯的可以看出工程師是認為 Object 才是”正常的操作狀態”，而存入資料庫(或其它persistent store)只是類似休眠的動作一樣，等將來要用時再取出即可。

從這個類比就不難看出Hibernate想要達到的目標，聽起來確實非常迷人，而更棒的是這個概念已經被port到各種語言，例如C#, php等都有，而且往往還有超過一種的選擇。

以目前調查的結果來看，比較完整的hibernate port都會再包含一層 database abstract layer，讓整個流程變的更有彈性(因為連data store的目標都可以隨便更換)，因此簡單來說，只要想辦法把物件從flash丟回app server，剩下的就交給 C#/php去處理，更讚的一點在於flash remoting可以透過binary的方式傳遞 native actionscript object (例如最常用到的 numeric array與associative array)，因此只要巧妙的玩弄remoting的binary特性，就可以在某種層度上達到Java Value Object甚至某些EJB才能做到的效果。

所以未來幾天有空的時間我會試試把整個流程串起來，看看是否真的可行。

不過使用persistent framework也不是完全沒有缺點，目前已知的問題有：

1、全新的專案比較適合使用，因為通常framework會統包db schema，很難與既有的schema吻合

2、由於db是由framework控管，因此要改東西時往往不是直接殺進db裏動手，而是要透過framework去修正，當架構越大時，成本就越高

3、各種framework都會讓專案的複雜度增加，最後可能變成”拿一個麻煩換另一個麻煩”(意思是：framewokr雖然解決了傳統OR mapping的煩索，但它自已本身可能也會變的很麻煩)

4、大部份php的hibernate port都是小規模私人進行的計畫，因此品質與可靠度只有天知地知他知但我不知，所以用起來要格外小心。

-簡易參考資料-