読者です 読者をやめる 読者になる 読者になる

C-FRONT

新卒2年目のエンジニア成長日記

#droidkaigiに行ってきて思ったことをダラダラ書いてみる

初めてDroidKaigi参加したので、ちょっとまとめるのが遅くなってしまったが記憶が新鮮なうちに考えていたことを残しておきます。 https://droidkaigi.github.io/2017/timetable.html

参加したセッション

参考までに参加したセッションは以下。

How to apply DDD to Android Application Development
リリース自動化と効率のよいリリースフローを求めて
インスペクションとAndroid Lint Custome Ruleによる、単一責任実装の実践
Data Bindingで開発を気持ちよくしよう
Android Resources Refactoring
オフラインファーストなアプリケーション開発
How to remodel current testing environment
What's New in RxJava 2.0
Android ORMの選び方
How to implement material design animation
Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
2つのアプリ、1つの設計のデザイン指針
エンジニアが武器にするMaterial Design
LayoutManagerをつくろう

特に強く印象に残ったこと

特に印象に残ったテーマを以下に記していきます

オフラインファーストなアプリケーション開発

https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa Realmすごい…。今のチームでもRealmいれてるけどバージョンが昔すぎて全然キャッチアップできてないことがわかった。 オフラインの時の体験を考えるってアプリならではの観点だから新鮮&そこにも踏み込んで考えていけるのがアプリのいいところ。

実際今のアプリってどれくらいオフラインファーストにされているんだろう

すごくこのセッションの内容に刺激を受けたので、オフライン状態で今のアプリがどれくらい使えるのか触ってみた。

  • Facebookinstagramgoogleフォト、メッセンジャーGoogle Play Musicはオフラインでもだいたい使える
  • instaは前に読み込んでいた10件くらいはオフラインでも見えるようになってる。追加読み込みだけできない。
  • twitterは微妙。ツイートはできる(iphoneのみ)けどタイムラインは見れない
  • Google Play Musicはすごくて、自分の評価した曲はオフラインでも聞けるようになってる。おかげで端末が圏外であることに気づかなかった。

今のチームのプロダクトはどうなんだっけ

アプリの業務仕様上最新の情報を常にリクエスト投げて確認しなくてはいけないので、通信エラーにすごく厳しいアプリになってる(オフライン時は通信エラーダイアログが出てで画面遷移できない)。オフライン時にアプリを立ち上げるとマジでなにもすることができないアプリになってた。

今まで「通信状況の悪さ」はアプリでは担保せず、ユーザーの状況が悪いんだよというふうに伝えてきた。けどこういう簡単に実装できるプラットフォームが出てきたりすると、通信状況というのはユーザーの責任ではなくアプリの責任になっていくのではないか?本当は通信エラーで画面遷移できないとかは、こっちの勝手な仕様のためにユーザビリティ落としているってことになるんだよなぁ。

なのでこれからはより通信状況に依存しないアプリの操作体験を作っていかなきゃいけなさそう、作っていきたい。 実際有名なトップレベルのアプリはオフラインでもある程度操作できるようになっているし、通信状況がないこともとても控えめに伝えるようになってる。気づきそうで普段意識してない観点を考えるきっかけになってよかった。

エンジニアが武器にするMaterial Design

https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design webと比較してアプリのデザインてグラフィカルなスキルだけでなくOSの標準の挙動とかOSが推奨しているデザインも把握していなきゃいけないよね→かなり負担なのでは?というところからアプリのユーザー体験みたいなところにエンジニアがもっと関わっていこうよ、というお話。特に、Androidは「iOSのデザイン、これAndroidにして」事件が多発しているし同じ課題を持っている人は多そう。

KPIの置き方のはなし

企画の人にとってはKPIに直つながる案件をしたいというのは当たり前なんだけど、時たま「ユーザビリティを多少落としてでも」アクションがあがる施策をやる判断になってしまうことがある。そういう時にわかってはいるんだけどもやもやするという経験があって、そういう時に「いやいや、ユーザビリティ落とすのはダメでしょ、なぜなら」を言えるエンジニアになりたい、けど言えない&うまく説明できない自分。この答えの一つが「エンジニアが武器にするMaterialDesign」なんだと思っている。本当はユーザビリティがKPIにつながっていること&重要さを証明できればいいのだが、現状難しいのかも。

キャリア戦略として

自分の会社はいわゆるグラフィカルデザイナーとUXデザイナーが別職種としているので、エンジニアがUXのところまで踏み込む武器のつけかたを見たことがなかったので、すごく刺激的だった。自分も興味がある分野だったので、これからどこ武器にしていくんだっけ?の参考にとてもなった。もうすごくステキな話で本当に聞きに行ってよかったと思った。

