Tatsuya Kawano

@scivola さん、コメントありがとうございます。 > 文末の疑問符・感嘆符のあとは空きを入れることを推したいです。（それらの記号は全角ものを使う前提で） > ... > > さて，「文末の疑問符・感嘆符」としたのは，例えば「マジ？と思った」「アホ！と叫ぶ」のような場合は空けないからです。 > ... > > そもそも，文末の疑問符・感嘆符のあとを空けるのは，文の終止を明示するためです。 なるほど。たしかに、それが理にかなってますね。勉強になりました。 > 横組の場合，全角でもいいのですが，「？」「！」のグリフの両脇がやや空いているために，後ろを全角空きにすると空き過ぎて見えるので，半角空きを好む人もいます。 > この場合の半角空きは U+0020 のスペースのことじゃなくて，全角の 1/2 の空きという意味です。ウェブでは少々面倒な話になるので，私は「全角スペースを入れる」でいいと思います。 U+0020 ですと、行の幅とその行の文字数によって伸び縮みしますから、おっしゃる通り具合が悪いですね。 文末の疑問符・感嘆符のあとに全角スペースを入れることに賛成しますが、具体的にどのように運用してくかは、ちょっと考えさせて（自分で試行錯誤させて）ください。GitHub の diff ですと、原稿の行末にスペース文字があるか見分けづらかったり、全角スペースの文字幅を HTML...

@y-yu PDF版の更新、いつもありがとうございます。 Circle CI ですが、調べてみたところ、follow という概念しかなく、管理者という概念はないようです。（y-yu さんは、すでに Circle CI 上の the-rust-programming-language-ja を follow されているようです。[リンク](https://circleci.com/gh/organizations/rust-lang-ja/settings#users)） Circle CI から GitHub のレポジトリに SSH キーや web hook を登録する際は、GitHub リポジトリ側の管理者権限が必要になります（[参考](https://circleci.com/docs/requires-admin/)）。そこで、[trpl-admin](https://github.com/orgs/rust-lang-ja/teams/trpl-admin) という管理者チームを作って、y-yu さんを登録しました。 > Circle CI...

Circle CI メモ： - [通知：CI 終了時に外部サービスのウェブフックをたたく](https://circleci.com/docs/configuration/#notify) - [通知：通知を飛ばすブランチを制限する](https://circleci.com/docs/configuration/#per-branch-notifications)

> 現状は、github.com 向けのものだけが登録されています。この鍵は私が管理してますので、公開鍵を教えることはできます。 公開鍵ですが、[こちらに](https://gist.github.com/tatsuya6502/3b132eaa3d8431418aecafe03a5f8639#file-trpl_circleci_rsa-pub)置きました。 **finderprint:** ``` % ssh-keygen -l -E md5 -f $HOME/.ssh/trpl_circleci_rsa.pub 4096 MD5:6c:8f:02:77:31:a0:9b:e5:5f:ef:78:11:54:36:8c:34 [email protected] (RSA) ```

GitHub の別のリポジトリでしたか。 Circle CI の web API を使うと、CI から別の CI を起動できるようです（[参考](http://stackoverflow.com/questions/29904816/on-circleci-how-can-i-trigger-one-build-after-another-but-only-if-the-first-is)）。ということは、もし、Circle CI に trpl-ja-pdf の CI を作成したなら、そこに登録したそれ専用のデプロイキー（trpl-ja で使っているものとは別のもの）を使って GitHub trpl-ja-pdf に連携できそうです。 流れ： 1. trpl-ja の CI がビルドに成功。 2. trpl-ja の...

@y-yu さんの案（trpl-ja の CI の途中で deploy key を入れ替えて、trpl-ja から trpl-ja-pdf へ自動コミットする）も、たしかに動くと思います。しかし、これは最後の手段としてとっておいて、この自動コミットは、trpl-ja-pdf の CI で行わせた方がよさそうに感じます。 理由は、trpl-ja の CI と trpl-ja-pdf の CI をできる限り疎結合にしたいからです。そうすることで以下のような利点があります。 - trpl-ja-pdf に関すること（deploy key の設定や自動コミットのスクリプト）が、その中で完結するので、メンテナンスや変更管理がしやすくなる。 - trpl-ja の...

メモ： trpl-ja の最新版を pull する前に、/1.9/ja/book に変更があるかを確認するコマンド。 ``` $ pwd ... /trpl-ja-pdf $ (cd the-rust-programming-language-ja; git fetch origin && git diff --stat HEAD..origin/master -- 1.9/ja/book | grep -q 'files changed'; echo...

https://github.com/rust-lang-ja/the-rust-programming-language-ja/issues/241#issuecomment-275028503 > trpl-ja の CI は、この API を経由して、trpl-ja-pdf の既存の Travis CI による CI を起動するだけにして、残り、というか、メインの作業、つまり、サブモジュールの更新と trpl-ja-pdf への自動コミットは trpl-ja-pdf の既存の CI に行わせてはどうでしょうか？ この方法で構わなければ、私の方で実装してみようと思います。ちょっと時間がかかるかもしれませんが、完成したら、trpl-ja-pdf と trpl-ja に、順に pull request を上げます。 - 第１段階：trpl-ja-pdf の既存の...

> ちょっと見てみないとわからないのですが、trpl-ja-pdfのCIの挙動が次のような二つになりそうな予感がします。 説明不足ですみません。 CI がどうやって起動されたかに関係なく、１回の実行で十分です。 ``` TRPL ← ./the-rust-programming-language-ja # trpl-jaに変更があったかに関係なく、ローカルのsubmoduleのアップデートを試みる。 (cd $TRPL; git fetch origin && git pull origin master) PDFのビルドを実行 # ローカルのsubmoduleがアップデートされているかをチェックする。 st ← (git status $TRPL |...

納得していただけたようで、よかったです。 > 複雑な方法はとりあえずは使わずに、trpl-jaの方に変更があれば常にtrpl-ja-pdfを更新するという方針でよいと思います。 了解です。これで進めますね。