Linux Bash 寫作筆記

*read <自 stdin 取得使用者輸入資料>

example: 自 stdin 取得使用者輸入資料，並存放於 $input_value 中

read -p "Please input something: " input_value




*sed <使用正規表達式對資料進行 尋找、取代...等 處理>

example: 將 A.txt 檔案內容中 oldvalue 字串取代為 使用者輸入值(上一個範例中取得)

sed_string=s/oldvalue/"$input_value"/g
cat A.txt | sed $sed_string > A.tmp
mv -f A.tmp A.txt


MySQL InnoDB 相關技巧

使用 MySQL InnoDB 可以帶來許多的好處，官方說有這些「transactions, row-level locking, and foreign keys 」，但也帶來許多奇奇怪怪的問題，和一些要注意的小地方。

因此在此做一些整理，以利將來查找使用。


***將 InnoDB 設定為預設表格型態***

my.cnf (Linux 或 Solaris) 或 my.ini (Windows) 包含下列選項：

default-table-type=innodb
不應該包含 skip-innodb 選項。



***MySQL #1005 - Can't create table 問題處理***

打開 MySQL Command Line，並輸入：

# mysql -u root -p
mysql> show innodb status;


在輸出資料中就可以找到詳細錯誤敘述。

我的第一個 OpenSouce(開放原始碼) 專案 - Abyss

Abyss 是我參與的第一個「正式」的 OpenSouce(開放原始碼) 專案，之前自己的 OpenSouce 作品都沒有嚴謹的坐 Licence 發佈與版權宣告，所以 Abyss 對我來說是一個新的里程碑！



Abyss v1.0.0 的開發者是 OHM KAO，在這個版本中我只是幫助 OHM 把 Abyss 轉換成一個 OpenSouce 的專案，接下來的版本我將加入開發的行列，希望能夠貢獻一些自己的力量！

OHM 是我前公司的同事，某次在聊天中 OHM 提到他做了一個 PHP 的 Framework 並邀請我看看這個 Framework 的架構，這個 Framework 是他集合了長久以來接 CASE 的經驗與目前各大 PHP Framework 的優點而研發出來的，我聽了當然是非常有興趣，在仔細的看過這個 Framework 之後我感到真是「相見恨晚」！



Abyss 提供了良好的 PHP 系統架構，導入導出機制、多國語言機制、並使用 SMARTY Template 技術、jQuery Framework，這些技術都是目前 PHP 的主流技術，同時集中在一個 Framwork 上我是第一次見到！這是我夢想中的 Framework 阿！



使用 Abyss 之前，對於 PHP 與 SMARTY 的架構要有一定程度的瞭解，這樣才能在使用上得心應手喔！



Abyss 於 SourceForge 專案：http://sourceforge.net/projects/abyss-system/

刺激 1995 ＝ 肖申克的救贖？

「刺激 1995」這部電影一直都名列我最喜愛的電影的前 5 名，今天在網路上找資料時，無意間逛到一個大陸人的 BLOG，裡面出現了這部電影的海報，但仔細一看電影名稱卻非常的不一樣...

原來這部電影在大陸被翻譯成「肖申克的救贖」...

去查了 WIKI 之後，發現原來台灣的片名翻得比大陸更爛...
以前就一直搞不懂為甚麼要叫「刺激1995」...哪裡有刺激到了？

這部電影的英文原名叫做「The Shawshank Redemption」，單依電影名稱最貼切的翻譯應該是「鯊城監獄的贖罪」吧。



Wiki 相關資料：

肖申克的救贖

MySQL View 效能堪慮

MySQL View 效能堪慮，使用前請三思...


自從上個 CASE 開始使用 MySQL 5，感受到 MySQL 真的有在慢慢進步了，其中 MySQL 5 終於開始支援 VIEW 就是一個重點，但是上一個 CASE 中不敢冒然使用。

今天早上在規劃目前手上 CASE 的 資料庫規格，突然心血來潮想要用 VIEW 來減低 QUERY 的複雜度，在開始實做前照慣例，先上 GOOGLE 搜尋一下相關的資訊。

結果不搜還好，一搜就給我發現大問題，那就是 MySQL 5 的 VIEW 似乎效能不好...主因來自於 MySQL 5 伺服沒有對 VIEW 做最佳化...

這件事對我這個完美主意者來說真是一個天大的災難...等於是叫我不准用 VIEW...看來只好繼續寫落落長的 QUERY 了...




