はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一

gRPCで送受信されるメッセージは、標準ではProtocol Buffersでシリアライゼーションされることになっている。一方、gRPCのwire protocolはそこは柔軟になっていて、実際、多くの実装ではシリアライゼーション形式をカスタマイズ可能だ。 たとえば、ある種のニーズのためにFlatBuffersが必要だとか、HTTP/2をサポートする標準的なツールでの解析のためにJSONのほうが可読性が良いとか、社内のバイナリ表現の一貫性のためMsgPackが必要だとか、宗教的な理由でProtobufを使えないとか、そういうときはスキーマだけprotobufで書いておいて、シリアライズは好きなようにやれば良い。 で、具体的にはそれはどうやったらできるのだろう。これが本稿の話題である。いくつかの言語で実際にJSONでシリアライズするクライアントとサーバーを書いてみたので、その結果を紹介する。

以前の記事ではprotocプラグインの書き方を紹介したが、実は1つ問題があった。 実用的なプラグインを書こうとした場合に、しばしば生成時に必要な、ドメイン固有の情報が足りないのである。本稿ではそれを補うカスタムオプションの話をする。 ここでもう一度確認しよう。protocのプラグインはProtocol Buffersのスキーマを読んで任意の処理を行える仕組みだ。それはCodeGeneratorRequest内のFileDescriptorProto messageを読み取って任意のバイト列を出力し、出力を受け取ったprotocが指定通りにファイルにバイト列を書き込んでくれる。 ただ、FileDescriptorProtoはprotobufのスキーマ言語の文法をprotobufメッセージとして表現したものに過ぎないから、極めて一般的なデータ構造とサービス定義を表現する能力しか持たない。プログ

様々なシリアライズ形式やデータベース向けのスキーマ言語としてProtocol Buffersが有用という話や、そのためにprotocプラグインを書く話をしてきた。 ここで、少し話は変わってProtocol Buffersメッセージのテキスト形式の話をする必要がある。 protobufで定義されたメッセージは、実はバイナリ形式やJSONにシリアライズするほか、独自のテキスト形式にもシリアライズできる。 テキスト形式はバイナリ形式の効率性やプロトコル後方互換性を欠いているが、いくつかよく使われるパターンがある。 protobufスキーマにカスタムオプションを記述するとき protobufデータを処理中のログ出力 protobufを積極活用しているプロダクト内での設定ファイル形式 別に読み書きが難しいフォーマットではないが、世の中にあまりドキュメントがないため書いておこうと思う。 なお本稿は、実

以前の記事では、Protocol Buffers (protobuf)の魅力の1つは周辺ツールを拡張しやすいことだと述べた。そこで本稿では具体的に拡張のためのprotocプラグインの書き方を紹介したい。 ちなみに、protobufの周辺ツールと言うと2種類ある。 1つはprotobufでシリアライズされたデータを処理するツール。JSONやCSVにとってのjqやsedやawkに相当する。 もう1つはprotobufのスキーマを処理するツール。 先の記事にあるようにProtobufはシリアライゼーション機能だけでなくスキーマ言語としても価値が高いので、典型的なweb開発用途では後者のほうが重要だ。 本稿は後者のスキーマ処理の話である。なお前者は、チュートリアルでAPIを覚えたらあとは自分で好きな処理を書きましょうというだけの話なので、別に難しくない。 protoc 初めに、protocについて

Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ

先の記事ではGoコードからCの関数を呼び出す(import)場合について見た。 この記事では逆にCの関数からGoのコードを呼び出す、つまりGoの関数をCにexportする場合を扱う。 ただし、ここで言うのはあくまでも「Goのパッケージの一部をCで実装するにあたって、CコードがGoの機能を利用できる」ということだ。CプログラムにGoライブラリを埋め込む話(-buildmode=c-archive, -buildmode=c-shared)とは別で、そっちの話は別途扱う予定だ。 今回の話では、プログラム全体はあくまでもGoで書かれてる前提で、前回と同様にそのごく一部だけをCで書くことを想定している。 サンプルコード 今度は次のような4つのファイルからなるパッケージ github.com/yugui/cgo-explained/example2を考える。 //exportディレクティブでgoVe

