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の話とかサンフランシスコの話とか。

達人出版会 エラッタ errata 正誤表

達人出版会でエラッタ探せなかったのでメモ.仕組み上実装されてはいなくて,著者ごとによる.フォーマットもバラバラ.

統一的なフィードバック方法

(2014-01-05時点)マイページを起点に
http://tatsu-zine.com/my/

書籍ダウンロード・購入履歴の フィードバック => 登録・表示 => 誤りの指摘

もしくは購入書籍一覧の書影画像をクリック or 書籍一覧から各タイトルクリック
著者によっては!! ここにerrataへのリンクが有る.ここ手段がバラバラなだけじゃなくて完全に自由フォーマットなのかー.

いろいろなサポートページ

github
『なるほどUnixプロセス ー Rubyで学ぶUnixの基礎』サポートページ

google spreadsheet
『入門Chef Solo』正誤表(達人出版会版)

はてなダイアリー
makotoiの日記:from London

サポートページない本もいくつか.

pragprog errata

pragprogはerrataのシステムがある

The Pragmatic Bookshelf | Errata for Metaprogramming Ruby

既出かどうか分かるのでかなり便利.なおerrataごとにpermalinkあればもっとよい.

いいと思ったシステム

github issue, e.g., スプリントゴールの達成するときの障害物 · Issue #5 · kdmsnr/ScrumGuide

トータルで,github issue ベースが都合よい.
より楽なのはpull requestベース(kindleだとページがなくてどこ読んでるかわからないので)だけど,publicにそうなったら買わなそう.はい.
あとどうでもいいissueに振り回されるのダルそう.具体的には,てにをは気になるマンの自分など.

Hatena Engineer Seminar #2行ってみてた

Hatena Engineer Seminar #2 行ってみてた。遅刻して着いたらid:aerealの発表終わっており、あとはまあどうでもよかった。エンジニア同士の目標の建て方、モチベーションに左右され過ぎない方法、チーム内・チーム外での見せ方、みたいなちょっと組織が大きくなってきた時に出始める問題について聞いてみたい、とアンケート用紙に書いた。はてなに就職する興味はないに丸をつけた。あとは懇親会でかなりぼっちで居て、帰った。