2013-03-01 :-(
_ 読書メーター
2013年2月の読書メーター
読んだ本の数：2冊
読んだページ数：746ページ
ナイス数：7ナイス
感情表現辞典の感想
感情を過去の作家たちがどのように表現しているか。など。電子化されてないんだろか
読了日：2月24日 著者：
ワンクリック―ジェフ・ベゾス率いるAmazonの隆盛の感想
本書をどこで知ったのか忘れたんだが、読んでみたらスタートアップの手本だった。始めは小さく、顧客を重視、方向転換、拡大などと書いてあり、リーンスタートアップやRunning Leanで読んだとおりのことが書いてあった。スタートアップの事例として読んでおくと面白い。しかし最初の資金調達というか儲けを度外視するのはたぶん真似しちゃイカンのだろうなあ
読了日：2月11日 著者：リチャード・ブラント
読書メーター
_ [NetBSD][kyua][ATF][テスト][翻訳]NetBSD Blog - Initial Kyua import done初めての Kyua 取り込み終了
March 01, 2013 posted by Julio Merino
I am very happy to announce that the initial import of Kyua into the NetBSD source tree is complete! I am sure there are some rough edges and here is where you come into play.
Kyua の初めての NetBSD ソースツリー取り込み完了について報告できることを嬉しく思います。多少 荒削りな部分があるので、みなさん遊んでね。
First of all, let me clarify that all the integration changes are gated by the MKKYUA build setting, which still defaults to no. Unless you explicitly set MKKYUA=yes in /etc/mk.conf or in the build.sh command line, you will not get a system with Kyua. However, once you set that flag, you will transition to the full new setup:
最初に、MKKYUA ビルド設定によるすべてのゲートの統合変更を明確にしましょう。デフォルトは no です。明示的に MKKYUA=yes を /etc/mk.conf に設定するか、buld.sh コマンドラインに指定しない場合、Kyua システムは使えません。ただし、一度そのフラグを設定すると、完全な新しいセットアップに移行します
- Kyua will be installed as /usr/bin/kyua. See kyua(1) to get started.
- Kyua は /usr/bin/kyua にインストールされる。 kyua(1) を読んで使いはじめよう。
- The old atf-run and atf-report tools will become compatibility wrappers. These should be a reasonable drop-in replacement for most use cases, but they are probably not perfect.
- 古い atf-run と atf-report ツールは互換性を保つためのラッパーになる。これらはほとんどの場合 正しく置き換えられるはずだが、完璧ではない。
- Your /usr/tests tree will be populated by a bunch of Kyuafiles.
/usr/tests ツリーには Kyuafiles のファイルが設置される。
So what's new compared to the ATF tools? Here are some highlights:
それで ATF と比べて何が新しいの？ 要点をいくつか紹介します。
- Ability to write and run ATF-less tests. It has been a common desire around here to develop test programs that do not rely on the ATF libraries. With this change, this becomes possible. See kyuafile(5) for details.
- ATF 不要のテストを記述し、実行できる。それは ATFのライブラリに依存しないテストプログラムを開発するための共通の願いであった。この変更により、これが可能となる。詳細については kyuafile (5) を参照。
- Direct HTML report generation. There is no need to set up a complex XML toolchain any more to convert the ATF test reports into HTML pages. Kyua can generate plain HTML directly, so it will be feasible to serve such content straight from NetBSD's built-in httpd.
- 直接 HTML レポート作成。ATF のテストレポートを HTML ページに変換するために、ややこしい XML ツールチェインをセットアップする必要はない。Kyua が直接プレーンな HTML を生成するので、NetBSD の組み込みの httpd から直接 レポートを提供することができる。
- Historical data. As seen in the various test beds that have appeared around ATF, there is a desire to maintain historical data of the test results. Kyua does that natively, by recording the results of the execution in a SQLite database. Reports can later be extracted from this database. There is still a lot of room for improvement here.
- 履歴データ。 ATF の周りに登場した様々なテストベッドに見られるように、テスト結果の履歴データを維持することが望まれている。Kyua は、SQLite データベース内の実行結果を記録することにより、ネイティブにそれを行う。レポートは後ほど このデータベースから抽出することができる。改善の余地はまだある。
- More flexible metadata and configuration. While this does not provide a real advantage today, as soon as the old atf-run and atf-report tools are gone we can trivially fix some long-standing issues (e.g. the inability to customize test deadlines).
より柔軟なメタデータと設定。今日では本当の利点をもたらさないので、とっとと古い atf-run および atf-report ツールを削除したので、いくつか判明している長年の問題 (例えば、テストの締め切りをカスタマイズすることができない) を修正できる。
- Less complexity during test case execution. As you may have noticed over the years, the code in atf-run to capture the output of tests and deal with interrupts is not particularly robust. There have been several problems in this area, and I'm not convinced that they are all fixed. The new code works in a different manner and has been more carefully thought around these edges.
- テストケースの実行時の少ない複雑さ。長年のことでお気づきかもしれませんが、atf-run 内のコードは割り込みを用いたテストと出力をキャプチャすることは、特に堅牢ではない。この部分にいくつかの問題があり、私はそれらがすべて修正されていたとは思っていない。新しいコードは異なる方法で動作し、より慎重にこれらの粗雑に取り組んだ。
- Independent testers. The code that implements the isolation of test cases and their controlled execution has been split into a set of "testers" that live in /usr/libexec/kyua-*-tester. These tools provide scriptable interfaces to interact with tests, with the idea that the kyua(1) frontend should end up being pretty straightforward. Should you want to write your own trivial script to run tests without kyua(1), you could pretty easily do that by interacting with the testers directly.
- 独立したテスター。テストケースとその制御された実行 {?????} を実装した独立したコードは、/usr/libexec/kyua-*tester の "testers" のセットに分割された。これらのツールはテストと対話するためのスクリプト可能なインターフェイスを提供する。kyua(1) フロントエンドは非常に簡単にしておくべきである、という考えである。kyua(1) なしでテストを実行するには、あなた自身のいつものスクリプトを記述する必要がある。直接テスターと対話することによって、かなり簡単にそれを行うことができる。
How can you help? Easy. Just rebuild your system with MKKYUA=yes, read through kyua(1), start using it to stress-test your system and report any problems you may encounter!
どのように助けることができますか？ 簡単です。MKKYUA=yes にしてシステムを再構築するだけです。kyua(1) を読みましょう。システムをストレステストするためにそれを使用して起動すると、遭遇した問題を報告 できるよ！
My immediate next steps include addressing your feedback and working with our major test runners to add support to their systems to use the new tools (for example, change anita to support running tests with kyua(1)).
私の直近の次の作業は、あなたのフィードバックへ対応し、新しいツールを使用するために私達の主要なテストランナーをシステムのサポートを追加する作業などがあります (たとえば、kyua(1) でのテストをサポートするために anita を変更します)。
