摘要: 最近想幫一個電子商務網站客戶搭建一個簡單的客服中心，客戶處于創業階段，一分錢想掰成兩半使，但是電子商務中，貼心的服務質量都是非常重要，當用戶在網站上下單成功或購買成功后，及時的與用戶溝通，反饋，非常非常重要，這個操作步驟, 需要一個回訪電話來完成，英文叫Happy Call, 很多小企業主并不懂得這個重要性或者擔心一個單本來就不賺錢，在搭進去話費，不值。使用網絡電話不僅可以打手機，還可以打固話，話費很低，是一個非常經濟的手段。
對與客戶來講，使用網絡電話，就是圖省錢的，在通話質量都差不多的情況下，誰最便宜，就要誰的。但如果搞價格戰，大家賺不到錢。所以大家的話費收費都差不多，都在每分鐘一毛和一毛二之間。對于用戶來說，似乎沒有選擇的余地。
UUCall的話費一毛二，看似沒有惡性競爭，但充值送話費，一下子將話費打到每分鐘6分錢的價位上。
閱讀全文
摘要: 現在國外的很多的創業團隊（Freelance)，都可以做出一步到位的原型，團隊中的人擅長前端設計、開發，Ajax, CSS, XTHML，web standard, cross browser不在話下，Flash, Flex, Fireworks 等RIA技術也是有豐富的項目經驗，很多人用flash, fireworks做的原型，非常棒。以用戶為中心的、注重用戶體驗、準確把握用戶業務的分析設計是他們的核心競爭力。
閱讀全文
摘要: 參與界面設計的人，容易與一線用戶脫鉤，很少有一種簡潔、直接、樸素、持久的設計風格，首先考慮的不是信息的組織、用戶的體驗，而是如何的炫，動感，漸進、半透明、滑門、延遲、手風琴、背景圖片等效果，總想用上一用，濫用顏色，這些除了造成視覺疲勞、操作繁瑣外，起不到真正的用戶體驗。
閱讀全文
摘要: 框架畢竟是框架，沒有最完美的，只有相對合適的，使用者需要分析知道自己的問題在那里，然后去設計開發、使用合適第三方的框架，或直接使用、或二次封裝、開發、修改源代碼，來解決自己的問題，總之，不要做一個問題的抱怨者，等著別人煮米下鍋。
閱讀全文
摘要: 我以前帶了一個分銷系統的項目，同時并行的還用另外的一個配合的項目，每周GM會review我們的工作，其實和過堂差不太多，氣氛太緊張了，冷冰冰的，很不舒服，再加上兩個PM一起被review，有點暗暗較勁的意味，我當時深深迷醉與項目管理的可視度的概念，就是增強透明度，我希望把我項目中的Issue盡早的暴露出來，評審的人可以看到，或可以幫助我一起解決，或了解項目的Risk和真實的Progress，真實的理解我的處境，給我必要的Resource支持。
閱讀全文
摘要: 最近，負責客戶的一個項目設計的審計工作，是一個短信平臺的項目，上行和下行通信都有，之所以叫平臺，是想將客戶的很多的業務系統，涉及到短信的部分都統一掛接到者一個服務平臺當中，只要一家服務提供商，量大從優，避免各自為戰，浪費資源。業務系統多是遺留系統，當中對短信需求各不一樣，客戶從自己的vendor List中找了一個短信服務提供商（SP）。一般的要是能進入vendor list中，說明實力還是有的。
閱讀全文
摘要: 對于business rule, 一般的情況是， 好的BA，可能更善于發現、抽取business rule ，并用結構化的方式描述、記錄下來， 普通的BA可能更是一種流水賬式的、吃那拉那的描述方式。
不管怎樣，BA在寫文檔，use case的時候，那些business rule被分布在文檔中不同的部分，然后這些rule，在分工時，有被理所當然的分給不同的開發人員來開發。
閱讀全文
摘要: 關于BA，很多人寫書為了謀取利益，極力和UML、UseCase扯上關系，誤導了很多努力向上的人，把工具當成了能力。很多公司在面試BA時，也非?？粗啬銜粫ML，無疑是添亂。
閱讀全文
摘要: 在旅行的途中，為山區的孩子們多背一公斤的捐贈物資，這樣的idea，平凡又偉大。
旅游區的普通百姓其實很苦，外地人的蜂擁，抬高了物價、房價，而大部分本地的人收入確非常的低。
人們看到了四川、貴州、云南、海南旅游風景的美麗，卻看不到山里的茅草屋里的貧窮。
閱讀全文
摘要: 人們在走上管理職位時或者被賦予超越自己目前現狀的角色時，精神狀態陡然發生了變化，工作更積極了，主動性加班也多了，說話的聲音也大了，語速也加快了，總帶著居高臨下的語氣，不說教一下別人總是不爽。
閱讀全文
摘要: 設計者高高在上，不食人間煙火，只是提供約束，不要這樣，必須那樣，而不是提供方法和可以復用的API。
開發者是處于解決問題的一線，飽嘗重復造輪子的疾苦，他們最需要的是快速的解決問題，以更恰當的方式工作，尋找更容易構建系統的技術和方式。
Jquery給設計者上了很好的一課。
Jquery就像一個魔法師一樣，$()就像魔法棒一樣，隨手一指，一個木偶變復活了，一瞬間具備了各種各樣的復雜的能力。
閱讀全文
摘要: 技術是基礎，積累才能提高，用戶是目的。成熟的架構+創新的擴展，server端，團隊應當繼續構建、成熟以spring為基礎的企業應用開發平臺，深度挖掘、孵化、封裝，同時將精力轉向客戶端。努力實現客戶端與server端的粘合劑開發提高開發效率，建議的平臺是spring + jquery
閱讀全文
摘要: Look at our school building. nothing can describe the scene.
閱讀全文
摘要: 2007年終于過去了，從焦油坑里爬出來幸存的人們，互相握手慶幸，喜極而泣，紛紛在博客上寫工作總結與來年展望，而我終于厭倦了期權的精神鴉片，難得的坐下來，遠離自己負責的網站，想一想來年的布局。
閱讀全文
摘要: full-stack 的設計，意味著各層能夠無縫的集成在一起，遵循的DRY原則（don't repeat yourself)，將各層共用的東西，抽取出來，并通過自頂向下的設計，無縫的集成在一起，粘合在一起，達到更高層次、更粗粒度的重用，同時為了保證靈活的可擴展性，在更高、更粗的粒度上遵守開放-封閉的原則，在各層的各個關鍵點，要提供諸多的鉤子，回調的接口，供使用者擴展。full-stack的設計，在層與層之間，并不一味的追求松散的機制，而是相反，在層與層之間增強一定的內聚性，粘合力，以此來達到粗粒度的封裝與重用。
閱讀全文
摘要: 在現實當中，真正影響我們，耗費我們大量時間的，對我們進度有很大影響的，就是在現實中復雜的需求，業務邏輯，這些復雜的需求，難以封裝，造成復雜的設計、復雜的庫表關系，這些復雜的設計，我們都知道越復雜的東西，越不穩定，更容易遭受到需求業務邏輯變化時的沖擊。（希望那些做增刪改查的人不要跳出來扯淡）
閱讀全文
摘要: 長期以來，很多Team的組合都是隨意的，從創建到穩定, 不經意之間，一個Team就出世了，在項目進行當中，弊端盡現的時候，也沒有人注意到是團隊的組織架構，人員搭配是否出現了問題，Team成長過程，就好像一個樹籽落在地下，然后自生自滅，有的長成了歪脖子，有的則樹倒猢猻散，有一部分，運氣好，成為能經風雨的大樹?！ ?nbsp;
閱讀全文
摘要: 最近做一個比較大的電子商務項目，預計每天訂單量將在５萬多單，客服人員需要頻繁的下單、查詢訂單、操作訂單，客人預訂完訂單后，會立即進入處理流程，為了提高服務質量，要求流水化作業，平均要在４０分鐘－８０分鐘內處理完訂單。所以訂單在創建后，會在短時間內，被頻繁的修改和查看.
閱讀全文
摘要: 我覺得現在技術換代很快，使用一項技術，首先是要快速的解決問題，然后要學習他的思想，那些整天死抱著Hibernate，自認為學習到ORM的設計技巧的人，就去繼續的學吧。
我已經會用Hibernate的一些方面，我覺得夠用就行了，犯不上，天天鉆研HSQL，如果有時間，我覺得躺在草坪上看看Unix的編程藝術，看看代碼大全，看看Oracle的編程藝術，比看Hibernate的SB書要愜意多了。
閱讀全文
摘要: 我認為避談代碼是可恥的，只要編碼有意義，我們在任何階段，都應當投入到編碼當中。
閱讀全文
摘要: 說老實話，我都不知道什么算是大型項目經驗，我也不知道，那些所謂要求有大型項目經驗的公司，在做多大的項目，有多NB，但我并不以做過大項目為榮，我這幾年的項目經驗告訴我，團隊不在于大，在于精，
閱讀全文
摘要: 所以對于框架來說，職責的分擔，是很重要的，完成你該完成的，該擴展的地方，即要提供默認實現，也要提供接口，供調用者二次開發。這才是框架的可擴展性、靈活性所在。
很多人在開發框架時，總期望做很多東東，自己給自己加套，反而喪失的靈活性，同時提供了很多不能擴展的實現，等于強加意志給使用者，愛用不用。
閱讀全文
摘要: 公司的發展出現了問題，不應當讓技術人員來買單，而是我們的管理團隊，是公司的上層建筑出現了問題，當領導的應當自己積極的反省，即使可以憑借權力讓下面無辜的人來買單，那又怎么樣，當公司over的時候，大家不都是一樣over，總有一天，報應會來的，終有一天，領導要為自己的決策失誤來買單。
閱讀全文
摘要: 星期四是約定去面試的日子，二面了，覺得還是有希望的，對方是臺灣的一家公司，從網頁上看，還算是跨國公司，規模也算比較大，做呼叫中心的。
閱讀全文
摘要: 我的項目中List都是基于ArrayList的，所以基本上很少用迭代器來遍歷，而是用for循環來遍歷，對于迭代器的作用我當然很清楚，但是我覺得有點庸人自擾了。
除非你經常用Collection作為你的接口方法中的輸入或輸出的集合參數類型時，你也就只能用Iterator。
但我一般在接口方法中，一般用List，所以我就不用迭代器，除非我的List是Linked List實例。
好的作法是：在供外部調用的接口方法中，使用Collection作為集合參數類型，在內部實現當中，使用List，而不是一味的使用Collections及Iterator，這樣做無異于作繭自縛。
JDK中推薦的是對List集合盡量要實現RandomAccess接口。
閱讀全文
摘要: 在電子支付的安全環節中，CA認證是必須要了解的技術
閱讀全文
摘要: 隨著企業競爭日漸激烈，各商業銀行業在擴展金融服務產品、服務渠道方面更是爭先恐后，但目前銀行系統存在的主要問題在于外圍前置機較多，部分業務流程復雜，系統交叉聯系，業務擴展時需改動的外圍系統較多，導致業務擴展較為困難。為了減少主機進行路由服務，減輕主機的壓力，使核心業務系統成為簡單而穩定的核心。同時為了滿足金融行業快速的電子化建設需要一個高度集成、 高可配置的開發和運行框架，既是一個高效、方便的開發環境，也是一個穩定、可靠的運行環境。 通過配置化的管理，實現渠道接入整合，業務流程的優化，數據分布的合理布局
閱讀全文
摘要: 電子商務發展的核心問題是交易的安全性問題，這也是企業應用電子商務最擔心的問題，因此如何在開放的公用網上構筑安全的交易模式，一直是人們研究的熱點和大家關注的話題，要構筑一個安全的電子交易模式，應滿足以下五個方面，這也是OSI規定的五種標準的安全服務
閱讀全文