C-FRONT

エモくありたい

Groovy入門して躓きメモ

Java→Groovy初日で出会ったエラーたちやメモたち。 syntaxもよくわからない中で出会って、解決するのに慣れなかったのでメモしておく。

メソッドの呼び出し間違い

メソッドの呼び出しが間違った時

Caught: groovy.lang.MissingMethodException: No signature of method: hogepackage.hogefile.hogemethod() is applicable for argument types: (java.math.BigDecimal, java.util.ArrayList, groovy.sql.Sql) values: ...

特にクロージャの中でエラーが起きるとクロージャのどこでそれが起きているのかよくわからなくて慣れるまで時間がかかった。

変数の宣言のスコープ

http://d.hatena.ne.jp/Kazuhira/20120318/1332083318

before

def sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

eachの中からsqlは呼び出せない。

Caught: groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile
groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile

after

sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

def をつけているとクロージャ内やメソッド内から呼び出せない。

列名が無効

before

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }
警告: Failed to execute: SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = ? AND TYPE != 0 ORDER BY INSERT_AT because: 列名が無効です。
Caught: java.sql.SQLException: 列名が無効です。
java.sql.SQLException: 列名が無効です。

てっきりSQLが悪いのかと思ってタイポかどうか必死に探したけどSQLが悪いわけじゃなかった

after

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,TYPE,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }

eachRowの中で参照しているit.typeがselectするものに含まれてないため。 エラー行数をよく見るとit.typeを使っている行を指しているのでわかる

for文の抜けかた

https://stackoverflow.com/questions/3049790/can-you-break-from-a-groovy-each-closure 次のイテレートに入るならeachのままcontinueしてもOK そもそもループを中止したい時(Javaでいうbreakをしたい時)はfindにしてその中でtrueを返してループを終わりにする

pointList.find{
                Data data = new Data();
                if(nowPoint<it.point){
                  //breakと同じ。ループを抜ける
                    return true;
                }else{
                    //continueと同じ。
                    return false;
                }
}

TDDBCに参加&ペアプロデモをしました #tddbc

tddbcにスタッフとして参加&ペアプロのデモをしました。

tddbc.connpass.com

ペアプロのデモとは

TDDBCではTDDのやり方を学んだ後、参加者がペアになってペアプロをしながらTDDを実践するプログラムになっています。 このペアプロでどうやって進めていくのか、のデモを行いました。 今回は@yattomさんとFizzBuzzを題材にペアプロしました。

やってみて

ある程度台本があるので安心です。ここでこういう説明が入るとか。 でも後はその場の雰囲気です。実際のペアプロをやってみせてるだけなので疑問とかもガンガン言っちゃっていいので気は幾分楽です。 今回は@yattomさんがリードしてくださり説明などもしてくれたので、なんとかなりました。 自分の開発環境を前のスライドに映しながら行うので自分の開発環境へのツッコミも新鮮でした。

今回@PoohSunnyさんから煽られてデモをすることになったけど、「人前でライブコーディングするのが一番成長するからやってみな」と言ってくれたと聞いて感謝してます:pray: (FizzBuzzをライブコーディングして成長するかは置いておいて、新しい経験だったので楽しかったです!)

その他

  • 午後は参加者に混じってペアプロやってた。1年目、2年目のフレッシュな方とペアを組んでみて自分も気づきがあって何より楽しかった。
  • tddbcの参加者の方々は話がうますぎる。どんなコードを書いたかを前で発表する時間があるのですが、皆さんプレゼンがうまくて引き込まれる。
  • 他の言語チームのコードを見たり話を聞いたりするのがとても楽しかった。Spock使ってみたくなったり、良い興味の入り口になったと思う。次は覚えたての言語で参加したい。
  • 皆テストについての興味や悩みが共通事項としてあるので、質問タイムも懇親会の即興LT大会もすごく盛り上がって楽しかった。こんなアットホームで参加者同士でこんなに仲良くなれるコミュニティはすごい。

  • ペアプロしている同士ではすぐ疑問解決されるから良いけど他のチームメンバーに逆に伝わらなくなったりしないの?な質問だったと思う。
  • PRのコメント/質問をgithub上で返すのではなく、コードのコメントに反映して設計意図を伝える方法良いと思った。

