易栈网-膘叔

HTML重构，以前是一个新鲜的东西，我也没有理解，博客园上有人在介绍，还写了三篇。。。

我这里只简单的复制点东西，还是以链接为重吧。（战略篇全文如下）

《Refactoring HTML: Improving the Design of Existing Web Applications》是一本精彩的HTML重构指南，作者给出了HTML重构的实践路线和方法。本文是《Refactoring HTML》的读书笔记，按照我的理解将全书的分为：战略篇，战术篇，工具篇。

本文是战略篇：全局方略的角度介绍重构的内涵，原因，时机，目标

嗯哼，我们开始：

         进行重构就像打一场仗，而战争的发起是要慎重考虑的，《孙子兵法》里面讲“兵者，国之大事，死生之地，存亡之道，不可不察也。”所以动手重构之前首先要回答下面几个问题：

• 什么是重构？
• 为什么进行HTML重构？
• 什么时候进行HTML重构？
• HTML重构的目标是什么？
• 面对质疑：还要重构么？

什么是重构 Refactoring?

        本书侧重实战，没有《UML Distilled》那样高屋建瓴的抽象，即使有抽象，抽象层面牵扯的细节过多(这一点在后续的阅读中也可以发现)。这一部分内容我援引了《Refactoring: Improving the Design of Existing Code》对重构的定义：

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

为什么进行HTML重构？

抽象地讲，HTML重构的可以让代码更能适应变化，应对系统和领域需求为新功能的开发提供更优秀的基础。

具体地讲，HTML重构可以：

• 让代码更具有可读性，更容易理解
• 重构过程中往往有意外的收获：发现隐藏的系统Bug
• 增强页面可用性， 关注点从设计者开发者转移到使用者
• 缩短提高页面的呈现时间(Slow pages -Rendering Times)
• 解决页面浏览器不兼容问题
• 搜索引擎优化Search Engine Optimization

进行HTML重构的时机?

• 每一次进行重新设计之前；新功能将构建在一个更稳固的基础之上
• Refactor When You Need to Fix a Bug
• Refactor As You Do a Code Review
• 一个原则:勿以善小而不为；重构的过程往往是断断续续的，很少有一个连续的时间给我们进行重构。所以我们只要有机会进行重构，就动手去做吧

HTML重构的目标（What  Refactor To） ?

• XHTML
  理由：XHTML更加严格，浏览器不再解析乱作一团的标签而是格式规范的页内容，这时负担从浏览器转移到页面开发者。内容聚合，搜索引擎优化，样式表都可以更好的应用基础。开发者能够更容易调试和解决问题，因为问题更容易定位了。XHTML不能完全解决浏览器兼容问题，但是它能够消除大部分的浏览器不兼容问题已经居功甚伟。主流HTML编辑器都提供对XHTML的支持。XHTML是未来Web应用提供坚实的基础，如：MathXML MusicXML SVG。
•  CSS

理由：将展现层从内容中分离出来。为不同的阅读者提供高可读性。减少代码重复，节省带宽。

• REST

REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：

1.网络上的所有事物都被抽象为资源（resource）；

2.每个资源对应一个唯一的资源标识（resource identifier）；

3.通过通用的连接器接口（generic connector interface）对资源进行操作；

4.对资源的各种操作不会改变资源标识；

5.所有的操作都是无状态的（stateless）。

REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。

重构的目标不是金科玉律，你没有必要逐一进行实践。你可以按照XHTML->CSS-->Rest的顺序按部就班步步为营，也可以根据实际情况调整重构目标和计划。但是只要你做了，你就可以从重构过程中得到好处。

面对质疑：还要重构么？

重构的本质决定了它不是生产性的，重构的完成并没有新功能的产生。所以重构往往面临来自各方面的质疑：

• 重构就是在浪费时间，我们还是开发新功能吧

面对质疑我们给出这样的答案：

• HTML重构从长远来看为后续开发提供了一个良好的基础，实际上是节省了时间。因为系统更容易添加新功能，更容易维护。重构的过程能让开发者对以前的工作有一个思考，对新人是一个熟悉系统的机会。
• HTML重构本身并不会占用太多的时间，因为我们有很多自动化的工具可用。
• HTML重构不需要一个连续的时间，断断续续的时间未尝不可，对于开发者来说，进行重构就像日行一善。

HTML重构：战略篇

HTML重构：战术篇

HTML重构：工具篇

这段时间最大的新闻莫过于SUN被收购了，收购人不是IBM而是oracle
新闻那是铺天盖地呀，去CNBETA看看就知道了，但对于我来说，关心的只有几点：

1、MYSQL会怎么个走法？
2、以后java会怎么继续
3、服务器价格会下降吗？

更多新闻请google一下就知道了

没想过要用这个东西，但群里有人问，这个地址也是群里的朋友贴出来的，仔细想想这个东西也有应用的场景，比如歌词的控制。能够得到播放时间，就能够控制歌词的显示了。估计那些用JS做的播放器大致都是这样的吧？猜测而已

内容如下：http://roln.cn/archives/80

2 让播放器播放多首歌曲并循环播放呢
思路就是建一个播放列表,然后通过js来控件.

