本編久しぶり！最近、本職で満足してたし、家族のイベントがいっぱいあるし、OSSから離れてたんだけど、自分が使いにくいということでfind-pull-requestプラグインの更新した。メジャーアップデート。メニューの位置を変えました。元々は右クリックのメニューのトップに2つともいた。ブラウザ開く機能: 右クリック | Open In | Pull RequestURLコピー機能: 右クリック | Copy / Paste Special | Copy Link to Pull Requestになった。cmd+shift+aで利用してる人はメニュー名が変わったので注意してね。なんか探すの難しいから他に方法ないか今模索してる。The action "Pull Request" is not easy to find from cmd+shift+a · Issue #157 · shiraji/find-pull-request · GitHub2020年の時にこの機能を出して放置してたんだが、Copy / Paste SpecialやOpen Inってメニューができて、ずっと汚いなーって思ってたけど、いい加減直すことにした。頑張った。ちなみにTwitterに報告しようかとも思ったんだけど、あんま関わりたくないので、ここで報告だけして終わりにします。次の記事でUI以外で何やったか？の詳細を書きます。一旦メジャーアップデートの報告だけ。以上。

find-pull-requestプラグインをメジャーアップデートした

先日、初めて、Meetyさん経由でカジュアル面談をさせて頂きました。meety.netちなみにカジュアル面談とは名ばかりの会でUbieの紹介とか一切せず、リンク先にある内容の通り、ひたすら医療情報に関して話しました。資料もさくっと作って、それをベースに話していたのですが、それを社内にちら見せしたらなかなか好評で、じゃあこの話をブログにも書いてみようということで、今ブログを書いております。医療のレガシーデータから会社(Ubie)を守りたい というタイトルのスライドです。全体としてはタイトル入れて16Pあります。スライドは直接お話しする時のお楽しみと言うことで今日はそのうちの何枚かを使い内容を紹介します。二つのトピックに関して話しています。医療データとは何か？Ubieではどう守っているのか？医療データとは何か？まず医療データですが、ざっくりというと2種類あります。Ubie社内で生成しているデータ外部に委託して生成しているデータそれぞれ説明していきます。Ubie社内で作っているデータ社内の医師が作っている・監修しているデータ医師がスクラムに入り、開発に必要なデータを必要なタイミングで作っていきます海外向けの方はシンガポールにいるグローバル担当医師（日本語話せない）が担当データの管理方法や同期方法も説明しますが、詳しくはこちらで！meety.net外部に委託して生成しているデータ薬、ICD10(国際疾病分類)、医療機関情報、これらは外部に委託しています。電カルベンダーさんや薬局でこういったデータが使われています。私たちもそのデータを使わせてもらおうと思ったのですが、いくつか問題があります。IDは変わるものCSVで最新版のみもらえるはい、IDは変わるものです数百万レコード月1更新 -> 普通にdumpしたら、サービス止まる（実績あり）これらは代表的なものですが、他にもいくつか問題があります。委託のデータが悪いわけではなく、それらの本来の目的とUbieのようなWebサービスのデータに対する狙いが乖離しているために発生している問題です。業界ではUbieの方がまだまだ異端児だったりします。詳細はmeety.netCalendlyも用意してあるよ！！！calendly.comあと、今回話さなかったので、ここで初出しですが、実は外部委託のデータから内製に切り替えたデータも存在しています。これは外部委託のデータがあまりに多く、そのまま利用するとデータが多すぎて逆にユーザを混乱させてしまうのがわかったため、社内医師により、内製に切り替えました。このあたりの話も当然・・・各種サービスでのデータの扱い方そのまま使う組み合わせて使うユーザが上書きして使う可能性あるほとんどがUbieの内製データそのまま利用することが多いですが、内製データと委託しているデータを組み合わせて使っているものもあります。さらに最近は、社内外のユーザがそのデータを上書きすることもあります。これはいろいろここで書くと長くなりますので、ぜひカジュアル面談でお話ししましょう！meety.netUbieではどう守っているのか？次にUbieでは実際どうUbieのシステムを外部のデータから守っているかの説明です。ざっくりとしたアーキテクチャ図を見ながら実際どうやっているのかを説明します。このアーキテクチャでどうデータを入れているのか？システムを止めないか？他のサービスとの関わり方などを・・・もう話した方が早いんで、応募してもらえませんか？meety.netcalendly.comTwitter DM公開してます。Meetyさんのチャット自分気づけないので、出来たらこっちの方が連絡取りやすいです！twitter.com最後に最後に現在対応している問題について説明します。上書きできるデータに対して、データの優先度を考えたり、月1の更新をしたり、以下略！ということで、絶賛お話相手になってくれる方募集しております。meety.net最後2Ubieではどのポジションも絶賛採用中です。特にこのブログにアクセスするであろうエンジニアは常に人員が足りません。一度ぜひこちら見てみてください。recruit.ubie.lifeあと、実はですね、Ubieは生活者向けのサービスも作っています。体調が悪くなった人がスマホで受診相談が出来ます。ちょっと体調悪いなー病院行った方が良いかもなー？不安だなーって人はぜひこれを使ってみてください。ubie.app最後にUbieの普通のカジュアル面談して欲しいという方はこちらを見てください。https://meety.net/matches?q=Ubie以上です。それではカジュアル面談応募楽しみに待ってます！

Ubie(が関わる医療データ)の話を聞いてくれ！！！

graphql-javaで@deprecatedがついてるフィールドにアクセスするクエリを見つける

みなさん、リモートワーク、テレワーク、WFH生活どうでしょうか？この生活がどれだけ続くか分かりませんが、案外会社が回ることがわかったことですし、新型コロナウイルス問題収束したあかつきにはリモートでの仕事をすることができるような日々が来るかもしれませんね。そんなご家庭にこんな働き方もありまっせ！ということで、決まった曜日にリモートをすることにより、共働きの家庭の未就学児に習い事をさせ、子育てを充実させてみたので、それについて書いてみます。前提Ubieの定義Ubieには2020年3月現在、UbieとUbie AI Consulting(UAC)の2つの組織が存在しています。このエントリーでは私が所属している開発を主に担当しているDevチームの話になります。UbieのDevチームはコアタイムなしのフルフレックス制度を採用しています。UACの詳細はきっと UAC代表 がどこかでしてくれると思います。楽しみにしていてください。平日の子供の習い事共働きで保育園に子供を通わせてるご家庭ならわかってくれるはず！と思うのですが、平日子供に習い事をさせるのはほぼほぼ無理です。平日の習い事は15時には帰宅する幼稚園に通っている子供向けに時間が設定されており、15:30~16:00くらいからスタートし、18:00までには終わる時間になっています。6時間勤務の時短を使っているご家庭は16:00~17:00くらいに退社することが多いはずです。その時間に会社から子供を迎えに行き、習い事のところまで届けるとしてもかなり厳しいです。私たち夫婦はフルタイムの共働きで、私がUbieに入社するまでは平日の習い事なんて考える余地がないくらい無縁なものでした。リモート利用状況Ubieには新型コロナウイルス問題以前から週2日のリモートワーク制度が存在しています。新型コロナウイルス問題以前の私のだいたいなリモート利用状況はこんな感じです。月曜日 基本出社。木、金に出勤すべき予定が入っていれば、リモート火曜日 リモート水曜日 会社の出社推奨日であるため、出社木曜日 予定が無ければリモート金曜日 木曜日がリモートできなければ、リモート1年間このルールに則って出社したりリモートしたりしていました。少なくとも週1は必ずリモートでした。それと半年経過して書いたエントリーにもありますが、出社時間は10:00-17:30にして、子供の送り迎えをし、タスク消費量が足らないので、その後は家で仕事をしています。shiraji.hatenablog.com水曜日水曜日だけ特殊で、出社推奨日となっています。基本この日はリモートせずに対面でみんな集まろう！と決まっています。その水曜日はスプリントのレビュー、全社でOKRの進捗確認、全員でやる採用定例などなどを実施しています。月、木、金月曜日をリモートしてしまうと水、木、金と三日連続で満員電車に乗らないといけない状況に陥るので、基本的に木、金のどちらかをリモートするようにしていました。あと月曜に出社すると週が始まった感があってシャキーン！🤩としてその週のパフォーマンスが若干よくなってる印象があります。。。（多分気のせい）火曜日さて本題の火曜日のお話です。習い事に通わせる経緯そもそもの発端は4歳児の運動会の時でした。私の息子は他の子たちと比べ、明らかに運動が出来ない子という感じで各競技をこなしていました。別に苦手なら苦手で良いのですが、息子は運動することがどちらかと言うとかなり好きな方であり、息子自身も何か歯痒いそうな感じが見て取れました。納得が出来ず妻と2人で振り返りをしました。そこで気づいたのが私と妻は共に保育園や学生時代は早く家に帰ってくることができる子供で、帰ってきたら外で遊ぶ生活をしていたそのため、子供とは親が何もせずとも普通に運動ができるものだと言う認識だった息子は家に帰ってくるのが19:30過ぎ。平日運動する機会が他の子供たちと比べ少なく、運動する機会を提供できていない完全に私たち親の問題だと気づきました。そこで運動ができる習い事をさせてあげようと探し始めました。ただ4歳児ともなると習い事をする子供が多く、特に保育園児が通う事ができる土日の習い事は半年待ち（ただし半年で入れるとは言ってない）状態で、空いていたのが、火曜日の15:30~17:30までやっている運動教室でした。当時まだUbieに入社して数ヶ月でリモートもあまり積極的に活用していませんでした。しかし、この習い事に通わせるため、数ヶ月週2リモート+フレックス生活を試し、自身のパフォーマンスを落とさずに仕事ができることを確認してから、息子をその習い事に通わせることにしました。初日にその習い事のお試し体験をさせてもらいました。あの時の息子の笑顔や楽しそうな大きな声は1年経った今でも鮮明に覚えています。本当に心から運動することを楽しんでいる息子を見て、ものすごく嬉しかったし、同時になんでもっと早く気づいてやれなかったのか？と後悔もしました。何がなんでもこの生活を回していくぞと決めた日でもありました。スケジュールざっくりとした火曜日のスケジュールはこんな感じです。火曜日のタイムテーブル夜は21時くらいまでは仕事してますが、子供の習い事のときの自分のパフォーマンスが悪かったら、もう少し遅くまで仕事してますし、そのスプリントで進捗良ければ、20時頃には切り上げたりしています。（冷静に考えて奥さん仕事し過ぎでは？🤔）火曜日午後の会議順調にリモートしつつ、習い事に行かせる生活を送っていたのですが、7月頃に大きな問題が発生しました。その時まで実は私と大半がリモートの業務委託の人たちだけのチームに所属していたため、同期的なコミュニケーションを取らずにリモートで仕事をすることができていました。しかし、7月頃にオフィスでスクラムをバリバリこなしているチームへ移籍となり、同期的なコミュニケーションが必要になりました。スクラムの各種セレモニーにも参加する必要があります。特にこのチームに移籍することの問題だったのが火曜日の午後に実施していたリファインメントでした。リファインメントは重要なスクラムセレモニーの一つで一回出ることが出来ないと次以降のスプリントのキャッチアップすることが厳しくなります。このタイミングで子供の習い事を辞めさせることを検討すべきかもしれませんが、あの笑顔を見た後にこの習い事をやめさせることは私の中に選択肢としてありませんでした。そこで、チームにリファインメントを午前中に変更してもらえないか？と話したところ、こんなプライベートな理由だったのですが、快くリファインメントの時間を変更してくれました。Ubieの本当に素晴らしいところは、チームメンバーのパフォーマンスを最大限引き出せる環境をみんなが真剣に考えて作ってくれる事です。この件に関して本当に感謝する事しか出来ません。ありがとうございます。この判断をしてくれたことにより、パフォーマンスを落とさず、習い事に通わせつつ、スクラムの一員になることが出来ました。その後また別のチームに参加することになったのですが、火曜日の午後は基本会議を入れないように配慮してもらっています。時間がどうしても合わず、今までに2回この時間に会議が入ったのですが、教室からリモートで参加をさせてもらいました。子供や周りの声が入り、聞こえづらい時があったのでノイズキャンセリングのヘッドフォンが必要だなーという感じでした。私が頻繁に発言するような会議がもしその時間に組まれた場合は子供たちの声を拾ってしまうことと、周りのママさんたちに迷惑になりそうなので、教室の外に行った方が良いかもしれないなーと考えています。結果Ubieやチームのサポートのおかげで、保育園の送迎など子育てを中心にした仕事のスケジュールを組むことができるようになっています。4歳児の時はとにかく何事もなく終わらせることしか頭になかったようですが、5歳児の運動会のダンスでは一番難しい技を出すグループに自ら手を上げて参加し、本番で成功させていました。走り方もすごく綺麗なフォームでしっかり走れていました。祖父母も明らかによくなったと喜んでいました。本人もやれることが増えて自信が顔に出ていました。保育園の先生からいろんなことを自ら積極的にやれるようになったと聞いています。卒園式では、園の毎年恒例である式の最後に、「園児が保護者のうち1人を呼び、感謝され、いろんな人に写真撮られつつ一緒に退室していく」という保護者の晴れ舞台を作るための時間がありました。普通その場で呼ばれるのは子育てに多くの時間を割いている「ママ」です。今年もクラスの大半が「ママ」を選択しました。しかしうちの息子は練習の時から「パパ」一択だったそうで、他の子に何を言われようが、先生に何を言われようが、ママ・パパに何を言われようが「パパ」にすると言っていました。息子は私が子育てに参加してることをしっかり認識してくれてることが本当に嬉しかったです。念のため明記しておきますが、妻も世間一般のママと同じかそれ以上にしっかりと子育てに参加してます。私と同様に息子に愛情を注いでいる素晴らしいママです。今後卒園式と書いてある通り、4月から息子は小学生になります。また生活がガラッと変わりそうですが、Ubieは柔軟に働くことができる環境なので、問題が発生したら都度チームに相談して解決していこうと思います。まとめリモートワーク、テレワーク、WFHも良いけど、フルフレックスのUbieならうまく時間を合わせられたら、子育て充実させられるよ！さて、そのUbieですが、現在絶賛採用募集中です。Webエンジニア、QAエンジニア、SRE、MLエンジニア、データエンジニア全ポジション募集中です。どのポジションも事業成長スピードと比較して全然人が足らないので、興味のある方はぜひwww.figma.comubie.lifeまた、このエントリーでは詳細説明しておりませんが、UACと言う組織が現在立ち上がりのフェーズに入っています。こちらも全然人が足らない！マーケティングやセールスが武器だ！と言える人ぜひ検討してください！！！ speakerdeck.com

Ubieのリモートワーク(テレワーク, WFH)を活用して、子育てが充実した話

IntelliJプラグインでAnnotate機能を作った

はじめにこれは Ubie Advent Calendar 2019 - Qiita の7日目の記事です。6日目は かみな/Kaito Minatoya@Ubie (@kamina_zzz) | Twitter による 地球上の Kubernetes ユーザーは絶対使うべきツールたちを紹介するよ - Qiita でした。想定読者Spring + Kotlin + GraphQLを使っていて、Ktorに移行したくなっちゃった人 (需要🤔)本題UbieでAdvent CalendarをKtor縛りで書くぞ！となりました。じゃあ自分は何を書こうかなーって考えてたらGraphQLに決まってるじゃん？と振られたので、UbieではKtor+GraphQLは使ってないのですが、もしSpringのアプリケーションである https://github.com/ubie-inc/kotlin-graphql-sample をKtorに移し替えるとしたら何をするのかを調査しつつ、記事にすることにしました。この記事では一旦動くところまでを目指します。生かすコード、諦めるコードフレームワークを載せ替えるとしてもそこまでガッツリ書き直す訳ではなく、生かすことが出来るコードが多々あります。今回は出来うる限りコードを生かす方向にしました。そのため、graphql-java-toolsを同様に採用します。github.comこれを採用するため、domainとquery resolver, resolver はSpringのアノテーションを消すだけで再利用出来ます。import com.coxautodev.graphql.tools.GraphQLResolver- import org.springframework.stereotype.Component- @Componentclass DiseaseResolver(...) : GraphQLResolver<Disease> {jdbc も同様に修正するのですが、Springのjdbcを使っているため、思った以上にガッツリ修正が入ります。この辺りはKtorで利用するDBアクセスライブラリ次第になります。ここではあまり関係ないので、省略します。スキーマファイルもSpringの時同様にresources直下に置きます。再利用できるコードもありますが、完全に捨てるコードもあります。例えば、JdbcConfigやKotlinGraphQLSampleApplication これらはSpringのための設定なので再利用は出来ません。ただこのようなコードだけなのでほとんどのコードが再利用することが可能となります。新規実装IntelliJのウィザードで作成されるここから、新規の実装をしていきます。fun main(args: Array<String>): Unit = io.ktor.server.netty.EngineMain.main(args)@Suppress("unused") // Referenced in application.conf@kotlin.jvm.JvmOverloadsfun Application.module(testing: Boolean = false) {}最初にRoutingの定義です。 GraphQLなので /graphql にコードを書いていきます。GraphQLは GETとPOSTのサポートをしているので、一応、両方とものAPIを書きます。fun Application.module(testing: Boolean = false) {    routing {        get("/graphql") {            TODO()        }        post("/graphql") {            TODO()        }    }}最初にリクエストをパースします。リクエストはこんなJSONです。{    "query":"{\n  drug(id:\"id\") {\n    name\n  }\n}",    "variables":null,    "operationName":null}これをこのままdata classにします。data class GraphQLRequest(    val query: String = "",    val operationName: String? = "",    val variables: Map<String, Any>? = mapOf())Ktorでデフォルトで使える、 ObjectMapper を使ってパース処理を書くと。fun Application.module(testing: Boolean = false) {    routing {        get("/graphql") {            val stringRequest = call.receive<String>()            val mapper = ObjectMapper()            val request = mapper.readValue(stringRequest, GraphQLRequest::class.java)        }        post("/graphql") {            val stringRequest = call.receive<String>()            val mapper = ObjectMapper()            val request = mapper.readValue(stringRequest, GraphQLRequest::class.java)        }    }}何度も同じ処理を二箇所に書くのは辛いので、 GraphQLController を作成します。class GraphQLController {    suspend fun handleGraphQL(call: ApplicationCall) {        val stringRequest = call.receive<String>()        val mapper = ObjectMapper()        val request = mapper.readValue(stringRequest, GraphQLRequest::class.java)        TODO()    }}これを使ってコード量減らします。fun Application.module(testing: Boolean = false) {    // Controller    val graphQLController = GraphQLController()    routing {        get("/graphql") {            graphQLController.handleGraphQL(call)        }        post("/graphql") {            graphQLController.handleGraphQL(call)        }    }}さて次は実際に graphql-java を利用してコードです。    val filePath = "kotlingraphqlsample.graphqls"    val graphQLSchema = SchemaParserBuilder()        .file(filePath)        .resolvers(            listOf(diseaseResolver,                 DiseaseQueryResolver(diseaseService),                // 他のResolverもここに記述する                ))        .build()        .makeExecutableSchema()    val graphQL = GraphQL.newGraphQL(graphQLSchema).build()この graphQL インスタンスをController内で使い、それぞれのResolverにアクセスしていきます。graphQL インスタンスはDI使うなり、コンストラクタに差し込むなり、Controller内でインスタンス化するなり、好きなようにControllerに差し込みます。    suspend fun handleGraphQL(call: ApplicationCall) {        val stringRequest = call.receive<String>()        val mapper = ObjectMapper()        val request = mapper.readValue(stringRequest, GraphQLRequest::class.java)        val context = ConcurrentHashMap<String, Any>()        // graphQLは上でインスタンス化したもの        val result = graphQL.execute(            ExecutionInput.newExecutionInput()                .query(request.query)                .operationName(request.operationName)                .variables(request.variables ?: emptyMap())                .context(context)        )        TODO()    }最後にresultをJSONにして、返します。    suspend fun handleGraphQL(call: ApplicationCall) {        val stringRequest = call.receive<String>()        val mapper = ObjectMapper()        val request = mapper.readValue(stringRequest, GraphQLRequest::class.java)        val context = ConcurrentHashMap<String, Any>()        val result = graphQL.execute(            ExecutionInput.newExecutionInput()                .query(request.query)                .operationName(request.operationName)                .variables(request.variables ?: emptyMap())                .context(context)        )        val json = mapper.writeValueAsString(result.toSpecification())        call.respondText { json }    }これでAPIは完成。APIアクセスを簡単にするために、GraphiQLも導入します。 graphiql/packages/examples/graphiql-cdn at master · graphql/graphiql · GitHub この辺りのサンプルコードをそのまま拝借し、index.htmlとしてプロジェクト直下に置きます。fun Application.module(testing: Boolean = false) {    // Controller    val graphQLController = GraphQLController()    routing {        static("/graphiql") {            // GraphiQL            default("index.html")        }        get("/graphql") {            graphQLController.handleGraphQL(call)        }        post("/graphql") {            graphQLController.handleGraphQL(call)        }    }}Runボタン押して、実際にGraphiQL http://localhost:8080/graphiql にアクセスしてみます。見えるようになりました。yay!終わりにいかがでしたでしょうか？(一回やってみたかった)やってみて思ったんですが、Springですでに動いているのであれば、今のところKtorに移す必要ないなーと言うのが感想です。今回はこんなレポジトリのコードを参考にしました。https://github.com/roschlau/ktor-graphqlhttps://github.com/excitement-engineer/ktor-graphqlあまりアクティブな開発がされていないので、今後どうなるのかわからないですが、もうちょっとKtorのGraphQL周りのプラグインが出来たら良いなーと。自分で作れってことか  🙃