MySQL VIEW 效能相關文章，都是出自「www.mysqlperformanceblog.com」：

MySQL VIEW as performance troublemaker

Derived Tables and Views Performance

Google App Engine 之 Python 與 BigTable 心得

上星期 5 (2008/06/27) 從朋友那裡得知有「Google App Engine」這個新的服務後，就開一連串對這個新服務的研究與測試。結果發現使用 Python 的問題不算大，而 BigTable 這個非關聯資料庫對於已經熟悉傳統關聯資料庫開發的技術人員來說，應該才是個真正的門檻。





首先來說說 Python。

在這次研究「Google App Engine」之前，我對 Python 的瞭解都只限於「是一種直譯式程式語言，跟 JAVA 有點像，可以用於 WEB 與 APPLICATION」，直到這次才有機會比較深入的去試試看 Python 到底是個什麼東西。

我得到 3 點心得：

1.結構鬆散
因為我一直都習慣使用 C 與 C++，而網頁程式也大都使用 PHP 開發，因此 Python 給我的第一個感覺是「很鬆散」...Python 並沒有像 C 語言的大括號 { } 可以用來切割程式碼的層級，因此只要程式碼比較長一點或是層級比較多一些，閱讀上就會變得很吃力...


2.格式限制
Python 的每個層級「一定」要用「兩個空格」做間隔，多了或少了都不行！這其實也是起因於 Python 沒有像 C++ 的大括號 { } 可以用來切割程式碼的層級，因此 Python 無法知道每個層級的開始與結束位置在哪裡，所以就必須要強制規定每個層級都是以「兩個空格」做間隔...

這對於程式設計師來說真是個惡夢！我在測試的期間就曾經因為不小心多按了一個 SPEACE 而跳出一個「怵目驚心」的花花綠綠錯誤警告頁面...當最後發現止是多按了一個 SPEACE 時，心裡著實有用力的喊了一聲「靠...」。


3.其實沒那麼難
基本上只要會寫 PHP 5(物件導向)、C++ 或 JAVA 的人，對於 Python 應該都會能夠快速的上手，因為 Python 用起來的感覺是「十分簡化後的 C++」，因此要使用「Google App Engine」這個服務的門檻其實沒有想像中的這麼高。





再來講講 BigTable。

這是我第一次聽到 BigTable 的名號，雖然經過閱讀一堆文件之後發現 Google 的很多產品都是使用這個資料庫，例如有名的 Google Analizy、Google Earth....等等，真是一個令人驚訝的事實阿！

而這更是我第一次接觸「非關聯式資料庫」，其實也不能這樣說，因為又經過閱讀一堆文件之後，我發現其實「非關聯式資料庫」的典型就是 EXCEL...也就是說，只要用過 EXCEL 的人，都可以自稱使用過「非關聯式資料庫」，只是使用深度上的差異罷了。

我得到以下 3 點心得：

1.丟掉正規化
要使用 BigTable 之前，首先要做的工作就是「把所有正規化的方法與技巧全部丟掉」，因為 BigTable 就像是一個 EXCEL 表格一樣，基本上是沒有必要正規化的，因為正規化的目的是在於「節省資料儲存空間」，而這個目標其實是「關聯式資料庫」的主要目標。

BigTable 的訴求完全不是這樣，BigTable 一開始設計時的主要目標就擺在「處理速度」，對於 Google 的服務來說，反應時間是首要考量，而反應時間要快就要使用叢集平行處理的技術，但正規化過後的資料大部分都只剩下「代號」，這對於叢集平行處理來說是個大問題！因為單一主機中所儲存的資料在沒有其它主機的表格做相互參照的情況下，會變得根本就沒有意義。試想今天你將數個已經正規化過後的表格，分別交給多個人持有，然後個別問他們表格中資料所代表的意義，大概就是那種況！

因此 BigTable 的設計，就像是一個「超大號」EXCEL 工作表，每一筆資料擁有超多的欄位。但在 Google 的眼裡，我們所謂的「超多」對他還說是「少量」，而且 Google 所說的是「欄位家族」(我自己翻的)會有數百個。(Google 的論文「Bigtable: A Distributed Storage System for Structured Data」中提到「It is our intent that the number of distinct column families in a table be small (in the hundreds at most)」)

欄位家族不是欄位，而是欄位的群組，也就是說一個欄位家族中會有很多個欄位...因此你可以想像，在 Google 眼中的「少量」到底有多少...

