紫風亂寫

有這么一種神器，英文叫做reference card, 中文我不知道叫什么，就作用來說，可以叫做快捷鍵一頁紙，可以打印出來，放在案頭，然后可以隨時查閱。百度不容易找到，用谷歌的話可以使用reference card作為關鍵字查找。

下面是幾個例子
Eclipse 4.6:　https://github.com/pellaton/eclipse-cheatsheet/raw/master/eclipse4.6/eclipse-shortcuts-4.6.0.pdf
Intellij IDEA: https://resources.jetbrains.com/assets/products/intellij-idea/IntelliJIDEA_ReferenceCard.pdf
Emacs:　https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf
Org-Mode: https://www.gnu.org/software/emacs/refcards/pdf/orgcard.pdf

     摘要: Emacs Tutorial中提到的快捷鍵以及自己找的一些快捷鍵  閱讀全文

     摘要: 在我看來，干活有兩種方式：

1. 沒想清楚了，貿貿然開干，然后各處救火各種解決問題
2. 想清楚了再開干，無驚無險，安然做完

本文講講如何在設計中系統的思考以避免內存溢出，并給出一個例子講解。  閱讀全文

5月初的時候，我發了一個帖子說要開始講單元測試，但是20多天過去了，為什么沒有更新呢？
原因就是我在做視頻公開課，發現光文字表現的話比較費勁，所以我決定錄制視頻，做成公開課。

第一個錄制的是JUnit技術，課程地址：http://edu.csdn.net/course/detail/908 歡迎大家觀后留言探討哦。

     摘要: 從04年開始，我就開始在項目實踐中使用單元測試。十幾年來，參與的項目基本上都或多或少的使用了單元測試，多的能有100%覆蓋率的要求，少的也要覆蓋主要代碼，發現這個實踐在提高軟件質量和開發速度上還是很有好處的。在和朋友同事的交流中，發現有很多項目沒有使用單元測試，也有很多程序員不會寫單元測試，但是大家對這個都很有興趣。所以我想把自己掌握的關于單元測試的技能（架構、設計和技術）和實施策略分享一下。  閱讀全文

代碼地址：https://github.com/Jimmy-Shi/bean-query/tree/bean-query-1.1.1

修改內容：

• 簡化用戶自定義轉換

例子：

在Maven項目中引用:

     摘要: BeanQuery 是一個把對象轉換為Map的Java工具庫。支持選擇Bean中的一些屬性，對結果進行排序和按照條件查詢。不僅僅可以作用于頂層對象，也可以作用于子對象。

BeanQuery的使用非常簡單也很直接  閱讀全文

     摘要: 作為一個程序員，我們的日常工作之一就是看Log，從Log中發現自己所需要的信息，以及對Log做一些簡單的分析和統計。本文分享了我所使用的工具和方法。  閱讀全文

     摘要: 本文介紹了在代碼中應該在什么時候需要Log什么信息；使用何種級別的Log；如何Log異常信息；Log中的一些要點。另外也分析了靜態Logger變量和對象Logger變量的優劣。  閱讀全文

     摘要: 作為《Java程序員修煉之道》博文的第一個主題Logging，我計劃中按照如下三篇來寫： 1. Logback的簡單介紹和配置 2. 在Java代碼中如何使用SLF4J來寫日志以及寫日志的要點 3. 作為一個程序員，在日常工作中如何分析和挖掘Log。 這個是第一篇，簡單介紹一下Logback的配置，適用于開始配置和開始入門，適用于一般情況下的使用。  閱讀全文

     摘要: 后來我意識到，我不能只抱怨，作為一個寫了10多年代碼，帶過項目、做過業務最終還是寫代碼， 有車有房有妻有娃的四有不太牛逼的程序員，我有責任幫助剛入行的、入行時間不短的，還沒車沒房的Java程序員們掌握一些基礎的東西。
如果你掌握了這些基礎的東西的話，而且英語口語還湊合的話，歡迎來找我幫你內部推薦工作，估計一萬多的月薪是不成問題的，至于30、40萬的年薪應該也是有機會的。  閱讀全文

Sorry every body, I am so busy that I can not finish this article on time. I will try to finish this article after I have got a job. You can compare the 2 xml files in the attached zip file to get some idea.

There are 2 files in the zip file:
1. google.xml: The original google search plugin
2. google-oracle.xml: The search plugin that only search the oracle.com web site.

