我的雲端生活網 - Life+

Sunday, January 21, 2007

erlang相關學習文件

erlang基本課程
http://www.erlang.org/course/course.html

erlang的簡體翻譯
http://computebank.spaces.live.com/blog/cns!955689A6CF175077!614.entry

Sunday, January 7, 2007

由高鐵訂票系統現象看技術

事實上有經驗的工程師,即使沒有寫過票務系統,一聽到座位會重複劃位
應該可以馬上就知道問題出在哪,舉個簡單的例子: 一個pool裡有20個
不重複的號碼,現在要從pool裡拿出不重複的號碼排在桌子上,跟高鐵的
售票系統就很類似,(這是Critical Section的問題),一個junior的
工程師,很可能使用select 的方式由table裡拿出未註記的座位號碼,
訂位後把座位做標記,然而;這樣完全沒有transaction的觀念,由訂位
前取號到訂位後註記,多工(多人連線)系統可能同時處理2以上的程序,
於是可能發生同時取得相同號碼的問題,這是很嚴重的系統規劃問題,取
號應該是同時只能容許一個程序進入(lock),訂位前到訂位後為同一個
transaction,應該要有成功與倒回的做法,然而;這些機制卻是很少人
會去注意,難怪;高鐵的系統會出現這麼可笑的問題,我想或許高鐵的開
發人員連如何lock 都不知道,這就是只會使用db 開發程式的RD會發生
的事,另一個有趣的問題發生在,為何系統上線前的測試沒發現這麼嚴重
的問題?我想做上線前系統測試的工程師絕對也是一個初級生,單工的測
試,怎麼可能測試出多人連線的狀況,或許這些工程師還在想,不可能阿!
我之前都有測試過,沒問題怎麼會這樣?呵呵..這句話應該是programmer
常說的話之一;這問題跟使用 db使用自動編號(or oracle內的serial
使用) 或是直接SELECT MAX(number)+1 ... 寫入db 所會發生的問題
很類似,只要是稍微有經驗的工程師就知道,確實的原因絕對與高鐵發佈的
消息完全無關,系統的規劃 撰寫 全是一群非常資淺的工程師所組成,這才
是主因,我相信這個系統與台灣彩券系統一樣,還有很多潛在的問題沒被挖
掘出來,這個基礎的設計問題事前都沒注意,何況是更深層的系統問題,而
這些目前看不到的問題才是真正可怕的地方

Friday, January 5, 2007

微程式資訊與優美企業合作列印管理系統的相關報導

摘自dititimes 付費文章 http://app.digitimes.com.tw/ShowNews.aspx?zCatId=117&zNotesDocId=0000036429_A207213DJP3PUWI8VX780

列印的文件會認人 安侯建業利用RFID管制事務機
(記者王明德/台北) 2006/12/26


商場競爭日漸激烈,各企業均使盡各種方法保護商業機密,台灣大型會計事務所安侯建業利用RFID管制辦公室事務機,企業員工列印時,必須持內建RFID晶片的員工識別證讓事務機讀取,文件才會列印出來,此舉不但可以避免非相關人員看到甚或攜走機密文件,同時也可以計算每位員工的列印紀錄,用以作為成本計算。

安侯建業是台灣屈指可數的大型會計師事務所,客戶包含台灣各重量級企業,在機密考量下,該公司在事務機內建置安全系統,協助導入的系統廠商微程式資訊總經理吳騰彥表示,這套系統與台灣事務機廠商優美企業合作,系統並未更動事務機內部架構,只在機器上設置讀取器,並在伺服器安裝閘道管控裝置而已。

當列印者送出列印指令後,訊息送往該公司內部網路伺服器,閘道管控裝置會將訊息留置,此時列印者在前往事務機,讓讀取器感應員工識別證內的RFID晶片,讀到訊息的讀取器再通知伺服器,將資料放行到該處列印,如此一來列印文件就可以保證只有列印者才能拿到,不會發生被有心者拿走或其他同事誤取的情況,而且使用者列印時也不用指定事務機,只要在最近一部機台上感應識別證即可列印,除了機密考量外,這套系統還可以紀錄所有員工的列印狀況,藉此管控成本。

吳騰彥指出,其實這套系統的技術不難,且不用動到事務機內部設計,只要在外部加掛設備即可,RFID的應用越來越廣,技術都已不是問題,價值在於創意的產生,未來相關應用會隨著發展加速而日漸多元。

從SI到ISV微程式資訊走出台灣軟體之路

文章摘自digitimes (96/01/02)
http://app.digitimes.com.tw/ShowNews.aspx?zCatId=913&zNotesDocId=0000035864_A206P17INP7KMLG3VG0JU

從SI到ISV 微程式資訊走出台灣軟體之路
(記者王明德/台北) 2007/01/02


前言:RFID這幾年在台灣成為當紅炸子雞,Internet 2、IT革命等美譽不斷堆疊其上,不過台灣長期以來多以硬體製造為主,軟體能力相對薄弱,在RFID的發展上也是如此,台灣的標籤晶片、讀取器製造能力不容置疑,不過在軟體開發上始終矮國外廠商一截,微程式資訊是台灣目前唯一一家RFID開發軟體廠商,總經理吳騰彥指出,在仍處起步階段的市場與政府支援有限的情況下經營,的確充滿挑戰。

