ラク スでメールディーラーの開発に携わっている@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]を繰り返していく手法のこと。

こんにちは、fuj_takです。 今回は ラク スのサークル活動について紹介します！ サークル活動について サークル活動は、 ラク スで働くにあたって、モチベーション向上や信頼関係を築くこと、 ワークライフバランス を充実させることを目的としています。 また、サークル活動に対して会社からの補助を受ける事ができます。 業務に近い内容だけでなく、趣味を通じて交流を図るサークルなど様々で 好きなテク ノロ ジー を開発 カメラ撮影 フットサル ガンプラ などです。 その他にも多数のサークルがあります。 ボードゲーム サークル 私が参加しているサークルは「 ボードゲーム サークル」です。 平日の業務時間後、課／部署問わず色々なメンバーが参加しています。 ボードゲーム といっても、広く知られている人生ゲームや モノポリー ではなく、 カタン カルカソンヌ ドミニオン といったもので、今まで名前を聞いた事がないものばかりでした。 始めはルールに混乱するのですが、一度やってみると大体ルールを理解できるようになりました。 どれも奥が深く、日頃パソコンや スマホ にばかり目を向けている自分にはとても新鮮で楽しいです。 日頃なかなかコミュニケーションを取りづらいメンバーとも ボードゲーム を通じて交流を図れるので、社内の交流の幅も広がるし、リフレッシュにもなるんですよね。 私のおすすめは ドミニオン です！ ゲームのルールを様々なバリエーションで組み合わせられるので、毎回違った面白さがあるんですよ。 こんな名前のカードがあって、なんか心をくすぐられます。 地下貯蔵庫 宰相 海の妖婆 策士 わが子が成長したら一緒にやろうともくろんでいます。 まだ1歳と3歳なので今は一緒にできませんが（笑）。 社内に広いリフレッシュスペースも備えているため、 ボードゲーム だけでなく様々な活動で社内の環境を活用できるようになっています。 www.wantedly.com ラク スでは業務だけでなく、サークル活動などの ワークライフバランス も意識しています。 業務もサークルも楽しみながら、楽しいエンジニアライフを送っていきたいと思います！

