Dreamer's Blog

PHP 截取HTML串

Dreamer — Wed, 19 Nov 2008 17:57:23 +0800

需求：将一段文字截取一定的物理长度显示，注意，要截取的不是字符串的字节数，UFT-8 的编码中文字符是3个字节或者4个字节的，而显示的时候中文会占两个字符的长度，英文字符只占一个，全角的时候又有不同。而且给的数据是HTML代码串，比如这样：

<div class=”aaa”><a href=”/aaa.php?id=1″>张三</a> 评论了 <a href=”/aaa.php?id=444″>李四</a> 分享的 <a href=”bbb.html”>一篇文章文章一长串的东西</a></div>

截取的时候是要截取 div 标签内部的东西，而且要保留HTML标签，只是对其中的文字做处理。比如我可能只是截取到“李四”的“李”字，但是如果就这样放到前端的话，“李四”前面的 a 标签是没有闭合的，所以截取之后要保证HTML的语法正确。

这个问题确实不太好搞，让我郁闷了两天。请注意，这只是一个字符串，只不过内容是HTML代码，是没有什么DOM的。如果是在前端处理就好办了，直接DOM获取，然后对里面的节点进行处理，最后把innerHTML 之类的东西输出就搞定了。现在可不行了，得换个思路。同事的思路是这样的：

遍历字符串的每一个字符。设置一个标记，碰到标签开始的标记< 就置为1，接下来的字符都不记数，然后碰到>之后再开始计数。对标签内部的字符串处理的时候，还要先判断当前字符的编码是不是可能是中文，一般来说PHP中 UTF-8 编码的中文字符的长度都是3，所以如果碰到是中文字符编码，就要跳过两个不记数……说到这里我自己头已经开始大了。个人认为这种方法很不爽，首先这种精致的逻辑不太容易控制，而且 UFT-8 编码下中文产生的长度有可能是3个或4个 所以代码的严密性值得怀疑。

我个人的思路是，用 Tidy 来搞（具体用法请看PHP手册吧）。昨天研究了一下那个 Tidy ，发现这个东西还是挺好用的。首先，把这个字符串转换成 Tidy 对象，这样：

$tidy = tidy_parse_string($str, array(), ‘utf8′); // 最后一个是设置编码的，注意，这里是utf8 ，不是utf-8，没有中间那个连线。

然后获取$tidy中的 body（因为转换之后$tidy会自动加上<head><body>等标签）：

$body = tidy_get_body($tidy);

这个时候你可以用 var_dump 看一些 $body 的结构，会发现它把每个标签都变成了一个对应的对象，里面有相应的属性。举例来说，比如 <a href=”#”>sdf</a> ，这么一条语句对应的一些属性有：