最高だった。

楽しかった!!!

Tokyo Android Meetupで初英語プレゼンしてきた

Tokyo Android Meetupというイベントで初めて英語でプレゼンしてきました。

speakerdeck.com

#11 Tokyo Android Meetup - July Edition - Tokyo Android Meetup (東京都) | Meetup

Meetup内のイベントは日本開催でも外国の方が参加するイベントが多いらしく、hotchemiさんのブログを見て以前からmeetupのイベントに参加してみたいなと気になっていた。

参考:hotchemi.hateblo.jp

そんな時にCLEMのイベントに参加したことがきっかけでmeetup参加したことないけど喋ってみることになりました:bow: clem.connpass.com

準備編

初めての英語プレゼンだったので、アドバイス貰った通りどんなことを話すかスライドとそれに合わせてスクリプトを作成していました。 keynoteのnoteのところにスクリプトを書き出してそれを見ながら練習していました。 英語に関しては、先輩に単純な文法のミスや、言い回しのアドバイスなどをレビューもらいました。

また、内容に関しても直前に社内でLTする場があったので日本語で同じ内容を発表してなんとなく内容について雰囲気をつかんだりしました。

当日行って気づいたこと

英会話のレッスンとネイティブの人が話す速さ、全然違うので聞き取れなかった
  • 特に単語と単語がつながりすぎて人によっては全く聞き取れなくて辛かった
  • 1ヶ月半英会話続けて単語レベルで英語が聞き取れるようになったと思ったけど速く話されるととたんに駄目だし、はっきり発音されないと何も聞き取れないということがわかった。
DMM英会話で女性の先生のレッスンばかりを受けていたことを後悔した
  • DMM英会話初めて1ヶ月半くらい経つのですが、「なんか安心できる」という理由だけで女性の先生ばかり選んでレッスンしていた
  • 実際エンジニア界隈は男性が多いのでハードルばかりがあがってしまい当日場が和むまで最高にコミュ障だった
だんだんBGMになっていくのがわかる
  • 最初は頑張ってついていってたつもりだけど、途中から完全に頭がついていかなくて全然話が入ってこない
  • 自分の今のキャパシティはここなんだなということがわかった。これをどんどん伸ばしていけたらいいなと思った。

感想

  • レッスンで話される英語と実際の会話で話されてる英語はちょっと雰囲気が違うのでそれを味わう。本当の会話にどれだけ太刀打ちできるか試しにくる意味ではmeetupのイベントとても良いと思った
  • meetup参加すると、「英語ができるようになりたい」じゃなくてこの人たちと話がしたいという思いになってモチベーションアップに良い。
  • 参加している外国の方、だいたい日本語も知ってる人が多いので日本人に対して色々な事情理解・配慮してくれているなと感じた
  • デベロッパーが使う言い回しなどを覚える貴重な機会。同じ境遇の人が多いから真似できる言い回しなど多いなと感じた。
  • 今回はすごくアットホーム。10人くらいの小さなイベントで最初の英語プレゼンをするには良い場所だったと思う。たいしたことない話だったと思うのに、ウンウンうなづいて聞いてくれたのがすごくうれしかった。
  • 日本の勉強会とも一緒だが、speakerしたことで日本人だからと関係なく話しかけてくれる人もいて助かった。楽しかった。
  • まだ私が来るには早かった、と思ったけど参加してみたらすごく楽しくて参加してよかった。

だいぶ楽しんだ模様。定期的に腕試し&モチベーション維持の意味でも良いと思いました。

Spring Bootのキャッチアップにバージョンアップで理解を深めた話

最近Androidアプリ開発からサーバサイドの開発に移り、移って早々SpringBootのバージョンアップをする案件にアサインしてもらった。SpringBootはじめてです!の段階でプロジェクトのSpringのバージョン担当することもなかなかない話かと思うので、Spring Bootのキャッチアップという点からバージョンアップで対応する時に学んだことをここにまとめる。

