Title / Topic
Version
1.0
November
2007
Author ZhangV
Abstract
Table of
Contents
1. Introduction
2. Development
2.1. Process Definition
2.1.1.
jPDL
2.1.2.
jPDL
designer
2.2. Configuration
2.3. Web-service
2.4. Transaction consideration
2.5. Integration
3. Deployment
3.1. […]
测试 Scribefire(1.4.2) 发布
有没有移动版本的Scribefire或者是其他可以在手机上添加blog的软件呢？
同时也是最伟大的网站。可惜在国内却看不到
flickr什么的被阉也就算了，毕竟还还可以看到每张图的红xx，锻炼锻炼想象力。
可是wikipedia？那是wikipedia呀！？如果拒绝知识那就是拒绝一切。
xxxx you, G.F.W
ZhangV
在jbpm的流程定义文件（processdefinition.xml）中当定义一个task的assignment的时候有几种选择：
Swimlane
Pooled Actors
Expression
Actor
Handler
这里分别描述一下每种的用法，以及使用场景。使用场景的理解很重要，只有清楚每一种用法的所适合的情形，以及他们之间的相互转换才能说是真的“会用了”。
Swimlane
可以理解为角色，这里是指这个流程中的参与者或者角色。在实际的业务系统中，他可能根本就不是一个业务角色，可能是一个外部应用，也可能是一个处理过程，或者是几个业务角色的结合。所以要清楚他是指“在该流程中”的角色。在jPDL的user guide中写的很清楚也反复强调 - “process role”。
通过在流程定义文件中定义：
<swimlane name=”leader”>
<assignment class=”com.modofo.engine.swimlane.LeaderSwimlane”></assignment>
</swimlane>
同样可以实现运行时的结合实际应用进行灵活的任务分配。这也是目前我看到的使用比较多的方式。
Actor
相当于设置TaskInstance的actorId属性，主要用于获取某个actor的所有任务列表。设置方法在定义中描述actor-id属性，或者调用TaskInstance.setActorId（String）方法，或者在AssignmentHandler中调用assignable.setActorId（String）方法。
Pooled Actors
用于定义所有的任务参与人（candidates for task instance）。在查找某个参与者可参与的任务时使用，其实就是一个actor的集合，jBPM通过TaskMgmtSession.findPooledTaskInstances(String actorId)或者TaskMgmtSession.findPooledTaskInstances(List actorIds) 来查找任务集合。
注意：actor的优先级比pooled actors要高，所以如果同时设置两者，那jBPM只会用actor来查找，而忽略pooled actors。
一句话： actor被用来获取某个参与者的个人任务列表，pooled actors用来获取某个参与者可以参与的所有任务列表，或者说组任务列表。
使用这个actor集合的初衷就是为了不让任务分配和角色体系耦合。流程定义中始终都是只有参与者的名称和集合，而不存在用户，角色和用户组的具体设计。而使用Expression就耦合了这些信息在流程定义里。
Expression
如果你使用jBPM的identity component的话。你可以使用表达式定义的任务分配模式。通常这个表达式的形式是：
<assignment expression=’previous –> group(hierarchy) –> member(boss)’ />
我看了之后也不是很清楚，group和member是jBPM的identity componenet的概念，这个表达的意思大概是：使用之前的actor，然后在hierarchy组，并且member（角色）是boss的所有actor。这种方法仅限于使用jBPM的IC时使用。
Handler
指定你自己的AssignmentHandler实现。该接口只有assign方法。这种任务分配方式主要用于运行时的任务分配，而不是hardcode到定义文件里。使用场景，如果不想让原本应用中的访问控制与jBPM耦合起来，就可以使用这种方法来将jBPM中的任务分配代理出来。当然更好的定义是用swimlane,这样可以让定义文件看起来不是很凌乱。
今天从黄老师那里听说了这个：tricycle + skate = trikke
这个是恩师的英姿：p
How about my trikking?
如果一个blog的主题比较集中而又不很专业化，比如keso或者老罗，那么就是subscriber-friendly。当然不是说他们“不专业”而是说他们的文章不是那种类似于“jBPM流程定义文件中的swimlane的用法”，而是比较符合大多数人口味的文章。这种blog适合独居。
而大多数个人blog要么太过专业化，太晦涩，要么太个人化。这些blog中有很多有价值的文章，但是却不适合让订阅者去发掘和分类了。这时候要么是blog选择群居，比如聚居于javaeye，csdn，要么等着让搜索引擎发现。也就是searchengine-friendly。这样的后果就是也许你的很有价值的文章要等一段时间才能被需要他的人发现，因为搜索引擎也需要一些时间。
也许前者就代表着主流的blog文化，后者就是所谓的边缘，有意思的是，如果你使用某个足够大的BSP，那么BSP是主流而你不是：）
你的blog是哪种呢？
Continue reading about subscriber-friendly 还是 searchengine-friendly
作者:DavidAnderson 原文
翻译:ZhangV 2007-11-26
之前，在描述我在corbis的管理和领导软件工程的方法时 ，我曾经提到我引入看板系统来维持项目运行。因为它的引入，我们现在每个月平均发布两个新的版本。然而，这些并没有使用传统的敏捷开发方法如两周迭代（two week iteration)或快速迭代（sprint)。而是用看板系统来管理变更请求（CR-Change Request）。当CR被完成时，它被设在准备发布状态，并在每周三被发布。
尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR，但基本上的日常工作，我们都是使用白板作为看板来跟踪所有CR，把Post-It当作看板卡。
我们的支持过程是由一组常见的软件工程资源驱动的，没有一个专责维持或维修团队。通过设置看板，我们可以向管理层保证 - 我们正在履行我们的承诺，我们使用了一定的资源来进行支持活动，而不需要特别指出是谁在负责。
每天早会上所有团队成员会围绕看板来进行当天的工作安排，讨论进度和当前存在的问题。达伦戴维斯，作为项目经理，会主持会议，并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID，及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing)，但每天都会验证它的有效性。
一些关键概念是值得的描述的。红星表示，这个项目是严重超时的，超过28个工作日服务水平协议（ sla ），通过该系统。这使”迟到”的项目能够自我加速，不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片：黄色-客户提出（customer-valued)的CR;蓝色-客户提出（和要求）的bug;绿色-IT维护项，如：的sql 2005的升级;橙色-新增（或额外）的bug;粉红-issue。
看板限制卡片最多只能有20张，分为不同阶段，系统的分析，开发，测试，构建/合并，部署。此外，我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候，我们会减少这个数量，或者干脆不要。此外，还有两个维护项，这让我们能解决固定分配一些资源到大大系统维护和升级，例如API版本升级，与平台的升级。 如net2.0或sql server 2005 。
该看板系统使我们能够提供对三个成功的要素：减少“正在完成工作(work-in-progress)”， （讽刺的是，这些事情本身会限制工作的完成） ;量入而出（如果有新的CR，首先看看板上有没有足够的空间） ;和确定优先顺序。我们每周和公司的技术总监（vice president-应该是负责人，而不是副总裁 - 译者）开会讨论，决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考一下一个，两个，或三个最重要的事情。看板强迫他们给出优先等级。
该看板系统，也把我们从定时迭代的压迫（constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新的版本，大的负责的任务可以在系统中最多可以存在60天。那些对于“一（两）周迭代”来说太大的任务同样可以放到看板里而不需要特殊的关照。
最后，看板解放了我们，我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理，除非有特殊情况出现，如需要加快请求或因环境或系统的维修问题变更发布时间。
technorati的标签：敏捷，朱+安德森，精益生产，看板，软件+工程
顺便问一下customer-valued怎么翻译？
今天和老贾通电话,他最近投资了一个网站 内蒙吃吃网, 让我去看看给点建议.
首先给我的感觉就是这个网站不够”二”,其实就是一个local listing的网站,而且似乎太local了,看了一下目前主要都是集中在呼和浩特市区范围,想想呼和浩特一共只有200多万的市区人口.再者因为不够二,那就意味着大多数内容要自己去找,结果很可能是吃力不讨好. 看看大众点评的呼和浩特频道我会毫不犹豫的选择后者.本来在没有看到大众点评的频道时候还觉得”可以考虑将来被大众点评收购”,现在看来看不到什么前途.
感觉自己就会”挑刺”,如果人家做的不好,那么你能吗?我不敢说如果我面对的是这样一个题目应该如何应对,虽然我可能不会把自己置于这样的境地.但毕竟如果我仅仅说了这个网站就目前来看是没有前途就闪人是不负责任的或者说太会取巧了.但有没有办法来改变呢?(除了放弃之外). 试试吧.
再来回顾一下关键字: local listing, 吃, 内蒙, 点评, web2.0 , 200万人口
首先让本地的人都知道你 - 不容易,因为他们发现你和发现其他分类服务网站的成本是一样的,可能名字有点优势
除了吃还有别的吗 - 有的,其他的消费娱乐都有 - 外卖可以是一个优势 - 还是存在被收购的可能(前提仍然是要二)
内蒙是一个人口少,而有分布分散的地方 -
目前的类似论坛的交流社区显然不够有效
怎么能让网站够二,让用户提供信息给你
200万人口里有多少人会使用互联网,多少人使用互联网分类服务,多少人会从成百上千的服务中选择你 - 为什么会选择你 . - 这些取决于当地的人口构成,分布和经济情况,当然还有互联网发展情况
呼和浩特的大学生是一个比较大的消费群,考虑一下
方法:
社区改造为用户提供信息的模式,评价是一个很好的方法
扩大覆盖面,毕竟像大众点评这样的网站只能覆盖到一个大中城市如呼和浩特,包头,鄂尔多斯, 那么其他的呢?
让商户提供信息,让他们知道你对他们是有价值的,比如让商户提供菜单和活动宣传
做好外卖,但考虑到当地人的生活习惯(没有那么大的生活工作压力但可能会比较不愿意出门尤其是冬天),外卖可能和上海北京不大相同
(同样是原来space的一篇,放到这里)
2007/6/14
游戏
完整的“游戏人生 “是每一个80sgeek的共同点. 电子游戏在中国的开始刚刚是 70年代末80年代初生人刚刚懂事上学的86/87年左右.
最早的时候是去大舅家玩,只记得那时候魂斗罗只能打到第一关boss, 打的最多的是 “吃豆豆“(NAMCO的<<PAC-MAN>>) 和坦克大战. 之后大舅给我买了一台任天堂(FC – Family Computer), 现在回想起来在当时那个只有两条被称为裤裆街的小镇上, 有人会花上300多块去买一台游戏机这是何等 “魄力“J — 不过后来不到半年就被别人巧取豪夺去了,可能那时候自己玩的太疯了. 不过很快, 就出现了很多“游戏机房“, 我家街对面就有一个我的根据地, 是一个姓张的老头开的, 叫“佳乐游戏室“, 也不知道老头子现在身体怎么样了 ,将近20年了. 一直到后来子承父业的张老二 , 我都是被紧密地团结在这里. 这个时候玩的游戏主要还是FC
功夫
采蘑菇(玛丽兄弟2,3)
魂斗罗(1,2)
双截龙(1,2,3)
街头霸王(虽然很粗糙,但是很可爱 )
洛克人(1,2,3…456是在大学时候在模拟器上看到的)
西游记
魔界村(这个游戏我到最后都没打到第二关, 后来玩的好像是超任上的 “大“魔界村)…
冒险岛
科纳米世界(巅峰之作!)
圣斗士
成龙之龙
赤影战士(水上魂斗罗)
后来就有了世嘉五代,最有名的应该是战斧,四天明王 ,三人格斗,兽王记,超级忍, 狮子王,幽游白书 – 这些应该是4,5年级时候玩到的 .
上初中时候街机开始流行, 街边出现大大小小的街机房,想必很多人记得名将 ,街霸,钩子船长,恐龙岛 ,真人格斗 – 那个时候也是漫画书比较热的时候,当时出了一本叫 <<画王>>的漫画杂志, 觉得很好 , 每期都买, 后来不知道为什么停刊了.现在也觉得很遗憾. 扯远了.
在后来是SFC的磁碟机版, 当时最热的是足球 , 玩过的人肯定还记得里边大步镗球,身后挑球过人, 梳着小辫子的巴乔 , 白头翁拉瓦内力, 爆炸头古利特…, 当时邻班居然组织全班联赛 […]
网站提供的流量不便于统计，比如你的blog有几个指到ebay的链接，而ebay是愿意为你的推广行为付钱。但现在的问题是，ebay没有办法付钱给你，因为他不认识你和你带来的流量，这些流量不得不成了你免费提供给他的。
有没有这样的中间机构，他们负责和大多数的愿意付钱给带给他流量的网站联络，另一方面其他的网站和这个机构达成一个协议，所有从他网站发出来的链接都先经过中间机构的统计然后再指引到目标网站。
比如，我的网站有一篇关于e61i资源的文章，其中提到了mosh。而mosh通过中间机构购买了流量。我所要做的就是在我的网站通过一个中转链接 - 先到中间商那里（进行统计）再转到mosh。这样我为mosh所作的推广行为就会得到记录。我不需要知道mosh，我只需要在中间商注册，中间商会帮助我和mosh连系起来，然后让mosh付钱给我。
问题：
流量其实是没有增加的，这样做是不是会让购买流量的网站付了更多的钱？
好像不少咸网就是这个模式吧？