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;
                }
}

2017-10-08

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

イベントぽえむ

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

tddbc.connpass.com

ペアプロのデモとは

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

やってみて

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

デモプレイヤーさんが Vimmer なのが気になる…… #tddbc
— えび🦐 (@ebc_2in2crc) 2017年9月30日

eclipse英語で使うの地味に大事だよね #tddbc
— てらひで (@terahide27) 2017年9月30日

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

その他

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

GitHubのPRで質問が来た場合はソースコードにコメントで回答する。これいいなぁ #tddbc
— おれたま (@AHA_oretama) 2017年9月30日

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

ご査収ください #tddbc pic.twitter.com/VxpMv57vT5
— ガオピン (@gaopin1534) 2017年9月30日

最高だった。

みなさんお疲れ様でした！！！ #tddbc pic.twitter.com/ftomcuBZsL
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日

楽しかった！！！

2017-07-26

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

次回のTokyo Android meetupでtalkをすると良いと思いますね😇 cc: @niko_yuwono
— hotchemi (@hotchemi) 2017年6月29日

準備編

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

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

当日行って気づいたこと

英会話のレッスンとネイティブの人が話す速さ、全然違うので聞き取れなかった

特に単語と単語がつながりすぎて人によっては全く聞き取れなくて辛かった
1ヶ月半英会話続けて単語レベルで英語が聞き取れるようになったと思ったけど速く話されるととたんに駄目だし、はっきり発音されないと何も聞き取れないということがわかった。

DMM英会話で女性の先生のレッスンばかりを受けていたことを後悔した

DMM英会話初めて1ヶ月半くらい経つのですが、「なんか安心できる」という理由だけで女性の先生ばかり選んでレッスンしていた
実際エンジニア界隈は男性が多いのでハードルばかりがあがってしまい当日場が和むまで最高にコミュ障だった

だんだんBGMになっていくのがわかる

最初は頑張ってついていってたつもりだけど、途中から完全に頭がついていかなくて全然話が入ってこない
自分の今のキャパシティはここなんだなということがわかった。これをどんどん伸ばしていけたらいいなと思った。

感想

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

speaker枠でもらった🎉 pic.twitter.com/WxWSdwDrS3
— よこ　ち！ (@chiiia12) 2017年7月25日

Second talk is Introduction to Calabash by @chiiia12 pic.twitter.com/noiuq0ofMY
— Niko Adrianus Yuwono (@niko_yuwono) 2017年7月25日

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

2017-06-25

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

Java

最近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.xmlのDependency 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の仕組みに慣れるのでよかった。エラー出ても少しは怖くない！プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。