厚生労働省の「新型コロナウイルス接触確認アプリ」が公開された。 かねて話題になっていたように、ある程度匿名性を保ったままbluetoothで他のデバイスが近隣に留まったことを認識する方式らしく、割と安心できそうかと思う。 またITMediaの記事によればCOVID-19 Japanという有志によるオープンソースプロジェクトを元にしているそうだ。 ただし、記事を読む限りでは完全にオープンソースプロジェクトそのままというわけではなく「COVID-19 Radar」の技術を核として厚生労働省がベンダーに開発を委託したとある。 そうなると、いくつか気になる点がある。 「COVID-19 Radar」のソースは公開されているからプライバシー等への懸念がある場合にはそれを読んで確認すれば良い、というような意見もあるが、「COVID-19 Radar」と「新型コロナウイルス接触確認アプリ」がその点におい

現代思想 2019年12月号 特集=巨大数の世界 ―アルキメデスからグーゴロジーまで― 作者:鈴木真治,フィッシュ,小林銅蟲,詩野うら出版社/メーカー: 青土社発売日: 2019/11/28メディア: ムック 『現代思想2019年12月号　特集＝巨大数の世界』を読んだ。かのフィッシュ氏による巨大数論解説に始まり、巨大基数や組合せ論や、古代ギリシャ以来もしくは仏教における巨大数、巨大数や数学的実体の存在論、永遠についての時間論、はたまたジンバブエドルなどを網羅している。巨大な概念を愛好する向きにはたまらない一冊である。またそれらのトピックが単に巨大であるという理由で任意に集められたわけではなく一定の相互関係を持っている点は注目に値する。 思想史ないし数学史の延長上における巨大数の位置付けは「情報社会にとって『数』とは何か」という大黒岳彦氏の論で述べられていて、これも大変勉強になった。現代の、

Nianticに転職して1年あまりが過ぎた。 2018年の9月からNianticで働いているのだが、そういえば転職エントリーを書きそびれていた。 転職して以来、相変わらずサーバーサイドの開発をしていている。なお、開発しているのはIngressでもPokémon GOでもハリー・ポッター：魔法同盟でもない。 Nianticとの関わり Ingressは2014年12月から続けていて、Pokémon GOも日本での正式リリース日からぼちぼちやってきているものの、それにしてもNianticで働くようになるとは思ってもみなかった。 Pokémon GOがなんかえらく流行り始めたときも、自分とは関係ない話だと思いつつGoogle Maps時代の知り合いが何人か関わっているのを思い出して無責任に祝福していたぐらいである。知り合いへのご祝儀のつもりでポケコインを1万円分ぐらい買って、行動圏内にルアーモジュ

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養 作者: エリン・メイヤー,田岡恵,樋口武志出版社/メーカー: 英治出版発売日: 2015/08/22メディア: 単行本この商品を含むブログ (3件) を見る しばらく前にエリン・メイヤー『異文化理解力』という本を読んだ。各国の仕事文化を比較して、それを理解し尊重する方法を示している本だ。 著者の経験と知識に基づいて文化の差異を8つの軸の度合いとして分析し、それぞれに意味があることを説明し、また差異どうやって扱うべきかを解説している。 最初に読んだ直後にtwitterでも読書メモを書いたんだけど、改めて私の理解と、とりわけ日本からの視点をまとめてみようと思う。 エリン・メイヤー『異文化理解力』読了。文脈依存、評価の伝え方、説得原理、階層性、意思決定者、信頼構築過程、見解の相違への許容度、予定の柔軟性の8軸で世界の仕事文化を

ある社内研修の一コマだった。 私は受講対象者ではないんだけど、良く覚えていない謎の理由によりオブザーバーとして参加していた。 ちょうど講師が「重要でなく緊急でもないもの」「重要でないが緊急のもの」「重要だが緊急でないもの」「重要で緊急のもの」って例の話*1をしていたときだった。話がだいぶすすんでそろそろ次の話題に行こうかというところで、はたと気づいた。私を含めて参加者の半分ぐらいがラップトップを開いてメールやSlackをチェックしながら聴いている。これはどうしたことだろう。 この手のメールチェックってのは往々にして「重要でないが緊急なもの」か「重要でも緊急でもないもの」だ。少なくとも私がやってたのはそうだった。 そこで、その場で参加者に訊いてみた。「私も含めてみんなメールチェックしてたけど、それって重要で緊急なものですか?　もしそうだったらお忙しいところ参加頂いていて大変申し訳ないんだけど

