PHP

PHP的使用门槛非常的低，而且通常用PHP写出来的东西代码都不是那么的“漂亮”。于是有些人将PHP看成是业余程序员用的东西。然而就是这么一个看似不怎么专业的东西统治了大半个互联网。PHP的“哲学”是“quick and dirty”。在一定程度上beauty和quick并不容易并存。PHP将quick和简单作为第一要求，代码的漂亮退居第二。dirty的代码并不容易维护，所以通常在系统在复杂后，复杂业务逻辑功能将交由其他技术实现。PHP则安心做着自己表现层的事。

Java

有人说Java是给笨人用的语言。这话虽然很难听，不过在一定程度上这还真就是Java的哲学。Java充分利用语言特性和IDE等自动化工具来避免程序员犯错，让人海战术成为可能。对于大多Java项目只需要少数的牛人来设计系统构架和主要接口，下面的具体实现用“笨人”来做就可以了。

Python

python的哲学是“quick and clean”。在一定程度上说python确实非常clean也很quick。不过python的clean可让也让python变的有些平庸。python号称什么都能做，却又没在哪个领域特别突出。

Ruby

Ruby强调人文关怀，编程是一件有乐趣的事，你可以按照自己喜欢的方式去使用ruby。相对而言ruby可能更容易发挥个人的创造性，但在团队协作时则容易遇到麻烦。

通常情况下用axis开发webservice服务端，需要挂在tomcat等web服务器下，以servlet的方式提供服务。但有些时候我会想将接口部分以一个单独应用程序的方式进行发布，另外再多带个web服务器似乎有些笨拙。

使用嵌入式的jetty是一个比较简单的解决方式。其中需要注意的是，一定要设置Context的ResourceBase，不然是无法找到webservice配置文件的。我当初就是想当然的认为jetty会默认在当前路径下查找配置文件，导致一直无法正确发布服务。

protected static void runJetty() throws Exception {
    Server server = new Server();
    SocketConnector connector = new SocketConnector();
    connector.setMaxIdleTime(30000);
    connector.setPort(8000);//jetty的端口
    server.addConnector(connector);
    ServletHolder axisServletholder = new ServletHolder(new AxisServlet());
    ServletHolder axisAdminServletholder = new ServletHolder(new AdminServlet());
    Context root = new Context(server, "/", Context.SESSIONS);
    root.setResourceBase("./web/");//WEB资源目录，./web/WEB-INF/server-config.wsdd
    root.addServlet(axisServletholder, "/servlet/AxisServlet");
    root.addServlet(axisServletholder, "/ws/*");//设置webservice的发布目录
    root.addServlet(axisServletholder, "*.jws");
    root.addServlet(axisAdminServletholder, "/servlet/AdminServlet");
    server.start();
}

这写天本想给JdbcTemplate做个扩展，让JdbcTemplate自动绑定对象。等写得差不多的时候，很不幸的发现自己只是重复造轮子而已。Spring已经自带了比较完善的解决方案，通过BeanPropertyRowMapper自动绑定数据库的列到对象。BeanPropertyRowMapper的绑定规则是，FiledName相同的绑定，如果绑定失败，将尝试将hiVik转换成hi_vik查找数据库的列。

如果需要查询出一个包含YouVO对象的List只需要做如下操作就可以了。

List objList = DbHelper.getJdbcTemplate().query(sql, new Object[]{}, new BeanPropertyRowMapper(YouVO.class));

最近简单的了解Play!，感觉确实是挺有意思的一个东西。Play!作为ROR“仿制品”，在开发思想方面和ROR还是比较接近。Play!本身提供了不少开发相关的辅助命令。使用命令创建出的新工程直接就可以运行了。相比之下，基于ssh的开发，光是脚手架的搭建就得费不少事。

数据模型方面使用JPA定义数据对象，直接从对象生成数据库。这点和django比较像，这也是比较符合我开发习惯的一个做法。

模板方面和Django类似，支持模板的继承。Django模板的继承给我的体验很好。jsp页面虽然可以使用include实现复用，但对于结构相似的页面依旧需要重复的include。Sitemesh虽然可以实现类似django模板的功能但看到那繁琐的配置我就撤了。

总的来说Play!给我的印象还是挺不错的，希望在日后的工作中可以用到。

其他

Play!的FAQ里有一个解答让我挺印象深刻的。其中有关于为什么使用不符合java规范的play做包名的说明。play!本身就是一个平台，运行在play!上的东西都将是符合play!规范的，所以不必为play这个包名而计较。play!专注于web的敏捷开发，为了适应web敏捷的需要一些无伤大雅的“另类”做法也是未尝不可的。想自己在某些情况下对代码还是有些所谓的“洁癖”。在django开发的时候喜欢在自己的app外面还要另外加一层包，而这种做法在一定程度上是不符合django做法的（django的app名必须唯一，即使上层的包名不同也没用）。