摘要: 插件架構(gòu)體系是我一直就非常關(guān)注的內(nèi)容，其實(shí)插件架構(gòu)體系的發(fā)展已經(jīng)有很久的背景了，插件架構(gòu)體系的優(yōu)點(diǎn)我們也是能看的非常明顯，象硬件一樣的即插即用、無論對于公司還是業(yè)界而言的良好的積累方式、為公司或業(yè)界提供統(tǒng)一而規(guī)范的開發(fā)方式以及穩(wěn)定的內(nèi)核架構(gòu)等等，這些優(yōu)點(diǎn)無論對于公司還是業(yè)界來說都是非常重要的。
插件架構(gòu)體系基本的一個(gè)概念就是基于松散的模塊積累方式，通過新增插件以及擴(kuò)展原有插件的方法來完成系統(tǒng)的實(shí)現(xiàn)，凡事有利必有弊，在看到插件架構(gòu)體系的這些優(yōu)點(diǎn)的同時(shí)，在實(shí)現(xiàn)和使用插件架構(gòu)體系的時(shí)候仍然會碰到不少的問題，在本文中大概的整理了一些也相應(yīng)的提出了一些自己的看法。
閱讀全文
摘要: 在和一個(gè)朋友交流權(quán)限系統(tǒng)方面的實(shí)現(xiàn)時(shí)，朋友提及到JAAS，我自己對JAAS不是那么了解，不好去評價(jià)，后來去網(wǎng)上查閱了不少JAAS的文檔，應(yīng)該說現(xiàn)在大致的對JAAS有些的理解了吧，個(gè)人覺得JAAS只能算是實(shí)現(xiàn)權(quán)限系統(tǒng)的另一種方式，相當(dāng)于提供了一個(gè)框架，至于這個(gè)框架基于什么模型我無從評價(jià)，對比下來我仍然認(rèn)為基于RBAC自行實(shí)現(xiàn)是更佳的方案，不過JAAS中也有可取之處，那就是它的PAM思想。
閱讀全文
摘要: 本來作為客戶而言，它需要關(guān)心的是自己想基于系統(tǒng)做什么，實(shí)現(xiàn)什么樣的功能，而不會關(guān)心到技術(shù)層面，但如果碰到了關(guān)心技術(shù)的客戶怎么辦呢，客戶關(guān)心到你用的是什么平臺、什么框架、為什么要用以及它如果要基于平臺做自主開發(fā)要怎么做，感覺在這種情況下挺棘手的，客戶往往就變成了對于你實(shí)現(xiàn)需求的技術(shù)進(jìn)行干預(yù)，而很多時(shí)候又沒法向用戶解釋清楚，而且在這種情況下往往是客戶根據(jù)你的介紹和講解來做出基于這樣的平臺是否能實(shí)現(xiàn)他們需求的評估，這就挺難搞了，也許是自己的技術(shù)不過關(guān)，不過覺得最缺乏的是溝通的方法，大家覺得在這種情況下會有什么比較好的方法呢？求教.......
閱讀全文
摘要: 幾乎在所有的系統(tǒng)中對于權(quán)限控制都有直接的需求，而這類需求往往有其相似性，綜合常見的對于權(quán)限系統(tǒng)的需求構(gòu)成了本文檔，文檔主要從功能復(fù)用以及模型復(fù)用的角度來對權(quán)限系統(tǒng)進(jìn)行總結(jié)，以便在各種系統(tǒng)中可對照此篇文檔來進(jìn)行權(quán)限系統(tǒng)的實(shí)現(xiàn)，考慮到文檔的關(guān)注點(diǎn)在復(fù)用度，在文檔中不會過多的去描述功能點(diǎn)到模型產(chǎn)生的過程，而是采用直接通過產(chǎn)生的模型來說明基于此模型如何實(shí)現(xiàn)功能點(diǎn)的需求。
閱讀全文
摘要: 從公司級來講，自己的資格是遠(yuǎn)遠(yuǎn)的不夠，在這里主要也是根據(jù)自己的項(xiàng)目經(jīng)驗(yàn)闡述下自己對中小型企業(yè)技術(shù)團(tuán)隊(duì)的一種觀點(diǎn)，個(gè)人覺得對于中小型企業(yè)來講三級團(tuán)隊(duì)的構(gòu)成是比較理想的，就是支撐平臺團(tuán)隊(duì)+應(yīng)用系統(tǒng)開發(fā)團(tuán)隊(duì)+實(shí)施團(tuán)隊(duì)，從三級團(tuán)隊(duì)的構(gòu)成來講切忌企業(yè)的面鋪的太廣，那這三級團(tuán)隊(duì)就很難形成了，但在國內(nèi)大部分中小型企業(yè)仍然處于盈利為上的策略，這也是沒辦法的，畢竟求生才是最重要的，在這種情況下，我覺得在這樣的公司不如干脆由應(yīng)用系統(tǒng)開發(fā)團(tuán)隊(duì)+實(shí)施團(tuán)隊(duì)來組成，而支撐平臺則選用開源的或進(jìn)行采購，當(dāng)然，選用開源的概念是某個(gè)可直接用的或者不需要進(jìn)行太多集成工作的，這樣在公司發(fā)展到一定程度的情況下，在適當(dāng)?shù)臅r(shí)機(jī)下再進(jìn)行升級到三級團(tuán)隊(duì)的建設(shè)。
閱讀全文
摘要: 大家都知道Eclipse是一個(gè)典型的插件系統(tǒng)，而從3.0起其插件體系架構(gòu)就重構(gòu)為基于OSGI規(guī)范來實(shí)現(xiàn)的，從這也可以看出osgi必然與Plugin Architecture是有很多的關(guān)聯(lián)性的，在這里就來說說自己對Osgi R3與Plugin Architecture的關(guān)聯(lián)。
閱讀全文
摘要: 本文主要對于軟件過程的整體規(guī)范進(jìn)行較為完整的描述，來源于個(gè)人的項(xiàng)目經(jīng)驗(yàn)、所在team使用的軟件過程以及個(gè)人的一些想法總結(jié)而成。
文章按照對項(xiàng)目中采用的軟件過程進(jìn)行描述，之后對保證整個(gè)軟件過程有效執(zhí)行的工具、制度等進(jìn)行描述。
本文意并不在標(biāo)明這個(gè)軟件過程是多么的優(yōu)秀，關(guān)鍵是要找到適合自己團(tuán)隊(duì)的軟件過程，沒有最優(yōu)秀的，只有最合適的。
閱讀全文
摘要: 根據(jù)自己的經(jīng)驗(yàn)整理一篇軟件過程規(guī)范的文章，主要是根據(jù)自己的經(jīng)歷以及目前的情況來完整的描述一個(gè)軟件項(xiàng)目過程中規(guī)范性的東西。
遵循的一個(gè)原則是："規(guī)范不是萬能的，要不斷調(diào)整，每個(gè)Team有每個(gè)Team適合的規(guī)范。"
這篇是序，明天整理一份完整的文檔，對整個(gè)軟件過程中涉及的規(guī)范的東西進(jìn)行較為完整的描述。
閱讀全文
摘要: 這篇Blog接著上篇Blog提出的場景進(jìn)行解決方案的描述：
在和江南白衣聊的時(shí)候他提出了oscache提供的cache:cache標(biāo)簽的解決方案，開始想了一下覺得不怎么可行，這也是因?yàn)樽约簩ache標(biāo)簽不熟的原因，后來去網(wǎng)上查了一下cache:cache標(biāo)簽的使用，看了后覺得對于解決上面的需求應(yīng)該是可行的。
閱讀全文
摘要: CMS中緩存顯的至關(guān)重要，CMS中的緩存主要有靜態(tài)緩存和動態(tài)緩存兩種技術(shù)，但看下來現(xiàn)在覺得這兩種也只是對于最終信息頁面的緩存，現(xiàn)在的需求是：
1、站點(diǎn)、欄目、信息列表的緩存。
2、信息頁面的緩存。
閱讀全文