クライアントサイドでもdecoderがないとただの文字列だったりオブジェクトだったりしますが、ひとまずRuby側だけでも。
Anyなんて使う機会あるの？って感じもしますが、「なんらかのオブジェクトの構造をもっているはずだが、クライアントサイドはその詳細を知る必要がない」ケースってあると思うんですよね。そういうときに使う想定です。多用するものではないと思いますが。
開発者向けにMarkdown JPというコミュニティを作ってみました
- Markdown自体の仕様については、CommonMarkに期待しているので commonmark.org でよい
- CommonMarkに収まらない拡張を日本語で議論できる場所がほしい
- ルビや数式など
- サービス間で（ある程度）互換性があることはMarkdownの大きな価値なので、その議論ができるといいと思っている
- ビジネス的には競合だったりするもあると思うが、そこで差別化してもユーザーにとってメリットはないと思うので
という感じです。
8月にMarkdown Nightをやったら思いのほか反響があったので、それをうけてコミュニティの必要性を感じたというのもあります。
GraphiQL が "Mode graphql failed to advance stream." というエラーで起動しなったときのワークアラウンド
GraphiQL（グラフィクル）ってのはGraphQL（グラフキューエル）のAPI consoleです。GraphQL IDEと呼ばれることもあります。
（現行バージョン: v0.11.5, バグ確認バージョン: v0.11.2）
こいつには、どうも変なクエリを食わせると二度と起動しなくなることがあるという問題があります。このときdev consoleには "Uncaught Error: Mode graphql failed to advance stream." というメッセージがでてます。
LocalStorageへ保存しているのがダメなクエリだと思われるのですが、データを消してもすぐGraphiQL自体がLocalStorageに書き込んでしまってダメな状態を復活させてしまいどうしたものかという感じでした。
とりいそぎ「GraphiQLを閉じて、同じドメインの別ページでLocalStorageを消す」という方法がうまく回復できるっぽいのでそれでしのいでいます。
少し調べたところ、codemirror-graphqlかCodeMirrorのバグっぽいなと当たりをつけ、codemirror-graphqlで問題を再現できたので起票しました。
https://github.com/graphql/codemirror-graphql/issues/236
しかし、この起票した問題はテストが無限ループっぽい感じになって終了しなくなるというもので、例外が出るわけではないので違う問題かもしれません。
yarnpkgのenginesのバージョンチェックを無効にする方法
yarnpkg v1.0から、 package.json の engines sectionのバージョンチェックが厳密になりました。これにより新しいnodejsやyarnpkgを試すのが面倒になります。
これにメリットを感じない場合は無効化しましょう。
具体的には、 ~/.yarnrc に ignore-engines true を書き足すと、 --ignore-engines が指定されたのと同じになりバージョンチェックが無視されます。
echo "ignore-engines true" >> ~/.yarnrc
Rubyの型定義ファイルを中央repoにしないほうがいい理由
あるいは私がDefinitelyTyped (DT) が失敗だと思っている理由、です。
DefinitelyTypedは明確に失敗だと思っているので、あれを避けるのはそんなに難しくないかなと。まず (1) anyを認めて「型がなくてもいいや」という気持ちでいく (2) 中央repoは作らずそれぞれのgemに対して型定義パッチをおくりつける でなんとかなるっしょ。
— FUJI Goro (@__gfx__) September 19, 2017
あたりが話の発端です。
DTについては以前いまいちイケてない理由を書いたことがあります。
TypeScriptのDefinitelyTypedは「ダメでもともと、うまく使えればラッキー」くらいの距離感がよい - Islands in the byte stream
この時の話を一言でまとめると「ライブラリの作者ではない第三者がメンテしていることが多く、基本的に品質が低い」のがよくないというものでした。
それ以外にもいろいろ欠点があります。
また、 あらゆるライブラリの型情報をあつめる という野心的な試みなのはいいものの、そのせいでrepositoryをcloneするのに時間がかかり、パッチを作るのも大変です。
DTの場合はバージョニングも微妙で、型定義ファイルのバージョンはmajor versionだけオリジナルと一致させてteenyなどを自動的にインクリメントさせる方式をとっています。このため、ライブラリの特定バージョンを表す型定義ファイルというものは存在しません。このへんは本質的な欠点というよりは、DTのポリシーがイケてないという話かもしれませんが。
というわけで、いま私が関わっているプロジェクトではDTをあまり使っていません。DTは、基本的には使わないほうがいいと考えています。
追記:
DefinitelyTypedを中央repoにせず個別のパッケージごとにrepoを分割したらマシだったか？というとそれも難しいな〜。第三者が定義する型定義ファイルは品質が低いということに変わりはないので。
— FUJI Goro (@__gfx__) September 19, 2017
TSはJavaScriptそのものではないのでいろいろ難しい面はあります。JS互換の静的型AltJSだけでもTypeScriptとflowtypeがあるし。
TypeScriptでPromise.prototype.finallyを使う
Promise.prototype.finally が stage-3 になって、 ES polyfill集である core-js にも v2.5.0 で追加されたので、babel-runtime などを使っている場合はcore-jsのバージョンを上げるだけで finally を使えるようになってます。
しかし、TypeScriptの場合は型情報が必要なので、core-jsのアップデートだけでなく、次のnpm moduleを使って型情報の追加が必要になります。
TypeScript compiler (確認したのはv2.5.2) 的には、package.jsonに追加（して当然npm installなりyarnpkg installなりする）だけで利用可能になるようです。
ただし、RubyMine (v2017.2.3) はそれだけだと解釈できないようで、エディタ上は型エラーになります。vscodeだと問題ないので、TSでちょっと変わったことをするならやはりvscodeのほうがいいですね。
RubyMineでも Invalidate Cache をしたらfinallyが見えるようになりました。よかった。
CommonMark v0.28 のイマイチなところ
作業メモとして。なお、 CommonMark ≒ GitHub Flavored Markdown くらいの感覚で書いてます（実際にはGFMはCommonMark + いくつかの独自拡張）。
膠着語分かち書きしない言語におけるスペースで区切られないトークンとインライン記法について
膠着語というのは、日本語や中国語のように単語と単語の間にスペースをいれないタイプの言語です。
膠着語は分かち書きしない言語のことではありませんでした…。素直に「分かち書きしない言語」というのがよさそうです。
CommonMarkは分かち書きしなくてもそれなりに動くように定義されていますが、エッジケースではまだ思った通りに動かないということがあるようです。
ひとつ仕様のバグっぽいのをみつけたので起票しましたが、これ系の話は中国語のコンテキストで議論されてるっぽいので見守り。
Non-spaced tokens with emphasis seems not parsed as expected · Issue #488 · commonmark/CommonMark
脚注記法
CommonMarkには（ついでにGFMにも）脚注記法は存在しません。存在しないこと自体はまあいいのですが、PandocやQiitaなど多数のmarkdownサービスで採用されている脚注記法（以下pandoc’s footnotes）が、CommonMarkのLink reference definitionという記法と一部かぶっていて意味がまったく違うため、CommonMarkとの互換性をとるとpandoc’s footnotesを実装することが不可能であるという問題があります。
これはCommonMarkの仕様を変えるかpandoc’s footnotesを諦めるかの二択なので困ったものです。
これも起票済み。
Footnote extensions vs Link Reference Definition - Extensions - CommonMark Discussion
参考スレッド:
CommonMarkのLink Reference Definitionがpandocのfootnotes （qiitaでも採用されている脚注記法）と構文的にはかぶっているのに意味が全然ちがっていて頭を抱えてる。 https://t.co/sACMtHu3b3
— FUJI Goro (@__gfx__) August 14, 2017
見出し記号（#）のあとにスペースが必要な件
CommonMark以前の仕様が未定義だったGFMでは #foo で見出しになっていたのが、CommonMark化後のGFMで見出しにならないのはだいたいこのせいです。これはおそらく、GitHubで多用するissue記法（#123）と明確に区別するためにスペースを必要にしたのだと思います。GitHubはCommonMark仕様策定に噛んでますからね。
これは受け入れるしかないのですが、影響範囲がそれなりにあるのでどうしたものかなという感じです。
Androidライブラリのためのmaskaradeというorgを作った
The Maskarade project · GitHub
最近イマイチAndroidの活動ができてないんですが、Androidライブラリのメンテを諦めたわけではなくて、たとえばOrmaとかはまだやりたいことがいくつかあるのでやるつもりはあります。一方で、ちゃんと新しいメンテナがいたほうがいいなーというプロジェクトもあって、とりあえず私のメンテする気のあるなしに関わらずユーザーがいそうなAndroidライブラリを全部まとめて maskarade（マスカレード）というorganizationに移すことにしました。
何故これが必要なのかというと、新しくオーナーシップをもったメンテナを受け入れられる体制にするためにorgが必要だからです。GitHubは個人アカウントにあるリポジトリのオーナーシップをコラボレータに渡すことはできないんですよね。なので、オーナーシップを誰かに渡したいときは (1) org管理にする (2) 新しいオーナーにrepoを移譲する、という選択肢しかないのです。
ここでオーナーシップにこだわるのは、そもそも誰かをOSSのメンテナに任命するにあたってはちゃんとオーナーシップ（リポジトリのオーナーシップとリリース権）を渡さないと引き継ぎがうまくいかないという経験則があるからです。逆に言えば、オリジナル作者がメンテしなくなったときに、コントリビュータにコミット権だけ渡してオーナーシップを渡さないと、結局そのコミッターは「お客さん」以上の関わり方ができず、そのOSSは死にます。OSSにユーザーがいなくなって死ぬのであればそれは寿命がきたということですが、ユーザーがいるのにオーナーシップが不明瞭なためメンテされずに死ぬのは大変残念です。
OSS の引き継ぎ方 - builderscon tokyo 2017 でも「引き継ぎをするときはリリース権もちゃんと引き継ぐこと」みたいな話をしていましたね。
というわけで、maskaradeのリポジトリは全てメンテナを名乗り出ればオーナーシップ（リポジトリのowner権限とbintrayのリリース権限）を渡します。私の直接の知り合いであればそのまま、そうでない場合でもそのまえに2~3のテスト（pull-requestをおくってレビューするというプロセスを経験する）をしたら渡します。なお、Androidライブラリをmaskaradeにtransferしたいとうい申し出も受け入れます（私はメンテはしませんが！）。
TODO: これを英語でも書いて maskarade/README に置く
builderscon 2017 tokyo に行った
builderscon tokyo 2017 - Aug 3, 4, 5 2017
いろいろな分野の人がいて非常に刺激になりました。来年はなにかネタを持っていきたい。
あと名札がリバーシブルなのよかった。なお一人ひとりにユニークなQRコードを発行するのはバリアブル印刷というそうです。
builderscon の名札、リバーシブルなのめっちゃ良かったのでこれがスタンダードになってほしい。 pic.twitter.com/qSrO5DYCuR
— FUJI Goro (@__gfx__) August 6, 2017
印象に残ったトークについて感想など。
横山光輝三国志 全文検索システム
最高に面白いサービスなのでぜひコンテンツの権利者と仲良くしてサービス化してほしいところ！
技術的にもわりと参考になりました。
- OCRはGoogle CVが曹操級で手書き文字もそこそこいける
- 誤検出したテキストは “MeCabで洗う” ときれいになる
- 解析できなかった部分を取り除けるの意
- テキストの座標もとれるので自動翻訳して置換するのもそこそこうごく
- 製品レベルにするのはちょっと大変そうだけどポテンシャルありそう
このへんを応用すると Kibela にアップロードした画像のテキストを検索できそうだなと。
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
アーキテクチャの話は苦手なんだよなあ…でもJSがどんどん複雑になってきてるからそろそろ真面目に考えるかーくらいの気持ちで聞きにいったんですが、めちゃくちゃ分かりやすくてよかったです。ちゃんと復習して製品開発に活かすぞ💪
repo: NekogataDrumSequencer も大変参考になりますが、 Drum Sequencer に対して無知すぎるのでそこはあまりピンときませんでした。
なおプレゼン中に紹介された FizzBuzz Enterprise Edition はめっちゃ笑いました。
OSS の引き継ぎ方
スライドは未upload?
ぼくもだいぶOSS引き継いでもらったり引き継いだりしてるので他の人はどうやっているのかな、と思ったらけっこうハードな話でした。Rubyコミッターの重責というか…。後半の事例集がわりとはしょられてしまったのが残念でした。RubyKaigi 2017でもやるみたいなので完全版の資料が楽しみです。
歴史あるOSSだとオリジナル作者がそのエコシステムを去っていたり死去(!)したりすることがままあって、しばしば「コミッターはいるけどプロダクトマネージャ（プロダクトオーナー）的な人がいなくて方向性が定まらない・年単位の開発が必要な機能がまとまらない」という感じになるそうで、これについては自分の観察範囲でも経験があり貴重な知見でした。自分が興味がある場合は「プロダクトオーナーやります！リリース権ください！」って言えばいいんですが、そのソフトウェアを使いはするけどオーナーをしたいというほど関心があるわけでもない場合は難しいんですよね、関心のあるところは直すけどプロダクトの方向性とかを舵取りしたいわけじゃないし。
このへん難しいのでうまく言葉にまとめられませんが、いい感じになってほしい。自分が干渉できる範囲ではいい感じにしたい。
Oss貢献超入門
実践的かつ具体例が豊富でよかったと思います。
OSS活動についての動機は大まかにいって「趣味」と「業務上の必要性」の２つがあって、きょうびのウェブサービス開発ではOSSに依存しないことはほとんど不可能なので、製品の品質をコントロールするためにはOSS活動は必要不可欠なんですよね。ほとんど常に業務上の必要性があるのに、実際の所OSS活動はどうやっていいのか分からんみたいなのは解決すべき課題といえるし、こういう入門セッションはいいなと思いました。
3Dプリンタで作る階差機関 / Build Difference Engine by 3D Printer
直接聞いてないけど、スライドだけでもだいぶ面白いです。「というわけで全部スクラッチで設計しました」あたりが強い。
3Dプリンタめっちゃ夢があるし、この調子でアンティキティラ島の機械にもチャレンジしてほしい。
npmjs.com で著名ソフトウェアによく似た名前のマルウェアが大量に発見された
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog
People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them
訳:
悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。
発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 babelcli, d3.js, ffmepg, jquery.js, mysql.js, openssl.js などです。これらのパッケージが依存関係にある場合、tokenなどの秘匿値を再生成すべきとのこと。
package.jsonに書いた直接の依存関係だけでなく、 依存ツリーのすべて を調べる必要があります。つまり、 あなただけでなく依存ツリー中の誰かがミスって偽パッケージを使っただけであなたの環境が攻撃対象になる ということです。依存関係は npm ls などで調べられます。
ライブラリ開発者としては、 scoped packages を使うのがよさそうだと元エントリでは述べています。
所感
オンラインでコードを配布・使用する以上、どんなパッケージリポジトリでもマルウェアを配布することはできます。つまり、npmjs.com (npm) だけの問題ではありません。
一方で、ある機能を実現するための別のパッケージが非常に沢山あります。たとえば、 zstdのnode binding だけでもパッと見て4つくらいあります。これは、npmのユーザー（＝JSの開発者）が他の言語にくらべて桁違いに多いため、車輪の再発明が頻繁におきるからではないかと想像しています。
また、しばしば同じライブラリに対応する複数の配布パッケージがあります。一例をあげると、lodash は単体で lodash (commonjs modules版) と lodash-es (ES modules版)という配布パッケージがあり、またlodashの提供する関数ごとに配布パッケージが提供されています (たとえば lodash.merge packageなど）。このような状況だと、たとえば react-es というパッケージを作って「ReactのES modules版です！」というdescriptionを設定すると、いかにもそれっぽく見せかけられます。つまり、著名ソフトウェアに便乗してマルウェアを配布することが簡単にできてしまいます。
この問題はなかなか難しくて対処療法ではない本質的な改善をどうしたらいいのかは分からないのですが、さしあたり自分の管理するライブラリに関しては、 scoped packages にして配布するしかないかなという気がします。
追記
npmjs.org の配布パッケージの中身を公式ウェブインターフェイスで見ることができない、というのもnpmの問題のひとつと言えるかもしれません。
…できないですよね？ 例:
たとえば metacpan.org は配布パッケージの中身をウェブで確認できます。例:
rubygems.org も配布パッケージの中身をウェブでは確認できませんね。例:
追記(2)
- 元エントリに確認用ワンライナがあり、今回発見された分に関していえば確認することはできます
- 元エントリが更新される可能性を考慮してここには引用しません
- 公式見解でました: npm Blog Archive: `crossenv` malware on the npm registry
