教育券

記得不久之前，在美國舉辦的國際電子元件會議上面，美國的學者呼籲美國政府改善工程師的教育，以免讓美國的工程能力慢慢衰退，其中他們建議要培養T型人材，也就是除了在工程相關領域的研究之外，也要延伸到數學、科學甚至美學的領域，構成一種深入專業領域的廣泛應用人才。當然還有創造力，對於快速以商業力量獲利的美國企業，慢慢的把重心放在商業經營而缺少創新能量。

對照現在政府採取教育券的模式，美國工程界的作法有何不同呢？首先，我們要改善的是基本教育面向，而不是技術。如果你看看這次政府官員在講這個政策，其實很大多數都是採用『技術訓練、快速上工』的思維，當然這凸顯了一個台灣教育體制的問題～～缺少實做精神。但我們應該如何改變這些狀況確實不應該由『技術訓練』著手，對於學校教育中能夠加強的應該是實際的應用思考。

簡單來說，當我們在學校學習許多的電腦程式演算法的時候，老師常常講解理論，然後把重點放在每個演算法的效能評估上面（就是big-O函數～～ㄏㄏ），當然這應該要了解，只是問題在於除了這一個部份，現有這麼多學習的演算法，有哪些地方可以用到老師從來不講解。當這些學生出了社會，赫然發現許許多多的任務要去解決，但～～～不知如何下手。

當然我們的工程師還有一個大問題也跟美國一樣，我們往往太過於專注於自己的領域，例如～～一個軟體工程師只對程式語言的議題感到興趣，其他的學識往往都一無興趣。但假設今天出現一個工作，希望工程師去完成一個應用程式，重點不在於軟體怎麼寫，而在於～～這個軟體怎麼運作，其中涉及的不是程式語言的範疇，而是～～～這個應該程式的know-how。

工作中常常遇到一些學校剛畢業的學生，在學校的時候成績一把罩，但當面對一個沒有標準答案的工作任務～～～往往傻眼不知如何下手，他們常常需要你告訴他們怎麼開始寫，其實很多東西學校都有教過，只是不知道為何當面對到的時候，一定要有人跟他們說『這裡應該可以用liXXXXXnked list解決』『scanline演算法可以處理這一段』...，我覺得如何把學生所學的東西實際貫通才是最為重要的。

台灣的科技產業歷經了大量代工的年代，因此很多優秀的畢業生，一畢業之後進到大公司往往就是開始做一些機械性重複的動作，這些優秀的學生在歷經多年這樣的職場訓練，往往也喪失了邏輯的處理能力。記得多年前有學者呼籲企業界讓員工開始創新，否則台灣的資訊產業將停留在代工、製程改善的死胡同。或許這才是目前台灣科技產業最大的問題，為何大量裁撤掉工程師，因為～～～這些工程師對公司來說只是螺絲釘，具有標準規格，之後在買就好，這樣子代工模式思維其實大量存在我們許多科技產業。

因此，如果要解決高學歷失業的問題，如何改變科技產業結構比讓畢業生重新受技能訓練重要，畢竟要讓市場上產生高學歷學生的需求比改變這些學生去符合現在產業來的長遠。其實現在高學歷失業的問題也凸顯一個有趣的問題是，我們這個社會真的需要這麼多大學生嗎？或是說需要這麼多科技相關領域的高知識份子？資訊產業對於台灣來說有一種磁吸作用，它往往讓其他較有未來的產業的社會資源被排擠，所以或許少一些資訊博士，多一些文化博士、音樂人才、農業專家.....會對這個社會產生比較正面的改變。

與其花許多的錢發放教育券，我倒是覺得認真思考我們的教育政策來的充實些。

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最好的方式吧。

不告訴別人～還是偷

不管到哪一個工作，總是會有一個現象，主管要求你『偷』東西。

自從open source的概念興盛於這個世界後，你隨便上網都可以找到一大推不用錢又好用的軟體，很多甚至連程式原始碼都給你下載，當然使用上不需要付錢，但～～要求你必須承認你使用人家的軟體。台灣（或許是世界上都這樣吧～～我只是一個台灣土包子工程師）的很多公司都有一個不好的文化：喜歡拿open source的project來更改一下，然後開始號稱自己的研發能力很強，產品很快就可以做出來。

記得以前一個業務的朋友跟我說『我們可以找到這些project來改也是我們的實力呀』，這話其實聽了很悲哀，因為這跟實力一點關係都沒有，這是一種基本的誠實問題。工程師通常會面臨一個嚴重的挑戰，現在的老闆通常知道有open source這種東西（儘管他們自己都用付費軟體～～歐，原來～～沒付費呀～～ㄏㄏ），所以老闆通常會給工程師一個難題：『你拿這些來改很快可以有產品，不然你同樣時間寫出來我就不管』。因此～～軟體工程師開始墮落、開始閉上眼睛。

其實長久以來慢慢的發現這些偷來的專案慢慢的也會消失，因為主要是別人的『智慧』，除非你願意花時間完整去了解整個程式，否則只是一種應付的心態，自然遇到後期的困難越來越多，也就越凸顯對於程式的無知，而後期的時間壓力更大。當然我不否認現在很多企業跟open source合作的很好，也都儘量遵守open source license的規範，但我們也必須承認的是，依然有許多公司會用偷的。（至少我就遇到很多間）

