今天一個外包的廠商用MSN傳送一個power-point檔案給我,說要我看一下內容,我回應他
『我的notebook是沒有裝office相關套件的linux,我回去再看』
沒想到對方的回應讓我有點不解,他似乎覺得我是因為在上班所以不想看,這是我編出來的理由,或許現在有人電腦裝linux不是怪事,但連所有office套件都沒裝似乎不是這個星球的人做的事,我~~也懶得解釋了。
有趣的地方是現在似乎每個人已經習慣自己的電腦裡面有『每個人都應該有』的軟體,所以當你把文件丟給別人的時候不會問別人『你有沒有xxx軟體可以看』,因為~~沒有是你自己有問題。但每個人的需求都不同,甚至對軟體的喜好也不同,這些就像是身處不同世界的人看著對方的詭異行徑。
其實就算使用openoffice,也有許多用微軟office的軟體製造出來的檔案無法顯示完全正常,恩~~我知道是微軟的問題,但另外的問題是現在的使用者已經習慣一個單一而制式化的無趣世界。所以其實我是支持公開格式的人,如果格式是公開的~~~誰管你用啥軟體。
但這樣的情況在產業界卻不容易發生,每一間廠商都用獨特的格式來包裹使用者,讓使用者變成必須被一直壓榨的對象,這種現象台灣在一個產業格外明顯:導航地圖。說實在的台灣的地圖資料提供商並沒有太多,很多起步的公司也是用運研所的基本圖來改,但是所有的廠商都會做一件事情,把這些格式轉成另一種別人讀不出來的格式,轉換的重點不只是效率(往往效率是最後的考量),而是~~防止複製。在國外的地圖有些不太一樣的發展,有一些專門只做圖資的公司專心的維護資料收取費用,而軟體公司專心研發更友善與更有效率的軟體,所以產業才會進步。
其實文書處理軟體也是相同的狀況,不知道從何時開始,好像你沒有開啟.doc檔案的能力,你的電腦就被宣告成廢物,不過~~或許我可以產生tex文件但對方無法使用,這又是不同世界的差異,但應該要尊重與你不同世界人的人。
在公司裡面因為開發linux的程式,所以我也就理所當然的把PC裝上linux,不過其他人卻是都是winxp+vmware,其實只要能夠工作,我也懶得管你用啥OS,不過當你要拿奇怪的windows程式的資料給別人的時候,我想應該要考慮到對方是否可以使用,而不是~~我有盜版的軟體,要的跟我拿。
莫名其妙被誤會成使用鳥藉口~~這~~還真是一個鳥世界呀。
Wednesday, April 15, 2009
Monday, April 13, 2009
iPhone
最近朋友介紹一個開發iPhone小程式的外包給我,雖然說我沒有mac寫程式的經驗,不過對方還是覺得ok(我想是因為我便宜吧~~~哈,反正我是抱持好玩學習的心態),因此開始了我的第一個iPhone與mac程式經驗。
不過Apple這死要錢的公司真是過份,還要開發者交一年99美金才能把程式放到iPhone上面,這~~我~~當然不付錢,這個時後就覺得Open Source真是親切呀~~連這都有人幫大家解決~~ㄏㄏ。使用一些破解的方式可以讓iPhone不綁SIM卡而且還可以安裝自己的軟體上去(透過cross-compiler,不是用XCode),不過台灣的中華電信版本iPhone已經是不鎖sim卡的版本,因此只要安裝installer與ldid這些軟體就好,透過網路就可以把軟體丟上iPhone(透過ssh)。
更自由的iPhone開機出現了~~~~鳳梨~~~ㄏㄏ

有terminal看起來更順眼了~~ㄏㄏ

新的經驗~~objc並不會太複雜,只是覺得interface builder暗地裡幫工程師做太多有的沒的,因此決定不用interface builder,反倒覺得程式比較好寫(這叫犯賤嗎~~哈),不過~~要我去買一台mac我倒是會猶豫了,因為我覺得還是linux好用,不過如果跟M$比Mac還是有優勢啦~~哈。
不過Apple這死要錢的公司真是過份,還要開發者交一年99美金才能把程式放到iPhone上面,這~~我~~當然不付錢,這個時後就覺得Open Source真是親切呀~~連這都有人幫大家解決~~ㄏㄏ。使用一些破解的方式可以讓iPhone不綁SIM卡而且還可以安裝自己的軟體上去(透過cross-compiler,不是用XCode),不過台灣的中華電信版本iPhone已經是不鎖sim卡的版本,因此只要安裝installer與ldid這些軟體就好,透過網路就可以把軟體丟上iPhone(透過ssh)。
更自由的iPhone開機出現了~~~~鳳梨~~~ㄏㄏ

有terminal看起來更順眼了~~ㄏㄏ