第一种方法 (此方法最终行不通)
建立一个数组相当于播放列表alist(假设这是用户选择歌曲后的结果)

第二种方法.现已解决.能正常使用. 思路就是用setTimeout()不停的循环,然后控件播放列表的索引得到值来改变URL

先建立一个播放列表
假设用户所选的歌曲参数已传过来
播放列表如下
<select name=”SongList” size=”5″ >
        OnDblClick=”player();”>
            <option value=”songs/001.mp3″>001</option>
            <option value=”songs/002.wma”>002</option>
            <option value=”songs/003.WMV”>003</option>
            <option value=”songs/004.mp3″>004</option>
            <option value=”songs/005.wma”>005</option>
 </select>
同时设置几个按钮
<a href=”#” onclick=”javascript:play();”>on</a>
<a href=”#” onclick=”javascript:Last_OneOK();”>last</a>
<a href=”#” onclick=”javascript:Next_OneOK();”>next</a>

js
<script language=”JavaScript”>
        //var server=’http://localhost/music/’;
        var SongList = document.getElementById(”SongList”);
        var Exobud = document.getElementById(”Exobud”);
        var TotalSongs = SongList.options.length;
        function play()
        {
        SongList.options[0].selected=true;
        player();
        }
        function player(){
      if(SongList.selectedIndex < 0) alert(’系统错误，请选择您要播放的曲目！’);
      else{
      var url;
      url = SongList.options[SongList.selectedIndex].value;
      Exobud.URL=url;
      //alert(TotalSongs);
      Exobud.controls.play();
      showTLab();
      return;
      }
        }
   
        function showTLab(){
      if(Exobud.playState == 1)
      Next_OneOK();
      setTimeout(”showTLab()”, 1000);
        }
   
        function Next_OneOK(){
      if(SongList.selectedIndex >= 0){
      if(SongList.selectedIndex < TotalSongs-1){
       SongList.options[SongList.selectedIndex + 1].selected = true;
        player();
      }else{
       SongList.options[0].selected = true;
        player();
      }
       }
         }
         function Last_OneOK(){
      if((SongList.selectedIndex > 0) && (SongList.selectedIndex < TotalSongs)){
      SongList.options[SongList.selectedIndex - 1].selected = true;
      player();
         }
         }
    </script>

这样问题就解决了.
注音乐文件都是我本地的

附上media player的一些控制方法

player.controls.play(); 播放
player.controls.stop(); 停止
player.controls.pause(); 暂停
player.controls.currentPosition 返回播放文件的当前时间位置（以秒为单位）
player.controls.currentPositionString 时间格式的字符串 “0:32″
player.currentMedia.duration 返回播放文件的总长度（以秒为单位）
player.currentMedia.durationString 时间格式的字符串 “4:34″
player.settings.volume 音量 （0-100）
player.settings.balance 声道,通过它应该可以进行立体声、左声道、右声道的控制。但对应的取值尚不清楚。
player.settings.mute = s 静音（s取值为true和false）
player.closedCaption.CaptioningID 网页中出现字幕的容器的ID
player.closedCaption.SAMIFileName 字幕文件地址
player.playState 返回播放器状态（ 3：正在播放,2：暂停1：已停止）

这个东西，我实在不知道放在哪个分类了。。但因为我是用PHP进行开发的，因此我还是将它归为PHP分类

昨天在Yhustc的博客上看城管操作手册，结果顺便看到了这个免费的webservice列表。

yhustc的博客功能越来越强大了，支持直接的ID的文章，现了也支持这种以英文名为路径的文章了，等再强一点，我也考虑换成yblog，哈哈，不过，要等他写转sablog的程序（实在是2.0到现在都没有出来，等的心急了）

对于sablog，我在另外的应用里，已经将它的模版机制全部转为discuz的，因为自己熟悉DZ的模版，改起来更快了。只是不知道何年才会派上用场。。。。

废话说了这么多，上重点的：

某网站支持

国内手机号码归属地查询WEB服务
2400多个城市5日天气预报 WEB服务
股票行情数据 WEB 服务（支持香港、深圳、上海基金、债券和股票；支持多股票同时查询）
中国电视节目预告（电视节目表）
火车时刻表 WEB 服务
IP地址来源搜索 WEB 服务
等等...

是什么网站呢？Look。。。

http://www.webxml.com.cn/zh_cn/web_services.aspx

其他两种我不懂，但wsdl我还是懂的。啥时候有空看看，oh yeah

文章来自至顶网，两年前的内容，只是感觉好象不错，就复制了过来。
原文链接如下：
http://soft.zdnet.com.cn/software_zone/2007/1022/570485.shtml
http://soft.zdnet.com.cn/software_zone/2007/1020/568251.shtml

很难想象，2居然比1先出来。

Linux 能有多小呢 ? 每一个做 embedded 系统的人都把小看成第一要务，其实这是不对的。小当然不会比较坏，但不一定比较好。如果系统使用 4MB 和 5MB 没有价格或性能上的差别，那 4MB 和 5MB 是一样好的。

到底有多小

废话说了一堆，那到底 Linux 有多小呢? 好吧，各位这么有小牛顿的精神。我也只好想办法生一个答案出来了。

首先我必须声明，我的不一定最小。不要说我在欺骗世人，你的核心比我小。我无意比较，我的数据只是给大家一个参考而己。不过我欢迎大家提出自己的心得，告诉大家怎么样做出更小的核心。

我使用的是 Mandrake 内付的 2.2.15，我没有修改任何一行程序码，完全只靠修改组态档得到这些数据。

首先，使用 make xconfig 把所有可以拿掉的选项都拿得。

不要 floppy；

不要 SMP,MTRR；

不要 networking,SCSI；

把所有的 block device 移除，只留下 old IDE device；

把所有的 character device 移除；

把所有的 filesystem 移除，只留下 minix；

不要 sound 支援。

相信我，我己经把所有的选项都移除了。这样做之后，我得到了一个 188K 的核心。 还不够小吗? OK，再加上一招，请把下列二个档案中的 -O3,-O2 用 -Os 取代。

./Makefile 
./arch/i386/kernel/Makefile

这样一来，整个核心水小了 9K，成为 179K。不过这个核心恐怕很难发挥 Linux 的功能，因此我决定把网络加回去。把 General 中的 network support 加回去，重新编译，核心变成 189 K。10K 换个 TCP/IP stack，似乎是很上算的生意。不过有 stack 没有 driver 也是惘然，所以我把 embedded board 常用的 RTL8139 的 driver 加回去，195K。

如果你需要 DOS 档案系统，那大小成为 213K。如果 minix 用 ext2 换代，则大小成长至 222K。不过大家要注意，那里的大小指的是核心档的大小。那和所需要的随取记忆体是二回事。这个数字代表的意义是你需要多小的 ROM 来存放你的核心。

Linux 所需的记忆体大约在 600~800 K 之间。1MB 可能可以开机了，但可能不太有用。因为可能连载入 C 程序库都有困难。2MB 应该就可以做点事了，但可能要到 4MB 以上才可以执行一个比较完整的系统。

到底谁占了这些空间

看到这里，是不是觉得 Linux 真的有点大。好吧! 那我们就来看看谁占用了这些空间，下面这个列表是从 222K 这个核心做出来的。

# wc  
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o  
ipc/ipc.o  
fs/filesystems.a  
net/network.a  
drivers/block/block.a  
drivers/char/char.a  
drivers/misc/misc.a  
drivers/net/net.a drivers/pnp/pnp.a  
/usr/src/smalllinux/arch/i386/lib/lib.a  
/usr/src/smalllinux/lib/lib.a  
/usr/src/smalllinux/arch/i386/lib/lib.a

结果如下 :

243 2250 81946 arch/i386/kernel/kernel.o 
42 316 10569 arch/i386/mm/mm.o 
173 1541 74660 kernel/kernel.o 
266 2307 68053 mm/mm.o 
222 3139 123193 fs/fs.o 
49 602 21600 ipc/ipc.o 
263 2940 106504 fs/filesystems.a 
137 1510 65512 net/network.a 
92 719 39178 drivers/block/block.a 
230 2308 87556 drivers/char/char.a 
1 1 8 drivers/misc/misc.a 
83 721 25680 drivers/net/net.a 
1 1 8 drivers/pnp/pnp.a 
20 187 9526 /usr/src/smalllinux/arch/i386/lib/lib.a 
23 150 7714 /usr/src/smalllinux/lib/lib.a 
20 187 9526 /usr/src/smalllinux/arch/i386/lib/lib.a 
1865 18879 731233 total

先说明一下，这里的大小和最终的大小有点差别，但大致还是可以做个参考。这边显示 730K 实际上大约在 600K 左右。

很显然的，filesystem 相当的大。大约在 230K 左右，占了 1/3 的体积。记忆体管理占了 80K，和核心其它部份的总合差不多。TCP/IP stack 占了 65K，驱动程序占了 120K。SysV IPC 占了 21K，必要的话可以拿掉，核心档应该可以再小个 10K 左右。

所以如果要减核心大小，应该动那里呢? 答案应该很明显，当然是档案系统。Linux 的 VFS 减化了档案系统的设计，buffer cache, directory cache 增加了系统的效率。但这些对整个系统都在 flash 上的 embedded 系统而言根本就用处不大。如果可以把它们对拿掉，核心可以马上缩小 20K 左右。如果跳过整个 VFS，直接将档案系统写成一个 driver 的型式，应该可以将 230K 缩减至 50K左右。整个核心缩到 100K 左右。

从上面的数据来看，ucLinux 所减小的 mm 部份反到省的不多，主要是 mm 除了 virtual memory 之外，也要处理 memory allocation 的部份，这部份是省不得的。如果二者齐做，则 100K 以下的 Linux 核心不是不可能的事。

结语

如果有人有闲的话，不妨拿 2.0 或 1.0 的核心来试试。看能做出多小的核心。看完本文后，143K 的核心不再是技术上的挑战了，是吗? 也许明天就有人宣称做了 120K 的核心了。不过，所为何来，省那几十K。不如好好想想 compressed filesystem 等更有用的技术吧!