マイペースなRailsおじさん

Ruby、Ruby on Rails、オブジェクト指向設計を主なテーマとして扱います。だんだん大きくなっていくRuby on Rails製プロダクトのメンテナンス性を損なわない方法を考えたり考えなかったりしている人のブログです。

日記

会社の書類に追われていました。

 

調べたこと

- redux

  - store、reducer、providerあたりの復習

- atomicデザイン

  - UIパーツを階層にわけて作る

  - 規模が大きいと、こういうのめちゃくちゃ効いてきますよね

- SSR サーバーサイドレンダリング

  - SPAのJSのダウンロードと初期表示画面の生成には時間がかかるので、JSをサーバーで実行してページ生成してしまおうという話

   - 理屈はわかりやすいんだけれども、やり方調べ中。

     - ユーザ固有の情報はどうやってくっつけるんだろうか。あとからクライアント側で実行？

      - SSR用のnodeのサーバーを用意する。

      - ルーターつかってページを分割していることとか考慮しないと行けなそう

 

やったこと

- webアプリを作り始めた

  - UIはmaterial-uiのreactコンポーネントライブラリを最大限使って構成

  - create-react-appで始めて、reduxを入れた

  - UIの状態をreduxをつかって分離した

 

考えたこと

- SSR、簡単そうに見えて難しくないか

- Most Valuable Productを作るには鍛錬がいる

  - こんなサービスあったら良さそう！と考えても、Valuableな部分は何かって考えていくと大したものが残らないことがよくある

  - なんか本さがしてみよう

日記 土日は休みたくなってきた。

日記

調べたこと

  • MATERIAL-UI
  • 9 things every React.js beginner should know
    • React.js初心者が知るべき9つのこと
    • ちゃんと読んでないけど、大事なことが凝縮されていそうな気がするのでダラダラ読んでいく
    • Viewライブラリである
    • Model、Controllerの機能は持たない
    • コンポーネントを小さく保ちなさい
    • 「小さい」の規模感は状況によってことなるが、できる限り本当に小さくするのがよい。
    • Functionalなコンポーネントを書きなさい
    • アローファンクションを使ってrenderメソッドを書いてやると見やすいので、コンポーネントはclassではなくfunctionで表すようにしよう
    • ステートレスなコンポーネントを作りなさい
    • Redux.jsを使いなさい
    • prop Typesは必ず書きなさい
    • shallow renderingを使いなさい
    • JSX, ES6, Babel, Webpack, NPMを使いなさい
    • React, Reducのデベロッパーツールを使いなさい

やったこと

  • React.js環境構築
    • nvm
  • Materila-uiちょっとつかう

考えたこと

  • 特に面白いことは思いつかなかった。

@Mockでモックを初期化する方法は3つある。

Mockito Java

mockitoでは、モックにしたい変数に@Mockアノテーションを付けるだけでモックを作れます。この場合、アノテーションを有効にする記述をする必要があります。アノテーションの有効化は、initMocksを呼び出す、Runnerを使う、Ruleを使うの3つの方法で行えます。

mockito

mockitoはモック作成、呼び出しの検証、スタブの作成が行えるユニットテスト用のJavaライブラリです。
以下は公式サイトにあるキャッチコピー。

Tasty mocking framework for unit tests in Java
Javaのユニットテストのための味わい深い（？）モックフレームワーク

インストール

gradleを使っている場合は、build.gradleのdependenciesにmockitoを追加してください。

group 'net.example'
version '1.0-SNAPSHOT'

apply plugin: 'java'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.21.0'
}

基本的な使い方

モックにしたクラスのメソッドにスタブを作ってテストするという使い方をよくします。

基本的なモック

mockの作り方

mockを作る方法は、mockメソッドを使う方法と、@Mockアノテーションを使う方法があります。

上の例で使っていたので、mockメソッドを使う方法です。

private List mockedList = mock(List.class);

もう一つが@Mockアノテーションを使う方法です。

@Mock
private List mockedList;

アノテーションを使ったほうが記述が少なく、見栄えもいいのですが注意が必要です。 @Mockに限らず、mockitoが提供しているいくつかのアノテーションを使うときはアノテーションを使ったMockを初期化する処理を書かなければいけません。

アノテーションを使ったmockを初期化する方法

@Mockとかを初期化する方法は3つあります。 私はRunnerを使うのが楽なので好きです。

initMocks()を使う

@Beforeなメソッドの中でinitMocksを使います。

initMocks

Runnerを使う

@RunWith(MockitoJUnitRunner.class)をクラスにつけます。 Mockito用のRunnerが適用されるので、Mockの初期化だけでなくスタブの用法が間違ってないか検証するなどの機能もあります。

Runnerを使う

Ruleを使う

JUnitのRuleを使ってMockitoJUnit用のルールを適用します。

@Rule public MockitoRule rule = MockitoJUnit.rule();

効果としてはRunWithを使った場合と変わらないようです。

Rule

情報源

Mockito (Mockito 2.21.0 API)

https://static.javadoc.io/org.mockito/mockito-core/2.21.0/org/mockito/MockitoAnnotations.html#initMocks-java.lang.Object-

MockitoJUnitRunner (Mockito 2.21.0 API)

https://static.javadoc.io/org.mockito/mockito-core/2.21.0/org/mockito/junit/MockitoRule.html

飲み会あったので日記つけるのつらかった

日記 Linux

調べたこと

  • gitのコンフリクト
    • checkout --theirs [ファイル名]とcheckout --oursを駆使する

やったこと

考えたこと

Windows 10 Enterprise Editionは開発機として使えるか

エンジニアはMac、その常識をWSLが覆そうとしている。というような話を聞いてから久しい。 Windows10 homeを使ってみて、やはりそんなことはなかったなぁと思っていた。
そんな私のもとに、職場都合でWindows10 enterprise editionがやってきた。以下、1日触った感想。

Windows10 EE のよいところ

  • フォントレンダリングがきれい
    • Win7に比べて、だけれど。やっぱりMacにはかてない。ヒラギノがつよいのか。なんなのか。 - Windows Subsystem for Linuxが最高すぎる
    • ターミナルエミュレータがヤバいのを除けば最高。だってLinuxがそのまま使えるんですもの。
  • docker for Windowsがいいかんじ
    • 仕組みはまだよくわかっていないけれど、Docker Tool Boxみたいに後ろで動いている VMを気にしなくていい。
    • WSLからもdocker.exeで使える

Windows10の残念なところ

  • インストールめんどくさいい。
    • 後からわかったけど、Chocolatyというパッケージマネージャを使えばよかった。
  • ターミナルエミュレータが残念
    • cmd.exeがちょっとだけよくなったくらいのやつ。
    • i18n対応バグなのか、フォントの設定をしてもMSゴシックに戻ってしまう。
    • VcXsrvを使うとX Window Systemが使えるので、GNOMEとかのいい感じのターミナルが使えるんだけどまだ未設定。

設計ムズスギィ

先輩エンジニアに指摘して頂いて、自分のやっている設計がまだまだオブジェクト指向を使いこなせていないのがよく分かった。 設計ばかりは数をこなすしかないよ、と優しくアドバイスしてもらっているけれど、何とかしなくては。
DDDをもっと理解していけば何か見えてくるような気がしているので勉強のモチベが上がっている。

思ったより調べてなかった

今日調べたことはあまりなかった。 なんか調べたような気がしたけど忘れてしまった。 はてなブログのアプリが結構便利なので、休み時間とかにメモるようにしておこう。

毎日投稿している人すごすぎ

今日は飲み会があったので記事書くの大変でした。あきらめようかと思ったけど踏ん張りました。 日に日に内容が薄くなっていくのを実感。

今日は1時間～

Mockitoメモ

Mockito

呼び出し時の変数を使って値を返すスタブ

doAnswer (かwhenのthenAnswer)を使うと、スタブの呼び出しの引数を使って返値を決めることができます。

doAnswer

例えば、スタブの返す値を引数によって変化させたいとき、引数と返値のマップを用意しておくとこのようにスタブが書けます。

        doAnswer(invocation ->
                someMap.get(invocation.getArguments()[0]))
                .when(mock).someMethod(anyString());

doAnswerは、Answerオブジェクトを引数にとります。 Answerクラスは、InvocationOnMockオブジェクトを引数にとって値を返すanswer()メソッドだけを持つクラスです。 ということは上記のようにラムダ式が使えます。

InvocationOnMock (Mockito 1.10.19 API)

サンプルコード

引数を使ってスタブの返値を決める

日記

日記

調べたこと

  • mockito
    • verify()
      • メソッドが呼び出された回数を検証する
    • doAnswer()
      • メソッドの引数を使って返値を設定できる
  • eclipse local history
    • 半日かけて書いたコードをEclipse上で消してしまった。
    • ゴミ箱にはいかずに消えていた。
    • Local Histryを使うと復元できる！