時代とともにRubyの使われ方は変わってきましたが、いつの頃からか発生したDSLのホスト言語としての役割にはずっとお世話になってます。人に優しく、故にプログラマ以外にも優しく、これがとてもRubyらしくて好きな点です。 #ruby25th— Yuki Yugui Sonoda (@yugui) 2018年2月24日 僕にとってRubyはfluentdやchefのための言語ですが、プラガブルなOSSエコシステムであったり、強力なDSLを作りやすかったりするところにその魅力を感じます。特にfluentdは大好きなOSSで、Mackerel運営でもかなり参考にさせてもらっています。 #ruby25th おめでとうございます！— songmu (@songmu) 2018年2月24日 DSLは本当に感動したところなんだけど、DSL開発ツールとしてのRubyが「発見」されたものなのか意図されたものな

最近、SRE - Site Reliability EngineeringのアナロジーとしてCorporate Reliability Engineeringというのを考えられないかみたいな話を社内でしている。 SREは伝統的なシステム運用チームの仕事を再定義したものだ。SREはシステムの安定だけを至上目的にするのではなく、際限なく増え続ける運用タスクを真面目にこなすことを目的にするのではない。開発チームを巻き込んで適切なシステム安定度を見いだし、より少ない手間でシステムを安定運用するための開発を自ら行なう。運用のルーチンワークに費やす時間を全体の50%に抑えるように努力する。そして残り50%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。 同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社

DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か

コンテキスト あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。 ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。 また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。 問題 プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。 プログラムは自分でCaptchaを解いたりEメールを受け取るのが

『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な

ここ何年か自作のブログシステムrhianoletheでブログをホストしていたが、とうとう耐えきれなくなったので、はてなブログに引っ越した。 主なリソースについてはすべて旧URLからのリダイレクトを提供しているつもりだが、取りこぼしがあったらアクセスログを見ながら適宜修正していこうと思う。 耐えきれなくなったのは、この数年のwebフロントエンドの発展と私の専門領域の乖離が原因だ。まず第一に、数年というもの私が専門にしてきたのはバックエンドだった。 一方、この期間においてデバイスの多様化やフロントエンド技術の発展がめざましく、こちらはこちらで専門化が進んでいったため、もはや個人が片手間に商用水準のフロントエンドをこなせる時代ではなくなってきている。少なくとも私には無理になってきたし、そこは私にとって重要な注力領域ではなくなった。 そういうわけなので、しばらくはてなブログでやっていこうと思う。

最近はlog collectionというと fluentd が話題らしいというので、少し触り始めている。 多少は分かってきたように思うので理解したことと、理解できていないところをまとめてみようと思う。 fluentdとは何か オフィシャルサイトには"tool to collect events and log"と書いてある。 要するに、サーバー群から継続的に情報を吸い上げるための仕組みを提供するdaemonである。 この「情報をかき集める」という枠組みは今時のサーバーサイドでは頻出パターンだ。 データベースサーバ、アプリケーションサーバー、フロントエンドキャッシュサーバー, ...と役割分担をするのが普通だし、 アプリケーションサーバーだって負荷分散のために複数インスタンスを持つのが当たり前だ。 そしてこれらサーバー群をきちんと管理するためには様々な情報をかき集めてきて一カ所に保存したり集

問: Dockerイメージはどういうフォーマットなのか 答: 特定のフォーマットはないが転送時はtar 以前の記事 では、Dockerはアプリケーション動作環境のファイルステムをまとめて差分転送できると書いた。 ではこのディスクイメージはどういうフォーマットなのだろう。 実装こそ違うが実態としては仮想マシン環境に似ているという点を鑑みると、qcowとか何かその類いのファイルフォーマットなのかもしれないという想像も成り立つ。 しかし実際には特定のフォーマットというものはない。 Dockerホスト環境では、ディスクイメージは動作に適した形で保存されている。このため保存形式はdocker daemonの -storage-driver オプションによって異なる。 つまり --storage-driver=aufs で走っているならローカルファイルシステムのサブディレクトリ内に展開されているし、

今までこのblogはVPS上で動作させてきたが、この度 Managed VMs に移行した。 Wikiと全文検索は一時的に利用不能になっているが、他はそのまま動作しているはずだ。 主な動機はいまどき個人blogのためだけにシステムを管理するのは厭ということである。 慣れているのと安いのでManaged VMsにしたが、システムをDockerizeしてあるので、必要であれば少しの手間でElastic Beanstalkでもどこでも移動できる。 難点としては、このblogにはVMがオーバースペックということだ。Managed VMs(elastic beanstalkも同じだった筈だが)はdockerコンテナとそれを走らせるVMを1:1にmapするので、この程度の負荷だとリソースが余ってしまう。複数のコンテナ(モジュール)でシステムを構成しようとするとVMの利用料がかなり無駄である。本当はN:

