GeoGebra 開箱

在臉書上看到蔡炎龍老師利用 GeoGebra 做出的這個圖片。題目看起來還挺有趣的，所以就想了一下。第一個想法是用複數，在白板上面稍微算了一下果然可行。但直覺這種東西應該有幾何上的意義，所以盯著這個圖片看了一陣子，總算看出了圖形化的證明。
但一來憑空想像的圖形有時會出錯，二來要怎麼把這個解法貼出？
於是，我想不妨試看看這個蔡老師推廣的 GeoGebra 好了。
第一步當然是先用 google 找到 GeoGebra 網站，發現是 Java 軟體，點一下然後等一下就能打開。稍微摸索一下，就上手畫出跟上面一樣的圖形。這也多虧有上面的圖當範本，讓我知道 GeoGebra 能畫出這樣的圖形，才能往正確的方向嘗試，幾乎可以說是打開就會用了。
接著就要做圖形化的證明。傳統的方式，我們會用輔助線的方式來做圖形證明。像是過某點作與某線段平行的直線之類的，然後再說新作出來多邊形和原來的哪個全等。
GeoGebra 也能做同樣的事，不過還有更好的做法。與其弄一堆平行的輔助線，我把原來的圖形繞著一個點旋轉 180 度，這樣平行以及全等就是自然而然的事情了。
準備儲存圖片時，發現可以輸出 GIF 動畫。心想這樣更好，但是找不到動畫時間軸的要怎麼弄，所以便宜行事 Google 了一下，了解 slider 的用法。

最後的結果如下:

由這個動畫，可以很清楚的了解兩個正方形中心相連的那個線段的幾何意義，當然也就清楚知道為什麼會垂直了。
也由於是 Java，什麼平台都能跑，拿來畫畫圖看起來還挺方便的。

Read More

Win8 安裝 (x32升x64 無 DVD/USB)與心得

在 preview 及 RTM 版本時,已經在 VirtualBox 上裝過了 Win8。因為主力筆電換了台 MBA，所以這次就放心地將之前的筆電來實機灌正式版 Win8 Pro。
不過問題是我原本的 Win7 是 32bit。原因也是當初選擇直接升級 Win7，所以只能 x32 升 x32。這次反正重要資料大多已經轉移了，就放心地完整升級 x64 版本。
先用一台 Win7 64 版的 PC 購買及下載了 Win8 x64 的 DVD ISO，接著，就發現糟糕了。
手邊沒有空白 DVD，也沒有 USB 隨身碟。實際上就算有空白DVD 也沒用，筆電的 DVD driver 已經拆下了。
直接用虛擬光碟跑 setup 是不行的，因為 x32 的 win7 根本不讓你跑 x64 的 setup。
靈機一動，想到手機裡有 Micro SD，然後剛好有轉接卡，所以就 bootsect /nt60 f: /force 之後，將 Win8 DVD 的檔案放到 SD 卡內。沒想到我的 LifeBook T4215 無法用 SD 開機。
如果能將 Android 手機當成外接硬碟開機也不錯，不過似乎也找不到簡單的現成解法。
隨便借個隨身碟也行，但是不知哪根筋不對，就是突然很執著想不用隨身碟來安裝。
所以決定用 grub 或者 windows 的 boot menu 來啟動光碟。 先嘗試用 boot menu，所以抓了 EasyBCD 來弄。果然順利啟動了光碟，但是會卡在找不到驅動程式。後來在安裝過程中的 X: 磁碟機，試了一些目錄讓他找驅動程式，結果搜尋了半天卡住了，只好重開機。
其實即使找到驅動程式也不是很放心，因為照理來說是不會發生這種問題的，所以很可能是 EasyBCD 沒有完全處理好光碟的模擬。 所以改使用 unetbootin。 用 unetbootin 將 ISO 安裝成從 C: 啟動，結果更慘，無法啟動光碟。 本來已經放棄了，重開機想確認一下還能回到 win7，結果不小心按錯，換成使用 EasyBCD 來啟動 ISO，結果這次居然順利啟動了安裝光碟，然後順利完成安裝。
想來是找來 ubootin， EasyBCD 也會怕競爭，終於肯認真工作的緣故。
回想起來，後來就再也沒機會完成原本想重新啟動進 win7 的動作了，因為 win7 很快就被我刪除了。 不禁感到一股淡淡的哀傷。

win8 的使用邏輯和之前有點不同。對於沒有多點觸控螢幕的電腦來說，鍵盤快捷鍵的使用機會大增。
比方大多數人第一個會注意到的，就是開始功能表不見了，所以會讓人有不知從何開始的感覺。實際上取代開始功能表的是在 Metro 桌面按 Windows+Q 的快捷鍵或者直接打字。跑出來像是上面的東西，然後你在搜尋框中，可以打程式名稱來搜尋。
過去的 Alt-F4, Alt-Tab 及 Ctrl-Alt-Del 都可用，外加 Windows+C,Z,Q,Tab,I,K,F,G 一堆新的。Screenshot 用 Windows+Scr。

第二個注意到的，可能是 Chrome 或者 Firefox 不見了。不過其實大多數使用者可能因為用得太習慣，忘記 Chrome 和 Firefox 本來就是另外抓的。裡面的 IE 一樣保有上網抓 Chrome 和 Firefox 的功能。商店裡面也能抓到 Google Search。不過 IE10 其實看起來還不差就是了。
IE10 有兩種介面，Metro UI 和傳統 windows UI。 就像是當年 Win 3.x 那種 GUI 配上 DOS 模式的感覺，  Win8 也是 Metro UI 背後配上 Win7 模式。可以靠 Windows 鍵跳回 Metro 磚頭頁，也可以用 Windows+D 跳到傳統桌面。
兩種雖然都是 GUI，但是使用上的感覺並不一致。比方我的 T4215 是 Tablet PC，所以有隻觸控筆。在傳統 UI 下，可以使用觸控筆的手勢拉網頁。但是在 Metro UI 下卻不行。
Metro App 的使用邏輯還沒有完全統一。有的時候搜尋可以用 Windows+Q 或直接打字(有時兩者皆可，有時則只有 Windows+Q)，有時則是滑鼠右鍵或 Windows-Z 叫出選單(像是地圖)。

優點也有一些。Live 帳號的整合度不錯，遊戲方面還能與 Xbox live 整合，雖然有時要回確認馬有點麻煩。檔案複製時的資訊非常完整，中文手寫輸入法很不錯。硬碟重組感覺很快。商店內也有些不錯的免費軟體，比方 Onenote 就是免費的。

Read More

Macbook Air 11" 2012 使用心得

查看今年在 coscup 的  irc log，發現我的旗艦筆電慘遭嘲笑：

11:38 < *******> [R1] 講者故意帶了很慢的電腦來展示

憤而決定更換新機。
開玩笑的，真正的原因是我常常上課或演講帶著筆電跑來跑去，雖然我連拿著磚塊般的 Xoom 都舉重若輕， 但因為加上電線、書本一堆的，常常還是覺得有點狼狽，所以就打算使用輕薄一點的機型。速度倒不是主要考慮的因素。雖然可能的選項還挺多的，但總之，最後選到了 Macbook Air 11" 2012 128G SSD 這款。
記得我的上一台蘋果電腦，是.......沒有。小學時家裡放了一台舅舅借的 Apple II 相容機。不過那時我還不會寫程式。後來學寫程式也是從 Apple II 的 basic 開始，但那時自己沒有機器，都是借用學校的。後來為了想拿麥金塔當獎品，參加蘋果的電腦繪圖比賽，最後拿到兒童組亞軍，只拿到一本「蘋果戰爭」的書。後來用 executor, pearpc, virtualbox 等模擬器跑過一些蘋果的作業系統，但沒有真的在用。所以我對 osx 完全不熟。
所以，以新手的角度，簡單的描述一下心得讓有類似需求的人參考。

1. 效能方面，配備有 1.7ghz 雙核心 core i5，GPU 是內建的 HD4000。記憶體我升級到 8G， cpu 雖然也有升級的選項， 但我認為 core i5 已經足夠。實際上使用的心得也是如此。效能方面大致上符合需求。
2. 重量 1.08 公斤。雖然比 Xoom 還重，但也許是外型扁平（空氣浮力？），也許是心理因素，拿起來並不感覺特別重。總之，比之前的筆電好攜帶多了。機器可以放入我為了 Kindle 買的套子。事實上，我常常將 Kindle 加上 MBA一起放入平板套中攜帶，有時還將手機一起塞進去。
3. 續航力是比較不滿意的地方，不過這是購買前已經了解到的事情。待機之類的耗電不多，開機很快，所以不用的時候，關機即可。但問題是持續使用的情形下，使用時間比平板要短一些。兩三個小時的使用不成問題，但時間久一點（比方一整天），跑的東西多一點，就會有點擔心電力的問題。雖然不見得真的會沒電，但因為這個擔心，可能會讓你考慮要多帶個充電器。
4. 螢幕雖小，但解析度還可以，所以其實使用上問題不大。我有實際試過在搭乘客運時 coding，的確可以工作。不過有老花眼之後，可能就不行了。
5. 找不到怎麼改字體大小，除了改解析度的方式外。
6. OS X 的使用一開始並不順手，但磨合期不會太長。最主要是要熟悉多點觸控手勢。由於螢幕小，大多數是使用單視窗邏輯去操作，所以固定在最上層選單使用起來不像 ubuntu 的 unity 那樣彆扭。
7. 中文輸入法的設定/安裝經驗不好。由於我使用許氏鍵盤注音，所以得額外安裝支援許氏鍵盤的輸入法。一開始使用 Openvanilla，但後來發現酷音要另外裝。上網找了一些安裝方式都裝不起來，我就放棄了。最後使用 Yahoo 的輸入法。但是 Yahoo 輸入法要選擇許氏鍵盤居然還要靠秘技才行？
8. 軟體包含許多實用的軟體，比方說 quick time 能將螢幕畫面錄下來。想放上 youtube，可能會想自己配樂。雖然 youtube 有提供一些音樂讓你配音，但其中一些似乎會強迫在你影片中放廣告。所以，可以自己用 garageband 放一些簡單的配樂進去。Facetime 的畫質和效果就我個人的經驗來說，是同類型最佳。
9. xcode 我用了一下，還沒有上手。
10. 由於 128G 的 SSD 不很大，根據網路上的資訊，我選擇用相對較省空間的 brew 來管理開源向的套件。當然也裝上了 python。雖說 osx 的底層是 bsd，但很多東西的支援度還是有差。比方上圖是最近練習寫的小遊戲，用的是 pyglet。pyglet 在 mountain lion 上跑不起來。當然最後我還是跑起來了，因為用了 1.2 alpha，而且還修改了裡面的 bug 才能跑（搜尋網路找到的）。但即使如此，跑起來還是有小問題。
11. 另外一個例子是 pcsx。下載官網事先編譯好的可執行套件，會發現無法使用硬體加速 plugin。原本我打算自己寫，不過下載好 source 後發現其實自己 compile 之後就有硬體加速的 plugin 了。總之，就是開源向的東西支援完整度沒有那麼好。不過，一部分的原因也是因為 mountain lion 本身的向下相容性問題。

以不到四萬元的機器來說，我認為是滿意的。目前大致上取代了 xoom 和原本筆電的功能。

Read More

用 Python 將漫畫轉 PDF 給 Kindle DX 用

Kindle DX 的 824x1200 解析度拿來看黑白漫畫還算合適。可以直接轉圖檔來看，但是 Kindle DX 的看圖軟體並不是很穩定。也可以用一些免費的 pdf 工具來把圖檔組合轉成 pdf 檔，但並不是很能隨心所欲的控制解析度。
所以這裡利用 python 的 reportlab 來做。
底下是先利用 PIL 先將圖檔切兩半，然後增加對比，壓縮成 JPEG，最後再利用reportlab 將圖檔放入 pdf 中即可。

from glob import iglob
from sys import argv
from io import BytesIO
from PIL import Image, ImageOps
from reportlab.pdfgen import canvas
from reportlab.lib.utils import ImageReader
dxsize=(776,1150)
pathname=argv[1]
c = canvas.Canvas( pathname+".pdf",pagesize=dxsize)
for fn in sorted(iglob(pathname+"/*.jpg")):
    img=Image.open(fn).convert("L")    
    w,h=img.size    
    im_split = map(img.crop, [(w/2,20, w, h), (0,20, w/2, h)])    
    im = [img.crop((0,20,w,h))] if w < h else im_split    
    for imgx in im:
        imgx=imgx.resize(dxsize, Image.ANTIALIAS)
        imgx=ImageOps.autocontrast(imgx, cutoff=10)
        tmpio=BytesIO()
        imgx.save(tmpio, "JPEG", quality=70)
        tmpio.seek(0)        
        c.drawImage(ImageReader(tmpio), 0, 0)
        c.showPage()
c.save()

裡面的 dxsize 是根據 mobileread 的網友實驗出來，kindle dx 中 pdf 可用的最大圖檔解析度。雖然 pagesize 的單位是 point 而不是 pixel，但看起來似乎這樣是對的設定。
由於抓來的圖檔對比太弱，利用 autocontrast 來加強對比。
im_split 那行是將圖切回左右兩頁，上面的 20px 是去掉漫畫網站的 mark。
ImageReader 其實吃 PIL 的 Image，但為了能夠控制 JPEG 的壓縮率，所以利用 BytesIO 來當暫存檔。由於某些 PIL bug 的緣故，雖然理論上 Image.save 應該要能吃 BytesIO，但是上面的程式碼會出錯，因為 PIL 沒有處理某些 BytesIO 丟出的 exception，所以我手動修改 PIL 的程式碼讓，save 能吃 BytesIO，也許改成 StringIO 也可以避開這個問題。
原先還想說是否要 dithering，不過至少漫畫看起來還可以接受。

倒也不是非得一定要用 python 寫，我同時也有抓 pdf fill 這樣的現成工具。只是剛好網路有點慢，還沒有抓完 pdf fill，已經先裝好 PIL、 reportlab，然後寫出上面那個程式的雛型了（不過原來沒有用 BytesIO 而且是用 reportlab 比較高階的寫法）。

Read More

從 Linus、飛機失火到魔法老師

圖片來源 Matt Cunnelly

最近在 Linux 的作者 Linus Torvalds ，因"飛機最大的問題就是窗戶打不開"的言論，在 Goolge+ 上罵美國共和黨總統候選人羅姆尼為「他媽的腦殘」 "He really seems to be a f*cking moron." 隔天又馬上在 Google+ 上改口說道：「他好像是開玩笑的」
這個故事告訴我們的是，即使像是 Linus 這樣，邏輯思考能力足以開發作業系統，分析能力足以在龐大程式碼找出 Bug 的人，在某些時候，一樣會被媒體誤導。畢竟有時因媒體的特性，部份資訊會無可避免的遺失（比方文字資訊不容易傳達語氣）。更別說有時有些資訊來源是別有目的的。
最近有所謂照南國小魔法老師七朵花事件。這中間誰對誰錯不是本文的重點。重點是，這裡面有黑函，還有黑函 2.0。

黑函也是一種資訊，只不過是一種消息來源不明確的資訊。消息來不明確，不見得資訊就不能用。比方如果有個不明來源的資訊，利用基礎的數論，在一張 A4 紙的空間上證明了 Fermat's Last Theorem，每個懂數學的人都可以直接驗證這個證明是否正確。如果正確，那這個證明真的是有意義的。資訊來源是否匿名，就不是那麼重要。但如果這張 A4 紙上同時宣稱這是 Fermat 當年沒有寫下的證明，我們雖然可以判斷裡面的數學手法和工具是否符合 Fermat 的風格，但相對來說比較難證實這件事。有消息來源，至少還能找到作者，也許還能確認他手上是否真的有當年的手稿。