前提

  • 業務で経験していたのはAndroid開発のみ
  • そういえば今まで業務でライブラリのバージョンアップを経験したことはなかった

要約

  • プロジェクトのSpringBootバージョンを1.2系から1.5系まであげた
  • SpringBoot始めたばかりで通常のエンハンス案件をやっているだけでは知らなかったと思える経験・感覚をつかめたので、学習の導入になった

バージョンアップを経験してよかったこと

SpringBootの導入には「はじめてのSpring Boot」でキャッチアップしていたが、そこでは知れなかったこと&もしこのままエンハンスをやっていたら知るのが遅くなってたであろうと思うことをいくつか。

ライブラリの依存関係について

バージョンアップ作業中に一番対応したのがライブラリの依存バージョンの解決だった。 //TODO:例えば AライブラリとBライブラリが中でCライブラリに依存してるが、AとBはバージョンによって依存するCのバージョンが違う、みたいなことが起こる。バージョンの違うライブラリに依存していると、順番はわからないがどちらかの依存versionしか参照できず、NoSuchMethodErrorで怒られる。この仕組みについて最初わかってないので困惑した。 mvn dependency:treeやpom.xmlDependency Hierarchyをみながら各ライブラリの依存ライブラリの整合性を修正していく作業が多かったかと思う。 ライブラリの依存関係を理解する過程で不要なdependencyなどを見つけたり、pom.xmlの整理の仕方も多少は身についたかと思う。

Android開発の時はライブラリのバージョンアップの経験がなくてライブラリ間の依存関係について意識することがなかったので勉強になった。

エラーログに向かう感覚の醸成

SpringBootを初めて触れた時、自分が書いたClassとは全く違うClassからエラーが吐き出されることにとても困惑した。今までは、基本的には自分の書いたコードからExceptionが吐かれることが多かったので、原因もわかりやすかった。 バージョンアップの対応にはたくさんのこうしたエラーに対応しなくてはいけないので、数をこなして慣れることができた。最初に感じていたゲッという気持ちはバージョンアップ経験後ではなくなったので非常によかったと思う。

参考にできるネット上のページの感覚

上にも関連することだが、たくさんエラーが出る中でわからないことを調べる時に参考になるページが集中的にインプットされる。最初はどうぐぐったらヒットするのか模索するのでとても効率が悪かったと思うので。 - Maven Repositoryの各ライブラリのDependency部分 - 公式ブログ - Release Note - Githubのissue - Javadoc - その他QiitaとかStackOverflowなどは普通に。。。 こう書いてみると当たり前なリソースな気がするが、これを経験する前はこれができなかったのである。

Springの各種プロジェクト間の関係性について

恥ずかしながら色々あるSpring系のFrameworkについて全く認識しないまま開発に入ってしまった。例えば以下などがバージョンアップを通して気づき経験した。 - starter系はversionが一緒になるのでそれを踏まえて依存関係を解決しなくてはいけない。 - Bootが依存しているSpring Frameworkのバージョンも変わるので、Spring Frameworkの変更点も確認しなくてはいけない。 - パッケージの変更などで新しくspring-securityをimportしなくてはいけなくなったり。 エンハンスだけしていたらあまり意識してなかったと思うので、いいきっかけにだった。まだ理解してないこともあるのだけど少しだけ。

バージョンアップするにあたり個別に対応したところ

どこで動かなくなったかがわからなくなるのが不安だったので、ひとつずつバージョンをあげて「ここまでは動く」を確認しながら進めた。 意外とボリュームが多かったので別記事にまとめる。うん。まとめる。

まとめ

キャッチアップ材料として「バージョンアップしてみる」選択肢としても考えてみるのも良いかもしれないと思った話。状況と必要性もあるが。 エラーのデバッグを集中的に数こなす意味ではSpring Bootの仕組みに慣れるのでよかった。エラー出ても少しは怖くない! プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。

JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3

JJUG CCC 2017 Springで登壇してきました。