Spring+GraphQLからKtor+GraphQLに移行する

最初にこの記事はどの企業も個人も批判する目的はありません。もし批判を感じる文章があればご指摘して頂けると幸いです。Hiroくんがインターンを予定通り8月中旬まで無事に終わらせたので、彼がこの期間何をやったのか？などを書こうと思います。アイキャッチ画像のための無意味なスクショ出会い最初の彼との出会いは、Twitter上で、自分の経歴とほぼ同じ経歴を持っている学生がいるなー珍しいなーと思ったけど、関わりないだろうなーとスルーしたのを覚えています。その数日後、彼のツイートは炎上していました。朝ごはん食べてたら前見つけた子が炎上してるじゃん！あららーもっと先にフォローして、声かけちゃえば良かったかなー。と朝ごはん食べながら眺めてました。最初、インターン先探しているということに対して、声かけるのはなしだよなーって思ったんですが、子供の朝ごはんを少しこぼしたので片付けをしていて、人ってミスするし、そこでダメって決めつけるのおかしい。優秀な子がこれでチャンス無くすのおかしい。弊社のバリューの一つが「launch x launch」(ロンロン)*1なのにグジグジ考えて行動起こさないのおかしい。と思い、声かけることにしました。声かけると決めた時の分報声かけたあと、東京に来るとのことだったので、その時に会いましょうと言う約束をしました。予定を聞いて、最後の方ってことだったので、まぁ彼のキャリア的にも弊社はまだ魅力的には見えないだろうから優先度下げられたかーとちょっと残念な気分でした。会ってみて5月頭に彼は日本に一時帰国していて、会社に来てもらいました。最初会ったとき、顔と体のギャップがすごい！って思ったのですが、話してみると本当に素晴らしい好青年でした。素直に話は聞けるし、しっかりと意見出来ていたし、キャリアもしっかり考えていたし、事業への質問も的を得たものでした。会う前に炎上してしまった経緯も説明してもらっていたのですが、本当に不可抗力だったのだろうなとそこでようやく納得できました。唯一問題というと彼の今後の専門としたい分野がUXなどであること。当時彼の経験があるAndroidアプリやUnityのポジションは弊社にはありませんでした。あるのはUXなにそれうまいの？CUIで良くね？と言っちゃう自分しかいないチームでのサーバサイドKotlinでした。そこで、「すごくHiroくんは優秀だと感じたし、ぜひ働いて欲しいけど、今弊社に来るとHiroくんのキャリア的に遠回りになるかもしれない。本気でおすすめ出来ない。でも同じ界隈にいるだろうし、引き続き仲良くしてね！」と笑顔で送り出すことにしました。彼が帰った後「すごく良さそうだったけど、今後の彼の専門や今のスキル的にポジションがほぼない。なので今回はなかったことで！」という評価を会社のメンバーに伝えておきました。数日後その数日後、TwitterのDMでこんなメッセージが来ました。「色々週末考えたのですが、Kotinサーバーサイドとして入らせて頂くこと可能でしょうか？」正直、まじか！空気読めない子か！ってフいたのを覚えてます。（そして今気づいたけど、typoしてるw）でも入りたい！と言ってきたのに、なにもせずにごめんなさいってするのはおかしいので、入社試験をしてもらいました。一週間くらいかけて貰えばいいかなーって思ったところ、1,2回のラリーはあったものの、2日で作り切り、コードもしっかり読めていて、想像以上でした。こちら側からお断りする理由もないし、彼のキャリア的に美味しいのか？と罪悪感を感じつつ、入社してもらうことにしました。【報告】インターン先決まりました。今日からUbieでしらじさん(@shiraj_i)の元、Kotlin書きます。Androidじゃなくて、サーバーサイドなので学ぶことしかないですが、頑張ります！— Hiro (@khiro_ca) May 15, 2019 ちなみに入社後に彼が書いた下でも紹介している記事を読んで、すごく真剣に話を聞いてもらえたのがわかったし、めっちゃ嬉しかったのを覚えています。入社前に今のUbieはまだまだ小さな会社であり、事業を危険に晒すこと＝即会社が潰れるということが十分あり得ます。そのため、彼の受け入れ条件としては公開して良い情報・ダメな情報を明確にすることをみんなに約束しました。と言っても、会った時にその話はしっかりすでにしていて、理解していたし、なんなら話す前から理解していたので、全く不安はありませんでした。入社一番の問題は彼が他の弊社メンバーに受け入れられず、ぎこちない関係になってしまうかも？という点でした。短い期間しかいないため、早めに打ち解けてもらいたかったです。そこでwelcomeランチがあったのですが、紹介一言目に「あの炎上した子です！」と全体に情報公開しました。彼はめっちゃ焦ってましたが、Ubieメンバーの器のデカさや彼が誠実に説明してるところを見て、みんな安心して受け入れてくれていました。あの早いタイミングでアイスブレイクしっかり出来たのは良かったなーと思います。彼いろんな会社のイベント参加してたし、入社日からUbieの一員になってくれました。タスクサーバサイドKotlinのポジションではあったのですが、せっかく来てもらう訳だし、色々吸収してもらおうと考えました。彼には複数のサービスの担当をしてもらい結果的にサーバサイド(Kotlin/Python/Rails)フロント(JS/TypeScript)実装設計単独での開発スクラムでのチーム開発デザインといろんなことをしてもらいました。全く経験がなかったのに、土日で勉強してきて、フロントの実装も素晴らしい速度でやっていたのは本当に驚きでした。もちろん彼にもまだまだ未熟な部分はあって、そこは週1の1on1で話していたし、色々彼なりに頑張って改善していました。結果今の彼のレジュメはぐちゃぐちゃになっただろうと思いますが、master resumeには残して、提出するresumeから外せばいいだけだし、好きにしたら良いと思う（責任放棄）留学生のインターン余談ですが、インターンインターンと言ってますが、留学生のインターンって日本で言う、学生の業務委託であり、使えなければクビ切られる覚悟を持っている人が多いです。彼もその考えを持っていました。もし留学生をインターンとして受け入れる会社があるなら、学ばせるというより、キャリアを積ませる＋プロの業務委託的な扱いをしてあげて欲しいです。なので、今回も学ばせると言うより、会社への貢献のためのタスクを選んでやってもらいました。このあたり読んでもらえると良いのではないかなーと思います。hiro-ca.hatenablog.comなぜこの記事を書いたか？インターン生や新卒などなど色んな人を見てきましたが、こんなブログを書くのは初めてで、今後もあんまり書かないだろうと考えています。しかし優秀な子が不本意なデジタルタトゥーにかわいそうな思いはして欲しくないので、彼はそんな人じゃないということをこの記事で明言しておきます。彼はフルタイムで働いているため会社の様々な情報にリーチできる人材でしたが、インターン期間中一度も情報公開に関して指導する必要はありませんでしたし、信用できる人間です。最後にHiroくん、お疲れ様でした。色々自分至らぬところがあったと思います。申し訳ないです。でも一緒に働けてすごく楽しかったし、Hiroくんが将来めっちゃ活躍してるところを早くみたいです。そして「わしが育てた」と言わせて下さい。Good luck!!!*1:弊社の三つのバリューのうちの一つ。100の議論より1の実行に価値がある。

カナダから来たUbieのインターン生(Hiroくん)はすごかった

Kotlin Festの感想ブログを読んでいて、やっぱり自分も書きたくなっちゃった。だから書く。(2年連続)去年の記事shiraji.hatenablog.comCfP今年はCfPだったので、2本書きました。GraphQL周り(通過した話)IntelliJ周り(DroidKaigiでなかなか反応良かった話の改良版)セッションの内容に新規性・独自性があることKotlin独自の知見を得られること ― 例えば内容をJavaに置き換えても同じ知見が得られるようなセッションは採用されにくいです。これらの要件が本当に難しくて、Javaに置き換えられない内容ってCoroutineやKotlinでしか使えないライブラリしかないんでは？と悩みまくりました。それに加えて新規性！？とかなり苦しんだCfPでした。通過連絡7/10に通過連絡が来ました。Kotlin Fest採択されたー！急いで準備せねば！社内での実例も出しつつ、KotlinでGraphQLの話しようと思います。渾身のIntelliJのおもしろネタは採択されなかった😭LTにして、「Kotlinを使ってIntelliJと話してみよう！」とかにすれば良かったか？この話どっかで話したいなー。 pic.twitter.com/W4djyN5JHe— shiraji (@shiraj_i) July 10, 2019 全然時間なかった！とここで文句書くつもりだったけど、メール確認して7/10に連絡来ていた事実を知り、1.5ヶ月もあったんなら余裕だったんじゃん・・・と今反省しています。いや、夏休みがあったから実質1ヶ月だしやっぱり時間なかった！スライド準備CfPの時にアウトラインが決まっていたこともあり、サクサク進むかなーって思ってました。IntelliJの話がしたくてしたくて、その影響もあり、あんまりモチベーションが上がらず、進捗は良くなかったです。7月から話す内容を書き出し、2週間前にKeynoteの1枚目を作り出し、1週間前にようやく完成しました。うおー！ようやくKotlin Festのスライド準備完了した！かなり削ってしまった。。。あとは一週間しっかりと練習して、細かいネタを仕込む作業に入る。— shiraji (@shiraj_i) August 18, 2019 かなり遅くて焦ったのですが、今までとは別の方法でスライド作成し、その方法が自分には結構フィットしました。これは自分にとってかなり大きな収穫かなーと考えています。前日去年同様、ぼっち飯回避ツイートをしました。Kotlin Fest 2019でもこれやりたい！どなたか一緒にランチ行きませんかー？サーバサイドKotlinやGraphQLなどなど興味ある方ぜひ！（今年も自腹でお願いします！）https://t.co/zQISiHftUs— shiraji (@shiraj_i) August 22, 2019 kouさん、ikkunさんが反応してくれたので、前日の時点でぼっち飯回避できたの本当に良かった。これあと一人だれか参加しませんかー？ぼっち飯回避！ #kotlinfest https://t.co/1l5SfW7Dp8— shiraji (@shiraj_i) August 24, 2019 当日に追加で呼びかけたらいっせいさんが反応してくれました。これで準備万端になりました！当日会場に入ったのは10:40くらいでした（これがあとで叱られる原因に）。もうすごい盛り上がっていて、会場入って、おおお！とすごくワクワクしたのを覚えています。控え室に荷物を置かせてもらい、キーノートを聴きました。Svetlana Isakovaさんに紹介してもらった、Inline classやimmutableListの話が非常に良く、早速どこに導入するべ？って検討していました。それとSvetlana Isakovaさんのスライドにまさか自分が出てくるとは思ってなかったのですごく嬉しかったです。It's me!!!#kotlinfest pic.twitter.com/PG38WHUe8u— shiraji (@shiraj_i) August 24, 2019 最近正直OSSで貢献できてないので、何かしなきゃ！と思いました。ランチ前日のツイートで集まった三人の方落ち合おうとしていたら、八木さんがランチ相手を探していたので、八木さんを引っ張っていき、去年と同じところでランチしました。バックグランドがみんなバラバラだったのですが、去年同様結構盛り上がりました。話の内容はKotlinの話はもちろん、Androidの話であったり、サーバサイドの話であったり、業務の話であったり、多岐に渡りました。たった1時間しかなかったのが残念ですが、やっぱり初めての人とご飯行くの楽しいし、知ってる人がいても楽しい！という気づきがありました。これは来年もKotlin Festがあるならぜひやりたい！当日(午後)午後のトークは自分の登壇が15:30からあると言うことであんまり聴いてないのですが、以下の二つを聴講しました。Kotlin コルーチンを 理解しよう 2019公募によるLT大会八木さんのトークはコルーチンの知識を最新版にアップデートしようと思いましたが、すんごくうまくスライド作っていて、発表内容も濃く、コードが読みやすく、途中で自分のスライドや発表内容直したくなりました。ちょっと自信を無くして、控え室に行った覚えがあります。LTはどれも良かったです。途中どうしてもトイレにいきたくなってしまい、漏らして人生終わらすならここで行くしかないと、「静的解析ツール detekt で任意の条件で警告させる」の話途中で抜けてしまいました。lintの話は大好きだったのでめっちゃ悔しかったです。急いでトイレ行った後に戻ってきたら会場が爆笑していて、漏らさなくて良かったけど、トイレはトーク前に行こう！と言う小学生並の知見を得ました。動画に映ってる気がするので、まじで申し訳ないです。すいません。LTはめちゃくちゃよくて、どれも5分じゃなくてもっと長い時間で聴きたい！と感じました。登壇スライドspeakerdeck.comGraphQLの話をする時、どこから話せば良いんだろう？と悩み、結局出来上がったのがKotlinの話をせずに1/3基本的なGraphQLの話をすると言う選択でした。最初にGraphQLの経験を確認してみたのですが、思った以上に少なくて、この選択が間違ってなかったー！良かったーと話ながら思っていました。GraphQLのデメリットの話は時間的に削りました。LTでGraphQLのN+1問題が辛いって話が出ていたので、そこで紹介してもらえたし、結果オーライかなーと。今回意識したのがspeakerdeckではあんまり見えないのですが、スライド間のトランジションです。GraphQLはデータの流れ、クエリの流れなどを理解することが重要だなと思っており、Magic Moveを駆使してそれを表現してみました。聴いてくれた方があれがすごく良かったと反応をくれたのが本当に嬉しかったです。余談ですが、Magic Moveを使う場合、閉じ括弧が消える問題があるのですが、これを解消するために、調べていたら結局Jakeさんに到達して、自分はようやく彼の5年前に追いついたのか・・・愕然としていました。(解消方法は下のツイートのスレッドに記述されていますが、透過率100%の文字を括弧の後ろに入れました。)Keynote's Magic Move hates closing curly braces ("}") which screws up all my beautiful code transitions. pic.twitter.com/mcxfv2mCi1— Jake Wharton (@JakeWharton) November 1, 2014オープニングでたろうさんが盛り上げましょうみたいな話をしてくれたので、話を聴いてくれた人たちが結構トーク中に反応してくれて嬉しかったです。スライド作った当時本当にコードしかなくて、これ絶対寝るわ。って思ったので、どうにかして、興味を失わず、理解してもらう方法を実施していたので、話ていて気持ち良かったです。聴いてくれた人たち本当にありがとうございました！登壇後Ask The Speakersで30分の休憩全部使って質問対応しました。みんなかなり面白い質問をしてくれて自分まだまだGraphQLのこと知らないなーって思いました。最初APIの開発辛いよねーって大げさな話を出したのですが、まさにあれば起こってるんです！ぜひ導入してみたい！と言う話を何人かにしてもらえたのがやっぱりこう言うのあるんだ。とびっくりしつつ、めっちゃ嬉しかったです。ブースブースですが、朝ブースにいる知っている人たちを見つけて、挨拶をして、あとで来ます！と宣言して、Ask The Speakers後に向かいました。しかし、自分のAsk The Speakersが終わる時間がブースの撤収開始時間らしく、ほぼほぼ回れませんでした。。。家族がブースでもらえるノベルティが大好きで、Twitterを眺めていて、あれ良さそう！と自分の帰りをワクワクして待っていたようなのですが、ステッカーだけもらって帰って来た自分に対し、なぜもっと早く会場に行かなかったのか？とガチ目な説教をしてきました。次回以降しっかり早めに行きます。。。各社のノベルティ、すごく工夫されていて -> 持って帰る -> 家族が喜ぶ -> その会社のプロダクトを使う と言う良い流れが私の家では出来ています。懇親会懇親会ですが、結構いろんな方と話せてすごく楽しかったです。Svetlana Isakovaさんに登壇直前の時間にあとで話しかけるね！と宣言しており、immutableListの話を聴けて満足しました。懇親会で朝からずっと気になってたimmutableListがなぜ必要なのかって話が聞けた。すごく腹落ちして満足出来た。初めましての方や去年のKotlin Festぶりの方だったり毎度おなじみの人、色んな人と話せて本当に楽しかったです。久しぶりにkontribute欲上がってきたー！#kotlinfest— shiraji (@shiraj_i) August 24, 2019 また初めての方が結構な数話しかけてくれたのが本当に嬉しかったです。自分が知ってる人に対しては話しかけることができるのですが、初めての方は紹介してもらうなりしないと遭遇出来ないです。でも食事を盛っている時とか、「今話しかけても良いですか？」とか言ってもらえて本当に嬉しかったです。ご飯食いたいけど、それ以上に話したいってのがあるので、どんどん話しかけてもらえるとありがたいなーと。お子さんを連れて参加していたポールさんとそのお子さんとお話も出来たのも良かったです。自分もいつか子供連れて勉強会とか参加したいなーと。まとめ来年もあったら絶対参加したい！絶対また登壇したい！おー！！！ハッシュタグとsince:2019-08-24_15:30:00_JST until:2019-08-24_16:20:00_JSTで検索して、ニヤニヤしながら、お酒飲んでる。 pic.twitter.com/NseyjP5l4y— shiraji (@shiraj_i) August 24, 2019 一人で馴染みの店で打ち上げ。めっちゃ美味かったー。

Kotlin Fest 2019に参加してきました

Yet another emoji supportという絵文字の入力をサポートするIntelliJプラグインをリリースしました。イメージとしてはこんな感じCommitダイアログでも利用できます。github.com経緯元々Emoji supportプラグインを公開していました。しかし、いくつかのissueで絵文字をコミットダイアログ以外のところでも挿入したいと言う要望を受けることが多くなりました。cmd+ctrl+spaceで入力できると何度も伝えていたのですが、なぜかみんなあんまり納得してくれませんでした。リリースから3年経過し、公式のサポートもまだないため、需要があるかさっぱりわからないですが、一旦作ってみるかということで作りました。特徴特徴としてはどの言語でもコメントでの入力をサポートしています。また自分の気づいたベースの言語に関してはStringの中での入力ができるようになっています。(GroovyとScalaが初期リリースでサポートされていないのは完全に失念していたためです。次のバージョンで対応予定です)細かい点としてはKotlinのようにString内でコードを書ける場合、コードを書くことが可能な箇所ではCompletionが出ないようになっています。val foo1 = "${:<caret>}" // この場合は出ないval foo2 = ":<caret>${}" // この場合は出る

Yet another emoji support をリリースしました。