その他

他の会社の開発環境が聞けるの、すてき

なかなか会社内にいると開発環境も似たり寄ったりなので、他の会社の開発環境が聞けてとても刺激的だった。世の中のプロダクトがこんなにRxJavaやDaggerなどの今時のライブラリを使って開発してるとは…。ライブラリを入れる入れないはちゃんと判断が必要だけど、若干の悔しさを感じて帰ってきた。

企業ブース、すてき

CyberAgentのブースで看板サービスのbuild.gradleを公開します!という企画をやっていて、開発イケてます!ということがよく伝わってうまいプロモーションだと思った。転職考えてたら絶対候補にはいると思う笑

他にもいっぱいノベルティもらってとにかくはしゃいできた。

アプリのOSS化、すてき

あとは今年はDroidKaigiのアプリにコントリビュートするぞ!と決めていて、なかなかレベル高くてひよっていたけどちっちゃいバグフィックスでコントリビュート達成した。いつもネットで見ているアイコンの人たちにコメントしてもらえたり、コントリビューター一覧に名前が載ったり、はかなりモチベーションあがった(マージされた夜は興奮してしまって眠れなかった)。ただの参加者からDroidkaigiに自分も関わってるんだぞ!と思える感じ、最高。

まとめ

DroidKaigiのセッションはスライドも動画も後で見れるのだがやっぱり当日行って全部の時間なにかしらセッションを聞きに行くのがすごく良いことだよなと思っている。後で動画で〜だったら自分の知っている範囲で課題感持っているところしか見ないと思うので、新しい分野を聞きに行く点で生で参加するメリットはあると思う。アフターパーティに出れなかったのが残念。

ということですごく良い経験をしました。来年も参加したい。今後は登壇にもチャレンジしていきたい!

スクラムごっこからガチスクラムになって変わったこと

チームビルディング

自分のチームは以前からスクラム体制を取り入れていましたが、今年同じスクラム体制でもやり方をガラッと変えたことで感じたこと・変わったことをまとめてみたいと思います。ちょっとタイトルはキャッチーに書いちゃったけど当時は本気でやってたよ!

プロセス改善前の状態

  • アプリの開発チーム
  • iOS 4Android 4人 スクラムマスター1人の体制
  • 2週間スプリント 自分がジョインする前から「スクラム」で開発を進めていた。「スクラム」で開発するのが初めてだったので、元からあるやり方で先輩に聞きながら開発を進めていた。

プロセス改善

転機は有名なアジャイルコーチの方がアドバイザーの形で入ってくれることになったこと。その時色々選択肢はあったのだが、色々あってスクラムで続けていきたいとなって、もう一回スクラムをやり直すことになった。

チームの再立ち上げ

新しくスクラムチームを立ち上げる時にやったことが以下。

開発チームできめたこと

それまでのプロセスとは変わったところ

1週間スプリントになった

今まで月曜はじまりの2週間スプリントだったけど火曜始まりの1週間スプリントにした。 火曜日始まりの理由は月曜は休みが多いから。水曜始まりでもよい。 火曜日の予定は 午前中にスプリントレビュー、レトロスペクティブ。 午後にスプリントプランニング。 火曜日にスプリント切り替えを全部行う。火曜日は一日会議になる。会議の日と実装の日が完全にぱきっと分かれる。最初はうげーとなるけど結構よい。

タスク分解の仕方

案件を実装タスクに落とす際は0.5~1hになるまで粒度を細かくする。 「調査」というタスクは入れない。影響調査などはすべてプランニング中に終わらせる。 プランニングの時に徹底的なプランニングをすることで、あとの日は徹底的に計画されたタスクをこなすだけという狙い。これも最初むりでしょーて思うけどできるようになるしそれがとても良いことだと気づく。

要件を受け入れ基準として定義する

ここは開発チームだけでなく企画側にもお願いするお話。要件をもらうときにAcceptance Criteria(受け入れ条件)を決めてもらいこれを元にエンジニア側で設計・実装をするし、このA.Cをもとに受け入れをしてもらう。なんとなくの案でもらうと、受け入れる人によっても基準が変わってしまう。開発側はA.Cに書いてあることだけ実装する(それ以外の挙動は変えないが前提)。そこに漏れた要件は企画側の責任になる。ここで今まであいまいになっていた責任分解点ができた。

結果変わったこと

チームの中でプロセス変えてどうだった?という話をだべったのでその内容を。

常に緊張感が出る

2週間スプリントの時は前半だれていた、後半がんばる、というサイクルに自然となっていたみたい。 1週間スプリントは緊張感がある。提出まで中4日しかないので、ちゃんと時間通りタスクを消化していかないと終わらない。例えば1日何かがあって遅れてたら、2週間スプリントだと最大8日かけてリカバリできるけど、1週間スプリントだと最大でも3日しかリカバリにかけられない。

開発の奴隷化の解消

どうしても企画側の企画があってから開発があるので、以前は開発工程で出た問題は開発の問題になりがちで責められがち。本当は開発の問題じゃなくても。 案件を受け入れ基準駆動で行うことで、企画側と開発側どっちの責任かがはっきり分かれ、全部開発の責任になるということが減ったと思う。 どこまでがどちらの責任と決めたこと、決めたことに対して公平な立場で厳しく言ってくれる人がいたことで、開発側も「悪いって言っていいんや!」と、ちょっと安心した面はあったと思う。企画側にも物言える開発チームに変わりつつある。 実際に仕様が詰められていない案件については企画側の責任範囲になるので、開発側が詰められていない案件のカバー&実装みたいなことはなくなって開発は幸せになったと思う

問題発見フレームワーク

スクラムというプロセスは何かの問題を解決するプロセスというより「問題を発見するためのフレームワーク」と習った。これをやってみるまではあまり実感できなかったが、計画スプリント内に行うタスクを0.5~1hまでの粒度まで落とすという作業は、細かく指定する分計画と違いが出たときにわかりやすい。 今までは「実装4h」などとざっくり見積もりでよかったのかもしれない。けど本当は問題が隠れていたのかもしれない。 また、ここまでタスクを切るということはプロジェクト内の影響調査のしやすさにも関係があると気づいた。この方法をしてから「簡単にタスク分解しやすい」案件と「どこをどう直せばいいかをつきとめるのに時間がかかる」案件に分かれる。じゃあ後者ってこれあんまり良いコードじゃないのでは?と問題を問題と気づくきっかけをくれた気がする。

その他

以下はスクラムをいれたからというより今のチームの状況で得たものも参考までに書いておく。

スクラムマスターの不在

スクラムマスターの不在というとちょっと意味が違うのだが、スクラムマスターの方が異動になり、チーム内でスクラムマスターという肩書を持った人がいなくなってしまった。事実上、アジャイルコーチの方がスクラムマスターのような役割をしてくれていたのだが、週に1度程度の頻度でしかコーチングに来れないため、セレモニーのファシリテーションやレトロで出た施策の管理などはチームメンバーがやっていた。 今考えると当たり前だと感じる点もあるのだが、前の体制は全部スクラムマスターにお願いしてしまっていたのだ。あとは他のコミュニティで「ファシリがうまいね」と言われたことがあって、それはここでの経験だと思っている。

QAの不在

これは自分の会社であるあるなのかもしれないが、だいたい開発チームはQAの方がいて、テストを担当してくださる。うちのチームはなぜか(スクラム導入時にそのような体制にしたと話は聞いた気がする)QAが不在のチームだった。従って当たり前に自分達でテストをすべて行う。 自分たちで開発→テストを行うので、テスト工程まで見越した考え方ができるようになったと思う。 QAがいてくれる安心感からは、「不具合を出しにくい設計とは?」という観点が出てこない気がする。QAがいて不具合を見つけてくれることで大変なのはQAだから。テストの中だけの改善、開発の中だけの改善だけでなくて、テストの改善のために開発を改善するみたいなことが起きる、考えられるようになる。自分にとっては考え方がかなり変わったところだ。

まとめ

結局事業には貢献したの?と言われるとなんといっていいかわからない。この体制にしてからプランニング時間内にで1つの案件しかプランニングできてなかったチームが今はだいたい20この案件をプランニングしそれを実装までこなせるようになったのは設計・開発スピードが改善したのだと思うけど、厳密に見れば色々他にも要因はあるからね。 個人的には、アジャイルの考え方やプロセス改善の方法を学べたことはとても成長になったと思う。 新卒1年目ウォーターフォール→新卒2年目スクラムとやって、もうウォーターフォールのチームには戻りたくない。なかなか大きい会社でスクラムをやることは難しいけど、気合や残業で解決することなく、人じゃなくて問題に目を向けるという意識が根付く。この意識が根付くことだけでも開発者が幸せになるフレームワークになるんじゃなかろうかと思っている。実際今年一年楽しかった。という振り返り。

Visitorパターンと他のデザインパターンを比較してみる

ぽえむ Java

会社の先輩からインプットもらったので、理解定着させるためにも整理してみます。知識0前提はは承知を。

発端

