MoDoFo.println(”

第一步: 修改RunWeka.ini文件,修改encoding为gbk, 否则会有中文乱码
第二步: 生成arff文件, 可以参考weka安装目录下的/data/ReutersCorn-train.arff文件格式. 中文和英文的一个区别是需要进行分词. 可以自己写个程序把文本转化为词序列.
比如:
text,class
‘我 是 帅哥’,1
‘胡言 乱语’,0
第三步: 预处理, 用explorer打开生成的arff文件, 然后使用选择filter->unsupervised->attribute->StringToWordVector. 点击apply
这样会将原本的instance:
‘我 是 帅哥’,1
转化为多个instance:
我,1
是,1
帅哥,1
胡言,0
乱语,0
第四步: 激活classify的tab, 选择分类器, 比如NaiveBayes, 注意选择”分类”属性选择class,否则无法进行分类, 点击start.
DONE, 下一篇通过代码来完成上述过程.

《浪潮之巅》作者吴军的主题分享归来，是最近几年少有的有干货的分享。主题是 – “不做事”。浪潮之巅本身是一本绝对值得多看几遍的书，之前我也一直想知道硅谷到底有什么神奇的地方。遇到美国的朋友常常会问问，硅谷为什么是硅谷，中国的缺少的是什么。
记下比较经典的几个观点，有些观点可供参考，但并非全部赞同。
1. 不做事
砍掉应该砍掉的东西，什么东西应该砍掉 ？ 低产出的项目和产品。说起来有点残酷，但这里有个前提，被砍掉项目并非是砍人，一个优秀的人自然可以找到好的项目发挥能量。这个应该和国企裁人是两码事，不应该上升到个人感情。
砍掉以后，focus
做事方法不重要，只要能够保证focus，“怎么做”可能取决于不同的vision，比如乔布斯做pc和盖茨做pc的套路就是两种，但都是成功的。因为二者的vision从开始就不一样，乔布斯想让所有人都有酷的，方便的电子设备，让科技走向大众消费领域，然后才是技术平台/生态圈；而盖茨就想让pc用起来爽，而且可以有很多应用，然后才是酷的，好玩的，炫的。基本可以说是帅哥和宅男的路数。
2. 捡西瓜而不是芝麻
虽说一看到这个标题我就很自然的冒出一句：“哪里有那么多西瓜啊！”
其实这个观点和“不做事”类似 – focus在有潜力/重要的产品上，但说回来，想要找到有潜力的点并能制造出壁垒避免被腾讯模仿，然后成功突围，在现时的中国还是有点难度。
壁垒是什么 – 先进的工具/管理理念，或者应该还有一个“牛逼的团队”
总的来说，从促进创新的角度来说，“边吃芝麻，边找西瓜”还是应该鼓励的。
3. 中国的工程师都是4流5流
吴军博士对工程师的定义很宽泛，本田宗一郎是一流工程师，Linus是二流偏一流工程师。。。我等鼠辈真是汗颜，距3流应该还是有一定距离的。三流的定义是可以定义产品并能带领团队开发完成。这样的在国内还是有一些的。不知道马哥是几流的？
其实到大可不必纠结自己倒是几流，认识到差距就是了。差距无非几个：1.耐性 2.表达 3.不畏惧权威（这个是我加的）
耐性在中国是一个很大的问题，真正能够耐着性子坚持的软件工程师不多，改善也没有多少。
美国的教育从小注重表达，无论是书面还是口头。这个和教育体系也有关系。
4. 未来的行业格局总是有历史可以参照的
每一波“浪潮”都必备的几种元素：
冤大头 – 最早的创意，先烈
主角 – 真正把握机会并垄断行业数年
千年老二 – 紧跟主角，无法撼动主角的位置，但依然可以活的不错
转型后居上者 – 从其他行业跳过来，通过不同的扩张手段站得一席之地（促进了不同行业间的互相换血）
小配角 – 模仿者，跟风者，企图通过微创新撼动主角地位的，
期待下一期！

面向对象和是否使用充血模型，是两个概念，不存在冲突。
如果使用充血模型，你的代码读起来就好像：今天他来了，然后他死了。 – he.goto(Place,TrafficTool); he.died(DeadReason);
而贫血模型的话，读起来就像是：一辆大巴载着他来了，然后死神带走了他。 – bus.taketo(He,Place); death.takeaway(He);
“他”就是模型，在整个编程模型中怎么理解他至关重要，否则在开发团队里就存在混用的情况。用哪种模型完全取决于个人喜好。
一般充血模型比较适合逻辑不是很复杂，比如大多数都是单表，不存在复杂的关联的情况。贫血模型的使用范围比较广，用着也简单，但代码看起来多，而且读起来吞吞吐吐。毕竟充血模型需要在扩展时非常清楚合理地把行为定义到正确的模型上。

今天听了york这位不老哥分享不老歌的点点滴滴，博客真的到了“尾”了吗？真的萎了吗？
觉得应该不是吧，也许这个时候才是博客本来的样子。

今天和同事讨论代码测试覆盖率时候想到一个问题 – “覆盖率到底多少时候才合理？”
其实没有简单的答案。比较赞同这篇文章作者的观点。
极端情况下，如果行覆盖率达到100%，那意味着分支覆盖率/路径覆盖率都达到了100%了。
但事实上，只要行覆盖率没达到100%，你永远不知道分支/路径覆盖率达到多少了。但至少可以通过对代码复杂度（分支密度）估计这两个比例。
二者的关系应该是这样的：

所以，最简单的答案：代码覆盖率不可能保证不出bug，也无法作为衡量生产力的指标。覆盖率尽可能保持在80%，才可能保证一定比例的分支覆盖率。举个简单的例子：你创造了一片森林，用户每天从里面进出，森林里的路如迷宫一般复杂，那就有50%的路是我们没有检查过，但用户天天都在经过的。

这里主要说移动app，其他类型的app也类似。不同的只是分发渠道稍有不同。

（图画的丑了点）
横轴代表时间，纵轴代表用户下载量/使用量
在发布初期用户数增长比较快，这取决于一些推广/营销/口碑传播，短期内可以把用户量推的比较高。但到达顶点后会下降，一些不感兴趣的用户会弃用或选择其他替代产品，但后续长期的增长则完全取决于产品本身是否真的能解决用户的问题。
每次产品的发布都会经历这样的过程，有尝鲜的人，用户量的小爆发，之后是冷静期，最后才是那些真正的用户。没有听说过一个产品只发布一次就是持续的获得用户，都要不断的改进，不断地经历这样的过程。在正确的阶段做正确的事情。

说实话，自己到现在还没有捞到ifttt的邀请，也没兴趣使用国内的快速山寨产品。
ifttt提供的服务，程序员最容易理解 – if xxx then xxx，对于一个程序员来说 if then 包含了所有的可能。
ifttt的几个特性：
1. 事件驱动
互联网形形色色的应用提供了用户监控各种事件的可能，不仅仅是博客收到某些人的留言这样的事件，甚至上海/北京/西藏同时下雨这样的事件。而事件本身其实又是另一事件的结果。
2. 指令互联网
当各种各样的智能设备接入互联网后，ifttt提供的服务可以让普通人更简单的”编程“。其实编程还不就是一堆ifthen吗？随着这种智能化需求的增加，也许有人还能靠编写各种指令来赚钱。规则和模式其实也是一大堆的ifthen
3. 集成/自动化
集成各种资源到这条”总线“变为可能，集成商需要做的是拿来各种应用接口，然后适配到这条”总线“上，供各种各样的用户使用（自助集成）。很多工作都可以实现信息的自动化流转。
以上纯属yy，希望国内的模仿哥不要仅仅把这个概念作为同步微博的东东。

ArrayList用到底, 其他选择 LinkedList, set, treeset,stack 关键是你要解决什么问题
一直以来, 在没有什么特殊情况下, 只要是元素数量不确定, 必然会用ArrayList. 除了增加了变长的特性外, ArrayList本质上就是个数组.
因此在创建ArrayList时应对其中要存储的对象数量有个估计, 否则经常性的扩容操作和remove带来的下标移位操作会影响程序的性能.
如果需要经常性的删除, 可以考虑hashset. 当然hashset不支持随机访问, 只能通过遍历.所以要根据需求来决定.
Linked***和其他集合的区别基本就是底层实现用链表和数组的区别. 链表和数组的区别请自行翻阅课本.

HashMap不指定size
由于HashMap的实现也是基于数组进行散列, 所以同样存在扩容时的性能问题. 所以尽量要指定合理的大小和factor

鄙视(膜拜)数组
最原始意味着最好或最坏, 每个人的看法都不一样. 数组的局限在于它是定长且只能是一种类型(java中).(当然你可以声明Object数组然后放任何东西, 但相信我, 你很少需要这么做)
通过下标访问数组元素是最快的
如果是频繁的数据访问, 计算(比如位图处理). 建议还是用数组, 最简单最纯粹也最高效.

随意使用concurrent
当发现HashMap存在多线程修改的情况时, 会立刻Map m = Collections.synchronizedMap(new HashMap(…));
实际上很多时候应该在集合操作以外保证并发的情况, 当然这里再加上一道也更稳妥,但能不用就不用
小心集合类的垃圾回收陷阱
集合对象如果没有设置为null的时候, 其中所有的对象即便设置为null都是无法被回收的, 因为集合仍然有该对象的引用.
所以当使用集合对象时 要记得集合中对象的生命周期, 以免造成泄漏.

参考:
深入Java集合学习系列：ArrayList的实现原理-http://zhangshixi.javaeye.com/blog/674856
深入Java集合学习系列：LinkedHashMap的实现原理-http://zhangshixi.javaeye.com/blog/673789
深入Java集合学习系列：LinkedHashSet的实现原理-http://zhangshixi.javaeye.com/blog/673319
深入Java集合学习系列：HashSet的实现原理-http://zhangshixi.javaeye.com/blog/673143
深入Java集合学习系列：HashMap的实现原理-http://zhangshixi.javaeye.com/blog/672697

sudo: sorry, you must have a tty to run sudo
由于ec2上所有涉及到root权限的操作都要sudo. 所以如果远程操作会报错. 我是使用ant的sshexec在本地操作.sudo时就会报这个错.
通过google找到这个:vi /etc/sudoers (最好用visudo命令)注释掉 Default requiretty 一行#Default requiretty
意思就是sudo默认需要tty(终端)。注释掉就不需要了.

 
在我目前接触到的开发中, 领域对象的状态通常都会对应到数据库中的某个字段(比如status,state). 如果状态不复杂倒也没什么.无非就是2,3个字段. 但是当状态机变得越来越复杂时(这种情况经常发生), 状态维护及已有数据状态一致性就受到挑战了.怎么解决这些问题, 通常也只能通过case by case的情况,遇到就改或修正数据. 这种修改如果是对整体系统有一个完整的印象的程序员还可以,否则稍有不慎就是一个潜在的风险点.
以前觉得应该在建模时就把状态跃迁模型进去,可是计划总是赶不上变化,总是会出现概念模型的变更和实际代码变更有出入的时候,要是没有时间去保持一致,最终又是混乱,当然,可以通过持续的沟通来解决.但似乎总是在”repeat yourself”.
目前想到的一种解决办法, 建模时还是定义状态机,通过状态机来生成配套的”对象状态跃迁校验代码”.在持久化时保证对象跃迁是符合定义. 应该可以解决问题.
关于一些实现细节:
1. 模型转化为状态机对象(领域对象, 当前状态机版本, 状态字段, 跃迁定义,持久化可以是一个xml文件)
2. 定义状态机验证接口, 配置方式
3. 运行时调用验证