Kotlinサーバサイド開発者のみなさん、graphql-javaでの開発の調子はどうでしょうか？去年末にリリースされたバージョンのgraphql-spring-boot-starterのExceptionハンドリングがめっちゃ便利で感動したので、ブログに残しておきます。想定読者graphql-spring-boot-starter使って、GraphQLやってる人/これからやる人はじめにgraphql-spring-boot-starterのバージョンが5.0.4の時、Resolver内で発生したExceptionは特に何も指定しない場合、全て Internal Server Error(s) while executing query と言うmessageを返していました。例えば、AuthException のような自前で作成したExceptionが出た場合、レスポンスとしては違ったものを返したくなりますが、問答無用でInternal Server Error扱いです。(ちなみに最新版でも互換性を残すため、同じ挙動です)    @Suppress("unused")    fun diseases(icd: String): List<Disease> {        if (icd.isEmpty()) throw IllegalArgumentException("icd must not be empty")        return service.getDiseases(icd)    }何だろうとInternal Server Error!そこで、カスタマイズしたエラーを返すようにしたいのですが、探せど探せど良い方法が見つかりません。issueにこのドキュメント通りに書けばいけるぜ！と書かれているので、URLをクリックするとこんなページに飛ばされ、かなりイライラします。*1でまぁ、色々調べていくと、Authエラーなどで全処理中断させたいであれば、 GraphQLException を実装すれば、一般的なランタイム時のExceptionとなり、エラーを返してくれると書いてあるので、試してみます。    @Suppress("unused")    fun diseases(icd: String): List<Disease> {        if (icd.isEmpty()) throw GraphQLException("icd must not be empty")        return service.getDiseases(icd)    }結果返してくれなかったよ・・・涙このあたりで心折れます。Spring BootでのExceptionハンドリング話変わって、Spring Bootには結構便利なExceptionハンドラがあります。以下のような感じで、各種Controller内で発生したExceptionに対して、一箇所でうまくシュッとやってくれます 😤@RestControllerAdvice(basePackageClasses = [ExceptionHandlerAdvice::class])class MyExceptionHandlerAdvice {    @ExceptionHandler(TimeoutException::class)    @ResponseStatus(HttpStatus.REQUEST_TIMEOUT)    fun handle(exception: TimeoutException): ExceptionResource {        log.error("caught an exception", exception)        return ExceptionResource("タイムアウト")    }    @ExceptionHandler(WebExchangeBindException::class)    @ResponseStatus(HttpStatus.BAD_REQUEST)    fun handle(exception: TimeoutException): ExceptionResource {        log.error("caught an exception", exception)        return ExceptionResource("なんか起こった")    }}まぁあんまり詳しく書いても話が逸れるので、こんな感じのものがあるのだなー程度で良いです。で、graphql-javaでもこんな感じで処理したい！と思う訳です。時間が解決してくれた(=中の人達が頑張ってくれた)それから数ヶ月が経ち、graphql-spring-boot-starterがメキメキ更新されていました。現在の最新のバージョン(5.7.3)を使い、graphql.servlet.exception-handlers-enabledをtrueにすると以下のコードでもうまくハンドリングしてくれるようになります。*2    @Suppress("unused")    fun diseases(icd: String): List<Disease> {        if (icd.isEmpty()) throw IllegalArgumentException("icd must not be empty")        return service.getDiseases(icd)    }IllegalArgumentExceptionですらうまくメッセージを返すようにものすごく良くなりました。しかし一点typeがException名になってしまいます。フロント側で IllegalArgumentException を処理してもらうで良いのですが、ちょっとダサい。GraphQLExceptionをthrowしたとしても、同じようにtypeが表示されてしまいます。Spring BootのExceptionハンドリングのように特定のExceptionに対して、カスタマイズしたGraphQLErrorを表示したくなります。そこで登場したのが、exception-handlers-enabledが導入されたタイミングでgraphql-spring-boot-starterが @ExceptionHandler によるExceptionのカスタマイズ機能です。実装方法としてはこんな感じのBeanやComponentをクラスを作るだけ！@Componentclass GraphQLExceptionHandler {    @ExceptionHandler(IllegalArgumentException::class)    fun handleSomeException(e: Throwable): GraphQLError {        return GenericGraphQLError("Foo! ${e.message}")    }}それで同じようにExceptionを発生させるとメッセージやtypeを表示しないなどのカスタマイズが出来た！これにより、エラーメッセージのカスタマイズやtypeなどを表示しないなどなどエラーハンドリングが容易に出来るようになりました。実際のコード実際にUbieで公開している https://github.com/ubie-inc/kotlin-graphql-sample に、動くコードをコミットしてあります。上記には記述してありませんが、graphql-java-toolsのバージョン上げも必要になりますので、ご注意してください。github.com*1:https://graphql-java.readthedocs.io/en/latest/ が https://www.graphql-java.com/documentation にリダイレクト機能なし+ドキュメント削除して移動したことが原因です*2:5.3で導入され、5.4.1でバグfixされています。

graphql-spring-boot-starterのExceptionハンドリングがめっちゃ便利になってた

8/20入社だったので2/20でUbieに入社して半年になりました。つまりサーバサイドエンジニアに転向して半年経ちました。以前の記事でこんなこと書いたので、続編を書いてみようと思います。半年くらい働けば、きっと悪いところももっと見えてくるはずなので、来年落ち着いたらまた続編を書いていきたいと思います。Ubie, incに入社しました。 - shiraji’s diary今月のツイートを冷静に眺めてみるとそこまで自社に関してのツイートしていないし、恋は盲目状態から解放されているようなので、冷静に自分のことを分析してみようと思います。サーバーサイドにキャリアチェンジしてどうだったか？新しいチャレンジAndroidアプリ開発と比較しての設計開発環境サーバサイドエンジニアとしての課題Androidアプリエンジニアとしての不安ベンチャー企業に入ってどうだったか？ルール働き方タスク時間の使い方初めての経験OKR/KPTアウトプットする人が多い名前引っ越し最後にサーバーサイドにキャリアチェンジしてどうだったか？サーバサイドにキャリアチェンジしたのが正解だったかどうかに関してはまだわかっていません。これに関しては結論が当分出ないような気がしています。ただ、以前のエントリーにも書いてありますが、元々AndroidアプリもUIのことより通信だったり、パフォーマンスだったりを主に見ていたため、AOSPの辛さがなくのびのびKotlinを書けるという環境は本当に楽しいです。今後、多くのネイティブアプリエンジニア達がサーバサイドに目を向けるようになってきた時にサーバサイドKotlinというのは一つの可能性でもあるし、ガンガン発信していって、サーバサイドKotlinのプレゼンス高めていきたいという想いがあります。新しいチャレンジ新しいチャレンジとしてはGraphQLに手を出し始めたのは自分にとって大きな出来事でした。shiraji.hatenablog.comshiraji.hatenablog.comGraphQLといえばGo、Rubyなどといった言語を使うのが主流な気がしますが、JVM言語でも可能性あるのでは？というところまで自分の中で良い印象を持っています。さらにここにKotlinならではの良さを追加出来ないか？と模索しているところです。Androidアプリ開発と比較しての設計設計に関しては、Androidアプリのように活発な動きはなく、特にAPIの作成の時などはシンプルな構成になります。ただし、Androidアプリでの経験が活きないか？と言われるとそれは間違っていて、Androidアプリで利用したDIやクリーンアーキテクチャなどは元々サーバサイドにあったものですし、そのまま利用することが出来ています。開発環境今まではAndroid Studioを使っていましたが、IntelliJ IDEAに乗り換えています。Android StudioとIntelliJを両方使ったことある人であれば、わかると思いますが、特に使い勝手は変わらず、多くのサーバサイドKotlinサポート機能が乗っていて、そこの乗り換えコストはほぼ0です。(自分はIntelliJ IDEAでプラグインを開発していたという経験もあるので、生存バイアスかかってるかもしれませんが。。。)さらにCoroutineやテストツール（JUnit5やmockkなど）など馴染みがあるツールをそのまま利用できる事もあり、サーバサイド辛いなーと感じることが少ないです。サーバサイドエンジニアとしての課題自分が今課題と感じているのが、自分自身、結構ネイティブアプリの開発に注力しすぎてしまったため、ネイティブアプリのライブラリなどの知識は深くなっていますが、昨今のウェブの開発スタイルにまだ馴染めていません。UbieではGCPを主に使っていますが、GCPにどんな機能があるのかを完全に把握しておらず、実装しようとして、あれ？その機能GCPにあるのでは？というツッコミを受けたことがあります。その機能がどういうものなのか？などの把握はそこまで時間がかからないのですが、自分の引き出しの少なさにちょっとがっかりしています。サーバサイドの進化はネイティブ開発に比べ遅い！と勝手に思って7,8年前までのサーバサイド開発のスタンスでいたのですが、これは完全に間違いでした。Androidアプリエンジニアとしての不安Androidアプリ開発の一線から退いて半年経ち、一番の不安は、最新のライブラリのキャッチアップが出来ないことです。例えば、JetPackの存在は知っていますし、コードはある程度眺めています。しかし、仕事でJetPackを使っていないですし、経験がありません。今年のGoogle IOでまた新しいものが発表された時、それに対して何かしら自分がアクションを起こせるかどうかは正直不明です。そのため、もしAndroidアプリエンジニアとしてカムバックしなくてはならない時、何かしらキャッチアップ期間がないと厳しそうだなーという感じています。実際、今サーバサイドエンジニアにカムバックしたといえばカムバックした訳で、このキャッチアップに時間を使っているというのも不安です。半年経った今でもまだサーバサイドエンジニアですと胸張って言えないような感じなので、キャッチアップって結構時間かかるなーという印象を持っています。ベンチャー企業に入ってどうだったか？今までいくつかの企業で働いていて、上場してない企業としてはUbieは2社目です。それ以外の会社は全て上場していて、多くのユーザーを抱えている企業でした。1社目は10人くらいで、今回は現在20人くらいなのでほぼ変わらない規模です。こういう会社に入ると感じるのは自分の稼働が会社へダイレクトに良くも悪くも影響を与える事です。変なバグを出してしまったりすれば会社は潰れるかもしれませんし、逆に素晴らしい機能を出せば一気に会社が大きくなる可能性があります。自分が会社を動かしているかも？という錯覚すら覚えて喜べます。1社目で感じていたのですが、こういう感覚が好きなエンジニアには小さい会社ありだなーと改めて思いました。アイキャッチ画像がなかったから、無駄に、自分のデスクのマスコットのアー写置いておく。ルール新しい会社にはよくあることですが、ルールが決まっていないかったり、そもそもなかったりします。必要であれば社員みんなで議論して、即ルールを制定しています。Ubieはなんかイベントが発生するとみんなで本気で解決しようとしてる姿勢が本当に良い。しきちさん忙しいはずなのに、これから子供持ちたいって人のために、人柱になって色々やってくれてるの最高。 https://t.co/Gf0PEeQgcb— shiraji (@shiraj_i) 2019年1月31日こういうことは小さな会社だから出来る自由さ、フットワークの軽さがあって、すごくいいなーと感じています。働き方働き方は今までよりワークライフバランスを特に意識するようになりました。これはリモートワークがいつでも自由に出来る状況*1であることが起因しているのですが、やろうと思えば、深夜でも早朝でも土日でもプライベートの時間を削って仕事が出来る状況になっています。自分のプライベートのGitHubアカウントを会社でも使っているので、GitHubの通知を見ようとすると会社の通知とOSSの通知を同時に受け取ってしまえます。さらに言うと、自分の会社の出社時間が10:00-17:30でだいたい多くの人より早く帰っており、家で足りない稼働分(30分)働いています。そのためそのまま流れで気づいたら仕事してたみたいな状況に陥りがちです。会社の今のフェーズはできるだけ多くのリソースを割いて、サービスをどんどん良くしていくというのはわかっています。しかし今まだ設立1年半のこのタイミングでエンジニアがいっぱい残業してしまうと今後入ってくる人もそういうのを会社は期待してしまうし、それは健全ではないと思っているので、自分1人だけでもワークライフバランスを特に意識しています。タスク任されているタスクは結構自分から手を挙げたものが多いです。サーバサイドKotlinの実装DBテーブルの設計・実装協力会社との連携処理の設計・実装SREの細かいタスクのサポートbot作成(これはほぼ遊びか？)今フロントエンジニアの質がものすごく充実しているように見えます。結構勉強出来そうな環境です。しかし、今の自分がフロントで足引っ張るより、サーバサイドや人が足りていないSREで足引っ張った方が会社のためになるでしょという判断をしたため、SREエンジニアの修行させてもらっています。手取り足取り @sakajunquality から知見吸えているのですごく良い判断したなーって思っています。時間の使い方これまでの会社と一番違う部分は実は時間の使い方なんじゃないかと思っています。今までの会社ではリーダーだったり、外部の方とのやりとりだったり、雑多な管理だったり、採用だったりと、そこまでまとまったの時間を開発に割いていませんでした。(これだけ読むとダメじゃんー！って思われるかもしれませんが、自分はこれはこれで実は結構好きだし、楽しかったです。)今の会社では毎週以下のような時間割でやっています。会議(3時間15分 *2 )その他、定期的ではない会議や採用周り、週平均2時間くらい残り週30時間以上は開発この定期的な会議の多くは出社推奨日の水曜にまとめています。そのため、結構まとまった時間開発することが出来ています。ただ、これでも自分の会社の滞在時間の制限があるため、週1以上は必ずリモートで仕事をし、より長く開発に時間を割けるように工夫しています。初めての経験Ubieに入って初めての経験がいくつかありました。OKR/KPTスクラムなどは経験あったのですが、今まで業務でOKRやKPTを実際にやったことがありませんでした。OKRは今期から本格的に実施することになり、会社から本を買ってもらい、みんなで勉強して実施するようになりました。KPTは良かったことを褒め合う機会と問題の共有・対処の検討などをしっかりやれるのが気に入ってます。アウトプットする人が多い今まで自分より登壇する回数が多い同僚と働いたことがなかったです。Ubieでは社外へのアウトプットを推奨しており、エンジニアはもちろんのこと、デザイナーや医師、Bizもアウトプットする機会があればどんどんアウトプットしています。これがすごく刺激的で、自分ももっとアウトプットしたい！という気持ちが湧いてきます。Ubieのエンジニア陣の登壇予定表が出来たのだけど、 @ngsw_taro @sakajunquality のアクティブさが半端ない。こう言う人たちに囲まれてるともうちょい自分も頑張らなきゃってなる。 pic.twitter.com/Cw1d62yUos— shiraji (@shiraj_i) 2018年10月5日名前これは入社時からだけど、会社で初めて「しらじ」って呼ばれてる。呼ばれすぎてて、社外の方と話すときに、自分のことを本名で呼ばれたりするとドキっとするようになってしまった。。。引っ越し先日Ubieは引っ越しをしました。新しい場所は三越前駅徒歩10秒です。goo.gl今までも席替えやビルの部屋が変わるなどは毎年1,2回のペースで経験してましたが、オフィスの場所が変わる引っ越しは初めての経験でした。新しい環境で働くのはいつもワクワクなので、引っ越してもそこまで変わらないだろうなーって思ったのですが、引っ越して駅から近くなって、オフィスも広くなって、会社の成長をモロに実感出来たのがすごく嬉しかったです。ベンチャー企業の醍醐味だなーこれ。と感じています。このオフィスも2年以内に引っ越す予定なので、次はもっと大きな場所で働けるようにがんばろー！って気分になれました。最後にAndroidエンジニアからのキャリアチェンジですが、SREにも手を出してますし、今のところうまく進んでいる気がします。会社の成長を感じられるのが本当に嬉しい日々です。さて、こんなUbieですが、引き続き、いろんな職種を募集しています。speakerdeck.com随時オフィス見学やUbie Dayなど社外の方を呼んで来てもらうようなイベントもやっていますので、興味あれば、TwitterでメンションやDM下さい。*1:最大週2で、出社推奨日もあります*2:1時間チーム内KPT, 30分全体KPT, 30分採用定例, 1時間エンジニア定例, 15分業務委託の方と1on1

Androidエンジニアからベンチャー企業でサーバーサイドエンジニアに転向して半年経って分かったこと

DroidKaigi2019に参加しました

