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寫一個滿足需求的核心框架、移植所有功能、逐步漸進式上線。此外，請記住，我們始終只有一兩個開發者為之工作 — 並且是兼職。
如果你想嘗試一下，請慎重考慮。你的團隊能否受益？你的整個組織能否受益？如果你來自商業組織，請記住商業需要持續運轉。你需要在商業目標和工程目標之間找到良好的平衡。