易栈网-膘叔

不是说真的没用。但是真有可能，以前我的显示器就是22寸的，那时候外面都还是19寸，我用的很爽。屏幕大，用的爽。。。

当然我现在也希望有大屏幕的，但好象不太现实了。我当然希望有一台iMAC，一台17的mbp，两台一起用。但好象有点不太现实。光这两样东西，就要将近4W了。但真正算起来，这些其实也并没有多少钱。相对于一名开发人员的薪水来说。无非就是挤挤乳沟就有了。但为什么很多公司就是不愿意投入这些呢？不明白。真的不明白，好象越是把硬件搞的越便宜就越开心。

----以下是内容，来自：http://news.cnblogs.com/n/144016/
英文原文：Why Quit? Because They Have Bigger Monitors

　　好的技术人员向往具有很强的企业技术文化氛围的工作场所。但如何你能从外部看清一个企业的技术文化状态？这里要讲的是我使用的两个简单而好用的参考指标。

　　首先我要讲讲“企业技术文化”这个词指的是什么。它是指技术人员在一个企业内受重视的程度和重要性。它能从一些事情上体现出来：

• 公司里的决策是如何制定出来的？在一个具有很好的技术文化的公司里，技术人员参与要做什么、何时做、由谁来做等决策制定。并不是说有最终拍板权，而是有真正的发言权。
• 对开发软件这个工种是否尊重？开发软件是一种创造性的工作，这种工作需要有合适的时间和合适的地点。有些项目很难预测出究竟要多久才能开发出来，而公司能认可这种情况。
• 基础设施。当需要把精力放到非软件特征功能方面的事情上时，明白事理的人(技术人员，经理)需要花多少的口舌才能让老板知道这些工作的重要性？这通常是指一些运行时系统里的工作(比如扩充消息队列容量)或后勤服务工作(例如编译系统或版本控制工作)。

　　不幸的是，想通过一次交谈咨询就把这种底细都摸清是不现实的，除非你在这个公司内部有受信任、知道内情的线人。

　　他们的显示器有多大？

　　发生在我的前一个公司里的故事。我当时是技术经理，试图想挽留一个人才。团队里有个程序员辞职要去一个很小的但很新潮的公司。下面是我跟他离职前的谈话：

我: 为什么要走？

他: 因为他们的显示器很大。

我: (怀疑) 开什么玩笑？我们也可以给你配个大显示器。

他: 并不只是我——每个人都需要大显示器。

我: 这有那么重要吗？

他: 这反映了公司如何看待我的时间的价值。公司需要决定的是，多花一些钱买个大显示器让更多的像素映入我的视网膜是否值得。

　　现在我明白了，他说的一点没错。重视员工的公司会认为设备上的额外开销相比起提高员工的工作效率(和提升他们的幸福感)来说，后者更重要。让最好的程序员使用最好的开发工具来工作。大个儿的显示器是一个非常醒目的判断指标。

　　员工是否可以选择他们自己的邮件地址？

　　非技术人员很多时候并不认为邮件地址有多么的重要。可它是你网上的身份证。严格的邮件地址命名规范(姓的全拼加名的缩写，或更糟糕的名的缩写加 姓的全拼)反映出公司重视所谓一致性超过对员工的心情的关心。更糟糕的是，这种规定非常直白的让员工们感觉到自己被当成了“齿轮”或“人力资源”，而不是 一个了不起的个人。

　　(旁白: 让我们远离“人力资源”这个词儿。太难听了。)

　　这一点对我个人而言格外重要，因为我有一个很独特的名。如果你不允许我的邮件地址为sef@company.com ，那你在我的印象里会大打折扣。不仅如此，冗长的邮件地址名让人产生错觉，就好象是个邮件列表地址，但里面只有一个成员，可以忽略不计。它很重要，它是你 shell 环境的提示符；它很重要，它是whoami命令的返回值。

　　最后一句话：我并不是在谴责你们这些不辞辛劳的搞 IT 的男孩和女孩们。你们让很重要的东西保持正常运转，但还不得不被迫遵守这些强加的规则。相反，我针对的是这些糟糕的制度(通常是根植于糟糕的企业文化 中)，是它们使你们处于糟糕的境地。如果你身处这样的一个公司里，那跪下来吧，祈求阳光的降临。

