其他

    通常用於監控前台空間屬性改變可以使用的事件有onblur, onchange, onpropertychange，第一個為當控制項失去焦點後觸發，而第二個為當屬性內容改變後觸發，不過前兩個同時使用，則會首先觸發後者，再觸發前者，而第三個是javascript的事件，不屬於控制項自身所帶事件，其可以監視任何控制項全部屬性的變化，十分的具體和全面，但同時也是非常的耗費資源，一不小心就會出現比較大的問題，所以建議使用的時候，一定要做好篩選過濾的工作，以上三個屬性都可以支援FireFox和IE，

    簡單描述下俺要廢話的背景吧，這幾天都在排查一個bug：silverlight用戶端應用中的某個控制項，會因為多次操作而導致瀏覽器記憶體飆升，至於飆升的速度嘛，差不多操作半個小時後，瀏覽器估計就累死了……     接到這個棘手的活兒後，先大概捋了一下自己的思路：    1. 複現問題：並掌握問題複現的“規律”。    2. 熟悉問題控制項的生命週期：一方面是控制項的需求功能，一方面是控制項的代碼實現。    3. 用階段排除法定位可疑程式碼片段：主要是通過調試、觀察，逐漸縮小問題包圍圈。 

這兩天在寫個小應用，主要是web上實現對各種瑣事事情記錄這方面的功能，倒是頗有一點兒小感受，正好也好久沒有寫點兒東東，總覺得有種小小的罪惡感~最大的一個感受就是要“簡單”：其實，以前自己也看過很多這方面的文章和書籍，但那隻是一種自己比較認同的觀念，但卻沒有切身的體會，這次算是小小的體驗了一把。一開始，自己雖然也是先大致勾畫了應用的基本介面和功能，但在實現的過程中，以及和木瓜同學的交流中，發現其實很多東東都是“冗餘的”，自己最應該關注的應該是“這東西到底能幫我幹啥？”，於是，把那些自己認為有趣的，

    在使用ListView控制項的時候，如果我們需要在列表中再放置一列的textbox控制項的話，情況多少就有一些複雜了，如果我們還需要對這些textbox中的內容進行遍曆，或者要根據其內容的變化實現一些用戶端的動作的話，其實還是有一點麻煩的。這裡記錄一下處理這樣問題的思路：    a)  

        一提到寫文檔，可能很多程式員可能會不屑一顧，但是，無論處於規範開發流程，還是就於逃避嫌責的目的，能夠將自己所從事的工作用文檔描述記錄下來，還是一件很有成就感的事情，拋開其功用不談，就個人的成長進程看，也是一個循序漸進式的好習慣，還是值得大家稍微關注一下的。   

        在開發一些功能的時候，尤其是自己設計並實現一些應用的時候，常常會被一些需求的細節所束縛，很可能是自己往往在開發伊始就考慮很多的需求細節問題的緣故，例如，我需要實現一個Create功能頁面，使用的ASP.NET MVC 2，通過直接建立強型別View視圖，就可以自動得到一個帶有全部內容的Create頁面，只不過頁面樣式是最初級的，展示的內容也是預設完整的，這時，自己就會想盡量把頁面的內容和樣式盡量多地確定，於是，花了很大的力氣在上面……    

     通過HttpWebRequest來進行POST請求的時候，如果發現在連續操作的情況下，會導致程式反應遲鈍或被卡死，可以查看一下，是否是因為缺少了擷取伺服器狀態這一關鍵步驟，所以才導致本地程式因為等待伺服器的響應而暫停等待，正常完整的發送請求程式碼範例如下：  1                 HttpWebRequest myReq = (HttpWebRequest)WebRequest.Create(UrlText.Text + FileUpload1.FileName); 2 

        學東西這事絕對是件功夫活，也絕對是條漫長路，因為當你決定踏上一條求學之路時，你可能對其充滿了朦朧的嚮往，而當你已經上路一段日子後，你可能又會感到到處都是自己不知道的東東，頂著頭皮再走一段日子，你可能會感到稍微有了一點點自信的安慰，因為你已經對一些基本的東東有了理解，以前很多的高深的東東也開始慢慢褪去了其身邊濃濃的白霧，但你仍舊有很多事情不懂.   

    現有一個可根據固定格式URL請求返回資料內容的網站，如果想減少網路傳輸壓力的話，使用瀏覽器緩衝可以起到很不錯的效果。但是，如果僅僅是通過下面設定來實現：  1 Context.Response.Cache.SetCacheability(HttpCacheability.Public);    

    最近參加了一個.NET進階培訓，同時也在讀一些進階編程的書，然後又翻開這兩年來自己寫的一些代碼，突然有一些體會，怕過了個周末就會忘乾淨，這裡趕緊寫下來和大家分享一下。    先說一下頁面吧，我們用.NET做Web App，項目的初始是使用的ASP技術，後來升級到ASP.NET

 1. 為啥要搞職業規劃？答：因為職業規劃可簡單分為“被動型”和“主動型”，而很多時候因為自己不清楚自己真正喜歡的是啥職業，也不知道到底啥工作才是最適合自己的等等原因，往往選擇一份不違背自己心裡底線的工作。但現實總是在不斷變化的，所以說，所謂的個人規劃也應該不斷地進行更新調整。最終目的，還是能夠協助自己找到屬於自己的興趣，變被動為主動，完成從面對工作到投身工作的轉變。  2. 技術人員發展方向？答：大致可分為三個方向：專家型技術人才、技術管理型、其他的如項目型、營運型、應用型或研究型等。  3.

視窗快速鍵：win+↑ 已最大化的視窗win+↓ 還原/已最小化的視窗win+← 使視窗佔領左側的一半螢幕win+→ 使視窗佔領右側的一半螢幕win+shift+← 使視窗在左邊的顯示器顯示win+shift+→ 使視窗在右邊的顯示器顯示win+home 還原/最小化所有的其他視窗工作列快速鍵：win+T預覽第一個工作列項，按住win鍵連續按T從左向右預覽win+shift+T預覽最後一個工作列項，按住win+shift鍵連續按T從右向左預覽鬆開以後，也可以按←或→鍵來按順序預覽win+數字鍵1

    大家使用指令碼或者樣式來開發web項目的時候，難免會遇到一些排查“錯誤原因”的問題，當然，如果要是你的項目不是特別的龐大，可能難度還不大，頂多折騰你1到2個小時，也差不多能把問題解決了，但是，如果在一個稍微龐雜的系統中進行修改、完善一部分指令碼和樣式的時候，你的噩夢即將來臨，下面簡單描述一下，自己在這段時間內，進行這部分工作後的一些感想，希望大家能夠少走彎路，直奔主題：  （1）

    對於剛剛來到一個團隊的新人來說，培養對項目的主人翁意識往往有些困難，如果要是項目起步階段還容易些，畢竟大家都是從一個起點開始，無論從項目的參與度，還是從任務的分配比例，再或者從與團隊成員配合的機會上，都是一個很好的開始！  

1. 學會休息：責任越大，相應地更應該注意自己的休息調整，以保持精神飽滿的工作狀態和清醒的思路。  2. 積極心態：多給自己一些帶有時限的挑戰，並多從一些積極的角度去思考問題，打破固有的思維模式去尋找新的解決思路。  3. 每日休息開關：能在一定程度上，把工作和生活的界限劃分清楚，保證足夠的睡眠休息和飽滿的精神狀態。  4. 對待事情的心態：面對它，接受它，處理它，放下它。  5. 帶團隊要重視的兩個方面：團隊文化，用於凝聚團隊的成員；承擔責任。  6.

        魔圖團隊設計師劉靜分享如何站在設計師的角度看待產品研發，還有知乎和經緯的兩位朋友分享了一些自己創業的經曆，簡單摘錄如下： 1. 設計師最好介入全程的產品周期。 2. 放下自己過往的種種經驗、限制和約束，一切從頭開始地去設計產品。 3. 從簡單開始：感覺很簡單，其實不簡單，要能夠讓使用者用著爽，同時不斷地進行改進，使得產品能夠伴隨著使用者而不斷地成長，這才是一種健康的產品成長軌跡。 4.

    昨天，公司領導給我們做了一次關於如何進行溝通的培訓，感覺收穫頗多，趕緊把自己隨時記錄的一些片段記錄下來，作為一個回顧~~ 1. 溝通的目的：解決問題 -》 達成共識 -》 互相接受 2. 溝通的狀態：不溝通 -》 心裡暗恨 -》 發牢騷、抱怨 -》 開放簡單 3. 文字是永遠含有歧義的 4. 郵件適合用於通知和記錄，不適於去解決問題 5. 讚美 + 解決方案 = 實現溝通的目標 6. 直接拒絕別人肯定是不對的 7. 用談戀愛的熱情去溝通，肯定會收到意想不到的收穫 8.

    通過.NET實現後台自動發送郵件功能的代碼，可以將一些基礎資訊放到web.config檔案中進行儲存：Web.config檔案資訊段：代碼Code highlighting produced by Actipro CodeHighlighter

不知道別的公司啥情況，就自己帶過的3家公司來說，基本都存在一種普遍的“趕工期”的現象，之所以說是普遍現象，這也有一些朋友的親身經曆，似乎這就是一種IT行業的特色，畢竟隨著互連網化的長足發展，對產品的更新速度是一個空前的挑戰！時間就是利潤啊，這個道理想必大家都懂，這裡就多說了。暫時不考慮這些外部因素的影響，但從產品研發周期上來講，我們大家在疲於奔命的無休止的為了產品上線，而不斷地以鏟地皮的速度累積功能的同時，我們也在為我們產品的未來埋下N多的“定時炸彈”！都有哪些可能的隱患會悄悄地溜進我們的產品中

1. 有效時間管理不在於方法，而在於看法。  2. 心智創造先於實體創造。  3. 成功方程式：Be -> Done -> Have，即首先應該選擇自己應該做什麼樣的人，然後我們會去按照我們的想法實踐一些事情，最終我們將收穫屬於我們的成果。  4. 習慣的養成過程：無意識的無行為 -> 有意識的無行為 -> 有意識的有行為 -> 無意識的有行為  5. 行政時間就是管理自己。  6. 時間管理技巧一：要事第一（1） 什麼是最重要的事兒？（2）