因此在這樣的架構下，一定要丟掉「所有正規化的想法」，回歸「自然」，然後你就會瞭解該要怎麼把資料儲存在 BigTable 裡面了，就像使用 EXCEL 一樣簡單！


2.不用 JOIN 好像也不錯
因為 BigTable 就像是 EXCEL 一樣，所以沒有 JOIN 這一回事！請試想在 EXCEL 裡面儲存正規化的資料，然後每看一筆資料就要去查另外的一堆表格才知道意義，那是一種何等痛苦的事？
在接受了 BigTable 就像 EXCEL 這個事實之後，我突然發現「不用 JOIN 好像也不賴」，因為取得資料變得超直覺，再也不用思考哪些資料存在什麼表裡面，需要怎麼 JOIN 近來效率才會好，因為取得的資料永遠都是「值」而不再會有「代號」了！


3.空間換取時間的優勢
Google 目前的伺服器數量與儲存空間在世界上是赫赫有名的！在這個儲存空間極度便宜的時代，我們真的還需要斤斤計較正規化所省下來的那一點點的儲存空間嗎？而且在叢集平行處理的加持之下，處理速度快得嚇死人的非關聯式資料庫真的有可能變成接下來的趨勢，至少 Google 帶起了這個可能性，不是嗎？





得到了這些心得之後，再回頭看「Google App Engine」好像也變得比較沒有這麼難搞了。接下來應該會有越來越多的應用在「Google App Engine」上面發生，我期待著所有有能力開發程式的人都可以簡單的取得一個良好的環境，為這個世界盡一份小小的力量，讓大家的生活更美好！

jQuery Plugin Demo 連結自動擷取(jQuery Plugin Demo Link Digger) for Firefox + GreaseMonkey

最近在玩 jQuery 發現他是一個設計良好的 Javascript 架構，可以讓程式設計師省去很多搞 DOM 的時間，只要要懂一些 CSS 就可以使用 jQuery 迷人的 CSS Selector 來取得所需的 HTML 物件，進而對此物件進行各種操作。

最棒的是，他提供了一個設計良好的 Plugin 架構，讓程式設計師可以把自己的創意或工作成果做成 Plugin 分享給大家，而其他程式設計師就不需要再時間去做別人已經完成的事情了～

如此一來也大幅的減低了使用 JavaScript 的門檻，基本上只要懂得 CSS、HTML 與簡單的 JavaScript 就可以使用幾乎所有的 jQuery Pligin 來為你的網站創造各種令人激賞的效果！



雖然 jQuery 這麼棒，但是 jQuery Plugin 的網站卻設計得讓人不敢恭維...

在 Category 頁面中，居然看不到每個 Plugin 的 Demo，而是要點入每個 Plugin 的 Project 頁面才「有機會」看到 Demo 連結，而且在 Category 頁面中也看不到使用者對此 Plugin 的投票評價...讓我才看了兩個 Plugin 就很火大...


因此我就寫了這個 UserScript：jQuery Plugin Demo 連結自動擷取(jQuery Plugin Demo Link Digger)

---

jQuery Plugin Demo 連結自動擷取(jQuery Plugin Demo Link Digger)

這個 UserScript 為您在 jQuery Plugin 的 Category 頁面，自動加上每個 Plugin 的 Demo 連結、Home Page 連結 與 使用者投評價，並使用字型大小的變化來增加此 Plugin 的評價識別度， 使用者評價越高 字體會越大、越粗！

背景的顏色則是用來識別 AJAX 資料的取得狀況：
[綠色] 代表 正在載入資料
[黃色] 代表 找到 Demo 連結
[灰色] 代表 找不到 Demo 連結

者投評價 會以 [V] 來顯示，越多 [V] 代表評價月高～



安裝網址( English with install )：
http://userscripts.org/scripts/show/26824

jQuery:
http://jquery.com/

jQuery Plugin:
http://plugins.jquery.com/project/Plugins

Library 編譯參數免煩惱～好用的 pkg-config！

時常在編譯程式的時候，會遇到找不到某個 Library 的 *.h 的問題，這個時候就要派出 pkg-config 來大顯神通了～

pkg-config 是一個會記住 Library 相關使用參數的好用工具，你可以利用它來取得編譯參數與其他有用的資訊。

