フリーランス残酷物語 14日目

この記事は「フリーランス残酷物語 Advent Calendar 2016」 14日目の記事です。

気がつけばフリーランスになって6年経ちました。こじか屋のしかじろうです。 フリーランスとしては中の下くらいだと思ってます。かろうじて生きてます。 受託だったり保守だったり講師だったり社員教育だったり趣味サービスやってます。

あと、もなかが可愛いです。 instagram

残酷な話をすると心が滅入るので、「残酷にならないためにはどうしたらいいか」っていう事を書こうと思います。

まとめ

これを読もう

SOFT SKILLS ソフトウェア開発者の人生マニュアル

収入分散化の勧め

技術力があって1システム全部作れると受託が金額的に良かったりします。ので、受託ばかり受けがちになってしまいます。

「じゃあこのシステム、200万でよろしくお願いします。」
『たまんねぇぜ(^q^)ジュルリ』

でも受託ばかりやっていると収入の波ができてしまいます。200万の入金の月もあれば、0円の月もあります。 これだと資金の見通しが立たず、なかなか経営が安定できません。 「自社サービスを作ろう!」と思ってもなかなか着手出来なかったりします。

  • 受託
  • 長期の保守
  • 定期的な講師業
  • スパンの長い社員教育

上記は僕がやってる or やってたものです。複数の収入先を確保すると安定します。心にも余裕ができます。

理想は不労所得です。寝ずに仕事すれば収入は増えますが長続きしません。 プログラマでしたら、自分でアプリやサービスを作り、僅かでも収入を受けれるようにがんばりましょう。 (僕に不労所得があるとは言ってません)

T型の勧め

一つの技術やプラットフォームに突出してる方が営業しやすいです。単価も高くしやすいのかもしれません。説明もし易いです。顔や名前を覚えてもらいやすいです。

(^o^)「こじか屋はAndroidアプリが得意です。」

なんでも作れますって言ってると、いざどこかで案件が発生した時にあなたの顔が浮かばないので、声がかかりづらいです。 といって、一つの技術しか使えないと大きめのお仕事を受けにくいので、他の技術も幅広く学んでおくと良いと思います。 一つの目立った技術と幅広い技術を持ちましょう。

例えばこじか屋では

  • Androidアプリ開発

を主軸としていますが、

  • GCPでのクラウド構築
  • Arduino/RaspberryPiでのプロタイプ開発

もやってたりします。

アプリの仕事だと思って聞いてるとサーバーも必要になることは多いですし、Arduinoなどのハードウェアを使った新たな提案も行えたりします。

これからの時代に求められるのは「T型ではなくH型の人材」

ぐぐってたら今はH型が良いそうです。

がんばろう。

健康の勧め

ここが一番大事です。もう上の2つは忘れてください。上の2つとは関係なく素晴らしい経営してる人たくさん居るので忘れてください。

心身共に健康になりましょう。

「風邪を引かない」という話ではありません。「毎日100%の元気で机に座ってプログラミングし続ける」という話です。

  • 不健康だと質の良いコードは書けません。
  • 不健康だと進捗がダメです。
  • 不健康だと営業に行けません。打ち合わせもままなりません。
  • 不健康だと勉強も頭に入りません。
  • 不健康だとコミュニティ活動もできません。
  • 不健康だとなにもできません。

フリーランスとは毎日健康であり続ける必要があります。 そして僕は1年前まで心身共に不健康でした。ずっと、ずっと、ギリギリで生きてきました。

健康になるには

健康で居続けるには

  • 早寝早起き
  • 健康的な食事

を心がけましょう。 やるのはこれだけです。 しかし、これをずっと続けなくてはいけません。

逆に言えば

  • 徹夜、夜型、不眠不休で働く
  • レッドブルとジャンクフード

は止めましょう。若い時しか持ちません。そのしっぺ返しはすぐ30代後半くらいで直ぐにやってきます。

宣伝

(^o^)「Androidアプリ案件お待ちしております!」 Twitter Facebook

おわりに

明日15日は akiraakさんの 奇妙で残酷な作業依頼 です。

AndroidのTestまとめ

この記事をまとめるにあたって Best Practices for Testing | Android Developers を主に参考にしています。

Androidのテストは大きく分けて Unit testUI test の2種類があり、実装方法や対象などで分けると5種類ある。

ジャンル テストの種類 Androidへの依存 主に利用するツール 特徴
Unit Test local unit Test なし Mockito java VMで動作する
  instrumentation Test あり hamcrest Android上で動作する
  App Component Test あり   Serviceなどのテスト
UI Test single app Test あり espresso  
  multi app Test あり uiautomator v18以上。

local unit test

android framework に依存しないテスト。java vm で実行されるため、他のAndroidOSに依存するテストに比べて高速。

android.jar は実際のコードが存在しないため、例外をスローしてしまう。そのため、以下の対応をする必要がある。

  • Mockito で代替となるモックの処理を実装する
  • テスト対象を android.jar に依存しないコードにがんばってする

Mockitoで処理する場合

  1. unitTests.returnDefaultValues = true を設定し、android.jarの中を呼んだ場合に、例外ではなくデフォルト値を返すようにする。
  2. Mockitoでモックを実装する
#build.gradle
android{
    testOptions {
        unitTests.returnDefaultValues = true
    }
}

kotlinでMockito

Mockitoがkotlinの予約語を使っているので、バッククォートが入ってちょっと書きづらい

Mockito.`when`()

nhaarman/mockito-kotlin whenever()を使えばいい感じに出来そうだったけど、引数がnullを許容していないので使いづらい。

fun <T> whenever(methodCall: T?) = Mockito.`when`(methodCall)

こんな感じで定義し直せばそれっぽく使える。 shikajiro/mockito-kotlin にfork する予定。

instrumentation test

android framework に依存したテスト。Android のエミュレータや実機 で実行される

直ぐにテストを実行できない問題にはまる

Android Studio の右クリック > Run すると、JUnitテストとして動いてしまい、 Empty test suite. とエラーになりテストできない。 以下の雛形を元に Android Testとしてビルド設定を作り実行するとちゃんと動く。

single app for espresso

後で書く

multi app for uiautomator

後で書く

Tips

android library のテストで 64k 問題にはまる

テストと直接関係ない話だけど、テストライブラリとか追加してたらはまった。デバッグビルドの時だけ、multidexにする。

android{
     buildTypes {
        debug{
            multiDexEnabled true
        }
    }
}

dependencies {
    debugCompile 'com.android.support:multidex:1.0.1'
}

first blog

jekyll

jekyll でブログ書いてみます。 pelicanはテーマが少なすぎた・・・。