この話になった背景は会社でやってもらってるコードレビューの場で、前からずっと継ぎ足されていたレガシーコードどう直す?となった時に出てきた話。

if(){

//処理。めっちゃ長い

}else if(hoge){

//処理。めっちゃ長い

}else if(huga){

//処理。めっちゃ長い

}else {

//処理。めっちゃ長い

}

こんなコードが出てきたら、StrategyパターンやCommandパターンが適用できないか検討するといいよーと。 今回はVisitorパターンで書けないか考えてみたと先輩が言ってたので私もそれで書いてみます。と書いてみることに。

Visitorパターン

visitorパターンとは http://www.techscore.com/tech/DesignPattern/Visitor.html/ https://ja.wikipedia.org/wiki/Visitor_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

Visitorパターン調べてると、Strategyとか色々出てきてよくわからない。 どんな時に使うパターンかというと、工程のような処理がいくつかあって種類によって工程が変わったり、なかったりする、みたいのをきれいに直せるよーらしい。

なので、以下みたいなコードが出てきたらVisitorパターンで書けないか検討すると良いみたい。

if(){

}

if(){

}
if(){

}

Visitorパターンにもいくつか種類があってinternalVisitorパターンとexternalVisitorパターンがあるんだって! http://qiita.com/lyrical_logical/items/bc6126f34a571a2c4f97

Visitorパターンは「データ構造」「走査方法」「処理」を分けて書くのがコアな考え方。 走査方法て何って感じだったけど「案内」と変えて聞くとちょっとイメージしやすかった。 案内係と実際の処理係。何を処理すればいいのかは処理係が知っているので、案内係は処理の順番だけ案内すればよい。ってイメージつけてる。

FactoryやStrategyとの比較

  • Factoryは生成に関するパターン
  • アルゴリズムを切り替えるのがStrategy
  • データ・走査方法・処理を分けるのがVisitor と一言で書くと、こんなかんじ?

例えばシャツの工程の話

例えばシャツを作りますー!の話をVisitorと例えばFactoryで考え方を比較してみる図。 f:id:chiiia12:20161212002120j:plain Visitorは一つの工程を順番にvisitしていく。工程の中の一つだけ変えたものを作りたい!ってなった時に一つの工程を入れ替えるみたいなことが可能。

f:id:chiiia12:20161212002056j:plain Factoryと比べると縦切りなのか横切りなのかで違うことがわかる。 どっちを使うかは、どういう仕様かによって変わってくるのかと思った。

結局デザインパターンって

色々なパターンを見ていくと、「○○パターンだけ!」を使って書ける、みたいのはない。 この観点だとStrategyっぽいしここはVisitorの要素が混じってるよねとか。実際今回Visitorパターンを書いたつもりが(理解しきってないのもあって)ここはFactoryの考え方、ここはStrategyっぽいってなった。 色々パターンがあるけど、どう分けるか?の違いなだけでどれが最適!ていう答えはその時々。 で、デザインパターンは「はしか」みたいなものだから、若い内に一回かかっておいた方がよいらしい笑 デザインパターンをいれよう!と思っていれるのは違うので、デザパタのメリットなどを知っておいて知らないうちにかこのパターンで書けてた!っていうのが一番良いコードになるのかなぁ。 一回極端にデザインパターンを書いてみるとそこら辺の塩梅がわかるようになるとのこと。

これ。私も書いてみたい。 https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

「テストが書きやすくなる」の意味を紐解く

ぽえむ Android日誌

Androidアプリの話です。MVPアーキテクチャAndroidにいれることでどういうリターンがあるんだろう?というのがもやもやしていて、「テストがしやすくなる」というメリットについてあまり実感持てずにいた。単体テストコードを書いていてなんとなくこういうことかなーと考えたことをまとめてみる。当たり前じゃん&間違ってるかもしれないけど、そこはご指摘いただければ…。

notMVPケース

前提

  • FragmentやActivityでAPIをたたいてたりDaoの呼び出しも書くケース
  • コールバックのinnerClassもFragmentに書いたり(privateで)
  • privateのinnerClassで持っているメソッドをテストしたい。
public class SampleFragment extends Fragment{


private static class hogeCallback {
    
    public void onSuccess(boolean ishoge){
            String testCase = ABテスト値取得;
            if(testCase==isA() && ishoge){
                hugaView.setVisibility(GONE)
            }
    }

}

書こうとするときにぶちあたる壁

その時確かめたいテストケースは「testCaseがhogeで、ishogeがtrueの時、hugaViewが表示されていること」だった。これを実現しようとして考えたことが以下。

