因为有闲工夫就倒腾 blog 的代码，所以攒了很多想写的话题。现在算是差不多了，不过打算写的时候，发现想要插入一张 Flickr 上的图片可真麻烦。要是只是一张图片还好，不过按照 Flickr Community Guidelines 的规定：
Do link back to Flickr when you post your Flickr content elsewhere.
所以除了嵌入图片，还要加一个链接，正如 Flickr 提供的 HTML 代码所做的。
于是写了一个 Greasemonkey 脚本来做这件事，安装之后再到 Flickr 的照片下载页面（在自己的某张照片页面点击 All sizes 按钮）就会看到多了一种代码选项，如下图：
没错，这张图所用的 Markdown 代码就是从图中绿框里复制出来的。
相信用 Markdown 的人很少，不过还是把代码分享出来：
新的 blog 上线之后，只是做了评论的展示，却一直懒得做提交评论的功能。
最近一段时间我隐隐感到一股神秘的力量正在积聚，肯定有人是因为不能发表评论憋坏了……于是我抵抗住了左邻右舍飘来的饭菜香气，终于完成了评论功能。请踊跃发表贺电！
简要教程
左上角的框添昵称，右上角添电子邮件，下面的大框自然是评论内容了……再有空了，我就给上面两个框各修饰一下，以便区分。
目前有人写了评论我也不会立即知道。不过我会时不时到数据库里去看一看的，哈哈。
Markdown 是一种轻量级的标记语言，两位牛人从纯文本邮件的格式惯例中借鉴了一些想法，规定了该语言的语法。因为标记语言的英文是 Markup, 所以大家看 Markdown 的名字就大概了解作者的意图了……
著名的面向程序员的问答交流站点 Stack Overflow 即采用 Markdown 作为用户输入中格式化文本的语言。我的这个新版 blog 也在后台采用这种格式写文章，很快就会上线的评论功能也将用 Markdown 作为输入格式。
我个人比较烦可视化 (WYSIWSG) 编辑器，因为大部分都异常臃肿（客户端加载慢，用户体验差），生成的代码非常垃圾。我使用 WordPress 的时候，也从来不用它自带的 tinyMCE，quick tag editor 挺好用的。
Stack Overflow 可以放心大胆地使用 Markdown，因为它面向的是程序员群体，即使从来没有接触过，稍微看一下帮助也就没问题了。如果真的不会，那你走错路了，我说程序员的平均水平咋这么差呢，你还是该干嘛干嘛去吧。
Flickr 不是面向程序员的，不过它同样没有在图片评论框使用可视化编辑器，而是使用了自定义图片、链接格式加部分 HTML 代码的形式。这一方面也是因为在评论框中输入大量格式文本的需求不是那么大。我觉得这样很好，稍微有点脑子就很快知道怎么格式化文本，那些智商实在太低的，就淘汰掉吧。
可是有时候不得不面对低智商的用户群，以前跟一个朋友交流，他就说，应用了可视化编辑器，许多用户还是不知道如何插入链接、图片。如果你不得已需要在网站上应用可视化编辑器，我推荐 NicEdit。
使用非 HTML 代码作为用户输入方式，还有一个很大的好处，就是你可以放心地过滤掉 HTML 代码，不需担心用户夹杂恶意代码。最近很感兴趣的 web.py 中，就提供了一个方便的函数 safemarkdown 来做这样的事情。
写完才发现，类似的内容我以前就写过一篇了：
blog 初步迁移到了自己写的 python 程序中，目前还非常简单，连评论也不能添加。在我自己的项目管理系统里，我就叫这个 milestone 0.1，到 0.2 就会有评论功能，肯定在一个月之内会实现。没有评论功能，意味着不能接受大家的贺电了，请抑制一下你们激动的心情…… (其实我是在响应号召，为建设和谐社会作贡献)
大约从 05 年底我开始写 blog，最初似乎是在 donews 提供的 wordpress mu 平台上写（我不太清楚之前有没有在其它的一些 BSP 写过没有了）。很快为了自己能更加方便地自定义而选择了租用空间自己管理 WordPress. 其实 WordPress 对我影响非常大，我的 Web 开发就是从定制 WordPress 开始学起的，尽管 PHP 一直不是太熟悉，后来用 Java 比较多。
所以转移阵地并不意味着 WordPress 不好。作为一个通用 blog 软件，它功能齐全，很容易定制，还是非常适合刚开始尝试自己架设 blog 的用户（或者刚刚弃暗投明从 sina, 163 等 BSP 过来的人）。我只是有了更加确切的需求，并且想放弃 WordPress 的大部分附加功能，同时借机学习一下 python. blogging 也是需要新鲜感的，所以每次 WP 的编辑页面升级的话，会大大提升写文章的欲望（虽然回头看时觉得文章大部分都是垃圾）。我现在确实有点厌烦 WordPress 了，并且在一个自己从头写出来的系统中，我可以更容易实现新的想法，甚至有些想法在 WordPress 中几乎不可能实现。
从写程序到迁移，这个过程回头看有点长了，虽然我给自己留出了余地，还是比预定的时间晚了一周。没有足够的时间和精力，加上有那么一点点完美主意情结，导致在做很多选择时都比较犹豫，比较纠结。
此次选择了 web.py 作为 framework, 它网站的 header 里说是 “the ideal way of writing a web app”. 我用过的 framework 不多，不过每个总有这样那样让人深恶痛绝的缺点，到现在为止，web.py 还没有让我不爽的地方。
原来的域名 qingbo.org 几乎所有的 url 都会 301 跳转到现在的 qingbo.net，而 qingbo.org 是我唯一一个在国内买的域名，鉴于现在的形势，我这样做也正好。目前只是做好了 blog 系统，把它放在了 /blog/ 这个路径下，根路径下准备放更多的内容，现在还在计划中，至少得过完年才能出来了。
以后业余时间接触 python 就比较多了，希望能有机会和这方面的高手多交流 🙂
第一次从 Windows 向 Linux 传文件的时候，我找到了 WinSCP，于是就以为世界上只有它可以干这个事情，一直以来都是用它在 Windows 和 Linux 之间互传文件，当然 samba 不算了。
最近经常在 Windows 里用 Excel 处理一些数据，保存成 csv 格式再放到 Linux 里继续处理。正好那台 Windows 上还没有安装 WinSCP，我就通过 Windows 共享中转到 Mac 上，然后再 scp 到 Linux 服务器上 —— 我也不知道我为啥自己懒得装 WinSCP 🙁
前几天实在受不了这个繁琐的过程了，在下载 WinSCP 之前搜了一下，原来 Windows 上也有成熟的 scp 命令行工具，即与 PuTTY 项目中的 pscp —— 不知道去那个页面下载过多少次 PuTTY，却没有仔细看 PuTTY 之外的其它程序，惭愧惭愧。我不知好歹炫耀新发现的时候，发现某些同事早就在用 pscp 了……
简单试用了一下 pscp，就我目前用到的功能，和 Linux 上的 scp 完全一致，非常方便。
建议习惯命令行操作、嫌鼠标麻烦低效的用户放弃 WinSCP，使用 pscp.
关闭了所有文章的评论，打算重新整理一下自己的网站，包括 blog 在内。
可能将来就不再使用 wordpress 了。
过半个月或者一个月，你就会看见我的新网站巍然屹立在 linode 上，以全新的技术（对我来说）驱动。
关闭评论，就可以把数据拿回来随便玩了。
扭曲的生存环境当然会造成扭曲的技术环境。在大部分技术人才没有房子可住的情况下，当然会有好多人选择所谓的“捷径”，去“精通”一些歪门邪道的东西。是啊，整天为房租或者还贷以及其它高昂的生活费用发愁，哪儿有那么多闲心去钻研真正可以称为技术的东西呢，这是可以理解的。
大多数（不是全部）“精通” SEO 的人，不会知道所谓 web 标准，不会知道 HTML 4，但是他们知道 h1, strong, meta-keywords, meta-description，还会熟练地用蹩脚的代码隐藏一些肮脏的东西在页面上，引来一阵艳羡。
作为某大公司的客户，拿到他们的 API 文档，废话连篇也就罢了，错误百出。打算写邮件给他们，写到一半就放弃了，烂得不可救药，让人连提建议的心都没有。这方面跟他们国外的竞争对手比起来差的是十万八千里，不过人家在国内活得滋润得不得了。说到最后，还是市场即环境决定的，他们不会把主要资源投到这么“没钱途”的事情上。
再往上说到那些高校实验室、研究所，里面有几个人在真正做科研？拉帮结派搞关系，骗国家钱，压榨学生才是来钱的正路。当然不是所有的老师都在这么干。
穷则独善其身……
公司在 SOHO 尚都，看起来很时尚很前卫的楼。租的是一间 LOFT，空间超大，非常开阔，墙壁多半都是玻璃，很亮堂。不过住在里面，很快就发现缺点不必优点少：
周围也有其它的 SOHO 建筑，应该都是出自万科，同事说都是中看不中用。是啊，破烂的办公楼见的多了，但是从来没有遇到过空调、电力、网络都这么差劲的……
上篇文章留下这么一个疑问，本以为被琐事缠身，没时间再写了，不过发布完之后正好将某事推掉，于是有时间马上写这一篇。造一个句：如果志不同，那么道不合。跟很没劲甚至很烦的人在一起吃饭，不如饿着肚子弄点技术方面的东西。我鼓捣的也不是很有技术含量的东西，就是有兴趣。
下载并正确配置 Flex SDK 以后，就可以使用 compc 命令了。这个名字实际上是 component compiler 的简写，就是用来生成 swc 文件的。还有一个命令叫 acompc，前面加的那个字母应该是指 AIR，它与 compc 的区别只是加载了不同的配置文件而已，所以本文以后就只使用 compc 了。
执行命令 “compc -help list” 就可以看到许多的编译选项，最重要的：
知道了这些就可以编译了 (我的当前目录下面是 twitter-api 目录，里面的 src 子目录里就是 svn export 的 http://twitterscript.googlecode.com/svn/trunk/src/)：
[code lang=’text’]
compc -compiler.context-root=twitter-api/src/ -include-sources=twitter-api/src/ -directory=true -output=twitter-swc
[/code]
于是在当前目录下生成一个子目录叫 twitter-swc，里面的 library.swf 就是我们想要的文件。可以再加上一个参数 “-compiler.debug=false” 来编译，获得更小的输出文件。
在 Adobe AIR 的首页上，就给出了三种 AIR 编程的途径：
Flex 编程中应该也会用到大量的 AS 编程，但是 Ajax 方式的 AIR 呢？一开始，我认为它利用与 Web 编程几乎没有差别的环境吸引了以前熟悉 Web 应用的开发者，但是却牺牲了 Flash 强大的表现能力，如果用 JavaScript 实现 Flash 同等的动画效果，难度和复杂度应该会大很多。
但是很快我就发现这个顾虑是多余的。Adobe 的 livedocs 中就有一个页面教大家怎么在 HTML 页面中调用 AS 的 library：”Using ActionScript libraries within an HTML page”
Adobe 对 webkit 做了一个小小的扩展，使其支持新的脚本并与 JavaScript 互通：
[code lang=’html’]
[/code]
该 swf 中的 AS 代码里的变量，怎么在 JavaScript 中引用呢？通过 window 变量一个特定的属性 runtime：
[code lang=’javascript’]
var libraryObject = new window.runtime.LibraryClass();
[/code]
大家还是看帮助页面吧，不过我几乎快把人家的东西全抄过来了。ActionScript 3 和 JavaScript 本来就应该遵循一个标准 – ECMAScript，这样也合情合理。
有些人可能奇怪了，你既然选择了使用 Ajax 途径，干嘛还又要用 AS 呢？其实就是有时候图个省事。比如我要写一个 “推特” 客户端，上网一搜，发现了根正苗红（倒不一定非常好）的 twitterscript，不想再重新造轮子，不过它是用 AS3 写的，我也懒得再把它翻译成 JS.
于是把项目提供下载的 swc 文件拿回来——那其实是一个 zip 格式，解压后，拿到我们想要的 library.swf，把它按照 Adobe 教的方法加到 AIR 程序的 HTML 页面中，马上就可以在 JavaScript 中使用这个库了！
有耐心看到这里的读者一定有个很大的疑问，怎么从一堆 AS3 代码得到这个 swf 文件的呢？假如要对 twitterscript 的源代码做一下修改怎么办？这还得回到刚才的那个 livedocs 页面，最下面有个 Note：
To compile an ActionScript SWF library for use as part of an HTML page in AIR, use the acompc compiler.
这里就不再细说了，这个 acompc 在 Flex SDK 中有，和其中的 compc 其实是一个东西（我觉得）。有兴趣的朋友自己去研究一下怎么编译吧，也许我再有空了会写一篇文章说说这个。
Update: 说时迟，那时快——如何将 AS 文件编译成为 swf