18 days ago

我的 blog 已經轉往 https://chchwy.github.io
往後這裡都不會再更新

 
about 3 years ago

老婆之前在美國時敗了一台 Macbook Pro 13" (2011 Late),但是她用不慣 Mac OS X,後來就霸佔了我的桌機,把這台 Macbook Pro 丟給我用。我原本也就只是將就用用,但是過一段時日後我發現 Mac 生態系有個很大的優點,就是 App Store 上有很多精緻的小眾 App,真的很多,越用越喜歡。

像我發現一款叫做 Alternote 的第三方 Evernote 編輯器,原本官方 Evernote 的文字編輯區其實對寫作非常的不友善,而我對編輯器的要求其實很簡單 1. 有暗色主題 (全白背景根本就是強暴眼睛) 2. 可以調整行高,預設的行高根本不適合中文寫作,就這麼簡單的要求,不但官方死都不做,Windows 上也是百尋不著替代品,但我就是在 Mac 上找到了。

專注寫作軟體也是,Mac 上選擇多的不得了,其中 Ulysses 堪稱極品,至於 Windows 上沒一個能打的。

我想這跟兩個 OS 的生態系有關,在 Windows 生態系裡面,這種獨立開發的小眾 App,很難獲取收入。但是 Mac 上有統一的軟體市集 App Store ,賣軟體的門檻就降低很多了,讓軟體工程師可以專注在開發好軟體,不用擔心怎麼賣的問題。

寫軟體難,但是賣軟體更難啊。

 
about 3 years ago

這是今天在做一些小程式練習的時候,使用原生的 Win32 API CreateWindowEx() 建立視窗中間碰到一個問題。

狀況是這樣,所有傳遞給 CreateWindowEx() 的參數都正確,但是執行程式後,不管怎麼弄視窗都沒有被正確創建出來。CreateWindowEx() 調用後,沒有如我預期的回傳新視窗的 handle,而是回傳了 NULL 表示視窗建立失敗。接著呼叫 GetLastError() 拿到 0,得不到任何出錯原因。

如果你懶的看原因,那麼簡短的解法就是記得在 Msg Handler 的最後呼叫 DefWindowProc ()

Read on →
 
over 3 years ago

昨天幫 Macbook Pro 換新的 SSD,可是換完後 OS X Yosemite 一直灌不上去,只要一安裝就跳出這句錯誤訊息:

無法驗證此版本的『安裝 OS X Yosemite』。可能是軟體損毀或下載時發生問題。

我重做了兩次 USB 安裝碟,確定檔案沒有問題。百思不得其解只好問 Google 大神,發現原因可能是系統時間。我打開終端機,輸入date命令,看見打印出來的系統時間是西元 2000 年,果然時間完全不對。

馬上又搜尋該怎麼在沒有 OS 的狀態下修改系統時間,作法是在終端機輸入:

date 063021192015.30

格式是MMDDhhmmYYYY.ss,06是月,30是日,21是時,19是分,2015是年,30是秒,然後按 Enter 鍵輸入。
修改成正確的時間後,安裝程式就一路順暢到底了。

雖然是解掉了,但是這個錯誤訊息.....到底有誰會知道是系統時間的關係啦 (翻桌)

附註:蘋果官方的說明網頁

 
over 3 years ago

第一次跑 PowerShell 一定會碰到這個錯誤,原因很簡單,因為 Windows 7/8 默認情況下禁止執行 PowerShell Script 檔案(.ps1) ,大概是怕用戶不小心執行了來路不明的檔案,所以要手動打開權限才行。

打開權限作法如下:

用「系統管理員」身份執行 PowerShell (一定要用系統管理員) 輸入以下命令:

Set-ExecutionPolicy RemoteSigned

這樣就可以順利執行自己寫的 PowerShell Script 了。

ExecutionPolicy 是 PowerShell 的安全性管制的機制。我們把權限改成 Remote Signed 的意思是執行從網路上下載的 .ps1 要檢查數位簽章,只有受信任的來源才允許執行。但是本機的 PowerShell Script 檔案就不受任何限制,直接放行。

更多 ExecutionPolicy 的等級可以參考這裡

 
over 3 years ago

qmake 可以將 Qt 原生的 .pro 專案文件轉換成 Visual Studio 專案
還蠻簡單的,只要下指令-tp vc

qmake -tp vc MyProject.pro   // 產生 MyProject.vcxproj

如果 .pro 內含多個專案,要產生 solution 而不是單一 vcxproj,就加一個參數-r

qmake -tp vc -r MyProject.pro // 產生 MyProject.sln,內含多個 .vcxproj

同理,在 Mac 平台上也可以產生 Xcode 專案,指定 -spec macx-xcode

qmake -spec macx-xcode MyProject.pro // 產生 MyProject.xcodeproj

這樣就可以用本地平台上比較強大的 IDE 來開發 Qt 程式了。
我比較好奇為什麼兩個平台下參數的方式不一樣...

Reference: http://doc.qt.io/qt-5/qmake-platform-notes.html

 
over 3 years ago

其實已經完成一陣子了(茶)

很久以前就想要學 Python 了,但是因為沒有明確的目標,所以雖然讀完了 Dive into Python 3 ,學了一些語法,依然未脫離 Python 門外漢的狀態。後來發現 Codecademy 的 Python 課程,一試之下覺得非常順手,就每天撥出半小時,用兩個月左右的時間把課程做完了。