  • privateのinnerクラスってどうやって呼ぶんだろう
  • assertは何でしたらいのだ?Espressoで表示中かどうかを確かめたらいいのか?
  • テストしたいケースはAPIを叩いた後のコールバック時のメソッド。どうやってその状況を再現する?
  • 単純なテストケースに見えるけど、なんか大変そうだということはわかった。

結局どう書いたのか

  • privateだったinnerClassをpublicにした
  • testCase変数の値によってテスト結果を確かめたかったので、testCase変数をメンバ変数でもたせる(コンストラクタで渡す)か、引数に追加する
@Test
public void hogeTest(){
    String testCase = "A";
    ViewGroup viewGroup = mock(ViewGroup.class);
    when(viewGroup.getVisibility()).thenReturn(View.GONE);
    SampleFragment.HogeCallback hogeCallback = new SampleFragment.HOgeCallback(context, viewGroup, 0, testCase);
    countCallback.onSuccess(0, true);
    verify(viewGroup, times(1)).setVisibility(View.VISIBLE);
}

だいたいこんな感じでテストケースを先輩に習いながら書いた。 正直、自分がこれを書こうと思ったら結構時間かかりそう。実際悩んだし。 結局、テストのためにプロダクトのコードを変える必要があってなんとなく良くないんじゃないか?と思っていた。

MVPで分けてみる

じゃあこれをMVPに書き換えて書いてみるとどうなるか? 簡単に、Viewじゃないところはpresenterにやってもらうようにした。

HogeCountTask task = new HogeCountTask(this).execute();

Fragment内で、API叩いてcallbackをもらう処理はpresenterに移す。

presenter.executeHogeCountTask();

presenterにlistenerをimplementsさせて、presenterの中でコールバックを受け取る

 @Override
    public void onSuccess(int count, boolean ableMoreSelect) {
        String testCase = getHelpMessageTestCase();
        boolean isShowHogeView = isShow(count, testCase);
        view.setVisibleHHogeView(isSHoe);
    }

    @Override
    public void onError(ResultDto resultDto) {

    }

こんなかんじ。で、ここでそもそも今回のケースではlistenerを継承したinnerClassは使わなくてよかったのでは?じゃあFragmentの中に書いてあってもテストの書き方は変わらないのでは?と思ったり。けどそれが気づけてシンプルにできたのならそれもまたいいところということで。

Presenterにロジックを移すということ

AndroidでFragment,Activityのテストをするのは気が億劫だ。(私だけなのだろうか) 正直正解がわからないし、どう立ち上げるのが正解かわからない。 presenterに移しておけば、Viewをモック化するだけでなんだかすごそうなツールを使わなくてもできる。

  @Before
    public void setUp() throws Exception {
        context = InstrumentationRegistry.getTargetContext();
        view = mock(SampleView.class);
        presenter = new SamplePresenter(view, context);
    }

    @Test
    public void 正常_isHelpMessageView() throws Exception {
        Method method = JobTypeSelectNewPresenter.class.getDeclaredMethod("isHelpMessageView",  boolean.class, String.class);
        method.setAccessible(true);
        boolean result = (boolean) method.invoke( true, "SHOW");
        assertTrue(result);
    }

だいたいこんなかんじ。privateメソッドだということ以外は結構スラスラかける。

結果「テストが書きやすい」ってこういうことなのでは?

