builderscon.io builderscon 2018 tokyoで「Java Cardの世界」というタイトルで話してきました．発表資料は以下のとおりです． 喋りたいトピックはJava Card以外にも様々あったのですが，「知らなかった、を聞く」というカンファレンスのテーマを鑑みた結果，あまり一般には知られていなさそうな *1，しかし身の回りを確かに支えている技術についてお伝えしたいと思い至り今回のような発表をした次第です．この発表で少しでも生活が豊かになってもらえれば望外の喜びであります． さてこの発表はありがたくもベストスピーカー賞第1位を頂戴しまして，感激の極みであります．本当に嬉しい！！！　もちろんこの発表は僕個人の力のみで成し遂げたものではなく，所属しているソラコムの同僚の多大なる協力があって達成したものです．特にJava Cardの偉大な知識を授けてくれたolivier

bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--

最近，社内Wiki書く時にその記事の頭に「この記事で分かること」というセクションを持ってくるようにしている．こんな感じ． wikiのページを開いた時に真っ先に「どういう情報が得られるか」が書いてあると，取捨選択を早い段階から行えるので調べ物のスピードが上がって良いような気がしている． あと所属している組織ではConfluenceを使っていて，Confluenceの検索機能に引っかかるような (引っかけやすいような) ワードを「この記事で分かること」に含めるように心がけている． 地味に便利になりつつある気がしている． [追記] そう言えばConfluenceの検索結果は「タイトル」と「サマリ」が出るんだけど，冒頭にこういう情報を書いておくとそれがサマリ部分に表示されるから，検索結果一覧の段階から情報の取捨選択できて便利というのもあった．

code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p

人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！　しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する

いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の

GitHub のリポジトリページにアクセスするだけでローカルに git clone される Chrome 拡張を書きました．ggc という略称になりますが，まあなんかこれ紛らわしいですね． なぜこんなものが必要になったかというと GitHub のリポジトリ内検索は割と結果がひどくて，手元に clone してきてから grep なりなんなりをかけた方が必要なものを得られる可能性が極めて高い，というのがあるためです． そんでもっていちいち clone するっつうのもダルいので，それだったらブラウザでリポジトリのページにアクセスした瞬間に自動的に clone すればいいじゃーん，もう2015年なのでストレージとか気にせず豪快にいこうやガッハッハ，という方法に id:s5r 氏と話していて辿り着いたのでそれを実装したというのが経緯になります． Chrome 拡張を名乗っていますが，実態は Chro

色々な事情があり，秘密のメッセージを送り合う必要性が今年に入ってから多数発生していて， そのたびに毎度毎度手で暗号化して〜みたいな風にやるのめんどいですね，そうですね， ということでこの度 naisho というものをこさえました．みんなには内緒ですよ． これは何かと言うと，やりとりしたい相手の GitHub の ID を指定するだけで その ID のユーザの ssh-rsa の公開鍵を引っ張ってきて その ID のユーザのメールアドレスを引っ張ってきて そのメールアドレスに対して公開鍵で暗号化したメッセージを添付ファイルにしてメールで送りつける という動きをするコマンドです． golang で書きたかったというのと golang で書くと便利なのではと思ったので golang で書いてあります． Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする -

java-mysql-diff が出ました．Maven Central にもリリースしています． http://search.maven.org/#artifactdetails|net.moznion|mysql-diff|1.0.0| 本パッケージは id:onishi さん作の mysqldiff の Java 8 移植版です． 最近 Java の環境で作業することが多いので，なんだかんだで Java 版があると便利だよね〜ということで作成しました． 本家の Perl 版 mysqldiff と同じような感覚で利用したかったので，全部の依存パッケージを1つにまとめた fat-jar も用意してあります． java -jar というコマンドを余分にタイプする必要はありますが，Perl 版と同じような感覚で利用することが出来ます． https://github.com/moznion/j

