meta-data

頭で考えてて、ちょっと頭の容量オーバーなのでうだうだ考えてないで作れって話があるけどdump。数ヶ月優先順位が上がらないけど頭に引っかかってて、あといい感じの実装も思いつかないので放置してる。

だいたいこんなことがやりたい。元になるデータセットがあって、そこから言語別クライアントライブラリを作る。

こういうイメージ。
https://github.com/zengin-code/zengin-rb
https://github.com/woothee/woothee-ruby

あとmongodb/mongoidが各言語用のテストデータセットをyamlで書いたっていうのをrubykaigi2015で聞いたんだけど、ざっとリポジトリ見る限り見当たらない。
https://github.com/estolfo
https://github.com/mongodb

言語別ライブラリを作った時に、実装を確認するデータセットがほしい。
データセット側を更新するのはプルリクエストで、そのテストでは、各クライアントライブラリ側で、新しいデータセットでテストが通ること、がデータセット側のテストに入っている。
データセット側リリースしたら、言語別ライブラリ側も新しいバージョンリリースされてほしい。

この仕組を使ってやりたいこと。
https://github.com/packsaddle/ruby-env_branch

こんな感じで、各CIサービス串刺しで、欲しいデータを取る、というのを作ってるんだけど、これの元になるデータセットを作りたい。

たとえばbranch nameだったらこんな感じかなあ。取りたいメソッドから考えるとこんな。

各CIでのbranch nameのkeyがほしい
たとえばcircle ciでのbranch nameがほしい
circle ciの環境変数一覧が欲しい

yamlで作って、jsonに展開
camelCase にする
https://google.github.io/styleguide/jsoncstyleguide.xml

複数CIサービスには詳しいけど複数コードホスティングサービスに詳しくないからなあ。pull requestとmerge requestは同じように扱えるようにした方がいいんだろうか?みたいなの。

あと取りうる値もかけないものか。
falsyなときに空文字列なのか、文字列でfalseがはいってくるとかそういうのを記述するのがダルい。各CIサービスで、このキーをとる、というのは流石に書いてあることが多いけど、こういう値を取りうるみたいなのが無いケースがよく有る。
環境変数だから文字列しかとりえないんだけど。あと、条件によってその環境変数自体がない場合もある。
json schemaなんかなーこういうの。json-schema触ったことないのと、オーバースペックに感じなくもないけど。

Edited 2016-02-03 12:59
あと、メソッドの返り値がこうなる、ではなくて、このci サービスはこういう値を返しうる、みたいな表現できるのかな。

欲を言って、こういう仕組みを生成する仕組みを作りたい。

ぼんやり迷ってる。

広告

assert

jsのpower-assertを契約プログラミングっぽく使うチャンスだ、と思った。実際はオブジェクトでもなんでもないところだからほぼ関係ない。ただ、testでもbabelでもなんでもないところで使おうとするとどうやって書いたらいいかよくわからない。
なおBertrand Meyer本読んでないんで理解は半端で適当。
こういうかんじのところ
firefox-build-link-plain/release-circleci.js at 4e61a02de858498ab6d2ab38605e5a914c73ef6c · dogwalk/firefox-build-link-plain

assertつかってる。trueだとおもったらfalseでした!にしかならなくて悲しい。

One data set, use anywhere

更新される1つのデータセット(json/csvなど)から、各プログラム言語向けpackageにして、簡単にshipする仕組みって作るの難しいんだろうか。メタ的なやつ。

イメージは、User-Agent parser/classifierのwoothee/wootheeとそこからの各プログラム言語ごとのpackagewoothee/woothee-js。ライブラリからはcsvやらjsonやら意識せず普通にobjectにマッピングされてるのも簡単に欲しい。

あとは、JSON-Schemaなりで定義書いたら、各プログラム言語ごとの簡単なAPIクライアント出来るとか。

git tagをpushしたらそのhookでリリースかなあ。デバッグや再実行しんどいからこのタイプのリリース好きじゃないけど、”各プログラム言語ごとのpackage”の数が増えてくると手作業は現実的でなくなる。

元データセットを更新したら(git tagを打ったら?)、数日以内ぐらいに各パッケージがそれを反映してupdateしてreleaseしたい。

x-ken-allをどうにかしようとして放置してるこれとか、emoji-cheat-sheet のhtmlをparseしてるこれとか、各言語から使いたい。

エコシステム周りの愚痴