こんにちは。エンジニアのmickey-STRANGEです。 はじめに 今回は先日、大阪オフィスで開催された11月ビアバッシュをご紹介いたします。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Mail Dealer 配配メール 楽楽精算 Chat Dealer 働くDB LT発表 街ブラUIレビュー CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける Meetupをはじめよう おわりに テーマ発表 11月のビアバッシュのテーマは新機能特集でした。 ラク スの各製品の開発者にこんな機能作った、ここがんばったよ、ここ苦労した、というお話をしていただきました。 また、テーマ発表の後にはLT発表もあり、内容たっぷりのビアバッシュでした。 Mail Dealer 今後リリース予定の機能についての発表でした。 いきなりですが、未リリース機能なので、内容は社外秘。本ブログでお伝えすることは出来ません… ですが、求められる要件と実装面の課題との狭間での激しい闘いのお話を聞くことが出来ました。 配配メール 今年7月にリリースした配配メールv5.0の機能についての発表でした。 配配メールv5.0ではデザイン変更、複数ユーザ対応を実施したそうですが、デザイン変更は全画面ですし、複数ユーザ対応も権限など全機能に関わる部分があり、圧倒的なタスク量だったとのことです。 改修対象ソースの洗い出しや、全画面の現状確認+テストに苦労したというお話を聞くことが出来ました。 楽楽精算 楽楽精算では、ユーザ操作を自動化する機能を開発しており、その中でも iOS アプリについての発表でした。 iOS アプリは、領収書明細の自動入力を実現しています。※ 電子帳簿保存法 オプション必須の機能 図メインのスライドになると何故か右から左の資料になっている点が気になりました。 Chat Dealer 既存機能のチャットボットを強化する新機能として開発された「ボットレポート」についての発表でした。 使用中のチャットボットの設定をブラッシュアップするために使用される機能で、実際にデモを交えて解説していただきました。 チャットボットの設定画面がそこはかとなく働くDBの自動処理設定に似ている気がしたのは私だけではありませんでした。 働くDB 自動処理ジャンプパーツについての発表でした。 オプション機能ですが、ジャンプパーツを使用することによって、条件分岐後に同じ処理をする場合の設定がきれいになるそうです。 before-afterを例で挙げていただきましたが、たしかにパーツ数が減って見やすくなっている気がします。 LT発表 LT発表は3人の発表者が登壇してくださいました。 内容は自由で、テーマに関係なく、思うままに発表していただきました。 街ブラUIレビュー 以前にも街中のBAD UIを発表して下さった方が、その続編ともいえる内容での発表でした。 言い回しのおかしい説明や、何かを目立たせるための強引な注意書きは定番の内容ですが、発表の中で気になったのが下の写真です。「電光 掲示 板を見たあと絶対に時計を確認しますよね」と聞いたときのアハ体験がとても印象的でした。 CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける 外部スライドを使用してのツール紹介の発表でした。 tbls というツールの紹介でしたが、肥大化したDBに対して、後付けでテーブル定義をすぐに作成できるというのは非常に魅力的なツールだと感じました。 speakerdeck.com github.com Meetupをはじめよう 先日開催されました、 Rakus Meetup Osaka #1 についての発表でした。 なぜ開催するのか、開催すると何が嬉しいのか、から始まり、開催するにあたっての心構えまでをまとめて発表していただきました。 おわりに 11月のビアバッシュをダイジェストでお送りいたしましたが、いかがでしたでしょうか。 各製品の新機能/オプションについて気になった方は、 ・ご利用中のお客様は、サポート窓口もしくは各製品のサポートサイト ・新規でご検討のお客様は、製品ページからのお問い合わせ にて詳細をご確認くださいませ。

最近、自宅で Laravel を使ったアプリを作成しています。 せっかく作ったアプリなので、公開しようとしたのですが、あくまで趣味の範囲であり、有料の環境を使おうとは思えず、Heroku へデプロイすることにしました。 今回は、Heroku でLaravel アプリをデプロイするための手順を簡単に説明します。 前準備 Profile の作成 .envファイルについて Heroku アプリ作成 Heroku へ push する メールの送信設定 その他 参考サイト 前準備 Heroku のアカウント作成と、Heroku CLI のインストールは事前に済ませてください。 Profile の作成 Heroku アプリの設定値を書き込む Profile を Laravel プロジェクトの直下に作成し、以下の内容を書き込みます。 これにより、Webサーバに Apache を使用し、Laravel の public ディレクト リをドキュメントルートにすることができます。 web: vendor/bin/heroku-php-apache2 public/ ファイルを作成次第、master ブランチに Profile を commit します。 .envファイルについて Laravel の .env ファイルでは、ローカルの 環境変数 を設定できます。 Heroku へのデプロイは、Git を用いて リポジトリ を Heroku へ push することで行うため、 git の管理外である .env ファイルを Heroku へ設置できません。 そのため、config ディレクト リ内の 環境変数 を Heroku 環境で使用したい値に変更しておきます。 Heroku アプリ作成 Laravelアプリの ディレクト リに移動し、 heroku login コマンドでメールアドレスとパスワードを入力し、Heroku にログインします。 その後、Heroku へ PHP アプリを作成するために、 heroku create コマンドを実行します。 > heroku login heroku: Enter your login credentials Email [xxxx.xx.xx@xxx.xx]: Password: ******* Logged in as xxxx.xx.xx@xxx.xx > heroku create my-app 実行できたら、 heroku apps コマンドを実行することで、Heroku にアプリケーションが増えていることがわかります。 Heroku へ push する Heroku へアプリが追加出来たら、作成したプロジェクトを Heroku へデプロイします。 デプロイと言えど、やることは Heroku へ master ブランチを push するだけです。 > git push heroku master 少し時間がかかりますが、push ができればデプロイ完了です。 メールの送信設定 作成していたアプリでは、メールを送信する必要がありました。しかし、Heroku から直接メールを送信することはできないので、他の方法を考える必要があります。 今回は、 Gmail に対して SMTP 接続を行い、メールを Gmail を用いて送信するようにしました。 手順としては、 Google アカウントにて、 Gmail の SMTP 接続を許可したうえで、config/mail. php の 環境変数 を以下のように変更します。 'driver' => env('MAIL_DRIVER', 'smtp'), 'host' => env('MAIL_HOST', 'smtp.gmail.com'), 'port' => env('MAIL_PORT', 465), 'from' => [ 'address' => env('MAIL_FROM_ADDRESS', 'my.gmail@gmail.com'), 'name' => env('MAIL_FROM_NAME', 'Fromの名前'), ], 'encryption' => env('MAIL_ENCRYPTION', 'ssl'), 'username' => env('MAIL_USERNAME', 'my.gmail@gmail.com'), 'password' => env('MAIL_PASSWORD', 'xxxxxxxxxxxxxxxx'), // Gmail設定時のパスワード文字列 これにより、Laravel アプリからメールを送信することができるようになります。 その他 その他、Heroku ではカスタム次第でいろいろな機能が使えます。 ちょっとしたアプリ作成や、実装の練習成果を公開する場合は、非常に便利ですね。 参考サイト qiita.com