Vagrantで簡単に隔離された開発環境を構築できるようになって久しいが、その後も不満な点がいくつかあった。 最近になって一応満足できる解決策を見つけたので記述する。 細かな点やVagrantの使い方次第ですぐに解決できるものはさておき、主な不満点は下記のようなものだった。 設定やツールのカスタマイズ管理 私の場合は開発環境には最新のRubyが入っていてほしいし、「いつもの」Vim設定やZsh設定が為されていてほしい。 関連リポジトリのチェックアウト 関連する複数のソースリポジトリをチェックアウトしてきてそれらをまとめて1つのVagrant環境内で開発したいことがよくある。 しかし、もはやgit cloneとかタイプすることすら面倒だし、環境を作り直すたびにどのリポジトリをチェックアウトすれば良いのか覚えておくのは嫌になる。 以上すべてのバージョン管理 当然のことながら、Vagrantfi

cgoを用いるとCのライブラリをGoバイナリにリンクしたり、Goパッケージの一部をCで書いたりできる。更にGo 1.5以降では、GoのパッケージをC用の静的ライブラリまたは動的ライブラリにまとめておいて、Cからリンクすることもできる。 これらの機能はすべてgo buildコマンドに統合されているので、普段は特にcgoを使っていることを意識することは少ない。しかし、pure goのコードのビルドにしたところでその裏側ではコンパイラ、アセンブラ、リンカが走っているわけである。ではcgoの場合をこの水準で見るとどのような処理が行われているのだろうか。 要は、gcc(1)の裏ではcc1, as, collect2なんかが走ってるよね、cgoではどうなってるの?　という話が本稿の話題である。 なお、Goのオブジェクトファイルがプラットフォーム独立な(ELFとかではない)フォーマットであることや、Go

JsonnetというJSONテンプレート言語を紹介する。 後で見るように、これはJSONを生成するための汎用テンプレートというよりはむしろ、計算や依存関係を含む設定を静的に書き下すために便利なのではないかと考えられる。 実際Jsonnetの仕様はGoogleのBCLに似ている。BCLはGoogleでコンテナクラスタシステムBorgの設定を記述するために使われている言語だ。 JSONテンプレート言語 ある意味でJsonnetは毎度おなじみのやつだ。JavaScriptの文法の不便さに対してalt JSが多数出てきた。CSSにおけるネストの分かりづらさやの記述の重複に対してCSS preprocessorが多数出てきた。それと同じようにして、Webにおける機械可読データのLingua FrancaたるJSONを記述するのが不便なのでJSONテンプレートが出てきた。 Jsonnetはその中の1つ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRu

Samba4でWindows/Linuxの認証統合をしてみた。 次のような要件が背景にある WindowsとGNU/Linuxで共通のユーザー認証データベースを用いる Windowsホストはいろんなバージョンがある LinuxホストはUbuntu Trusty Tahr 予算がないのでWindows Serverをドメインコントローラーにするのは却下 ホームディレクトリはネットワーク上に置いて各マシンで共通して用いる (本稿では扱わないが)できればSolarisとHP-UXとAIXとIrixとFreeBSDも統合したい いろんなOSで依存性を解決してSambaをビルドして回りたくないのでwinbind認証は却下 SSOできるに越したことはない 要件を鑑みて、次のような構成にしてみた Samba4でActive Directoryドメインを構成する Windowsマシンはドメインメンバーにす

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Googleの認証がいよいよ2段階認証としてセキュリティキーをサポートするようになった。 従来の2段階認証ではグーグル認証システムなどが生成する6桁のOpen Authenticationワンタイムパスワード(OATH OTP)を利用していたが、新たにFIDO Universal 2nd Factor(U2F)に準拠したハードウェアトークンを利用できるようになったのである。 早速試してみたので報告したい。 背景 U2Fは2段階認証にさらなる安全性と簡便性をもたらすことになる。 まずは簡便性について。OTPでは6桁の数字を制限時間以内に手