在2004年美國零售巨人Wal-Mart宣布RFID政策,全球80%以上的廠商才開始了解什麼是無線辨識系統(Radio Frequency Identification;RFID),不過遠在11年前,吳騰彥就已經做過RFID的案子,「那時候甚至還不叫RFID,而有另一個專有名詞。」當時的他剛退伍,回到母校嘉義農專當助理,學校因緣際會接到1件荷蘭廠商的專案。

荷蘭是全球酪農產業最發達的國家之一,養育乳牛的技術也居全球之冠,該地農家開始採用全自動養殖系統,每天發派定量飼料,過一段時間後卻發現牛奶品質不穩定,查驗流程後發現,牛隻進食的比例不一定,多吃的牛,牛奶品不一定會更好,但是少吃的卻一定會下降,於是荷蘭廠商希望能有一套定量餵食的系統,於是找上嘉義農專。

吳騰彥接到這件案子後,找遍國內外,最後發現當時還不叫RFID的射頻辨識技術,可以解決問題,他將晶片設計成耳環掛在牛耳上,再配合飼料槽上的讀取器,當牛隻靠近飼料槽,讀取器讀到資料後會判斷當天這隻牛有無進食過,沒有的話會自動掉落飼料,反之則沒有動作。

多年後回想起這件案子,再延伸到現在微程式的RFID業務,吳騰彥表示可算是一脈相承,雖然中間過程轉了好幾個彎。

打造在地化、單一簽入系統

退伍後的吳騰彥在學校待了一段時間後,教授認為他如果不繼續往學術發展,念個碩士、博士學位的話,不如離開學校往外發展,幾經思考,他決定創業,憑著在學校接專案的經驗,與朋友合資開了微程式,不過嚴格來說,教授的話吳騰彥只聽了一半,雖然開了公司,他還是離不開學校,因為微程式做的是學校生意。

微程式成立初期的市場定位是「大專院校的系統整合廠商」,學校單位長期以來被SI業者視為畏途,雖然有預算,但預算不多,勇於投錢,但後續維修麻煩也不少,投資報酬率在廠商眼中並不划算,不過麻煩越多就代表競爭者越少,微程式的學校生意越做越大,從南部大專院校一路往北發展,現在全省各地校園都不難看到微程式的系統。

「IT產業那麼大,我們當然不可能什麼都做,主要的技術是單一簽入系統(Single Sign On SolutionSSO)」,學校實驗室中有各種IT平台,每一種平台都有各自的登入系統,每一個使用者都必須使用自己的帳號、密碼才能登入,不過平台太多,使用者懶的1個1個登入,於是就開始便宜行事,整個實驗室共用1組帳號密碼,結果身分識別的功能徹底消失,平台誰登入過?誰改過資料?完全無法管控,要解決這個問題,就必須建置單一簽入系統

如果把IT系統比做1棟大房子,系統中的各式平台就好像裡面的房間,使用者拿鑰匙打開大門後,如果每進一個房間還要掏出同一把鑰匙開門,那未免太沒有效率,單一簽入系統就是讓使用者只要在大門口開一次門,進門之後,裡面所有房門都會認得你,人一到門就會自動打開,對建有多系統的機構來說,十分方便。

單一簽入系統包括微程式在內,全球共有5家廠商在做,不過前4名都是國際大廠,所以吳騰彥常自嘲說,微程式是全球第五大,因為總共只有這五家。不過這些國際大廠並不會來搶微程式的生意,「因為他們太大了,不可能會因為1家客戶來更改自己的標準系統。」他接著指出,微軟等大企業的系統都是標準化,他們的單一簽入系統必須應用在自己的平台上,而台灣企業的e化系統往往由不同廠牌平台架構起來,要做他們的單一簽入,必須要能與這些系統介接,微程式就是利用自己的彈性化設計,搶到台灣市場。

研發人才難覓 中小企業要自己搞定

隨著企業規模擴大,微程式發現技術不夠用,對此吳騰彥感嘆,台灣的SI廠商很可憐,現在民間資訊越來越發達,SI過去賴以維生的專業知識竟然慢慢淪為普通知識,為了讓企業存活,SI廠商必須往上尋求更專業的技能,才能做出產品區隔,但台灣產業環境並沒有太多管道讓SI廠商往上成長,當時身為SI角色的微程式也有相同問題。

於是微程式自己到學術單位找技術,培養研發人才,做著做著,竟然開始有SI同業向微程式尋求技術合作,而且次數越來越多,於是吳騰彥乾脆順勢讓轉型,讓微程式成為SI廠商上游的ISV業者,並將產品線延伸,RFID研發套件就是轉行後提出的產品。

歷經過SI、ISV等身分,吳騰彥深深覺得人才難覓與政府協助有限,是這個業界目前最大的困境,他指出SI廠商的產品領域多半較為特別,產品組成也不同,對一個新進人員來說,全部都是陌生領域,經過磨合期如果發現不適合而求去,對企業與個人來說,都是資源上的浪費。

