# ルールとコーパスをglobalへインストール
$ npm i -g . textlint technological-book-corpus-ja
# コーパスに対してルールを実行する
$ technological-book-corpus-ja | xargs textlint --rule textlint-rule-ja-no-redundant-expression -f pretty-error
✈ technological-book-corpus-ja| xargs textlint --rule textlint-rule-ja-no-redundant-expression -f pretty-error
ja-no-redundant-expression: "演算を行う"は冗長な表現です。"演算する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/database-programming.md:145:38
v
144. * レコードは「カラム (属性) 」を持つ
145. * SQL と呼ばれる言語に基づいて、テーブルを定義したりテーブルに対して演算を行うことができる
146.
^
ja-no-redundant-expression: "問い合わせを行う"は冗長な表現です。"問い合わせする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/database-programming.md:170:12
v
169. ## SQL
170. * 関係データベースに問い合わせを行うための言語
171. * SQLは標準化されており、ほとんどのRDBMSで使うことができる
^
✓ ja-no-redundant-expression: "することができるカラム"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/database-programming.md:532:19
v
531.
532. * テーブル内でレコードを一意に識別することができるカラム (任意)
533. * 他のレコードと被ってはいけない (UNIQUE制約)
^
✓ ja-no-redundant-expression: "することができるB"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/database-programming.md:625:11
v
624. * 計算量
625. * インデックスがない: O(n)
626. * インデックスあり: O(log n)
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/foundation-of-programming-scala.md:973:13
v
972.
973. 型パラメータは柔軟に指定することができ、例えばあるクラスの派生クラスのみ受け取りたい、などの指定ができる。
974. より詳しく知りたい場合は、「型境界」「変位指定アノテーション」などのキーワードで調べてみよう!
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:22:82
v
21.
22. View は画面の表示を司るコンポーネントである。iOS アプリにおいては `UIView` とそのサブクラスにあたる。View は複数の subview を内包することができ、view を重なり合わせて画面をつくる。アプリは原則的にひとつのウインドウ (`UIWindow`) を持ち、その上に必要な view をいくつも載せていく。
23.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:636:164
v
635.
636. Web API と通信する際、`viewDidLoad()` メソッドを利用した。これは view controller のライフサイクルメソッドの一つである。View controller にはライフサイクルが存在し、生成されて表示され、さらに非表示になるまで、いくつもの段階を追うことができる。このライフサイクルに合わせて処理を行うことが非常に重要である。
637.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:647:391
v
646.
647. `loadView()` は `UIViewController` の `var view: UIView!` property が `nil` のとき、`view` にアクセスすると呼び出される。デフォルトでは `view` property に空の `UIView` のインスタンスをセットする。また Storyboard などを利用していれば、紐付けられた view が読み込まれる。このメソッドを override して、独自の view を読み込むようにしてもよい。`UITableViewController` の場合はここで `UITableView` のインスタンスがセットされている。こうして `view` が読み込まれると、次に `viewDidLoad()` が呼び出される。この時点で view が生成されていることが保障されるので、これを前提とした追加の処理を行うことができる。
648.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:669:43
v
668.
669. Storyboard で設定された segue の identifier に合わせて処理を行うことができる。
670.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:703:151
v
702.
703. `@IBOutlet` と同様に、`@IBAction` 属性を付けたメソッドは Interface Builder から参照できる。`UIButton` などの `UIControl` オブジェクトから、`UIControlEvents.TouchUpInside` などのイベントを接続し、必要な処理を行うようにすることができる。
704.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:703:159
v
702.
703. `@IBOutlet` と同様に、`@IBAction` 属性を付けたメソッドは Interface Builder から参照できる。`UIButton` などの `UIControl` オブジェクトから、`UIControlEvents.TouchUpInside` などのイベントを接続し、必要な処理を行うようにすることができる。
704.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:711:160
v
710.
711. `UIControl` を継承していない view や、あるいは単純ではないジェスチャーを扱うために、`UIGestureRecognizer` を利用することもできる。`UIGestureRecognizer` の種々のサブクラスを `UIView` に `addGestureRecognizer(_:)` で追加することができ、タップやスワイプなどのジェスチャーに対する target や action を設定できる。
712.
^
✓ ja-no-redundant-expression: "することができるほか"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:728:53
v
727.
728. `NSLayoutConstraint` は Interface Builder から GUI 上で設定することができるほか、イニシャライザ `init(item:attribute:relatedBy:toItem:attribute:multiplier:constant:)` や _visual format language_ で初期化できる。また `UIView` の _layout anchor_ を利用することもできる。Visual format language では、例えば `H:|-8-[view]-8-|` のような書式で、複雑な複数の制約を一度に作ることができる。Layout anchor は `NSLayoutAnchor` のインスタンスで、例えばふたつの `UIView` の `var topAnchor: NSLayoutYAxisAnchor { get }` property を使って `view1.topAnchor.constraintEqualToAnchor(view2.topAnchor)` とすると、view の上辺が揃う制約を作ることができる。
729.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:752:32
v
751.
752. Xcode でアプリを開発する際には、ふたつの方法で自動テストすることができる。プログラムの個々のモジュールが期待どおりに動作することを確かめるユニットテストと、アプリを操作して正しく動作することを確認する UI テストである。Xcode においては、これらは `XCTest` フレームワークの機能として提供される。これらの機能はプロジェクトエディタでテスト用のターゲットを追加することで利用できる。
753.
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:781:28
v
780.
781. ユニットテストでは、単にプログラムの特定の部分についてテストを行う。主に公開 API について、その振る舞いが正しいことをテストする。
782.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:783:152
v
782.
783. テスト対象の Swift のモジュールは、テストコードとは異なるモジュールになっている。すなわち `import` する必要があり、また `public` の可視性を持ったシンボルしか参照できない。ただし `@testable import` することで `internal` の可視性を持つものを参照することができる。
784.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:798:98
v
797.
798. テストメソッドでは、UI を操作してその結果が正しいことをアサーションしていくことになる。UI を操作するコードは一般に煩雑であり、手で書くのは比較的難しいので、Xcode では人間の操作を記録することができるようになっている。
799.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-development-apps.md:823:21
v
822.
823. 例外発生時に止まるブレークポイントを設定することができ、例外の原因を辿りやすくなる。
824.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:179:64
v
178.
179. このように値が `nil` かどうかをケアしたくないとき、`ImplicitlyUnwrappedOptional` 型を利用することができる。`ImplicitlyUnwrappedOptional<String>` は `String!` と書ける。
180.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:248:11
v
247.
248. すべての要素について処理を行いたい場合は `for...in` が利用できる。処理は Array の要素の順序通りに行われる。
249.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:281:11
v
280.
281. すべての要素について処理を行いたい場合は `for...in` が利用できる。Set では順序が不定である。
282.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:312:11
v
311.
312. すべての要素について処理を行いたい場合は `for...in` が利用できる。それぞれの要素がキーと値のタプルで得られる。順序は不定である。
313.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:476:27
v
475.
476. `for...in` 文を利用してすべての要素を列挙することができる。このとき列挙される対象となる集合は `protocol SequenceType` に準拠している必要がある。
477.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:611:96
v
610.
611. 関数は、関数名やラベル、引数の型、返り値の型などを合わせてシグネチャを形成する。シグネチャが異なる関数は別な関数となる。このことを利用して、関数名は同じだが引数や返り値の型は異なる関数を定義することができ、これをオーバーロードと呼ぶ。オーバーロードされた関数は、引数や返り値の型から呼び出される関数が決まる。
612.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:651:14
v
650.
651. 引数にはデフォルト値を設定することができ、デフォルト値の設定された引数は呼び出し時に省略できる。
652.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:683:61
v
682.
683. 引数ラベル以外のシグネチャが同じ関数があり、関数名だけで一意に特定できない場合は、引数ラベルを明示することで曖昧さを回避することができる。
684.
^
✓ ja-no-redundant-expression: "することができるので"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:705:9
v
704.
705. また関数はネストすることができるので、上記の例は下のようにも書ける。
706.
^
ja-no-redundant-expression: "呼び出しを行う"は冗長な表現です。"呼び出しする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:743:141
v
742.
743. `guard` に続けて `if` 文のように必要な条件を記述し、`else` 節でそれが充足されなかったときの処理を書く。`else` 節では必ず `return`, `break`, `continue`, `throw` のいずれかまたは 返り値が `Never` の関数の呼び出しを行う必要がある。
744.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:834:89
v
833. >
834. > クロージャを受け取る関数は、そのクロージャを評価しても評価しなくてもよい。このため特定の条件に当てはまる場合にだけ必要な値を得るのに、その値を返すクロージャを受け取るようにすることができる。もし必要なければクロージャを評価しないことでパフォーマンスを改善できるかもしれない。このようなユースケースのために `@autoclosure` 属性があり、関数の引数にこの属性をつけることができ、この属性がつけられた引数に渡す値は自動的にクロージャに変わる。例えば `func someFunc(parameter: @autoclosure () -> String)` という関数に `someFunc("A" + "B")` という風に引数を与えることができ、このとき `"A" + "B"` は呼び出し時には評価されず、関数の内部でクロージャを評価したときに実際に評価される。実際に `??` 演算子はこの属性を活用しており、`func ??<T>(optional: T?, defaultValue: @autoclosure () -> T) -> T` という定義になっている。左辺値が nil でなければ右辺を評価しない短絡評価はこのように実装されている。
835.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:882:31
v
881.
882. enum 型の要素を引数に与えるとき、enum の型名を省略することができる。
883.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:912:94
v
911.
912. メンバの名前には、予約語を使用することはできないが、バッククォートで囲むことで一部(`self`, `dynamicType`, `Type`, `Protocol`)以外の予約語を宣言することができる。
913.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1109:51
v
1108.
1109. `willSet` や `didSet` ブロックを書くことで、プロパティの値の変化の前後に何らかの処理を行うことができる。
1110.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1283:13
v
1282.
1283. イニシャライザは複数定義することができる。また第一引数からラベルを明示する。
1284.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1289:69
v
1288.
1289. 値型の場合は `self.init` で自身のイニシャライザを呼び出すことができる。stored プロパティに初期値を与える以外の初期化処理を行っている場合、そのイニシャライザを呼び出すことでコードの重複を避けられる。
1290.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1301:53
v
1300.
1301. `required` 修飾子をイニシャライザに前置することで、サブクラスにそのイニシャライザの実装を強制することができる。
1302.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1446:13
v
1445.
1446. protocol は継承することができ、`protocol SomeProtocol: AnotherProtocol` という形で書ける。また protocol に準拠できる型を class に限定することができ、`protocol SomeProtocol: class` と宣言する。
1447.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1446:101
v
1445.
1446. protocol は継承することができ、`protocol SomeProtocol: AnotherProtocol` という形で書ける。また protocol に準拠できる型を class に限定することができ、`protocol SomeProtocol: class` と宣言する。
1447.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1456:28
v
1455.
1456. extension を用いることで既存の型に機能を追加することができる。追加できるのは computed プロパティやメソッド、イニシャライザや subscript である。stored プロパティを増やすことはできない。
1457.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1470:13
v
1469.
1470. このように任意の型を拡張することができる。
1471.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1472:37
v
1471.
1472. extension 型を何らかの protocol に適合するように拡張することができる。`extension Something: SomeProtocol` のように書ける。
1473.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1502:59
v
1501.
1502. 上記の例では `protocol Collection` を拡張している。また `where` 節によって条件を指定することができ、この場合は `Collection` の個々の要素が protocol に適合しているか確認している。
1503.
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/swift-programming-language.md:1581:34
v
1580.
1581. 関数の最後に必ず実行したい処理がある場合、`defer` 文を利用することができる。
1582.
^
ja-no-redundant-expression: "アクセスを行う"は冗長な表現です。"アクセスする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/web-application-development-scala.md:263:15
v
262. - repository
263. - データベースへのアクセスを行う
264. - modelへのマッピングを行いオブジェクトを返却する
^
ja-no-redundant-expression: "マッピングを行う"は冗長な表現です。"マッピングする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/web-application-development-scala.md:264:14
v
263. - データベースへのアクセスを行う
264. - modelへのマッピングを行いオブジェクトを返却する
265. - Data Mapper Pattern
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/web-application-development-scala.md:513:60
v
512.
513. ScalatraのURLパスは単純な文字列だけではなくパターンを指定してその値をできます。例えば以下のようにidを取得することができます。
514.
^
✓ ja-no-redundant-expression: "することができまし"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/web-application-development.md:361:48
v
360.
361. という html を出力するとします。これで A さんはブログを書き、その内容を他の人達に共有することができました。
362. ここで B さんがこのブログサービスに目を付けました。B さんは「<script>alert('XSS')</script>」という内容で投稿しました。この B さんのブログを見た人には
^
ja-no-redundant-expression: "通信を行う"は冗長な表現です。"通信する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/web-application-development.md:373:86
v
372. という html が出力されます。これは有効な html ですので、ブラウザは script タグを解釈して alert を実行します。B さんのブログを見に行った人には、ブログサービス側が意図していないアラートで `'XSS'` が表示されるということです。
373. B さんにはいたずら心はありましたが悪意があるわけではなかったので、よくわからないアラートが表示されるだけで済みました。もし悪意があれば cookie をいじったり勝手に通信を行ったり、JavaScript で可能な操作ができてしまいます。その結果、ユーザーに意図しない行動をとらせることが出来てしまう可能性があります。
374.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/01_What_is_Blender_What_is_Add-on.md:18:180
v
17.
18. Blenderは元々オランダで開発されていたレンダリングソフトでした。現在はオープンソース化され、3Dモデリングからマテリアル設定・アニメーション制作など、3DCG制作に必要なほとんどの作業をBlenderだけで行うことができるなど高機能化しています。さらに最近ではゲームエンジン機能も強化されるなど、Blenderを用いてインタラクティブなコンテンツを制作することができるようになってきています。Blenderの開発は現在も活発であることから、今後の発展が非常に楽しみなソフトの1つであると言えます。
19.
^
ja-no-redundant-expression: "であると言えます"は冗長な表現です。"である" または "と言えます"を省き簡潔な表現にすると文章が明瞭になります。参考: http://www.sekaihaasobiba.com/entry/2014/10/24/204024
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/01_What_is_Blender_What_is_Add-on.md:18:243
v
17.
18. Blenderは元々オランダで開発されていたレンダリングソフトでした。現在はオープンソース化され、3Dモデリングからマテリアル設定・アニメーション制作など、3DCG制作に必要なほとんどの作業をBlenderだけで行うことができるなど高機能化しています。さらに最近ではゲームエンジン機能も強化されるなど、Blenderを用いてインタラクティブなコンテンツを制作することができるようになってきています。Blenderの開発は現在も活発であることから、今後の発展が非常に楽しみなソフトの1つであると言えます。
19.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/01_What_is_Blender_What_is_Add-on.md:47:106
v
46.
47. またBlenderはPythonのスクリプトエンジンを内蔵し、Python向けのAPIをユーザに公開しているため、Blender本体のソースコードを読むことなく、提供されているAPIを使ってユーザが新機能を作成することができます。
48.
^
ja-no-redundant-expression: "公表を行う"は冗長な表現です。"公表する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/01_What_is_Blender_What_is_Add-on.md:58:293
v
57. アドオンはプラグイン（plugin）やスクリプト（script）と呼ばれることもあります。
58. プラグインとアドオンは同じような意味で使う方が多いようですが、元から存在するBlender本体に対して新たな機能を追加（on＝プログラムの上に機能を載せる）するための小さなプログラムという意味ではアドオンの方が正しいです。また、Blender内では一貫してアドオンと呼んでいることから、本書でもアドオンと呼ぶことにします。なおプラグインは、プログラム本体の機能を差し替える（in＝プログラムの中に入れて機能を差し替える）ためのアプリケーションコードのことを指すため、厳密にはアドオンとは異なります。Blenderは開発者に向けてBlender本体の動作自体を変えるための手順の規格化や公表を行っていないので、Blenderプラグインは存在しません。
59. スクリプトは、ソースコードを記述したらすぐに実行できるプログラムのことを指すため、曖昧になりがちなアドオンとプラグインに比べて明らかに用語の意味が異なります。
^
✓ ja-no-redundant-expression: "することができるBlender"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/01_What_is_Blender_What_is_Add-on.md:87:28
v
86.
87. <div id="space_page"></div>
88.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/02_Use_Blender_Add-on.md:43:65
v
42.
43. |<div id="box">3</div>|*International Fonts* にチェックを入れると、UIの言語を変更することができるようになります。||
44. |---|---|---|
^
✓ ja-no-redundant-expression: "することができる。"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/02_Use_Blender_Add-on.md:280:40
v
279.
280. * Blenderは標準で日本語をサポートするため、必要に応じてUIを日本語化することができる。
281. * Blenderのアドオンは、アドオンの品質や将来性を示すサポートレベルで分類できる。
^
ja-no-redundant-expression: "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/03_Prepare_Add-on_development_environment.md:19:29
v
18.
19. アドオンを開発しやすくするために、Blenderのエリア設定を行います。ここで示しているエリア設定は筆者の好みがそのまま反映されているため、各自作業しやすい環境に設定してください。
20.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/03_Prepare_Add-on_development_environment.md:66:28
v
65.
66. Blenderはアプリケーション内で複数のエリアに分割することができます。エリアを分割することで、他のエリアで作業したい時に毎回エリアを変更する必要が無くなります。
67.
^
ja-no-redundant-expression: "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/03_Prepare_Add-on_development_environment.md:68:6
v
67.
68. アドオンの開発を行いやすくするため、ここでは以下のようにエリアを分割します。
69.
^
✓ ja-no-redundant-expression: "することができる開発"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/03_Prepare_Add-on_development_environment.md:399:42
v
398. * Blenderのエリア分割機能を利用することで、複数のエリアの状態を同時に確認することができる
399. * 開発環境の整備が終わったら、スタートアップファイルとして保存することを忘れないようにしよう
400. * スタートアップファイルを保存した後でも、ダウンロード時の初期状態に戻すことができる
^
✓ ja-no-redundant-expression: "することができませ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:45:83
v
44.
45. Blenderにはアドオンのインストール機能が備わっています。アドオンをインストールするための標準的な方法ですが、アドオンのソースコードの構成によってはインストールすることができません。ソースコードが単一のファイルで構成されている場合は問題なくインストールできますが、ソースコードが複数のファイルで構成されている場合は、 ```__init__.py``` が置かれたディレクトリが **zip形式で圧縮されている** 必要があります。
46.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:101:67
v
100.
101. Blenderにインストール済のアドオンが配置されているアドオン用フォルダにソースコードを直接配置することで、アドオンをインストールすることができます。この方法では、単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、インストールすることができます。
102.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:101:129
v
100.
101. Blenderにインストール済のアドオンが配置されているアドオン用フォルダにソースコードを直接配置することで、アドオンをインストールすることができます。この方法では、単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、インストールすることができます。
102.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:146:54
v
145.
146. アドオンをインストールした時と同様、Blenderのアドオンインストール機能を用いてアドオンをアップデートすることができます。インストール時と同様、アドオンのソースコードが複数のファイルで構成されている場合は、 ```__init__.py``` が置かれたディレクトリがzip形式で圧縮されている必要があります。
147.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:153:67
v
152.
153. Blenderアドオン用フォルダに配置されているアップデートするアドオンのソースコードを直接置き換えることで、アドオンをアップデートすることができます。インストール時と同様、単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、アップデートすることができます。
154.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:153:133
v
152.
153. Blenderアドオン用フォルダに配置されているアップデートするアドオンのソースコードを直接置き換えることで、アドオンをアップデートすることができます。インストール時と同様、単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、アップデートすることができます。
154.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:160:254
v
159.
160. 方法2では、複数のソースコードから構成されるアドオンをアップデートする度に毎回Blenderを再起動する必要があります。このため、ソースコードの一部を修正してBlenderに反映することが多いアドオン開発時では、ソースコードを修正するたびにBlenderを再起動する必要があり手間がかかります。この煩わしさを解決してくれるのが、Blenderが標準で持っている『Reload Scripts』機能です。『Reload Scripts』機能を利用することで、Blenderを再起動せずにアドオンをアップデートすることができます。
161.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:221:62
v
220.
221. アドオンのインストール/アップデートと同様、Blenderのアドオンアンインストール機能を用いてアドオンをアンインストールすることができます。アドオンのソースコードが単一のファイルで構成されているか、複数のファイルで構成されているかにかかわらずアンインストールできますが、最初からBlenderにインストールされているアドオン（アドオンのサポートレベルがReleaseまたはContrib）は削除することができません。
222.
^
✓ ja-no-redundant-expression: "することができませ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:221:199
v
220.
221. アドオンのインストール/アップデートと同様、Blenderのアドオンアンインストール機能を用いてアドオンをアンインストールすることができます。アドオンのソースコードが単一のファイルで構成されているか、複数のファイルで構成されているかにかかわらずアンインストールできますが、最初からBlenderにインストールされているアドオン（アドオンのサポートレベルがReleaseまたはContrib）は削除することができません。
222.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:278:43
v
277.
278. アドオン用フォルダに配置されているソースコードを直接削除することで、アンインストールすることができます。アドオンのソースコードが単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、アンインストールすることができます。また、最初からBlenderにインストールされているアドオン（アドオンのサポートレベルがReleaseまたはContrib）についても削除することができます。
279.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:278:112
v
277.
278. アドオン用フォルダに配置されているソースコードを直接削除することで、アンインストールすることができます。アドオンのソースコードが単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、アンインストールすることができます。また、最初からBlenderにインストールされているアドオン（アドオンのサポートレベルがReleaseまたはContrib）についても削除することができます。
279.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_01/04_Understand_Install_Uninstall_Update_Add-on.md:278:191
v
277.
278. アドオン用フォルダに配置されているソースコードを直接削除することで、アンインストールすることができます。アドオンのソースコードが単一のファイルで構成されているか複数のファイルで構成されているかにかかわらず、アンインストールすることができます。また、最初からBlenderにインストールされているアドオン（アドオンのサポートレベルがReleaseまたはContrib）についても削除することができます。
279.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:25:55
v
24. 実際にアドオンを開発する時も、仕様を最初に明確化しておくことが重要です。
25. アドオンの仕様を最初に決めることで、アドオンで何を実現すればよいか、そして実現にあたり何が課題となるかを整理することができます。
26.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:131:25
v
130.
131. 以下のコードにより、bpyモジュールをインポートすることができます。
132.
^
ja-no-redundant-expression: "修正を行う"は冗長な表現です。"修正する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:237:106
v
236.
237. 正式リリース前はメジャーバージョンを ```0``` とし、アップデートの度にマイナーバージョンを増やします。メジャーバージョンは正式リリース時に ```1``` とし、以降はアドオンのUIなどに影響する大きな修正を行う時に増やします。機能追加などの修正の場合は正式リリース前と同様に、マイナーバージョンを増やしていきます。なおメジャーバージョンを増やした時は、マイナーバージョンを ```0``` に戻します。
238.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:266:112
v
265.
266. アドオンのチュートリアルなど、アドオンに関するドキュメントが存在するWebページのURLを指定します。Blender公式のWikiページにアドオンのドキュメントを公開している場合は、Blender公式のWikiページを指定することができます。
267.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:331:53
v
330.
331. *ユーザ設定* ウィンドウでは、インストールされたアドオンについてサポートレベルでフィルタリングして表示することができます。例えば *ユーザ設定* ウィンドウの *サポートレベル* にて *テスト中* ボタンのみを選択状態にすることで、 ```support``` に ```TESTING``` が設定されたアドオンのみを表示することができます。
332.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:331:165
v
330.
331. *ユーザ設定* ウィンドウでは、インストールされたアドオンについてサポートレベルでフィルタリングして表示することができます。例えば *ユーザ設定* ウィンドウの *サポートレベル* にて *テスト中* ボタンのみを選択状態にすることで、 ```support``` に ```TESTING``` が設定されたアドオンのみを表示することができます。
332.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:358:22
v
357.
358. アドオン開発者は新しいカテゴリを自由に追加することができますが、独自のカテゴリの追加はユーザを混乱させる原因にもなるので、可能な限り既存のカテゴリに含めるように心がけましょう。実際、既存のカテゴリだけでも十分網羅できているはずですので、よほどのことがない限り新たにカテゴリを作る必要はないと思います。
359.
^
ja-no-redundant-expression: "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:369:23
v
368.
369. アドオンからBlenderに対して何かしらの操作を行うためには、 **オペレータクラスを作成し具体的な処理を定義する** 必要があります。オペレータクラスは、bpyモジュールが提供するクラスである、 ```bpy.types.Operator``` を継承して作成します。
370.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:390:86
v
389.
390. |```bl_idname``` 、 ```bl_label``` 、 ```bl_description``` に指定した値は、図のように追加したメニューの項目から確認することができます。||
391. |---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:442:54
v
441. BlenderのAPIリファレンスから探しても良いですが、本APIについてはもっと簡単に調べる方法があります。
442. Blenderではメニューやボタンをマウスオーバーすることで、メニューを実行した時に呼び出される関数を表示することができます。このため、*3Dビュー* エリアのメニューの *追加* > *メッシュ* > *ICO球* にマウスカーソルを置くことで、ICO球を生成する関数を確認することができます。
443. この方法で確認することができるのはメニューなどで提供される機能に限りますが、非常に手軽にAPIを確認できるため覚えておいて損はないでしょう。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:442:139
v
441. BlenderのAPIリファレンスから探しても良いですが、本APIについてはもっと簡単に調べる方法があります。
442. Blenderではメニューやボタンをマウスオーバーすることで、メニューを実行した時に呼び出される関数を表示することができます。このため、*3Dビュー* エリアのメニューの *追加* > *メッシュ* > *ICO球* にマウスカーソルを置くことで、ICO球を生成する関数を確認することができます。
443. この方法で確認することができるのはメニューなどで提供される機能に限りますが、非常に手軽にAPIを確認できるため覚えておいて損はないでしょう。
^
✓ ja-no-redundant-expression: "することができるの"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:443:8
v
442. Blenderではメニューやボタンをマウスオーバーすることで、メニューを実行した時に呼び出される関数を表示することができます。このため、*3Dビュー* エリアのメニューの *追加* > *メッシュ* > *ICO球* にマウスカーソルを置くことで、ICO球を生成する関数を確認することができます。
443. この方法で確認することができるのはメニューなどで提供される機能に限りますが、非常に手軽にAPIを確認できるため覚えておいて損はないでしょう。
444. 
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:470:97
v
469.
470. ```self.layout.operator()``` 関数の引数に ```CreateObject.bl_idname```を指定することで、作成したオペレータクラスの処理をメニューに登録することができます。
471.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:480:127
v
479.
480. ```bpy.utils.register_module()``` 関数 は、引数に指定したモジュールを登録してBlender内で使えるようにするための関数です。引数に ```__name__``` を指定することで、ファイル内の全てのモジュールを登録することができます。
481.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:482:129
v
481.
482. ```bpy.types.INFO_MT_mesh_add.append()``` 関数に、メニューを構築する関数である ```menu_fn()``` 関数を指定することで、*3Dビュー* エリアのメニューである *追加* > *メッシュ* に項目を追加することができます。
483.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:486:123
v
485.
486. bpy.types.INFO_MT_mesh_addは、bpy.types.INFO_MT_mesh_add.append()関数を確認した時と同様に、*3Dビュー* エリアのメニュー *追加* > *メッシュ* をマウスオーバーすることで確認することができます。
487. ここで、もしマウスオーバーした際にサブメニューが開いてしまって確認できない場合は、キーボードの左キーを押すことで確認することができるようになります。
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:487:59
v
486. bpy.types.INFO_MT_mesh_addは、bpy.types.INFO_MT_mesh_add.append()関数を確認した時と同様に、*3Dビュー* エリアのメニュー *追加* > *メッシュ* をマウスオーバーすることで確認することができます。
487. ここで、もしマウスオーバーした際にサブメニューが開いてしまって確認できない場合は、キーボードの左キーを押すことで確認することができるようになります。
488.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:497:132
v
496.
497. ```bpy.types.INFO_MT_mesh_add.remove()``` 関数に、メニューを構築する関数である ```menu_fn()``` 関数を指定することで、*3Dビュー* エリアのメニューである *追加* > *メッシュ* からメニューを削除することができます。
498.
^
ja-no-redundant-expression: "構築を行う"は冗長な表現です。"構築する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:534:56
v
533. * アドオンの処理は、```bpy.types.Operation``` クラスを継承したオペレータクラスの ```execute()``` メソッドに記述する
534. * ```register()``` 関数はアドオン有効化時に呼ばれる関数であり、モジュールの登録やメニューの構築を行う処理を記述する
535.
^
ja-no-redundant-expression: "破棄を行う"は冗長な表現です。"破棄する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/01_Basic_of_Add-on_Development.md:540:62
v
539.
540. * ```unregister()``` 関数はアドオン無効化時に呼ばれる関数であり、モジュールの削除や構築したメニューの破棄を行う処理を記述する
541. * *テキストエディター* からスクリプトを実行した時に呼ばれるメイン処理はアドオンでは不要であるが、慣習として書くことが多い
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:131:149
v
130.
131. ```execute()``` メソッドに渡されてくる引数については、[2-1節](01_Basic_of_Add-on_Development.md) で説明しましたので、引数の詳細についての説明はここでは省略します。引数 ```context``` から、現在のコンテキスト（実行状態）を取得することができます。
132.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:133:127
v
132.
133. 現在選択されているオブジェクトである ```context.active_object``` を ```active_obj``` に一度保存し、 ```active_obj.scale``` を2倍にすることで取得したオブジェクトのサイズを2倍に拡大することができます。
134.
^
ja-no-redundant-expression: "オペレーションを実行"は冗長な表現です。"オペレーションする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:135:41
v
134.
135. その後 ```self.report()``` メソッドを用いて、ユーザに対してオペレーションを実行した後に、オブジェクトを拡大・縮小したことがわかるようなメッセージをスクリプト実行ログに出力します。ここで、```execute()``` メソッドの引数である ```self``` は、オブジェクトのインスタンスです。
136.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:144:43
v
143.
144. 表示したいメッセージの内容に応じてメッセージの種類を指定し、スクリプト実行ログへ出力することができます。出力メッセージの種類には例えば以下のようなものがあります。
145.
^
✓ ja-no-redundant-expression: "することができる登録"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:285:35
v
284. * ```self.report()``` メソッドを利用することで、スクリプト実行ログにメッセージを出力することができる
285. * 登録したオペレータクラスの ```bl_idname``` は ```bpy.ops.<bl_idname>``` に登録される
286. * Pythonコンソールを利用して、APIの確認や簡単なテストを行うことができる
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/02_Register_Multiple_Operation_Classes.md:286:30
v
285. * 登録したオペレータクラスの ```bl_idname``` は ```bpy.ops.<bl_idname>``` に登録される
286. * Pythonコンソールを利用して、APIの確認や簡単なテストを行うことができる
287.
^
ja-no-redundant-expression: "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/03_Use_Property_on_Tool_Shelf_1.md:26:14
v
25.
26. Blenderでは何かしら操作を行う度に、直前の操作に対するパラメータ設定のためのUI（本書ではオプションと呼びます）がツール・シェルフの下側に表示されます。**直前に行った操作に対し、パラメータを調節して再度操作を実行** する時に使用します。
27.
^
ja-no-redundant-expression: "操作を実行"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/03_Use_Property_on_Tool_Shelf_1.md:26:106
v
25.
26. Blenderでは何かしら操作を行う度に、直前の操作に対するパラメータ設定のためのUI（本書ではオプションと呼びます）がツール・シェルフの下側に表示されます。**直前に行った操作に対し、パラメータを調節して再度操作を実行** する時に使用します。
27.
^
✓ ja-no-redundant-expression: "することができるオペレータ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/03_Use_Property_on_Tool_Shelf_1.md:189:50
v
188. * ユーザが直前に実行した操作に対して、ツール・シェルフのオプションからパラメータを調整して再実行することができる
189. * オペレータクラスのクラス変数にプロパティクラスを追加することで、ツール・シェルフのオプションによる処理の制御が可能となる
190. * ツール・シェルフのオプションに指定した値を変更すると、値を変更するたびにオペレータクラスの ```execute()``` メソッドが実行される
^
ja-no-redundant-expression: "することが可能な"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/04_Use_Property_on_Tool_Shelf_2.md:107:48
v
106.
107. ```EnumProperty``` クラスを用いると、ユーザがセレクトボックスにより値を選択することが可能なUIを作成することできます。```EnumProperty``` クラスを用いてセレクトボックスに選択項目を追加するためには、```EnumProperty``` クラス作成時の引数 ```items``` に選択項目のリストを渡す必要があります。
108.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/04_Use_Property_on_Tool_Shelf_2.md:146:85
v
145.
146. このように、セレクトボックスの選択項目リストを返す関数を ```EnumProperty``` クラスの ```items``` に指定することで、選択項目を動的に追加することができます。
147.
^
ja-no-redundant-expression: "調整を行う"は冗長な表現です。"調整する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/04_Use_Property_on_Tool_Shelf_2.md:184:42
v
183.
184. ツール・シェルフのプロパティを用いると、直前に行った操作に対してユーザがより細かい調整を行った上で操作を再実行することができます。ただし特定の機能に対してプロパティを追加しすぎると、指示できる項目が多すぎてかえってわかりづらくなるという問題もありますので、本当に必要な項目かどうかを見極めてプロパティを追加していきましょう。
185.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/04_Use_Property_on_Tool_Shelf_2.md:184:56
v
183.
184. ツール・シェルフのプロパティを用いると、直前に行った操作に対してユーザがより細かい調整を行った上で操作を再実行することができます。ただし特定の機能に対してプロパティを追加しすぎると、指示できる項目が多すぎてかえってわかりづらくなるという問題もありますので、本当に必要な項目かどうかを見極めてプロパティを追加していきましょう。
185.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/05_Create_Sub-menu.md:56:122
v
55.
56. |<div id="box">2</div>|[2-4節](04_Use_Property_on_Tool_Shelf_2.md) と同様、複製されたオブジェクトの拡大率・回転角度・配置先を *ツール・シェルフ* の *オプション* から変更することができます。||
57. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/05_Create_Sub-menu.md:106:208
v
105.
106. これまでオペレータクラスをメニューに追加する時は ```self.layout.operator()``` 関数を利用していましたが、メニュークラスをメニューに追加する場合は ```self.layout.menu()``` 関数を利用します。```self.layout.menu()``` 関数にメニュークラスのクラス変数 ```bl_idname``` を引数として渡すことで、メニューをメニューの項目に追加することができます。
107.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/05_Create_Sub-menu.md:131:179
v
130.
131. サブメニュー登録時に ```self.layout.operator()``` 関数の代わりに ```self.layout.menu()``` 関数を用い、サブメニュー用に作成したメニュークラスのクラス変数 ```bl_idname``` を指定します。そしてサブメニュー用に作成したクラスの中で、オペレータクラスを登録することで、3階層のメニューを作成することができます。
132.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/05_Create_Sub-menu.md:139:57
v
138.
139. サブメニューを用いることで、本節のサンプルのように処理対象を選択できるようにしたり、メニュー項目を機能ごとに整理することができるようになります。ぜひここでサブメニューの作り方を習得し、わかりやすいUI作りに活かしましょう。
140.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/06_Allocate_Shortcut_Keys.md:80:120
v
79.
80. 本節のサンプルは、*shift* + *ctrl* + *R* キーが押された時にイベントを発生させ、オブジェクトの複製の処理をイベント発生時に実行するように引数を指定しています。イベント発生時に引数 ```idname``` に指定した処理を実行しますが、引数 ```value``` には例えば以下のようなイベントを発生する時の条件値を指定できます。
81.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/06_Allocate_Shortcut_Keys.md:107:188
v
106.
107. Blenderでは既に多くの機能にショートカットキーが割当てられているため、単一のキーの中からショートカットキーとして何も割当たっていないキーを探すのは意外と大変です。このため、**ctrlキーやshiftキー、altキーとの組み合わせたショートカットキーを割り当てる** ことも検討しましょう。これらのキーと組み合わせることで、既に割り当てられているキーと被る可能性を低くすることができ、より簡単に空いているキーを見つけることができると思います。本節のサンプルでも、ctrlキーやaltキーを組み合わせたショートカットキーを登録しています。
108.
^
ja-no-redundant-expression: "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/06_Allocate_Shortcut_Keys.md:113:126
v
112.
113. [2-4節](04_Use_Property_on_Tool_Shelf_2.md) を改造し、*3Dビュー* エリアのメニューである *オブジェクト* > *選択オブジェクトの複製* にショートカットキーを割り当て、ショートカットキーからアドオンの機能を実行できるようにしました。ショートカットキーを機能に割り当てることで、ユーザが機能を素早く利用できるようになります。
114.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:9:108
v
8.
9. ###### BlenderのUIを自由に変えたいと思ったことはありませんか？実はBlenderのUIの大半はPythonで記載されているため、Pythonを理解できていればある程度自由にBlenderのUIを変更することができます。<br>本節は、アドオンの開発はしないけど自分の好みのUIへ改造したい、という方にも参考になると思います。
10.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:158:59
v
157.
158. 他にもクラス変数 ```bl_space_type``` には、Blenderのエリアに対応した以下のような値を指定することができます。
159.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:184:44
v
183.
184. クラス変数 ```bl_region_type``` には、他にも以下のような値を設定することが可能です。
185.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:207:81
v
206.
207. 本節のサンプルでは、*オブジェクトモード* 時かつオブジェクトが選択されている時のみタブが表示される仕様としていました。特定の状況下でのみメニューを表示したり、処理を実行させるようにしたりするためには ```poll()``` メソッドとクラス変数 ```bl_context``` 活用します。
208.
^
ja-no-redundant-expression: "することが可能な"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:209:29
v
208.
209. ```bl_context``` はパネルクラス時に指定することが可能なクラス変数で、**指定したコンテキストである時のみパネルの描画処理を実行します。** ```bl_context``` には以下のような値を設定することができます。
210.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:209:109
v
208.
209. ```bl_context``` はパネルクラス時に指定することが可能なクラス変数で、**指定したコンテキストである時のみパネルの描画処理を実行します。** ```bl_context``` には以下のような値を設定することができます。
210.
^
ja-no-redundant-expression: "説明を行う"は冗長な表現です。"説明する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:275:96
v
274.
275. BlenderのUIを変更すると聞くと難しそうに思えますが、Pythonさえ理解できていればなんとかなりそうだと、ここまでの説明を読んだ方であれば思えてきたのではないでしょうか？なお、UIの説明を行っている [2-9節](09_Control_Blender_UI_2.md) と [2-10節](10_Control_Blender_UI_3.md) の内容も一緒に理解すれば、Blenderで実現可能な大半のUIを自由に扱えるようになったと言ってよいと思います。
276.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:288:22
v
287. * ツール・シェルフのタブを追加するためには、```bpy.types.Panel``` クラスを継承したパネルクラスを作成し、クラス変数 ```bl_region_type``` に ```TOOLS``` を指定する必要がある
288. * 特定の状況下でのみメニューを表示したり処理を実行を禁止したりと、定義した処理に制限をかける場合は ```poll()``` メソッドを使用する
289. * パネルクラスのクラス変数 ```bl_context``` を宣言することで、描画するコンテキストを指定することができる
^
✓ ja-no-redundant-expression: "することができるツール・シェルフ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/08_Control_Blender_UI_1.md:290:26
v
289. * パネルクラスのクラス変数 ```bl_context``` を宣言することで、描画するコンテキストを指定することができる
290. * ツール・シェルフに追加したタブのヘッダーのUIを変更するためには、パネルクラスに ```draw_header()``` メソッドを定義する
291. * ツール・シェルフに追加したタブのメニューのUIを変更するためには、パネルクラスに ```draw()``` メソッドを定義する
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:78:65
v
77.
78. |<div id="box">3</div>|*一行に表示するアイコン数* の値を変えることで、一行に表示するアイコンの数を変更することができます。||
79. |---|---|---|
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:117:35
v
116.
117. ボタンは ```layout.operator()``` 関数で追加することができ、以下の引数を指定します。ボタンを押すと、```layout.operator()``` 関数の第1引数に指定したオペレータクラスの ```bl_idname``` を持つオペレータクラスの処理が実行されます。
118.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:136:207
v
135.
136. [2-5節](05_Create_Sub-menu.md) で説明したサブメニューを追加するための関数 ```layout.menu()``` により、メニューを追加します。追加したメニューは、セレクトボックスのUIとなります。表示されるメニュー名は、デフォルトで第1引数に指定したメニュークラスの ```bl_label``` が表示されますが、```text``` 引数に表示したい文字列を指定することで変更することができます。
137.
^
ja-no-redundant-expression: "定義を行う"は冗長な表現です。"定義する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:145:22
v
144.
145. プロパティを追加するためには、プロパティの定義を行う必要があります。
146.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:190:110
v
189.
190. なお、```operator()``` の代わりに ```label()``` 関数、 ```prop()``` 関数や ```menu()``` 関数を使うことによって、ラベル、プロパティやメニューを一行に並べて配置することができます。
191.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:194:47
v
193.
194. ```layout.operator()``` 関数を複数回実行することでボタンを一列に配置することができますが、隙間が広く気に入らない方もいると思います。隙間を縮めた状態でボタンを縦に並べるためには、```layout.column()``` 関数を使って列成分を取得し、取得した列成分に対して ```operator()``` 関数を使ってボタンを配置します。
195.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:206:111
v
205.
206. なお、```operator()``` 関数の代わりに ```label()``` 関数、```prop()``` 関数や ```menu()``` 関数を使うことによって、ラベル、プロパティやメニューを一列に並べて配置することができます。
207.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:213:98
v
212.
213. ```layout.column()``` 関数や ```layout.row()``` 関数で取得した行成分や列成分に対してさらに行成分や列成分を取得することで、より複雑なボタンの配置を実現することができます。
214.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:222:46
v
221.
222. ```layout.row()``` 関数を用いて行成分を取得することで一行にボタンを配置することができますが、ボタンはすべて等幅になっていました。ボタンの横幅を変えたい時は、```layout.split()``` 関数を用いて領域を分割します。
223.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:233:95
v
232.
233. ```layout.split()``` 関数により分割した領域の変数 ```split``` に対して ```split.split()``` 関数を実行することで、2つ以上の領域に分割することができます。なお、```split.split()``` 関数に指定する引数 ```percentage``` について注意が必要です。
234. 最初の領域分割で ```layout.split()``` 関数を実行する時は、引数に指定した ```percentage``` がツール・シェルフの横幅に対する割合を示しますが、2回目の領域分割で```split.split()``` 関数を実行した時は、```layout.split()``` で分割した残りの領域、つまり本節のサンプルではツール・シェルフの横幅 70% の領域に対する割合を指定します。同様に3回目の領域分割では、2回目に分割した残りの領域に対する割合を指定します。従って、ツール・シェルフに対する横幅はそれぞれ、**領域1で 30%、領域2で 70% × 0.7 = 49% 、領域3で 70% × 0.3 = 21%** となります。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:264:63
v
263.
264. 本節のサンプルでは、以下のコードにより4つのボタンをグループ化しています。グループ内のUIは、通常のUIと同様のコードで構築することができます。
265.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:271:87
v
270.
271. [2-3節](../chapter_02/03_Use_Property_on_Tool_Shelf_1.md) で説明したツール・シェルフのオプションのUIもカスタマイズすることができます。
272.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:281:180
v
280.
281. 利用可能なアイコンの識別子一覧は、```bpy.types.UILayout.bl_rna.functions['prop'].parameters['icon'].enum_items.keys()``` により取得できます。取得したアイコンの識別子を、```row.label()``` 関数の引数 ```icon``` に指定することで、アイコンを表示することができます。本節のサンプルでは、今後アドオンを作る人がアイコンを作る時の参考になるように、アイコンと識別子の対応関係がわかるようにしています。このため、引数 ```text``` にアイコンの識別子を代入して表示しています。また見やすさを考慮し、一行に表示可能なアイコンの数をオプションから指定することができます。ぜひ活用してください。
282.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:281:331
v
280.
281. 利用可能なアイコンの識別子一覧は、```bpy.types.UILayout.bl_rna.functions['prop'].parameters['icon'].enum_items.keys()``` により取得できます。取得したアイコンの識別子を、```row.label()``` 関数の引数 ```icon``` に指定することで、アイコンを表示することができます。本節のサンプルでは、今後アドオンを作る人がアイコンを作る時の参考になるように、アイコンと識別子の対応関係がわかるようにしています。このため、引数 ```text``` にアイコンの識別子を代入して表示しています。また見やすさを考慮し、一行に表示可能なアイコンの数をオプションから指定することができます。ぜひ活用してください。
282.
^
✓ ja-no-redundant-expression: "することができる本節"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/09_Control_Blender_UI_2.md:323:10
v
322. * Blenderが提供するUI部品は、メニュークラスやパネルクラス、オペレーションクラスが持つメンバ変数 ```layout``` を用いて配置することができる
323. * 本節のサンプルはアドオンから利用可能なアイコンの一覧を表示する機能を持つため、アドオン開発時に使いたいアイコンを調べたいときに活用できる
324.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:108:43
v
107.
108. |<div id="box">3</div>|ダイアログメニュー上のプロパティは変更することができます。||
109. |---|---|---|
^
ja-no-redundant-expression: "操作を実行"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:177:20
v
176.
177. *確認ポップアップ* ボタンを押すと、操作を実行するか中断するかを問うポップアップが表示されます。
178.
^
ja-no-redundant-expression: "操作を実行"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:195:24
v
194.
195. |<div id="box">2</div>|操作を実行するか中断するかを問うポップアップが表示されるので、*確認ポップアップ* をクリックします。||
196. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:277:47
v
276.
277. |<div id="box">3</div>|*項目1*・*項目2*・*項目3*の中から検索することができます。||
278. |---|---|---|
^
ja-no-redundant-expression: "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:322:354
v
321.
322. ```invoke()``` メソッドは、処理が実行された時に呼ばれるメソッドです。```execute()``` メソッドも処理が実行された時に呼ばれますが、```execute()``` メソッドの引数にはなかったイベント ```event``` を受け取る点が異なります。[3-1節](../chapter_03/01_Handle_Mouse_Click_Event.md) でも説明しますが、引数 ```event``` には ```invoke()``` メソッドが呼ばれた時のマウスの位置や発生したキーイベントなどの情報が含まれています。また、```invoke()``` と ```execute()``` が2つ定義されていた場合、メニューの項目を選択した時やボタンを押したなどのUIから操作を行うと ```invoke()``` が優先的に呼ばれます。一方、[2-2節](../chapter_02/02_Register_Multiple_Operation_Classes.md) で説明した ```bpy.ops.<オペレーションクラスのbl_idname>``` を実行すると ```execute()``` が呼び出されます。
323.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:324:48
v
323.
324. このようにユーザからの入力を積極的に使いたい場合や、```invoke()``` メソッドで前処理を行った後に ```bpy.ops.<オペレーションクラスのbl_idname>``` を実行じて ```excute()``` を呼び出したい場合に ```invoke()``` メソッドを利用します。
325.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:365:28
v
364. ```execute()``` メソッドでは、ダイアログメニューのプロパティに指定した値をスクリプト実行ログに出力します。
365. ダイアログメニューで指定したプロパティの値でアドオンの処理を実行したいときに活用しましょう。
366.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:393:22
v
392.
393. Blenderの機能の中には、実行する前に処理を実行するか中断するかを確認するためのポップアップを表示する機能があります。例えば、*情報* エリアのメニュー *ファイル* > *スタートアップファイルを保存* は、実行確認のポップアップを表示する例の1つです。
394.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:395:67
v
394.
395. 実行確認のポップアップは、```context.window_manager.invoke_confirm()``` 関数により表示することができます。
396.
^
✓ ja-no-redundant-expression: "することができる、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:418:5
v
417.
418. 値を変更することができる、プロパティ付きポップアップを作ることもできます。実行結果を見るとダイアログメニューと同じ動きに見えますが、ダイアログメニューは *OK* ボタンを押すまで処理が実行されないのに対し、**プロパティ付きポップアップではプロパティを変更するたびに処理が実行されます。**
419.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:425:101
v
424.
425. プロパティ付きポップアップは、```invoke()``` メソッド内から ```context.window_manager.invoke_props_popup()``` 関数を実行することで表示することができます。プロパティを変更すると ```execute()``` メソッドが実行され、 現在のプロパティの値がスクリプト実行ログに表示されます。
426.
^
ja-no-redundant-expression: "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:434:76
v
433.
434. なお、プロパティ付きポップアップで表示されたプロパティは、ツール・シェルフのオプションにも表示されているため、ポップアップが閉じてしまった場合でも他の操作を行わなわない限り変更することができます。
435.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:434:89
v
433.
434. なお、プロパティ付きポップアップで表示されたプロパティは、ツール・シェルフのオプションにも表示されているため、ポップアップが閉じてしまった場合でも他の操作を行わなわない限り変更することができます。
435.
^
✓ ja-no-redundant-expression: "することができる、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:443:18
v
442.
443. あらかじめ登録した項目の中から検索することができる、検索ウィンドウ付きのポップアップを表示することができます。実際このUIがどのように役立つのか、筆者もよくわかっていませんが、BlenderのAPIとして用意されているので紹介します。
444.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:443:46
v
442.
443. あらかじめ登録した項目の中から検索することができる、検索ウィンドウ付きのポップアップを表示することができます。実際このUIがどのように役立つのか、筆者もよくわかっていませんが、BlenderのAPIとして用意されているので紹介します。
444.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:479:68
v
478.
479. 本節で前編は終わりです。ここまで読まれた方であれば、アドオンを作るだけでなくPythonで書かれているBlenderのUIも自由に変更することができるようになっていることでしょう。後編では、より高度なアドオンを作りたい人向けの話題を取り上げます。
480.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:490:22
v
489. * オペレータクラスに定義する ```invoke()``` メソッドと ```execute()``` メソッドは、引数にイベント情報を受け取らない点で異なる
490. * メニューやボタンからオペレータクラスの処理を実行する場合は、```invoke()``` メソッドが優先的に実行される
491. * ```bpy.ops.<オペレーションクラスのbl_idname>``` オペレータクラスの処理を実行した場合は、```execute()``` メソッドが優先的に実行される
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/10_Control_Blender_UI_3.md:491:49
v
490. * メニューやボタンからオペレータクラスの処理を実行する場合は、```invoke()``` メソッドが優先的に実行される
491. * ```bpy.ops.<オペレーションクラスのbl_idname>``` オペレータクラスの処理を実行した場合は、```execute()``` メソッドが優先的に実行される
492. * UIの構築方法を知ることと、わかりやすいUIを構築することは別である。わかりやすいUIを構築するために他の方が作成したUIを参考にしよう
^
ja-no-redundant-expression: "解説を行う"は冗長な表現です。"解説する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_02/SUMMARY.md:9:45
v
8.
9. Blenderおよびアドオンの基礎知識を一通り習得したところで、本章からはアドオン開発の解説を行います。
10. サンプルを用いて解説しますので、理解を深めるために手を動かしながら読み進めてください。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/01_Handle_Mouse_Click_Event.md:112:186
v
111.
112. アドオン有効時に ```PointerProperty``` の引数 ```type``` へグループ化のために定義したクラス名を指定することで、```bpy.types.Scene.dfrc_props``` 変数にプロパティのグループを登録します。以降、各プロパティには ```bpy.types.Scene.dfrc_props.running``` 等でアクセスすることができます。
113.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/01_Handle_Mouse_Click_Event.md:240:81
v
239.
240. ```bpy.ops.view3d.select()``` 関数の引数 ```location``` にマウスの位置を指定することで、マウスの位置にある面を選択することができます。もしマウスの位置に面がなければ ```bpy.ops.view3d.select()``` 関数は ```{'PASS_THROUGH'}``` を返すため、マウスの位置に面がないことを出力した後に処理を終了します。
241.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/01_Handle_Mouse_Click_Event.md:274:105
v
273.
274. 最後に、```modal``` メソッドは ```{'PASS_THROUGH'}``` を返します。```{'PASS_THROUGH'}``` が返されるとイベントを本処理に閉じず、別の処理に対しても通知することができます。```{'PASS_THROUGH'}``` が指定されていないと、マウスやキーボードのイベントが発生した時に行う ```DeleteFaceByRClick``` の処理後にイベントが捨てられてしまい、マウスやキーボードからのイベントに対する他の処理が発生しなくなってしまいます。
275.
^
ja-no-redundant-expression: "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/01_Handle_Mouse_Click_Event.md:278:16
v
277.
278. プロパティパネルからアドオンの機能を実行開始した後はボタンを押すことができなくなり、処理を終えることができなくなります。これは ```DeleteFaceByRClick``` の ```modal()``` メソッドでイベントが捨てられ、他の処理へイベントが通知されていないことを示します。
279.
^
✓ ja-no-redundant-expression: "することができるプロパティパネル"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/01_Handle_Mouse_Click_Event.md:293:50
v
292. * ```bpy.types.PropertyGroup``` クラスを継承したクラスのクラス変数にプロパティクラスを指定することで、プロパティをグループ化することができる
293. * プロパティパネルへメニューを追加するためには、 ```bpy.types.Panel``` クラスを継承し、 ```draw()``` メソッド内でUIを定義する必要がある
294. * ```invoke()``` メソッドや ```execute()``` メソッドで ```{'RUNNING_MODAL'}``` を返すとモーダルモードへ移行し、登録されたモーダルクラスの ```modal()``` メソッドが実行される
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/02_Handle_Keyboard_Key_Event.md:73:85
v
72.
73. |<div id="box">2</div>|本節のサンプルの仕様で書いたように、オブジェクト並進移動モードではキーボードのキーの組み合わせによりオブジェクトを並進移動することができます。||
74. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:68:21
v
67.
68. 開始ボタンを押した後もオブジェクトを移動することができますが、タイマイベントを契機に元の場所に戻ります。
69.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:116:16
v
115.
116. 最後にモーダルモードへ移行する処理を行っていますが、必ずしも ```__handle_add()``` メソッドで行う必要はありません。```__handle_add()``` メソッド自体が ```invoke()``` メソッドから呼び出されているので、[3-1節](01_Handle_Mouse_Click_Event.md) や [3-2節](02_Handle_Keyboard_Key_Event.md) と同様、```invoke()``` メソッドの処理内で ```context.window_manager.modal_handler_add()``` 関数を呼んでモーダルモードへ移行しても良いです。
117.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:134:149
v
133.
134. [3-1節](01_Handle_Mouse_Click_Event.md) や [3-2節](02_Handle_Keyboard_Key_Event.md) と同様に ```modal()``` メソッドでは、*3Dビュー* エリアの画面更新と ```modal()``` メソッドの終了判定処理を行います。その後、オブジェクトの位置を更新します。
135.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:140:31
v
139.
140. 続いて、終了ボタンが押された時にオブジェクトの移動を停止する処理を実行します。終了ボタンが押された時は、オブジェクトの移動を停止する以外にもオブジェクトを開始ボタンが押された時の初期位置に移動させる必要があります。
141.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:151:137
v
150.
151. オブジェクトの初期位置はインスタンス変数 ```orig_obj_loc``` の値に保存されているため、オブジェクトの初期位置に移動先の位置を相対座標で加えることでオブジェクトの位置を更新します。オブジェクトの位置は ```obj.location``` から参照・変更することができます。
152.
^
✓ ja-no-redundant-expression: "することができるため"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:187:262
v
186.
187. *3Dビュー* エリアのプロパティパネルに追加した *一定間隔でオブジェクトを移動* パネルは、```poll()``` クラスメソッドで表示する条件を絞っています。本節のサンプルでは最低でも1つのメッシュ型のオブジェクトが選択され、かつオブジェクトモードの時にパネルを表示しています。オブジェクトの型がメッシュ型かつ選択された状態であるかを判定する方法は先ほど書きました。そして、現在のオブジェクトが *オブジェクトモード* と *エディットモード* のどちらの状態にあるのかは ```obj.mode``` により取得することができるため、先ほどのパネル表示条件を満たしたことを判定するコードは次のようになります。
188.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:191:67
v
190.
191. なお、```obj.mode``` には次のような値が設定されます。オブジェクトが現在どのようなモードであるかを確認したい場合に利用することができます。
192.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:212:59
v
211.
212. タイマのイベントを扱う方法を説明しました。タイマを使うと指定した間隔でイベントを発生させることができるため、定期的に処理を実行するような機能を実現することができます。
213.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/03_Handle_Timer_Event.md:212:74
v
211.
212. タイマのイベントを扱う方法を説明しました。タイマを使うと指定した間隔でイベントを発生させることができるため、定期的に処理を実行するような機能を実現することができます。
213.
^
ja-no-redundant-expression: "判定を行う"は冗長な表現です。"判定する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/04_Use_API_for_OpenGL.md:165:11
v
164.
165. 続いて表示する図形の判定を行った後、 ```bgl.glBegin()``` 関数により図形描画を開始します。```bgl.glBegin()``` の引数には描画モードを指定します。 ```bgl.GL_TRIANGLES``` を指定することで三角形の描画を、 ```bgl.GL_QUADS``` を指定することで四角形の描画を開始します。
166.
^
ja-no-redundant-expression: "判定を行う"は冗長な表現です。"判定する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/04_Use_API_for_OpenGL.md:196:11
v
195.
196. 最初に描画中か否かの判定を行った後、描画中であれば終了ボタンを、描画中でなければ開始ボタンを配置します。
197.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/04_Use_API_for_OpenGL.md:207:123
v
206.
207. 本節で紹介した ```bgl``` モジュールと [3.1節](01_Handle_Mouse_Click_Event.md) で紹介したマウスからのイベントを扱う方法を組み合わせることで、Blender専用のUIとは全く異なる独自のUIを構築することができます。
208.
^
ja-no-redundant-expression: "描画を行う"は冗長な表現です。"描画する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:9:60
v
8.
9. ###### [3-4節](04_Use_API_for_OpenGL.md) ではOpenGLのAPIを利用した図形描画を行う方法を説明しましたが、本節のサンプルではテキストを描画する方法を説明します。
10.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:128:157
v
127.
128. 現在開いているエリアの一覧は ```context.screen.areas``` に保持されているため、```get_region()``` スタティックメソッドの引数に指定したエリアのタイプ ```area_type``` と ```area.type``` が一致することを確認することで目的のエリアを取得することができます。本節のサンプルでは、```get_region()``` スタティックメソッドの引数 ```area_type``` に ```'VIEW_3D'``` が指定されているため、*3Dビュー* エリアを取得することができます。
129.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:128:269
v
127.
128. 現在開いているエリアの一覧は ```context.screen.areas``` に保持されているため、```get_region()``` スタティックメソッドの引数に指定したエリアのタイプ ```area_type``` と ```area.type``` が一致することを確認することで目的のエリアを取得することができます。本節のサンプルでは、```get_region()``` スタティックメソッドの引数 ```area_type``` に ```'VIEW_3D'``` が指定されているため、*3Dビュー* エリアを取得することができます。
129.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:130:52
v
129.
130. 取得したエリアから ```area.regions``` により、エリアを構成するリージョン一覧を取得することができます。エリアと同様に ```region.type``` と ```get_region()``` スタティックメソッドの引数 ```region_type``` が一致すれば、目的のリージョンを取得することができます。本節のサンプルでは、 ```get_region()``` スタティックメソッドの引数 ```region_type``` に ```'WINDOW'``` が指定されているため、ウィンドウリージョンを取得することができます。
131.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:130:159
v
129.
130. 取得したエリアから ```area.regions``` により、エリアを構成するリージョン一覧を取得することができます。エリアと同様に ```region.type``` と ```get_region()``` スタティックメソッドの引数 ```region_type``` が一致すれば、目的のリージョンを取得することができます。本節のサンプルでは、 ```get_region()``` スタティックメソッドの引数 ```region_type``` に ```'WINDOW'``` が指定されているため、ウィンドウリージョンを取得することができます。
131.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:130:272
v
129.
130. 取得したエリアから ```area.regions``` により、エリアを構成するリージョン一覧を取得することができます。エリアと同様に ```region.type``` と ```get_region()``` スタティックメソッドの引数 ```region_type``` が一致すれば、目的のリージョンを取得することができます。本節のサンプルでは、 ```get_region()``` スタティックメソッドの引数 ```region_type``` に ```'WINDOW'``` が指定されているため、ウィンドウリージョンを取得することができます。
131.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:135:101
v
134.
135. ウィンドウリージョンは、```get_region()``` スタティックメソッドの戻り値 ```region``` に保存されています。```region``` からは、リージョンに関する情報を取得することができます。本節のサンプルでは、作業時間を描画する座標を求めるために ```region``` を利用します。
136.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:137:175
v
136.
137. リージョンの左下の座標値が (x, y) = (0, 0) であることから、左上の座標は (x, y) = (0, リージョンの高さ) で求められそうです。```region``` はリージョンの高さや幅の情報を保持していて、```region.height``` でリージョンの高さを、```region.width``` でリージョンの幅を取得することができます。このため、リージョンの左上の座標は (x, y) = (0, region.height) で取得することができます。
138.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:137:234
v
136.
137. リージョンの左下の座標値が (x, y) = (0, 0) であることから、左上の座標は (x, y) = (0, リージョンの高さ) で求められそうです。```region``` はリージョンの高さや幅の情報を保持していて、```region.height``` でリージョンの高さを、```region.width``` でリージョンの幅を取得することができます。このため、リージョンの左上の座標は (x, y) = (0, region.height) で取得することができます。
138.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:183:151
v
182.
183. フォントIDはBlenderに読み込まれているフォントの識別子で、デフォルトのフォントには0が割り当てられています。好きなフォントに変えたい場合は、blf.load()関数を使ってフォントを読み込み、フォントIDにblf.load()の戻り値を指定することで、読み込んだフォントを使ってテキストを描画することができます。
184.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:204:42
v
203.
204. ```blf.shadow_offset()``` 関数により、影の表示位置も変更することができます。本節のサンプルでは、テキストの描画位置から右に2ピクセル、下に2ピクセルずらして影を表示するように設定しています。
205.
^
✓ ja-no-redundant-expression: "することができる "は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/05_Render_String_with_blf_Module.md:274:26
v
273. * Blenderで開いているエリア情報は、```context.screen.areas``` から取得することができる
274. * ```blf.enable()``` により描画するテキストにに様々な効果を付け加えることができるが、不要になった設定は ```blf.enable()``` 必ず無効化する必要がある
275.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:78:49
v
77.
78. |<div id="box">4</div>|*音量* の値を変更することで、再生中の音量を変更することができます。||
79. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:87:48
v
86.
87. |<div id="box">5</div>|*停止* ボタンをクリックすることで、再生を停止することができます。||
88. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:137:78
v
136.
137. サウンドデバイスとサウンドファクトリは、```aud.device()``` 関数および ```aud.Factory()``` 関数を実行することで作成することができます。```aud.device()``` 関数は引数が不要ですが、```aud.Factory()``` 関数は再生するオーディオファイルのパスを引数に指定する必要があります。サウンドデバイスは一度作成した後に再度作り直す必要はありませんが、サウンドファクトリは再生するオーディオファイルを変更する度に作成し直す必要があります。
138.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:175:64
v
174.
175. オーディオファイルの再生状態は、```AudioDevice.handle.status``` の値を参照することによって判断することができます。```AudioDevice.handle.status``` に設定される値を以下に示します。
176.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:185:264
v
184.
185. 本節のサンプルでは、*3Dビュー* エリアのツール・シェルフにある *オーディオ再生* パネルからユーザが音量を変更したこと検知し、即座にオーディオファイル再生へ反映しています。ここまで順を追って読み進めてきた方は、ふと疑問に思うかもしれません。[2-3節](../chapter_02/03_Use_Property_on_Tool_Shelf_1.md) で示したプロパティ値の設定直後に同じ処理を再実行するか、[3-4節](04_Use_API_for_OpenGL.md) で示したプロパティの値をユーザが設定した後に処理を行うかの2通りのパターンであったため、問題になることはありませんでした。しかし本節のサンプルでは、一度オーディオファイルを再生してしまうと再生処理がアドオンの処理とは非同期に行われてしまいます。つまり、プロパティの値を参照した後に処理を行うこれまでの方法ではうまくいかないのです。
186.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:185:382
v
184.
185. 本節のサンプルでは、*3Dビュー* エリアのツール・シェルフにある *オーディオ再生* パネルからユーザが音量を変更したこと検知し、即座にオーディオファイル再生へ反映しています。ここまで順を追って読み進めてきた方は、ふと疑問に思うかもしれません。[2-3節](../chapter_02/03_Use_Property_on_Tool_Shelf_1.md) で示したプロパティ値の設定直後に同じ処理を再実行するか、[3-4節](04_Use_API_for_OpenGL.md) で示したプロパティの値をユーザが設定した後に処理を行うかの2通りのパターンであったため、問題になることはありませんでした。しかし本節のサンプルでは、一度オーディオファイルを再生してしまうと再生処理がアドオンの処理とは非同期に行われてしまいます。つまり、プロパティの値を参照した後に処理を行うこれまでの方法ではうまくいかないのです。
186.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:187:31
v
186.
187. 本節のサンプルのようにプロパティの値が変わったことを検知して処理を行いたい場合は、プロパティクラスを作成する時に引数 ```set``` と ```get``` に、プロパティが変わった時に実行する関数を登録する必要があります。音量を変更するプロパティの定義の処理を見てみましょう。
188.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:197:228
v
196.
197. ```get_volume()``` 関数は第1引数に ```bpy.context.scene``` が代入された状態で呼び出されます。```init_props()``` 関数で ```bpy.context.scene``` にプロパティクラスを登録したことから、プロパティクラスを登録した変数へは ```bpy.context.scene['paf_volume']``` つまり ```self['paf_volume']``` としてアクセスすることができます。
198.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:205:135
v
204.
205. ```set_volume()``` 関数は、```self['paf_volume'] = value``` によりプロパティの値を更新した後、```AudioDevice.handle.volume``` に値を設定することで音量を変更しています。このような一連の処理を行うことで、ユーザからのプロパティ変更を検知し、オーディオファイルの再生音量を変更することができます。
206.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:205:179
v
204.
205. ```set_volume()``` 関数は、```self['paf_volume'] = value``` によりプロパティの値を更新した後、```AudioDevice.handle.volume``` に値を設定することで音量を変更しています。このような一連の処理を行うことで、ユーザからのプロパティ変更を検知し、オーディオファイルの再生音量を変更することができます。
206.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:225:21
v
224. * サウンドハンドラはオーディオの再生制御を行うだけでなく、オーディオ再生の設定(音量やピッチなど)を参照/変更することができる
225. * プロパティクラスの値が参照された時に処理を実行したい場合は引数 ```get``` 、更新されたときに処理を実行したい場合は引数 ```set``` に処理を定義した関数を指定する
226.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:225:54
v
224. * サウンドハンドラはオーディオの再生制御を行うだけでなく、オーディオ再生の設定(音量やピッチなど)を参照/変更することができる
225. * プロパティクラスの値が参照された時に処理を実行したい場合は引数 ```get``` 、更新されたときに処理を実行したい場合は引数 ```set``` に処理を定義した関数を指定する
226.
^
✓ ja-no-redundant-expression: "することができるプロパティクラス"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/06_Play_Audio_File.md:225:57
v
224. * サウンドハンドラはオーディオの再生制御を行うだけでなく、オーディオ再生の設定(音量やピッチなど)を参照/変更することができる
225. * プロパティクラスの値が参照された時に処理を実行したい場合は引数 ```get``` 、更新されたときに処理を実行したい場合は引数 ```set``` に処理を定義した関数を指定する
226.
^
ja-no-redundant-expression: "登録を行う"は冗長な表現です。"登録する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/07_Multilingual_Support.md:200:6
v
199.
200. 翻訳辞書の登録を行うと、Blenderの言語設定に応じて自動翻訳関数で指定したキーに対応した文字列が表示されるようになります。このため、翻訳を行いたい箇所を自動翻訳関数 ```bpy.app.translations.pgettext()``` で置き換える必要があります。
201.
^
ja-no-redundant-expression: "翻訳を行う"は冗長な表現です。"翻訳する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/07_Multilingual_Support.md:200:69
v
199.
200. 翻訳辞書の登録を行うと、Blenderの言語設定に応じて自動翻訳関数で指定したキーに対応した文字列が表示されるようになります。このため、翻訳を行いたい箇所を自動翻訳関数 ```bpy.app.translations.pgettext()``` で置き換える必要があります。
201.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:174:8
v
173.
174. 最初に1と2の処理を行うコードを次に示します。
175.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:178:83
v
177.
178. オブジェクトの位置座標は、```bpy.data.objects``` の各要素から取得できるオブジェクトデータの ```location``` メンバ変数から取得することができます。続いて、オブジェクトの位置座標をリージョン座標に座標変換します。この座標変換を1から実装するとなると、カメラのビュー行列などを用いて行列計算を行う必要があります。幸いなことに ```bpy_extra``` モジュールの ```view3d_utils``` サブモジュールが提供するAPIを利用することで、この処理を比較的簡単な方法で実現することができます。本節のサンプルでは、オブジェクトの位置座標をリージョン座標に変換するために ```view3d_utils.location_3d_to_region_2d()``` 関数を呼び出します。```view3d_utils.location_3d_to_region_2d()``` 関数の引数を以下に示します。
179.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:178:263
v
177.
178. オブジェクトの位置座標は、```bpy.data.objects``` の各要素から取得できるオブジェクトデータの ```location``` メンバ変数から取得することができます。続いて、オブジェクトの位置座標をリージョン座標に座標変換します。この座標変換を1から実装するとなると、カメラのビュー行列などを用いて行列計算を行う必要があります。幸いなことに ```bpy_extra``` モジュールの ```view3d_utils``` サブモジュールが提供するAPIを利用することで、この処理を比較的簡単な方法で実現することができます。本節のサンプルでは、オブジェクトの位置座標をリージョン座標に変換するために ```view3d_utils.location_3d_to_region_2d()``` 関数を呼び出します。```view3d_utils.location_3d_to_region_2d()``` 関数の引数を以下に示します。
179.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:186:44
v
185.
186. 3Dリージョンデータは、スペースの ```region_3d``` メンバ変数から取得することができます。座標変換対象のリージョンとスペースは ```get_region_space``` スタティックメソッドで取得します。本節のサンプルでは、*3Dビュー* エリアのウィンドウリージョンを座標変換対象としたいため、リージョン ```WINDOW``` とスペース ```VIEW_3D``` を取得しています。```view3d_utils.location_3d_to_region_2d()``` 関数の第1引数に取得したリージョンを、第2引数にスペースの ```region_3d``` メンバ変数を、第3引数にオブジェクトデータの ```location``` メンバ変数を指定して呼び出すことで、座標変換後のリージョン座標を取得することができます。取得した情報は、```self.loc_history``` メンバ変数に保存します。```self.loc_history``` の各要素には、選択された全てのオブジェクトの位置情報を配列として保存されます。
187.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:186:371
v
185.
186. 3Dリージョンデータは、スペースの ```region_3d``` メンバ変数から取得することができます。座標変換対象のリージョンとスペースは ```get_region_space``` スタティックメソッドで取得します。本節のサンプルでは、*3Dビュー* エリアのウィンドウリージョンを座標変換対象としたいため、リージョン ```WINDOW``` とスペース ```VIEW_3D``` を取得しています。```view3d_utils.location_3d_to_region_2d()``` 関数の第1引数に取得したリージョンを、第2引数にスペースの ```region_3d``` メンバ変数を、第3引数にオブジェクトデータの ```location``` メンバ変数を指定して呼び出すことで、座標変換後のリージョン座標を取得することができます。取得した情報は、```self.loc_history``` メンバ変数に保存します。```self.loc_history``` の各要素には、選択された全てのオブジェクトの位置情報を配列として保存されます。
187.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/08_Use_Coordinate_Transformation_1.md:213:79
v
212. * ```bpy_extra``` モジュールは、 ```bpy``` モジュールだけで処理を実装すると面倒な処理を、開発者がAPI呼び出しだけで簡単に実現できるようにした、APIの集まりである
213. * ```bpy_extra``` モジュールのサブモジュールである ```view3d_utils``` サブモジュールは、*3Dビュー* エリア上で座標変換を行うためのAPIを提供する
214.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:107:109
v
106.
107. マウスカーソルのリージョン座標を取得するためのコードを次に示します。マウスカーソルのリージョン座標は、```mouse_region_x``` （X座標）と ```mouse_region_y``` （Y座標）で取得することができます。
108.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:118:101
v
117.
118. レイの発生源は、*3Dビュー* エリアの3D空間を映し出しているカメラの座標（視点）となるため、```view3d_utils.region_2d_to_origin_3d()``` 関数を使って取得することができます。一方レイの向きは、視点からマウスカーソルのリージョン座標を *3Dビュー* の3D空間座標に変換した座標の点への向きとなるため、```view3d_utils.region_2d_to_vector_3d()``` 関数を使って取得します。```view3d_utils.region_2d_to_vector_3d()``` 関数と ```view3d_utils.region_2d_to_origin_3d()``` 関数の引数は次に示すように、共に同じ引数を受け取ります。
119.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:155:117
v
154.
155. 本節のサンプルでは ```ray_cast()``` の処理を ```try``` ブロックで囲み、例外処理を実装しています。これはメッシュ型のオブジェクトを作成した時に、作成タイミングの問題で ```ray_cast()``` の処理を実行できない場合に例外が発生し、処理が中断してしまうことを避けるためです。この問題を避けるために ```ray_cast()``` 関数を実行するオブジェクトをメッシュ型に絞っていますが、ここまで対処してもタイミングによって時々例外が発生してしまうことから、安全面を重視して例外処理を追加しています。
156.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:208:9
v
207.
208. ## 自力で座標変換を行う
209.
^
✓ ja-no-redundant-expression: "することができなく"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:216:82
v
215.
216. リージョンやスペースの取得を ```get_region_and_space()``` 関数で行なっていますが、仮に指定したスペースが存在しなかった場合は座標変換することができなくなるため、何もせずにプログラムの実行を終了します。
217.
^
ja-no-redundant-expression: "計算を行う"は冗長な表現です。"計算する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:218:44
v
217.
218. 本節の冒頭でも書きましたが、ローカル座標からリージョン座標へ座標変換するためには以下の計算を行う必要があります。
219.
^
ja-no-redundant-expression: "計算を行う"は冗長な表現です。"計算する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:243:24
v
242.
243. ローカル座標からグローバル座標への変換は、次の計算を行います。
244.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:253:40
v
252.
253. グローバル座標変換行列は ```obj.matrix_world``` で取得することができ、グローバル座標変換行列に1で取得したローカル座標を掛けることでグローバル座標へ変換することができます。
254.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:253:89
v
252.
253. グローバル座標変換行列は ```obj.matrix_world``` で取得することができ、グローバル座標変換行列に1で取得したローカル座標を掛けることでグローバル座標へ変換することができます。
254.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:264:97
v
263.
264. ビュー変換行列と射影変換行列は、それぞれ ```space.region_3d.view_matrix``` と ```space.region_3d.window_matrix``` で取得することができます。しかしBlenderでは、射影変換行列とビュー変換行列を掛けた透視変換行列 ```space.region_3d.perspective_matrix``` を利用することができます。従って、上記の座標変換をコードにすると次のようになります。
265.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:264:189
v
263.
264. ビュー変換行列と射影変換行列は、それぞれ ```space.region_3d.view_matrix``` と ```space.region_3d.window_matrix``` で取得することができます。しかしBlenderでは、射影変換行列とビュー変換行列を掛けた透視変換行列 ```space.region_3d.perspective_matrix``` を利用することができます。従って、上記の座標変換をコードにすると次のようになります。
265.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:277:81
v
276.
277. Blenderは、適用されているビューポート変換行列を参照するためのAPIを提供していません。このため、ビューポート変換を自力で行う必要があります。ビューポート変換を行うために必要な情報は、リージョンの幅と高さです。リージョンの幅と高さは ```get_region_and_space()``` 関数で取得したリージョン情報 ```region``` から取得することができます。これらの情報と ```viewport_transform()``` 関数を用いて、ビューポート変換を行います。
278.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:277:182
v
276.
277. Blenderは、適用されているビューポート変換行列を参照するためのAPIを提供していません。このため、ビューポート変換を自力で行う必要があります。ビューポート変換を行うために必要な情報は、リージョンの幅と高さです。リージョンの幅と高さは ```get_region_and_space()``` 関数で取得したリージョン情報 ```region``` から取得することができます。これらの情報と ```viewport_transform()``` 関数を用いて、ビューポート変換を行います。
278.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:277:240
v
276.
277. Blenderは、適用されているビューポート変換行列を参照するためのAPIを提供していません。このため、ビューポート変換を自力で行う必要があります。ビューポート変換を行うために必要な情報は、リージョンの幅と高さです。リージョンの幅と高さは ```get_region_and_space()``` 関数で取得したリージョン情報 ```region``` から取得することができます。これらの情報と ```viewport_transform()``` 関数を用いて、ビューポート変換を行います。
278.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:289:65
v
288.
289. 最後に、自力で行った座標変換と ```view3d_utils``` を利用した場合と結果が一致することを確認します。自力で座標変換を行うスクリプトは ```transform_wo_view3d_utils.py``` ですが、```view3d_utils``` を利用して座標変換する場合のスクリプトを ```transform_w_view3d_utils.py``` として作成しました。
290.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:334:96
v
333.
334. サンプルのアドオンでは、```ray_cast()``` 関数を使ったレイとオブジェクトの交差判定も行いました。```ray_cast()``` は非常に便利な関数で、交差した面や位置も取得することができます。例えば、マウスでクリックした時にマウスカーソルの位置に穴を開けたり、マウスカーソルが重なっている面を強調表示といった処理も ```ray_cast()``` 関数を使って実装することができると思います。
335.
^
✓ ja-no-redundant-expression: "することができると"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:334:193
v
333.
334. サンプルのアドオンでは、```ray_cast()``` 関数を使ったレイとオブジェクトの交差判定も行いました。```ray_cast()``` は非常に便利な関数で、交差した面や位置も取得することができます。例えば、マウスでクリックした時にマウスカーソルの位置に穴を開けたり、マウスカーソルが重なっている面を強調表示といった処理も ```ray_cast()``` 関数を使って実装することができると思います。
335.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:336:216
v
335.
336. 本節の最後では、```view3d_utils``` サブモジュールが内部で行っている座標変換について具体的に理解したい方向けに、自力でローカル座標からリージョン座標へ変換する方法する方法を解説しました。アドオンを作るだけであれば理解する必要がない内容ですが、Blenderがどのように座標変換を行なっているかを理解することはAPIを深く知るきっかけになるため、余力のある方は目を通しておきましょう。また、解説するために自力で座標変換を行うスクリプトを紹介しましたが、細かい最適化やエラー処理は省いています。座標変換さえ行えれば十分という方は、素直に ```view3d_utils``` のAPIを利用するようにしましょう。
337.
^
✓ ja-no-redundant-expression: "することができる "は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/09_Use_Coordinate_Transformation_2.md:348:9
347. * ```view3d_utils``` を使わずとも、ローカル座標からリージョン座標へ変換することは可能である
348.
349.
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:9:43
v
8.
9. ###### ユーザはアドオンごとに提供される設定をユーザー・プリファレンスから変更することができます。アドオンで使用するキーボードのキーやUIのフォントなどのユーザに設定させたい情報をユーザー・プリファレンスに配置することで、プロパティパネルなどの既存のUIの邪魔にならないようにできます。本節では、ユーザー・プリファレンスからアドオンの設定を行うための方法を説明します。
10.
^
ja-no-redundant-expression: "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:9:171
v
8.
9. ###### ユーザはアドオンごとに提供される設定をユーザー・プリファレンスから変更することができます。アドオンで使用するキーボードのキーやUIのフォントなどのユーザに設定させたい情報をユーザー・プリファレンスに配置することで、プロパティパネルなどの既存のUIの邪魔にならないようにできます。本節では、ユーザー・プリファレンスからアドオンの設定を行うための方法を説明します。
10.
^
✓ ja-no-redundant-expression: "することができるの"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:18:48
v
17.
18. 具体的なサンプルの説明に入る前に、ユーザー・プリファレンスにてアドオンの設定をどこで参照＆設定することができるのかを知る必要があります。ここでは、筆者が作成したアドオン『Magic UV』を使って確認します。アドオン『Magic UV』は、https://github.com/nutti/Magic-UV/releases/download/v4.0/uv_magic_uv.zip からダウンロードすることができます。
19.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:18:202
v
17.
18. 具体的なサンプルの説明に入る前に、ユーザー・プリファレンスにてアドオンの設定をどこで参照＆設定することができるのかを知る必要があります。ここでは、筆者が作成したアドオン『Magic UV』を使って確認します。アドオン『Magic UV』は、https://github.com/nutti/Magic-UV/releases/download/v4.0/uv_magic_uv.zip からダウンロードすることができます。
19.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:112:121
v
111.
112. |<div id="box">2</div>|[3-2節](02_Handle_Keyboard_Key_Event.md) の機能が、1で割り当てたキーで動作することを確認します。キーを重複して登録した時は、登録した軸の正方向に同時に移動することができます。||
113. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:158:71
v
157.
158. アドオン設定クラスのメンバ変数 ```bl_idname``` には、すでにインストール済みの他のアドオンのパッケージ名やモジュール名を指定することができます。この場合、アドオンを有効化すると、```bl_idname``` に指定したパッケージ名を持つアドオンの設定情報に、アドオン設定クラスで定義した設定情報が表示されます。（```bl_idname``` に指定した表示先のアドオンと、アドオン設定クラスを定義したアドオンの両方が有効化されている必要があることに注意が必要です。）
159. 例えば、Blenderに標準搭載されている（サポートレベルがOfficialである）アドオンである「UV Layout」に設定情報を表示するためには、「UV Layout」のパッケージ名が ```io_mesh_uv_layout``` であることから、```bl_idname = 'io_mesh_uv_layout'``` と指定します。
^
✓ ja-no-redundant-expression: "することができまし"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:166:59
v
165.
166. アドオン設定クラスにプロパティクラスをメンバ変数に定義することで、ユーザー・プリファレンスにアドオンの設定情報を追加することができました。続いて、アドオンの処理でユーザが設定した設定情報を取得する必要があります。本節のサンプルでは、以下の処理によりアドオン設定クラスに定義した設定情報を取得します。
167.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:170:131
v
169.
170. ユーザー・プリファレンスに追加された全てのアドオンの設定情報は、```context.user_preferences.addons``` にパッケージ名やモジュール名をキーとした辞書型で保存されていて、設定情報は ```preferences``` から参照することができます。本節のサンプルは単一ファイルで構成され、かつ自分自身のアドオンの設定情報を取得するため、```context.user_preferences.addons[__name__].preferences``` で取得することができます。仮にアドオンが複数のファイルで構成されている場合は ```bl_idname``` の時と同様、```__init__.py``` の場合は、```context.user_preferences.addons[__name__].preferences``` 、それ以外の場合は ```context.user_preferences.addons[__package__].preferences``` のように指定することでアドオンの設定情報を取得できます。
171.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:170:248
v
169.
170. ユーザー・プリファレンスに追加された全てのアドオンの設定情報は、```context.user_preferences.addons``` にパッケージ名やモジュール名をキーとした辞書型で保存されていて、設定情報は ```preferences``` から参照することができます。本節のサンプルは単一ファイルで構成され、かつ自分自身のアドオンの設定情報を取得するため、```context.user_preferences.addons[__name__].preferences``` で取得することができます。仮にアドオンが複数のファイルで構成されている場合は ```bl_idname``` の時と同様、```__init__.py``` の場合は、```context.user_preferences.addons[__name__].preferences``` 、それ以外の場合は ```context.user_preferences.addons[__package__].preferences``` のように指定することでアドオンの設定情報を取得できます。
171.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:172:115
v
171.
172. 取得したアドオンの設定情報は、アドオン設定クラスで定義したメンバ変数 ```x_axis``` であれば ```context.user_preferences.addons[__name__].x_asis``` のように取得することができます。最後にアドオンの設定情報を使ってオブジェクトを移動する処理を次に示します。
173.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:180:117
v
179.
180. ユーザー・プリファレンスにアドオンの設定情報を配置し、ユーザから設定された情報を取得する方法を紹介しました。ユーザー・プリファレンスを活用することで、プロパティやツール・シェルフに設定情報が多くなりすぎて見づらくなるという問題を解消することができます。ユーザー・プリファレンスに配置する設定情報を選択する基準を決めるのはなかなか難しいところがあります。ユーザが設定を変更する可能性のある情報をユーザー・プリファレンスに配置するのは使い勝手が悪そうですし、結局のところ設定情報を頻繁に設定するか否かが1つの基準になるのではないかと思います。
181.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:182:104
v
181.
182. 本節までで、BlenderのUIを構築する方法が何度か出てきました。しかし幸いなことに、BlenderのUIは対象がプロパティパネルであってもユーザー・プリファレンスであっても基本的には同じような方法で構築することができます。1度覚えたことを他の場面でも使うことができるのは、実現したいことがあるたびに新たに覚えなおす必要がなくて助かりますね。UIの構築については、[2-8節](../chapter_02/08_Control_Blender_UI_1.md) から [2-10節](../chapter_02/10_Control_Blender_UI_3.md) の3節に渡って説明しているため、参考にしてみてください。
183.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:184:173
v
183.
184. さて長くなりましたが、サンプルを使ってBlenderのAPIを紹介するのは、本節で最後になります。これまで様々なアドオンのサンプルを紹介してきましたが、いかがでしょうか？ここまで紹介したBlenderのAPIを組み合わせることで色々なことができると思えてきませんか？APIを単独で使うのではなく、組み合わせて使うことでより面白く便利な機能を提供することができます。[5章](../chapter_05/SUMMARY.md) では、これまで紹介してきたAPIを使ったサンプルをいくつか紹介していますので、参考にしてみてください。
185.
^
✓ ja-no-redundant-expression: "することができるUI"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_03/10_Use_User_Preference.md:195:35
v
194.
195. * ユーザー・プリファレンスには、アドオンごとに設定や詳細情報を記述することができるUIが用意されている
196. * 頻繁に変更する設定をツール・シェルフやプロパティパネルに配置し、その他はユーザー・プリファレンスに配置するなど、設定内容に応じてアドオンの設定情報を配置する場所を決めよう
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:26:48
v
25.
26. Blenderが提供しているAPI一覧は、Blender公式が公開しているドキュメントから確認することができます。
27.
^
ja-no-redundant-expression: "再生を行う"は冗長な表現です。"再生する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:88:22
v
87. |```gpu```|GLSLを扱うための関数群|
88. |```aud```|サウンドの読み込みや再生を行うための関数群|
89. |```bpy_extras```|```bpy``` モジュールを補助する目的で提供される便利関数群|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:102:120
v
101.
102. [2-2節](../chapter_02/02_Register_Multiple_Operation_Classes.md)でも説明しましたが、 Pythonコンソールウィンドウを用いることでBlenderが提供するAPIを検索し、実行することができます。
103.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:148:108
v
147.
148. |<div id="box">5</div>|```select``` に ```True``` を代入することでオブジェクトを選択状態に、 ```False``` を代入することでオブジェクトを非選択状態に変更することができます。||
149. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:225:64
v
224.
225. |インストール済みのアドオンのソースコードが置かれている場所は、ファイル > ユーザ設定で開くウィンドウのアドオンタブから確認することができます。<br>非公式にインストールするアドオンの場合は、ダウンロードしたアドオンのソースコードを直接参照することができます。||
226. |---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:225:123
v
224.
225. |インストール済みのアドオンのソースコードが置かれている場所は、ファイル > ユーザ設定で開くウィンドウのアドオンタブから確認することができます。<br>非公式にインストールするアドオンの場合は、ダウンロードしたアドオンのソースコードを直接参照することができます。||
226. |---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:304:64
v
303.
304. アカウント登録後、CODING > Python SupportのPOST NEW THREADボタンからアドオンに関して質問することができます。
305.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:321:127
v
320.
321. 本サイトでは、質問したり他人の質問に回答したり誤字や脱字などを編集したりすることで各ユーザがポイントを得られる仕組みがあり、各ユーザの貢献度を見ることができます。さらに、ポイントを獲得していくことでPS4のトロフィーやXBoxの実績のようなバッジを獲得することができ、初期の段階で利用制限されていた機能を使えるような仕組みもあります。
322.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:332:74
v
331.
332. コミュニティサイトには、アカウント登録したユーザがBlenderについて議論できるフォーラムがあり、フォーラム内の質問板でアドオン開発について質問することができます。
333.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/01_Research_official_Blender_API_for_Add-on.md:350:10
v
349.
350. 筆者は、似たような処理を行っているアドオンを参考にしつつ、わからない部分を公式のAPIドキュメントで使用を確認したり、Pythonコンソールウィンドウを使って動作確認したりしてアドオンの開発を進めます。それでも欲しい情報が得られない場合は、コミュニティサイトで質問します。
351.
^
ja-no-redundant-expression: "デバッグを行う"は冗長な表現です。"デバッグする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:23:78
v
22. 読んで字のごとく、 ```self.report()``` メソッドを用いたデバッグ手法です。
23. ```self.report()``` メソッドの第2引数に任意の文字列を入力できることを利用し、確認したい変数の値をスクリプト実行ログに表示させることでデバッグを行います。
24.
^
ja-no-redundant-expression: "デバッグを行う"は冗長な表現です。"デバッグする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:46:38
v
45.
46. self.reportデバッグと同じように、確認したい変数の値を表示させてデバッグを行う方法ですが、self.reportデバッグでは確認できなかった処理中の変数も確認することができます。ただし ```print()``` 関数の出力先はコンソールウィンドウであるため、[1-3節](../chapter_01/03_Prepare_Add-on_development_environment.md) を参考にして、コンソールウィンドウからBlenderを起動する必要があります。
47.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:46:85
v
45.
46. self.reportデバッグと同じように、確認したい変数の値を表示させてデバッグを行う方法ですが、self.reportデバッグでは確認できなかった処理中の変数も確認することができます。ただし ```print()``` 関数の出力先はコンソールウィンドウであるため、[1-3節](../chapter_01/03_Prepare_Add-on_development_environment.md) を参考にして、コンソールウィンドウからBlenderを起動する必要があります。
47.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:65:66
v
64.
65. Pythonコンソールウィンドウからbpy.ops.XXX（XXX：オペレーションクラスのbl_idname）を実行してアドオンの処理を行った場合、print()関数の出力先はPythonコンソールウィンドウになります。
66.
^
ja-no-redundant-expression: "デバッグを実行"は冗長な表現です。"デバッグする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:88:1
v
87.
88. デバッグを実行するために、EclipseとPyDevをインストールします。
89.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:444:103
v
443.
444. 先ほど作成した ```debug.py``` と ```debuggee.py``` は、 ```PyDev Package Explorer``` の ```scripts/addons``` から参照することができます。
445.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:475:121
v
474.
475. |<div id="box">3</div>|New_Configurationを選択し、Runボタンをクリックします。<br>以降は、Run > External Tools > New_ConfigurationからBlenderを起動することができるようになります|<br><br>|
476. |---|---|---|
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:520:53
v
519.
520. |<div id="box">8</div>|3Dビューのメニューで、追加 > メッシュ > デバッグのテストを実行します||
521. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/02_Debug_Add-on.md:538:47
v
537.
538. |<div id="box">10</div>|Debugパースペクティブで変数値などを参照することができます。<br>この他にもEclipseには様々な機能が備わっていますが、ここでは割愛します。||
539. |---|---|---|
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:9:60
v
8.
9. ###### ここまでアドオンの開発に絞って解説してきました。今後はこれまで解説した内容をもとに、独自のアドオンを開発することができるようになると思います。そしてアドオン開発を行っていくと、いずれそのアドオンを公開したいという気持ちが生まれてくるかもしれません。本節では、作成したアドオンを公開する方法について紹介します。自作したアドオンを他の方に使ってもらいたい方は、ぜひ目を通してみてください。
10.
^
ja-no-redundant-expression: "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:9:86
v
8.
9. ###### ここまでアドオンの開発に絞って解説してきました。今後はこれまで解説した内容をもとに、独自のアドオンを開発することができるようになると思います。そしてアドオン開発を行っていくと、いずれそのアドオンを公開したいという気持ちが生まれてくるかもしれません。本節では、作成したアドオンを公開する方法について紹介します。自作したアドオンを他の方に使ってもらいたい方は、ぜひ目を通してみてください。
10.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:30:66
v
29.
30. Blenderアドオンの本体はソースコードですので、ソースコード管理サイトでアドオンのソースコードを公開することで、アドオンを公開することができます。
31.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:52:52
v
51. |GitHub Release|ソフトウェアをGitHub上で配布するための機能です。<br>アドオンはソースコードで構成されるため、直接ソースコードをダウンロードして配布しても良いです。しかしアドオンに明にバージョンを設定している場合は、アドオンのバージョンごとにユーザがダウンロードできた方が良いはずです。このような時に本機能が役に立つはずです|
52. |gh-pages|GitHubはソースコードを管理するだけでなく、プロジェクト毎にWebページを作成することができます。<br>本機能を用いると、個人でWebページを作成する時に必要となるHTMLなどの知識がない状態でもマウスをクリックしていくだけで、アドオンの紹介ページを作成することができます|
53. |Wiki|プロジェクトごとにWikiページを持つことができます。<br>アドオンのチュートリアルなど、アドオンの情報をまとめる時に役立つと思います|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:52:141
v
51. |GitHub Release|ソフトウェアをGitHub上で配布するための機能です。<br>アドオンはソースコードで構成されるため、直接ソースコードをダウンロードして配布しても良いです。しかしアドオンに明にバージョンを設定している場合は、アドオンのバージョンごとにユーザがダウンロードできた方が良いはずです。このような時に本機能が役に立つはずです|
52. |gh-pages|GitHubはソースコードを管理するだけでなく、プロジェクト毎にWebページを作成することができます。<br>本機能を用いると、個人でWebページを作成する時に必要となるHTMLなどの知識がない状態でもマウスをクリックしていくだけで、アドオンの紹介ページを作成することができます|
53. |Wiki|プロジェクトごとにWikiページを持つことができます。<br>アドオンのチュートリアルなど、アドオンの情報をまとめる時に役立つと思います|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:54:53
v
53. |Wiki|プロジェクトごとにWikiページを持つことができます。<br>アドオンのチュートリアルなど、アドオンの情報をまとめる時に役立つと思います|
54. |Issue|バグや課題を管理するための機能です。<br>バグ報告やアドオンに関して議論する場として利用することができます。|
55. |Pull Request|アドオン作成者以外の方がソースコードを修正し、修正者が作成者に修正内容の反映依頼を作成者本人に出す機能です。<br>アドオンに不具合があった場合などに、アドオンに興味を持ってくれた方が修正してくれるかもしれません。|
^
ja-no-redundant-expression: "宣伝を行う"は冗長な表現です。"宣伝する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:59:63
v
58.
59. 本書執筆時点では、アドオンのソースコード管理やチュートリアルサイトの作成をGitHubで行い、アドオン宣伝サイトでアドオンの宣伝を行うのが主流になりつつあるようです。
60.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:121:47
v
120.
121. フォーラムのPythonスクリプト・Plug-in板を利用して、開発したアドオンを投稿・宣伝することができます。投稿するためには、アカウントを登録する必要があります。
122.
^
ja-no-redundant-expression: "宣伝を行う"は冗長な表現です。"宣伝する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:162:53
v
161.
162. Blenderで作成したCG作品を公開するコミュニティが多いようですが、一部のコミュニティではアドオンの宣伝を行うことができます。例えば、以下のコミュニティがアドオンの宣伝の場所に適しています。
163.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/03_Publish_your_Add-on.md:182:109
v
181.
182. アドオンを宣伝する上で最も効果的な方法は、作成したアドオンをBlender本体に取り込んでもらうことです。Blender本体にアドオンを取り込んでもらうことで、Blenderをインストールした人すべてがアドオンを利用することができるようになります。
183.
^
ja-no-redundant-expression: "することが可能で"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:29:127
v
28. |---|---|---|
29. |GNU General Public License（GPL）|Free Software Foundation|本ライセンスが適用されているプログラムはソースコードを公開しなければなりません。<br>本ライセンスが適用されたソースコードは誰でも入手することが可能で、改変や再配布も自由です。<br>一方、GPLが適用されたプログラムやソースコードを利用した派生物は、たとえそれが一部分であってもGPLを適用する必要があることに注意が必要です。このように強い感染力を持つことから、GPL汚染と呼ばれることがあります。<br>GPLにはバージョンが3つあり、バージョンごとに制約が異なっている（特に特許関係）ため、GPL適用時にはバージョンも確認する必要があります。|
30. |MIT License|マサチューセッツ工科大学|GPLと比べて制約が緩いライセンスです。X11 Licenseなどと呼ばれることもあります。<br>MIT Licenseが適用されたソースコードは、改変・再配布などを行う際に著作権の表示とMIT License本文の記載、および無保証であることの記載という条件のみを要求します。ソースコードを非公開にしても良いですし、適用するライセンスを変えて再配布することもできます。|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:31:203
v
30. |MIT License|マサチューセッツ工科大学|GPLと比べて制約が緩いライセンスです。X11 Licenseなどと呼ばれることもあります。<br>MIT Licenseが適用されたソースコードは、改変・再配布などを行う際に著作権の表示とMIT License本文の記載、および無保証であることの記載という条件のみを要求します。ソースコードを非公開にしても良いですし、適用するライセンスを変えて再配布することもできます。|
31. |クリエイティブ・コモンズ・ライセンス（CC）|クリエイティブ・コモンズ|ここで紹介しているソースコードのライセンスとは異なり、全ての著作物に対して適用可能なライセンスです。Blenderを使っている方ではこちらの方が馴染みがあるかもしれません。著作物の複製・頒布などを行うする際に、「著作者の表示」「非営利目的での利用に限定」「改変禁止」「ライセンスの継承」の4つの制約の中から選択してライセンスを適用することができます。<br><br>著作権を完全に放棄して（パブリックドメインとして）公開する場合は、CC0を適用することになります。|
32. |Apache License|Apache Soft Foundation|MIT Licenseよりもさらに緩いライセンスで、こちらはライセンスの本文すら記載が不要となっています。本ライセンスが適用されたソースコードを改変・再配布する場合は、ソースコードの著作権の表示とApache Licenseが適用されている文言を入れるだけでよいです。もちろん、再配布の際は適用するライセンスを変えることが可能で、ソースコードを非公開にすることもできます。|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:39:258
v
38.
39. Blenderはオープンソースソフトウェアでソースコードが公開されていますが、ソースコードには基本的に **GPLv2** が適用されています。その他にもCyclesは **Apache 2.0** ライセンスとして利用できたり、Blenderのビルドに必要なライブラリには **MIT** ライセンスや **BSD** ライセンスなどが適用されていますが、ここでは、BlenderはGPLv2のライセンスが適用されていると覚えておけば問題ありません。ライセンスの詳細については、Blenderのホームページで確認することができます。
40.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:51:119
v
50.
51. BlenderのライセンスにはGPLv2が適用されていることが分かりましたが、Blender上で動作するアドオンのソースコードのライセンスには何を適用すればよいのでしょうか？その答えは、先ほど紹介したBlenderのホームページから確認することができ、Blenderを構成するすべてのコンポーネントは **GPLv3互換** でなければならないと書いています。アドオンのライセンスをGPLv3にする必要は必ずしもなく、GPLv3 **互換** とする必要があるということに注意してください。Blenderのアドオンを利用している間は、Blender上で動作することになるため自動的にGPLが適用されるため、GPLv3互換ではないライセンスが設定されているアドオンはライセンス違反となり使用できないことになります。例えば、ライセンスが明記されていないアドオンはGPLv3互換とはならないため、ライセンス違反とならないためにも使用を控えるべきです。GPLと互換である（両立する）ライセンスは次のホームページから確認することができますので、アドオンに設定しようと考えているライセンスがGPL互換か否かを必ずチェックするようにしましょう。
52.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:51:456
v
50.
51. BlenderのライセンスにはGPLv2が適用されていることが分かりましたが、Blender上で動作するアドオンのソースコードのライセンスには何を適用すればよいのでしょうか？その答えは、先ほど紹介したBlenderのホームページから確認することができ、Blenderを構成するすべてのコンポーネントは **GPLv3互換** でなければならないと書いています。アドオンのライセンスをGPLv3にする必要は必ずしもなく、GPLv3 **互換** とする必要があるということに注意してください。Blenderのアドオンを利用している間は、Blender上で動作することになるため自動的にGPLが適用されるため、GPLv3互換ではないライセンスが設定されているアドオンはライセンス違反となり使用できないことになります。例えば、ライセンスが明記されていないアドオンはGPLv3互換とはならないため、ライセンス違反とならないためにも使用を控えるべきです。GPLと互換である（両立する）ライセンスは次のホームページから確認することができますので、アドオンに設定しようと考えているライセンスがGPL互換か否かを必ずチェックするようにしましょう。
52.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:91:222
v
90.
91. ソースコード全てにライセンス本文が記載されているのが最善ではありますが、ソースコードの数が多くなってくるとライセンスを記載することが面倒になってくると思います。そして、故意ではなくてもライセンスを記載し忘れてしまう可能性もあります。このような場合には、ソースコードが置かれたトップディレクトリに ```LICENSE``` ファイルを作成し、ライセンスの本文を ```LICENSE``` ファイルに記載することでも、適用するライセンスを宣言することができます。複数のライセンス（マルチライセンス）を適用する場合は、適用するライセンス全てについて ```LICENSE``` ファイルに記載します。
92.
^
✓ ja-no-redundant-expression: "することができない"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:110:346
v
109.
110. Web上に公開されているアドオンのソースコードを見ていると、いずれのライセンスにも適用されていないものが数多くあります。実際に筆者自身もライセンスが適用されていないアドオンへの対応で困ったことがあります。ライセンスが適用されていないアドオンのバグを修正してほしいという依頼を受けたのは良いのですが、ソースコードを確認してみると適用しているライセンスが書かれた文章がどこにも見つかりませんでした。ソースコードの作者が外国の方で、英語で聞く必要があることについては対応のしようがあるのでまだ良いのですが、問題はソースコードを作成した日付が5年以上前となっていたので連絡が取れるのかということでした。たまたまこの時は連絡がついたのですが、もし連絡が取れなかったらライセンスがないためアドオンを修正することができないことになります。
111.
^
✓ ja-no-redundant-expression: "することができなく"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/04_Determine_License_of_Add-on.md:112:62
v
111.
112. このように、アドオンにライセンスが適用されていないと **せっかく素晴らしいアドオンを作成しても、作者以外はアドオンを修正することができなくなってしまいます。** 筆者自身、アドオンを公開する時にライセンスを適用し忘れてしまうことがよくあるのであまり言える立場ではないのですが、公開後の面倒な対応を避けるためにも公開する前にライセンスを適用するようにしましょう。本節では、最低でもこのことだけでも覚えておいてもらえればよいです。
113.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:21:197
v
20.
21. BlenderはGUIベースのソフトウェアですので、アドオンの機能が正しく動作していることを動作確認するためにはマウスやキーボードを使った操作が必要になるため、テストを自動化することが難しいと感じるかもしれません。しかし幸いなことに、BlenderはコマンドラインでPythonスクリプトを実行するモード（CUIモード）が標準で備わっているため、CUIモードを活用してアドオンのテストを自動化することができます。
22.
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:29:170
v
28.
29. 上記のコマンドを実行すると、BlenderがCUIモードで起動後にBlenderが終了します。しかしこれだけでは、CUIモードでBlenderが起動して終了するだけで意味がありません。CUIモードが強力なのは、オプション ```--python``` の引数に指定したPythonスクリプトを実行できることにあります。例えば、レンダリング処理を実行するPythonスクリプトを作成し、高性能なレンダリングを行うサーバでCUI実行することで、ネットワークレンダリングを行うことができます。また、過去に作成した.blendファイルに対してPythonスクリプトを使って同じ処理を繰り返したい場合にも、コマンドラインから実行することで作業時間を短縮することができます。
30.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:29:322
v
28.
29. 上記のコマンドを実行すると、BlenderがCUIモードで起動後にBlenderが終了します。しかしこれだけでは、CUIモードでBlenderが起動して終了するだけで意味がありません。CUIモードが強力なのは、オプション ```--python``` の引数に指定したPythonスクリプトを実行できることにあります。例えば、レンダリング処理を実行するPythonスクリプトを作成し、高性能なレンダリングを行うサーバでCUI実行することで、ネットワークレンダリングを行うことができます。また、過去に作成した.blendファイルに対してPythonスクリプトを使って同じ処理を繰り返したい場合にも、コマンドラインから実行することで作業時間を短縮することができます。
30.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:51:36
v
50.
51. このように、BlenderのCUIモードでPythonスクリプトを実行することができます。CUIモードでPythonスクリプトが実行できることを利用し、アドオンの機能をテストするスクリプトを実行することで、GUIモードでマウスやキーボードを用いることなくアドオンのテストを行うことができます。しかし、CUIモードでBlenderを起動しただけではアドオンが有効化されていません。作成したアドオンをCUIモードで有効化してBlenderを実行するためには、```--addons``` オプションの引数に有効化したいアドオンのパッケージまたはモジュール名を指定します。例えば、モジュール名が ```addon_test``` であれば以下のコマンドを実行することで、アドオン ```addon_test``` が有効化された状態でスクリプト ```run_script_on_cui_mode.py``` を実行します。
52.
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:51:133
v
50.
51. このように、BlenderのCUIモードでPythonスクリプトを実行することができます。CUIモードでPythonスクリプトが実行できることを利用し、アドオンの機能をテストするスクリプトを実行することで、GUIモードでマウスやキーボードを用いることなくアドオンのテストを行うことができます。しかし、CUIモードでBlenderを起動しただけではアドオンが有効化されていません。作成したアドオンをCUIモードで有効化してBlenderを実行するためには、```--addons``` オプションの引数に有効化したいアドオンのパッケージまたはモジュール名を指定します。例えば、モジュール名が ```addon_test``` であれば以下のコマンドを実行することで、アドオン ```addon_test``` が有効化された状態でスクリプト ```run_script_on_cui_mode.py``` を実行します。
52.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:59:180
v
58.
59. 有効化されているアドオンの機能は、[2-2節](../chapter_02/02_Register_Multiple_Operation_Classes.md) で紹介したように、オペレータクラスの ```bl_idname``` が ```bpy.ops.<オペレーションクラスのbl_idname>``` として登録されることを利用し、スクリプトから実行することができます。
60.
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:61:59
v
60.
61. テストするアドオンを有効化した状態でBlenderを実行し、アドオンの機能をスクリプトから実行することで、アドオンのテストを行うことになります。すなわち、アドオンの動作確認を行うためにマウスやキーボードを用いて行なっていたことを、Blenderが提供するAPIを使って実現する必要があります。このため、処理によってはスクリプトで実現できない可能性があることに注意が必要です。
62.
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:66:133
v
65.
66. CUIモードでスクリプトを実行する方法を紹介しましたが、これを用いてアドオンの動作テストを自動化する方法を紹介します。アドオンの動作テストを自動化する方法として、ここではGitHubとTravis CIを連携してアドオンをGitHubのリポジトリにコミットした時にテストを行うための方法を紹介します。
67.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:70:149
v
69.
70. GitHubについては、[4-3節](03_Publish_your_Add-on.md) にて紹介しましたが、GitHubの機能の1つに外部サービスとの連携があります。外部サービスと連携することにより、更新したソースコードをコミットした時に外部サービスを利用し、そのコミットが正常であるかを確認することができます。GitHubの登録の仕方についてはすでに多くの情報がWeb上で紹介されているため、本書では割愛します。
71.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:110:72
v
109.
110. |<div id="box">2</div>|リポジトリ有効化ボタンの隣にある歯車マークをクリックすると、テスト（ビルド）を実行する契機を確認することができます。||
111. |---|---|---|
^
ja-no-redundant-expression: "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:145:334
v
144.
145. スクリプト自体は単純で、```testee.py``` で登録するオペレータクラスの ```bl_idname``` を使ってアドオンの機能を呼び出すだけです。アドオンの機能を呼び出した後は、その戻り値を ```assert``` 文で判定します。第1引数の条件が偽の場合には ```AssertionError``` 例外オブジェクトが発生し、```except``` 処理の中で第2引数に指定した文字列が表示されたあと、```sys.exit(1)``` によりBlenderが復帰値 ```1``` で終了することでテストがエラー終了します。Travis CIはテストのコマンドの結果が ```0``` 以外の場合には、テストが失敗したと判断します。アドオンの機能を実行した時の戻り値が期待したものではなかった場合にBlenderが ```0``` 以外で終了するようなスクリプトを作成することで、アドオンが正常に動作しているのか否かを確認することができます。
146.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:145:424
v
144.
145. スクリプト自体は単純で、```testee.py``` で登録するオペレータクラスの ```bl_idname``` を使ってアドオンの機能を呼び出すだけです。アドオンの機能を呼び出した後は、その戻り値を ```assert``` 文で判定します。第1引数の条件が偽の場合には ```AssertionError``` 例外オブジェクトが発生し、```except``` 処理の中で第2引数に指定した文字列が表示されたあと、```sys.exit(1)``` によりBlenderが復帰値 ```1``` で終了することでテストがエラー終了します。Travis CIはテストのコマンドの結果が ```0``` 以外の場合には、テストが失敗したと判断します。アドオンの機能を実行した時の戻り値が期待したものではなかった場合にBlenderが ```0``` 以外で終了するようなスクリプトを作成することで、アドオンが正常に動作しているのか否かを確認することができます。
146.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:152:11
v
151.
152. Travis CIでテストを実行するためには、```.travis.yml``` ファイルというYAML形式の設定ファイルを作成する必要があります。
153.
^
ja-no-redundant-expression: "ダウンロードを実行"は冗長な表現です。"ダウンロードする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:166:327
v
165.
166. Blenderをコマンドラインから実行する方法で記載したように ```script``` には、```--python``` , ```--addons``` と ```--background``` オプションを指定して、アドオン ```testee``` を有効化した上でテストスクリプト ```test.py``` をCUIモードで実行しています。他にも、オーディオを無効化する ```-noaudio``` オプションや初期状態で起動する ```--factory-startup``` オプションを追加しています。```-noaudio``` オプションを指定しないで実行すると、オーディオライブラリ関連のエラーがログに出力されてしまいます。ダウンロードを実行した直後にBlenderを実行するため初期状態での起動となり ```--factory-startup``` は本来不要ですが、念のために指定しています。
167.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:171:58
v
170.
171. Blenderのコマンドラインオプションの一覧は、```--help``` オプションを指定して実行することで表示することができます。
172.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:210:23
v
209.
210. テストの実行結果は、Travis CIで確認することができます。Travis CI上でテスト結果を確認する方法を次に示します。
211.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:238:48
v
237.
238. |<div id="box">3</div>|*Job log* から、テストの実行ログを確認することができます。||
239. |---|---|---|
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:255:29
v
254.
255. 修正後にアドオンのソースコードをリポジトリにコミットし、テストを実行します。
256.
^
✓ ja-no-redundant-expression: "することができること"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:269:195
v
268.
269. GitHubとTravis CIを利用して、アドオンのテストを自動化する方法を紹介しました。すでにGitHubでアドオンを公開している方や、これから公開することを考えている方は、本節で紹介したテストの自動化はアドオンの品質や開発効率の向上に役立つと思います。GitHubにアドオンを公開しない方でも、BlenderをCUIモードで起動してテストスクリプトを実行することでもアドオンをテストすることができることを覚えておきましょう。
270.
^
ja-no-redundant-expression: "テストを行う"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:271:193
v
270.
271. 本節で紹介したテスト自動化は、修正時に他の機能への影響が見えづらくかつテスト量が多くなりがちな、ソースコードの規模が大きいアドオンに対して効果を発揮します。一方数百行程度のアドオンの場合、テストスクリプトや設定ファイル作成などのテスト自動化の手続きにより、かえって手間がかかってしまう可能性があります。また今後のサポートを考えていないなど、あくまで個人用途で作成したアドオンであれば、テストを行う必要がないかもしれません。作成したアドオンの規模やサポート範囲を踏まえ、アドオンの自動テスト化を行うか判断すると良いと思います。
272.
^
✓ ja-no-redundant-expression: "することができるCUI"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/05_Test_Add-on_Automatically.md:282:29
v
281. * *ターミナル* からBlenderを実行する時にオプション ```--background``` を指定することでCUIモードでBlenderを実行することができる
282. * CUIモードでPythonスクリプトを実行するためには、```--python``` オプションの引数に実行するスクリプト名を指定する
283. * CUIモードでアドオンを有効化するためには、```--addons``` オプションの引数に有効化したいアドオンのパッケージまたはモジュール名を指定する
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/06_Commit_your_Add-on_to_Blender.md:97:108
v
96.
97. いきなりアドオンのソースコードレビューを行うのではなく、作成したアドオンが実用的なものかを判断する機能レビューを最初に行います。レビューの申請は、developer.blender.org（通称D.B.O）から申請することができます。
98.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/06_Commit_your_Add-on_to_Blender.md:200:34
v
199.
200. 機能レビューに合格する前でも、Blender Wikiページを作成することができます。D.B.Oで作成したタスクの説明文においてBlender Wikiのページを参照したい場合は、レビュー依頼を出す前にWikiページを作成してもよいと思います。
201.
^
ja-no-redundant-expression: "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/06_Commit_your_Add-on_to_Blender.md:378:21
v
377.
378. 以下のコマンドを実行し、commit先の設定を行います。
379.
^
ja-no-redundant-expression: "解説を行う"は冗長な表現です。"解説する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_04/06_Commit_your_Add-on_to_Blender.md:489:18
v
488.
489. これまで本書を通してアドオン開発の解説を行ってきましたが、これで最後となります。長くなりましたが、お疲れ様でした！
490.
^
✓ ja-no-redundant-expression: "することができるオブジェクト"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_05/01_Transform_Object_with_Keybord.md:45:39
v
44. * 特殊オブジェクト編集モード中は、移動量・拡大率・縮小率・回転量を設定することができる
45. * オブジェクトの変形操作の結果は、*3Dビュー* エリアのメニュー *オブジェクト* > *トランスフォーム* > *移動* , *回転* , *拡大縮小* によるオブジェクト変形と同じである
46.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_05/01_Transform_Object_with_Keybord.md:107:83
v
106.
107. |<div id="box">4</div>|*3Dビュー* エリアのプロパティパネルの *特殊オブジェクト編集モード* から、移動量・拡大率・縮小率・回転量を指定することができます。||
108. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_05/02_Calculate_Working_Hour.md:84:61
v
83.
84. |<div id="box">4</div>|ユーザー・プリファレンスのアドオン設定から、表示位置やフォントサイズを変更することができます。||
85. |---|---|---|
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_05/04_Display_Object_Name.md:40:18
v
39. * *3Dビュー* エリアのプロパティパネルに *オブジェクト名の表示サポート* を追加し、オブジェクト名の表示を開始するためのボタンを配置する
40. * オブジェクト名表示中は、以下の処理を行う
41. * *3Dビュー* エリアに表示されている全てのオブジェクトについて、オブジェクトの位置にオブジェクト名を表示する
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/Introduction-to-Add-on-Development-in-Blender/chapter_05/04_Display_Object_Name.md:85:66
v
84.
85. |<div id="box">4</div>|ユーザー・プリファレンスからそれぞれの機能について、表示文字列のフォントや位置を変更することができます。||
86. |---|---|---|
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/ESLint/README.md:76:93
v
75.
76. ESLintではこのASTを使って、[no-console.js](#no-console.js)のように`console.log`などがコードに残ってないかなどをルールを元にチェックすることができます。
77.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/ESLint/README.md:256:8
v
255. 逆に与えられたコード(AST)を書き換える場合には、
256. ルールを同時に処理を行うためルール間で競合するような変更がある場合に破綻してしまいます。
257.
^
ja-no-redundant-expression: "書き換えを行う"は冗長な表現です。"書き換えする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/ESLint/README.md:263:55
v
262. > **NOTE** ESLint 2.0でautofixing、つまり書き換えの機能の導入が予定されています。
263. > これはルールからの書き換えのコマンドを`SourceCode`というオブジェクトに集約して、最後に実際の書き換えを行うという抽象レイヤーを設けています。
264. > - [Implement autofixing · Issue #3134 · eslint/eslint](https://github.com/eslint/eslint/issues/3134 "Implement autofixing · Issue #3134 · eslint/eslint")
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/ESLint/README.md:274:45
v
273. ESLintのルールはただのJavaScriptモジュールなので、
274. ルール自体を[npm](https://www.npmjs.com/ "npm")で公開することができます。
275.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/gulp/README.md:26:22
v
25.
26. この一連の処理は次のようなタスクとして定義することができます。
27.
^
ja-no-redundant-expression: "追加を行う"は冗長な表現です。"追加する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/gulp/README.md:57:45
v
56. ここでは`gulp-prefixer`というgulpプラグインを書いていきます。
57. `gulp-prefixer`は与えられたそれぞれのファイルに対して先頭に特定の文字列の追加を行うプラグインです。
58.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/gulp/README.md:236:63
v
235.
236. 元々、Transform Streamは1つの変換処理を行うことが得意なので、その変換処理を`pipe`を繋げることで複数の処理を行うことができます。
237.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/jQuery/README.md:5:56
v
4.
5. jQueryでは`$.fn`を拡張することで、`$()`の返り値となるjQueryオブジェクトにメソッドを追加することができます。
6.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/jQuery/README.md:47:60
v
46. 単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。
47. 動的にメソッドを追加するだけではなく、既存の実装を上書きするmonkey patchのようなものもプラグインとして追加することができます。
48.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/JavaScript-Plugin-Architecture/Redux/README.md:117:11
v
116. 上記のArrowFunctionの連なりが一見すると何をしているのかが分かりにくいですが、
117. これは次のように展開することができます。
118.
^
ja-no-redundant-expression: "比較を行う"は冗長な表現です。"比較する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/implicit-coercion/README.md:12:27
v
11. > 等価演算子（`==`）はオペランド同士が異なる型の値であった場合に、
12. > 同じ型となるように**暗黙的な型変換**してから比較を行います。
13.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/implicit-coercion/README.md:353:4
v
352.
353. 同様の処理を行う方法として`Number.isNaN(x)`メソッドがあります。
354. 実際に値が`NaN`かを判定する際には、`Number.isNaN(x)`メソッドを利用するとよいでしょう。
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/implicit-coercion/README.md:445:26
v
444.
445. JavaScriptは、型エラーに対して暗黙的な型変換を行うなど驚くほど許容しています。
446. そのため、大きなJavaScriptアプリケーションを書く場合は、このような検出しにくいバグを見つけられるように書くことは重要です。
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/implicit-coercion/README.md:463:14
v
462.
463. 次のコードでは、明示的な型変換を行っていますが、`0`も**空文字**となってしまい意図しない挙動になっています。
464.
^
ja-no-redundant-expression: "終了を実行"は冗長な表現です。"終了する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/loop/README.md:24:13
v
23. 1. `条件式` の評価結果が`true`なら処理を続け、`false`なら終了
24. 2. `実行する文`を実行
25. 3. ステップ1へ戻る
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/loop/README.md:174:4
v
173.
174. 同様の処理を行う `isEvenIncluded` 関数を実装してみます。
175. 次のコードでは、break文が実行され、ループを抜けた後にreturn文で結果を返しています。
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/object/README.md:13:38
v
12. オブジェクトを作成するには、オブジェクトリテラル（`{}`）を利用する方法が簡単です。
13. また、オブジェクトリテラルのプロパティ名はクオート（`"`や`'`）を省略することが可能です。
14.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/object/README.md:60:32
v
59. オブジェクトは、一度作成した後もその値自体を変更できるためミュータブル（mutable）の特性を持ちます。
60. そのため、作成したオブジェクトに対して、後からプロパティを追加することが可能です。
61.
^
ja-no-redundant-expression: "足し算を行う"は冗長な表現です。"足し算する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:8:6
v
7. 演算子はよく利用する計算を関数やメソッドではなく、記号として表現したものです。
8. たとえば、足し算を行う `+` も演算子の一種で、演算子には多くの種類があります。
9.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:178:28
v
177. 単項マイナス演算子も文字列などを数値へ変換します。
178. 単項プラス演算子と同様で、単項マイナス演算子で数値への変換を行うべきではありません。
179.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:286:36
v
285. 等価演算子（`==`）は、2つのオペランドを比較します。
286. 同じ型のオペランドを比較する場合は、厳密等価演算子（`===`）と同じ処理を行います。
287.
^
ja-no-redundant-expression: "比較を行う"は冗長な表現です。"比較する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:301:25
v
300. しかし、等価演算子（`==`）はオペランド同士が異なる型の値であった場合に、
301. 同じ型となるように**暗黙的な型変換**してから比較を行います。
302.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:357:47
v
356.
357. 不等価演算子も、等価演算子（`==`）と同様に異なる型のオペランドを比較する際に、暗黙的な型変換を行ってから比較します。
358.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:368:10
v
367. そのため、不等価演算子（`!=`）は、利用するべきではありません。
368. 代わりに暗黙的な型変換を行わない厳密不等価演算子（`!==`）を利用します。
369.
^
ja-no-redundant-expression: "表示を行う"は冗長な表現です。"表示する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/read-eval-print/README.md:23:50
v
22.
23. JavaScriptの多くの実行環境では、Console APIが**コンソール表示**を行うAPIとなっています。
24. `console.log(引数)`の引数にコンソール表示したい値を入れることで、評価結果がコンソールに表示されます。
^
ja-no-redundant-expression: "処理を実行"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/statement-expression/README.md:41:26
v
40.
41. **文**（Statement）を簡潔に述べると、処理を実行する1ステップが1つの文といえます。
42. JavaScriptでは、文の末尾にセミコロン(`;`)を置くことで文と文に区切りを付けます。
^
ja-no-redundant-expression: "結合を行う"は冗長な表現です。"結合する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/string/README.md:62:19
v
61.
62. 特定の書式に値を埋め込みために文字列結合を行う場合には、
63. テンプレートリテラルを使うとより宣言的に書くことができます。
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/string/README.md:305:36
v
304.
305. しかし、JavaScriptにおいて、見た目どおりの**文字**ごとに処理を行う標準的な方法は用意されていません。
306. 結合文字などを考慮した**文字**について、詳しくは[JavaScript has a Unicode problem · Mathias Bynens][]を参照してください。
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/js-primer/string/README.md:373:20
v
372. これらの関係演算子も、文字列の要素であるCode Unitの数値を先頭から順番に比較します。
373. しかし、これらの関係演算子は暗黙的な型変換を行うため事前に文字列同士であるかのチェックが必要です。
374.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:20:255
v
19.
20. もっとも有名なVCSツールの一つは、RCSと呼ばれるシステムでした。今日でも、依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムでも、開発者ツールをインストールするとrcsコマンドが入っています。このツールは基本的に、リビジョン間のパッチ（ファイル間の差分）の集合を特殊なフォーマットでディスク上に保持するという仕組みで動いています。こうすることで、任意のファイルについて、それが過去の任意の時点でどういうものだったかということを、パッチを重ね上げていくことで再現することができます。
21.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:40:95
v
39.
40. さらに、これらのDVCSの多くは、複数のリモート・リポジトリで作業をするということがうまく扱えるようになっているので、異なった方法で異なる人々のグループと同時に同じプロジェクト内で共同作業することができます。このため、階層モデルなどの、集中システムでは不可能な幾つかのワークフローが構築できるようになっています。
41.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:124:56
v
123.
124. 少しGitを使う事に入りましょう。何よりも最初に、Gitをインストールしなければなりません。幾つもの経路で入手することができ、主要な二つの方法のうちの一つはソースからインストールすることで、もう一つはプラットフォームに応じて存在するパッケージをインストールすることです。
125.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:165:112
v
164.
165. MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはSourceForgeのページ（図1-7参照）からダウンロードすることができます：
166.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:190:122
v
189.
190. 今や、Gitがシステムにあります。Git環境をカスタマイズするためにしたい事が少しはあることでしょう。アップグレードの度についてまわるので、たった一度でそれらを終わらすべきでしょう。またそれらは、またコマンドを実行することによっていつでも変更することができます。
191.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:192:77
v
191.
192. Gitには、`git config`と呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります：
193.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:207:207
v
206.
207. また、もし`--global`オプションを指定するのであれば、Gitはその後、そのシステム上で行なう（訳者注：あるユーザーの）全ての操作に対して常にこの情報を使うようになるため、この操作を行なう必要はたった一度だけです。もし、違う名前とE-mailアドレスを特定のプロジェクトで上書きしたいのであれば、そのプロジェクトの（訳者注：Gitディレクトリの）中で、`--global`オプション無しでこのコマンドを実行することができます。
208.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/01-introduction/01-chapter1.markdown:238:53
v
237.
238. また、Gitに設定されている特定のキーの値を、`git config {key}`をタイプすることで確認することができます：
239.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:17:121
v
16.
17. 空のディレクトリではなくすでに存在するファイルのバージョン管理を始めたい場合は、まずそのファイルを監視対象に追加してから最初のコミットをすることになります。この場合は、追加したいファイルについて `git add` コマンドを実行したあとでコミットを行います。
18.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:27:312
v
26.
27. 既存の Git リポジトリ (何か協力したいと思っているプロジェクトなど) のコピーを取得したい場合に使うコマンドが、`git clone` です。Subversion などの他の VCS を使っている人なら「`checkout` じゃなくて `clone` なのか」と気になることでしょう。これは重要な違いです。Git は、サーバーが保持しているデータをほぼすべてコピーするのです。そのプロジェクトのすべてのファイルのすべての歴史が、`git clone` で手元にやってきます。実際、もし仮にサーバーのディスクが壊れてしまったとしても、どこかのクライアントに残っているクローンをサーバーに戻せばクローンした時点まで復元することができます (サーバーサイドのフックなど一部の情報は失われてしまいますが、これまでのバージョン管理履歴はすべてそこに残っています。*第 4 章* で詳しく説明します)。
28.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:39:23
v
38.
39. Git では、さまざまな転送プロトコルを使用することができます。先ほどの例では `git://` プロトコルを使用しましたが、`http(s)://` や `user@server:/path.git` といった形式を使うこともできます。これらは SSH プロトコルを使用します。*第 4 章* で、サーバー側で準備できるすべてのアクセス方式についての利点と欠点を説明します。
40.
^
✓ ja-no-redundant-expression: "することができまし"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:43:50
v
42.
43. これで、れっきとした Git リポジトリを準備して、そのプロジェクト内のファイルの作業コピーを取得することができました。次は、そのコピーに対して何らかの変更を行い、適当な時点で変更内容のスナップショットをリポジトリにコミットすることになります。
44.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:92:62
v
91.
92. ステージされていると判断できるのは、“Changes to be committed” 欄に表示されているからです。ここでコミットを行うと、`git add` した時点の状態のファイルがスナップショットとして歴史に書き込まれます。先ほど `git init` をしたときに、ディレクトリ内のファイルを追跡するためにその後 `git add (ファイル)` としたことを思い出すことでしょう。`git add` コマンドには、ファイルあるいはディレクトリのパスを指定します。ディレクトリを指定した場合は、そのディレクトリ以下にあるすべてのファイルを再帰的に追加します。
93.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:301:28
v
300.
301. ステージングエリアの準備ができたら、変更内容をコミットすることができます。コミットの対象となるのはステージされたものだけ、つまり追加したり変更したりしただけでまだ `git add` を実行していないファイルはコミットされないことを覚えておきましょう。そういったファイルは、変更されたままの状態でディスク上に残ります。今回の場合は、最後に `git status` を実行したときにすべてがステージされていることを確認しています。つまり、変更をコミットする準備ができた状態です。コミットするための最もシンプルな方法は `git commit` と打ち込むことです。
302.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:336:196
v
335.
336. コミットの内容を思い通りに作り上げることができるという点でステージングエリアは非常に便利なのですが、普段の作業においては必要以上に複雑に感じられることもあるでしょう。ステージングエリアを省略したい場合のために、Git ではシンプルなショートカットを用意しています。`git commit` コマンドに `-a` オプションを指定すると、追跡対象となっているファイルを自動的にステージしてからコミットを行います。つまり `git add` を省略できるというわけです。
337.
^
✓ ja-no-redundant-expression: "することができなく"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:382:128
v
381.
382. 次にコミットするときにファイルが削除され、追跡対象外となります。変更したファイルをすでにステージしている場合は、`-f` オプションで強制的に削除しなければなりません。まだスナップショットに記録されていないファイルを誤って削除してしまうと Git で復旧することができなくなってしまうので、それを防ぐための安全装置です。
383.
^
ja-no-redundant-expression: "展開を行う"は冗長な表現です。"展開する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:392:80
v
391.
392. `*` の前にバックスラッシュ (`\`) があることに注意しましょう。これが必要なのは、シェルによるファイル名の展開だけでなく Git が自前でファイル名の展開を行うからです。ただしWindowsのコマンドプロンプトの場合は､バックスラッシュは取り除かなければなりません｡このコマンドは、`log/` ディレクトリにある拡張子 `.log` のファイルをすべて削除します。あるいは、このような書き方もできます。
393.
^
ja-no-redundant-expression: "レビューを行う"は冗長な表現です。"レビューする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:502:180
v
501.
502. コードレビューの際､行単位ではなく単語単位でレビューするほうが容易な場合もあるでしょう｡`git log -p` コマンドのオプション `--word-diff` を使えば､通常の行単位diffではなく､単語単位のdiffを表示させることができます｡単語単位のdiffはソースコードのレビューに用いても役に立ちませんが､書籍や論文など､長文テキストファイルのレビューを行う際は便利です｡こんな風に使用します｡
503.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:554:182
v
553.
554. ごらんの通り `--stat` オプションは、各コミットエントリに続けて変更されたファイルの一覧と変更されたファイルの数、追加・削除された行数が表示されます。また、それらの情報のまとめを最後に出力します。もうひとつの便利なオプションが `--pretty` です。これは、ログをデフォルトの書式以外で出力します。あらかじめ用意されているいくつかのオプションを指定することができます。`oneline` オプションは、各コミットを一行で出力します。これは、大量のコミットを見る場合に便利です。さらに `short` や `full` そして `fuller` といったオプションもあり、これは標準とほぼ同じ書式だけれども情報量がそれぞれ少なめあるいは多めになります。
555.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:561:46
v
560.
561. もっとも興味深いオプションは `format` で、これは独自のログ出力フォーマットを指定することができます。これは、出力結果を機械にパースさせる際に非常に便利です。自分でフォーマットを指定しておけば、将来 Git をアップデートしても結果が変わらないようにできるからです。
562.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:630:164
v
629.
630. 出力のフォーマット用オプションだけでなく、 `git log` にはログの制限用の便利なオプションもあります。コミットの一部だけを表示するようなオプションのことです。既にひとつだけ紹介していますね。`-2` オプション、これは直近のふたつのコミットだけを表示するものです。実は `-<n>` の `n` には任意の整数値を指定することができ、直近の `n` 件のコミットだけを表示させることができます。ただ、実際のところはこれを使うことはあまりないでしょう。というのも、Git はデフォルトですべての出力をページャにパイプするので、ログを一度に 1 ページだけ見ることになるからです。
631.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:722:86
v
721.
722. ウィンドウの上半分に、コミットの歴史がきれいな家系図とともに表示されます。ウィンドウの下半分には diff ビューアがあり、任意のコミットをクリックしてその変更内容を確認することができます。
723.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:805:96
v
804.
805. Git にコミットした内容のすべては、ほぼ常に取り消しが可能であることを覚えておきましょう。削除したブランチへのコミットや `--amend` コミットで上書きされた元のコミットでさえも復旧することができます (データの復元方法については *第 9 章* を参照ください)。しかし、まだコミットしていない内容を失ってしまうと、それは二度と取り戻せません。
806.
^
ja-no-redundant-expression: "追加を行う"は冗長な表現です。"追加する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:846:26
v
845.
846. これまでのセクションでも何度かリモートリポジトリの追加を行ってきましたが、ここで改めてその方法をきちんと説明しておきます。新しいリモート Git リポジトリにアクセスしやすいような名前をつけて追加するには、`git remote add [shortname] [url]` を実行します。
847.
^
ja-no-redundant-expression: "フェッチを実行"は冗長な表現です。"フェッチする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:876:103
v
875.
876. リポジトリをクローンしたときには、リモートリポジトリに対して自動的に *origin* という名前がつけられます。つまり、`git fetch origin` とすると、クローンしたとき (あるいは直近でフェッチを実行したとき) 以降にサーバーにプッシュされた変更をすべて取得することができます。ひとつ注意すべき点は、`fetch` コマンドはデータをローカルリポジトリに引き出すだけだということです。ローカルの環境にマージされたり作業中の内容を書き換えたりすることはありません。したがって、必要に応じて自分でマージをする必要があります。
877.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:876:139
v
875.
876. リポジトリをクローンしたときには、リモートリポジトリに対して自動的に *origin* という名前がつけられます。つまり、`git fetch origin` とすると、クローンしたとき (あるいは直近でフェッチを実行したとき) 以降にサーバーにプッシュされた変更をすべて取得することができます。ひとつ注意すべき点は、`fetch` コマンドはデータをローカルリポジトリに引き出すだけだということです。ローカルの環境にマージされたり作業中の内容を書き換えたりすることはありません。したがって、必要に応じて自分でマージをする必要があります。
877.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:1004:22
v
1003.
1004. GPG 秘密鍵を持っていれば、タグに署名をすることができます。その場合は `-a` の代わりに `-s` を指定すればいいだけです。
1005.
^
ja-no-redundant-expression: "補完を行う"は冗長な表現です。"補完する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:1162:186
v
1161.
1162. すべてのユーザーに対して Git 用の Bash シェル補完を使わせたい場合は、Mac なら `/opt/local/etc/bash_completion.d` ディレクトリ、Linux 系なら `/etc/bash_completion.d/` ディレクトリにこのスクリプトをコピーします。Bash は、これらのディレクトリにあるスクリプトを自動的に読み込んでシェル補完を行います。
1163.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/02-git-basics/01-chapter2.markdown:1182:100
v
1181.
1182. Git は、コマンドの一部だけが入力された状態でそのコマンドを推測することはありません。Git の各コマンドをいちいち全部入力するのがいやなら、`git config` でコマンドのエイリアスを設定することができます。たとえばこんなふうに設定すると便利かもしれません。
1183.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:84:149
v
83.
84. これで、プロジェクトの歴史が二つに分かれました (図 3-9 を参照ください)。新たなブランチを作成してそちらに切り替え、何らかの作業を行い、メインブランチに戻って別の作業をした状態です。どちらの変更も、ブランチごとに分離しています。ブランチを切り替えつつそれぞれの作業を進め、必要に応じてマージすることができます。これらをすべて、シンプルに `branch` コマンドと `checkout` コマンドで行えるのです。
85.
^
ja-no-redundant-expression: "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:99:14
v
98.
99. 1. ウェブサイトに関する作業を行っている
100. 2. 新たな作業用にブランチを作成する
^
ja-no-redundant-expression: "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:101:11
v
100. 2. 新たな作業用にブランチを作成する
101. 3. そのブランチで作業を行う
102.
^
ja-no-redundant-expression: "対応を行う"は冗長な表現です。"対応する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:149:9
v
148.
149. 次に、緊急の問題対応を行います。緊急作業用に hotfix ブランチを作成し、作業をそこで進めるようにしましょう (図 3-13 を参照ください)。
150.
^
ja-no-redundant-expression: "解消を行う"は冗長な表現です。"解消する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:262:244
v
261.
262. このような解決を各部分に対して行い、`<<<<<<<` や `=======` そして `>>>>>>>` の行をすべて除去します。そしてすべてのコンフリクトを解決したら、各ファイルに対して `git add` を実行して解決済みであることを通知します。ファイルをステージすると、Git はコンフリクトが解決されたと見なします。コンフリクトの解決をグラフィカルに行いたい場合は `git mergetool` を実行します。これは、適切なビジュアルマージツールを立ち上げてコンフリクトの解消を行います。
263.
^
ja-no-redundant-expression: "削除を行う"は冗長な表現です。"削除する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:309:21
v
308.
309. これまでにブランチの作成、マージ、そして削除を行いました。ここで、いくつかのブランチ管理ツールについて見ておきましょう。今後ブランチを使い続けるにあたって、これらのツールが便利に使えるでしょう。
310.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:318:81
v
317.
318. `*` という文字が `master` ブランチの先頭についていることに注目しましょう。これは、現在チェックアウトされているブランチを意味します。つまり、ここでコミットを行うと、`master` ブランチがひとつ先に進むということです。各ブランチにおける直近のコミットを調べるには `git branch -v` を実行します。
319.
^
ja-no-redundant-expression: "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:370:78
v
369.
370. 一方、トピックブランチはプロジェクトの規模にかかわらず便利なものです。トピックブランチとは、短期間だけ使うブランチのことで、何か特定の機能やそれに関連する作業を行うために作成します。これは、今までの VCS では実現不可能に等しいことでした。ブランチを作成したりマージしたりという作業が非常に手間のかかることだったからです。Git では、ブランチを作成して作業をし、マージしてからブランチを削除するという流れを一日に何度も繰り返すことも珍しくありません。
371.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:431:373
v
430.
431. これは、ちょっとしたショートカットです。Git はまずブランチ名 `serverfix` を `refs/heads/serverfix:refs/heads/serverfix` に展開します。これは「手元のローカルブランチ serverfix をプッシュして、リモートの serverfix ブランチを更新しろ」という意味です。`refs/heads/` の部分の意味については第 9 章で詳しく説明しますが、これは一般的に省略可能です。`git push origin serverfix:serverfix` とすることもできます。これも同じことで、「こっちの serverfix で、リモートの serverfix を更新しろ」という意味になります。この方式を使えば、ローカルブランチの内容をリモートにある別の名前のブランチにプッシュすることができます。リモートのブランチ名を `serverfix` という名前にしたくない場合は、`git push origin serverfix:awesomebranch` とすればローカルの `serverfix` ブランチをリモートの `awesomebranch` という名前のブランチ名でプッシュすることができます。
432.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:431:529
v
430.
431. これは、ちょっとしたショートカットです。Git はまずブランチ名 `serverfix` を `refs/heads/serverfix:refs/heads/serverfix` に展開します。これは「手元のローカルブランチ serverfix をプッシュして、リモートの serverfix ブランチを更新しろ」という意味です。`refs/heads/` の部分の意味については第 9 章で詳しく説明しますが、これは一般的に省略可能です。`git push origin serverfix:serverfix` とすることもできます。これも同じことで、「こっちの serverfix で、リモートの serverfix を更新しろ」という意味になります。この方式を使えば、ローカルブランチの内容をリモートにある別の名前のブランチにプッシュすることができます。リモートのブランチ名を `serverfix` という名前にしたくない場合は、`git push origin serverfix:awesomebranch` とすればローカルの `serverfix` ブランチをリモートの `awesomebranch` という名前のブランチ名でプッシュすることができます。
432.
^
✓ ja-no-redundant-expression: "することができませ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:443:156
v
442.
443. 注意すべき点は、新しいリモートブランチを取得したとしても、それが自動的にローカルで編集可能になるわけではないというところです。言い換えると、この場合に新たに `serverfix` ブランチができるわけではないということです。できあがるのは `origin/serverfix` ポインタだけであり、これは変更することができません。
444.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:497:148
v
496.
497. しかし、別の方法もあります。C3 で行った変更のパッチを取得し、それを C4 の先端に適用するのです。Git では、この作業のことを _リベース (rebasing)_ と呼んでいます。`rebase` コマンドを使用すると、一方のブランチにコミットされたすべての変更をもう一方のブランチで再現することができます。
498.
^
ja-no-redundant-expression: "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:518:35
v
517.
518. リモートブランチ上での自分のコミットをすっきりさせるために、よくこの作業を行います。たとえば、自分がメンテナンスしているのではないプロジェクトに対して貢献したいと考えている場合などです。この場合、あるブランチ上で自分の作業を行い、プロジェクトに対してパッチを送る準備ができたらそれを `origin/master` にリベースすることになります。そうすれば、メンテナは特に統合作業をしなくても単に fast-forward するだけで済ませられるのです。
519.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:524:24
v
523.
524. リベース先のブランチ以外でもそのリベースを再現することができます。たとえば図 3-31 のような歴史を考えてみましょう。トピックブランチ (`server`) を作成してサーバー側の機能をプロジェクトに追加し、それをコミットしました。その後、そこからさらにクライアント側の変更用のブランチ (`client`) を切って数回コミットしました。最後に、server ブランチに戻ってさらに何度かコミットを行いました。
525.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:524:197
v
523.
524. リベース先のブランチ以外でもそのリベースを再現することができます。たとえば図 3-31 のような歴史を考えてみましょう。トピックブランチ (`server`) を作成してサーバー側の機能をプロジェクトに追加し、それをコミットしました。その後、そこからさらにクライアント側の変更用のブランチ (`client`) を切って数回コミットしました。最後に、server ブランチに戻ってさらに何度かコミットを行いました。
525.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:538:31
v
537.
538. これで、master ブランチを fast-forward することができるようになりました (図 3-33 を参照ください)。
539.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/03-git-branching/01-chapter3.markdown:555:39
v
554.
555. これで、ベースブランチ (`master`) を fast-forward することができます。
556.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:21:70
v
20.
21. 共有ファイルシステムをマウントしているのなら、それをローカルのファイルベースのリポジトリにクローンしたりお互いの間でプッシュやプルをしたりすることができます。この手のリポジトリをクローンしたり既存のプロジェクトのリモートとして追加したりするには、リポジトリへのパスを URL に指定します。たとえば、ローカルリポジトリにクローンするにはこのようなコマンドを実行します。
22.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:35:47
v
34.
35. そうすれば、このリモートとの間のプッシュやプルを、まるでネットワーク越しにあるのと同じようにすることができます。
36.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:65:305
v
64.
65. SSH を使う利点は多数あります。まず、ネットワーク越しでのリポジトリへの書き込みアクセスで認証が必要となる場面では、基本的にこのプロトコルを使わなければなりません。次に、一般的に SSH 環境の準備は容易です。SSH デーモンはごくありふれたツールなので、ネットワーク管理者の多くはその使用経験があります。また、多くの OS に標準で組み込まれており、管理用ツールが付属しているものもあります。さらに、SSH 越しのアクセスは安全です。すべての転送データは暗号化され、信頼できるものとなります。最後に、Git プロトコルや Local プロトコルと同程度に効率的です。転送するデータを可能な限りコンパクトにすることができます。
66.
^
ja-no-redundant-expression: "プッシュを行う"は冗長な表現です。"プッシュする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:99:15
v
98.
99. HTTP 越しの Git のプッシュを行うことも可能ですが、あまり使われていません。また、これには複雑な WebDAV の設定が必要です。めったに使われることがないので、本書では取り扱いません。HTTP でのプッシュに興味があるかたのために、それ用のリポジトリを準備する方法が `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` で公開されています。HTTP 越しでの Git のプッシュに関して、よいお知らせがひとつあります。どんな WebDAV サーバーでも使うことが可能で、特に Git ならではの機能は必要ありません。つまり、もしプロバイダが WebDAV によるウェブサイトの更新に対応しているのなら、それを使用することができます。
100.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:99:373
v
98.
99. HTTP 越しの Git のプッシュを行うことも可能ですが、あまり使われていません。また、これには複雑な WebDAV の設定が必要です。めったに使われることがないので、本書では取り扱いません。HTTP でのプッシュに興味があるかたのために、それ用のリポジトリを準備する方法が `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` で公開されています。HTTP 越しでの Git のプッシュに関して、よいお知らせがひとつあります。どんな WebDAV サーバーでも使うことが可能で、特に Git ならではの機能は必要ありません。つまり、もしプロバイダが WebDAV によるウェブサイトの更新に対応しているのなら、それを使用することができます。
100.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:105:83
v
104.
105. HTTPS で読み込み専用のリポジトリを公開することもできます。これで、転送されるコンテンツを暗号化したりクライアント側で特定の署名つき SSL 証明書を使わせたりすることができるようになります。そこまでやるぐらいなら SSH の公開鍵を使うほうが簡単ではありますが、場合によっては署名入り SSL 証明書やその他の HTTP ベースの認証方式を使った HTTPS での読み込み専用アクセスを使うこともあるでしょう。
106.
^
✓ ja-no-redundant-expression: "することができない"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:111:171
v
110.
111. HTTP によるリポジトリの提供の問題点は、クライアント側から見て非効率的だということです。リポジトリのフェッチやクローンには非常に時間がかかります。また、他のネットワークプロトコルにくらべてネットワークのオーバーヘッドや転送量が非常に増加します。必要なデータだけをやりとりするといった賢い機能はない (サーバー側で転送時になんらかの作業をすることができない) ので、HTTP はよく _ダム (dumb)_ プロトコルなどと呼ばれています。HTTP とその他のプロトコルの間の効率の違いに関する詳細な情報は、第 9 章を参照ください。
112.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:139:163
v
138.
139. ユーザーが SSH でアクセスでき、かつ `/opt/git/my_project.git` ディレクトリへの書き込みアクセス権限があれば、すでにプッシュもできる状態になっています。`git init` コマンドで `--shared` オプションを指定すると、リポジトリに対するグループ書き込みパーミッションを自動的に追加することができます。
140.
^
ja-no-redundant-expression: "プログラムを実行"は冗長な表現です。"プログラムする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:176:193
v
175.
176. そして「○○」「○○.pub」というファイル名の組み合わせを探します。「○○」の部分は、通常は `id_dsa` あるいは `id_rsa` となります。もし見つかったら、`.pub` がついているほうのファイルがあなたの公開鍵で、もう一方があなたの秘密鍵です。そのようなファイルがない (あるいはそもそも `.ssh` ディレクトリがない) 場合は、`ssh-keygen` というプログラムを実行してそれを作成します。このプログラムは Linux/Mac なら SSH パッケージに含まれており、Windows では MSysGit パッケージに含まれています。
177.
^
ja-no-redundant-expression: "認証を行う"は冗長な表現です。"認証する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:204:75
v
203.
204. それでは、サーバー側での SSH アクセスの設定について順を追って見ていきましょう。この例では `authorized_keys` 方式でユーザーの認証を行います。また、Ubuntu のような標準的な Linux ディストリビューションを動かしているものと仮定します。まずは 'git' ユーザーを作成し、そのユーザーの `.ssh` ディレクトリを作りましょう。
205.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:519:55
v
518.
519. Gitolite は、単なるリポジトリ単位の権限付与だけではなくリポジトリ内のブランチやタグ単位で権限を付与することができます。つまり、特定の人 (あるいはグループ) にだけ特定の "refs" (ブランチあるいはタグ) に対するプッシュ権限を与えて他の人には許可しないといったことができるのです。
520.
^
ja-no-redundant-expression: "､を実行"は冗長な表現です。"､する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:536:84
v
535.
536. 最後に､あなたのワークステーションに戻って､`git clone git@gitserver:gitolite-admin`を実行します｡これで完了です! Gitolite はサーバにインストールされ、`gitolite-admin` という新しいリポジトリがあなたのワークステーションにできあがりました。Gitolite の設定を管理するには、このリポジトリに変更を加えてプッシュします。
537.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:576:22
v
575.
576. パーミッションは、"ref" レベルで設定することができます。次の例では、インターン (@interns) は "int" ブランチにしかプッシュできないように設定しています。エンジニア (@engineers) は名前が "eng-" で始まるすべてのブランチにプッシュでき、また "rc" のあとに一桁の数字が続く名前のタグにもプッシュできます。また、管理者 (@admins) はすべての ref に対してあらゆることができます。
577.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:636:56
v
635.
636. Gitolite では、ワイルドカード (実際のところは Perl の正規表現です) を使ってリポジトリを指定することができます。たとえば `assignments/s[0-9][0-9]/a[0-9][0-9]` のようにします。この機能を使うと、新たな権限モード (`C`) が用意されます。これは、ワイルドカードにマッチするリポジトリの作成を許可するモードです。新たに作成したリポジトリの所有者は自動的にそのユーザに設定され、他のユーザに `R` あるいは `RW` の権限を付与できるようになります。この機能についても､詳細はドキュメントを確認してください｡
637.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:658:66
v
657.
658. **ミラーリング**: Gitolite は、複数のミラーを保守したり、プライマリサーバーが落ちたときに簡単にミラーに切り替えたりすることができます。
659.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:666:30
v
665.
666. いずれにせよ、Git プロトコルは比較的容易にセットアップすることができます。デーモン化するためには、このようなコマンドを実行します。
667.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:695:109
v
694.
695. 次に、どのプロジェクトに対して Git プロトコルでの認証なしアクセスを許可するのかを Gitosis に指定します。各リポジトリ用のセクションを追加すれば、Git デーモンからの読み込みアクセスを許可するように指定することができます。Git プロトコルでのアクセスを `iphone_project`に許可したい場合は、`gitosis.conf` の最後に次のように追加します。
696.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:738:263
v
737.
738. GitHub がその他多くのコードホスティングサイトと異なるのは、プロジェクトの位置づけです。プロジェクトを主体に考えるのではなく、GitHub ではユーザー主体の構成になっています。私が GitHub に `grit` プロジェクトを公開したとして、それは `github.com/grit` ではなく `github.com/schacon/grit` となります。どのプロジェクトにも「正式な」バージョンというものはありません。たとえ最初の作者がプロジェクトを放棄したとしても、それをユーザーからユーザーへと自由に移動することができます。
739.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:740:86
v
739.
740. GitHub は営利企業なので、非公開のリポジトリについては料金をとって管理しています。しかし、フリーのアカウントを取得すればオープンソースのプロジェクトを好きなだけ公開することができます。その方法についてこれから説明します。
741.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:794:96
v
793.
794. Public Clone URL は、読み込み専用の公開 URL で、これを使えば誰でもプロジェクトをクローンできます。この URL は、あなたのウェブサイトをはじめとしたお好みの場所で紹介することができます。
795.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:835:253
v
834.
835. 他の人がこのプロジェクトにアクセスしたときに見えるのがこのページとなります。このページには、さまざまな情報を見るためのタブが用意されています。Commits タブに表示されるのはコミットの一覧で、`git log` コマンドの出力と同様にコミット時刻が新しい順に表示されます。Network タブには、このプロジェクトをフォークして何か貢献してくれた人の一覧が表示されます。Downloads タブには、プロジェクト内でタグが打たれている任意の点について tar や zip でまとめたものをアップロードすることができます。Wiki タブには、プロジェクトに関するドキュメントやその他の情報を書き込むための wiki が用意されています。Graphs タブは、プロジェクトに対する貢献やその他の統計情報を視覚化して表示します。そして、Source タブにはプロジェクトのメインディレクトリの一覧が表示され、もし README ファイルがあればその内容が下に表示されます。このタブでは、最新のコミットについての情報も表示されます。
836.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/04-git-server/01-chapter4.markdown:861:52
v
860.
861. 自前でサーバーを構築すれば、多くのことを制御できるようになり、ファイアウォールの内側でもサーバーを実行することができます。しかし、サーバーを構築して運用するにはそれなりの手間がかかります。ホスティングサービスを使えば、サーバーの準備や保守は簡単になります。しかし、他人のサーバー上に自分のコードを置き続けなければなりません。組織によってはそんなことを許可していないかもしれません。
862.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:9:236
v
8.
9. 中央管理型のバージョン管理システム (Centralized Version Control System: CVCS) とは違い、Git は分散型だという特徴があります。この特徴を生かすと、プロジェクトの開発者間での共同作業をより柔軟に行えるようになります。中央管理型のシステムでは、個々の開発者は中央のハブに対するノードという位置づけとなります。しかし Git では、各開発者はノードであると同時にハブにもなり得ます。つまり、誰もが他のリポジトリに対してコードを提供することができ、誰もが公開リポジトリを管理して他の開発者の作業を受け入れることもできるということです。これは、みなさんのプロジェクトや開発チームでの作業の流れにさまざまな可能性をもたらします。本章では、この柔軟性を生かすいくつかの実例を示します。それぞれについて、利点だけでなく想定される弱点についても扱うので、適宜取捨選択してご利用ください。
10.
^
✓ ja-no-redundant-expression: "することができるから"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:50:109
v
49.
50. この手のワークフローはあまり一般的ではありませんが、大規模なプロジェクトや高度に階層化された環境では便利です。プロジェクトリーダー (独裁者) が大半の作業を委譲し、サブセット単位である程度まとまってからコードを統合することができるからです。
51.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:58:75
v
57.
58. これは非常に説明しづらい内容です。というのも、ほんとうにいろいろなパターンがあるからです。Git は柔軟なシステムなので、いろいろな方法で共同作業をすることができます。そのせいもあり、どのプロジェクトをとってみても微妙に他とは異なる方式を使っているのです。違いが出てくる原因としては、アクティブな貢献者の数やプロジェクトで使用しているワークフロー、あなたのコミット権、そして外部からの貢献を受け入れる際の方式などがあります。
59.
^
ja-no-redundant-expression: "コミットを行う"は冗長な表現です。"コミットする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:60:106
v
59.
60. 最初の要素はアクティブな貢献者の数です。そのプロジェクトに対してアクティブにコードを提供している開発者はどれくらいいるのか、そして彼らはどれくらいの頻度で提供しているのか。よくあるのは、数名の開発者が一日数回のコミットを行うというものです。休眠状態のプロジェクトなら、もう少し頻度が低くなるでしょう。大企業や大規模なプロジェクトでは、開発者の数が数千人になることもあります。数十から下手したら百を超えるようなパッチが毎日やってきます。開発者の数が増えれば増えるほど、あなたのコードをきちんと適用したり他のコードをマージしたりするのが難しくなります。あなたが手元で作業をしている間に他の変更が入って、手元で変更した内容が無意味になってしまったりあるいは他の変更を壊してしまう羽目になったり。そのせいで、手元の変更を適用してもらうための待ち時間が発生したり。手元のコードを常に最新の状態にし、正しいパッチを作るにはどうしたらいいのでしょうか。
61.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:84:162
v
83.
84. 次に、コミットの単位が論理的に独立した変更となるようにしましょう。つまり、個々の変更内容を把握しやすくするということです。週末に五つの問題点を修正した大規模な変更を、月曜日にまとめてコミットするなどということは避けましょう。仮に週末の間にコミットできなかったとしても、ステージングエリアを活用して月曜日にコミット内容を調整することができます。修正した問題ごとにコミットを分割し、それぞれに適切なコメントをつければいいのです。もし別々の問題の修正で同じファイルを変更しているのなら、`git add --patch` を使ってその一部だけをステージすることもできます (詳しくは第 6 章で説明します)。すべての変更を同時に追加しさえすれば、一度にコミットしようが五つのコミットに分割しようがブランチの先端は同じ状態になります。あとから変更内容をレビューする他のメンバーのことも考えて、できるだけレビューしやすい状態でコミットするようにしましょう。こうしておけば、あとからその変更の一部だけを取り消したりするのにも便利です。第 6 章では、Git を使って歴史を書き換えたり対話的にファイルをステージしたりする方法を説明します。第 6 章で説明する方法を使えば、きれいでわかりやすい歴史を作り上げることができます。
85.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:607:342
v
606.
607. これは、作業ディレクトリ内のファイルを変更します。`patch -p1` コマンドでパッチをあてるのとほぼ同じなのですが、それ以上に「これでもか」というほどのこだわりを持ってパッチを適用するので fuzzy マッチになる可能性が少なくなります。また、`git diff` 形式ではファイルの追加・削除やファイル名の変更も扱うことができますが、`patch` コマンドにはそれはできません。そして最後に、`git apply` は「全部適用するか、あるいは一切適用しないか」というモデルを採用しています。一方 `patch` コマンドの場合は、途中までパッチがあたった中途半端な状態になって困ることがあります。`git apply` のほうが、 `patch` よりもこだわりを持った処理を行うのです。`git apply` コマンドはコミットを作成するわけではありません。実行した後で、その変更をステージしてコミットする必要があります。
608.
^
ja-no-redundant-expression: "削除を行う"は冗長な表現です。"削除する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:707:144
v
706.
707. この方法は、誰かと継続的に共同作業を進めていく際に便利です。ちょっとしたパッチをたまに提供してくれるだけの人の場合は、パッチをメールで受け取るようにしたほうが時間の節約になるでしょう。全員に自前のサーバーを用意させて、たまに送られてくるパッチを取得するためだけに定期的にリモートの追加と削除を行うなどというのは時間の無駄です。ほんの数件のパッチを提供してくれる人たちを含めて数百ものリモートを管理することなど、きっとあなたはお望みではないでしょう。しかし、スクリプトやホスティングサービスを使えばこの手の作業は楽になります。つまり、どのような方式をとるかは、あなたや他のメンバーがどのような方式で開発を進めるかによって決まります。
708.
^
✓ ja-no-redundant-expression: "することができ、"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:788:55
v
787.
788. 他の人があなたのプロジェクトをクローンするときには、master をチェックアウトすれば最新の安定版をビルドすることができ、その後の更新を追いかけるのも容易にできるようになります。一方 develop をチェックアウトすれば、さらに最先端の状態を取得することができます。この考え方を推し進めると、統合用のブランチを用意してすべての作業をいったんそこにマージするようにもできます。統合ブランチ上のコードが安定してテストを通過すれば、それを develop ブランチにマージします。そしてそれが安定していることが確認できたら master ブランチを先に進めるということになります。
789.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:788:126
v
787.
788. 他の人があなたのプロジェクトをクローンするときには、master をチェックアウトすれば最新の安定版をビルドすることができ、その後の更新を追いかけるのも容易にできるようになります。一方 develop をチェックアウトすれば、さらに最先端の状態を取得することができます。この考え方を推し進めると、統合用のブランチを用意してすべての作業をいったんそこにマージするようにもできます。統合ブランチ上のコードが安定してテストを通過すれば、それを develop ブランチにマージします。そしてそれが安定していることが確認できたら master ブランチを先に進めるということになります。
789.
^
✓ ja-no-redundant-expression: "することができるという"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/05-distributed-git/01-chapter5.markdown:802:176
v
801.
802. 最終的に `master` にマージされたトピックブランチは、リポジトリから削除します。Git 開発プロジェクトでは `maint` ブランチも管理しています。これは最新のリリースからフォークしたもので、メンテナンスリリースに必要なバックポート用のパッチを管理します。つまり、Git のリポジトリをクローンするとあなたは四つのブランチをチェックアウトすることができるということです。これらのブランチはどれも異なる開発段階を表し、「どこまで最先端を追いかけたいか」「どのように Git プロジェクトに貢献したいか」によって使い分けることになります。メンテナ側では、新たな貢献を受け入れるためのワークフローが整っています。
803.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:13:28
v
12.
13. SHA-1 ハッシュを指定すれば、コミットを明確に参照することができます。しかしそれ以外にも、より人間にやさしい方式でコミットを参照することもできます。このセクションでは単一のコミットを参照するためのさまざまな方法の概要を説明します。
14.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:67:92
v
66.
67. 特定のコミットを参照するのに一番直感的なのは、そのコミットを指すブランチがある場合です。コミットオブジェクトや SHA-1 値を指定する場面ではどこでも、その代わりにブランチ名を指定することができます。たとえば、あるブランチ上の最新のコミットを表示したい場合は次のふたつのコマンドが同じ意味となります (`topic1` ブランチが `ca82a6d` を指しているものとします)。
68.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:92:142
v
91.
92. 何らかの理由でブランチの先端が更新されるたびに、Git はその情報をこの一時履歴に格納します。そして、このデータを使って過去のコミットを指定することもできます。リポジトリの HEAD の五つ前の状態を知りたい場合は、先ほど見た reflog の出力のように `@{n}` 形式で参照することができます。
93.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:399:153
v
398.
399. simplegit.rb のステータスがおもしろいことになっています。ステージされた行もあれば、ステージされていない行もあるという状態です。つまり、このファイルを部分的にステージしたというわけです。この時点で対話的追加モードを抜けて `git commit` を実行すると、ステージした部分だけをコミットすることができます。
400.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:411:88
v
410.
411. 例を見てみましょう。自分のプロジェクトでいくつかのファイルを編集し、その中のひとつをステージしたとします。ここで `git status` を実行すると、ダーティな状態を確認することができます。
412.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:522:36
v
521.
522. これを使うと、保存していた作業をお手軽に復元して新しいブランチで作業をすることができます。
523.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:526:142
v
525.
526. Git を使って作業をしていると、何らかの理由でコミットの歴史を書き換えたくなることが多々あります。Git のすばらしい点のひとつは、何をどうするかの決断をぎりぎりまで先送りできることです。どのファイルをどのコミットに含めるのかは、ステージングエリアの内容をコミットする直前まで変更することができますし、既に作業した内容でも stash コマンドを使えばまだ作業していないことにできます。また、すでにコミットしてしまった変更についても、それを書き換えてまるで別の方法で行ったかのようにすることもできます。コミットの順序を変更したり、コミットメッセージやコミットされるファイルを変更したり、複数のコミットをひとつにまとめたりひとつのコミットを複数に分割したり、コミットそのものをなかったことにしたり……といった作業を、変更内容を他のメンバーに公開する前ならいつでもすることができます。
527.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:526:382
v
525.
526. Git を使って作業をしていると、何らかの理由でコミットの歴史を書き換えたくなることが多々あります。Git のすばらしい点のひとつは、何をどうするかの決断をぎりぎりまで先送りできることです。どのファイルをどのコミットに含めるのかは、ステージングエリアの内容をコミットする直前まで変更することができますし、既に作業した内容でも stash コマンドを使えばまだ作業していないことにできます。また、すでにコミットしてしまった変更についても、それを書き換えてまるで別の方法で行ったかのようにすることもできます。コミットの順序を変更したり、コミットメッセージやコミットされるファイルを変更したり、複数のコミットをひとつにまとめたりひとつのコミットを複数に分割したり、コミットそのものをなかったことにしたり……といった作業を、変更内容を他のメンバーに公開する前ならいつでもすることができます。
527.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:538:59
v
537.
538. これを実行するとテキストエディタが開きます。すでに直近のコミットメッセージが書き込まれた状態になっており、それを変更することができます。変更を保存してエディタを終了すると、変更後のメッセージを含む新しいコミットを作成して直近のコミットをそれで置き換えます。
539.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:542:20
v
541.
542. この技を使う際には注意が必要です。この処理を行うとコミットの SHA-1 が変わるからです。いわば、非常に小規模なリベースのようなものです。すでにプッシュしているコミットは書き換えないようにしましょう。
543.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:546:197
v
545.
546. さらに歴史をさかのぼったコミットを変更したい場合は、もう少し複雑なツールを使わなければなりません。Git には歴史を修正するツールはありませんが、リベースツールを使って一連のコミットを (別の場所ではなく) もともとあった場所と同じ HEAD につなげるという方法を使うことができます。対話的なリベースツールを使えば、各コミットについてメッセージを変更したりファイルを追加したりお望みの変更をすることができます。対話的なリベースを行うには、`git rebase` に `-i` オプションを追加します。どこまでさかのぼってコミットを書き換えるかを指示するために、どのコミットにリベースするかを指定しなければなりません。
547.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:681:227
v
680.
681. 変更を保存してエディタを終了すると、Git はリストの最初のコミットの親まで処理を巻き戻します。そして最初のコミット (`f7f3f6d`) と二番目のコミット (`310154e`) を適用してからコンソールに戻ります。コミットをリセットするには `git reset HEAD^` を実行します。これはコミット自体を取り消し、変更されたファイルはステージしていない状態にします。ここまでくれば､取り消された変更点から必要なものだけを選択してコミットすることができます｡一連のコミットが終わったら､以下のように`git rebase --continue` を実行しましょう｡
682.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:728:197
v
727.
728. もうひとつよくある例としては、「作業を始める前に `git config` で名前とメールアドレスを設定することを忘れていた」とか「業務で開発したプロジェクトをオープンソースにするにあたって、職場のメールアドレスをすべて個人アドレスに変更したい」などがあります。どちらの場合についても、複数のコミットのメールアドレスを一括で変更することになりますが、これも `filter-branch` ですることができます。注意して、あなたのメールアドレスのみを変更しなければなりません。そこで、`--commit-filter` を使います。
729.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:788:145
v
787.
788. 自分のコードをリリースして運用環境にプッシュしたあとに、バグ報告を受け取ったと仮定しましょう。そのバグは開発環境では再現せず、なぜそんなことになるのか想像もつきません。コードをよく調べて問題を再現させることはできましたが、何が悪かったのかがわかりません。こんな場合に、二分探索で原因を特定することができます。まず、`git bisect start` を実行します。そして次に `git bisect bad` を使って、現在のコミットが壊れた状態であることをシステムに伝えます。次に、まだ壊れていなかったとわかっている直近のコミットを `git bisect good [good_commit]` で伝えます。
789.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:796:112
v
795.
796. Git は、まだうまく動いていたと指定されたコミット (v1.0) と現在の壊れたバージョンの間には 12 のコミットがあるということを検出しました。そして、そのちょうど真ん中にあるコミットをチェックアウトしました。ここでテストを実行すれば、このコミットで同じ問題が発生するかどうかがわかります。もし問題が発生したなら、実際に問題が混入したのはそれより前のコミットだということになります。そうでなければ、それ以降のコミットで問題が混入したのでしょう。ここでは、問題が発生しなかったものとします。`git bisect good` で Git にその旨を伝え、旅を続けましょう。
797.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:802:60
v
801.
802. また別のコミットがやってきました。先ほど調べたコミットと「壊れている」と伝えたコミットの真ん中にあるものです。ふたたびテストを実行し、今度はこのコミットで問題が再現したものとします。それを Git に伝えるには `git bisect bad` を使います。
803.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:830:110
v
829.
830. こうすると、チェックアウトされたコミットに対して自動的に `test-error.sh` を実行し、壊れる原因となるコミットを見つけ出すまで自動的に処理を続けます。`make` や `make tests`、その他自動テストを実行するためのプログラムなどをここで実行させることもできます。
831.
^
✓ ja-no-redundant-expression: "することができるよう"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:838:134
v
837.
838. Git では、サブモジュールを使ってこの問題に対応します。サブモジュールを使うと、ある Git リポジトリを別の Git リポジトリのサブディレクトリとして扱うことができるようになります。これで、別のリポジトリをプロジェクト内にクローンしても自分のコミットは別管理とすることができるようになります。
839.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:1044:55
v
1043.
1044. まず最初に `rack` ディレクトリをアンステージしなければなりません。それからだと、サブモジュールを追加することができます。
1045.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/06-git-tools/01-chapter6.markdown:1072:477
v
1071.
1072. サブモジュールの仕組みに関する問題を見てきました。今度は同じ問題を解決するための別の方法を見ていきましょう。Git でマージを行うときには、何をマージしなければならないのかを Git がまず調べてそれに応じた適切なマージ手法を選択します。ふたつのブランチをマージするときに Git が使うのは、_再帰 (recursive)_ 戦略です。三つ以上のブランチをマージするときには、Git は _たこ足 (octopus)_ 戦略を選択します。どちらの戦略を使うかは、Git が自動的に選択します。再帰戦略は複雑な三方向のマージ (共通の先祖が複数あるなど) もこなせますが、ふたつのブランチしか処理できないからです。たこ足マージは三つ以上のブランチを扱うことができますが、難しいコンフリクトを避けるためにより慎重になります。そこで、三つ以上のブランチをマージするときのデフォルトの戦略として選ばれています。しかし、それ以外にも選べる戦略があります。そのひとつが _サブツリー (subtree)_ マージで、これを使えば先ほどのサブプロジェクト問題に対応することができます。先ほどのセクションと同じような rack の取り込みを、サブツリーマージを用いて行う方法を紹介しましょう。
1073.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:7:49
v
6.
7. 第 1 章で手短にごらんいただいたように、`git config` コマンドで Git の設定をすることができます。まず最初にすることと言えば、名前とメールアドレスの設定でしょう。
8.
^
ja-no-redundant-expression: "読み書きを行う"は冗長な表現です。"読み書きする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:14:201
v
13.
14. Git の設定については最初の章でちらっと説明しましたが、ここでもう一度振り返っておきます。Git では、いくつかの設定ファイルを使ってデフォルト以外の挙動を定義します。まず最初に Git が見るのは `/etc/gitconfig` で、ここにはシステム上の全ユーザーの全リポジトリ向けの設定値を記述します。`git config` にオプション `--system` を指定すると、このファイルの読み書きを行います。
15.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:74:126
v
73.
74. core.pager は、Git が `log` や `diff` などを出力するときに使うページャを設定します。`more` などのお好みのページャを設定したり (デフォルトは `less` です)、空文字列を設定してページャを使わないようにしたりすることができます。
75.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:122:94
v
121.
122. どのコマンドをどのように色づけするかをより細やかに指定したい場合、コマンド単位の色づけ設定を使用します。これらの項目には `true`、`false` あるいは `always` を指定することができます。
123.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:197:56
v
196.
197. このようなラッパーを設定しておくと、あとで diff ツールやマージツールを変更したくなったときにも簡単に変更することができます。たとえば `extDiff` や `extMerge` で KDiff3 を実行させるように変更するには `extMerge` ファイルをこのように変更するだけでよいのです。
198.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:205:45
v
204.
205. Git にはさまざまなマージツール用の設定が事前に準備されており、特に設定しなくても利用することができます。事前に設定が準備されているツールは kdiff3、opendiff、tkdiff、meld、xxdiff、emerge、vimdiff そして gvimdiff です。KDiff3 を diff ツールとしてではなくマージのときにだけ使いたい場合は、kdiff3 コマンドにパスが通っている状態で次のコマンドを実行します。
206.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:219:74
v
218.
219. Git はこの問題に対処するために、コミットする際には行末の CRLF を LF に自動変換し、ファイルシステム上にチェックアウトするときには逆の変換を行うようにすることができます。この機能を使うには `core.autocrlf` を設定します。Windows で作業をするときにこれを `true` に設定すると、コードをチェックアウトするときに行末の LF を CRLF に自動変換してくれます。
220.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:219:82
v
218.
219. Git はこの問題に対処するために、コミットする際には行末の CRLF を LF に自動変換し、ファイルシステム上にチェックアウトするときには逆の変換を行うようにすることができます。この機能を使うには `core.autocrlf` を設定します。Windows で作業をするときにこれを `true` に設定すると、コードをチェックアウトするときに行末の LF を CRLF に自動変換してくれます。
220.
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:227:103
v
226.
227. この設定は、Windows にチェックアウトしたときの CRLF への変換は行いますが、Mac や Linux へのチェックアウト時は LF のままにします。またリポジトリにコミットする際には LF への変換を行います。
228.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:235:114
v
234.
235. Git には、空白文字に関する問題を見つけて修正するための設定もあります。空白文字に関する主要な四つの問題に対応するもので、そのうち二つはデフォルトで有効になっています。残りの二つはデフォルトでは有効になっていませんが、有効化することができます。
236.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:270:180
v
269.
270. すでにプッシュしたコミットをリベースしてもう一度プッシュした場合、あるいはリモートブランチが現在指しているコミットを含まないコミットをプッシュしようとした場合は、プッシュが拒否されます。これは悪くない方針でしょう。しかしリベースの場合は、自分が何をしているのかをきちんと把握していれば、プッシュの際に `-f` フラグを指定して強制的にリモートブランチを更新することができます。
271.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:280:160
v
279.
280. `denyNonFastForwards` の制限を回避する方法として、いったんブランチを削除してから新しいコミットを参照するブランチをプッシュしなおすことができます。その対策として、新しいバージョン (バージョン 1.6.1 以降) の Git では `receive.denyDeletes` を true に設定することができます。
281.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:290:104
v
289.
290. 属性を使うと、ファイルやディレクトリ単位で個別のマージ戦略を指定したりテキストファイル以外での diff の取得方法を指示したり、あるいはチェックインやチェックアウトの前に Git にフィルタリングさせたりすることができます。このセクションでは、Git プロジェクトでパスに設定できる属性のいくつかについて学び、実際にその機能を使う例を見ていきます。
291.
^
ja-no-redundant-expression: "比較を行う"は冗長な表現です。"比較する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:310:60
v
309.
310. Gitでは、バイナリファイルの差分を効果的に扱うためにGitの属性機能を使うことができます。通常のdiff機能を使って比較を行うことができるように、バイナリデータをテキストデータに変換する方法をGitに教えればいいのです。ただし問題があります。*バイナリ*データをどうやってテキストに変換するか？ということです。この場合、一番いい方法はバイナリファイル形式ごとに専用の変換ツールを使うことです。とはいえ、判読可能なテキストに変換可能なバイナリファイル形式はそう多くありません(音声データをテキスト形式に変換？うまくいかなさそうです...)。ただ、仮にそういった事例に出くわしデータをテキスト形式にできなかったとしても、ファイルの内容についての説明、もしくはメタデータを取得することはそれほど難しくないでしょう。もちろん、そのファイルについての全てがメタデータから読み取れるわけではありませんが、何もないよりはよっぽどよいはずです。
311.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:409:201
v
408.
409. その他の興味深い問題としては画像ファイルの差分があります。PNGファイルに対するひとつの方法としては、EXIF情報(多くのファイルでメタデータとして使われています)を抽出するフィルタを使う方法です。`exiftool`をダウンロードしインストールすれば、画像データをメタデータの形でテキストデータとして扱うことができます。従って、次のように設定すれば、画像データの差分をメタデータの差分という形で表示することができます。
410.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:439:203
v
438.
439. SubversionやCVSを使っていた開発者から、キーワード展開機能をリクエストされることがよくあります。これについてGitにおける主な問題は、Gitはまずファイルのチェックサムを生成するためにcommitした後にファイルに関する情報を変更できないという点です。しかし、commitするためにaddする前にファイルをcheckoutしremoveするという手順を踏めば、その時にファイルにテキストを追加することが可能です。Gitの属性はそうするための方法を2つ提供します。
440.
^
ja-no-redundant-expression: "展開を行う"は冗長な表現です。"展開する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:455:28
v
454.
455. これには、commit/checkout時にキーワード展開を行うためのフィルタを書いてやることで対応できます。このために"clean"と"smudge"フィルタがあります。特定のファイルに対して使用するフィルタを設定し、checkoutされる前("smudge" 図7-2参照)もしくはcommitされる前("clean" 図7-3参照)に指定したスクリプトが実行させるよう、`.gitattributes`ファイルで設定できます。これらのフィルタはあらゆる種類の面白い内容を実行するように設定できます。
456.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:463:156
v
462.
463. この機能に対してオリジナルのcommitメッセージは簡単な例を与えてくれています。それはcommit前にあなたのCのソースコードを`indent`プログラムに通すというものです。`*.c`ファイルに対して"indent"フィルタを実行するように、`.gitattributes`ファイルにfilter属性を設定することができます。
464.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:508:42
v
507.
508. アーカイヴを生成するとき、あるファイルやディレクトリをエクスポートしないように設定することができます。プロジェクトにはcheckinしたいがアーカイブファイルには含めたくないディレクトリやファイルがあるなら、それらに`export-ignore`を設定してやることができます。
509.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:518:108
v
517.
518. アーカイブ作成時にできる別のこととして、いくつかの簡単なキーワード展開があります。第2章で紹介した`--pretty=format`で指定できるフォーマット指定子とともに`$Format:$`文字列をファイルに追加することができます。例えば、`LAST_COMMIT`という名前のファイルをプロジェクトに追加し、`git archive`を実行した時にそれを最新のcommitの日付に変換したい場合、次のように設定します。
519.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:532:46
v
531.
532. Git属性を使えば、プロジェクトにある指定したファイルに対して異なるマージ戦略を使うようにすることができます。とても有効なオプションのひとつは、指定したファイルで競合が発生した場合に、マージを行わずにあなたの変更内容で他の誰かの変更を上書きするように設定するというものです。
533.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:562:118
v
561.
562. 最初の4つのフックはコミットプロセスに関するものです。`pre-commit`フックはコミットメッセージが入力される前に実行されます。これはいまからコミットされるであろうスナップショットを検査したり、何かし忘れた事を確認したり、事前にテストを実行したり、何かしらコードを検査する目的で使用されます。`git commit --no-verify`で回避することもできますが、このフックから0でない値が返るとコミットが中断されます。コーディングスタイルの検査（lintを実行する等）や、行末の空白文字の検査（デフォルトのフックがまさにそうです）、新しく追加されたメソッドのドキュメントが正しいかどうかの検査といったことが可能です。
563.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:564:104
v
563.
564. `prepare-commit-msg`フックは、コミットメッセージエディターが起動する直前、デフォルトメッセージが生成された直後に実行されます。コミットの作者がそれを目にする前にデフォルトメッセージを編集することができます。このフックはオプションを必要とします: 現在までのコミットメッセージを保存したファイルへのパス、コミットのタイプ、さらにamendされたコミットの場合はコミットSHA-1が必要です。このフックは普段のコミットにおいてあまり有用ではありませんが、テンプレートのコミットメッセージ・mergeコミット・squashコミット・amendコミットのようなデフォルトメッセージが自動で挿入されるコミットにおいて効果を発揮します。テンプレートのコミットメッセージと組み合わせて、動的な情報をプログラムで挿入することができます。
565.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:564:361
v
563.
564. `prepare-commit-msg`フックは、コミットメッセージエディターが起動する直前、デフォルトメッセージが生成された直後に実行されます。コミットの作者がそれを目にする前にデフォルトメッセージを編集することができます。このフックはオプションを必要とします: 現在までのコミットメッセージを保存したファイルへのパス、コミットのタイプ、さらにamendされたコミットの場合はコミットSHA-1が必要です。このフックは普段のコミットにおいてあまり有用ではありませんが、テンプレートのコミットメッセージ・mergeコミット・squashコミット・amendコミットのようなデフォルトメッセージが自動で挿入されるコミットにおいて効果を発揮します。テンプレートのコミットメッセージと組み合わせて、動的な情報をプログラムで挿入することができます。
565.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:566:135
v
565.
566. `commit-msg`フックも、現在のコミットメッセージを保存した一時ファイルへのパスをパラメータに持つ必要があります。このスクリプトが0以外の値を返した場合Gitはコミットプロセスを中断しますので、プロジェクトの状態や許可待ちになっているコミットメッセージを有効にすることができます 。この章の最後のセクションでは、このフックを使用してコミットメッセージが要求された様式に沿っているか検査するデモンストレーションを行います。
567.
^
ja-no-redundant-expression: "デモンストレーションを行う"は冗長な表現です。"デモンストレーションする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:566:199
v
565.
566. `commit-msg`フックも、現在のコミットメッセージを保存した一時ファイルへのパスをパラメータに持つ必要があります。このスクリプトが0以外の値を返した場合Gitはコミットプロセスを中断しますので、プロジェクトの状態や許可待ちになっているコミットメッセージを有効にすることができます 。この章の最後のセクションでは、このフックを使用してコミットメッセージが要求された様式に沿っているか検査するデモンストレーションを行います。
567.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:570:39
v
569.
570. コミットワークフロークライアントサイドスクリプトはあらゆるワークフローに使用することができます。clone中にスクリプトが転送される事はありませんが、これらはしばしばサーバー側で決められたポリシーを強制する目的で使用されます。これらのスクリプトは開発者を支援するために存在するのですから、いつでもオーバーライドされたり変更されたりすることがありえるとしても開発者らによってセットアップされ、メンテナンスされてしかるべきです。
571.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:574:39
v
573.
574. Eメールを使ったワークフロー用として、三種類のクライアントサイドフックを設定することができます。これらはすべて `git am` コマンドに対して起動されるものなので、ふだんの作業でこのコマンドを使っていない場合は次のセクションを読み飛ばしてもかまいません。`git format-patch` で作ったパッチを受け取ることがある場合は、ここで説明する内容が有用になるかもしれません。
575.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:576:174
v
575.
576. まず最初に実行されるフックは `applypatch-msg` です。これは引数をひとつだけ受け取ります。コミットメッセージを含む一時ファイル名です。このスクリプトがゼロ以外の値で終了した場合、Git はパッチの処理を強制終了させます。このフックを使うと、コミットメッセージの書式が正しいかどうかを確認したり、スクリプトで正しい書式に手直ししたりすることができます。
577.
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:578:137
v
577.
578. `git am` でパッチを適用するときに二番目に実行されるフックは `pre-applypatch` です。これは引数を受け取らず、パッチが適用された後に実行されます。このフックを使うと、パッチ適用後の状態をコミットする前に調べることができます。つまり、このスクリプトでテストを実行したり、その他の調査をしたりといったことができるということです。なにか抜けがあったりテストが失敗したりした場合はスクリプトをゼロ以外の値で終了させます。そうすれば、`git am` はパッチをコミットせずに強制終了します。
579.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:584:91
v
583.
584. `pre-rebase` フックは何かをリベースする前に実行され、ゼロ以外を返すとその処理を中断させることができます。このフックを使うと、既にプッシュ済みのコミットのリベースを却下することができます。Gitに含まれているサンプルの `pre-rebase` フックがちょうどこの働きをします。ただしこのサンプルは、公開ブランチの名前が next であることを想定したものです。実際に使っている安定版公開ブランチの名前に変更する必要があるでしょう。
585.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:586:88
v
585.
586. `git checkout` が正常に終了すると、`post-checkout` フックが実行されます。これを使うと、作業ディレクトリを自分のプロジェクトの環境にあわせて設定することができます。たとえば、バージョン管理対象外の巨大なバイナリファイルや自動生成ドキュメントなどを作業ディレクトリに取り込むといった処理です。
587.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:588:96
v
587.
588. 最後に説明する `post-merge` フックは、`merge` コマンドが正常に終了したときに実行されます。これを使うと、Git では追跡できないパーミッション情報などを作業ツリーに復元することができます。作業ツリーに変更が加わったときに取り込みたい Git の管理対象外のファイルの存在確認などにも使えます。
589.
^
✓ ja-no-redundant-expression: "することができるという"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:592:192
v
591.
592. クライアントサイドフックの他に、いくつかのサーバーサイドフックを使うこともできます。これは、システム管理者がプロジェクトのポリシーを強制させるために使うものです。これらのスクリプトは、サーバへのプッシュの前後に実行されます。pre フックをゼロ以外の値で終了させると、プッシュを却下してエラーメッセージをクライアントに返すことができます。つまり、プッシュに関するポリシーをここで設定することができるということです。
593.
^
✓ ja-no-redundant-expression: "することができませ"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:598:288
v
597.
598. `post-receive` フックは処理が終了した後で実行されるもので、他のサービスの更新やユーザーへの通知などに使えます。`pre-receive` フックと同様、データを標準入力から受け取ります。サンプルのスクリプトには、メーリングリストへの投稿や継続的インテグレーションサーバーへの通知、チケット追跡システムの更新などの処理が含まれています。コミットメッセージを解析して、チケットのオープン・修正・クローズなどの必要性を調べることだってできます。このスクリプトではプッシュの処理を中断させることはできませんが、クライアント側ではこのスクリプトが終了するまで接続を切断することができません。このスクリプトで時間のかかる処理をさせるときには十分注意しましょう。
599.
^
✓ ja-no-redundant-expression: "することができるの"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:713:64
v
712.
713. これで権限がわかったので、あとはプッシュされた各コミットがどのパスを変更しようとしているのかを調べれば、そのユーザーがプッシュすることができるのかどうかを判断できます。
714.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:825:127
v
824.
825. このジレンマに対する答えとして、サーバーが却下するであろう作業をするときにそれをユーザーに伝えるためのクライアントサイドフックを用意します。そうすれば、何か問題があるときにそれをコミットする前に知ることができるので、取り返しのつかなくなる前に問題を修正することができます。プロジェクトをクローンしてもフックはコピーされないので、別の何らかの方法で各ユーザーにスクリプトを配布しなければなりません。各ユーザーはそれを `.git/hooks` にコピーし、実行可能にします。フックスクリプト自体をプロジェクトに含めたり別のプロジェクトにしたりすることはできますが、各自の環境でそれをフックとして自動的に設定することはできないのです。
826.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/07-customizing-git/01-chapter7.markdown:851:117
v
850.
851. 次に、ACL で決められた範囲以外のファイルを変更していないことを確認しましょう。先ほど使った ACL ファイルのコピーがプロジェクトの `.git` ディレクトリにあれば、次のような `pre-commit` スクリプトでチェックすることができます。
852.
^
✓ ja-no-redundant-expression: "することができて"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:11:137
v
10.
11. Git の素晴しい機能のひとつに、Git と Subversion を双方向にブリッジする `git svn` があります。このツールを使うと、Subversion のクライアントとして Git を使うことができます。つまり、ローカルの作業では Git の機能を十分に活用することができて、あたかも Subversion を使っているかのように Subversion サーバーに変更をコミットすることができます。共同作業をしている人達が古き良き方法を使っているのと
12. 同時に、ローカルでのブランチ作成やマージ、ステージング・エリア、リベース、チェリーピックなどの Git の機能を使うことができるということです。共同の作業環境に Git を忍び込ませておいて、仲間の開発者たちが Git より効率良く作業できるように手助けをしつつ、Git の全面的な採用のための根回しをしてゆく、というのが賢いやり方です。Subversion ブリッジは、分散VCS の素晴しい世界へのゲートウェイ・ドラッグといえるでしょう。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:11:197
v
10.
11. Git の素晴しい機能のひとつに、Git と Subversion を双方向にブリッジする `git svn` があります。このツールを使うと、Subversion のクライアントとして Git を使うことができます。つまり、ローカルの作業では Git の機能を十分に活用することができて、あたかも Subversion を使っているかのように Subversion サーバーに変更をコミットすることができます。共同作業をしている人達が古き良き方法を使っているのと
12. 同時に、ローカルでのブランチ作成やマージ、ステージング・エリア、リベース、チェリーピックなどの Git の機能を使うことができるということです。共同の作業環境に Git を忍び込ませておいて、仲間の開発者たちが Git より効率良く作業できるように手助けをしつつ、Git の全面的な採用のための根回しをしてゆく、というのが賢いやり方です。Subversion ブリッジは、分散VCS の素晴しい世界へのゲートウェイ・ドラッグといえるでしょう。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:122:115
v
121.
122. 次に、これをプッシュして上流を変更しなければなりません。この変更が Subversion に対してどのように作用するのかに注意しましょう。オフラインで行った複数のコミットを、すべて一度に Subversion サーバーにプッシュすることができます。Subversion サーバーにプッシュするには `git svn dcommit` コマンドを使います。
123.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:164:62
v
163.
164. これで手元の作業が Subversion サーバー上の最新状態の上でなされたことになったので、無事に `dcommit` することができます。
165.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:235:122
v
234.
235. Subversion のブランチは Git のブランチとは異なります。可能ならば、Subversion のブランチは使わないようにするのがベストでしょう。しかし、Subversion のブランチの作成やコミットも、`git svn` を使ってすることができます。
236.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:256:71
v
255.
256. 複数のブランチを同時に操作するときは、ローカルブランチを `dcommit` でその Subversion ブランチにコミットするのかを設定することができます。そのためには、Subversion のブランチをインポートしてローカルブランチを作ります。`opera` ブランチを個別に操作したい場合は、このようなコマンドを実行します。
257.
^
ja-no-redundant-expression: "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:262:19
v
261.
262. `git merge` を使ってこの操作を行ったとしても、そしてそれが Subversion でのマージよりもずっと簡単だったとしても (Git は自動的に適切なマージベースを検出してくれるからね)、これは通常の Git のマージコミットとは違うということを覚えておきましょう。このデータを Subversion に書き戻すことになりますが Subversion では複数の親を持つコミットは処理できません。そのため、プッシュした後は、別のブランチ上で行ったすべての操作をひとまとめにした単一のコミットに見えてしまいます。あるブランチを別のブランチにマージしたら、元のブランチに戻って作業を続けるのは困難です。Git なら簡単なのですが。`dcommit` コマンドを実行すると、どのブランチからマージしたのかという情報はすべて消えてしまいます。そのため、それ以降のマージ元の算出は間違ったものとなります。dcommit は、`git merge` の結果をまるで `git merge --squash` を実行したのと同じ状態にしてしまうのです。残念ながら、これを回避するよい方法はありません。Subversion 側にこの情報を保持する方法がないからです。Subversion をサーバーに使う以上は、常にこの制約に縛られることになります。問題を回避するには、trunk にマージしたらローカルブランチ (この場合は `opera`) を削除しなければなりません。
263.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:357:168
v
356.
357. 先ほどの節で `git svn` の使い方を読んでいれば、話は簡単です。まず `git svn clone` でリポジトリを作り、そして Subversion サーバーを使うのをやめ、新しい Git サーバーにプッシュし、あとはそれを使い始めればいいのです。これまでの歴史が欲しいのなら、それも Subversion サーバーからプルすることができます (多少時間がかかります)。
358.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:461:197
v
460.
461. `git-p4` という識別子が各コミットに含まれることがわかるでしょう。この識別子はそのままにしておいてもかまいません。後で万一 Perforce のチェンジ番号を参照しなければならなくなったときのために使えます。しかし、もし削除したいのならここで消しておきましょう。新しいリポジトリ上で何か作業を始める前のこの段階で。`git filter-branch` を使えば、この識別子を一括削除することができます。
462.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:491:397
v
490.
491. Subversion や Perforce 以外のシステムを使っている場合は、それ用のインポートツールを探さなければなりません。CVS、Clear Case、Visual Source Safe、あるいはアーカイブのディレクトリなどのためのツールはオンラインで公開されています。これらのツールがうまく動かなかったり手元で使っているバージョン管理ツールがもっとマイナーなものだったり、あるいはインポート処理で特殊な操作をしたりしたい場合は `git fast-import` を使います。このコマンドはシンプルな指示を標準入力から受け取って、特定の Git データを書き出します。生の Git コマンドを使ったり生のオブジェクトを書きだそうとしたりする (詳細は第 9 章を参照ください) よりもずっと簡単に Git オブジェクトを作ることができます。この方法を使えばインポートスクリプトを自作することができます。必要な情報を元のシステムから読み込み、単純な指示を標準出力に出せばよいのです。そして、このスクリプトの出力をパイプで `git fast-import` に送ります。
492.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/08-git-and-other-scms/01-chapter8.markdown:599:31
v
598.
599. 先ほど定義した `export_data` メソッドを再利用することができます。この書式はコミットメッセージの書式と同じだからです。
600.
^
ja-no-redundant-expression: "仕事を行う"は冗長な表現です。"仕事する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:14:149
v
13.
14. 本書は、`checkout` や `branch`、`remote` などの約30のコマンドを用いて、Git の使い方を説明しています。ですが、Git は元々、完全にユーザフレンドリーなバージョン管理システムというよりもむしろ、バージョン管理システムのためのツール類でした。そのため、下位レベルの仕事を行うためのコマンドが沢山あり、UNIXの形式（またはスクリプトから呼ばれる形式）と密に関わりながら設計されました。これらのコマンドは、通常は "配管（plumbing）" コマンドと呼ばれ、よりユーザフレンドリーなコマンドは "磁器（porcelain）" コマンドと呼ばれます。
15.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:37:136
v
36.
37. Git は連想記憶ファイル・システムです。素晴らしい。…で、それはどういう意味なのでしょう?それは、Git のコアの部分が単純なキーバリューから成り立つデータストアである、という意味です。`hash-object` という配管コマンドを使用することで、それを実際にお見せすることができます。そのコマンドはあるデータを取り出して、それを `.git` ディレクトリに格納し、そのデータが格納された場所を示すキーを返します。まずは、初期化された新しいGit レポジトリには `objects` ディレクトリが存在しないことを確認します。
38.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:86:31
v
85.
86. これで、そのファイルを最初のバージョンに復帰（revert）することができます。
87.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:142:24
v
141.
142. また、これがツリーオブジェクトであることを検証することができます。
143.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:171:169
v
170.
171. 先ほど書き込んだ新しいツリーから作業ディレクトリを作っていれば、二つのファイルが作業ディレクトリのトップレベルに見つかり、また、最初のバージョンの test.txt ファイルが含まれている `bak` という名前のサブディレクトリが見つかります。これらの構造のために Git がデータをどのように含めているかは、図9-2のようにイメージすることができます。
172.
^
ja-no-redundant-expression: "オペレーションを行う"は冗長な表現です。"オペレーションする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:234:64
v
233.
234. 驚くべきことです。あなたは Git ヒストリーを形成するために、フロントエンドにある何かを利用することせずに、ただ下位レベルのオペレーションを行っただけなのです。これは `git add` コマンドと `git commit` コマンドを実行するときに Git が行う本質的なことなのです。それは変更されたファイルに対応して、ブロブを格納し、インデックスを更新し、ツリーを書き出します。そして、トップレベルのツリーとそれらの直前に来たコミットを参照するコミットオブジェクトを書きます。これらの三つの主要な Git オブジェクト - ブロブとツリーとコミットは、`.git/object` ディレクトリに分割されたファイルとして最初に格納されます。こちらは、例のディレクトリに今あるすべてのオブジェクトであり、それらが何を格納しているのかコメントされています。
235.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:282:196
v
281.
282. 最後に、zlibで圧縮された（zlib-deflated）コンテンツをディスク上のオブジェクトに書き込みます。オブジェクトの書き込み先のパスを決定します（SHA-1ハッシュ値の最初の2文字はサブディレクトリの名前で、残りの38文字はそのディレクトリ内のファイル名になります）。Rubyでは、`FileUtils.mkdir_p()` 関数を使用して（存在しない場合に）サブディレクトリを作成することができます。そして、`File.open()` によってファイルを開いて、前に zlib で圧縮された（zlib-compressed）コンテンツをファイルに書き出します。ファイルへの書き出しは、開いたファイルのハンドルに対して `write()` を呼ぶことで行います。
283.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:297:191
v
296.
297. すべての履歴をひと通り見るには `git log 1a410e` のように実行します。しかしそれでも履歴を辿りながらそれらすべてのオブジェクトを見つけるためには、`1a410e` が最後のコミットであることを覚えていなければなりません。SHA-1ハッシュ値を格納できるファイルが必要です。ファイル名はシンプルなもので、未加工（raw）の SHA-1ハッシュ値ではなくポインタを使用することができます。
298.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:308:59
v
307.
308. 最後のコミットはどこにあるのかを覚えるのに役立つような参照を新しく作るには、これと同じぐらいシンプルなことを技術的にすることができます。
309.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:312:54
v
311.
312. これであなたは、Git コマンドにある SHA-1のハッシュ値ではなく、たった今作成したヘッダの参照を使用することができます。
313.
^
ja-no-redundant-expression: "変更を行う"は冗長な表現です。"変更する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:319:14
v
318.
319. 参照ファイルに対して直接、変更を行うことは推奨されません。Git はそれを行うためのより安全なコマンドを提供しています。もし参照を更新したければ `update-ref` というコマンドを呼びます。
320.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:397:115
v
396.
397. オブジェクトエントリはあなたがタグ付けしたコミットの SHA-1 ハッシュ値をポイントすることに注意してください。またそれがコミットをポイントする必要がないことに注意してください。あらゆる Git オブジェクトに対してタグ付けをすることができます。例えば、Git のソースコードの保守では GPG 公開鍵をブロブオブジェクトとして追加して、それからタグ付けをします。Git ソースコードレポジトリで、以下のように実行することで公開鍵を閲覧することができます。
398.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:397:220
v
396.
397. オブジェクトエントリはあなたがタグ付けしたコミットの SHA-1 ハッシュ値をポイントすることに注意してください。またそれがコミットをポイントする必要がないことに注意してください。あらゆる Git オブジェクトに対してタグ付けをすることができます。例えば、Git のソースコードの保守では GPG 公開鍵をブロブオブジェクトとして追加して、それからタグ付けをします。Git ソースコードレポジトリで、以下のように実行することで公開鍵を閲覧することができます。
398.
^
ja-no-redundant-expression: "プッシュを実行"は冗長な表現です。"プッシュする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:405:41
v
404.
405. これから見ていく三つ目の参照のタイプはリモート参照です。リモートを追加してそれにプッシュを実行すると、Git は追加したリモートにあなたが最後にプッシュした値をを格納します。そのリモートは `refs/remotes` ディレクトリにある各ブランチを参照します。例えば、`origin` と呼ばれるリモートを追加して、それを `master` ブランチにプッシュすることができます。
406.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:405:182
v
404.
405. これから見ていく三つ目の参照のタイプはリモート参照です。リモートを追加してそれにプッシュを実行すると、Git は追加したリモートにあなたが最後にプッシュした値をを格納します。そのリモートは `refs/remotes` ディレクトリにある各ブランチを参照します。例えば、`origin` と呼ばれるリモートを追加して、それを `master` ブランチにプッシュすることができます。
406.
^
✓ ja-no-redundant-expression: "することができるの"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:533:124
v
532.
533. これに関する本当に素晴らしいことは、いつでも再パックが可能なことです。Git は時折データベースを自動的に再パックして、常により多くのスペースを確保しようと努めます。また、あなたはいつでも `git gc` を実行することによって手動で再パックをすることができるのです。
534.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:549:201
v
548.
549. デフォルトのケースでは `git remote add` コマンドを実行することで自動的に書かれます。このコマンドを実行すると、Git はサーバ上の `refs/heads/` 以下にあるすべての参照をフェッチして、ローカル上の `refs/remotes/origin/` にそれらを書きます。そのため、もしもサーバ上に `master` ブランチがあると、ローカルからそのブランチのログにアクセスすることができます。
550.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:575:76
v
574.
575. このケースでは、master ブランチのプルは早送りの参照ではなかったため拒否されました。`+` の記号を参照仕様の先頭に指定することで、それを上書きすることができます。
576.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:577:30
v
576.
577. さらに設定ファイルの中のフェッチ設定に複数の参照仕様を指定することができます。もし master と実験用のブランチを常にフェッチしたいならば、二行を追加します。
578.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:588:26
v
587.
588. しかし、似たようなことを達成するのに名前空間を使用することができます。もし一連のブランチをプッシュしてくれる QAチームがいて、master ブランチと QAチームのブランチのみを取得したいならば、設定ファイルのセクションを以下のように使用することができます。
589.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:588:121
v
587.
588. しかし、似たようなことを達成するのに名前空間を使用することができます。もし一連のブランチをプッシュしてくれる QAチームがいて、master ブランチと QAチームのブランチのみを取得したいならば、設定ファイルのセクションを以下のように使用することができます。
589.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:595:109
v
594.
595. QAチームと開発チームがローカルのブランチにプッシュして、結合チームがリモートのブランチ上でプッシュして、共同で開発するような、複雑なワークフローのプロセスであるならば、このように、名前空間によってそれらを簡単に分類することができます。
596.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:625:34
v
624.
625. Git は2つのレポジトリ間を二つの主要な方法によってデータを移行することができます。ひとつは HTTPによって、もうひとつは、`file://` や `ssh://`、また、`git://` によるトランスポートに使用される、いわゆるスマートプロトコルによって。このセクションでは、これらの主要なプロトコルがどのように機能するのかを駆け足で見ていきます。
626.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:629:168
v
628.
629. Git の over HTTPによる移行は、しばしば無口なプロトコル（dumb protocol）と言われます。なぜなら、トランスポートプロセスの最中に、サーバ側に関する Git 固有のコードは何も必要としないからです。フェッチプロセスは、一連の GET リクエストであり、クライアントはサーバ上の Gitレポジトリのレイアウトを推測することができます。simplegit ライブラリに対する `http-fetch` のプロセスを追ってみましょう。
630.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:649:109
v
648.
649. オブジェクトバック（object back）を取得します。それは、サーバ上の緩い形式のオブジェクトで、静的な HTTP GETリクエストを超えてそれをフェッチします。zlib-uncompress を使ってそれを解凍することができます。ヘッダを剥ぎ取り（strip off）それからコミットコンテンツを見てみます。
650.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:741:85
v
740.
741. リモートリポジトリ上の `upload-pack` プロセスを開始する異なった方法があります。あなたは `receive-pack` プロセスと同様に SSH経由で実行することができます。さらに、Git デーモンを介してプロセスを開始することもできます。そのデーモンは、デフォルトではサーバ上の 9418ポートを使用します。`fetch-pack` プロセスはデータを送信します。そのデータは接続後のデーモンに対して、以下のように見えます。
742.
^
ja-no-redundant-expression: "フェッチを行う"は冗長な表現です。"フェッチする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:747:11
v
746.
747. もし SSHを介してフェッチを行っているとき、`fetch-pack` は代わりにこのように実行します。
748.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:778:23
v
777.
778. 次のように手動で `auto gc` を実行することができます。
779.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:782:147
v
781.
782. 繰り返しますが、これは通常は何も行いません。約 7,000個もの緩いオブジェクトがあるか、または50以上のパックファイルがないと、Gitは実際に gc コマンドを開始しません。これらのリミットは設定ファイルの `gc.auto` と `gc.autopacklimit` によってそれぞれ変更することができます。
783.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:836:86
v
835.
836. ここでチェックアウトした2つのコミットを見つけることができますが、ここに多くの情報はありません。もっと有効な方法で同じ情報を見るためには、`git log -g` を実行することができます。これは reflog に対する通常のログ出力を提供してくれます。
837.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:855:56
v
854.
855. 一番下にあるコミットがあなたが失ったコミットのようです。そのコミットの新しいブランチを作成することでそれを復元することができます。例えば、そのコミット（ab1afef）から `recover-branch` という名前でブランチを開始することができます。
856.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:855:118
v
854.
855. 一番下にあるコミットがあなたが失ったコミットのようです。そのコミットの新しいブランチを作成することでそれを復元することができます。例えば、そのコミット（ab1afef）から `recover-branch` という名前でブランチを開始することができます。
856.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:865:191
v
864.
865. 素晴らしい。`master` ブランチがかつて存在した場所に、最初の二つのコミットを再び到達可能にして、あなたはいま `recover-branch` という名前のブランチを持っています。次に、損失の原因は reflog の中にはないある理由によるものだったと想定しましょう。`recover-branch` を取り除いて reflog を削除することによって、それをシミュレートすることができます。最初の二つのコミットは今いかなるものからも到達不能な状態です。
866.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:878:84
v
877.
878. このケースでは、あなたは浮遊コミットの後に見失ったコミットを見つけることができます。その SHA1ハッシュにポイントするブランチを加えることによって、同様にそれを復元することができます。
879.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:954:315
v
953.
954. `--index-filter` オプションは、ディスク上のチェックアウトされたファイルを変更するコマンドを渡すのではなく、ステージングエリアまたはインデックスを毎度変更することを除けば、6章で使用した `--tree-filter` オプションに似ています。特定のファイルに対して `rm file` を実行するように取り除くよりもむしろ、`git rm --cached` を実行して取り除かなければなりません。つまりディスクではなくインデックスからそれを取り除くのです。このようにする理由はスピードです。Git はあなたの除去作業の前にディスク上の各リビジョンをチェックアウトする必要がないので、プロセスをもっともっと速くすることができます。同様のタスクを `--tree-filter` を使用することで達成することができます。`git rm` に渡す `--ignore-unmatch` オプションは取り除こうとするパターンがそこにない場合にエラーを出力しないようにします。最後に、`filter-branch` に `6df7640` のコミットから後の履歴のみを再書き込みするように伝えます。なぜならこれが問題が生じた場所であることをあなたは知っているからです。さもなければ、最初から開始することになり不必要に長くかかるでしょう。
955.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/09-git-internals/01-chapter9.markdown:954:359
v
953.
954. `--index-filter` オプションは、ディスク上のチェックアウトされたファイルを変更するコマンドを渡すのではなく、ステージングエリアまたはインデックスを毎度変更することを除けば、6章で使用した `--tree-filter` オプションに似ています。特定のファイルに対して `rm file` を実行するように取り除くよりもむしろ、`git rm --cached` を実行して取り除かなければなりません。つまりディスクではなくインデックスからそれを取り除くのです。このようにする理由はスピードです。Git はあなたの除去作業の前にディスク上の各リビジョンをチェックアウトする必要がないので、プロセスをもっともっと速くすることができます。同様のタスクを `--tree-filter` を使用することで達成することができます。`git rm` に渡す `--ignore-unmatch` オプションは取り除こうとするパターンがそこにない場合にエラーを出力しないようにします。最後に、`filter-branch` に `6df7640` のコミットから後の履歴のみを再書き込みするように伝えます。なぜならこれが問題が生じた場所であることをあなたは知っているからです。さもなければ、最初から開始することになり不必要に長くかかるでしょう。
955.
^
ja-no-redundant-expression: "解消を行う"は冗長な表現です。"解消する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/progit/README.md:56:51
v
55. - 翻訳の変更をpull requestにして送る場合､pull requestのタイトルとコミットメッセージに国別の接頭詞をつけてください｡ 例) [ja] Update chapter 2.
56. - 翻訳の変更は､マージ時にコンフリクトが発生しないよう注意してください｡メンテナーはコンフリクトの解消を行いません｡
57. - ファイルが変更されてもPDF/電子書籍への変換､git-scm.comの更新がうまくいくよう､可能な限り確認してください｡
^
ja-no-redundant-expression: "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/01_introduction.md:27:28
v
26.
27. JavaScriptからCoffeeScriptに戻す変換を行うことも[js2coffee](http://js2coffee.org/)プロジェクトを用いて可能です。JavaScriptのプロジェクトをCoffeeScriptに移行する場合に特に便利です。
28.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/01_introduction.md:42:90
v
41.
42. こうすることで実行コマンド`coffee`を得ます。コマンドラインオプションを与えずに実行するとCoffeeScriptのコンソールに入りCoffeeScriptの文を手早く実行することが可能です。ファイルのコンパイルを行うには`--compile`オプションを与えます。
43.
^
ja-no-redundant-expression: "インデントを行う"は冗長な表現です。"インデントする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:53:71
v
52.
53. CoffeeScriptはとても冗長なfunction文を削除しました。そしてそれを細い矢印`->`で置き換えました。関数は1行でも良いし、インデントを行って複数行記述も可能です。関数の最後の式が暗黙的に返り値となります。つまり`return`文を使う必要がありません。関数の途中で返り値を返したい場合には使うことも可能です。
54.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:104:24
v
103.
104. 関数はJavaScriptと全く同じように実行することが可能です。括弧:`()`を付けたり、`apply()`を適用したり、`call()`を呼んだりです。しかしRubyのように、CoffeeScriptは関数が最低一つの引数と実行されれば、自動的に関数を呼出します。
105.
^
ja-no-redundant-expression: "参照を実行"は冗長な表現です。"参照する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:124:102
v
123.
124. もし実行時に1つも引数を渡さない場合、CoffeeScriptはあなたが関数の実行を意味しているのか、変数として取り扱って欲しいのか理解できません。この事実より、CoffeeScriptの処理は常に関数参照を実行するRubyとは異なり、Pythonにより近いものとなっています。このことが私のCoffeeScriptプログラムではいくつかのエラーの元となりました。従ってあなたが引数無しで関数を起動する場合には十分に気を付けて括弧を付けましょう。
125.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:198:66
v
197.
198. 否定にびっくりマーク(`!`)を用いる代わりに、`not`キーワードを用いることが可能です。それを用いることでコードをより読み易くすることが可能です。びっくりマークは簡単に見落としますから。
199.
^
ja-no-redundant-expression: "議論を行う"は冗長な表現です。"議論する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:225:217
v
224.
225. 上の例でお気付きでしょうが、CoffeeScriptは`==`演算子を`===`に変換し、`!=`を`!==`に変換します。これは私の好きなこの言語の最もシンプルな機能の1つです。この考えの背景にあるものは何でしょうか？率直に言ってJavaScriptの型変換は少し変です。そしてそれらの比較演算子は比較のために型変換を強制します。そのことが理解し難い挙動に繋り、ひいては多くのバグの元となります。この話題については第7章でより長い議論を行います。
226.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/02_syntax.md:345:54
v
344.
345. もし`null`チェックをプロパティにアクセスする前に行う場合、存在確認演算子をその前に置くだけでスキップすることが可能です。これはActive Supportの[`try`](http://guides.rubyonrails.org/active_support_core_extensions.html#try)メソッドに似ています。
346.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/03_classes.md:13:108
v
12.
13. この上の例では`Animal`がクラス名であり、かつ結果としてインスタンスの作成に用いる変数です。裏側ではCoffeeScriptはコンストラクタ関数を用いており、クラスのインスタンスを`new`演算子を用いて作成することが可能です。
14.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/03_classes.md:55:206
v
54.
55. JavaScriptにおけるコンテキストの変更は嫌なものです。以前の文法の章でCoffeeScriptがファットアロー`=>`を用いることで`this`の値を特有のコンテキストにロックすることを説明しました。関数がどのようなコンテキストの下に呼ばれようとも、関数が作成されたコンテキストの下で実行されます。つまりファットアローをインスタンスメソッドに用いることで、それが正しいコンテキストで実行されることを確認することができます。`this`は常に現在のインスタンスになります。
56.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/03_classes.md:92:81
v
91.
92. 何らかの形の継承が無ければ正しいクラスの実装にはならないでしょう。CoffeeScriptは失望させません。`extends`キーワードを用いて他のクラスを継承することが可能です。下の例では`Parrot`は`Animal`を拡張し、全てのインスタンスプロパティ、`alive()`等を継承しています。
93.
^
ja-no-redundant-expression: "処理を行う"は冗長な表現です。"処理する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/04_idioms.md:38:42
v
37.
38. 文法の章で説明したとおり、CoffeeScriptの内包表記は`map()`と同じ処理を行うことが可能です。内包表記を括弧で囲んでいることに注意して下さい。それはあなたが期待したmapを実行した結果の配列を得ることを確実にするのに**とても重要**です。
39.
^
ja-no-redundant-expression: "選択を行う"は冗長な表現です。"選択する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/04_idioms.md:64:41
v
63. 括弧を絶対に忘れないで下さい。でなければ`result`は配列の最後の要素になるでしょう。
64. CoffeeScriptの内包表記はとても自由度が高く次の例のようにとても強力な選択を行うことを可能にします。
65.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/05_compiling.md:5:151
v
4.
5. CoffeeScriptの問題はあなたとJavaScriptの間に他のレイヤーを増やすことです。CoffeeScriptのファイルが変更され、古くなる度に手動でコンパイルせねばなりません。幸いなことにCoffeeScriptはいくつかのコンパイル代替形態を持っており、開発サイクルをいくらかスムーズにすることが可能です。
6.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/05_compiling.md:65:48
v
64.
65. もしあるタスクが別のタスクに依存する場合、別のタスクを`invoke(name)`を用いて実行することが可能です。`Cakefile`にもう一つ便利なタスクを追加しましょう。`index.html`を開きソースの変更の見張りを開始します。
66.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/05_compiling.md:74:30
v
73.
74. タスクには`option()`関数を用いてオプションを定義することが可能です。引数として短かい名前、長い名前、そして説明を渡せます。
75.
^
ja-no-redundant-expression: "することが可能で"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/05_compiling.md:96:292
v
95.
96. Rails3.1ではCoffeeScriptのサポートは[Sprockets & the asset pipeline](https://github.com/sstephenson/sprockets)を通して提供されます。CoffeeScriptファイルを`app/assets/javascripts`の下に追いてください。Railsは十分に賢くリクエストを受けたときに事前にコンパイルします。JavaScriptとCoffeeScriptのファイルは特別なコメントの指示を用いて包まれ、連結されます。これは1つのリクエストでアプリケーションの全てのJavaScriptを取得することが可能であることを意味します。運用時にはRailsはコンパイル結果をディスクに記録し、キャッシュされ、高速なサービスを保障します。
97.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/06_applications.md:15:125
v
14.
15. 実際に、モジュールはあなたのコードがローカルネームスペース(コードカプセル化)の中で動くことを保障します。他のモジュールを`require()`関数で読むことができます。そして`module.exports`を通してモジュールプロパティを外部に公開することができます。それではそのことについてもう少し掘り下げてみましょう。
16.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/06_applications.md:19:34
v
18.
19. 他のモジュールやライブラリ内で`require()`を用いてロードすることが可能です。単純にモジュールの名前を渡すだけです。もしロードパスの中に存在すれば、そのモジュールを表すオブジェクトを返します。次の例をご覧下さい。
20.
^
ja-no-redundant-expression: "試用を行う"は冗長な表現です。"試用する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/06_applications.md:147:194
v
146.
147. ロジックをクライアントサイドに動かしたい場合、あなたは間違いなく何らかのテンプレートライブラリを必要とするでしょう。JavaScriptテンプレートはサーバのテンプレートとほぼ同じものです。例えばRubyのERBやPythonのテキスト内挿法のようなものでもちろんクライアントサイドでも動作します。世の中には数多くのテンプレートライブラリがあります。そのため私はあなたにいくらかの調査と試用を行うことをお勧めします。Stitchはデフォルトでは[Eco](https://github.com/sstephenson/eco)テンプレートを内部に持っています。
148.
^
ja-no-redundant-expression: "することが可能です"は冗長な表現です。"することが可能"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/06_applications.md:173:32
v
172.
173. 任意のCoffeeScriptの式をテンプレートタグの中で使用することが可能ですが、気をつけることが1つだけあります。CoffeeScriptは空白に敏感です。しかしEcoテンプレートはそうではありません。従ってインデントされたCoffeeScriptブロックを始めるEcoテンプレートタグはコロンを追加せねばなりません。インデントブロックの終わりを示すには特別なタグ`<% end %>`を使用します。次の例をご覧下さい。
174.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/06_applications.md:191:121
v
190.
191. Stichは自動的に私達のテンプレートをコンパイルして`application.js`に含めてしまいます。そして私達のアプリケーションのコントローラではテンプレートをrequireすることがモジュールのように可能で、必要なデータを渡して実行することができます。
192.
^
ja-no-redundant-expression: "チェックを実行"は冗長な表現です。"チェックする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/The-Little-Book-on-CoffeeScript/07_the_bad_parts.md:426:102
v
425.
426. ストリクトモードを許可することをお勧めしましたが、ストリクトモードは何も新しい機能をJavaScriptで使用可能にはしません。それに実際にはコードのパフォーマンスを少しだけ遅くします。VMにより多くのチェックを実行時にさせるためです。ストリクトモードで開発を行い、運用ではそれを外すのも良いでしょう。
427.
^
ja-no-redundant-expression: "公開を行う"は冗長な表現です。"公開する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/deploy.md:26:36
v
25. 使い方は、prepareゴールとperformゴールを順番に呼び出すだけです。
26. リリースするバージョンなどを対話的に指定するだけで自動的に検証・編集・公開を行います。
27.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/snapshot-and-stable.md:33:87
v
32.
33. artifactは通常1バージョンにつき1度しかdeployできませんが、SNAPSHOT修飾子を利用したバージョンは同じバージョンで何度も異なるartifactをデプロイすることができます。
34. これにより、利用者に対して *常に最新の開発版を提供することができます* 。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/snapshot-and-stable.md:34:27
v
33. artifactは通常1バージョンにつき1度しかdeployできませんが、SNAPSHOT修飾子を利用したバージョンは同じバージョンで何度も異なるartifactをデプロイすることができます。
34. これにより、利用者に対して *常に最新の開発版を提供することができます* 。
35.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/snapshot-and-stable.md:50:39
v
49.
50. 例えばバージョン `1.2.3` の開発過程において、以下の順で修飾子を利用することができます。
51.
^
ja-no-redundant-expression: "リリースを行う"は冗長な表現です。"リリースする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/snapshot-and-stable.md:62:1
61. バージョンアップではALPHA, BETA, CRとFINAL修飾子を用いたリリースを、バグ修正ではパッチバージョンや[SP修飾子を用いたリリース](http://planet.jboss.org/post/hibernate_orm_4_2_7_sp1_released)を行っています。
62.
63. ## ピリオドとダッシュの違い
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/specify-repository.md:27:24
v
26.
27. セントラルリポジトリには誰でもライブラリを公開することができます。詳細は以下のページを参照してください。
28.
^
ja-no-redundant-expression: "アクセスを行う"は冗長な表現です。"アクセスする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/deploy/specify-repository.md:33:19
v
32.
33. Mavenは基本的にWebDAVでのアクセスを行います。FTPやSSHを使用する場合は対応するプラグインの利用が必要です。
34.
^
ja-no-redundant-expression: "実装を行う"は冗長な表現です。"実装する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/create-project.md:68:7
v
67. なお、archetypeプラグインを利用するとpom.xmlを自動的に生成してくれます[^3]ので、
68. スクラッチで実装を行う場合はぜひ利用してください。以下のコマンドでMavenプロジェクトの作成を行えます。
69.
^
ja-no-redundant-expression: "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/create-project.md:76:9
v
75.
76. Eclipseで開発を行う場合、以下のコマンドでEclipseプロジェクトの作成を行ってください。
77. 作成後、メニューバーの「ファイル→インポート」から既存のEclipseプロジェクトとして取り込むことができます。
^
ja-no-redundant-expression: "作成を行う"は冗長な表現です。"作成する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/create-project.md:76:39
v
75.
76. Eclipseで開発を行う場合、以下のコマンドでEclipseプロジェクトの作成を行ってください。
77. 作成後、メニューバーの「ファイル→インポート」から既存のEclipseプロジェクトとして取り込むことができます。
^
ja-no-redundant-expression: "実装を行う"は冗長な表現です。"実装する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:4:40
v
3. Mavenプラグインの実体は、Mojo（Maven plain Old Java Object）と呼ばれるクラスです。Mavenプラグインは含まれるゴールの数だけMojoを保有します。
4. このクラスに必要なメソッドとMojoアノテーションを追加することでプラグインの実装を行います。
5.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:50:51
v
49.
50. `@Mojo`アノテーションの`defaultPhase`オプションによって、実行するフェーズを指定することができます。
51. この設定はユーザの設定によって上書くことが可能ですが、デフォルト設定で多くの環境で問題なく動作することが望ましいでしょう。
^
✓ ja-no-redundant-expression: "することができるため"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:56:16
v
55. プラグインは様々なプロジェクトに対応するため、しばしば設定を提供します。
56. 設定は`pom.xml`に記載することができるため、同じ設定を複数の環境で容易に共有することができます。
57. 一般的な設定としては以下があります。`
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:56:43
v
55. プラグインは様々なプロジェクトに対応するため、しばしば設定を提供します。
56. 設定は`pom.xml`に記載することができるため、同じ設定を複数の環境で容易に共有することができます。
57. 一般的な設定としては以下があります。`
^
ja-no-redundant-expression: "実行を行う"は冗長な表現です。"実行する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:59:28
v
58.
59. * `<skip>` ... trueならプラグインの実行を行いません。プロジェクト固有のプロパティで指定できることもあります。
60. * `<outputDirectory>` ... 成果物の出力先ディレクトリです。`project.build.directory`プロパティが示すディレクトリ、あるいはそのサブディレクトリをデフォルト値として使用するべき[^1]です。
^
ja-no-redundant-expression: "出力を行う"は冗長な表現です。"出力する"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:83:26
v
82. なお引数に渡す文字列には、改行コードを含めないことをおすすめします。接頭辞がつかない行ができてしまい、
83. 機械的に処理することが難しくなるためです。複数行の出力を行いたい場合は、メソッドを複数回に分けて
84. 呼び出してください。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/unit-test.md:60:14
v
59. そのディレクトリ名を`getBasedir()`メソッドに渡すことで、ダミープロジェクトの設定を元に
60. Mojoインスタンスを作成することができます。
61.
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/unit-test.md:116:51
v
115.
116. `Mojo`インタフェースはロガーをセットするメソッドを提供していますので、モックオブジェクトを利用することができます。
117. 以下のコードは[Mockito](https://github.com/mockito/mockito)を利用してデバッグログの出力内容を確認するものです。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/module/option.md:15:39
v
14.
15. `--projects`オプションを使うことで、特定のモジュールだけをビルドすることができます。
16. 例えば次のコマンドはcoreモジュールだけをinstallします。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/module/option.md:53:13
v
52. ビルドが失敗してそれを修正した場合、ビルドを最初からやり直す必要はありません。修正したモジュールからビルドを再開することで、
53. ビルドにかかる時間を短縮することができます。ビルドを開始したいモジュールを`--resume-from`で指定してください。
54.
^
✓ ja-no-redundant-expression: "することができまし"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/primer/abstract.md:53:23
v
52.
53. Antでは各targetの間に依存関係を明示することができました。
54. 例えば以下のXMLは、packageを実行する前にcompileを実行しなければならないことを意味しています。
^
ja-no-redundant-expression: "テストを実行"は冗長な表現です。"テストする"など簡潔な表現にすると文章が明瞭になります。参考: http://www.atmarkit.co.jp/ait/articles/1001/19/news106_2.html
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/primer/build-lifecycle.md:42:18
v
41.
42. 先ほどMavenがコンパイルや自動テストを実行したのは、packageフェーズを実行するために必要なvalidateからprepare-packageまでの16のフェーズすべてを実行したためです。
43. こうしたフェーズの依存関係によって、Mavenユーザはやりたいことだけを伝えるだけで済むのです。
^
✓ ja-no-redundant-expression: "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。参考: http://qiita.com/takahi-i/items/a93dc2ff42af6b93f6e0
/Users/azu/.nodebrew/node/v11.5.0/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/primer/maven-repository.md:16:50
v
15.
16. 何らかの理由でセントラルリポジトリにライブラリを公開したくない場合、自分でリポジトリを用意して利用することができます。このリポジトリのことをプライベートリポジトリと呼びます。WEBDAVが使えるサーバならなんでもプライベートリポジトリとして使えますが、Apache Archivaや[Nexus](http://www.sonatype.org/nexus/)などの管理機能を持つウェブアプリケーションを使うと便利です。
17.
