Data Structure說是資訊學院的精華所在，如果有人反對，應該不是唸CS的吧。長官又指定一個其他組員搞不定的工作過來了，任務是因應組織調整，變動人事資料表，但是資料來源是LDAP，沒有開發大量讀取的權限，最棘手的是，資料來源不是常見的關聯式資料，如Oracle或Informix，不單單是搞定ODBC Driver就ok了，那該怎麼辦呢?
--
Data Structure說是資訊學院的精華所在，如果有人反對，應該不是唸Computer Science的吧。鏈結串列、Binary Tree、B-Tree、in-order、pre-order、post-order、recursive，等等不但是程式設計的延伸，還必須承接後續高年級課程，如人工智慧要用到決策樹，不但是計算機概論常出考古題的所在，在考研究所或國家考試時，也常是必選科目。
長官指定一個其他組員搞不定的工作過來了，任務是因應組織調整，變動人事資料表，但是資料來源是LDAP，沒有開放大量讀取的權限，一次只能抓一筆，最棘手的是，資料來源不是常見的關聯式資料，如Oracle或Informix，不單單是搞定ODBC Driver就ok了，那該怎麼辦呢?
我先到書局罰站了一下，帶回了一本Visual C++的書，然後我引入ladp的dll，連上ldap主機，先抓取一筆人員資料看一下，我所要的姓名、組織代碼，年齡，電話甚至學歷都有，另外再抓取一筆單位資料，發現了裏頭有上層組織的代碼，這不就是樹狀結構，這時候，求學時代所學的Data Structure就派上用場，要dump出來有兩個做法，一個是先深(DFS)，一個是先淺(BFS)，我比較懶惰，不想去寫queue或是找STL，我就利用遞迴呼叫就是一種堆疊的觀念，實作先深尋訪，抓出了六個分公司當root，呼叫完遞迴後，就成功的完成了這個專案，再排入這個AP後，後來的組織整併，就與我們沒有關係了，因為都自動處理好了。
昨天在PTT的Soft_Job板上爬文，看到有人抱怨，上104找來的面試的人，DFS與BFS都搞不清楚，還好至少我還記得修課時教什麼，因為期中考考過BFS。
2011/9/30
資訊學院的30堂課-資料庫管理 DataBase
之前開發一套車輛管理系統，車籍資料超過80個欄位了，資深的長官指示車籍資料分成會異動的一個表格，不會變動的另外一個表格，當時剛到公司的被稱為小朋友，長官說甚麼，就只好幹甚麼，這卻是災難的開始。
資料庫管理系統，課程主要精神就是在教EDR與正規化，正規化很重要，一個系統的效能在於適當地切割資料表，沒有正規化的資料庫，很容易發生資料不匹配的問題，而導致於coding時事倍工半。修課當時，也只是照著課本做，其實對於如何合適地使用SQL語法，是上班之後的事了，不過我覺得對於語法效能最有幫助的課反而是Data Structure，order by就不用說了，排序最少是O(N*logN)當我下了一個group by或者union，腦袋瓜要馬上閃過，這樣子在實際上執行時，花費的時間複雜度是否可以接受。另外，偶而會幫忙同事turning語法，新手最容易犯的錯誤，就是查詢網頁時，資料看不到，原因就在於inner join與left join的不同。
再來是索引的運作，大部分的所以都是使用B-Tree結構來節省查詢的時間，樹狀結構可以把線性搜詢所需要的O(n)時間，reduce到O(logN)，如果資料結構B-Tree的那個章節有認真學的話，使用B-Tree的好壞處很快就可以理解，自然也知道最適合加入索引的時間。
之前開發一套車輛管理系統，車籍資料超過80個欄位了，資深的長官指示車籍資料分成會異動的一個表格，不會變動的另外一個表格，當時剛出社會時，被年長20歲的前輩，稱為小朋友，長官說甚麼，就只好幹甚麼，這卻是災難的開始。這樣設計的下場是甚麼呢，就是超級慢的查詢速度，車籍資料有4000筆，兩個表格進行join後，產生4000*4000這麼大的笛卡耳積，先不論資料庫系統進行的什麼優化，或者有設定索引，光就時間複雜度的觀點，就慢了4000倍，這80欄的車籍資料，在大部分的頁面，都需要讀取兩個表格，後來跟我同組的同事討論後，決定合併這兩個表格，結果速度就馬上有明顯的提升，因為長官這一個決策錯誤，全部的code翻起來review一次。
不知道CS哪一門課，教把會變動的資料與不會變動的資料，分開來存放的，是！有的，剛好我們大學開了一門很冷門的課課，叫做檔案結構，不是資料結構喔，這樣存放的確可以減少讀取到記憶體的資料量，但是我們系統的最終儲存目的地是資料庫，而不是自己維護的檔案，所以長官應該是沒有修過資料庫管理系統，甚至於資料結構，經後來他的談話之後，還真的耶，他的開發經驗就是C語言加檔案結構，後來他就沒有再插手系統設計的部分了，只安排了我們做什麼工作，什麼時候交出來而已。
資料庫管理系統，課程主要精神就是在教EDR與正規化，正規化很重要，一個系統的效能在於適當地切割資料表，沒有正規化的資料庫，很容易發生資料不匹配的問題，而導致於coding時事倍工半。修課當時，也只是照著課本做，其實對於如何合適地使用SQL語法，是上班之後的事了，不過我覺得對於語法效能最有幫助的課反而是Data Structure，order by就不用說了，排序最少是O(N*logN)當我下了一個group by或者union，腦袋瓜要馬上閃過，這樣子在實際上執行時，花費的時間複雜度是否可以接受。另外，偶而會幫忙同事turning語法，新手最容易犯的錯誤，就是查詢網頁時，資料看不到，原因就在於inner join與left join的不同。
再來是索引的運作，大部分的所以都是使用B-Tree結構來節省查詢的時間，樹狀結構可以把線性搜詢所需要的O(n)時間，reduce到O(logN)，如果資料結構B-Tree的那個章節有認真學的話，使用B-Tree的好壞處很快就可以理解，自然也知道最適合加入索引的時間。
之前開發一套車輛管理系統，車籍資料超過80個欄位了，資深的長官指示車籍資料分成會異動的一個表格，不會變動的另外一個表格，當時剛出社會時，被年長20歲的前輩，稱為小朋友，長官說甚麼，就只好幹甚麼，這卻是災難的開始。這樣設計的下場是甚麼呢，就是超級慢的查詢速度，車籍資料有4000筆，兩個表格進行join後，產生4000*4000這麼大的笛卡耳積，先不論資料庫系統進行的什麼優化，或者有設定索引，光就時間複雜度的觀點，就慢了4000倍，這80欄的車籍資料，在大部分的頁面，都需要讀取兩個表格，後來跟我同組的同事討論後，決定合併這兩個表格，結果速度就馬上有明顯的提升，因為長官這一個決策錯誤，全部的code翻起來review一次。
不知道CS哪一門課，教把會變動的資料與不會變動的資料，分開來存放的，是！有的，剛好我們大學開了一門很冷門的課課，叫做檔案結構，不是資料結構喔，這樣存放的確可以減少讀取到記憶體的資料量，但是我們系統的最終儲存目的地是資料庫，而不是自己維護的檔案，所以長官應該是沒有修過資料庫管理系統，甚至於資料結構，經後來他的談話之後，還真的耶，他的開發經驗就是C語言加檔案結構，後來他就沒有再插手系統設計的部分了，只安排了我們做什麼工作，什麼時候交出來而已。
crapto1.c
/* crapto1.c
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, US$
Copyright (C) 2008-2008 bla <blapost@gmail.com>
*/
#include "crapto1.h"
#include <stdlib.h>
#if !defined LOWMEM && defined __GNUC__
static uint8_t filterlut[1 << 20];
static void __attribute__((constructor)) fill_lut()
{
uint32_t i;
for(i = 0; i < 1 << 20; ++i)
filterlut[i] = filter(i);
}
#define filter(x) (filterlut[(x) & 0xfffff])
crypto1破解軟體
居然在維基百科就有連結
而且開宗明義說 機乎是沒有保護狀態
http://www.dexlab.nl/downloads.html#emulator
這邊把演算法說的很清處
http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf
而且開宗明義說 機乎是沒有保護狀態
http://www.dexlab.nl/downloads.html#emulator
這邊把演算法說的很清處
http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf
冰淇淋三明治之後，Android下一代作業系統要叫做Jelly Bean？
根據美國科技網站ThisisMyNext報導，Google下一代Android系統還是跟「甜食」脫不
了關係，代號極有可能為「Jelly Bean」（雷根糖），也意味著跟著I系列（Ice Cream
Sandwich，冰淇淋三明治）之後，「J」系列作業系統蓄勢待發。
再說回還未推出的冰淇淋三明治作業系統，今年五月Google開發者大會首次公開系統功
能，大家普遍認為這是要將智慧型手機和平板電腦不同的Android版本合併的開端，目
前智慧型手機採行的Android系統代號為「Gingerbread」，平板電腦則為
「Honeycomb」。最新傳出三星將會推出Ice Cream Sandwich平台的Nexus Prime智慧型
手機，就連董事長施密特也親自表示十月或十一月就要推出。
以目前來看，Google新版Android「Ice Cream Sandwich」將整合手機與平板平台使用
情境，其中也包含了不少有趣的應用，例如對應NFC、透過相機進行圖像辨識或是整合
數位家電控制等。而在目前，Google下一個以「J」為開頭的Android版本似乎也準備開
始有消息？
相關情報從This is my網站的消息來源所透露，表示接續整合手機與平板使用情境的
「Ice Cream Sandwich」的下一版Android，其名稱將會是「Jelly Bean (雷根糖)」。
不過，由於目前Google官方尚未正式公佈「Ice Cream Sandwich」實際版本編號，因此
目前也無法確認「Jelly Bean」將會是什麼版本。
而從相關消息來源所透露說法，「Jelly Bean」主要將會著重於「遊戲規則」方面上的
改革，不過並沒有太多關於這方面的消息，從Google去年便一直強化針對以HTML5打造
web遊戲內容的應用，甚至目前在Chrome Web Store中也有不少遊戲存在 (而且今年的
Google I/O大會也請來《Angry Bird》開發商Rovio執行長Peter Vesterbacka擔任背
書)，後續也針對Google+開設了遊戲服務，或許下一步將會透過Android平台進軍行動
遊戲市場？
但目前看起來，「Jelly Bean」僅只是其中一種可能的名稱，至少Google似乎還沒有作
出最後決定，但可以確定下一版Android名稱一定是以「J」為開頭的甜點名稱。
現在還沒有比較確定的「Ice Cream Sandwich」正式釋出時程，即便先前的傳聞已經有
消息"透露"下一款Nexus手機仍為三星製作，不過進一步消息可能還是要等Google官方
公佈。至於時間的部份，先前傳聞最快會是在今年10月，而Google董事長Eric Schmidt
的說法則是表示會在10月或11月之間，但看起來應該會比先前兩款Nexus手機發表時間
還要早一些？
了關係，代號極有可能為「Jelly Bean」（雷根糖），也意味著跟著I系列（Ice Cream
Sandwich，冰淇淋三明治）之後，「J」系列作業系統蓄勢待發。
再說回還未推出的冰淇淋三明治作業系統，今年五月Google開發者大會首次公開系統功
能，大家普遍認為這是要將智慧型手機和平板電腦不同的Android版本合併的開端，目
前智慧型手機採行的Android系統代號為「Gingerbread」，平板電腦則為
「Honeycomb」。最新傳出三星將會推出Ice Cream Sandwich平台的Nexus Prime智慧型
手機，就連董事長施密特也親自表示十月或十一月就要推出。
以目前來看，Google新版Android「Ice Cream Sandwich」將整合手機與平板平台使用
情境，其中也包含了不少有趣的應用，例如對應NFC、透過相機進行圖像辨識或是整合
數位家電控制等。而在目前，Google下一個以「J」為開頭的Android版本似乎也準備開
始有消息？
相關情報從This is my網站的消息來源所透露，表示接續整合手機與平板使用情境的
「Ice Cream Sandwich」的下一版Android，其名稱將會是「Jelly Bean (雷根糖)」。
不過，由於目前Google官方尚未正式公佈「Ice Cream Sandwich」實際版本編號，因此
目前也無法確認「Jelly Bean」將會是什麼版本。
而從相關消息來源所透露說法，「Jelly Bean」主要將會著重於「遊戲規則」方面上的
改革，不過並沒有太多關於這方面的消息，從Google去年便一直強化針對以HTML5打造
web遊戲內容的應用，甚至目前在Chrome Web Store中也有不少遊戲存在 (而且今年的
Google I/O大會也請來《Angry Bird》開發商Rovio執行長Peter Vesterbacka擔任背
書)，後續也針對Google+開設了遊戲服務，或許下一步將會透過Android平台進軍行動
遊戲市場？
但目前看起來，「Jelly Bean」僅只是其中一種可能的名稱，至少Google似乎還沒有作
出最後決定，但可以確定下一版Android名稱一定是以「J」為開頭的甜點名稱。
現在還沒有比較確定的「Ice Cream Sandwich」正式釋出時程，即便先前的傳聞已經有
消息"透露"下一款Nexus手機仍為三星製作，不過進一步消息可能還是要等Google官方
公佈。至於時間的部份，先前傳聞最快會是在今年10月，而Google董事長Eric Schmidt
的說法則是表示會在10月或11月之間，但看起來應該會比先前兩款Nexus手機發表時間
還要早一些？
訂閱：
文章 (Atom)