Yiiredis是Yii的一个插件。用来方便我们对redis进行操作。封装了一些常用的list,hash之类的操作，对于Cache也做了一个封装，但在方便之余，问题也还是不少。比如说，我们要对数据sort，取出平均值，取出最大值之类的。默认的方法就不能用了。虽然yiiredis的类用了Array的interface，但利用php的操作，总归不如redis自身的操作。

一些参考资料上就写的比较详细：

典型的比如那些在线游戏的排行榜，比如一个Facebook的游戏，根据得分你通常想要：

-列出前100名高分选手

-列出某用户当前的全球排名

这些操作对于Redis来说小菜一碟，即使你有几百万个用户，每分钟都会有几百万个新的得分。

模式是这样的，每次获得新得分时，我们用这样的代码

1. ZADD leaderboard <score> <username> 

你可能用userID来取代username，这取决于你是怎么设计的。

得到前100名高分用户很简单：ZREVRANGE leaderboard 0 99。

用户的全球排名也相似，只需要：ZRANK leaderboard <username>。

看上去也比较方便，不过我没有仔细看究竟是因为phpredis的实现有问题还是yiiredis的问题。等晚上睡不着的时候看看伦家的源码先

今天又遇到了这个问题，以前其实是知道的。IE下的cookie长度和firefox下不一样。GET的长度也不样。
但我在记忆中一直是当成4096来处理的。看来我脑子里想的更多的都是firefox或者chrome，今天遇到某些信息不能显示的时候，又想起这个问题。才发现：
原文：http://blog.csdn.net/tuwen/article/details/5257154

看见很多朋友讨论浏览器最大URL长度限制的问题。其实实际中URL长度限制是由2方面决定的。1 客户浏览器 2 接受服务请求的服务器端的设置。对于大多数用户来说，他们使用的浏览器是IE浏览器，IE的最大URL长度限制是2083字节，而实际可以使用的最大长度 为2048字节。

--------------------
关于cookie，可以看一下：
Cookie常识
“同名Cookie”的分析
cookie，又见cookie

这是一个流程图，来自于禅道，http://www.zentao.net/help-read-79236.html
可以在自己的项目中做借鉴啊

在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。如果您现在的团队是采用敏捷开发的话，那么可以对应到 product owner, scrum master和team(dev and tester)。这几种角色之间紧紧围绕产品的需求展开协作，取得成果。禅道核心的管理流程全图如下所示：

其实以前公司有流程图，但这一张图相对会比较完善一点

又到了一周回顾的时候了。本周确实没有做过多的事情。自己给自己加加压了
1、看了一下postgreSQL。准备用作mysql的补充。其实也考虑过用其它数据库做补充，比如mangoDB之类的。由于目前已经采用了redis。所以对于mongoDB的需求就不是那么明显了。
不过redis和mongoDB还是有区别的。但只有一台机器的话。redis分配了不少内存的情况下，再用mongo，内存就吃紧了

2、本周针对系统中原来的缓存功能做了清理，发现了一系列的问题，调整了一下。这确实是由于以前的功能单一而造成的原因

3、对于数据抓取，先作分词再做匹配。当匹配次数小于总次数的1/4时，认为原文是不匹配的。这个功能对于采用readability功能的抓取还是相对有点效果的

4、对于宽度固定的图片，原来在做PHP缩图的时候，保持宽高比的情况，现在做了调整，基于宽度进行调整（当然，这仅能用在宽度是指定的情况下。不是适合所有情况。当然对于图片过小的情况，也先作了放大处理。避免出现小图片）

5、nginx的php-fpm超时时间过短，导致上传大文件就会有问题，比如视频这一块的上传，就好纠结啊。尝试用cgi的方式上传，还没有折腾。

6、下周准备对于现有系统的API进行调整，业务增长的同事，原有架构需求也发生变化了。毕竟在最初写程序的时候不可能会考虑到所有会发生的情况，但事实上，这些业务正在逐步变化，没辙的情况下，只能做调整。否则，以后会更痛苦