声に出して読みたいUNIX&LINUXライブラリ関数
"LINUXプログラミングインターフェイス"という本を読みました。 この本は、"本書は Linux および UNIX システムプログラミング API の(ほぼ)完全な解説を目標とし、内容 は広範囲の Linux プラットフォームに通用するもの(まえがきより)"ということで、約1500ページに渡りPOSIX/SUS API及びLINUX独自のシステムコールについて広範な解説を行っている書籍です。
- 作者: Michael Kerrisk,千住治郎
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/01
- メディア: 大型本
- クリック: 14回
- この商品を含むブログ (5件) を見る
せっかく読んだので何かアウトプットを出したいと思い、知らなかったけれど便利そうなAPIの一部を並べてみることにしました。自分が知らなかったものなので特にジャンル(?)はなく雑多です。
続きを読むPolymerのデータバインディングについて(公式ドキュメント日本語訳)
はじめに
最近気になっていたWeb Componentsを本格的に触り始めようかということで、Web Componentsの機能をフル活用したライブラリであるPolymerの公式ドキュメントを斜め読みしていたところ、データバインディングについて記載があったので訳してみました。
個人的には、Model-View間でのデータバインディング機能がまともにない環境では効率的にアプリを作成することは難しいと思っているので、結構肝のところかなと思います。なお、訳したのはデータバインディングのところだけです。悪しからず。
訳してみた感想としては、(Web標準なので当たり前かもしれないですが)ライブラリ特有の癖がなく、一度学習したらすんなり使えそうな印象を受けました。今度時間をとって実際に試してみようと思います。
なお、本ドキュメントのライセンスは原文と同じくCC BY 3.0であり、原文はPolymer Authorsにより記述され、原文そのものはここにあります。
続きを読むC++における単体テストのための依存性注入方法まとめ
はじめに
あるモジュールを作成した時、当然ながら(ですよね?)このモジュール(以降テスト対象モジュールと呼びます)を何らかの方法でテストする必要があります。テスト対象モジュールが別のモジュール(以降依存モジュールと呼びます)に依存している場合、
- テスト対象モジュールと依存モジュールを一緒にテストする
- 何とかして依存モジュールをテスト対象モジュールと切り離し、テスト対象モジュールを単独でテストする。
一般的に、1は結合テスト、2は単体テストと呼ばれます。
この記事では、単体テストで何とかして依存モジュールを切り離す、言い換えるとテストのために別の依存モジュール(依存性)を注入する方法を紹介します。
一応記事タイトルをC++としていますが、いくつかは別の言語でも使えるはずです。
node.jsを支えるlibuvのチュートリアル"uvbook" :プロセス
この文書はuvbookの日本語翻訳の一部となります。文書そのものの説明その他については目次をご覧ください。
プロセス
libuvはかなりの量の子プロセス管理機能を提供しており、プラットフォーム間の差異を抽象化し、ストリームや名前付きパイプを用いて子プロセスと通信することを可能にしています。
Unixにおける共通のイディオムは全てのプロセスが一つのことを良好に行えることです。このようなケースでは、プロセスはタスクを完遂するために複数の子プロセスを使用します(シェルがパイプを用いるように)。メッセージを用いるマルチプロセスモデルはスレッドと共有メモリを用いるモデルに比較して簡単になるでしょう。
イベントベースのプログラムに対する共通のマイナス要因は現代のコンピュータにおいて複数のコアを持つ利点を活用しきれない点です。マルチスレッドプログラムではカーネルはスケジューリングを行い、異なるスレッドに異なるコアを割り当てることができます。しかし、イベントループは単一のスレッドです。これに対する回避策は代わりに複数のプロセスを起動することであり、各プロセスはイベントループを処理し、各プロセスは別々のコアを割り当てられます。
続きを読むnode.jsを支えるlibuvのチュートリアル"uvbook" :スレッド
この文書はuvbookの日本語翻訳の一部となります。文書そのものの説明その他については目次をご覧ください。
スレッド
ちょっと待って下さい? なぜスレッドの話をするのですか? イベントループは web-scaleプログラミング を行うための 手段 だったのではないのですか? いいえ、違います。スレッドはまだプロセッサが処理を行う際の手段であり、同期プリミティブを苦労して使う必要があるとしても、スレッドは時々かなり有用です。
スレッドは全てのシステムコールを非同期の性質を持つかのように装わせるために内部的に用いられています。libuvはまた、スレッドを起動してタスクが終了した時に結果を収集することにより、実際はブロックするタスクを非同期的に実行するためにスレッドを用いています。
現在、２つの有力なスレッドライブラリが存在します。Windowsのスレッド実装とpthreadsです。libuvのスレッドAPIはpthread APIによく似ており、しばしば同様の部分があります。
libuvのスレッド機能の特筆すべき点は、これがlibuvそのものに含まれている(self contained)点です。他の機能がイベントループやコールバックと密接に関係しているのに対して、スレッドは完全に隠蔽されており、戻り値を直接経由したシグナルエラーを必要に応じてブロックし、最初の例で見るようにイベントループを実行する必要すらありません。
libuvのスレッドAPIはスレッドの意味や文法がプラットフォームごとに全て異なり、完全さの店でもレベルが異なるのでとても制限されています。
この章では以下の仮定を行います: 一つのイベントループだけが存在し、単一(メイン)のスレッド上で動作する （ uv_async_send を用いた場合を除き）イベントループは他のスレッドと関連することはありません。 :doc:multiple は異なる複数のスレッドでイベントループを実行し、これらを管理します。