因此微程式計畫開始建教合作,讓學生在就學階段就能來公司工作,一方面了解企業文化、產品特色,另一方面也透過合作模式,讓學校能夠真正教導業界所需的知識,至於此舉會不會奏效,他坦言目標不大,「1年能留下1個就好。」

「其實台灣不缺人才,是中小企業缺人才。」吳騰彥認為廠商規模會對人才取得產生排擠作用,他曾與1位博士面談,希望對方來微程式進行研發工作,當時對方還有另一個工作在考慮,那家公司就是台積電,吳騰彥對他說:「來我們這邊有發展機會,你去台積電或許薪水比較高,不過只是顧機台而已,因為他們有錢,請的起博士顧機台。」然而到最後,對方跟你我一樣,還是選擇了台積電。

中小企業經營管理 仍需政府協助

人才問題一直困擾著微程式,吳騰彥開始想盡辦法找人,為了旗下RFID在醫療業的應用,他甚至還考進博士班念醫療管理,「當然也是希望自己有醫療管理知識,以便於產品研發,不過另一方面也是可以跟博士生做朋友,培養人脈。」吳騰彥直言自己要畢業恐怕不容易,不過到是透過博士班找到不少人。

除了人才外,中小企業的經營也是一大問題,台灣企業只要有心做、方向對,公司要成長並不難,不過成長之後要轉型,常常會是一大挑戰,舉例來說,企業成長到一定階段要擴大規模,必須向銀行借貸,但中小企業的財報資料大多自己處理,未必能符合銀行要求,於是常會被打回票,關於這點,政府並沒有太多輔助。

在經營方面,企業成長速度快,組織卻不一定跟的上,這時候要停止成長重理組織,還是先衝業績再說,這個抉擇拿捏就考驗著企業主的智慧,不過這相關單位同樣也沒給企業資源或協助,當初微程式放棄SI業務轉做ISV,除了依靠自己的判斷外,吳騰彥認為也是賭一把,只不過後來結果是成功,對於中小企業的經營,尤其是台灣的軟體資服業者,政府必須扶持,否則光靠廠商,他最後表示:「氣終究還是不夠長」。

Wednesday, January 3, 2007

jabber 的歷史

Jeremie Miller於1998年開始了這個項目。第一個公開版本於2000年5月發行。這個項目的主要產品是jabberd,Jabber的伺服器端軟體。它既可以創建私人的Jabber網路,也可以加入全球的公共Jabber網路。Jabber的關鍵特色是,分散式的即時通訊系統,以及使用XML串流。

Jabber協定目前由Jabber軟體基金會管理,而Jabber協定的主要基礎已經在RFC3920當中以XMPP之名被網際網路工程工作小組(IETF)接受為網際網路標準。Jabber和以SIP協定為基礎的SIMPLE常被視為為即時通訊及Presence告知領域的競爭對手,然而XMPP的設計更傾向提供一個一般用途的、應用程式之間的中介軟體設施。

2005年,Google發佈了Google Talk,這是一個IP電話及即時通訊的服務,即時通訊功能採用了開放的Jabber/XMPP。預計這將對Jabber社區起很大的推動作用。初期此服務不支援伺服器到伺服器的通訊功能,所以未能完全發揮Jabber的分散式特色。2006年1月17日起,伺服器到伺服器的通訊啟用了,Google Talk用戶可與其他Jabber公共網路的用戶對談。

Tuesday, January 2, 2007

perl6 的一些歷史簡介

http://www.perlchina.org/archive/archive.php?action=archive&page=27

ejabberd 使用 Erlang 開發IM Server

最近在思考message center 所使用的jabber server要自己寫還是用現成
的server,自己寫不是不可能只是可能要花的時間可能會比較久,於是參考了
ejabberd

他的網站提到
ejabberd is a free and open source instant messaging server written
in Erlang.

從來沒聽過語言,查了一下
Erlang is a programming language designed at the Ericsson Computer
Science Laboratory. Open-source Erlang is being released to help
encourage the spread of Erlang outside Ericsson.

看來是一種非oo 非程序 的functional programming language,有點類似
Haskell,最有趣的是他是跨平台的語言,而讓我驚奇佩服的是,ejabberd 居然可
以把功能做的這麼完善,真是高手中的高手

微軟確認了ie7上的bug

經過幾次交涉,我們提供了測試環境,微軟終於確認了這個ie7 的bug,詳細的bug內容請參考前面的文章
疑似IE7的bugs;以下是微軟的信件回覆,為了保留別人的隱私我把別人的基本資訊刪除了

Dear Luke
After I confirmed with US PM, the issue the customer encounter is a problem of IE 7. It is caused by
the way IE7 performs feed format detection: it’s looking for elements starting with “RSS”. Clearly
this is incorrect in the case we encounter. We’ve noticed this issue and may consider fix it in the future.

Let me know if you have any questions. Thank you.


技術支援工程師 Product Support Engineer
Platform Desktop Support Team
Global Technical Support Center - Taiwan
技術支援服務首頁: http://support.microsoft.com

Blog Archive