Usage
1. Put the google-oracle.xml in your personal firefox searchplugin folder. In windows firefox version 4 it is {FIREFOX_HOME}\distribution\searchplugins
2. Restart the firefox. Done

Click here to download the search plugins

If after upgrading your eclipse STS plugin from 2.5.2 to 2.6.0, your grails projects can not be build, and when building it, it always warning that "Errors running builder 'Java Builder' on projec". That might be caused by the old 1.6 groovy compiler.  The solution is to edit the file "eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info" and find the line for org.codehaus.groovy_1.6 and remove it. And then restart the eclipse. you can find that it should be fixed.

Reference: http://docs.codehaus.org/display/GROOVY/Compiler+Switching+within+Groovy-Eclipse

     摘要: 第一章　新的機會 第二章　對抗卡布福斯 第三章　“硅谷” 第四章　CD-ROM工廠 優質管理的四大要素 l 選擇正確的人 l 為他們分配正確的工作 l 保持他們的積極性 l 幫助團隊凝聚起來并保持團隊的凝聚力 （其他的一切都只是“文案”） 安全和變化 l 除非感到安全，否則人...  閱讀全文

上周去一家大型網絡公司的內部系統開發部門面試，該部門主要是為公司的各個部門開發工作中所需要用到的系統，比如財務，人事的一些小系統。面臨著：資源少，任務多，體現不出部門價值等問題。面試出來后想了幾點，發給他們了，另外也分享出來，希望對從事類似工作的同學們有用。
1. 統一簡潔的頁面風格和CSS
因為是內部系統，所以頁面不需要太華麗和復雜的界面，所需要的是簡單易用。因為是都是sohu的內部系統，所以可以有統一的頁面風格。
統一頁面風格帶來以下這些好處：
a. 只需要采用一套CSS，而不需要在每個項目都進行CSS的開發
b. 能減少頁面設計的時間，頁面布局，功能區域設置能全部都統一起來
c. 減低用戶對于新系統的學習曲線
因為是內部系統，客戶端與服務器之間的連接速度能保證。因此可以采用簡潔的頁面風格。
簡潔的頁面能帶來以下好處：
a. 減少頁面的開發難度，不用在一個頁面中堆積過非必要的數據。
b. 方便任務分配
 
2. 在做需求的時候同時完成靜態頁面的設計
這條的好處是做頁面設計的時候能進一步理解用戶的需求，也能同時從解決方案的角度來考慮問題，從用戶的角度來說，針對模型進行思考能進一步的引導他的需求。
具體的做法就是
a. 在一邊談需求一邊用紙畫出大概的頁面模型和用戶溝通，初步形成頁面功能的設計
b. 談完需求之后盡快使用統一的CSS做出靜態的頁面。用頁面跳轉代替表單提交。
c. 用靜態頁面組成的模型和用戶進行初步溝通，在溝通過程中，如果時間不多的話在紙面上進行修改再溝通，如果時間多的話，快速的修改靜態頁面，爭取盡可能多的把重點頁面和用戶達成一致。
根據溝通結果把可以開始做的部分安排開發人員開始做，還不能確定的和客戶約好時間再進行下一次溝通。
 
3. 逐步建立可復用的代碼庫（功能組件）
這一點說起來容易，做起來需要一定的額外代價，是一個部門內部的積累。前提是第一條建議能夠比較好的實施。這里的代碼庫（功能組件）大到一個功能模塊（連接LDAP）,小到一個頁面控件（多層次部門選擇下拉列表）。具體做法是
a. 在項目開發中有意識的把可通用的組件單獨放到一個包里
b. 項目結束后，花1到2天的時間整理成可復用的代碼
c. 整理完之后再對相關技術人員進行培訓（這個很重要，有通用代碼而別人不知道=沒有通用代碼）
d. 在以后的項目中，在復用的過程中進行完善
e. 盡量減少復制粘貼再修改
 
4. 收集客戶部門使用系統后的效果，其結果可用于對上對外和對內
客戶部門應該會有這樣的數據，因為他們需要這些東西來說明他們上新系統的效果。本部門可以用這些數據來說明自己的貢獻以獲取公司的認同甚至可以去爭取更多的資源
IT或者運維部門應該會有bug數量的和分布的統計數據，如果沒有的話自己可以收集到達本部門的bug數量和分布的數據，通過這些可以在以后的工作中有意識的避免這些bug
通過這些數據可以在以后的需求分析過程中為客戶部門提供更容易使用的系統