はてなブックマーク

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

IngressのField Testがあるので福井に行ってきた。 Field Testは国内でも数か所で実施されるのでどこに行こうか結構迷ったのだけど、結果としては福井で正解であった。なんだか、自分でも思った以上に福井と縁があったので、終始それを感じて楽しめたのである。 さて、まず福井につくなり駅の階段で迎えてくれるのが永和システムマネジメントの広告である。Rubyといえばesm, esmといえば福井が本社なので、最初からそこはかとない安心感と親近感を覚えさせてくれる。 福井だからなぁ pic.twitter.com/s9fs4Bl3U7— Yuki Yugui Sonoda (@yugui) September 14, 2019 次に、階段を降りたところにいるのが見慣れた恐竜博士の像。ながらく表参道で働いていたのだけれども、昼休みによく歩いたあたりに福井のアンテナショップがあって、その前

時代とともに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%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。 同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社

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

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

@vvakame さんが TechBooster の新刊"JavaScriptoon"の中でgRPCを解説していて、その中で grpc-gateway にも触れている。これはとてもよい記事だったので、みんなこの本の電子書籍版を買えば良いと思う。 ただし、grpc-gatewayは記事中で使われているだけで主題ではないので、すべてのトピックをカバーしてくれているわけではない。それは仕方が無いが、そろそろgrpc-gatewayの機能を見渡す日本語記事が欲しいと思ったので自分で書くことにする。 grpc-gatewayとは gRPC (HTTP/2 + ProtocolBuffers)をwrapして古典的なJSON API (HTTP 1.1 + JSON)を提供するリバースプロキシを生成するコード生成機だ。 別記事 にも書いた。 何ができるのか gRPCで使うサービス定義(IDLみたいなやつ

Context The service you are developing provides APIs for users. When an user calls an API, (s)he must show a short-living authorization credential, e.g. an OAuth2 token. The user creates, owns, updates or deletes resources in the service on behalf of the account to which the credential is associated. Here, the `user' might be (an user-agent operated by) a human but also it might be an automated pr

先日公開した grpc-gatewayだが、gRPCのメーリングリストで宣伝したらGoogleからフィードバックがあったので対応した。 実はGoogleは社内にgrpc-gatewayに似た仕組みを持っていて、RESTful APIとgRPCの変換にはそれを使っている。 んで、今回Googleはその変換の設定に使っているスキーマを https://github.com/google/googleapis/tree/master/google/api に公開してくれたのだ。 これを受けてgrpc-gateway独自のカスタムオプションを捨ててGoogleが公開したオプションを使うことにした( grpc-gateway#12 )。これには幾つか理由がある。 Googleの長年の経験を踏まえて設計された語彙のほうが、私がとりあえずプロトタイプとして適当に設計した語彙より拡張性と十分性において信頼

grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く

引き続き、 言語処理100本ノック を敢えてRubyで解いている。 第3章は正規表現がテーマだが、正規表現はそこまで得意ではないので辛い。マッチの効率とか深く考えていない。 20. JSONデータの読み込み require 'json' uk = File.foreach("jawiki-country.json"). map(&JSON.method(:parse)). find {|article| article['title'] == 'イギリス' } raise "no article about イギリス" unless uk puts uk['text'] 感覚的なものだけど、この場合は &obj.method(:mid) 形式の簡潔さが見慣れない分のデメリットを上回る気がした。 21. カテゴリ名を含む行を抽出 File.foreach('uk.txt').grep(/\[

10. 行数のカウント p $<.count 確認 wc hightemp.txt $< の仕様はまさにこういう処理を書くために考えられている。 が、今回に関しては普通ならわざわざ書かずにwcを使う。 11. タブをスペースに置換 $<.each_line do |line| puts line.gsub("\t", ' ') end 確認 sed "s/^I/ /g" hightemp.txt 12. 1列目をcol1.txtに，2列目をcol2.txtに保存 File.open("col1.txt", "w") {|f1| File.open("col2.txt", "w") {|f2| $<.each_line do |line| cols = line.split("\t") f1.puts cols[0] f2.puts cols[1] end } } 確認 cut -f1 hi

言語処理100本ノック を(飽きるまで)やってみるにあたり、敢えてRubyで書いてみる。 基本的にはPythonを想定しているらしいし、そもそもNLPライブラリの充実度から言ってもPythonを使うのが極めて妥当な選択といえるだろう。そこを敢えてRubyで。 00. 文字列の逆順 puts "stressed".reverse RubyでもPythonでも大差ない。 01. 「パタトクカシーー」 str = "パタトクカシーー" puts 1.step(7, 2).map{|i| str[i]}.join やはりスライスにstepを指定できるPythonのほうが楽である。 02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 strs = %w[パトカー タクシー] puts strs.map(&:chars).inject(&:zip).flatten.join 別解 strs =

『 アンダースタンディング コンピュテーション ―単純な機械から不可能なプログラムまで 』を監訳者の笹田さんから頂戴したので、読んだ感想をまとめてみる。 この本はRubyを用いて計算理論を紹介しようというものだ。具体的には次のようなトピックを扱っている。 形式的意味論 操作的意味論 表示的意味論 オートマトンとチョムスキー階層 ラムダ計算 停止性問題と計算不能性 静的意味論と型システム サンプルが丁寧に書かれていて簡単に動作させられること。これが本書の強みだと言える。 正直なところ今までオートマトンはともかく形式的意味論は他の本を何度を読んでもいまいちピンと来なかったのだが、本書のサンプルプログラムを動かして初めて理解が進んだ気がする。 そもそも本文にも書かれているように、ミニ言語の形式的意味論をより強く(曖昧な)言語であるRubyで書いたところで理論的には意味は無い。 意味の定義がRub

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

『プロフェッショナルのための実践Heroku入門』をざっと読んだ。 コンパクトにまとまっていて良い本だと思う。 私が以前1日がかりで調べて回ったこと+αぐらいが書かれているので、読んでおけばそういう調べ回る時間を節約してくれるし。 インストール手順に結構な紙面を割いたりするあたりはあまり好みの構成ではないが、薄い割に触れているトピックが豊富なのは良い。 Herokuの概要、各言語の開発環境セットアップ、Herokuを用いたアプリケーションの開発サイクル、デプロイの仕組み、Addon, Herokuアーキテクチャの外観などに順に触れている。 web開発者ならこれだけ一冊読めばとりあえずHerokuにアプリケーションを立ち上げられるようになるだろう。 ベストプラクティスやアンチパターンについても折々触れているので、読んでおけば先々楽にもなる。 残念なのは、workerプロセスについては名前ぐら

libchan を読んだのでまとめてみる。 libchanとは libchanはdockerに使われているライブラリの1つで、先月の DockerCon で発表された。 非同期かつ一方向の通信チャネルをインプロセスでもネットワーク越しでも扱えるというGoライブラリである。 一方向とはいうものの、チャネル自体をデータに添えて他のチャネル越しに送れる。なので、返信や待ち合わせが必要ならば自分宛のチャネルを送って相手に使ってもらい、自分はそのチャネルの上で待機していれば良い。 早い話がGo言語の機能であるチャネルをネットワーク対応したようなものだ、と書いてある。 DockerはこのDockerConではDocker 1.0に加えてlibcontainer, libchan, libswarm, Docker Hubを発表していて一応キーノートの話題の１つではあったものの、 個人的にはlibswa

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

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