只会用火车头，说明可能有几点没有掌握好。
1.数据库读写操作
2.编写基础的逻辑代码，循环，判断等等

但是至少这些是了解的。
1.html 的结构和显示原理
2.基础的服务器搭建
3.正则表达式

以上的五点都了解，就可以做到用 python 写采集器了。
所以除了看 python 的理论书籍之外，再增加数据库操作的学习就可以做到写一个阻塞的单线程采集器来替换火车头了。
学习阶段无非就是这几个。
1.学会用 python 抓取网页信息， requests 之类的库很方便就可以抓取到网页内容。
2.学会用 python 解析网页信息，可以用正则表达式扫描，也可以用 lxml 之类的将 html 解析成序列化的结构数据。
3.学会用 python 读写数据库， pymysql 之类的。达到第三阶段就可以实现用 python 写一个可以替换火车头的采集器了。
4.学习任意一个 python 的爬虫框架如 scrapy ，把 1 、 2 、 3 阶段的操作都放到框架里面，可以方便做采集任务的管理。

还是有人没有仔细看 lostsnow 给的链接啊。
那个链接把原理说得挺清楚了，在默认配置下，可以让 PHP 解释器执行后缀为图片类型或者其它任意类型的文件。
所以攻击原理就是把 PHP 攻击代码以图片文件的形式传到服务器上面再构造执行请求，就可以执行任意 PHP 代码。能执行代码的情况下，再生成什么文件都很正常。

所以只要有上传图片的接口可以用，很可能是通过图片执行漏洞去创建的 PHP 文件。

location ~ \.php {
fastcgi_index index.php;
#安全检查
if ($request_filename ~* (.*)\.php) {
set $phpFile $1;
}
if (!-e $phpFile.php) {
return 403;
}

fastcgi_pass 127.0.0.1:9000;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
}

我们项目的坑里是这么解决这个漏洞的。
在 php 的执行检查里面加上类型检查。
#安全检查
if ($request_filename ~* (.*)\.php) {
set $phpFile $1;
}
if (!-e $phpFile.php) {
return 403;
}
这样可以保证非 php 文件不会被执行。

做技术的危机感要很强，如果岗位是自己能力范围内的，工作内容上没有学习的空间，公司业务也没有增长去支撑经验增长的空间，是很危险的。
所以可以接受接触新的领域和学习新的东西。但是不能接受的是学习的这些东西只用到很简单的基础知识，并且是重复性的工作，对于跨岗位，但无法增加经验或能力提升上有帮助的事情，是绝对抵触的。
比如做个前端，让去写后端的参数格式化处理。
做个后端，让去服务端增加一个新网站的配置。
做个运维，让去改个界面，改个专题页的前端。
这种都是跨领域的事情，可以去学怎么做，但是绝对不能接受学会之后只能做简单的工作，占用了工作时间却没有经验和能力的提升。

像楼主举的例子，如果说是，前端走了，你做后端的，这块业务和交互都一起做一下。从业务分析、设计、交互效果到整个界面都交给后端做，那提升空间是比较大的，这个问题不大。只要工期给够无所谓。

但是，如果说是，前端走了人不够，这个设计稿你帮忙切切图，方便前端填充 html 模板。或者是帮忙改个模板的 div 位置。这种事情前端都会嫌毫无技术含量的活。绝对是拒绝的。

看来每个人对感谢的理解不一样。在这个社区，每个人进行操作都是要消耗铜币的，这样的情况下，每个人对所发表的内容都付出了自己的思考时间和铜币。
如果觉得这个人的操作发表的主题或者回复有价值，自己从中受益了，感谢一下给予 10 个铜币做为他输出内容的补偿，是很合理的内容激励方式呀。
如果输出有质量的内容没有激励，输出低质量内容没有惩罚，社区内容怎么进行良性循环。

我是调休了，国庆到公司干活，国庆后再出去疯七天。

如果要真实姓名，去爬知乎的数据，过滤掉 100 赞以上的用户。或者爬校内的用户。
只是要网名，懒的话天涯社工库，各种中英文名都有。

这种项目业务都没有梳理清楚，需求做得一团糟的，还是不要写总完工的工期为好，只要学 xx 需求和业务什么时候可以交付，因为需求不停提，很可能还是改变了原有业务的需求，根本没有头。

