[筆記] SQL語法裡問號的功用

今天在寫程式的時候意外的看到一段SQL

    SELECT token FROM oauth_tokens WHERE userID = ? LIMIT 1

而其中的問號引起了我的注意，因為沒有看到userID在程式中出現，所以就查了一下SQL中問號的功用，後來在stackover裡面的這篇好到答案，才發現他其實是一個好習慣，所以就順便筆記下來了

問號的功能，是用來變數化SQL查詢

他一種安全的作法用來取代原來的寫法

    ODBCCommand cmd = new ODBCCommand("SELECT thingA FROM tableA WHERE thingB = 7")
    result = cmd.Execute()

這個寫法在thingB為固定值的時候沒有什麼問題，但是當你需要動態載入變數的時候，他就會需要寫成這樣（底下的方法是不建議的）

    string s = getStudentName()
    cmd.CommandText = "SELECT * FROM students WHERE (name = '" + s + "')"
    cmd.Execute()

我們就很直覺的使用字串串接的方式來將變數整合成一句SQL，但是這樣會面臨SQL injection的危險，因為當你要寫入的變數，是來自於你不信任的第三方（不論是使用者、或者是hacker）都有可能串接到無法預期的文字，好一點只是SQL statement Error，但是如果對方傳入設計過的字串，例如Robert'); DROP TABLE students; --，則結果會...

    SELECT* FROM students WHERE (name = Robert');
    DROP TABLE students;

就悲劇了，當然你可能會覺得他怎麼知道你的TABLE Name那又是另外一回事了.XD

所以

應該改用這種方式，除了程式有比較好的可讀性以外，還可以事先過濾使用者輸入的字串

    ODBCCommand cmd = new ODBCCommand("SELECT thingA FROM tableA WHERE thingB = ?")
    cmd.Parameters.Add(7)
    result = cmd.Execute()

當然你也可以使用php PDO的方式來寫入

    $query = 'SELECT token FROM oauth_tokens WHERE userID = ? LIMIT 1';
    $stmt = $this->pdo->prepare($query);
    $stmt->execute(array($this->userID));

都是一種好習慣也是一種好方法:D

pygame遊戲程式設計筆記<前言>

    心血來潮，想寫個網路應用程式來學習網路的操作，但是要寫出一個怎樣的程式或者應用，所以我更進一步的去設計這個想法，很巧的又看到以前的網路遊戲，於是，「何不做一個簡單的網路遊戲？」這個念頭由然而生，就開始上網找了很多的資料，發現遊戲引擎還是以C++和JAVA為大宗，當然現在很多前端的設計、AI還是會使用scripting language來編寫，其中不乏語法簡單，適合用來編寫遊戲的語言Lua的framework，在看過眾多資料後，最終決定使用python來當主力開發語言，雖然資源相對上算是少的，但是目前滿足我的需求上來說，是足夠的，所以在決定後就開始我的遊戲程式設計學習筆記了！

筆記-小型專案開發過程

這學期因為修課的關係，很巧的有兩個team project需要團隊去執行，整個過程雖然不算風風雨雨，但也總是有些不順遂，本想說在社群網站設計的期末展覽結束之後就整理心得，也比較不會忘記當下的想法，不過因為要準備去杭州的比賽以及搬家就先被擱置了，不過在思考沈澱以後，寫下一些筆記也是不錯的。

隊友：

首先，你不得不承認找隊友是件很重要的事情，因為如果找到很強大的隊友他就能將整個專案一手包辦，如此，你就可以很輕鬆的完成這個專案，當然，如果你想要也一起參與這個專案，我想事實的拿出積極度與參與討論都是很重要的，而對於一個專案的需求，會需要不同領域不同能力的隊友也是可以預見的，不過我有幾點覺得應該注意：

1. 不因為人情選擇你的隊友
• 因為人情選擇你的隊友，往往使得你們在以後會變得更加難堪，在專案討論的時候，從概念的討論到最後的成品，中間的過程中會有無數次討論甚至爭執，如果因為人情選擇了一個不太好合作的朋友，反而會因為這次的合作使得兩個人因概念上的差異直接產生衝突，所以與其一開始因為人員配置的考量而拒絕對方，也不要因為人情壓力而選擇同組，這對兩個人都不會是件好事情。
2. 不嘗試去改變對方的想法，認為好的領導就是不管什麼樣的人都可以領導
• Mr. Jamie網誌中曾提過，「其實沒有一個人是壞掉的，你也往往無法改變他人。與其浪費時間在你無法改變的人身上，還不如去找那些願意接受你的想法的人。」，這點我很認同，千萬不要自己為自己可以改變別人，否則當對方依照他的思維模式在做的時候，吃虧的往往是自己。
3. 不過份重視過去，但也別小看前科
• 過去的經驗雖然輝煌，但每次的合作有很大的部份還是全新的一個過程，過去的經驗與戰績未必在這次合作中會起作用；但是，也別小看過去對方是否有不良的經驗，或是不好的態度，如果有，還是在找伙伴時就把他檔在門外吧！！！

溝通：

團隊溝通也是很重要的，如果可以還是建議使用專案管理的協助工具（git、wiki）來協助開發，並且定期討論，而每次進度回報最好能夠完成下面幾點的答案：

1. 甘特圖
2. 進度達成度
3. 下次預定進度

而除此之外，團隊也要養成將遇到的問題筆記的習慣，可以讓在開發類似性質的專案時，減少自行解決問題的成本。

合作：

這次的合作過程中，很榮幸的能夠和設計的朋友一起合作，而當然也有碰到些問題，其實這次合作的過程中設計師是比較隨和的，也許是考量期末展快近了，很多設計被完成出來時其實不完全能夠達到當初設計的概念，例如距離的誤差、按鈕被碰觸時的互動，但若是設計師跟切版者不能是同一人的話，設計師在出圖的時候最好能夠一起附上：

1. 原始設計圖：最好是可以模擬瀏覽緝獲者手機上瀏覽時的真實情況，並且考慮不同解析度相容性問題，如果今天解析度過小或者過大要怎麼處理。
2. 框架圖：每個元件跟元件間的位置，如果有顏色，也需要將色碼寫在旁邊，越詳細越可以減少切版時的微調成本。
3. 動態元件分鏡圖

如果這些東西都齊全了，就只要附上元件圖，如此可以將切版的成本降到最低。

而和程式設計師合作，則是門大學問，市面上有許多書籍在討論，小弟也不夠清楚，不過有幾點我覺得在簡單的專案中可以減少許多溝通成本，以及將討論的時間大幅下降：

1. 高內聚低耦合的架構設計，如此除了方便切割每個元件的責任歸屬，如果有想要作測試，這種方式也是比較好測試的一種程式設計技巧。
2. 寫文件，沒錯，就是幫自己設計的元件寫文件，每次要趕著作業的deadline時，常常會聚在一起趕作業，但是其實一個程式設計師在自己熟悉、舒適的環境中寫程式的效率是比較好的，大家聚在一起其實是降低了個別的生產力，但是之所以聚在一起是因為「我不知道你寫了些什麼」、「我不懂你程式的流程應該要怎樣串街」等等的問題，而除了真的因為架構比較旁大的元件需要當面討論外，很多時候其實只要將文件寫好供其他開發者查找，就可以解決這個問題了，而在每個元件最基本應該要有的資料最好也獨立處理，例如每個參數是用來做什麼的、回傳什麼東西、回傳的物件是實例還是參考等等的資訊，都可以透過團隊討論制定好統一文件規格來撰寫，如此就可以降低溝通成本了。

以上是我一點心得的筆記，如果有什麼更好的建議或者不一樣的想法歡迎交流。

[python]dict[x]後串接list()

使用python寫程式時，會遇到需要整理資料的場合，最好是用資料的類別或者ID做索引，對於資料的呈現或是寫入資料庫時，程式都有比較好的架構，但是python只有支援dictionary和list並沒有整合的data structure，所以要自己寫一個。
因為當初自己寫時有遇到些問題，所以配合這一篇，把寫法記錄下來，希望對要用到的人會有幫助。

1. 在要新增一筆資料的時候檢查是否已經被初始化為list

d = {}
d[key] = list()
d[key].append(value)

初始化後就可以使用.append()當成list用了，不過需要檢查是否已經被初始化過了，避免重複初始化。
initialize

d = {}

check

if key not in d:
    d[key] = list()
d[key].append(value)

2. setdefault

initialize

d = {}

setdefault

d.setdefault(t,list()).append( c )

會將dictionary預設為list()

修改 :link :visited :hover等等CSS的預設屬性

    在寫網站CSS的時候，有會需要將一段文字超連結，所以會在文字外圍使用<a>這個標籤包覆，問題是CSS有預設:link :visited :hover的一些特性，所以可能導致自己寫得內容被覆蓋過去，這個時候在CSS檔案裡面的開頭加上

a:link
    color:inherit;
    text-decoration:inherit;
}
a:visited{
    color:inherit;
    text-decoration:inherit;
}

