id:radiocat です。年度末（弊社は3月です）が近づいてきました。私の所属するチームにとって2018年度は本格的に スクラム に取り組んだ1年でした。その締めくくりとして大きなイベントに登壇させて頂くことになりました。せっかく頂いた機会なのでしっかり振り返って我々の取り組みをお伝えしたいと思います。ぜひご参加ください。 Scrum Fest Osaka 2019（2/22〜23） www.scrumosaka.org 『あきらめない スクラム 』というタイトルで2/23に登壇予定です。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com 残念ながら採択されなかった Regional Scrum Gathering® Tokyo 2019 向けの発表テーマでしたが、大阪でも新たにScrum Festというイベントが立ち上がると聞いて改めてCfPに応募し採択して頂きました。もともと私たちは大阪拠点の開発チームなので、大阪開催のイベントで大阪のチームの取り組みを紹介できるのは非常に嬉しいことです。 この1年を大きく3段階の取り組みに分けてご紹介します。 はじめる闘い つづける闘い あきらめない闘い これらの闘いの中で「我々は何を学んだのか？」をお話できればと思っています。 当日はチームのメンバーもオーディエンスとして参加します。Scrum Festではセッションの発表を聞くだけでなく、ワークショップやCoffee/Tea Breakなどで参加者同士の交流の時間も設けられていますので、チケットをお持ちのかたはぜひ会場でお声がけください。 RAKUS Meetup Osaka #2 アジャイル Night（2/26） rakus.connpass.com 楽楽精算開発2課のメンバーがそれぞれの立場から スクラム 1年目を語ります。私たちはチームでの スクラム の取り組みをアウトプットするために、半年前からこのイベントに向けて準備してきました。 以下のそれぞれの立場でメンバーが発表する予定です。 主力エンジニアの場合 中途入社エンジニアの場合 若手エンジニアの場合 スクラム マスターの場合 メンバーの入れ替わりなどもあり、私たちはそれぞれの立場で様々な課題に向き合ってきました。それらは開発の現場ではよくあることかもしれませんが、同じ課題を抱えるエンジニアの皆様にお伝えすることで何かの気づきになれば幸いです。 LT枠も募集していますので、それぞれの現場での アジャイル な取り組みを共有しあえればと思います。ご参加お待ちしております。

Y-Kanohです。先日開催された、「フェリー ハッカソン 2019」に他数人のエンジニアと参加してきました。 ハッカソン イベントには初めての参加でしたが、チームにも恵まれて楽しく終えることができました。 眠かった。 イベント概要 詳しくは、参加前に@neroblubrosさんが投稿している記事をご覧ください。 http://tech-blog.rakus.co.jp/entry/20190125/interaction/engineer-learning/hackathon/ 日時：2019年1月25日～27日（二泊三日） 公式Webサイト ： http://ferryhack.code4.osaka/ 簡単に説明すると、「大阪港 - 別府間のフェリーに乗りながら、 ハッカソン を行うイベント」です。 公式Webサイト の「日程」からもわかりますが、 アイディアソン開始が21:30 、 ハッカソン 開始が24:00 という素晴らしいスケジュールです。 テーマ説明時にも不穏なスライドが！ 全体の流れ 一日目 作成するサービスのテーマ説明会 アイディアソン（作成するサービスの案出し） ハッカソン スタート（サービス作成開始） 二日目 別府会場にて ハッカソン / 発表資料作成 三日目 発表会 フェリーについて 今回はフェリーに乗りながらプログラムを書くという、非日常な体験をしてきました。 フェリー内には、運営チームのインフラ部隊が Wi-Fi 環境を整えてくださり、プログラムできる環境が用意されています。 そのため、船内のいたるところに Wi-Fi 機器が取り付けられていました。 ハッカソン について 私のチームでは、 QRコード を読み取ってサーバとやり取りを行うシステムを作成しました。 QRコード 読み取り機器などのハード側のプログラムや、読み取った後に接続するWebアプリケーションの作成、さらには表示する画面のデザインなど、やることは多岐にわたるため、チームメンバの方々と役割分担して進めました。私も微力ながら、読み取った QRコード の情報を判別する API の実装を担当しました。 復路のフェリー内では、アプリケーションの結合を行う傍ら、発表資料を作成し、最終日には発表も担当させていただきました。 惜しくも最優秀賞は逃しましたが、協賛企業の さくらインターネット 様による、「 さくらインターネット 賞」をいただきました。 デモ風景 所感 初めての ハッカソン イベント参加ということもあり、一番印象に残ったことは、 社外エンジニアのスキルを感じられる点 でした。 社内で使われていない技術や、自分が使ったことがない技術でも、社外では一般的なことや、技術に対する温度感を身近に感じることができ、自身の知識の低さや、認識の間違いに気づかされることもありました。 また、チームで作業をする中で、他社の業態や必要とされる技術など、実際の現場でのお話もお聞きできるため、勉強会やカンファレンスより深く知見が広がる印象でした。 参加前から過酷なイベントだと聞いていましたが 、終わってみると、とても楽しく、また得るものも多いイベントだっだと感じました。 フェリーというあまり自由が利かない環境の中で、社外のエンジニアの方と作業することはとても新鮮で、勉強になりました。

はじめに こんにちはMasaKuです。 先日、ブログでも告知させていただきました「フェリー ハッカソン 2019」に参加しました。 tech-blog.rakus.co.jp ハッカソン への参加が初めてだったこともあり、参加前は非常に緊張しました。 しかし、社外のエンジニアの方とチームを組んで開発したり、普段使ったことが無い技術を組み合わせて新しいサービスを考えることができ、総じて貴重な経験ができました。 今回はフェリー ハッカソン 2019に参加してみて「 良かったこと 」と「 悔しかったこと 」について書いていきたいと思います。 はじめに フェリーハッカソンの流れ 作成したWebアプリ フェリーハッカソンに参加して良かったこと 社外のエンジニアの方と一緒に開発する経験ができた 自分のすべきことを全うしようという意識ができた 新たな技術習得に対するモチベーションが向上した 悔しかったこと 時間内に全ての機能が実装できなかった 開発環境をしっかり整えておけばよかった まとめ おまけ 参考サイト フェリー ハッカソン の流れ フェリー ハッカソン は３日間で行う ハッカソン です。 まずは、フェリー ハッカソン の流れについてご説明したいと思います。 ３～４人程度のグループで船や旅に対するイメージを ブレインストーミング 出てきた案を元にして船旅が楽しくなるようなサービスを考える 各サービスを参加者全員で評価 評価が良かったサービスを開発するためのチームを作成 開発開始 発表会 私は「旅先で見つけたお土産を船上で食べるグルメパー ティー 」を提案しましたが、全然刺さっていない様子でした・・・。 作成したWebアプリ 私はその後、ほかの方が考えた「大阪から大分までの移動時間約10時間を最大限暇つぶしできるWebアプリの作成」をテーマにした、乗船客が白組と黒組に分かれて対戦する50×50マスの リバーシ を作成するチームに参加しました。 50×50マスの リバーシ （対戦中盤から1手で変わる石の数が想像以上に多く爽快感があります） 私はサーバサイドを担当し、 PHP を用いてゲームの進行状況を管理する機能の実装を行いました。 ホワイトボードを利用したシステム設計 フェリー ハッカソン に参加して良かったこと フェリー ハッカソン に参加して良かったことはいくつもありましたが、その中でも特に印象に残ったものをご紹介したいと思います。 社外のエンジニアの方と一緒に開発する経験ができた 社内のMeetup やプライベートでエンジニアの方と交流することはありますが、一緒に作業した経験はありませんでした。 そのため、 ハッカソン で同じチームになったメンバーと技術領域が違った場合の作業の進め方についてまったく想像ができず、少し不安な気持ちがありました。 しかし、参加してみると、サーバサイドとフロントエンド、インフラなど、各メンバーが不足点を補いながらチーム全体として最大の効率を発揮できる担当割り振りができました。 技術領域が違っているからこそ、気を掛け合わなければならない点について意識するようになり、各機能の結合時には積極的にコミュニケーションを取りながら作業を進めることができました。 他のメンバーとは異なるユニークなスキルを持っていれば、できることの可能性も広がっていくと思ったので、自分の興味のある内容については 知名度 を気にせず、どんどん挑戦していきたいと思いました。 自分のすべきことを全うしようという意識ができた 自分の担当作業において、他のメンバーが扱ったことがない技術や プログラミング言語 を選択している場合は、メンバーに協力を依頼できない場合があります。 そのため、開発中にトラブルが発生し実装が予定よりも遅れたとしても、自分の力で解決しなければならない状態になる場合があります。 しかし、そういったプレッシャーのかかる状況だからこそ、自分の担当機能がほかのメンバーが開発した機能と結合できた際の達成感は大きかったです。 自分に任された作業をしっかりとやり遂げるために、自分の技術を磨くこととトラブル時の状況説明を明確にすることの大切さを改めて実感することができました。 新たな技術習得に対するモチベーションが向上した 普段の業務で利用している技術については、どのように利用できるかが明確なので、今回作成したWebアプリの開発においても、自分がどのようにチームに貢献できそうかも想像できました。 しかし、外部のエンジニアの方はそれぞれの技術領域での解決方法を知っており、アド バイス を頂いた際に「そういう方法もあるんだ！」といった気づきを得ることもできました。 自分の技術領域を広げていくことで、「自分ならこうして実現するな」であったり「あの技術を組み合わせたらこんなこともできるな」といった発想力を持つことができるようになると思いました。 自分の枠にとらわれず、積極的にいろいろな技術に触れて柔軟な思考ができるようになりたいと思います。 棋譜 をレシートとして出力したメンバーもいました 悔しかったこと 自分としてはうまくできると思っていたところも、かなり苦戦してしまった場面もいくつかありました。 反省点の振り返りも兼ねて2点ご紹介したいと思います。 時間内に全ての機能が実装できなかった 開発開始当初に実装しよう思っていた機能のうち、一部の機能が時間内に実装することができませんでした。 結果的に、ほかのメンバーが開発した機能とうまく連携できなかったものもありました。 Webアプリとして、より面白いものを作りたいという気持ちと、時間内に実現できそうなラインの見極めが重要だと思いました。 開発環境をしっかり整えておけばよかった 普段の業務ではマルチモニターにしたり、その他周辺機器を利用して開発を行っています。 今回、 ハッカソン に参加するにあたって、荷物の関係上あまり多くの周辺機器は持ち込めないと思ったので、特にツール等は持ち込まず、普段あまり使わない タブレットPC に最低限の準備だけをして参加しました。 案の定、小さなモニターと タッチパッド 操作に慣れず、実装中に操作面で足を引っ張られた場面が何度かありました。 開発環境を整えておくことで、開発の効率も変わってくると改めて実感したので、より効率よく作業をするために、今一度業務で利用している開発環境も見直すべきかと思いました。 まとめ ハッカソン 初参加ではありましたが、大変実りのある経験ができたと思います。 今回は３日間という短い期間でのチームでしたが、通常業務でのチーム開発にも通ずる経験ができたと思ったので、今回学んだ内容を反映させていきたいと思います。 開発チームという枠組みで個性を発揮しつつも、チーム開発で最大の効率が出せるようなチームメンバーになっていきたいですね。 おまけ 開発の休憩時間を利用して、別府観光にも行きました。 楽しく開発しつつ観光も楽しめる素敵なイベントになりました。 白池地獄 とり天定食 参考サイト フェリーハッカソン2019 - connpass Facebook 無効なURLです フェリーハッカソン2019のまとめ - Togetter

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュについて、紹介記事を書きました。 なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 iOSアプリ開発でオススメのライブラリ ゼロから始めるPython入門講座に参加してきました 新規メンバーのための「TKG」と「過去問」のススメ おまけ おわりに 発表内容 大阪オフィスのビアバッシュとは異なり、東京のビアバッシュでは今のところ自由なテーマでの発表のみ行っています。 iOS アプリ開発 でオススメのライブラリ 簡単に使えておしゃれなUIが作れる iOS アプリのライブラリに関する紹介です。 ウォークスルー *1 や、読み込み中のアニメーションなどが簡単に実装できるライブラリが紹介されていました。 iOS アプリを利用していて、よく見かけるUIと同じものが紹介されていたので、それらが簡単に実装できるのは iOS アプリ開発 をする上で有用だと思いました。 ゼロから始める Python 入門講座に参加してきました 私、 id:FM_Harmony が Python 勉強会に参加した事について発表しました。 発表内容の紹介が、入門講座に参加した際の個人的な感想になりますが、非エンジニアと思われる方も参加されていたのが印象的でした。 講座内で「 Python はプログラミング入門に適している」というお話もあったのですが、個人的にはそのことが要因なのかと感じています。 新規メンバーのための「TKG」と「過去問」のススメ 若手メンバーがプロダクトについて理解するために取り組んでいることについての発表です。 東京の楽楽精算開発チームでは、若手メンバーの活動として以下の２つを行っているとのことでした。 過去問 過去にリリースした機能を題材とした学習、若手メンバーが既存機能の実装や開発手法を理解することを目的にしている。 定例業務改善グループ （通称 TKG ） 属人的な作業の引継ぎや、作業内容の改善を行っている。 今でも私は思いますが、楽楽精算は機能も多く実装内容の全容を理解することが大変で、実際の開発に入る前に覚えなければいけない知識も多いです。なので、それらへの理解を助ける上記の活動はチームに参加したばかりのメンバーにとってとても有用だと思います。 おまけ ラク スのサークル活動や今度の2/19(火)に行われるRakus Meetup Tokyoの宣伝発表もありました。 Rakus Meetup Tokyoについては、以下のリンクから参加登録可能です。参加枠の倍近く予約があり、増席予定とのことでした。 rakus.connpass.com おわりに 東京オフィスの1月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。大阪側のように、今後は東京の社内イベントも定期的に紹介記事を書いていけたらと思います。 *1 : スワイプしながらアプリの説明をするような画面のこと