name=>”a”
value => “<a href=”#”>sdf</a>”
child=> array{[0]=>一个文本节点对象，value是 sdf}
attribute=array{”href”=>”#”}
…..其他属性

可以看到，我们其实是可以单独去处理 a 标签对应节点下面的文字节点的值的，那样就不会破坏任何HTML完整性。原来我以为改变 a 标签中文字节点的值之后， a 标签的value也会跟着改变，那样我直接返回a标签对应节点的value就OK了，没想到不是那个样子，哎，所以处理过其中的文字之后还是要自己拼出新的HTML。

知道了Tidy对象的结构之后，一切就好办了，只要遍历所有的节点，对于本需求来说，就是找到那个 div 标签，然后开始处理里面的节点。代码如下：

if(mb_strwidth($subchild->value, ‘utf-8′) >= $len)
{
$subchild->value = mb_strimwidth($subchild->value, 0, $len, ‘…’, ‘utf-8′);
$trimed_str .= $subchild->value;
break;
}
else
{
$trimed_str .= $subchild->value;
$len = $len - mb_strwidth($subchild->value, ‘utf-8′);
}

里面的$subchild 就是一个子节点。注意，这里使用了 mb_strwidth 来获取字符串长度。严重推荐一下这个 mb_strwidth，很好用，它会把中文当作两个字符长度处理，正好符合这里的需求！而且截取字符串的时候用到了 mb_strimwidth，这个函数也会把中文当作两个字符长度处理，mb_ 开头的函数真是好用啊。

具体代码我就不写出来了，因为是针对一个需求写的，没做成通用的形式。哪天我有时间做成通用的再发布一下。

另外，可惜FireFox不支持 text-overflow 属性，不然也不用后台那么辛苦地去截断了。如果大家有更好的方法，欢迎提出！不胜感激。

分享收藏

在PHP中处理 HTML 代码

Dreamer — Mon, 17 Nov 2008 20:41:23 +0800

下午的时候同事碰到了一个小问题，是这样的：他从别人的接口中取回一长串的HTML，但是他只需要其中的一块。这就涉及到在PHP中解析HTML字符串的问题，花了挺长时间，找了不同的方法，在此记录一下：

1.最简单的就是字符串解析，灵活运用 strpos , substr 混合处理，把那一段代码抠出来。由于他要取的是一个固定的div内的东西，而且那个div 的 class 属性也是固定的，所以这种方法倒也简单，直接先以<div class=”xxx” 作为needle 找到那个div，然后做一些操作就行了。

2.PHP DOMDocument 。听到这个问题的时候首先想到的是PHP的DOM解析功能，刚开始真的以为找到了救星。但是最后发现这个东西的功能不能解决问题，反正我是没找到。因为最好我们想要把div里面的html代码输出出来，结果用 DOMDocument 提供的方法输出的全是不带标签的纯文本，无奈，只好弃用。（可能是我不知道它的用法，希望知道的不吝赐教。）

3. Tidy Functions 。其实 Tidy 是用来整理HTML的，不过它也可以进行HTML的解析处理。先使用tidy_parse_string() 把字符串转换成 tidy 对象，然后就可以利用tidy的方法对其进行处理了，还算方便，不过这个东西只能在 PHP 4.3.x 和 PHP 5 的版本下才有。具体方法和使用请参考手册。

4. strip_tags() 。无意中发现了这个函数，实在是太好用了！！上面几种方法最好我都是结合着strip_tags()来使用的。strip_tags() 可以过滤掉HTML和PHP标签，返回一个全新的字符串！用法如下：

string strip_tags ( string 要处理的字符串 [, string 想保留的标签] )

如果你想保留某些标签，比如 <a> 标签，就可以这样写，strip_tags($str, “<a>”) ，如果想保留多个标签，就可以这么写： strip_tags($str, “<a> <img>”); 标签之间用空格隔开就可以了。

5.另外，据我另一个同事测试，好像使用 XMLReader 来搞，没尝试，有兴趣的可以搞一下。

在工作中学习到的一些小东西，记录下来，省的以后忘记了。如果大家有什么更好的技巧，欢迎赐教，谢谢。

分享收藏

遇到的一些小问题

Dreamer — Mon, 17 Nov 2008 12:03:12 +0800

最近给应用做了一个直邮推广，期间遇到一些小问题，在此记录一下。

1.直邮里面不允许用javascript，这点很让人郁闷，所以一切交互只能借助html原生的的东西来实现。实现的时候按钮本来是使用 button 标签的，不过后来发现在 IE 下无法完成提交表单的功能，不知为何，后来改为 input 标签，成功。

2. FireFox 下面不支持 cursor:hand 属性，所以在FireFox里设置鼠标形状为手型，需要这样来搞：cursor:pointer 。但是这么一来 IE 下又不好使了，无奈，只好 hack 一下：cursor:pointer;*cursor:hand

3. HTML的原生标签都是有默认样式的，所以我设置了 h1 的padding-bottom之后发现IE 和 FireFox 显示不一致，后来得知要先把这个标签的 margin 和 padding都置为0 。所以很多页面的CSS开头就是 *{margin:0; padding:0;}，不过好像不推荐使用 * ，可以考虑一下YUI的 Reset CSS。

4. 直邮里面很多地方尽量用图片。一个WD告诉我的，因为邮箱可能对邮件内容做很多限制，很多CSS属性也不保证能弄。他们说直邮是最没有技术含量的，哈哈，所以我赶紧弄过来自己切页面了，锻炼一下，没有技术含量的工作适合现在的我。

分享收藏

YUI学习笔记：YUI Loader

Dreamer — Sun, 02 Nov 2008 17:34:42 +0800

说明：英文好的请直接猛击这里，本文没什么新东西。

YUI中有很多核心组件，比如像DOM, Event，几乎每个应用都会用到，但是我觉得在学习这些组件之前，最好先了解一下YUI Loader 这个好东西。YUI Loader 也是一个 YUI 的组件，它的作用就是通过脚本加载页面中需要用到的YUI 组件，说白了，就是在页面加载的时候，动态地在页面中插入<script> 标签，那么它和直接在页面中写 <script> 标签有什么区别呢？好处如下：

1. 可靠；按照依赖顺序加载YUI组件。由于YUI中组件很多，为了平衡代码重用和代码独立，很多组件相互之间都有依赖关系，必须要按照依赖次序加载，不然就要出错。YUI Loader知道组件之间的依赖关系，如果你加载某个组件的话，YUI Loader就会先把这个组件依赖的所有组件按照次序加载进来，保证不出错。

2. 当页面中已经有YUI组件的时候，利用YUI Loader添加新的组件会比较安全。因为开发者会自己编写一些可重用的YUI组件，所以在加载这些组件的时候页面中可能已经有了YUI其它的组件，如果自己编写的YUI组件依赖于YUI中其他组件的话，可能会在页面中重复加载一些YUI组件。使用YUI Loader就可以避免这个问题，它不会重复加载那些页面中已经存在的组件，只是把那些页面中不存在的组件加载进来。

3.自动使用集成的（rolled-up）文件。YUI中有些 js 文件集成了很多功能，比如 yahoo-dom-event.js 就集成了YAHOO全局对象，Dom 以及 Event 。YUI Loader会根据情况判断是否使用集成文件，这样的话就会少加载一些js文件，减少了HTTP请求，而页面的HTTP请求对页面加载速度是会有很大影响的。（关于HTTP请求请看这里）

提示： 任何一种在客户端脚本中动态加载外部js的方法，或多或少都会对性能有一些影响。如果你追求性能最优的话，那么在页面中直接写<script> 或 <link> 标签会更好。

在使用 YUI Loader 这个组件之前呢，还是要首先引入一个script文件，如下：
<script type=”text/javascript” src=”http://yui.yahooapis.com/2.6.0/build/yuiloader/yuiloader-min.js” ></script>

如果你决定使用 YUI Loader 组件的话，就不用单独引入YAHOO全局对象的js文件了，因为YUI Loader 本身就包含了YAHOO全局对象。

下面介绍一下YUI Loader组件中的一些主要参数和方法：

方法：

insert() 方法：最经常用的一个方法，在配置好YUI Loader之后，使用这个方法把YUI组件动态加载进来。

sandbox() 方法：有时候动态加载进来的组件可能会和现有的组件有冲突，这个时候就可以使用sandbox() 方法安全地加载组件。该方法通过YUI Connection Manager 来获取组件，并且在一个匿名函数中执行。所以，这个方法只能够加载同一个域下的JS。

addModule() 方法：用来添加自定义的组件，有以下主要参数（具体看这里）：
name: 组件的名字，必须是独一无二的，而且不能与YUI自带的组件冲突。
type: 组件类型。js 或者 css
path: 组件的路径，一般都是相对于 YUI Loader中的 base 的相对路径。
fullpath: 组件的完整路径。
requires: 所依赖的YUI组件

参数（全部参数介绍请看这里）：

require：数组，包含了要加载的组件的模块名。

base：加载组件的默认路径，加载组件的时候YUI Loader会先去这里找。相当于系统变量里的path。

onSuccess：函数，加载成功的时候调用。

onFailure：函数，加载失败的时候调用。

varName：如果你加载的是自定义的组件，当组件加载完毕的时候这个变量就会变成可用的。

最后说一下YUI模块名称，说白了，就是YUI组件在 YUI Loader中对应的缩略名，这样就方便了加载，比如，你只需要在require 里加上 “dom” 就可以YUI中的DOM组件。全部对应关系请看这里

OK，我就简单地介绍这么多，由于时间和精力的关系，很多地方写得都不是很详细，而且如果太详细了就是完全翻译文档了，也没什么太大意义。想了解更多还是去官方网站吧。

另外，附送一篇YUI Blog上关于使用 YUI Loader 减少加载文件大小的分析：
Loading YUI: Seeds, Core, and Combo-handling

分享收藏

RIAMeeting[北京]第八次会议

Dreamer — Thu, 30 Oct 2008 11:23:20 +0800

RIAMeeting[北京]第八次会议

近来Adobe出招频繁，随着Flash Player10的正式发布，还有让人万分期待的Adobe CS4创作合集，都无疑给RIA市场注入了兴奋的动力，身为RIA开发者的你，是否跃跃欲试？

Show Time！RIAMeeting第八次开发者聚会将在11月8日召开，具体信息如下：

这次的会议的主题：
Flash Player 10的新特性

时间：
2008年11月8日下午

地点：

Adobe中国研发中心
北京海淀区中关村东路1号院清华科技园科技大厦 A座 21层

会议日程：

1:30 - 2：00 签名入场（收集名片，最后抽出5个幸运奖，有惊喜奖品哦）

2：00 - 3：00 Flash Player 10新特性演示

3：00 - 3：20 休息，并收集大家的问题

3：20 - 5：00 根据问题展开分组讨论

本次会议特别邀请7yue作为我们的现场嘉宾，和大家一起畅谈RIA话题

本次报名将采用系统报名的方式，请使用下面的地址报名：

http://www.riameeting.cn/register/

如有问题，请咨询邮件：contactus@riameeting.cn

分享收藏

[转载]程式設計師的格言

Dreamer — Mon, 27 Oct 2008 13:58:36 +0800

via Tsung’s Blog

从 Tsung’s Blog 上看到这篇东西，发现里面的一些格言实在太经典、太贴切了！我觉得这个应该是和技术相关的，贴在这里，估计有共鸣的人应该很多。:)