a:hover{
    color:inherit;
    text-decoration:inherit;
}

就會去看是否樣式已經被設定好了，如此自己寫得樣式就不會被覆蓋過去了。

打造你的專屬VIM Editor - 簡報釋出

        會有想要講這個的念頭是因為看到小畢的那場talk，其實我們很早就在預謀了(誤)，在很爽快地訂日期之後馬上想到當天是自己生日，但是自己想要有個跟以往不一樣的生日，所以選擇了扛下這場演講，而且當消息放出去以後，自己就會強迫自己檢視自己到底學會了什麼，順便把以前想要學的，但是總是沒時間的技巧拿出來徹底研究，也整理了.vimrc，並認真思索怎樣才可以把一個這麼好的編輯器推廣到大家手上，也希望可以透過演講降低使用vim的門檻，選擇了一個這麼刺激的事情來當自己的生日禮物其實還蠻特別的，但是明年我會選擇吃蛋糕唱歌XD

talk (4/12): 打造你的專屬VIM Editor - Create an editor belong to yourself.

「生一個VIM會不會比較快？」...

「還在用難用的IDE寫CODE嗎？」
「如果今天你有多台電腦，還在一一調整編輯環境嗎？」
「你擁有24吋大螢幕，卻還只用14吋小空間來寫程式嗎？」
「用筆電寫程式，如果沒帶滑鼠，就像是行走在程式大漠中窒礙難行嗎？」
「常常覺得同樣的事情，但是要按很多鍵很麻煩，但又沒辦法寫個script來完成很不方便嗎？」

