「TEST」を含む日記

はてなキーワード: TESTとは

2016-10-26

■harmful pathogens

In that test tube are deadly pathogens

Permalink | 記事への反応(1) | 16:24

2016-10-01

■[test]test

anond:20130907131219

Permalink | 記事への反応(0) | 23:50

2016-09-19

■http://anond.hatelabo.jp/20160919121645

追記：論理積と論理和の優先順位で間違いがあったため修正しました。

まず最初の条件をif分を一回終わらせて入れ子にするか、falseならreturn させるといい。

入れ子になってもとにかく自分が分かるようにするといいです。

一行で書くのはそのあとではどうだろう

if(param == 0 &amp;amp;&amp;amp; test(param2)) {
   if(!param3) {
     something todo
   }
 }

また

if(!(param == 0 &amp;amp;&amp;amp; test(param2))){
  return false;
}
if(test(param2) || !param3) {
  実行分
}

あと、一つの条件式で書きたいなら、括弧を使ったり、改行したりして、式の流れを細かくすると分かりやすくなる。

2:paramが0
3：かつ
4：判定関数でparam2の条件を返して、true
5：またはparam3がfalseのときがtrueだから

なのに　param==0 ＆＆判定(param2) || !param3　だと

param==0 ＆＆判定(param2)

と

!param3

で別れるはず（言語によって違う可能性もありますが）

だけど、日本語を言葉にすると「paramが0かつ判定関数でparam2の条件を返して、trueまたはparam3がfalseのときがtrueだから」

となって、かかる範囲が分かりづらくなるから、

だから、論理演算子が複数になるときは、日本語でかつ、または使うと逆に混乱するから、

trueになる一つ目の条件の時は「○○」またはといったように書くと、

冗長的ですが、言葉にしても分かりやすいかと思います。

それ以外には既に上げていた色んな増田の方のやり方もそうだし、

変数名で分かりやすくするというのもあるぞ。


is_children = age &lt; 20
has_game    = check_game(param2)
if(is_children &amp;amp;&amp;amp; has_game) {
  print ゲームをもったこども
}

条件式は思考にブレーキがかかるからこうやって、

変数名に置き換えること、文章として読めるからブレーキがかかりにくくなる。

と、無理にワンライナーで書かない方法を導入すると理解しやすくなると思います。

Permalink | 記事への反応(2) | 18:45

■http://anond.hatelabo.jp/20160919121645

条件をXとおく。

if (X) {
    /* Something to do */
}

満たす条件は、

(i) paramが0 かつ判定関数でparam2が真

param == 0 &amp;&amp; test(param2)

(ii) param3が偽

!param3

(i),(ii)はどちらかを満たせばよいので

X = (i) || (ii)

Permalink | 記事への反応(0) | 13:01

■aaaa

test

Permalink | 記事への反応(0) | 02:12

2016-08-31

2016-08-22

■Titanfall2が前作から大幅に変わった理由を邪推した

まだTechnical Testなので細かい点は置いといて、外的要因がいかにゲーム内容に影響を与えた（と俺が考える）かを適当に書いてみる。

変更点の殆どは「1マッチ当りのサーバ リソース消費を限界まで下げる必要性があった」事に起因する

なぜならもうサーバをよそに丸投げせず費用も運用も自前で面倒見ることになったので、あたりまえだがコスト削減は必須。

それに加えて今作からはPS4にも出るので単純にマッチ数が増える。インストールベースを比較すれば最低でも3倍以上にはなるだろう。

その分運用コストも嵩むわけで、マッチ数が増えた分そのまんまサーバ運用コストを増やせるかというとそれは流石に無理。

となると1マッチ当りのサーバコストをいかに削るかを製作陣は必死に考えたはずだ。

それが、1マッチ当りの延べタイタン数の削減とタイタンのさらなる短寿命化。降りたらAIが稼働するタイタンは削減必至だったといえそう。

ユーザー反発を抑える緩衝材としてシールド回復をバッテリー方式にしてバッテリーをタイタンロデオで取得可能にしたのは上手い事考えたと思う。