はじめに 開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 前々回 、 前回 と弊社エンジニアへのなんちゃってインタビューで記事を書いてきましたが、今回は久々に調べものをした結果をまとめてみようかと思います。 目次 はじめに 目次 経緯 ラインエディタ ed の概要 edの機能 コマンドライン モード コマンド一覧 行指定 指定された行の操作 その他 ed を実際に使ってみた 同じedでも環境によって違うこともある おわりに 参考 経緯 実は私は自宅では非常に貧弱な性能のマシンしか持っていません。でもやっぱり家でも趣味の開発はしたいわけですが、まずエディタ選びが悩ましい。 Eclipse は動くには動くけどどうももっさりしてて使ってられない。 Atom エディタも同じ感じ。 Visual Studio Code やGeanyという軽量エディタはわりとマシだったものの、時間が経つにつれてだんだん重くなっていく…。 結果ターミナルで vim という選択肢に行き着いたわけですが、やはりあまり使いこなせない。何とか使いこなせるようになろうと vim の操作を調べるうちに、ラインエディタというものの存在を知りました。 ラインエディタ vi( vim )はスクリーンエディタというものに分類されるそうです。 テキストエディタ といえば、画面上に編集するテキストを表示し、その上でカーソルを移動させて編集を行なうものを連想しますが、そういったエディタがスクリーンエディタと呼ばれます。 対してラインエディタでは、画面上への表示は最小限です。スクリーンエディタと異なり内容の閲覧/編集はそれぞれ独立した機能であり、目的の行を抽出、編集、更新というサイクルで編集を行います。 最初期の テキストエディタ の形であり、スクリーンエディタの開発以前は主にこれが使用されていたようです。 ed の概要 ed はラインエディタの一つであり、初期の頃から存在する UNIX 上の標準的な テキストエディタ の一つです。今も事実上全てのバージョンの UNIX と Linux に装備されています。 ただ最近では vi や Emacs 、その他のスクリーンエディタにとって代わられ ed を対話的に使用することは滅多に無いようです。ただ問題が発生したときには ed が使用可能な唯一のエディタである場合もあり、そのような場合に限って ed は対話的に使用されます。 またエディタコマンドは標準入力で受け取られるので、 シェルスクリプト 内で使用することが出来、そういった用途で使われることはあるようです。 edの機能 コマンドライン ed を起動するには端末で以下のようにタイプします。オプションとファイル名を引数として指定できます。 ed [options] [file] 代表的なオプションは以下のものがあります。 オプション 長い書き方 説明 -h --help 使用法を表示して終了 -V --version バージョン情報を表示して終了 -l --loose-exit-status コマンド実行に失敗しても終了ステータス 0 を返す -p STRING --prompt=STRING プロンプトとして STRING を指定 モード ed には、コマンドモードと入力モードがあります。 コマンドモードではエディタを操作するためのコマンドを入力してテキストの編集や置換、行の削除などを行っていきます。存在しないコマンドなどを入力したなどのエラー時は、 ? と表示されます。 入力モードでは、コマンドを実行することはできません。標準入力から入力されたデータは、 直接エディタバッファへと書き込みとされます。ピリオド1つだけの行を入力すると、入力モードを終了します。 コマンド一覧 行指定 ed では常に操作の対象となる行を指定する必要があります。 ed は現在行を管理しており、コマンドに行番号が指定されない場合は、現在行がデフォルト行として用いられます。ファイルが最初に読み出された直後は、現在行はファイルの最後の行となります。一般的に、現在行はコマンドが操作した最後の行となります。 なお行番号は1始まりです。 コマンド 内容 . 現在行 n n 行目 + n 現在行より n 行後の行 + 現在行の１行後の行。 +1 と同じ - n 現在行より n 行前の行 - 現在行より１行前の行。 -1 と同じ $ ファイルの最終行 m , n m 行目から n 行目の範囲。 m , n は数字または単一行指定コマンドを使用可能。e.g., 5行目から10行目を指定する場合は 5,10 、ファイル全体を指定する場合は 1,$ , ファイル全体。 1,$ と同じ ; 現在行から最終行までの範囲。 .,$ と同じ 指定された行の操作 テキストの編集や置換、行の削除などは、行指定とコマンドを組み合わせて行います。以下の表では括弧書きした部分が行指定で、省略時のデフォルト動作を示しています。 コマンド 内容 (.) i 指定した行の前にテキストを追加。編集モードになる (.) a 指定した行の後ろにテキストを追加。編集モードになる (.,.) c 指定した範囲の行を削除して、そこにテキストを追加。編集モードになる (.,.) d 指定した範囲の行を削除 (.,.) y 指定した範囲の行をカットバッファにコピー（yank） (.) x カットバッファの内容を指定した行の後ろにペースト (.,.) m (.) 左辺で指定した範囲の行を右辺で指定した行の後ろに移動。右辺には 0 を指定できる (.,.+1) j 指定した範囲の行を連結 (.,.) p 指定した範囲の行を表示 (.,.) n 指定した範囲の行を行番号つきで表示 (1,$) g/ reg / cmd 指定した範囲の行のうち、 正規表現 で reg と一致した文字列のある行に対し、 cmd を実行 (.,.) s/ reg / rep /n 指定した範囲の行のうち、 正規表現 で reg と n 番目に一致した文字列を rep に置き換える (.,.) s/ reg / rep / 指定した範囲の行のうち、 正規表現 で reg と1番目に一致した文字列を rep に置き換える。 s/ reg / rep /1 と同じ (.,.) s/ reg / rep /g 指定した範囲の行のうち、 正規表現 で reg と一致した文字列をすべて rep に置き換える ($) = 指定された行の行番号を表示 その他 コマンド 内容 u 直前のコマンド実行をアンドゥ。 u コマンド自体もアンドゥできる P コマンドモード時に、行頭にプロンプト文字列を表示。 コマンドライン 引数で文字列が指定されていない時は、 * が使用される。 ! cmd cmd で指定したコマンドを、 sh を用いて実行 w [ file ] file に編集内容を書き込み q エディタを終了。編集内容が未保存の場合はエラー Q エディタを終了。編集内容が未保存でも強制的に終了 ed を実際に使ってみた edコマンドの使用例として、実際にファイルの編集を行ってみました。 とりあえず ed のバージョンを確認。1.1のようです。 $ ed --version GNU Ed 1.1 Copyright (C) 1994 Andrew L. Moore, 2008 Antonio Diaz Diaz. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. 適当な ディレクト リに移動します。 $ cd /some/path $ ls -a ./ ../ ファイルが何もないですが、せっかくなので ed で作ることにしましょう。 $ ed P *i hoge hoge hoge . *= 1 *a fuga fuga fuga moge moge moge piyo piyo piyo . *= 4 *w test 60 *q 最初に P コマンドを使用してプロンプトを出すようにしています。 i や a で行を追加。 = で現在行の番号を確認しています。最後は w コマンドで"test"という名前でファイルに保存しました。 確認してみると、 $ ls test $ cat test hoge hoge hoge fuga fuga fuga moge moge moge piyo piyo piyo 思った通りにファイルが作成されていました。 起動時にファイル名を指定するとエラーが表示されるのですが、最後の保存時に名前を指定しなくてもよくなるようです。 $ ed test2 test2: そのようなファイルやディレクトリはありません P *i hoge . *w 5 *q $ ls test test2 次に作成したファイルを編集してみます。 $ ed test 60 P *,n 1 hoge hoge hoge 2 fuga fuga fuga 3 moge moge moge 4 piyo piyo piyo *2c foo bar baz spam ham egg . *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 moge moge moge 5 piyo piyo piyo *,s/moge/toto/g *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 toto toto toto 5 piyo piyo piyo *wq 70 最初に行番号付きで現在のファイル内容を確認しました。その後 c コマンドで2行目を変更し、ついでに新しい行を続けて入力しています。再度行番号付きで現在のファイル内容を確認すると、確かに2行目が変更され、その下に行が追加されていました。手入力で行の中の一部分を変更することはできないので、仮に同じ部分があったとしてもその行は全部書き直しです。 最後の保存と終了は同時に出来るみたいです。vi も同じですね！ ed 終了後にファイルの中身を確認すると、きちんと変更されていました。 $ cat test hoge hoge hoge foo bar baz spam ham egg toto toto toto piyo piyo piyo 同じedでも環境によって違うこともある Windows にインストールした BusyBox 1.22.1に含まれる ed は、上でまとめたものとはオプションやコマンドが若干異なるようでした。 コマンドライン オプションが使えない デフォルトでプロンプトが表示されている プロンプト文字列は : P コマンドがない 他にも違いはあるかも おわりに 古くからあるがゆえに逆に知らなかったエディタ ed について調べてみました。 実際使ってみましたが、ファイル内が今どんな状態なのかがすぐにわからないのが少し不安に思いました。いくら軽量だとは言え普段使いするならやっぱりスクリーンエディタかな、というのが正直な感想です。ただ シェルスクリプト で使うこともあるかも…。 なお今回まとめたのは ed のコマンドの中でも一部にすぎません。もっと詳しく知りたいなら参考に挙げたページや、manやinfoを見てくださいね。 参考 テキストエディタ - Wikipedia Man page of ED ED - Wikipedia edを使ってみる http://www.uetyi.com/server-const/entry-271.html ラインエディタ体感ツアー――vi/vimの「動作モード」なるものの謎に迫る - 新・日々録 by TRASH BOX@Eel おすすめのLinuxフリーテキストエディタ12選！ 5-1 どんな環境でも使えるライン・エディタ - edエディタ - エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

