re: 敏捷將亡 咖啡屋的鼠標 2010-06-11 18:01
@BeanSoft
你竟然是第一個瀏覽的，最近還好不？
這世道總是混事的侵占做事的創造出來那點果實。無奈
@javaliqi@163.com
呵呵，兩年前回復的那天，確實還沒找到。謝謝您還關心。
re: 我眼中的軟件開發 咖啡屋的鼠標 2010-04-15 22:02
@路人甲
可擴展，可維護。最終的判斷指標也是隨著擴展和維護，需要付出的時間。擴展時需要寫的代碼減少也是代碼減少。誠然代碼不能一概而論的作為時間的考量標準，因為一行代碼和一行代碼的價值并不同。除了不同的人，即便是同一個人，在不同的階段代表的時間占有量也不同。可是在每一個單獨的時間點，我們可以把它做為一種單位去考慮我們的設計。比如我們需要擴展一個系統，好的設計可能只需要寫少量的代碼，不好的設計可能需要寫很多代碼。這也算是減少了代碼量。
re: 天命 咖啡屋的鼠標 2009-01-09 15:08
@Alex wang
呵呵，有點，間接的關系。
re: 囚徒 咖啡屋的鼠標 2008-08-14 15:04
@窮
在InfoQ的一篇評論后看到這么一句話：
“李斯討論軍隊任命時，說：新兵賞之則喜；罰之則懼。老兵賞之不喜；罰之不懼。”
現實中也真是這樣。
接觸油滑的老程序員越多，就越喜歡畢業生。不過這也沒有辦法，生活壓力把大家都壓得心態都變形了。大公司的政治斗爭就更惡心，無益于問題的解決，更養成了不良的心態。
re: OO 原則 咖啡屋的鼠標 2008-03-18 21:27
總感覺這里面有些原則是告訴我們應該做什么，而有些只是說了做好了應該是什么樣。
re: 想在Flex平臺上學習設計模式的人注意啦 咖啡屋的鼠標 2008-03-09 13:16
@lwz7512
嗯，確實沒注意到，我對這個領域的信息渠道一直在建設中。。。
感謝提供了一個好書，最近覺得那本書里寫的模式實現很多有點取巧的意思。倒不是說有什么問題，僅從審美的角度講覺得有點不舒服，代碼有點多。
re: 正欲燎原的Flex 咖啡屋的鼠標 2008-02-29 15:40
@香草的天空
這個問題，看怎么看了，Java不也是1.4之后才成熟的么。而Java的IDE也曾經被大多數的人嘲笑過。而且，站在開發者的角度，這不見得是壞事，如果等到那個時候再去研究Flex，哪里還有機會？小白鼠還是開拓者，見仁見智吧。
ps：Flex的IDE其實不僅僅是Flex Builder，IDEA，FDT，好像還有一個開源的拿Flex寫的。名字忘了。
re: 正欲燎原的Flex 咖啡屋的鼠標 2008-02-28 10:44
@Kenshin
我改不了，blogjava不提供給我這功能，相反，如果你注冊了，那你就能改自己的評論，不注冊的我就不知道咧。。。
re: 正欲燎原的Flex 咖啡屋的鼠標 2008-02-28 09:40
@交口稱贊
我跟你觀點差不多，不過網站的話，信息發布類雖然不行，但交互性要求很高的社區類網站就很合適。
re: 第一次應用blazeDS實錄 咖啡屋的鼠標 2008-02-24 11:43
我發郵件告訴你了，你沒收到？
re: 第一次應用blazeDS實錄 咖啡屋的鼠標 2008-02-22 10:48
樓上，你是怎么反編譯的，求方法。
雖然Flex Builder里面有代碼，但是反編譯swc還是很有用的技能。
我覺得flex不會經歷大改動，進入AS3之后已經很穩定了。flex3馬上就要發布了，而flex2的開源項目重新編譯一下都能在Flex3上使用，對開發人員沒有影響。
re: 開始看blazeDS 咖啡屋的鼠標 2008-02-21 10:51
感謝博主的幫助文檔下載地址
re: 為什么大家瞧不起國內的開源 咖啡屋的鼠標 2008-02-21 10:36
許久不用Struts Spring Hibernate的人飄過。。。。。。
國內搞開源是比較難，想做個像紅十字會那樣正式的組織還得部級干部牽頭。開源軟件在國內的生存環境真的是不容易。
至于為什么討厭國內的開源，那沒有辦法，有些人已經讓國內開源給大眾留下了掛羊頭賣狗肉、喜歡作秀勝于實干的印象。印象的改變要好久。樓主既然選擇了這條路，而且覺得自己做的不是這樣的開源軟件的話，那就用行動來改變唄，有位工匠說過，一個優秀的工匠應該是用行動去說話
re: (轉)什么才是軟件開發的葵花寶典？ 咖啡屋的鼠標 2008-02-14 11:57
需不需要先自宮？
re: web2.0時代也談在家辦公 咖啡屋的鼠標 2008-02-01 16:08
@allenny
你可以去試用一下Google Docs，尤其跟多個人一起編輯一個文檔，那跟SVN、CVS完全不是一種感覺的。
@fiction
十分感謝您提供的這條信息，對我可能會非常有幫助。
Web Service我沒有搭建過，大概了解他是使用的XML通信，如果是XML的話，當然不用映射。我們可能是因為是采用的HttpService的緣故，后臺寫的代碼沒有為生成XML而進行過合理的設計，而且或許因為項目的特殊性也很難設計，我們的數據對象不是POJO,也不是數據庫的數據，而是一些非結構化的對象，每一個取數據的操作都是一個底層API的訪問。在后臺將其轉換成XML還是JSON都需要編碼。這個過程主要是在后臺，不是在Flex端。
re: 談一談在家辦公的利弊 咖啡屋的鼠標 2008-01-31 13:10
嘿嘿，可不可以收咨詢費啊。
開玩笑了，不過這個方案真是可以想象一下，我這今天正愁江郎才盡寫不出東西來呢，有時間也就這個寫篇博客文章。
re: 談一談在家辦公的利弊 咖啡屋的鼠標 2008-01-31 12:04
確實很遙遠，不過也可以幻想一下，如果真要在家辦公的話，可以用Twitter，小組成員互相follow，每隔一段時間寫一下大家都在干什么，搞不好比在同一個辦公室更好。
討論可以用msn，甚至QQ群（這個當然有弊）等，省的討論起來沒有個頭，也有記錄。必要的時候才打電話。還有Adobe提供了一個在線會議的軟件，也可以試試看。
Google日歷上安排工作計劃，大家共享日歷。
GoogleNote上寫一些關鍵點、用戶故事什么的。
Google文檔可以大家共同編輯文檔。
每天把要做的事情先寫好
re: [轉貼]成功其實哪有那么多道理 咖啡屋的鼠標 2008-01-31 11:50
@木偶人
活出自我，不因為失敗而扭曲自己，我覺更勵志一些。
re: 解析Java Class文件格式 咖啡屋的鼠標 2008-01-30 16:15
占座看熱鬧
re: Flex項目技術架構前的假想 咖啡屋的鼠標 2008-01-30 13:36
我的上一個項目就是用的第一種方法，然后用AS寫了一個底層通訊的類，總的來說代碼是比較清晰的，唯一的問題是前后臺的數據傳遞，Flex端不管是解析XML（偉大的E4X！）還是使用JSON對象都很方便，可是后臺就不太方便了。mapping那塊很麻煩，還對重構不太友好。或許可以考慮寫一個CodeGen來輔助。
我個人是傾向第三種解決方案。試用了一下BlazeDS還是不錯的，省掉了很多麻煩。不過沒有在真實項目用過還不知道在細節上會不會有嚴重的問題。如果采用這種方式，我覺得像寫Servlet一樣寫一些門面類，讓Flex通過門面來訪問是比較穩妥的一個方案，不要暴露太多后臺的類給前臺。
寫模塊的時候mxml寫view，as寫model和controller（必要的時候as也可以寫點view，因為編譯速度快），盡量減少代碼行數，不要寫沒用的類結構。較大而且獨立性比較強的模塊就用Module，Module直接寫在mxml中是沒用的，得使用ModuleLoader。
re: 模式回顧---單例 咖啡屋的鼠標 2008-01-30 13:18
考慮了一下，還是趁中午的時間把改正的結果更新了，經過簡單的多線程測試是沒有問題的。
re: 模式回顧---單例 咖啡屋的鼠標 2008-01-30 11:45
@dennis
感謝您的批評指正，這個寫法是有點問題。昨天跟朋友討論出這個方法的時候沒考慮細，剛才看了看，改改也能使用，可能就丑陋點了。先刪去。
至于最后一種，確實不是lazy的，我看了看也沒寫是Lazy的，應該不會有誤導概念的問題，但還是標明了一下以防止誤會，很感謝你的指出。我只是把所有的初始化代碼放到了init里面，在構造器里不做任何操作初始化操作，其實還應該做一次是否初始化的二次判斷。省的多次初始化，但是那樣我就還要再寫一個函數來控制復位，說起來可能會更繁瑣，就沒加。
re: TDD與Junit的一點偶想 咖啡屋的鼠標 2008-01-29 20:34
怎么說呢，TDD的理論是無懈可擊的。可是現實中給的時間往往都不太現實。導致很多人從常識出發得出TDD浪費時間且無意義的錯誤結論之后拋棄在項目中采用TDD的實踐
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-25 11:39
@aj
我也看好Flex，但不覺得Ajax會被淘汰。
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-25 11:21
@6rl
Wooo，聽起來蠻酷的
@left
gladder、自由門、TOR等，Google一下你就知道
@sam
準確的講，不像。他是用actionscript寫flash的一種技術。屬于Flash世界的玩意。移步這里學習：
http://www.adobe.com/products/flex/
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-25 00:19
@王能
dojo聽說是很多缺點
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-25 00:18
@treenode
感謝你提供了一個線索，我會去試試的。
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 15:33
@窮
呵呵，好久不見了。
我的觀點跟你基本一致。不過前不久聽說可以重寫瀏覽器事件，比如后退。ajax可以考慮采用重寫瀏覽器事件的手法。防止用戶后退或者刷新。也許是一條路也說不定。
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 15:27
@地球玩家
http://www.earthplayer.com:8080/earthplayer/home.htmlflash大小447.26k，還算小
不過比起mapbar和googlemaps打開速度慢很多。但刷新一下很恐怖的。我忘了說Flex的另一個問題了，一旦彈出異常，用戶要是點一個取消而不是繼續，有時就只好按F5刷新了。
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 13:35
@久城
上一篇大概提了一下，Ajax只是借用了這個名詞（這里可以精確定義一下：指HTML+CSS+JS的RIA實現）。
我其實自己也是在考慮將來的走向，Flex的RIA還是Ajax的RIA。甚至于，考慮AIR。
Flex的話，開始可能是，但現在遠不止這么簡單了，對于Adobe來說或者說是Flash對他來說是未來最大的一盤棋了。Flex可以把它的產品攥成一個拳頭。
Flex的編譯速度也實在是令我頭痛，不過也沒有你那么慢，我們一萬多行的代碼大概20多秒。（里面還有很多mxml）你最好找找是不是哪里有問題。
Tin的ppt里講了如何優化Ajax，我們經常見到的web2.0應用其加載速度都非常快。而Flex目前最小也得100多K，可以用的至少都在500K以上。如果用Module的話也許好一點。不過每一個Module也都不小。這肯定是不能接受的一個體積。以Google的那些應用為例，同等效果的Flex應用肯定會大不少（而且純Flash能不能實現還兩說，我就想不通Flex怎么做Google reader這種產品，除非用DIV,像我昨天看的一個效果）
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 10:29
@cnodin
@久城
感謝二位的評論，根據意見又做了一些修改
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 10:07
@久城
其實我想說HTML,CSS這是很成熟的框架了。再配上這幾個框架，另外，容易上手是ajax的大優勢，我加上它。之所以說Ajax的框架成熟，是因為他已經對很多問題已經有了現成的解決方案，做Flex經常會發現原來在使用JS+HTML+CSS方面不是問題的，在這里反而成了問題，比如tab頁的初始化和ViewStack，每次后面的都不初始化，至今沒找到解決辦法，我恨這個特性。
re: Ajax還是Flex？（一）前輩Ajax 咖啡屋的鼠標 2008-01-24 09:53
@cnodin
DOM太多？是說DOM操作太多還是，DOM結構太龐大？這兩者倒是都會影響速度，Tin的ppt里有相關的說明。
extjs做出來的效果完全夠用了（其表格控件比Flex內置的好很多，Flex里面目前我還沒找到更好的），漂亮到一定程度之后，對大部分的項目經理來說，他們寧愿選擇大家都會的成熟的技術。而不是像Flex這么生僻的。
我是站在公司的角度來講，應用現有的公司資源比你從新開發一套AIR的東西好得多，公司往往已經積累了很多財富。air不得不去調這些東西（COM組件什么的，如果能調），這些東西平臺相關的東西會限制AIR的跨平臺的能力。就跟Java的境地一樣，很多Windows下開發的Java程序還真是不能放到Linux下不是Java的問題，是外圍的問題。
re: Lean與SARA模式-消滅慣性思維 咖啡屋的鼠標 2008-01-22 10:26
@cleverpig
"sara的成功是非常規思維制勝法？還是Lean的潛在作用？或者說是它蒙上了？"
這個問題誰知道呢，不過他確實是消除了浪費，從這個角度上講，是有Lean的潛在作用的。另外一個消除浪費的例子是三星，三星老總認為，花一億韓元，馬上就能擁有的技術，卻要花十幾億韓元，進行三到五年的開發，那是一種浪費。
re: Lean與SARA模式-消滅慣性思維 咖啡屋的鼠標 2008-01-22 09:42
@gfh21cn
那個度就是敏捷追求的東西。
新思維只是告訴我們可以換一個思路去解決本質的問題，而不是告訴我們把之前的都推翻。有這種想法就表示了腦海中還存在慣性思維，一有新的就把舊的全推翻（我時常想這究竟是宣傳后遺癥，還是我們的民族就這個毛病），關鍵是要找到本質的問題，真正的問題，解決它。
re: Lean與SARA模式-消滅慣性思維 咖啡屋的鼠標 2008-01-22 09:37
@cleverpig
隧道其實只是一種手法了，國內的情況是已經建立了大量集中的大型工廠，如果盲目去建隧道就是形而上學了，至于縮短前導時間，國內倒是聽說有一家公司做到了，手法非常簡單，老板聽完郎的講座之后回來跟員工說，我們要縮短前導時間，我們不要求12天那么快，15天就可以。果然很有壓力，核心人員跟老板拍板說，不可能啦，進貨要三天，XX要五天。老板全部炒魷魚，雇了一群新畢業的本科生，跟他們說，不管用什么辦法，15天，全做到了。
re: Lean與SARA模式-消滅慣性思維 咖啡屋的鼠標 2008-01-22 09:31
@李劍
抱歉抱歉，我記錯了。
re: flex3 控件轉圖片 咖啡屋的鼠標 2008-01-22 00:50
有用的技巧，頂
re: 敏捷真的是玄而又玄的“文化”嗎？ 咖啡屋的鼠標 2008-01-16 10:28
@hiswing
那是分布式敏捷的情形。具db4o的人說，他們是采用分布式敏捷的。關于文檔和體制，敏捷追求的不是沒有嚴格的體制和沒有文檔，只不過選擇用切實的工作模式（站立式晨會、結對、TDD、卡片墻等等）替代文字條框，用代碼代替文檔。
相對于敏捷，我一直在想，CMMI操作起來可能會有很多隱患，比如EPG的家伙們搞過級還可以，制定出來的文檔模板可能根本不好用，文檔可能看了幫助不大。中國的項目，工期大多是拍腦袋拍出來的，很有可能會是不可能完成的任務。小組成員還要分心寫文檔，一方面文檔大多湊付了事，后期文檔的效果會大打折扣；另一方面從事真正開發的時間進一步減少。
re: 敏捷真的是玄而又玄的“文化”嗎？ 咖啡屋的鼠標 2008-01-13 01:57
敏捷的本質是快速反饋，不管是小組與客戶之間的，項目組成員之間的，你自己的的代碼與代碼之間的等等。
背棄了這個原則，敏捷也就不成之為敏捷了。
re: Extjs學習筆記 --- 實戰 咖啡屋的鼠標 2008-01-13 01:43
哈哈，我是今天剛看完ext，成長歷程跟你完全相反。把你的extjs換成Flex，把Flex換成Extjs就是我的心態。
ext確實很酷，目前最酷的客戶端類庫了。
而Flex跟ext分屬兩種不同世界的玩具，玩玩就知道了，順便給你推薦一個Flex控件庫：
http://code.google.com/p/flexlib/wiki/ComponentList
re: Core Java之OO繼承設計技巧 咖啡屋的鼠標 2007-05-08 19:56
個人認為抽象類才是為繼承而設計的，普通類不是。而能用接口的盡量還是不使用抽象類。
>>>>>>
最近發現TDD很容易造成設計欠賬，相對與過度設計，設計欠賬也是不好的。想要用好TDD還得修煉啊。