苦し紛れとはいえタイタン寿命の削減をうまい事ゲーム性に変えてて面白い。

あとbot兵の削減。コレはプレイヤーが載ればAI 演算分を削れるタイタンと違って数を削減すればそれがそのままリソース減に直結する関係上

派手に削られた。というか、むしろ言い訳程度にしか残されてない。製品版出たとき bot兵が今より大幅に増えることはないだろう。

細かい 仕様はともかく、マッチ中盤からはタイタン 祭りになった前作とは別ゲーになることは避けられない

前作では下手なプレイヤーでも1マッチ2回はタイタン呼べたし、うまいプレイヤーはそれこそタイタンの寿命も長いし、壊しても直ぐ次のタイタン呼べたから

ホントにタイタン祭りだったけど、今作はTechnical Testの結果を踏まえた調整がどのような方向に進んでもタイタン祭りはさほど起こらないだろう。

起こるとすれば上級者のタイタンによる蹂躙がより凄惨さを増すぐらいじゃないか。

その他

バーンカード辺りは普通に実装されるんじゃないかと思う。というか何らかのガチャ要素仕込まないと長期運用が見込めないからまず間違いなく実装される。

低級者が狩りの獲物であることには変わりはないが最低限楽しめる要素が仕込まれてた前作と違い、今作は他の数多のFPSのように低級者は本当にただの獲物になるだろう。

結局、「前作を楽しんだ人ほど不評で、新規参入者や前作をあまり遊ばなかった人には受け入れられる」という形に落ち着くのではないかと。

でもまぁ、前作も大ヒットというほど売れてるわけでもないし、新規参入を見込めるユーザーが前作の総プレイヤー数より多そうな今作は

評価としては全体的には前作よりちょっとマシなレベルに落ち着くんじゃないかと思う。

Permalink | 記事への反応(0) | 21:09

2016-07-25

■gitにおけるコミット ログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

ピリオドで終わっているもの(4535件)
小文字で始まっているもの(2242件)
過去形, 現在進行形で始まっているもの(1044件)
Merge/Revertで始まっているもの(6555件)
絵文字を使っているもの(2171件)
その他バージョン番号のみ等、参考にならないと判断したもの(313件)

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションやフラグ、メニューを追加した

Add -enable-experimental-nested-generic-types frontend flag
Add --main-process flag to run specs in the main process
Add Throws flag and ThrowsLoc to AbstractFunctionDecl
Add "event" parameter for "click" handler of MenuItem
Add File > Exit menu on Windows

ファイルを追加した

Add npm start script
Add build script
Add SkUserConfig.h with blank SkDebugf macro

メソッドや機能を追加した

Add TypeLowering::has FixedSize()
Add overflow scrolling
Add convenience API for demangling
Add a typealias to avoid a build ordering dependency between projects
Add a helper method mayHaveOpenedArchetypeOperands to SILInstruction

実装を別のものへ切り替えた

Use args.resourcePath instead of args.devResourcePath
Use arrays instead of while loops
Use auto instead of repeating explicit class names
Use weak pointer instead of manual bookkeeping
Change all uses of 'CInt' to 'Int32' in the SDK overlay
Change Integer#year to return a Fixnum instead of a Float to improve consistency

新しく何かに対応した/機能上の制約を取り払った

Add support for closure con texts to readMetadataFromInstance()
Add support for activating and deactivating package-specific key maps
Add support for launching HTML files directly
Add support for allocators that require tensors with zero
Make it possible to call `reflect` multiple times
Make it possible to set a data type for variables that come out of constants
Allow atom-pane to be shrunk independently of its contents' width
Allow null TextEditorComponent::domNode during visibility check

何かを使うようにした

Use const for util require
Use FoldingSetNode for ProtocolType
Use unique text editor title in window and tab titles
Use an empty object if metadata is ~null
Use target_link_libraries for fat executab le dependencies
Use existing flatMapToOptionalTests dataset