先摘录几个经典的（做了小幅修改，替换了一些繁体术语）：

要殺一個程式設計師不需要刀，改三次需求就好

程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工期實現這樣的需求。
修改需求是對奇蹟吐槽的亵渎行為。
而追加修改則是相信奇蹟還會重現的無謀行動。

追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

原文出处：程式設計師的格言 « but, or bug
——————————————————————————

程式設計師的格言（盜作不少）

譯自

* プログラマーの格言（盗作多し）
* http://mixi.jp/view_community.pl?id=1772737

(版本2 2008/10/12更新)

譯註

* SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
* 程式設計師多半自己不面對客戶。
* 跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）

1. 每天有24小時。
所謂的「今天之內」，是指到明天早上為止。
2. 程式不會照自己所想的跑。只會照所寫的跑。
3. 需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4. 我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
5. 程式碼不要在開發現場寫！去客戶那寫！
除錯不要在期限前做！上線後再做！
6. 畫面是藍色的！
(國際太空站太空人重新安裝 Windows NT，日誌中的名句)
7. 先說「沒辦法」的人贏。
8. 有意見的話你寫
9. 要殺一個程式設計師不需要刀，改三次規格就好
10. 首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
11. 開發沒有終點。只有釋出(release)。
12. 無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
13. 客戶總是覺得水跟追加需求是不用錢的。
14. 付錢愈計較的客人愈囉唆。
15. 在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
16. 一個人掛了大家都掛了。
17. bug過了一晚可能就變成規格了。
18. 好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
19. 客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。
20. 對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。
21. 顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
22. 很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。
23. 品質的劣化程度依規格改變的次數與規模而定。
24. 業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
25. 有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
26. 程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
27. 程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
28. 對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
29. 程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。
30. SE需要持久力，程式設計師需要爆發力。
31. 準時離開公司，工作會變多。
32. 完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
33. 詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
34. 還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
35. 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
36. 所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…
37. 地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
38. 遠處的火災一定燒到這裡。
39. 禱告，然後 “工作” 吧。(修道院的標語)
40. 程式不是用腦記的，要用身體記住。
41. 明天能放假的話死了也罷。
42. 外面有下雨耶，昨天開始下的嗎？
43. 心若不廢掉(消極)，身體會廢掉。
若不讓自己殘忍，自己會被殺。
44. 客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）
45. SE總是不講理的(unreasonable)說「沒有辦不到(impossible)」，
業務總是沒辦法(impossible)說「沒道理(unreasonable)」。
46. 規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
47. 再嘮嘮叨叨下去也是要付錢的。
48. 多想個10秒鐘，你可以不說「嗯，這個做得到」。
49. 人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。
50. 老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。
51. 所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
52. 程式、SE、經理不是職種。是職責。
53. 業務是最難搞的客戶。
54. 能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley
55. 漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…
56. 上線後的除錯才叫做bug。
57. 追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。
58. 除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
59. 不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。
60. 要解決地獄的辦法，就是客戶把錢交出來。
61. 不懂電腦的操作者是發現bug的天才。而且無法重現。
62. 每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。
63. 搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）
64. 啊，那是微軟的規格。
65. 程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）
66. 程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
67. 正因為健康，才能做不健康的事。
68. (這個不是 bug 嗎？)
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
69. 那是你說的規格。
70. 開發室沒有窗戶，那是因為以前…
71. 即使爛了也是規格。
72. SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）
73. 為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。
74. 不會動的bug就只是普通的bug。（會動的bug則能視為規格）
75. 今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。
76. 客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。
77. 唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。
78. 共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。
79. 如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
80. 對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫出這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。
81. 設計者應該是不該要求製作者製作出超過設計以上內容的吧…
82. 無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。
83. SE對程式設計師說的「常識」每三小時變一次。
84. 自己看規格書。不能跑的是規格。
85. 「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。
86. 工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。
87. 能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。
88. 累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）
89. 試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。
90. REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零嗎？拜託加上注音吧。
（譯註：我比較煩惱 Linux）
91. 有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
92. 小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路
93. 「不要讓老闆當業務比較好」
94. 說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。

