应用它还有个最大的好处是，不用担心设置半透明背景会一刀切影响到子元素的透明度。

实现方案与兼容性见这篇 blog

就是应用起来，不是那么的方便，涉及到一些数值换算，比如通常我用十六进制的颜色值，小数表示的 alpha 值，而十进制的 RGB 颜色值和十六进制的 alpha 值就显得很特别，每次都进行换算比较不符合懒人的做法。

于是就有了这个小工具页。

还有就是实现细节上和上面的 blog 介绍的有点区别。

欢迎使用。Enjoy!

平江水经过水闸之后，打着漩涡而去，但一点都不影响这外表的平静感觉。

来到思婆桥，名字很温情，但是看过介绍之后想法就会发生一点变化。很多人拿着大炮对准这桥，我也若无其事地拿起小炮等待桥上的人散去。

平江路的一边是河，一边是各式商铺。不过有些店铺的门口挺雷的。

例如这个在典型的石门框内，镶嵌着自动玻璃门。十分古旧感觉的普通石阶梯，门两旁的很有民居风格的植物，已经掉色的如意吉祥，与现代设计的招牌来个碰撞。不知道其他人怎么想，反正很合我胃口。

再接着遇到一另类书店，不过我觉得是个四周围都放满了书的茶室。

上了二楼，发现一只踢都不走的猫，后来大概觉得躺太久累了，伸伸懒腰就游走了。如果一定要把这店归入书店类别的话，我觉得算是个生活用书专卖店吧。

其实，主角还是平江。

已经不是什么大清早了，这家店主人比较懒，都懒得开店了～

没点特色在这里会混不下去的。

这亭子绝对凉快

桥，很多的桥。大多数时候，我们都不满足于隔岸相望，更希望借助桥的力量，来实现进一步的接触。

接下来，将会与谁发生接触呢？

即将开放

不仅花好看，叶子也非常漂亮，绿油油，坚挺，纹理清晰，还有花边

想像一下成片的绣球开启时是何其壮观

大风车

几天之后……

完全盛放

由完全青涩幻化成完全粉艳

花面展开犹豫大舞台，花芯就是那唯一的主角

红花，绿叶，这是一种大自然的绝配

出于项目管理与前期代码经营不足等原因，在版本发布临近之时，bug 猛增。其实 bug 多起来不是什么大问题，而且修复起来也挺快的，问题是为什么不能及早发现？直觉认为是测试在后期进行。但，提前让测试人员参与进来就能够解决问题吗？

在 bug 管理当中，是有分类的，人们对于不同种类的 bug 反应也是不一样的。例如对于一些 regression (倒退)表现得很严重。看似很合理的反应。

在某种程度上，开发的情绪是被测试牵引波动的。就像训练老鼠跑迷宫一样，电击多了就记得什么(错)路不能再走。但我怀疑这会不会导致开发会 LOST （迷失），忽略了代码中隐藏的各种信号，而依赖于测试反馈的信号。而据我观察，这种担忧不是多余，从开发修 bug 所改动的代码就可以看出。真是头痛医头，脚痛医脚，不报 bug，不修改。这里假设开发都不是应付式工作。这种对 bug 抱有偏见的状态所造成的问题，只要眼球足够多，迟早会以代码质量问题显现出来。那就是前一个现象发生的原因。

bug 不可怕，代码混乱才是问题，开发应该保持客观。显示 bug 是测试要做到事情，也是重要指标，但对于开发的，它也有指示作用，但肯定不是领头羊级的指标。开发要做的是书写良好的代码，让 bug 及早显现。不过也有一些外部因素，比如项目换血频繁，代码交接断裂，人员良莠不齐，普遍缺乏信托意识等等，都会造成累积的仅仅，仅仅是代码。

有良好的土壤，才能培育出丰厚的果实。

与其说这是一种杂草，不如说，它就是一个普遍存在，在这天地间有它存在的法则。

前不久看到有报道指日本用维护生态平衡来正义化捕鲸。简直是大笑话。就算是为了生态平衡，大规模捕鲸这种做法就和最近国内平抑房价的做法一样，治标不治本。利益驱动之下，什么言论都可以出。现在有多少人会回归关注人与自然的关系呢，太多人疲于应付人与社会的关系了，难道那些只适合当小学生的学习课题？

我选择了绕开正在甜蜜的情侣，在远处慢慢欣赏宁静的依靠
我选择了与愁眉深锁的人擦肩而过，原来我们并不孤单

我选择了默默地观察
我选择了让观点去碰撞

我选择了回避
我选择了面对

