前兩天突然覺得家裡的電腦變的很慢
突然警覺是不是硬碟快壞掉了
用了 Windows 的磁碟修復, 後又恢復正常,
後來無聊查了一下我這顆硬碟的型號, 發現原來我這顆是3年前
Seagate 出包的那顆死雞硬碟, 上了 plurk 慶幸了一下
趕緊就做了韌體的更新… 沒想到原本 SMART 沒有錯誤的
一更新完就出現紅字 = =, 想說是不是快爆炸了
順便打開 hdtune 掃描, 就跑去睡覺了..
結果隔天早上起來就出現 = =…找不到開機磁區的訊息
真的是心頭一驚啊
我又重開了一次, 幸好還可以進入 windows..
心想大概硬碟真的快壞了吧…趕緊關機..
接著就把電腦關機把硬碟帶去公司備份
一開始還找的到磁碟資訊, 沒想到越copy 越慢, 時間跑到2天去了 = =..想說是不是 USB沒插好, 重插… 結果跳出了一堆視窗 顯示磁碟損壞, 您必須要格式化才能使用… 真的是當下無言
只好把久久未用的 testdisk 拿出來掃了… 只是東按按西按按, 好像不太對勁
testdisk 是可以把 partition 找回來, 但我的檔案咧~~!! 全都不見了!!
只好搬出了 O&O Disk Recovery 花了大半把時間, 掃描, 終於看到熟悉的檔名 …
結果匯出才知道… 這些檔案全壞的..
存文字檔案打開 所有的開頭都被截掉了, 反而是屁股多了一堆有的沒的亂碼..
我在想大概是程式沒寫好檔案位置的 offset 有問題… 但是也沒辦法
後來索性按了testdisk 中的 PhotoRec 沒想到掃出檔案來了, 不過是沒有目錄結構的檔案, 亂成一團, 我種不可能一個一個分吧, 但至少知道 檔案是還弄的出來的, 只是要找什麼軟體才能正確的匯出目錄結構 還有檔案
後來就想著從 NTFS 專用的 DiskRecovery 程式找, 終於找到了一套還不錯的 GetDataBack 比起 O&O DiskRecovery 聰明的是他面對不明的(RAW) Partition 至少不會出現整顆硬碟的大小, 還掃半天
掃描完以後目錄果真也出來了, 點選檔案也可以看, 正打算copy 出來時
跳出… 您未購買該軟體的訊息… 接下來大家知道怎麼做了吧..
不過後來查了一查 NTFS 的檔案資訊會存在 MFT , 而 MFT 也有備份, 叫做 MFT Mirror, 而 testdisk 能做的修複就是從 MFT Mirror copy 回原本 MFT 的位置, 但是…
如果兩個都不存在就沒有用了, 但天無絕人之路,
其實還是可以透過最原始的方式去掃描 Sector 找到部份的 MFT 組合成完整的
也就是 GetDataBack 這套軟體做的事
再差的話, 就是用 testdisk 中 PhotoRec 一個一個掃描 Sector 把特定檔案鐅型的資料撈出來, 不過這種做法, 只能針對常用的檔案, 因為他是去比對檔案的 header 來藉此分析, 不常見的檔案沒有搜尋的依據自然沒辦法找回來, 同時你的檔案結構就會遺失, 也就是說, 你可能還要花大把的時間去整理, 不過如果真的窮途末路也只能這樣了
參考文件: http://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair
參考文件2: http://www.wuziq.com/weblog/node/965
用繼承的方式果然好搞很多, 直接攔截事件開始處理…
又可以重複使用
dojo.declare("dijit.MyTabContainer" , [ dijit.layout.TabContainer ] ,
{
postCreate : function() {
var childId = dojo.cookie(this.id);
var tabContainerId = this.id;
if (childId !== undefined) {
// use dojo.addOnLoad to avoid tab content not ready.
dojo.addOnLoad(function() {
var selectedChild = dijit.byId(childId);
if (selectedChild !== undefined) {
dijit.byId(tabContainerId).selectChild(selectedChild);
}
});
}
this.inherited(arguments);
},
selectChild : function(selectedTab) {
// save selected tab id
if (selectedTab !== undefined) {
dojo.cookie(this.id, selectedTab.id , { expires : 365 });
}
this.inherited(arguments);
}
});
SVN: 常用管理分支(Branching)方式
好久沒 PO 文了, 自從開始工作之後越來越少時間能做一些有的沒的事, 包含分享一些東西, 以前看不懂英文, 總覺得為什麼中文的資源總是這麼的少, 現在看的懂英文卻懶的將這些文章一一的翻譯成中文, 看的速度遠比打字的速度還要快, 我這條小鯨魚有時也只能量力而為。
或許很多人都對 SVN 不陌生, 也了解 Version Control 的意涵, 但在實際的開發上, 不僅僅只是要會用這些工具, 而是要能將這些東西合理順暢的在團隊的運作中使用. 並且讓所有人了解, 在我第一次將 SVN 導入開發團隊的工作中也吃了不少苦頭, 絕大多數沒有 Version Control 概念的使用者, 沒有辦法理解這樣的制度, 『為什麼要 commit, 要 update 這麼麻煩』, 『我的程式碼一 update 後就壞了怎麼辦』, 更有人是放出大絕招, 把檔案直接砍了用自己原本的蓋回去, …也就是跟別人 conflict 的東西全消失了…只剩他的, 換言之別人的心血也全沒了…。
SVNBook 其實很詳盡, 但內容太多, 所以我只能就有需要的部份翻譯, 讓大家了解概念, however, 剛好今天抽了點時間把 SVNBook 中 Common Branching Patterns 的內容做了一點翻譯, 裡面說明實務上管理 branch 常用的方式.
————————————————————————————————————————-
SVN-常用的分支方式
SVN 中分支與合併有很多不同的用法，這個小節只說明常用的幾種方式。
版本控制經常被用在軟體的開發上，這裡介紹兩個程式設計師所最常使用的方式。如果您目前並非使用 Subversion 做為軟體開發的工具，您可以跳過此節。如果您是個第一次使用版本控管系統的軟體開發者，那就需要認真了解，因此這幾個方式是被有經驗的使用者認為最適合做 為範例案例。以下談到的流程並不僅限用於 Subversion，也可以應用在其他的版本控管系統。
發佈用分支(Release Branches)
大部份的軟體常見的生命週期為: 開發(Code), 測試(Test), 發佈(Release), 循環(Repeat)。在這樣的流程式當中會有兩個問題:
第一, 開發團隊需要開發新的功能的同時, 品管團隊需要持續的測試來維持軟體的穩定性, 新的開發工作並沒有辦法等待軟體測試而中斷。
第二, 開發團隊通常需要去維護舊有已發佈的版本，若在這些舊有的版本中發現問題，客戶會想要立即修正目前的問題，而不想等待其他新的主要功能開發完畢才發佈的版本。
這就是版本控管所能解決的問題，常見的處理流程如下：
- 開發團隊會持續送交(Commit)所有新的開發內容到主幹(Trunk)。
開發團隊每天都會不停持續的修改並且將修改的內容送交到 /trunk: 不論是新功能、問題修正、等等。 - 將主幹複製成為 『發佈用』 分支。
當開發團隊認為軟體已經可以準備發佈 (例如: 1.0 release), 則會從 /trunk 複製一份分支到 /branches/1.0。 - 開發團隊與品管團隊同時進行工作。
品管團隊對要準備發佈的分支進行測試，而開發團隊則繼續開發 (例如: 2.0) 於 /trunk，如果發現有錯誤同時存在兩個分支，則會將問題的修正移植(Ported)到分支，並且繼續開發。在任何時間都可以做這件事，即使開發的流程 已經中止。當最終的測試完成時會將分支凍結(Frozen)停止修改並等待發佈。 - 將分支標記(Tagged)並且正式發佈。
當測試結束，/branches/1.0 會被複製到 /tags/1.0.0 做為備份，並且將已標記的版本打包(Packaged)並正式發佈給客戶。 - 當分支維護一段時間後。
當 2.0 的開發工作一直持續在 /trunk 進行，錯誤的修正也會持續從 /trunk 移植到 /branches/1.0。當累積足夠的錯誤修正，管理者可能會決定發佈 1.0.1 release: 再將 /branches/1.0 複到 /tags/1.0.1，並將 /tags/1.0.1 打包並發佈。
整個流程不停的重複循環，當 2.0 開發工作完成，則會建立新的 2.0 發佈用分支，經過測試、標記直到最後的正式發佈。
幾年過後，儲存庫(Repository)上會有數個以 『維護中(Maintenance)』 的狀態存在的分支(Branch)，並且有數最終已發佈的版本的標記(Tag)。
開發用分支(Feature Branches)
特色分支(Feature Branches)，這邊稱做開發用分支，它是一個暫時的分支，用在複雜的開發工作，可以避免影響 /trunk 的穩定性。與發佈用分支不同的是 (可能需要永久維護)，開發用分支最終會合併(Merge)回到主幹，然後永久移除。
開發用分支的使用時機會隨著專案的管理政策有廣泛影響。
有些專案不使用開發用分支: 這些專案將所有的修改都送交到 /trunk，這樣的好處是管理方式非常的簡單–沒有人需要學習分支(Branching)與合併(Merging)的管理。缺點是主幹的程式碼時常處 於不穩定(Unstable)或不可用(Unusable)的狀態。
也有一些專案會極端的使用分支: 沒有任何的修改會直接送交到主幹，即使修改內容非常微小、使用的分支的時間非常短暫，也會一一經過嚴密的審查(Review)過後才合併到主幹，然後分支才會被移除，這樣的管理方式使主幹擁有異常的穩定性及可用性，但會耗費巨大的開銷。
大多數的專案會採用中傭之道，這些專案堅持使用 /trunk 開發並且測試。但需要大量的修改會使送交的內容不穩定的時候，就會使用開發用分支。良好的經驗法則是先考慮以下的問題：如果開發人員獨立開發數天並一次送 交大量的修改內容 (為了維持 /trunk 在穩定的狀態)，這樣的修改幅度是否會導致管理人員審查? 如果您的答案是 『是』，那麼這些修改應該在開發用分支中進行。因為這樣開發人員能將修改內容逐一送交到分支，而不是一次送交大量的修改內容，如此一來管理人員就能較輕易 的去審查這些修改內容。
最後, 還有一個問題是如何保持開發用分支與主幹的內容保持同步(Sync)。如先前所提到的，讓一個分支獨立開發數週或數月有很大的風險，主幹依然會持續開發，在這樣的情況之下若主幹與分支的開發內容差異過大，那合併分支回主幹的工作將會成為一場惡夢。
這個問題最好的解決方法是定時的合併主幹的修改內容到分支。訂定一個方針: 每週一次, 將最新一週主幹的開發內容合併到分支。
直到一直都有在進行同步的開發用分支要準備合併回主幹。要將分支合併回主幹，需先將最新版本的主幹內容合併至分支，這個動作是確認除了您在分支所修改的內容以外，其餘的部分會與主幹完全相同，最後使用 –reintegrate 參數將分支合併回主幹。
————————————————————————————————————————-
原文的參考文件其實很多, 我隨便挑了一個, 可以參考以下網址的圖片會更容易了解
http://paulhammant.com/blog/branch_by_abstraction.html
軍旅生涯中難忘的一天
這會是一個我在軍旅生涯中難忘的一天
這也是軍旅中的第一篇文章, 因為我想好好保留
接了參三業務, 雖然很忙, 很少自由時間, 也有很多事沒做好, 被長官罵
其實當兵真的就是看你願意花多少心思做多少事
長官也不會特意要求義務役的兵去做什麼特別艱難的事,
因為時薪八塊半, 擺爛有理, 我很慶幸能遇到好長官
但業務其實還是很忙, 壓力大, 比起其他兵
連長常說, 來到東引已經夠倒楣了, 又來到東引的防X連, 連長這麼凹, 弟兄也比其他連還要累, 還要精實
小抽1抽1沒抽到, 已經夠倒楣了, 又來到防X連, 接了業務, 根本是天註定, 所以我也很認命, 但也時常有想放棄的念頭 (沒事做什麼業務啊)
我很高興在軍旅生涯中這個特別的日子, 我的朋友們沒有忘記我, 寄了一些零食, 禮物
呵呵, 收了三次包裹, 就只有開心能形容啊
本來以為 4/16 在軍中會是一如往常的一天, 但奇妙的事發生了…
晚上像平常一樣被幹的 開完了課前會議, 下去盥洗作業, 每次開完會就是一大堆事要做
到了9點, 集合時間到了, 參三突然被輔導長點起來
『建瑋, 快給我去拿課表, 馬上, 不然你就死定了』
心想, 『靠, 不會又出包了吧』
二話不說的我就衝出去把課表拿回來…
就在輔導長正要飆我的時候…, 突然看見我的好同踢 仁和兄 居然拿了一個大蛋糕進來
東引這種鳥地方那來這麼大的蛋糕
我心想 『er… 今天是什麼日子, 四月份慶生嗎? 挑在這個時間也太怪了吧 = =…』
因為平常都只有月底加菜時才會慶生…
就聽到輔導長破口大罵 『黃仁和, 又是你, 都被你搞砸了, 你這麼早進來做什麼』
看到這裡, 大家或許不是很明白發生了什麼事, 對.. 我也不是很明白
Trac – Page2Docbook on FreeBSD
Docbook 是一種來輸出書藉的 XML 格式
Trac 中可以將 Wiki 的部份轉換為 Docbook 的格式
這樣的功能可以很方便的將 Wiki 中積存已久的文件, 以書的型式輸出
當然 Docbook 輸出的型式包含了 pdf, html, chm… 依不且需求可以使用不同的格式發行
這使得我們不需要再為每種格式都製作一份文件,
附帶一提, freebsd 的文件也是以這種方式輸出
我們需要的套件叫做
Page2Docbook – http://trac-hacks.org/wiki/Page2DocbookPlugin
python 的安裝方式很件單只要透過 easy_install
easy_install http://trac-hacks.org/svn/page2docbookplugin/page2docbook/
就會幫你從 SVN 上將最新版本的 plugin 抓下來並且安裝
由於這個套件還需要一些 python 的 extensions 在它的說明文件中有提到
python-uTidyLib
python-libxml2
python-libxslt
在 FreeBSD 平台上的使用者不需要擔心, 這幾個套件 FreeBSD 都納進了 Ports 當中了
只需要進入 Ports 底下的目錄:
/usr/ports/www/py-utidy
/usr/ports/textproc/py-libxml2
/usr/ports/textproc/py-libxslt
使用 make install clean 分別安裝完以上的套件後
就可以在 Trac Admin 中的 Plugins 看到這個 Page2Docbook 的出現
接著就是將他打勾, 就能使用了
cwlin0416
