分类目录归档:PHP

Composer 的库

the_house_of_the_famous_composer

继《Composer 基本用法》,接着翻译官方文档的下一部分:Composer 的库。之所以想到翻译这部分,是因为,之前我的项目是基于 Symfony 2 框架,是框架在用 Composer,而不是我,现在我在准备自己的项目,我要用 Composer,得知道的更多。

适合阅读对象:
1、了解什么是 Composer(不了解的看这里:《Composer (作曲家),PHP 的依赖管理器》)
2、想了解如何让你的包能通过 Composer 安装
3、想了解 Composer 大的体系

一、所有项目都是一个包

如果你的目录里有一个 composer.json,那这个目录就是个包。当你在项目中添加了一项 ”require“,你就创建了一个依赖其他包的包。你的项目和外部库的唯一区别就是:你的项目是一个没有名字的包。

如果想让你的包能通过 Composer 安装,你需要给它指定一个名字。通过给 composer.json 添加 name 字段即可:

例子中,项目的名称为 acme/hello-world,其中 acme 是供应方(vendor)的名字。供应方名是必须强制提供的。

(注:如果你不知道供应方名该怎么取,你的 GitHub 用户名通常是不错的选择。因为包名是大小写敏感的,所以一般用小写字符并在词之间用横杠分隔)

二、平台的包

Composer 也有平台的包,这些包是并不是由 Comoposer 安装,它们是安装在操作系统上的东西,Composer 将它们作为虚拟的包,以方便管理。它们包括:PHP 本身,PHP 的扩展,还有一些系统中的库。

1、php 包
代表用户的 PHP 版本,这样就允许你对 PHP 版本定义依赖,比如,“>=5.4.0”。如果必须要 64 位版本的 PHP,你可以依赖 “php-64bit” 这个包。

2、ext-<name> 包
你可以依赖 PHP 的扩展(包括核心扩展)。至于包的版本,这里有很多不一致,建议就用 “*”。比如你的项目用到 GD 库,就可以依赖 “ext-gd” 这个包。

3、lib-<name> 包
你可以依赖一些 PHP 用到的系统库。比如:curl、iconv、libxml、openssl 等。

你可以用命令 “composer show –platform” 查看你本地的有效的平台包。比如我的结果是:

三、指定版本

你需要通过某种方式指定包的版本。不过当你在 Packagist 上发布包时,它会通过 VCS(version control system, 如:git,svn,hg)推断出版本信息,所以这种情况下就不需要指定版本。

如果你手工创建包,则必须指定它的版本,可以用 version 字段:

1、Tags(标签)

对应每个 tag,都会有一个版本的包创建。tag 名称必须匹配 “X.Y.Z” 或 “vX.Y.Z”,还有一些可选的后缀名,如:RC,beta,alpha,patch 等。

这里有些 tag 名称的例子:

2、Branches(分支)

对应每个分支,都会有一个开发版本的包创建。如果分支的名字看起来像个版本的命名,则版本名将会是 “{branchname}-dev”。比如,一个叫 “2.0” 的分支,会得到一个 “2.0.x-dev” 的版本(“.x” 是因为技术原因而添加的,目的是让它看起来像个分支,“2.0.x” 这种分支也是有效的,也会被转换为 “2.0.x-dev”)。

如果分支名看起来不像版本号,它的版本名会是 “dev-{branchname}”。比如,master 分支的版本名为 “dev-master”。

(注:如果你安装一个开发版本,Composer 将会从来源来安装它)

3、Aliases(别名)

可以将分支名化名为版本名。比如,你可以将 “dev-master” 化名为 “1.0.x-dev”,以后你可以在其他包里依赖 “1.0.x-dev”。

四、锁文件

如果你愿意,可以为你的代码库提交 “composer.lock” 文件。这可以保证你的团队始终在测试同一份依赖的包,不会因为依赖的包的更新带来干扰。但是,这个锁文件不会对其他依赖它的项目造成任何影响,它只影响当前这个项目。

五、发布到 VCS(版本控制系统)

如果你的 VCS 中有一个项目含有 “composer.json” 文件,那你的库已经可以被 Composer 安装了。下面这个例子,假设我们在 GitHub 上发布了 “acme/hello-world”,位置在 “github.com/username/hello-world”。

我们在本地创建一个项目,我们叫它 “acme/blog”。这个项目将依赖 “acme/hello-world”,而后者又依赖了 “monolog/monolog”。我们可以通过下面一两步完成这些处理。

先创建个 “blog” 目录,里面创建个 “composer.json” 文件:

”name“ 字段在这里不是必须的,因为我们没想要将它发布为一个库。

然后我们要告诉这个博客应用怎么去找 ”hello-word“ 这个依赖。我们可以添加一个包的仓库定义语句到 ”composer.json“:

OK 了。现在你可以运行 Composer 的 ”install“ 命令来安装依赖。

(再次提醒:任何 git/svn/hg 仓库,如果含有 ”composer.json“,就能添加到你的项目中,只要你指定包的仓库地址,并声明依赖它)。

六、发布到 Packagist(packagist.org 这个网站)

好了,现在你能够发布你的包了。但是每次指定 VCS 仓库会显得很笨重。而且你也不想强迫你的用户来做这事情。

有件事你可能注意到了,就是上面例子中,我们没有指定 ”monolog/monolog“ 的仓库。那它是如何工作的?答案就是:Packagist。

Packagist 是 Composer 的首要的包的仓库,而且这个仓库默认就是可用的,不需要额外定义。任何发布到 Packagist 的包都能被 Composer 自动使用。monolog 就是在 Packagist 上,所以我们依赖它,可以不需要添加一个额外的仓库地址。

如果你要和世界分享你的 ”hello-world“,你可以将它发布到 Packagist。很简单的。

 

题图:《the house of the famous composer》by ali

Google AppEngine 适合托管 PHP 应用么?

php-gae

翻译一段 GAE 托管 PHP 应用的利弊分析文章。以下为内容。

 

你也许想知道,AppEngine 是否真的对 PHP 网站支持的很好。

现在,GAE 将官方的 PHP-5.4 定制和整合到 Google 云平台。很多常用的扩展已经编译进去,当然,不是所有。

这当然是一个有约束的环境,所以你别指望所有 PHP 特性都能用上。GAE 环境和常规环境会存在一些差异,有利的和不利的都有。

还没有人把真正的使用报告给出来,差异肯定比我们想象的要多,我们可以先从官方文档中观察出一些差异。

有利的:

1、几乎无穷的扩张能力

如果你的站点出现了一个请求的高峰,理论上 AppEngine 会处理这些负载。如果是常规环境下,你就需要小心地添加一些服务器并且分发那些请求到这些服务器上。

2、自动备份

AppEngine 会自动备份你的应用和数据库,你也可以按需要定制备份计划。

3、分布式的 session

AppEngine 模拟了一个 memcached 服务,不管你的应用代码在不在同一台机器,你都可以存取数据。

通过这样来存取 session 数据,比 PHP 原生的本地文件的实现方式要好多了。

4、任务队列

AppEngine 提供了队列接口,你可以将脚本的执行延迟到后端进程。为了方便队列的使用,官方已经提供封装好的类库。

你还可以安排任务的执行时间表,就像使用 crontab 一样。

(译者注:任务队列确实是普通虚拟主机提供商不能提供的东东,嗯,还有 memcached 服务。备份还好说,无穷的扩展能力,一般小站还不奢望能用上。)

不利的:

1、没有本地文件系统可以用了

很多 PHP 应用都是可以读写自己的文件的,比如配置文件、用户上传的文件。这些数据现在都是通过特殊的文件流句柄写到云存储服务中了。

你就不能用 require 或 include 去执行动态创建的文件了。虽然看起来,这提高了安全性,但也给很多 PHP 应用强加了限制。

举个栗子,很多 PHP 应用都用到模板引擎,模板引擎的实现就是将模板文件解析为可执行的 PHP 文件,在显示页面时 include 这些解析好的 PHP 文件。所以很多模板引擎就不能用了。还有,类似 WordPress 自动升级的功能也就跑不起来了。

解决方案似乎也有,把云存储上的文件读取下来,然后赋值给变量,然后用 eval 去执行。当然,很多应用根本还不会这样工作。

(译者注:eval 这种方式太不可取了,可以先放一边。没有本地文件系统确实是硬伤,模板引擎也只能用那些不产生中间文件的。很少有应用是不读写本地文件的,所以要上 AppEngine 的应用都避免不了调整)

2、没有远程资源获取途径(如:sockets、Curl)

至少现在看起来,是不能用 fsockopen 或 Curl 扩展去建立 socket 连接的。

如果要连接到远程站点,你得用 fopen、file_get_contents 等类似函数。

(译者注:这样搞起来,很多远程连接的类库也不能用了,是出于什么目的要禁用这些函数和扩展呢?)

3、URL 由 AppEngine 的配置来映射了,而非 mod_rewrite

因为 AppEngine 运行在 Google 的 Web 服务器上,mod_rewrite 这样的扩展肯定不能用了。

URL 和 PHP 脚本的映射是由特定格式的配置文件管理的,得学。

(译者注:配置文件格式和语法如果和 rewrite 的语法类似,问题倒不大)

4、没有 PHP 错误日志了

至少现在看起来,是没有 PHP 错误日志的入口的。意味着,如果生产环境的 PHP 代码出错了,你会看不到它们。