GitHubのauthのscopeがこういうの向きになってなくて、organization用のapi keyとかないから、organizationつくる、organization にbotアカウント作る(規約違反)、botアカウントがpushできるようにする、とかが大変。botアカウントなのにadminに入れないとリポジトリ増やした時にいちいちwrite権限をteamに追加しなきゃだし。

travis-ci/circleciなりからrubygems/npmなどにpushできるようにするのもダルいよなあ。これも既存の自分のrubygems/npmアカウントと別にpush用のアカウント作るんかな。ただ、bot アカウントがnpm publishしてくるのってどうなんだろう。信頼チェーン的にダメな気がしないでもない。

イノベーティブじゃない

他人がビジネスにしようとしているのを例えばhoundciなど、を多少自腹を切りつつ労働力も注いで、タダで提供するのばっかり考えちゃうけど、なんか全然イノベーティブじゃないなー
お金にしようと考えるのをサボってるだけとも言える
その先、その先かあ

banの思い出

ひとまずブラウザゲームのリクエストはパラメーター変えて送ってみるようなセキュリティホールで遊ぼう界隈の出身だったので、ソーシャルゲーム作ってる時に「疑わしきはban」という感じでピシピシbanしてたのにひえーってなった。あとマクロもban。ただ結果を見ると少なくともゲームの場合は疑わしきはbanでモラルを守ったほうがよかった。あれは割となるほど~となった。

コミュニティサービスもまた線引き難しいですね。
ban大変ですね。

2014年11月12月なにしてたか

退職したあとなにしてたか。柱は三本。どれもお金になってないなあ。

Tachikoma.io

Tachikoma.ioはわかってやってるつもりなんだけど、刺さる層がめっちゃ狭い。configurationをアプリにどう載せよう。まだ載せられてない。早めに戦略を方針転換しないとだなーと気付かざるを得なかったので練り直し。登録ユーザー180がもう二桁ぐらい増えないと。フクオカRuby大賞の本審査1月19日の週にプレゼンしに福岡行きます。

parser

javascript界隈でastをお手軽書き換えな流れと、ruby界隈でもrubocop, synvert, transpecあたりの流れから、何かしてpull requestやレビューコメントというwebサービスと親和性高いのでは、という目論見から。うまく行かなくて挫折。敗因は、コメント行の扱いがつらかったのと、ast to astでコード書き換えちゃうと、unparserでコード書き戻すしかなくなって、それで出力されるのがいわゆるDSLっぽいコードではなくなってしまい、先が長いなーと思ったからだった。Gemfileの並べ替えしたかったのは、これはこれで再挑戦したい。

metarubygems.org

herokuのハッカソンで運営資金もらうぞーとおもったけど、1円ももらえなかったので、sakura vpsの4G 初期費用4300円月額4000円を吸われ続けていくことになってしまった。ひとまずTachikoma.ioでスポンサーする。
これは、rubygems.orgはgemごとのreadmeが見えないのと、diffをgithubにいちいち探しに行くのがツライので、handcooler.org以前作った。でも自分で使うにも帯に短しだったので、やっぱ自分でgemを保持するか!という気持ちになった。rubygems.orgと同じmeta情報取れるようにするのと、file api, diff api, readme apiまでは構想ある。おれの考えた最強のAPI、というところまでは自分で作りきらないとな。未完。

あいだでなにかミスった時に誰も気付かなくなるのでrebase反対

あいだでなにかミスった時に誰も気付かなくなるのでrebase反対

“Merge pull request”の弊害 | POSTD

merge, merge, mergeで全部積み上げていってほしい。mergeでもconflict解消で解消した人以外わからなくなるから変わらないのでは、については。いちおうmergeしたポイントがヤバイとは残る。

2014 年になって聴き漁った Tech Podcast(2)

Tech Podcast好き。
2014 年になって聴き漁った Tech Podcast – present

codelunch fm
http://codelunch.fm/

h13i32maru, iizukak のpodcast。ふたりともklabのフロントエンドよりなエンジニア(?)。Emscripten触るjsエンジニアをなんて呼んでいいのかよく知らない。自分はみんなでフロントエンド触り始めるタイミングでソーシャルゲーム業界から抜けたのでビハインドしてる。なので面白い。今は四回までやってて月一っぽい。

ここまでのテーマはjsのフレームワーク, go, emscripten, 浮動小数点数。

書いてて気づいたけどitunes store縛りだと無いかも。いまのイチオシ。

riywo’s podcast
http://podcast.riywo.com/

riywo のpodcast。denaのopsエンジニア。2013/4 更新の4回目で止まっちゃってる。courseraの話とかサンフランシスコの話とか。