nDiki : JSON

オンラインのアウトライナー WorkFlowy Pro (有料)にした

オンラインのアウトライナー(outliner、アウトラインプロセッサ)サービスの WorkFlowy、しばらく使ってみたところなかなか良かったので有料の WorkFlowy Pro にした。有料版の違いは、

• 項目数の制限が無くなる。無料版は月500項目までなんだけれど使い始めるとあっという間に無くなるので、制限が無くなるのは心理的なブレーキが無くなるので大きい。
• 特定の WorkFlowy アカウントとだけリストを共有できる。他に使っている人がいる場合は便利。共有したリストの項目数のカウントはオーナー側につくので、無料アカウントの人も有料アカウントからリストを共有してもらえればガンガン項目追加できたりする。
• Dropbox への1日1回のバックアップ。結構地味に効く。プレーンテキスト形式と JSON 形式で各世代のものが保存される。間違えて消してしまったり、やはり消さなければ良かったというのにも後でアクセスできるのが安心感がある。workflowy.com が落ちたとしても、バックアップ時点までのは参照できるし。なお WorkFlowy からは「アプリ/WorkFlowy/」ディレクトリ以下の読み書き権限だけを要求するので、Dropbox の他のデータまでアクセスされてしまうのは嫌という懸念も発生しないので良い。
• テーマ設定とフォント設定の自由度アップ。

といったところ。

いろいろなアイデアやノートが貯まってきた時に、タグや検索を駆使してリストの再整理をしていくと、いろいろ気付きがありそうで楽しみ。

• https://workflowy.com/
  • このリンク先から登録すると通常の2倍のスペースが使えます。

Twitter API v1 完全停止

ついに Twitter API v1 が完全停止となった。

あー、自分の Tweet 取得スクリプトも一部は v1.1 に合わせたのだけれど、RSS フォーマット版で呼んでて JSON 対応は先送りしてたんだよね。

ということで cron で動かしているのだけれど取ってこなくなった。週末修正するかなぁ。それともメンテナンス止めて Twilog のログダウンロードで済ますかなぁ。

Thanks everyone! API v1 Retirement is complete. Please use API v1.1 instead. dev.twitter.com/blog/api-v1-is…

— Twitter API (@twitterapi) June 11, 2013

Twitter API v1.1 対応とか、パイプでやりとりするの JSON でいいのとか

Twitter API v1.1 に対応していないスクリプトがあって、たしか OAuth 対応はしてあるけど RSS 形式を使っていたので JSON で取得して処理するようにしなければなーと思ってたんだけれど、そもそも OAuth 対応すらしてなかった。

なので Net::Twitter::Lite を使うように書き換え。

あと、いままで1つのスクリプトで「Twitter API を呼び出してタイムライン取得」「シリアライズしてファイルに保存」「Wiki 形式に整形して書き出し」をしていたんだけれど、UNIX 哲学に従って小スクリプトに分割してパイプで受け渡すように変更するなど。

スクリプト間のやりとりは構造化テキストデータなので JSON にしたんだけれど、若干これでいいのかなぁ感はある。テキスト形式だし最近の主流フォーマットではあるんだけれど、それでもシェルから見ると複雑な形式な気がするんだよね。でもあと軽量な構造化テキストフォーマットだと YAML ぐらいかなぁ。

今日のさえずり: 浴室乾燥の影響でトイレが暑い

2013年06月16日

• 11:46 浴室乾燥の影響でトイレが暑い。
• 11:56 user_timeline 取得を Twitter API 1.1 からに書き換える必要あるんだけれど、差分大きくて本腰入れる必要がある。
• 16:05 2時間ほどペーパークラフトした。
• 16:22 ラムネを水に溶かす実験。
• 21:45 1コ Twitter API 1.1 対応した。ついでにスクリプトはスクリプトらしくパイプ使えるように分割した。
• 21:47 標準出力に吐いてパイプで受け渡すの構造化データなので JSON にしたんだけれど、ちょっとモヤっとする。

Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon

LINE株式会社で開催された Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon 「秋のPlack/PSGI祭り」に参加してきた。今回は YAPC::Asia Tokyo でもよくトークされている masartz 氏とご一緒させていただいた。ここの会場にくるのは「第3.5回 データ構造と情報検索と言語処理勉強会」「PerlCasual #05」に続き3回目。

