有人说:
"有句还挺受欢迎的话是,程序员就是把咖啡变成代码的机器。随便问一个程序员什么时候效率最高,很有可能他们会说大多是深夜的时候(中文)。 有些早点,有些晚点。常见的是:在凌晨4点起床,赶在吵闹的一天开始前完成一些工作。另外一些喜欢在凌晨4点睡觉。这种做法的目的是避免干扰。但是你可以 锁上门啊,为什么夜晚这么特别呢?swizec 的博主认为可以归结为三件事:员工的时间表、疲惫的大脑和明亮的电脑屏幕。"
其实想想不完全是这样,白天的时候在单位各种各样的事情,都有可能会导致写代码的时候被打断,这种打断其实很影响写代码,思路一断,很可能半小时一小时都不会恢复。晚上没人,外面也很安静,虽然说真的是避免干扰,但其实晚上和清晨人的大脑好象很容易集中(所以我们小时候背书一般都在凌晨,当然也有深夜)。【传说,屙扁扁的时候人的记忆力是最好的,所以那个时候看书其实很容易记得牢,无科学依据,纯粹说说】。
果然有中文版的(上面斜体字中的中文版,我复制过来了,但不复制图,要看原文请移步:http://blog.jobbole.com/10797/)
XML/HTML代码
- 有句还挺受欢迎的话是,程序员就是把咖啡变成代码的机器。
-
- 果然,随便问一个程序员什么时候效率最高,很有可能他们会说大多是深夜的时候。有些早点,有些晚点。常见的是:在凌晨4点起床,赶在吵闹的一天开始前完成一些工作。另外一些喜欢在凌晨4点睡觉。这种做法的目的是避免干扰。但是你可以锁上门啊,为什么夜晚这么特别呢?
-
- 我认为可以归结为三件事:员工的时间表、疲惫的大脑和明亮的电脑屏幕。
-
- 员工的时间表
-
- Paul Graham在2009年写过关于员工的时间表的问题 —— 基本上,在世界上有两种类型的时间表。传统管理者的时间表是分散地切割成小时和一个个十分钟的方式绩效,通常是按一个小时的价值给你报酬。
-
- 另一种,叫做员工的时间表——针对我们这些程序员。工作于大型虚拟系统时,需要把所有涉及的事都记在脑子里——有人曾经比喻这就像用昂贵的水晶建造房子,一旦有人打扰,房子就一股脑塌落并碎成一片。
-
- 这就是为什么当有人打断程序员的思路时,他们那么恼火。
-
- 由于这种巨大的精力投入,使得我们无法简单地开始工作,直到我们能连续几小时不被分散注意力才行。刚在脑中构建了整个模型,结果半小时后就毁了可不值得。
-
- 事实上,跟很多员工交谈后你会发现,他们感觉根本不能在白天完成任何工作。接连不断地被打扰、关注重要的事物和回复邮件都不能让他们安心工作。所以他们选择在别人睡觉的深夜来完成大部分的工作。
-
- 疲惫的大脑
-
- 就算是程序员,晚上也应该睡觉。我们不是超人。也会感到白天更机敏。
-
- 那为什么我们要在大脑想睡觉的时候做最复杂的工作,而在大脑最敏锐和灵活的时候做简单的任务呢?
-
- 与巴尔默峰值类似,疲劳让我们更易集中精力,因为当你的大脑疲劳时,它就必须集中精力!没有多余的脑力让你不集中精力。(《“10倍效率”程序员/开发人员的习惯》第5点:集中精力)
-
- 我似乎在喝茶过多或不合适的时间喝能量饮料后完成的工作最少。这些让我很活跃,一会儿查看Twitter,一会儿看看Hacker News,我似乎一直在到处浏览。
-
- 你应该在想我能很好地工作——这么有精力,这么有脑力。但是相反,我一直在阻绊自己因为我不能集中精力超过两秒。
-
- 然而,当我微感疲倦时,我就能坐下来编码了。用有点疲劳的大脑,我能一小时又一小时地编码,甚至都不想查看Twitter或者FaceBook。就好像互联网不存在了。
-
- 我觉得这适用于大多数程序员。我们有太多的精力去完成80%的工作——面对现实吧,一个好的算法,需要用10倍的代码量来营造使用它的环境。即使你做的是最高级的机器学习(或者是其他的),很多工作也仅仅只是清理数据和将结果以友好的方式呈现出来。
-
- 当你的大脑并不是竭尽全力地工作时,它就会找其他的事做。疲劳使你愚钝,从而使你只能顾及手头上的工作。
-
- 明亮的电脑屏幕
-
- 这条非常简单。在夜晚一直盯着明亮的光源并且使你的睡眠周期延后。你直到凌晨3点才感到疲倦。然后中午11点起床,当夜晚来临时你并不感到疲劳,因为,呵呵,你中午11点才起床!
-
- 经过足够多的反复,本质上是把你带到了不同的时区。更有趣的是,它会保持相对稳定,一旦你进入凌晨3、4点睡觉的节奏中,你就会一直保持那样。
-
- 结语
-
- 综上所述,程序员晚上工作是因为没人强制规定你必须什么时候停止工作,这可以给你更轻松的方式,你的大脑不再一直寻找分心的事并且明亮的屏幕使你保持清醒。
原文链接:swizec.com 编译:伯乐在线 – 魏哲
文章的内容写的不错,所以转载一下。
原文:http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下:
XML/HTML代码
- 过去当运行一个大的web应用时候意味着运行一个大型的web服务器。因为你的应用吸引了大量的用户,你将不得不在你的服务器里增加更多的内存和处理器。
-
- 今天,’大型服务器’模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。这是一种更可行的方法,将使硬件成本降至最低。
-
- ‘更多小服务器’的优势超过过去的’大型服务器’模式体现在两个方面:
-
- 1. 如果服务器宕机,那么负载均衡系统将停止请求到宕机的服务器,转而分发负载到其他正常运行的服务器上。
- 2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。
-
- 所以,把握住这个机会:). 当然,代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。
-
- 这时你可能对自己说: ‘但是我怎么知道我正在使用负载均衡呢?’。最诚实的回答是,如果你正在问这个问题,那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况,当应用成长足够大的规模时,负载均衡就需要明确提出和设置了。然而,我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡,或者像下面描述的那样要自己来做。
-
- 在继续下面的内容之前,我要指出本文主要描述PHP的负载均衡。将来我可能会写有关数据负载均衡的文字,但是现在你必须等待。
-
- 注意,我一直提“web应用”而不是website,这是想区分’web应用’是那些复杂的站点往往涉及服务器端编程和数据库,而不是website那样只显示简单的静态内容。
- 1. PHP文件
-
- 第一个问题是,如果你有大量的小型服务器,你怎么把你的php文件上传到所有的服务器上?有如下的方法供你参考:
-
- 1. 分别上传所有的文件到每一个服务器 , 这种方法带来的问题是:想像一下你有20个服务器,那么上传过程中这将很容易导致错误,并且更新时极有可能导致不同服务器上有不同版本的文件。
- 2. 使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。
- 3. 使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码,当发布我的应用时,可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。
- 4. 使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然,如果你的文件服务器宕机,那么多所有你的站点将不能使用。这时,你就需要花费更多的开支来恢复它。
-
- 选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统,那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而,如果使用文件服务器,你就要实现一些失败恢复机制,防止万一服务器宕机导致请求失败。
- 2. 文件上传
-
- 当只有一台服务器时,文件上传不是一个问题。但是当我们有多台服务器时,那么上传的文件应该怎么存放呢?上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:
-
- 1. 把文件存储到数据库中 。大多数数据允许存储二进制数据。当你请求文件下载时,访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。
- 2. 在一个文件服务器上存储上传的文件 . 与前面的介绍一样,你要安装一个文件服务器让所有web服务器共享,把所有上传的文件上传到这里,上传后所有的web服务器就都可以使用它。但是,如果文件服务器宕机,那么可能发生图像文件下载中断。
- 3. 设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷,但是将增加你代码的复杂度。例如,如果上传到多个服务器过程中,服务器宕机,你要怎么处理?
-
- 用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时,首先检查缓存系统中是否有该文件,如果发现那么从缓存系统下载,否则从数据库读取并把它缓存到文件系统中。
- 3. 会话(Sessions)
-
- 如果你熟悉php的session处理,你将可能知道默认情况下,它存储session数据在服务器的临时文件里。而且,这个文件仅仅在你请求处理的那个服务器上,但是接下来的请求可能被另外一个服务器处理,这将在另一个服务器上生成新的session。这导致session频繁地不被识别,如登录用户总是要求重新登录。
-
- 我推荐的方案是,要么重新php内建的session处理机制存储session数据到数据库,或者实现你自己的机制保证发送一个用户的请求到同一台服务器。
- 4. 配置(Configuration)
-
- 尽管这个话题不是和php特别相关,我感觉还是有必要提及。当运行集群服务器时,用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致,可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。
-
- 我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件,也可以保持所有服务器配置文件同步。
- 5. 日志(Logging)
-
- 像配置问题一样,logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统,你怎么知道如果PHP代码开始产生错误(在系统正式运行时,你总是关闭display_errors 设置,不是吗?)
-
- 有几种方法你可以实现logging:
-
- 1. 在每一个服务器上记录日志。 这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单,可能只要很少的配置。但是,随着服务器数量的增多,监控每台服务器上的日志文件将变得非常困难。
- 2. 记录日志到一个共享 这种方法每一个服务器仍然有这个日志文件,但是他们通过共享机制被存储在一个中央文件服务器上,这将使监控日志变得更简单。该方案的问题在于,如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。
- 3. 记录日志到logging服务器 你可以使用一个logging软件,如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置,但是他也提供了最健壮的方案。
SVN的机制确实是很多人现在所考虑的,一来这样保证了代码的同步,二来也不需要担心开发版和上线版的区别,更重要的是,每次的update你肯定不会有错。
文件上传其实才是一个大头,当你的服务器过多的时候,你如何保证每一台服务器的上传内容同步?如果你同步了,那么这么多的冗余文件是否是一个浪费?如果你不同步,而采用同一个NFS服务器来存储,那么就象文中说的如果NFS宕机了怎么办?给NFS也来一个负载均衡?
总之,当服务器越来越多的时候,你考虑的就不仅仅是代码的问题,而是架构的问题