WEWE x 知識 x 學習 x 筆記

今天下午在設定 apache 伺服器 rewrite module 的時候遇到了一些問題。花了一兩個小時才找到問題，這問題以前應該解過，只是很就沒碰就忘了，所以把他記錄下來。最近在用CodeIgniter(CI) 這套 php framework需要用到 rewrite module來改寫Requst Uri。 我原本以為只要下指令Load rewrite module 再重開 apache 就好了 sudo a2enmod rewrite sudo /etc/init.d/apache2 restart 殊不知，啟動後沒有效果，試了很多方式，發現我有個最基本的設定沒有改動，也就是 apache 設定的AllowOverride這個參數需要設定，但這個參數老實說我也不太了解，趁這個機會了解一下好了。 通常我們會將rewrite rule寫在 .htaccess這個檔案中，但好死不死 AllowOverride這個參數就是在控制 .htaccess 這個檔案中寫的設定值，可否覆蓋掉 apache 設定檔中設定的值，所以需要對這個參數做設定。這個參數的設定也跟安全性有關。以下列出可能的設定值與其意義。 All     全允許 AuthConfig        允許覆蓋認證相關的設定 FileInfo      允許覆蓋文件相關的設定(包含rewrite module, mime module的相關設定) 其他還有 Indexes, Limit, Options[=Option,...] 詳細內容可以參考  http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride 我只需要設定 AollowOverride FileInfo 就可以. vim /etc/apache2/sites-enabled/000-default AollowOverride None  改成 AoolowOverride FileInfo 其實這個設定還有.htacces設定後子目錄相關的問題，有點懶，這裡就不探討了。

 前言 在我工作的團隊中，幾個月前我們改變了我們使用svn的方法，加入了feature branch的概念，就是每開發一個新的功能就需要從主幹開一個branch出來做開發，以免開發中的功能影響到其他人的作業(bug fix ...)。我們在改變規則的時候討論了很多次，原本以為規則已經很OK了。殊不知，才是惡夢的開始。 老舊的branch 有些功能branch分出來之後，此功能可能初步開發完成，尚未測試完成。但因為專案時程與需求變動的關係，導致這個功能的優先順序降低，所以不能跟著下次的release出去，且被assign更緊急的工作，這個feature branch 從主幹分出來太久，之後要merge回主幹可能會有一大堆衝突與問題。而你也沒辦法保證被svn auto merge後的結果一定是正確的，這個時候問題就來了。 如何解決老舊的feature branch? 我找了一些資料，這篇stackoverflow上是跟我一樣的問題 Subversion Branch/Trunk Best Practice - keeping Branch Up-to-Date? ，其中提到的我覺得OK的做法有幾點: 常常把主幹的code merge到你的feature branch，也就是說常常更新你的feature branch，就像每次開發前要update code一樣(好像有點爛，不過這好像已經是最好的辦法了 主動教你的團隊如何把code merge做好，且誰做更動的就應該由更動的人做merge的動作 我也覺得要常常更新feature branch，但為時已晚ㄎㄎ，我還是需要merge一大堆change，解決一大堆衝突，慘兮兮。既然都要做了順便提一下如何 Keep your feature branch up to date. 有人有更好的辦法歡迎留言告訴我。 Keep your feature branch up to date. SV作法其實很簡單，就是把主幹merge到branche就好。 Keeping a Branch in Sync Svn book - Branching and Merging  > Keeping a Branch in Sync Without Merge Tracking Su

最近在辦公室用centos寫code， 常常在用tab 補齊指令時，找不到東西就逼逼叫 很吵，所以就去找了一下怎麼處理想不到意外的簡單 pcspkr (PC speaker) 這個是一個kernel module預設會載入，用來控制那個主機板上機歪的警示音撥放器   記得要切換成root權限 使用lsmod確認你的這個module是否有被載入(有被載入才會叫) lsmod | grep pcspkr 使用rmmod卸載那個module rmmod pcspkr 就OK了 如果想在以後開機後都不要讓他載入就編輯 /etc/modprobe.d/blacklist   在這個檔案加入 blacklist pcspkr 把pcspkr加入黑名單，以後在開機時就不會被載入了 參考網址: http://thedaneshproject.com/posts/how-to-disable-the-beep-in-linux/

    這三個月下來，從中心同事的身上學到不少東西，這些都是他們累積下來的經驗，讓我收穫良多，謝謝他們。工作已經將近三個月，有很多的心得，職場、寫程式都有不少心得，今天先從程式談起好了，以前在學校無論是寫作業，接case，算一算也寫了不少程式，但真正工作寫大型的軟體後。發現產品跟之前寫的程式完全不一樣，要考慮的事情也多了很多，我從程式的設計、開發、測試三個部份來說好了。 設計   之前寫程式雖然知道事前的設計很重要，但都是粗略的想一下就著手進行開發了，往往在開發完成要使用的時候遇到需要改很大的問題，額外又多花很多時間修改。看書上寫多多紙上談兵，設計的修改往往比成式的修改省時，但那時沒甚麼感想。現在外面工作之後，才真正在實務上遇到，我們花很多時間在討論新的功能如何實做，以及會遇到各式各樣的問題都事先預想，怎樣跟其他組整合才不會影響到原本的功能，甚至討論到快吵起來。不過最後討論出來的東西雖然稱不上完美，但也非常好了。而且在我們的team中，大家的設計都是往right things to do 的方向想，也會兼顧目前的時程，我覺得非常的好。有非常多的人事物值得我學習。 開發前多想一點多考慮一點，以後的修改與錯誤就少一點。 開發 開發的部分也有很多跟以往經驗不同的地方，最讓我印想深刻的就程式的容錯性，因為我們開發的是儲存系統，上面儲存的的是重要的資料，所以容錯性非常重要，在這常常需要考慮到，系統crash後再啟動，資料是否能正確的被保留下來，系統是否能正常運作，在這個部份我是完全的新手。但在我們組內，每個人開發都會考慮到容錯性，還有錯誤還原等問題，這是我不足的地方，也是我在這裡努力的方向。程式的效能也是一大的考量，之前再開發教學網站就有預到類似的問題了，這種問題處理起來也蠻累人的。在工作之後，這個問題也是每天會討論到的問題，希望在這裡可以學到這方面的經驗。不過在這邊的開發也有一些問題，文件的不足(我之前想到公司學的就是開發的文件化)，由於我們中心也才成立第三年，很多流程制度等也還不夠成熟，很多都是藉由大家的努力持續在改善中，文件我想過一陣子開發的進度不那麼忙的時候就會被注意到了，到時候就做中學吧。還有一個很大的不同，就是以前很少開發multi-thresad的程式，這邊幾乎都是，所以在除錯上的困難度對我來說很高，我有找一個同步問題找一個禮拜的經驗= =