ex 系列

1. 就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。
2. 規格與規格書是不同的東西。
3. 比期限更重要的是靈感與睡眠。
4. 比知識與經驗重要的是手冊與時間。
5. 能動就好了，能動的話…
6. 過了三天就是別人寫的程式碼。
7. (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！
8. (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！
9. 漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了
10. bug與規格是一體兩面
11. 電腦裡沒有bug，bug常在人心。
12. 無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)
13. 估價需要1%的經驗與99%的直覺
14. 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
15.
* 『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
* 『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
* 『PM』＝每天修改自己定下的行程表的人
* 『業界老鳥』＝臉色蒼白缺乏表情的人
* 『外包』＝幫不會寫程式的正職員工寫程式的人
* 『coding』＝複製貼上的工作
* 『單體測試』＝指開始寫程式
* 『除錯』＝把程式碼註解掉的工作
* 『新同事』＝在火燒屁股的專案火上加油的人
* 『出貨日』＝把只完成一半的系統上線的日子
* 『末班電車』＝業界平均的下班時間
* 『颱風假』＝一年一度可以準時下班的業界假日
16. 當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
17. 最終手段
「重開機」
意外的常常都很有效
18. 最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
19. 「程式碼的可信度，不會比寫的人還可信。」

分享收藏

Efflex

Dreamer — Mon, 27 Oct 2008 11:23:49 +0800

var InsideRIA

Efflex 是一个开源的Flex effect 集合，里面的效果都很好，可以先看一下Demo。友情提示：有些Effect效率不怎么样，可能会出现暂时的假死 -_-。

Efflex

分享收藏

TextFlow beta 出炉

Dreamer — Tue, 21 Oct 2008 09:13:36 +0800

邀请年年有，这段时间特别多。昨天又收到了 TextFlow 的注册码（关于TextFlow，请看我以前这篇日志），告诉我可以试用beta版了，于是乎，我就去安装了一个，这个东西使用 Adobe AIR 做的，界面还不错，不过由于这个是用来协同编辑文档的，我只有一个账号，体验不到它的好处，就发现这家伙可以编辑word文档……囧……

这个东西暂时没法邀请，想要尝鲜的就猛击这里去注册等待邀请码吧。另外，你也可以先去看一个 Flex 做的 Demo，很帅。

分享收藏

一种 DOCTYPE 的缩写

Dreamer — Fri, 17 Oct 2008 11:23:37 +0800

var HedgerWow

写HTML代码的时候，第一行就要写DOCTYPE，而DOCTYPE一般都很长，大家也懒得去记，所以基本都是直接去复制以前写过的。不过今天了解到一种 DOCTYPE 的缩写，如果你的 DOCTYPE 是下面这样的话：

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

可以用下面的缩写来代替：

<!DOCTYPE HTML>

简单，好记，这样以后就不需要去复制了。BTW，我想举一反三试一下 <!DOCTYPE XHTML> ，结果失败，页面成了“混杂模式”，大家有什么其他的技巧欢迎提供。

分享收藏

收到Broadchoice Workspace Beta邀请

Dreamer — Fri, 17 Oct 2008 09:53:14 +0800

由于在网上看到有好东西的邀请派送我就提交自己的email，所以刚收到这个东西的邀请的时候我都不知道它是做什么的。看了之后了解到，Broadchoice Workspace 是一个强大的 AIR 程序，整合了很多应用进去，看看他们自己的说明：

Broadchoice Workspace is collaboration software for workgroups, companies, and communities who want an easy way to boost creativity and productivity by connecting people and their ideas.

简单地说，这个软件的目的就是让一群人更好更方便地进行协作，大体看了一下这个东西的功能，发现它整合了书签、便笺、联系人等功能。下面还有一排是Facebook，twitter等，开始我还以为它能绑定这些应用的账号，没想到只是在程序里面嵌入了一个浏览器而已……

由于是基于AIR的，界面很漂亮，想尝试的请留下email 。（我也不知道能邀请多少人，先到先得，哈哈）

Broadchoice Workspace

分享收藏

Dreamer's Blog

PHP 截取HTML串

相关日志

在PHP中处理 HTML 代码

相关日志

遇到的一些小问题

相关日志

YUI学习笔记：YUI Loader

相关日志

RIAMeeting[北京]第八次会议

相关日志

[转载]程式設計師的格言

相关日志

Efflex

相关日志

TextFlow beta 出炉

相关日志

一种 DOCTYPE 的缩写

相关日志

收到Broadchoice Workspace Beta邀请

相关日志