• http://atnd.org/events/45276

開催を知った時には定員60人すでに埋まっていて補欠だったんだけれど、その後定員80人に増やしてくれたようで参加できるようになった。当日時点ではキャンセル等で定員切っていてきたい人はこれるようになってたよ。

普通に使う Plack/PSGI Server @fujiwara 氏

会場アンケートをとりつつ、必須な/便利なモジュールや Plack::Middleware の紹介。

• だいたい Starlet か Sterman を使っている。
• リバースプロキシ使っている時には Plack::Middleware::ReverseProxy が便利。
• Server::Starter の start_server では plackup を実行するシェルスクリプトを作ってそれを指定するようにするとパラメータ変更できるのでいいよ。
• Devel::NYTProf する時には if $$ % 11 == 0 などで一部のプロセスだけでプロファイリングするようにすると不運な人は遅くなるけど、全体の影響抑えつつできるよ。

『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3 を受けての話題 @kazeburo 氏

YAPC::Asia Tokyo 2013 の発表の続き。

Plack/PSGI のパフォーマンス向上の取り組みが進めば Perl の適用領域を広がるし(リアルタイムな広告系とか)、Perl 使いの仕事も増えるよ。

Plack::BodyParser の話 @tokuhirom 氏

• 最近のサーバーサイドの開発は JSON API の開発と管理画面の開発だよね。
• HTTP ステータスコードの使い方をシンプルに。アクセス自体が成功したら 200 を返して、API の結果の方に API 処理自体のステータスを入れる方がシンプルだし、アクセスログ処理なども楽だよと。
• JSON API のボディ内で返すステータスも HTTP ステータスコードと同じにしたら覚えることが少なくて楽。
• URI の /v1/ とか入れたりするけど /v2/ とか出たためしがない。

など。プラクティカルなトーク。

Plack::Request with Encoding @moznion 氏

リクエスト中のパラメータの decode を Plack で一箇所でやってしまう話。

Mojolicious の知りたい 10 のコト @yusukebe 氏

• morbo と hypnotoad。それほどパフォーマンス悪くない。
• Mojo::Base は使わなくていい。それほど機能無いし、Web 系以外では Mojo に依存したくないし。

「YAPC::Asia 2014 やります!」とのことです。

LT

@bayashi 氏の plackup -e でちょっとしたこといろいろできて便利だよという話や、@azumakuniyuki 氏の Haineko の話や、 @hkoba 氏のコントローラを書く人がいないプロジェクト向けのテンプレートエンジンの話や、@songmu 氏の .psgi からの卒業の話とか、@tasukuchan 氏のきまぐれオレンジ☆ロードについてのラジオみたいなビデオ LT とか。

空気を読まない(読めない)一方通行なビデオ LT は新しく。

今日のさえずり: きまぐれオレンジ☆ロードについてのラジオみたいなの

2013年11月20日

• 08:58 今日 #plackcon なの思い出したので ThinkPad 持って家出ようかな。今89/80人なので補欠まだまだ繰り上がりそう。
• 10:18 年末調整関連書類提出完了。
• 12:55 I'm at 株式会社ノハナ (渋谷区, 東京都) http://4sq.com/1fftymA
• 13:16 隣のエンジニアが妙にすき家推し。
• 13:24 すき家。 (@ 神戸 らんぷ亭 渋谷並木橋店) http://4sq.com/1itqSS7
• 13:49 場所把握した。 (@ 改良湯) http://4sq.com/1jlhmhK
• 13:56 参拝。 (@ 氷川神社) http://4sq.com/1ffErou
• 14:33 “SNSの“悪意ある発言”をブロックする「SMC4」　公的立場の人や企業に有用 | Techable” http://bit.ly/1b763ur
• 18:10 Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon 現在77/80人なので近い人行けばいいと思う。
• 18:28 ぼちぼち #plackcon 行く準備。 (@ 株式会社ミクシィ (mixi, Inc.)) http://4sq.com/17nUZWE
• 18:54 到着。 #plackcon (@ LINE 株式会社 渋谷オフィス w/ 2 others) http://4sq.com/17nZEaZ
• 19:09 「普通に使う Plack/PSGI Server」 @fujiwara 氏 #plackcon
• 19:13 Starlet か Starman がほどんど。 #plackcon
• 19:17 Plack::Middleware::ReverseProxy #plackcon
• 19:31 『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3 を受けての話題 @kazeburo 氏 #plackcon
• 19:46 Plack/PSGI のパフォーマンス向上 = Perl の適用領域を広げる。 #plackcon
• 19:58 Mac 率 95% 以上っぽくて脅威。 #plackcon
• 19:59 Plack::BodyParser の話 @tokuhirom 氏 #plackcon
• 20:02 「最近のサーバーサイドの開発は JSON API の開発と管理画面の開発だよね」 #plackcon
• 20:10 Plack::Request with Encoding @moznion 氏 #plackcon
• 20:18 Mojolicious の知りたい 10 のコト @yusukebe 氏 #plackcon
• 20:24 morbo と hypnotoad #plackcon
• 20:26 「Mojo::Base 使わなくていいと思います。」 #plackcon
• 20:32 「YAPC::Asia 2014 やります!」 #plackcon
• 21:27 きまぐれオレンジ☆ロードについてのラジオみたいなのが最後に観られたのが良かったですね(どの世代まで知っているのだ?)。 #plackcon
• 24:39 @noritaka_okabe あの一方的感がたまらなく良かったです。 #plackcon

今日のさえずり: 「闇開発」、意外と Google 検索結果少ない

2014年04月16日

• 14:44 特定班。 / “「ソーシャル新人類」の不夜城〜10代は何を考えているのか - 恐ろしいほど簡単な個人の特定、「匿名性」の...：ITpro” http://nkbp.jp/1kZXJ5i
• 14:44 アウトランだって! / “3D アウトラン ｜セガ 3D復刻プロジェクト” http://bit.ly/1kZXK9c
• 17:10 「闇開発」、意外と Google 検索結果少ない。
• 20:36 jq 試している。1行1データをいったん JSON の配列にするの cat data.txt | jq -R '.' | jq -s '.' 以外にいい方法あるのかな?

各行が JSON になっているログファイルを jq でチェック

各行が JSON になっているログファイルのチェックにコマンドライン JSON プロセッサの jq 使ってみた。

• http://stedolan.github.io/jq/

とりあえず | オペレータが肝なのと、フィルタリングには select 関数を使えば良いということを理解した。あと関数はパイプライン的に受け取るデータと、引き数とで受けとるデータとの2種類があるのでちょっと慣れが必要。普段からレシピを作っておく方が良さそげ。気がついたら http://www.naney.org/diki/dk/jq.html の方にメモっておくことにする。

ワンライナーで書けるのは便利だけれど、大量の JSON データでかつきちんと parse しないで正規表現で抜けるようなデータの場合は Perl でチャキチャキっとやった方が当然だけれど圧倒的に高速なのでうまく使い分けだね。

Android + Google Chrome で使える日記アプリ Journey

日記アプリ(ジャーナルアプリ)は「Day One (iOS) + Narrate (Android)」をメインで使っているのだけれど、「別のテーマで日誌をつけるのに分けたい」のと「Web ブラウザでも編集・閲覧したい」というのがあって Journey が良さそげなので使ってみることにした。

Android アプリは Google Play では Journal (by Journey) になっている。

• http://2appstudio.com/journey/

データは自分の Google ドライブに保存される

データは自分の Google ドライブに保存されるので端末がクラッシュしても大丈夫。開発元の 2 App Studio のストレージには保存されない。「Google か Dropbox か Evernote なら自分のプライベートなデータを置くのを許容する」という自分のルール的にも OK。

日記アプリは、ロックインされないことが重要で選択時の大きな基準。Journey の場合は Android アプリから「Export/Backup」で JSON ファイル群を ZIP アーカイブしたファイルで保存する機能がある。 常に XML ファイルとして普通にアクセス可能な状態になっている Day One より一歩劣るものの、 JSON なので移行が必要な時は自分で変換できるので許容範囲と判断。

Google Chrome から閲覧・編集できる