JJUGについては以下。 www.java-users.jp

発表内容については以下を参照ください。 speakerdeck.com

ここからは忘れないうちに感想文。 外部イベントで2回目の発表でした。(1回目はこちら。)

chiiia12.hatenablog.jp

20分の発表は話の構成のしかたがすごく難しいなと思った。今回はストーリー作りもそうだし、スライドでの伝え方に結構苦戦して、結局最終的なストーリーに行き着くまでに何回か潰した気がする。20分のボリューム感、どこまで話広げるべきかがわからなくて、結局最後の練習まで17分で終わってしまうボリュームだった(本番はなぜかぴったり20分になった)。

本番は小さい部屋でしたが、満員で部屋に入れなくなるほど人が来てくれたり、発表後に質問に来てくれた方もいた。発表してよかった。。。 ちょっと今後気をつけようとおもったのは、新しいmacとアダプター経由でのプロジェクターへの接続が悪くてヒヤッとした。やっぱりしばらく旧macも一緒にもってないと怖いかも。

あとは他のイベントと比べてtwitter実況が少ないイメージ。どんなところが刺さったんだろう?ちゃんと伝わってたかな、心配です。

また登壇後、コーディングスキルアップの仕方について後輩と話したりして、結局今回レビューしてくれていた先輩がすごかった&かなり恵まれてたんだなぁということに気づく。 多分若手にとってもどんな知らない世界があるのかわからない、先輩にとっても若手がどこまで知らないのかわからない、このお互いの状態をつきあわす機会があって、うまく知識を整理してインプットしてくれる先輩がいて今回の内容に繋がったんだとおもった。 恵まれてる環境だったのは確かなんだが、より横展開しやすい形にできたらもっと良かったなと感じた。

あとは初めてはてなホッテントリに入って感動!準備してる時は地獄だとおもったけど、こういうアウトプットにできて今回CfP出してみてよかった。

ちなみに2017年の目標は「社外のイベントで登壇する」にしていて、これで叶ってしまったのでまた新しい目標を立てるとする。 自分のアウトプットに反応が返ってくる意味で登壇するのすごくよかったので、これからも機会あったらどんどん出してこ!

Node学園25時限目でLTしました〜初めての社外LTの振り返り〜 #tng25

Node学園というイベントでLTをしてきました。

nodejs.connpass.com

内容はこんな内容になります。

speakerdeck.com

ちょこちょこ社外のイベントには出てきましたが、自分でLTをするのは初めてだったので、振り返り&感想を書いておこうと思います。

準備編

スライドのトンマナ

社外でしゃべるのが初めてということもあって自分のパワポテンプレートを作りたいなーと思っていた。できることなら、スライドであっこの人だ!とブランディングできたら理想だなーと思っていた。 例えばtwadaさんはtwitterでslideのリンクが流れて来た時に、サムネイルだけでtwadaさんのスライドだとわかるので、ちょっとそういうのに憧れている。 なので、多少今後も改良はしていくだろうけど、ある程度今後も使うぞっていう前提でスライドのベースを作ってみた。

話を組み立てる順番

自分はイラレを使ってスライドを作っているので、あんまり話が固まってないままスライドのdetailを作り始めちゃうと結局時間が足りないだの、喋ってみたらちょっと違った、みたいなdiffが出てきてせっかく作ったスライドが無駄になるという知見を聞いていたので以下の順番で進めてみた。

  • だいたいのストーリーを組む
  • パワポで雑にスライド作る
  • スクリプトを組む
  • 時間におさまるか、ストーリーに合わないスライドは修正していく
  • 最後に詳細なデザイン

トーリー組むのって結構憂鬱なのではやく詳細なデザイン作り込みたくなってしまうのだけど、そこはぐっと我慢で最初にスクリプトまで決めてしまうのが一番無駄がなさそう。できればデザインに入る前に人にみてもらってストーリーラインを壁打ちするのがGoodだと感じた。

初心者向けでも楽しんでもらうために