今天老闆還是要求我去找一個軟體來偷放在我們的機器上，我需要找一個類似小畫家的軟體，其實根本上我不覺得這種軟體在我們小小的3吋顯示螢幕上有何用處（每個icon都已經小到要有很準確的螢幕點取能力～～ㄏㄏ），當然老闆想要的原因也很簡單～～因為競爭對手有。這樣的開發心態其實存在很多的專案，記得看過使用者介面設計的文章有提過：不要在乎使用者說的需求，要去觀察使用者應該如何完成工作。

在這樣充滿各種eye-candy的產品的時代，使用者已經習慣要求各種美麗的第一印象，但是往往買完才會發現自己根本用不到這些功能，更慘的是～～有時候還會發現自己要的功能不足。所以一個負責任的產品設計應該著重於使用者的操作，而不是使用者的眼睛，當然設計者也應該避免寵物理論（就是把使用者當成寵物，覺得你可以訓練他的操作行為），重點是研究使用者如何完成他的工作，然後設計出符合這樣操作流程的好用介面。

我們習慣告訴小孩～～不能偷拿別人的東西，但～～～～這樣的法則似乎不存在於商業的世界。

工程師的創世紀

當軟體工程師久了慢慢的也接觸過不少專案，有一些專案是從頭開始的，通常一個從頭開始的專案會不會成功，一開始就看得出端倪。

或許現在視覺化的工具太多，因此很多工程師都每天忙著畫使用者介面，當然一個程式要有互動性，使用者介面是很重要的，但～～它該是一個專案的創世紀篇嗎？不少時候專案領導者在開始新專案的時候，都是要求『我畫面上要有三個按鈕』、『這裡的圖如果會跳動一定很炫』、『這個字型應該用美麗一點的』...等等。發現了嗎，一個專案由視覺開始，這～～不好嗎？

我相信一個程式他的使用者介面是一個小小的部份，通常那只是展現的問題，所以每次當面試的時候有人問說『那個OOXX的library你有多熟』，恩～～我都會回答，可以上網查跟看書就很熟，不行～～就不熟。其實大多數的圖形介面library都做的很容易上手，當然你要給它弄的不像原來library的呈現就要花功夫，但～～那也是你自找的。

用使用者介面當成思考的起點通常有一個大麻煩，就是實際內部運作的程式碼常常會跟圖形library綁在一起怎麼也切不開，當然如果你對一個GUI library至死不渝，那我沒有意見，但如果要你換一個GUI～～你會不會想哭。很多Open Source的程式都可以有不同GUI的支援，因為他們通常把程式運算與程式呈現分的很清楚，這樣容易讓自己的程式那多樣化的作業系統（如linux）執行無誤。會這樣設計的程式，我相信一開始不會用使用者介面當成思考的起點，因為～～那不重要，重要的是這程式要完成哪一種任務。

商用產品通常用介面著手，因為商業人士了解到外觀是觸動你『想要』的重要因素，但滿足你『需要』的要素卻是內部的功能，因此站在一個業務的立場，當然希望外觀越美越好，但～～從工程的角度出發，是否該從程式架構與功能需求著手呢？

我當然不是說美麗的UI不重要，但應該仔細想想的是一個成功的產品一定具有人性化的操作方式（我是說操作方式，不是美麗的圖示），當然也會具有可愛讓人愛不釋手的介面，但營造這個可愛的介面前應該由程式的行為著手思考，有了行為～～再去分配外觀。

多年了我還是不習慣台灣很多軟體設計都先寫UI，在一個Do-nothing的UI上再去開發程式，這樣的下場通常都是讓程式越來越混亂，不過好像常常都是這樣，或許我們的主管們也必須在看到畫面後才能開始思考功能吧～～～這～～我有點不能理解。

講或不講～～～思考中

每次我對於一個開發linux軟體的公司，對於員工使用linux當成平台很困擾的狀況，都會感到十分詭異。

或許因為這些主管本身都是使用windows的作業環境，因此說實話他們對於linux很不熟悉，但～～他要指導工程師如何寫linux的程式，當然對於不同的環境每個人的編譯方式自然不同，反正最終還是要進到linux環境下面執行。對於習慣在linux下面開發程式的朋友應該很熟悉 autoconf與automake這些工具，他讓你可以快速的產生一個編譯環境，當然～～他不是圖形化的工具。

主管對於我的程式裡面有這些autotool產生的檔案非常不以為然，他今天下了指導旗，他覺得這些『不必要』的檔案不應該存在專案中，我想或許他沒有寫過具有大量程式檔的專案經驗吧，當你的程式檔案很多的時候，自己一行一行編寫Makefile可是一大通苦的差事。上次有跟他解釋過這些檔案並不是『無用的』，不過～～看來他無法接受，恩～～好吧～～對他無用就是無用。

我想這些MS體系出身的工程師，對於非MS的編譯環境自然感到十分排斥（其實跟我不習慣MS的環境是一樣的道理），但至少必須承認不同的方式也是一種方式，而不是～～～非我族類者殺之。

現在的我有兩個選項，一個是每次送程式碼給他的時候就自己辛苦點把這些設定檔刪除不要讓他看到，一個是繼續跟他說明，不過這會讓我想到一些過往的經驗，通常我的下場會是～～～此員工頑劣固執難相處。所以～～或許我會選擇就隨波逐流吧，反正，就是一個寫程式的小角色，高層～～～總是有讓人摸不透的思考的。