(译者注:AppEngine 应该提供其他渠道能看到吧?)

 

更多细节可以参考:gaeforphp.appspot.com (官网,被墙了)
文章翻译自:Is Google AppEngine a Good Solution for PHP Application Hosting?

GAE 添加 PHP 支持引发的一波讨论

phptool

5月份的 Google I/O 大会,Google 宣布 GAE(Google App Engine)将支持 PHP。

这一支持,引发了一波针对 PHP 的讨论,有些唱衰 PHP 的人就说是 Google 挽救了 PHP,不然 PHP 就快挂了;有些看了唱衰的文章的人觉得看不下去了,于是也长篇大论地开始反驳。

唱衰的文章有篇国内已经翻译了,原文叫《Google Pries Another Nail From PHP’s Coffin》,在 CSDN 上被翻译为《拯救行将就木的PHP:谷歌为GAE添加PHP支持》。文中引用的主要证据是:去年 StackExchange 的联合创始人 Jeff Atwood 罗列了 “若干希望PHP死亡的声明”,他呼吁开发者帮助其改进其它编程语言以替代 PHP。但仅凭这点真的没啥说服力,其实有点标题党。

反驳的文章,有一篇《5 Reasons Why the Web Platform War is Over: PHP Won with 75% says Google》,即《5 个理由说明为什么 Web 平台战争已经结束了:因为 Google 说 PHP 赢得了 75% 的份额》。咋一看,似乎也是标题党,不过作者还是较理性地阐述了一遍,论据比较充分。

这篇文章国内没有翻译,那怎么行,唱衰的有人翻译,反驳的怎么能没人翻译,就信息失衡了!开个玩笑,我翻译是因为,文章信息量较多 ,可以分享。文章太长,这次先翻译一部分:PHP 赢得 Web 平台战争胜利的 5 个理由。以下为译文。

 

事实上,根本没有 Web 平台的战争,至少对大部分 PHP 开发者来说是这样的。

事实这样的,PHP 聚集了大量的人气,然后那些选择了其他编程语言的人经常会陷入反对 PHP 的争论中,因为 PHP 的流行会减弱他们所选编程语言能更流行的机会。因此在这些选择其他编程语言的人的脑子里,他们进入了一场反对 PHP 的战争。

(译者注:这里所说的选择了其他编程语言的人,其实并不是指全部,我认为应该是指其中的没理解编程的人,理解编程的人,没有语言之争,因此,PHP 的开发者中也有很多初级的没理解编程的人。不是语言的问题,是人对编程的理解问题。当然,因为自己所选的语言没另一门流行而信心不足,或者太喜欢一门语言中的一些特性而另一门里面没有,因此而反对另一门语言,也是可以理解的。)

1、Google 知道真实的数据,因为它的机器人蜘蛛爬行了整个 Web

Google 爬行了整个 Web,它可以很容易地知道每个网站用的是什么语言。大多数用 PHP 的网站的响应会包含类似这样的头:
Server: Apache/2.2.8 (Unix) PHP/5.3.11

虽然有些站点可能隐藏了这样的头信息,但是大部分不会。

现在,Google 计算出有 75% 的网站是运行 PHP 的,这是铁一样的事实啊。

2、Google 并没有多少影响 Web 开发者

GAE 一开始就支持了 Python,5 年时间下来,如果说 Google 是想影响 PHP 开发者转投 Python,并使用 GAE,现在从结果来看,Google 对开发者的影响确实不大。

3、Wordpress 已经是统治地位的博客平台了

PHP 如此成功的一个原因是杀手级应用:Wordpress。

WordPress 的扩展性非常强,它还可以做博客之外的几乎任何东西,插件非常丰富。它的代码可能不是很漂亮,特别是对有洁癖的程序员来说,但这没关系。很多从事其他语言的开发者也在用 WordPress。

WordPress 不仅是个应用,也是个生态系统。人们基于它来开发站点,PHP 招聘中常常有招会 WordPress 的。

同样,Drupal、Joomla,等等流行的 PHP 应用,都是可以提及的。

WordPress 的社区和 PHP 的社区几乎没啥相干,似乎 WordPress 社区的事件更能引起轰动。所以说 WordPress 对 PHP 很重要。

4、编程并不一定要代码写的漂亮

(译者注:这一段讨论了很多关于编程的话题,比如 PHP 的代码为什么这么招人诟病。我打算另外写一篇文章讨论,所以这里先不翻译了)

5、PHP 的攻击者的关注点是错误的

列举了一些攻击 PHP 的文章,其中最有杀伤力的还是 Jeff Atwood 的那篇文章。这段内容也和 “4” 一起,放到下次的文章中。