Node学園というイベントは結構内容がギーク向けで、その中で初心者が初心者向けの発表をする時に、どうやったら聞いてよかったなーと思ってもらえるんだろうということは気にしていたきがする。 スライドシェアでスライドが見れるこの時代に生で聞けてよかったと思える発表は個人的にはストーリーの面白さ(笑えるポイントがあるとか)なんじゃないかなーと個人的に思っていて、ちょこちょこ笑えるポイント作れないかなーと思いながらストーリーは考えていたりしました。

  • 自己紹介で何か場がほぐれる掴み(ちょっとウケた)
  • 背景画像を地味に意味ありげな写真にしとく(誰にも気づかれずにすべった)
  • みんなが知ってる人のネタを仕込むとか(ちょっとウケた)

こんなかんじかしら。自分も笑いポイントってどういれていいかわからずLT経験豊富な同僚にアドバイスもらいながら最後仕込みました。 あとは、「初心者向けですよ」と最初に宣言することで期待値を調整するようには心がけたつもり。多分そこがズレていると厳しいまさかりが飛んできそう、お互いにとってよくない。

当日編

話している間はあっという間だったのであんまり覚えてない。けど楽しかった!!

拡散量がはんぱない

今までアウトプットのメインはブログだったけど、登壇&スライドの共有の拡散量はすごいなーと感じました。 あと当たり前だけどフィードバックの量が多い。どこらへんが共感してくれて、ほーと思ってくれたのかがわかるのはうれしいなと思ったり。自分が世に出したもので、はてぶ30とかはじめてもらった。あと内容が初心者向けでかつ想定読者層が広いといろんな人にひっかかるというのもあったのかも。

意外とtwitterの通知気づかない

結構どうでもいい話な気もするけど、今回まで気づかなかったので。 自分へのリプライ全然気づかず、あやうくとりこぼすところだったので注意深くみておかないと・・・。

あとは自分のスライドをシェアしてくれているツイートについては、短縮URLになっちゃったりのでタイトルも一緒でつぶやいてくれている人以外は検索にもひっかからない。自分の知らないところでつぶやいてくれてたりすることも多々あり、たまたま見つけたもののできれば全部拾いたいなーと。自分は登壇内容タイトルで検索かけてニヤニヤしていたのですがなんかもっといいエゴサの方法あるのかしら。

次に繋がる

Node女子学園でこの内容話してほしい。みたいに言ってもらったりして、次の機会につながった。 初心者向けって誰が参考になるんだろうかと思ってたけど、初心者向けの発表も新しい人が入って来やすく、学びやすい環境を作る意味で大事ですよと言ってもらえて本当発表してよかったなーと。今までJava/Android界隈の勉強会にしか行かなかったので新しい世界で知り合いが増えたのもすごく楽しかった。

LTの形にまとめることで知識の整理に

今回一つテーマを切って人に伝えられるレベルに色々組み直してLTと言う形にするプロセスがすごくやってきたことの整理にいいなと思った。意外とスライドにしてみたら、ここって本当はどうなんだっけとか間違ってること言ってないよね?の確認をする過程でも知識を深められたり。 これはブログでもできると思うけど結構自己満でいつも書きなぐっちゃうので、直で目の前に人がいて自分の言葉で喋らなくてはいけないLTのレベルまで思考を整理するのは大事だなと。

おわりに

今回初めてLTをしてみてこれはエンターテイメントだなとえもくなってしまった。個人的な話だが、昔ダンスで舞台に立っていた時、このイベントにはこのネタをやろうとかコンテストだからこういうネタにしようとか次はどのネタやる?みたいな感じで次はなんのネタを踊るか決めていた。それと同じことがこういう技術的なイベントに立つ時でも起きているなと思っていて、イベントに合わせてネタ変える感じとか自分のネタがどんどん増えていく感じとか、ちょっと昔を思い出した気がした。ダンスで舞台に立つのが好きだった時と同じ感覚が、もしかしてイベントで登壇することで味わえるんだとしたらこの世界には自分はすごくはまるし相当楽しめると思った。