pkg-config 通常會放在 /usr/bin/pkg-config
而設定檔通常會放在 /usr/lib/pkgconfig/*.pc

要用到某個 Library 之前就去 /usr/lib/pkgconfig 底下找找看相關的名字吧。
因為有時候 Library 的設定檔名稱後面會帶有版本號碼，不去看看的話很難猜出來到底應該指定的 Library 名稱是什麼。

---

假設有一個 test.c 要用到 dbus 這個 Library，這時 Makefile 可以寫成這樣：

Makefile

CFLAGS := $(shell pkg-config --cflags dbus-1)
LDFLAGS := $(shell pkg-config --libs dbus-1)


CC = gcc
LIBS=


SRCS=bluez-client.c

all:demo

demo:$(SRCS:.cpp=.o)
$(CC) $(CFLAGS) $(LDFLAGS)-o $@ $^ $(LIBS)


clean:
-rm -f demo
-rm -f *.o

簡單的透過 pkg-config --cflags dbus-1 就可以取得 dbus 的 CFLAGS，透過 --libs 參數同樣也可以取得 LDFLAGS。

如此一來以後就不用再擔心不知道 Library 要下什麼參數才能使用了～

利用 sudo 在 root 擁有的資料夾中 mkdir

使用非 root 帳號最常遇到的問題就是：沒辦法在 root 擁有的資料夾中 mkdir。

但是我又時常需要做一些測試與設定的動作，因此在此記錄一下要怎麼樣利用 sudo 在 root 擁有的資料夾中 mkdir，並安全的的轉移資料夾權限給自己。

---

Step 1.
切換到需要 mkdir 的資料夾底下。



Step 2.
執行
sudo mkdir [新資料夾名稱]

例如
sudo mkdir work



Setp 3.
執行
sudo chown -R $USER [新資料夾名稱]

例如
sudo chown -R $USER work



Setp 4.
完成了，ls -al 一下，就可以看到 OWNER 變成自己摟。

自訂 Console 的文字顏色

有鑑於 Fedora 的 kconsole 每次預設的 資料夾 文字顯示顏色都是深藍字，而我又喜歡用黑底的 console，最後的結果就是每次都看不清楚資料夾名稱。

因此在這裡記錄一下要怎麼修改 console 底下文字顏色的方法。

---

Step 1.
編輯 /etc/DIR_COLORS.xterm

找到這一段：

# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
NORMAL 00 # global default, although everything should be something.
FILE 00 # normal file
DIR 00;34 # directory
LINK 00;36 # symbolic link
FIFO 40;33 # pipe
SOCK 00;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 01;05;37;41 # orphaned syminks
MISSING 01;05;37;41 # ... and the files they point to



Step 2.
把這一行：
DIR 00;34 # directory

改成這樣：
DIR 00;34;46 # directory


之後存檔～




Setp 3.
重新開啟一個 console，這時候就會看到，所有的資料夾變成 淺藍底色 + 深藍字 了～
也可以改成其他的顏色，或修改其他項目喔！




ps.如果修改 /etc/DIR_COLORS.xterm 沒有用，那就修改這個檔案 /etc/DIR_COLORS 。
傳說中 /etc/DIR_COLORS.xterm 是給 X Window 用的，/etc/DIR_COLORS 是文字模式用的。

免密碼 sudo，保平安又免麻煩！

自從我的耍寶同事 Derek 用 root 帳號在自己的 Linux 環境底下執行了一個「迷樣的 Script」，並將環境徹底的摧毀之後，我就開始瞭解 Mark 老大說的：「不要用 root 亂搞！」是什麼意思了...

於是，跟 Mark 老大請教了要怎麼樣使用 sudo 最方便，但又可以保平安的方法～

在這裡做個記錄跟分享～

---

Step 1.
編輯 /etc/passwd

第一行應該長得像這樣
root:x:0:0:root:/root:/bin/bash

把第一個 x 拿掉，變成這樣
root::0:0:root:/root:/bin/bash

最後存檔離開～



Step 2.
編輯 /etc/sudoers

找到這一行：
# %wheel All=(All) NOPASSWD: All

把前面的 # 拿掉。

一樣存檔離開～



Step 3.

編輯 /etc/group

找到這一行：
wheel:x:10:root

在後面加上你想要讓他可以使用 sudo 的帳號，記得用逗號分隔，變成這樣：
wheel:x:10:root,firch

依然存檔離開～




Setp 4.
開開心心的使用不用密碼的 sudo～




ps.還是要節制的使用 sudo，否則哪天習慣成自然的把 sudo 拿來砍掉自己的系統，可不要來找我！