2017-03-10

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

チームビルディング

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

プロセス改善前の状態

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

プロセス改善

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

チームの再立ち上げ

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

開発チームできめたこと

決定のルール
DONEの定義
ワーキングアグリーメント

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

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年目スクラムとやって、もうウォーターフォールのチームには戻りたくない。なかなか大きい会社でスクラムをやることは難しいけど、気合や残業で解決することなく、人じゃなくて問題に目を向けるという意識が根付く。この意識が根付くことだけでも開発者が幸せになるフレームワークになるんじゃなかろうかと思っている。実際今年一年楽しかった。という振り返り。

リーン開発の本質

作者: メアリー・ポッペンディーク,トム・ポッペンディーク,高嶋優子,天野勝,平鍋健児
出版社/メーカー: 日経BP社
発売日: 2008/02/07
メディア: 単行本
購入: 6人クリック: 141回
この商品を含むブログ (67件) を見る

SCRUM BOOT CAMP THE BOOK

作者: 西村直人,永瀬美穂,吉羽龍太郎
出版社/メーカー: 翔泳社
発売日: 2013/02/13
メディア: 単行本（ソフトカバー）
購入: 5人クリック: 13回
この商品を含むブログ (33件) を見る

2016-12-12

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

2016-09-08

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

ぽえむ TIL

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のギリギリまでテストができる、しかも単純な。
とりあえずあんま難しいこと考えなくていい

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

2016-08-29

ばあちゃんが残した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

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

2016-07-26

アラサーの女子力を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

仕様としては以下。

skin:をトリガーにしてこのスクリプトを動かす
skin:30,3,5,3で水分量、水分、油分、柔らかさの順で投げる
スプレッドシートに記述

次ごとにシートを分ける

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

gist.github.com

結果

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

感想

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

おわり

2016-04-02

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

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

何エンジニアか

JavaでAndroidアプリを開発していました。

(ちなみに、学生時代は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年後これを振り返って「こんなちょろいことしてたのかーーーーー！」って思えるくらい成長できるといいな。

2016-02-15

【Android日誌】2016_02_08週_Collectionとは

TIL

Javaでまだまだわかってない部分もあるので、改めて調べる機会などもありました。今週のアウトプット少ない。

Collectionとは

Collection * List * ArrayList * LinkedList * Vector * * Set * SortedSet * HashSet * TreeSet * * Map * Hashtable * HashMap * TreeMap * SortedMap

LinkedList

LinkedListとArrayListの違い d.hatena.ne.jp
LinkedListの特徴 www.javadrive.jp 特にできることは同じだが、
読み出し性能重視はArrayList
挿入や削除の性能重視はLinkedList

Set

重複を許さないコレクション。 o1.equals(o2)が成り立つものはaddしてもaddされないし例外も吐かれない。

 Set set = new TreeSet<>();
        set.add(3);
        set.add(6);
        set.add(0);
        set.add(1);
        
        Iterator iterator = set.iterator();
        while(iterator.hasNext()){
            System.out.println(iterator.next());

        }
//0,1,3,6

独自にcomparator()をセットすれば自分で並び順を変えることができる。デフォルトは要素の自然順序付けによって行われる。