VIM不是什麼，
VIM是什麼！

        VIM是一個開起來很快，寫起來也很快，放棄起來更快的純文字編輯器，他有著系統預設很好的游標移動能力，跟複製、可數的操作性，是程式快速編輯不可或缺的強力大手，但是自從大一被強迫接觸他以後，很多人對他有很深的誤解，因為「他只不過是可以編輯文字的黑嘛嘛的東西。」很多人在DEV C++寫完作業以後，也只是簡單的vi :wq然後下gcc的指令去看看程式在伺服器上有沒有問題，而且他討厭的地方有很多，例如不能使用滑鼠、輸入文字要按i、存檔還要打指令，但是這其中一定有什麼誤會，其實VIM是很耐斯的，這次分享雖然不冀望會有人跳過去使用他XD，但至少知道他可以幹什麼，如果你今天要換編輯器的時候會考慮過他，減少世人對他的誤會。

        而之所以要用VIM是因為程式設計師寫程式最常接觸的，不是IDE的整合介面，也不是花花綠綠的功能列，是文字編輯介面的本身，如果是使用比較普通的IDE，最基本的要求一定是「行號」、「縮排」、「syntax highlight」，更多一點，是加速編輯的熱鍵，那如果今天打錯了，要修正怎麼辦？當然你可以說「很簡單，移動到滑鼠上點選你想編輯的地方，或是選取你想刪除的地方，或是說使用鍵盤上的←↑↓→。」直覺，但是很慢；但是如果你今天使用的是VIM，只需要切換模式（甚至不用切換），就可以利用操作和數字的組合出快速的移動並且隨心所欲的修改。

        分享的過程中，會從文字編輯器最常用到的功能開始分析比較VIM和IDE之間的差異，告訴你如何選擇一個適合你的文字編輯器，即使你最後的選擇不是VIM，也希望你知道如何找一個好的歸屬，而不是隨著程式語言漂泊在不同的IDE上；而在你熟悉基本操作之後，如何去安裝第三方的plug-in讓你的編輯速度可以快速攀升，而不在只是停滯在前面的曲線。

時間：4月12日 晚上7:33
地點：成大資訊系館 4261 教室
講者：魏聖儒 (老魏/Lucas)
講題：打造你的專屬VIM editor

一起來打造屬於你的editor \^O^/