twigphp
⑴ 用sublime text 3写C++程序有什么好用的插件或者技巧吗
All Autocomplete
Themr
- —– BEGIN LICENSE —–
- Michael Barnes
- Single User License
- EA7E-821385
- 8A353C41 872A0D5C DF9B2950 AFF6F667
- C458EA6D 8EA3C286 98D1D650 131A97AB
- AA919AEC EF20E143 B361B1E7 4C8B7F04
- B085E65E 2F5F5360 8489D422 FB8FC1AA
- 93F6323C FD7F7544 3F39C318 D95E6480
- FCCC7561 8A4A1741 68FA4223 ADCEDE07
- 200C25BE DBBC4855 C4CFB774 C5EC138C
- 0FEC1CEF D9DCECEC D3A5DAD1 01316C36
- —— END LICENSE ——
Sublime Text 默认的 Autocomplete 功能只考虑当前的文件，而 AllAutocomplete 插件会搜索所有打开的文件来寻找匹配的提示词。
sublime可以下载很多风格样式，用这个插件可以管理所有的风格
这些就是我们大部分要用到的，其它的我就不细说了，因为每个人不一样,比如说git，sass，svn这些你们可以自己查找
插件的网址如下，你可以找到你喜欢的插件
https://packagecontrol.io/browse
最近出现sublime：3103版本好多没有激活码
今天在这补充下文章
⑵ 如何利用 onion 管理 php 专案
相信只要是 Ruby 开发者，都会对 Gem 这个专案套件管理机制非常赞赏。而其中还有一个很棒的工具叫做 bundler，它能在我们布署专案时，协助我们处理专案所会相依的 gem 套件。
PHP 在这方面虽然旅脊余有 PEAR 这个套件管理库，但是能够处理专案相依套件的功能却付之阙如。所幸网路高手 c9s 也发现了这个问题，因此他便开发了 Onion 这个非常好用的 PEAR 套件管理工具。（http://hounwang.com/lesson.html）
在“ 利用 GitHub 建立自己的 PEAR 频道”一文中，笔者曾简单地介绍 Onion 建立 PEAR 套件的方式，本文将继续为大家介绍 Onion 的其他强项功能。
Onion 入门
1. 安装
Onion 的安装很简单，只要透过 curl 指令就可以快速安装：
$ curl -s http://install.onionphp.org/ | sh
这样一来， onion 指令会被安装在个人家目录的 bin 资料夹下。如果你不想放在这个路径，那麽你也可以从以下路径直接下载：
https://raw.github.com/c9s/Onion/master/onion
然后再将它设为可执行，
$ chmod u+x onion
并搬移至系统 PATH 环境变数所找到的路径下即可，例如 /usr/local/bin/ 。
2. 功能简介
安装好 onion 指令后，直接输入：
$ onion
将可以看到以下输出：
alt
▲ 1：onion 指令之输出
在 onion 中可以使用的指令有：
help：显示说明文件，如图1 所示。
init：初始化 package.ini 文件。
build：建立 PEAR 套件。
compile：将目前的专案编译为 Phar 格式的函式库。
install：在 vendor 目录下，安装目前专案所相依的套件。
bundle：同 install 指令，为旧版相容用。
self-update：自我更新成最新的版本。
以下为大家介绍如何使用这些功能。
3. 专案初始化
在新版的 Onion 中，我们可以直接利用 init 指令来帮我们建立一个预设的 package.ini 档案，语法格式如下：
$ onion init＜dir＞
package.ini 是 Onion 用来管理套件所必要的档案，稍后笔者会再为大家详细介绍它。
4. 建立 PEAR 套件
在“利用 GitHub 建立自己的 PEAR 频道”一文中，笔者已经介绍过 build 指令的用法：
$ onion build --pear
这样一来， Onion 会透过 PEAR 的内建功能，为我们把目前的专案打包成 PEAR 可以接受的压缩档格式。
5. 编译为 Phar 格式的函式库
PHP 的 Phar 格式类似 Java 中的 JAR 格式，可以将套件下所有的 PHP 档案全部包成一个压缩档，方法如下：
alt
▲ 2：onion compile 的范例指令
这麽一来我们会得到一个 example.phar 的档案，而程式进入点则为专案中的 example.php。以下方式就可以让这个 Phar 档直接执行：
$ mv example.phar example
$ chmod +x example
$ ./example
注：如果各位打算将套件打包成 Phar 档的话，那麽要注意 require(_once) 及 include(_once) 所引入的档案路径，必须是相对的才行
6. 安装目前专案所相依的套件
在开发 Ruby 专案时，我们可以用 Gemfile 来管理相依的套件；而这对 Onion 来说，也是很容易的事情。
在 package.ini 中定义好专案所相依的 PEAR 套件后，就可以用以下指令来安装：
$ onion install
接下来 Onion 就会把这些相依套件安装在专案的 vendor/pear 路径下。至于如何在 package.ini 设定相依套件，稍后笔者会再详细介绍。
7. 自我更新版本
c9s 所开发的 PHP 工具几乎都有这个强大的功能，可野州以自行将工具的版本升级，指令拆滚如下：
$ onion self-update
这样一来，就可以更新到最新的版本。
package.ini 常用设定介绍
接下来笔者要为大家介绍 package.ini 中，几个比较常用区段的设定说明。
1. package
这个区段是在执行完 init 指令后，就会自动建立好的。 Onion 会事先提供：name、 version、 desc 及 author 等四个参数；以下为目前所支援的参数说明，标明“选用”的参数可以不写：
[package]
; 套件名称
name = Your Package Name
; 套件描述
desc = Description
; 同 desc (选用)
summary = ....
; 套件的官方网站 (选用)
homepage = http://your.web.com
; 版权说明，预设为 PHP (选用)
license = PHP
; 版本号
version = 0.0.1
; API 的版本号，预设同 version (选用)
version.api = 0.0.1
; 套件频道，在打包成 PEAR 压缩档时会需要用到
; 预设为 pear.php.net (选用)
channel = pear.php.net
; 专案作者
author = Author Name ＜author＠example.com＞
; 专案有多个作者时可以用以下方式定义 (选用)
authors[] = Author Name ＜author＠example.com＞
authors[] = Author Name
; 程式码贡献者及维护者 (选用)
contributors[] = ...
maintainers[] = ...
2. require
这个区段主要描述专案所需要的环境及相依套件，它们在使用 install 指令时会用到；预设不会提供，需要自己加入。
[require]
; PHP 版本，可加入 ＞ 及 ＜ 等前置字符
php = '＞ 5.3'
; PEAR 安装程式版本
pearinstaller = '1.4.1'
; 专案所相依的 PEAR 套件，格式为“频道/套件名称 = 版本号”
; 其中版本号可以省略，这样 Onion 会直接下载最新版本
pear.channel.net/package = 1.1
; 相依套件的另一种写法，直接使用 URI 定义
package = http://www.example.com/Foo-1.3.0
; 专案会用到的 PHP extension
extensions[] = 'reflection'
extensions[] = 'ctype'
extensions[] = 'pcre'
3. roles
这个区段主要在定档套件中档案的角色，它们会依照角色的不同，被安装到适当的位置里。
[roles]
; 通常套件如果有提供 shell script 的话，可以将它放在 bin 目录下
; 并且给它 script 角色，那麽在透过 pear 指令安装时，
; 它就会被安装为系统指令
bin/your_script = script
; 其他副档名的角色，支援万用字符 (*)
*.md = doc
*.php = php
其他的区段在实务上笔者几乎用不到，若是有使用上的疑问，可以请教原作者 c9s。
范例
以下笔者将用 Library 及 Web Applicaton 这两种不同的范例，来介绍 Onion 在实际专案上是怎麽使用的。
1. Library
通常我们会希望开发出来的功能是可以被重复使用的，这时把它们打包成 library 是明智的选择。这里笔者将介绍
首先我们要依照 Onion 所规范的方式来定义专案的目录结构，假设专案的路径为 /path/to/library：
$ mkdir -p /path/to/library
$ cd /path/to/library
$ mkdir bin src docs tests
其中 bin 是放置 Shell Script，src 是存放 PHP 程式原始码；docs 则是用来存放文件，tests 则放置测试程式。
接下来我们要建立 package.ini ，执行：
$ onion init .
建立 package.ini 后，修改里面的内容：
[package]
name = UriFetcher
version = 0.0.1
desc = Fetch and cache data from URI
author = Jace Ju ＜jaceju＠example.com＞
channel = pear.jaceju.net
[require] php = "> 5.3"
pearinstaller = 1.4.1
[roles] bin/urifetcher = script
*.md = doc
*.php = php
这里我虚构了 UriFetcher 这个套件，它必须在 PHP 5.3 以上版本执行；另外这个套件也提供 urifetcher 这个 Shell Script ；当然，这里的内容只是范例，请大家依实际状况调整。
现在我们可以开始撰写套件内容了，这边就不再为大家详细介绍程式内容，只单纯列出这个套件的档案清单：
alt
▲ 3：onion - library tree layout
在 src 目录下，所有 PHP 类别档的命名与路径都要按照 PHP FIG PSR-0 的规范。
而在 tests 目录下，每个类别档的单元测试程式一样也是要遵守 PSR-0 规范。
在开发的过程中，各位可以选择使用 TDD 或其他惯用的开发流程。在确定功能无误后，我们就可以建立 package.xml，方便我们将套件安装到系统上测试；这个步骤可以透过以下指令来执行：
$ onion build
建立好 package.xml 后，就透过以下指令来进行安装测试：
$ pear config-set auto_discover 1
$ pear install -f package.xml
另外因为我们有加入 urifetcher 这个 shell script ，所以可以利用以下指令来查看它是否有被正常安装：
$ which urifetcher
在系统安装测试无误后，就可以按照“利用 GitHub 建立自己的 PEAR 频道”一文中所介绍的方式，来将套件打包并上传到我们自订的频道。
2. Web Application
Web Application 的开发方式其实与 Library 很像，差别在于它需要布署在 Web Server 上面来向浏览者提供服务，而非透过程式的呼叫。
通常它的目录结构会如下所示：
alt
▲ 4：onion - webapp tree layout
当然大家也可以采用目前一些常见 Web Framework 所定义好的目录结构，基本概念都是差不多的。
第一步我们当然是先初始化我们的 package.ini ，这里假设专案路径为 /path/to/webapp：
$ cd /path/to/webapp
$ onion init .
然后修改 package.ini 的内容：
[require]
pear.twig-project.org/Twig =
这里假设会在这个专案里面会用到 Twig 这个样版套件。
各位应该会发现笔者在这里只用到 require 这个区段，这是因为我们不需要打包 Web Application ，所以不需要把 package.ini 转译为 package.xml ；换句话说，在 Web Application 中，我们只需要透用 Onion 来管理相依套件。
接下来不论在在开发、测试或正式上线等环境，我们都可以用以下的方式来安装相依套件：
$ onion install
而在程式里面，我们必须在进入点 (通常是 index.php ) 的最上方，加入这段 PHP 码：
＜?php
// 加入此段程式码
set_include_path(implode(PATH_SEPARATOR, array(
__DIR__ . '/vendor/pear',
get_include_path(),
)));
// 自动载入的程式码
// ...
这样程式才能够先取用 vendor/pear 中的相依套件。
大致上笔者常用的功能就是这些，其他更进阶的功能，各位可以在 Onion 的官网与作者讨论。
心得
PHP 在第四版时，套件管理这个概念才正式进入 PHP ；而在实作上， PEAR 套件的开发方式也比其他语言的机制繁琐。
但即便如此，透过了 Onion 这个方便的工具，不但让我们能够轻松地管理专案的相依套件，也能够让我们能以简单的方式来设定自行开发的套件。
或许 PEAR 这个架构现在看起来是老旧了些，但还是有其他高手正努力为 PHP 开发更良好的套件管理机制。相信有一天，我们能够以更方便更快速的方式，来打造属于我们自己的 PHP 套件。
更多问题到问题求助专区 （http://bbs.hounwang.com/）
⑶ Node.js代码转php
如果你们开发团队正在使用PHP，并考虑迁移到Node.js，这篇文章很适合你。本文并不探讨从PHP移植到Node.js的细节，以及Node.js的基础知识。而是涵盖：决策制定、着手点的描述、编写 Node.js 服务器的深层次注意事项、以及部署策略。
为什么迁移？
1stdibs 决定从 Apache/PHP 迁移到 Node.js+Express 有五个理由：
代码更少
全栈式JS
开发人员幸福度更高
投入回报率
未来的优化
代码更少
1stdibs基于面向服务体系架构（SAO），前端调用后台的Java服务。这意味着需要同时维护前端模型，以及服务端PHP和客户端JS模板。试想一下，如果可以摆脱PHP，就能够统一前端展现与后台模型于一种语言：JavaScript（同时可以合并一些模板）。从维护的角度来看，这么做代码更简洁，并且没有重复逻辑。
同构JavaScript万岁!
全栈式JS（及其优点）
整个开发栈使用一种语言很简便。对开发者来说，较少的环境切换使他们开心和高效。额外的好处是工具使用更简单。相比之前使用Composer和npm两个包管理器，现在只需要一个。尽管Composer很出色，由于nbp负责工具和客户端管理，nbp总是必要的。一旦去掉所有的PHP代码，nbp将成为仅有的包管理器。
开发人员乐意
我们要保证开发人员的技能集得到扩展、职业生涯不断发展，这一点很重要。对于JavaScript工程师而言，Node.js极具吸引力。能够在服务端使用与客户端相同的工具、风格和模式，是非常顺手和高效的。此外，Node.js相当流行，在企业级开发上也得到了长足发展。Node.js是JavaScript工程师的必备技能。
投入回报率
我们在招聘优秀的JS工程师和培训初级JS工程师方面花了大价钱。由于客户端栈很复杂，我们需要高级JavaScript工程师。我们不再雇用PHP工程师，仅仅雇用了JavaScript工程师。我们的观点是，为什么不培养他们在服务端的技能呢？
未来的优化
长远而言，我们打算把两个庞大的应用分割成一系列独立部署的小应用。这很容易通过Node.js、Express和nbp实现。理论上，PHP（比如使用Slim）可以做同样的事。但我们非但得不到上述好处，还会搞得一团糟：在Apache/PHP上进行操作会更加复杂，基础设施也会变得有些奇怪。
选择框架
那个最终被我们用Node.js替换掉的PHP应用，主要有如下职责：
登录和授权
路由选择和服务端模板引擎（服务HTML）
引导前端应用
代理服务（为了回避CORS）
服务静态资源（js，css，images）
这些就是我们需要替换掉的基本功能。
我们尝试过不少框架，Express令人叹为观止（试一下我们评估过的spreadsheet）。任何未基于Express 的框架看起来都不靠谱。Express通俗易懂，并有良好的文档。另外，可以招聘到正经培训过Express的人。
我们添加了一些kraken的核心模块（express-enrouten用于路由选择、lusca负责安全）；此外，i18n-node提供国际化支持，模板引擎使用Swig（我们后来放弃了Swig。呵呵，开源软件还是有风险的）。
我们考虑过全盘使用kraken，但是从原来的服务端php模板引擎Twig切换到Swig直截了当，还很快捷。此外，kraken里面的Dust和i18n也不讨人喜欢。
编写服务器
选好了框架，下一步该写服务器了。
使用Apache+PHP时，你不需要再写一个服务器。Apache本身就是服务器，PHP是应用。如果使用Node.js，服务器和应用是同一个。从Apache/PHP转到PHP，你需要处理一些之前自然而然使用的功能，这一点很重要。使用Apache，你（或者系统管理员）配置服务器，在PHP应用里完全不用关心Apache为你处理的那些事。Node.js却以一种不同的方式来工作。
提供静态文件服务
毋庸置疑，提供静态文件服务是Apache的核心功能。Node.js与此不同，你要在应用中配置静态文件服务。幸运的是这很简单，有良好的文档说明，并且是在Express中实现的。
日志
很多基本的Apache配置为你提供访问日志和错误日志。使用Node.js时，估计你也猜到了，同样需要在应用中配置。所幸很多优秀的开源软件包使之变得很简单。Morgan是一个基本的请求日志记录器，它配置简单，允许你把日志写到输出流（标准输出设备或文件）。如果你需要把日志写到数据库，或者有别的（更高级的）日志需求，那就试一下winston吧。
代理
我们有一个基本需求：能够代理传输客户端ajax请求到后台服务。相比于处理CORS头，代理所有来自相同域的请求要简单得多。但你要想通过代理使用webpack-dev-server（正如我们所做的），就必须在Node.js应用中处理这一问题。http-proxy是一个简单可靠的解决方案。
剩下的工作
除了上面提到的，还有一些列别的工作需要完成。我们从一个MVC应用谈起，该应用基于 CodeIgniter(CI)框架，为一系列单页应用提供服务。大部分工作就是移植：
CI控制器移植到Express路由选择器和中间件（包括登录和认证）
Twig模板引擎移植到Swig（这一步比较琐碎）
Service层数据访问（以便正常启动客户端单页应用）
上面并未列出CodeIgniter模型这一关键组件。事实上根本不用重写PHP模型！太给力了！我们的客户端应用使用Backbone模型。当然这要扩展Backbone.Model.sync，从而使之全局地工作在服务器和客户端。
部署
如果你的app规模较大，不应该一次性全部上线。可以通过渐进式部署的方式逐步上线。我们因此花费了好几周。
渐进式部署的优点：
最小化bug范围
每次在发布一部分路由及功能的同时，其他工程师可以正常进行开发
对正在进行的功能开发和改进影响最小 — 新功能可以继续发布（这可能导致重复的工作）
如果操作得当，可以快速回滚到之前的服务
NGINX很不错
该如何逐步上线呢？我们在众多的服务器中挑选了Nginx。
1
2
3
4
5
+----------+
http | |--->
Apache/PHP
request---->| Nginx
|
| |--->
Node.js
+----------+
Nginx允许你一次只“打开”一个路由（如果发现情况不妙就关掉 — 正如我们多次遇到的），这给了你很大的自由度。我们也发现打开路由的时候不用部署代码，这很有帮助。这在一周一次的发布计划里，为我们提供了一些回旋空间。
不过有一个缺点，你需要确保客户端代码同时接受旧的Apache/PHP服务器和新的Node.js服务器提供的服务。这并不可怕，不过你要把旧服务器上未优化的功能移植到新的服务器。屏住呼吸去做吧（记得写一个便利贴去清理你的技术债）。
总结
从头到尾，整个移植工作大概花费了一年。这听起来可能有点荒谬，不过这个时间表包括决策过程（比较匆忙）、基于Express写一个满足需求的核心框架、移植所有功能、逐步渐进式上线。此外，请记住，我们始终只有一两个开发者为之工作 — 并且是兼职。
如果你想尝试一下，请慎重考虑。你的团队能否受益？你的整个组织能否受益？如果你来自商业组织，请记住商业需要持续运转。你需要在商业目标和工程目标之间找到良好的平衡。