该状态码表示客户端发送附带条件的请求（附带条件的请求是指采用GET方法的请求报文中包含If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since中任一首部。）时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304 Not Modified（服务器端资源未改变，可直接使用客户端未过期的缓存）。304状态码返回时，不包含任何响应的主体部分。304虽然被划分在3XX类别中，但是和重定向没有关系。
形如If-xxx这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。
是这样产生304的
上图中显示的200是不是应该是304啊？
点击右上角的“购买证书”按钮
找到免费的证书，阿里云的免费证书藏的比较深
选择品牌“Symantec”
证书类型里才会出现免费的，选择“免费型DV SSL”
购买并支付
打开证书管理页面
在证书列表里点击“补全”
填写域名信息
填写个人信息
提交
审核完成之后就可以在证书管理页面下载证书了
点击下载之后会打开下载证书的页面，选择对应的服务器的证书下载即可
在Nginx的安装目录下创建cert目录，并且将下载的全部文件拷贝到cert目录中。如果申请证书时是自己创建的CSR文件，请将对应的私钥文件放到cert目录下并且命名为214499409770626.key；
在/etc/nginx/sites-available里创建一个新的网站配置文件（以下属性中ssl开头的属性与证书配置有直接关系，其它属性请结合自己的实际情况复制或调整）
server {
listen 443;
server_name [你的域名];
ssl on;
root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;
ssl_certificate cert/[你的证书名字].pem;
ssl_certificate_key cert/[你的证书名字].key;
ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
root html;
index index.html index.htm;
}
}
创建一个连接，把你刚才编辑的文件连接到/etc/nginx/sites-enabled目录下
重启 Nginx
通过 https 方式访问您的站点，测试站点证书的安装配置。
史蒂夫·乔布斯说过，每个人都应该学习给电脑编写程序的技术，因为这一过程能够教你如何去思考！众所周知，编程已成为开发者生命中至关重要的一部分。很多事实表明，越来越多的人不管男女老少都将参与编程这个行业。
学习编程的渠道有很多种，比如你可以利用一些互动平台或者书籍去学习编程，无论是哪种，只要找到适合自己的就OK。俗话说，光说不练嘴把式，因此，我们还需要进行实践。
编程极富有创造性，你可以创造出许多新奇有趣的想法。很多时候，开发者在相同的问题上花费了大量时间，而忽略了创造性。笔者不能确定这是否是许多网站发起编程挑战赛的原因，但可以确定的是，这些挑战对于开发者而言是有很大帮助的。它的好处在于：
文中搜集了14个不错的学习资源，帮助你挑战自我，领略并探索计算机领域无穷奥秘。
[topcoder]社区得到了数百万编码者的支持，因此你可以了解到很多挑战性的项目，基于此你还可以为自己赚去额外的报酬。你可以每天或每周参与编码挑战，该社区提供的项目极具有挑战性，对于初学者而言有一定的难度，但却值得一试。
HackerEarth提供了SaaS应用，能够为应试者自动评估技术和逻辑技能。此外，它还可作为人才聚集地，为公司提供智能招聘服务资源，帮助公司挑选适宜人才。
HackerEarth会频繁更新挑战项目，你可以提前几周登记注册，事先了解下项目，为挑战做好充足的准备。
Coderbyte旨在帮助提高开发者的编程技能，其得到了初学者和中级程序员的一致好评。该项目由Daniel Borowski?于2012年推出，现今任何开发者都可利用业余时间进行维护。
如果你遇到难题，你可以在Coderbyte上提问，该社区的用户相当活跃，你可以获得任何你想要的答案。
Project Euler可能是全球最流行的编程挑战网站，项目推出初期就拥有几十万的用户，足以表明其影响力有多大。Project Euler致力于鼓励、挑战并且发展解题技巧，并为那些对迷人的数学世界有兴趣的人提供乐趣。
你可以通过：Wikipedia?、?Reddit?、?Stack Overflow?以及Google Code?了解更多Project Euler相关信息。
如果你想了解更多关于编程和问题解答，那么Reddit Daily Programmer就是你的好去处。毋庸置疑，许多开发者都喜欢在Reddit上查看新闻、探讨话题。你的每一次创建、评论，社区成员都审阅并提交，所以你可能会获得许多意见和答案，直至满足你的需求。
Codility Train支持多种语言，你可以预先定制或预先思考挑战项目，根据难易度进行分类，当然挑战何种程度取决于你自己的选择。
每项编程挑战最后都有详细的解释，挑战时间也有限制并不是绝对的自由。
Sphere Online Judge?是一个由成千上万个编码挑战项目组成的社区，它几乎支持所有的编程语言，你还可以基于该社区论坛需求帮助
麦当劳的巨无霸不好吃啊
要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。
即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。
再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。
如上，即便你不懂他所用的语言，不却关心程序的逻辑，对好的程序员还是差的程序员就能做到八九不离十的判断。程序的好坏几乎总是取决于它们是否“漂亮”，不“漂亮”而好的程序，除了C++ STL源码，我再也没见过（如果你稍仔细看，STL的源码虽然不够“漂亮”，但仍然满足这里提出的一致性原则）。而又好又“漂亮”的代码则随处可见，如Linux Kernel，InnoDB，JDK，JUnit等等。
如果再仔细阅读，就能更准确。好的程序员写的代码，好似浑然天成，简单而直白。函数通常较短小，函数的名称准确的反映函数要完成的工作。逻辑简单而自然，让你读的时候由衷的发出“啊，就应该是这样”的感叹，而差的程序员的代码经常让你发出“怎么是这样？这是再干什么呀？”的疑问。好的程序员会在紧要关头加以画龙点睛般的注释，差的程序员要么没注释，要么注释只是代码的重复，纯粹是废话，更差的是注释是错的，是误导。
好的程序员未必是“语言律师”，即那种非常清楚的了解语言的各个细节，在编程时到处使用的家伙。好的程序员也不常“炫技”，在代码中精心构造一些独具匠心的片断，他们偶而会，但大多数时候总是用直白的语言来表述。
从代码也可以看出一个程序员的团队协作精神。注意团队合作的程序员，会严格按照团队规范写代码，而风格与团队规范不一致的程序员则很可能欠缺团队精神。注意团队合作的程序员会注意给模块的对外接口加以重要的说明，如前置条件、后置条件、参数能否是NULL等等，不注意团队合作的程序员懒于处理这些细节。
好的程序员与差的程序员的生产力差别巨大，项目的周期越长，项目越复杂，项目对质量的要求越高，好的程序员的价值就越大。好的程序员与差的程序员，管理成本也差别巨大，好的程序员只需要与他共同确定设计，代码可以不看，差的程序员的代码经常需要经过多次review，且仍有可能达不到理想的质量。
要成为好的程序员，首先要树立要成为好的程序员的志向，再勤加练习，天长日久，就会越来越好，这些人不怕老。没有志向永远成不了好的程序员，这些人若不在老去之前成为经理就会变成废人。
通过两个小时的笔试和半个小时的面试对于判断程序员来说是不够的。通过笔试与面试，你可以判断一个程序员是否具备算法与数据结构等基础知识，可以判断他对编程语言的特性是否掌握，可以判断他对技术是否关注，然而要知道他能否真的能很好的完成工作，不写代码是不够的。
那些显得对技术充满热情的，未必是好的程序员。这些人可能非常乐意从事有新意的工作，但后续的编码、测试、调试、文案工作则可能让他们感到厌烦。他们可能会提出好的创意，但却经常不能够有始有终的将其完成。公司不需要多少这样的人。
因此招聘的方式需要改善。招聘是最重要的，因为进来后就难以出去，即便是试用。转正条件白纸黑字写的很清楚，只要合格就可以转正，要达到合格并不是很困难。今年部门里进了很多新人，并不是人人都很优秀，但确实也都合格，自然也应该转正。
改善招聘的方法，就是让他写程序，可以出两道题，一道让他写程序，一道让他重构一个已有的较长的程序，一天之内完成。假使可以考他半个月，那么重构是不太需要的，但一天的时间太短，通过重构可以考察阅读并理解代码，并通过重构“化腐朽为神奇”的能力。那些不愿意写别人的代码，不愿意接受别人的代码，经常要重来一遍的人是不理想的。
今年有两个人采用了类似的方法。有一位简历很优秀的人，做了两道编程题被拒了，有一位简历及面试一般的人，通过编程测试，录用了。我感觉比单纯的笔试与面试要准确。
编写生产质量级别的代码似乎是一个明摆着的目标，但计算机行业却费了不少时日才弄明白正确的实现之道。例如，Windows 95曾经有个Bug会让操作系统在连续运行49.7天之后挂起—但是该Bug花了4年时间才暴露，有Bug这件事本身并不特别让人觉得惊讶，时间之所以这么长是因为其他Bug在不到49.7天的时候就让Windows 95崩溃了。
通往高质量代码的道路有两条，你可以二选一：一开始就内置质量，或者事后再敲打它。前者需要你在日复一日的编码中遵循众多戒律；后者则要求大量测试，到头来，在自以为完工之后，你会发现还有很多工作要做。
事后敲打（beat-it-in-afterward）是常见的工作方式，行业占统治地位的瀑布开发方法就是这样：规格说明、设计、构建、测试。测试是最后的步骤。产品来到测试部门，很快就崩溃了。于是，又回到工程部门，修复Bug。接着，把另一版提交给测试部门，又由于其他原因崩溃。就这样，来来回回，许多月（甚至是数年）流逝。
在程序员们深入具体实践之前，我们会从技巧1——敲打代码开始，帮你建立正确的思维方式。
你可能认为编写可靠代码是再明显不过的工作要求了。招工广告上不可能写：“急聘：具备良好工作态度、团队合作精神和桌上足球技巧的程序员。有则更佳：会编写可靠的代码。”可有问题的程序还是有这么多，怎么回事？
在深入探讨保证代码质量的日常实践之前，让我们先讨论“编写可靠代码”的含义。它不仅仅是一份实践清单，它还是一种思维方式。在把产品交到客户手中之前，你必须敲打自己的代码和整个产品。
客户终究敲打你的产品，以一种你不曾预料到的方式使用它。他们用它的时间会很长，而且会在你没有测试过的环境里用它。你必须考虑的问题是：打算让客户发现多少Bug？
你现在对代码敲打的次数越多，在交到客户手中之前，能清除掉的Bug就越多，留给客户的Bug就越少。
质量保证的形式
1.代码评审
保证代码质量最简单的方法就是让另一个程序员去读它。别出心裁的评审过程并没有必要，而且就连结对编程也算是一种形式的实时代码评审。团队将利用代码评审捕获Bug，贯彻编程风格和标准，同时在团队成员间传播知识。我们将在“技巧8：代码评审要早且多”中讨论代码评审。
2.单元测试
在你一个类接着一个类、一个方法接着一个方法地构建应用的业务逻辑时，验证代码的最佳方式就是单元测试。这种内部零件级的测试被设计用来对逻辑的各部分单独验证。
3.接受测试
单元测试立足于由内而外地审视产品，接受测试则被设计成模拟真实世界的用户，代表他们与系统交互。理想状况下，它们是自动执行的，而且以某种叙述式的风格书写出来。例如，某银行自动柜员机应用会有类似这样的接受故事：若我的活期存款为0，当我在ATM的“活期存款”中选择“取款”时，那么我应该看到“对不起，今天的晚餐吃泡面吧。”
它不像莎翁著作那样文采飞扬，但这些测试操练了整个系统：从用户界面一直到业务逻辑。无论它们是自动执行的，还是人工执行的，你的公司需要知道—在任何客户使用它之前—所有系统组件正在像预期的那样协调工作。
4.负载测试
负载测试将产品置于真实的压力条件下，然后度量它的响应。例如，某网站可能需要在数据库有100万条记录的条件下在100毫秒内展示指定页面。这些测试将揭示正确但不恰当的行为，如需要线性伸缩但却以指数级别伸缩的代码。
5.定向探索测试
接受测试覆盖了产品的所有指定行为，它可能来自于产品需求文档或会议。但程序员通常还是有办法使之崩溃—总有些黑暗角落被规格说明疏忽掉。定向探索测试就是要将这些边界情况挖出来。
这种测试通常是人工执行的，可能是程序员自己，用于探索和发现问题。但最初探索之后，任何有用的测试就会被加到接受测试套件之中。
该测试有一个专业化的变种，如安全审计。在这些情况下，专业测试人员会利用他们的领域知识（可能也包括代码评审）来指导他们的测试。
6.机构测试
硬件产品需要不同的机构认证：FCC度量电磁辐射，确保产品不会导致无线电干扰；美国保险商实验室（UL）检查当你将产品置于火上或舔电池电极时会发生什么。这些测试都在新产品发布之前进行，每次硬件变化都会影响认证。
7.环境测试
硬件产品的运行温度和湿度也需要在推至极限时测试。这些测试是用环境室来完成的，它可以同时控制这两个因素；当产品在其间运行时，它会经历所有四种极限条件。
8.兼容性测试
一旦产品需要跟其他产品进行互操作（如某字处理程序需要跟其他字处理程序交换文档），这些兼容性的论断就需要定期验证。它们可能会访问一组已保存的文档，也可能会实时地将你的产品连接到其他产品上。
9.耐久性测试
你会注意到这里提到的大多数测试都是尽量频繁且快速地运行。可有些Bug只会在一段时间的使用之后现身。前面提到的49.7天的Bug很好说明了这一点—它源于每毫秒递增的32位计数器，在49.7天之后，它会从最大值反转成0。测试若不持续运行上一会儿，你就无法发现类似Bug。
10.Beta测试
产品在这一阶段被送到了真实客户手中—他们知道自己要参加测试，并同意发现问题时提交报告。Beta测试的目的就在于我们在本技巧一开始讨论的：Beta测试者将以你意想不到的方式使用产品，试用它一段时间，并在你没有测试过的环境中测试产品。
11.运行中测试
公司可能会在产品上市之后继续测试。尤其是硬件产品，如偶尔从制造线上拔掉一个单元并证明制造线能工作正常是一种很有用的方法。这些运行中测试的设计目的就是为了捕获因零件或装配过程中的变化而导致的问题。
实践 VS 思维方式
你的团队可能采用类似“所有代码都必须有单元测试”或“所有代码必须先评审后检入（check in）”的实践。但这些实践没有一个能保证代码坚若磐石。想想若公司根本就没有采用一个质量实践，这种状况下该怎么做，即你将如何敲打代码以保证它的可靠性？
这是在继续深入之前你需要建立的思维方式。提交可靠的代码。质量实践只是达到目的的一种手段—最终的裁判是客户手中产品的可靠性。你想让你的名字跟市面上满是Bug的垃圾产品挂钩吗？不，当然不想。
行动指南
在上述所有形式的测试中，你的公司采用了哪些？在源代码中寻找单元测试，向测试部门询问接受测试计划，问问Beta测试是如何进行的以及向哪个部门提交反馈。再问下资深工程师：这是否足以保证客户有一个平滑的体验？
在定向探索测试上多花些时间，哪怕你的“方向”有点儿模糊。实际用一下产品，看看你是否可以让它崩溃。如果可以，那就相应地记下Bug报告。
Josh Carter，资深软件设计师，具有超过20年编程行业从业经验。热衷于编程和追逐前沿技术，但同时谨记史蒂夫?乔布斯的箴言“真正的艺术家能让产品面市”。他还涉足工程管理领域，曾经主管大型企业软件开发团队。目前已出版多本关于计算机软件的技术书籍，同时他还在主流计算机杂志的技术专栏发表文章。
作者Josh Carter，资深软件设计师，具有超过20年编程行业从业经验。热衷于编程和追逐前沿技术，但同时谨记史蒂夫?乔布斯的箴言“真正的艺术家能让产品面市”。他还涉足工程管理领域，曾经主管大型企业软件开发团队。目前已出版多本关于计算机软件的技术书籍，同时他还在主流计算机杂志的技术专栏发表文章。
这篇文章要介绍的，是我作为专业程序员这些年来学到的能真正提高我的代码质量和整体工作效率的10件事情。
1. 永远不要复制代码
不惜任何代价避免重复的代码。如果一个常用的代码片段出现在了程序中的几个不同地方，重构它，把它放到一个自己的函数里。重复的代码会导致你的同事在读你的代码时产生困惑。而重复的代码如果在一个地方修改，在另外一个地方忘记修改，就会产生到处是bug，它还会使你的代码体积变得臃肿。现代的编程语言提供了很好的方法来解决这些问题，例如，下面这个问题在以前很难解决，而如今使用lambdas却很好实现：
现在我们重构含有部分相同代码的函数，用delegate模式重写它们：
2. 留意你开始分心的时候
当你发现自己在浏览facebook或微博、而不是在解决问题，这通常是一种你需要短暂休息的信号。离开办公桌，去喝一杯咖啡，或去跟同事聊5分钟。尽管这样做看起来有点反直觉，但长久去看，它会提高你的工作效率。
3. 不要匆忙赶任务而放弃原则
当带着压力去解决一个问题或修改一个bug，你很容易失去自制，发现自己匆匆忙忙，甚至完全忘了一直坚持的重要的测试过程。这通常会导致更多的问题，会让你在老板或同事眼里显得很不专业。
4. 测试你完成的代码
你知道你的代码能做什么，而且试了一下，它确实好用，但你实际上需要充分的验证它。分析所有可能的边界情况，测试在所有可能的条件下它都能如期的工作。如果有参数，传递一些预期范围外的值。传递一个null值。如果可能，让同事看看你的代码，问他们能否弄坏它。单元测试是到达这种目的的常规方法。
5. 代码审查
提交你的代码之前，找个同事一起坐下来，向他解释你做了哪些修改。通常，这样做的过程中你就能发现代码中的错误，而不需要同事说一句话。这比自己审查自己的代码要有效的多得多。
6. 精简代码
如果你发现写了大量的代码来解决一个简单的问题，你很可能做错了。下面的boolean用法是一个很好的例子：
这时你应该写成这样：
代码越少越好。这会使bug更少，重构可能性更小，出错的几率更小。要适度。可读性同等重要，你可不能这样做而使代码丧失可读性。
7. 为优雅的代码而努力
优雅的代码非常的易读，只用手边很少的代码、让机器做很少的运算就能解决问题。在各种环境中都做到代码优雅是很难的，但经过一段时间的编程，你会对优雅的代码是个什么样子有个初步的感觉。优雅的代码不会通过重构来获得。当你看到优雅的代码是会很高兴。你会为它自豪。例如，下面就是一个我认为是优雅的方式来计算多边形面积的方法：
8. 编写不言自明的代码
勿庸置疑，注释是编程中很重要的一部分，但能够不言自明的代码跟胜一筹，因为它能让你在看代码时就能理解它。函数名变量名要慎重选择，好的变量/方法名字放到语言语义环境中时，不懂编程的人都能看懂。例如：
9. 不要使用纯数字
直接把数字嵌入代码中是一种恶习，因为无法说明它们是代表什么的。当有重复时更糟糕——相同的数字在代码的多个地方出现。如果只修改了一个，而忘记了其它的。这就导致bug。一定要用一个命名常量来代表你要表达的数字，即使它在代码里只出现一次。
10. 不要做手工劳动
当做一系列动作时，人类总是喜欢犯错误。如果你在做部署工作，并且不是一步能完成的，那你就是在做错事。尽量的让工作能自动化的完成，减少人为错误。当做工作量很大的任务时，这尤其重要。
11. 避免过早优化
当你要去优化一个已经好用的功能代码时，你很有可能会改坏它。优化只能发生在有性能分析报告指示需要优化的时候，通常是在一个项目开发的最后阶段。性能分析之前的优化活动纯属浪费时间，并且会导致bug出现。
好吧，我说是10个，但你却得到了额外赠送的一个！
这些就是我要说的，我希望它们能帮助你改进编程开发过程。
下次再见！祝快乐！
Cheers, Paul.
英文链接：www.wildbunny.co.uk/blog/2012/11/01/10-steps-to-becoming-a-better-programmer/
来源：外刊IT评论网
12306网购火车票的同学，如果出现页面加载缓慢，可以在
C:WINDOWSsystem32driversetchosts
中添加一条记录：
“122.228.243.22 dynamic.12306.cn”，
或者”61.183.42.94 dynamic.12306.cn”，
这是提供给海外用户访问的CDN节点，几乎没什么人。
x 语言入门 —> x 语言应用实践 —> x 语言高阶编程 —> x 语言的科学与艺术 —> 编程之美 —> 编程之道 —> 编程之禅—> 颈椎病康复指南
?