成就更好的自己

成就更好的自己

學習 / 生活 / 體驗

Linux

用Vim來分析程式碼

在比較大型的專案之中,如果只靠Vim本身的find, grep是不太夠的,因此,我們需要借助一些工具,可以讓我們更方便的來分析程式碼。 首先,先準備以下三樣: * Taglist:在你的Vim呈現出所有變數、函式列表(這是個Vim Script) * ctags:會先掃過你所有的程式,並且對每個函式名稱自動做標籤 * cscope:補上ctags沒有的功能(檔案間的跳躍,並且加上變數的支援) 安裝方式: 1. 到此下載Vim Script,然後解壓縮到~/.vim之中 2. 透過套件管理員安裝ctags與cscope,以Mac為例:sudo port install ctags cscope 在使用之前,我們必須先讓ctags與cscope掃過專案底下的所有程式檔: $ cd ~/PROJECT $ ctags * $ cscope -bR 接著我們就可以開始來Trace Code了~ * :Tlist 打開Tag List列表,可以透過" control w+
1 min read
Essay

[轉錄] 為什麼在大公司工作,總是很無聊?

作者: 阮一峰 日期: 2009年6月15日 下面的內容是我在網上看到的。 我沒有找到原作者和出處,但是感覺說得相當有道理。 ================================ 以前,公司都願意找能力強、資格老的人來做研發,有點個人英雄主義在裡面。一個優秀能幹的員工能給公司帶來很大的利益。 但是,凡事都有雙面性。 現在這個社會,人才流動很快。能力強的、聰明的人,雖說給公司帶來過不少利益,但也經常給公司帶來很大的傷害,做幾年就遠走高飛的人太多了。他們的離開給公司造成了很大的缺口,很多地方都要好久才能補上。總之,元氣大傷。 這種情況見得多了,這些大公司就精了。他們發現,不能讓公司太依賴人才,而應該讓人才依賴公司才對頭。管理層的最終作用,就是讓誰離開了都無所謂,公司都能正常運作。所以,他們把各個部門劃分得很細很細,每個人負責的東西很單一。這樣一來,「術業有專攻」,效率上去了,經驗積累了,工作都流程化了。漸漸地,公司的運作流程化了。 結果就是,員工的工作就變得很單調了,沒有太多的創作性在裡面。什麼創意、可靠性、穩定性等都有專人做了,你就只需要拿個小手
2 min read
Essay

做研究!

王汎森《如果讓我重做一次研究生》[原文下載] 研究生應該: * 從接受知識轉換成製造知識,要期許自己的論文有所創新,跟研究所以前的單向接收無法幫助成長 * 大量閱讀 -> 老師提點 -> 通任督二脈 -> 產生興趣 -> 主動學習 -> 習慣養成(良性循環) * 博碩士不是訓練你寫出經典的論文,而是寫出結構嚴謹、論述清楚與言之有物的論文(透過大量閱讀,以及寫作培養此能力) * 形成自己的知識樹:學習要有所取捨,找出自己的主幹(具延展性的題目),再延身旁枝,最後掛上屬於自己的東西(創新) * 跳脫桎梏、精緻思考:conceptualization與跨領域學習 * 責任感與罪惡感 * 設定目標、模範學習、勇於挑戰 MIT * 做研究,要以正確且深厚的理論基礎為出發點,並利用身邊的有限資源,,以最有效率的方式解決問題 * Think with
3 min read
AppEngine

App Engine Tips

一樣是COSCUP重點整理: 首先提到的是Internationalization,在這之前先介紹一下相關名詞(中間數字代表英文字母數) I18N (Internationalization):國際化,把原先只支援英文的程式語言擴展成支援多國語言(也就是解決編碼相關問題) L10N:本地化,將軟體使用語言自動依據使用者所在區域不同而不同 M17N:多語言化,讓軟體可以支援、呈現多國語言 **Tips 1:**在App Engine使用i18n,django有提供一個template可以做到這件事 **Tips 2:**注意 1. 資料存放在何處?(資料是分散式存放的,注意data store id連續性) 2. 有多少processes正在跑?(request次數可能會超過程式可以處理的程度) 3. 超過免費額度了嗎?(30s timeout) 4. 例外處理了嗎?(善用Task Queue) Q&A經典問題「請問你為什麼不付錢?」 (註:這場演講是利用app engine如何完成報名確認信件發送的實例做討論)
1 min read
COSCUP

UI Design Pattern

