サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
qiita.com/yugui
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — 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について確認しよう。こ
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
状況 TurnipでGivenScenarioしたい! Turnip向けに書いたGherkinシナリオが、他のシナリオに書いたステップで実現される状況を前提としている。 このため、前に書いたシナリオAを今書こうとしているシナリオBにおいて「前提」ステップとして再利用したい。 こんな風に書けたらいいな 機能: Hoge 背景: 前提 Fugaする シナリオ: Aを登録 もし Piyoする ならば PiyoPiyo シナリオ: Bを登録 前提 「Aを登録」しておく もし Hogeraする ならば HogeraHogeHoge 解 Cucumberの各ホスト言語における実装は知らんけど、Turnipの場合割とシンプルに内部でRSpecのdescribe ... context ... it構造にマップされているため頑張ればなんとかなる。 このfeatureに対応して内部で生成されているのはだいた
Rubyにおける良いスタイルとして、ブロック付きメソッドでリソースを自動管理するという手法がある。 この安全性を破壊してみよう。 前提知識 まず、確認として次を見てみよう。 1行目で開いたFileオブジェクトfは3行目で自動的にcloseされる。ブロック中の制御フローが多少複雑でも、例外が発生しても確実に3行目でcloseされる。 最近では他の様々なメジャーな言語が独特の構文で似た機能を提供しているから、10年前とは異なり特にRubyの目立つ機能というわけでもなくなったが、とにかくブロックによるリソース管理は良いものだ。 しかし、安全は不自由でもある。ブロック終了時点で確実にファイルを閉じてしまうため、File.openを呼んだメソッドが終了したあとでf.readを呼ぶことはできない。 def open_file(name) File.open(name) {|f| return f }
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
先の記事では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つ
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
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マシンはドメインメンバーにす
Googleの認証がいよいよ2段階認証としてセキュリティキーをサポートするようになった。 従来の2段階認証ではグーグル認証システムなどが生成する6桁のOpen Authenticationワンタイムパスワード(OATH OTP)を利用していたが、新たにFIDO Universal 2nd Factor(U2F)に準拠したハードウェアトークンを利用できるようになったのである。 早速試してみたので報告したい。 背景 U2Fは2段階認証にさらなる安全性と簡便性をもたらすことになる。 まずは簡便性について。OTPでは6桁の数字を制限時間以内に手で打ち込まねばならなかったが、U2FではUSBポートに挿さったトークンをタップするだけなので簡単である。ただしこれについてはOTPでも簡単にする方法はいくらでも考えられるので、必ずしもU2F特有とは言えないであろう。 重要なのはセキュリティである。OTPは確
このページを最初にブックマークしてみませんか?
『@yuguiのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く