如果是有经验的项目经理处理，不会马上开工，而是先问清楚业务流程，做一个需求说明给负责人审核。确定需求可以满足业务了才会去做功能说明、交付计划、验收方案和付款方案，不要嫌流程繁琐，这是为了保证双方后期不会撕逼。

签订了需求之后，再有新增的业务全部扔下一期的去评估再做交付计划。

这种活也不是一个程序员就能搞定的，最好是一群人去分工，就算是全栈能力爆表，搞得定开发里面的前后端代码，还有非开发技能的测试需求分析交付的使用培训，这么多领域的工作，在切换工作内容的时候是要花时间预热的，切来切去工作效率反而很差。

这种给传统企业做 ERP 的事情有专门的雇佣军，就是一个经理入职，直接把业务理顺之后做一个方案，申请好需要的钱和完工的奖金，就开工，找人验收管项目全都是这个经理负责，一般为期一年，做的时候会有很多雇佣军写代码，项目一旦上线，写代码的就撤场，剩下经理留下来做三个月的线上使用的 bug 修复和招聘维护人员并培训，做完三个月经理拿完奖金也闪人。去下一家公司继续开新坑。这种形式的做法需求比普通外包公司做得更细致，在传统行业的圈子里口碑更好一些。所以钱还真的不少。

对于要求稳定性的服务器来说，用得起硬件解决的问题尽量用硬件解决。
软件在性能和稳定性上面，和硬件解决方案是有量级的差距的。
硬件架构上面，肯定是要根据需求进行取舍的，又要便宜又要性能和安全性最好是不可能的。

硬盘方案来说，我只说 raid 的事情。单盘不要用 raid ，不管从安全性还是读写效率上面的提升都很有限，效率还不如单盘带日志的 ext4 。做 raid 最好 4 个盘起步。
如果上面要跑虚拟机，最好算一下虚拟机系统正常运行所需的 IOPS ，再选择 raid 方案，磁盘读写速度不够，内存 cpu 配置再高也会卡成狗。
如果是存数据库文件，为了安全最好选 raid10 方案。
如果是给美工用来保存美术文件进行协作读取速度要求高一些，安全性可以降低的， raid5 方案比较合适。 raid6 也可以，冗余更好一些，不过要算两个校验，写入就要牺牲一下了。

家用机配置也带不动多少虚拟机的，主板的内存通道是主要瓶颈。不是内存大就一定能用得上，总线的带宽决定了拖得动几个虚拟机。

如果你不懂服务器的硬件性能应该如何提升，就买商用的塔式服务器放公司。
我就说几点我知道的性能提升选择，内存一定要多通道，通道越多主线总带宽越大，读写效率越高。
服务器的 CPU 没必要太高。
如果要提高磁盘读写性能，一定要买 raid 卡，软 raid 太耗 CPU ，瓶颈全在计算校验上面了。每种 raid 的读写效率和安全性是不一样的，自己根据需求做权衡。
磁盘一定要同系列同系列同系列，不然做什么 raid 。

利用迅雷从多个源下载数据但校验不严谨的事情进行木马代码污染下载文件不是新鲜的技术了，这是迅雷一直以来的坑，好多年前就有这个问题，直接伪造一个感染木马的源发布到迅雷上。所有数据校验都可以构造给迅雷的服务器，这种数据流迅雷也很难验真。

好想听 zhuizhui 内部人员分享一下， zhuizhui 在后端选择上从 python 到 php 到 Ruby 的变迁上都考虑了什么，解决了什么问题。

双向选择，这种员工如果对团队士气造成负面影响了，公司认为他的工资配不上贡献，应该从制度和管理上面做出一点限制，比如输出的代码质量评估，月度季度的奖金激励。去抹平这些工作积极性或者工作质量差异给团队造成的负面影响。只要公司还认为他的贡献配得上工资，不想开除，那就通过制度和管理去调控。而不是看着他给公司带来负面影响。

这种事情是管理人员的锅，应该让管理人员去处理，如果只是同级同事，最多就是出于朋友关系提醒一下，说什么批评或者私下评论他的作为是否得当，其实都是不对的，反而如果管理人员不作为，那该考虑一下这样的公司管理不到位的情况下自己还能从中获得什么利益，经验还是工资，评估一下自己是不是要找下家了。

因为北京的房子升值速度肯定要比成都大。同样 100w 首付买房，过五年，成都不会比北京涨得多。到时候北京房子一卖，可以置换到更多现金。

那么算，就算两个发起人各占有 8%不可稀释的股权，其实可以释放的股权只有 34%，空间其实也不大，最简单的例子，如果又招人进来分走发起人的股权或者有投资，发起人的股权低于 50%以后产品方向有问题了，你们几个 8%的人联合反对发起人，你们反而是报团的大股东，发起人有可能失去对产品方向的控制。

各人经济情况不一样，一定要股份比例一致，那么需要发放资金用于个人生活费的，可以签借条，公司未来有分红了，从分红里面扣。如果公司破产了，这笔钱算公司的借出款项，追回的借款用于清偿完公司债务之后，剩余的借款按股份比例转到股东身上。当然这个我只是一说，毕竟如果经济条件本来就差一些的情况下，干得越久负债越多，带来的压力反而比一开始就出资直接负债的压力更大。

我觉得既然风险承担能力不一样，不如按贡献分股权，股份比例不要一致，在行权的时候就按贡献从期权池里面购买期权，要领工资的就适当减少行权比例，这样会更好一些，按贡献分股权，而不是一开始就分好。毕竟承担的风险比例不一样，每个人的风险承担能力也不一样，如果这方面有分歧，不如直接在一开始摊开了说，个人在不领工资的情况下，能承受几年？这样大家也都清楚，团队在什么情况下会面临解散的风险，到时候真出问题了，要散伙还是招人顶岗继续撑，都可以好聚好散。

创业本来就是一个高风险的事情，产品要几个月能推出，几年能盈利，其实都是未知的。一个公司从产品成型到盈利这个摸索的过程，要付出很多时间成本和资金去试错的，团队的资金能撑多久很重要。不领工资的模式，公司必须快速打开局面，开始盈利或者业务需求增长很快。否则经济条件不好的人，很容易因为长时间打不开局面被经济问题分散精力，其实也不利于团队士气。

以上只是个人看法。

如果公司直接盈利，不考虑融资和追加投资的事情，那么直接分配股权，且技术人员股权不稀释，没有问题，毕竟直接赚钱分了。
如果不是直接盈利，后续可能要扩招人员、融资等等，那么有 50%不可稀释的股权不在创始人手上会是一个很麻烦的事情，因为后来的扩招人员和融资都没有空间了。

我觉得有一个方案很不错。
创业必然是有资金、技术和时间成本的。所以要有一个大家认同的成本公式和退出机制。比如 2 年做不成就散伙。
1.总资金成本，项目支出总费用。这笔费用是各个人的出资决定。
2.按个人技术当前的市值工资乘以一个大家认同的风险系数，比如出去找工作月薪能有 2w 的工资，再乘以一个大家认同的风险系数，比如 1.2,那么一年的技术成本等额也有 28w 。
这么总计下来，得到一个总的资金成本。在这个统计结果上面做股权分配会更好。按技术成本把分配的股权放到期权池。
行权的份额则按照工资成本进行计算，比如自己要拿 50%的工资，那么满一年就可以行权购买分配的股权的 50%。
每一年按照公司实际情况计算估值和风险系数，再签新的行权份额。

这样盈利的分红和引入融资都有空间操作。如果创始人直接就只有 50%的份额，其他人 50%且不可稀释，稀释股份都是从创始人那边稀释的，一轮融资就把创始人的股份稀释到 50%以下了，后面创始人必然会出现话语权不足的尴尬场面。

付费 github ，或者 oschina 托管都可以。 git 本身就是分布式的代码托管，服务器崩了也可以从本地记录找回来。
小团队，项目也不是重要到不能泄密的程度，托管给专门处理代码托管的商业公司最好。因为这个时候的人力成本太高。
搭建私有 git 服务，必然是要耗费自己团队人员的精力去处理服务器的问题的。假设有人愿意承担这个 SA 的职责，他要花多长时间去处理这些 git 部署和维护的事情？假设一年只花一周的时间可以达到商业付费方案的安全级别和服务内容，那他一周的工资够不够你们付费购买相应的 git 托管服务？
有多大的风险会出现不熟练导致维护私有 git 的部署维护出错？此外租用的 vps 容灾方面的可靠性和商业付费的容灾方案比起来，哪个更可靠？

我在 godaddy 注册的两年多了 没有被回收 也没有收到 godaddy 的回收通知。