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的美国人后来在其邮件中询问他 某个单词的意思。呵呵。
以后的IT路还很长（2） 想想自己好久没静下来思考下了，等反省好了，再睡吧！毕竟知道自己以后怎么做了，比起一晚上不睡觉，重要的多。 我一直想做个智慧的人，现在发现，自己连聪明也算不上，更是聪明反被聪明误，想想那些事情，我都不想见人了！ 想当初，一周前还说着不到南京，一周后，就屁颠屁颠的跑到南京了，之后，就是连续一个多月的加班，之前，哪里这样过啊！来南京两年多了，觉得最能放松下来的是，有次上线升级，我已经抗了几个通宵了，那天晚上，抗不住了，就趴着睡了，老大把我喊起来，让我把所有事情，交给同事帮同事帮我上线，让我回家睡觉，我立马收拾了下，给同事说了几句，回家就睡觉，那次，是我觉得最轻松的时候，现在想起来，都能感觉舒服好多。 现在，让我最怀疑我自己的是，两年前做的傻事了，当时竟然把自己封起来了，和谁也不联系了，目的只想看看自己努力了一年，一年以后的自己是个什么样，事实证明，我还是老样子，除了多知道了几句南京话，也没啥变化了，还有就是失去的东西。是不是做错了，目前看来，是错了，彻头彻尾的错了！ 我本来就是不想多说话的人，那次以后，说的话，更少了，而做我们行业的，做是我们的基础，要做好，更多的东西都是说出来的。我知道这样不好，也时常给自己提醒，可自己就这样慢慢，变的少说的多了，在团队里面，我说的是最少的，这也导致我最后在团队里面，属于孤立的地位，在做团队工作时，遇到最大的难题。也影响我个人的生活，已经和别人，不知道怎么沟通了。 我是个很阿Q的人，一直认为着，有问题是好事，不是什么坏事，有问题解决问题，人就是在解决问题中成长起来的，现在有矛盾也是好事，现在的矛盾多一些，以后的矛盾就能少一些，不是什么坏事。 也一直在安慰自己，等实际成熟了，等准备周全了，等什么事情做完了，等这一切都好了，什么都晚了，什么都就没有了。 现在我也慌了，不知道自己要什么，要做些什么，什么也不知道，对什么也没有信心，老是害怕，越害怕，越想逃避，真不想对面对这些烦人的事情。常常给自己说的，有困难，有问题，有矛盾，不是什么坏事，是好事，这样才好玩，太平了，就没意思了。另外一句，烦啊！烦不了了，烦不了，我不玩总行吧！爱咋咋地吧！ 最悲剧的是，玩，看不到希望，不玩，又看不到失望，伤不起啊！ 慌了，就去钓鱼，钓鱼其实也是种逃避，钓鱼完后，还得面对，是自己的事情，总得去解决，除非，不玩这个游戏了。 现在，事情按照计划去做，问题、矛盾一点点的解决，梦想，一点点的实现，如果没发成功，我也只好归结到天意如此，我也没辙了，我已经尽自己的最大努力了！
以后的IT路还很长（1）最近有两位兄弟同事离职了，蛮可惜了，在一个战壕一起一、两年了，人各有志嘛！希望他们发展更好些！目前的公司是个创业型的公司，公司从08年的50来个人，扩张到今年11年400多人，今年的目标是500人，扩张速度相当快，公司主要是做中国移动游戏这块的，也在扩展自己的业务和产品，但到底是要走什么样的路，看不清，公司内部也是跑马圈地。在公司里面，最苦的项目组是我们组和另外一个组，每周不停的上线、升级，修改bug，是谁都会奔溃的，我们组已经换了好几拨的人了。技术牛的、不牛的，能拼的、不能拼的，男的、女的，没小孩的、怀孕的、有小孩的，在项目中都出现过，一波接着一波。我入职后，离职的同事算上最近两位，一共4个。第一个离开是个小女孩，小小的一90后，特别能吃苦，我刚入职时，帮了我不少的忙，她的离职，对我有些影响，因为我还有同事，我们属于空降过来的，对老人都有些冲击，还有那段时间，问题的高发期，小女孩的压力不是一般的大啊！我想帮帮，有心力不足啊！最后，那段时间也挺过来了，压力太大了，当时我没有直面问题，我也跟在小女孩旁边，偶尔出出主意，压力我也算是有些体会，有些男娃真比不上她。最后，她就离职到了我们楼上的一家公司，现在偶尔和她聊天，工作也还是挺轻松，不用怎么的加班，也不用关系升级，比在公司时，笑的更多了。接着走的同事，是和我从上一个公司一块过来的，很聪明的一个小伙，当时要走，我很早就知道了，他走的时候，都挺担心的，他经历的事情还有些少，一边希望他能留下来，给他一些时间，整理整理自己的能力，感觉差不多了，再走，另外一方面，他现在走，也是好事，让他能多磨练磨练。他是走了，公司也是国内一家很不错的公司，就是加班多一些。现在，他工作，可没比在公司舒服些，呵呵！男人嘛！现在多一些压力是好事，不是什么坏事。之后，团队稳定大半年了，也就是最近，有两位同事接连离职了。这位同事离职，我得付一些责任，做了一些让人看着不舒服的事情，这个我道歉，另外一块，在他走后，就是我们团队中说的，谁接谁死的模块，现在，是由我来接的。另外一位同事的离职，是刚刚知道的，之前知道他还没有转正，就有些担心，刚过几天，他就离职了，有些吃惊啊！他也是和我从上一个公司过来的，过来是比我们晚了许多。他和我算是搭档，他做需求，我做研发，是想把事情的的确确做起来的。我很感谢这位兄弟的，也很感谢我们的老大的，没他们帮我，我那段艰难困惑的时间，真不知道怎么能过来。团队人员走的走，也在加入新的献血，总得把事情继续坚持下去。
5月6月牢骚一大把 5月过了就像把这个牢骚发发的，没找着机会，这次5月6月的牢骚一起发了。4月末项目中的短信发送出了问题，负责这块的哥们回家了，我跟了这块的问题，算是有人在处理，可也没处理个啥结果，心急啊，我也没个实质性的好办法。系统升级失败，回退到升级前的状态，还出问题，真是叫人无法理解，没法查啊！还是硬着头皮看代码，又不是这块的熟手，没办法改这个东西。最后为了过个安稳点的5.1，有了一个版本出来了，算是解决了正常使用，也遗留了一大块的问题，放到5.1后再处理了。5.1前的问题就这么过去了。原想是5.1休息休息，前两天我姐到武汉了，5.1就去了趟武汉，去那边了，没看见过太阳，我姐身体不太好，还带着小外甥，没出去转过哪里。回南京时，去火车站，半路公交车给坏了，下了一车人，还赶巧了，下车的那地方，就是黄鹤楼，进去一张门票是30还是60的，忘记了，没去，都6点多了吧！我还得找地方住呢，不然晚上要在雨下面待着了。5月份一上班，稀里糊涂的就去另外个项目做支援去了，当时没弄明白，事后才知道的，也不给人说清楚些。5月份基本都在这项目组里面，要给领导们做演示，加班加点的，没休息几天，休息了一次，还在搬家。今年的5月份，最倒霉了，啥倒霉事情还都赶到一起了。事情做完了，没落个是什么好，我认了，这真是我个人的问题。另外就是，演示的前一天中午，在领导要看系统的面前，电脑打不开了，最后的结论是硬盘坏了，项目代码都在我电脑上面，这个运气，真是赶上时间了啊！幸好代码曾经给一朋友发过一份，不然真就是完蛋了。硬盘坏了，这天灾，我也认了。后面接着还有，领导对我今年来的状况做了教育，今年来杂七杂八的事情，心一直静不下来，被教育是应该的。后面有的是，被别人在我后面说三道四了，o(︶︿︶)o 唉！这个我就有点伤心了，一个战壕里面都1年的兄弟了，不需要这样吧！说我做的不对的，我不介意，说一些乱扣帽子的，就不好了吧！这么久了，谁做什么，谁说什么，都知道，真不需要这样的。6月，我是打算好好干起来的，可就是没压住，事情还是有遗漏，这个遗漏啊，把这次升级弄的一团糟，o(︶︿︶)o 唉！现在也不知道咋办了，又乱起来了，比之前更加的乱。NND！！！！！
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的过滤器很好用，不仅可以设置过滤器，还可以设置局部和全局的过滤器，还可以设置过滤器的权重，满足什么时候，什么场景，采用什么过滤器。 我写的基本可以用起来，满足了我的基本要求了。现在也仅仅是满足需求，对一些漏洞还需要继续的修补。