Skip to content

Instantly share code, notes, and snippets.

@azu
Last active January 8, 2019 13:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save azu/4bf42bf27c8fcfd480b66bedbd0e0117 to your computer and use it in GitHub Desktop.
Save azu/4bf42bf27c8fcfd480b66bedbd0e0117 to your computer and use it in GitHub Desktop.
dict 5,6のみ
ja-no-redundant-expression: 【dict5】 "演算を行う"は冗長な表現です。"演算する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/Hatena-Textbook/database-programming.md:145:38
v
144. * レコードは「カラム (属性) 」を持つ
145. * SQL と呼ばれる言語に基づいて、テーブルを定義したりテーブルに対して演算を行うことができる
146.
^
ja-no-redundant-expression: 【dict5】 "問い合わせを行う"は冗長な表現です。"問い合わせする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "呼び出しを行う"は冗長な表現です。"呼び出しする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "通信を行う"は冗長な表現です。"通信する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "公表を行う"は冗長な表現です。"公表する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "修正を行う"は冗長な表現です。"修正する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "構築を行う"は冗長な表現です。"構築する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "破棄を行う"は冗長な表現です。"破棄する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "オペレーションを実行"は冗長な表現です。"オペレーションする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "操作を実行"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "調整を行う"は冗長な表現です。"調整する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "説明を行う"は冗長な表現です。"説明する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "定義を行う"は冗長な表現です。"定義する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "操作を実行"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "解説を行う"は冗長な表現です。"解説する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "判定を行う"は冗長な表現です。"判定する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "判定を行う"は冗長な表現です。"判定する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "登録を行う"は冗長な表現です。"登録する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "翻訳を行う"は冗長な表現です。"翻訳する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "計算を行う"は冗長な表現です。"計算する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "計算を行う"は冗長な表現です。"計算する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "宣伝を行う"は冗長な表現です。"宣伝する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "宣伝を行う"は冗長な表現です。"宣伝する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "機能を実行"は冗長な表現です。"機能する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "ダウンロードを実行"は冗長な表現です。"ダウンロードする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "解説を行う"は冗長な表現です。"解説する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "追加を行う"は冗長な表現です。"追加する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "足し算を行う"は冗長な表現です。"足し算する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:8:6
v
7. 演算子はよく利用する計算を関数やメソッドではなく、記号として表現したものです。
8. たとえば、足し算を行う `+` も演算子の一種で、演算子には多くの種類があります。
9.
^
ja-no-redundant-expression: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:178:28
v
177. 単項マイナス演算子も文字列などを数値へ変換します。
178. 単項プラス演算子と同様で、単項マイナス演算子で数値への変換を行うべきではありません。
179.
^
ja-no-redundant-expression: 【dict5】 "比較を行う"は冗長な表現です。"比較する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:301:25
v
300. しかし、等価演算子(`==`)はオペランド同士が異なる型の値であった場合に、
301. 同じ型となるように**暗黙的な型変換**してから比較を行います。
302.
^
ja-no-redundant-expression: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:357:47
v
356.
357. 不等価演算子も、等価演算子(`==`)と同様に異なる型のオペランドを比較する際に、暗黙的な型変換を行ってから比較します。
358.
^
ja-no-redundant-expression: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/operator/README.md:368:10
v
367. そのため、不等価演算子(`!=`)は、利用するべきではありません。
368. 代わりに暗黙的な型変換を行わない厳密不等価演算子(`!==`)を利用します。
369.
^
ja-no-redundant-expression: 【dict5】 "表示を行う"は冗長な表現です。"表示する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/read-eval-print/README.md:23:41
v
22.
23. JavaScriptの多くの実行環境では、Console APIが**コンソール表示**を行うAPIとなっています。
24. `console.log(引数)`の引数にコンソール表示したい値を入れることで、評価結果がコンソールに表示されます。
^
ja-no-redundant-expression: 【dict5】 "結合を行う"は冗長な表現です。"結合する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/js-primer/string/README.md:62:19
v
61.
62. 特定の書式に値を埋め込みために文字列結合を行う場合には、
63. テンプレートリテラルを使うとより宣言的に書くことができます。
^
ja-no-redundant-expression: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "展開を行う"は冗長な表現です。"展開する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "レビューを行う"は冗長な表現です。"レビューする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "追加を行う"は冗長な表現です。"追加する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "補完を行う"は冗長な表現です。"補完する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "対応を行う"は冗長な表現です。"対応する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "解消を行う"は冗長な表現です。"解消する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "削除を行う"は冗長な表現です。"削除する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "作業を行う"は冗長な表現です。"作業する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "認証を行う"は冗長な表現です。"認証する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "削除を行う"は冗長な表現です。"削除する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "読み書きを行う"は冗長な表現です。"読み書きする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "比較を行う"は冗長な表現です。"比較する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "展開を行う"は冗長な表現です。"展開する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "デモンストレーションを行う"は冗長な表現です。"デモンストレーションする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "操作を行う"は冗長な表現です。"操作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "仕事を行う"は冗長な表現です。"仕事する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "オペレーションを行う"は冗長な表現です。"オペレーションする"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変更を行う"は冗長な表現です。"変更する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "解消を行う"は冗長な表現です。"解消する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "変換を行う"は冗長な表現です。"変換する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict6】 "参照を実行"は冗長な表現です。"参照する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict6
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "議論を行う"は冗長な表現です。"議論する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "選択を行う"は冗長な表現です。"選択する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "試用を行う"は冗長な表現です。"試用する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "公開を行う"は冗長な表現です。"公開する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "実装を行う"は冗長な表現です。"実装する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "作成を行う"は冗長な表現です。"作成する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "実装を行う"は冗長な表現です。"実装する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "実行を行う"は冗長な表現です。"実行する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/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: 【dict5】 "出力を行う"は冗長な表現です。"出力する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5
/Users/azu/.nodebrew/node/v9.2.1/lib/node_modules/technological-book-corpus-ja/source/what-is-maven/implement-plugin/implement.md:83:26
v
82. なお引数に渡す文字列には、改行コードを含めないことをおすすめします。接頭辞がつかない行ができてしまい、
83. 機械的に処理することが難しくなるためです。複数行の出力を行いたい場合は、メソッドを複数回に分けて
84. 呼び出してください。
^
✖ 87 problems (87 errors, 0 warnings)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment