在ios開發過程中，asihttprequest庫是最常用的網路庫，功能強大，使用也非常方便。
但是，在使用此庫過程中，發現有幾點小問題。
乙個問題是，我發現當非同步請求比較多，併發連線數量比較多的時候，會導致一些請求失敗。
原因：**預設是最大4個併發連線，其他的連線需要等待。然後如果有連線請求完畢了，就會去復用這個連線，但是還會出現連線關閉的情況，這個時候**不會再一次重新請求，導致這次請求失敗，返回nil。
簡單解決：
最簡單的解決就是把復用連線關閉，每次都新建連線就不會出問題。或者一次只允許乙個連線。
asihttprequest裡加入下面** [self setshouldattemptpersistentconnection:no];
另乙個問題是偶爾出現異常，在asihttprequest的startasynchronous呼叫後偶爾出現exc_bad_access異常。
在viewcontroller中是採用委託的方式，即在- (void)viewdidload方法中加入**：[request setdelegate:self]
然後實現其委託方法- (void)requestfinished:(asihttprequest *)request和- (void)requestfailed:(asihttprequest *)request
測試過程中發現，在執行請求未結束時候不斷關閉和開啟此介面，就容易出現exc_bad_access異常。
解決方法：
在stackoverflow.com上，有網友提出了兩個解決方法。
第乙個，使用同一的delegate，並且應用一執行就初始化它。如果其他類要呼叫非同步請求，將delegate發過去。
呼叫方法如下：
- (void)sendurl: (nsstring *) resturl withcallback:(nsobject*) delegate;
然後，在delegate的實現方法中利用request的tag來標識來自哪乙個類的非同步呼叫。
第二個，使用block直接實現非同步請求，拋棄delegate。
使用"setcompletionblock:^"代替delegate的"setdidfinishselector"。
request做乙個設定就可以，比原來通過設定request.delegate再實現delegate的方法簡單多了。
[request setcompletionblock :^];
[request setfailedblock :^];
談談我對CMMI的認識
cmmi是一種非常好的軟體工程方法，已經總結和建立了很多優秀的流程方法，而且諮詢公司會提供模板資料，把這些別人的東西般過來學習和實施，就可以在自己的企業運作得非常好 在我看來，這些理解完全是錯誤的。這種錯誤理解或觀念，使得很多企業實施cmmi後卻完全看看不到效果，甚至事倍功半，開發效率和質量還比不上...
談談我對bloom filter的理解。
我們都看過封神榜吧，每乙個神位都對應著乙個人。在西周時代，如果乙個人聲稱自己是神，那麼他必須可以通過封神榜的驗證，如果封神榜驗證了下這個人，發現神位上根本沒這號人，那麼這個人絕對不是神。但是封神榜的驗證方式是有漏洞的，那些企圖依靠神的名聲招搖撞騙的人之中，有些人發現了這個秘密，他們可以通過偽造自己的...
談談我對flexbox的理解
寫在開頭 關於flex，學了很久的前端了，偶爾也在用，尤其是當需要水平居中的時候，就用display flex，感覺非常好用。但是其實對於flex的理解並不是很到位，根本都不懂flex，所以正兒八經的來研究一下flexbox。flex布局模型不同於塊和內聯模型布局，塊和內聯模型的布局計算依賴於塊和內...