[追記] 予想通り、このスクリプトは不要でした!
| jq <filter> | jq -s
でイケます! ポイントは jq と jq -s を分けること! jq -s はレコード指向ではなく全体をまるっと扱うオプションなんだけど、おかげで filter の指定方法が変わってしまう。しかし「抽出、加工」と「整形」を分けてしまうことでその問題も解決できちゃう。
こうなればいいんじゃないのかな?
— eban (@eban) November 13, 2018
あとはパイプで別のjqでもいいし。
% jq -sc . nd.json
[{"key":"value"},{"key2":2},{"key":null}]
さすがっす…。
改めてまとめると、jq の出力だけに注目すると
default | 謎の format |
-c | ndjson |
-s | いわゆるJSON |
ただし、-s オプションは filter の動作も変わってしまうので、
jq <filter> | jq -s
で出力するとよい。
以下は要らんドヤりでっす!
jq は JSON の中から欲しいデータを抽出したりできる便利なコマンドなんだけど、そのまま出力すると NDJSON ( Newline Delimitted JSON ) のようなものになる。
{
"key": "value"
}
{
"key2": 2
}
{
"key": null
}
このように Array を意味する "[" "]" もその区切りの "," もない形になってしまう。
正確には1行1レコードじゃないので NDJSON とも呼べなくて、こういう微妙なフォーマットをデフォルトにされると他のツールと互換性がなくなってしまうので嬉しくない。
そこでいわゆる本来の JSON にしたい場合はちょっと工夫が必要になる。
※ もしかしたら jq 自身にそういうオプションがあるかもしれないので、その場合は以下のコードは無駄です。
jq には -c オプションがあるので、これを使って出力すると余計な改行などがカットされて正しく NDJSON になる。そのうえで、こんな awk スクリプトを用意して、
#! /usr/bin/awk -f
BEGIN {
print "["
}
{
if ( last_line ) { print last_line "," }
last_line = $0
}
END {
print last_line
print "]"
}
以下のように
| jq -c <filter> | awk -f nd2purejson.awk
みたいなことをして各行のお尻に "," を付加して [ と ] で挟んでやれば ok.
awk はこんな風に面倒なロジックを考えずにちょっとした工夫で加工が済んじゃうのがいいんだよねぇ。
今回の工夫は今読み込んだ行を出力するのではなく、さっき読み込んだ行を出力するようにタイミングをずらしてやると、最後の END で自動的に最終行だけ異なる出力にすることができるというもの。これでいわゆる「ケツカンマ」を避けて正しい JSON を作ることができる。
※ 逆に JSON は jq -c . だけで NDJSON になるよという話でもあるんだけど、さすがにこれだけで独立したエントリ書くのははばかられますな。
これまでの環境
Mac を使っているんだけど、普段 Web ブラウザは
- Camino ( PPC Mac の常用 )
- Firefox ( PPC Mac の開発用 / Intel Mac の常用 )
を利用している。
Firefox はバージョンアップするたびに速くなっているとは思うのだが、開発者の視点で拡張を増やしてしまうためにどうしても重くなりがちなのと、自分の環境ではメモリ 2GB 積んでても 300MB 以上メモリを食い始めた段階で妙に Firefox が重くなってしまう。他に大きなアプリが動いていなくても。特に feed 消化のためにたくさんのタブを開いたり閉じたりしていると如実に重くなってしまので、300MB をメドに再起動するようにしている。
面倒だなと思いながらも、放置してると使いものにならなくなるので仕方ないと思って手作業をくり返し投入するのはやはり精神衛生上よろしくない。そこで試しにネットカフェなんかでたまに使う Google Chrome をそろそろ常用してみたらどうだろう、と重い腰を上げてあれこれ試してみた。
まずは素の Chrome
実は Chrome はインストールしてあるので使うのはすぐ使える。黙ってアップデートする Chrome 様なので、もちろん自分の環境の Chrome も最新である。
起動も十分速いしページの読み込みも速い。タブを開いたときの動作は Firefox の方が速い気がするけど、開き終わったタブ内での動作は速い。
ではカスタマイズします
とは言え、素の状態はあまりにつらい。自分の使い方で常用するには以下のものがあればよいみたい。
delicious
まぁ bookmarklet でもいいんだけど。
Delicious Bookmarks Extension (Beta) - Google Chrome 拡張機能ギャラリー
十分速いし、まったく問題なく使える。
AutoPagerize
さすがにこれがないとつらい。
AutoPagerize - Google Chrome 拡張機能ギャラリー
LDRize
Chrome Keyconfig - Google Chrome 拡張機能ギャラリー
Greasemonkey のときは mini-buffer とかいろいろ必要なんだけど、mini-buffer 使ってなかったのでこれだけで済むのは嬉しい。
popup block 対策
これないと死ぬ。LDRize だけでは o でウィンドウを開こうとしても popup window が殺されてしまううえに FLDR 側で block されたことが分からないので単純に pin がなくなってしまう。
LDR open in background tab for Greasemonkey
を入れて対処。
user css
Chrome Stylist - Google Chrome extension gallery
起動オプションでも user css を有効にできるようだが、@moz-document 相当の機能があるかどうかまで調べきれていない。上の Chrome Stylist では可能。
例えば twitter で勝手に表示される更新分の表示を切ったり、実はこまごまと user css を当てて使っているのでこれがないと結構困る。
Type ahead find
Type-ahead-find - Google Chrome 拡張機能ギャラリー
今は Firefox の方は find as you type って言うんだっけ。検索のアクションをわざわざ起こさなくてもキーを押すだけでリンクになっている文字から検索してくれる優れもの。
ただし日本語 UI のサイトだとほとんど意味を成さないので悲しくなることも。
user script はちょっと考える
自動起動してよいものは Greasemonkey のようにどんどんインストールできる。
GM_registerMenuCommand (だっけ)の必要なものは bookmarklet から起動することでなんとかなった。mongoose(旧shttpd) で localhost に geekmonkey 専用サーバを起こして対応。
自動起動はとりあえず Browse Lingon Files on SourceForge.net で。開発終了してるので今後のことはまた考える必要あり。
cf. あーありがち - Yet Another Geekmonkey
よく分かっていないもの - 設定ファイル
Mozilla で言うところの user.js のように使い回せる設定ファイルはないのだろうか。なんか同期をとるための拡張があるみたいだけど、完全に同期してほしいわけでもなく、必要なものだけ手動で揃える程度でよいのだ。
特に user css なんかはこの形になってると自分用の repository に置いておくだけでよいので非常に嬉しい。
とりあえず断念したもの - 外部エディタ
Firefox では Dafizilla ViewSourceWith :: Add-ons for Firefox を使っているんだけど、調べると Google Chrome はセキュリティポリシーで外部プロセスの起動は NG らしい。そこでエディタと通信するためのサーバを立てて Ajax でそいつと通信してエディタに textarea の内容を送り、編集完了後の内容を取り込むという非常に大げさな仕組みがあるらしい。
- Edit with Emacs - Google Chrome 拡張機能ギャラリー
- Google Chrome のテキストエリアを外部エディタで編集する Edit with Emacs - 酒日記 はてな支店
実は rack 版もあって仕組み的には面白いとは思うんだけど、自分の場合は普段 emacs-server は使ってないし、textarea に js が組み込んであってそいつがすでに ajax してるような場合(Simplenote の textarea など)はまだ安定動作しないみたい。
ということでこの日記は Firefox + ViewSourceWith で書いている。write より read の方が機会は圧倒的に多いので、潔く諦めてしまうことにした。
たまたま ruby-lang.org のリファレンスを見ていたら 1.8.2 以降はPStore のバックアップファイルが自動的に削除されるようになったらしい。ほー。
今まで tDiary を使っていて、cache の中に大量の *~ ファイルができるのがなんだかなぁと感じていた。まぁ自分は Emacs 使いなので、自分でも *~ ファイルは日々大量に生産しているわけだけれども。これがなくなると。ローカルのバックアップを確認すると確かに *~ のある月とない月が混在している。いいじゃないの。
手元のも 1.8.2 用のリファレンスだったはずなんだけど、更新されたのね。よしよし 2005-10-29 版が最新か。ではありがたくゲットさせていただきます!
だったのですが。お店のセッティングの問題で前方(主賓の目の前)で起きていたことのほとんどを見ることができませんでした。まーこっちは久しぶりに(安)ワインかっくらっていい気分だったんで、どうでもいいっちゃいいんですが。(こら)
言っとくが、おれはこんな席設けんぞ。まーごくごくごく近しい人とはうまい酒を飲みに行くと思います。行きましょう。師匠は呼ばないのかという話が一部で出ましたが、「呼んでどうする」という気持ちの方が強いので呼ばないでしょう。呼ばれた方が楽しめる席でないと。呼ばれた人間の気持ちが中途半端になりそうな席っていやなんですよ。ヘタレだけど完全主義だから。
ヘッダ、フッタをなくす方法が分からん。えーどゆことやねん。Mac 版だけのバグ?
にある今回の顛末のまとめは分かりやすい。
個人的には
- そもそも RD ってものがあやふやすぎ(Working Draft なのか仕様が確定したのかもよく分からん)
- RWiki とかで使ったり Ruby 界隈のドキュメントフォーマットとして標準的に使っているはずなのになぜか RDTool はいつまでも標準配布されない
- Perl の pod のツールのようにさっさと標準で入れるべきだった
- そのくせ RDoc はさくっと標準配布になったのはどういうことだ
って段階でかなり間違っていると思うので、ぜひ標準添付していただきたいなぁ。ただこの話をうまく ML に投下する自信はないので、とりあえず忘れないようにここに書いておく。
RD に限らず、なんだかよく分からないふにゃふにゃな状態で不便な思いをしている Ruby User(Not Ruby Hacker) が実はたくさんいるんじゃないかということが、もう少し運営サイドにうまく伝わるといいんですがね。「じゃーお前やれ」だけじゃなくてね。例えば協力者の募集にしたって、何を協力してほしいのか分からなければ集まらないと思うわけですよ。
www.ruby-lang.org のメンテナの話もそうだけど、どれくらいのスキルがあれば手伝えるのかも分からないんじゃ、怖くて手挙げられないもん。スキルだけの問題じゃなくて調整とか必要ってんならそれこそ手伝える人は限られちゃう。例えば別に Ruby に深く commit してるわけじゃないけど、便利に使わせてもらってるし、サイトの保守・運営のノウハウはあるから手伝うよ、って人もいるかもしれない。でもメンテナンスの中に内容の精査が必要なものが入ってきちゃうともうそういうお手伝いは不可能になる。というかそもそも公式サイトのメンテナ不足なんて少しもアナウンスされてないっつーところが問題ですな。人が集まるわけがない。
言語そのものは 10年経ってるけどまだまだ Ruby に commit して publish するコミュニティは成熟できていない。そういうことの一端が今回表に、少し過激な形で出て来しまったってことのような気もする。
Thunderbird for OS X でのインポートに失敗
- Thunderbird 0.9 for OS X で UNIX From 形式の mbox のインポートがうまくいかない
- 同じ mbox ファイルを Thunderbird 0.7.3 for Windows ではインポート可能
添付ファイルの展開に失敗
- 最初 mbox をテキストで直接見ていた(いつもの作業環境と違ったのよん)
- 添付ファイル発見。Content-Type: application/msword 確認。
- base64 のデータを切り出して nkf -mB でデコード
- できあがったファイルを、、、開けません
結論としては
- しまってあった Windows + Datula な環境を起こしてデコード → 開ける
- インポートできた Thunderbird で見るとそもそも添付ファイルがない
- 頑張れ Thunderbird。バージョン上げろってか。それとも単に Datula が優秀だっただけか。OE 6 のメールくらい正しく解釈しないと社会でやっていけませんよ > Thunderbird
- まてよ。そもそもエクスポートを別なマシンの Datula でやったんだから、そっちを疑うべきか?
nkf -mB でのデコードでうまくいかなかったのは単なる自分の力量不足だろうか。よく分かんねーけどただのテキストデータを Word で打って添付してくんじゃねえ!(逆ギレ)
from CNET Japan
はい。前回の続き。
超乱暴に言うと PowerPoint をアウトラインプロセッサとして使うって話。まぁそうね。間違ってないね。
Line Marker の(まて)Piro たんとこ。なかなかねー。JavaScript ってまともに時間取って勉強する時間取れないんだよな。テキスト野郎なんでファイルとかデータ処理できないとつまらないってのもあるんだけど。
ま、そのうちそのうちっつーことでメモ。JavaScript も DOM もおさえておきたいと言いつつもうどんだけ経つんだ。