スクラム とは こんにちは。strongWhiteです。今回は スクラム に関する解説記事です。 スクラム とは、変化の激しいソフトウェア開発の問題に対応するための開発手法です。 ソフトウェアは建築物などの三次元的な物体とは異なり、認識しにくく不透明な存在であるため、 潜在的 な問題（バグなど）を早期に察知するのが難しい性質を持っています。また、問題を認識できたとしても修正などの後戻りが難しい場合があります。このようなソフトウェア開発の問題を解決するのが スクラム です。 スクラム では、あらかじめ定めた期間内に一定の成果物を作成（開発）し、徐々にソフトウェアを構築するというアプローチを取ります。ソフトウェアに「透明性」を見出し、 潜在的 な問題を認識しやすくするのです。 今回の記事では スクラム を用いた開発を始める方向けの前提知識として、 スクラム 開発の関係者（ スクラムチーム ）と スクラム 開発中で発生するイベント（ スクラムイベント ）について解説します。 スクラムとは スクラムチーム プロダクトオーナー 開発チーム スクラムマスター まとめ（1） スクラムイベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ まとめ（2） スクラム チーム スクラム 開発は、以下の役割を担う人（たち）が相互に作用し合って進捗していきます。 プロダクトオーナー 開発チーム スクラム マスター 各役割とその使命については後述します。これらの役割を担い、 スクラム 開発を進める人たちを スクラムチーム と呼びます。 プロダクトオーナー プロダクトオーナー は開発しようとしているプロダクトのオーナーであり、プロダクトの最終責任者です。 プロダクトオーナーは「プロダクトのビジネス的価値」に着目し、プロダクトで実現したいことに優先順位をつけてリスト化した プロダクトバックログ を作成・更新・管理する役割を担います。プロダクトオーナーは 開発チーム にプロダクト バックログ を公開することで、なぜそのプロダクトを作るのかというビジョンと優先順位を理解してもらうよう努めます。 開発チーム 開発チーム はプロダクトオーナーが決定した要件を成果物として実現するメンバーの集まりです。 プロダクトの開発責任を担うのが開発チームであり、プロダクトに不具合がある場合や、プロダクトオーナーの定める品質基準に達しない場合にそれらの問題解決に努めます。 スクラム マスター スクラムマスター はプロダクトオーナーと開発チームが スクラム を実行する手助けを行います。 スクラム マスターは現場の スクラム のルールを熟知し、 スクラム チームが最高のパフォーマンスを発揮できるように働きかけます。開発チームが技術的困難に遭遇している場合は解決策を提示し、プロダクトオーナーがプロダクト バックログ の更新に問題を抱えている場合はアド バイス します。また、 スクラム チームの進捗に影響を及ぼす要因の排除や、 スクラム の理解が不足しているメンバーに対して コーチン グするなど、その役割は多種多様です。 まとめ（1） スクラム 開発における各役割とその関係の理解が少しでも進めば幸いです。 「要するにプロダクトの責任者と開発チームがいて、それらのサポーターを通して開発を進めるってこと？」 ...今は恐らくこれぐらいの認識ではないでしょうか。実際に スクラム を導入されるとそれぞれの役割の重要性が見えてくるかと思います。 「役割はなんとなく理解できたけど、どのように「 スクラム を実行する」の？開発以外のイベントって何？」 それでは次章以降、 スクラム 開発で発生するイベント（ スクラムイベント ）について解説します。 スクラム イベント スクラム 開発では、単に開発を進めるだけでなく、ソフトウェアの「透明性」を見出すためのアプローチを取る必要があります。そのために規則的に行われる5つのイベントがあり、これらを スクラムイベント と呼びます。 スプリント スプリントプランニング デイリー スクラム スプリントレビュー スプリントレトロスペクティブ スクラム イベントは定期的なミーティングとは違い、自分たちの スクラム のあり方に問題があれば解決し、より良い状況を作るために行います。このようにフィードバックを織り込んだイベントを実施することで開発を円滑に進めます。 スプリント スプリント は開発の イテレーション のことです。 スクラム チーム内で適当な期間を定めますが、通常は1週間〜3週間が多いです。 決められたサイクルで開発を進めることで、 スクラム チームで完了できる仕事量を把握します。 スプリントプランニング スプリントプランニング はスプリント開始時に行われる最初の スクラム イベントです。 「スプリント期間内で何ができるか（何をするか）」を明らかにするミーティングであり、 スクラム チーム全員が参加します。プロダクト バックログ で優先順位の高いものから順に完了できそうなものを選び、選んだ項目について具体的なタスク量を明確化するために適当な単位でタスクを分割してリスト化した スプリントバックログ を作成します。 デイリー スクラム デイリースクラム はいわゆる「朝会」であり、昨日したこと、今日やること、課題を共有する場です。 主に開発チームが行う スクラム イベントであり、スプリント期間中は決まった時間に毎日行います。そのスプリントのゴールが達成できそうかと、日々の仕事の進捗を把握します。また、デイリー スクラム には スクラム マスターも参加します。 スプリントレビュー スプリントレビュー はスプリントの成果物を披露し、プロダクトについてフィードバックを得るためのミーティングです。 スクラム チーム全員が参加します。 スクラム チームの他に ステークホルダー （ スクラム チームに所属しない会社の経営陣、あるいは顧客など）を招待する場合もあります。開発チームはスプリント期間内に達成できたことと、達成できなかったことを伝え、次回以降何をどう作っていけばいいか議論します。 スプリントレトロスペクティブ スプリントレトロスペクティブ はスプリント終了時に行われる最後の スクラム イベントです。 スクラム チーム全員が参加します。 いわゆる「振り返り」であり、 スクラム チームの現状を見直し、次回以降のスプリントでより良い仕事を行うための改善策を出していく場です。開発チームと スクラム マスターが中心になって進め、次回のスプリントに向けてのアクションプランを出します。 まとめ（2） スクラム 開発の進め方が理解できたでしょうか。本当はもう少し細かい話もあるのでが、ざっくりとまとめると 計画→開発→お披露目→振り返り→（以下、繰り返し） となります。 イテレーション が設定されているおかげで問題に気付きやすくなり、改善や後戻りしやすいシステムになっています。これこそが スクラム 開発の醍醐味であり強みでもあります。これから スクラム を始める人にとって、今回の記事が少しでも参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。このたび大阪Meetupの運営委員に任命されました！ 9月に東京でMeetupを開催しましたが、大阪でもやります！ rakus.connpass.com 新しくなった大阪オフィスは本当に良い環境で、広くなった セミ ナールームを早く活用したい！ということで移転直後から準備を進めてきました。 そんな大阪オフィスの様子は↓コチラをご覧ください。 www.wantedly.com テーマは『大阪開発チームのチャレンジ』です せっかくの大阪初開催ですので、大阪所属のエンジニアで トーク セッションを固めました。東京を中心として盛んに行われているITエンジニアの勉強会ですが、最近は大阪でも活発に行われていて私もよく同業他社の勉強会に参加させて頂いています。せっかく、梅田駅から徒歩5分という立地で セミ ナールームを拡充して環境も整ってきたので、我々も一緒に大阪のIT業界を盛り上げていきたいと思っています。今後はコミュニティへの会場提供もしていきたいので、この機会に新しいオフィスを覗いてみていただければと思います。 当日の トーク セッションは以下を予定しています。なお、 トーク 内容と順番は仮のものですので当日までに変更の可能性がありますがご了承ください。 チャットディーラーの高速開発を支えるLaravel 吉元和仁（よしもとかずひと） 今年夏に開催された PHPカンファレンス 関西 2018 の登壇内容をベースにお話しします。10年以上 PHP でノン フレームワーク により開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際に Laravel を選択しました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。 Why Mob Programming? - モブプロという働き方 - 大平直宏（おおひらなおひろ） 大阪の楽楽精算の開発チームでは、 スクラム 開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。 アジャイル な開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。 トウダン・ジャーニー 川並裕（かわなみゆう） 今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。 大阪のエンジニア同士で交流しましょう！ 今回は参加者のみなさまの中からもLTを募集いたします。テーマは同じく「チャレンジ」です。みなさまが普段チャレンジしていることを共有していただければと思います。そして トーク セッション後には交流会も開催します。弊社のエンジニアも含めて参加者同士で情報を交換し合い、エンジニア同士の交流を深めていければと思っています。 会場の場所や参加方法については以下のconnpassに掲載していますのでご確認のうえお申し込みください。みなさまのご参加をお待ちしております！ rakus.connpass.com