Ruby on Rails
2006年第45周杂事
deminy 在 周日, 2006-11-05 17:05 提交
2006-11-01 （周三）
我曾说过，写本书是我的未来理想之一；我也曾说过，2007年我的计划之一就是写本自娱自乐的书。
这天晚上，首次安装CTeX，一个关于文字排版工具LaTeX的中文套装软件，并初步开始写书的草稿。书名还没想好，章节还未划分清楚，也还没想好找谁作序……简而言之：一切还未正式开始。
在此之前的一个星期，顾东东同学有意邀我参与写一本书中的一小部分。我对他说，“我把写书看成一个严肃的事情”。我也是这么着看待我未来将出炉的这本书的，虽然只是玩玩而已。我有句个人口号常挂在心里，就是“做最专业的菜鸟”。我对很多事情感兴趣，不可能每样都做得很好。但只要我用心去做，在我能力、精力范围之内，我就要尽量做得比一般人更专业、更好。
至少，我要能感受到在这个过程中（学习）的乐趣所在。
2006-11-02 （周四）
有些无聊，于是，下午买了一箱啤酒。结果一天半的时间里喝了10余瓶。
于是再次感觉自己很没品位。
关于品位这个话题，等以后我有品位了再详细讨论。
2006-11-03 （周五）
虽然在此之前的几天初次阅读了CakePHP的在线手册，但直到这天晚上才下载、安装、测试CakePHP。按照在线手册的说明，建了一个简单的网志(blog)程序来尝试CakePHP的一些特性。随后第二天（周六）中午又看了几部CakePHP的视频教程。
去年，在谈到Ruby on Rails的时候，我曾经用“震撼”一词来形容该技术给我的冲击力。现在，我想再次用“震撼”一词来形容CakePHP给我的感受。
除了在语言编码方面还有明显需要改进的地方外，CakePHP正是我目前想要的那种东西。
我曾说过，写本书是我的未来理想之一；我也曾说过，2007年我的计划之一就是写本自娱自乐的书。
这天晚上，首次安装CTeX，一个关于文字排版工具LaTeX的中文套装软件，并初步开始写书的草稿。书名还没想好，章节还未划分清楚，也还没想好找谁作序……简而言之：一切还未正式开始。
在此之前的一个星期，顾东东同学有意邀我参与写一本书中的一小部分。我对他说，“我把写书看成一个严肃的事情”。我也是这么着看待我未来将出炉的这本书的，虽然只是玩玩而已。我有句个人口号常挂在心里，就是“做最专业的菜鸟”。我对很多事情感兴趣，不可能每样都做得很好。但只要我用心去做，在我能力、精力范围之内，我就要尽量做得比一般人更专业、更好。
至少，我要能感受到在这个过程中（学习）的乐趣所在。
2006-11-02 （周四）
有些无聊，于是，下午买了一箱啤酒。结果一天半的时间里喝了10余瓶。
于是再次感觉自己很没品位。
关于品位这个话题，等以后我有品位了再详细讨论。
2006-11-03 （周五）
虽然在此之前的几天初次阅读了CakePHP的在线手册，但直到这天晚上才下载、安装、测试CakePHP。按照在线手册的说明，建了一个简单的网志(blog)程序来尝试CakePHP的一些特性。随后第二天（周六）中午又看了几部CakePHP的视频教程。
去年，在谈到Ruby on Rails的时候，我曾经用“震撼”一词来形容该技术给我的冲击力。现在，我想再次用“震撼”一词来形容CakePHP给我的感受。
除了在语言编码方面还有明显需要改进的地方外，CakePHP正是我目前想要的那种东西。
类别:
"Ruby on Rails"技术观后感 (3)
deminy 在 周五, 2005-11-25 14:40 提交
从拨号上网时代开始过渡到DSL/ISDN等宽带上网时代的时候，我们意识到要要提高下载速度，这时候大多数人选择的是等待硬件提升或者新一代的高速网的出现。但有一个人，在现有技术的基础上，选择了走另外一条文件下载思路：基于点对点(p2p)的BT技术。依照同样的思路，还有一个人，选择了另外一种流媒体传输思路：CoolStreaming。他们的技术非常成功。
我们都在思考如何能够更好地提高开发效率，减少重复劳动，我们也知道各种框架模型：CS（客户端/服务器端）、BS（浏览器端/服务器端）、三层、MVC(模型-视图-控制)等，但我们没有能够从这些模型中把他们的共同点更好地抽象出来并且付诸实现。但有一个人，他做到了这一点，于是众人瞩目的"Ruby on Rails"出现了。
我们都拥有同样的资源，拥有类似的知识，但是，却有着不同的成果。
拥有思想比掌握某一门具体语言1重要，比掌握某一门具体技术更重要。一个人可能很精通几门编程语言，但他的水平也就仅仅限于编程，仅仅限于一个程序员的水平了。如果你只想着怎么更好地掌握和运用一门语言，你就永远只是一个程序员的水平。
语言其实是一件不重要的东西。
[注1] 这里的“语言”指编程语言，不是指自然语言。
我们都在思考如何能够更好地提高开发效率，减少重复劳动，我们也知道各种框架模型：CS（客户端/服务器端）、BS（浏览器端/服务器端）、三层、MVC(模型-视图-控制)等，但我们没有能够从这些模型中把他们的共同点更好地抽象出来并且付诸实现。但有一个人，他做到了这一点，于是众人瞩目的"Ruby on Rails"出现了。
我们都拥有同样的资源，拥有类似的知识，但是，却有着不同的成果。
拥有思想比掌握某一门具体语言1重要，比掌握某一门具体技术更重要。一个人可能很精通几门编程语言，但他的水平也就仅仅限于编程，仅仅限于一个程序员的水平了。如果你只想着怎么更好地掌握和运用一门语言，你就永远只是一个程序员的水平。
语言其实是一件不重要的东西。
[注1] 这里的“语言”指编程语言，不是指自然语言。
类别:
"Ruby on Rails"技术观后感 (2)
deminy 在 周四, 2005-11-24 09:35 提交
看完"Ruby on Rails"后，Deminy产生了一个问题：怎样把"Ruby on Rails"的概念移植到PHP中，构建(所谓的)"PHP on Rails"呢?1
这个思路是可能行得通的。
首先，"Ruby on Rails"是基于Rails架构、用Ruby这样一个面向对象(Object Oriented)的编程语言实现的。PHP是一个面向过程(Procedure Oriented)的编程语言，但也是一个面向对象的编程语言。既然"Ruby on Rails"可行，"PHP on Rails"也应该是可行的。
其次，一项技术的竞争力和难点往往在于它的设计，而不在于它所依赖的编程语言。就像新产品最难的地方往往是设计，而不是投产（所以新产品设计出来后，马上就可能出现很多仿造的产品）。类似地，当"Ruby on Rails"被设计出来了，人们很容易把这项技术类似地推广到"Java on Rails"、"PHP on Rails"等。
基于上面两点分析，通过Internet搜索，可以发现如下五项主要的"PHP on Rails"技术可以考虑：Biscuit、PHP on TRAX、TaniPHP、Cake、Symfony 。暂无时间测试它们，无法评价。但目前似乎Biscuit相对要更成熟点。
[注1] 也许有人会问，既然已经有了"Ruby on Rails"，干嘛还要研究"PHP on Rails"呢？原因有好些，其中一个合理的原因是：不愿意为了实施一项技术而要求所有相关技术人员多学一门无太大意义的语言。
[注2] 接前文“'Ruby on Rails'技术观后感 (1)”。
这个思路是可能行得通的。
首先，"Ruby on Rails"是基于Rails架构、用Ruby这样一个面向对象(Object Oriented)的编程语言实现的。PHP是一个面向过程(Procedure Oriented)的编程语言，但也是一个面向对象的编程语言。既然"Ruby on Rails"可行，"PHP on Rails"也应该是可行的。
其次，一项技术的竞争力和难点往往在于它的设计，而不在于它所依赖的编程语言。就像新产品最难的地方往往是设计，而不是投产（所以新产品设计出来后，马上就可能出现很多仿造的产品）。类似地，当"Ruby on Rails"被设计出来了，人们很容易把这项技术类似地推广到"Java on Rails"、"PHP on Rails"等。
基于上面两点分析，通过Internet搜索，可以发现如下五项主要的"PHP on Rails"技术可以考虑：Biscuit、PHP on TRAX、TaniPHP、Cake、Symfony 。暂无时间测试它们，无法评价。但目前似乎Biscuit相对要更成熟点。
[注1] 也许有人会问，既然已经有了"Ruby on Rails"，干嘛还要研究"PHP on Rails"呢？原因有好些，其中一个合理的原因是：不愿意为了实施一项技术而要求所有相关技术人员多学一门无太大意义的语言。
[注2] 接前文“'Ruby on Rails'技术观后感 (1)”。
类别:
"Ruby on Rails"技术观后感 (1)
deminy 在 周三, 2005-11-23 20:21 提交
"Ruby on Rails"是近期（或者说今年）很热的一个web技术话题，简单的来说它就是一项web快速开发技术。它基于MVC (Model-View-Controller，模型-视图-控制)的架构进行设计，遵循两大设计理念：不重复工作 ("Don't Repeat Yourself")和墨守成规 ("Convention Over Configuration")。
晚上Deminy访问了"Ruby on Rails"官方网站，下载了几部视频教程，阅读了几份相关文档，大致了解了"Ruby on Rails"的思路和结构。看完之后的感觉是：震撼。
以前(指2001年前后)在讯能(TOM)工作的时候，时时都有好些项目要做，但很多项目是一种很重复的行为：在web上实现对数据库的各种操作。当时，孙翯就和我说，要设计一个系统，可以（在相当程度上）自动完成很多这些重复的工作，提高开发效率2。我对此也深有同感，但要从需求各异的项目中把它们的共性高度抽象出来，然后基于此设计出一套可重复使用的架构，难度很高。
"Ruby on Rails"的思路和孙翯的想法是类似的，但做得极其出色。"Ruby on Rails"是一项高超的设计艺术。这种设计艺术，是目前(暂时)中国人在技术上想得到、但往往做不到的设计艺术。
[注1] 相关网址:
IBM网站对"Ruby on Rails"的介绍 (中文。IBM总是提供很完善的技术资料)
Wiki百科上对"Ruby on Rails"的介绍 (英文)
"Ruby on Rails"官方网站 (英文)
[注2] 后来孙翯为此做了一个框架，用在一些小型、简单项目的开发上。
[注3] 下接后文“'Ruby on Rails'技术观后感 (2)”。
晚上Deminy访问了"Ruby on Rails"官方网站，下载了几部视频教程，阅读了几份相关文档，大致了解了"Ruby on Rails"的思路和结构。看完之后的感觉是：震撼。
以前(指2001年前后)在讯能(TOM)工作的时候，时时都有好些项目要做，但很多项目是一种很重复的行为：在web上实现对数据库的各种操作。当时，孙翯就和我说，要设计一个系统，可以（在相当程度上）自动完成很多这些重复的工作，提高开发效率2。我对此也深有同感，但要从需求各异的项目中把它们的共性高度抽象出来，然后基于此设计出一套可重复使用的架构，难度很高。
"Ruby on Rails"的思路和孙翯的想法是类似的，但做得极其出色。"Ruby on Rails"是一项高超的设计艺术。这种设计艺术，是目前(暂时)中国人在技术上想得到、但往往做不到的设计艺术。
[注1] 相关网址:
IBM网站对"Ruby on Rails"的介绍 (中文。IBM总是提供很完善的技术资料)
Wiki百科上对"Ruby on Rails"的介绍 (英文)
"Ruby on Rails"官方网站 (英文)
[注2] 后来孙翯为此做了一个框架，用在一些小型、简单项目的开发上。
[注3] 下接后文“'Ruby on Rails'技术观后感 (2)”。
类别:
