vueによって追加される属性
ディレクティブではないため、「v-」をつけない
ref="someName"を付与することで、参照を獲得できる
直接DOMを書き換えることができるが、vueでバインドしているわけではないため、リアクティブにならない
ここで画面表示完了
オブジェクトとして定義するとインスタンス間で共有されるため、コンポーネントでdataを扱いたい場合には、functionにする必要がある
DOMの切り替えに使う。 引数に真偽値のdataを渡す。
dataがfalseの場合、タグがDOMから削除され、代わりにコメントが挿入される。 v2.1以降であればv-if-elseディレクティブが使える。
複数のタグをv-ifで囲みたいときに利用する。 それぞれにv-ifを書いて同じdataを参照させるよりもスマート。
v-ifとは異なり、styleにdisplay:noneが付与されるだけでタグは残る。 基本的にはv-ifのほうがパフォーマンス面で有利。
繰り返し処理に使う。 v-for="item in list"の形式で使用する。 v-for="(item, i) in list"とすることでインデックスが使用できる。 順番は守ること。
ネストしていないタグで同じループを共有したい場合はtemplateディレクティブを使用する。
配列以外のオブジェクトの場合はv-for="(value, key) in objects"の形式でkeyを利用できる。 順番は守ること。
3番目にv-for="(value, key, index) in objectes"の形式でindexが利用できる。
前回の記事ではラムダ式を理解するための足がかりとして匿名クラスについて書きました。
実は匿名クラスとラムダ式は同じことを違う書き方で表現しているだけなのです。
実際の処理を匿名クラスとラムダ式でそれぞれ記述して比較してみましょう。
今回サンプルで実装するのは、ラムダ式と一緒によく登場するList.sortです。 メソッドについてよく知らない人は、Javadocを眺めてみてください。 それでもピンとこない人はListの中身をソートするメソッド、くらいに捉えればOKです。
シグネチャはvoid sort(Comparator<? super E> c)となっています。Comparator型の引数を渡してあげればよいですね。
今回は、sortメソッドの実装までは詳しく触れませんが、sortメソッドに渡されるComparatorによって振る舞いが変化します。
つまり、このComparatorこそがソートのアルゴリズムで、それを自分で実装することができます。
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort(new Comparator<String>() { public int compare(String str1, String str2) { return str1.compareTo(str2); } });
自分で実装できます！とか言っておきながら、内部ではString.compareToに移譲しています（笑） 今度は同じ処理をラムダ式で書いてみましょう。
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort((str1, str2) -> str1.compareTo(str2));
一見難解ですが、記述量はかなり減りましたね。 ではどうしてこの２種類の書き方が同じになるのか見ていきましょう。
今回実装したComparatorは関数型インターフェースと呼ばれるものです。 関数型インターフェースとは、抽象メソッドが一つだけ定義されているインターフェースのことです。 この関数型インターフェースを利用することで、コンパイラはごく僅かな情報からシグネチャを特定できます。
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort(new Comparator<String>() { public int compare(String str1, String str2) { return str1.compareTo(str2); } });
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort( public int compare(String str1, String str2) { return str1.compareTo(str2); } );
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort( (str1, str2) { return str1.compareTo(str2); } );
List<String> list = Arrays.asList("aa", "b", "ccc"); list.sort( (str1, str2) { str1.compareTo(str2); } );
->でつなぐList<String> list = Arrays.asList("aa", "b", "ccc"); list.sort((str1, str2) -> str1.compareTo(str2));
ね。簡単でしょ？
初めて学んだ（学んでいる）プログラミング言語がJavaだという方は多いのではないでしょうか。 かくいう私も、新卒で入った会社の研修でJavaを学びました。
その後も、業務で扱ってきた言語は8割以上がJavaでした。 一年ほど立った頃、現場が移動になりました。 新しい現場でもJavaのシステムに関わることになりました。 まずは現場に慣れるためにソースコードリーディング。
そこで受けた衝撃は二度と忘れないでしょう。 そう、そこにはJavaという名前の見たことのない言語で書かれたソースがあったのです。 ラムダ式、脳内で文字にするのも一苦労なその構文は、その後の私を随分と苦しめてくれました。
色々と原因はあるのでしょうが、一番ひっかかるのはその奇妙な構文でしょう。 他の構文と比べても明らかに異質です。
ラムダ式を理解する方法として、一番やってはいけないことはずばり丸暗記です。 ラムダ式の本質はその柔軟性です。 つまり、ラムダ式の書き方だけを覚えても、応用がまるで効かないため、いざ自分でコーディングする際には全然使えないのです。 したがって、段階を追ってその意味を理解していくことがラムダ式習得への近道です。
まずは匿名クラスについて理解しましょう。 匿名クラスとは、インターフェースの宣言と実装を一度に行うことができる構文です。
Hoge hoge = new Hoge() { public void huga() { } };
この例では、hugaメソッドを持つHoge型のインターフェースを宣言と同時に実装しています。 アノテーションがついていませんが、hugaメソッドはオーバーライドされています。 実装クラスの名前は定義されていません。これが匿名クラスと言われる理由です。
３〜５年目のエンジニアをターゲットにしています。
かくいう私も４年目エンジニア、もうすぐ５年目に突入しようとしています。
実は技術に興味を持ったのはここ２年ほど。
それまではレガシーな現場で仕事をこなすだけの日々を送っていました。
学生時代にプログラミング経験は全くなく、今使っている知識のほとんどはこの２年間で覚えたもの。 学生時代からばりばりコードを書いてきた後輩たちには技術力では正直負けている。 けどまだエンジニアとしてのキャリアに見切りをつけるつもりは毛頭ない。
そんなエンジニアたちに私が読んでよかった技術書を紹介しようと思います。
具体的な技術というよりも、エンジニアとしての価値観について書かれた本。
所謂エンジニア文化の基礎にたくさん触れられます。
同僚たちの価値観にイマイチピンときていない方は一読の価値あり。
鉄板ですね。
一度だけでなく、節目節目に何度でも読み直す本です。
まさか読んだことない、なんて言いませんよね？
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
HTTP, RESTなど、現在主流のWebアプリ開発に必要な基礎知識が詰まっています。
Webアプリ開発経験が浅い場合はぜひ読むべき
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
クラウドやコンテナ技術の台頭により、インフラエンジニアでなくとも、インフラ側の知識が要求される場面は増え続けています。
とりあえずこの本レベルの内容が頭に入っていれば、クラウドやコンテナと親和性の高いアプリを設計できる第一歩になるはず。
Linux教科書 LPICレベル1 Version5.0対応
アジャイル開発の抽象的な概念をわかりやすく学べる一冊
とはいえ、理解は簡単でも実践が難しいのがアジャイル。
前提知識を身につけたあとは実践あるのみ。
日々プロジェクトで発生する色んなもやもや感をうまく言語化してくれた一冊。
何となく良くない気はするけど、どう改善したら良いのかわからない。 そもそも課題をうまく定義できていない。
もっと良くしたい。そんな思いを行動に変えてくれる一冊。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
まだまだ若いもんには負けん！
前回の記事では割愛した、commitの改変についてもう少し詳細に見ていこうと思います。
git rebase -i commit履歴 を実行すると対話的にrebaseを行うモードに移行します。
対話的rebaseモードでは、指定したcommit以降のcommit履歴が古いものから順に表示されます。
commitサンプル
A B C D
この履歴に対して、git rebase -i D を実行すると
pick C pick B pick A
このような画面が表示されます。 それぞれのcommitとこれから適用する操作の一覧です。
下のほうには以下のように適用可能な操作の説明が記載されています。
# These lines can be re-ordered; they are executed from top to bottom. # # d, drop = remove commit # x, exec = run command (the rest of the line) using shell # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message # p, pick = use commit
| 操作名 | 内容 |
|---|---|
| drop | commitを破棄する |
| exec | commitに対して指定したshellを実行する |
| fixup | logを残さずにsquashを実行する |
| squash | commitを一つ前のものと統合する |
| edit | commitを適用し、一時停止する |
| reword | commitを適用するが、logを改変する |
| pick | commitをそのまま適用する |
それぞれの操作を選択し、次に進むと古いものから順に適用が行われます。 exec,edit,reword操作を適用するcommitに到達すると、適用が一時中断され ます。 必要な改変を行って、continueすると再び適用が行われます。 すべての操作が適用されるとrebaseは完了です。
モックしているオブジェクトのメソッドの引数を検証したい場合は、Mockito ArgumentCaptorを利用すると良いでしょう。
public class Person {
privatre String name;
Person (String name) {
this.name = name;
}
}
public class User {
void varArgMethod(List<Person> list) {
}
}
public class UserTest {
@Mock
User user;
@Test
void test() {
ArgumentCaptor<List> varArgs = ArgumentCaptor.forClass(List.class);
verify(user).varArgMethod(varArgs.capture());
List expected = Arrays.asList(new Person("John"), new Person("Jane"));
assertEquals(expected, varArgs.getAllValues());
}
}
ArgumentCaptor.forClassメソッドでArgumentCaptorのインスタンスを生成し、 verify()でモックオブジェクトのメソッドが呼び出されていることをテストするのと同時に、その呼出引数をcapture()します。 引数がListの場合はgetAllValues()、List以外の場合はgetValue()で実際に呼び出された値を取得することができます。
ArgumentCaptorの初期化には@Captorを代わりに使うこともできます。
public class UserTest {
@Mock
User user;
@Test
void test() {
@Captor
ArgumentCaptor<List> varArgs;
verify(user).varArgMethod(varArgs.capture());
List expected = Arrays.asList(new Person("John"), new Person("Jane"));
assertEquals(expected, varArgs.getAllValues());
}
}
こちらのほうがより簡潔に書けて良いですね。