這次會造成家長連署，進而會需要讓校長讓調班的事件，起因應該是黑函和口語（所謂的七朵花在苗栗風評很差，懶人包中也有提到）。
很多時候，匿名資訊代表著發布資訊者不願意為這個資訊負責。
這是黑函可怕的地方，大多數人並不在意消息怎麼來的。不是沒注意到而已，而是根本不在意。因為大多數人沒有 Linus 邏輯能力、分析能力，還有自省能力。
 不過更可怕的是黑函 2.0 。這次事件讓絕大多數人氣憤的，是那個七朵花在會議中對長官態度惡劣的 youtube 影片。絕大多數人不關心的是，該影片的上傳者，是一個註冊不到一天的人上傳的，而且用了個 Chen Charly 這樣不知道是誰的名字。

黑函不可怕，可怕的是它居然有效。
日常生活中，充斥著不明來源的「黑函」。吃什麼樣的食物才健康，什麼東西有電磁波會致癌，還有某某某的性愛光碟。
可怕的是它居然有效。

Read More

3D 超任模擬器

這是基於 snes9x 的簡單修改，增加雙眼視覺 3D 立體效果。
 不是什麼新點子，但如果你搜尋一下網路，就會發現說得人多，做得人少（大部份的情節是某人問說 snes9x 有沒有支援 3d stereoscopy，然後會有人說不行、沒意義等等的，有時也有人說應該可以，但就是沒有人真的去弄）。

3D 遊戲要弄出深度很簡單，但超任明明是 2D 畫面，要怎樣弄出深度？
因為超任有四層 background，一層 sprite，每層 background 和 sprite 又有不同的優先權等等的差別，所以可以依照繪製的順序給出深度（雖然得出的深度不見得理想），而 snes9x 的實作中，也給出了 z-buffer，所以有內建的深度可用，所以只要簡單的依照深度將 tile 位移即可。

目前的實作在 https://github.com/tjwei/snes9x-3d，只支援 odd-even-rows，還有 linux/gtk，因為這是我桌機的設定。 為了要放上 youtube，所以改了個 left-right 的版本（只是左右有點搞不清），然後用 recoredmydesktop 來錄。但是錄起來有 window 的邊，所以又用了 HandBrake 手動修掉邊。
由於影片製作的過程很家庭手工，所以有點不太順，實際上使用的效果會比影片要好一點。
有些遊戲效果還不錯，有些則不怎麼樣。

在 evo 3d 上看，似乎要深度加強一點，所以也錄了一個深度加強版。 由於我 compile 的 Snesoid 會 crash，所以 port 到 evo 3d 上要等等了。

Demo 如下
深度較強，適合小螢幕，只有快打旋風二



深度較弱，比較長

Read More

窮人的 3D 全像 : 使用 Android 手機

這是一個簡單的實做，利用隨手可得 Android Phone 來製作 Swept-volume display。顯示的是一個立方體，其中兩面顯示英文字母，一面顯示黃色，其他幾面是空心的。因為手機螢幕及錄影機的 framerate 的緣故，錄得不是很好，（有點類似錄 CRT 電視的情況），實際上的效果要好些。 其他還有弄一些單純的方塊，方塊中加個圓管，十字架，方塊中一個小方塊，但就沒有錄了。

 視覺暫留顯示(POV Display) 不罕見，如下面的影片

 

 Volume Display 最常見的就是 Led Cube，




 上面兩個都是常見的 DIY project，Swept-volume display 差不多就是上面兩個東西的混合。
用手機的好處就是 X,Y 的解析度是 480x800，不是 LED Cube 的 8x8 能比的。做 POV Display，也不用額外的硬體，單純用人力揮動配合手機的 accelerometer 即可。
但 Z 軸的解析度就很差。假設手一秒來回揮動三次，一般手機螢幕更新率是 60Hz，那表示 Z 方向從頭到尾移動一次只花了 1/6 秒，畫面只更新了 10 次。外加一些誤差（手的誤差和 sensor 的更新率），去頭去尾之後，Z 軸的解析度也只有 6～8。
當然你也可以手揮動得慢一點，但是太慢了就無法讓眼睛產生視覺暫留。
總之，暫時無法弄出 Leia 公主。修改之後應該還可以再擠出一些 Z 軸的 frame 出來。

更新：新影片，攝影技巧好得多。比較有信心能弄出 Leia 公主或初音了。

Read More