タグ

ブックマーク / qiita.com/yugui (9)

  • ぼくたちのかんがえたさいきょうのi18n国家

    記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良

    ぼくたちのかんがえたさいきょうのi18n国家
    progrhyme
    progrhyme 2018/08/11
    とても1人の人間の手に負えるものではない
  • protocプラグインの書き方 - Qiita

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

    protocプラグインの書き方 - Qiita
    progrhyme
    progrhyme 2018/02/11
  • 今さらProtocol Buffersと、手に馴染む道具の話 - Qiita

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

    今さらProtocol Buffersと、手に馴染む道具の話 - Qiita
    progrhyme
    progrhyme 2018/02/08
  • ブロック付きメソッドによる安全なリソース管理を破壊する - Qiita

    Rubyにおける良いスタイルとして、ブロック付きメソッドでリソースを自動管理するという手法がある。 この安全性を破壊してみよう。 前提知識 まず、確認として次を見てみよう。 1行目で開いたFileオブジェクトfは3行目で自動的にcloseされる。ブロック中の制御フローが多少複雑でも、例外が発生しても確実に3行目でcloseされる。 最近では他の様々なメジャーな言語が独特の構文で似た機能を提供しているから、10年前とは異なり特にRubyの目立つ機能というわけでもなくなったが、とにかくブロックによるリソース管理は良いものだ。 しかし、安全は不自由でもある。ブロック終了時点で確実にファイルを閉じてしまうため、File.openを呼んだメソッドが終了したあとでf.readを呼ぶことはできない。 def open_file(name) File.open(name) {|f| return f }

    ブロック付きメソッドによる安全なリソース管理を破壊する - Qiita
    progrhyme
    progrhyme 2017/06/01
    ご利用は計画的に案件ぽい
  • cgoを使ったCとGoのリンクの裏側 (2) - Qiita

    先の記事では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

    cgoを使ったCとGoのリンクの裏側 (2) - Qiita
    progrhyme
    progrhyme 2017/04/27
  • 至高のDockerイメージ生成を求めて - Qiita

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

    至高のDockerイメージ生成を求めて - Qiita
    progrhyme
    progrhyme 2016/12/22
  • 例外、エラー、異常、そして - Qiita

    「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「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

    例外、エラー、異常、そして - Qiita
    progrhyme
    progrhyme 2016/09/01
    シソーラス揃えたい案件。
  • Jsonnetの薦め - Qiita

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

    Jsonnetの薦め - Qiita
    progrhyme
    progrhyme 2016/07/31
  • cgoを使ったCとGoのリンクの裏側 (1) - Qiita

    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

    cgoを使ったCとGoのリンクの裏側 (1) - Qiita
    progrhyme
    progrhyme 2016/04/11
  • 1