新的經驗~~objc並不會太複雜,只是覺得interface builder暗地裡幫工程師做太多有的沒的,因此決定不用interface builder,反倒覺得程式比較好寫(這叫犯賤嗎~~哈),不過~~要我去買一台mac我倒是會猶豫了,因為我覺得還是linux好用,不過如果跟M$比Mac還是有優勢啦~~哈。
Wednesday, March 25, 2009
軟體合法
今天在Slashdot看到一篇文章講到在工作上因為前一位職員幫公司內的PC都裝了盜版軟體,我想這個位置應該是類似MIS的工作吧,但是當他接手後,如果跟公司員工解釋說公司內部沒有這些軟體或是他是非法的,通常會讓對方非常生氣,因為~~以前那位仁兄都可以生出來。
其實在資訊產業上班,尤其是小公司,這類的問題層出不窮,有時候甚至你不得不低頭,以我的例子來說,之前曾經在一個軟體公司,裡面的開發環境都是windows-base,當然沒辦法需要使用VC這類的編譯環境。上司拿給我盜版的軟體,安裝呢~~總覺得自己是這邪惡海盜王國的幫凶,不裝呢~~我怎麼工作?我想我是不會自己去買一套正版的,因為除了工作之外我根本不用windows。
除了工作之外,生活上也是一樣的問題,因為自己從事軟體這行,親朋好友似乎把你當成補帖商,要啥軟體就跟我要,每一次要解釋這些版權的問題總是會引起一些『你是不想幫我吧』的感覺。介紹他們自由軟體~~恩,他們一點興趣都沒有,只想要使用那些『已經會使用』的軟體。
所以現在我現在大多找linux上面的軟體設計工作,不過~~在linux上面開發軟體使用linux的機器對很多公司主管來說也是把我當怪人~~哈,很多從事linux程式設計的工程師都用windows平台,當然現在的VM都做的很有效率,不過總是缺乏一種使用者的觀感。這樣的問題或許在Mac與PC之間更為明顯,因為操作方式更大的差異(所以我也用WindowMaker來減少落差~~哈)。
軟體合不合法在道德層面是件簡單的思考,我想大多數人都會義正詞嚴的說要保護智慧財產權,但當自己需要使用的時候,道德~~就留給跟小孩說教的時候使用。我喜歡我的linux box~~~因為~~我不用感到我是海盜的擁護者。
Slashdot文章在此
其實在資訊產業上班,尤其是小公司,這類的問題層出不窮,有時候甚至你不得不低頭,以我的例子來說,之前曾經在一個軟體公司,裡面的開發環境都是windows-base,當然沒辦法需要使用VC這類的編譯環境。上司拿給我盜版的軟體,安裝呢~~總覺得自己是這邪惡海盜王國的幫凶,不裝呢~~我怎麼工作?我想我是不會自己去買一套正版的,因為除了工作之外我根本不用windows。
除了工作之外,生活上也是一樣的問題,因為自己從事軟體這行,親朋好友似乎把你當成補帖商,要啥軟體就跟我要,每一次要解釋這些版權的問題總是會引起一些『你是不想幫我吧』的感覺。介紹他們自由軟體~~恩,他們一點興趣都沒有,只想要使用那些『已經會使用』的軟體。
所以現在我現在大多找linux上面的軟體設計工作,不過~~在linux上面開發軟體使用linux的機器對很多公司主管來說也是把我當怪人~~哈,很多從事linux程式設計的工程師都用windows平台,當然現在的VM都做的很有效率,不過總是缺乏一種使用者的觀感。這樣的問題或許在Mac與PC之間更為明顯,因為操作方式更大的差異(所以我也用WindowMaker來減少落差~~哈)。
軟體合不合法在道德層面是件簡單的思考,我想大多數人都會義正詞嚴的說要保護智慧財產權,但當自己需要使用的時候,道德~~就留給跟小孩說教的時候使用。我喜歡我的linux box~~~因為~~我不用感到我是海盜的擁護者。
Slashdot文章在此
Friday, February 27, 2009
爭論點
那天跟公司的研發主管報告專案的程式部份,對我來說要跟別人解釋自己的程式重點我會放在架構,因此我把大多數的時間放在我怎樣使用共用的介面函數指標建立共用的物件(C語言),中間我提到一個東西被轟整場的,我說到~『我的callback function的prototype定義為.....』。
後來這些老大們開始活絡起來(本來好像快睡著的樣子),他們突然開始說『callback function的定義是一定要有signal的事件引發一個function才能叫做callback function』,或許我才疏學淺吧,我怎麼印象中只要使用function pointer指到一特定的函數位置,讓某一機制的程式碼去呼叫這些函數就稱為callback,我印象中跟signal好像沒有直接關係。
不過呢~~爭論一下下我就發現糟糕,因為其實這並不是重點,重點是這是主管要下『指導棋』的時候,所以其實我應該是要說『恩,原來我沒有注意到這麼深的學問』(ㄟ~~吐好看一點啦)。但我覺得很怪的是針對一個程式專案要討論或研究,架構才是重點,但老是把事情放在這種雞毛蒜皮的事情上面,難怪我很討厭開會~~ㄏㄏ。
其實這也是我覺得我們的開發流程有問題的地方,我們一直把焦點放在GUI library上面,也就是大家都在討論~~~哪一個widget可以用、有沒有辦法用更簡單的方式把GUI拉好、顏色怎麼改.....等等,當然我不是說這不重要,只是這些東西在這些GUI論壇或甚至是google一下都可以有解答,但一個程式絕對不是有GUI就完成。(只要GUI不完成任何事的程式不就是示範程式嗎~~ㄏㄏ)
這也讓我想到常常會有人問~~『你對某某library熟不熟』,我常常都不知道怎麼回答,我很少『熟悉』一個library,所以我寫程式一定要有網路,因為我要一直查API的網頁~~ㄏㄏ,但是我發現他們好強歐,用背的耶~~我的天呀。我對SQLite熟不熟~~『恩,我有使用SQL關聯式資料庫的概念,SQLite我知道他是用檔案式的小型資料庫』,這樣的回答基本上我的同事與長官們是會把我當異類的~~ㄏㄏ。
哪些library有哪些API~~我沒有半個熟的,要用的時候我會上網查或甚至把include file打開搜尋一下也可以有個概念,但~~~不論開會的目的是啥,我想應該最終都是要解決問題,因此爭論點是否可以放在『我覺得這樣的架構有....的缺點』、『如果....設計是不是更好』,至於其他展現熟悉度與高深學問的爭議~~我就免了,畢竟~~我本來就不是高材生呀~~ㄏㄏ。
後來這些老大們開始活絡起來(本來好像快睡著的樣子),他們突然開始說『callback function的定義是一定要有signal的事件引發一個function才能叫做callback function』,或許我才疏學淺吧,我怎麼印象中只要使用function pointer指到一特定的函數位置,讓某一機制的程式碼去呼叫這些函數就稱為callback,我印象中跟signal好像沒有直接關係。
不過呢~~爭論一下下我就發現糟糕,因為其實這並不是重點,重點是這是主管要下『指導棋』的時候,所以其實我應該是要說『恩,原來我沒有注意到這麼深的學問』(ㄟ~~吐好看一點啦)。但我覺得很怪的是針對一個程式專案要討論或研究,架構才是重點,但老是把事情放在這種雞毛蒜皮的事情上面,難怪我很討厭開會~~ㄏㄏ。
其實這也是我覺得我們的開發流程有問題的地方,我們一直把焦點放在GUI library上面,也就是大家都在討論~~~哪一個widget可以用、有沒有辦法用更簡單的方式把GUI拉好、顏色怎麼改.....等等,當然我不是說這不重要,只是這些東西在這些GUI論壇或甚至是google一下都可以有解答,但一個程式絕對不是有GUI就完成。(只要GUI不完成任何事的程式不就是示範程式嗎~~ㄏㄏ)
這也讓我想到常常會有人問~~『你對某某library熟不熟』,我常常都不知道怎麼回答,我很少『熟悉』一個library,所以我寫程式一定要有網路,因為我要一直查API的網頁~~ㄏㄏ,但是我發現他們好強歐,用背的耶~~我的天呀。我對SQLite熟不熟~~『恩,我有使用SQL關聯式資料庫的概念,SQLite我知道他是用檔案式的小型資料庫』,這樣的回答基本上我的同事與長官們是會把我當異類的~~ㄏㄏ。
哪些library有哪些API~~我沒有半個熟的,要用的時候我會上網查或甚至把include file打開搜尋一下也可以有個概念,但~~~不論開會的目的是啥,我想應該最終都是要解決問題,因此爭論點是否可以放在『我覺得這樣的架構有....的缺點』、『如果....設計是不是更好』,至於其他展現熟悉度與高深學問的爭議~~我就免了,畢竟~~我本來就不是高材生呀~~ㄏㄏ。
Monday, February 09, 2009
一樣?
以前常常會跟PM吵架,現在大多我已經不吵了,原因大多數是因為工作職權分責。
最近一些軟體專案要開始運作,不過往往負責規劃的人都很會拖,當然我也知道可以把一些基本架構寫好,不過至少要知道這個專案到底要完成哪些工作吧。其實大多數我遇到的狀況都是告知一個很大的框架,然後~~~~工程師應該可以寫了吧。
以前記得有一間公司要做車用資訊系統,規劃的PM很有架式的把工程師叫進去,講了一推CarPC的未來多麼不可限量,然後~~要做啥?我當然知道是車上的資訊系統,只是除非是研發經費無限大、系統能力無限多、研發工程師要多少有多少....不然,還是得有個規劃吧。
以前最常遇到的狀況是~~『阿你不會去看競爭對手有啥功能歐』,其實我很討厭這句話,當然我並不反對參考別人的設計,但那必須是去思考別人的設計用意為何,是否是個適合我們的設計方式,在我們的產品中是否該做如何的轉變。不過~~事實上~~上面的回覆通常是:跟他們一樣就好,比較安全。而且~更讓我奇怪的是,為何這些事情都變成工程師要去想辦法的?
一樣的產品,何必在研發一次呢?當然我知道很多老闆都會用價格來取勝,但除非你偷到別人的設計原始稿會是原始碼,否則很多的東西都是複製表面的狀況,自然~~這類的產品破壞市場的功能多於創造新產品。
現在的狀況其實變化不大,今天總部的PM來討論我對於設計上我覺得不太好用的功能與設計,對方的回答是『你說的其實我都同意,不過競爭對手都是這樣,我們就一樣就好』,一樣~~好吧~~那就一起浮沈吧。
最近一些軟體專案要開始運作,不過往往負責規劃的人都很會拖,當然我也知道可以把一些基本架構寫好,不過至少要知道這個專案到底要完成哪些工作吧。其實大多數我遇到的狀況都是告知一個很大的框架,然後~~~~工程師應該可以寫了吧。
以前記得有一間公司要做車用資訊系統,規劃的PM很有架式的把工程師叫進去,講了一推CarPC的未來多麼不可限量,然後~~要做啥?我當然知道是車上的資訊系統,只是除非是研發經費無限大、系統能力無限多、研發工程師要多少有多少....不然,還是得有個規劃吧。
以前最常遇到的狀況是~~『阿你不會去看競爭對手有啥功能歐』,其實我很討厭這句話,當然我並不反對參考別人的設計,但那必須是去思考別人的設計用意為何,是否是個適合我們的設計方式,在我們的產品中是否該做如何的轉變。不過~~事實上~~上面的回覆通常是:跟他們一樣就好,比較安全。而且~更讓我奇怪的是,為何這些事情都變成工程師要去想辦法的?
一樣的產品,何必在研發一次呢?當然我知道很多老闆都會用價格來取勝,但除非你偷到別人的設計原始稿會是原始碼,否則很多的東西都是複製表面的狀況,自然~~這類的產品破壞市場的功能多於創造新產品。
現在的狀況其實變化不大,今天總部的PM來討論我對於設計上我覺得不太好用的功能與設計,對方的回答是『你說的其實我都同意,不過競爭對手都是這樣,我們就一樣就好』,一樣~~好吧~~那就一起浮沈吧。
Wednesday, February 04, 2009
教育券
記得不久之前,在美國舉辦的國際電子元件會議上面,美國的學者呼籲美國政府改善工程師的教育,以免讓美國的工程能力慢慢衰退,其中他們建議要培養T型人材,也就是除了在工程相關領域的研究之外,也要延伸到數學、科學甚至美學的領域,構成一種深入專業領域的廣泛應用人才。當然還有創造力,對於快速以商業力量獲利的美國企業,慢慢的把重心放在商業經營而缺少創新能量。
對照現在政府採取教育券的模式,美國工程界的作法有何不同呢?首先,我們要改善的是基本教育面向,而不是技術。如果你看看這次政府官員在講這個政策,其實很大多數都是採用『技術訓練、快速上工』的思維,當然這凸顯了一個台灣教育體制的問題~~缺少實做精神。但我們應該如何改變這些狀況確實不應該由『技術訓練』著手,對於學校教育中能夠加強的應該是實際的應用思考。
簡單來說,當我們在學校學習許多的電腦程式演算法的時候,老師常常講解理論,然後把重點放在每個演算法的效能評估上面(就是big-O函數~~ㄏㄏ),當然這應該要了解,只是問題在於除了這一個部份,現有這麼多學習的演算法,有哪些地方可以用到老師從來不講解。當這些學生出了社會,赫然發現許許多多的任務要去解決,但~~~不知如何下手。
當然我們的工程師還有一個大問題也跟美國一樣,我們往往太過於專注於自己的領域,例如~~一個軟體工程師只對程式語言的議題感到興趣,其他的學識往往都一無興趣。但假設今天出現一個工作,希望工程師去完成一個應用程式,重點不在於軟體怎麼寫,而在於~~這個軟體怎麼運作,其中涉及的不是程式語言的範疇,而是~~~這個應該程式的know-how。
工作中常常遇到一些學校剛畢業的學生,在學校的時候成績一把罩,但當面對一個沒有標準答案的工作任務~~~往往傻眼不知如何下手,他們常常需要你告訴他們怎麼開始寫,其實很多東西學校都有教過,只是不知道為何當面對到的時候,一定要有人跟他們說『這裡應該可以用liXXXXXnked list解決』『scanline演算法可以處理這一段』...,我覺得如何把學生所學的東西實際貫通才是最為重要的。
台灣的科技產業歷經了大量代工的年代,因此很多優秀的畢業生,一畢業之後進到大公司往往就是開始做一些機械性重複的動作,這些優秀的學生在歷經多年這樣的職場訓練,往往也喪失了邏輯的處理能力。記得多年前有學者呼籲企業界讓員工開始創新,否則台灣的資訊產業將停留在代工、製程改善的死胡同。或許這才是目前台灣科技產業最大的問題,為何大量裁撤掉工程師,因為~~~這些工程師對公司來說只是螺絲釘,具有標準規格,之後在買就好,這樣子代工模式思維其實大量存在我們許多科技產業。
因此,如果要解決高學歷失業的問題,如何改變科技產業結構比讓畢業生重新受技能訓練重要,畢竟要讓市場上產生高學歷學生的需求比改變這些學生去符合現在產業來的長遠。其實現在高學歷失業的問題也凸顯一個有趣的問題是,我們這個社會真的需要這麼多大學生嗎?或是說需要這麼多科技相關領域的高知識份子?資訊產業對於台灣來說有一種磁吸作用,它往往讓其他較有未來的產業的社會資源被排擠,所以或許少一些資訊博士,多一些文化博士、音樂人才、農業專家.....會對這個社會產生比較正面的改變。
與其花許多的錢發放教育券,我倒是覺得認真思考我們的教育政策來的充實些。
對照現在政府採取教育券的模式,美國工程界的作法有何不同呢?首先,我們要改善的是基本教育面向,而不是技術。如果你看看這次政府官員在講這個政策,其實很大多數都是採用『技術訓練、快速上工』的思維,當然這凸顯了一個台灣教育體制的問題~~缺少實做精神。但我們應該如何改變這些狀況確實不應該由『技術訓練』著手,對於學校教育中能夠加強的應該是實際的應用思考。
簡單來說,當我們在學校學習許多的電腦程式演算法的時候,老師常常講解理論,然後把重點放在每個演算法的效能評估上面(就是big-O函數~~ㄏㄏ),當然這應該要了解,只是問題在於除了這一個部份,現有這麼多學習的演算法,有哪些地方可以用到老師從來不講解。當這些學生出了社會,赫然發現許許多多的任務要去解決,但~~~不知如何下手。
當然我們的工程師還有一個大問題也跟美國一樣,我們往往太過於專注於自己的領域,例如~~一個軟體工程師只對程式語言的議題感到興趣,其他的學識往往都一無興趣。但假設今天出現一個工作,希望工程師去完成一個應用程式,重點不在於軟體怎麼寫,而在於~~這個軟體怎麼運作,其中涉及的不是程式語言的範疇,而是~~~這個應該程式的know-how。
工作中常常遇到一些學校剛畢業的學生,在學校的時候成績一把罩,但當面對一個沒有標準答案的工作任務~~~往往傻眼不知如何下手,他們常常需要你告訴他們怎麼開始寫,其實很多東西學校都有教過,只是不知道為何當面對到的時候,一定要有人跟他們說『這裡應該可以用liXXXXXnked list解決』『scanline演算法可以處理這一段』...,我覺得如何把學生所學的東西實際貫通才是最為重要的。
台灣的科技產業歷經了大量代工的年代,因此很多優秀的畢業生,一畢業之後進到大公司往往就是開始做一些機械性重複的動作,這些優秀的學生在歷經多年這樣的職場訓練,往往也喪失了邏輯的處理能力。記得多年前有學者呼籲企業界讓員工開始創新,否則台灣的資訊產業將停留在代工、製程改善的死胡同。或許這才是目前台灣科技產業最大的問題,為何大量裁撤掉工程師,因為~~~這些工程師對公司來說只是螺絲釘,具有標準規格,之後在買就好,這樣子代工模式思維其實大量存在我們許多科技產業。
因此,如果要解決高學歷失業的問題,如何改變科技產業結構比讓畢業生重新受技能訓練重要,畢竟要讓市場上產生高學歷學生的需求比改變這些學生去符合現在產業來的長遠。其實現在高學歷失業的問題也凸顯一個有趣的問題是,我們這個社會真的需要這麼多大學生嗎?或是說需要這麼多科技相關領域的高知識份子?資訊產業對於台灣來說有一種磁吸作用,它往往讓其他較有未來的產業的社會資源被排擠,所以或許少一些資訊博士,多一些文化博士、音樂人才、農業專家.....會對這個社會產生比較正面的改變。
與其花許多的錢發放教育券,我倒是覺得認真思考我們的教育政策來的充實些。
Monday, January 12, 2009
Gtk+上使用stack
Gtk+是在linux上面使用十分頻繁的GUI library,許許多多的project都以它為front-end的介面程式,最近使用Gtk+的時候,產生了一個簡單的需求:Stack,但找了一下glib裡面發現卻沒有stack的支援,看來要自己去寫。
不過~~我真的很懶,於是我看了一下,恩~~用linked-list來幫我完成這項工作吧。
首先,當然你必須宣告一個glib的linked-list,你可以宣告成全域變數或是在每一個push與pop的參數列將它傳入,當然用參數比較具有彈性,這個stack可以到處使用,我這邊的stack只有一個地方需要使用,於是~~我簡單的把他宣告成全域變數
GList *MyStackList = NULL;
一個stack的資料結構其實很簡單,就是資料後進先出,它擁有兩個簡單的介面:push與pop,我們用GList來幫我們簡化這些程式碼。首先,push的實做:
void _my_stack_puch(struct _my_own_data *data)
{
struct _my_own_data *ptr = (struct _my_own_data *)g_malloc(sizeof(struct _my_own_data));
ptr->data1 = data->data1;
.....其他你的資料需要複製的部份,當然~~最簡單就是memcpy.......
MyStackList = g_list_prepend(MyStackList, (gpointer)ptr);
}
每一次插入一個元素我就宣告一個然後放置在linked-list的前端。簡單吧,再來就是pop的實做了:
gboolean _my_stack_pop(struct _my_own_data *data)
{
struct _my_own_data *ptr;
if (MyStackList == NULL)
return FALSE;
ptr = (struct _my_own_data *)g_list_nth_data(MyStackList, 0);
if (ptr == NULL)
return FALSE;
data->data1 = ptr->data1;
.....其他你的資料需要複製的部份.......
g_free(ptr);
MyStackList = g_list_delete_link(MyStackList, MyStackList);
return TRUE;
}
只是GList的刪除link的動作,不過要記得這個我們在pop分配的記憶體要記得刪除這個link前先釋放掉。
這樣就簡單的完成一個用GList實做出來的stack可以使用,你當然可以再寫一個清除所有stack裡面元素的function,這很簡單我就不寫了。簡單的利用別人寫好的程式,我想這才是使用open source最好的方式吧。
不過~~我真的很懶,於是我看了一下,恩~~用linked-list來幫我完成這項工作吧。
首先,當然你必須宣告一個glib的linked-list,你可以宣告成全域變數或是在每一個push與pop的參數列將它傳入,當然用參數比較具有彈性,這個stack可以到處使用,我這邊的stack只有一個地方需要使用,於是~~我簡單的把他宣告成全域變數
GList *MyStackList = NULL;
一個stack的資料結構其實很簡單,就是資料後進先出,它擁有兩個簡單的介面:push與pop,我們用GList來幫我們簡化這些程式碼。首先,push的實做:
void _my_stack_puch(struct _my_own_data *data)
{
struct _my_own_data *ptr = (struct _my_own_data *)g_malloc(sizeof(struct _my_own_data));
ptr->data1 = data->data1;
.....其他你的資料需要複製的部份,當然~~最簡單就是memcpy.......
MyStackList = g_list_prepend(MyStackList, (gpointer)ptr);
}
每一次插入一個元素我就宣告一個然後放置在linked-list的前端。簡單吧,再來就是pop的實做了:
gboolean _my_stack_pop(struct _my_own_data *data)
{
struct _my_own_data *ptr;
if (MyStackList == NULL)
return FALSE;
ptr = (struct _my_own_data *)g_list_nth_data(MyStackList, 0);
if (ptr == NULL)
return FALSE;
data->data1 = ptr->data1;
.....其他你的資料需要複製的部份.......
g_free(ptr);
MyStackList = g_list_delete_link(MyStackList, MyStackList);
return TRUE;
}
只是GList的刪除link的動作,不過要記得這個我們在pop分配的記憶體要記得刪除這個link前先釋放掉。
這樣就簡單的完成一個用GList實做出來的stack可以使用,你當然可以再寫一個清除所有stack裡面元素的function,這很簡單我就不寫了。簡單的利用別人寫好的程式,我想這才是使用open source最好的方式吧。
Thursday, December 18, 2008
不告訴別人~還是偷
不管到哪一個工作,總是會有一個現象,主管要求你『偷』東西。
自從open source的概念興盛於這個世界後,你隨便上網都可以找到一大推不用錢又好用的軟體,很多甚至連程式原始碼都給你下載,當然使用上不需要付錢,但~~要求你必須承認你使用人家的軟體。台灣(或許是世界上都這樣吧~~我只是一個台灣土包子工程師)的很多公司都有一個不好的文化:喜歡拿open source的project來更改一下,然後開始號稱自己的研發能力很強,產品很快就可以做出來。
記得以前一個業務的朋友跟我說『我們可以找到這些project來改也是我們的實力呀』,這話其實聽了很悲哀,因為這跟實力一點關係都沒有,這是一種基本的誠實問題。工程師通常會面臨一個嚴重的挑戰,現在的老闆通常知道有open source這種東西(儘管他們自己都用付費軟體~~歐,原來~~沒付費呀~~ㄏㄏ),所以老闆通常會給工程師一個難題:『你拿這些來改很快可以有產品,不然你同樣時間寫出來我就不管』。因此~~軟體工程師開始墮落、開始閉上眼睛。
其實長久以來慢慢的發現這些偷來的專案慢慢的也會消失,因為主要是別人的『智慧』,除非你願意花時間完整去了解整個程式,否則只是一種應付的心態,自然遇到後期的困難越來越多,也就越凸顯對於程式的無知,而後期的時間壓力更大。當然我不否認現在很多企業跟open source合作的很好,也都儘量遵守open source license的規範,但我們也必須承認的是,依然有許多公司會用偷的。(至少我就遇到很多間)
今天老闆還是要求我去找一個軟體來偷放在我們的機器上,我需要找一個類似小畫家的軟體,其實根本上我不覺得這種軟體在我們小小的3吋顯示螢幕上有何用處(每個icon都已經小到要有很準確的螢幕點取能力~~ㄏㄏ),當然老闆想要的原因也很簡單~~因為競爭對手有。這樣的開發心態其實存在很多的專案,記得看過使用者介面設計的文章有提過:不要在乎使用者說的需求,要去觀察使用者應該如何完成工作。
在這樣充滿各種eye-candy的產品的時代,使用者已經習慣要求各種美麗的第一印象,但是往往買完才會發現自己根本用不到這些功能,更慘的是~~有時候還會發現自己要的功能不足。所以一個負責任的產品設計應該著重於使用者的操作,而不是使用者的眼睛,當然設計者也應該避免寵物理論(就是把使用者當成寵物,覺得你可以訓練他的操作行為),重點是研究使用者如何完成他的工作,然後設計出符合這樣操作流程的好用介面。
我們習慣告訴小孩~~不能偷拿別人的東西,但~~~~這樣的法則似乎不存在於商業的世界。
自從open source的概念興盛於這個世界後,你隨便上網都可以找到一大推不用錢又好用的軟體,很多甚至連程式原始碼都給你下載,當然使用上不需要付錢,但~~要求你必須承認你使用人家的軟體。台灣(或許是世界上都這樣吧~~我只是一個台灣土包子工程師)的很多公司都有一個不好的文化:喜歡拿open source的project來更改一下,然後開始號稱自己的研發能力很強,產品很快就可以做出來。
記得以前一個業務的朋友跟我說『我們可以找到這些project來改也是我們的實力呀』,這話其實聽了很悲哀,因為這跟實力一點關係都沒有,這是一種基本的誠實問題。工程師通常會面臨一個嚴重的挑戰,現在的老闆通常知道有open source這種東西(儘管他們自己都用付費軟體~~歐,原來~~沒付費呀~~ㄏㄏ),所以老闆通常會給工程師一個難題:『你拿這些來改很快可以有產品,不然你同樣時間寫出來我就不管』。因此~~軟體工程師開始墮落、開始閉上眼睛。
其實長久以來慢慢的發現這些偷來的專案慢慢的也會消失,因為主要是別人的『智慧』,除非你願意花時間完整去了解整個程式,否則只是一種應付的心態,自然遇到後期的困難越來越多,也就越凸顯對於程式的無知,而後期的時間壓力更大。當然我不否認現在很多企業跟open source合作的很好,也都儘量遵守open source license的規範,但我們也必須承認的是,依然有許多公司會用偷的。(至少我就遇到很多間)
今天老闆還是要求我去找一個軟體來偷放在我們的機器上,我需要找一個類似小畫家的軟體,其實根本上我不覺得這種軟體在我們小小的3吋顯示螢幕上有何用處(每個icon都已經小到要有很準確的螢幕點取能力~~ㄏㄏ),當然老闆想要的原因也很簡單~~因為競爭對手有。這樣的開發心態其實存在很多的專案,記得看過使用者介面設計的文章有提過:不要在乎使用者說的需求,要去觀察使用者應該如何完成工作。
在這樣充滿各種eye-candy的產品的時代,使用者已經習慣要求各種美麗的第一印象,但是往往買完才會發現自己根本用不到這些功能,更慘的是~~有時候還會發現自己要的功能不足。所以一個負責任的產品設計應該著重於使用者的操作,而不是使用者的眼睛,當然設計者也應該避免寵物理論(就是把使用者當成寵物,覺得你可以訓練他的操作行為),重點是研究使用者如何完成他的工作,然後設計出符合這樣操作流程的好用介面。
我們習慣告訴小孩~~不能偷拿別人的東西,但~~~~這樣的法則似乎不存在於商業的世界。
Wednesday, December 17, 2008
工程師的創世紀
當軟體工程師久了慢慢的也接觸過不少專案,有一些專案是從頭開始的,通常一個從頭開始的專案會不會成功,一開始就看得出端倪。
或許現在視覺化的工具太多,因此很多工程師都每天忙著畫使用者介面,當然一個程式要有互動性,使用者介面是很重要的,但~~它該是一個專案的創世紀篇嗎?不少時候專案領導者在開始新專案的時候,都是要求『我畫面上要有三個按鈕』、『這裡的圖如果會跳動一定很炫』、『這個字型應該用美麗一點的』...等等。發現了嗎,一個專案由視覺開始,這~~不好嗎?
我相信一個程式他的使用者介面是一個小小的部份,通常那只是展現的問題,所以每次當面試的時候有人問說『那個OOXX的library你有多熟』,恩~~我都會回答,可以上網查跟看書就很熟,不行~~就不熟。其實大多數的圖形介面library都做的很容易上手,當然你要給它弄的不像原來library的呈現就要花功夫,但~~那也是你自找的。
用使用者介面當成思考的起點通常有一個大麻煩,就是實際內部運作的程式碼常常會跟圖形library綁在一起怎麼也切不開,當然如果你對一個GUI library至死不渝,那我沒有意見,但如果要你換一個GUI~~你會不會想哭。很多Open Source的程式都可以有不同GUI的支援,因為他們通常把程式運算與程式呈現分的很清楚,這樣容易讓自己的程式那多樣化的作業系統(如linux)執行無誤。會這樣設計的程式,我相信一開始不會用使用者介面當成思考的起點,因為~~那不重要,重要的是這程式要完成哪一種任務。
商用產品通常用介面著手,因為商業人士了解到外觀是觸動你『想要』的重要因素,但滿足你『需要』的要素卻是內部的功能,因此站在一個業務的立場,當然希望外觀越美越好,但~~從工程的角度出發,是否該從程式架構與功能需求著手呢?
我當然不是說美麗的UI不重要,但應該仔細想想的是一個成功的產品一定具有人性化的操作方式(我是說操作方式,不是美麗的圖示),當然也會具有可愛讓人愛不釋手的介面,但營造這個可愛的介面前應該由程式的行為著手思考,有了行為~~再去分配外觀。
多年了我還是不習慣台灣很多軟體設計都先寫UI,在一個Do-nothing的UI上再去開發程式,這樣的下場通常都是讓程式越來越混亂,不過好像常常都是這樣,或許我們的主管們也必須在看到畫面後才能開始思考功能吧~~~這~~我有點不能理解。
或許現在視覺化的工具太多,因此很多工程師都每天忙著畫使用者介面,當然一個程式要有互動性,使用者介面是很重要的,但~~它該是一個專案的創世紀篇嗎?不少時候專案領導者在開始新專案的時候,都是要求『我畫面上要有三個按鈕』、『這裡的圖如果會跳動一定很炫』、『這個字型應該用美麗一點的』...等等。發現了嗎,一個專案由視覺開始,這~~不好嗎?
我相信一個程式他的使用者介面是一個小小的部份,通常那只是展現的問題,所以每次當面試的時候有人問說『那個OOXX的library你有多熟』,恩~~我都會回答,可以上網查跟看書就很熟,不行~~就不熟。其實大多數的圖形介面library都做的很容易上手,當然你要給它弄的不像原來library的呈現就要花功夫,但~~那也是你自找的。
用使用者介面當成思考的起點通常有一個大麻煩,就是實際內部運作的程式碼常常會跟圖形library綁在一起怎麼也切不開,當然如果你對一個GUI library至死不渝,那我沒有意見,但如果要你換一個GUI~~你會不會想哭。很多Open Source的程式都可以有不同GUI的支援,因為他們通常把程式運算與程式呈現分的很清楚,這樣容易讓自己的程式那多樣化的作業系統(如linux)執行無誤。會這樣設計的程式,我相信一開始不會用使用者介面當成思考的起點,因為~~那不重要,重要的是這程式要完成哪一種任務。
商用產品通常用介面著手,因為商業人士了解到外觀是觸動你『想要』的重要因素,但滿足你『需要』的要素卻是內部的功能,因此站在一個業務的立場,當然希望外觀越美越好,但~~從工程的角度出發,是否該從程式架構與功能需求著手呢?
我當然不是說美麗的UI不重要,但應該仔細想想的是一個成功的產品一定具有人性化的操作方式(我是說操作方式,不是美麗的圖示),當然也會具有可愛讓人愛不釋手的介面,但營造這個可愛的介面前應該由程式的行為著手思考,有了行為~~再去分配外觀。
多年了我還是不習慣台灣很多軟體設計都先寫UI,在一個Do-nothing的UI上再去開發程式,這樣的下場通常都是讓程式越來越混亂,不過好像常常都是這樣,或許我們的主管們也必須在看到畫面後才能開始思考功能吧~~~這~~我有點不能理解。
Monday, December 15, 2008
講或不講~~~思考中
每次我對於一個開發linux軟體的公司,對於員工使用linux當成平台很困擾的狀況,都會感到十分詭異。
或許因為這些主管本身都是使用windows的作業環境,因此說實話他們對於linux很不熟悉,但~~他要指導工程師如何寫linux的程式,當然對於不同的環境每個人的編譯方式自然不同,反正最終還是要進到linux環境下面執行。對於習慣在linux下面開發程式的朋友應該很熟悉 autoconf與automake這些工具,他讓你可以快速的產生一個編譯環境,當然~~他不是圖形化的工具。
主管對於我的程式裡面有這些autotool產生的檔案非常不以為然,他今天下了指導旗,他覺得這些『不必要』的檔案不應該存在專案中,我想或許他沒有寫過具有大量程式檔的專案經驗吧,當你的程式檔案很多的時候,自己一行一行編寫Makefile可是一大通苦的差事。上次有跟他解釋過這些檔案並不是『無用的』,不過~~看來他無法接受,恩~~好吧~~對他無用就是無用。
我想這些MS體系出身的工程師,對於非MS的編譯環境自然感到十分排斥(其實跟我不習慣MS的環境是一樣的道理),但至少必須承認不同的方式也是一種方式,而不是~~~非我族類者殺之。
現在的我有兩個選項,一個是每次送程式碼給他的時候就自己辛苦點把這些設定檔刪除不要讓他看到,一個是繼續跟他說明,不過這會讓我想到一些過往的經驗,通常我的下場會是~~~此員工頑劣固執難相處。所以~~或許我會選擇就隨波逐流吧,反正,就是一個寫程式的小角色,高層~~~總是有讓人摸不透的思考的。
或許因為這些主管本身都是使用windows的作業環境,因此說實話他們對於linux很不熟悉,但~~他要指導工程師如何寫linux的程式,當然對於不同的環境每個人的編譯方式自然不同,反正最終還是要進到linux環境下面執行。對於習慣在linux下面開發程式的朋友應該很熟悉 autoconf與automake這些工具,他讓你可以快速的產生一個編譯環境,當然~~他不是圖形化的工具。
主管對於我的程式裡面有這些autotool產生的檔案非常不以為然,他今天下了指導旗,他覺得這些『不必要』的檔案不應該存在專案中,我想或許他沒有寫過具有大量程式檔的專案經驗吧,當你的程式檔案很多的時候,自己一行一行編寫Makefile可是一大通苦的差事。上次有跟他解釋過這些檔案並不是『無用的』,不過~~看來他無法接受,恩~~好吧~~對他無用就是無用。
我想這些MS體系出身的工程師,對於非MS的編譯環境自然感到十分排斥(其實跟我不習慣MS的環境是一樣的道理),但至少必須承認不同的方式也是一種方式,而不是~~~非我族類者殺之。
現在的我有兩個選項,一個是每次送程式碼給他的時候就自己辛苦點把這些設定檔刪除不要讓他看到,一個是繼續跟他說明,不過這會讓我想到一些過往的經驗,通常我的下場會是~~~此員工頑劣固執難相處。所以~~或許我會選擇就隨波逐流吧,反正,就是一個寫程式的小角色,高層~~~總是有讓人摸不透的思考的。
Monday, April 30, 2007
空間判斷小問題(一)
最近同事的工作上出現了一個小小的問題與主管討論,這是一個關於空間的判定問題,簡單的說就是:今天有一個圖形上面充滿了許多的區域,也就是說一個有許多polygon的圖形,當使用者用滑鼠點選螢幕的一個位置的時候,程式必須決定使用者選取了哪一個位置而做出相對應的反應。這樣的問題在graph裡面算是一個簡單的小問題,當然也可以不用graph的方式解決,後來同事似乎用顏色判別來解決(每一區用一個顏色代表),但是當我們必須使每一區域都一樣的顏色或是顏色會改變時,就得真正的去面對空間的問題.....繼續閱讀
Wednesday, April 11, 2007
Google notebook
Thursday, March 22, 2007
AGG: Anti-Grain Geometry
最近在學習AGG這個2D圖形library,覺得他真的很棒
反鋸齒的展示2D圖形在向量圖中的表現關係到整體感覺
AGG在這個方面表現的十分出色
AGG是一個用C++來實作的library,他用了大量的template來作泛型化設計
因此它的使用十分具有彈性
在跨平台上面他也是很棒
幾乎所有的code都是跨平台的
惟一與平台有關的是在OS event與drawing上面
因此他利用了一個類別稱為platform_support來處理與OS相關的
在platform_support裏面的platform_specific他只宣告它是一個類別
所有跟OS相關的資料結構妳可以宣告在這個類別中
因此將AGG放進目前不支援的drwaing library是非常簡單的
AGG目前有X11、SDL、Mac與win32的支援
我實作了DirectFB的支援,還挺容易的
AGG自己有一套control系統,現在已經有一些基本的control
譬如check box與slide-bar等等的控制元件
在字型顯示方面,他有提供freetype的支援
因此在文字顯示也不是問題
我試過utf-8的中文顯示很棒
但是在轉換unicode碼的部份妳要自己實作
不過這部份並不困難就是
結合AGG+DirectFB+SVG
或許可以有一些有趣的project可以玩玩歐
反鋸齒的展示2D圖形在向量圖中的表現關係到整體感覺
AGG在這個方面表現的十分出色
AGG是一個用C++來實作的library,他用了大量的template來作泛型化設計
因此它的使用十分具有彈性
在跨平台上面他也是很棒
幾乎所有的code都是跨平台的
惟一與平台有關的是在OS event與drawing上面
因此他利用了一個類別稱為platform_support來處理與OS相關的
在platform_support裏面的platform_specific他只宣告它是一個類別
所有跟OS相關的資料結構妳可以宣告在這個類別中
因此將AGG放進目前不支援的drwaing library是非常簡單的
AGG目前有X11、SDL、Mac與win32的支援
我實作了DirectFB的支援,還挺容易的
AGG自己有一套control系統,現在已經有一些基本的control
譬如check box與slide-bar等等的控制元件
在字型顯示方面,他有提供freetype的支援
因此在文字顯示也不是問題
我試過utf-8的中文顯示很棒
但是在轉換unicode碼的部份妳要自己實作
不過這部份並不困難就是
結合AGG+DirectFB+SVG
或許可以有一些有趣的project可以玩玩歐
Wednesday, March 14, 2007
淺談OpenSER(三)
在整個openser.cfg中最重要的大概就是你怎麼處理route裏面的規則,這裡給你做一個簡單的示範。
通常一開始會先檢查SIP message是否是合法的,因此我們對SIP message的forward header與message長度作檢查.......繼續閱讀
Thursday, March 01, 2007
淺談OpenSER(二)
如果妳打開openser.cfg這個檔案,第1眼印象妳可能會以為它是一個script檔案,其實這樣說也沒有不對,但是之前說過這個script其實是lex的輸入文檔,因此妳必須滿足它的字彙規則,讓我們先簡單看一下這個檔案。
這個設定OpenSER的動作檔案簡單可以分成4個部份,分別如下......繼續閱讀
Tuesday, February 13, 2007
淺談OpenSER(一)
VoIP這種應用已經常識了很多年,卻似乎一直沒有太大的成果,當然這涉及到很多的問題,不過以SIP為基礎的原則也越來越確定(好啦,我知道妳用 Skype)。很多人對於VoIP總是感覺像是高不可攀的技術,但其實它並不如此的困難,尤其是有了自由軟體世界的努力,很多Project都可以讓妳輕 鬆的完成你的VoIP規劃。
當然VoIP是一個很廣泛的稱乎,舉凡用網路即時傳遞交換語音訊號其實都可以稱為Voice over Internet,但是VoIP還必須要涉入一些電信的領域,也就是signaling的動作。 就如同PSTN一般,VoIP也需要一個傳遞訊號的機制來建立通訊的兩端,SIP便負責了這件工作。一個SIP的register server可以讓妳每一個SIP client來交換訊息,當你要打電話給另一個朋友,在網路上妳必須要能先找到他,也就是對方的網路位置,但是當你的網路位置會改變的時候,一個可以記錄 你的網路位置的SIP register server便可以發揮功能.....繼續閱讀Friday, January 26, 2007
OpenSSL 0.9.8
之前提過使用OpenSSL的方式
OpenSSL 0.9.7版本的方式在0.9.8d並不能正常運作
後來發現是SSL_library_init()與OpenSSL_add_all_algorithms()的問題
不要在使用這兩個function,請使用
SSleay_add_ssl_algorithms()
來代替
換成OpenSSL0.9.8d後可以把我搞慘了呀....ㄏㄏ
OpenSSL 0.9.7版本的方式在0.9.8d並不能正常運作
後來發現是SSL_library_init()與OpenSSL_add_all_algorithms()的問題
不要在使用這兩個function,請使用
SSleay_add_ssl_algorithms()
來代替
換成OpenSSL0.9.8d後可以把我搞慘了呀....ㄏㄏ
Thursday, January 25, 2007
Gentoo 2006.1 stage 1
好久沒有安裝linux了
最近有了一台新的硬體
想說給他裝一下Gentoo
於是乎抓了2006.1的install CD image後
開始從stage1給他安裝
(好啦...我知道我很閒...時間多)
發現2006.1版本stage1有個問題
當我用bootstrap.sh完要emerge system後
發生perl的module有些問題
看到是ExtUtils:MakeMaker:Config.pm的問題
對於perl我是非常陌生的...
但是當我
emerge unmerge perl
emerge perl
一切就回到正常了
看來是stage1的tar ball裏面有些問題
不過....小問題....這個世界又多一台linux box了...ㄏㄏ
最近有了一台新的硬體
想說給他裝一下Gentoo
於是乎抓了2006.1的install CD image後
開始從stage1給他安裝
(好啦...我知道我很閒...時間多)
發現2006.1版本stage1有個問題
當我用bootstrap.sh完要emerge system後
發生perl的module有些問題
看到是ExtUtils:MakeMaker:Config.pm的問題
對於perl我是非常陌生的...
但是當我
emerge unmerge perl
emerge perl
一切就回到正常了
看來是stage1的tar ball裏面有些問題
不過....小問題....這個世界又多一台linux box了...ㄏㄏ
Wednesday, January 17, 2007
State Design Pattern
以前寫程式的時候大多數寫一些具有互動UI的程式,因此所有的程式動作都決定於某一個event的發生,不過在很多的情況知下卻需要程式自己決定下 一步的動作,這種需求在自動化的設備中更是重要。以前唸書時相信大家都唸過finite state machine這樣的觀念,自己那個時候還真的是有念.....還真的沒有懂.....因為不知道如何應用....ㄏㄏ。
慢慢在工作上遇到 一些要求後才開始體認state machine是很重要的,但是當你用條件判斷式去決定下一個動作來實作state machine的時候,你會面臨一個問題:上面的長官對於程式的行為很喜歡改來改去....ㄏㄏ。因此每每加上一個新的state的時候都會搞得人揚馬翻 的,每次遇到程式的彈性不夠的時候,就會想起C++的可愛。在之前看Design Pattern的書的時候,曾經看到一種design pattern的設計:State。這次就讓我來試試實做一下吧....繼續閱讀Saturday, January 06, 2007
Subscribe to:
Posts (Atom)