  • 「これを渡したらこれが返ってくる」って思考をそのままコードにしやすい
  • viewのギリギリまでテストができる、しかも単純な。
  • とりあえずあんま難しいこと考えなくていい

雑なまとめになっちゃった。新しいアーキテクチャいれるって時、何が目的なんだろう、いれたらどんないいことがあるんだろう、って自分は今までアーキテクチャを理解するだけで考えられなかったので、少し違う側面が見えてきたかも?というお話でした。まる

ばあちゃんが残した800枚の絵をフォトブックにするまで

Creative

1年とちょっと前の8月15日、朝起きたらばあちゃんが亡くなってた。 葬儀や納骨が終わって少しだけ儀式が落ち着いた頃、母が部屋を掃除したところ、油絵が出てきた。しかも大量に。ばあちゃんの絵の部屋、倉庫、押入れ、どこ開けても絵が出てきた。だいたい800枚くらい。 まだまだばあちゃんの死を受け入れられなくて、何かこの絵をこのままにしておくのはもったいなくて、フォトブックにすることにした。

11月~2月 絵の撮影

まずは絵を写真ですべて撮影をする。 なるべく写真そのまま使えるよう、お家撮影セットを作った。 ホームセンターでベニア板と壁紙、何かをひっかけるアレを買ってきて、デスク用のライトで照らす。これで絵を撮影した。

f:id:chiiia12:20160829233442j:plain

だいたいばあちゃんが描いたジャンルは花、人物、人形、モノ(静物)、風景みたいだったので、ジャンルごとに撮っていくことにした。何に使えるかわからないけど一応番号をつけながら。

一枚ずつ番号をつけながら撮影していく過程で「この絵いいね」「これひいおばあちゃんのこと?覚えてる?」なんてひとつひとつ絵を見れた。 月1,2回実家に帰って少しずつ撮影していった。なかなかかかって結局ずいぶんかかってしまった。

6月~ 絵の整理・加工

だいぶ時間が空いてしまった。ちょっと絵を撮り終えて気が抜けてしまったがまだ仕事は終わってない。 写真を整理してみると、明るさはバラバラ。朝撮ったものもあれば夜撮ったものもあって。お家スタジオには入らない大きさの絵もあって、電球の暗い玄関で頑張って撮ったのもあった。 それに歪みがひどい。私が撮ったやつまじひどい。綺麗な正方形になってない。 ということで明るさ調整&歪み調整が必要になった。800枚。 f:id:chiiia12:20160821232412p:plain 明るさを調整した写真を… f:id:chiiia12:20160821232439p:plain 切り取る f:id:chiiia12:20160821232509p:plain 歪みを調整して f:id:chiiia12:20160821232544p:plain 長方形に修正。

photoshopで機械のように処理した2週間。 本当はスクリプトとか書いて自動化できたのだろうか?と思ったが私の実力ではわけわからず、ショートカットを設定するしかできなかった…。 なかなかに辛い&気が遠くなる作業だったが、また絵を一枚ずつ眺める機会ができてよかったと思う。

7月~ レイアウト&発注

気の遠くなる作業が終わった後は、レイアウトを作る作業だ。 発注はapple photobookサービス。 www.apple.com

apple photobookサービスは自動でレイアウトが組まれたのを選べるのだが、キャンバスのサイズが縦横比が自由すぎて、絵をだいぶ削る必要がありそうだった。また、7月末の一周忌に間に合わせたいという母の要望を叶えるため結構なタイトスケジュールであったため、自分でレイアウトを組んだ方が早いと判断し一枚ページとして作ることにした。 f:id:chiiia12:20160829232012p:plain イラレでなんとなくレイアウト組み… f:id:chiiia12:20160829232203p:plain こんな感じにして入稿!

混んでいる時期だと2週間くらいかかると聞いたので早めに急いで出したけど、結局5日で来てappleすごい。

完成

150ページくらいの大作になった。(デフォルトは20ページ) 同じページを2枚入稿してしまったことと若干の日付を間違えてしまうドジっ子は許してもらった。

f:id:chiiia12:20160829232611j:plain f:id:chiiia12:20160829232608j:plain f:id:chiiia12:20160829232604j:plain

手元にコンパクトで置いておけるフォトブックにできたこと、なによりばあちゃんの油絵キャンバスをデータ化できたことはちょっとホッとしたかもしれない。 結構好きな絵がみつかったこと。家に絵を飾るって結構いいかも。なんて。 せっかくだからもらってくれる人がいないかな、なんて。 せっかくたくさん家にある絵を活用したいななんて思う夏の終わりなのでした。

アラサーの女子力をslackで監視する

日常

事の始まりは「20代女子は肌に投資すべし」というツイートに煽られエステのお試しに行った私が彼氏に「エステ通いたい…」とつぶやいたところから。 「それって効果あるの?」から始まり、「KPIは?」「どうやって効果あるって測るの?」「きちんと数字でモニタリングして効果があったらいいんじゃない?」と煽られた。くそう!その通りである ということで肌の調子をモニタリングできる環境を整えることにした

測定ツールの導入

今まで肌の調子を測るものは私の感覚であった。なんとなく化粧のノリがいいぞ、つるつるしてるぞ、と自分の感覚値でしかなかったので、客観的にわかる数値を出せるものを探した。 すべての肌の調子は水分量に宿ると信じてこちらを購入。

https://www.amazon.co.jp/gp/product/B008N4KKKA/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

毎日の測定

朝起きてからこれで毎日同じ位置で測定。 これをスプレッドシートにでも記録してグラフにでもしてやろうと思っていた。 amazonのレビューを見てると、夜スキンケアした後だと高く出たりで安定しないので、朝起きた時がよいとのこと。ということで朝起きた直後に毎日測ることにした。

パックした次の日とかは水分量が高く出たけど謎。

f:id:chiiia12:20160726225543j:plain こんな感じで測定できます

めんどくさい

スプレッドシート開くわけがない 朝メモまでは頑張ってするけどその後、スプレッドシートに記録することなく一週間が過ぎていった。

つぶやいたら記録しておいてほしい

ということで、slackでつぶやく→スプレッドシートに自動で記入されたら負担が楽になるのでは?と思いスクリプトを作った。

ボット作成 http://qiita.com/kyo_nanba/items/83b646357d592eb9a87b

ライブラリ http://qiita.com/soundTricker/items/43267609a870fc9c7453

slackのchannelIdを取得 http://qiita.com/Yinaura/items/bd28c7b9ef614696fb7e

ほぼこれでいけた。ありがとうございます。

ハマったところ

GASで何かを書くのがなかったのでちょこちょこ初心者のハマりしたかと思う。

slackからのコマンドを受け取る