Codecademy 課程的優點就是強迫動手敲代碼。Codecademy 的課程都有三個部份:一小段解說,一個小問題,然後要求你敲代碼解決它。第一課就是簡單介紹 datetime 的用法,然後要我打印出今天的年、月、日數值。每個課程段落都切分得很小,很容易進行,可以很快得到學習的反饋。每解掉一道習題,看見代表答案正確的綠色勾勾亮起,再按下「Start Next Lesson」,很像遊戲過關,很有學習成就感。

我自己知道寫程式是一種黑手性質很強的工作,看懂了、聽懂了,那距離真的懂了還很遠,一定要自己敲代碼,親手解決每個編譯錯誤,把每個步驟實現過一遍,才能算真學會了。所以我覺的 Codecademy 這種互動式的教學比書本、老師都還要有效,因為課程的進行方式就是「從做中學」。而且這種習題為主的課程,剛好適合我這種沒有明確目標,想學 Python 但是還不知道 Python 可以拿來寫啥東西的學生。之前學習失敗的經驗就是腦袋裝了一堆語法跟函數,但是沒地方使用所以很快的就忘光。

順便推薦一篇老文章「學會開放性思維」,文章裡建議程式設計師要學 C、Lisp、Python、Perl 這四種不同風格的語言,文中說的「通用的程式設計思考方法」很吸引我,所以我才會想學 Python。

接下來想要嘗試看看用 Flask Framework 來寫 Web ,或者用 PyQt 來做點桌面小程式。

 
over 3 years ago

現在可以選擇的 Blog 平台太多了,我用過的平台就有 Blogger、Tumblr、Logdown、Github Pages、博客園五個。

最早用的是 Google Blogger,後來因為貼程式碼不便,所以曾經短暫的使用博客園一陣子。但是在我發現了 Github Page 之後,立馬就頭也不回的開始折騰 Github Page 了。Github Page 最吸引我的原因就是它給了我完全控制頁面的權利,但是相對的代價就是你真的必須親手搞定整個站,主題啦,文章列表,CSS啦,前前後後改了四五次,博文沒寫幾篇,時間反倒是都花在搞版面跟 Jekyll 設定上了。我不是專業的 Web Designer ,雖然有一些 Html+CSS 的知識,但是到後來我也會想,寫個文章而已,弄這麼累幹麻。

反思一下,我一直在追逐最理想的博客平台,但是這個追逐其實沒有什麼意義,每個平台或許都有一點不方便,但是其實並不會真的阻擋我寫下文字。博客終究是內容為王,一步一腳印的寫下筆記和感想才是最重要的。

寫博客最重要的還是對自己負責,紀錄、思考、咀嚼自己的工作,梳理過後寫成博文。沒有內容之前,平台阿、觀眾阿什麼的,都隨風去吧。

 
over 3 years ago

過年後看見 PCHome 24h 在促銷 M550,就直接刷了一顆。先說結論,這是這一整年來花的最值得的三張小朋友。不囉唆,上圖。

以前早上進公司按下開機,都要先泡杯咖啡上個廁所,等電腦慢慢開機。現在換上 SSD 開機只要20秒,重新開機30秒。Visual Studio、瀏覽器各種秒開,無法形容的順暢感,太爽了。強烈建議每個公司都應該要幫工程師配 SSD,絕對是增進開發效率的神器。現在的 256G SSD 只要三千元上下,投資報酬率太高了。

但是 Build code 倒是沒快上多少。我們的專案原本使用傳統硬碟 Rebuild 需要 26 分鐘,改用 SSD 之後縮短為 23 分鐘。大約只快了15% ,可見編譯 C++ 主要的瓶頸還是在 CPU。

最後推薦一下 AOMEI Partition Assistant 這套軟體,只要按一下 "Migrate OS to SSD" 就可以無痛的把舊硬碟上的 Win 8 作業系統遷移到新買的 SSD 上,過程大約 40 分鐘,不需重灌作業系統。當然最重要的,它免費。

 
almost 5 years ago

Objective-C 裡有個我非常喜愛的特性,就是對空物件 nil 調用方法不會出錯。
類似這樣:

NSArray* myArray = nil;
[myArray count]; // It's ok.

在許多主流語言裡,像是 C++,對 NULL 指標調用方法都是非常嚴重的錯誤,很可能馬上導致程序崩潰。但是在 Objective-C 裡不同,對 nil 調用方法被視為稀鬆平常的事情,這個方法調用不會使程式崩潰,也不會拋出異常,程序就是單純的不做任何反映,船過水無痕地默默繼續運行。如果該方法有回傳值,就回傳 nil 或零。

空指標就不做事的原則,大多數時候也的確符合我們的期望,所以 Objective-C 程式裡不再需要處處塞滿 if ( ptr != NULL ) { ... } ,提心吊膽的預防洩漏的空指標造成程序崩潰,這個小差異大大提高了程序的穩定性。代碼也更簡短清晰了。

後來我發覺這個 NULL / nil 的小差異,其實沒那麼簡單,真正的問題是將指標設為 NULL 這件事,破壞了程式語言類型的保護網。

Read on →