はじめに はじまして、新卒1年目エンジニアのyk_itgです。 今回は初めて参加したカンファレンス、 JJUG で知った プログラミング言語 、Kotlinについて調べてみました。 www.java-users.jp はじめに Kotlinとは なにができるの？ 実行してみた FizzBuzz Null安全 nullを許容しない変数と許容する変数 nullチェック まとめ Kotlinとは Kotlin(コトリン) は Java と同じ 静的型付けの オブジェクト指向言語 です。 開発したのは 統合開発環境 IntelliJ IDEAを構築している JetBrains で、 Java をもっと簡潔・安全になるように改良した産業利用向け汎用言語として開発されました。 また、 JVM 上で動作する のでほとんどの環境で実行が可能です。 なにができるの？ 利用用途は幅広く、Webアプリケーションや Android アプリなどの開発をすることができます。 また、2017年に Android の公式言語 になったので、安心して Android アプリの開発に使えます！ 実行してみた Kotlin公式サイトでお手軽に実行できます。 Kotlin Programming Language kotlinlang.org FizzBuzz 試しによくある FizzBuzz を書いてみました。 fun main() { for (i in 1..100) { val ret = fizzBuzz(i) print("$ret,") } } fun fizzBuzz(num: Int): String { return when { (num % 15 == 0) -> "FizzBuzz" (num % 3 == 0) -> "Fizz" (num % 5 == 0) -> "Buzz" else -> num.toString() } } 1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz,16,17… 書き方は元となった Java とは大きく違う ことがわかります。 Null安全 記事のタイトルの通り、KotlinはNull安全な プログラミング言語 です。 Null安全とは、ざっくり言えば NullPointerException が起きない ということです。 ですが、nullが使えないわけではありません。 nullを許容しない変数と許容する変数 Kotlinにはnullの代入を 許容しない変数 と 許容する変数 が存在します。 変えるのは簡単で型宣言の後に「 ? 」を付ければ、nullを許容する変数にすることができます。 fun main() { //nullを許容しない変数 var num1:Int //nullを許容する変数 var num2:Int? num1 = null num2 = null } num1 はnullを 許容しない変数 なのでnullを代入しようとすると コンパイル 時エラー になります。 num1 = null; //コンパイル時エラー num2 はnullを 許容する変数 なのでエラーが出ません。 num2 = null; //エラーにならない nullチェック nullを許容すると NullPointerException が起こってしまいそうですが、そんなことはありません。 nullを許容する変数を参照する場合、 nullチェックをしていないと コンパイル 時エラー になるからです。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 println(sum(num1, num2)) //num2にnullチェックを行っていないのでエラー } fun sum(num1: Int, num2: Int): Int { return num1 + num2 } なので、参照する場合には必ずnullチェックを行わなくてはいけません。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 if (num2 != null){ println(sum(num1, num2)) //これならOK } } このようにKotlinはnullを参照することがない、 nullチェックを コンパイラ が強制する仕組み を持っているNull安全な プログラミング言語 なのです。 まとめ Null安全な プログラミング言語 「Kotlin」についてご紹介してきましたが、いかがでしたでしょうか。 今回紹介した以外にも、 型推論 や Java のソースをKotlinに変換できる といった特徴もあります。 まだまだ特徴はあるので興味を持った方は是非調べてみてください。 参考サイト Kotlin - Wikipedia https://eigoninaritai.com/about_kotlin_of_official_language_on_android/ Kotlinとは――読み方、メリット、「Java」とのコード比較、実行までのチュートリアル (1/3)：Android Studioで始めるKotlin入門（1） - ＠IT Null安全がすごい - 騒音のない世界 BLOG

はじめに 今回は大阪オフィスで開催された1月ビアバッシュをご紹介します。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Chat Dealer 配配メール Mail Dealer 楽楽精算 働くDB 自由発表 Githubでタスク管理 CfP を書く技術 LT発表 コードの好みを知りたい おわりに テーマ発表 業務 カイゼン ジャーニー 新年最初のビアバッシュのテーマは業務 カイゼン ジャーニーでした。 ラク スの各製品の開発者にこんな業務 カイゼン をやったよ、というお話をしていただきました。 また、テーマ発表の後にはテーマ自由の発表やLT発表もあり、ボリュームのあるビアバッシュとなりました。 Chat Dealer リリース作業をAnsible化して 工数 削減が実現できたというお話でした。 Chat Dealerの発表内容 Chat Dealerはリリース頻度が高く、リリース作業が大きなコストになっていたそうです。Ansible化したことで作業手順がどのように変わったのか、どのあたりが楽になったのか、ということをお話いただきました。 お話しいただいた内容で私が開発に携わっている製品でも活用できないかと考えましたが、リリース作業を担当したことがなく実感がないので、まずは大変さを知るためにもリリース作業をやってみることから始めないとな、と思いました。 配配メール チームのタスク管理として最近始められたカンバン運用の振り返りについてのお話でした。 配配メールの発表内容 各メンバーが一日分のタスクを分割して付箋に書いて張り出し、遅れているタスクがないかチーム全員で 見える化 したそうです。 私もタスク管理が大雑把になっているので、個人的にカンバンのように 見える化 して カイゼン できないか試してみます。。。 また、今回の発表が一般的な業務改善の進め方と対比して振り返りを行うという形式でしたので、 カイゼン 活動を進める際の参考例として活用できるかなと個人的に思っています。 Mail Dealer ベトナム で行っているオフショア開発の カイゼン についてお話しいただきました。 品質が低いという課題とその対策の話も興味深かったのですが、特に気になったのは ベトナム メンバーの ヒアリ ングから分かった「日本メンバーが怖い」という課題があったことです。近くでコミュニケーションが取れない分、ミーティングの際は ビデオチャット で顔を映して、とにかく笑顔を意識するなど、細かなことから気を付けて カイゼン したという話が印象的でした。 Mail Dealerの発表内容 私自身も現在2年目ですでに後輩がいますし、来年度にはさらに増えますので、良好なコミュニケーションをとれるよう同じようなことを意識します。。。 楽楽精算 以前に取り組んでいたモブプログラミングを実際に業務プロセスの一部として盛り込んでみた、というお話でした。モブプログラミング自体の取り組みついてはMeetupの記事をご参照ください。 tech-blog.rakus.co.jp 今回は業務に組み込むうえで気を付けたこと、やってみた結果の振り返りをお話いただきました。 楽楽精算の発表内容 モブプログラミングの題材がリファクタだったので、どのようなソースがイケてないかという共通認識の形成に役立ったそうです。私の所属するチームでも、この「イケてない」という感覚を新人にどうすれば共有できるかという話が出たことがあるので、モブプログラミングをしてみるということは選択肢の一つとしてアリだなと感じました。 働くDB 開発規約に準拠したコードを作成し、さらにそれをテンプレートとして新規コードを起こす際に自動生成するツールも作成したというお話でした。 働くDBの発表内容 このチームでは明文化された開発規約が最近できたばかりだったので、規約に準拠したコードがほぼ無く、新しくチームに入った人が混乱してしまうことがあったそうです。 私が新しくチームに参加したらということを考えると、規約に準拠したコードがあればコーディングの細かな部分に悩まずに済みますし、自動生成ツールがあればなおさら楽に進められそうですね。 自由発表 Github でタスク管理 タスクをIssueをとして登録することで、 Github でタスク管理をするという話でした。 他のタスク管理ツールと比較をすると、プルリク エス トなどの開発関連作業含めて1つのアプリケーション内で完結することが利点だそうです。 Github でタスク管理 CfP を書く技術 CfPを書く際に意識したところを、実例を交えて解説していただきました。 ※CfPとはCall for Paperの略称で、カンファレンスのスピーカーとして応募する際に必要なものです。 トーク の内容や必要性などを記載し、主催者はこれを見て トーク を採択するか判断します。 CfPを書く技術 画像内の各色は、赤色が 推し ・オレンジ色が ニーズ ・ピンク色が エモ を意識して作成されたフレーズだそうです。 またこちらの内容については来月開催される Laravel JP Conference 2019 で登壇し発表します。 tech-blog.rakus.co.jp LT発表 コードの好みを知りたい ビアバッシュ参加者の方に対して「どっちのコードが好み？」というアンケート的な発表をしていただきました。今回は4つ事例がありましたが、参加者の好みが分かれるもの、偏るもの様々でした。 コードの好みを知りたい どっちが好み？は答えられますが、なぜ好むのかまでは改めて考えたことがありません。それを自分の中で明確にできると書くコードにも一貫性が出せそうなので、一度考えてみようと思います。 おわりに 1月のビアバッシュをダイジェストでお送りしました。 各チームとも課題を解決すべく様々な カイゼン 活動を行っていました。課題があることは成長できる余地があるということなので、引き続き カイゼン 活動を行っていきます。

ラク スでメールディーラーの開発に携わっている@neroblubrosです。 今回は本日の夕方から始まるフェリー ハッカソン について書きます。 フェリーの中で ハッカソン ！ その名の通りフェリーの中で ハッカソン を行うというもの。なぜフェリーなのか？ってことですが、実はフェリー ハッカソン は今回で2回目の開催です。 第1回目は2017年に開催されました。2017年は大阪港開港150周年の年で、その記念イベントとしてCode 4 Osakaが主催、フェリーを運行している「さんふらわぁ」の協力のもと、 大阪市 や 別府市 が後援し開催されました。 開港イベントだったので一回限りの ハッカソン の予定だったみたいですが、思っていたより好評だったので、第2回目も開催されました。 ラク スが協賛しています 前回のフェリー ハッカソン が好評だったことや、社内で参加希望者が数名いることから、今回は ラク スが協賛企業としてお手伝いをしています。 また私以外で2名参加します。彼らも参加レポートのブログを書く予定ですのでお楽しみに！ 関連サイト 前回のフェリー ハッカソン の様子はこちらをご覧ください。 http://036-yakudachi-info.com/blog/hackathon/ferry-hackathon フェリー ハッカソン サイト http://ferryhack.code4.osaka/ Facebook ページ https://www.facebook.com/events/1167433570099385/ Twitter https://twitter.com/ferry_hack

はじめに こんにちは、MasaKuです。 プライベートの時間を利用して、ニュース記事などで見つけた面白そうな技術を使ってみたり、「こんなのあったら便利かも？」と思ったものを作ったりしています。 そこで、最近流行のゲームである、対戦相手を攻撃して画面外にふっとばすゲームの対戦記録を残せたら便利じゃないかな？と思い、簡単なWebアプリを作ってみました。 「 とりあえず動く 」を目標に作成していたため、使い心地などは一切考慮せずに作っていましたが、そもそも簡単なアプリなので、そこまで工夫できるポイントもないかと思っていました。 しかし、既存アプリの調査をしてみると ちょっとした工夫でユーザの操作を楽にできる ことに気づいたので、自分の反省のためにも記載していきたいと思います。 はじめに アプリ概要 使いづらい点 無駄な送信ボタン キャラクターの選択操作 まとめ 参考サイト アプリ概要 まず、今回作成しようと思ったWebアプリで実現したかったことは以下です。 twitter のOAuthによるユーザ登録とログイン機能 使用キャ ラク ターの利用回数の記録 使用キャ ラク ターの勝率の表示 対戦情報をより詳細に記録できるようにしたかったのですが、ひとまずの目標は対戦回数と勝率が出せたらいいかと思い、このような形になりました。 また、上記程度であれば、実装イメージも湧きやすかったというのもあります。（個人開発のモチベーション維持には実は大事） 作成したWebアプリの画面は以下のようになりました。 トップページ データベースに入力値を登録するだけの簡単なフォームですが、必要な要件はクリアしています。 使いづらい点 上記機能がすべて利用可能な既存アプリと比較して、 今回作成したWebアプリの使いにくい点 について、特に気になったポイントをご紹介したいと思います。 無駄な送信ボタン 私の作成したWebアプリでは、以下の操作が必要です。 使用したキャ ラク ターをプルダウンから選択 勝敗をプルダウンから選択 送信ボタンを押下する 上記のうち必要が無い操作だと気づいたのは「3. 送信ボタンを押下する」です。 通常、送信ボタンを押す前にフォームに必要な情報が全て正しく入力できているかをユーザに確認させる必要かあります。 しかし、今回のWebアプリのような簡単な入力画面では必ずしも確認するフェーズは必要ではないのではないかと思いました。 入力間違いが許されないような画面については、送信前に確認させる意味合いも込めて、送信ボタンを押させる必要があるかと思います。 しかし、今回のような場合は少ない操作で登録できて、後から簡単に修正できるようにするのも良いかと思いました。 つまり、この操作は以下のように修正することができます。 使用したキャ ラク ターをプルダウンから選択 勝敗ボタンを押下 送信ボタンを削除 確認ダイアログが何度も表示される画面などと似たケースにはまっていたのかもしれません。 キャ ラク ターの選択操作 私の作成したWebアプリで使用したキャ ラク ターを選択する場合は、プルダウンから選択する必要があります。 そのため、日本語化されたキャ ラク ター名を探して、該当項目を選択しなければいけません。 しかし、既存アプリの場合は、キャ ラク ターのサムネイルを選択するという方式になっていました。 キャ ラク ターの選択方法 対象ユーザはゲームを遊んでいる人なので、キャ ラク ターの名前と、キャ ラク ターのサムネイルではどちらの方が馴染み深いかは言うまでもありません。 キャ ラク ターの名前を忘れてしまうことがあっても、キャ ラク ターそのものを識別できなくなることはほとんど無いでしょう。 選択肢がある入力フォームではプルダウンが採用されるという固定概念ができてしまっていたと感じました。 まとめ 今回は、以下の二点について勉強になりました。 必要がない操作の削減 探しやすい選択項目の表示方法 Webデザインにおける認知負荷では以下に気をつけなければならないようです。 操作負荷 … マウスやキーボードといった機器の操作 視覚負荷 … 目の前にみえる情報に気を止めたり、気付いたりすること 知覚負荷 … 考えたり、記憶したり、 スキーマ と関連付けさせること 今回の場合は、操作負荷と視覚負荷を高めてしまった形になるかと思いました。 普段の開発業務では、モックや詳細設計書の画面イメージを元に開発を行います。 そのため、使いやすい画面とはどういう作りになっているか、ということについて、あまり意識していませんでした。 開発に携わるものとして、デザイン上の アンチパターン についてはしっかりと認識しておかなければならないと思いました。 参考サイト builder.japan.zdnet.com

id:radiocat です。1月17日に大阪オフィスで初の「もくもく勉強会」を開催しましたので、今回はその模様をご報告します。 rakus.connpass.com 経緯 大阪の開発部門では毎週木曜日にもくもく勉強会を開催しています。以前のエントリーでもその様子を少しご紹介しています。 tech-blog.rakus.co.jp 2018年9月に大阪オフィスが移転して、広い セミ ナールームが確保できたことから、もくもく勉強会を社外向けにも開放してみてはどうかという声が上がるようになりました。そして私の所属する楽楽精算開発2課のメンバー数名と協力して最低限の運営方法などを整備してこのたび開催することになりました。 みんなで楽しむもくもく勉強会 まだ試行錯誤的な取り組みですが、せっかく社外の方にも参加していただくので何らかの接点を持って今後に繋げていただきたい思いがあります。もちろん「もくもく勉強会」と言うからにはエンジニアの自主学習の場であることが第一優先ですが、その中でこの場をさらに少しでも有意義な場にするために何かできることはないかと考えました。 もくもくすることを共有する もくもくすることを共有できる「一言共有ボード」を準備しました。受付が終わると、まずその日にもくもくする事を一言で付箋に書いてホワイトボードに貼って頂きます。そして参加者が揃う19時ごろに付箋を見ながら自己紹介も兼ねた一言共有会を実施しました。 その日やったことを参加者同士で共有し合うことで学習のモチベーションに繋がりますし、お互いが取り組んでいる技術などを知ることでエンジニア同士の交流にも繋がります。なお、付箋の記入と共有は希望者のみ実施していただくことにしていますので、共有しないと参加できないわけではありません。 もくもくのついでに交流もできる 参加者同士の交流は自由に行っていただけます。直接は会話しづらいこともあるかもしれないので、その場での連絡や情報交換を気軽にできるツールとしてSlackのチャンネルも準備しています。もちろんSlackへの参加する／しないも自由です。 また、今回は20時終了としていましたが運営メンバーで振り返りを行った結果、次回は21時を最終退出期限として自由時間を確保することにしました。もくもく勉強した後で交流時間に使っていただくも良し、もう少しキリの良いところまで自習していただくも良し、という予備時間です。もちろん、基本的に入退室は自由ですので都合のつく範囲で参加していただき、いつでも帰宅していただけます。 次回告知 次回は2月14日に開催予定です。既にconnpassに公開していますのでご覧下さい。 rakus.connpass.com まだまだ試行錯誤中ですが、参加していただいた皆様と楽しみながらこの場を育てていきたいと思っています。興味を持たれた方は是非ご参加いただけましたら幸いです。

こんにちわ @kawanamiyuu です。来月開催される Laravel JP Conference 2019 に弊社から 2 名のエンジニアが登壇することになりましたのでお知らせします。また、株式会社 ラク スは BRONZE スポンサーとしてイベントに協賛しています。 イベント概要 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ ハッシュタグ ： #laraveljpcon conference2019.laravel.jp 登壇情報 タイムテーブルは コチラ チャットディーラーの高速開発を支える Laravel レギュラー トーク （14:40 〜 15:10） 発表者：坂田晃平 10年以上 PHP でノン フレームワーク で開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際にLaravelを選択をしました。 開発期間半年というスピードが求められる中で、チームがLaravelに抱いた理想と現実、また、Laravel(Blade)とVue.jsの組み合わせによる 脆弱性 への対応など、Laravelでの新規サービス立ち上げの経験を具体的にお伝えします。 昨年の PHP カンファレンス関西 2018 で発表 した内容の再演です。 電撃：Laravel API クイズ ライトニング トーク 発表者：加納悠史 「Laravel は便利」「Laravel で開発速度が上がる」とは、よく聞くセリフですが、我々はどこまで Laravel を使いこなせているのでしょうか。 Laravel ビギナーがドキュメントを読み漁って掘り当てた、Laravel のニッチな便利機能/便利関数をクイズ形式で紹介します。目指せ！全問正解！！ どんなニッチな機能を掘り当ててくるのか楽しみです！ まとめ 昨年夏の PHPカンファレンス関西 2018 、先月の PHPカンファレンス 2018 に続いて PHP のイベントへの登壇が立て続けに決まって非常に嬉しいです。株式会社 ラク スは今後も PHP コミュニティへのコミットを推し進めていきます。

はじめに id:d_shr です。 MailDealer開発チームでコードレビューを担当しています。 去年の４月からコードレビュー担当になり１年が経とうとしているので、若手(新卒2年目)がコードレビューをやって良かったこと、難しかったことなどを振り返ってみようと思います。 はじめに コードレビューとは コードレビュー担当をしていて良かったこと ① コードを読む力がつく ② レビュワーの観点がつく ③ 指摘が自分に返ってくる ④ 他の人が書くコードが読める ⑤ いろんな機能の仕様、中身を把握できる コードレビュー担当をしていて難しかったこと ① 指摘を出す ② ついでに直して欲しいを指摘で返してはいけない ③ コード規約に載っていない暗黙のルール まとめ 若手のコードレビューはオススメ コードレビュワーが指摘するときに気をつけるべきこと 最後に コードレビューとは 一言で言えば、書いたコードを他の人にレビューしてもらうこと。 主に以下について確認します。 コード 規約違反 がないか？ 保守性の低いコード、冗長なコードになっていないか？ コードミスがないか？ 仕様通りのコードになっているか？ コードレビュー担当をしていて良かったこと ① コードを読む力がつく 元々コードを読むことには自信がありましたが、ここ１年でかなりのコードを見たので、さらに自信がついたかなと思っています。 いろんな人が書くコードを読むので、読む力はかなりつきます。 ② レビュワーの観点がつく コードを書くときに、良いコードを書かなきゃと可読性を意識しますよね。 コードレビューをするようになってから実装をするときに、「このコードを自分がレビューするとしたら…」という視点が持てている実感あり、良いコードが書きやすくなっている自覚があります。 レビュワーとして指摘しているようなミスはできないし、書いた段階で気づけるので、効率よくコードが書けるようになった気がします。 ③ 指摘が自分に返ってくる ②と繋がる話ですが、指摘した内容が自分に刺さることは少なくありません。 「偉そうに指摘したけど、人のこと言えないなぁ…自分がコード書くときは気をつけないと。」 みたいな感じです。 このようなことも含めて自分の成長に繋がっています。 ④ 他の人が書くコードが読める 他の人のコードを読むことはすごく参考になります。 自分よりもエンジニア歴が長い人たちのコードが読めるので、「こういう書き方もあるんだ」と参考になることが多いです。 ⑤ いろんな機能の仕様、中身を把握できる コードレビューを行うためには最低限仕様を把握している必要があります。 開発中の機能の3〜4割程度のコードレビューを担当していますが、その分だけ仕様を把握することができています。 開発中によくわからないエラーに直面したときはいろんな機能を把握できているおかげで解決が早い事が多いです。 コードレビュー担当をしていて難しかったこと ① 指摘を出す ベトナム の開発メンバーが書いたコードをレビューすることがほとんどです。 顔を合わせて話ができない、日本語で説明できない相手に指摘をすることになります。 指摘を返すときに、理由を明確にして相手が納得できるような指摘を返すことを心がけていますが、言語の壁があったり、指摘したことに実は意図があったりと最初は難しかったです。 ② ついでに直して欲しいを指摘で返してはいけない 修正したことに関連して既存でイケてないコードがあると、ついでに直して欲しいと思うことがあります。 修正すべきなので良かれと思って指摘として伝えると、コードを書く人は不満を持ってしまうことがありました。 指摘ではないけど修正してほしいという意図をしっかり伝えて、コードを書く人に不満を持たせないように心がけています。 ③ コード規約に載っていない暗黙のルール コード規約や正しく書いていることを確認するチェックリストなどのドキュメントはありますが どこにも書かれていないけど、こういうコードは良くないみたいな観点はあると思います。 「こういう書き方はしてほしくない」、「この場合はこういう書き方をしてほしい」、「この関数はこういう使い方をしてほしい」…etc そういったことを明確なルールにしていくことが難しいと思いました。 ルールになっていなかったものや、指摘が多かったことをまとめたドキュメントを作成してメンバーに展開しました。 まとめ 若手のコードレビューはオススメ コードを読む力、読むことで参考になること、コードを書くときに活かせるなど メリットがたくさんあり、成長に繋がることが多かったと思います。 出した指摘から自分の意識と高めることができたり、レビュワーの視点が身についたり良かったことが多かったです。 コードが読めて、ある程度実装ができるなら、どんどんコードレビューを積むことは良いことではないかと思いました。 コードレビュワーが指摘するときに気をつけるべきこと 難しいと思ったことから簡単にまとめると… 問題を明確にする 理由を明確にする 修正方法を明確にする どういう観点なのか？ 参照すべきドキュメントがあるなら記載する 指摘ではなくついでに直して欲しいことは明確に 怪しいコードを見つけたら書いたコードの意図を聞いてみる 最後に 今後もコードレビュー担当を通して、成長できればと思っています。 品質向上にも貢献できるようにコードレビュー担当の観点でできることをやっていきたいと思います。

kuwa_38です。先日 SQLite を使った Android アプリを作成していたのですが、表示データが多くなると画面外に表示されるため対策が必要だなと考えていました。 この記事では ScrollView を使って特定領域内をスクロール可能にする方法をご紹介します。 今回作成するアプリと過去の記事 ScrollViewを導入して特定領域内をスクロール可能にする （注意１）画面のレイアウトが崩れる 注意１の解決方法 （注意２）複数要素を指定したい場合 注意２の解決方法 おわりに 今回作成するアプリと過去の記事 今回 ScrollView によりスクロールを導入するアプリを紹介します。簡単に言うと SQLite を用いてDB内のデータを表示するアプリです。今回はそのアプリで表示するViewにスクロール機能をつけることがゴールです。 qiita.com scroll ScrollViewを導入して特定領域内をスクロール可能にする 画面レイアウト用の xml において、スクロールをさせたい範囲を ScrollView で囲むと、その範囲をスクロールさせることができます。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : id = "@+id/scrollView" > <!-- スクロールさせたいTextView --> <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> </ScrollView> （注意１）画面のレイアウトが崩れる 「 ScrollView で要素を囲む」。これだけでいいのですが、注意点があります。１つは画面のレイアウトが崩れることがあることです。文字入力しようとするとキーボードが出てきた際にレイアウトが崩れてしまいます。 レイアウト崩れ 注意１の解決方法 ScrollView に android:isScrollContainer="false" を追加することで解決できます。下記のサイトによると isScrollContainer は IME が表示されたときにスペースを空けるためにViewをリサイズするかどうかを指定するものだそうです。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <!-- スクロールさせたいTextView --> <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> </ScrollView> retrocatsoft.blogspot.com （注意２）複数要素を指定したい場合 2つ目は ScrollView は１つの要素しか指定できないことです。 実際、下記のように要素を追加すると、エラーが発生します。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> <TextView android : id = "@+id/textView2" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "２つ目のTextView" /> </ScrollView> # consoleのエラー ...（略） ...ScrollView can host only one direct child 注意２の解決方法 LinearLayout で指定したい要素を囲み ScrollView で指定する要素を LinearLayout の要素1つとすることで解決できます。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <LinearLayout android : id = "@+id/LinearLayout" android : orientation = "vertical" android : layout_height = "fill_parent" android : layout_width = "fill_parent" > <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> <TextView android : id = "@+id/textView2" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "２つ目のTextView" /> </LinearLayout> </ScrollView> 複数要素のスクロール おわりに 今回は ScrollView を使って特定領域をスクロールさせる方法をご紹介しました。最初は ScrollView で囲むだけなので簡単だと思っていましたが、レイアウト崩れや要素の制限などやってみると思いの他詰まり奥が深い（というか自分が知らないことが多い）なという印象です。 今後も Android アプリ開発 は続けるつもりなのでこういった記事を書いていこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに エンジニアは勉強しなければいけないのか？ 「知識を吸収すること」の大切さ 運営として 執筆者として 来年に向けて おわりに はじめに こんにちは、 @rs_tukki です。メリークリスマス！ というわけで、この記事は ラク ス Advent Calendar 2018の最終日の記事です。 qiita.com エンジニアとして働き始めて2年も経っていない私ですが、実は去年の10月からエンジニアブログの運営という大任を仰せつかっています。 最後の記事では、1年以上もの間このブログに中核から携わって気づいた「エンジニアが学び続けることの大切さ」について記事にしたいと思います。 エンジニアは勉強しなければいけないのか？ エンジニアという仕事をするにあたって、よく聞く言葉があります。 「エンジニアは、常に学び続ける必要がある」 正直、去年の今頃は、あまりこの言葉を信じてはいませんでした。 自分から社外の勉強会やカンファレンスに行くこともありませんでしたし、ブログの記事も最初にひとつ書いて終わりでした。「別に勉強なんかしなくても何とかなるんじゃない？」と心のどこかで感じていた気がします。 「知識を吸収すること」の大切さ ですが、今年1年、ブログの運営、あるいは執筆を続けていくうちに、社内に閉じたままではなく、社外に出て知識を得ることの大切さをひしひしと感じるようになりました。 運営として ブログの運営は、寄稿してもらった記事のチェック、投稿、アクセス数の集計などが主な仕事です。 この一年、 ラク スのエンジニアの方々の記事を見てきましたが、皆さん本当に様々な知識を持っているな、と実感しています。 Google Homeがブログの記事タイトルを読み上げるアプリを作って公開した話 - RAKUS Developers Blog | ラクス エンジニアブログ 「openSUSE」で始める初めてのLinuxデスクトップ - RAKUS Developers Blog | ラクス エンジニアブログ 新人がDockerを学習すべき4つの理由 - RAKUS Developers Blog | ラクス エンジニアブログ Android Studioで天気情報を表示するアプリを作ってみた - RAKUS Developers Blog | ラクス エンジニアブログ 5分で理解する！Google Apps Script超入門 - RAKUS Developers Blog | ラクス エンジニアブログ Dockerのコンテナ間通信~アプリとDBを繋ぐ~ - RAKUS Developers Blog | ラクス エンジニアブログ 業務に関係することだけでなく、新しい知識を積極的に取り入れている方が非常に多いです。 そしてどの方もそれを1回で終わらせず、習慣にしていることが素晴らしいと思います。Advent Calendarは募集したそばからどんどん埋まっていきました(自分は囲い込まれた側)し、社内チャットの技術チャンネルは毎日様々な話題で盛り上がっています。 そういった「勉強を推奨する風土」が、 ラク スの成長の一端なのではないかと感じています。 執筆者として 運営としてエンジニアブログに携わるだけではなく、私自身も記事を書く機会が結構あり、(この記事を除いて)全部で7本の記事を書かせていただきました。 新卒1年目が新卒0年目に贈る、5+1冊の「エンジニア虎の巻」 - RAKUS Developers Blog | ラクス エンジニアブログ Node.jsの勉強会でお手軽にWebアプリを作った話 - RAKUS Developers Blog | ラクス エンジニアブログ 自由度抜群！コスト削減！「ハイブリッドアプリ」の仕組みと「Monaca」で作るスマホアプリ - RAKUS Developers Blog | ラクス エンジニアブログ VagrantとDockerで「環境に縛られない」開発環境を構築しよう - RAKUS Developers Blog | ラクス エンジニアブログ 【新卒向け】説明力向上の虎の巻！？『Lightning Talks』のススメ - RAKUS Developers Blog | ラクス エンジニアブログ 振り返りの手法を理解しよう～KPT法編～ - RAKUS Developers Blog | ラクス エンジニアブログ 30歳以下限定の技術カンファレンス「Developers Boost」に参加してきました - RAKUS Developers Blog | ラクス エンジニアブログ 実は、このうち5本の記事が勉強会、あるいはカンファレンスで学んだ知識をもとに書いた記事です。 最初のころは、ただ何となく誘われたからとか、ブログの記事のネタになりそうだからとかで参加していた勉強会ですが、だんだんと知識をつけること自体が楽しくなってきて、最終的に1年間で 30以上 の勉強会に参加しました。 そして、そういった勉強会で身に着けた知識は、関係ないことに見えても業務で役立つことがあります。 先輩たちが話している内容が少しずつ分かるようになってきましたし、考える時間が増えたことで開発やテストも以前よりスムーズにできるようになりました。 また、自分と同年代のエンジニアがバリバリ活躍しているのを見て刺激になった、ということも多少なりあった気がしています。 来年に向けて というわけで、今ならはっきりと主張できます。 「エンジニアは、常に学び続ける必要がある」 そして来年は、ただ学ぶだけではなく、それを伝える機会を更に増やしていきたいです。 既に先輩方の中にはカンファレンスで登壇した方もいまして、登壇への憧れが日々増している今日この頃。 この前登壇してた人にまたもインタビューしてみた - RAKUS Developers Blog | ラクス エンジニアブログ PHP カンファレンス 2018 でライトニングトーク登壇してきました - RAKUS Developers Blog | ラクス エンジニアブログ このブログで記事を書いたり、勉強会で登壇したりといった 「学んだ知識をアウトプットする場」 を増やして、周りのエンジニアにも学ぶことの大切さ、楽しさを伝えていければいいなと思っています！ おわりに 今年一年、 ラク スのエンジニアブログを閲覧していただきありがとうございました。 来年以降は新卒のエンジニアを交えて、更に 「学び続けて」 いきたいと思いますので、どうぞよろしくお願いいたします！

こんにちは、 @kawanamiyuu です。先日東京で開催された PHP カンファレンス 2018 でライトニング トーク に登壇してきました。 PHP カンファレンスには毎年プライベートで参加していましたが、今回は登壇するということで会社に交通費を出してもらって参加することができました。会場近くのホテルに前泊できたので当日は朝ゆっくり寝れてありがたかったです。 イベント概要 日時 : 2018 年 12 月 15 日 (土) 会場 : 大田区産業プラザ PiO 公式 HP : http://phpcon.php.gr.jp/2018/ phpcon.php.gr.jp 登壇内容 今年の夏に開催された PHP カンファレンス関西 2018 への登壇 を業務として推進した取り組みの、その背景や具体的な施策について発表しました。 speakerdeck.com www.youtube.com 所感 発表内容としてはレギュラー トーク でも十分な話せそうなボリュームだったため、少し駆け足な発表になってしまいましたが、動画を見返したところ案外ちゃんとしゃべれていて安心しました笑。ネタによりけりですが、次回はレギュラー トーク にも挑戦してみたいと思いました。 発表の中でもお話しましたが、今年は PHP カンファレンスをはじめとしていろいろ登壇や協賛に向けての提案や取り組みを行うことができました。開発組織としても個人としても大きな一歩はもう踏み出すことができたので、来年、さらに取り組みを活発化して周囲を巻き込んで進めていきたいと思っています。

はじめに こんにちは、 id:FM_Harmony です。前回は PostgreSQL のターミナルコマンドである psql について、記事を作成しました。 tech-blog.rakus.co.jp さて、先日12/15（土）に日本 Java ユーザグループ（以下 JJUG ）が開催するカンファレンスである「 JJUG CCC 2018 Fall 」が開催されました。 http://www.java-users.jp/ccc2018fall/#/ www.java-users.jp 休日を利用して参加してきましたので、今回は私が参加したセッションについて簡単に書いてみました。参加されなかった方にも会場の雰囲気など伝わりましたら嬉しいです。 はじめに 各カンファレンスの感想 Pivotal認定講師によるSpring Framework 5.1ハンズオン！ IBM CloudとKubernetesでSpring Bootのマイクロサービスを簡単に！ 今こそStream API入門 Migration Guide from Java 8 to Java 11 オイラ大地の18年拡張し続けているECサイトをSpring Bootとk8s on Azureでマイクロサービス化する事例 Scala とマイクロサービスでつくる証券会社とスタートアップ おわりに おまけ 参考資料 各カンファレンスの感想 Pivotal認定講師による Spring Framework 5.1ハンズオン！ コードを書きながらSpring Framework5.1の機能を学んでいくというセッションでした。 事前に準備を行っていなかったため当日は準備作業から始めていたのですが、会場の回線に問題があったのか必要なソフトのDL等に時間がかかってしまいました。チューターの方に助けていただき何とか環境構築はできたのですが、そこまでで時間が終わってしまったのが残念です... その後、空いた時間でハンズオンを進めていたのですが、 xml ではなく Java のコード上で アノテーション を利用してアプリケーションの設定を行えるところがSpringの特徴なのかなと感じました。コードベースで設定が行えるため、 JUnit を使って正しい設定ができているか確認できるようになっていたのが興味深かったです。まだ、全項目完了していないので、今年中には全部終わらせたいと思います。 IBM Cloudと Kubernetes でSpring Bootのマイクロサービスを簡単に！ タイトル通り、 IBM Cloud上の Kubernetes へSpring Bootで作成したアプリケーションのデプロイやデータベースの構築を行う方法についてのセッションでした。 IBM ライト・アカウントを作成してFree プランの Kubernetes を使うことで、無料で使える環境を用意することができるということでした。アプリケーションのデプロイ等もコンテナ化しておけばコマンドを叩くだけで処理を行えるようなので、難易度自体は高くないのかなと思いました。個人的に AWS を利用していますが、 Kubernetes やDockerに対する理解を深めるのであれば、 IBM クラウド の無料で利用できる範囲で学習するのもアリかと思いました。 今こそStream API 入門 個人的に、今回参加した中では一番面白いと感じたセッションです。 セッションのポイントは、 Stream API は複数のデータに対して繰り返し行う処理を簡潔に記述できる 中間処理と終端処理に分けて考えると分かりやすい 慣れないうちはfor文で記述してからStream API に置き換えると理解しやすい という点かと思います。 何となく今までStream API に対して取っ付きにくさを感じていたのですが、セッションを聞いた結果「分かった」気になれました。機会があれば、実務でも使ってみたいと思います。 Migration Guide from Java 8 to Java 11 Java8からJava11への移行する際の注意点に関するセッションでした。 アプリケーションで利用している Java のアップデートに携わる機会があったので、参加してみました。が、正直なところセッション内で登場する単語は初耳なものが多く、いま私が持つ知識では内容を吸収しきれなかったと感じました。 セッション内で印象に残ったのは、「 findbugs などコミュニティが終了してJava11に対応できないものがある」という点と「Java11では原則リフレクションが禁止になった」という点です。前者については、業務で使う機会もあるためJava11アップデート時にポイントになるかと感じています。後者については、携わっているアプリケーション内でリフレクションを利用している箇所があったはずなので、将来的にJava11に移行する際に苦労するのではないかと感じました。 オイラ大地の18年拡張し続けている ECサイト をSpring Bootと k8s on Azureでマイクロサービス化する事例 品質維持やリリースサイクルの高速化、スケーラビリティのために自社サービスのマイクロサービス化を行っているという内容のセッションでした。 一度にすべてのサービスを移行させることはできないので、段階的にサービスを移行する 自社 クラウド と クラウド サービスと複数の クラウド を利用した構成にした モノリシックな部分に依存しない範囲については、DBを徐々に分割していく という点をポイントに挙げていました。 また、ログ検索を目的とした新規サービスの作成や バッチ処理 、利用者が閲覧するのみのマスタ関連の処理は外に出しやすいため、マイクロサービス化の第一歩として行ったというお話もありました。 Scala とマイクロサービスでつくる証券会社とスタートアップ 金融商品 を取り扱うサービスで Scala を利用していることと、マイクロサービス化する理由等に関するセッションでした。 Scala に関しては疎いのですが、 Scala が持つ型宣言機能によって Java よりもコードに意味を持たせることができるという点が印象に残りました。型宣言により コンパイル 前にエラーを検知しやすいというお話もされていました。 また、マイクロサービス化については、サービスを分けることによって障害の影響範囲を小さくすることができる他にも、開発チームをサービスごとに分けることで対象の業務について知識を深めやすくなるという点が印象的でした。 おわりに いかがでしたでしょうか。 Java のカンファレンスといいつつ、マイクロサービスに関するセッションにばかり参加してしまいました。ただ、個人的な感想ではありますが、マイクロサービスに関するセッションが多かったことからも「やはり今のトレンドはマイクロサービスなのだ」と改めて感じました。 また個人的な意見ですが、マイクロサービス化の事例などで課題や目的として挙がっていた事項は、楽楽精算とも重なる点があるように感じました。 将来的に今回のセッションで得た知識を使うことがあるかもしれないので、時間のある時に改めてセッションの内容と関連する知識を自分の中でまとめておきたいと思います。 おまけ 懇親会で出されたお寿司が美味しかったです。 参考資料 JJUG CCC Fall 2018 資料まとめ - Qiita 執筆時↑に上がっていなかったもの Pivotal認定講師によるSpring Framework 5.1 & Spring Boot 2.1ハンズオン！ #jjug_ccc Migration Guide from Java 8 to Java 11 #jjug オイラ大地の18年拡張し続けているECサイトをSpring Bootとk8s on Azureでマイクロサービス化する事例 Scala と Microservices でつくる 証券会社とスタートアップ / FOLIO in JJUG CCC 2018 Fall - Speaker Deck

はじめに 印象に残ったセッション U30エンジニアとしての技術的投資戦略 Androidからサーバーサイドまで！プログラミング言語 Kotlinの魅力 ID連携を用いたサービス間連携とQR決済サービスPayPay 大規模プロジェクトの制作裏話〜改善から成し遂げるまでのプロセス〜 課外活動で勉強会を主催していたら会社の事業になった話 おわりに はじめに こんにちは、 @rs_tukki です。 先日、30歳以下エンジニアのための技術カンファレンス「Developers Boost」に参加してきました。 event.shoeisha.jp 登壇者も参加者もU30限定という中で、業務改善を行った話、最新技術の紹介をする話、エンジニアとしての生き方を考える話など興味深いセッションが多く、あまり知識のない私でも最後まで楽しむことが出来ました。(そういう人を狙ったセッションが多かったのかも…？) というわけで、今回は参加報告も兼ねて印象に残ったセッションを簡単にまとめていこうと思います。 印象に残ったセッション U30エンジニアとしての技術的投資戦略 ペッパーのプログラムを組み人間との 漫才コンビ で M-1 に出場したという異色の経歴を持つ安野 貴博さんのセッションです。 30歳以下の若手エンジニアとして、私たちにはどのような武器があるのか、そしてどのように生きていくべきか、という最初からとても考えさせられるセッションでした。 若手エンジニアの武器は2つ。 リスクを取りやすい 時間的リソースを投入しやすい そのため、成長している領域に対して勉強を重ね、勝負していける。失敗してもやり直しがきく。 そして、その「成長している領域」が何かを知るために、未来を予測し、備え、出てきた選択肢を 定量 比較した上でベットしていく… エンジニアは常に勉強しなければ生き残れないとはよく言いますが、ただ闇雲に進むのではなく、どんな未来に賭けるかを意識しよう、という話自体が非常に勉強になりました。 Android からサーバーサイドまで！ プログラミング言語 Kotlinの魅力 日本Kotlinユーザグループの代表を務められている、 長澤 太郎さん のセッションです。 こちらは、スライドが公開されていました。 speakerdeck.com Android の開発の現場でKotlinという言語はよく聞きますが、発表が2011年、安定版は2016年のリリースということで、想像以上に最近出てきたばかりの言語なんだと実感しました。 Java と同じ静的型付け オブジェクト指向言語 で、 Java との相互運用性がありながら、 Java より記述が容易だったり、 演算子 を オーバーロード 出来たりと、かなり便利に扱えるなと感じました。(感覚的には C# に近いかも？ とも思いました) あとWebアプリケーションにも使えるのがちょっと意外でした。 ID連携を用いたサービス間連携と QR 決済サービスPayPay こちらもスライド公開済み。 ヤフーの本間 洋光さんによる、今話題のPayPayの仕組みに関するセッションです。 ID連携を用いたサービス間連携と QR決済サービスPayPay #devBoostA from Yahoo!デベロッパーネットワーク www.slideshare.net 丁度他の勉強会でOAuthについて学ぶ機会があったのですが、その時はまだ完全に理解しきれていないところがありました。 今回のセッションではPayPayのシステムを例に、(OAuthを拡張した)OpenIDConnectという仕様を使った連携フローについて説明 いただいたので、より理解が進んだ気がします。 ちなみにヤフーには連携のためのIDに関わる開発専門の部隊が存在するそうです。流石... 大規模プロジェクトの制作裏話〜改善から成し遂げるまでのプロセス〜 ディライトワークス株式会社の畠山 彰秀さんのセッションです。 大規模な開発プロジェクトの中で、他の人のサポートという「見えないタスク」への対処でスケジュールが押されないよう、画面仕様や導入資料などの様々なドキュメントを作成していった、という話でした。 弊社でも私たち若手メンバーを交えて既存の資料を改善していく努力はしていますが、 「大事なのは誰かを待つのではなく、まずやってみること」 という言葉が胸に刺さりました。 今後新たなメンバーが アサイ ンしてきたときにドキュメントが整備されているか否以下の差は大きいので、気づいたらやる、という点は徹底していきたいです。 課外活動で勉強会を主催していたら会社の事業になった話 IoTLT という勉強会の主催である 菅原 のびすけ さんのセッションです。 主催していた勉強会のモチベーションが下がっていたところに社長を呼んでみたら、とんとん拍子で事業化まで事が運んでしまった… という話でしたが、何より 「モチベーションがなくても続ければ価値になる」 という言葉が響きました。 ひたすらアウトプットを続けていくことで、いずれそれに価値を見出せることができるということで、来年からは積極的にブログなどの技術発信を続けていこうと感じました。 おわりに 通常のカンファレンスや勉強会では、登壇者も年上の方が多いのですが、今回はU30という関係上、非常に近い立場の方の話を聴くことが出来ました。(私と同い年で登壇されている方も！) 社内に限らず、こういった社外での勉強会や交流の場で学べることはとても多いので、皆さんもぜひ参加してみてはいかがでしょうか？ #devboost 懇親会も含め、Developers Boostすべて終了しました！ ご来場いただいた皆さま、ありがとうございました！！！ pic.twitter.com/navawUkBjZ — Developers Boost（デブスト）12/11オンライン開催｜参加登録の受付開始！ (@developersboost) 2018年12月15日

id:radiocat です。今回はモブプログラミング Advent Calendar 2018の12日目の記事として投稿させて頂きます。久々の スクラム 事例です。 qiita.com 私達のチームでは スクラム 開発の中で毎週モブプログラミング（以下モブプロ）をする時間を設けています。その名も「ボーナスステージ・モブプロ」です。 実践に至る経緯 まずは現在のモブプロのスタイルを実践するに至った経緯をご紹介します。 チームの知識共有 我々が開発を担当している楽楽精算はチームで開発を進めていくうえで以下の2点が課題となります。 経理 業務の知識 レガシーかつ 経理 業務に合わせた独特なシステム設計 例えば、今年リリースした iPhoneアプリ は精算時に使う領収書を撮影して保存することができますが、領収書を電子化して保存する 経理 業務の背後には「 電子帳簿保存法 」という法律があります。操作性や アーキテクチャ の側面だけでなくお客様の 経理 業務への効果や影響も意識してシステムを実現する必要があるためチームの知識共有がとても重要になります。 メンバーの半分がチームにJOINして1年未満 体制の変更もあって経験と立場がそれぞれ違うメンバー構成となり、それまでのように知識豊富な一部のメンバーがリードして進めるスタイルの限界を感じていました。 スプリントにモブプロを取り入れてふりかえりで改善 モブプロには以前から実験的に取り組んでいましたが、これらの課題が明確になってきてからは思い切ってスプリントの一部に組み込むようになりました。はじめはスプリント計画時にモブプロでやったほうが良い開発タスクを決めてモブプロの時間を設けていました。しかし、モブプロのために全員のスケジュールが合う時間を調整しなければならずスプリントを進めるうえでの負担になってしまいました。ふりかえりでこのような課題を議論した結果、スプリントで計画するのではなくスプリントが終わってからモブプロするほうが取り組みやすいという結論になりました。 スプリント最終日の午後はモブプロタイム！ 1週間スプリントの木曜は朝からスプリントレビューなので前日の水曜日は15時に開発が完了することを目標に計画していました。計画通りに終わればそれ以降は直前に開発した機能のPOレビューや翌日のスプリントレビューの準備、次のスプリントの準備の時間に充てます。計画より早く終われば改善などにも取り組むことができるので、この時間をボーナスステージと呼んでいます。モブプロに取り組むようになって試行錯誤の結果、このスケジュールをさらに繰り上げて開発完了目標を水曜午前中までとして、モブプロをボーナスステージに組み込むことにしました。 実装やコードレビューの中で「ここがわからない」「ここの知識が共有できていない」と気づいた部分は「今週のモブプロのお題にしよう！」と決めてリストアップしておき、ボーナスステージでテストコードを強化したり リファクタリング したりしながらモブプロするようにしています。 スプリント中にモブプロすることを禁止しているわけではないですが、開発中はスプリントの完了を優先させて取り組み、ボーナスステージに突入してから落ち着いてモブプロに取り組むスタイルが定着しています。チームで決めた トレードオフ スライダーの最上位が「納期」であることもこのスタイルが定着する要因のひとつと言えるかもしれません。 実践のポイント モブプロを実践する中でチームで合意している取り決めがいくつかあります。 モブプロはあくまでボーナス 開発中にトラブルが起きて計画どおりに進められなかった場合、ボーナスステージは無くなります。その時は無理にモブプロをすることはしません。チームの最優先は「納期」なのでまた次のスプリントで頑張ってボーナスステージに突入できるように改善していくだけです。 知識の共有をメインにする 我々のチームのモブプロの目的は今のところ知識の共有なので、それ以外の目的でモブプロすることはしません。ボーナスステージに突入しても特に共有が必要なテーマがなければ無理にモブプロはしていません。逆に知識の共有が必要なことであればプログラミングに限らずモブの時間を取るようにしています。最近ではコードレビューふりかえりと呼んで、プログラミングの観点だけに絞ったふりかえりの時間を設けてより良いコードの書き方やコードレビュー観点などを議論する時間を取ってみたりもしています。 環境の共 通化 我々のチームでは各自のノートPCを持ち寄ってモブプロしていますが、モブプロあるあるの課題としてドライバーを交代した時に他人の設定している環境が使いづらいという問題があります。そのため、チームで話し合ってモブプロのときに使用する最低限の IDE の設定などをいくつか決めています。個人で開発している時に設定を変えるのは自由ですが、モブプロの時にはみんな同じ設定で作業します。人によっては普段より効率が落ちるケースがあるかもしれませんが、事前にチームで話し合って決めたルールなのでモブプロの時は合わせてもらいます。事前に決めておくことで、モブプロの時に突然設定が変わって戸惑うことも少ないですし、事前に設定して慣れておくこともできます。 メリット このようなモブプロの実践についてメリットを考えてみました。 生産性の話をしなくていい モブプロを実践するうえで最も議論になるのが生産性の話です。1つのプログラムをチーム全員でプログラミングするのは効率が悪いのではないか？というヤツです。 しかし我々のやり方の場合、スプリントの開発は既に終わっています。やるべき事をやったので、もっと良くするために知識を共有する目的でモブプロをやっているだけなので少なくとも開発チーム内で生産性の議論をする必要がありません。生産性の議論をしなくて良いのはモブプロを実践するうえで非常に取り組みやすい状況です。 安心して開発に集中できる 「知識の共有」と言うのは簡単ですが、知らない事を知るという意味では言うほど簡単な事ではありません。1週間という短いスプリントの中でメンバー間の知識差に気づいた時には、時間的にも精神的にもそれほど猶予はない状態なので、「じゃあちょっとモブプロでもしようか」とはならないのです。「ここはひとまずこのまま進めておいて、あとでみんなでモブプロしながら リファクタリング しよう」と言えるのはチームにとって非常に強力な手段となります。 ボーナスステージへのモチベーションが上がる なんだかんだ言ってみんなで集まってワイガヤしながらプログラミングするのは楽しいです。1週間のスプリントを無事に終えてリラックスしながら、成果物をさらに良くしていくというのはスプリントを早く終わらせてモブプロしようというモチベーションにも繋がります。 デメリット モブプロ自体のデメリットではありませんが、ボーナスステージで実践することにはいくつかリスクがあります。意識して取り組めば回避可能なので紹介しておきます。 デグレード のリスクがある スプリントの最後にモブプロで リファクタリング するということは完成したものに手を加えるということなので デグレード を起こすリスクがあります。翌日は朝からスプリントレビューなので、完成したはずの機能が万が一動かなくなっていたらスプリントでやってきたことが全て水の泡です。そこまで大事には至らなかったものの、実際に我々も デグレード を起こしてしまったことがあります。そのため我々はモブプロを行ったあとに一通りの機能を再度テストをして終わるようにしています。 予定が立てにくい ボーナスステージというのはうまくいけば訪れるものなので、事前に計画することができません。モブプロしようと思ったら全員が集まれる場所が確保できなかったということも起こりえます。デイリー スクラム で日々の状況をうかがいながら先回りして予定を確保する必要があります。 もっとできるのにがんばらないリスク スプリント終わりにモブプロをするのを「ありき」にしてしまうと、その分の余裕をみて計画を立ててしまいます。しかしそれではチームのパフォーマンスは上がっていきません。あくまでスプリントで出来ることを出来るだけこなしたうえで、余裕があればモブプロを実行するのが理想です。POやステークホルダがもっとたくさん作って欲しいと思っているのに開発チームがスプリントを早めに切り上げてモブプロしているような状態になってしまうとモブプロの意義も疑われてしまいます。これは スクラム マスターがしっかり状況を判断してコン トロール しなければなりません。 まとめ 我々のチームでは知識の共有を目的としてモブプロを実践することでチーム力を強化してきました。最近ではスプリント計画時にもこれからモブプロをするかのように、みんなでプログラムを見ながら「ここをこうするんだ」と議論して計画を立てるようになりました。新たに若手のメンバーも迎え入れてチームを強化している最中で、学習をテーマにしたモブプロも実践してみたいと話をしています。 このように我々はチームを前進させるために目的を決めてモブプロを取り入れています。モブプロには他にも様々な効果があると思いますが、目的を絞って取り組んでみると改善点も明確になるのでチームに定着させやすいと感じています。 お知らせ 楽楽精算開発チームでは1年前から スクラム 開発を取り入れて実践してきました。これらの取り組みを2月に行われる Scrum Fest Osaka 2019 ご紹介できればと思い応募していますので、よろしければ投票お願いします。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com

sts -250rrです。 今回は ラクス Advent Calendar 2018 に投稿した記事、「 開発環境を作るためにDockerを使った話 」の続きになります。 qiita.com はじめに Dockerネットワークを作成してコンテナ間通信 開発環境（Go）・PostgreSQLコンテナの起動 docker-compose.yml Dockerfile 1_createdb.sql main.go 今回のポイント Goのパッケージインポート PostgreSQLコンテナで初期DB構築を行う 実は・・・ まとめ はじめに 前回の記事 ではDockerで開発環境を作ってみました。 が、このままではあまりにもチープな構成に感じます。。。 今回は コンテナ間通信 を使って別コンテナに作成したDBのデータを取得できるような構成を作っていくことを目標とします。 目標とする形は以下のようなイメージです。 Dockerネットワークを作成してコンテナ間通信 コンテナ間通信を実現するために、Dockerネットワークを作成します。 Dockerネットワークはコンテナ名を指定することでアプリ用（開発環境用）のコンテナからDBコンテナに接続することができるようになります。 まずはDockerネットワークを作っていきます。 $ docker network create my-network cbe89848f313a1b7766780903f79da2ff3a83bbe962f930c1f3caf9136fbac6f $ docker network ls NETWORK ID NAME DRIVER SCOPE 39d283374d44 bridge bridge local a3d0faef3da4 host host local cbe89848f313 my-network bridge local 7b1a7347c6b9 none null local 以下のコマンドでDockerネットワークの詳細を確認することができます。 $ docker network inspect my-network [ { "Name": "my-network", "Id": "cbe89848f313a1b7766780903f79da2ff3a83bbe962f930c1f3caf9136fbac6f", "Created": "2018-12-09T02:41:41.8124636Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.21.0.0/16", "Gateway": "172.21.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": {}, "Labels": {} } ] 作成したてのDockerネットワークなので何も登録されておらず、Containers部分が空っぽです。 コンテナ起動時にこのDockerネットワークを指定することで、同一のネットワークにコンテナが作成されるため、コンテナ間通信ができるようになります。 ※細かい部分は詰められていません。 開発環境（Go）・ PostgreSQL コンテナの起動 コンテナを起動して、開発環境コンテナのGoプログラムから PostgreSQL コンテナのDBに接続出来るような環境構築を行なっていきます。 今回もdocker-composeを利用していくので ディレクト リ構成・ファイルを以下のように作成します。 <任意のディレクトリ> |-- init | |-- 1_createdb.sql |-- Dockerfile |-- docker-compose.yml |-- main.go 今回、 main.go から PostgreSQL コンテナのDBに接続するために各設定ファイルやDBの初期構築が必要になります。 各ファイルは以下のように作成します。 docker-compose.yml version: '3' services: postgres: image: postgres environment: POSTGRES_USER: postgres # user POSTGRES_PASSWORD: postgres # pass ports: - "5432:5432" volumes: - ./db:/docker-entrypoint-initdb.d networks: - my-network app: build: . ports: - "8080:8080" networks: - my-network volumes: test_db: external: false networks: my-network: external: true Dockerfile #ベースのDockerイメージをgolangで指定 FROM golang:latest EXPOSE 5000 #ワークディレクトリを設定する WORKDIR /go #ホストのディレクトリを/go配下にコピー ADD . /go #GOPATHの設定 ENV GOPATH $GOPATH:$HOME/go RUN go get github.com/jinzhu/gorm RUN go get github.com/lib/pq #main.goを実行 CMD ["go", "run", "main.go"] 1_createdb. sql create database testdb; main.go main.goはこちらを参考にさせていただきました。 実行するとDBに登録されているIDと名前を出力します。 https://qiita.com/rky_1011/items/9772d92b5fe8cb3b82b0 qiita.com package main import ( "fmt" "github.com/jinzhu/gorm" _ "github.com/lib/pq" ) type User struct { ID int64 `gorm:"primary_key" json:"id"` Name string `json:"name"` } type Users []User func main() { db, err := gorm.Open("postgres", "host=172.24.0.3 user=postgres port=5432 password=postgres dbname=testdb sslmode=disable") if err != nil { panic(err) } defer db.Close() db.AutoMigrate(User{}) var user = User{Name: "testname"} db.NewRecord(user) db.Create(&user) db.Save(&user) var users = Users{} db.Find(&users) fmt.Println(users) } さて、ファイルが揃ったら、 docker-compose build 、 docker-compose up を実行すれば、 main.go の実行結果が得られます。 (略) postgres_1 | 2018-12-09 06:32:23.787 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" postgres_1 | 2018-12-09 06:32:23.829 UTC [58] LOG: database system was shut down at 2018-12-09 06:32:23 UTC postgres_1 | 2018-12-09 06:32:23.851 UTC [1] LOG: database system is ready to accept connections app_1 | [{1 testname}] app_app_1 exited with code 0 postgres_1 | や app_1 | といった形でコンテナごとの出力結果が得られています。 app_1 | [{1 testname}] と出力されているのでなんだかいけてそうな気がします。 これだけではピンとこないので PostgreSQL コンテナに入ってDBを確認してみると、 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f9a9ed9b3fc8 postgres "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 0.0.0.0:5432->5432/tcp app_postgres_1 $ docker exec -it app_postgres_1 bash root@f9a9ed9b3fc8:/# psql -U postgres testdb psql (11.1 (Debian 11.1-1.pgdg90+1)) Type "help" for help. testdb=# select * from users; id | name ----+---------- 1 | testname (1 rows) PostgreSQL コンテナの内容と開発環境コンテナのmain.go実行時の内容が一致するので正しく値を取得できているようです。 最後にDockerネットワークの状態を確認します。 docker network inspect my-network [ { "Name": "my-network", "Id": "e77a834d8aff49e316e7ab153666232eab35f7fe4350b18be19da1d608125c4b", "Created": "2018-12-09T06:25:02.1986525Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.24.0.0/16", "Gateway": "172.24.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "f9a9ed9b3fc8b67232edb76ec4202e0b66ec776dbd0665db7f9ee11341088571": { "Name": "app_postgres_1", "EndpointID": "6dfd276d55c4352668364de97a588ca5072bf5ee647b8b9dbe5cbdc04d8603f1", "MacAddress": "02:42:ac:18:00:03", "IPv4Address": "172.24.0.3/16", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] Go側のコンテナは実行完了と同時に停止してしまうので、 Containers には表示されていませんが、Postgresコンテナが my-network 内に含まれていることがわかります。 色々複雑でしたが、コンテナ間通信ができる開発環境、無事完成です。 今回のポイント Goのパッケージインポート ローカルでGoを書く時にも必要なことですが、軽く詰まりました。 main.goの中で Github からパッケージをインポートしていますが、事前にGOPATHを設定したり、go getでGitリモー トリポジ トリをダウンロードしておかなければならなかったようです。 Dockerコンテナでもこれは同様なのでDockerfile上でENVやRUNで必要な事前処理を行っていますが、詰まったのはRUNでgo getを実行する部分です。 はじめはCMDで実行していましたが、main.go実行時にこうなります。 app_1 | main.go:6:4: cannot find package "github.com/jinzhu/gorm" in any of: app_1 | /usr/local/go/src/github.com/jinzhu/gorm (from $GOROOT) app_1 | /go/src/github.com/jinzhu/gorm (from $GOPATH) app_1 | /go/src/src/github.com/jinzhu/gorm app_1 | main.go:7:4: cannot find package "github.com/lib/pq" in any of: app_1 | /usr/local/go/src/github.com/lib/pq (from $GOROOT) app_1 | /go/src/github.com/lib/pq (from $GOPATH) app_1 | /go/src/src/github.com/lib/pq app_app_1 exited with code 1 パッケージ見つからないよ。という旨のエラーですね。 調べてみたらRUNとCMDでこんな違いがありました。 qiita.com 深くまで追えていませんがイメージ作成時に実行しておかないとmain.goの実行時にはDLが完了できないとかなんでしょうか？ PostgreSQL コンテナで初期DB構築を行う PostgreSQL コンテナをただ作るのみではもちろんDBの作成はしていないので、接続に失敗します。かといって毎回コンテナを起動するたびに手動で作成するのはDockerの利点を潰してしまっていますよね。 そんなことをしなくて良いようにDockerhubの公式のイメージには便利機能がありました。 If you would like to do additional initialization in an image derived from this one, add one or more . sql , . sql .gz, or *.sh scripts under /docker-entrypoint-initdb.d (creating the directory if necessary). /docker-entrypoint-initdb.d という ディレクト リに .sql や .sh のファイルを配置しておけば起動時に実行してくれるみたいです。 ということで、 docker-compose.yml の volumes: で init 以下の 1_createdb.sql を docker-entrypoint-initdb.d に配置し、 createdb を実行していました。 実は・・・ 必要なファイルが揃えば、さも簡単に実行できるかのように書いていますが、1度目の実行は ほぼ必ず 失敗します。 というのも1度目の実行ではDockerネットワーク上の PostgreSQL コンテナに割り振られるIPがわからないためです。。。 main.goの中で接続先のDBのあるIPを指定しているので、その部分でコケます。 多分何かしらいい方法があるんだと思いますが、現時点では見つからず。。。 良い方法があれば教えていただきたいです。。。 まとめ 今回はDockerネットワークを使ってGoアプリとDBを接続してみました。 アプリのコンテナとDBを分けることができ、なんだかそれらしくなってきたような気がします。 Dockerやdocker-composeがよしなにやってくれる分、上手くいかなかった時にはどこに問題があるのかを見つけるのが大変です。 その分出来上がってしまえば作り直しや複製が簡単にできてしまうので、便利であることに変わりはないですね。 個人的には、「実は・・・」でお伝えした部分はなんとか解決したいものです。。。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。以前 ご案内 したとおり11/27に大阪オフィス初のMeetupを開催しました。 今回はMeetupのご報告とともに、運営で得た知見などを少しだけご紹介します。 大阪開発チームのチャレンジ紹介 今回は次の3つのチャレンジをご紹介しました。 チャットディーラーの高速開発を支えるLaravel 今年夏に登壇させて頂いた PHPカンファレンス関西 2018 の内容 をベースに、Laravel導入のチャレンジとそこで得た知見をお伝えしました。Vue.jsと格闘したエピソードでは前回登壇時には無かった開発メンバーの生の声を加えることで、大阪開発チームらしさもお伝えできたと思います。 speakerdeck.com Why Mob Programming? - モブプロという働き方 - モブプロに取り組み始めた経緯、はじめ方、やってみて良かったこと、悪かったことなど、 アジャイル を推進する開発現場のモブプロへのチャレンジと得た知見を余すことなくお伝えしました。本編のスライドに使用されている写真は移転前のオフィスで撮影されたものでしたが、唯一、新オフィスで撮影した一番最後のスライドの「俺たちの戦いはこれからだ！」っぽい雰囲気もまたチャレンジ感をお伝えできたのではないかと思います。 speakerdeck.com トウダン・ジャーニー 1つ目の発表にある PHPカンファレンス 関西 2018への登壇に向けて開発組織を横断した登壇推進チームを結成して取り組んだチャレンジについてお伝えしました。既に次の登壇も決まっており、社内チャットにさりげなく釣り針を落とすことから始まった登壇へのジャーニーは今後もまだまだ続きます。 speakerdeck.com Meetupへのチャレンジ 今回、私自身はMeetupの運営にチャレンジしました。運営のチャレンジで特に大切だったことは次の2つです。 イベントのテーマを何にするか？ Meetupのテーマを何にするかは運営にとって最初の大きな課題でした。そもそもテーマを絞る必要があるのか？という疑問もありました。しかし、せっかく仕事終わりの時間を使って多くのかたに集まってもらうので、我々がどんなイベントにしようとしてるのかをイメージしてもらえる程度にテーマを絞るべきと考えました。特定の技術テーマに絞ることも考えましたが、初めてということもあるのでまずは大阪オフィスと開発チームの雰囲気を知ってもらうのが良いだろうと考えました。 「チャレンジ」というのはチャレンジそのものではなく、チャレンジを実践して結果を出したその場に価値があると思います。つまり、チャレンジというキーワードを通して「開発の現場」を知ってもらうことが大事だと考えました。そして、社内のビアバッシュで「Meetupをはじめよう」というLTを行ってこの思いを開発チームのメンバーに共有しました（ その模様は『 大阪開発ビアバッシュ～11月「新機能特集」 』で投稿していますのでご確認ください）。 今回、登壇を引き受けてくれたメンバーはその思いを汲み取ってそれぞれの視点でエンジニアの現場のエッセンスを発表に盛り込んで伝えてもらえたと思います。 LTをやりたい！ イベントの運営を引き受けるうえで、もうひとつ大切にしたかったのが次の2つを軸とした交流です。 大阪の梅田という地域性 エンジニアの楽しみ ここ数年で大阪でもたくさんの勉強会イベントが日々開催されるようになり、我々も一緒に大阪のコミュニティを盛り上げたいという思いがあります。また、社内外のエンジニアの交流を深めることで、エンジニアが楽しみながら成長していける場にしていけたらという思いもあります。社外の勉強会には私もよく参加させて頂いてたくさん情報交換させて頂いていますが、逆の立場で自社でもイベントを開催し、社外と社内が混ざり合って交流することで2つの軸はさらに強くなると思います。 そこで、LTを募集して参加者の方々にもイベントの一部に加わって頂くことで、この2つを軸とした交流をさらに深めたいと考えました。ただ、弊社が主催するイベントということもあり、本編のセッションと繋げてしまうとLTして頂く側からするとやりにくさもありそうなので、本編のセッションが終わったところで一区切り入れて交流会の中でLTして頂くことにしました。 交流会をスタートしてからLTに入るタイミングや進め方などはまだまだ改善の余地があると感じていますが、運営側の願いどおりの楽しみながら交流できるLTセッションにして頂けました。LTに応募して頂いた皆様、本当にありがとうございました。 おわりに 運営のチャレンジは始まったばかりで課題もたくさんありますが、フィードバックもたくさん頂きましたので得られたものも大きいです。今後につなげて継続的に開催していきたいと思います。 次回は2月頃に開催を予定 詳細が決まり次第、connpassに公開します。 もくもく勉強会も計画中 1月から月1回程度のペースでもくもく勉強会の開催も計画しています。こちらも決まり次第、connpassに公開します。 rakus.connpass.com 今後もこのようなイベントを企画してエンジニアを楽しくするための交流の場をつくっていければと思います。ぜひご参加をお待ちしております。 お知らせ ラク ス Advent Calendar 2018を実施中！ 毎年恒例の アドベントカレンダー が今年も始まっています。 ラク スのメンバーがこの1年間で集めたそれぞれのネタをつないでリレーしていますのでぜひご覧ください！ qiita.com Scrum Fest Osaka 2019に応募しています 大阪では2月に Scrum Fest Osaka 2019 という大きなイベントが開催される予定で、現在セッション公募が行われています。私も楽楽精算開発チームの スクラム の取り組みをご紹介できればと思い応募していますので、よろしければ投票お願いします。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com

はじめに こんにちは、 @rs_tukki です。 以前 id:radiocat さんが記事にされていましたが、効率よくプロジェクトを進めるにあたって、「振り返り」を行うことは非常に大切です。 今回は、その「振り返り」の手法のひとつ、 KPT 法について話したいと思います。 tech-blog.rakus.co.jp はじめに 振り返りとは なぜ振り返りが大切なのか？ KPT法 K ~Keep:継続すべきこと~ P ~Problem:問題だと思うこと~ T ~Try:改善していくこと~ KPT法のメリット 実践例 おわりに 参考 振り返りとは 振り返る 読み方：ふりかえる (1)身体を翻して後方を見る、後ろ側を向く、などの意味の表現。 (2)過去の物事を顧みる、思い起こすこと。回顧すること。 (3)これまで行われてきた物事の一連の流れを総括すること。 引用: 振り返る(ふりかえる)の意味や定義 わかりやすく解説 Weblio辞書 今回扱う、プロジェクトを進めるにあたっての「振り返り」は、このうちの(3)にあたります。 ここまで実施したことの内容と結果、それを通じて学んだことをメンバー全員で確認することで、これから実施することを見直し、改善していく作業のことを指します。 特に アジャイル 開発を採用したプロジェクトだとスプリントごとに行うことが多いですが、開発現場に限らずとも、複数人で何かを進めていく場では、よりよい方向を目指すために役立ちます。 なぜ振り返りが大切なのか？ 「振り返り」という言葉だけでは、「反省」と勘違いされることがあります。 しかし、反省が、過去の失敗がなぜ起こったのか、という原因の追及を行うのに対して、振り返りは、 目標にしていたことが達成できたか 、 達成できたのなら次の目標はどうするか 、 達成できなかったのならどうすれば達成できるようになるのか 、という考え方のもとに進めていきます。 次の仕事をより効率よく改善していくためには、単なる「反省」ではなく、「振り返り」を実施することが大切なのです。 KPT 法 KPT 法とは、振り返りの手法として用いられている枠組みの1つです。 今までの仕事の中で感じたことを、 一人ずつ「Keep」「Problem」の二つに分けて挙げてもらい、議題とします。その中から次の改善案となる取り組みを「Try」として選び実施していきます。 元々はAlistair Cockburn氏が2004年の著書で提唱した理論を、平鍋 健児氏が KPT と呼んだのが始まりのようです。既に15年近くも使われている伝統の手法みたいですね。 tbpgr.hatenablog.com K ~Keep:継続すべきこと~ K には、実施してよかったこと、今後も継続して実施していきたいことが入ります。 例えば、新機能の開発を行うとき、複雑なコードをモブプログラミングで実装したとします。その機能が大きなバグもなく、スムーズにリリースできたというKeepがあれば、モブプログラミングの実施は効果があった、という判断ができ、またそれを提案した人が達成感を覚える機会にもなります。 P ~Problem:問題だと思うこと~ 一方で P には、失敗したこと、これから改善していきたいことが入ります。 例えば、バグの修正を行うとき、影響範囲がどこなのか、よく調べずに取り組んでしまったとします。 結果、修正に余計な時間がかかってしまった、別のところにバグが発生してしまった、というProblemがあれば、その問題を共有するとともに、改善へ向けた意識付けができます。 ここで問題なのは、先ほど書いたように 原因の追及をしない ということです。 起こってしまった問題に対して個人を攻撃するのではなく、どうすれば改善できるか、を考えることが大事です。 T ~Try:改善していくこと~ 最後に T は、今まで挙がった内容を踏まえて、次の機会にどのように実施していくかのまとめが入ります。 上記の例で言えばモブプログラミングによる効率を上げるために、より多くの機能でモブプログラミングを実践する、 あるいはバグ修正の手戻りをなくすために、修正方針をレビューしてもらう、といった形です。 そして次回の KPT では、今回Tryに挙げたことがまたKやPに入り、更なる改善を目指していくのです。 KPT 法のメリット 振り返りの手法には、有名なもので PDCA *1 がありますが、こちらではそれぞれの中で具体的にどのようなことをすればいいのかが曖昧です。 KPT 法では、 PDCA の中の CA に絞った手法を具体的に示しているので、初めて振り返りをする場合でも、何を確認して何を話し合えばいいのか分かりやすいのがメリットと言えます。 実践例 以下の画像は、私たちのチームで毎年実施しているとあるプロジェクトの KPT です。 特別な道具を用いる必要はなく、一つの Excel ファイルへメンバーが一人ひとり自由に記載してもらっています。 ここで重要なことは、 意見の被りを気にしない ことと、 プロジェクトを実施するたびに行う ことです。意見が被るということは、それだけ多くの人が同じことを感じているということですので、それだけ継続、あるいは改善の優先度が高まります。Problemの全てをTryにするのが難しい場合でも、意見の数を参考にTryにすること、しないことを判断できるのです。 また、 KPT は1回で終えるのではなく、都度繰り返し実施することで、よりよいプロジェクトになっていくのではないかと思います。 おわりに 今回は、チームのプロジェクトを進めるにあたって振り返りが必要なこと、またその手法の一つとして KPT 法を紹介いたしました。 実施したことを適切に振り返り、改善していけば、効率が格段にアップするはずですので、ぜひ一度試してみてください。 参考 Alistair.Cockburn.us | Reflection workshop 「振り返り」をするかしないか、で変わること。振り返りは、未来の自分へのアドバイス…？｜社員研修・人材育成コラム｜FCEトレーニング・カンパニー “振り返り”に役立つ5つのフレームワーク。振り返りシートの書き方や方法を押さえよう｜ferret KPTとは？ふりかえりのフレームワーク・進め方・成功のコツ・ポイント | BOXIL Magazine エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : 計画[Plan]、実行[Do]、評価[Check]、改善[Action]を繰り返していく手法のこと。