こういうのを後押ししてくれる会社だったり、今の環境最高である。

次はこれに出ます!準備がんばります

www.java-users.jp

社会人2年目をエモめに振り返る

エンジニアとして2年めが終わったので振り返り。今思うことは今書いておかないと忘れちゃう。あと根がネガティブなので記しておかないと「私1年何やってたんだろう・・・」とすぐなっちゃうので。

ちなみに1年目の振り返りエントリは以下。

chiiia12.hatenablog.jp

今年度の主なトピックは以下。

  • Androidアプリエンハンス&その中で学んだ諸々。
  • スクラムチームの再立ち上げ
  • プライベートでのアプリ開発
  • 外部イベントの参加

が大きな出来事だったかと思います。

Androidアプリのエンハンス

1年目は新規アプリの開発がメイン&かなり短いスパンでチームを移動していたので、同じチームで一つのプロダクトを開発し続けるという経験は初めて。新規ではなくエンハンスをする中でただAndroidの実装スキル以上のことを学ぶきっかけになった気がする。

ライブラリの導入

今までのチームはモダンなライブラリをいれよう!という話があまりなかったので、今のチームに異動してきてから同じチームの先輩にはすごく刺激をもらった。

Realm、ActiveAndroid、Retrofit、などまだ使ったことなかったライブラリなどを、今年初めて触ったり。導入を進める先輩にライブラリの特徴・思想を聞いたり、何が便利なんだっけ?を考えたりするきっかけになった。特に先輩がRetrofitにプルリク送っているところを隣で見れたりして、すごく刺激になった。 その後、自分でチームにLightStreamAPIを導入したりできて、ちょっとだけチームのプロダクトどういう風にしていきたい?という気持ちが芽生えてきた気がする。 ライブラリを導入すると、何をどうやって便利にするライブラリなの?を考えるようになるので、自分で設計を考えるときにも参考になるなーと感じる。リスクの方が語られがちだったり学習コストなども考えるとライブラリの導入などはハードルが高かったりするけど、設計方針などのインプットにもなるのを考えるともっと導入すべきだなーとも思うようになった。

変更に強い・バグを生みにくい設計

先輩にココらへんの話のインプットはすごくしてもらった。あまり今まで設計のことを考えたことがなかった。正確にいうと、既にあるアーキテクチャに従う練習はちょっとしてきたけど、アーキテクチャを選択する練習をしてこなかった。なんでこういうアーキテクチャになっていてなぜそれを選ぶ?という観点がなかったので、そこを養えたのはよかった。デザパタとかクリーンアーキテクチャの話とかなどなど。 以下の記事は色々インプットしてた時で整理してた頃。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

あーちょっと恥ずかしくて見たくないエントリ…

テスト自動化

スクラムを再立ち上げした頃にユニットテストコードを書いていこうというルールになって初めてテストコードというのを書くことになった。 社内のアプリチームではテストコードを書いているチームがあまりなかったので良い経験になった。色々社内の先輩などに相談できる機会があったりなど、ただテスト自動化すごい!じゃなくてメリットやデメリット考えつつどう進めていったらよい?なことは考えるようになったかも。最初はデグレをなくしましょうという話からテスト自動化の話が始まった気がするけど、設計やリファクタの話につながっていくところまで考えられるようになった。 かなりここの分野も楽しくてこれからももっと知りたいなーと思ってる。

chiiia12.hatenablog.jp

スクラムチームの再立ち上げ

スクラムチームをどう立ち上げてどうなったかはこちらのエントリで。

chiiia12.hatenablog.jp

上のエントリに書いたとおりスクラムチームの再立ち上げを2回経験していて。2回やってようやくスクラムの良さみたいのを感じれた気がする。すごく今はアジャイルの考え方の虜になっていてここの分野ももっと知りたいなと思っている。 元がコミュ障で人の言うことをすごく気にしてしまうので、チームの環境によって自分のキャラを出せなかったりパフォーマンスも左右されてしまうんですよね。そういうところをスクラムとかのアジャイルフレームワークは多少でもカバーしてくれる気がしている。なので自分にはすごく合っていたのかも?と思ってる。