このブログはDroidKaigi 2019の Android Studio設定見直してみませんか？ の詳細です。せっかく聴いてくれる方がメモを取ってて話を聴き逃してもらいたくないためのエントリーです。登壇中何らかの問題が発生した時の対策でもあります。前提設定の遷移の区分けはJetBrainsの公式と同じで「 | 」です。「Preferences | Keymap」という記述の場合、Preferencesの中にあるKeymapというメニューを表しています。Macを使っている前提で話が書いてあります。Android Studio 3.1から3.3.1での動作確認はしています。Quick Listsリファクタ、Surrend With、右クリックなどをすると出てくるポップアップがあると思います。 いろんなポップアップがありますこれ、実は自分専用のポップアップを作ることができます。Preferences | Appearance & Behavior | Quick Listsと遷移するとQuick Listsを作成する画面が出てきます。Quick Listsの設定画面ここの「+」をクリックし、「Display name」にはわかりやすいものを設定し、ポップアップに表示したいアクションを追加します。shiraji quick listsというQuick Listsを作ってみました「Find Actions」で「Display name」に入力した値を選択すると、自分でカスタマイズしたポップアップが表示されるようになります。Find Actionsに表示される自分専用のポップアップが！このQuick ListsはKeymapを設定することも出来て、便利です。keymapも設定できるFont ligatures!=, ->, ==ってITエンジニアなら読むことは出来ると思うのですが、!=は≠と表示される方がカッコイイです！（主観です）Android Studioではこの表示をサポートしています。Preferences | Editor | FontEnable font ligaturesにチェックを入れ、Font ligaturesに対応しているフォントに変えます。Fontはデフォルトで入っていてFont ligaturesに対応しているFira Codeを選択そうすると、コードがこんな感じに表示されるようになります。  左が変更前、右が変更後Notification右下や右上に出てくるポップアップです。Power Save ModeをONにすると出てくるポップアップこのポップアップですが、すぐ消えちゃったり、何度も出てきてイライラさせたりしてくれます。全てのポップアップにはIDが振られており、Notificationの設定で表示方法を変えることができます。これは3rdパーティのプラグインも含まれます。Gradle Syncが終わったらポップアップを表示させるようにしてみる今回紹介したいのはこの設定ではなく、どのNotificationでも使われていない、「Read aloud」という設定です。どの設定もOFFになっているGradle Syncの設定の「Read aloud」を選択して、Gradle Syncをしたらどうなるでしょう？Notificationの内容をAndroid Studioが大きな声で何秒かかったのかを伝えてくれます！(この渾身のネタが文字でしか伝えられない悲しさ・・・)ちなみに当日は、「おおおお！」とAndroid Studioさんに言ってもらうためのプラグインを使い、褒めてもらいました。github.comFile ColorFile Colorはデフォルトで利用されているので、結構みんな知らないうちに使っている機能だと思います。Project Viewにあるテストコードの背景が黄緑になっています。これがFile Colorです。背景が黄緑色になっているタブも色が変わるFile Colorは便利な利用方法があります。Preferences | Appearance & Behavior | File Colors上の方のWindowにある、プラスボタンをクリックします。「Scope」を「Production」として、「Color」を「Blue」としてみます。そうすると、「Run」ボタンを押して、アプリを起動する時に利用されるソースコードが青くハイライトされるようになります。青くハイライトされるBuild Variantを変えても即反映されます。Build VariantをpremiumReleaseにしたら、debugのソースのハイライトが消え、premiumのソースがハイライトされたコードフォーマットコードフォーマットにはいろんな方法が提供されています。昔よく話に上がっていたのは、reformat code/organize importsなどを保存時に実行するマクロを組むとか、Eclipseのデフォルト機能から作られたであろう、Save Actions - Plugins | JetBrainsというプラグインを導入する、Commitダイアログにあるreformat code/organize importsなどにチェックして、Commitする。Commitダイアログのコードフォーマットの設定ここで紹介するのは、コードを書いているときに、コードフォーマット漏れしているかを確認する方法です。Preferences | Editor | Inspections | Kotlin | Style IssuesKotlinのInspectionの中に「File is not formatted according to project」という設定があります。これを有効にして、「Severity」を「Error」とします。これでプロジェクトのコードフォーマット設定に違反したコードを書くと文法エラーのような表示なります。コードフォーマットされていないとエラー表示になるこの赤線のところで、「Option(Alt) + Enter」をすると、「Reformat File」という選択肢が出るようになります。Reformat Fileという選択肢が出るそこで「Reformat File」を選択すると、フォーマットされるようになります。簡単にコードフォーマットできるこれを利用すれば、コーディング中にフォーマットされているかどうかの確認が可能です。Android Studio上でエラー表示になっているだけで、ビルドは問題なく出来ます。余談ですが、特定の箇所をCode Formatしたくない場合もあると思います。そう言う場合はPreferences | Editor | Code Style「Enable formatter markers in comments」を有効にし、「@formatter:off」と「@formatter:on」で括れば、フォーマットエラー表記もされないようになりますし、「Reformat File」しても無視されます。コードフォーマット対象にはならないBreakpointsの削除Breakpointsはデバッグ時に必須なものです。Breakpointsを特定の条件下のみ発動することも可能です。Breakpointを右クリックし、「Condition」を入力すればその「Condition」がtrueの時のみBreakpointで止まります。Breakpointに条件を追加するで、このBreakpoint、作るときも削除するときも簡単で、クリックしたら出来ちゃいます。ワンクリックで簡単すぎる削除・・・結構複雑な条件を設定したにも関わらず、誤ってワンクリックで消してしまい、またその条件を入力しなくてはならなくなった経験ありませんか？筆者は首がもげるくらいあります。この問題への対処方法があります。Preferences | Build, Execution, Deployment | Debugger「Remove breakpoint」のところにある、「Confirm removal of conditional or logging breakpoints」を有効にしてみてください。そうすると、条件付きのBreakpointをクリックすると、削除するか確認ダイアログが出現するようになります。削除するか確認ダイアログInject LanguagesInject Languageと言う機能は生のStringに対して、JSONやYAMLなどの言語に対するサポートができるようになる機能です。対象のStringにカーソルを合わせ、「Option (Alt) + Enter」を押し、「Inject Language or reference」を選択します。その後、そのStringの言語を指定したら、その言語のサポートを受けられるようになります。同じ文字列なのに、コードハイライトが有効になっているまた、ここではJSONを利用しているため、「Edit JSON Fragment」と言う機能も利用でき、それを利用すると、別WindowでJSONを入力したら、エスケープなどを良しなにやってくれるようになります。下のWindowで編集したら上の文字列に反映されるこの機能は非常に便利なのですが、チームで共有するためには、@language("JSON")や//language=jsonなどを記述しなくてはなりません。この記述は「Inject Language or reference」を選択したタイミングですぐに再度「Option (Alt) + Enter」を押せば補完してもらえるのですが、忘れがちです。アノテーションをつけるかを聞かれる。別のアクションをしたら消えてしまう！この問題を解消する機能があります。Preferences | Editor | Language Injections | Advancedこの設定画面の一番下にある「Add @Launguage annotation or comment if needed」を有効にします。その後、もう一度「Inject Language or reference」を選択すると、@language("JSON")や//language=jsonを最初から補完してくれるようになります。Layout EditorAndroid開発者なら誰もがお世話になるだろうLayout Editorの設定の紹介です。このLayout Editorは設定がいっぱいあって、なかなか面白い機能ではあるのですが、今回紹介するのはこの画面の設定ではなく、Preferecesの方の設定を変えてみます。Preferences | Editor | Layout Editorこの三つの設定のうち、一番上にある、「Prefer XML editor」という設定。有効にしてみて、もう一度Layout Editorを開いてみます。Prefer XML editorを有効にして、開き直しても特に見た目の違いが見えない。。。よーく見てみます。本当に違いがありますTextタブの位置が変わっています。Textタブの位置が左に！！！デフォルトでは、Designが左で、Textが右。デフォルトはこれ細部までこだわり抜いて作られている感じがします。Preferenceのパスのコピー方法これは設定というより機能のお話です。登壇中もこのブログでも特定の設定画面への遷移を「Preferences | Keymap」のように記述していました。たぶんここを読んでいる方も社内や自分のドキュメントで設定への遷移を書いたことある人いるのではないでしょうか？これをタイピングするのは、なかなか厳しいです。そこでこの機能を使うと便利です。Preferences | Build, Execution, Deployment | Gradle をタイピングするのは大変左側にあるTree的なメニューにポインターを合わせ、右クリックしてみてください。「Copy Preferences Path」と出てきます。これをクリックすれば、そこまでのパスをコピーすることが出来ます。Copyメニューが出てくるPluginのインストールを強制する特定の機能を使っている場合、チームで必須で使うプラグイン揃えたい時があると思います。例えばDatabindingを使っているプロジェクトでDatabinding Support - Plugins | JetBrainsを入れるとか。登壇で使ったプロジェクトでは、自分がどんなタイピングをしたのか、どんなActionを実行したのかをあとでみやすくなるように、Presentation Assistant - Plugins | JetBrainsを強制していました。Preferences | Build, Execution, Deployment | Required Pluginsプラグインの強制方法はこの設定画面で、現在使っているプラグインの中から強制するプラグインを選択します。これらのプラグインをインストールせずにプロジェクトを開くと、右下のところにエラーが表示されます。プラグインがインストールされていない場合、エラーが出る。このエラーポップアップの「Install required plugin」というリンクをクリックすると、インストール予定のプラグインの詳細が表示されます。OKボタンを押すと、全てのプラグインをインストールしてくれます。当日の発表は多分ここまでです。これ以降は時間の都合上、発表することが出来なかったお話です。設定の共有ここまで色々設定変更を見てきましたが、これらの設定はチーム内で共有することが可能です。多くの設定はプロジェクトの.idea内に含まれています。.idea内に設定ファイルが格納されているexternalDependencies.xmlは必要なプラグインの設定、vcs.xmlはバージョンコントロールの設定だったりします。ただし、例えば、workspace.xmlのようなその個人の設定ファイルも含まれてしまっていますので、必要に応じて、.gitignoreなどでコミットしないように注意が必要です。github.comGitHubのgitignoreにJetBrainsのものが公開されていますので、それを参考にすると良いと思います。icon.png/icon_dark.pngというファイルがあると思います。これはそのプロジェクトiconとして認識されます。プロジェクトのアイコンが表示されるちなみに、最近Android Studioの対応がされた、Toolboxでもアイコンが表示されます。Toolbox便利なのでぜひ使うといいと思いますAndroid StudioをNotepadにしてみよう！最後に（最初から？）ちょっとAndroid Studioで遊んでみます。Android Studioにはいろんなボタンや空白などがあります。これを全て消すとどうなるか！？を試してみます。初期表示「Hide All Windows」Tool Windowを隠す「Tabs Placement」を「None」にタブが無くなった「Show line numbers」を「OFF」に行番号が消えた「Status bar」を「OFF」に最下部のStatus Barが非表示に「Navigation Bar」を「OFF」に上部のNavigation Barを消した「Show Gutter icons」を「OFF」に行番号の横にあったスペースがなくなった「Tool Buttons」を「OFF」に外枠のボタンが全部なくなった「Breadcrumbs」を「Don't Show」に下部のスペースがなくなったここまで来るともうNotepadとほぼ見分けが付きません！画面が有効活用出来そうです！ちなみに、ここまでやってしまって、最初に戻す方法は用意されていません。Macの場合、~/Library/Preferences/AndroidStudio3.3/のoptionsフォルダを消せば元に戻せます。実行は自己責任でお願いします！まとめ以上、DroidKaigi2019の Android Studio設定見直してみませんか？ の詳細でした。これを聴いてくれた、または読んでくれた方が1人でも設定変えてみたり、他にも面白い設定/機能ないかなー？ってAndroid Studioの探訪をしてくれると嬉しいなーって思います！宣伝さて、Ubieでは、こんな感じで、便利なものを積極的に採用して開発を進めています。もし、Ubieに興味出てきたなーって方はぜひ、@shiraj_iにDM下さい！サーバサイドエンジニア以外にもいろんな職種募集していますので、こちらもぜひ確認してみてください。speakerdeck.com

Android Studio設定見直してみませんか？ -詳細-