  • ウェブアプリケーションとして導入
アプリケーションにアクセスできるユーザー:全員(匿名ユーザーも含む)

にしていないと届かない。

  • コードを変更した後→ウェブアプリケーション導入 バージョン情報をあげないとコード内容が変更されない

受け取ったデータをスプレッドシートに移す

http://qiita.com/nurburg/items/744ec53477f4ae328555

仕様としては以下。

次ごとにシートを分ける

結構日毎だとあまり変化がなくて効果がわからないので6月分のシート、7月分のシートなどに分けて月次で数値も出したらわかりやすいのでは?と思い、新しい月になったら新しいシートを作るようにちょっと手直し。

gist.github.com

結果

slackで朝測定した値をつぶやくとbotが返ってきて成功。 f:id:chiiia12:20160726224850p:plain こんなかんじで記録されます。 f:id:chiiia12:20160726225220p:plain

感想

  • slackの可能性無限大。
  • 毎日知らずのうちに溜まっていってるのが楽しい。
  • スチーマあてて結構頑張った時は次の日の水分量高い(飲み会後とかで適当に寝た時は低い)
  • 6月の平均値:40.29411765 7月の平均値:40.58823529 微妙すぎる
  • 女子力あげたい!!!!!

おわり

文系からエンジニアになって1年が経っちゃったよ

文系でバックグラウンドなかったけど、新卒入社でエンジニアとして配属、働いて1年経った区切りなので振り返ってみます。

何エンジニアか

JavaAndroidアプリを開発していました。

(ちなみに、学生時代はHTML,CSSをちょろっと書いていたくらい。webのフロントに必要なJSも少しだけ。)

1年間の仕事内容

JavaでWebアプリ開発(研修)

研修でJavaを学習、フルスクラッチでWebアプリを1本書いた。 今まで「ちょっとかじってきましたー」がいい感じに叩き潰されて一からJava勉強できてよかった。

新規アプリ開発①

OJT的なプロジェクト。1ヶ月ほどのAndroid学習期間の後アサイン。 ベテランの先輩のサポートもたくさんあってAndroidアプリってこうやって開発してリリースするんだぁ、って一連の流れがわかったという感じだったと思う。コーディング規約に沿ってないとか超基本的なところを指摘されてた。

新規アプリ開発②

1つめのアプリをベース&ちょっとアレンジしたアプリで、ベテラン先輩なしで1ヶ月ちょっとで開発。 少しずつできることも増えたけど不具合お化けである。 iPhoneアプリがすでに先にリリースされていたので、「iOSが正で!」的な要件だった。 iOSではできるけどAndroidでは実装つらい挙動とかにぶつかってAndroidのデザインとは?みたいなことを考えていたような気がする。

新規アプリ開発③

もうひとつ新規アプリ開発をした。規模は小さかったけど、MVP設計を取り入れて開発したアプリ。 設計とは?みたいなところも初めて考えるきっかけにもなった。結局何が嬉しいの?ってところをよく議論・考えたような気がする。 この時にかなり細かいところまでガッツリコードレビューをしてもらったのがとてもよかった。 そのお陰で「こういう書き方にした方がいいのでは?」みたいな意志がやっと芽生えた気がする。

tech.recruit-mp.co.jp

konifar.hatenablog.com

既存アプリのエンハンス

すでに数万のアクションをもっている既存のアプリチームに入った。 スクラムな体制で開発を進めていて、いくつかエンハンスの案件をやらせてもらった。 エンハンスで入るのは初めてだったのと、今までとは比較にならない規模の大きさ&ソースコードの複雑さで最初はかなり大変だった。あまり新しくコードを書いて機能を追加したりはしなかったが、プロダクトオーナーからの要求に対して最適な手段を提供するにはどうしたらいい?みたいなことを考えていた気がする。既存のコードがあるから、Howが一筋縄ではいかない、じゃあどうする?みたいな壁にたくさんぶつかれた気がする。

資格など

1年目に会社から課された資格が以下の3つ。ギリギリだったりしたけど3つ全部受かった。

Oracle Java Silver

研修でも業務でもやっていたので、良い復習&穴を埋める機会になってかなりよかった。 それまで「やさしいJava」みたいな本しか読めなかったけど、この資格きっかけに「Perfect Java」のありがたさを知る。今までなんとなくでしか理解していなかったものを色々発見しながら深められたのは楽しかったし、ベースアップにもなったと思っている。 いつでも受けられるけど受験料がクソ高いのが難点。

www.amazon.co.jp

応用情報技術者試験

ここから業務とはあまり関連のない分野もたくさんで辛かった。 2ヶ月くらいガッツリ土日の時間を割いて勉強していた。半年に一回しか試験がないし、落ちてもごまかしようがなくてかなりのプレッシャーだった。 情報系の全般知識を広く学べたのはよかったと思う。名前でも聞いたことがある&なんとなくあそこらへんの言葉だ、というのが今後に生きると信じてる。

LPIC レベル1

これも業務との関連性はなし。3月ギリギリまで残してしまった。 試験に受かるための勉強になってしまったことが反省。 コマンドのオプションなどかなり細かいところまで聞かれる自分にとっては鬼畜試験だった。 内容はとても楽しかったけどね。101に関しては一回落ちたんだけどね。受けなおしてなんとか取ることができました。

www.lpi.or.jp

業務以外

プロコン

同期と何人かでやっているプロコン勉強会。 蟻本を参考に毎週1問ずつ解いてきてAOJ,POJに通すというもの。 最初は何回やってもWA(Wrong Answer:そもそもロジックが間違っている・パターンが網羅されていなかったり)で通らなかったけど、少しずつ通るようになってきたり、 TLE(Time Limited Exceeded:制限時間内に返ってこない)になってなんでだろう!!とか少しずつ悩みの内容が変わっていくのがうれしかった。 CodeFestivalの予選を解いてみたり、などなど新しい世界を同期には教えてもらって結構楽しかった。

www.amazon.co.jp

AIZU ONLINE JUDGE: Programming Challenge

Welcome To PKU JudgeOnline

(おまけ)動画編集

副産物的な話ですが、 1年目で懇親会や忘年会などなどで新人芸をやる機会などが多くて、動画を作る・編集することが多かった・・・。結構楽しくてハマったところもあったので動画編集も新しい世界だったかも。

その他

