其他

在項目過程中，通過觀察，感覺做好PM這個角色需要做好以下幾點：對項目關鍵點的細節要足夠瞭解 雖然PM可以不參與具體的編碼工作，但並不等於不需要瞭解具體的實現細節，特別是一些影響項目成敗的關鍵點。有些PM離技術越來越遠，遠到一些功能是怎麼實現的、用的是什麼技術、有哪些地方需要特別注意都不清楚，這會非常影響他的決策力和判斷力，特別是在處理突發事件時會手足無措。在現階段，特別是項目規模不大的情況下，感覺PM兼任架構師比較好。對項目各個階段的時間點要足夠清晰 PM頭腦得時刻有一個清晰的項目roadmap

在VMware裡建立虛擬機器嚮導時會讓選擇是否預分配虛擬磁碟空間（preallocate for virtual disk），如果選是，VMware將立即分配所有空間（Allocate all disk space

在以前的項目裡為了寫作方便，總是以word文檔的方式提供架構和設計文檔，帶來的好處僅僅是自己寫作起來較為方便，但帶來的麻煩卻有很多，比如：更新文檔較為麻煩。他人瀏覽較為麻煩，特別當需要從docx轉換到doc的時候。很難形成與其他文檔的聯絡。難以協同合作以上的缺點導致很不好的後果：設計有了更新卻懶於同步到文檔裡，他人也不願看文檔，乾脆直接來問設計者，文檔支淩破碎，寫文檔成了個別人的事情。因此在計費二期裡我決定擯棄用word的形式，改成用wiki，並在公司wiki裡好好規划起來，相比較word，wi

一.web伺服器1）apacheapache分為很多模式，大家最熟悉有prefork和worker兩種，在linux上安裝apache可見文檔值得注意的是prefork和worker的選擇是在編譯期，在make之前就需要選定安裝的模式，如：./configure --with-mpm=prefork./configure --with-mpm=worker二.壓力工具1）abab為apache內建的壓力工具，功能簡單實用方便，使用執行個體如：/usr/alibaba/install/httpd-

Redmine是一款開源的、基於web的專案管理軟體，採用Ruby on Rails架構開發。Redmine具有豐富的專案管理功能，包括：任務跟蹤、檔案管理、wiki、新聞台、多專案管理等。對於代碼管理，Redmine可以整合常見版本管理系統和bug跟蹤系統，包括Subversion、Darcs、Mercurial、CVS、Bazaar 和

--------------英文文檔見android-ndk-r5b的documentation.html屬於Android Native Development Kit (NDK)的一部分見http://developer.android.com/sdk/ndk/（需要代理）翻譯僅個人見解-----------------Application.mk file syntax specification Application.mk檔案文法規範 Introduction: 介紹：--------

1、啟動並進入Linux系統。2、然後選擇虛擬機器菜單中的“虛擬機器/安裝VMware-Tools”,此時就會有把VMware-tools檔案映像到CD－ROM中。3、把“VMwareTools-6.0.2-59824.i386.rpm，VMwareTools-6.0.2-59824.tar.gz”檔案複製到自己的需要的位置中，然後選擇一種安裝方式。在此我選VMwareTools-6.0.2-59824.tar.gz。4、解壓# tar -zxvf VmwareTools-6.0.2-59824

