这两天把收藏了好久的文章，还有收藏夹中的链接做了整理。现在我的做法是文章的收藏一般都会放到麦库里面，我麦库的公开地址是http://note.sdo.com/u/dapeng 现在公开地址的访问还有些问题，访问子栏目需要输入密码，可我没有设置密码，麦库的客服说只能到下一周解决了，等待解决吧！另外是对一些链接的管理办法是，建立收藏网站，使用新浪的SEA提供的typecho搭建了收藏的网站http://zptools.sinaapp.com 收藏网站是模仿阅微草堂的想法建的，部分的链接也是来源那里的。使用新浪的SEA来搭建是为了服务器的稳定，毕竟我自己的用的服务器在国外，说不定哪天给和谐了，不放心啊!在做网站收藏整理的时候，发现国内优秀的JAVA网站没多少，网站的收藏还需要继续的更新整理，才能符合自己的需要。方向是java相关、企业服务SOA、数据库、linux、前端设计、项目管理、互联网等等吧！ 选择了一款比较简单的主题，对主题也做了修改，主要是增加css3的使用，使用了css3的圆角、还有阴影。在chrome、ie9、opera、firefox5测试都通过了，很可惜firefox3没有通过，当然ie6是不会通过了。还增加使用了一个jquery的插件scrolltotop，当页面向下滚动的时候，就会出现返回上面标记。修改好了，也就把博客主题也替换一样了，统一风格吧！现在瞧瞧两个站点吧！http://zptools.sinaapp.com http://dapeng.me
在新浪微博上面看到，铁道调度系统现BUG，已拘留两无证程序员，很震惊，再怎么着也不能拿我们码农开脱啊！当时也做了评论，尔后，也有些怀疑，太不可思议了，做了下搜索，图是张假图，猜测是经过某位愤怒的码农的PS。这位同仁有些过分了啊！视频原址：http://tv.sohu.com/20110725/n314420232.shtml截图取自视频00:08秒 发现真相原帖地址：http://taizhou.19lou.com/forum-1629-thread-2022831311584000078-1-1.html
Tech2IPO:商业计划有两个主要的目的，向有意向的投资者介绍你的公司，以及对于在处于征信调查阶段，只看文档的投资者来说，商业计划能帮助他们了解公司的其他信息。 我们不建议把商业计划作为给风投们看的第一份文档，商业计划应该是一个概要总结和邮件首页里放的东西。但是也有人会要求在见面之前看看这份东西，还有一些人会把商业计划作为和你开始合作的第一份接触式文档，尤其是和你赞助商的合作伙伴，所以基于这些原因，商业计划应该是介绍性质的文件。因此这就意味着要把概要总结性的东西放在最前面，而且一定要注意到，这份概要是可以独立阅读，并且能够让用户在读完后，对你的整个商业计划有一个非常高的理解，并且不需要去阅读其他部分的商业计划。说到这份计划的正文。首先，结构要好。要有清晰的逻辑结构，让人一口气读完。同时这样的逻辑也要让读者一下能够被吸引住，就像销售总监的人物传记或者财务分析预测一样。然后，内容鲜明。在产品，市场，团队，竞争对手和财务预测这些部分要分段说明。另外，根据以后独立公司的想设立的部门以及特色，你可以写写市场战略，进入壁垒，单位经济情况，退出策略，公司历史，资本使用，融资历史等等一切能够让公司鹤立鸡群的东西。但是不要写得过于冗长和夸大，整个文档长度保持在15页足有。如果有意向的投资者有足够的兴趣的话，他们会想你索要更多的信息。上本文由Tech2IPO作者Jason编译自互联网。如果您对Tech2IPO其他内容也感兴趣，请通过RSS订阅我们，或者在微博上关注我们的最新动态商业计划有两个主要的目的，向有意向的投资者介绍你的公司，以及对于在处于征信调查阶段，只看文档的投资者来说，商业计划能帮助他们了解公司的其他信息。
Android IT:分享一些程序员个人修养的行为表现，希望程序员们能够引以为戒，更快的成长！1) 情绪化的思维如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你 经常可以看到很多很糟糕的程序会使用下面的这些语句：我的程序不可能有这种问题。Java就是shit。我最恨的就是使用UML做设计。需求怎么老在变，没办干了。受不了这些人，他们到底懂不懂啊。这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误 码率的判断和决定直接决定了你的人生。2) 怀疑别人糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用 STL类：map，当他发现这样放入字符串后却取不出来，觉得那是STL库的BUG，然后自己写了一个map！我的天啊！某些时候，过早的下结论是一个很不好的习惯，任何事情都有其原因，只有知道了原因，你才能知道是谁的问题。一般来说，总是自己出的问题。3) 过多关注实现，陷入问题细节有些时候，当我们面对一个问题或是一个需求的时候，糟糕的程序员总是会马上去找一个解决方案或是实现，这是一个很不好的习惯。设计模式告诉我们， “喜欢接口，而不是实现”就是告诉我们，认清问题的本质和特性要比如何实现更重要。对于一个客户的问题来说，首先应该想到的是如何先让用户正常工作，如何恢复正在“流血”的系统，而不是把用户放在一边而去分析问题的原因和解决方 案。对于解决一个bug来说，重现bug，了解原来程序的意图是首先重要的事，而不是马上去修改代码，否则必然会引入更多的BUG。对于一个需求来说，我们需要了解的需求后面的商业背景，usecase和真实意图，而不是去讨论如何实现。只有了解了用户的真实意图，实际使用的方式和案例，你才能真正如果去做设计。糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。4) 使用并不熟悉的代码糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地 工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？5) 拼命工作而不是聪明的工作对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有 效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在 开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去 总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。6) 总是在等待、找借口以及抱怨当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当 然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的teamleader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完 美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting,leading instead of following.7) 滋生办公室政治有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的 话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。8 ) 说得多做得少糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子 呢？就是吹啊吹啊。另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提 出可行的解决方案。这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。9) 顽固当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就 是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单 的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一 片质疑声中，他不得不采用了我最先告诉他的那个方法。这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。10) 写“聪明”的代码他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码本应该简洁和易读，而他们喜欢在 代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了 展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他 某个单词的意思。呵呵。
linux和windows下的抓包分析linux下抓包分析1.使用root帐号对需要监听的端口进行抓包 tcpdump -X -s 0 -w ssh.cap port 222.将生成的ssh.cap下载到本地，使用Wireshark来打开ssh.cap分析具体内容 windows下抓包分析1.打开capture，选择interfaces2.选择需要监听的ip
人人网的开源框架paoding-rose(2) 上次写过rose，说到文档不全，其实不是文档不全，而是我没有细细看，文档还是写的很详细的，而且源码注释很规范，加上源码注释和文档，rose框架还是很容易的掌握的。 在安全性设计上面打算采用spring security来实现的，把spring security集成到系统用了几天的时间，这样系统就是spring + spring security + rose的设计了。 其中的遇到的问题是spring security 需要配置自己的过滤器，而在rose的系统中只需要配置一个过滤器，配置两个过滤器就出抛出已经有过滤器的异常，我把spring security的过滤器去掉了，只配置了一个rose的过滤器，再按照配置spring security的方式配置好了。在配置过程中，就是一个不断尝试，试着配出来的。 配置好了，就是项目启动不再出现异常情况，运行也不报错了。可预期的结果并不是我要的结果。我过滤的方式是通过url来控制权限的，spring security对正常的url是可以进行控制的，对pathinfo格式的url就不能做控制。这个问题纠结了好久，我还询问过开发rose框架的作者，他给我的解释是rose本身就是一个独立的context，它的parent是root context，这样说来，rose就和spring security是属于两个context了，当然不能控制了。 根据日志记录，这样的解释说不过去，从日志记录中，spring security对url都是做过滤的，首先是rose对url进行过滤，接着是spring security进行过滤。在看rose源码的时候，有这样的一段注释。“如果一个请求在Rose中没有找到合适的类来为他服务，Rose将把该请求移交给web容器的其他组件来处理。” 这样才能解释通道理，也可以和日志记录对应起来。rose先做了处理，无法处理的时候才交给其他容器做处理的。 我想尝试先让spring security先来处理，这样处理之后，spring security却不会请求交给rose来处理，这块尝试了好久，没有找到解决的办法，最终只跟踪到spring security中的一个异常对象，在rose处理了，就不会把异常抛出，这个也是spring security不能处理rose请求的原因的。结果是我解决不了，引入spring security就放弃了。 引入spring security我是想偷工的，没有偷成。反过来也想想，引入了新框架进来，就会增加系统的负担，我还是希望系统轻巧一点。 可安全性总是要做的，了解spring security的原理，同理写一个了。spring security是按照面向切面的思路，通过过滤器来实现的。rose的过滤器很好用，不仅可以设置过滤器，还可以设置局部和全局的过滤器，还可以设置过滤器的权重，满足什么时候，什么场景，采用什么过滤器。 我写的基本可以用起来，满足了我的基本要求了。现在也仅仅是满足需求，对一些漏洞还需要继续的修补。