Linux命令行json解析工具——jq

jq基本使用可以参考这篇文章：

jq英文文档请参考：

=================================================================
基本格式：
jq [参数列表] ‘过滤条件’ 文件名或标准输入
例：
jq -c ‘.foo’ a.json
或：
cat a.json | jq -c ‘.foo’

=================================================================
参数说明：
–compact-output / -c
默认情况下，jq会将json格式化为多行树状结构输出，但有时需要将一个json串在一行输出，即可使用该参数
=================================================================
过滤器说明：
.foo, .foo.bar
获取json中key的值，可过滤出多级json串中的key值。
.foo, .bar
同时获取json中多个key的值。但过滤出的多个值会分多行显示。
{foo: .foo, bar: .bar}
获取json中部分key的值，并组合为新的object形式的json串。foo与bar即新json串的key，.foo与.bar即原json串中需要获取值的key。
注意，生成的json串内容顺序是倒序的，上例中会生成：{“bar”:””, “foo”:””}
[.foo, .bar]
获取json中部分key的值，并组合为新的数组形式的json串。.foo与.bar即原json串中需要获取值的key。
注意，生成的json串内容顺序是正序的，上例中会生成：[“foov”, “barv”]

本来是想介绍Semantic-UI的，但如果只介绍这个框架，没什么内容，框架相关feature站点上有不需要说，所以干脆列出自己常用的几个前端框架，算是做个阶段性总结。本文的核心是侧重于HTML/CSS的框架，JS框架或以JS为核心的框架不讨论(比如YUI)；多屏已是既定事实，虽然不是所有开发都要考虑自适应，但有自适应功能至少说明了这框架短期内不会被淘汰，所以不带自适应功能的框架不讨论(比如flaminwork)；非开源、不可商用，或是需要付费的框架不讨论(比如easyframework)。

先说Bootstrap，这两年都在用它，如今Bootstrap有点烂大街了，难免有些审美疲劳。但想想在Bootstrap这种框架出现之前，程序员做的界面实在是惨不忍睹，如今至少升级成“还能看”的级别了，所以“泛滥”这个问题是瑕不掩瑜的。平时开发个小工具用它来做界面，写个底层脚本用它来做文档界面，工作环境中也可以用来做原型或是布局，谁都看得懂没什么学习成本。总体来说，这个框架对于互联网的美化实在是功不可没。

Bootstrap的优点是拿来就能用，节省时间。缺点是class满天飞（也许你看到这篇文章的时候它已经变好了但不影响我现阶段的吐槽），而且不够语义化，也不适合做定制——最多改改颜色，如果对自适应有定制需求可以考虑用Foundation来替代。这个框架我最初是用来写产品原型的(这个用途现在已经被Bootstrap替代了)，结果到3.0版Foundation更改Title为“全世界最先进的前端自适应框架”(most advanced responsive front-end framework in the world)，是否最先进有待商榷，但它在自适应方面的定制性确实比Bootstrap好，Bootstrap有的控件它都有。

我没在生产环境中用过Foundation，12年6月它由原型工具转型成前端框架时，Bootstrap已经很流行了，有Twitter做技术后盾，不太可能说服程序员转向Foundation。现在的4.0版本用Zepto替换了jQuery，如果项目中在用Zepto可以考虑用它代替Bootstrap。

接下来才是本文的重点——Semantic-UI。这名字就是它最主要的卖点了：语义化。Semantic-UI比Bootstrap更语义化，使用了更容易理解的标签名称：导航的是nav，主要内容的是main，class名也很明确，而且不像Bootstrap需要套很多层。Bootstrap很通用，兼容性很好，甚至能兼容低版本的IE，Semantic-UI则更Geek，有不少CSS3的特性，比如Shape和Reveal就很有趣。从界面设计风格来说，Semantic比Bootstrap(2)更扁平化：

这些特性都很fancy，但我现在用Semantic-UI替换Boostrap，主要是因为它的JS插件(Modules)更容易操作，预设了一些常用动画，视图(Views)中的评论(Comment)和动态信息(Feed)实在是帮了大忙。反正我需要用到的Bootstrap功能它都有，于是欢乐的更换了Semantic-UI。大多数的样式效果Semantic-UI都比Bootstrap代码量少，在相同的熟练程度下开发起来比Bootstrap快。而且提供多种主题，一定程度上避免了Bootstrap千站一面的问题。

再找找缺点，我刚开始用的时候，被Semantic-UI的Grid坑过。自适应的问题，bootstrap通过md/sm/xs定义在不同屏幕宽度下的显示，虽然麻烦，但容易控制。Semantic-UI是用Stackable/Doubling来实现，而且还能手动调整，不知不觉就被玩坏了。似乎这个框架的设计接近Ruby的哲学而不是Python的，同一个需求有多种方式来实现，比如我要实现列表，可以用List或是Items；要实现侧边栏，可以用Rail或是Grid，选择多了有时候也是很纠结的问题。还有，Semantic-UI完整的库文件很大，JS+CSS文件有接近500kb的大小，考虑到国内的网速，这个体积显得有些庞大了。可以用NodeJS自己build，前提是清楚每个组件具体是干嘛。

以上框架适合擅长实现功能(前端的JS以及后台相关交互)但不擅长设计的程序员，用以上框架可以快速做出一个不错的Web界面。另一种场景是自己会设计，或是由专业设计师出设计，再转成HTML/CSS，上述框架就太重了，很多功能用不上。

这种情况我通常只需要框架来做布局(Grid)，10年写过一篇文章介绍网页设计多用960px宽度的原因，当时还在用960gs，但自适应的需求960gs满足不了，就用了一段时间的lessfreamwork。最近960gs的作者开发了unsemantic，于是又换成了unsemantic。在编写自适应网页时，要根据设备的不同加载不同的css文件，unsemantic都替你切分好了，省时省力。