其他

public int delete(int sID) {　Connection con = getConnection(ctx); 　 try {　　 con.setAutoCommit(false);// 更改JDBC事務的預設提交方式　　 dbc.executeUpdate("delete from xiao where ID=" + sID);　　 dbc.executeUpdate("delete from xiao_content where ID=" + sID);　　

這個暑假一直在做有關Struts2的相關開發，可是亂碼問題一直出現，也一直沒在意。。。今天閑來有空，總結一下，希望以後亂碼問題不要再出現　　先把以往需要設定的點羅列一下： 　　1. JSP 檔案頭 　　  　　2. struts.properties中的編碼設定 　　struts.locale = UTF-8         struts.i18n.encoding=utf-8　　3. Resource的native2ascii 轉碼 　　通常這些搞定就能解決編碼問題了。 　　再過一點在web.

MVC模式（三層架構模式）（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。MVC模式最早由Trygve Reenskaug在1974年提出，是施樂帕羅奧多研究中心（Xerox

OA專案管理系統開發需求描述（一）項目基本資料管理（二）項目立項管理（三）項目進度管理（四）項目資源管理（五）項目成本管理（六）項目合約及回款管理（七）項目文件管理（八）項目溝通管理（九）項目品質及風險控制 一、項目基本資料管理（一）經營目標分解與看板管理（二）合作單位資訊庫維護（三）責權關係及管理架構（四）項目利益相關資訊 二、項目立項管理（一）立項流程客戶需求描述－項目評估－項目實施計劃－專案計劃評審－項目立項（二）專案工作資訊維護（三）明確責權利關係－計獎辦法（四）項目設計文檔模版（五）項

這是敏捷開發一千零一問系列的第十三篇。（在這裡提問，之一，之二，之三，問題總目錄）問題這是課堂上提的一個問題，這是一家外企，PO在國外，研發在國內；PO希望大家用故事點估算，而團隊習慣用人天估算，問用哪個好，或者兩個都用好？分析先分析，後出方案。這個是一個典型的有關無我、無住的問題。所謂無我，就是先弄清楚為什麼不同的人想要不同的東西，然後本著到底“誰應該要，應該優先滿足誰”而非“我應該要，應該優先滿足我”來分析問題。所謂無住，就是故事點和人天估算本無優劣之分，否則就不應該並存在另外一個了，何時使

1.下載反編譯工具jad（下面提供下載）將下載下來的jadstar158.zip解壓縮，將jad.exe檔案放入jdk安裝目錄下如：C:\Program

一：~ the + --est + n. + (that) + 主 + have even seen/known/heard/had/read.Helen is the most beautiful gril that I have ever seen.二：Nothing is + --er than to + VNothing is + more +adj +than to +vNothing is more important than to receve

本文是團隊管理系列的第五篇，也是“松結對程式設計”系列的第九篇。（團隊管理欄目目錄，松結對程式設計欄目目錄）抱歉在這次MPD上不知道中間的20分鐘茶歇也在3小時內，所以最後有10分鐘左右的內容沒有講，這裡補充一下。大型團隊的切分如果團隊大到一定程度，比如40人，那麼怎樣切分團隊最好呢？答案是縱向切分，就是按產品而非按職能切分，也就是事業部化，而非開發-測試-支援這樣劃分。原因大致如此：1. 縱向切分的團隊之間不會有直接競爭、對抗關係，避免了各種對抗和辦公室鬥爭。2. 縱向切分的團隊內部目標清晰，

這是敏捷開發日常跟進系列的第四篇。 （欄目目錄）跟進表是大型敏捷團隊的一種實踐。在一個80多人的網路遊戲團隊中，他們為了清晰地顯示整個團隊的運作方式，使用了這種方法。跟進表以上面的網路遊戲團隊為例，說明一下跟進表上的資訊：1. 哪些故事完成了在故事板中也能表達，但缺少結構性。故事板中的故事都是平等的，較難顯示大小、父子內含項目關聯性等。2. 誰在跟進案例中這個人一般是策劃人員，故事的建立者和驗收者。3. 誰在開發案例中這個一般是若干個開發人員、指令碼、美術的群體，也可能只有其中一個工種。4.

最近在學習Hibernate的基本內容，剛好在項目中有用到，基本上都是用到哪就學哪。今天看看六種方式實現hibernate查詢.........分別是HQL查詢，對象化查詢Criteria方法，動態查詢DetachedCriteria，例子查詢，sql查詢，命名查詢。           如果單純的使用hibernate查詢資料庫只需要懂其中的一項就可以完成想要實現的一般功能，但是從一個點，讓我們掌握6中方法，則提供了更多選擇。每一種方法都有其適用的情況與前提。HQL查詢HQL是hibernat

這是火星人預覽系列的第七篇（之一，之二，之三，之四，之五問答，之六，之七）。之一：需求與故事結構之二：編輯故事，產品管理，組織圖之三：迭代，計劃會，分配任務之四：故事板，燃盡圖 (burndown

問題現象：單據頭欄位進行合計，在序時簿介面，合計的結果不正確，對於單據有N條分錄的情況，單據頭合計欄位對此條單據記錄會得到N倍實際值的結果。分析解答：找到此單據序時簿介面listui對應的query，在“欄位”頁簽中，找到要合計的單據頭欄位，然後在下面的擴充屬性欄中增加一個PKNameGroupBy，並將此擴充屬性對應的值修改為id，然後重新發布即可。問題現象：用戶端運行時候，單據序時簿介面左下角統計的行數跟實際顯示的不一致。分析解答：此問題一般出現在包含有分錄業務單據中，而沒有分錄的基礎資料，

本人在學習Java的這段時間裡，尤其是學習到J2EE這塊內容時，經常遇到的一個問題就是中文亂碼問題，特別的頭疼，相信大家也會有同感，故在學習的時候不斷的總結，發現解決這類問題無非是如下幾點（以gb2312為例），和大家分享一下心得:1、TOMCAT中解決中文亂碼在conf/server.xml檔案中，增加一句URIEncoding="gb2312"的代碼到下面的地方，選擇合適的編碼方式  <Connector port="8080"

這是火星人預覽系列的第六篇（之一，之二，之三，之四，之五問答，之六，之七）。之一：需求與故事結構之二：編輯故事，產品管理，組織圖之三：迭代，計劃會，分配任務之四：故事板，燃盡圖 (burndown

文章目錄 品質控制 Quality Control敏捷品質控制

這是火星人預覽系列的第四篇（之一，之二，之三，之四，之五問答，之六，之七）。之一：需求與故事結構之二：編輯故事，產品管理，組織圖之三：迭代，計劃會，分配任務之四：故事板，燃盡圖 (burndown chart)，我的工作項目之五：常見問題問答之六：我的空間，我的通知之七：自訂欄位  日常跟進故事板：燃盡圖 (burndown chart)（具備切入功能）：跟進表：個人中心個人中心是3月迭代的重點，所以未來會多很多功能。我的通知：我的工作項目（建立和當前負責，可以篩選類型）：

這是IT職場人生系列的第二十二篇。（序言，專欄目錄）（續上篇）擷取協助謙虛、大膽、再謙虛地嘗試這幾個詞看起來很不搭嘎，但我細細回憶起來10多年編程的經曆，這句話很可能是高手與低手最後產生差別的關鍵，所以重點寫一整篇。菜鳥不是低手，低手指的是工作了很久，但技術能力上很落後的傢伙。如果作為菜鳥，怎麼才能避免成為低手呢？那就是謙虛、大膽、謙虛地嘗試。未必所有問題都能百度到，也未必身邊一定有高人給予指點，那麼遇到困難的時候，我怎麼知道有還是沒有方法解決、方法是什麼呢？1.

這是火星人預覽系列的第三篇（之一，之二，之三，之四，之五問答，之六，之七）。之一：需求與故事結構之二：編輯故事，產品管理，組織圖之三：迭代，計劃會，分配任務之四：故事板，燃盡圖 (burndown chart)，我的工作項目之五：常見問題問答之六：我的空間，我的通知之七：自訂欄位  反覆項目計劃反覆項目計劃：團隊與迭代日曆：意向表及預估（對於當前迭代、前一個及更久遠迭代、之後迭代的綜合安排）：計劃會故事講解+估算：分配頁面（計劃會後和平時都可使用）：

摘要:應屆生在求職的過程中，很可能會對面試比較困惑和迷茫：面試中會出現什麼問題，我該怎麼回答，有什麼回答技巧等。下面一位資深HR談他對應屆生的面試建議。即使是最優秀的HR，在對應屆生進行面試時，都會感到些許茫然：問不到工作經驗；沒有Reference Check可以提供；所學專業知識與實際需要脫節；有些畢業生甚至不知道自己的興趣所在；再加上畢業生的心態不穩定---急功近利者，妄自菲薄者，眼高手低者都大有人在。所以，很多公司都開始使用Competency (勝任力)

文章目錄 Young(Nursery)：年輕代Old(Tenured)：年老代Permanent：持久代Young(Nursery)：年輕代Old(Tenured)：年老代Permanent：持久代 前段時間在一個項目的效能測試中又發生了一次OOM（Out of swap