  • Rails Girls Tokyoというイベントに参加したり
  • potatotipsにも参加してみたり
  • 会社で「Arduino触ってみた」でLTしたり

などなど少し興味の幅も変わってきたり、手を出せる幅も変わったのかなぁと感じています。

railsgirls.com

connpass.com

1年を総じて感じたこと

時間の使い方が大事

本当に時間がない(というか使い方が下手だとあっという間に過ぎていく)。できる人は家でも努力している。まだまだ時間の使い方が下手だったと思う。 そういうのを感じて「もっと頑張らなきゃ・・・私できてない・・・」と奮起&鬱にもなったり。 飲み会も選んで行くようになった。 以下の記事にはハッとさせられた・・・ life.libinc.jp

深ぼる癖をつける

私がこの世界に入った時は「これは呪文だからそういうものだと思って覚えようね」などと言われたりした。これが染み付いていて、必要になったらその分の知識をつけるという流れになっていた。 普段から調べる・深ぼる癖をつけておかないと、いつまでたっても活躍できるエンジニアにはなれないなと感じた。

指摘されなくても気づける能力がほしい

もはや願望ですが、今年1年は新人だから指摘される機会が多かったのもあって気づいたこともあったと思う。技術力に関してもコードレビューしてもらえないとスキルアップできないとなると困る。 自ら成長するとか簡単にいうけど、そして今まであんまり意識していなかったけど色々方法を模索していかなきゃいけないと感じた。2年目怖い。

最後に

1年間通して「どうしても勝てなさそうな相手」がいるということがわかったり、自分のできなさにかなり悩んだところもあった。「やっぱり私向いてない」とか「無能って思われるの辛い」とか色々感じていたけど、「できないけどこれからどうしていくか」について前向きに捉えられるようになったのはよかったと思う。まだ頑張れる。 書き始めたらどんどん書くことが湧いてきてこんなに長くなったし、それだけ新しい世界には出会っているんだな! 1年後これを振り返って「こんなちょろいことしてたのかーーーーー!」って思えるくらい成長できるといいな。