GraphQL(Kotlin)とStackdriver Traceがすごくいい感じだったから見て欲しい。実装ここで公開したアプリに修正を加えてみました。shiraji.hatenablog.comgithub.comライブラリの追加spring-cloud-gcp-starter-traceを使い、Stackdriver Trace*1利用するため、gradleに変更を加えます。repositories {    mavenCentral()    jcenter()+    maven(url = "http://repo.spring.io/libs-milestone")}dependencies {+    val springCloudGcpVersion = "1.1.0.RC2"+    compile("org.springframework.cloud:spring-cloud-gcp-starter-logging:$springCloudGcpVersion")+    compile("org.springframework.cloud:spring-cloud-gcp-starter-trace:$springCloudGcpVersion") {+        // remove this after 1.1.0.RELEASE+        exclude(group = "io.grpc")+    }+    compile("app.ubie:brave-kt:1.0.0")https://github.com/ubie-inc/kotlin-graphql-sample/commit/b0aee867adf13e3e2ef41e8c3e8a5979619995f3exclude(group = "io.grpc")しているのは、1.0.0.RC1よりバージョンが上のspring-cloud-gcp-starter-traceを使うと、io.grpcが複数のバージョンに依存してしまう問題があるためです。以下で問題提起しています。1.1.0.RELEASEで修正が完了する模様です。github.com環境変数などを変更次に、Stackdriver Traceを利用できるように環境変数などを変更しています。GraphQLのクエリをログ出力するために、graphql.GraphQLのログレベルをDEBUGに変えています。  cloud:    gcp:      trace:-        enabled: false+        enabled: true      logging:-        enabled: false+        enabled: true  sleuth:    sampler:      probability: 1.0@@ -24,3 +24,4 @@ logging:  level:    root: INFO    org.springframework.jdbc.core.JdbcTemplate: DEBUG+   graphql.GraphQL: DEBUGhttps://github.com/ubie-inc/kotlin-graphql-sample/commit/beb23dc3b858c1cd8cbead49d2f7c1a0abd59b21Scope Spanを使い、さらに見やすく最後に、brave-ktを利用して、各クエリがどれくらい時間がかかっているのかを確認するTraceを入れます。-        if (icd.isBlank()) return emptyList()-        return jdbcTemplate.query(+        return Tracing.currentTracer().scopedSpan("findKinkiDrugsByIcd") {+            if (icd.isBlank()) return emptyList()+            jdbcTemplate.query(                 //language=SQL                 """                 SELECT                   yj_code,                   icd                 FROM                   disease_kinki_drug                 WHERE                   icd = :icd                 """.trimIndent(), mapOf("icd" to icd), rowMapper-        )+            )+        }https://github.com/ubie-inc/kotlin-graphql-sample/commit/25e8e477b365f037daa4948dc94b24ff5789709abrave-ktに関しては以下の記事に書いてあります。shiraji.hatenablog.com結果ライブラリ追加して、ちょこっと見やすい工夫を入れるだけなのですが、以下のような結果が表示されるようになります。Scope Spanを使い、各DBアクセスの時間を見えるように1クエリ内で発行されたログも表示できるリクエストクエリなども見える特定のクエリに対して、どのSQLがどのタイミングで発行され、どれくらいの時間がかかっているのか？などが一目でわかるようになりました。感想めっちゃ便利。この結果が美しくて惚れました 😍宣伝さて、Ubieでは、こんな感じで、便利なものを積極的に採用して開発を進めています。もし、Ubieに興味出てきたなーって方はぜひ、@shiraj_iにDM下さい！サーバサイドエンジニア以外にもいろんな職種募集していますので、こちらもぜひ確認してみてください。speakerdeck.com*1:Stackdriver Traceを利用するには https://cloud.google.com/trace/docs/quickstart?hl=ja を参照

GraphQL(Kotlin)とStackdriver Traceの美しさに惚れました。

今年本当に自分のエンジニア生活が一変した年だったので、書き留めておく。(2年連続同じ文言)shiraji.hatenablog.com技術的な話は皆無です。ツイートと共に自分のための振り返りです。ので、自分のことを知りたい人以外が読んでもらっても多分「あ、そう。」という感想だけしか得られないはずので、戻るボタンクリックお願いします。1月初詣。今年もKotlinで何か出来ますように。New year pray(play?) at Japanese Kotlin holy land pic.twitter.com/WAQkNrotpK— shiraji (@shiraj_i) 2018年1月7日2018年はこんなところからスタート実はですが、初詣に行って、嫁ちゃんに今年で転職しそうだね。しっかりお祈りしときな。と言われて、（ははーん！この人何も俺のことわかってないね！結婚して何年経ったんだよ？）と思ったけど、今日の時点では（何で自分より自分のことを知ってる人がこの世に存在するんだ・・・？）と言う畏怖の念を抱いております。2月前のセッション誰もいないから勝手に本番の場所でリハ始めてます。（スタッフさんたちには話してます）今回、表示してるスライドが見えたりマイク持たなくて良いみたいで、最高すぎる環境っぽい！！！ pic.twitter.com/WW173s5tLs— shiraji (@shiraj_i) 2018年2月8日DroidKaigiがありました。How to Kontribute v4をやりました。このネタは結構な回数こなしてたんですが、あんまりうまくやれずに悔しい思いをしたのを覚えています。あくまで噂で聞いたんですけど、某カンファレンスの参加費を出さなくてエンジニア一人失った某社、今年は参加費出したらしいですよ。辞めたエンジニアさんその会社大好きだって言ってたし、きっと心の底から喜んでるでしょうね😄— shiraji (@shiraj_i) 2018年2月8日きっと心の底から喜んでるでしょうね！3月時間オーバーした気がするけど、ライブコントリビュートしたぞー！https://t.co/keWfqkDPkZ— shiraji (@shiraj_i) 2018年3月15日r.kt #3でライブコントリビュートしました。ライブでコーディングしたの初めてだったので、かなり練習したのを覚えてます。recruit-lifestyle.connpass.comさぁ懇親会だ！ #shibuya_apk pic.twitter.com/xclUxAxWvE— shiraji (@shiraj_i) 2018年3月20日ライブストリーミングでshibuya.apkにも参加しました。子供がいるのでこう言うのがどんどん流行ってほしい！と思ってます。準備が大変ですけど・・・。4月一人目のエンジニアとかになるにはどうやってコネ作ればいいのかわからない。それとCEOがエンジニアじゃないとキツいって聞いたことがあるけど、『一人目のエンジニア』の時点でそれでは？起業？🤔— shiraji (@shiraj_i) 2018年4月6日Twitter転職って人生で何回まで使えて、一回使ったら何年待ったら再度使えるようになるんだろう？🤔— shiraji (@shiraj_i) 2018年4月19日4月になったので、キャリアについて真剣に考え始めたタイミングでした。早めのジョイン狙いだよなーってなってる時です。まさに自分がこれ。最初に入った会社年収350切ってて、副業に手出したけど、無理しすぎて体壊した。そのまま続けても600届きそうになかったし、転職するスキルつかなかった。副業やめてブログやOSSやり出したら転職先選べるようになったし、本業で600万越えた。 https://t.co/4TA3aMwaRk— shiraji (@shiraj_i) 2018年4月19日年収ツイートするといいねいっぱい貰えると学んだツイートスゴい！頑張って下さい！ https://t.co/ZrCBNYmUXy— shiraji (@shiraj_i) 2018年4月23日フラグが立った日やはりスタートアップの早い段階での参画もなると知り合い経由だよね。— shiraji (@shiraj_i) 2018年4月23日そして、その日のうちに、スタートアップの早めのジョインなんて今の自分じゃ無理だと判断したツイート。やっぱり4月は転職周りのツイート多いな。。。5月めっちゃ席空いてる。 pic.twitter.com/iORGriWBGx— shiraji (@shiraj_i) 2018年5月7日自分の顔見て話しかけてもらえるのすごい嬉しい。日本人の知っている人以外ではいないけど。OSS Communityにさっき参加して色んな国の人と話せたので良しとしよう。— shiraji (@shiraj_i) 2018年5月9日Google IOに行かせてもらいました。初めての参加でした。デバイス情報 pic.twitter.com/HgXOJbLCP1— shiraji (@shiraj_i) 2018年5月10日Codelabで問題一切やらずに、ChromeBookの検証してた。これ出来たらOSSとして公開してくれるといいなー。変更履歴とかも見たい。 https://t.co/PIeAK9V8Z9— shiraji (@shiraj_i) 2018年5月21日これ忘れられなくて、どうしてもやりたくて、現職でやらせてもらいました。もうすぐ詳細を弊社の誰かが書くはず！6月サーバサイドKotlinの企業での導入実績ってあるのか？ってツイート見かけた。界隈各位、サーバサイドKotlinの企業での導入事例が行き渡っていないみたいなので、もっとお願いします！（単に自分がいっぱい聞きたい）— shiraji (@shiraj_i) 2018年6月6日サーバサイドKotlinの導入事例のツイートして、聞きたそうな人がちらほら見える。本当に知られてない感じ。。。ちなみに自分が知っている中ではサーバサイドもガッツリKotlinってサービス持っている会社少なくとも5社はあるはず。しかも結構な規模の会社。本も出版されてますよ。— shiraji (@shiraj_i) 2018年6月6日サーバサイドKotlinやりたくて仕方なくなってる頃です。皆様、さらに一社増えそうです。https://t.co/B9Mvz01Wdd— shiraji (@shiraj_i) 2018年6月7日なるほど#GitHubSatelliteTokyo?w=1の機能、UIでもう出来るんだ。— shiraji (@shiraj_i) 2018年6月12日GitHub Satellite Tokyoに参加して、色々話聞きました。で、この機能を知らなかったことに正直衝撃を受けてて、毎日GitHub触ってないことに対して危機感を覚えました。このままこのキャリアでもいいかな？と考えてもいたのですが、この危機感は今でも鮮明に覚えていて、この日を境にキャリアを変えると決断しました。で、6月終わりには現職に転職を決めました。7月Kotlinコントリビュートもくもく会 #1 @コネヒト に参加を申し込みました！ https://t.co/UMftgphmn1— shiraji (@shiraj_i) 2018年7月9日めっちゃ資料作成が捗る。#コネヒトもくもく— shiraji (@shiraj_i) 2018年7月23日コネヒトさんのイベントに参加して、Kotlin Festのネタ集めを始めました。本当にこのイベントのおかげで色々助かったので、コネヒトさんには感謝しかない！全然wifi落ちない。快適すぎる。#コネヒトもくもく— shiraji (@shiraj_i) 2018年7月23日にも関わらず恩を仇で返す実を言うと自分もうだめです。 突然こんなこと言ってごめんね。 でも本当です。8月中旬に次の出社日があります。それが終わりの合図です。 程なく残りの有給休暇消化があります。それが明けたら、少しの間もおかず最終日8/19がきます。— shiraji (@shiraj_i) 2018年7月27日当然ごめん。8月最終出社だん！— shiraji (@shiraj_i) 2018年8月9日そして最終出社日最後の最後まで、店舗の方に顔だして仕事してたりしてました。自分がこの会社で長く働けなかったことは本当に悔しいし、またどこかの大企業に再挑戦できる機会がどこかであればいいなと思ってます。今日のコミケひょっとして、参加できちゃうんでは？（参加準備してない）— shiraji (@shiraj_i) 2018年8月9日そして、テンションおかしくなって、なぜかその日のうちにコミケに初参加を決めました。「西め」あたりにいけば興味あるものが置いてあるっぽい！程度で初参加の素人が戦場に一人で向かう。— shiraji (@shiraj_i) 2018年8月10日参加者がみんな熱いな！ってちょっと感動してました。Kotlin Festスケジュール公開されて、LTの時間と被りました！本当に誰も自分のところに来ないのでは？って心配になってる。自分のトークよりLTのライブストリームでも見て、ちゃちゃ入れする方が面白い気がしてきた。副音声的な。https://t.co/xcROzXyIIk— shiraji (@shiraj_i) 2018年8月17日本当に誰も自分のトーク聴きにこなかったら別ネタでLT乱入しよう。— shiraji (@shiraj_i) 2018年8月17日Kotlin Festのスケジュールが公開されて、ふてくされました。会いにきた。 pic.twitter.com/QXShG7WbJx— shiraji (@shiraj_i) 2018年8月19日入社日前日に現職のBBQイベントがあったので、家族同伴で参加しました。たろうさんとのコードレビューでの殴り合い楽しい😊— shiraji (@shiraj_i) 2018年8月21日入社して一番やりたかったことを2日目にしてやらせてもらって、本当に嬉しかった。機転を効かせてくれたスタッフや会場の皆さん、本当にありがとうございます！当日までむちゃな要望出してもしっかり回答してくれたスタッフの方たちにも感謝です！TLさっき見たのですが、楽しんでもらえたようで登壇出来て本当に良かったです！#KotlinFest— shiraji (@shiraj_i) 2018年8月25日その一週間後のKotlin Festで登壇。自分と同じ時間のLTの人たちがみんな時間通り進めたおかげで、最後の辺り全員が自分の登壇を観ると言う美味しい状況でした。明日Kotlin Festでランチ誰か一緒に行かないですか？サーバサイドKotlinの話したい方、Kontributeしたい方、弊社興味ある方ぜひ！！！自分含めて四人くらいで！（自腹でお願いします。。。）— shiraji (@shiraj_i) 2018年8月24日あと、ぼっち飯回避でTwitterで募集したら始めてお会いする人たちとご飯いけました。本当に楽しかった。shiraji.hatenablog.comこの8月は今年の中で一番濃かったなー。9月現役最後のPRでエバァンジェリストに褒められたので、もう悔いはないです🙏 pic.twitter.com/3mH8Mxeray— shiraji (@shiraj_i) 2018年9月12日現役引退予定でしたが、いまだにバリバリコーディングしてます。35歳定年なんてのはないですね。10月Pixel3予約購入だん！ついに念願の合法のPixelを手に入れるぞ！（スタンドも欲しかったけど、YAuthで弾かれた）— shiraji (@shiraj_i) 2018年10月10日Pixel, Pixel2が出なくて、その発想になってしまいました。今はサーバサイドに戻り、Kotlinやってます。（まさかPixel3が来るとは）一緒にやります？— shiraji (@shiraj_i) 2018年10月18日Pixelを合法的に日本で触れるなんて思ってもいなかったですね。これが4月までに発生してたら転職とかなかったかも？なので、何が起こるかわかりませんね。GraphQL+Kotlin動いた。オシャレだなー。エラー時とかかなあと問題になりそうなのは。— shiraji (@shiraj_i) 2018年10月18日GraphQL始めました。この辺りからツイートがGraphQL一色になってる。かなりお気に入りになった模様。そんなに数ないのですが、UbieでKotlinで殴り合うためのコーディングスタイルを公開しました！https://t.co/O0pzqoWLsO— shiraji (@shiraj_i) 2018年10月25日これ公開したら良くね？って気づいてすぐにOSSとしてコーディングスタイル公開しました。なかなか良い反応もらえて嬉しかった。Is there kotlin support for brave? I don't like writing start()/finish() for spanKotlinで使いやすくなるbraveのサポートってないですかね？start()/finish()を書くのが怠くて。https://t.co/xpo3lurzdK— shiraji (@shiraj_i) 2018年10月26日会社でリリースしたOSSについて書きました！ / “122105” https://t.co/WlQr1AXCbh— shiraji (@shiraj_i) 2018年11月4日その勢いのままbrave-ktも公開しました。shiraji.hatenablog.comgithub.com11月DroidKaigiでAndroid Studioの話しますー！リラックスして聞いてもらうような内容になる予定です！よろしくお願いします！！！ pic.twitter.com/es20siRRJq— shiraji (@shiraj_i) 2018年11月10日2年連続でDroidKaigi登壇が決まりました。今回は日本語でやります。ライブコーディングの予定です。スライドあるとしても自己紹介だけになるので聴きに来てね！Ubieに入社したので書いてみました！ / “Ubie, incに入社しました。 - shiraji’s diary” https://t.co/QWLn43zJrg— shiraji (@shiraj_i) 2018年11月22日キャリア変えたことを報告しました。Android開発者に罵られるかも？とビクビクしてました。でも当然そんなこと無く、本当に暖かい良い開発者コミュニティだなーと思います。DroidKaigiで少しでも恩を返せたらと！shiraji.hatenablog.com12月今年はこっちのアドベントカレンダーに参加です！ pic.twitter.com/DgVshEfzUE— shiraji (@shiraj_i) 2018年12月1日今年はアドベントカレンダーに参加しない方針だったので、こっちの参加表明。勢いで公開して、Kotlin Advent Calendarまで書きました！ / “サーバサイドKotlin+GraphQLのアプリケーションをOSS化しました - shiraji’s diary” https://t.co/E7PqOIu9yj— shiraji (@shiraj_i) 2018年12月14日でもKotlin枠が空いてて、書くのを抑えられなかった人です。これ結構プロダクションに乗っかってるコードに近いので、興味ある人はぜひ触ってみてください！10月から月1ペースでOSS公開してます。そんな頻度とかは特に意識はしてないけど、出せるものは出して、サーバサイドKotlinやる人増えてくれたら嬉しいなー。shiraji.hatenablog.comgithub.com2018年の目標達成度2018年の目標一回登壇を経験したので、流れも掴めたし、登壇の方の負荷も減ると思うので、コードのアウトプットと両立させたい。負荷減ってない気が・・・。OSSのコードアウトプット量は前半かなり減っていたので、焦りが出た。それを機に転職して、2018年後半結構アウトプット出来たと思う。ただ、まだまだやれると思うので、来年はもっと増やしていきたい。2019年の目標OSSもそうだけど、仕事でのアウトプットも増やしていきたい。まだまだ手探り感がある。プライベートはようやく来年から落ち着きそうなので、家族みんな元気に過ごす！が目標。最後に8月に転職してまだ4ヶ月しか経ってないのかーと驚きです。今年は仕事もプライベートも色々あって、ドタバタだった感があります。今年も初めましてな方といっぱい会うことが出来ました。来年もきっと楽しいことが起こるだろうなとワクワクしています。今年一年、ありがとうございました。来年もよろしくお願いいたします。

Twitterエゴサーチで見る2018年まとめ

これはQiita Kotlin Advent Calendar 10日目の記事です。qiita.comこれマニアックなんじゃね？Kotlin大好きな人向けなんじゃね？ってstdlibにあるIterable/Collection/List/Set/Mapのメソッドを独断と偏見で挙げてみようと思います！Collection - Kotlin Programming Language想定読者KotlinのCollectionのstdlibメソッドもっと知りたい人一旦はさすがです！って褒めてくれる人環境Kotlin 1.3.11で使えるメソッドにしています。全メソッドPlaygroundで動作確認済みです。distinct説明: 重複削除したListを作るdistinct - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/HJnYskugVfun main() {    val list = listOf(1,1,1,3,5)    println("List: $list") // List: [1, 1, 1, 3, 5]    println("Result: ${list.distinct()}") // Result: [1, 3, 5]}感想: かー毎回Setに詰め込んでたね。それでListが欲しい場合は、toListしてたね。さらに順番が必要なら色々頑張ってたね。便利😊intersect説明: 両方のCollectionに入っている要素をSetにして返すintersect - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/SkQkak_eEfun main() {    val list1 = listOf(1,1,1,3,5)    val list2 = listOf(3,4,1)    println(list1.intersect(list2)) // [1, 3]}感想: 知らなかったら、filterとかcontainsメソッドなどで泣きながら書いてたと思う。union説明: Collectionをがっちゃんこする。戻り値はSetunion - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/rykBje_lVfun main() {    val list1 = listOf(1,1,1,3,5)    val list2 = listOf(3,4,1)    println(list1.union(list2)) // [1, 3, 5, 4]}感想: intersectと同じ感想onEach説明: 渡した引数のactionを全ての要素に実行し、レシーバーを返すonEach - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/HyrGyxugEfun main() {    val list = listOf(1,1,1,3,5)    list.onEach {        println("Log: $it")    }.filter {        it > 3    }.forEach {        println("Result: $it")    }}結果Log: 1Log: 1Log: 1Log: 3Log: 5Result: 5感想: forEachして、そのまま何かしたい！って時にまたレシーバーを書いてたけど、これ使えば全部繋げられるじゃん。便利じゃん。onEachWithIndexとか欲しくなりそう。partition説明: Collectionの要素が引数の条件にマッチした要素をPairのfirstのListに。マッチしない要素をsecondのListに分割するpartition - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/HJgvexugNfun main() {    val list = listOf(1,1,1,3,5)    println(list.partition { it >= 3 }) // ([3, 5], [1, 1, 1])}感想: 分割が必要な時、頑張らなくてもいいね！requireNoNulls説明: 要素にnullがないことを担保する。もし、nullがあればIllegalArgumentExceptionrequireNoNulls - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/SJ3VMlul4fun main() {    val list: List<Int?> = listOf(1,2,4)    val listNoNulls: List<Int> = list.requireNoNulls()}感想: requireNotNullのCollection版って感じ。nullがないことが前提条件のメソッドとかで利用できそう。(特に気にもせずに無心でfilterNotNullするかもだが。。。)unzip説明: PairのArrayに対し、firstの値だけのListとsecondの値だけのListをPairとして返す。https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/unzip.htmlサンプルコード: https://pl.kotl.in/ryYFNedx4fun main() {    val array = arrayOf(1 to "foo", 2 to "bar", 3 to 5)    println(array.unzip()) ([1, 2, 3], [foo, bar, 5])}感想: ちょっと限定的すぎる？🤔いや、こういうのいいですよねきっと！windowed説明: Collectionをsizeの要素数のListを作る。次のListはstep分ずれたものからスタートする。ごめんなさい。どう英訳すれば一番わかりやすいのかすらわからない。以下が原文。Returns a list of snapshots of the window of the given size sliding along this collection with the given step, where each snapshot is a list.windowed - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/r13a_gdxNfun main() {    val list = listOf(0,1,2,3,4,5,6,7,8,9)    println(list.windowed(size = 5, step = 3)) // [[0, 1, 2, 3, 4], [3, 4, 5, 6, 7]]    println(list.windowed(size = 5, step = 3, partialWindows = true)) // [[0, 1, 2, 3, 4], [3, 4, 5, 6, 7], [6, 7, 8, 9], [9]]}partialWindowsがtrueだった場合、sizeに足りてないものも含む。感想: ちょっと置いていかれたメソッド。これが便利なんだ！というくらいKotlinを使いこなしたい・・・zipWithNext説明: Listの隣り合った要素をListのPairとして返すzipWithNext - Kotlin Programming Languageサンプルコード: https://pl.kotl.in/r1cjdxOlEfun main() {    val list = listOf(0,1,2,3,4,5,6,7,8,9)    println(list.zipWithNext()) // [(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9)]    println(list.zipWithNext { a, b -> a + b }) // [1, 3, 5, 7, 9, 11, 13, 15, 17]}感想: transformを渡せば、数列とかで便利かも？あとは次の値を見て何かするような処理とかでもいいかも。

Kotlin大好きな人向けなCollectionのstdlibメソッドを掘り出してみた

これはQiita Kotlin Advent Calendar 2018 1日目の記事です。qiita.comサーバサイドKotlinのコード公開したらみんな見てくれるかな？そこで開発出来そう！ってなったらサーバサイドKotlinのエンジニアになりたくなるかな？— shiraji (@shiraj_i) 2018年12月13日ツイートしたら良い反応もらえたので、サーバサイドKotlinのアプリを以下で公開する事に決めました。github.comcloneして、docker-compose upしたら、GraphiQLが http://localhost:8090/graphiql 立ち上がって、サーバの動作確認が出来る。簡単！！！GraphiQL画面Ubie内で絶賛開発中のシステムに少し手を加えていますが、基本的に実際に開発している環境と同じになっています。公開目的公開に至った理由はいくつかあります。サーバサイドKotlinやりたいって人のハードルを下げたかったやりたい！という声はいろんなところで聞くけど、「環境ないし・・・。」「経験無いし・・・。」という方も多いと思ってます。実際Ubie入社前の自分がそうでした。このプロジェクトは、clone後すぐにローカルで動かす事が可能です。そのため、このお手軽さを見てもらい、もっと多くの方にサーバサイドKotlinやってもらいたいなーと思いました。Kotlin+SpringBoot+GraphQLの開発者にコードレビューしてもらいたかった。または仲良くなりたかった今回、色々な事情があり、KotlinでGraphQLの採用をしています。自分にKotlin+GraphQLの実績がないため、コードを公開することにより、いろんな人に見てもらい、より良いものになったら良いなと思いました。さらに同じような環境の方ともっと仲良くなりたいです！特に後述しますが、多対多のGraphQLResolverの処理が本当にこんな感じのコードで良いのかが不明です。Spring+GraphQLの情報が少なすぎる。。。もっと効率良く出来そうなんですが・・・同じ構成のものをOSS化することにより、Ubieの入社即パフォーマンス発揮！をしてもらいたかった今のところ、Ubieのサーバサイドに関わる人には入社前に1日インターンをしてもらい、チームに溶け込めるか？を見てもらう時間を取っています。しかし、時間が1日しかなく、環境構築に時間を取られてしまうのはもったいないです。そのため、同じ環境をOSS化することにより、先に環境構築出来る状況にしたいと考えました。さらに将来的には1日インターン宗教上無理！って方にこのOSSプロダクト開発に携わってもらい、雰囲気をそこで味わってもらうのもいいかなと考えています。技術スタックこのプロジェクトでは以下の技術スタックを利用しています。Git/GithubCircleCIDockerPostgreSQLSpring BootKotlinGradle(Kotlin Script)GraphQL/graphql-javaFlywayLogbackktlintJaCoCo(ただしまだテストはない)今後テスト書くので、以下が追加予定JUnit5MockkWebTestClientパッケージ構成app.ubie.kotlingraphqlsample├── domain├── infrastructure│   └── jdbc├── presentation│   ├── queryresolver│   └── resolver└── service(Query)Resolver → Service → JDBCという呼び出し階層になってます。DBE-R図薬と傷病の関係性のサンプルテーブルになっています。医療業界で利用されているデータに合わせ、IDがなかったり、外部キーがUniqueじゃなかったり、全て多対多の仕様になっています。DBアクセスはspringがデフォルトで提供しているJDBCを使い、SQLをコードに書いてDBアクセスしています。これは賛否両論あると思いますが、以下の理由から採用しています。SQLのチューニングがしやすいラーニングコストが低い一目でどこでどのSQLを発行しているのかがわかるFlywayを利用して自動マイグレーションが走る状態にしてあります。GraphQLGraphQLのスキーマ定義ファイルには薬情報と病気情報が定義されています。type Query {    # 薬を取得します    drugs(yjCode: String!) : [Drug!]    # 病気を取得します    diseases(icd: String!) : [Disease!]}# 薬情報type Drug {    # 薬品名    name: String!    # YJ Code。だいたい薬を表すために使われるCode。一意ではないので注意    yjCode: String!    # 併用禁忌薬    kinkiDrugs: [Drug!]    # 処方してはいけない特定の病気    kinkiDiseases: [Disease!]} # 病気type Disease {    # 傷病に対してつくコード。一意ではないので注意    icd: String!    # 病名    name: String!    # 処方されてはいけない薬    kinkiDrugs: [Drug!]}Queryブロックには公開APIが定義されています。graphql-javaではこの定義をGraphQLQueryResolverを実装したクラスで記述する必要があります。このプロジェクトではqueryresolverパッケージ内で定義されています。@Componentclass DiseaseQueryResolver(private val service: DiseaseService) : GraphQLQueryResolver {    fun diseases(icd: String): List<Disease> = service.getDiseases(icd)}@Componentclass DrugQueryResolver(val drugService: DrugService) : GraphQLQueryResolver {    fun drugs(yjCode: String): List<Drug> = drugService.getDrugs(yjCode)}Drug/Diseaseブロック内にあるkinkiDrugsなどの外部キーを使った結合はgraphql-javaではGraphQLResolver<T>を実装する必要があります。resolverパッケージ内で定義されています。typeがDrugのkinkiDrugsの取得時にはfun getKinkiDrugs(drug: Drug): List<Drug>が呼び出される。@Componentclass DiseaseResolver(private val service: DiseaseKinkiDrugService, private val drugService: DrugService) : GraphQLResolver<Disease> {    fun getKinkiDrugs(disease: Disease): List<Drug> {        val kinkiDrugs = service.findKinkiDrugsByIcd(disease.icd)        return drugService.getDrugs(kinkiDrugs.map { it.yjCode })    }}@Componentclass DrugResolver(    private val kinkiDrugService: KinkiDrugService,    private val diseseKinkiDrugService: DiseaseKinkiDrugService,    private val drugService: DrugService,    private val diseaseService: DiseaseService) : GraphQLResolver<Drug> {    fun getKinkiDrugs(drug: Drug): List<Drug> {        val kinkiDrugs = kinkiDrugService.findKinkiDrugsByYjCode(drug.yjCode)        return drugService.getDrugs(kinkiDrugs.map { it.kinkiYjCode })    }    fun getKinkiDiseases(drug: Drug): List<Disease> {        val kinkiDrugs = diseseKinkiDrugService.findKinkiDrugsByYjCode(drug.yjCode)        return diseaseService.getDiseases(kinkiDrugs.map { it.icd })    }}多対多な関係が多く、SQLの発行回数が若干多いなーという印象があります。この辺りどうしたらいいのか誰かと語りたい！！！終わりにこのコード読んで、UbieでサーバサイドKotlinやってみたいと思った方は @shiraj_i に直接DMか以下のWantedlyさんのサイトから話を聞きにきて下さい！www.wantedly.comもっと気軽にUbieに遊びに来たい！という方は以下のBosyuさんからメッセージを送って下さい！bosyu.me(adsbygoogle = window.adsbygoogle || []).push({});

サーバサイドKotlin+GraphQLのアプリケーションをOSS化しました

2018/08/20からUbieに入社しています。3ヶ月の試用期間も無事明けたので、色々書いておこうと思います。キャリアを変えようとした動機ちょくちょく話題になる35歳に今年なりました。現役最終日です😂— shiraji (@shiraj_i) 2018年9月12日2018年4月の時点で自分の今後のキャリアについて悩んでいました。主な悩みはこのままAndroidアプリ開発者を続けるか？です。Twitterさんや日経さんなど今や多くのWebサイトがブラウザ上での体験を圧倒的に良くするPWAを採用し始めています。PWAと比較してネイティブアプリを作る優位性が、低いレイヤーの処理を必要とするゲームくらいしかないのでは？という不安に陥っていました。このままこのキャリアを続けて5年後、Androidアプリ開発者の需要が万が一無くなってしまった場合、40代で(ゲームではない)Androidアプリ開発が得意です！としか言えなかったら、エンジニアとしてのニーズが無くなりそうだと。Androidアプリ開発者の需要がある今のうちに、新しいモノを試して、駄目だったり、さらにAndroid開発者の需要が増えたら、またカムバックすることが最善策ではないかと考えるようになりました。Ubieを知るさぁ次のキャリアどうするかー？といろんな会社にお話させてもらおうと考えていた時にたろうさんの転職のエントリーが出ました。taro.hatenablog.jpこのエントリーで初めてUbieという会社があるんだなと知りました。当時このブログエントリーの感想は面白そうなことやってる会社だなー。RailsをKotlinに置き換えるとかスタートアップがそんな余裕なの！？でした。Ubieと話すたろうさんの記事の後1ヶ月くらい経ってから、Ubieがサーバサイドエンジニアを募集しているということを知りました。せっかくなのでとお話を聞かせてもらいました。共同代表の久保と話すことが出来て、ざっくりまとめるとRailsからKotlinに切り替えるのはガチ論文を読み込んで、真剣に機械学習に取り組んでいる精度に関しては圧倒的な自信あり。他社はまず追いつけない創業して1年目（当時）だけど、日本だけではなく、世界をもう視野に入れてるのような話をしてもらいました。思った以上にすごすぎて、ちょっとポカーンとしちゃいました。Ubieに入るその後、冷静に自分がUbieで働く場合を整理してみるとサーバサイドKotlinをやるチャンスがあるあのたろうさんと一緒に働けるData Scienceチームのサポート役の経験を積めそう組織がまだこれから整備される状況であり、自分の知見が活かせる余地がありそう事業的には伸び代かなりありそう創業1年目のベンチャーで、面白そうなフェーズ自分の次のキャリアとしてこれ以上ないなと思い、入社をさせてもらうことにしました。今では本当にタイミングと運が良かったなと思っています。入社の儀撮影してもらいましたUbieの業務入社前からサーバサイドKotlinをしたいと言い続けていたので、希望通り、主なタスクはサーバサイドKotlinをやらせてもらっています。Kotlin化の初期だったということもあり、たろうさんと1on1での開発をさせてもらいました。そのおかげもあり、サーバサイド開発のキャッチアップは結構すんなりいけました。Ubie社での僕としらじさん？仲良くお仕事してるよ☺️ pic.twitter.com/IKtqCzaV6S— たろう (@ngsw_taro) 2018年10月16日ライフサイクルが非常にシンプルということもあり、Kotlinのコーディングに集中出来、コード書く楽しさを実感してます。テストもしっかり書く文化になっているのもお気に入りです。Kotlinのタスク以外にもGitLabからGitHubへの移行、CircleCIの導入、OSSとしてライブラリの公開などなど色々やらせてもらっています。毎日のようにテレレ テッテッテーとBGMが頭の中で流れています。今後はこれらに加えGraphQL+Kotlinや機械学習との連携、SRE業務やPythonでの開発など様々なことに手を出していきます。リモートRepository移行させたということもあり、正確なPR/issueの数とかわからない+自分の働き方上、多くのRepositoryに顔出しているので、分散しちゃっているのですが、一番コミット数が多いRepositoryはこんな感じでした。Ubieの制度 - リモートワークと有給休暇Ubieは「週2のリモートワークが可能」です。オフィスの環境が良いこともあり、多くの人がオフィスに出社しています。今の事業フェーズではあまりうまく事が進むように整備し切れていないため、フルリモートは出来ないようになっています。今後可能になるように絶賛整備中です。自分は奥さんと子供がいます。台風が来た週、子供が熱を出してしまったため、台風で一日、子供の看病で一日リモートしました。さらに子供の熱が下がらない可能性があり、有給休暇を取るかリモートするか悩んだため、Slackで投げかけてみました。リアクション見てもらえばわかる通り、看病であれば、週3日のリモートもOKでした。ただ、さらに良くないことが続きました。自分の奥さんが入院することになってしまいました。自分たち家族は親族が新幹線乗らないと来れない距離にいるため、今までであれば、この状況に陥った場合は有給を使い看病することになります。入退院を繰り返すことになってしまったので、合計すると3ヶ月のうち、約1ヶ月はリモートしていました。最大2週間連続でした。でも同僚は自分がうまく働けるように工夫してくれました。この件からUbieのリモートワークのルールは「週2のリモートワークが可能。ただし何かしら理由があり、恒久的でなければフルリモート可」が実態です。ということで、この3ヶ月会社にいないことも多かったのですが、最終的に有給休暇の消化0です。子供が産まれてから子供の看病のため有給休暇を取得し、毎年有給消化率80%は越えていました。あんまり自分のための有給を取った覚えがなく、どういうタイミングで取ればいいのか悩んでいます。ちなみに有給は休みます！と宣言したら取れますし、週5のフルタイムであれば入社日に14日付与となります。Ubieの制度 - 勤務時間Ubieは裁量労働制です。日本で初めて入った会社が裁量労働制で、朝9:30出社(1分でも遅刻NG)で帰りは残業などして夜10:00がザラでした(見込み残業が30時間だったので40-50時間くらいサービス残業してました)。そのため、裁量労働制に対して非常に嫌なイメージを持っていて、それ以降裁量労働制の会社を避けていました。Ubieも裁量労働制だと聞いたので、若干の残業は覚悟の上で、プライベートは絶対死守しようと考えていました。しかし、実態はUbieはしっかり裁量労働をさせてくれています。遅刻という概念がほぼなく、業務中にお昼寝や映画を観にいく人もいます。自分は現在奥さんが病気になってしまったこともあり、朝息子を保育園に送り、夜迎えに行くことが必須となっています。そのため、出社が10:00頃になり、退社は17:30です。30分業務時間が足りてません！しかし自分の労働時間ではなくアウトプットを見てくれてますし、足りていない分、家で仕事して補填しています。トータルでは残業はほぼなしです。自分があまりの早さで帰るため、Ubieの他の社員さんたちがどれだけ残業しているのかあまり把握していないですが、自分より早く来て早く帰る人もいますし、自分も今後も残業0時間を目安に働いていこうと考えています！Ubieの制度 - KPTUbieでは週次でチーム内KPTをしています。リモートワークを始めたタイミングではたろうさんや自分が今何をやっているのか把握できない事態に陥ってしまったため、この課題がKPTのPとして挙がりました。解決策としては「Slackで始業時に今日のTODO共有する」としたところ、お互い何をやっているのかが把握でき、リモートでも非常にスムーズにタスクが進められるようになりました。こんな感じで毎朝やってます。この日はリモートで9時から開始残業ほぼなし、リモートもしていて、パフォーマンスが下がらないか不安だったのですが、問題があれば、都度全員で解決策を考え、改善していく文化があり、色々手助けをしてもらい、特にパフォーマンスを落とさずにタスクがこなせています。他にも良いと思ったものを取り入れたり、逆にこれは減らして良いだろうと判断したものは削減したりと試行錯誤していて、ガンガン変わっていく姿が見れて楽しいなーと感じています。Ubieの社員構成Ubieの中でかなり気に入っているのがこの社員構成です。特徴的なのがSaaSのスタートアップにデザイナーが2人揃っていること。しかも強い。この2人がUXのためなら公民館だろうが診察室だろうがガンガン入っていってより観察しまくります。動き方はUIデザイナーではなく、サービスのデザイナーです。医師が2人いるのも特徴的です。Ubieに入って初めて医師って全員が全員病院に勤務するわけでもないのだなという気づきがありました。弊社の医師だけなのかもしれませんが。全体を観て、バランスが非常に取れている組織だなーという印象を受けています。(業務委託の人がカウントされていないので、その人たちを含めるともう少しエンジニアの数が増えます。)ちなみにこの社員構成ですが来月には数字がいくつか増えます。どんどん大きくなっていっていて、ワクワクします。終わりにということで、3ヶ月しか働いていないこともあり、良いことにしか目がいっていない恋は盲目状態のブログエントリーでした。半年くらい働けば、きっと悪いところももっと見えてくるはずなので、来年落ち着いたらまた続編を書いていきたいと思います。これを見て、興味あるなーという方は @shiraj_i にDMしてもらうか、以下で応募して下さい。https://www.careers.dr-ubie.com/www.careers.dr-ubie.com一覧にはないのですが、SREやデータサイエンティストも募集してますのでぜひ！直近ではこんなイベントもあるよ！bosyu.mebosyu.me

Ubie, incに入社しました。

Ubieという会社に入社して、brave-ktというライブラリを公開しました。Ubie入社ブログエントリーは試用期間明けたら書くとして、このライブラリについて書いていこうと思います。想定読者Ubieのシステムに興味ある人サーバサイドKotlin興味ある人前提今自分が関わってるプロジェクトではSpring Boot2.1+Kotlin1.3+GCP(GKE, CloudSQL)を利用して、RESTfulのAPIを開発しています。ざっくり図にするとこんな感じです。よくある構成だと思います。ユーザがAPIを叩くと、最初にロードバランサーに到達し、アプリサーバを経由して、DBアクセスします。ログ出力この構成で問題になるのはログです。一つのリクエストを処理するのに複数のコンテナが関わっており、あるユーザのリクエストを追跡する場合、ログを一つ一つ確認していかなければなりません。この問題を解決するために出てきたのであろうものがStackDriver Traceです。導入すると以下の公式ドキュメントのquickstartの画像のようにTimelineのところで複数のコンテナのログを一つのリクエストごとにまとめてくれます。Quickstart  |  Stackdriver Trace Documentation  |  Google CloudStackDriver Traceの導入StackDriver Traceの導入には、Google Cloud SDKが必要です。Installing Google Cloud SDK  |  Cloud SDK Documentation  |  Google Cloudgcloudにログインして、project名を設定します。gcloud auth application-default logingcloud config set project [PROJECT名]Spring Bootでの導入には設定をいくつか追加します。Ubieではlogbackを利用しています。ちなみに、spring-cloud-gcp-starter-traceの1.0.0.RELEASEは動かないので注意して下さい。build.gradlerepositories {    // for spring-cloud-gcp-starter    // There is a bug on 1.0.0.RELEASE    maven { url "http://repo.spring.io/libs-milestone" }}dependencies {    compile 'io.sentry:sentry-logback:1.7.5'    def springCloudGcpVersion = '1.0.0.RC1'    compile("org.springframework.cloud:spring-cloud-gcp-starter-trace:$springCloudGcpVersion")    compile("org.springframework.cloud:spring-cloud-gcp-starter-logging:$springCloudGcpVersion")}logback-spring.xml<configuration>    <springProfile name="production">        <include resource="org/springframework/cloud/gcp/autoconfigure/logging/logback-appender.xml" />        <root level="INFO">            <appender-ref ref="STACKDRIVER" />        </root>    </springProfile></configuration>application.ymlspring:  cloud:    gcp:      trace:        enabled: true      logging:        enabled: true  sleuth:    sampler:      probability: 1.0問題発生さて、ここまでやってログを出してみたのですが、以下のようになってしまいました。queryのログなどがまとまっています。しかし以下の赤線の部分がquery実行中になるはずなのですが、queryの実行時間などを見ることが出来ません。これはCloudSQLがTraceなどに対応していないように見えます*1。つまり以下のような感じになっているようです。これを解決するためには、GCE上のSpring+Kotlin側で明示的にログを出力する以外手は無さそうです。ようやく本題この問題を解決するため、TraceのライブラリにあるScopedSpanを使います。val span = Tracing.currentTracer().startScopedSpan("db access")try {    jdbcTemplate.query ( ... )} finally {    span.finish()}こんな感じに表示されるようになります。良さそう。それでこのコード見てて、Kotlinだしもうちょっと書きやすくできないかなーって思い、ライブラリを作りました。それがbrave-ktです。これを導入すると以下のように書けるようになります。val result = tracer.scopedSpan("db access") {    jdbcTemplate.query ( ... )}以上！（二行しか紹介してない。。。）宣伝さて、Ubieでは、エンジニアを募集してます！https://www.careers.dr-ubie.com/www.careers.dr-ubie.com結構GCPにはヘビーに今後も依存していくので、その辺り関わりたいSREの方や、Spring+Kotlin書きたいサーバサイドKotlinやりたい人はぜひ応募して下さい！雰囲気先に知りたいって方は以下のただ社員が遊ぶイベントがありますので、どんな感じか確認しにきてください。bosyu.meちょっと怖いから何からすればいいかわからない。という方はTwitterでDMして下さい。*1:Issue上げてます。https://issuetracker.google.com/issues/118466628

brave-ktをリリースしました

Kotlin Festの感想ブログを読んでいて、やっぱり自分も書きたくなっちゃった。だから書く。登壇依頼DroidKaigiの発表の時、CfPを出すものだと思っていたので、何を書こうかなー？って思ってたのですが、一向にCfP出せる場所がなく、本当に大丈夫なのかな？と心配していたら、@satorufujiwaraさんから依頼を直接受けました。日時が土曜日だったこともあり、家族に確認を取り、なんとか了承してもらって参加することに決めました。登壇内容はHow to Kontributeを日本語でやってほしいという話でした。もともとはHow to KontirbuteはOSSの話であるし、日本人だけにやるものではないと思っていて、英語でやるものだというイメージがあったのですが、藤原さんがそういうならと日本語でやってみようと思い、快諾しました。登壇準備準備は英語のプレゼンを日本語にしていくだけなので、簡単だと思ってました。が、初めてリハをやったときは52分(セルフィーなし)という記録を出してしまいました。これはプレゼン最中にふと思ったことを口にしてしまえる母国語だからで、これ重要だ！とかここで笑いを取りにいけそう！と思ったら口に出してしまい、グダグダに伸びるという状態でした。さすがに5分以上超過はまずいと、スライドを何枚か削り、メモを英語で書いていたので、あまり考える余地を作らせないために、日本語に書き直すなどの対処をしました。スケジュール確定スケジュールを知ったのはconnpassでスケジュールが公開された時です。公開された＋LTと同じというのを同僚の某主催者から聞かされました。カンファレンスでは基本早めにトークさせて下さいって毎回お伝えしているのですが、Kotlin Festでは時間の指定しなかったです。ただまさか最後になると思ってなかった＋LTとセッションを同時刻にやると思ってなかったので、決まった時の本音は「それはないわー！」でした。前日完全に見落としてたのですが、ランチがないことにconnpassを見て気づきました。で、せっかくだし、色んな人と話したいと思ったので、こんなツイートしました。明日Kotlin Festでランチ誰か一緒に行かないですか？サーバサイドKotlinの話したい方、Kontributeしたい方、弊社興味ある方ぜひ！！！自分含めて四人くらいで！（自腹でお願いします。。。）— shiraji (@shiraj_i) 2018年8月24日これツイートする前に結構文章推敲してて、それを嫁ちゃんが横で見ていて、ツイートしたらぼそっと「これで誰も来なかったらウケるｗ」って言われてまじでこれで来なかったらどうしようと泣きそうになりましたが、結果4人も集まってくれました！ちなみに夜にリハする予定だったのですが、気づいたら、寝てて、3時くらいに「あ、この登壇終わったわ・・・」と愕然としてました。当日(午前中)時間通りに到着しました。ビルの入り口がわからなくて迷子になったけど。会場の入り口がわからず、一周しちゃった— shiraji (@shiraj_i) 2018年8月25日登壇者の控室がものすごく広くて快適でした。快適だったんですが、これなら3つの会場にしてもらって、もっと色々発表あったら！と思ったけど、あまりに快適だったからやっぱりそのままがいいです。控室にもセッションの音とスライドが見えていて、登壇準備や練習をしつつ、聴けるという最高の環境でした。オープニングは会場の雰囲気を確認したく、2列目で聴いてました。そしたら、LTと時間がかぶったためなのか、二回も紹介してもらっちゃって、もうテンション上がりまくりでした。私です！ （うまく撮れない😂）#KotlinFest pic.twitter.com/KNFTKk7Xln— shiraji (@shiraj_i) 2018年8月25日また紹介してもらえたー！！！#kotlinfest pic.twitter.com/gCZAGF3691— shiraji (@shiraj_i) 2018年8月25日「Kotlinを愛でる」をプッシュしまくっていたので、じゃあ、ということで、タイトルにEmbracing Kotlinを追記しました。ランチ前日に募集したのですが、何話すとか、何も決めずに向かいました。お店は朝迷ったときにビルの1階に肉のお店を見つけて、暑かったし、そこでどうでしょう！って即決しました。初めて会った人ばかりだったのですが、一時間Kotlinの濃い話が出来ました。もっと時間あったら良かったのですが、本当に楽しかったです。また登壇とかする機会があれば、スピーカーということネタにランチ募集しようかなと思いました。当日(午後)参加者と交流することが目的だったので、セッション一つも聴いてないです。(そのためPSIViewerがこの日二回目の登場だったのを知らなかった)Yahooさんのブースでモブプロやるって言っていたので、参加しました。モブプロはあと一人か二人自分のチームに入ったら、たろうさん、自分含めやってみたいなーと思ってたので、どういう感じになるのかな？ということで参加しました。RESTのAPIを作るプロジェクトでした。Springの知らない機能を使っての実装だったので、あんまり口が出せなかったのが残念だったのですが、気になっていた、意見が衝突する場合、どう解消するのか？を知りたく、それまでの話からドライバの方が想定していたであろうControllerのメソッド名(findById)ではないもの(show)にしませんか？と叫んでみました。まぁRESTのControllerのメソッド名はあんまり影響ないためか、参加者から挙がったものだからか、特に議論もなく採用されてしまいました。あー！やっちまった！ということでモブプロで爪跡残したぞ！#kotlinfest— shiraji (@shiraj_i) 2018年8月25日さすがに時間が短かったなーという印象です。登壇前の30分でしたし、参加者は席を取りたいし。個人的には実際に意見がぱっかり割れた時にどのように合意が形成されるのかが知りたかったです。RESTのAPIを作ることが目的になってしまっていた感じで、うーん、じゃあSpringのライブコーディングという形にして、モブプロではなくても良いんでは？となってしまいました。でもモブプロを疑似体験出来て良かったです。設計するタイミングとかでの採用もいいなーという感じでした。他にもmixiさんやCAさんのブースのPuzzler参加しました。mixiさんの方では、何問か間違えましたが、なんとか良い結果だったと思います。CAさんの方はさっぱり過ぎて、手元にIDEAないと無理でしょこんなん！という感じでした。楽しかった！ただ、CAさんの方、これせっかくやるならエンジニア一人は常時ブースにおいてほしかったです。ブースにいる方がふたりともエンジニアじゃなくて、このコードに関してーとか話そうとしたのですが、エンジニアじゃないので、またあとで来て下さい！と言われてしまって、うおー聴きたい！と消化不良でした。もっと話したかった！ブースを一通り回ってから、控室に戻り、スライドの手直しをはじめました。控室で他のスピーカーの話が聞こえるの非常に良いのですが、あまりに面白そうな内容で気になってしまって、控室前の椅子に座って準備してました。トイレ前だったこともあり、結構色んな人に話しかけてもらえて、これはこれで楽しかったです。登壇前の緊張がほぐれたし、色々また勉強することが出来ました。登壇2時間前くらいに自分のスライドの特にInspectionの実装コードのスライドがちょっとこのカンファレンスの空気と合ってないなーと感じました。そこで、登壇時間が懇親会前ってこともあり、急遽いらすとやさんの飲み物、食べ物の画像をペタペタ貼り、Twitterで盛り上げようぜ！というスライドを追加しました。このタイミングでスライドを増やすことにより、80Pに到達した。。。— shiraji (@shiraj_i) 2018年8月25日残り時間少しということもあり、最後のリハをしました。控室で外向きながら小声でブツブツ話していたので、傍目から見たら相当やばい感じだったと思います。登壇登壇前15分に会場に行きました。アダプターが合わず、かなり焦ったのですが、スタッフ、会場の皆さんに探してもらい、ちょうど良いものを10分くらい前にそろえてもらいました。本当に感謝です。さらに想像通り、結構な方がLTの会場に向かっていました。そこで登壇者の控室で近くにいた、m3の方たちに控室で聴けるにも関わらず、空いてるから会場に来て下さい！とお願いしたら本当に来てくれてしかもかなり前の席を確保してくれるという神対応をしてもらいました。登壇前めっちゃ緊張してたのですが、@mhidakaさん、@shanonimさん、@chiiia12さんが色々話しかけてくれて、結構リラックスしてやることが出来ました。登壇中、いくつかのスライドで頭真っ白になってしまい、あれ？何話すんだっけ？とめっちゃ頭がフル回転したのは覚えています。会場に聴きにきてくれた人たちの反応が暖かく、自分が思った通りのところでしっかり反応してくれていて、やっぱりKotlin界隈暖かくていいなーと。懇親会のための気分盛り上げのいやすとやさんも反応が良くて、してやったり！でした。photos.app.goo.glそして、未来のKontributorの皆さんです！すいません！！！自撮りが下手で全員入ってない😭https://t.co/UJSz3W7rih pic.twitter.com/VtN7nNEJ4p— shiraji (@shiraj_i) 2018年8月26日終わった後気づいたのですが、LT会場でも結構自分のことを紹介してもらっていて、さらにスタッフの機転でLT後に自分の会場もつないでもらったようで、本当にごちそうさまでした。某主催者から会社のランチで、LTと同じ時間ですって聴いて、それはないわーLT何人も話すし、そんなん誰も聴きにこないじゃーん！って思ったんですが、オープニングでは二回も紹介してもらえたし、部屋にいっぱい人が来てもらえてたし、さらにLT会場も繋げてもらえて、はっきり言って美味しかったです😊— shiraji (@shiraj_i) 2018年8月25日懇親会懇親会ではパックマンルールが採用されてました。本当にこのルールいいですね。懇親会だと仲良い人と話すことになりがちなんですが、空いているので、入ってきやすいし、輪を作ってる人も周りを意識している感じでした。でももっとはじめましてな方と話したかった！最後にものすごく楽しかったです。Kotlin Fest 2019も登壇したい！！！Kotlinをもっともっと愛でたい！！！！！！

Kotlin Fest 2018に参加してきました

まとめAIとJetpackとConstraintLayout前提条件会場で起こったことをつらつらと書いていきます。技術的な話は一切ありません。苦手な人は戻るボタンで戻って下さい。前日SFにはGoogle IO前日に到着しました。飛行機内がガラガラだったため、平らな場所で足を伸ばしてのんびり出来ました。1時間ほど寝れたのが良かったのか時差ボケはなかったです。筋肉のおかげかもしれません。筋トレしてないですけど。着いてすぐにSFで仕事があり、SFO->SFにBARTで行きました。先方と会議をしてから、CaltrainでSF->Mountain Viewへ移動。このまま会場でBadge Pickupしたかったのですが、スーツケースが飛行機で壊れされちゃったので、一旦AirBnBの宿泊先に行きました。プール付きでした。一日目(Keynote)セッションの予約はこのセッションだけは聞かないと帰れない！というKotlinの2セッションだけ前日までにしていて、あとはKeynoteを確認してから予約しようと考えていました。前から聞いていたけど、KeynoteはAI一色。何をするにもAIが入っていた気がします。他にはJetpack周りが大きいかな？という印象でした。自分の現在のタスクがAndroid開発から離れ、R&D的な仕事をしているため、知識を広げることに重きを置き、聞くセッションを決めました。それと一回はコミュニティのMeetupに行きたかったので、二日目のOSS Community Meetupに行くこととしました。一日目(セッション)Effective machine learning using Cloud TPUsWhat’s new with Android TVWhat's new in Android development toolsThe future of apps on Android and Google Play: modular, instant, and dynamicModern Android development: Android Jetpack, Kotlin, and moreと、Keynoteでは考えておきながら、いくつか会場を間違えて入ってしまったので、結果的にAndroid中心に聞きました。The future of apps on Android and Google Play: modular, instant, and dynamic印象的だったのが、間違って入ったセッションの一つのThe future of apps on Android and Google PlayでDynamic Featureです。ざっくり概要としてはDynamic Featureの話の前提としてアプリサイズは小さく抑えたいよね。ほぼ使わない機能は使う人にだけ渡せば良いよね？という流れから出来たであろう機能です。実際、アプリを開発していて、この機能90%以上のユーザ使わないな。って機能結構あるので、非常に良いなーという印象でした。code pushみたいな名前なので、戸惑う可能性があると思いますが、apkをGoogle Play内で分割しているという印象なので、Dynamic featureだけを更新するとかは出来ないようです。Modern Android development: Android Jetpack, Kotlin, and more他のセッション聴いていてもそうなんですが、今後Android開発ではJetpackが台風の目になるのは確実だなという印象を受けました。ただ若干勇み足な感じもしていますが。。。詳しいことはすごい人に任せます。一日目(セッション後)アメリカで働いている同僚と落ち合いました。そこにいた色んな人とお話が出来ました。そこまでほぼ一人で行動していたので、楽しかったです。日本の初めてお会いする方ともお話が出来ました。マジックショーがあったので、それを見て、AirBnBの方へ戻りました。そこから日本のチームと仕事してたのですが、なぜか3時までやってました。惚れさせ１５５　「実質」二日目(セッション前)朝8時前にAirBnBを出たのですが、Lyftの車が全然来なかったです。値段が跳ね上がってました。初めてシェアして乗りました。道路も混んでおり、降りた時点で8:30過ぎてました。一緒に乗車していたロシアの方と降りた後話が盛り上がり、入り口でものすごい並んだので、二人でデバイスピックアップにいきました。Android Thingsはパズルやらないとあげないーとかわいく拒否されたので、前日終わらせていた彼にヒントもらいパズル解くことにしました。会場入り出来たのが結局9時前だったので、朝ごはん食べつつ、掲示されているブースを色々回りました。二日目(セッション)What's new in Android Things[Meetup] Open Source communityBuild real consumer devices with Android ThingsTensorFlow for JavaScriptWeb Components and the Polymer Project: Polymer 3.0 and beyondAndroid Jetpack: what’s new in Android Support LibraryML Kit: Machine Learning SDK for mobile developersIntegrating your content with the Google Assistant using AMP and markupThe power of Headless Chrome and browser automationMachine learning models + IoT data = a smarter worldこの日はトピックがうまくバラけました。Open Source Community初日に参加を決めたOpen Source CommunityではGooglerのOSSの人たちと話せるということで、GoogleのOSSにも関わりたいなーと思っていたので、ぜひにと気合入れていきました。そしたら、すんごいふんわりいつの間にか始まっていて、勝手に話して良いよ？と言われ、うまく輪の中に入れなかったので、一緒に輪に入れなかった人たち+後から来た人たちと話しまくってました。結局40分ほどずっと同じ人達と話してGooglerと話さなかったｗでも普段かかわらないnode.jsのコントリビューターやUS政府のプロジェクトに関わっている人たちと話せたのは良い機会でした。OSSをやりたいけど、やったことがないという人たちにアドバイスとかもしてました。プロジェクトへの参画動機や最初のコミットどこから？などみんな同じような考えをしていたのが印象に残りました。TensorFlow for JavaScript特に印象に残ったセッションの一つのTensorflow for JavaScript。お昼ご飯食べつつ、片耳で聞いているかーと思い芝生から聞いていたのですが、途中から楽しくなっちゃって食べずに話ばっかり聞いてました。tensorflowの結果をブラウザで見える化したらすごい良いレスポンスだったので、JSでtensorflow出来るようにしてみたらしいです。ブラウザで出来るというのはすごく敷居が下がって良い。さらに過去サーバでpythonなどで生成したモデルもそこで再利用出来るのも既存の資源が無駄にならないのも良い。高校生や大学生が利用しているとか。AIを高校生の時点で学べるなんてなんて贅沢なんだ。。。さらにこの日サーバサイドでnode.jsが使えるようになったという発表されました。python一色だったtensorflowにJSの流れが来ているので、今後注目だなーという感じでした。Web Components and the Polymer Project: Polymer 3.0 and beyondPolymerの発表もすごかったです。Polymer界では有名な二人が登壇するとあって、登場しただけで拍手出てました。ニワカなので、すごさがわからなかった。内容はもう怒涛な感じでした。前日の睡眠不足から、このあたりで眠気くるよなって思ったんですが、寝てる暇ないくらいどんどん新しい情報をinput出来ました。Polymer3.0が使えるようになったことと今議論進んでいる内容も含めて色々話が聴けました。このセッションのメモ「情報ありすぎてウケる」で終わってました。動画確認してみてください。本当に怒涛です。Android Jetpack: what’s new in Android Support Library昨日からちょくちょくJetpackのFragmentという言葉が出ていたので、あーヤバそうだなーって思い、これを聴いて、パッケージが変わるのが確定したので、issueあげておきました。https://github.com/permissions-dispatcher/PermissionsDispatcher/issues/472書いた後にFragmentだけじゃなくActivityもじゃね？別のsupport libのクラスもじゃね？って思ったんですが、後で考えることにします。二日目(セッション後)前日に続き、仕事がふってきていたので、コンサートも参加せず、AirBnBで仕事していました。自分頑張りすぎだと思う。賞賛して下さい。三日目(セッション前)朝は結構空いていました。3日目ともなるとみんな体力なくなるのかな？まず朝初っ端からPermissionsDispatcherの対応に関してOffice Hourに向かいました。ただ、残念ながら、support libraryの人たちではわからないと言われ、Sandboxへ行くように言われ、行ってみたら、わかる人がまだ来てないとのことでした。もうこの時点で結構時間を取られていたので、セッション終わった後にまた来ると伝え、場所を離れました。たらい回しになったのですが、みんな良い感じで接してくれたので、特に嫌な思いをしなかったのが良かったです。最終的にこのコメントになりました。https://github.com/permissions-dispatcher/PermissionsDispatcher/issues/472#issuecomment-388219243三日目(セッション)How to Kotlin - from the Lead Kotlin Language DesignerAndroid Jetpack: sweetening Kotlin development with Android KTXWhat's new with ConstraintLayout and Android Studio design toolsHow to Kotlin - from the Lead Kotlin Language DesignerKotlinの神が初心者向けのKotlinの説明をしてくれました。どんどんコードが短くなっていくなーって眺めていたら、coroutineの説明が出てきてあー最早coroutineは初心者向けの常識なのかと驚きました。Android Jetpack: sweetening Kotlin development with Android KTXJakeさんのセッション。ktxの説明よりKotlinのライブラリを作るにはどうしたら良いか？という説明の方を目的に聴きました。ktxの方の説明、力抜いていたのですが、ライブラリの話になって、急に@ExtensionFunctionをJavaコードにつけたら、Kotlinが勝手にExtension Functionと認識して呼べるようになるだからこれをつけよう！って話していて、このアノテーションを出された時点で混乱して、ググっても情報なんら出てこないし、どういうことだ？って思ったら、この発表の1時間前にKEEPにJakeさんが上げた内容の説明だったようです。github.comあまりに驚いて。これでも、すごくない？まだ自分一人でこれ欲しいんだよねーって言ってるだけで、誰からもレスポンスないのに、あのGoogle IOで入るかもよ！って話すんだよ。こんな暴挙出来るの世界でも彼だけでしょ— shiraji (@shiraj_i) 2018年5月10日What's new with ConstraintLayout and Android Studio design toolsすごい。やばい。すごかったです— shiraji (@shiraj_i) 2018年5月10日セッションを見てないAndroiderは最初のほうは流していいから、早めに観たほうが良いです。三日間のセッションで一番拍手が凄かった。三日目(セッション以外)三日目で人も少なかったし、アグレッシブに動き周りました。Android AssistantAndroid AutoDesign & AccessibilityCodelab友達が出来た+会えたAndroid AutoAndroid Autoは前から楽しみにしています。一緒に並んでいた4人と車の中で説明をしてもらいました。車のエアコンのコントロールを声で出来たり、Google Assitantを利用して、メッセージのやり取りなどそ実践してもらいました。大きなサイズのものなのか、タブレットサイズで、画面が非常に見やすかったです。NY Timesなどがサポートしているようで、音でコンテンツを提供できるアプリなどは最高だなーという感じでした。CodelabCodelabは多くの問題があり、Googlerに聴きつつコードを書ける場所だったのですが、ChromeOS with Linuxが気になってしまい、マシンスペック見たり、コマンド触ってみたり、全くCodelabとは関係ないことをしていました。Chromebookセッションの時adbないって笑ってたのに、普通にインストール出来てるし、動いてるし、空プロジェクトなら簡単にシミュレータにインストール出来るし、まじで買いじゃん！— shiraji (@shiraj_i) 2018年5月10日pic.twitter.com/Cw8n0xf6Sk— shiraji (@shiraj_i) 2018年5月10日gitも入ってる pic.twitter.com/ti4VZ5zkLu— shiraji (@shiraj_i) 2018年5月10日MBAとほぼ同じ薄さ。重さもほぼ同じ。 pic.twitter.com/eWN3RPlbWB— shiraji (@shiraj_i) 2018年5月10日Linuxのデフォルトで入ってるコマンド結構使えますね。curlとかも出来ました。 pic.twitter.com/3g0O6pliSg— shiraji (@shiraj_i) 2018年5月10日帰国便待っている時に@ymndさんから聴いたのですが、実機確認が直接出来ないとのことだったので、開発機としてはやっぱり厳しいのかなー？と思いつつ、curlやsshなども出来たし、サーバサイドの開発などには可能性あるかもなーとぼんやり考えてます。友達が出来た+会えたOSSのCommunity Meetupだけではなく、偶然話しかけてくれた人と仲良くなったり出来ました。また、普段会えない人たちともお会い出来ました。道ですれ違って挨拶だけしかしなかった人が何人かいて、時間が足りませんでした。。。突然だと「あ、あ、」ってなってしまう。。。その中でも特に印象が残っているのが、以前Kotlin Night Koltakaでリモートで挨拶させてもらった@ravidsrkさんと偶然隣の席になり、お話出来たことです。What a coincident! @ravidsrk find me sitting next seat! #io18 We met @KotlinKolkata night remotely. pic.twitter.com/bBS4RXKhLu— shiraji (@shiraj_i) 2018年5月10日彼はKontributeの動画を観てKontributeし始めてくれた一人で、さらに自分の公開しているプラグインもガッツリ使ってくれているようでした。会社の環境構築フローに自分のプラグインを数個入れてくれていて、Find Pull Requestなんてあるよ？と説明したら、めっちゃ喜んでくれました。最近これ動かないけど、どうしたの？とか、この機能公式に取り込まれたね！とか作った本人よりプラグインのこと知っててくれて本当に嬉しかったです。最後にAndroid周りはスゴイ人たちがわかりやすく説明してくれるはずなので、新しい出会いを求めることに努めて非常に良かったなーという印象です。このIOでAndroid関係ないTODOの優先度最高なものがいくつか出来たので、何かしら形にしたいなーと思っています。

Google IO 2018に行ってきました

DroidKaigi 2018で登壇した&参加した

今年本当に自分のエンジニア生活が一変した年だったので、書き留めておく。が、普通に文字だけで書いたら、ただの長いエモいものになってしまった。そこでエゴサーチ縛りにしてみました。まず2017年まとめの前に2016年のことを書かないと始まらないので、2016年のことから。2016/11/21自分の生活はこのツイートで良くも悪くも変わった。.@shiraj_i 予算がないとかで、申請が却下されそう。自腹か。8000円の参加費と3/9, 10休んでもいいという会社ありましたら、転職しますので、ご連絡下さい。— shiraji (@shiraj_i) November 21, 2016前職の人たちは本当に良い人たちばかりで、特に批判などせずに、暖かい目で見守ってくれた。一番怖かったのが前職の上層部に知られ、首にされ、家族に見放される場合だった。そこで、嫁ちゃん意を決して伝えてみた。自分「〜〜こういうことがありまして」嫁ちゃん「あ！ガチャ！セフィロス(FFイベント)だ！」自分「転職するつもりです。」嫁ちゃん「がーん。出なかった・・・。チッ！エースってなんだよ。」自分「聞いてた？」嫁ちゃん「ショックや・・・てか話終わったなら洗濯物干してよ早く。」自分(しぶしぶ洗濯物干しに向かう)嫁ちゃん「てか首になっても、私がフルで残業して、(自分が)バイトでもしてくれたら生活困らんでしょ？」嫁ちゃん「そんなことよりセフィロス出なかったほうがショックだわ。エースってなによー。」男気溢れる嫁ちゃんでした。抱いて！1, 2月さて、こんな感じで、2017年を迎えました。初旬で転職活動がようやく完了しました。慎重になっていたと言うより、スケジュール調整で手間取ってしまった方が大きかったです。こんな自分に声をかけてくれる会社には全て会わなければ！と思い、20社会い、そこから面接に入っていたので。でも本当にどの会社も今からでも行けるほど良い会社ばかりでした。(Twitterとタイトルにあるにも関わらずですが、相手がいるため、この辺りツイートは一切しておりません)background/foregroundチェック用のライブラリを出していた。これAAC使ったほうが良いのかな？deprecatedにすべきかも？Released Android library called butai. Now the application knows if it is background/foreground https://t.co/tvjAAjBttY— shiraji (@shiraj_i) 2017年1月28日他にもDroidKaigiアプリにコントリビュートいくつかキメました。今年もコントリビュート頑張ります！（後でみんながコントリビュートしやすいようにバグとかtypoとか入れておきます！）— shiraji (@shiraj_i) February 6, 20173月DroidKaigiそんなこんなで、"自腹"で初参加でした。自分の大好きなバーテンダーさんに今日本当に幸せな顔していますよと言われた。— shiraji (@shiraj_i) March 10, 2017本当にようやく参加出来たし、勉強いっぱい出来て、しかもすごいエンジニアの人たちといっぱい関われたので、幸せでした。フラグも立てた。来年チャンスあったらスピーチ側に回りたい！という思いだけはあるので、次のCfP期限までに何か武器拾いたい。今持ってる武器はニッチ過ぎて、誰もいない部屋で一人で泣きながらプレゼンしてるのが目に見える。— shiraji (@shiraj_i) March 10, 2017DroidKaigiの幸せに浸っていたけど、KotlinConfの存在に気づく。おおおう！？https://t.co/HiFC5sGv17— shiraji (@shiraj_i) March 29, 2017この日のうちに、Speakerを目指し、動き出す。4月人生初のCfP提出。(How to KontributeのCfP）Submitted KotlinConf CfP! This is my very first CfP!!!— shiraji (@shiraj_i) April 7, 2017そういえば、前職の若手達からPRがまだ来てない。OSS頑張っているだろうか？(そもそも彼らがコントリする価値があるRepoを自分が持っていないけど晒しておきます)若手のホープ達がOSSやります！PR投げるので見て下さい！とか宣言してきた。OSS沼に引きずり込むことに成功した模様。— shiraji (@shiraj_i) April 13, 20175月現職に初出社。初日は神戸本社。出社ァァァ！ pic.twitter.com/nUbhtH4UAe— shiraji (@shiraj_i) May 1, 2017一ヶ月でWeb業界との違いに色々心がざわついた。いろんな仕組みをいろんな会社が作っていて、諸々やばそう。しかも規模でかそう。くらいのざっくりしか一ヶ月で把握できない状況だった。正直焦りはあったけど、まずは足元しっかり固める為にとにかくシステムに関わる人と話した。初めて執筆に関わった。出国前にv1.0.0リリースきた！初めて本？に関わりました。スピード感がよかったです。本書くのって大変だなーという感想でした。楽しかったー。https://t.co/SQdpvUxX1a— shiraji (@shiraj_i) 2017年5月29日リリースされた日にそのままボストンへ。一ヶ月ボストンで修行してきます！PC持ち込み禁止になる前にはなんとしても帰ってきたいです。。。ではまたー！（どうせ向こうでもOSSやってるだけであまり変わらんだろうけど） pic.twitter.com/3HIVG5sH3t— shiraji (@shiraj_i) 2017年5月29日6月ボストンで武者修行。海外でフルタイムで働けるかどうかちょっと心配だったが、いい人が良く、仲良くさせてもらった。スクラムをしっかりやったのは実は初めてだった。特に苦なく、進められた。肉！🍖🍗 pic.twitter.com/4tDGwO8w7o— shiraji (@shiraj_i) 2017年6月9日途中KotlinConfのCfPが通った。KotlinConfを無事に終わらせるが今年の最重要事項に設定した。手が震えてクリック出来ない。 pic.twitter.com/G3Qv7iNndK— shiraji (@shiraj_i) 2017年6月13日ボストン空港で結婚指輪を盗まれ、テンション最低となり、帰国ツイートせずに帰国。そのため何人かに、日本にいるんです？と混乱させてしまった。7月5月入社して、社内のことがほったらかしだったので、人事周りやら、いろんな案件に顔を出しつつ、タスクこなす日々。社外向けの発信をしなきゃね！ということで、調査開始。企業の（テック的な）ブログ作る場合、どのサービス使うのが良いのでしょう？ブログを自前で用意するリソースがないです。— shiraji (@shiraj_i) 2017年7月5日最終的にMediumに落ち着く。8月PermissionsDispatcherのコアなメンテナ達と初めての会食。これは本当に楽しかった。もっと英語うまくなりたい。permissions dispatcher maintener united!!! @hotchemi @marcelschnelle pic.twitter.com/18LiMeTkp3— shiraji (@shiraj_i) 2017年8月25日9月7月初旬から始めて実を結ぶ。I just published “Start ASICS Digital Publication” https://t.co/pT7iYWLQTo— shiraji (@shiraj_i) 2017年9月20日でもここからブログより優先度あげて、最近リリースしたアプリに集中することにしたので、ブログの発信が途絶えた。ツイートしていなかったけど、Android Tokyo Meetupに参加。日本で初めて英語の登壇をした。10月CA.kt #3で登壇した。CA.kt来た！（飛行機乗ってきたので、汗臭い）偉い人に無線の設定してもらってる。#ca_kt pic.twitter.com/JLphX8nblP— shiraji (@shiraj_i) 2017年10月19日この登壇は忘れたくても忘れられない。いい勉強させてもらった。人生初、献本して頂いた。(まだ感想書いてない・・・すいません。)生まれて初めて献本された！嬉しい！！！ありがとうございます！ @satorufujiwara @ngsw_taro @boohbah @yy_yank pic.twitter.com/2GeAcT5zNB— shiraji (@shiraj_i) 2017年10月23日11月11/2 KotlinConfに登壇した。I will be there as a Speaker! So excited!!!#KotlinConf pic.twitter.com/kQ6GEP8Zil— shiraji (@shiraj_i) 2017年11月2日11/4 KotlinConfの登壇ネタをブログに書いたら、初めてホットエントリーに入った。興奮して寝れないので、がーっと書いてみた。雑文過ぎるので、後で修正か消すかも？ / “LT1回しかしたことなかったエンジニアがKotlinConf 2017に登壇したお話 - shiraji’s diary” https://t.co/qeVLs6cHgY— shiraji (@shiraj_i) 2017年11月4日11/5 DroidKaigiのCfPが通過How to Kontribute、また採択してもらえたー！さらにもう一回チャンスある！時間かけて準備してたから嬉しい！！！Android Studioプラグイン周りはやはり需要なかったか。残念。英語でしかプレゼンしないキャラにでもなっとくかこれ。— shiraji (@shiraj_i) 2017年11月5日この数日、神すぎでは？念願のdex.fmにも出演した。今まで何回か名前だけ出してもらっていたので、ようやく。でも収録聞いたら、笑ってるだけだった。。。すまんな。調整中。緊張する。 pic.twitter.com/4RooDCnNUS— shiraji (@shiraj_i) 2017年11月17日12月KotlinConfのフィードバックもらった。Does this mean my talk's audience gave me 5th place in entire the conference? Am I dreaming? How nice were they!!! #kotlinconf17 pic.twitter.com/LeyOIg1TRs— shiraji (@shiraj_i) 2017年12月7日9月の社外向けブログが出たくらいから本格的にアプリ開発着手。入社後初の新規アプリリリース。新規でアプリ作りに関わったの数年ぶりかも？楽しかった。【宣伝】エンジニア: 研究員デザイナー: アプリデザイン初経験PM: PM初経験見届け人: 自分このチームを9月に作り、アプリ一つ形になりました！みんな開発経験ない中、もがき苦しみながらやってくれました。☆1は勘弁して欲しいですが、ぜひ使ってみて下さい！https://t.co/v1hpliXBU4— shiraji (@shiraj_i) 2017年12月14日2017年反省点登壇にこだわり続けた一年だった。とにかく登壇を意識していた。非常に良い結果になったし、このまま続けていけるなら続けていきたい。しかし、コードのアウトプットが激減した。優先度を下げたのも事実だが、もうちょっと良いやり方がある気がする。2018年の登壇予定1/18 どこでもKotlin #5これに登壇します！Android x Kotlin+登壇者が豪華ということもあり、人気いっぱいあるイベントですが、需要無視してASプラグインネタやります！途中でブーイングを受けても舞台から降りませんので！どこでもKotlin #5 〜Android特集〜 https://t.co/SxmzcsWVDA #m3kt— shiraji (@shiraj_i) December 24, 20171/26 DroidKaigi Prelude@__gfx__ さんと @muumuumuumuu さんがDroidKaigiのセッションの事前説明をしてくれるらしいので、舞台上で聴いてくる！https://t.co/OHs7Vmgtwm— shiraji (@shiraj_i) 2017年12月5日2/8 DroidKaigi2018年の目標一回登壇を経験したので、流れも掴めたし、登壇の方の負荷も減ると思うので、コードのアウトプットと両立させたい。(ただ、Kontribute以外の登壇ネタが見当たらないので、自然にコードのアウトプットが増える気がする。)最後にそれにしてもこの一年、本当に色々ありました。。。勉強会に何回か出ることも出来て、初めてお会い出来た人がいっぱいいました。来年も引き続きよろしくお願いいたします。

Twitterエゴサーチで見る2017年まとめ

LT1回しかしたことなかったエンジニアがKotlinConf 2017に登壇したお話

DroidKaigi2017参加してきた。自腹で

まとめ以前から色んな箇所で取り上げられているjitpack.ioですが、ドキュメントに書いてない機能であったり、書いてあってもよくわからない機能がいくつかあったのでまとめてみました。そもそもjitpack.ioって何か？とかどう使えばいいのか？は以下のリンクを確認して下さい。qiita.com以下の機能の説明をします。compile指定以外Multiple ModuleSNAPSHOT versioncompile指定以外compile指定以外ももちろん問題なく動きます。例えばよく使う、aptの場合apt 'com.github.$USER.$REPO:$Module:$VERSION'Multiple Module一つのレポジトリで複数のmoduleを扱うことがあります。その場合、jitpack.ioにアクセスし、repositoryのURLを貼ってみます。例えば、自作ライブラリでやってみます。github.com        allprojects {        repositories {            ...            maven { url "https://jitpack.io" }        }    }    dependencies {        compile 'com.github.User:Repo:Tag'    }こんな感じで入れればいいよ！と言われるので、そのままやるとコケます。Multiple Moduleなので、以下のように指定が必要になります。compile 'com.github.$USER.$REPO:$Module:$VERSION'これはドキュメント通りhttps://jitpack.io/docs/BUILDING/#multi-module-projectsなのですが、一つドキュメントに記載されていない事項があります。例えば、自分がコントリビュートしている、PermissionsDispatcherの場合github.comcompile 'com.github.shiraji.permissionsdispatcher:permissionsdispatcher:2.1.1'compile 'com.github.shiraji.permissionsdispatcher:permissionsdispatcher-processor:2.1.1'このように指定する必要が出てきます。つまりcompile 'com.github.$USER.$REPO.toLowerCase():$Module:$VERSION'が正しいフォーマットです。SNAPSHOT versionSNAPSHOTバージョンはweb上では一つしか選択できないようなUIです。ドキュメントにもbranch-SNAPSHOTと記載されているので、-SNAPSHOT付きのブランチを作成してもweb上では反映されません。しかし、ブランチが存在していさえすれば利用は可能のようです。例えば、v1.1.1-SNAPSHOTというブランチをリモートに作成してあるとしたら、以下になります。compile 'com.github.$USER.$REPO:$Module:v1.1.1-SNAPSHOT'ドキュメントにも書いてあるけど、webUIには反映されないから気をつけてねってことです。

jitpack.ioではまったところまとめ

この文章は以下に該当する方へ、なぜエンジニアにリファクタリング(リファクタ)させるべきなのかを記載しています。リファクタリングする＝サービスの開発が停止すると考えている方リファクタリングに関して価値を見出せない方エンジニアにリファクタリングさせて欲しいと言われる方最初にリファクタリングの話をする前に、一般的な職場に関する質問があります。あなたの職場は綺麗ですか？あなたが思い浮かべる「できる同僚・上司」の机は整理整頓されていますか？全ての人に当てはまるわけではないと思います。しかし大抵の方は両方回答がYesになると思います。職場を綺麗にするのはそこで働く人の健康維持やモチベーション向上に役立ちます。職場を綺麗にしてくれる専門のスタッフがいる企業もあるのではないでしょうか？また整理整頓された机で仕事することにより、ムダを省略することが出来ます。仕事をするスペースが増えることにより効率もあがります。大抵の出来る人は机を整理整頓している傾向があるそうです。著名な会社の研修でも同じようなことを説いていました。汚い環境で働くということは、モチベーションを下げ、ムダな作業を発生させ、効率を下げるということです。汚い環境で働くのは非常に辛く、可能であれば、人はその環境から離れていきます。リファクタリングとは何か？さて、本題のリファクタリングについてです。wikipediaでは以下のように説明されています。リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。*1もう少しサービス開発に絡めて切り込んだ説明にすると、「リファクタリングするということは、サービスの機能の追加や削除は一切行わず、コストをかけて、今まで動いていたコードに対して修正を加える作業です。」リファクタリングをすることにより、バグを埋め込んでサービスを止めてしまう可能性も含まれることになります。もちろんそれを避ける術はいくつかあるのですが、手段はエンジニアが考えればいいのでここでは省略させていただきます。リファクタリングをなぜやるのか？なぜこんなムダな作業を行うのでしょうか？エンジニアはアホなんでしょうか？エンジニアはコード上で仕事をしている（実際、アホなことやる人は多いですが・・・）事自分たちが行っているサービス開発に関して言えば、プライドを持って行っているはずです。サービスに携わっている以上、そのサービスがより良くなることを望んで開発しています。そのエンジニアがコストがかかることを承知で、リファクタリングさせて欲しいという理由があります。それはエンジニアはコード上で仕事をしているということです。デスクの綺麗さとコードの綺麗さ私が非エンジニアにリファクタリングの重要性を説明する時は以下のように説明します。デスクに毎日のようにいろんな人が資料を置いていくとします。資料を置くことを目的にする社員もいるので、資料はあなたが意図した場所には置かれません。デスクがどんどん汚くなっていき、必要な資料を探すのに苦労します。間違った資料を使って仕事をする可能性も出てきます。このような状況になった場合、あなたがまず最初に行うのが、整理整頓だと思います。ではエンジニアはコード上で仕事をしているということなので、デスクを「コード」、置かれていく資料を「追加機能」と読み替えてみます。コードに毎日のようにいろんな人が機能を追加していきます。機能追加を目的にする社員もいるので、エンジニアが意図した場所に機能が追加されません。コードがどんどん汚くなっていき、必要な機能を調査するのに苦労します。間違った機能を使って仕事をする可能性も出てきます。(=バグを作り出す)このような状況になった場合、エンジニアがまず最初に行うのが、整理整頓(=リファクタリング)だと思います。エンジニアが作業しているコードを綺麗にすることにより、将来的にバグを作り出さなかったり、効率良く作業が出来る環境を作ることが出来ます。エンジニアを惹きつける、引き止めるためのリファクタリング汚い環境で働くということは、モチベーションを下げ、ムダな作業を発生させ、効率を下げるということです。汚い環境で働くのは非常に辛く、可能であれば、人はその環境から離れていきます。この文章も同じように読み替えることが出来ます。汚いコード上で働くということは、モチベーションを下げ、ムダな作業を発生させ、効率を下げるということです。汚いコード上で働くのは非常に辛く、可能であれば、エンジニアはそのコード（会社）から離れていきます。エンジニアが働く場所の環境を良くすることとそのエンジニアを魅了するためにリファクタリングをさせる猶予を与えてあげてください。この魅力的な余裕があることでエンジニアとしてやる気が向上し、整理されたコードで仕事が出来るためパフォーマンスが上がります。働きやすい職場(コード)で最高のパフォーマンスを出すことが出来るのであれば、エンジニアが離職するのを引き止めるのに役立つはずです。まとめ汚い場所で人を働かせることが辛いということがわかるのであるなら、ぜひ汚い環境で働かされているエンジニアに掃除をする猶予を与えてあげてください。それが長期的に見るとサービスを改善を早くし、技術力のあるエンジニアを定着させ、変化に柔軟なサービスを提供させることが出来るようになるからです。*1:"リファクタリング (プログラミング)". wikipedia. https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

リファクタリングについて伝えたいこと。

はじめてはてなブログを使ってみようと思います。普段技術ネタをQiitaにあげているのですが、技術ネタではないものを書くためにこのブログを開設しました。shirajiともうします。Qiitaもshirajiというアカウントで記載しておりますので、そちらも確認してください。思ったものを記載していくつもりです。更新ペースはそこまで高くないです。よろしくお願いいたします。

自己紹介

Objective-cやらJavaやらRailsやらPlay frameworkやら手を出しまくっているせいか書くネタがない。。。ということで、本題。Eclipseの設定をするという非常にだるいことになったので、一旦、何を毎回しているかメモ書き。あくまで自分の環境なので、設定して壊われても責任持ちません。vimのvundleみたいにファイル一つでやってくれたらいいのに。）1. インストールAndroid開発ならADT）http://mergedoc.sourceforge.jp/2. 英語化http://d.hatena.ne.jp/shiraji/20130427/13670544263. プラグインGlance（ctrl-jの上位互換）URL: http://code.google.com/p/eclipse-glance/Update Site: http://eclipse-glance.googlecode.com/svn/site/キーバインド設定は下に記載。Eclipse Color Theme (Editorの色変更)URL: http://eclipsecolorthemes.org/Update Site: http://eclipse-color-theme.github.io/update/設定方法テーマを選ぶWindow > Preference > General > Appearance > Color Themeで選ぶ（いつもWombat）カーソルがある行のハイライトがうざいので消すWindow > Preference > General > Appearance > Text Editor > Highlight current lineのチェックを外すついでに行番号を表示するWindow > Preference > General > Appearance > Text Editor > Show line numbersのチェックを入れるWombat好きなんだけど、field名とクラス名の色が同じなので、かえる。Window > Preference > Java > Editor > Syntax Coloring > Java > Fieldsを選択。色を変える。（色はだいたいいつも左から6番目、上から3番目）Eclipse Theme (Editor以外のテーマ変更、4.2 - Juno以上だった場合)URL: https://github.com/jeeeyul/eclipse-themesUpdate Site: https://raw.github.com/jeeeyul/eclipse-themes/master/net.jeeeyul.eclipse.themes.updatesite設定方法テーマを選ぶWindow > Preference > General > AppearanceでJeeeyul's theme - Chrome Themeを選び、再起動するパディング(Shadow？)を消すWindow > Preference > General > Appearance > Chrome Theme > General > Sash WidthでThin Sashを選ぶさらに画面大きくWindow > Preference > General > Appearance > Chrome Theme > Part > Part Statck ShapeのPart Paddingを0pxにする各パネルの色がいやWindow > Preference > General > Appearance > Chrome Themeで、右にあるパレット？の横の下三角形から > Editor's Presets > Chrome ClassicメモEclipse Dark Junoというものもあるけど、ところどころ白くて嫌。全部まとめて変えられればいいのに。 4. 補完Javaの補完の機能をもっと便利にWindow > Preference > Java > Editor > Contents AssistEnable auto activationをチェックAuto activation delay(ms): 80Auto activation triggers for Java: .abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_いらない補完候補を消すWindow > Preference > Java > Editor > Contents Assist > AdvancedJavaの開発ならJava Proposalsだけあれば十分 5. UTF-8化エンコーディングをUTF-8にする。てかこれなんでデフォルトじゃないのだろう？Window > Preference > General > Workspace > Text file encodingをUTF-8 6. キーバインド Preferences > General > KeysGlanceのため、Incremental FindとIncremental Find ReverseをアンバインドGlanceのキーバインドName:「Open Glance」Windows」Name:「Next Match」上のキーバインドをコピーし、Name:「Previous Match」クリーンName:「Clean」Windows」ツールバー出したり消したりName：「Toggle Toolbar」Windows」 7. スプラッシュ画像を変える変えたいsplash.bmpを以下のフォルダに置く（オススメはEclipseたんなんですが、職場ではイメージを壊す恐れがあるので、要注意）eclipse\plugins\org.eclipse.platform_xxADTの場合eclipse\plugins\com.android.ide.eclipse.adt.package_xx 8. ツールバーのカスタマイズEclipse Junoを使っている方（特にADT）この設定はやらないほうがいいです。理由は追記に記載。Window > Customize Perspective... > Tool Bar Visibilityで不必要なものからチェック外す。自分の場合、LaunchとDebug以外全て外す。LaunchとDebugはマウス使うので。右にある各Perspectiveのテキストがうざい右にある各Perspectiveのアイコン右クリック > Show Textからチェック外す 9. コードテンプレート新しくファイル作成するとファイルの1-3行目にコメントが入るのがうざいWindow > Preference > Java > Code Style > Code Templates > Comments > Files > Edit > 空にするOverrideしたメソッドのコメントが意味不明Window > Preference > Java > Code Style > Code Templates > Comments > Overriding methods > Editに以下を記載/**新しいメソッドのテンプレートがうざいWindow > Preference > Java > Code Style > Code Templates > Code > Method body > Editで以下を記載throw new UnsupportedOperationException("havn't implemented, yet");新しいファイル作成時、必ずコメントをつけるWindow > Preference > Java > Code Style > Code TemplatesでAutomatically add comments for new methods and typesをチェック（これもデフォルトにしてー） 10. その他検索した結果からファイルへ飛ぶときに新しいタブを開いてほしいWindow > Preference > General > SearchでReuse editors to show matchesを外すフィールド名の前は「m」とかプレフィックスにする。だけど、getter/setterではmはつけない場合。(開発場所により変わる)Window > Preference > Java > Code StyleでFieldsを選択し、Edit > Prefix listにm保存時に何かする（フォーマットとか）Window > Preference > Java > Editor > Save Actions開発場所によりかなり変わるため、なんともいえないが、必ずつけるものは以下Format source codeをチェックFormat edited linesを選択Organize importsをチェックAdditional actionsをチェックし、congifureをクリックCode Organizing > Remove trailing whitespaceをチェックAll linesを選択Missing Code > Add missing Annotationsをチェックし、その下の全てをチェックUnnecessary Code > Remove unused importsとRemove unnecessaray castsをチェックthis.とかのルールもここで設定すると便利。これ設定するようになってから、ctrl+shift+oとctrl+shift+fを押さなくなりつつある。Package Explorerに隠しファイルを表示するPackage Explorerの右側にある三角形 > Filters...をクリック.* resourcesのチェックを外す。 なんかまとめたら大作になた・・・。githubにあげて管理しなきゃ。放置しているレポジトリがあるから、腰をあげてみますか。にしてもこのブログのフォーマットうまくできない。// 追記 ////////////////////////////////////////////////ツールバーの変更についてツールバーにバグが存在しています。ツールバーのアイコンの移動や消したものをもとに戻す機能にバグがあり、動かないと報告もあります。https://bugs.eclipse.org/bugs/show_bug.cgi?id=340695もし、ツールバーからアイコン消したけど、やっぱり必要だったーなどがあった場合、以下のファイルを消すともとに戻ります。eclipse.e4.workbench/workbench.xmiパースペクティブなどのレイアウトをし直す必要があります。扱いには細心の注意を払って下さい。

Eclipseの環境構築をまとめてみた

10月くらいからObjective-cを触っている。windows使っていて、Mac持っていないので、会社でしか触れていなくて。Mac買おうかなー。ということで初歩的なところではまったのでメモ。// 配列nil];for (NSIntger index = -1; index こんな感じで、ループさせてみた。まぁなにゆえ、ループ前にやらないのかとかあるけど、とりあえずそこはおいておいて。Javaにはないunsigned型があるので注意しましょうということでした。