這COSCUP的演講其實只著重於在Android上,但是我認為可以把它其實可以更為廣泛些 所以我把Android的字眼拿掉,做些適度修改 以下是把COSCUP的演講做個整理: 在設計應用程式時,不管程式是怎麼實作的,使用者都不知道,也不會知道 所以不僅是程式要下苦工,UI更是要仔細鑽研: 好的UI,第一眼給人的感覺就是有質感 好的UI,讓使用者體驗良好,知道怎麼用,才會想繼續用 好的UI,帶來高評分,高評分帶來高下載量,高下載量帶來高獲利 所以,UI設計上該注重些什麼? * 簡潔 而非 簡單 * 內容充實 而非 華而不實 * 一致性卻又吸引人的互動體驗 * 巧妙的利用雲端跨平台 聚焦在使用者 1. 要知道使用者需要的是什麼(e.g., 最常用操作應該可以第一眼看見且易於使用) 2. 從使用者角度來設計產品(e.g., UI要有適度的回饋讓使用者瞭解,如:按下按鈕) 3. 儘早且頻繁的給目標市場上實際使用者測試 Don’t make the
2 min read
AppEngine

股票機器人 – Goristock

在未投入股市之前,不知道大家會不會認為說要在股市賺錢好像不難啊?! 像之前金融風暴,我就在心裡想說,如果我有錢我一定趁現在狂買 用這樣的疑惑去問我朋友,發現歹誌沒有傻人想的這麼簡單,當你真的在玩股票的時候,你每個買賣動作都會關乎到你的金錢!所以就沒辦法像看新聞的時候這麼處之泰然 這程式的概念就是出自於此,讓心情起伏的干擾因素降到最低(投影片有白痴的阿斯拉比喻) 講者講得不錯,不過太有自信能在五分鐘之內(lightning show限制)講完了,一開始還說不知道為什麼想跟大家敬禮XD,最後只講了一半就被趕下台,哈! **[goristock in Coscup flash](http://www.slideshare.net/toomore/goristock-in-coscup-flash "goristock in Coscup flash")**View more [presentations](http://www.slideshare.net/) from [Toomore](http://www.slideshare.net/
1 min read
iPhone

EPUB with HTML 5 in iBooks

原來的講題是"HTML5 電子書閱讀器",讓我以為就單純的是用HTML 5寫的線上閱讀器,興趣缺缺… 沒想到竟然是說iBooks裡面的EPUB改用HTML5的格式來寫,測試之下,發現目前所有行動電子書閱讀器,就是Apple的iBooks支援度最高了! 其實我對電子書一直也有這樣的需求:要是還能夠互動就好了 我也知道EPUB其實就是HTML的寫法,但是我沒想到iBooks竟然可以吃HTML5!! 而且他不是單純的用UIWebView,而是自己利用webkit核心來重刻,但是有HTML5只可以實現canvas以及聲音影像,但是還少了互動! 解決方案在此! 有空的時候一定要親自試試XD!
1 min read
COSCUP

模組化與自我驗證的重要性

同樣是COSCUP一場精采的演講 原本的主題:Front-end Modular & Automated Development 但是我認為,這其實不只適用於Web Development的前端開發而已,所以決定下個中文標題 **[Front-end Modular & Autmomated Development ](http://www.slideshare.net/josephj/frontend-modular-autmomated-development "Front-end Modular & Autmomated Development ")**View more [presentations](http://www.slideshare.net/) from [Joseph Chiang](http://www.slideshare.net/josephj). [![](http://www.hitripod.com/blog/content/
2 min read
COSCUP

Open Governance

在今天的COSCUP中聽到Nokia北京技術經理報告滿有趣的概念:Open Governance 為什麼會有這個東西呢?是因為最近在智慧型手機的市場,Nokia幾乎快被iPhone跟Android打趴了,而這觸使了Maemo與Moblin的合體,也就是Meego,他們也很清楚光是這兩個合體還不夠,再加上已經推出一段時間的跨平台UI framwork – Qt,並且把全部都open source出來,不只是程式碼本身的開放,連軟體的開發與管理也開放! 概念如下: 1. Planning in Public 開發的過程中,會把目前進度以及將來預計加入的功能都依照時間表(Roadmap)公開,同時提供讓使用者(也就是用Qt開發程式的人)技術交流的平台,並且經常性的舉辦聚會,讓使用者可以參與產品的走向 2. Development in public 不論是內部員工,或是社群的貢獻者,都是一同以同樣的方式參與產品的開發 3. M
2 min read