放弃Model对联合主键的支持…
本以为ActiveRecord支持联合主键并不是什么难事,不过,当实现了70%后,发现,不是技术上的问题,而是动机上出现了难易取舍的情况. 考虑到支持关联表, 联合主键并不是如此简单. 虽然多数也已实现,但目前看,造成部分代码的复杂度增加, 而我目前修改的初衷是裁剪和简化,我不想实现一个太重太全的ORM,这是PHP不是Java,我们需要快速和简单.
即便实现了,那么在今后的应用中造成学习曲线的上升, 目前的使用者势必会放弃这些所谓精心实现的”特性”.
所以,放弃了目前的实现, 重新回归到单一逻辑主键的支持上.
毕竟,在web应用场合,多数是逻辑主键的
毕竟, RoR本身也不支持联合主键(虽然可以通过第三方的extension获得支持)
所以, 安慰一下自己
就是可惜了那几千行的新增代码,呵呵, 砍吧.
忙着doggy 1.3开发
最近有点忙, 重写Doggy, 力争月底前完成1.3的第一个版本.
重构doggy的过程中,catalyst的源码也读了不少,有些许收获.
重构是可以说是痛并快乐的,很多事情都是在反复中前进, 所谓螺旋式上升.
一直强调TDD, 没有单元测试,重构是无法进行的.
不知道那些受我鼓吹快1年TDD的同事们能否做到? 严重怀疑…
在重构doggy中,写了不少perl代码, 算是享受. 彻底扔掉Phing了, 嗯,
当初选择Phing是由于需要植入很多java代码, 用多了Ant.
现在这些都被一个个perl小工具取代了.
上个版本用ZDE开发, 由于过多的代码提示, 忽略了最基本的简洁,
现在用TextMate, 虽然没有那么智能的代码提示, 但是更潜心注重代码的质量,开发效率反而提升了…
这是一种风格的转变, 从Java到Perl, 重量,大而全到小巧简单.
轻松一些, coding何必那么累?
因此,我将doggy 1.3的code name称之为:”New Soul”
New Soul && Bloom!
关于Bloom!:
Bloom!是视觉中国网站新社区的项目,也许和豆瓣有点点相似,不过不会是简单的模仿,
更不是ucenter home那种肤浅的克隆…
Bloom!的第一个版本我已经想好了,名字是Daisy.
关于New Soul:
Doggy2 的代码名称
这是为Bloom!重新设计的开发框架, 力求颠覆以前的设计思想, 达到实质的突破.
构建成本高(相对于普通的PHP coder),但是使用成本低(使用预搭建的平台服务).
BTW: 下周想让扑扑给NewSoul和Bloom!设计下logo,那就非常好了.
PS:
1. 感谢 Yael Naim, 感谢 Apple Air, Doggy2 有了满意的名字.
2. 即便无聊透顶,现在非常厌烦去一些什么论坛…. 太多的浮躁
还是自己修炼内功为佳
I’m a new soul I came to this strange world hoping I could learn a bit about how to give and take
But since I came here felt the joy and the fear finding myself making every possible mistakeLa-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-la
La-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-laI’m a young soul in this very strange world hoping I could learn a bit about what is true and fake
But why all this hate try to comunnicate finding just in love is not always easy to makeLa-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-la
La-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-laThis is a happy end cause’ you don’t understand everything you have done why’s everything so wrong
This is a happy end come and give me your hand I’ll take your far awayI’m a new soul I came to this strange world hoping I could learn a bit about how to give and take
But since I came here felt the joy and the fear finding myself making every possible mistakeLa-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-la
La-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-laLa-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-la
La-la-la-la La-la-la-la La-la La-la-la-la La La-la-la La-la-la
doggy和mysqlnd
doggy早期版本使用adodb作为底层数据库的driver,从1.2开始,引入mysqlnd作为新的driver.从1.2.4开始,正式启用mysqlnd为首选的driver.虽然windows下的开发仍使用adodb的adapter,
但是我自己的osx开发环境和正式部署中已经不再使用adodb了.虽然,通过编译php的mysqlnd驱动可以间接
发挥一些Mysqlnd的优势,不过没有充分利用其未公开的特性,为此,我实现了一个mysqlnd的adapter,并不复杂.
经过我的自己测试,以及视觉新系统和老系统的测试,mysqlnd的稳定性和速度,效率都不错.尤其在效率,内存的使用上有明显的改善.
其实,最初使用mysqlnd是因为我自己的osx的开发环境编译mysql ext总出现莫名的问题,包括在Linux的64位上也偶尔
出现一些奇怪的问题,于是就尝试mysqlnd,这下彻底解决了libmysql的一些问题(因为我使用ICC静态编译了mysql,
导致php编译中出现一些问题).
mysqlnd已经加入php 5.3,目前也实现了pdo的driver,相信不久会成为默认的mysql的驱动了.
虽然,mysqlnd仍是beta版,不过从作者的blog的反映以及我自己的实际测试,在生产环境中(至少在doggy框架中)
应用是没有问题的.
我对应用框架的一些思考
关于框架(FrameWork),尤其是PHP开发框架,现在真是漫天飞舞,让人眼花缭乱.想当初我设计第一个所谓的框架时,
PHP可用的框架基本上是空白,所以很多东西是参照Java的特点来作的,那时年轻,也有些轻狂,以为框架就这么容易做出来了.
设计框架会有一些偏差:
首先一个问题,框架=类库的聚合. 这种情况一般是设计者有些代码开发的经验,但是缺乏更广的知识沉淀.不经历风雨怎见
彩虹,如果没有涉足多个领域的痛苦折磨,仅仅在某个,某些项目甚至某个开发语言上有些涉足,就想,框架不过如此而已.于是乎,
框架就在复制粘贴的过程中产生了.
其实,一个框架代表的是一个思想,一种哲学,类库只是这种哲学的附属品罢了.
第二个问题是设计过度,偏离了实用. 这种问题产生于一些比较追求完美主义者甚至是大师,为了完美,设计而设计. 比如spring在最初版本中,
其MVC就有些不太实用的地方,这点对比webwork/xwork就能发现,不过后来随着使用者的增多和流行,这些问题也很快被消除.
看来,实践是检验真理的唯一标准.
上面2个问题在我身上都印证过. 尤其是第二个问题更为明显,自身功力不足,却强行希望看上去很美,导致了现实和理想之间的差距.所以,在doggy之前,
我虽然也自己实验过一些原型,不过很快就被扔掉了.
现在,在作doggy的实现时,我更多的是考虑,哪些功能是确实需要的,哪些是体现我的理念的,后者是首要实现的.
比如,doggy的一个最重要的思想是:支持TDD开发的模式,测试先行,测试驱动. 因此,对于测试的支持是首要必备的,
此外,对于持续构建,项目部署分发,也是实际中很现实的问题,这些也需要重点考虑.
至于扩展性则放在第三位,这里所谓的扩展,并未局限于框架代码本身,而是和整个系统的部署,所谓网站的系统架构上综合考虑的.
例如,在存储层的扩展,是需要考虑能否支持分布式存储,本机开发是一回事,但是能否部署到如mogilefs,hardoop.
如何支持fastcgi的部署,如何最大化利用lighttpd,nginx,varnish.
缓存上,3级缓存中,各级缓存在实际中如何去实现,这些需要doggy去支持,否则就无法扩展系统.
比如,在cms中,多数文章是可以使用静态文件生成,并分发到cdn等负载钧衡网络中,那么如何过期,如何刷新,
则需要考虑cdn网络如何去构建,是用nginx?nfs共享,磁盘阵列gfs?还是用squid,varnish的反向代理?
这些都是doggy需要去考虑的.
当构建web2.0的应用时,需要考虑的是另一种情况,此时,单纯采用静态化已经解决不了问题,那么需要使用
局部缓存,解决并发的数据读写,如何保证数据的实时更新和同步….
再比如,确保应用服务和静态服务的分离,项目的开发和部署的隔离…
因此,对我而言,应用框架需要解决不仅仅是代码层的优化,更要解决的是一些实际的应用.doggy框架,我姑且
仍认为它是一个应用框架,在应用层面则是提供一个解决这些问题的方案,这是我所关注的.
而其他的一些东西,我认为并不重要,比如,url/action的route方式,doggy只支持一种,足够.为什么?因为我可以通过
其他的方式去弥补,比如可以在Nginx的rewrite实现,可以使用lighttpd的lua实现,这些方案的效率远远高于
PHP,那么何必去实现这些吃力不讨好的东西呢.
因此,doggy不是通用的,它需要unix环境,不支持windows的部署,开发环境最佳是linux/osx,window则需要使用cygwin,必须使用一些
定制的pecl extension,PHP需要作一些特定的优化,webserver需要最适合的等等.
也许,我是在自娱自乐,但确实好用.
Imagick进步真快阿
在去年设计Doggy框架时,我选择MagickWand作为主要支持的图片操作的extension库.
当时列入我眼中的候选有magickwand和imagick. 有人可能会说,为什么不用gd2?
因为gd不论是性能还是功能都太弱了,作为普通的图片处理可以勉强胜任,但是如果需要实现类似flickr那样
的图片处理任务就歇菜了. 而ImageMagick则是很好很强大,可以轻易将很红很创意的图片变成
很黄很暴力,呵呵.
当时imagick使用的人很少,而且稳定性也不高,对于magickwand,我以前则用过,因此就选择了magickwand for php.
不过当时对于magickwand并不满意,因为其实它不过是magickwand的一个wrapper而已.
和gd一样需要resource handler, 并不符合我喜欢的OO的精神.
这几天又重新看了下imagick,版本升级到2.x,功能也改进很多.从作者的博客上看了些介绍,让我有些心动了.
由于是PHP native的extension,使用上也是OO,而且可以继承并扩展原生类,这点确实够诱惑,够强大.
计划假期启动doggy2的设计,我想是不是考虑换成imagick呢
Doggy2 Plan
Doggy 是视觉全部平台的核心框架。目前使用的版本是v1.1, 正在开发的是v1.2
Doggy框架目前主要由我设计和维护。本来这篇日志应该放到我的技术blog中，不过天生的懒人，实在懒得去了，
以后就都在这里记录了。
Doggy设计的原则是适用于大型互联网应用的快速开发，和FleaPHP,ThinkPHP不同的是，Doggy注定是一个定制的框架，
扩展和高效是首要的原则，在此基础上，一些通用性将被舍弃，同时，注重网站架构也排在前列，从而构建一个可以良好的，高扩展性
的应用。
Doggy初期的学习曲线会很高，尤其是对于传统的PHP开发者来说更是如此。设计中借鉴了java,ror等的优点。
2.0 目前考虑的特性
－ 实现Dispatcher层的Restful
原计划在1.3中的Rest特性延迟到2.0
－ 基于Unix脚本的快速开发和部署
目前1.x是基于Phing方式的代码生成和部署。由于window的特点，在window下效率较低。因此，需要转移到Cygwin环境，使用
unix工具进行测试单元生成，项目部署，代码框架生成等工作。(我使用的mac osx,使用unix环境非常舒服，而其他兄弟虽然用windows，
通过cygwin也能享受到unix环境的便利。btw，如果osx能够成功安装到pc上，也许都会转到osx上，毕竟TextMate实在是一种享受)
－ 使用PHP5.3的namespace等特性重构代码
2.0的doggy应该是基于php5.3
－ 支持ICE
1.0版本中被移去的ICE的支持将被重新加入，这样PHP可以快速享受Java的服务,
比如我最感兴趣的是分布算法，分布存储。
－ 使用Extension重新部分核心代码
通过对1.0的profiling，继续进行代码优化，将部分代码使用c重新写，这点应该和SPL类似，首先使用php代码实现原型，
然后用c重新在extension中实现。
－ IM
支持Jabber/MSN/Gtalk等IM，为开发IM客户端提供底层支持
－ 实现一些开源的协议，如openid
－ 文本聚类
如果有时间，会考虑完善一些分词和聚类的东西
－ 强化TDD开发规范
和国内一些框架不同，Doggy的一个重要特点是测试驱动的框架，在2.0中，将为TDD提供更多的便利。
－ 引入其他优秀框架的特性
我比较关心的是RoR.
由于Doggy2需要使用PHP5.3的特性，因此，具体的发布时间不会太早（初步定是08年10月份左右？)。
在2.0未发布前，我会将一些特性backport到1.x版本中。
Doggy2 的目标是能够让视觉中国拥有像豆瓣那样强大的后端处理技术和引擎。