より好ましい実装に改良した

Make the clone function more generic
Make IO faster for v8 compile cache
Make model constructor argument to addViewProvider optional
Make Browser::Quit more robust
Make Menu.getApplicationMenu() public
Improve incompatible native module error message
Improve readability of multi-line command
Improve folds behavior when duplicating lines
Improve deprecated message on webPreferences options

何かを出来ない/しないようにした

Don't bail reading a metadata instance if swift_isaMask isn't available
Don't exit until the parent asks for an instance
Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
Don't use MatchesExtension for matching filters
Don't use ES6 class for AutoUpdater windows class
Don't use MatchesExtension for matching filters
Avoid `distinct` if a subquery has already materialized
Avoid infinite recursion when bad values are passed to tz aware fields

オブジェクトの内容や挙動を確認しやすくした

Emit capture descriptors in their own section
Emit field metadata for @objc classes
Emit reflection info for protocols

Assertを追加した

Add assert for role with app name in label
Add assertions for no available bookmark
Add asserts for properties

不要なコードを除去した

Remove some dead code
Remove some unused enum declaration
Remove unused variable
Remove unnecessary line feeds
Remove trailing whitespace
Remove debug statement
Remove redundant mapType{Into,OutOf}Con text() calls

コードを移動した

Move function signature analysis to a Util
Move markInvalidGenericSignature() to a method on TypeChecker
Move diagnostic for stored properties in protocols from type checking to validation
Move Doxygen converter into a proper MarkupASTNode visitor
Move Module require to top

名前を修正した

Rename environment -> environmentHelpers
Rename watchProjectPath to watchProjectPaths
Rename generic arguments
s/grammarName/grammar
fullVersion -> writeFullVersion

小さな バグやタイポを修正した, 警告を潰した

Fix typos
Fix a typo
Fix a test
Fix typo in DevTools Extensions tutorial
Fix DownloadingState typo
Fix includes order
Fix mistake in tvOS availability
Fix cpplint warnings
Fix wrong markdown
Add missing return
Add missing period in comment

バグや好ましくない挙動を修正した

Fix a memory leak in FSO
Fix lifetime issues in ManagedBuffer.value
Fix mangling for nested generic types
Fix memory corruption in another circularity check
Fix thread-unsafety in Process.Argument initialization
Fix "Object has been destroyed" error in "page-title-updated" event
Make Error.prepareStackTrace read-only (again)
Make string slicing tests standalone
Make sure showing success dialogs works correctly
Make sure to emit closure bodies only once
Make sure all native resources get freed on exit
Make sure temp file will be cleaned up when base::Move fails

テスト、コメント、ドキュメントを追加した

Add tests for pending pane items
Add validation test for projecting existentials
Add a basic test for opening an editor in largeFileMode if >= 2MB
Add specs for moveSelection Left()
Add failing spec for Menu.buildFromTemplate
Add comment about map key/values
Add TODO about blinkFeatures -> enableBlinkFeatures
Add a design-decisions section to the CONTRIBUTING guide
Add style.less examples
Add docs for app.getLocale()
Add documentation for --proxy-bypass-list

テストを削除した

Remove a redundant test
Remove an empty test

テスト、コメントを修正した

Fix comment
Fix outdated comment
Fix failing specs on Windows
Fix PersistentVector test for powerpc64{le}
Update specs for deferred activation hooks
Update successor/predecessor in validation tests
Update some tests to use LifetimeTracked instead of hand-rolled canaries

ドキュメントを修正した

Update README.md
Update docs for marker callback
Update documentation for mark*Position
Update link to solarized-dark-syntax
Improve documentation of `ses.cookies.set()`
Improve readability in CSRF section of guide
Improve spec description

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add	1149
Fix	1014
Update	584
Remove	566
Use	382
Don't	260
Make	228
Move	178
Change	103
Rename	85
Improve	76
Avoid	68
Allow	65
Implement	60
Handle	58

コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。

また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞か Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。

一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。