2010年8月15日

          前兩天休眠后機器非正常關(guān)機,重新啟動后運行eclipse。悲催的發(fā)現(xiàn)eclipse 無法啟動了。每次雙擊啟動后,確定完workspace后,顯示啟動畫面,沒過一會就進入灰色無響應(yīng)狀態(tài)。啟動畫面始終停留在Loading workbench狀態(tài)。反復(fù)重啟,狀態(tài)依舊。嘗試解決。

          搜索了一下,應(yīng)該是非正常關(guān)機導(dǎo)致eclipse工作區(qū)的文件狀態(tài)錯誤導(dǎo)致。在工作區(qū)目錄中,有一個.metadata目錄,里面是工作區(qū)及各插件的信息,刪除此目錄可以解決問題。

          為保險起見,將.metadata改名移動到/tmp目錄,再重啟eclipse,果然可以正常啟動eclipse了,但原來工作區(qū)的配置和項目信息也都消失,直接顯示的是歡迎界面。

          如何恢復(fù)原來的project配置呢?嘗試對比了當前的.metadata和之前備份的那個目錄,發(fā)現(xiàn)缺少了很多配置文件。試著一點點恢復(fù)一些目錄,但效 果不理想。因為不知道哪些文件(目錄)可以恢復(fù),哪些恢復(fù)會帶來問題。將備份的整個目錄恢復(fù)試試?Eclipse又回到了無法啟動的狀態(tài)了。

          怎么辦?這時想到啟動停止時顯示的狀態(tài):"Loading workbench",看來和這個workbench插件有關(guān)。查看原來的.metadata/.plugins目錄,在眾多文件夾中
          com.collabnet.subversion.merge          org.eclipse.search
          org.eclipse.compare                           org.eclipse.team.core
          org.eclipse.core.resources                  org.eclipse.team.cvs.core
          org.eclipse.core.runtime               org.eclipse.team.ui
          org.eclipse.debug.core                 org.eclipse.ui.ide
          org.eclipse.debug.ui                   org.eclipse.ui.intro
          org.eclipse.dltk.core                    org.eclipse.ui.views.log
          org.eclipse.dltk.core.index.sql.h2     org.eclipse.ui.workbench
          org.eclipse.dltk.ui                           org.eclipse.ui.workbench.texteditor
          org.eclipse.epp.usagedata.recording    org.eclipse.wb.discovery.core
          org.eclipse.jdt.core                             org.eclipse.wst.internet.cache
          org.eclipse.jdt.ui                                 org.eclipse.wst.jsdt.core
          org.eclipse.ltk.core.refactoring          org.eclipse.wst.jsdt.ui
          org.eclipse.ltk.ui.refactoring            org.eclipse.wst.jsdt.web.core
          org.eclipse.m2e.core                    org.eclipse.wst.sse.ui
          org.eclipse.m2e.logback.configuration  org.eclipse.wst.validation
          org.eclipse.mylyn.bugzilla.core        org.eclipse.wst.xml.core
          org.eclipse.mylyn.tasks.ui             org.tigris.subversion.subclipse.core
          org.eclipse.php.core                   org.tigris.subversion.subclipse.graph
          org.eclipse.php.ui                     org.tigris.subversion.subclipse.ui

          發(fā)現(xiàn)了兩個: org.eclipse.ui.workbenchorg.eclipse.ui.workbench.texteditor

          不管三七二十一,刪了這兩個目錄,重新啟動eclipse。正常啟動且原項目信息正確加載。
          posted @ 2012-11-11 14:15 胡鵬 閱讀(6458) | 評論 (7)編輯 收藏

          最近團隊遇到一個案例。看似很小的事情,但仔細研究起來,徹底分析,每一個環(huán)節(jié)都沒做好,細節(jié)部分糟糕得一塌糊涂,最后導(dǎo)致一件事情的結(jié)果:完全失敗。

          經(jīng)常有人在聊起公司的時候問我,你現(xiàn)在最擔心的事情有哪些? 我當然會重點提到團隊。不過在談及團隊的時候,我又最擔心在「細節(jié)」問題上做不好。

          細節(jié)就是競爭力,尤其是對小團隊來說,小團隊更應(yīng)該注重細節(jié)問題。大一點的公司可以追究責(zé)任人,靠流程、靠制度,靠各級評審等等一系列的「成本」來提升細節(jié)能力。小一點的公司或者團隊怎么辦? 恐怕只有依賴每個人的能力和責(zé)任心了。

          細節(jié)也是鍛煉人的能力的地方,搞清楚每一個細節(jié),將每一個細節(jié)涉及到的背景知識和技能掌握好,能力自然也就會得到提升。繼而,著手做更大的事情也不 會手忙腳亂。相反,做不好細節(jié)和小事的人,如果總?cè)轮觥钢匾沟氖虑椋龈小柑魬?zhàn)」的事情,這樣的事情真的到你面前,真的能接住么?

          為什么我們在細節(jié)上做不好?

          對細節(jié)問題不夠重視 一件事情到了自己這里,頭腦中先入為主認為只是一件小事,是一件簡單的事情。這樣,當然就不會給予足夠的重視。小事不一定不重要,小事不一定意味著做起來就簡單。

          對事情復(fù)雜度缺乏認知 不就是給客戶寫一封電子郵件么? 不就是用 HTML 寫一個頁面么? 不就是做一則橫幅廣告么? 那么,這些事情真的簡單么? 為什么別人為客戶寫的郵件打開率更高? 為什么別人寫的頁面更容易被搜索引擎收錄? 為什么別人做的廣告轉(zhuǎn)化率更好? 背后涉及到哪些知識? 不想研究一下么? 不能研究一下么?

          對細節(jié)缺乏耐心 草草了事,應(yīng)付了事,遇到問題馬馬虎虎,輕易得放過了很多可以讓自己得到成長的機會。「這問題我沒想過」「這事情我沒遇到過」「設(shè)計稿都改過兩次了」... 這類借口在任何一個團隊都很常見。

          缺少責(zé)任心 常常覺得自己這里做不好,還有別人會把關(guān)呢。擔心什么? 可如果所有人都這么想呢? 「文案是產(chǎn)品經(jīng)理的事情,關(guān)我甚么事?」如果你能對文案也有改進意見,誰說以后你就不能做產(chǎn)品經(jīng)理做的事情呢?

          主觀上不認可自己的工作 就給我這么一點錢,要我做這么多工作? 問題是我們?nèi)绻欢嘧鲆稽c工作,不提升一下自己,又怎么能多一點錢呢?

          為什么細節(jié)上做不好? 不同人不同的角度還會有不同的看法。不過有一點我能肯定,細節(jié)不會決定成敗,但做不好細節(jié),一定會失敗。

          做好細節(jié),百事可作。

          posted @ 2012-10-28 16:31 胡鵬 閱讀(239) | 評論 (0)編輯 收藏
          mac中自帶的jdk并不包含源代碼,所以在eclipse中無法查看, 需要到apple上去下載,
          https://developer.apple.com/downloads/index.action
          Documentation and developer runtime of "Java for OS X 2012-005". Contains JavaDoc, tools documentation, and native framework headers.
          目前的版本是:Java for OS X 2012-005 Developer Package
          下載下來后,直接安裝,默認設(shè)置就可以了,然后可以建個link,方便選擇。
          1. sudo -s
          2. cd /System/Library/Frameworks/JavaVM.framework/Home
          3. ln -s /Library/Java/JavaVirtualMachines/1.6.0_35-b10-428.jdk/Contents/Home/docs.jar
          4. ln -s  /Library/Java/JavaVirtualMachines/1.6.0_35-b10-428.jdk/Contents/Home/src.jar
          5. 最后跟windows類似,在eclipse中用command + click點擊查看一個類的源碼。然后選“add source",選中上面的 src.jar 文件即可
          posted @ 2012-10-16 21:48 胡鵬 閱讀(3791) | 評論 (0)編輯 收藏
          雖然android安裝完成后會有一套參考手冊,其中包括了api,但是如果在開發(fā)過程中能查看android的源碼(sdk的源碼),將對我們學(xué)習(xí)android有一定的幫助.畢竟,有時候源碼比api文檔更能說明問題.
              我平常學(xué)習(xí)android用的2.2版本,從網(wǎng)上下載了2.2的源碼(從官方git庫下載太麻煩,是從網(wǎng)友共享的源碼位置下載的).按照網(wǎng)上的說法,我把 解壓后的那一堆文檔放在了android-sdk-root\platforms\android-8\sources目錄下.不過并沒有重啟 eclipse.而是通過這種方法來做的-----在eclipse中,鼠標放在一個android提供的類上,按下ctrl鍵,會打開一個新頁面,提示 找不到對應(yīng)的類的class或者源文件,但這個新頁面上有個導(dǎo)入源碼的按鈕,點擊之后選擇下載好的source位置,確定后就可以了.
              順便說下我下載android源碼的位置:
                  http://tech.cncms.com/UploadFiles/20101025/androidsdk2.2_sources.zip

          下載源碼到maven倉庫: http://search.maven.org/#search|gav|1|g%3A%22com.google.android%22%20AND%20a%3A%22android%22

          posted @ 2012-09-16 10:15 胡鵬 閱讀(459) | 評論 (0)編輯 收藏
                  離開淘寶后,自己創(chuàng)業(yè),產(chǎn)品需要推廣,考慮到當今流量最大的聚集在微博上,我們也來做做微博運營,我是一個技術(shù)人員,運營對于我來說,從0開始,站在巨人的肩膀上學(xué)習(xí),稍稍總結(jié)了下。

          1. 使用工具:微博第三方插件已經(jīng)提供了很多功能,適合自己的都用起來,這個我覺得最節(jié)省我的時間,其他網(wǎng)上提供的軟件都可以使用,重要是適合自己,安全第一。

          2. 寫工具:有很多個性化需求的時候,如果變相的不能實現(xiàn),人為處理太慢太花時間,我們現(xiàn)在是小創(chuàng)業(yè)團隊,很多事情都需要自己做,數(shù)據(jù)增長慢,在有限的資源下,寫工具是非常好的方式,作為技術(shù)人員就直接動手寫,當然也需要看看性價比。


          3.微博定位:
          找好本微博的主題,內(nèi)容一般遵循原則:定制+非定制。定制是指針對你的目標群體來選擇內(nèi)容,要讓這部分人感興趣,非定制:是指那種適合任何粉絲的內(nèi)容。

           

          例如:我的目標群體是女性,我的定制內(nèi)容就有美容、護膚、服飾搭配、星座、愛情等女性關(guān)注的話題,非定制的有笑話、經(jīng)典語錄、旅游等大眾類容。根據(jù)內(nèi)容來 建立話題,如#美容護膚# #開心一笑##XX語錄#等等,我就為自己建立了10個左右話題,每天的內(nèi)容按照話題來制作。

           

          4.主要工作流程:(這個圖是轉(zhuǎn)的)


          5.常用的微博話題(這個圖片也是轉(zhuǎn)的)



          6. 關(guān)注項目:微博和主動@,評論,私信,群,邀請,勛章,策劃產(chǎn)品活動,參與微活動

           

           7.微博運營最重要的是:一段時間需要總結(jié)挑選合適的方法執(zhí)行,沒有效果的去除。

          如:微博發(fā)布時間/數(shù)量

          我(轉(zhuǎn),不是我)曾在粉絲超過一萬之后就開始研究的我的微博改什么時候發(fā)布,每天發(fā)布多少。我現(xiàn)在粉絲中做了一個投票:你們一般什么時候織微博。最后有200多人參加, 我大概劃分了5個時段,9-12點,12-17點 17-19點 19-22點 22-24點 0-3點,做多選擇3個答案,結(jié)果出來之后就有個大概了。接下來我用一周的時間從9點—24點之間每1小時發(fā)布一條信息。總共16條信息,我就分析每條信 息的轉(zhuǎn)發(fā)、回復(fù)數(shù)量,一周之后我就可以摸清粉絲的上網(wǎng)時間規(guī)律。然后我選擇哪幾個時間段重點維護,并在那幾個時間段進一步研究發(fā)布數(shù)量規(guī)律,我又分為每1小時,每0.5小時兩個因素來研究發(fā)布數(shù)量。



                
          posted @ 2012-03-28 18:28 胡鵬 閱讀(255) | 評論 (0)編輯 收藏

          JMock是幫助創(chuàng)建mock對象的工具,它基于Java開發(fā),在Java測試與開發(fā)環(huán)境中有不可比擬的優(yōu)勢,更重要的是,它大大簡化了虛擬對象的使用。本文中,通過一個簡單的測試用例來說明JMock如何幫助我們實現(xiàn)這種孤立測試。
              我們在測試某類時,由于它要與其他類發(fā)生聯(lián)系,因此往往在測試此類的代碼中也將與之聯(lián)系的類也一起測試了。這種測試,將使被測試的類直接依賴于其他類,一旦其他類發(fā)生改變,被測試類也隨之被迫改變。更重要的是,這些其他類可能尚未經(jīng)過測試,因此必須先測試這些類,才能測試被測試類。這種情況下,測試驅(qū)動開發(fā)成為空談。而如果其他類中也引用了被測試類,我們到底先測試哪一個類?因此,在測試中,如果我們能將被測試類孤立起來,使其完全不依賴于其他類的具體實現(xiàn),這樣,我們就能做到測試先行,先測試哪個類,就先實現(xiàn)哪個類,而不管與之聯(lián)系的類是否已經(jīng)實現(xiàn)。

              虛擬對象(mock object)就是為此需要而誕生的。它通過JDK中的反射機制,在運行時動態(tài)地創(chuàng)建虛擬對象。在測試代碼中,我們可以驗證這些虛擬對象是否被正確地調(diào)用了,也可以在明確的情況下,讓其返回特定的假想值。而一旦有了這些虛擬對象提供的服務(wù),被測試類就可以將虛擬對象作為其他與之聯(lián)系的真實對象的替身,從而輕松地搭建起一個很完美的測試環(huán)境。

              JMock是幫助創(chuàng)建mock對象的工具,它基于Java開發(fā),在Java測試與開發(fā)環(huán)境中有不可比擬的優(yōu)勢,更重要的是,它大大簡化了虛擬對象的使用。

              本文中,通過一個簡單的測試用例來說明JMock如何幫助我們實現(xiàn)這種孤立測試。有三個主要的類,User,UserDAO,及UserService。本文中,我們只需測試UserService,準備虛擬UserDAO。對于User,由于本身僅是一個過于簡單的POJO,可以不用測試。但如果你是一個完美主義者,也可以使用JMock的虛擬它。在這領(lǐng)域,JMock幾乎無所不能。

          這里我用到的是:(我用的是maven依賴)

                      <dependency>
             <groupId>org.jmock</groupId>
             <artifactId>jmock</artifactId>
             <version>2.5.1</version>
          </dependency>
           
          <dependency>
             <groupId>org.jmock</groupId>
             <artifactId>jmock-junit3</artifactId>
             <version>2.5.1</version>
          </dependency>

          在官方的網(wǎng)站上也有的下載。   地址:  http://jmock.org/dist/jmock-2.5.1-jars.zip

           


          public class User {
          private String name;
          public User() {
          }
          public User(String name) {
          this.name = name;
          }
          public String getName() {
          return name;
          }
          public void setName(String name) {
          this.name = name;
          }
          }

           UserDAO負責(zé)與數(shù)據(jù)庫打交道,通過數(shù)據(jù)庫保存、獲取User的信息。盡管我們可以不用知道JMock如何通過JDK 的反射機制來實現(xiàn)孤立測試,但至少應(yīng)知道,JDK的反射機制要求這些在運行時創(chuàng)建的動態(tài)類必須定義接口。在使用JMock的環(huán)境中,由于我們要虛擬 UserDAO,意味著UserDAO必須定義接口

          public interface UserDAO {
          public User getUser(Long id);
          }

          public interface UserService {
          public void setUserDAO(UserDAO userDAO);
          public User getUser(Long id);
          }



          public class UserServiceImpl implements UserService {
          private UserDAO userDAO;
          public UserServiceImpl() {
          }
          public void setUserDAO(UserDAO userDAO) {
          this.userDAO = userDAO;
          }
          public User getUser(Long id) {
          return userDAO.getUser(id);
          }
          }


           
          import org.jmock.Expectations;
          import org.jmock.integration.junit3.MockObjectTestCase;

          public class UserServiceTest extends MockObjectTestCase {
          private UserService userService = new UserServiceImpl();
          private UserDAO userDAO = null;
          public UserServiceTest(String testName) {
          super(testName);
          }
          protected void setUp() throws Exception {
          userDAO = mock(UserDAO.class);
          userService.setUserDAO(userDAO);
          }
          public void testGetUser() {
          String name = "lsb";
          final User fakeUser = new User(name);
          checking(new Expectations(){{
                      oneOf(userDAO).getUser(1L);
                      will(returnValue(fakeUser));
                  }});
          User user = userService.getUser(1L);
          assertNotNull(user);
          assertEquals(name, user.getName());
          }
          protected void tearDown() throws Exception {
          }
          }

          posted @ 2012-02-23 21:52 胡鵬 閱讀(865) | 評論 (0)編輯 收藏
                   在開發(fā)Android和iPhone應(yīng)用程序時,我們往往需要從服務(wù)器不定的向手 機客戶端即時推送各種通知消息,iPhone上已經(jīng)有了比較簡單的和完美的推送通知解決方案,可是Android平臺上實現(xiàn)起來卻相對比較麻煩,最近利用 幾天的時間對Android的推送通知服務(wù)進行初步的研究。
          在Android手機平臺上,Google提供了C2DM(Cloudto Device Messaging)服務(wù)。

          Android Cloud to Device Messaging (C2DM)是一個用來幫助開發(fā)者從服務(wù)器向Android應(yīng)用程序發(fā)送數(shù)據(jù)的服務(wù)。該服務(wù)提供了一個簡單的、輕量級的機制,允許服務(wù)器可以通知移動應(yīng)用程序直接與服務(wù)器進行通信,以便于從服務(wù)器獲取應(yīng)用程序更新和用戶數(shù)據(jù)。C2DM服務(wù)負責(zé)處理諸如消息排隊等事務(wù)并向運行于目標設(shè)備上的應(yīng)用程序分發(fā)這些消息。

          使用C2DM框架的要求
          1. 需要Android2.2及以上的系統(tǒng)版本
          2. 使用C2DM功能的Android設(shè)備上需要設(shè)置好Google的賬戶。
          3.  C2DM需要依賴于Google官方提供的C2DM服務(wù)器,由于國內(nèi)的網(wǎng)絡(luò)環(huán)境,這個服務(wù)經(jīng)常不可用,如果想要很好的使用,我們的App Server必須也在國外,這個恐怕不是每個開發(fā)者都能夠?qū)崿F(xiàn)的

          要使用C2DM來進行Push操作,基本上要使用以下6個步驟


          (1)注冊:Android設(shè)備把使用C2DM功能的用戶賬戶(比如android.c2dm.demo@gmail.com)和App名稱發(fā)送給C2DM服務(wù)器。

          (2)C2DM服務(wù)器會返回一個registration_id值給Android設(shè)備,設(shè)備需要保存這個registration_id值。

          (3)Android設(shè)備把獲得的registration_id和C2DM功能的用戶賬戶(android.c2dm.demo@gmail.com)發(fā)送給自己的服務(wù)器,不過一般用戶賬戶信息因為和服務(wù)器確定好的,所以不必發(fā)送。

          這樣Android設(shè)備就完成了C2DM功能的注冊過程,接下來就可以接收C2DM服務(wù)器Push過來的消息了。

          (4)服務(wù)器獲得數(shù)據(jù)。這里圖中的例子Chrome To Phone,服務(wù)器接收到Chrome瀏覽器發(fā)送的數(shù)據(jù)。數(shù)據(jù)也可以是服務(wù)器本地產(chǎn)生的。這里的服務(wù)器是Google AppEngine(很好的一項服務(wù),可惜在國內(nèi)被屏了),要換成自己的服務(wù)器。服務(wù)器還要獲取注冊使用C2DM功能的用戶賬戶(android.c2dm.demo@gmail.com)的ClientLogin權(quán)限Auth。

          (5)服務(wù)器把要發(fā)送的數(shù)據(jù)和registration_id一起,并且頭部帶上獲取的Auth,使用POST的方式發(fā)送給C2DM服務(wù)器。

          (6)C2DM服務(wù)器會以Push的方式把數(shù)據(jù)發(fā)送給對應(yīng)的Android設(shè)備,Android設(shè)備只要在程序中按之前和服務(wù)器商量好的格式從對應(yīng)的key中獲取數(shù)據(jù)即可。

          轉(zhuǎn)自:
          posted @ 2011-12-29 17:57 胡鵬 閱讀(1168) | 評論 (0)編輯 收藏

          地理位置索引支持是MongoDB的一大亮點,這也是全球最流行的LBS服務(wù)foursquare 選擇MongoDB的原因之一。我們知道,通常的數(shù)據(jù)庫索引結(jié)構(gòu)是B+ Tree,如何將地理位置轉(zhuǎn)化為可建立B+Tree的形式,下文將為你描述。

          首先假設(shè)我們將需要索引的整個地圖分成16×16的方格,如下圖(左下角為坐標0,0 右上角為坐標16,16):

           

          單純的[x,y]的數(shù)據(jù)是無法建立索引的,所以MongoDB在建立索引的時候,會根據(jù)相應(yīng)字段的坐標計算一個可以用來做索引的hash值,這個值叫做geohash,下面我們以地圖上坐標為[4,6]的點(圖中紅叉位置)為例。

          我們第一步將整個地圖分成等大小的四塊,如下圖:



          劃分成四塊后我們可以定義這四塊的值,如下(左下為00,左上為01,右下為10,右上為11):

          01 11
          00 10

          這樣[4,6]點的geohash值目前為 00

          然后再將四個小塊每一塊進行切割,如下:



          這時[4,6]點位于右上區(qū)域,右上的值為11,這樣[4,6]點的geohash值變?yōu)椋?011

          繼續(xù)往下做兩次切分:




          最終得到[4,6]點的geohash值為:00110100

          這樣我們用這個值來做索引,則地圖上點相近的點就可以轉(zhuǎn)化成有相同前綴的geohash值了。

          我們可以看到,這個geohash值的精確度是與劃分地圖的次數(shù)成正比的,上例對地圖劃分了四次。而MongoDB默認是進行26次劃分,這個值在建立索引時是可控的。具體建立二維地理位置索引的命令如下:

          db.map.ensureIndex({point : "2d"}, {min : 0, max : 16, bits : 4})

          其中的bits參數(shù)就是劃分幾次,默認為26次。










           

          posted @ 2011-11-25 17:19 胡鵬 閱讀(577) | 評論 (0)編輯 收藏
               摘要: java中的引用分為4種:String Reference, WeakReference, softReference,PhantomReference  Strong Reference: 我們平常用的最多的就是強引用了 如:String s = new String("opps");這種形式的引用稱為強引用,這種引用有以下幾個特點 1.強引用可以直接訪問目標對象&...  閱讀全文
          posted @ 2011-10-30 11:59 胡鵬 閱讀(1102) | 評論 (0)編輯 收藏
               摘要:   一、對ThreadLocal概術(shù)             JDK API 寫道: 該類提供了線程局部 (thread-local) 變量。這些變量不同于它們的普通對應(yīng)物,因為訪問某個變量(通過其 get 或 set 方法)的每個線程都有自己的局部變量,它獨立于變量的初始...  閱讀全文
          posted @ 2011-10-29 17:39 胡鵬 閱讀(1446) | 評論 (0)編輯 收藏
               摘要:        起因:在寫java的時候,經(jīng)常遇到函數(shù)需要返回2個值或者3個值,java必須編寫一個Object,來封裝,但很多應(yīng)用場景只是臨時使用,構(gòu)建對象感覺殺雞用宰牛刀,而其他語言有比較好的實現(xiàn)方法。(當然通過指針引用可以解決一部分問題) 如:一般寫法:     Code high...  閱讀全文
          posted @ 2011-10-28 18:35 胡鵬 閱讀(6406) | 評論 (0)編輯 收藏
               摘要:     java.util.concurrent包分成了三個部分,分別是:                        ...  閱讀全文
          posted @ 2011-10-12 17:25 胡鵬 閱讀(2444) | 評論 (0)編輯 收藏
                不復(fù)制內(nèi)容了,可以看戲如下鏈接,還是有很多值得看的東東,有空看下。~

              
              http://terryblog.blog.51cto.com/1764499/547777
          posted @ 2011-07-13 20:12 胡鵬 閱讀(254) | 評論 (0)編輯 收藏


          申請一個Android Maps API Key

          1.找到你的debug.keystore文件所在的路徑:
          證書的一般路徑為:打開eclipse,選擇Windows———>Preference———>Android———>Build,其中Default debug  keystore的值便是debug.keystore的路徑(windows的一般在 C:\Documents and Settings\當前用戶\.android下找到debug.keystore)
          2.在命令提示符中執(zhí)行: keytool -list -keystore debug.keystore  (keytool是java一個命令,在%java_home%\bin里可以看到)
          需要輸入密碼:android
          然后就會得到MD5的值,進入
          http://code.google.com/intl/zh-CN/android/add-ons/google-apis/maps-api-signup.html ,根據(jù)MD5值獲取MAPS API KEY(前提是你必須有一個google賬戶)
          posted @ 2011-06-18 16:37 胡鵬 閱讀(998) | 評論 (0)編輯 收藏
                使input組件的絕對位置覆蓋select組件的選擇框,當select的狀態(tài)發(fā)生改變的時候,使用this.parentNode.nextSibling.value=this.value把select所選擇的值賦給input.

          <HTML> 
          <HEAD> 
          <META http-equiv='Content-Type' content='text/html; charset=gb2312'> 
          <TITLE>可輸入的下拉框</TITLE> 
          </HEAD> 
          <BODY > 
           
          <div style="position:relative;"> 
          <span style="margin-left:100px;width:18px;overflow:hidden;"> 
          <select style="width:118px;margin-left:-100px" onchange="this.parentNode.nextSibling.value=this.value"> 
          <option value="<option value="<option value="WEB開發(fā)者"> WEB開發(fā)者 </option> 
          </select></span><input name="box" style="width:100px;position:absolute;left:0px;"> 
          </div> 
          </BODY></HTML> 

          單例創(chuàng)建模式是一個通用的編程習(xí)語。和多線程一起使用時,必需使用某種類型的同步。在努力創(chuàng)建更有效的代碼時,Java 程序員們創(chuàng)建了雙重檢查鎖定習(xí)語,將其和單例創(chuàng)建模式一起使用,從而限制同步代碼量。然而,由于一些不太常見的 Java 內(nèi)存模型細節(jié)的原因,并不能保證這個雙重檢查鎖定習(xí)語有效。它偶爾會失敗,而不是總失敗。此外,它失敗的原因并不明顯,還包含 Java 內(nèi)存模型的一些隱秘細節(jié)。這些事實將導(dǎo)致代碼失敗,原因是雙重檢查鎖定難于跟蹤。在本文余下的部分里,我們將詳細介紹雙重檢查鎖定習(xí)語,從而理解它在何處失效。

          單例創(chuàng)建習(xí)語

          要理解雙重檢查鎖定習(xí)語是從哪里起源的,就必須理解通用單例創(chuàng)建習(xí)語,如清單 1 中的闡釋:


          清單 1. 單例創(chuàng)建習(xí)語
                                  import java.util.*;
                      class Singleton
                      {
                      private static Singleton instance;
                      private Vector v;
                      private boolean inUse;
                      private Singleton()
                      {
                      v = new Vector();
                      v.addElement(new Object());
                      inUse = true;
                      }
                      public static Singleton getInstance()
                      {
                      if (instance == null)          //1
                      instance = new Singleton();  //2
                      return instance;               //3
                      }
                      }
                      

          此類的設(shè)計確保只創(chuàng)建一個 Singleton 對象。構(gòu)造函數(shù)被聲明為 privategetInstance() 方法只創(chuàng)建一個對象。這個實現(xiàn)適合于單線程程序。然而,當引入多線程時,就必須通過同步來保護 getInstance() 方法。如果不保護 getInstance() 方法,則可能返回 Singleton 對象的兩個不同的實例。假設(shè)兩個線程并發(fā)調(diào)用 getInstance() 方法并且按以下順序執(zhí)行調(diào)用:

          1. 線程 1 調(diào)用 getInstance() 方法并決定 instance 在 //1 處為 null

          2. 線程 1 進入 if 代碼塊,但在執(zhí)行 //2 處的代碼行時被線程 2 預(yù)占。

          3. 線程 2 調(diào)用 getInstance() 方法并在 //1 處決定 instancenull

          4. 線程 2 進入 if 代碼塊并創(chuàng)建一個新的 Singleton 對象并在 //2 處將變量 instance 分配給這個新對象。

          5. 線程 2 在 //3 處返回 Singleton 對象引用。

          6. 線程 2 被線程 1 預(yù)占。

          7. 線程 1 在它停止的地方啟動,并執(zhí)行 //2 代碼行,這導(dǎo)致創(chuàng)建另一個 Singleton 對象。

          8. 線程 1 在 //3 處返回這個對象。

          結(jié)果是 getInstance() 方法創(chuàng)建了兩個 Singleton 對象,而它本該只創(chuàng)建一個對象。通過同步 getInstance() 方法從而在同一時間只允許一個線程執(zhí)行代碼,這個問題得以改正,如清單 2 所示:


          清單 2. 線程安全的 getInstance() 方法
                                  public static synchronized Singleton getInstance()
                      {
                      if (instance == null)          //1
                      instance = new Singleton();  //2
                      return instance;               //3
                      }
                      

          清單 2 中的代碼針對多線程訪問 getInstance() 方法運行得很好。然而,當分析這段代碼時,您會意識到只有在第一次調(diào)用方法時才需要同步。由于只有第一次調(diào)用執(zhí)行了 //2 處的代碼,而只有此行代碼需要同步,因此就無需對后續(xù)調(diào)用使用同步。所有其他調(diào)用用于決定 instance 是非 null 的,并將其返回。多線程能夠安全并發(fā)地執(zhí)行除第一次調(diào)用外的所有調(diào)用。盡管如此,由于該方法是 synchronized 的,需要為該方法的每一次調(diào)用付出同步的代價,即使只有第一次調(diào)用需要同步。

          為使此方法更為有效,一個被稱為雙重檢查鎖定的習(xí)語就應(yīng)運而生了。這個想法是為了避免對除第一次調(diào)用外的所有調(diào)用都實行同步的昂貴代價。同步的代價在不同的 JVM 間是不同的。在早期,代價相當高。隨著更高級的 JVM 的出現(xiàn),同步的代價降低了,但出入 synchronized 方法或塊仍然有性能損失。不考慮 JVM 技術(shù)的進步,程序員們絕不想不必要地浪費處理時間。

          因為只有清單 2 中的 //2 行需要同步,我們可以只將其包裝到一個同步塊中,如清單 3 所示:


          清單 3. getInstance() 方法
                                  public static Singleton getInstance()
                      {
                      if (instance == null)
                      {
                      synchronized(Singleton.class) {
                      instance = new Singleton();
                      }
                      }
                      return instance;
                      }
                      

          清單 3 中的代碼展示了用多線程加以說明的和清單 1 相同的問題。當 instancenull 時,兩個線程可以并發(fā)地進入 if 語句內(nèi)部。然后,一個線程進入 synchronized 塊來初始化 instance,而另一個線程則被阻斷。當?shù)谝粋€線程退出 synchronized 塊時,等待著的線程進入并創(chuàng)建另一個 Singleton 對象。注意:當?shù)诙€線程進入 synchronized 塊時,它并沒有檢查 instance 是否非 null







          雙重檢查鎖定

          為處理清單 3 中的問題,我們需要對 instance 進行第二次檢查。這就是“雙重檢查鎖定”名稱的由來。將雙重檢查鎖定習(xí)語應(yīng)用到清單 3 的結(jié)果就是清單 4 。


          清單 4. 雙重檢查鎖定示例
                                  public static Singleton getInstance()
                      {
                      if (instance == null)
                      {
                      synchronized(Singleton.class) {  //1
                      if (instance == null)          //2
                      instance = new Singleton();  //3
                      }
                      }
                      return instance;
                      }
                      

          雙重檢查鎖定背后的理論是:在 //2 處的第二次檢查使(如清單 3 中那樣)創(chuàng)建兩個不同的 Singleton 對象成為不可能。假設(shè)有下列事件序列:

          1. 線程 1 進入 getInstance() 方法。

          2. 由于 instancenull,線程 1 在 //1 處進入 synchronized 塊。

          3. 線程 1 被線程 2 預(yù)占。

          4. 線程 2 進入 getInstance() 方法。

          5. 由于 instance 仍舊為 null,線程 2 試圖獲取 //1 處的鎖。然而,由于線程 1 持有該鎖,線程 2 在 //1 處阻塞。

          6. 線程 2 被線程 1 預(yù)占。

          7. 線程 1 執(zhí)行,由于在 //2 處實例仍舊為 null,線程 1 還創(chuàng)建一個 Singleton 對象并將其引用賦值給 instance

          8. 線程 1 退出 synchronized 塊并從 getInstance() 方法返回實例。

          9. 線程 1 被線程 2 預(yù)占。

          10. 線程 2 獲取 //1 處的鎖并檢查 instance 是否為 null

          11. 由于 instance 是非 null 的,并沒有創(chuàng)建第二個 Singleton 對象,由線程 1 創(chuàng)建的對象被返回。

          雙重檢查鎖定背后的理論是完美的。不幸地是,現(xiàn)實完全不同。雙重檢查鎖定的問題是:并不能保證它會在單處理器或多處理器計算機上順利運行。

          雙重檢查鎖定失敗的問題并不歸咎于 JVM 中的實現(xiàn) bug,而是歸咎于 Java 平臺內(nèi)存模型。內(nèi)存模型允許所謂的“無序?qū)懭?#8221;,這也是這些習(xí)語失敗的一個主要原因。







          無序?qū)懭?/span>

          為解釋該問題,需要重新考察上述清單 4 中的 //3 行。此行代碼創(chuàng)建了一個 Singleton 對象并初始化變量 instance 來引用此對象。這行代碼的問題是:在 Singleton 構(gòu)造函數(shù)體執(zhí)行之前,變量 instance 可能成為非 null 的。

          什么?這一說法可能讓您始料未及,但事實確實如此。在解釋這個現(xiàn)象如何發(fā)生前,請先暫時接受這一事實,我們先來考察一下雙重檢查鎖定是如何被破壞的。假設(shè)清單 4 中代碼執(zhí)行以下事件序列:

          1. 線程 1 進入 getInstance() 方法。

          2. 由于 instancenull,線程 1 在 //1 處進入 synchronized 塊。

          3. 線程 1 前進到 //3 處,但在構(gòu)造函數(shù)執(zhí)行之前,使實例成為非 null

          4. 線程 1 被線程 2 預(yù)占。

          5. 線程 2 檢查實例是否為 null。因為實例不為 null,線程 2 將 instance 引用返回給一個構(gòu)造完整但部分初始化了的 Singleton 對象。

          6. 線程 2 被線程 1 預(yù)占。

          7. 線程 1 通過運行 Singleton 對象的構(gòu)造函數(shù)并將引用返回給它,來完成對該對象的初始化。

          此事件序列發(fā)生在線程 2 返回一個尚未執(zhí)行構(gòu)造函數(shù)的對象的時候。

          為展示此事件的發(fā)生情況,假設(shè)為代碼行 instance =new Singleton(); 執(zhí)行了下列偽代碼: instance =new Singleton();

          mem = allocate();             //Allocate memory for Singleton object.
                      instance = mem;               //Note that instance is now non-null, but
                      //has not been initialized.
                      ctorSingleton(instance);      //Invoke constructor for Singleton passing
                      //instance.
                      

          這段偽代碼不僅是可能的,而且是一些 JIT 編譯器上真實發(fā)生的。執(zhí)行的順序是顛倒的,但鑒于當前的內(nèi)存模型,這也是允許發(fā)生的。JIT 編譯器的這一行為使雙重檢查鎖定的問題只不過是一次學(xué)術(shù)實踐而已。

          為說明這一情況,假設(shè)有清單 5 中的代碼。它包含一個剝離版的 getInstance() 方法。我已經(jīng)刪除了“雙重檢查性”以簡化我們對生成的匯編代碼(清單 6)的回顧。我們只關(guān)心 JIT 編譯器如何編譯 instance=new Singleton(); 代碼。此外,我提供了一個簡單的構(gòu)造函數(shù)來明確說明匯編代碼中該構(gòu)造函數(shù)的運行情況。


          清單 5. 用于演示無序?qū)懭氲膯卫?/strong>
                                  class Singleton
                      {
                      private static Singleton instance;
                      private boolean inUse;
                      private int val;
                      private Singleton()
                      {
                      inUse = true;
                      val = 5;
                      }
                      public static Singleton getInstance()
                      {
                      if (instance == null)
                      instance = new Singleton();
                      return instance;
                      }
                      }
                      

          清單 6 包含由 Sun JDK 1.2.1 JIT 編譯器為清單 5 中的 getInstance() 方法體生成的匯編代碼。


          清單 6. 由清單 5 中的代碼生成的匯編代碼
                                  ;asm code generated for getInstance
                      054D20B0   mov         eax,[049388C8]      ;load instance ref
                      054D20B5   test        eax,eax             ;test for null
                      054D20B7   jne         054D20D7
                      054D20B9   mov         eax,14C0988h
                      054D20BE   call        503EF8F0            ;allocate memory
                      054D20C3   mov         [049388C8],eax      ;store pointer in
                      ;instance ref. instance
                      ;non-null and ctor
                      ;has not run
                      054D20C8   mov         ecx,dword ptr [eax]
                      054D20CA   mov         dword ptr [ecx],1   ;inline ctor - inUse=true;
                      054D20D0   mov         dword ptr [ecx+4],5 ;inline ctor - val=5;
                      054D20D7   mov         ebx,dword ptr ds:[49388C8h]
                      054D20DD   jmp         054D20B0
                      

          注: 為引用下列說明中的匯編代碼行,我將引用指令地址的最后兩個值,因為它們都以 054D20 開頭。例如,B5 代表 test eax,eax

          匯編代碼是通過運行一個在無限循環(huán)中調(diào)用 getInstance() 方法的測試程序來生成的。程序運行時,請運行 Microsoft Visual C++ 調(diào)試器并將其附到表示測試程序的 Java 進程中。然后,中斷執(zhí)行并找到表示該無限循環(huán)的匯編代碼。

          B0B5 處的前兩行匯編代碼將 instance 引用從內(nèi)存位置 049388C8 加載至 eax 中,并進行 null 檢查。這跟清單 5 中的 getInstance() 方法的第一行代碼相對應(yīng)。第一次調(diào)用此方法時,instancenull,代碼執(zhí)行到 B9BE 處的代碼為 Singleton 對象從堆中分配內(nèi)存,并將一個指向該塊內(nèi)存的指針存儲到 eax 中。下一行代碼,C3,獲取 eax 中的指針并將其存儲回內(nèi)存位置為 049388C8 的實例引用。結(jié)果是,instance 現(xiàn)在為非 null 并引用一個有效的 Singleton 對象。然而,此對象的構(gòu)造函數(shù)尚未運行,這恰是破壞雙重檢查鎖定的情況。然后,在 C8 行處,instance 指針被解除引用并存儲到 ecxCAD0 行表示內(nèi)聯(lián)的構(gòu)造函數(shù),該構(gòu)造函數(shù)將值 true5 存儲到 Singleton 對象。如果此代碼在執(zhí)行 C3 行后且在完成該構(gòu)造函數(shù)前被另一個線程中斷,則雙重檢查鎖定就會失敗。

          不是所有的 JIT 編譯器都生成如上代碼。一些生成了代碼,從而只在構(gòu)造函數(shù)執(zhí)行后使 instance 成為非 null。針對 Java 技術(shù)的 IBM SDK 1.3 版和 Sun JDK 1.3 都生成這樣的代碼。然而,這并不意味著應(yīng)該在這些實例中使用雙重檢查鎖定。該習(xí)語失敗還有一些其他原因。此外,您并不總能知道代碼會在哪些 JVM 上運行,而 JIT 編譯器總是會發(fā)生變化,從而生成破壞此習(xí)語的代碼。







          雙重檢查鎖定:獲取兩個

          考慮到當前的雙重檢查鎖定不起作用,我加入了另一個版本的代碼,如清單 7 所示,從而防止您剛才看到的無序?qū)懭雴栴}。


          清單 7. 解決無序?qū)懭雴栴}的嘗試
                                  public static Singleton getInstance()
                      {
                      if (instance == null)
                      {
                      synchronized(Singleton.class) {      //1
                      Singleton inst = instance;         //2
                      if (inst == null)
                      {
                      synchronized(Singleton.class) {  //3
                      inst = new Singleton();        //4
                      }
                      instance = inst;                 //5
                      }
                      }
                      }
                      return instance;
                      }
                      

          看著清單 7 中的代碼,您應(yīng)該意識到事情變得有點荒謬。請記住,創(chuàng)建雙重檢查鎖定是為了避免對簡單的三行 getInstance() 方法實現(xiàn)同步。清單 7 中的代碼變得難于控制。另外,該代碼沒有解決問題。仔細檢查可獲悉原因。

          此代碼試圖避免無序?qū)懭雴栴}。它試圖通過引入局部變量 inst 和第二個 synchronized 塊來解決這一問題。該理論實現(xiàn)如下:

          1. 線程 1 進入 getInstance() 方法。

          2. 由于 instancenull,線程 1 在 //1 處進入第一個 synchronized 塊。

          3. 局部變量 inst 獲取 instance 的值,該值在 //2 處為 null

          4. 由于 instnull,線程 1 在 //3 處進入第二個 synchronized 塊。

          5. 線程 1 然后開始執(zhí)行 //4 處的代碼,同時使 inst 為非 null,但在 Singleton 的構(gòu)造函數(shù)執(zhí)行前。(這就是我們剛才看到的無序?qū)懭雴栴}。)

          6. 線程 1 被線程 2 預(yù)占。

          7. 線程 2 進入 getInstance() 方法。

          8. 由于 instancenull,線程 2 試圖在 //1 處進入第一個 synchronized 塊。由于線程 1 目前持有此鎖,線程 2 被阻斷。

          9. 線程 1 然后完成 //4 處的執(zhí)行。

          10. 線程 1 然后將一個構(gòu)造完整的 Singleton 對象在 //5 處賦值給變量 instance,并退出這兩個 synchronized 塊。

          11. 線程 1 返回 instance

          12. 然后執(zhí)行線程 2 并在 //2 處將 instance 賦值給 inst

          13. 線程 2 發(fā)現(xiàn) instance 為非 null,將其返回。

          這里的關(guān)鍵行是 //5。此行應(yīng)該確保 instance 只為 null 或引用一個構(gòu)造完整的 Singleton 對象。該問題發(fā)生在理論和實際彼此背道而馳的情況下。

          由于當前內(nèi)存模型的定義,清單 7 中的代碼無效。Java 語言規(guī)范(Java Language Specification,JLS)要求不能將 synchronized 塊中的代碼移出來。但是,并沒有說不能將 synchronized 塊外面的代碼移 synchronized 塊中。

          JIT 編譯器會在這里看到一個優(yōu)化的機會。此優(yōu)化會刪除 //4 和 //5 處的代碼,組合并且生成清單 8 中所示的代碼。


          清單 8. 從清單 7 中優(yōu)化來的代碼。
                                  public static Singleton getInstance()
                      {
                      if (instance == null)
                      {
                      synchronized(Singleton.class) {      //1
                      Singleton inst = instance;         //2
                      if (inst == null)
                      {
                      synchronized(Singleton.class) {  //3
                      //inst = new Singleton();      //4
                      instance = new Singleton();
                      }
                      //instance = inst;               //5
                      }
                      }
                      }
                      return instance;
                      }
                      

          如果進行此項優(yōu)化,您將同樣遇到我們之前討論過的無序?qū)懭雴栴}。







          用 volatile 聲明每一個變量怎么樣?

          另一個想法是針對變量 inst 以及 instance 使用關(guān)鍵字 volatile。根據(jù) JLS(參見 參考資料),聲明成 volatile 的變量被認為是順序一致的,即,不是重新排序的。但是試圖使用 volatile 來修正雙重檢查鎖定的問題,會產(chǎn)生以下兩個問題:

          • 這里的問題不是有關(guān)順序一致性的,而是代碼被移動了,不是重新排序。

          • 即使考慮了順序一致性,大多數(shù)的 JVM 也沒有正確地實現(xiàn) volatile

          第二點值得展開討論。假設(shè)有清單 9 中的代碼:


          清單 9. 使用了 volatile 的順序一致性
                                  class test
                      {
                      private volatile boolean stop = false;
                      private volatile int num = 0;
                      public void foo()
                      {
                      num = 100;    //This can happen second
                      stop = true;  //This can happen first
                      //...
                      }
                      public void bar()
                      {
                      if (stop)
                      num += num;  //num can == 0!
                      }
                      //...
                      }
                      

          根據(jù) JLS,由于 stopnum 被聲明為 volatile,它們應(yīng)該順序一致。這意味著如果 stop 曾經(jīng)是 truenum 一定曾被設(shè)置成 100。盡管如此,因為許多 JVM 沒有實現(xiàn) volatile 的順序一致性功能,您就不能依賴此行為。因此,如果線程 1 調(diào)用 foo 并且線程 2 并發(fā)地調(diào)用 bar,則線程 1 可能在 num 被設(shè)置成為 100 之前將 stop 設(shè)置成 true。這將導(dǎo)致線程見到 stoptrue,而 num 仍被設(shè)置成 0。使用 volatile 和 64 位變量的原子數(shù)還有另外一些問題,但這已超出了本文的討論范圍。有關(guān)此主題的更多信息,請參閱 參考資料







          解決方案

          底線就是:無論以何種形式,都不應(yīng)使用雙重檢查鎖定,因為您不能保證它在任何 JVM 實現(xiàn)上都能順利運行。JSR-133 是有關(guān)內(nèi)存模型尋址問題的,盡管如此,新的內(nèi)存模型也不會支持雙重檢查鎖定。因此,您有兩種選擇:

          • 接受如清單 2 中所示的 getInstance() 方法的同步。

          • 放棄同步,而使用一個 static 字段。

          選擇項 2 如清單 10 中所示


          清單 10. 使用 static 字段的單例實現(xiàn)
                                  class Singleton
                      {
                      private Vector v;
                      private boolean inUse;
                      private static Singleton instance = new Singleton();
                      private Singleton()
                      {
                      v = new Vector();
                      inUse = true;
                      //...
                      }
                      public static Singleton getInstance()
                      {
                      return instance;
                      }
                      }
                      

          清單 10 的代碼沒有使用同步,并且確保調(diào)用 static getInstance() 方法時才創(chuàng)建 Singleton。如果您的目標是消除同步,則這將是一個很好的選擇。







          String 不是不變的

          鑒于無序?qū)懭牒鸵迷跇?gòu)造函數(shù)執(zhí)行前變成非 null 的問題,您可能會考慮 String 類。假設(shè)有下列代碼:

          private String str;
                      //...
                      str = new String("hello");
                      

          String 類應(yīng)該是不變的。盡管如此,鑒于我們之前討論的無序?qū)懭雴栴},那會在這里導(dǎo)致問題嗎?答案是肯定的。考慮兩個線程訪問 String str。一個線程能看見 str 引用一個 String 對象,在該對象中構(gòu)造函數(shù)尚未運行。事實上,清單 11 包含展示這種情況發(fā)生的代碼。注意,這個代碼僅在我測試用的舊版 JVM 上會失敗。IBM 1.3 和 Sun 1.3 JVM 都會如期生成不變的 String


          清單 11. 可變 String 的例子
                                  class StringCreator extends Thread
                      {
                      MutableString ms;
                      public StringCreator(MutableString muts)
                      {
                      ms = muts;
                      }
                      public void run()
                      {
                      while(true)
                      ms.str = new String("hello");          //1
                      }
                      }
                      class StringReader extends Thread
                      {
                      MutableString ms;
                      public StringReader(MutableString muts)
                      {
                      ms = muts;
                      }
                      public void run()
                      {
                      while(true)
                      {
                      if (!(ms.str.equals("hello")))         //2
                      {
                      System.out.println("String is not immutable!");
                      break;
                      }
                      }
                      }
                      }
                      class MutableString
                      {
                      public String str;                         //3
                      public static void main(String args[])
                      {
                      MutableString ms = new MutableString();  //4
                      new StringCreator(ms).start();           //5
                      new StringReader(ms).start();            //6
                      }
                      }
                      

          此代碼在 //4 處創(chuàng)建一個 MutableString 類,它包含了一個 String 引用,此引用由 //3 處的兩個線程共享。在行 //5 和 //6 處,在兩個分開的線程上創(chuàng)建了兩個對象 StringCreatorStringReader。傳入一個 MutableString 對象的引用。StringCreator 類進入到一個無限循環(huán)中并且使用值“hello”在 //1 處創(chuàng)建 String 對象。StringReader 也進入到一個無限循環(huán)中,并且在 //2 處檢查當前的 String 對象的值是不是 “hello”。如果不行,StringReader 線程打印出一條消息并停止。如果 String 類是不變的,則從此程序應(yīng)當看不到任何輸出。如果發(fā)生了無序?qū)懭雴栴},則使 StringReader 看到 str 引用的惟一方法絕不是值為“hello”的 String 對象。

          在舊版的 JVM 如 Sun JDK 1.2.1 上運行此代碼會導(dǎo)致無序?qū)懭雴栴}。并因此導(dǎo)致一個非不變的 String







          結(jié)束語

          為避免單例中代價高昂的同步,程序員非常聰明地發(fā)明了雙重檢查鎖定習(xí)語。不幸的是,鑒于當前的內(nèi)存模型的原因,該習(xí)語尚未得到廣泛使用,就明顯成為了一種不安全的編程結(jié)構(gòu)。重定義脆弱的內(nèi)存模型這一領(lǐng)域的工作正在進行中。盡管如此,即使是在新提議的內(nèi)存模型中,雙重檢查鎖定也是無效的。對此問題最佳的解決方案是接受同步或者使用一個 static field

          posted @ 2011-05-08 19:17 胡鵬 閱讀(346) | 評論 (0)編輯 收藏
          薪水族如何“錢滾錢” 教你用2萬賺到1000萬
          工薪族月薪2000元的理財竅門
          在有很多的大學(xué)生都是在畢業(yè)以后選擇留在自己上學(xué)的城市,一來對城市有了感情,二來也希望能在大的城市有所發(fā)展,而現(xiàn)在很多大城市勞動力過剩,大學(xué)生想找到一個自己喜歡又有較高收入的職位已經(jīng)變得非常難,很多剛畢業(yè)的朋友的月收入都可能徘徊在2000元人民幣左右,如果您是這樣的情況,讓我們來核算一下,如何利用手中的有限資金來進行理財。如果您是單身一人,月收入在2000人民幣,又沒有其他的獎金分紅等收入,那年收入就固定在25000元左右。如何來支配這些錢呢?
          生活費占收入30%-40%
          首先,你要拿出每個月必須支付的生活費。如房租、水電、通訊費、柴米油鹽等,這部分約占收入三分之一。它們是你生活中不可或缺的部分,滿足你最基本的物質(zhì)需求。離開了它們,你就會像魚兒離開了水一樣無法生活,所以無論如何,請你先從收入中抽出這部分,不要動用。
          儲蓄占收入10%-20%
          其次,是自己用來儲蓄的部分,約占收入的10%-20%。很多人每次也都會在月初存錢,但是到了月底的時候,往往就變成了泡沫,存進去的大部分又取出來了,而且是不知不覺的,好像憑空消失了一樣,總是在自己喜歡的衣飾、雜志、CD或朋友聚會上不加以節(jié)制。你要自己提醒自己,起碼,你的存儲能保證你3個月的基本生活。要知道,現(xiàn)在很多公司動輒減薪裁員。如果你一點儲蓄都沒有,一旦工作發(fā)生了變動,你將會非常被動。
          而且這3個月的收入可以成為你的定心丸,工作實在干得不開心了,忍無可忍無需再忍時,你可以瀟灑地對老板說聲“拜拜”。想想可以不用受你不喜歡的工作和人的氣,是多么開心的事啊。所以,無論如何,請為自己留條退路。
          活動資金占收入30%~40%
          剩下的這部分錢,約占收入的三分之一。可以根據(jù)自己當時的生活目標,側(cè)重地花在不同的地方。譬如“五一”、“十一”可以安排旅游;服裝打折時可以購進自己心儀已久的牌子貨;還有平時必不可少的購買CD、朋友聚會的開銷。這樣花起來心里有數(shù),不會一下子把錢都用完。
          最關(guān)鍵的是,即使一發(fā)薪水就把這部分用完了,也可當是一次教訓(xùn),可以懲罰自己一個月內(nèi)什么都不能再干了(就當是收入全部支出了吧),印象會很深刻而且有效。
          除去吃、穿、住、行以及其他的消費外,再怎么節(jié)省,估計您現(xiàn)在的狀況,一年也只有10000元的積蓄,想來這些都是剛畢業(yè)的絕大部分學(xué)生所面臨的實際情況。如何讓錢生錢是大家想得最多的事情,然而,畢竟收入有限,很多想法都不容易實現(xiàn),建議處于這個階段的朋友,最重要的是開源,節(jié)流只是我們生活工作的一部分,就像大廈的基層一樣。而最重要的是怎樣財源滾滾、開源有道,為了達到一個新目標,你必須不斷進步以求發(fā)展,培養(yǎng)自己的實力以求進步,這才是真正的生財之道。可以安心地發(fā)展自己的事業(yè),積累自己的經(jīng)驗,充實自己,使自己不斷地提高,才會有好的發(fā)展,要相信“機會總是給有準備的人”。
          當然,既然有了些許積蓄,也不能讓它閑置,我們建議把1萬元分為5份,分成5個2000元,分別作出適當?shù)耐顿Y安排。這樣,家庭不會出現(xiàn)用錢危機,并可以獲得最大的收益。
          (1)用2000元買國債,這是回報率較高而又很保險的一種投資。
          (2)用2000元買保險。以往人們的保險意識很淡薄,實際上購買保險也是一種較好的投資方式,而且保險金不在利息稅征收之列。尤其是各壽險公司都推出了兩全型險種,增加了有關(guān)“權(quán)益轉(zhuǎn)換”的條款,即一旦銀行利率上升,客戶可在保險公司出售的險種中進行轉(zhuǎn)換,并獲得保險公司給予的一定的價格折扣、免予核保等優(yōu)惠政策。
          (3)用2000元買股票。這是一種風(fēng)險最大的投資,當然風(fēng)險與收益是并存的,只要選擇得當,會帶來理想的投資回報。除股票外,期貨、投資債券等都屬這一類。不過,參與這類投資,要求有相應(yīng)的行業(yè)知識和較強的風(fēng)險意識。
          (4)用2000元存定期存款,這是一種幾乎沒有風(fēng)險的投資方式,也是未來對家庭生活的一種保障。
          (5)用2000元存活期存款,這是為了應(yīng)急之用。如家里臨時急需用錢,有一定數(shù)量的活期儲蓄存款可解燃眉之急,而且存取又很方便。
          這種方法是許多人經(jīng)過多年嘗試后總結(jié)出的一套成功的理財經(jīng)驗。當然,各個家庭可以根據(jù)不同情況,靈活使用。
          正確理財三個觀念
          建立理財觀念一:理財是一件正大光明的事,“你不理財,財不理你”。
          建立理財觀念二:理財要從現(xiàn)在開始,并長期堅持。
          建立理財觀念三:理財目的是“梳理財富,增值生活”。
          理財四個誤區(qū)
          理財觀念誤區(qū)一:我沒財可理;
          理財觀念誤區(qū)二:我不需要理財;
          理財觀念誤區(qū)三:等我有了錢再理財;
          理財觀念誤區(qū)四:會理財不如會掙錢。
          理財?shù)奈宕竽繕?/strong>
          目標一:獲得資產(chǎn)增值;
          目標二:保證資金安全;
          目標三:防御意外事故;
          目標四:保證老有所養(yǎng);
          目標五:提供贍養(yǎng)父母及撫養(yǎng)教育子女的基金。
          --------------------精彩閱讀推薦--------------------
          【500強企業(yè)的薪水有多高?】
          全球500強大企業(yè)的薪水實情大揭密
          不一定要是自己的offer letter上的數(shù)據(jù),凡是能夠確認比較準確的公司薪水都可補充。補充的話最好說明職位、本碩區(qū)別、多少個月工資、獎金。寶潔:本7200、研8200、博9700,均14個月,另有交通補助,區(qū)域補助等,CBD,marketing每幾個月漲20%-30%不定。
          【工薪族的你跑贏通脹了嗎?】
          工薪族理財跑贏通脹 開源節(jié)流資產(chǎn)合理配備
          龍先生家是典型的工薪階層。龍先生47歲,是某大型企業(yè)的技術(shù)師,年收入5.5萬元,購買了各類基本保險。太太42歲,是某商場的合同工,年收入4萬元,購買了基本的社會保險。兩人均在單位吃中午飯,搭班車上下班。兒子16歲,尚在讀高中。
          【怎樣才能錢生錢?】
          “階梯存儲”應(yīng)對利率調(diào)整 學(xué)三招輕松錢生錢
          當前,儲蓄依然在居民理財?shù)耐顿Y組合中占據(jù)著重要地位,但在當前的加息周期內(nèi),一些人因缺乏科學(xué)的儲蓄理財規(guī)劃而損失利息收入。理財專家建議,進入加息周期,為了使儲蓄理財能賺取更多的利息收入,儲戶應(yīng)在存款期限、存款金額和存款方式上注意以下幾點。
          【爺們的臉往哪擱!】
          女人太會賺錢也是錯? 爺們兒的臉往哪擱
          女人財大就氣粗?別偏激,妻子賺錢自己也是受益者,所以首先心態(tài)放平和些,別太執(zhí)著于傳統(tǒng)的思維和他人的看法。會不會賺錢是女人衡量男人的重要標尺。男人沒錢,女人覺得沒有面子,不愿提及她的男人;有錢男人不怕提及他女人,無論漂亮與否,只要不給他戴綠帽子。
          posted @ 2011-03-10 20:07 胡鵬 閱讀(155) | 評論 (0)編輯 收藏
                 

                  說起精致,最容易想起的詞大概是瓷器了,但這個詞用到程序員身上,肯定讓很多人覺得摸不著頭腦,在詳述"精致"這個詞以前,還是先來看一個"破窗理論",讓我們真正的理解"精致"的概念。

                 最早的"破窗理論",也稱"破窗謬論",源自于一位經(jīng)濟學(xué)家黑茲利特(也有人說源于法國19世紀經(jīng)濟學(xué)家巴斯夏),用來指出"破壞創(chuàng)造財富"的概念,以徹底地否定凱恩斯主義的政府干預(yù)政策。但后來美國斯坦福大學(xué)心理學(xué)家詹巴斗和犯罪學(xué)家凱琳也提出了相應(yīng)的"破窗理論"。

                  心理學(xué)家詹巴斗進行了一項試驗,他把兩輛一模一樣的汽車分別停放在帕羅阿爾托的中產(chǎn)階級社區(qū)和相對雜亂的布朗克斯街區(qū)。對停在布朗克斯街區(qū)的那一輛,他摘掉了車牌,并且把頂棚打開,結(jié)果不到一天就被人偷走了;而停放在帕羅阿爾托的那一輛,停了一個星期也無人問津。后來,詹巴斗用錘子把這輛車的玻璃敲了個大洞,結(jié)果僅僅過了幾個小時車就不見了。

                 而犯罪學(xué)家凱琳曾注意到一個問題:在她上班的路旁,有一座非常漂亮的大樓,有一天,她注意到樓上有一窗子的玻璃被打破了,那扇破窗與整座大樓的整潔美麗極不調(diào)諧,顯得格外的刺眼。又過了一段時間,她驚奇地發(fā)現(xiàn):那扇破窗不但沒得到及時的維修,反而又增加了幾個帶爛玻璃的窗子……這一發(fā)現(xiàn)使她的心中忽有所悟:如果有人打壞了一個建筑物的窗戶玻璃,而這扇窗戶又得不到及時維修的話,別人就可能受到某些暗示性的縱容去打爛更多的玻璃。久而久之,這些破窗戶就給人造成一種無序的感覺;其結(jié)果是:在這種麻木不仁的氛圍中,犯罪就會滋生。這就是凱琳著名的"破窗理論"。

                  后來的"破窗理論",已經(jīng)突破原有經(jīng)濟學(xué)上的概念,有了新的意義:殘缺不全的東西更容易遭受到別人的破壞。前面的汽車和窗戶都表明了這一點。

                 其實作為程序員開發(fā)軟件也是一樣,可能有十種好的方法去寫一個功能,一個類,但同時可能會有一百種更快捷但不好的方法去做同樣的事情,很多程序員會因為各種原因,如時間壓力,工作強度,技術(shù)水平等一系列問題選擇了后者而非前者。同樣的事情還發(fā)生在維護和修改階段,當看到別人的代碼寫的隨意,不好時,那么自然就會沿著別人的方向走下去,結(jié)果就是產(chǎn)生出更多不好的代碼,這是在代碼開發(fā)中的一個典型"破窗理論"的體現(xiàn)。

             承認一點,現(xiàn)實世界是不完美,特別是開發(fā)中,因為時間,精力,能力等各種因素,我們始終是要打破一些窗戶,但是卻要記住兩點:
                  1.一個月前多打破了一扇窗戶,結(jié)果一個月就會打破10 扇甚至更多的窗戶。
                  2.如果打破了一扇窗戶,就要記住,遲早應(yīng)該將它補上。

                  因為各方面的原因,一個程序員也許不能做到精致的代碼,但是如果一個程序員不想去做精致的代碼,那么又何必選擇軟件開發(fā)呢?
          posted @ 2011-01-11 22:35 胡鵬 閱讀(190) | 評論 (0)編輯 收藏
           

          最近有Java解壓縮的需求,java.util.zip實在不好用,對中文支持也不行。所以選擇了強大的TrueZIP,使用時遇到了一個問題,做個記錄。
          解壓縮代碼如下:

          ArchiveDetector detector = new DefaultArchiveDetector(ArchiveDetector.ALL,
                  new Object[] { "zip", new CheckedZip32Driver("GBK") } );
          File zipFile = new File("zipFile", detector);
          File dst = new File("dst");
          // 解壓縮
          zipFile.copyAllTo(dst);

          代碼十分簡潔,注意這個File是

          de.schlichtherle.io.File

          不是

          java.io.File

          當處理完業(yè)務(wù)要刪除這個Zip File時,問題出現(xiàn)了:
          這個文件刪不掉!!!
          把自己的代碼檢查了好久,確認沒問題后,開始從TrueZIP下手,發(fā)現(xiàn)它有特殊的地方的,是提示過的:

          File file = new File(“archive.zip”); // de.schlichtherle.io.File!
          Please do not do this instead:
          de.schlichtherle.io.File file = new de.schlichtherle.io.File(“archive.zip”);


          This is for the following reasons:
          1.Accidentally using java.io.File and de.schlichtherle.io.File instances referring to the same path concurrently will result in erroneous behaviour and may even cause loss of data! Please refer to the section “Third Party Access” in the package Javadoc of de.schlichtherle.io for for full details and workarounds.
          2.A de.schlichtherle.io.File subclasses java.io.File and thanks to polymorphism can be used everywhere a java.io.File could be used.

          原來兩個File不能交叉使用,搞清楚原因了,加這么一句代碼搞定。

          zipFile.deleteAll();

          posted @ 2011-01-11 22:30 胡鵬 閱讀(1298) | 評論 (0)編輯 收藏
          http://www.aygfsteel.com/Files/lsbwahaha/ANTLR_info.pdf
          antlr簡介


          目前的ANTLR支持的語法層的選項主要包括:

          語言選項(Language)、

          輸出選項(output)、

          回溯選項(backtrack)、

          記憶選項 memorize)、

          記號詞庫(tokenVocab)、

          重寫選項(rewrite)、

          超類選項(superClass)、

          過濾選項(Filter)、

          AST標簽類型(ASTLabelType

          K選項

           

           

          /**
                  //一些寫法







          k=2;

                  backtrack=true;

                  memoize=true;

          */

           

          1.   語言選項 language

           

          語言選項指定了ANTLR將要產(chǎn)生的代碼的目標語言,默認情況下該選項設(shè)置為了Java。需要注意的是,ANTLR中的嵌入的動作必須要使用目標語言來寫。

          grammar T;
          options {
              language=Java;
          }

           

          ANTLR使用了特有的基于字串模板(StringTemplate-based)代碼生成器,構(gòu)建一個新的目標語言顯得較為簡單,因此我們可以構(gòu)建多種 語言,諸如JavaCC++C#PythonObjective-CRuby等等。語言選項讓ANNTLR去模板目錄(例如 org/antlr/codegen/templates/Java or org/antlr/codegen/templates/C)下尋找合適的模板,并使用模板來構(gòu)建語言。該目錄下包含大量的模板,我們可以向其中加入其 他的模板以滿足我們的需求。

          2.   輸出選項 output

          輸出選項控制了ANTLR輸出的數(shù)據(jù)結(jié)構(gòu),目前支持兩種輸出:抽象語法樹——ASTAbstract Syntax Trees)和字串模板(StringTemplates——template。當output這個選項被設(shè)置后,所有的規(guī)則都被輸出成了AST或者 template

          grammar T;
          options {
              output=AST;
          }

           

          3.   回溯選項backtrack

          當回溯選項打開的時候,在執(zhí)行一個LL(K)失敗的時候,ANTLR會返回至LL(K)開始而嘗試其他的規(guī)則。

           

          4.   記憶選項 memorize

          memoize選項打開以后,每條解析方法(Paser Method)開始之前,ANTLR會首先檢測以前的嘗試結(jié)果,并在該方法執(zhí)行完成之后記錄該規(guī)則是否執(zhí)行成功。但是注意,對于單條的規(guī)則打開此選項經(jīng)常比在全局上打開該規(guī)則效率更高。

           

          5.   記號詞庫(tokenVocab

          說白了就是output輸出目錄中的XX.tokens文件中的定義可以方便的給 大型工程中多個.g中的符號同步更新。

           

          大型的工程中常常利用AST作為中間產(chǎn)物對輸入進行多次分析并最終生成代碼。對AST的遍歷時需要經(jīng)常使用樹語法(tree grammar),而tree grammar中經(jīng)常需要將符號與其他的文件中的符號進行同步或者更新。tokenVocab實現(xiàn)了這個功能。
          例如我們定義了下面的一個語法文件:

          grammar P;
          options {
              output=AST;
          }
          expr: INT ('+' ^ INT)* ;
          INT : '0'..'9' +;
          WS : ' ' | '\r' | '\n' ;
          利用該文件生成了一個標記:P.token,并生成了語法樹(AST)。這時我們需要一個用于遍歷該ASTtree grammar,并通過tree grammar 中的tokenVocab選項來向其中更新tokens:

          tree grammar Dump;
          options {
              tokenVocab=P;
              ASTLabelType=CommonTree;
          }
          expr: ^( '+' expr {System.out.print('+' );} expr )
              | INT {System.out.print($INT.text);}
              ;

          編譯tree grammar的時候ANTLR默認會在當前目錄下尋找.token文件,我們可以通過-lib選項來設(shè)置用于尋找.token文件的目錄,例如:
          java org.antlr.Tool -lib . Dump.g

          6.   重寫選項(rewrite

          通過重寫選項可以改變ANTLR對輸入的默認處理規(guī)則,一般用在輸出為template的情況下。將該選項使能之后,ANTLR將一般的輸入直接拷貝至輸出,而將適于模板重寫規(guī)則的輸入做其他的處理。

          7.   超類選項(superClass

          用于指定一個超類。

          8.   過濾選項(Filter

          9.   AST標簽類型(ASTLabelType

          10.             K選項

             K選項用于限制對LL(K)進行語法分析的次數(shù),從而提高了ANTLR的解析速度。K只能為*或者數(shù)字,默認為*

           

           

           

           

          屬性和動作

          動作(Actions)實際上是用目標語言寫成的、嵌入到規(guī)則中的代碼(以花括號包裹)。它們通常直接操作輸入的標號,但是他們也可以用來調(diào)用相應(yīng)的外部代碼。屬性,到目前為止我的理解還不多,感覺像是C++中類里面的成員,一會看完應(yīng)該會更清楚一些。

          1.
          語法動作(Grammar Actions
          動作(Actions)是指嵌在語法中的、用目標語言寫成的代碼片段。ANTLR則把這些代碼(除了用$%標記的以外)逐字地插入到生成的識別器中。
          動作可以放到規(guī)則的外邊,也可以嵌入到某條規(guī)則當中。當動作位于規(guī)則之外時候,這些動作同城定義了一些全局的或者是類的成員(變量或者成員函數(shù));而當其嵌入規(guī)則之中時,則用于執(zhí)行某些特定的命令,這些命令在識別器識別了其預(yù)訂的字符的時候就會開始執(zhí)行。例如下面的例子:

          parser grammar T;
          @header {
              package p;
          }
          @members {
              int i;
              public TParser(TokenStream input, int foo) {
                  this(input);
                  i = foo;
              }
          }
          a[int x] returns [int y]
          @init {int z=0;}
          @after {System.out.println("after matching rule; before finally");}
          : {
          action1} A {action2 }
          ;
          catch[RecognitionException re] {
              System.err.println("error");
          }
          finally {
          do-this-no-matter-what }

          從中可以看出,前面的兩個動作,@head and @members是兩個處于規(guī)則之外的全局的動作,定義了一些變量和類;而后兩個則分別在a這個規(guī)則的前后執(zhí)行(@init在前,@after在后,這個在前面提到過)。 這里針對兩種類型詳細敘述。


          antlr簡介
          posted @ 2010-12-17 19:20 胡鵬 閱讀(1511) | 評論 (0)編輯 收藏

          1. 需要有全職的有威信,有能力的產(chǎn)品負責(zé)人(PO-Product Owner).
          2. PO要和Scrum Team、其他的利益相關(guān)者(stakeholder)一起工作
          3. 有PO來創(chuàng)建和管理產(chǎn)品backlog.
          4. Scrum每日站會必須的3個問題(完成了什么,準備做什么,有什么障礙)。
          5. Scrum每日站會要在固定的地方時間不要超過15分鐘。
          6. 有規(guī)律的Sprint長度(不超過30天)
          7. 在Sprint計劃會議上創(chuàng)建Sprint Backlog和經(jīng)過詳細估算的任務(wù)列表。
          8. 一定要有Sprint的燃盡圖。
          9. Team必須的設(shè)備及相關(guān)的供應(yīng)要齊全。
          10. 使用回顧會議確保過程在不斷提升。
          11. 有明確的對于“任務(wù)完成”的定義。
          12. 按照合理的速率給出承諾(根據(jù)Sprint的工作量估計)。
          13. 團隊大小在7 +/- 2,最多不能超過12人
          14. 跨職能的團隊包括Scrum Master和PO.
          15. 自組織的團隊 - 團隊成員志愿挑選任務(wù)。
          16. Scrum master要跟蹤進度,并且為團隊掃清障礙。
          17. 確保Team不被外界干擾。
          18. Sprint之間不能間斷。
          19. 合理的節(jié)奏 - 根據(jù)固定時間段來確定任務(wù)量, 不只是一個進度表。
          20. 質(zhì)量是第一,不需要在質(zhì)量上討價還價 - 代碼缺陷永遠位于Backlog的最上層。


          posted @ 2010-11-29 10:20 胡鵬 閱讀(223) | 評論 (0)編輯 收藏
          javaeye上一篇文章不錯,介紹Linux文件系統(tǒng)簡介的,講解比較基礎(chǔ),遺忘的時候看下不錯的,記錄一下~!~
          http://www.javaeye.com/topic/816268
          posted @ 2010-11-28 10:30 胡鵬 閱讀(184) | 評論 (0)編輯 收藏

             轉(zhuǎn)載于:http://www.infoq.com/cn/articles/skills-for-scrum-agile-teams 

          敏捷項目的工程獨特性

             1. 設(shè)置開發(fā)環(huán)境
               
               
          在傳統(tǒng)項目中,團隊可以投入充分的時間來設(shè)置開發(fā)環(huán)境;而在敏捷團隊里面,他們需要從第一刻時間起就能產(chǎn)出。根據(jù)我們的經(jīng)驗,我們認識到缺乏設(shè)置開發(fā)環(huán)境的相關(guān)文檔是設(shè)置環(huán)境如此耗時的一個關(guān)鍵原因。第二個關(guān)鍵原因是在設(shè)置過程中涉及的手工步驟數(shù)。在第0次sprint,我們必須記錄每一件開發(fā)人員必須做了才能開始編寫代碼,并集成團隊其他人工作的小事。


             2. 自動構(gòu)建
            
                 讓我們盡早失敗!我們領(lǐng)悟到,手工構(gòu)建可能既脆弱,又特定于某一臺機器,而且當時間耗費在手工構(gòu)建的基礎(chǔ)工作上面時,開發(fā)和測試的時間就被擠占掉了。除去最小的項目,自動構(gòu)建過程對于每一個項目都是必不可少的。我們認識到,即使需要抽出時間來創(chuàng)建自動構(gòu)建的環(huán)境,你以后是能把這些時間賺回來的。這也使得我們更易于確保項目有一個人人共有的標準化構(gòu)建。

             3. 持續(xù)集成

               
          根據(jù)我們過去的經(jīng)驗,我們領(lǐng)悟到,等到最后的幾個星期才去把不同團隊成員的代碼集成到一起是一個災(zāi)難。如果你已經(jīng)擁有了自動構(gòu)建,接下來的事情就是持續(xù)集成。當然,版本控制(或者軟件配置管理——另一個更為正式的和令人印象深刻的名字)是自動構(gòu)建和持續(xù)集成環(huán)境的前提。我們學(xué)到的一個重要教訓(xùn)是,你越快識別出集成的錯誤,你就能越快地解決這些問題。我們曾經(jīng)使用過的主要工具包括 CruiseControlCruiseControl.NetBamboo。  hadson,基礎(chǔ)集成還是不錯的。

             4. 單元測試

              
          在高度流動的環(huán)境中,隨著多個開發(fā)人員一起工作、需求的變更和優(yōu)先級的不斷變化,確保昨天可以運行的東西今天也能運行,這是至關(guān)重要的。此外,我們還要與集成出現(xiàn)的錯誤為戰(zhàn)。一種方法(我們從艱難歲月中學(xué)習(xí)得來)是使用單元測試,這樣代碼的更改不會破壞現(xiàn)有的功能。我們也開始在開發(fā)編碼之前編寫單元測試用例。我們曾經(jīng)使用過的主要工具包括JUnit(以及其他的xUnit工具如NUnitHttpUnit等)和MockObjects。 

             5. 重構(gòu)

                 在傳統(tǒng)的項目中,通常有一個人保護他們的代碼庫,直到代碼集成階段。但是在敏捷里面,我們持代碼集體所有制的觀點——所有的代碼屬于所有的開發(fā)人員,只要開發(fā)人員認為有必要,每個人都能不受約束地去改善代碼。在一段時間里面,我們的代碼庫開始出現(xiàn)奇怪的行為——解決辦法就是重構(gòu)(感謝Martin Fowler在他的同名著作中把重構(gòu)一詞推廣開來)。重構(gòu)的本質(zhì)歸結(jié)為修改代碼以改善代碼的結(jié)構(gòu)和清晰度,但不改變代碼的功能。我們學(xué)到的一個重要教訓(xùn)是在重構(gòu)代碼之前使用單元測試作為安全網(wǎng),我們曾經(jīng)使用過的一些主要工具包括EclipseNetBeansIntelliJ IDEA的Visual Studio.NET


          在敏捷團隊之中工作所必備的行為特征

          由于敏捷團隊不同于普通的團隊,并且非常倚賴于有效果和有效率的溝通和快速執(zhí)行,敏捷團隊更需要使用軟技能。如果我們意識到這一點,并積極鼓勵使用這些特征和技能,我們可以使得敏捷團隊更有價值和富有成效。

          自組織往往倚賴于諸如正反饋、負反饋、深度探索和廣度調(diào)研之間取得平衡以及多重互動的基本要素。根據(jù)我們的經(jīng)驗,團隊可能由于許多文化和社會因素?zé)o法給予正確的反饋或者回避人與人之間的互動。

          根據(jù)我個人的經(jīng)驗,這仍然是一個“神話”。我們總是傾向于患有“可預(yù)測性綜合癥”——如果我們做更多的規(guī)劃,我們將更加功能預(yù)測。

          團隊需要有良好的紀律、有能力承擔責(zé)任、盡忠盡責(zé)以及承擔職責(zé)和所有權(quán)。

          團隊需要擁有的關(guān)鍵技能之一是有能力尋求幫助,并尋求他人的評價。在某些情形下,我們已經(jīng)看到了“自我”因素表現(xiàn)為一個主要的障礙。

          有些時候,承擔責(zé)任,盡忠盡責(zé)和協(xié)作精神是理所當然的,但是根據(jù)以往的經(jīng)驗,為了這些能夠出現(xiàn),我們有時需要外部干預(yù)。

          有些我們常常傾向于忽視的關(guān)鍵技能是積極主動、在激烈的環(huán)境中享受工作和易于適應(yīng)新的形勢和框架。

          我們的大多數(shù)項目都是分布式的,這意味著在客戶和服務(wù)供應(yīng)商之間將會共同使用Scrum。在這種情況下,諸如管理多樣化團隊、時間管理、外交技巧和領(lǐng)導(dǎo)力等技能是非常關(guān)鍵的。

          敏捷團隊的成功“咒語”

          對于任何一個希望成功和高效的敏捷項目,團隊需要對向同儕學(xué)習(xí)(不管資歷和專業(yè)知識)表現(xiàn)出更大的熱情和正確的態(tài)度。必須保證一個無畏表達的安全網(wǎng),這樣才會展現(xiàn)出真正的友情,而這反過來會增強團隊成員對團隊目標的關(guān)注,而不是“哪些由我來做”?

          結(jié)論

          根據(jù)我個人的經(jīng)驗和觀察,對于提高生產(chǎn)率所需的技能,敏捷項目與傳統(tǒng)項目有所不同。本文定義了團隊提高生產(chǎn)率所需的行為和技術(shù)技能。具有這些“delta” 特征的人應(yīng)該具備了合適的行為和技術(shù)技能,這些技能使得他們在敏捷項目中的工作能夠富有成效。對于這些技能的總結(jié)請見下表。

          技能表

          角色

          技術(shù)技能(在不同的方面)

          行為技能

          開發(fā)人員

          CRUD操作,開發(fā)框架不同層之間的調(diào)用

          單元測試(工具——NUnit、JUnit)

          代碼覆蓋率的概念和工具

          代碼審查的概念和工具

          持續(xù)集成工具

          重構(gòu)的概念

          代碼味道的概念

          Scrum過程

          溝通

          合作

          時間管理/計劃

          思維

          沖突管理

          處理更改/靈活性

          決策

          團隊合作/團隊建設(shè)

          處理壓力

          問題解決

          領(lǐng)導(dǎo)

          外交

          QA

          “完成”的定義 —> 驗收標準

          測試管理

          自動化/腳本

          環(huán)境設(shè)置

          數(shù)據(jù)庫概念

          與開發(fā)人員相同

          Scrum Master

          Scrum過程

          模板和使用

          項目管理工具

          持續(xù)集成工具

          設(shè)置開發(fā)環(huán)境

          開發(fā)人員的技能+推動力

          作者簡介

          Prasad,擁有10年的IT服務(wù)行業(yè)經(jīng)驗,他第一次接觸敏捷項目是在2005年微軟的一個項目;從那時起,他為許多公司如GE、思科、可口可樂等,針對敏捷及其變體提供了解決方案開發(fā)、培訓(xùn)、咨詢以及指導(dǎo)。目前他正在Symphony Services的敏捷實驗室擔任經(jīng)理。Symphony40%的項目都是關(guān)于敏捷或其不同的形式,并且自2004年起就通過敏捷為客戶提供商務(wù)的關(guān)鍵價值。你可以通過pprabhak@symphonsysv.com與他聯(lián)系。

          查看英文原文:Skills for Scrum Agile Teams


          posted @ 2010-11-08 19:08 胡鵬 閱讀(265) | 評論 (0)編輯 收藏


            敏捷最大的特點是:不但快,反應(yīng)要更快。

            最終的目的是:提升效率。

              敏捷是一種思想:
                 溝通:個體交互
                 簡單:快速交付
                 反饋:客戶合作
                 勇氣:響應(yīng)變化

              關(guān)鍵條件還是目標一直的團隊
                共同愿景
                高效溝通
                互相信任
                嚴格執(zhí)行

               迅速迭代,越變越美,允許試錯
               敏捷精華: 小勝+ 反思
          posted @ 2010-11-08 19:03 胡鵬 閱讀(226) | 評論 (0)編輯 收藏
          想法是:
          1.現(xiàn)在列出你認為你能完成的一件事。
          比如我認為每天30分鐘的話,下一周我能讀一本書:書名叫《人人都是產(chǎn)品經(jīng)理》
          2.每天把進度記錄到地下
          我會把讀完的頁數(shù)寫出來,加上一點點感想
          看完后,總結(jié)下。
          posted @ 2010-10-07 22:38 胡鵬 閱讀(857) | 評論 (6)編輯 收藏

          任何一個有經(jīng)驗的程序員都知道,軟件開發(fā)遵循著一些不成文的法則。然而,如果你不遵循這些法則也并不意味著會受到懲罰;相反,有時你還會獲得意外的好處。下面的就是軟件編程中的21條法則:

          1. 任何程序一旦部署即顯陳舊。
          2. 修改需求規(guī)范來適應(yīng)程序比反過來做更容易。
          3. 一個程序如果很有用,那它注定要被改掉。
          4. 一個程序如果沒用,那它一定會有很好的文檔。
          5. 任何程序里都僅僅只有10%的代碼會被執(zhí)行到。
          6. 軟件會一直膨脹到耗盡所有資源為止。
          7. 任何一個有點價值的程序里都會有至少一個bug。
          8. 原型完美的程度跟審視的人數(shù)成反比,反比值會隨著涉及的資金數(shù)增大。
          9. 軟件直到被變成產(chǎn)品運行至少6個月后,它最嚴重的問題才會被發(fā)現(xiàn)。
          10. 無法檢測到的錯誤的形式無限多樣,而能被檢測到的正好相反,被定義了的十分有限。
          11. 修復(fù)一個錯誤所需要投入的努力會隨著時間成指數(shù)級增加。
          12. 軟件的復(fù)雜度會一直增加,直到超出維護這個程序的人的承受能力。
          13. 任何自己的程序,幾個月不看,形同其他人寫的。
          14. 任何一個小程序里面都有一個巨大的程序蠢蠢欲出。
          15. 編碼開始的越早,花費的時間越長。
          16. 一個粗心的項目計劃會讓你多花3倍的時間去完成;一個細心的項目計劃只會讓你多花2倍的時間。
          17. 往大型項目里添加人手會使項目更延遲。
          18. 一個程序至少會完成90%,但永遠完成不了超過95%。
          19. 如果你想麻煩被自動處理掉,你得到的是自動產(chǎn)生的麻煩。
          20. 開發(fā)一個傻瓜都會使用的軟件,只有傻瓜愿意使用它。
          21. 用戶不會真正的知道要在軟件里做些什么,除非使用過。
          [英文出處]:21 Laws of Computer Programming
          posted @ 2010-10-06 13:32 胡鵬 閱讀(222) | 評論 (0)編輯 收藏

          public class CheckQueryParams {

              private static interface Validation{
           void check(QueryInfo query);
              }
             
              private static List<Validation> validations = new ArrayList<Validation>();
             
              static {
           validations.add(new Validation() {
               public void check(QueryInfo query) {
            if(StringUtils.isEmpty(query.getStartKey()) && StringUtils.isEmpty(query.getEndKey()))
                throw new RuntimeException("Both keys can not be null or empty at the same time");
               }});
              }

              public static void check(QueryInfo query) {
           for(Validation validation : validations) {
               validation.check(query);
           }
              }
          }

          posted @ 2010-08-15 20:52 胡鵬 閱讀(228) | 評論 (0)編輯 收藏

          public class LRUCache<K,V> {

              final private int capacity;
              final private Map<K,Reference<V>> map;
              final private ReentrantLock lock = new ReentrantLock();
              final private ReferenceQueue<Reference<V>> queue = new ReferenceQueue<Reference<V>>();
             
              public LRUCache(int capacity) {
           this.capacity = capacity;
           map = new LinkedHashMap<K,Reference<V>>(capacity,1f,true){
               @Override
               protected boolean removeEldestEntry(Map.Entry<K,Reference<V>> eldest) {
                   return this.size() > LRUCache.this.capacity;
               }
           };
              }
             
              public V put(K key,V value) {
           lock.lock();
           try {
            map.put(key, new SoftReference(value,queue));
            return value;
           }finally {
               lock.unlock();
           }
              }
             
              public V get(K key) {
           lock.lock();
           try {
               queue.poll();
               return map.get(key).get();
           }finally {
               lock.unlock();
           }
              }
           
              public void remove(K key) {
           lock.lock();
           try {
               map.remove(key);
           }finally {
               lock.unlock();
           }
              }

          }

          posted @ 2010-08-15 20:33 胡鵬 閱讀(629) | 評論 (0)編輯 收藏

          導(dǎo)航

          <2010年8月>
          25262728293031
          1234567
          891011121314
          15161718192021
          22232425262728
          2930311234

          統(tǒng)計

          • 隨筆 - 93
          • 文章 - 0
          • 評論 - 48
          • 引用 - 0

          常用鏈接

          留言簿(3)

          隨筆分類

          隨筆檔案

          agile

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 昌都县| 封丘县| 双鸭山市| 思茅市| 汾阳市| 介休市| 信阳市| 会理县| 修水县| 洛南县| 临沂市| 渑池县| 凉城县| 喀喇沁旗| 芒康县| 高淳县| 涿鹿县| 宜都市| 山西省| 郑州市| 定兴县| 大渡口区| 班玛县| 泾阳县| 南汇区| 福泉市| 彰化市| 长岛县| 晋江市| 静宁县| 贵阳市| 渝北区| 上高县| 会同县| 石台县| 吉林市| 花莲县| 贡嘎县| 萍乡市| 开封县| 搜索|