前兩天休眠后機器非正常關機，重新啟動后運行eclipse。悲催的發現eclipse
無法啟動了。每次雙擊啟動后，確定完workspace后，顯示啟動畫面，沒過一會就進入灰色無響應狀態。啟動畫面始終停留在Loading
workbench狀態。反復重啟，狀態依舊。嘗試解決。
搜索了一下，應該是非正常關機導致eclipse工作區的文件狀態錯誤導致。在工作區目錄中，有一個.metadata目錄，里面是工作區及各插件的信息，刪除此目錄可以解決問題。
為保險起見，將.metadata改名移動到/tmp目錄，再重啟eclipse，果然可以正常啟動eclipse了，但原來工作區的配置和項目信息也都消失，直接顯示的是歡迎界面。
如何恢復原來的project配置呢？嘗試對比了當前的.metadata和之前備份的那個目錄，發現缺少了很多配置文件。試著一點點恢復一些目錄，但效
果不理想。因為不知道哪些文件(目錄)可以恢復，哪些恢復會帶來問題。將備份的整個目錄恢復試試？Eclipse又回到了無法啟動的狀態了。
怎么辦？這時想到啟動停止時顯示的狀態:"Loading workbench"，看來和這個workbench插件有關。查看原來的.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
發現了兩個：
org.eclipse.ui.workbench 和
org.eclipse.ui.workbench.texteditor。
不管三七二十一，刪了這兩個目錄，重新啟動eclipse。正常啟動且原項目信息正確加載。
最近團隊遇到一個案例。看似很小的事情，但仔細研究起來，徹底分析，每一個環節都沒做好，細節部分糟糕得一塌糊涂，最后導致一件事情的結果：完全失敗。
經常有人在聊起公司的時候問我，你現在最擔心的事情有哪些? 我當然會重點提到團隊。不過在談及團隊的時候，我又最擔心在「細節」問題上做不好。
細節就是競爭力，尤其是對小團隊來說，小團隊更應該注重細節問題。大一點的公司可以追究責任人，靠流程、靠制度，靠各級評審等等一系列的「成本」來提升細節能力。小一點的公司或者團隊怎么辦? 恐怕只有依賴每個人的能力和責任心了。
細節也是鍛煉人的能力的地方，搞清楚每一個細節，將每一個細節涉及到的背景知識和技能掌握好，能力自然也就會得到提升。繼而，著手做更大的事情也不
會手忙腳亂。相反，做不好細節和小事的人，如果總嚷著要做「重要」的事情，做更有「挑戰」的事情，這樣的事情真的到你面前，真的能接住么?
為什么我們在細節上做不好?
對細節問題不夠重視 一件事情到了自己這里，頭腦中先入為主認為只是一件小事，是一件簡單的事情。這樣，當然就不會給予足夠的重視。小事不一定不重要，小事不一定意味著做起來就簡單。
對事情復雜度缺乏認知 不就是給客戶寫一封電子郵件么? 不就是用 HTML 寫一個頁面么? 不就是做一則橫幅廣告么? 那么，這些事情真的簡單么? 為什么別人為客戶寫的郵件打開率更高? 為什么別人寫的頁面更容易被搜索引擎收錄? 為什么別人做的廣告轉化率更好? 背后涉及到哪些知識? 不想研究一下么? 不能研究一下么?
對細節缺乏耐心 草草了事，應付了事，遇到問題馬馬虎虎，輕易得放過了很多可以讓自己得到成長的機會。「這問題我沒想過」「這事情我沒遇到過」「設計稿都改過兩次了」... 這類借口在任何一個團隊都很常見。
缺少責任心 常常覺得自己這里做不好，還有別人會把關呢。擔心什么? 可如果所有人都這么想呢? 「文案是產品經理的事情，關我甚么事?」如果你能對文案也有改進意見，誰說以后你就不能做產品經理做的事情呢?
主觀上不認可自己的工作 就給我這么一點錢，要我做這么多工作? 問題是我們如果不多做一點工作，不提升一下自己，又怎么能多一點錢呢?
為什么細節上做不好? 不同人不同的角度還會有不同的看法。不過有一點我能肯定，細節不會決定成敗，但做不好細節，一定會失敗。
做好細節，百事可作。
雖然android安裝完成后會有一套參考手冊,其中包括了api,但是如果在開發過程中能查看android的源碼(sdk的源碼),將對我們學習android有一定的幫助.畢竟,有時候源碼比api文檔更能說明問題.
我平常學習android用的2.2版本,從網上下載了2.2的源碼(從官方git庫下載太麻煩,是從網友共享的源碼位置下載的).按照網上的說法,我把
解壓后的那一堆文檔放在了android-sdk-root\platforms\android-8\sources目錄下.不過并沒有重啟
eclipse.而是通過這種方法來做的-----在eclipse中,鼠標放在一個android提供的類上,按下ctrl鍵,會打開一個新頁面,提示
找不到對應的類的class或者源文件,但這個新頁面上有個導入源碼的按鈕,點擊之后選擇下載好的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
離開淘寶后，自己創業，產品需要推廣，考慮到當今流量最大的聚集在微博上，我們也來做做微博運營，我是一個技術人員，運營對于我來說，從0開始，站在巨人的肩膀上學習，稍稍總結了下。
1. 使用工具：微博第三方插件已經提供了很多功能，適合自己的都用起來，這個我覺得最節省我的時間，其他網上提供的軟件都可以使用，重要是適合自己，安全第一。
2. 寫工具：有很多個性化需求的時候，如果變相的不能實現，人為處理太慢太花時間，我們現在是小創業團隊，很多事情都需要自己做，數據增長慢，在有限的資源下，寫工具是非常好的方式，作為技術人員就直接動手寫，當然也需要看看性價比。
3.微博定位：
找好本微博的主題，內容一般遵循原則：定制+非定制。定制是指針對你的目標群體來選擇內容，要讓這部分人感興趣，非定制：是指那種適合任何粉絲的內容。
例如：我的目標群體是女性，我的定制內容就有美容、護膚、服飾搭配、星座、愛情等女性關注的話題，非定制的有笑話、經典語錄、旅游等大眾類容。根據內容來 建立話題，如#美容護膚# #開心一笑##XX語錄#等等，我就為自己建立了10個左右話題，每天的內容按照話題來制作。
4.主要工作流程：（這個圖是轉的）
5.常用的微博話題（這個圖片也是轉的）
6. 關注項目：微博和主動@，評論，私信，群，邀請，勛章，策劃產品活動，參與微活動
7.微博運營最重要的是：一段時間需要總結挑選合適的方法執行，沒有效果的去除。
如:微博發布時間/數量
我（轉，不是我）曾在粉絲超過一萬之后就開始研究的我的微博改什么時候發布，每天發布多少。我現在粉絲中做了一個投票：你們一般什么時候織微博。最后有200多人參加， 我大概劃分了5個時段，9-12點，12-17點 17-19點 19-22點 22-24點 0-3點，做多選擇3個答案，結果出來之后就有個大概了。接下來我用一周的時間從9點—24點之間每1小時發布一條信息。總共16條信息，我就分析每條信 息的轉發、回復數量，一周之后我就可以摸清粉絲的上網時間規律。然后我選擇哪幾個時間段重點維護，并在那幾個時間段進一步研究發布數量規律，我又分為每1小時，每0.5小時兩個因素來研究發布數量。
JMock是幫助創建mock對象的工具，它基于Java開發，在Java測試與開發環境中有不可比擬的優勢，更重要的是，它大大簡化了虛擬對象的使用。本文中，通過一個簡單的測試用例來說明JMock如何幫助我們實現這種孤立測試。
我們在測試某類時，由于它要與其他類發生聯系，因此往往在測試此類的代碼中也將與之聯系的類也一起測試了。這種測試，將使被測試的類直接依賴于其他類，一旦其他類發生改變，被測試類也隨之被迫改變。更重要的是，這些其他類可能尚未經過測試，因此必須先測試這些類，才能測試被測試類。這種情況下，測試驅動開發成為空談。而如果其他類中也引用了被測試類，我們到底先測試哪一個類？因此，在測試中，如果我們能將被測試類孤立起來，使其完全不依賴于其他類的具體實現，這樣，我們就能做到測試先行，先測試哪個類，就先實現哪個類，而不管與之聯系的類是否已經實現。
虛擬對象(mock object)就是為此需要而誕生的。它通過JDK中的反射機制，在運行時動態地創建虛擬對象。在測試代碼中，我們可以驗證這些虛擬對象是否被正確地調用了，也可以在明確的情況下，讓其返回特定的假想值。而一旦有了這些虛擬對象提供的服務，被測試類就可以將虛擬對象作為其他與之聯系的真實對象的替身，從而輕松地搭建起一個很完美的測試環境。
JMock是幫助創建mock對象的工具，它基于Java開發，在Java測試與開發環境中有不可比擬的優勢，更重要的是，它大大簡化了虛擬對象的使用。
本文中，通過一個簡單的測試用例來說明JMock如何幫助我們實現這種孤立測試。有三個主要的類，User，UserDAO，及UserService。本文中，我們只需測試UserService，準備虛擬UserDAO。對于User，由于本身僅是一個過于簡單的POJO，可以不用測試。但如果你是一個完美主義者，也可以使用JMock的虛擬它。在這領域，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>
在官方的網站上也有的下載。 地址： 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負責與數據庫打交道，通過數據庫保存、獲取User的信息。盡管我們可以不用知道JMock如何通過JDK 的反射機制來實現孤立測試，但至少應知道，JDK的反射機制要求這些在運行時創建的動態類必須定義接口。在使用JMock的環境中，由于我們要虛擬 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 {
}
}
在開發Android和iPhone應用程序時，我們往往需要從服務器不定的向手 機客戶端即時推送各種通知消息，iPhone上已經有了比較簡單的和完美的推送通知解決方案，可是Android平臺上實現起來卻相對比較麻煩，最近利用 幾天的時間對Android的推送通知服務進行初步的研究。在Android手機平臺上，Google提供了C2DM（Cloudto Device Messaging）服務。
Android Cloud to Device Messaging (C2DM)是一個用來幫助開發者從服務器向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，允許服務器可以通知移動應用程序直接與服務器進行通信，以便于從服務器獲取應用程序更新和用戶數據。C2DM服務負責處理諸如消息排隊等事務并向運行于目標設備上的應用程序分發這些消息。
使用C2DM框架的要求
1. 需要Android2.2及以上的系統版本
2. 使用C2DM功能的Android設備上需要設置好Google的賬戶。
3. C2DM需要依賴于Google官方提供的C2DM服務器，由于國內的網絡環境，這個服務經常不可用，如果想要很好的使用，我們的App Server必須也在國外，這個恐怕不是每個開發者都能夠實現的
要使用C2DM來進行Push操作，基本上要使用以下6個步驟
（1）注冊：Android設備把使用C2DM功能的用戶賬戶（比如android.c2dm.demo@gmail.com）和App名稱發送給C2DM服務器。
（2）C2DM服務器會返回一個registration_id值給Android設備，設備需要保存這個registration_id值。
（3）Android設備把獲得的registration_id和C2DM功能的用戶賬戶（android.c2dm.demo@gmail.com）發送給自己的服務器，不過一般用戶賬戶信息因為和服務器確定好的，所以不必發送。
這樣Android設備就完成了C2DM功能的注冊過程，接下來就可以接收C2DM服務器Push過來的消息了。
（4）服務器獲得數據。這里圖中的例子Chrome To Phone，服務器接收到Chrome瀏覽器發送的數據。數據也可以是服務器本地產生的。這里的服務器是Google AppEngine（很好的一項服務，可惜在國內被屏了），要換成自己的服務器。服務器還要獲取注冊使用C2DM功能的用戶賬戶（android.c2dm.demo@gmail.com）的ClientLogin權限Auth。
（5）服務器把要發送的數據和registration_id一起，并且頭部帶上獲取的Auth，使用POST的方式發送給C2DM服務器。
（6）C2DM服務器會以Push的方式把數據發送給對應的Android設備，Android設備只要在程序中按之前和服務器商量好的格式從對應的key中獲取數據即可。
轉自：
地理位置索引支持是MongoDB的一大亮點，這也是全球最流行的LBS服務foursquare 選擇MongoDB的原因之一。我們知道，通常的數據庫索引結構是B+ Tree，如何將地理位置轉化為可建立B+Tree的形式，下文將為你描述。
首先假設我們將需要索引的整個地圖分成16×16的方格，如下圖（左下角為坐標0,0 右上角為坐標16,16）：
單純的［x，y］的數據是無法建立索引的，所以MongoDB在建立索引的時候，會根據相應字段的坐標計算一個可以用來做索引的hash值，這個值叫做geohash，下面我們以地圖上坐標為［4，6］的點（圖中紅叉位置）為例。
我們第一步將整個地圖分成等大小的四塊，如下圖：
劃分成四塊后我們可以定義這四塊的值，如下（左下為00，左上為01，右下為10，右上為11）：
這樣［4，6］點的geohash值目前為 00
然后再將四個小塊每一塊進行切割，如下：
這時［4，6］點位于右上區域，右上的值為11，這樣［4，6］點的geohash值變為：0011
繼續往下做兩次切分：
最終得到［4，6］點的geohash值為：00110100
這樣我們用這個值來做索引，則地圖上點相近的點就可以轉化成有相同前綴的geohash值了。
我們可以看到，這個geohash值的精確度是與劃分地圖的次數成正比的，上例對地圖劃分了四次。而MongoDB默認是進行26次劃分，這個值在建立索引時是可控的。具體建立二維地理位置索引的命令如下：
db.map.ensureIndex({point : "2d"}, {min : 0, max : 16, bits : 4})
其中的bits參數就是劃分幾次，默認為26次。
摘要: java中的引用分為4種：String Reference， WeakReference， softReference，PhantomReference Strong Reference: 我們平常用的最多的就是強引用了 如：String s = new String("opps");這種形式的引用稱為強引用，這種引用有以下幾個特點 1.強引用可以直接訪問目標對象&...
閱讀全文
摘要:
一、對ThreadLocal概術
JDK API 寫道：
該類提供了線程局部 (thread-local) 變量。這些變量不同于它們的普通對應物，因為訪問某個變量（通過其 get 或 set 方法）的每個線程都有自己的局部變量，它獨立于變量的初始...
閱讀全文