在无数次选择之中，造就了数亿万个我
在天空深处的另一个我，你还好吗？

第一个问题：工具，我需要工具。奇缺。后悔搬窝的时候连小脑都没用。翻了好久才找到个小十字螺丝刀。根据网上图文并茂的解剖教程，首先是要弄下鼠脚垫，才能看得见固定螺丝。水果刀华丽登场。

解开鼠皮。真正的问题出现，还是工具的问题。国产微动开关的保护壳，教程说要小金属片，我的天啊！哪里来金属片，还要小的！这不是微创手术么？

灵感闪现，真的只是灵感。我的所有物品当中，只有剃须刀片能满足这两大条件。只是吉列的双层刀片也有个保护层（用来保护我们的肌肤），使用暴力，胜利获取物品——两块小金属片。下面就是插呀插呀，撬呀撬呀，为了后面能恢复回去，半小时左右才将微动开关的保护壳温柔地卸下来。

终于可以亲眼目睹这个奇妙的装置。人类真是太聪明了，用这么大的一个按钮去控制这么小的开关。用指甲直接单击，还真有弹性。清洁小金属片不难，未免不要拆开再来一遍，特意刮得亮得不能再亮。事情没完。将小金属片装回去不容易啊，教程也特意说明过，我居然不信。最后那个安装顺序有点不一样，我是按照 3，1，2 这样的顺序完成的。尽信书不如无书。过程中不断怨恨我的手指太粗了。恢复之前，开鼠标，实测了一下，证实有效。

好久没有做这样的小手术了。突然回忆起曾经是那么热衷于解剖各种东西，钟，电子表，柯柏文，音箱，耳机，可以打俄罗斯方块的掌上游戏机……

以前那只电视机经常坏，我曾经想过如果学会了修电视机，就不用看见靓妈虽然不情愿但还是要花钱请人来修了，惭愧，现在还是不会修。

hash: #fly
host: localhost:8000
hostname: localhost
href: http://localhost:8000/lab/index.html?key=1#fly
pathname: /lab/index.html
port: 8000
protocol: http:
search: ?key=1

这篇文档里面有相关属性的说明。不过还有一点不太起眼的地方，hash 和 search 的先后顺序。
作为对比，有“http://localhost:8000/lab/index.html#fly?key=1”

hash: #fly?key=1
search:

各个浏览器上表现都是一样的，hash 先出现的话会吃掉 search 的，这让我有点费解，这个顺序还真那么重要吗？
当我们点击一个锚点的时候浏览器会在整个 URL 之后加上 hash的，这样似乎也挺好理解的。
只是如果需要手工拼接 URL，那就需要注意一下这个顺序了。

优化的第一准则：不要优化。
优化的第二准则（仅限于专家）：还是不要优化。 —— Michael A. Jackson

脑子在掐架了。最通常的想法都是要程序跑得快是需要优化一下。不过有些真实经历告诉我，只有很少经过严格试验的优化手段是有效的，其它很多都是自作聪明。书中接下去这句很有感觉：

良好设计和清晰编码的代码几乎总是优于“优化的”代码。

不要优化代码的奇怪现象真是相当有趣。其实就是要程序员扩宽角度去思考关于高质量的代码问题。

提个题外的问题：这是范参议公祠，知道里面展出的是什么吗？

然后从另外一本书中看到这句：

这听上去似乎反直觉，但谁说过算法是一个靠直觉的学科呢？

这样被他一提醒，立马回想起来很多事情的确走了直觉路线，但却隐隐有种怪怪的感觉。
如果下次又遇到一些事情时就又多一个思路了，非直觉思路。

PS: 第一本书是《架构之美》，第二本书是邹恒明的《算法之道》

答案是：动漫，还有喜羊羊！真是这货～！不过是在天平山动漫节期间。贱笑了 ~

BANG0924070914FC9A4CC6111627XIANGUO

经济上的产能过剩除了可以裁剪和淘汰落后产能，还可以辅以提升居民消费力来吸收剩余产品。但是软件上的设计过剩恐怕就没那么多选择了，如果不在投入的过程中加以控制，那么不仅浪费时间，还可能最终导致项目腐败变烂，而这都是一点一点的慢慢形成。

目前也有一些实践是用来对付其中一些问题的，比如敏捷编程，减少浪费就是其核心思想。不过，也许可以专门独立出来一个话题来更好的关注这类问题。通过分析现象，比较过程与结果，可以帮助我们采取更加有效的实践。

先开个头，再逐步累积，让我们更加清晰地认识问题并寻找到合适的方案。