Chrome アプリがあり PC から閲覧・編集ができる。PC 向けには公式には Mac アプリしかない Day One とは違って Windows や Linux でも使えるのが良い。なお Android アプリとは関係無しに Chrome ウェブストアから Chrome に追加して使えるので、PC のみで使うというのもあり。

ちなみに Journey Web ( http://journeyapp.me/ ) で Chrome アプリを入れなくても自分のジャーナルを閲覧できるようになっている。

ローカルホストから直接 Google ドライブにアクセスし 2 App Studio 側を経由しないと言明しているのでプライバシー的にも安心(信用する限り)。

Chrome アプリでは、いにしえの Evernote を彷彿させる巻物的表示(全文を時系列にスクロールで見ていける)なのがとても良い。個人的にこのタイプの表示が好きなのだけれど、現状少ないので嬉しい。

文字が大きく行間が広いのでかなりスカスカ感はあるので、もう少しタイトになるといいなとは思う。

その他

Markdown をサポートしているのも良いところなのだけれど、見出しがセンタリングだったりするのがそこはかとなくダサい。

あとはまずまず良い感じ。

(画像は http://2appstudio.com/journey/ より。)

---

[ Android アプリレビュー ]

今日のさえずり: あのまとめ、中の人が作成したっぽいな

2015年03月19日

• 10:51 NAVERまとめにあるあのまとめ、中の人が作成したっぽいな。同じユーザーが他のまとめも数個作っているけど更新日が2日間ぐらいに集中しているし、ダミーと推測。
• 13:44 I'm at どん兵衛屋 渋谷駅ナカ店 in 渋谷区, 東京都 http://4sq.com/1Gs5QxK
• 13:50 初どん兵衛屋。意外に広くゆったりしている。 https://flic.kr/p/qK7yY6
• 14:04 どん兵衛屋、マクドナルドよりリラックスできるぞ(ただしどん兵衛の CM がエンドレスで流れている)。
• 20:06 昨日 Perl で書いたスクリプトを(まともに書いたことがない) Go で書き直してみてた。 encoding/json で JSON 文字列を Unmarshal すると面倒なことはわかった。
• 24:37 ずっと ~/var/Dropbox にしていたんだけれど ~/Dropbox に昇格させた。その方がスクリプトを書くの手抜けるし。

Markdown ビューアを OpenID Connect を使って Google アカウントで認証できるようにした

社内で動かしている Markdown ビューアについては去年 mixi Open ID 認証にしました(記事)。ですが mixi OpenID については 2016年1月25日提供終了となっていますので今回認証を変更しました。

今回は Google アカウントで認証できるように OpenID Connect を使ってみることに。基本的には OAuth 2.0 とほぼ同じです。

認証ページ(https://accounts.google.com/o/oauth2/auth)にリダイレクトさせる時に scope パラメータに 'openid email' を指定しておきます。

そしてコールバックを受けて https://accounts.google.com/o/oauth2/token でアクセストークンを取得した際に、レスポンスに一緒に含まれる id_token をパースして email 取り出します。今回はそのメールアドレスが指定ドメインだったらアクセスを許可するという処理にしました。

JSON Web Token (JWT) である id_token のパースには OIDC::Lite::Model::IDToken モジュールを使用。

 $email = OIDC::Lite::Model::IDToken->load($id_token)
    ->payload->{email};

で email が取得できます。

初全ツイート履歴ダウンロード

自分の Tweet は API で取ってきておおむね nDiki の記事にまとめてあるのですが、使い始めの頃はそんなことをしていなかったので手元にデータとして取ってありませんでした。公式機能で全ツイート履歴ダウンロードができるのは知っていましたがそのうちと思いつつずっとやり忘れていたので、ようやく腰を上げて全ツイート履歴リクエストを設定からしてみたところ、ほどなくして準備完了のメールが届きました。

ダウンロードした ZIP ファイルの中をみると、予想していた通り人間用に HTML ファイルがありました。そしてそれ以外に CSV 形式ファイル・JSON 形式ファイルが含まれていてきちんと利用しやすい形になっていて良くできているなと感心してしまいました。良いですね。

きちんと README.txt をみてみたら HTML ファイル (index.html) は JSON 形式ファイルを読んで表示するページになってました。なるほど。API のレスポンス仕様と同じ JSON 形式をエクスポートデータにしているのですね。