Onishiリファレンス用にまとめてみました。随時追記・編集していきます。OnishiFacebookやTwitterでgistに上げたものを公開したら思ったより反響があって驚きました。DropBoxにはiPhone等を接続したとき、自動で写真をインポートしてアップロードする機能があります。iPhoneを同期する際、すぐに写真はDropBoxにバックアップされますし、iPhoneからは写真を削除できるのでとても便利に使っていました。普通に使い続けていると、どんどんファイルが肥大化してしまって、Finderで開くのさえ時間がかかるようになってきます・・・。そんな肥大化した写真フォルダを、こんな感じに年月でフォルダ分けしてくれるスクリプトを書きました。Onishi完全に自分用。Macにpython関係の環境構築したときのメモです。Onishiタイトル長くてすみません。最近TypeScriptの勉強をしていて、様々な文章を読ませていただいています。その一つが次のものなのですが、納得できなかったところがあったので自分なりにまとめてみます。1.5の文法解説などが分かりやすく書かれており、とても参考にさせていただきました。“I”は使うべきではない?インターフェースの宣言には、通常のクラスではないことを示すために、接頭辞に”I”を追加することが多々あります。”User”クラスはインターフェースとして”IUser”インターフェースを実装している、といったようにです。先に挙げたページの、インターフェースについての解説で著者は次のように述べています。命名規則として、先頭にIを付けていた時期もありましたが、現在ではマイクロソフトのガイドライン上で、Iは付けないこと、と改められています。これを読んだとき、どうしても納得できませんでした。「Iをつけること」ならまだしも「つけないこと」をガイドラインで明文化されているというのは、自分の中で全くもって同意できなかったからです。Onishiこの記事はPascal編の内容をC++向けに書き換えたものです。2で読み込める、一目均衡表のテクニカルインジケーターを描画するDLLを作成することをゴールにします。Pascal編と同様の部分は省略していますので、先にそちらの記事をお読みなることをお勧めします。4(以下MT4)を使っています。Advisor)を自作することができます。MT4の場合は、本体インストール時にコンパイラも同時にインストールされ、プログラミング言語といっても習得が容易なオリジナル言語MQL4でより容易にプログラムすることができ、ソースコードが公開されていることも多いのですが、FT2の場合はC++またはPascalを使って、これらのdllを作る必要があります。普段Mac使いなこともあって、数年ぶりにこれらの開発環境を整えるときに躓いたことがあったので、備忘録として手順を書き留めようと思います。ちなみに、言語はPascalでもC++でもどちらでも良いと思います。C++は後で別に記事にするつもりです。プログラミング初学者で、どちらの言語も触れたことがない方であればPascalの方が私は楽だと思います。DLLファイルの容量がC++でビルドした方が小さくなります。気になる方はC++が良いかもしれません。前提として「バグがある」ことを証明できるが、「バグがない」ことは証明できないバグを限りなくゼロに減らすために有限時間内でチェックを行っているステートが増える毎にテストケースとテスト時間は指数関数的に増加するウェブサービスでブラウザを介して行うものは完全なブラックボックステストであるし、仮に誤った出力となるケースを発見しても、そのリクエスト内のどの段階(メソッド)でバグが起きているのか特定することはできない基礎知識テストは最低限の品質保証です。テストを行っていなかったプロジェクトにテストを導入する場合、「この関数の結果は最低限、保証されていなければならない」とする関数を最優先のテスト対象とします。テストを実施するためには、テストを行いやすい設計が必要不可欠であるため、既存のコードのままテストを実施しようとは考えない方が良いでしょう。ユニットテストは、リグレッションテスト(デグレードテスト)を行うための最適な方法です。リグレッション(デグレード)というのは、新たに機能を追加したり、既存のコードのバグを修正した際に、新たなバグを生みだしてしまうことです。ユニットテストを正しく行っていれば、常に要求を満たすテストケースによって過去の修正内容も検証され続けることになるためです。テストコードを書く習慣のない人が書いたコードは総じてテストしにくいコードを書く傾向にあり、テスト導入を決めたプロジェクトでテストコードに関する知識の無い人にコードを書かせ続けるのはとても非効率です。...それでも、テストコードを書く人が指摘しないといつまでも書けるようにはなりません。テストコードは誰でも書けるのか正しいテストコードを書くにはプログラミングの知識だけでなく、テスト工程におけるテストスキルと経験も必須です。機械的に行うユニットテストなどのソフトウェアテストは、ブラウザを介した出力を人間が目視で行うブラックボックステストと根本的に異なります。今回取り上げているのはユニットテストですが、その具体的なテストケースには同値分析や境界線分析など多くの手法があり、また適切なテストケースを書くことができないのであれば、テストコードを書かないも同然です。なにより、実施しようとしているテストの基礎知識がなければ、どの程度テストコード、テストケース、カバレッジを維持すれば十分という判断をすることができないし、そもそもプログラミングの知識がなければテストコードを書くことも出来なければ、テスト対象のコードを読んで適切なテストケースを作ることも不可能です。ゆえに、テストコードを書くにはテスト対象のコード(つまりビジネスロジック)を書く以上のスキルと経験が必要と言えます。テストコードを書かないのは悪ではないユニットテストはソフトウェアテスト手法の一つですが、これは通常の開発手法(例えばウォーターフォールやアジャイル、スクラム等々)と同様に、適用して効果的なプロジェクトもあれば、むしろ適用した結果マイナスに作用してしまうプロジェクトもあり、すべてのプロジェクトに導入を勧められるものではないことを理解してください。そのため、事前にユニットテストを導入するのが本当に効果的なのかどうかを検討・判断する必要があります。ユニットテストが効果的なプロジェクトの条件を次に挙げます。頻繁にリリースが行われる例えばリリースが年に数回のように、頻繁にリリースをしない場合、手動テストのコストが相対的に小さくなり、ユニットテストを導入するコストの方が大きくなります。逆にアジャイルで毎日デプロイを繰り返すようなプロジェクトの場合、手動テストだけでは太刀打ちできなくなることでしょう。長い期間保守されるリリース頻度と同じ考え方ですが、短時間で保守されなくなるプロジェクトでは、トータル的に自動テストが実行される回数が少なくなるため導入コストの方が大きくなります。サービス案を練って試作してみる時のプロトタイプなどに導入するのは不向きということになります。多くの人数が開発に関わる例えば1人で開発を継続できる規模のプロジェクトでは、当人がすべてのコード・仕様を把握しているケースが多く、テストコードを導入したとしても成果物の品質に影響を与えないことが多いです。逆に数十人規模の開発チームの場合、一人がすべてのコードを把握するのは不可能でしょうし、初めて触れるコンポーネントの改修を安心して行うことができるようになります。頻繁に参加しているメンバーが変動するプロジェクトの場合、テストコードのメンテナンスコストが高まり、テスト自体が破綻することがあるので注意が必要です。ある程度コードの規模が大きくなってきたプロジェクトにおいては、トータルで見たとき「自動テストを導入した後の開発速度」の方が導入前と比べて早いことも多いのですが、その段階以前の小規模なプロジェクトでは、自動テストを導入しない方が開発速度は速くなります。実際のビジネスの世界では品質よりスピードを重視することも多々あるので、開発ステージに応じた選択が必要になります。「テスト駆動開発」のススメテスト駆動開発とは一般的な開発工程では、機能実装者=その機能のテストコード実装者になります。方が考え方としてはより適切であり、成果物の品質向上を期待できます。このように、先にテストコードを書いてからビジネスロジックを実装する開発手法をテスト駆動開発(テストファースト)と言います。テスト駆動開発には、テスト対象のコードを書く前の時点でその全体像を頭の中で設計する必要があり、プログラム初学者が習得するのは困難です。開発が遅くなる?テスト駆動開発を実施すると生産性が下がると主張する人も多いのですが、実際は正しくテストが行えていればトータルで見た生産性は上がります。いうと、実際にコードを書くエンジニアでないと分からない感覚かもしれませんが、エンジニアが「実際にコードを書く時間」より、「処理を頭の中で考えて設計する時間」と、「書いた後の動作チェックの時間」の方が長くなりがちです(そうでないケースを私は知りません)。新人の頃は設計も未熟であり、十分に頭の中でシュミレーションできず、いきなり手を動かしてコードを書く作業に入るために無駄なコードが増えがちです。その繰り返しによって知見が十分に溜まることにより、手を動かす前に今から書こうとするプログラムの全体像を自然とイメージできるようになります。経験を積み重ねた熟練者はコードの実行結果を頭の中でシュミレーションできるので、無駄なプログラミングを初めからしなくなります。従って、テスト駆動開発の導入によりテストコードを先に書くことによって、開発工程で一番時間のかかる「脳内設計工程」と「動作チェック工程」が一体化し生産性が向上します。何が言いたいのか分からなくなってきました。ここまで書くのに疲れました。所感ここまで語れるほどユニットテストの経験が長いわけではない...はずが、いつの間にか書けるくらいの知識量になっていました。初学者だった頃は「テスト難しそう...書くと遅くなるし要らないや」なんてよく思っていました。Onishi実際の業務で個人的によく使うものや、過去に使ったトリッキーなものをまとめてみます。直前のコマンドの引数を参照できます。-ホームから深い階層間を飛び回るときなどに重宝。