今天去配了副眼镜，近视度数和5年前差不多，但散光增加的，真够郁闷。眼镜越来越贵，都到了让人瞠目结舌的地步了。便宜的镜框无法看上眼，至于镜片就更是一个被狠砍的部分，什么防紫外线防辐射什么的，扯淡。配了副胶框，好久都没戴过胶框了，我的前2副眼镜是胶框的，后来又戴过4副金属框。原来我戴了十几年的眼镜啊！
这个月的消费额是平时的近10倍！过年真不是好东西。
很邪恶地又把这里固定链接的格式改了，改为了/posts/%post_id%，之前的固定链接格式是archives/%post_id%的，童鞋们大概访问我的文章又有难度了。原谅我这个善变的人吧。不过好消息是应该不会再改了。
正在继续折腾wp的一些功能，在考虑如何增加这里的访问速度，是不是要把一些东西收起呢？毕竟页面东西太多访问时间太长，但无论时间多长都不够访问sitemap的时间长。
努力吧！
到处都在说SEO，到底SEO是啥？这里我就不解释了，请到sofish那里认真学习。
sitemap又是啥呢？直译，网站地图，就是为了让大伙儿更容易在网站里找到要找的而制造的页面。对于个人小blog而言，没什么地图不地图的，毕竟刚开始写生活blog的人不太会利用标签和分类，基本上就是大杂烩炒成一堆，但这也不要紧，因为伟大的BSP也会根据月份/年给大家分类。日子久了，杂乱无章的东西原来也挺整齐，只是大家没注意到。而对xrspook来说，文章够多的了，到2010-02-23为止有大概2300篇，如何整理这些东西呢？我真的很需要一个简单朴实的sitemap来“展示”我这些庞大而华丽的“历史”。
由于系统是wp，我的第一反应是装个插件，装了Google XML Sitemaps，非常厉害经典的插件，如果你的wp是放在网站根目录下的，非常幸运，你装好插件就能用了（当然啦，手动在wp的根目录建立空的sitemap.xml和sitemap.xml.gz还是必须的），至于那些不是放在根目录的童鞋们，你们就要折腾一下sitemap.xsl这个文件的存在问题了（这只又是啥？貌似CSS的东西）。
经过一番周折，并请求Matrix帮助后，终于有了自己的http://www.xlanda.net/sitemap.xml，效果如下图。
虾米意思，这也算地图？叫人怎么看！别生气，的确，这不是给人看的，这是机器看的，是特意给搜索引擎抓的，上面除了数字就是字母，对正常人来说，特别是为了找路的人来说，这简直就是一团糟，因为这个sitemap是XML的。
于是，从sofish那里我有了另外一思路，我还要弄一个XHTML的sitemap，而这东西是给人，专门给有血有肉的人准备的，上面有实实在在的文字信息：字母+数字+汉字（晕，不就多了个汉字嘛）= 找地图的人所需要的关键数据。sofish有教我们该怎么整，但依着葫芦画瓢后发现不行，在我的模板下不行，空白一片。
仔细研究代码后发现，我page.php页面的结束代码居然是这样的“<?php endif; ?>”，而不是sofish说的“<?php endwhile; endif; ?>”，代码不一样就是一个杯具，因为我把自己主题代码的“<?php endwhile; else: ?>”也删掉了，怎么可能不白屏呢？代码全部都得有始有终，有始无终了，不死翘翘才怪。好不容易战胜了白屏的问题，但效果很恐怖，而且我的文章数太多，如果全部显示出来，会形成一个惊人的界面，而且类似“按月归类”和“分类”的信息我已经在sidebar里展示，无需再次铺尘，所以，改造是必须的。
一直对模板里的“archive.php”摸不着北，但今天我却偶尔在增加页面的时候知道它的厉害。原来自己使用的lightword模板已经具有了归档功能，是伸缩式的，很强大，但却没有sofish介绍的那个全面，于是，我就来了个联姻，请看展示页http://www.xlanda.net/sitemap，童鞋们，这就是我的人肉XHTML网站地图！看清楚，没有“.xml”，有那个的是给机器看的，没那个的是给地球人看的，切记！展示图如下：
http://www.xlanda.net/sitemap.xml和http://www.xlanda.net/sitemap的载入速度都不快，因为数据量同样大，为什么第二个也那么慢呢？因为实际上它的数据量和第一个一样多，别看它的滑块比较长，实际上，把每个月的数据展开后滑块就会变短好多了，有兴趣的童鞋浏览一下源代码就可看出原机。
wp很强大，插件很多，懂wp的人也很强大，他们的方法也很多，但是否照搬就行呢？只有了解自己，才会懂得学习他人然后融入自己，创造出最适合的东西。
我的sitemap做好了，你的呢！
昨天，知道了原来我们粮库也有网站，迫不及待地去观摩一下。汗！我用的是FF，结果呢？中国人做的网页就是对IE以外的浏览器水土不服，于是，汗，再汗……
网页是个需要测试测试再测试的东西，内容当然很重要，但如果不同用户不同浏览器出来的效果不一样呢？杯具……在中国人设计的网页中，非IE不可是习惯性真理性的，比如说大名鼎鼎的备案网站，又比如同样如雷贯耳的网上支付网站，巨汗！地球人都知道IE的安全性不好，速度不优秀，但，勤劳勇敢机智过人的中国人就喜欢用系统自带原汁原味，甚至还没经过升级到7或8的IE，果然是微软的忠实粉丝啊！
但，我们某些人的思维是发散的，面向的是世界各地的盆友。在外国盆友设计的网页中，基本上FF横行，是推荐用浏览器，比如说我用的WP模板的作者。显然，他老人家视IE为无物。请看下图：
这是IE的截图。
这是FF的截图。
左图是我千辛万苦经过修改后的IE适应版，右边是原版。杯吧，原版在IE下，3栏的设计都变成2栏了，2个侧栏“被迫”挤到了一块，肯定是和背景不搭调的，揪心啊！
为了挽救这恐怖的杯，我首先请来了Firebug大人。
模板，显然，是div的，样式肯定是CSS的，而问题就发生在content-body、content-sidebar-2和content-sidebar里。首先，我在content-sidebar的CSS里加了一句“float:right;”，解决了content-sidebar在IE里跟在content-sidebar-2屁股后面的问题，实现右置。但为什么升不上去呢？难道因为太窄？我尝试修改过很多宽度都不行，看来不是位置不够的问题。会不会是content-sidebar里有“clear”的命令呢？应该不会。如果有的话，在FF就不会正常了。中间部分三栏设计，我们可以用3个float来解决问题，于是我试探性地在content-sidebar-2里加一句“float:right;”惨了，占到了最右方，当然，因为它的层在content-sidebar之前，理所应当占最右边。那如果改为“float:left;”呢？我的设想是它或许会正常，如果content-body已经设定为“float:left;”的话，怪异的是，在IE下正常，在FF下content-sidebar-2抢到了正文的左边。问问Firebug，虫子说content-body里有个“float:none;”的设置。怎么可能，我已经把CSS文件里所有content-body都加上“float:left;”，怎么有可能还是“float:none;”！！！！但如果不存在，Firebug不可能爬虫出来，到底在哪里呢？无计可施之下，找起了网页源文件，居然，居然被我在网页头部找到这等东西！！！
实在太杯具，灰常杯具啊！文件头，居然放在文件头，无语了。在WP的header里找，没找到，最后终于在function里找着，我的老天，该死的“none”！于是，终于用3句float解决了IE怪异的效果，让中国人看到的效果和外国人相似。
哎，如果大家用订阅的话，版面什么个鬼样又有什么关系呢。
哈，今天完成了2009年的工作总结，花了2小时写了近2800，还行，自感不错了。还有很多想写，但例子已经举得太多了，再写就成长篇小说了。现在已经是短篇小说了，我这个会吹的人……很开心地，终于完成了一个不想完成但又必须完成的任务。
晚上终于有时间折腾自己的新家，还是那个index.php的问题，问过老大那是lighttpd重写设置的问题，但结果居然是老大在我的域名下更改，我 前后台都登入不了，老大说什么都不肯在全局更改，说会影响到其他人，杯具！还没见过如此强硬过的老大。不改就不改嘛，差点我弄哭了，心情一下子down了 下去，于是发了个豆邮给danzhu，大姐姐总会有办法的，总有一天G老师会得出不一定在那里改的办法的，我坚信！但是，非常完美的Linux主机，非常 容易修改的Lighttpd系统，却咫尺天涯，叹一句，人啊~~~
人生总是跌宕起伏，错落有致。今天把300多张磅单用计算器按过多次，真是神经的经历。
这两天在狂听Tyrone Wells的Sink Or Swim，大爱，狂爱，GA S06E11的季首开场介绍里有用过，PP S03E11也在用，我的血液都沸腾起来了，比喝咖啡还有用。
坐过山车，还好吧。
昨天晚上我是凌晨一点回去睡觉的。
今天晚上我是凌晨一点离开办公室的，还没洗澡，躺在床上的时候已经是凌晨一点半。
我很累，在上班时间里被检验、文档排版、数据抄写榨干。下班后，成为小村屋群的义务核心技术员，被代码转化和CSS修整榨干。CSS修整本是很简单的事，FF+Firebug+css code就能得心应手，需要做的就只是修改和刷新，但是，偏偏某村友的blog用的插件却把该死的CSS可视化了，分开一小段一小段，加上说明，却不显示最最原始的代码，还得让你一个个翻，要多按好多次保存，还经常会找偏。结果最后我气了，直接用Firebug去找我要找的地方，在自定义的CSS里敲打一番，嘿，终于可以了，真邪恶！
今天的重头戏是帮一位有困难的村友搬家，听村屋首领说他帮忙搬的时候失败了，于是，在危难的时候，当大家有需要我的时候，xrspook挺身而出了！接到从BlogBus弄出的代码，马上用Python转换，得出如下结果：
很诡异，我之前遇到的错误代码可不是这样的哦。我第一个反应是时间有问题，应该是某个设定的时间不对劲，但到底在哪里呢？94、268、371、376（此数字为行数）我都排查过，没有。于是，我第二个反应是人肉排查替换。把376以前的先删掉，转换后面的。OK，没问题。再把前面的转换，同样结果。接着，把94-376的删掉，转换94以前的，一切正常。然后，把94-376的转换，嘿！还是那个界面，但现在根本就不存在376啦！所以我意识到从那些行根本不会找到突破口。重复以上操作大概3、4以后，剩下3篇文章，卡住。剩下2篇！最后一篇！肯定是这里的问题。村友们，你知道我发现什么了吗？见下图：
LogDate包围的日期居然是0000-00-00 00:00:00！！！！难怪Python会报错！而这等事情是怎么发生的呢？fish故意的吗？不是，是BlogBus可以算bug也可以不算bug的地方。为什么这么说呢？因为我是那种在记事本写完日志往blog上贴的人，记事本时间提取是用F5，只有yyyy-mm-dd hh:mm，而BlogBus的格式是yyyy-mm-dd hh:mm:ss，所以，我就要把前面的粘上去，留默认的秒数，但如果我一不小心粘错粘漏了呢？BlogBus会默认把时间设定为0000-00-00 00:00:00！于是，发现新文章不见了的xrspook就会翻到日志的最后一页把那个莫名其妙的日期改回来。大概当时fish没发现这等问题，以为是自己出错了就没去理会，所以，导出数据中就存在了个那么匪夷所思的日期。程序是认规律不认人的，它觉得年一定是从1开始，月只有12个数，日是1-31，若超出范围，它就笨蛋不懂了，前提是，它不会BlogBus的日期潜规则，若有人让它增强读取BlogBus的潜规则并把那个诡异数转化为转换当场时间的话，杯具就不会发生。所以，看来很严重的问题，把几个0改为正常数就行。解决方法很简单，但查找就异常曲折。成功那一刹那我是多么的高兴啊！！！
信心满满地把转换好的数据传给村屋首领，却又出现怎么都导入不了报错的现象。难道fish就那么背？在多次尝试，包括重装WP之后，首领提出会不会是导入.xml的格式不对，解释错误导致报错？接着，我发现他装的居然是2.8.5，我转换用的是2.8.6啊！转出来的数据适用于2.8.6后（即2.9系列），新数据导入老系统，不错就见鬼了。于是，我把经过一层转换的导进去，问题解决。大功告成，村友们，我们狠狠地拥抱一下吧！
以前都是自己解决自己的问题，或者请求别人解决自己的问题，但这次居然是xrspook帮助他人解决问题，真让人有飘飘欲仙的感觉。几个即时通讯工具闪个不停~~~
妹爱的不是钱，妹爱的是成就感！
于是，你知道我为什么乐了:)
