随机应变

也许有时候得承认,一个人用地最多的语言多多少少会影响到对其他语言的看法.
毕竟,每门语言都有自己独有的模式.

最近又用NodeJS写了点东西.

选它的理由很直接.

因为是想用SVG画点简单的图形做logo/icon之类的.
所以最直接的思路就是打开Chrome console里直接SVG的JavaScript API画.
简单封一下就是命令式的作图工具了.

虽然说,解决这个问题的方法很多.
比如SAI/PS什么的,花样还多些.
或者退一万步来说,也有现成的SVG library或者现成Pixlr App,也不用自己手工写.

但想想,可能只是简单画线而已了.
所以大概不用上这么些重量级的东西.
而且自己写的,多少可控些.

说到底,可能还是某种NIH Syndrome的表现吧.

于是,既然前面所见部分都是Javascript了,那么后面存储转换什么的,也就直接NodeJS了.

虽然原则上来说,处理小事情个人还是偏向python的.
但对于这可能最多几百行的东西来说,异构的技术栈可能没那么必要.

而且有一点是,至少从Http模块来说,NodeJS可以直接上手.
python内置的那个,多少还得做点事情.

事情到这里其实都还是意料之中的.

直到开始考虑SVG转PNG的时候,大概问题就来了.

首先考虑的自然是imagemagick去做转换.

估计着NodeJS的流行度,找个binding库应该不难.

然而看了Google Search头几条的基本都不维护了.
而且稍微翻了下实现,都是直接spawn一个命令行convert出去的.

当初考虑用binding库的时候就是不想这么做的.
而且,如果接受spawn的话,自己spawn就行了,何必再带一个第三方库.

于是想想,这些项目被主动abandon倒说明作者还是有点良心的.
免得别人写个hello world还得带上一堆三方库.

不过native的binding也还是有的.

问题在于,NodeJS的许多库,它存在不代表可用.

由于node版本的关系,目前node-imagemagick-native master的版本对4.0.0这个版本的node是不行的.
大概是依赖的nan库还没跟进上.

说到底就是v8的某些接口改了,上游没跟进,于是下游自然也没办法.

暂时妥协,nvm换低版本的node.

本以为就此结束了.

然后事实是始终无法svg to png.
直接异常,还不带堆栈.

至少看看怎么改对应实现一步步debug看下什么问题.

所幸的一点是这项目的gyp配置写得还不错,build没问题.
于是把吞掉的异常重新抛出来看了下.

大致是SVG本身算是XML文本,跟其他通常意义的image格式的一个明显差别是没有明显的meta信息.
尤其是图片规格/大小.

这个虽然说可以在XML里作为属性附上,但毕竟不是必选项目.
而且要一个图片处理库去处理XML,换自己也懒得去管.

所以,问题是convert的时候需要提供一下SVG的size.

然后回头看了下node-imagemagick-native,根本就没考虑这种情况.
于是proposal了个pull request加个参数解决.

但即使接受也不知何年何月的事情.
况且还有node版本的问题待解决.
加上看了下node的native module也不难的样子.

于是去翻了下gyp的文档.

看完之后的一个想法是.
这不清不楚的居然是官方文档.

不过gyp本来就是一个特定项目的build tool.
自己人自己知道怎么用,文档不是太重要.
被node拿去用,只能说node社区就是这样的性格/风气.

依照的有限的文档写配置,build.
结果确实什么都没发生.

对比了下generate出来的makefile和node-imagemagick-native的区别,发觉是cflags/ldflags没生效.

照文档的说法改了几种方式依然.
于是只能Google下有没类似案例再不行就只能看实现了.

所幸这个问题还算常见.
原因只是在OSX上,gyp是用另外的xcode相关的参数在generate的时候代替标准的clfags/ldfags配置.

于是只能再次感叹,gyp果然是一个自己人给自己人玩的东西.

不过一个意外收获倒是直接了解了gyp的大致parse过程.
也算是聊胜于无的收获.

解决完这个想着,该没什么其他问题了吧.

然而很快地build发觉居然还是symbol not found.

重新看了下generate的makefile发觉看起来不至于.

Google之后到了node-imagemagick-native的某个issue下面.

里面解释了说brew的magick++ build的时候link的是libc++.
而node link的是libstdc++.
于是感谢C++的mangling,symbol not found也就难怪了.

解决途径只能是告诉xcode,这里用的libc++,并且得指定targeting的OS是OS X 10.7以上.

然而,事情还是没完.

不过剩下的都是magick++的API设计问题了.
或者说SVG这种无相对有效meta信息的格式带来的问题.

所以convert的只能是empty image,然后设置完必要的size之后再read,然后write出去.
不然一般的话,应该可以直接构造image然后write.

不过这种超出写作时的设计范畴的事情,也只能这么解决.
毕竟,要单独弄一套API出来,可能更不好看.

不过最终还是convert完成了.

虽然说,自从之前被grunt打击过之后,对NodeJS的印象其实不太好了.
这次的一些问题更觉得node可能不太适合一些严肃的地方.

至于C++的部分嘛.
至少以后提到说over engineering的时候,大概有除了Java之外的候选了.

晚上重新review了下SVG的部分.

估计以后会再用到的时候会选path而不是polygon做代表了.

毕竟来说,path确实更general一些.

想想,不考虑曲线的话,可能也够了.

不过真有重新用的一天的话,大概会重写相当部分吧.
毕竟,到时可能思路和思考方式又不一样了.

所谓随机应变.