MoDoFo.println(”

当业务又分布式的服务构成时,事务将很难控制甚至无法控制,也就变得不那么重要了.这种时候我们也就没有理由一定要”关系的”数据库了.

1.简单并不代表一陈不变和单调 – 界面可以稍微调整让使用者更直接的找到自己的需要
2.信息过滤机制缺少,或者搜索功能比较贫乏
3.可以根据内容调整页面(同1). craiglist的页面简单的一个主要原因是页面上没有其他”干扰”因素,而百姓网页面上”干扰”太多了
4.如果有一个”监控器”给用户,也许我会经常来看看.(比如我可以设定一个半年内入手一辆二手的trek,但不需要每隔几天上来看看,当监控找到匹配时可以自动发email给我)

是否可以把分类信息网站和twitter整合起来,比如发布信息后自动推倒twitter, 也许就可以增加关注度了.
比如我发布一条莘庄的二手信息, 分类网站直接发布一条包含位置信息的推, 而位于莘庄某个地方的另一个人在使用IM++时候可以看到nearby里有人在卖这件东西.然后follow,进而可以和我直接联系,最后线下完成交易.
这样,也许可以增加交易的成功率,在较短的未来也许还不太可行(有很多局限,比如twitter的限制/移动互联网的不普及).但相信未来还是有很多可能的.

直接上代码:
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
import org.json.me.JSONObject;
public class GooglUtils {
private static String GOOGL_API_ENDPOINT=”http://goo.gl/api/shorten?security_token=null&url=”;
public static String shorten(String url) throws Exception{
HttpConnection con = null;
InputStream in = null;
OutputStream out = null;
ByteArrayOutputStream bos = null;
OutputStreamWriter osw = null;
InputStreamReader isr = null;
byte[] request;
int messageLength;
try {
bos = new ByteArrayOutputStream();
osw = new OutputStreamWriter(bos, “UTF-8″);
//            osw.write(url);
osw.flush();
request = bos.toByteArray();
messageLength [...]

今天和小小兔工作室的杨同学聊了聊.
关于互联网,android,产品创新,职业发展,创业…
互相简单自我介绍之后,就是关于互联网创业的一些想法和观点.很赞同他的一些观点:
1.做事情要布局,先是做一个个点,然后要把这些点连起来形成面,形成网络
2.想法可以有,但还是要做出来. – 这点我很惭愧.
3.精确的时间管理
4.要有自己的东西,避免依赖别人,但可以借鉴.
5.做事情的成败最终归结到人(团队)的素质
6.坚持/专注
今天和小小兔工作室(xiaoxiaotu.com)的杨同学聊了聊.关于互联网,android,产品创新,职业发展,创业…
简单自我介绍之后,就是关于互联网创业的一些想法和观点.很赞同他的一些观点:
1.做事情要布局,先是做一个个点,然后要把这些点连起来形成面,形成网络. – 不懂得布局的结局就是各种无法关联起来的独立”点”,最终把事情变成重复劳动,无法形成系统.警惕!!
2.想法可以有,但还是要做出来. – 这点我很惭愧,相当惭愧!!
3.精确的时间管理 – 这个不是一时半会可以解决的,是性格使然.
4.要有自己的东西,避免完全依赖别人,但可以借鉴或部分取用. -关于集成api的地方.
5.做事情的成败最终归结到人(团队)的素质 – 一个人可以做到事情,总有人会超过你.好的团队是很难被超越的.
6.坚持/专注 – 很通用
呵呵,相见恨晚啊.很nice的. 虽然目前工作室并没有明显的成功案例,但我很看好.

软件可以deliver不一定是因为所有既定需求完成，而是用户可以接受了(没有理由再去变化需求了)

项目启动会议开始, 项目经理拿出自己的项目计划信心满满的想要告诉大家接下来的项目实施应该如何展开. 可是刚刚开始就被需求分析师和产品经理质疑:
模块划分不合理,应该按照业务场景制定发布计划.
这意味着项目经理原本按照功能和系统模块制定的计划被90%的推翻.
为什么会有这样的问题?
项目经理的技术出身导致其对项目的scope估计无可避免的过早考虑到设计(甚至是代码重用)
而产品经理和需求方更多关注的是产品提供的feature,或者说一个”完整的”功能点.在scrum里我们称为”用户故事”.
而项目经理的项目计划又有两份,一份是给”上面”看的,也就是用户,产品经理,需求方;而另一份是给”下面”看的,也就是系统设计/开发人员.而这里显然是第一份.因为关注点不同.
这也是项目驱动(project-oriented)和产品驱动(product-oriented)的交付方式和内容的不同.
项目驱动更多的是在整个项目结束后交付完整的代码和所有的功能.因为项目(开发)的周期相对较短.
而产品驱动则是要在不同的阶段都要交付feature和功能(当然你觉得每个阶段都可以用项目驱动来做也没什么不妥),同时还要兼顾整体的系统设计和重用性/维护性等问题.因为产品(开发)的周期通常较长,夜长也就梦多了,开发周期可能同时伴随的维护任务和设计重构.在产品驱动模式中,项目经理需要更好的平衡能力和全局掌控能力.
项目启动会议开始, 项目经理拿出自己的项目计划信心满满的想要告诉大家接下来的项目实施应该如何展开. 可是刚刚开始就被需求分析师和产品经理质疑:
模块划分不合理,应该按照业务场景制定发布计划.
这意味着项目经理原本按照功能和系统模块制定的计划被90%的推翻.
为什么会有这样的问题?
项目经理的技术出身导致其对项目的scope估计无可避免的过早考虑到设计(甚至是代码重用)
而产品经理和需求方更多关注的是产品提供的feature,或者说一个”完整的”功能点.在scrum里我们称为”用户故事”.
而项目经理的项目计划又有两份,一份是给”上面”看的,也就是用户,产品经理,需求方;而另一份是给”下面”看的,也就是系统设计/开发人员.而这里显然是第一份.因为关注点不同.
这也是项目驱动(project-oriented)和产品驱动(product-oriented)的交付方式和内容的不同.
项目驱动更多的是在整个项目结束后交付完整的代码和所有的功能.因为项目(开发)的周期相对较短.
而产品驱动则是要在不同的阶段都要交付feature和功能(当然你觉得每个阶段都可以用项目驱动来做也没什么不妥),同时还要兼顾整体的系统设计和重用性/维护性等问题.因为产品(开发)的周期通常较长,夜长也就梦多了,开发周期可能同时伴随的维护任务和设计重构.在产品驱动模式中,项目经理需要更好的平衡能力和全局掌控能力.

早就想试试持续集成.终于有机会了.
刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.
hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.
我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.
在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.
之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.
之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.
此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.
其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!
hudson,很和谐!
早就想试试持续集成.终于有机会了.
刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.
hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.
我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.
在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.
之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.
之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.
此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.
其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!
当基础模块部分基本稳定后,我们将应用模块也做到自动化构建和发布到开发集成环境.每小时进行一次发布.确保了我们集成开发环境始终都有最新的版本. 后续我们准备将自动化smoke test也做一些,也许不需要很彻底,只需要基本的接口可用即可.
hudson,不,持续集成,很和谐!

敏捷估计与规划笔记
敏捷宣言推崇:1.个人与交互重于开发过程和工具–敏捷开发小组认为: 一个由使用普通工具的优秀人员组成的/运行良好的小组,总是会比由使用优秀工具和过程的普通人组成的,紊乱的小组做的更好.–我们花了太多的时间试图定义一个开发过程,以便把人当作机器上可被替换的齿轮,却没有取得成功2.可用的软件重于复杂的文档–每次迭代结束时获得一个稳定的,逐渐增强的版本,比便更频繁的收集对产品和开发过程的反馈–将反馈回馈到开发过程,以保证开发小组始终在处理最有价值的功能3.寻求客户的合作重于对合同的谈判–这是一个希望,也许不是开发小组可以控制的 –我认为4.对变化的响应重于始终遵循固定的计划–最终的目标!!是向项目客户和用户交付更多的价值(或者更多的必要特性,更合理的时间,更小的成本)–而切记计划是为目标服务的 –我认为
基于活动而不是基于功能进行规划 (是不好的!)基于活动的规划分散了我们对功能的注意力,而功能才是衡量客户价值的担忧忽视关于用户最终需要什么的不确定性,会导致虽然然按时完成了项目,却没有包含在制定计划以后发现的那些重要功能.
敏捷开发小组的主要工作方式:1.作为一个整体工作2.按短迭代周期工作3.每次迭代交付一些成果4.关注业务优先级5.检查与调整
如何分割用户故事1.按照数据边界分割按照用户故事所支持数据的边界分割大型用户故事2.按照操作边界分割把大型用户故事分割成独立的建立/读取/更新/删除操作3.去除横切考虑为用户故事建立两个版本:一个具备对横切考虑的支持,另一个不具备这种支持.4.不用满足性能限制5.分割具有混合优先级的用户故事6.不要把故事分割成任务而是寻找一个方法来让曳光弹穿过整个故事7.避免相关变化的诱惑在一个适当规模的功能中增加相关变化会把事情弄糟,除非这些变化具有同样的优先级8.组合用户故事对按照2周一次的迭代周期工作的开发小组来说,合适的做法是3~5天做完
速度驱动的迭代规划步骤调整优先级/确定目标速度->确定迭代目标->选择用户故事->分解任务->对任务估计
承诺驱动的迭代规划调整优先级->确定迭代目标->选择要增加的用户故事/把故事扩展成任务/对任务估计->要求小组作出承诺<->移除一个用户故事(如果无法承诺)->迭代规划完成(可以承诺)