Lucene 2.0 has been released.
This is mostly a bugfix release from release 1.9.1. Note however that deprecated 1.x features have now been removed. Any code that compiles against Lucene 1.9.1 without deprecation warnings should work without further changes with any 2.x release. For more information about this release, please read CHANGES.txt.
Binary and source distributions are available here.
1、《软件构架师的特点》，不错的文。
来自于 Rational Edge：在电影制作术语中，软件项目经理被称作制作人，因为他们决定需要做什么事情。而软件构架师就是导演，他来决定所作的事情是否正确，并且他要保证产品符合投资人的要求。
篇文章是关于软件构架的系列文章（共四篇）中的第二篇。上个月，这个系列文章中的第一篇给构架作了一个定义。因此现在我们可以把注意力集中到创建构架的人员——构架师身上。软件构架师被证明是软件开发项目过程中最具挑战性的角色。软件构架师是项目的技术领袖，并且从技术角度来讲，他承担了项目成败的责任。
下面是电气及电子工程师协会给“构架师”做的定义：
[构架师是]负责系统构架的人，团队或者组织。
作为项目的技术主管，构架师的技术需要非常的广泛，这比技术深度更加重要（当然构架师在特定的领域需要一定的技术深度）。[....]
2、《面向方面的编程：它的好处是什么？》
来自于 Rational Edge：关于面向方面的编程的大多数介绍，都是建立在技术可行的有限环境的基础之上，而忽略了AOP的实际价值。这篇文章提供了将AOP技术应用于软件开发项目的一系列实际的例子。
最近，我被要求领导我们软件工程研究小组（SERG）开一个关于面向方面的编程（AOP）的讨论。在会议开始前的几小时，一个学生问我：“那么，方面的好处是什么？但是不要给我关于日志的例子。那似乎是我阅读关于方面的东西时，唯一看见的东西。”
他的问题促使我停下来，并考虑将AOP应用于一些正在做的软件系统的有效方法。他同时也使我认识到需要如何和什么时候采用新的方法，尤其是当他们需要一个新的思考方式时。AOP，我之前在这个专栏已经谈论过，它似乎代表了一个新方法。我想谈论一些我认为AOP可以被（或已经被）有效使用的方法。同时我们将看到一些可能有助于AOP推广的最新进展。[....]
PostgreSQL minor versions 8.1.4, 8.0.8, 7.4.13 and 7.3.15 have been updated to address a SQL injection vulnerability, for applications that embed untrusted input directly into SQL statements (i.e., avoiding the PreparedStatement facility for escaping input).
和 MySQL 的 SQL 注射类似，假设有如下代码：
<?php
$sql = "select * from users where username='".$username."' and password='".$password."'";
//....
?>
那么在填写密码的时候使用 "a' or username like '%' or password like '%"，这样 SQL 语句就变成了：
select * from users where username='a' and password='a'
or username like '%' or password like '%'
这样就可以绕过密码检测了。
不过这个问题很容易解决，可以使用 prepare statment 的方式（PHP 调用 pg_prepare() 函数）解决，也可以通过用户名取出密码，然后再做字符串的比较，个人觉得，预防 SQL 注射，主要还是在编码者，当然相应的语言也应该提供简单方便的函数以供调用。
官方的解决办法更加具体：
Q: What else can I do to foil SQL injection attacks?
A: There are quite a number of steps you can use to foil SQL injection attacks in addition to these updates, which are things security-conscious application developers should be doing anyway:
- Employ a good database security design, in which restrictive database permissions are assigned to public database roles.
- Use parameterized prepared statements to execute queries (e.g. "SELECT * FROM table WHERE id = ?") (please note that PHP does not have proper support for this feature earlier than v5.1)
- Use stored procedures to execute queries from web applications, instead of sending them directly to the database.
- Hash or encrypt valuable data in the database.
过了这么久，今天总算可以发布百度 MP3 批量下载程序 v2.2.0 了。
ChangeLog
这几天不少同学在 phpe.net 上对 DiggMore & Zend Framework 进行了激烈的讨论，这里需要先对 DiggMore 说明一下。最初对 DiggMore 的想法是因为 binzy 和我都觉得我们应该提供一个平台，让国内的 phpers 能够通过这个平台了解到 PHP 相关的各方面咨询，甚至可以在此基础上进行交流讨论，为国内 phpers 的共同进步而努力。通过交流，我们觉得 Digg 的方式非常合适，可以让大家都参与进来，也可以让有用的信息上浮。正当我们准备开始 DiggMore 的工作时，Zend Framework 恰好发布，这也是一个机会，可以在 DiggMore 的开发中顺带应用 ZF，但是，ZF 并不是这个项目的全部，我们可能会用到 ZF 的 Controller、DB、Feed 等等，但我们不想让 DiggMore 强依赖于 ZF。接下来就是这个上面这个帖子讨论的问题了，ZF 的 Controller 并不能让我们满意，因为对于 Action 无法测试，另外正如 binzy 所说：
Zend_Controller_Front作为最前的门面, 缺乏Flexable. 因为很显然你需要根据不同的request去load不同的信息, 去add不同的Zend_Controller_Plugin. 即Zend_Front缺乏可配置性, 从Zend Framework的MailList中可以看到有Configuration相关的Proposal, 但是什么时候出来是另外一回事情了. 所以建议在Zend_Controller_Front前再加一层, 去实现Zend_Front没有做的那些事情, 即Load Configuration, Add不同的Plugins, 即创建Request所对应的Zend_Controller_Front的实例.
这导致了我们开始“改造” ZF 的 FrontController 部分，说是“改造”，但实际上我们并没有“入侵” ZF 的任何代码，在中间增加了 FrontInterface、Action、ResultType 等等接口。
帖子的讨论中让我比较失望的是，我一再地强调减少依赖、松耦合、测试优先等等，但却很少得到回应，而更多的是在讨论 image、js、view 的目录结构问题，我觉得这些目录结构都不是重点，我并不关心这些，因为一个可配置的系统平台，这些问题很容易处理，而且目录结构并没有一个必须遵循的原则，如果说有的话，那就是用户不需要访问到的文件都放到发布目录之外，呵呵，这个也算不上什么大原则。
从讨论中我开始发现其实我们（至少是 phpe 上的 phpers）相对于其它语言的讨论落后了许多，本身 PHP 在 OO 方面起步就比较晚，而 phpers 中实际懂得 OO，晓得设计模式，应用敏捷开发原则的人实在是少之又少，这不免让我对国内 PHP 的发展有些担忧（但愿是杞人忧天）。语言并不是软件开发的障碍，编程思想才是障碍，为什么我们不能多学习一下 Java、C++、.Net 等等呢，比如 Java 方面，已经有很多成熟应用设计模式案例、项目及讨论，而我们还在闭门造车，继续着复制粘贴、重复开发的机械工作。希望 DiggMore 能为大家带来一些启发，即使是一丁点的，我觉得都是成功的，毕竟我们敲开了第一块砖。
