2007/03
11
You can use
Google Earth (
Navigatation plus for Chinese) or
Google Maps (
EEmap.org for Chinese) to see the Earth, but How can I learn the acknowledge in the space.
Kstars is wonderful.
KStars is a Desktop Planetarium for KDE. It provides an accurate graphical simulation of the night sky, from any location on Earth, at any date and time. The display includes 130,000 stars, 13,000 deep-sky objects, all 8 planets, the Sun and Moon, and thousands of comets and asteroids.
Two picture followed:
Figure 1: The sky for current time (13:01:40) in Shanghai, And I can see the Sun above my header.
Figure 2: The sky for this night time(04:09:56), And the Moon is the focus.
Figure 3: My constellation: PISCES.
Defined tags for this entry:
linux,
软件
Posted by rollenc
2007/03
10
cn域名现在搞成1块钱，估计也没什么抢头了。但有总比没有好。既然
edong送了5个域名机会，先用掉再说：
- phpfunction.cn 三马说的，要一个php函数网。这个再适合不过了，这个域名留给三马了。
- phplibrary.cn 函数是不够的，library才是我真正想要的。
- php.hi.cn 这个域名比较好玩，也满简短的。hi, php! 很可能近期就会用起来。
- rss.hi.cn 这个域名一注册下来就后悔了，因为是在不晓得可以拿来干嘛。就一个名词RSS而已，也不是我深入的方向。
- pmal.cn 呵呵，从镜子中看，就是LAMP。而且我觉得按pmal排列我需要的知识深度更合适。
Defined tags for this entry:
其他
Posted by rollenc
2007/03
9
在
卓越网购买了两本书，前天下的订单，晚上付款，今天上午拿到手上了。
一本
Head First Design Patterns, 一本是
代码大全（第二版），两本书前段时间都看了会电子版，不过眼睛太累了，还是纸质的要舒服，“养眼”：）
Defined tags for this entry:
学习
Posted by rollenc
2007/03
8
最近学习笔记全部在blog上站看，但是还是会遇到一些名词想记录或者查询一下，找找wiki。s9y本身有一个wiki插件，但是太庞大了，和nl2br，geshi的兼容性也不行，安装之后很打乱很多的地方。
索性，自己做了个简单的，支持wiki的链接就成了。
就像这样：[ [首页|rollenc笔记库] ], [ [系统架构师] ] （去掉[ [之间的空格）
就变成了：
[[首页|rollenc笔记库]], [[系统架构师]]
下载地址Defined tags for this entry:
其他
Posted by rollenc
2007/03
7
整理书签时才发现，
prototype最新版改成1.5了。虽然以前一直用的是1.5的beta版本，但重新过一遍1.5的
Note，发现不少的新东西，其中部分也是以前自己写过相应代码来实现的功能，如String templates等。
以前的JS代码可以修改一下了，对照prototype的实现，看看自己的代码和prototype处理同样的功能上代码级别的差异。
Posted by rollenc
2007/03
4
过年回来，发现我的wiki笔记库访问不了了，告诉我500错误。想了一下，使用的wiki版本也够旧的了，重装一个得。
Dreamhost的一键安装着实不错，备份好配置文件，图片文件夹和数据库，轻轻一点，成功安装。再使用浏览器进入URL简单的配置一下就搞定了，DH也会在文件安装完毕后发送一个配置的方法给你，照做就成。
数据库也是自动升级的。
一切完好。
马上进入
rollenc笔记库。
Defined tags for this entry:
其他
Posted by rollenc
2007/03
4
Containment
＊ 通过包含来实现“有一个／has a”的关系
＊ 在万不得已时通过private继承来实现“有一个”的关系
＊ 警惕有超过约7个数据成员的类
Inheritance
＊ 用public继承来实现“是一个／is a”的关系
＊ 要么使用继承并进行详细说明，要么就不要用它
＊ 遵循Liskov替换原则LSP
＊ 确保只继承需要继承的部分
＊ 不要覆盖一个不可覆盖的成员函数
＊ 把公用的接口、数据及操作放到继承树中尽可能高的位置
＊ 只有一个实例的类是值得怀疑的（特例：单件模式）
＊ 只有一个派生类的基类也值得怀疑 （提前设计）
＊ 派生后覆盖了某个子程序，但在其中没有任何操作，这种情况也值得怀疑
＊ 避免让继承体系过深
＊ 尽量使用多态，避免大量的类型检查
＊ 让所有的数据都是private（而非protected）
知识来源： 《代码大全2》 P143－P148
Defined tags for this entry:
学习
Posted by rollenc
2007/03
4
创建高质量的类，第一步，可能也是最重要的一步是创建一个好的接口。这也包括了创建一个可以通过接口来展现的合理抽象，并确保细节仍被隐藏在抽象背后。
抽象通过提供一个可以让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节。
创建类的抽象接口的指导建议：
＊ 类的接口应该展现一直的抽象层次。
＊ 一定要理解类所实现的抽象是什么
＊ 提供成对的服务
＊ 把不相关的信息装一道其他类中
＊ 尽可能让接口可变成，而不是表达语义
＊ 谨防在修改时破快就口的抽象
＊ 不要添加与接口抽象不一致的公用成员
＊ 同时考虑抽象性和内聚性
良好的封装的指导建议：
＊ 尽可能地限制类和成员的可访问性
＊ 不要公开暴露成员数据
＊ 避免把私用的实现细节放入类的接口中
＊ 不要对类的使用着作出任何假设
＊ 避免使用友元类（friend class C++）
＊ 不要因为一个子程序里仅使用公用自程序，就把它归入公开接口
＊ 让阅读代码比编写代码更方便
＊ 要格外警惕从语义上破快封装性
＊ 留意过意紧密的耦合关系
知识来源：《代码大全2》 P133-143
Defined tags for this entry:
学习
Posted by rollenc
2007/03
3
1. 文档缺少。 manual中个实例过于简陋，不足以得到一个中级应用的参考。
2. API复杂且没有组织好。感觉像是PHPDOC工具生成的，但是没有给出PHPDOC的标识。但多个类函数混杂在一起，比如Model中混杂了model_php4.php和model_php5.php.导致了不少歧义和重复。
3. 代码级混乱。cakePHP是以MVC面向对象为主导思想的，但是其内部在类的访问控制上却很混乱，经常可以在外部直接访问对象的私有属性和方法。举例有cake_1.1.13.4450 » cake » libs » model » datasources中的
read方法，在
544行使用$model->__associations。这从语法上来讲就是错误的。
一个好的框架应该不需要去看代码甚至不需要看自动生成的API就能正确使用的，，如
Smarty，直接看一遍Manual就可以使用了。Smarty没有生成code API给他的使用者。如果需要这一级的API，开发使用PHPDOC就可以了。Smarty的代码我一直没有去多看，就因为她的Manual太好了。
Defined tags for this entry:
PHP
Posted by rollenc
2007/03
3
＊ 辨识对象及其属性（method && data）
＊ 确定可以对各个对象进行的操作
＊ 确定对象的哪些部分对其他对象可见——public && private
＊ 定义每个对象的公共接口public interface
这些步骤并无须以特定的顺序来完成，需迭代。
知识来源： 《代码大全2》 P88-89
Defined tags for this entry:
学习
Posted by rollenc
2007/03
3
1. 寻找显示世界中的[[对象]] FFind Real-World Objects 相关：
使用对象进行设计的步骤
2. 形成一直的抽象 Form Consistent Abstractions （在子程序接口、类接口的以及包接口的层次上进行抽象）
3. [[封装]]实现的细节 Encapsulate Implementation Details
4. 当[[继承]]能简化设计时就继承 Inherit －－ When Inheritance Simplifies the Design
5. 信息隐藏 Information Hiding （隐藏复杂度，类的接口应该尽可能少的暴露其内部工作机制）
6.
找出容易改变的区域 Identify Areas Likely to Change
7. 保持松散[[耦合]] Keep Coupling Loose （耦合标准： 规模，可见性。灵活性； 耦合种类：简单数据参数耦合，简单对象耦合，对象参数耦合，语义耦合）
8. 查阅常用的[[设计模式]] Look for Common Design Patterns
9. 高[[内聚|内聚性]] Aim for Strong Cohesion
10. 构造分层结构 Build Hierarchies
11. 严格描述类契约 Formalize Class Constracts
12. 为对象分配职责 Assign Responsibilities for Objects （每一个对象该对什么负责，这个对象应该隐藏些什么信息）
13. 为测试而设计 Design for Test
14. 避免失误 Avoid Failure
15. 有意识地选择绑定时间 Choose Binding Time Consciosly ()
16. 创建中央控制点 Make Central Points of Control
17. 考虑使用蛮力突破 Consider Using Brute Force （拿不准时，用蛮力解决 ——Butler Lampson）
18. 画一个图 draw a Diagram
19. 保持设计的模块化 Keep Your Design Modular
知识来源： 《代码大全2》 P87-110
Defined tags for this entry:
学习
Posted by rollenc
2007/03
1
Identify Areas Likely to Change
1.找出看起来容易变化的项目
如果需求做得很好，那么其中就应该包含一份潜在变化的清单，以及其中每一项变化发生的可能性。如果需求中没有包含潜在变化，那么参考下面的“在任何项目中都容易发生变化的区域”；
2.把容易变化的项目分离出来。把第一部中找出的容易变化的组件单独划分成类，或者和其他容易法神变化的组件划分到同一个类中；
3.把看起来容易变化的项目隔离开来。设法设计好类之间的借口，使其对潜在的变化不敏感。设计好类的接口，把变化限制在类的内部，且不会影响类的外部。任何使用将会变化的类的其他类都不会察觉到变化的存在。类的接口承担保护类的隐私指责，即封装变化。
在任何项目中都容易发生变化的区域：
1. 业务规则 很容易成为软件频繁变化的根源。
2. 对硬件的依赖性。
3. 输入和输出。
4. 非标准的语言特性。
5. 困难的设计区域和构建区域。
6. 状态变量
不要使用boolean变量作为状态变量
使用访问器子程序取代对状态变量的直接检查
7. 数据量的限制
找出容易变化的区域的办法：
1. 首先找出程序中可能对用户有用的最小子集。这一子集构成系统的核心，不容易发生改变；
2. 接下来，用微小的步伐增量扩充这个系统。
3. 当考虑功能上的改变时，同样也要考虑质的变化：比如多线程安全，程序本地化等。
4.潜在的改进区域构成了系统中的潜在变化，请依据信息隐藏的原则来设计这些区域。
通过首先定义清楚核心，你可以认清哪些组件属于附加功能，这事就可以把它们提取出来，并把它们的可能改进隐藏起来。
知识来源： 《代码大全2》 P97－99
Defined tags for this entry:
学习
Posted by rollenc
2007/03
1
几经周折，一路颠簸的，终于到了上海。
毕竟是到达了，其他的，都是后话了。
希望07年不顺利事情都集中在这个开头，以后可以一直的开开心心。
Defined tags for this entry:
生活
Posted by rollenc