test:Add CUSTOM_BUNDLE_IDENTIFIER and CUSTOM_PRODUCT_NAME under the user defined section of build settings.Add a .xcconfig file to the project with CUSTOM_PRODUCT_NAME, and CUSTOM_BUNDLE_IDENTIFIER set to the nominal values.Set the product name to ${

在以前做錢掌柜的時候就想著做項目發布員，因為做這項工作可以協助你對整個項目實際運轉情況摸得更清楚，但後來還是放棄了，主要是感覺自己比較毛糙，不太適合做這項風險較高的工作。可這次計費中心項目讓我沒有退路，只有自己可以頂上去。計費中心是個新項目，發布環境和生產環境都為0，痛點就在於需要從頭開始搭建基礎設施。這個項目構建用的是maven而不是以前阿里自製的antx，所以項目結構和構建指令碼與以前項目都不太一樣。但對於我這個項目發布新手來說，又恰恰是較為有利的一面，可以讓我沒有任何曆史包袱，可以完全遵循

最近看了一本書《軟體架構師應該知道的97件事》，本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為正確的架構師管理辦法，以此來矯正自己的行為。客戶需求高於一切不要為了自己的項目經曆上添加光彩而去一味追求時髦而光鮮的方案，而是應該紮根客戶需求，腳踏實地地為客戶著想，這樣才能更體現技術的價值，不至於

經曆過大 規模架構重構（ ReArchitecture ）的同學都知道： ReArchitecture 是一個極其痛苦的過程，要想將原有的 working 的代碼，徹底地用新的架構，新的技術 重新寫一遍，其工作量是令人望而生畏的。最複雜的莫過於商務邏輯的梳理，如果你有精力將原有的代碼從頭讀一遍，那是最 lucky 的事，但大多數情況下，別人寫的代碼 需要你自己重新寫一遍，大多數人沒有精力或不願意去通讀代碼，而主要依賴於需求文檔，結合舊代碼，寫出新的代碼。但需求文檔的更新永遠趕不上代碼的更新速

-----英文文檔見android-ndk-r5b的documentation.html屬於Android Native Development Kit (NDK)的一部分見http://developer.android.com/sdk/ndk/（需要代理）翻譯僅個人見解-----------------Android module paths (sharing code made easy): Android模組路徑（方便共用代碼）：=============================

redmine確實是一個好的管理系統，可是架設起來太費勁了。這個“費勁”是由於它每個版本需要的特定的運行包版本才能匹配。按照官方的文檔進行安裝，所有運行包都按照官方匹配，可還是出現了如下的bug：rake aborted!uninitialized constant Gem::SyckDefaultKey反覆的重裝與更換以下工具的版本：Ruby & Rails & Rack & Rake &

web伺服器都提供長串連的方式，所謂長串連就是用戶端一次請求完後，不關閉串連，保持一段時間的串連，下次此用戶端再次請求時，不用建立新串連，複用所持續連線即可。從理論上，長串連可以免去大量建立和關閉串連的資源消耗，但同時也有大量串連被佔用的代價。因此可以初步判斷長串連比短串連能帶來更高的TPS，更低的CPU消耗，更少的IO，更高的記憶體佔用，下面通過實戰來驗證。伺服器環境和測試載入器可以見工具和環境準備篇本次web伺服器選用apache

先確保解決方案簡單可用，再考慮通用性和複用性系統的複雜性往往是架構師基於通用性和複用性的設計而引入的，很多具體問題往往不需要通用性和複用性的解決方案。如果存在多個可實施方案難以取捨，先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時，無需排斥通用和靈活，但是如果過早脫離具體情況，只會迷失在無限的可能性裡，被複雜的配置選項、超負荷的參數列表、冗長羅嗦的介面，以及存在缺陷的抽象所淹沒。先簡單滿足需求，當重複需求再次發生時，通過重構來達到複用是一種不錯的方式架構師應該親力親為架構師幹久了

作者： 北南南北來自： LinuxSir.Org摘要： Linux作業系統中，計劃任務通常由cron來承擔，瞭解或掌握cron，能為我們管理伺服器帶來更多的便利，也能省卻更多的時間。本文也舉了一些簡單明了的例子，為了讓新手上路方便；目錄  2.1.1 在Redhat 或 Fedora等RPM包管理的系統的安裝； 2.1.2 在Slackware系統中的安裝； 2.1.3 cron 的開啟、停止、重新啟動方法；2.2.1 全域性設定檔； 2.2.2 cron 配置計劃任務的書寫格式 2.2.3

----------------- 英文文檔見android-ndk-r5b的documentation.html 屬於Android Native Development Kit (NDK)的一部分見http://developer.android.com/sdk/ndk/（需要代理） 翻譯僅個人見解----------------- Android NDK & ARM NEON instruction set extension supportAndroid NDK 和 ARM

架構師是個很需要溝通技巧的角色，需要和老闆溝通，使其相信在技術上的可行性；需要和PD溝通，弄清楚商業邏輯；需要和專案經理溝通，使其更科學地安排人員和進度；需要和開發人員溝通，使其理解設計思路，保障設計架構在具體實施中得以落實；需要和QA溝通，使其瞭解項目的風險點和關鍵點。因此，架構師需要在溝通上下功夫，這是保障工作順利進行的關鍵環節。下面是我總結的幾個很常用的溝通方式：挑釁式的溝通方式具體方法：在矛盾雙方中，以其中一方比較極端的觀點來合理地構想後果，然後將這樣的後果與另外一方進行溝通，激發另外一

越來越發現沒思考就沒有進步，忙碌的工作非但不能讓你沉澱起來，反而會讓你因為失去思考而變得空乏。身邊不乏拚死工作卻沒啥突破的例子，也包括自己，問題關鍵就是與是否學會了思考。最近一直在思考這麼一個問題，如何激發思考，如何使自己在千遍一律的工作中找到突破口。找到了一些思路和方法，總結如下：1）when---何時需要思考每天早上工作之前，安排當日的工作每天晚上給自己10分鐘安靜地想想當日的工作項目出現事故時，不管和自己是否相關，想想其原因和解決辦法項目和公司發生變化時，想想自己在新環境如何改變和適應自己

讓開發人員自己做主架構師雖然需要為系統的設計負責，但無須包攬所有的設計工作，應該給予團隊成員足夠的自主權，讓他們發揮自己的創意和能力，你的工作是確保大家的工作能很好的組合在一起，協助他人解決棘手困難。當你發現同事遇到麻煩時，可以主動給出建議，但更可取的做法是創造良好的氛圍，讓大家主動向你徵求意見。控制項目規模架構師要試圖避免做那種“超大型”系統，因為這種系統往往難以控制，控制項目規模的辦法通常有：抓住真正需求分而治之設定優先權儘快交付原則架構師不是演員，而是管家有些架構師誤解了證明自己價值的含義