完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな． そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう． (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．

git grepが便利なので，同じ感覚でag (The Silver Searcher)を使ってみたいという話です．何事も速いほうが良い． 前提 ぶっちゃけagは，デフォの状態で.git/以下の内容や.gitignoreに書かれてるファイルやディレクトリなんかを検索の対象から排除するのであんま旨味は無い． 方法 以下のエイリアスを張る *1．もちろんconfigファイルを直で編集しても良いです． $ git config alias.ag '!git ls-files | xargs ag'git ls-filesを使って，gitで管理されているファイルの一覧を持ってきて，xargsを使ってagに渡してやるという感じ． 実際僕はこれで十分なんですが，表示と挙動をgit grep(1)っぽくしたい場合は以下のようになるでしょう． $ git config alias.ag '!git ls-

皆さん年に2，3回は，「ウェッブページのTable要素をXLSX (もしくはCSV) に変換して保存したいワ！」となることがあると思います．僕はあります． そういう時は，「心をこめてTableをコピーしてExcel (もしくはお好みのヒョーケーサンソフト) にペースト！」みたいな感じになると思うんですが，コピペギョームはTableの行数がめっちゃ多い時 (1画面で収まらないTable要素とか) にだるいし，コピペ処理中になんらかの事故が起きてミスった結果えらい人に呼ばれて怒られる可能性なども否めないので，そういうことをクリック2発で実現するChrome拡張を書きました． https://chrome.google.com/webstore/detail/table-to-spreadsheet/haidhlbpihfihbjcggmffnmhgiddjcoc?hl=ja 何をするChrom

―「間違っているかもしれないので，その時はこの銃で僕を撃ってくれ，良いね？」 [2014-05-19T17:48:28Z 追記] http://a-suenami.hatenablog.com/entry/2014/05/17/131326 補足してもらったので読むと良いと思います． わかっちゃはいたけれど上手く言語化できていなかった部分，あるいはわかっていない部分について言及されていたので参考になりました．ありがとうございます． いやーつーかさー，「『メソッドに対するテスト』っていう言葉自体がわかりにくくね？」っていうのはその文言を見たり，この文章書いている間もずっと思ってて，つまり端的に言うとそういう事を言いたかったはずなのに，今このエントリ読み返すとそうした[趣主]旨から完全にズレててメッチャ違和感あるな！　ってなりました．俺のバカ！ これを仮に言い換えるとしたら「内部構造に対するテ

とりあえずデモサイトを示しますので適当に見て下さい． http://ukigumo.moznion.net/ さて今回はゆるふわCIシステムであるところのUkigumoのナウいスタイルについて説明しようと思います． ここ最近ではUkigumo::AgentというAgentサーバが存在しており，これを使うとまあ便利なんですけれども，ドキュメントが少ない為か *1 あまり利用されている事例を見かけませんので，それらも踏まえて解説したい感じです． まずUkigumoとは何か CIシステム．Perl製． Perl製だが，もちろん他言語のプロジェクトでも使える． Travisのようにサービスとして提供されている感じではなく，自前でインストールして使う． 多分，感覚としてはJenkinsに近いと思うが，そこまで複雑ではなく，シンプル． 基本的に，「テストの実行及びその結果の取得」と「テスト結果の保存」

merge済みのブランチがいつまでも環境に居座っていると精神衛生上よろしくないのでこまめに消す派なのですが，いちいち手作業でやるのもダルいしコマンド一発ですべてを片付けたいというのが人情と言うものなので，最近ではゴリッとスクリプトを書いてそれを使っています． ここにも同じものを置いてあります． シェル力が低いので，正直これが良いやり方なのかどうかはわかっていませんが，とりあえず動いていて便利なので記した次第．

「UNIXという考え方」をAmazonのwish listに入れていたらid:kenjiskywalkerさんが贈ってくださったので読みました．お陰でUNIXという考え方を学べました．ありがとうございます！ 本書では一貫して「プログラムを小さく作る」という事と「1つのプログラムには単一のことだけを上手くやらせる」という事について言及されています． プログラムを小さく作るということによって，そのプログラムはコンピュータのリソースに対して優しくなり，なおかつ巨大なプログラムと比較して人間が理解するのが簡単になるので保守がしやすくなり，かつ他の部品と組み合わせやすくなるという論旨です． プログラムを小さく作ると，必然的にそのプログラムは多くの責務を負えなくなる為，自然とプログラムは単一の機能のみを持つようになります．従ってこれら2つの考え方は対になっていると言えるでしょう． 本書で言われている「

参加してまいりました． 途中までは事実を述べて，途中からはポエムになります．どこからポエムが始まるか，みんなで探してみよう！ 開催期間中は毎朝6:30に起床してはdoor2doorで2時間かけて，それも満員の中央線と山手線を駆使して出勤しなければならないという，朝と満員電車に弱い僕にとってはまさに試練とも呼ぶべき催しで，僕の心は幾度も布団の誘惑に屈しそうになりましたが，奇跡的に1日たりとも遅刻せずにインターンシップを終えることが出来ました．というか朝6:30って言ったら僕のような人間にとっては午前3時にも匹敵する早起きですよ！*1 さてインターンシップの内容ですが，1週間でスマートフォンアプリをモリモリッと企画してそれをグワワッと実装して，それをジャーンとプレゼンするという大変にエクストリームリィな内容でした．「1週間でスマートフォンアプリを作る」というのは字面だけを見るとさほど難しいこと

去る2014年2月22日にtmux 1.9がリリースされたので勇んでアップデートしたところ，1.9からはdefault-pathオプションが削除されており，またそれが原因かどうかは定かではありませんが *1，new-windowやsplit-windowするとcurrent pathの情報を引き継いで *2 くれなくなってめっちゃ不便！！！！　ってなって，「これもう1.9にアップデートしなくても良くね？？？　CHANGES見てもこれといった変更ないし……」という心意気に一時はなったんですが，僕みたいな糞ミーハーはやっぱり新しいものを使いたいのでちょっと調べてみました． 結論 bind '"' split-window -vc "#{pane_current_path}" bind '%' split-window -hc "#{pane_current_path}" bind 'c' ne

去る2014年1月27日にNHK番組表APIが公開され，これが中々良い感じだったので，PerlからそのAPIを触れるクライアントであるWWW::NHKProgram::APIを書きました． https://metacpan.org/release/WWW-NHKProgram-API https://github.com/moznion/WWW-NHKProgram-API このモジュールを使うと，NHK番組表APIが提供している 地域，サービス (いわゆるチャンネル)，日付の指定による該当する条件の番組リストの取得 地域，番組のジャンル，日付の指定による該当する条件の番組リストの取得 番組IDの指定による該当する番組情報の取得 地域，サービスの指定による，現在放送中の番組情報の取得 の機能を利用することが可能となります．APIの詳細に関しては以下を参照してください． http://api

世の中の Perl の Package の末尾には大体 `1;` って書いてあって、これが何か言うと「このモジュールは真値を返していますよー」という表明で、まああけすけに言うとこれが記述されていなければ、そのモジュールは use とかされた時に不正なモジュールとして扱われてしまい、読み込みが 失敗してしまう訳です。 さっきも言ったように、返す値は真値であれば何でも良いので、`42;` って書いたり `"HELLO";` って書いたりしても別に良い。 で、世の中には `!!1;` っていう面妖な記述をしているモジュールがあって、人が泣いている。 `!!1;` は、1 という真値を ! によって偽値にして、さらにそれを ! する事によって真値にすることによって、真値であることを表明している。 これでも問題なく動くけれど、`!!1;` って初見の人はびっくりしてしまうし、そもそも2回も否定演算し