コーチの人に言われたことで印象に残っているのは 「問題解決は簡単だ、解決方法はいろんなひとが試しているからそこらじゅうに転がってる。大事なのは問題発見する能力。ここが長けている方が価値の高いことなんだよ」 というようなことを言われたこと。問題発見したからやばい、もうダメなチームだ、じゃなくて問題が見つかったってことは今まで見つからなかったことが問題として見つかったのは良いこととポジティブに言われたことが自分の中でも改善に対する捉え方が変わった出来事だったと思う。

プライベートでのアプリ開発

2年目になって1年目のように資格勉強に時間取られることもなくなったので、プライベートでサービス開発しているチームにjoinしました。Androidアプリ作りたいけどちょうど人がいないという時に誘ってもらって、タイミング良かった。 これまで社外でこういったコミュニティがなかったので、違う会社の話を聞けたり視野も広がったり。

www.service-safari.com

play.google.com

業務で試せてないライブラリやツールを試せる機会になったり、業務とプライベート複数同時にプロジェクトを進められる良さを知れた。一つ自分が作ったプロダクトができたのもうれしい。 その後自分一人でもう一個アプリ作ってみたのも勉強になった。CI自分で回したり自分でストアにあげたり。アイコンも自分で作ったり。自分が作ると他のアプリも注意深く見るようになるなー。自分だけでやってるので放置になりがちなのが反省点。

外部イベントへの参加

これも2年目になって業務都合をつけやすくなったので、ちょこちょこ外部のイベントにも参加するように。同じ年代の人がLT登壇とかしていてやばい!!!と良い刺激にも。

chiiia12.hatenablog.jp

去年も行きたかったけど行けなかったDroidKaigiにも今年初参加! 他の会社がどんなことに取り組んでいるのか、最新技術等やっぱり行かないとわからないことがたくさんでとてもよかった。登壇にも挑戦してみたいなぁ。

今年はDroidKaigiの公式アプリにもコントリビュートすることを目標にしていて、本当にちっっちゃなBugFixだけど英語でプルリク出してみたり。いつもtwitterで見るアイコンの人がコード見てくれて当日のContributersスライドにアイコンが載ったり。かなりうれしかった出来事。

今年度の最後にはJJUG CCCの登壇も決まり準備をそろそろ始めなきゃという感じ。去年はおっかなくて周りの人に投票なんてお願いできなかったけど、背中を押してくれる先輩もできて、いろんなコミュニティに投票をお願いできたり、良い関係のコミュニティが増えたんだなぁと感じて、前向きに色々がんばれてるなと思う。

その他

そういえば応用取ったし次は高度受けるかっつってネスペを受けたけど午後で落ちた。情報処理試験はいつも勉強がつらい。

後はちょっとしたクリエイティブ。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

後は会社でOSS勉強会なるものに参加したり(先輩のコードでnodeにプルリク送ってみたり)、外部の会社のエンジニアとTDD的な勉強会でGo触ったり。 刺激!な1年だったのかも。

まとめ

会社の先輩にこんなこと言われたのが印象的でそう信じてる言葉。

「エンジニアはやればやる程知らない事が増えていく。知らない事が減るってことは成長していないということだから、知らないことが増えていくことは良いことだと思って!」

この1年も色々新しい世界を知れて楽しかった!特に周りの人には恵まれていたなと思っていて、良いまさかりをたくさんもらえたなー。相談できる人も増えたしかなりのびのびやらせてもらえたと思っている。まだまだ技術力は低いと言われているのが悔しいところで、そこはこれからも伸ばしていきたいところ。

今年は取り組んできたことをブログなりなんなりにアウトプットすることを重視してきた気がする。ちょっとブログを読んでくれる人が増えたりして、自分のことを知ってくれる人がいるのはうれしいなーと思ったり。あと精神安定的にも◎。 今年は、ブログだけじゃなくてもっとコード書いてアウトプットしなきゃな。

次はどんな1年になるんだろう!3年目もがんばるぞー!