やったこと

  • mockitoのverify()とTheoryでドハマりした。
    • Theoryで複数パターンをテストするとき、verify()で使う呼び出し回数はリセットされない。
    • reset()でMockをリセットしてやらないといけない。
    • デバッグで変数追いかけまくってやっとわかった…

考えたこと

Theoryはデバッグしづらさがある

TheoryとFixtureを使ったテストは最高に簡単に書けるので大好きだったのですが、デバッグしにくいのが難点かもしれませんね。何回目の呼び出しでバグったかわかりにくいし、コンディショナルブレークポイントを刺さないといけないし…

ラムダ式を深く追いかけたい

仕事中、ブレークポイントを刺してバグを見つけることは多いですが、あまり時間をかけられません。で、よく気になるのがラムダ式。なんかよくわからないところに飛びまくるんですよね。時間があるときに深追いしよう。

Springアノテーション地獄

アノテーションはおまじないになりがち。アノテーションがやってくれている処理にたどり着くまでが遠いんですよねぇ。これも時間があるときに深追いしよう。

日記を書くのはいいことだ

一度アウトプットしておくと、頭の中が空っぽになったかのような気分で次の新しいことを学べる。（気がする） 自分の学習の傾向を後から振り返って作戦を立てるなんてこともできますわよ。

今日は30分で書きました。内容がうすい～。

日記（トピック: JavaのflatMapがちょっと気に食わない）

日記 Java JavaScript Linux

調べたこと

やったこと

  • VMのUbuntuのvimをセットアップした
    • vim8のターミナルモード、つかいやすい。neovimはターミナルモードのウィンドウから移動するのがだるかった。
  • gatsby
    • GraphQLでクエリを投げてみた。
    • gatsby developでwatchがちゃんとできてないっぽかったけど解決できなかった。

考えたこと

Java.util.StreamのflatMap()はなんか微妙

flatMapの引数はStreamを返す関数。
てことは、リストのリスト（e.g. List<List>）からリスト（List）を得るみたいなありがちな処理は以下のように書くことになる。

注目してほしいのはこの部分。

List<Integer> list = listOfList.stream()
    .flatMap(List::stream) // .flatMap(l -> l.stream())でもいい
    .collect(Collectors.toList());

flatMapは、streamに対して関数を適用して、そこで得られたstreamをすべてくっつけて一つのstreamにします。 てことは受け取ったstreamの中身はリストなので、それをstreamに変換してくっつけると、リストの中身を取り出すことになるわけですね。

いやしかし私はflatMapの引数がstreamを返す関数というのがどうも気に入りません。
単にくっつけるときのstreamの中身を返すだけにしてしまうと、 streamへの変換を行わなければいけないくてそれを自動でやるのは難しいというところでしょうか。 それで、どのように変換するかはプログラマに任せないといけないという事情だと思います。が、どうになならないのかなーと思いました。
というか、その問題を解決しているライブラリがありそうなので調べてみます。

ファイルの重複行を削除するアルゴリズムってどうなってるんだろう

  • メモリに全行読み込む系
    • ハッシュテーブルを使えば、重複の検出は素早く済みそう
  • メモリに全行読み込まない系
    • ファイルをチャンクに分けて少しずつ見ていって、↑に書いたやつをメモリに書く代わりにファイルに書きながら進める
    • 一度ソートしてファイルに書く⇒次の行が同一か見るならいけそう
      • じゃあどうやってメモリに全行読み込まずにソートするんだろう問題

i18nのこと、そろそろちゃんと考えたい

qiita.com

記事のテーマ：i18n（ソフトウェアの国際化対応）は、単に文や時間（タイムゾーン）を差し替えれば済むような簡単なものじゃない。自分たちの文化にはない決まりにしたがって文ができていることがある。場合によっては、そのためのロジックを加えなければ対応できない。そのような対応が必要になるような文化を数多く持った国家で育つと、i18nに対応したプログラムを特に意識せずに書くことができるようになるのではないか。

今の仕事では、英語のUIを持ったサービスを作っているけど、ユーザーの使用言語は3つある。 ので、そのうちi18n対応をすることになりそうな気がしている。 とても興味深かった、というか、そのうちまたお世話になりそう

これからやること

  • flatMapをもう少しきれいに書けるようなライブラリがないか調べる。
  • gatsbyをAPIと連携させる

今日は一時間20分くらいで書きました。