最近、Jsonnetを用いてwebアプリケーションをデプロイする際に適用する設定群をテストしようとしている。 今やInfrastructure as a Codeと言われて久しく、アプリケーション配備の基盤構成もその上で走るwebアプリケーションをどうやって設定するのかもコードとして書かれるのが一般的になった。 それらはコードとして書かれているのでバージョン管理可能であり、テストも可能である。だから何かが間違っていれば実際に配備する前に気づくし、それでも間違えていれば差し戻せる。 「どうやって設定するか」はコードになった。では「何が設定されるか」はコードになっているだろうか。やっている人もいるだろうけれども、そんなに簡単な話でもない。 実際Chefで設定ファイルを扱う際は templates なり files なりが第一の選択であるとは思うが、これらはよほどヘルパーメソッドを充実でもさせな

祖父母と話していて、ちょっと調べて本を読んで考えれば分かることに対してなぜいつまでも堂々巡りの思考を巡らしているのだろうと思うことが良くあった。 学生時代に工場生産や農業にかり出されてあまり教育を受けられなかったというのはあるが、それにしても祖父は戦後に大学を出ている。時代的な教育の問題だけとも考えづらい。 しかし、よくよく考えてみるとちょっと調べるために私が使うのはインターネットの情報だ。書籍は書籍の価値があるので同様に情報源とする(今は過渡期で境界が曖昧とは言え、やはり書籍の形に手間暇掛けてまとめ上げた有料情報ならではの価値というのはある)が、それにしたって書籍に到達するのはweb上の書評経由であることも多い。入手経路も半数はAmazonからだ。これらを通じて学んだ情報や考え方、情報の取捨選択の方法に基づいて私は考えている。 これらはどれも祖父母が持っていない物だった。自分が何を知らな

先に報告した ようにこのたびGoogleに転職した。 ここで、Googleのトランスセクシュアルへの対応に感心したので書いておく。 履歴書 まず、US系の企業としては当たり前の慣習であり法的自己防衛でもあるのかもしれないけど、履歴書に性別を書かされない。 背景 履歴書に書くべき何か簡潔な性別の記述というものが存在するのであれば私にとっては問題ないのだけれども、実際のところはそうではない。 この話は 以前も書いた 。 人は性別という単一の二値属性が存在することを信じるが、残念なことに自然はそういう風にはできていない。人の信じる仮構は単に、少数者を例外として排除してしまえば幾つかの性別要素にまつわる量が成す数ベクトル空間について2つの同値類が存在し、それを「男」「女」と呼べるというだけの話に過ぎない。 残念なことに最初に省いた特異点を含めると単純な同値類は成立しない。都合の悪い例から逃げずに一

世間は地震により慌ただしい。震源地近くの被災者の方にはお見舞いを申し上げる。 この最中に、個人的な報告を投下するのはちょっと憚られるものもあるのだけれども、あまり時期を外しても書く機会を逸するので思い切って書くことにしよう。 1月一杯で約3年務めた 株式会社スケールアウト を辞め、3月1日から Google Japan で働き始めた。twitterでは大勢の方に祝っていただき有り難い限りである。 Googleについては特に語ることはない。みんなが知っているし、私もまだみんなが知っているようなことの他は僅かしか知らない。だからスケールアウトについて語ることにしよう。 株式会社スケールアウト スケールアウトは広告配信エンジン/広告在庫管理システム/広告入稿システム/広告案件管理システムをフルスタックの製品「ScaleAds」を提供するスタートアップである。 創業 創業者の山崎大輔さんは、元はY

オライリー・ジャパンから『 実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング 』を頂戴した。 概要 オライリーの『実践xxx』『Mastering xxx』 という本は技術xxxに少し慣れてきた人が更にステップアップするための本という印象がある。そして、体系的な理論というよりは現場の常識というものを扱っている。 『実践デバッグ技法』は前者の印象には反する。これは本当にGDBの使い方と問題の切り分け方を手取り足取り教えてくれる本で、まだデバッガが何なのかすら分かっていない人こそ読むべきだ。 一方で後者の印象には合致する。これこそが『 Debug Hacks -デバッグを極めるテクニック&ツール 』で著者のよしおかさんが訴えていた点でもあった。つまり、今までデバッグの技法というものは理論化されそれが普及しているとは言い難い。にもかかわらず、現場では常識である。初心者はどう

会長や取締役の方々、事業部の本部長などラインの上司にあたる方々がブラウザ三国志というゲームにはまりまくっているということです。 知り合いがとある動画サイトを運営している会社に勤めているのですが、会長や取締役の方々、事業部の本部長などラインの上司にあたる方々がブラウザ三国志というゲームにはまりまくっているということです。 このままでは仕事に支障をきたすと思うのですがその知り合いはどうしたらいいでしょうか？ 本当に仕事に支障を来しているとしたら私なら上司たちに面と向かって散々なことを言ったり、社内での愚痴の聞き手に回って楽しんだりしそうだけど、でも、この文面だけからするとひねくれたことを言いたくなるなー。 管理職のためのハッカー FAQより: 2.5: しかしですね、うちの他の従業員はハッカーの成功に気分を損ねてますし、彼らの生産性を損なっているのですが。 あなたは本当に、既に何かをやってしま