前不久回答了一个关于后端语言选型的问题，写的回答也让笔者有了很多感触，因此在这里谈论下自己对后端语言选型的心得体会，姑且算是抛砖引玉，希望大家能分享各自的心得。

环境部署一直是一个很大的问题，无论是开发环境还是生产环境，但是 Docker 将开发环境和生产环境以轻量级方式打包，提供了一致的环境。极大的提升了开发部署一致性。当然，实际情况并没有这么简单，因为生产环境和开发环境的配置是完全不同的，比如日志等的问题都需要单独配置，但是至少比以前更加简单方便了，这里以 PH...

最近有个朋友问我 PHP 命名空间是咋样的，但是由于长期不做开发，笔者实际上也已经忘得差不多了，所以也回答不出来。只是记得和 Java 挺像的。事后重新查了一下 PHP 的官方文档，并且和 Java 做对比，Java 的命名空间实际上来自于 JVM 本身的机制，JVM 是基于 class 字节码文件加载类，由于类很容易出现重名的情况，换言...

PHP7即将在12月3日正式发布，而RC8是已经差不多稳定了的版本，后续的GA版本主要都是在修复bug，所以为了未来开发环境的升级，准备尝试安装一下。

关键词 “必须”("MUST")、“一定不可/一定不能”("MUST NOT")、“需要”("REQUIRED")、“将会”("SHALL")、“不会”("SHALL NOT")、“应该”("SHOULD")、“不该”("SHOULD NOT")、“推荐”("RECOMMENDED")、“可以”("MAY")和”可选“("OPTIONAL")的详细描述可参见 RFC 2119 。

本规范的主要目的，是为了让日志类库以简单通用的方式，通过接收一个 Psr\Log\LoggerInterface 对象，来记录日志信息。框架以及CMS内容管理系统如有需要，可以对此接口进行扩展，但需遵循本规范，这才能保证在使用第三方的类库文件时，日志接口仍能正常对接。

当多名程序员在多个项目中合作时，就需要一个共同的编码规范，而本文中的风格规范源自于多个不同项目代码风格的共同特性，因此，本规范的价值在于我们都遵循这个编码风格，而不是在于它本身。

当多名程序员在多个项目中合作时，就需要一个共同的编码规范，而本文中的风格规范源自于多个不同项目代码风格的共同特性，因此，本规范的价值在于我们都遵循这个编码风格，而不是在于它本身。

关键词 “必须”("MUST")、“一定不可/一定不能”("MUST NOT")、“需要”("REQUIRED")、“将会”("SHALL")、“不会”("SHALL NOT")、“应该”("SHOULD")、“不该”("SHOULD NOT")、“推荐”("RECOMMENDED")、“可以”("MAY")和”可选“("OPTIONAL")的详细描述可参见 [RFC 2119][] 。

一个标准的 命名空间(namespace) 与 类(class) 名称的定义必须符合以下结构：\<Vendor Name>\(<Namespace>\)*<Class Name>；

最近要做图书馆查询服务的转换php，上次写oracle中间层的时候因为没有oci8模块和oracle实例，所以手工写代码没有调试，这次工作量有些庞大，所以花费了一些时间来安装oci8模块，方便php调试工作。