こんにちは MasaKu です。 先日、ブログでもご紹介しましたが、弊社もスポンサーとして協賛している PHPerKaigi 2019 に参加してきました。 phperkaigi.jp tech-blog.rakus.co.jp 発表が大変素晴らしかったことはもちろん、イベントの様々な趣向が面白く、充実したイベントでしたので是非とも参加レポートを書かせていただきたいと思いました。 各発表のスライドは以下の記事で大変丁寧にまとめられております。 qiita.com PHPerKaigi 2019 全体を通して感じたこと 普段、業務では PHP で開発を行っておりますが、社外のエンジニアの方で PHP を利用されている方にあまりお会いすることがなかったので、会場のいたるところで PHP の話で盛り上がっている光景がすごく新鮮でした。 技術系イベントでは twitter の ハッシュタグ が用意されていることが多いイメージですが、このイベントでは発表会場ごとに ハッシュタグ が用意されていました。 メインの ハッシュタグ 　・・・　 #phperkaigi A会場の ハッシュタグ 　・・・　 #phperkaigi #a B会場の ハッシュタグ 　・・・　 #phperkaigi #b そのため、発表を聞きながらつぶやいた内容をほかの参加者の方が拾って下さったり、何気なく疑問に思ったことをつぶやいたところ、発表後に発表者の方からご回答いただいたりすることもありました。 「 PHPerKaigi2019のサイトができるまで 」という発表では、PHPerKaigi 2019 のサイトを制作された企業様のアートディレクターの方が発表されていたのですが、サイトのコンセプトを「 参加者、スポーカーはもちろん、スタッフ、スポンサーも大いに楽しむ場 」とされていました。 speakerdeck.com イベント会場内に用意されたフリースペースでは、アンカンファレンスが開催されたり、参加者の方々が発表者の方と交流されていたりして和気あいあいとした雰囲気があり、まさにコンセプト通りのイベントだったと思います。 アンカンファレンスの予定ボード LT会場 想像以上に広い会場でした 印象に残った発表 様々な発表を聴講させていただいた中で、特に印象的だったものをいくつかご紹介させていただきます。 設計力を上げるバリエーションの見極め術 speakerdeck.com サービスを運用していると、当初は想定していなかったような新しい機能の追加などが発生します。 そのため、「変化」に強いプログラムを作ることが重要です。 いま開発している機能が「 今後の機能追加を考慮すると、こう作るべきだろうか？ 」という想像力を働かせながらプログラミングする能力が必要だと思いました。 発表の中でもおっしゃられていましたが、上記のような想像力は、業務知識をつけなければ身につかないものなので、コーディング力だけでなく、サービスに対する理解も重要だと改めて思った発表でした。 マニュアルにない引数を与えるとどうなる？ php -srcへのバグ報告をした時の話 speakerdeck.com PHP のバグを報告されたという発表でしたが、バグの報告のために必要な要点をまとめられていた内容が大変参考になりました。 PHP の公式から出ている バグ報告時のルール として以下のようにまとめられていました。 英語で報告してください １つのバグは１つの報告にしてください どういう目的のため何をしてどうなったのか報告してください 必要十分な情報量で報告してください 過去のバージョンのバグは報告しないでください 既に報告済みのバグがないか調査してください エラーメッセージの内容をちゃんと読んだ上で報告してください OSS にコントリビュートするということに対して、途方もなく高いハードルを感じていましたが、バグ報告については、開発時のトラブルの報告と似ていると思いました。 それと同時に、普段のトラブル報告の内容でも上記の観点に気をつけながら報告しなければならないと思いました。 バグが見つかった際は「 何をすればバグが再現するのか 」ということと「 関係の無い情報は混同させない 」ということを意識していきたいです。 【アンカンファレンス】 STEPUP プログラミング高速化！～「君、プログラミング早いね」といわれるために speakerdeck.com プログラミングを早くするための施策を４つのステップでご説明されていました。 STEP1: 書いて覚える STEP2: 綺麗に書く STEP3: 書き方を覚える STEP4: プログラミングをするプログラムを書く 特に重要だと思ったのはSTEP2の「 綺麗に書く 」だと思いました。 綺麗な書き方というのはプロジェクトによって様々です。 例えば、使用している フレームワーク が違ったりコーティングルールがあったりと、そのプロジェクトにおける最適な書き方がそれぞれ存在するため、ケースバイケースで書き方を調整していかなければいけません。 書き方に慣れていない時に急いで雑に書いたプログラムは簡単なミスが紛れ込んだり、バグが発生した際に修正コストが大きくなるプログラムになってしまいます。 しかし、プログラムを書き上げるまでに時間がかかったとしても、綺麗に書く事を気をつけておけば、もしバグが見つかったとしても修正箇所が見つけやすく素早く修正できます。 また、綺麗に書くことに慣れてくると、その書き方で素早く書き上げることができるようになってくるので、結果的にバグが少なく、読みやすいコードが短い時間で書けるようになります。 この観点は新しい書き方が増えるたびに更新していかなければならない内容なので、「できるようになった」と思っても気を抜かず、継続的に意識しておかなればならない内容だと思いました。 まとめ 何となく知っているキーワードを頼りに発表を聞くだけでも、「そういうことだったんだ！」といった気づきを得られ、そこから新しい興味も湧いてくるため、こうしたイベントへ参加することは本当にいい経験になると改めて思いました。 イベント自体も発表者と参加者が一緒に楽しめる趣向が盛りだくさんだったので、オーディエンスとしての参加ではありましたが、決して取り残されている感覚にはならないイベントだと思いました。 今後の PHP 関係のカンファレンスは以下のとおりです。 PHPカンファレンス 福岡 2019 PHPカンファレンス 北海道2019 PHPカンファレンス 沖縄 CakeFest - THE CAKEPHP CONFERENCE JAPAN 2019 - PHPカンファレンス 2019 残念ながら関西での開催は今のところありませんが、機会があればどこかにまた参加してみたいと思いました。 qiita.com 参考サイト PHPerKaigi 2019 PHPerKaigi 2019 に協賛します - RAKUS Developers Blog | ラクス エンジニアブログ PHPerKaigi2019 スライドまとめ - Qiita PHPerKaigi2019のサイトができるまで - Speaker Deck 設計力を上げる！バリエーションの見極め術 - Speaker Deck PHPのマニュアルにないことをしてphp-srcへバグ報告をした - Speaker Deck STEP UP プログラミング高速化 「君、プログラミング早いね」 / Step up! fast programming - Speaker Deck 2019年に開催される全国のPHPカンファレンスのまとめ - Qiita

こんにちわ、 @kawanamiyuu です。先週、 AWS 認定ソリューションアーキテクト - アソシエイト 試験（以下、SAA 試験）を受験してきましたので、勉強方法などを共有したいと思います。ちなみに、試験結果は 893 点 (/1000) で 合格 でした ε-(´∀｀*)ﾎｯ 筆者の AWS スキル感 AWS での基本的な冗長構成（ELB + Auto Scaling + RDS Multi-AZ）とか、 Well-Architected フレームワーク レベルのことはこれまでのエンジニア経験の中で知識としては知っている 以前このブログで紹介した かみせんプロジェクト などの技術検証系のプロジェクトで ECS などの流行りのサービスをちょこちょこ触ったことがある AWS でインフラを 0 から構築した経験はない 本番環境での AWS 運用経験はない ※ AWS を利用したサービスの開発に携わったことはありますが、インフラレイヤは当時ノータッチ 受験のモチベーション 現在開発を担当している新規事業（HR x Tech）で AWS を利用することが確定しており、いつまでも「知ったかぶり」ではツライ（笑）ので、 AWS の基本について一度ちゃんと理解しておきたかった 社内に AWS に詳しいエンジニアが少ないので、今後の キャラ立ち を狙って 勉強方法 学習期間 期間としては 2019/1 〜 2019/3 の約 3 ヶ月間 当初、2 月中に受験しようと計画していましたが、なかなか勉強時間がとれずなんとか年度末に受験できました 普段 Studyplus というアプリで勉強の記録を付けていて、実質の学習時間は 20 〜 30 時間でした 学習教材 ちょうどよいタイミングで 最新 の試験内容に対応した対策本が 2 冊出版されましたので両方購入して勉強してみました。 以下の順で勉強しました。 AWS Well-Architected フレームワーク の ホワイトペーパー 一通り読みました Amazon Web Services エンタープライズ 基盤設計の基本 発売日：2018 年 10 月 8 日 オンプレミスのコーポレートサイトをモデルに、 AWS のサービスを使って可用性、拡張性、セキュリティ、保守性を段階的に高めていくという内容で、 AWS の基本的なサービスについて理解できます 図も多くて非常にわかりやすかったです 各章末に SAA 試験を想定した問題がついていて、試験勉強にもうってつけでした www.nikkeibp.co.jp 徹底攻略 AWS 認定 ソリューションアーキテクト - アソシエイト教科書 発売日：2019 年 1 月 19 日 模擬問題をこなすために購入 65 問の模擬問題（PDF）がついています 教科書部分も一通り読みました。試験範囲の事項についてちょうどよいボリューム感でまとまっていて勉強になりました book.impress.co.jp 最短突破 AWS 認定ソリューションアーキテクト アソシエイト 合格教本 発売日：2019 年 2月 21 日 当初、こちらの購入予定はありませんでしたが、受験時期のズレに伴い追加購入しました 模擬問題をこなすために購入 65 問の模擬問題（小冊子）がついています 模擬問題の難易度は「徹底攻略 AWS 認定 ソリューションアーキテクト - アソシエイト教科書」より少し難しかった気がします こちらも教科書部分も一通り読みました 「徹底攻略 AWS 認定 ソリューションアーキテクト - アソシエイト教科書」と比較すると、「セキュアな複数階層アプリケーション（第 9 章）」「高可用性構成（第 10 章）」といった重要な事項によりページを割き、図を多用してわかりやすく解説されています gihyo.jp AWS Black Belt の AWS サービス別資料 対策本の学習と並行して読み進めました 「 AWS Well-Architected フレームワーク のホワイトペーパー」と「 Amazon Web Services エンタープライズ 基盤設計の基本」の中で登場したサービスについては一通り読みました aws.amazon.com AWS 公式の サンプル問題 （10 問）※無料 AWS 公式のオンライン模擬問題（25 問）※有料 試験本番 試験会場は京都の嵐山近くのテストセンターでした テストセンターでの試験は初体験だったので、ちゃんとテストを受けることができるか緊張しました リモート試験官とのチャットが日本語だったので安心しました 本番試験は 130 分で 65 問が出題されます。見直しも含めて 70 分くらいで回答完了しました 試験内容については AWS 認定プログラムアグリーメント のため詳しくは紹介できませんが、模擬問題よりも、より具体的な ユースケース について、 AWS サービスへのより具体的な理解が求められる設問が多かったです 受験してみて 試験勉強を通して、 VPC やサブネット、セキュリティグループ、IAM、オートスケールといった、セキュリティや可用性に関する AWS の基本のキといえるサービスや機能について理解することができ、とても有意義なチャレンジだったと感じています。 AWS への関心と期待、残りの AWS 認定取得へのモチベーションも高まっていて、今後、開発実務で AWS を活用しつつ、認定についても引き続きまずはアソシエイトレベル制覇を目指して AWS の経験と理解を深めていきたいと思います。 P.S. ちなみに、 ラク スにはエンジニアの資格取得を支援する制度があり、今回の受験料はしっかり経費として精算しました (-д☆)ｷﾗｯ

4月1日にパパになった 福岡@楽楽 労務 開発課 です。 めちゃめちゃカワイイです♪ さてさて、娘自慢はこれくらいにして、 参加者様から好評をいただいております弊社のもくもく勉強会、4月開催の告知も兼ねて3月の模様をお伝えしようと思います。 2月の模様はこちらから ↓ tech-blog.rakus.co.jp 3月実施の模様 ２月実施会の振り返りから、今回は次のような改善を実施しました。 BGMの音を途切れないようにする お菓子をとりやすい空気をつくる ■BGMの音を途切れないようにする もくもく勉強会のBGMは、ラズパイからラジオを流していました。 しかし、少し前からラズパイの処理的な問題なのかBGMが途切れ途切れになってしまっていたため、 スマホ から音楽を流すようにしました。 結果、途切れることはなく、より集中して学習する場になったのではと思います。 ■お菓子をとりやすい空気をつくる 事前にブログで周知した効果なのか、ガンガン減っていきました。 開始30分でほぼ半分にｗ 本来の目的としては、お菓子を取りに行った際にコミュニケーションが発生すればいいなーという思いから設定しておりました。 誰かがお菓子をとることで、お菓子をとりやすい空気＆食べながら交流するという空気が出来上がっていたように思います。 次回も皆さんガンガン消費して、ガンガン交流していただければと思います。 次回告知 次回は4月9日に開催予定です。 木曜日ではなく火曜日ですので、ご注意ください！ 既にconnpassに公開中ですので、興味を持たれた方は是非お越しください。 rakus.connpass.com

こんにちわ @kawanamiyuu です。株式会社 ラク スは、今週末に開催される PHPerKaigi 2019 に Silver スポンサーとして協賛しています。ちなみに、CfP も弊社から 3 名のエンジニアが応募しました。が、残念ながら不採択でした... 当日はスポンサー枠で弊社のエンジニアが 1 名参戦しますので、参加者のみなさまと一緒にイベントを楽しめればと思います！ イベント概要 日時 : 2019 年 3 月 29 日 (金) 〜 31 日 (日) 会場 : 練馬区 立 区民・産業プラザ Coconeri ホール 公式 HP : https://phperkaigi.jp/2019/ ハッシュタグ ： #phperkaigi phperkaigi.jp 「PHPer チャレンジ」企画 今回の PHPerKaigi では期間中の3日間「PHPerチャレンジ」という企画が開催されます。 PHP チャレンジ とは・・・ PHPerチャレンジは会場内外に隠された「PHPer トーク ン」を探しだし、イベントサイトに入力して得られたスコアを競う企画です。 PHPer トーク ンは「記号の# + 任意の文字列」の形をしています。 PHPer トーク ンはイベント公式のものに加えて、スポンサーから提供されるものもあります。 ラク スの PHPer トーク ンはコチラです！　→　 #RAKUSMeetup

こんにちは。 新卒1年目のbadaikiです。 はじめに まもなく入社して1年、配属されて9カ月、 PHP 歴9カ月になります。 PHP の記法にもつまることなくコーディングできるようになったので、そろそろステップアップを目指していきます。 そこで今回は v7.1 ～ v7.3 で追加された新機能の一部を紹介し、今後に活かしていきます。 はじめに 公式サポート期限 新機能 v7.1 nullableな型 void関数 対称的な配列の分解 クラス定数のアクセス範囲指定 v7.2 object型 抽象メソッドのオーバーライド v7.3 フレキシブルな HereDoc 構文と NowDoc 構文 array_key_first(), array_key_last() おわりに 公式サポート期限 昨年 2018年12月 をもって v5.6 が EOL (End Of Life) を迎えました。 バージョン 初回リリース日 最新リリース 最新リリース日 アクティブサポート セキュリティサポート 7.3 2018/12/06 7.3.1 2019/01/10 2020/12/06 2021/12/06 7.2 2017/11/30 7.2.14 2019/01/10 2019/11/30 2020/11/30 7.1 2016/12/01 7.1.26 2019/01/10 2018/12/01 (終了) 2019/12/01 7.0 2015/12/03 7.0.33 2018/12/06 2017/12/03 (終了) 2018/12/03 (終了) 5.6 2014/08/28 5.6.40 2019/01/10 2017/01/19 (終了) 2018/12/31 (終了) 上記に従い、現在セキュリティサポートありのv7.1～v7.3を対象としました。 新機能 v7.1 nullableな型 パラメータや返り値の型宣言で nullable 指定ができるようになりました。 v7.0 で取り入れられた 型変換 の型の前に クエスチョンマーク をつけると、nullable であることを指定できます。 nullable 指定をすると、指定した型だけでなく NULL も渡せるようになります。 <?php function returnString () :? string { return "Hello!" ; } function returnNull () :? string { return null ; } function dumpParam ( ? string $ str ) { var_dump ( $ str ) ; } var_dump ( returnString ()) ; var_dump ( returnNull ()) ; dumpParam ( "Hello!!!" ) ; dumpParam ( null ) ; 出力結果 string(6) "Hello!" NULL string(8) "Hello!!!" NULL void関数 戻り値の型として void が導入されました。戻り値の型を void と宣言した関数は、関数内での return 文を省略するか、あるいは空の return を使う必要があります。 void 関数から NULL を返すことはできません。何か値を返そうとするとエラーになります。 <?php function dumpParam () : void { var_dump ( "Hello!!!" ) ; } dumpParam () ; 出力結果 string(8) "Hello!!!" 対称的な配列の分解 配列の短縮構文 ( [ ] ) を使って、 代入用に配列の値を取り出せるようになりました (foreach でも使えます)。 これは、list() の代替として使えます (list() もまだ使えます)。 <?php $ colors = [ [ 'apple' , 'red' ] , [ 'banana' , 'yellow' ] ] ; echo "list形式 \n " ; foreach ( $ colors as list ( $ fruits , $ color )) { echo $ fruits . "'s color is " . $ color . ". \n " ; } echo "[]形式 \n " ; foreach ( $ colors as [ $ fruits , $ color ]) { echo $ fruits . "'s color is " . $ color . ". \n " ; } 出力結果 list形式 apple's color is red. banana's color is yellow. []形式 apple's color is red. banana's color is yellow. クラス定数のアクセス範囲指定 クラス定数のアクセス範囲を指定できるようになりました。 <?php class ConstDemo { const PUBLIC_CONST_1 = 1 ; public const PUBLIC_CONST_2 = 2 ; protected const PROTECTED_CONST = 3 ; private const PRIVATE_CONST = 4 ; } v7.2 object型 object型 が新たに導入されました。 任意のオブジェクトに対する (反変) パラメータの型付けや (共変) 返り値の型付けで使えます。 <?php function test ( object $ obj ) : object { return new SplQueue () ; } test ( new StdClass ()) ; 抽象メソッドのオーバーライド ある抽象クラスが別の抽象クラスを継承しているときに、 継承元クラスの抽象メソッドをオーバーライドできるようになりました。 <?php abstract class Animal { abstract function call ( $ str ) ; } abstract class Dog extends Animal { abstract function call ( $ s ) ; } v7.3 フレキシブルな HereDoc 構文と NowDoc 構文 v7.2 以前の HereDoc 構文と NowDoc 構文 <?php //HereDoc 構文 echo <<< HERE abc \n HERE ; //NowDoc 構文 echo <<< 'NOW' def NOW ; v7.2 の HereDoc 構文と NowDoc 構文では以下の記法により制限されていました。 終端 ID はインデントのものにします。 終端 ID のある行にはスペースやタブなどの文字を含めることはできません。 終端 ID の前の最初の文字は改行にします。 終端 ID の後に改行します。 v7.3 以降では記法が改善されます。 終端 ID のインデント、行頭スペースの削除が可能になる 終端 ID の改行要件が削除される よって以下のように書くことで同じ結果が得られます。 v7.2 <?php $ values = <<< END a b c END . ' d e' ; v7.3 <?php $ values = <<< END a b c END . ' d e' ; array_key_first(), array_key_last() v7.2 以前では reset()、end() および key() 関数を使用して配列の最初と最後のキーを取り出すことができます。ただし、配列の内部ポインタを先頭や末尾に移動させてしまうため、コードの可読性とパフォーマンスが低下してしまいます。 v7.3 では array_key_first(), array_key_last() を追加しました。この関数は配列の内部ポインタに影響を与えずに先頭、末尾のキーを取得することができます。 おわりに 今回、v7.1 ～ v7.3 のバージョンアップで追加された新機能について一部を紹介しました。知っていれば取り入れられたなと思うものやどのように使えばよいのかわからないもありましたが、今後もバージョンアップにもアンテナを張り、追加された新機能や関数を使いこなしていきたいと思います。

株式会社ラクス でエンジニア リングマ ネージャをしているmzwkunです。 先月開催された Developers Summit 2019 にて、 AWS の方が『 イノベーション を支えるアマゾン文化』というテーマを発表されていたので、普段行っている自分たちの開発スタイルと比較して、特に気になったところをピックアップしていきます。 多彩で使いやすいサービスを提供されている AWS さんと比較して学べればと思っています。 AWSのイノベーションの文化 AWSのイノベーションのための組織づくり AWSのアーキテクチャ AWSのカルチャー AWSの組織 Every day is still Day One. AWS の イノベーション の文化 顧客に徹底的にこだわる、顧客を起点に行動する 長期的視点での継続した投資 ビジョンにはこだわるが、詳細なことは柔軟に対応 もし創造的でありたいなら失敗を恐れない ラク スには リーダーシッププリンシプル があり、少し表現は違いますが以下と合致しそうだと感じました。 「やるべきことを実行する」「小さく試して大きく育てる」「誠意をもって人と接する」「失敗を許容する」 自分のやりたい事ではなく、顧客視点や失敗を恐れないでチャレンジする点は イノベーション の起点ですね。 AWS の イノベーション のための組織づくり 新サービス開発を行う際にまずはプレスリリースとFAQを作る FAQは顧客と ステークホルダー （社内関係者）の両面を含める 会議でプレゼンツールはあまり使わず見た目に委ねないようにする（見栄えで騙されないように） 6pagerと呼ばれるレポートを作り事前に読んでおく（ナラティブ【物語】とも呼ばれている） 目的や効果を定めるために真っ先にプレスリリースを作るのは興味深い行動ですね。 私達の開発では「要求仕様書」というドキュメントを企画と開発、関連部署で作成して意識を合わせるようにしています。 そこには要求概要や機能要求など定めるべき当然なものから、保守・品質・性能・運用・サポートといったサービス全体に必要と思われるものが記載されています。 プレスリリースは作れていませんが、 ステークホルダー の視点は全て集約できるようにし、レビューによって多様な立場からの意見を受け入れるようにしています。 AWS の アーキテクチャ 単一目的のサービス HTTPS の API のみによる通信 お互いのサービスは ブラックボックス に DevOpsを推進（テストを重視、自動化を重視） マイクロサービスを前提にテストや自動化の重視と奇をてらうこと無く基本に忠実でした。 ラク スでもDevOpsは外部に任せず内製で力をつけながら進めています。 AWS のカルチャー 5 whys （いわゆる、なぜなぜ） ドアデスクがある　創業時にドア用の板を簡素な机にしていた　※倹約を忘れないように！ スピード　過剰な分析、過剰な議論よりもプロトタイプを作ってみる ベストを尽くす　高い目標、メンタリング、ピアフィードバック QCD、ロジカル、インタ ラク ションというキーワードになりそうです。 ロジカルは ラク スでも古くからの重要な文化であり、インタ ラク ションも最近重要視されていて、1on1ミーティングや コーチン グというワードが飛び交っています。 そこからどのような行動に移しているかは今後ご紹介したいと思います。 AWS の組織 2-Pizza Teams　必ず目が行き届くように QA、障害対応、運用はすべて自チーム内でやる 早く経験し、繰り返す レビュー待ち状態は厳禁！ やはり10人以下のチーム構成による、きめ細やかなコミュニケーションを土台としたチーム開発が重要そうです。 ラク スでもメンバーを増やすだけではなく、リーダーやマネージャも積極的に育成や採用をして不自然な構成にならないよう努めています。 自チーム内でやるというのも、全てを内製で進めている ラク スと似ています。 レビュー待ち厳禁は少し耳の痛い言葉ですが、リーダーの皆さんが頑張って効率性を守ってくれています。 Every day is still Day One. 毎日が常に「Day One」である 最初の一歩を踏み出す日 新たな挑戦を心待ちにする日 そして今日が、皆様にとっての「Day One」 素晴らしい考え方ですね。素直に参考としたいです。 いろいろと見ていきましたが、共通となりそうな点も多く、自分たちのやっていることにさらに自信が持てそうです。

はじめに こんにちは。 年末に http://www.java-users.jp/ccc2018fall/#/ に参加してきましたので、少し期間が空いてしまいましたが、聴講したセッションについて投稿します。 当日のタイムテーブル、資料は下記をご覧ください。 https://docs.google.com/spreadsheets/d/1cyNPjk8doq26FgjhLVwA0Pw2grGFwxqo4yVXqJgQCTE/edit#gid=413114967 qiita.com はじめに 参加セッション セッション感想 IBM CloudとKubernetesでSpring Bootのマイクロサービスを簡単に！ エムスリーでのKotlinへの取り組み Java を活用したマイクロサービスのための Kubernetes 活用 終わりに 参加セッション https://jjug-cfp.cfapps.io/submissions/017fc549-8d12-49dc-bb20-08ed3c9ccbb2 https://jjug-cfp.cfapps.io/submissions/331c1102-be76-4e17-bf7c-43f55dbc73da https://jjug-cfp.cfapps.io/submissions/cf4aefdb-b146-449e-9350-66f581900a84 セッション感想 IBM Cloudと Kubernetes でSpring Bootのマイクロサービスを簡単に！ IBM クラウド 上に Kubernetes の クラスタ を作成して、DBの構築、事前にDockerイメージとして作っておいたSpring Bootの Java アプリケーションをデプロイしてサービスを構築していくセッションとなっていました。 先日からDocker周りに興味が湧いているところなので、次は Kubernetes に手を出すいいきっかけになりそう。 エムスリーでのKotlinへの取り組み 運用中の Java アプリケーションをKotlinに移行する話。 移行の方法としては３通りほど考えられていましたが、今回は「全部まとめて書き換える」方法を取られていました。 コンバート中は完全に機能開発を止めて、移行をすることに集中、余計なことはしない、短期間に完了する。 移行作業のノウハウを学ぶことができ、システムをAからBに移行するぞとなった時の参考になりそうです。 Java を活用したマイクロサービスのための Kubernetes 活用 かなり内容の濃いセッションになっていて、 k8s にまだ触れていない私は少々パンク気味でしたが、今後自身で K8s を触る時の参考になるTips紹介が多かったです。 Docker関連 Dockerイメージの取得時、いつのバージョンかわからなくなるのでlatestは使わないこと! 小さなサイズのイメージをつくるように! DockerHubのイメージは安全か? 信頼されてないイメージは 脆弱性 が含まれている可能性はある。 本番利用するならセキュリティチェック・検証はしましょう。 k8s 関連 利用用途によって、向き不向きあるので何でもかんでも k8s でというのはやめましょう。 k8s は色々できるけど、全ての機能を使う必要はない！ 後々のメンテナンスのことも考えてシンプルな構成にしておくのがおすすめ。 k8s のバージョンアップには要注意！ 今まで動いていた yaml では動かなくなる可能性がある。 新しく クラスタ を作成して、動くことがわかってからルーティングを変えて対処しましょう Docker、 k8s に関してはまだまだ初学者であるため、触り程度でしかわかっていない部分がありますが、今後触っていく際の有益な情報になりました。 何でもかんでも k8s でというのはやめましょう。 私もよく言われていて耳が痛いですが、手段ベースでものを選んではいけないの典型ですね。 終わりに JJUG には昨年度から参加していますが、昨年よりも内容がわかるようになっている自分を感じることができました。 同じテーマで複数の発表があれば今のトレンドの技術はこれなのかな？といった業界の流れのようなものも少し感じられた点も昨年から参加していた成果かと思います。 若手にとって、はじめての勉強会やカンファレンスへの参加は足が重い人が多いかもしれませんが、大きめのカンファレンスは参加のハードルも低いので、１ヶ月後に入社する新メンバーにもオススメしてあげたいです。

こんにちは。新卒1年目エンジニアのbadaikiです。 はじめに 今回は、先日大阪オフィスで開催された3月ビアバッシュをご紹介いたします。 前回のビアバッシュの記事はこちらです。↓ tech-blog.rakus.co.jp はじめに テーマ枠発表 自由枠発表 サービスの環境構築 1年間で得た新たなCSSの知識 おわりに テーマ枠発表 今回のテーマは、「トラブル事例特集」。今年度に発生したトラブルを発表していただきました。 「今年度のトラブルは今年度のうちに」ということで、何が原因でどのように対処したのか、各チームに当時の心情も込めてお話していただきました。 共有したいところなのですが、ほとんどの内容が社外秘の内容のため以下は発表全体の総括になっております。 全部で5つのサービスで起きたトラブルを発表していただきました。 なかには「リリース日と震災が重なったことで出社できた社員が2名という状況下で発生したバグ対応」というものもあり、そういうこともあり得るのだと知りました。 トラブルを起こさないことが一番ではありますが、トラブルが起きてしまったときに如何に冷静かつ迅速に対応できるかが重要になると感じました。すぐには難しいですが、いずれは私もトラブルの対応ができる技術を身につけていきたいです。 これまで配属されてからほとんどのビアバッシュに参加してきましたが、いつものビアバッシュと比べて緊迫感があったような気がしました。 自由枠発表 テーマ枠のほかに自由枠発表もありました。 テーマ枠とは異なり、今自分が気になっていること、伝えたいことを題材に2名の発表者が登壇してくださいました。今回は2名とも新卒1年目の若手が発表していただき、最近つまったことや今年度を振り返った内容となっていました。 サービスの環境構築 チームに新しく参入するメンバーの環境構築や開発の準備を行った際に、苦戦した点を発表していただきました。 あと3か月ほどすれば新卒の後輩が私のチームにも配属されるため、私も他人事ではないなと考えながら聞いておりました。 手順書に記載されている通りに行うのではなく、なぜこの スクリプト を叩く必要があるのか、なぜこの作業が必要なのか、を考えながら作業をしていくべきだと感じました。 1年間で得た新たな CSS の知識 新卒1年目のメンバーが配属してからの期間で得た CSS の知識について発表していただきました。 この方は学生のときから CSS に興味があり使っていたそうなのですが、業務レベルにはまだ達していなかったことを痛感したそうです。 私も学生のときに得た知識だけでは足りないと思う節がこの一年間だけで多くありました。今の知識だけで十分だと慢心せずに積極的に技術を吸収することの重要さを再認識いたしました。 最後には彼の今後の成長意欲を感じました。 おわりに 普段はあまり聞くことができない各サービスのトラブルについて聞くことができました。直で聞くことにより、当時の緊迫感なども伝わり普段のビアバッシュとは一風変わったビアバッシュだったのではと感じました。 私自身はまだ大きなトラブルに見舞われたことはありませんが、発生時には慎重に対応していきます。 ラク スでは同じような問題を二度起こさないよう、開発全体で起きた問題やその対処法を共有しております。 過去の知見を活かし、障害を乗り越え、 ラク スのサービスは進化していきます。

はじめに はじめまして、新卒1年目のエンジニアのmrym_618です。 今回は、Schooで JavaScript について学習してみましたので、その感想を書いていきます。 目次 はじめに 目次 Schooとは 実際に学習してみた Schooとドットインストールの比較 まとめ Schooとは Schoo(スクー)とは、大人たちがずっと学び続ける生放送コミュニティであり、参加型の生放送授業と、4,600授業以上の動画教材で 「仕事に活きる」知識・スキル・考え方を学べるサービスです。 schoo.jp 特徴 プログラミングやWebデザインなどのIT分野以外にも英語やビジネススキル、企画・ マーケティング など幅広い分野の授業がある 生放送ならではの講師や生徒同士でのリアルタイムなコミュニケーションをとることができる PCだけでなく、 スマートフォン 、アプリからも利用することができる 実際に学習してみた 今回は、業務でも使うことが多い JavaScript について改めて学習したいと思い、 JavaScript 入門を受講してみました。 また、ドットインストールでも JavaScript についての学習を行い、Schooとの比較をしてみました。 schoo.jp Schooとドットインストールの比較 Schoo 講義ベースなので、基礎からわかりやすく学習できる 講師の方が実際のエンジニアの方なので、現場ではどのように使われるかを話してくれる ドットインストール 一つ一つの項目を短時間で学習することができる 知りたい項目をピンポイントに学習できる 新しいことなど基礎 からし っかり学習したい場合は、Schooで学習した方が分かりやすいと感じました。逆に、ある程度知識があり、短時間でピンポイントに学習したい場合は、ドットインストールで学習する方がいいと感じました。なので、どのように学習したいかによって使い分けることが大切だと思いました。 まとめ 今回は、Schooで JavaScript について学習しました。Schooは、新しいことを基礎 からし っかり学習するには分かりやすいと感じましたので、今後も様々な分野を学習するときに活用していきたいと思います。

はじめに こんにちは、新卒で入社して3年目のnorth_mkyです。 最近業務で SQL チューニングをする機会があったので、実行計画を読み解く記事を書こう！...と思いたったのですが、記事を書くにあたってサービスのデータベースを使うわけにはもちろんいかないので 適度なサンプルデータベースを作成し、 大量のデータを投入する という準備作業を行う必要がでてきました。 今まで大量のデータを入れるという作業はあまりしたことがなかったため、備忘も込めて当初予定していた記事を書く前に大量データの投入について述べたいと思います。 はじめに PostgreSQLに大量データを投入する方法は大きくは2つ generate_series()関数を使用する方法をおすすめする3つの理由 1. 大量データ投入処理までの準備はなし 2. 学習コストがほとんどない 3. 実行時間がCOPYコマンドと変わらない generate_series()関数を使用した大量データ投入方法とは 検証 : COPYコマンド VS generate_series()関数 環境 サンプルデータベース 結果 おわりに PostgreSQL に大量データを投入する方法は大きくは2つ 色々探していると、大きくは下記2つが投入方法として出てきました。 CSV ファイルをインポートする方法 generate_series()関数を使用する方法 1. は postgresql が用意しているCOPYコマンドを使用する方法です。公式のお墨付きです。 14.4. データベースへのデータ投入 データベースにデータを初期投入するために、大量のテーブル挿入操作を行う必要がままあります。 本節では、この作業を効率良く行うためのちょっとした提言を示します。 (中略) 単一コマンドですべての行をロードするために一連のINSERTコマンドではなく、COPYを使用してください。 COPYコマンドは行を大量にロードすることに最適化されています。 https://www.postgresql.jp/document/10/html/populate.html ですが、公式の言葉を押し切って今回私は 2. generate_series()関数を使用する方法 をおすすめします。 generate_series()関数を使用する方法をおすすめする3つの理由 1. 大量データ投入処理までの準備はなし 両者の作業手順は以下になります。 投入方法1では大量データを生成する→生成したデータをインポートする、というデータ投入前にデータを用意する準備作業が発生しますが、投入方法2では データ生成→データインポートの両方の処理をSQL1文で行ってくれる ため、投入するまでにかかる準備はありません。generate_series()関数は標準で入っているので拡張モジュールの読み込み等も不要です。 CSV ファイルをインポートする方法 CSV ファイルを生成する スクリプト を作る 作成した スクリプト を実行する COPYコマンドに適切な引数を与えて実行する generate_series()関数を使用する方法 大量データを生成する SQL を作る(generate_series()関数を使用) SQL を実行する 2. 学習コストがほとんどない 投入方法1の CSV ファイル生成 スクリプト は自分の好きなやり方で組めばいいのでそこまで時間はかかりませんが、鬼門はCOPYコマンドだと思います。COPYコマンドはおそらく大量データの投入か、既存テーブルの別テーブルへの複製に使うと思いますが、いざ使おうとすると色々お作法に馴染みがなく手間取ってしまいます。 COPY table_name [ ( column_name [, ...] ) ] FROM { 'filename' | PROGRAM 'command' | STDIN } [ [ WITH ] ( option [, ...] ) ] ここでoptionは以下のいずれかです。 FORMAT format_name OIDS [ boolean ] FREEZE [ boolean ] DELIMITER 'delimiter_character' NULL 'null_string' HEADER [ boolean ] QUOTE 'quote_character' ESCAPE 'escape_character' FORCE_QUOTE { ( column_name [, ...] ) | * } FORCE_NOT_NULL ( column_name [, ...] ) FORCE_NULL ( column_name [, ...] ) ENCODING 'encoding_name' https://www.postgresql.jp/document/10/html/sql-copy.html ファイルパスの指定1つにしても windows と linux で異なるのはもちろんのこと、投入するカラム値に空白が入っている場合の扱いを指定したりなど、馴染みのない人間にとっては トライアンドエラー で時間がかかります(私は5-10分かかりました)。 一方投入方法2はいつもどおり SQL を作成するだけなので学習コストは ほぼなし です。 3. 実行時間がCOPYコマンドと変わらない これは実測して驚いたのですが、両者とも 投入時間はほぼ変わらない という結果になりました。 公式のお墨付きのCOPYコマンドと同等の処理性能で、準備に時間がかからないというので私はこのgenerate_series()関数を使用する方法をおすすめします。 generate_series()関数を使用した大量データ投入方法とは 「顧客テーブルに1000万行のデータを入れる。名前は" ラク ス太郎n"にする(n=1...10,000,000)」 上記を満たす大量データ生成 SQL は以下になります。 1000万行が入った1GB超のファイルを用意する必要はありません。SQL1文で作成できます。 INSERT INTO customer (id,name) SELECT i, format('ラクス太郎%s', i) FROM generate_series(1,10000000) as i ; SELECT 部分だけを打つと下記が返ってきます。 ?column? | ?column? ----------------+------------------------ 1 | ラクス太郎1 2 | ラクス太郎2 ... 10000000 | ラクス太郎10000000 連番を生成し、集合として返すgenerate_series()関数を応用すると、このようにその場でテーブルを作るようなことができ、大量データを投入することができます。他にも上述のformat()関数のようにrandom()関数などと組み合わせるといい感じの大量データを手軽に作成することができます。 検証 : COPYコマンド VS generate_series()関数 あるテーブルに1000万行を投入する処理の経過時間を計測しました。 環境 Mac OS10.14, メモリ8GB postgresql 11 postgresql .conf shared_buffer=128MB wal_level = minimal # アーカイブ をoffにする サンプルデータベース PostgreSQLTutorial.com のサンプルデータベースを使用しました。 チューニングの記事を書く目的だったため、ある程度外部キー制約があったりカラム数があったりするデータベースはないかな、と探していたらすぐにこのデータベースが見つかりました。 http://www.postgresqltutorial.com/postgresql-sample-database/ 結果 両者ともほぼ同じ結果になりました。 COPYコマンド dvdrental=# COPY customer (store_id,first_name,last_name,email,address_id,activebool,create_date,last_update,active) FROM '/Users/north_mky/customer.csv' ( delimiter ',', format csv, header true ); COPY 10000000 Time: 556051.126 ms (09:16.051) generate_series()関数 dvdrental=# INSERT INTO customer (store_id,first_name,last_name,email,address_id,activebool,create_date,last_update,active) dvdrental-# SELECT dvdrental-# 2, dvdrental-# 'Austin', dvdrental-# format('Cintron%s', i), dvdrental-# format('austin.cintron%s@sakilacustomer.org', i), dvdrental-# 605, dvdrental-# 't', dvdrental-# '2006-02-14', dvdrental-# '2013-05-26 14:49:45.738', dvdrental-# 1 dvdrental-# FROM dvdrental-# generate_series(1,10000000) as i dvdrental-# ; INSERT 0 10000000 Time: 558479.994 ms (09:18.480) おわりに generate_series()関数は大量データの投入に対して、楽に導入できて楽に使える関数です。 テスト時に大量データが必要になった際の手助けになれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

RAKUS Meetup のロゴ @moomooya こと 勉強会最速オジサン を目指している鈴木です。 先日弊社にて RAKUS Meetup Tokyo #2 フロントエンドNight と称したイベントを開催しましたので、そちらのイベントレポートを投稿します。 いつもはイベント閉幕後3秒以内にレポートを公開しているのですが、今回は1,688,400秒ほど経過してしまいましたorz 当日の様子 発表の紹介 Vue.js の新規プロダクトで楽して UI を提供しようと思ったらそこまで楽じゃなかった話 話の経緯と発端 選択の成否 鈴木の感想 既存 Web アプリケーションへの React.js 適用 話の経緯と発端 React 導入にあたってやったこと 既存実装との共存と、その後の課題 鈴木の感想 Vue.js を初めてプロダクトに導入して直面した課題と得られた幸せ プロダクトに Vue.js を導入してぶつかった課題 Vue.js を採用して幸せだったこと 懇親会 次回開催について 当日の様子 RAKUS Meetup Tokyo #2 会場の様子 今回は30人の募集枠を予定していたのですが、予想外の好評につき会場をグループ企業である ラクスパートナーズ のオフィスに変更しての開催となりました。 当日は雨も降る 悪天候 の中ご参加いただきありがとうございました。 発表の紹介 Vue.js の新規プロダクトで楽して UI を提供しようと思ったらそこまで楽じゃなかった話 好きな言葉は YAGNI と "Done is better than perfect." *1 という弊社デザイナー竹川の発表です。 新規サービスで利用する UI フレームワーク を選定した時の話です。 話の経緯と発端 新規サービス開発プロジェクトに スクラム 開発のプロダクトオーナーとして参画。プロジェクトの方針が 「提供してから考えよう」 というものだったため、UIについてはどんどん変わるものとして自前での作り込みを避ける方向に意思決定したとのこと。 選択肢として Bootstrap か Material Design か検討したところ、仕様として技術レイヤから独立している Material Design を採用することに。 さらに主だった3種類の UI フレームワーク のなかから Vuetify を採用。 Material Design な UI フレームワーク の特徴比較 選択の成否 ただし、現状ではどの選択肢も完璧ではない様子。一時は選定をミスしたと思い再度検証したものの、 Material Design の仕様に対する充足度はどれも一長一短である ことがわかった。採用した Vuetify の作者は Twitter 上でこのように発言している。 One thing I've learned over the years working with @materialdesign is that there are so many inconsistencies between the spec and their web components. It's frustrating, but in the end works out for the user because we are going to make sure both are supported. — John Leider (@zeroskillz) 2019年1月6日 「仕様と公式実装の差異も多いが、 UI フレームワーク 側で吸収していくしかなさそう」（意訳） 鈴木の感想 「Bootstrap は Twitter Geek 向け」 というなかなかパンクな発言が面白かったです。 既存 Web アプリケーションへの React.js 適用 dev ドメイン 購入予定の ポケモンGO オジサンで、弊社楽楽明細リードエンジニアの三田の発表です。 2017年後半に 楽楽明細 の新機能を開発する際に React.js を導入した話です。 話の経緯と発端 既存のフロントエンドの実装は jQuery を用いたものだったが、このとき開発する機能はフロントエンドの要件が複雑なものだった。 DOM を基軸に操作を行う jQuery では状態の管理が難しく 、フロントエンド フレームワーク の導入を検討。 選定当時は特に日本国内で React.js が突出して流行っていた。JSX の見た目の インパク トとは裏腹に覚えることが少なく、 マークアップ をシンプルに保てそうだったことが魅力に感じた。加えて、流行っていたため情報量が多いこともプラス評価になった。 React 導入にあたってやったこと 導入にあたってはチーム内で小さなツールを開発してみた。実際に開発してみると state と props の管理が大変だったため、最初から Redux を採用することに。 小さく試してみることは大事 だった。 さらに ES2015 勉強会をチーム内で開催。資料として WEB+DB vol.87 は神号 なのでオススメ。 既存実装との共存と、その後の課題 jQuery との共存はできていて、適材適所に使い分けている。本番移行後に React に起因したバグはまだ起きていない 。 当時まだ v15 系だったので現在 v16 系への以降を頑張っているが、破壊的な変更もあり少しつらい。 他画面への適用は簡単な画面でも適用するべきかどうかなど悩んでいるが、古いシステムを少しずつ React に置き換えていくことは可能そう。 鈴木の感想 「人類にDOMを扱うのは難しすぎる」 という発言がすごくわかりみが深かったです。DOM ベースで複雑な状態管理はすごく難しいです。 ちなみにスライド5枚目の 出番のないSさん は私のことです（当時楽楽明細開発チームにいました）。 余談ですが、 楽楽明細もついに CM を作ってもらえました 。 Vue.js を初めてプロダクトに導入して直面した課題と得られた幸せ Qiitaで勉強会最速オジサンを目指している 弊社エンジニア鈴木（私のことです）の発表です。 竹川の発表にも出てくる 新規サービス の開発に Vue.js を導入した話です。 弊社のサービスでは一部 Vue.js を採用しているサービスはあるものの、プロダクションレベルで全面的にフロントエンド フレームワーク として Vue.js を導入したのは今回のプロジェクトが初でした。 ちょうど私がこのプロジェクトに参画する際に Vue 熱が高まっていたこともあり、 半ばゴリ押しで 採用にこぎつけました。 とはいえ本格的に利用するにあたって以下のような課題にぶつかりました。 プロダクトに Vue.js を導入してぶつかった課題 アロー 演算子 使えない 初期化時に存在しないプロパティをオブジェクトに追加するときは注意が必要 ライブラリ間で要素名が衝突してしまうと動作しなくなる セオリーがわからない けどスタイルガイドが充実しているので熟読すると答えが書いてあることが多い Vue.js スタイルガイド Vue.js コンポーネントスタイルガイド Vuex使いすぎ？問題 コンポーネント に閉じるような非同期なデータ取得処理 *2 も Vuex に実装していた React （というか Redux ）だとそれが正解らしい *3 ですが、Vue だと コンポーネント に実装したほうが扱いやすかった mixins 使いすぎた props やローカルステートを mixins で定義してしまい、 mixins が解決されるまでの一瞬の間 undefined になって困った Vue.js を採用して幸せだったこと 単一ファイル コンポーネント は本当に幸せ ドキュメントが充実しているのも本当に幸せ 最近、 弊社の大平 も ローカライズのコントリビューターになっています React + Redux やってた人なら考え方が近いので Vue + Vuex もスムーズに入れて助かった 懇親会 お約束の Sushi と Pizza と Beer を用意しました 次回開催について 次回の東京での開催は5月に 「BtoBサービスが自社DCに Amazon S3 互換ストレージを導入したときの苦悩」 をテーマに開催予定です。 今月3月の後半には募集を開始できると思います。 Connpassのグループ に入っていただけると通知が飛びますのでそちらもよろしくおねがいします。 *1 : Facebook 本社の壁に貼られているという標語。日本では「完璧を目指すよりまず終わらせろ」と訳されている。 *2 : API 叩いてデータ取得するような処理 *3 : 懇親会で教えていただきました

はじめに こんにちは。エンジニア1年目のy_kwmtです。先日、業務でpuppeteerを用いてE2Eテストのテストコードを実装しました。E2Eテストとは、End to Endテストの略で、開始から終了までアプリが期待通り動くか確認するテストです。今回はpuppeteerの学習をするためにpuppeteerを用いて自動で ラク スのエンジニアブログサイトにアクセスしたことについて書きたいと思います。 目次 はじめに 目次 puppeteerとは 導入方法 コーディング、実行 最後に puppeteerとは puppeteerは、Node.jsでHeadless Chrome を自動で操作できるようにするライブラリです。puppeteerを用いることでクリック、テキスト入力、画面遷移などが自動で行えます。 公式サイトはこちらです。 github.com 導入方法 今回はこちらの記事を参考にインストールを行いました。 tech-blog.rakus.co.jp まずはNode.jsとnpmをインストールしてください。 Node.jsは こちら からダウンロードを行い、 インストーラ を実行し、画面の指示に従ってインストールしてください。npmのインストールは以下を実行してください。puppeteer は操作結果を Promise で返すので、async/await が使えるv7.6.0 以降のバージョンを用意したほうがよいです。 npm init Node.jsとnpmのインストールが完了したら、puppeteerのインストールを実行します。 npm i puppeteer コーディング、実行 puppeteerのインストールが完了したら、コードを書いていきます。コードはこちらのページを参考にさせていただきました。 webbibouroku.com 以下のファイルを実行して ラク スのエンジニアブログにアクセスします。今回は実行できているか確認するためにブラウザを表示するだけでなく、 スクリーンショット も撮影しました。そのコードがこちらです。 ファイル名：sample.js const puppeteer = require( 'puppeteer' ); (async () => { //ブラウザを定義(headless:false ブラウザを表示する, true 表示しない) const browser = await puppeteer.launch( { headless: false } ); //タブを定義 const page = await browser.newPage(); //ブラウザのサイズを定義 await page.setViewport( { width: 1240, height:1080 } ); //待機 async function sleep(delay) { return new Promise(resolve => setTimeout(resolve, delay)); } // Googleにアクセス await page. goto ( 'https://www.google.co.jp/' ); // 検索窓に「ラクス　エンジニアブログ」と入力 await page.type( '.gLFyf' , 'ラクス　エンジニアブログ' ); //スクリーンショット撮影 await page.screenshot( { path: 'google.png' } ); // 検索ボタンクリック //待機時間を設けないと止まってしまうことがあるので記述 await sleep(5000); await page.focus( 'input[name="btnK"]' ); await page.click( 'input[name="btnK"]' ); //待機時間を設けないと止まってしまうことがあるので記述 await sleep(5000); //スクリーンショット撮影 await page.screenshot( { path: 'search_result.png' } ); // 検索結果の先頭リンクをクリック await page.click( '.rc > .r > a' ); //スクリーンショット撮影 await page.screenshot( { path: 'blog.png' } ); //ブラウザを閉じる await browser.close(); } )(); コードを書いたら、コマンドでファイルを実行します。 node sample.js 実行中に撮影した スクリーンショット がこちらです。 google . png search_result. png blog. png 最後に 今回はサイトにアクセスするという簡単な動作でしたが、puppeteerを0から始めてファイルを実行することができました。今後、また業務でpuppeteerを使うとなった時のために、これからも勉強を続けて複雑な動作を自動化できるよう頑張ります。

id:radiocat です。2/26に大阪オフィスで実施したMeetupでは楽楽精算開発2課のメンバー全員で半年かけて準備をして発表しました。今回はMeetupの内容と合わせて、全員で役割を持って取り組んだ勉強会発表プロジェクトの内容をご紹介します。 rakus.connpass.com プロジェクトの経緯 私たち楽楽精算開発2課は成長サービスを支える開発組織として、常に新しい領域の開発に取り組んできました。一方で、開発部門としてMeetupというイベントを継続的に開催していくことになり、私たちのチームがどう関わっていくべきかを考えた時に、チームでイベントのコンテンツを作り上げるという新しいチャレンジを行ってその知見を残すことが私たちのチームらしい取り組みではないかと考えました。そして2月のMeetup発表者としてチームで名乗りを上げてプロジェクトをスタートさせました。 2018年10月にプロジェクトスタート 前回のMeetup の開催翌月にキックオフを行いました。 まず、どういうイベントにしたいかを全員で話し合って、発表テーマの候補を出しました。その中からいくつかのテーマに絞り込んでそれぞれのメンバーがいったん持ち帰り、次回までに発表テーマを検討することにしました。 11月 前月にそれぞれが持ち帰って検討した発表テーマと発表のイメージを共有して、イベントの全体像をすり合わせしました。 この時にそれぞれのメンバーが担当する発表内容の大枠が決定しました。若手メンバーは3人1組で発表資料を作って代表者が発表することになりました。 12月 前月に決まった発表テーマと内容の大枠をスライドに落とし込んでアウトラインレベルで中間発表を実施しました。そしてお互いの発表を聞いてフィードバックし合いました。このとき、主力エンジニア、中途社員エンジニア、若手エンジニア、 スクラム マスターというそれぞれの視点で発表するという流れがだいたい確定しました。 1月 ドラフト版レベルのスライドで発表練習して、全員でレビューしました。ここまでは スクラム マスターが最初に発表する流れにしていましたが、「いきなり スクラム マスターが場を引っ張って発表するのはなんか違うよね」となって、 スクラム マスターは最後に発表する流れに変更しました。 2月 本番さながらの練習会を実施し、資料と発表内容の精度を上げていきました。チームで整合性を合わせる部分があるため前日までスライドのチェックや修正を行って当日を迎えました。 発表したスライド 当日のスライドと合わせて発表に関わったメンバーのコメントをご紹介します。 大阪開発チームが取り組んだ スクラム 1年目の開発現場 まずはチームを取り巻く状況と、 スクラム に取り組んできた経緯を簡単にご紹介しました。 1. 開発チームク エス ト 楽楽精算開発チームの岡本です。 Meetupでは「開発チームク エス ト」というタイトルで、開発チームが歩んだ１年間の振り返りを発表しました。 タイトルは直訳すると「開発する仲間たちで探求する」になります。 探求とは「さぐり求めること。さがし回ること。※1」らしいですが、この1年はまさに仲間たちで課題の解決方法を探し回った1年でした。 中でも一番深刻だった課題がチームの分断問題です。若手とベテラン、新規メンバーと既存メンバーで知識量に差があり、フォローによる稼働圧迫が慢性的に発生していました。我々のチームでは、モブプロ／モブワークの手法を採用して、この課題を克服しようとしました。 当初は知識のあるメンバーがモブを主導することが多かったのですが、回数を重ねるうちにチームの平均知識が上がっていき、今は知識のあるメンバーが一方的に発言するというシーンは少なくなっています。また、モブで開発を進めた結果、必然的にメンバー個々へのフォローも少なくなりました。 ところで、モブプロとは全員でひとつの課題に取り組む開発手法ですが、これを言い換えると「開発する仲間たちで(ひとつの課題を)探求する」と言えるんじゃないかと思います。つまり、色々書いていましたが、今回の発表の結論としては「モブプロやってみると意外と良かった」に尽きると思います。 ※1 出典:精選版 日本国語大辞典 2. 中途社員がチームに参加しました 中途入社の福岡です。昨年5月に入社してからの1年間について発表しました。 当初は、入社してからの苦労話を発表しようとしたのですが、全く思い出せず、最初は何を話せるだろう、どういった価値を参加者へ提供できるだろうと悩みました。そこで発想を変え、どうして苦労話がでてこないのか？から、 スクラム チームが実施しているイベントを振り返り、これがなかったら苦労しただろうなという事例をピックアップしました。 またイベントだけでなく、HRTという考えから得るもの、これまでの自分を反省することが多々ありました。このブログを見た方は「HRT」についてだけでも、 Google先生 に聞いてみてください(笑) 今後チームに新たにメンバーを迎えられる方、またチームへ参加される方に何か響くものがあればと思います。 3. 学習 スクラム をやってみた件 入社3年目の中野です。私は「若手エンジニア」パートの発表を担当させていただきました。 チームの教育課題に スクラム を適用するという内容で登壇させていただきましたが、今回のMeetupに参加された方の多くは、プロダクトの開発に スクラム を適用することはあっても、新人の教育課題にまで スクラム を適用した例はあまり無いのではないかと思います。 実際、弊社のチームでも教育課題に スクラム を適用したのは今回が初めてでした。「教える側」は スクラム の経験が約1年と浅く、「学ぶ側」は スクラム の経験が皆無という状況で、お互い様々な苦労がありました。登壇の際にも触れましたが、最初の頃はタスクの残量がバーンダウンせず、どうすれば計画通りタスクを消化できるかを考える日々が続きました。スプリント内で確実にタスクを完了させるために1つのタスクの粒度を小さくしてみたり、前提知識を補うための事前学習的なタスクを作ってみたり、試行錯誤を繰り返しました。思い返せば スクラム において最初の難関はこの「バーンダウンしない問題」なのかもしれません。 今回は上記のような問題が発生するたびに「教える側」と「学ぶ側」が一緒になって解決策を考えたので、お互いにとって学びや成長があったと思っています。まだまだ スクラム 初学者の私が言うのも恐縮ではありますが、もし貴社で新人教育に スクラム を取り入れようと考えておられるならば、今回の発表が少しでも参考になれば幸いです。 入社二年目の桑原です。 私は学習 スクラム に教える側として参加し、Meetupでは資料作成に協力しました。ここでは発表であまり触れることのできなかった、学習 スクラム の中で、教える側がプロダクトオーナー(以後PO)や スクラム マスター(以後SM)のロールを体験して感じたことについて記載したいと思います。 私は1年ほど スクラム の開発に参加してきました。もちろん、POやSMの立場の人とも関わることがありました。そのため、学習 スクラム 実施前は、それなりにロールを担うことができるだろうと考えていました。しかし、実際に学習 スクラム が始まると全然ダメでした。例えばPOを担当した際のプロダクト バックログ 1つに着目しても、 バックログ の順番やどこまで作りこむか、エラー時の動作等、考慮が足りないことは多くありました。結果、最初のスプリントは計画段階で躓き、開発時間を圧迫、進捗も悪くなり、次のスプリントの準備も不十分になるという悪循環に陥っていました。最終的に、イベントの実施日は決めたものの、そのイベントのゴールは何か、そのゴールのために誰が何をどこまで準備するのかを整理できていなかったことに気づき、各イベントで最低限やることをリスト化、イベントまでに誰が何をするのか整理することで改善しました。 今思い返してみると、POやSMの役割、チームが動きやすいように舵をとることに関して、表面上は知っていた（見ていた）ものの、その役割を果たすためにどのような準備をしているのかが分かっていなかったのだと思います。１年間 スクラム に触れ、少しは分かったつもりになっていましたが、まだまだ学ぶべきことは多いのだと感じさせられました。学習 スクラム という取り組みは、新規メンバーが スクラム に慣れていくという面だけでなく、教える側の若手にとっても、チームがよりよく動くために自分達が何をすべきかを改めて考えさせられる良い取り組みであったと思います。 入社一年目の庄禮です。 「学習 スクラム をやってみた件」で実際に教えていただく立場にあり、中野（登壇者）の資料作成に協力しました。 学習課題を スクラム で回すという初めての取り組みで、「こんなの上手くいくわけがない！」と始める前や始めた当初は思っていました、しかし、 スクラム を回していく中で徐々に改善していき、イベントの役割などを身をもって体感することができたので、結果的に取り組んでよかったと思っています。 この度Meetupの題材にあがって資料作成をおこなうまで教育者側の苦労などは意識できていなかったのですが、資料づくりの中で今後のチームや教育の改善の観点から学習 スクラム を見ることができたので、今回のMeetupでアウトプットすることができて良かったと思っています。 来年、チームに入ってくる新人がいれば私も教育に関わることになるので、今回の反省点や課題点も踏まえて取り組んでいきます。もし機会がありましたら、学習 スクラム の取り組みの進捗・変化をみなさんにお伝えしたいと思います。 4. アジャイル であり続けるためのチームリーディング スクラム マスター担当の大塚です。 9月末に大阪オフィスで1回目のMeetupを開催した時に、次回は私たちのチーム全員で取り組んでみたら面白いのではないかと考え、チームに提案してみたのがきっかけで準備がスタートしました。半年もあれば準備万端で当日を迎えられるかというと、実際はそんなに単純ではありませんでした。業務の合間を縫って少しずつ準備を進める必要がありました。また、半年前から内容が決まっていたわけではなく全員が「これからやること」をイメージして2月に「こういう発表ができそう」というテーマを決めて、仕事でそのイメージに向かって進んでいくことで発表内容も同時に組み立てられていきました。つまり、Meetupに向けて発表の準備をすること自体が、ひとりひとりがチームの未来をイメージしてそれに向かって進んでいく作業にもなっていました。 主力メンバーが別のチームに移った時、今こそチームで アジャイル になるべきだと私は考えました。「誰か」ではなく「私が」でもなく「チームで」が大事な理由は同じことを繰り返さないためです。誰かがチームを引っ張るのではなく、チームで未来をイメージしてみんなで取り組んで作り上げる過程こそ アジャイル ではないでしょうか。そうやってMeetupに向けて進みながら少しずつイメージを具体化していく過程を スクラム マスターとして支援してきました。 「やってみたら面白そう」と思えるようなア イデア を見つける それを実践するきっかけを作る 実現イメージの具体化をファシリテートする 実行するうえでの課題や懸念の解消を手伝う このようなちょっとした支援で少しずつチームが前進していくのを手助けすることこそが サーバントリーダー の醍醐味だと思います。 ふりかえり アジャイル Night らしく、ふりかえりは 「Fun Done Learn」をやりました。 Fun Done Learnって何？というかたはこちらをご確認ください。 qiita.com Fun Done Learnをやってチームで議論した内容を以下にまとめます。 良かったこと・学び スクラム の取り組みについて参加者との交流や外部のエンジニアとの情報交換ができた 自分たちがやってきた事へのフィードバックが得られて今後のモチベーションに繋げられた 自社開催でチームでの取り組みなのでアウトプットへのハードルが低く、 心理的 障壁が少ない中で前向きに取り組めた 半年間の活動でしっかり時間を確保して学んだことや取り組みの総括ができた 改善点や今後に向けたTry 資料作りが基本であり一番大事、これを極めればもっと良い内容にできそう スケジュールを立ててチェックポイントを設けて計画的に取り組むことが大事 当日の発表を想定した練習が大事（もっとやっておくべきだった） ふりかえった内容は社内で共有して、他のチームの新たなチャレンジに役立ててもらいたいと思っています。また、社内だけでなくこの記事を読んで頂いた皆さんの何かの取り組みに役立てば幸いです。 おわりに 次回のMeetupは6月を予定しています。内容は決まり次第、connpassで告知します。 rakus.connpass.com また、大阪オフィスでは毎月1回エンジニアもくもく勉強会を開催しています。今回の発表内容に関しても興味を持たれましたら情報交換できればと思っていますので、是非ご参加ください。 rakus.connpass.com

楽楽精算開発２課 岡本です。 今年から月１回のペースで開催している「もくもく勉強会」ですが、３月もまた実施しますので、告知も兼ねて２月実施回の模様をお伝えしようと思います。 ちなみに、１月の模様はこちらの記事で紹介されています。 tech-blog.rakus.co.jp ２月実施の模様 前回(１月実施回)の振り返りで主に以下のような意見が出たので、２月はこれらの改善を実施しました。 参加者同士が離れて座りがち 食べ物があったほうがいい BGMの音が大きい ■参加者同士が離れて座りがち 前回は、机を離して設置していたため、それぞれの机に別れて参加者が座ってしまい、もくもく中にコミュニケーションが取りづらい状況でした。 前回の様子。空席が多くてどことなく寂しい感じ そこで、今回は参加者同士が近くに座れるように、机の配置を見直しました。 今回の様子。写真の時点では全員揃っていないので空席ありますが、最終的には各机に一人づつで全ての席が埋まりました。 ■食べ物があったほうがいい 食べ物があったほうがコミュニケーションを取りやすいのではという意見が出たので、今回はお菓子を用意してみました。 ちょうど実施日が２月１４日だったのでチョコレートをメインに用意。 ただ、あまり消費量は芳しくなかったようです。 まだまだ残っています。 次回以降も、お菓子は用意しようと思うので、お越しの際はガンガン消費していってください。 ■BGMの音が大きい もくもく勉強会の会場では普段からRaspberryPiからラジオが流されるようになっています。 こんな感じ、ちなみにこのRaspberryPiでエントランスのディスプレイに流れている映像も制御しています。 前回はここから流れてくる音が大きすぎるという意見が出ていたので、今回は予め音を絞ってBGMを流していました。 ただ、RaspberryPiの処理の関係で時々BGMが途切れ途切れになってしまっていたようなので、次回は別の方法でBGMを流そうと検討中です。 次回告知 次回は３月１４日に開催予定です。既にconnpassに公開中ですので。興味を持たれた方は是非お越しください。 rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュに関する紹介記事を書きました。なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 デブサミ2019で印象に残ったセッション デブサミ2019で興味があったもの PostgreSQL11のパーティショニングを試してみる おわりに 発表内容 前回 同様、東京のビアバッシュでは自由なテーマでの発表のみ行われました。 デブサミ 2019で印象に残ったセッション LTのタイトル① 前回に続き、今回も私が発表する場をいただけました。 2/14(木)、2/15(金)に開催された Developers Summit 2019（以下 デブサミ 2019）について参加しましたので、今年のテーマである「SHARE YOUR FUN！」にちなんだ以下のセッションの内容、感想を発表させていただきました。 event.shoeisha.jp event.shoeisha.jp セッションの感想ですが、楽しんで仕事をすることで利用者が幸せになるようなものを作りたいと思いました。また、東京のビアバッシュでも何度か話題になった技術書典についても、「面白い」と感じるポイントがあったので、次回開催分にはぜひ参加しようと思いました。 デブサミ 2019で興味があったもの LTのタイトル② 同じく デブサミ 2019に関する発表でした。興味がわいたセッションとして、下記のセッションについて発表されていました。 event.shoeisha.jp Node-REDを用いたコードレスなアプリケーション開発に興味がわいたとのことです。 PostgreSQL11のパーティショニングを試してみる 以前、 ラク スAdvent Calendar 2018に記事を投稿された方が、記事の内容について発表されていました。 qiita.com PostgreSQL 10から追加された宣言的パーティショニングについて、下記の二点が追加された PostgreSQL 11からは実用可能なレベルになったのでは？ということでした。 親テーブルにプライマリキーが設定できるようになった ただし、プライマリキーにはパーティショニングキー（分割の際に参照する項目）を含める必要がある パーティショニングキーを更新した場合、自動であるべきテーブルにデータが移動されるようになった 発表の最後には参加された方の間で、パーティショニング機能の商材利用についてディスカッションのように質疑応答が繰り広げられていました。 おわりに 東京オフィスの2月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。 3月は拡大版ビアバッシュともいえる全社MeetUpの開催が予定されていますので、そちらで発表された内容もお伝えできればと思います。

はじめに こんにちは。若手エンジニアのchoreiiです。 最近、業務でswiftに触れる機会がありました。 Xcode での アプリ開発 が楽しく、swift勉強したい欲が高まり勉強会にも参加しています。初心者ながら、ある程度アプリの作り方も理解してきたので一度アウトプットをしようと思います。 swift勉強中の方の刺激・参考となれば幸いです。 目次 はじめに 目次 題材 完成形 地図の埋め込み 検索とピン配置 最後に 題材 取り上げるのは、 MapKit になります。 簡単に言うと、アプリの画面に地図を埋め込んだりできる フレームワーク です。 今回はMapKitを使って、近場の駅を表示するアプリを作ってみました。 完成形 最初に完成形をお見せします。 起動後 ラク スの会社住所で検索 駅にピンがたつ（検索地が ラク スです） ゴールイメージが掴めたところで実際の手順を説明します。 地図の埋め込み xibまたはstoryboardで MKMapView を貼り付けるだけです。 xcode で部品をペタペタ貼り付けるのは直感的にできるのですごく楽しいです。（しっかりとしたレイアウトを考えだすと面倒ですが） MKMapViewの配置 今回はテキストボックスに住所を入力して検索するので textField も貼り付けています。 検索とピン配置 検索はMKLocalSearchを使用しています。精度はあまりよくないようですが、ローカルで API のように簡単に検索機能が使えるので使用しています。 検索用の関数を作成している先人の方がいらっしゃったので、検索自体は そちら をお借りしています。 Map.search(query : "駅" , region : region ) { (result) in switch result { case .success( let mapItems ) : for map in mapItems { let annotation = MKPointAnnotation() annotation.coordinate = map.placemark.coordinate annotation.title = map.name ?? "名前がありません" mapView?.addAnnotation(annotation) } case .failure( let error ) : print ( "error \( error.localizedDescription ) " ) } } query: 検索したい建物　region: 検索範囲のイメージです。 帰ってきた検索結果それぞれに MKPointAnnotation() を addAnnotation することでピンを立てています。今回は駅固定にしていますが、ここも入力フォームやユーザデフォルトに保存しておいた値などを使うと、いろんな建物が検索できて使い勝手はよくなると思います。 最後に xibファイル上でのオブジェクトの配置と、コード上でのオブジェクトの操作の両方を体験できるので、 iPhoneアプリ の開発練習にはぴったりだと思います。私自身イベントの制御などまだまだ把握できていないところばかりなのでこれからも勉強は続けていきます。今回のアプリのソースは GitHub に置いておきます。練習用のコードで汚く読みづらいコードとなっていますが、基本的な操作は一通り試しているのでご自由にお使いください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして、新卒のtaku_76です。 qiita.com 上記URLからチャット bot を作成したいと思ったのですが、これにNode.jsの知識が必要だと書いてあったので学習してみました。 その結果 フレームワーク であるExpressを使用すると簡単に Webサーバーが構築できることが分かったので試しに使ってみました。 Node.jsとは Node.jsのインストール Expressで新規プロジェクトを作成 おわりに 参考 Node.jsについての記事 Node.jsとは JavaScript を使ってサーバーサイドのコードを書くことが出来るプラットフォームです。 特徴 V8エンジン GoogleChrome で使われている JavaScript エンジンでブラウザとほぼ同じ JavaScript が書くことができます。 JavaScript を即座にコンピュータが理解できる 機械語 に変換して処理を行うため非常に高速です。 ノン ブロッキング I/Oモデル I/Oが終わったか何度もチェックし、終わっていなければ次の処理に進んで、次の処理が終わったらまたチェックする、この動作を繰り返します。 シングルスレッドの大量のアクセス制御が難しいというデメリットを回避します。 Node.jsのインストール https://github.com/nullivex/nodist/releases こちらのURLからnodistをインストールします。 nodistとは Windows 環境で動作する Node.js のバージョン管理ツールです。これを使うことで、複数の Node.js のバージョンを切り替えて使い分けることができるようになります。また、同時にnpmもインストールされます。 npmとは Node.jsのパッケージを管理するツールです。Node.jsのパッケージとは、予め用意された便利な機能をまとめたものです。 Expressで新規プロジェクトを作成 Expressとは Node.jsで利用できるWebアプリケーション フレームワーク です。 イベントループで非同期のため同時リク エス トに強く、多くのユーザーの同時アクセス・大量リク エス トを捌くことができます。 テンプレートエンジン(サーバーサイドで動的にオブジェクトを渡して、それをHTMLとして返す)を選べます。 今回はhtmlに近い形でかけるテンプレートエンジンのejsを使います。 Expressのインストール 以下のコマンドでインストールを行うことが出来ます。 C:\Users\takumi\Desktop\test\Nodist>npm install -g express-generator 公開までの手順 C:\Users\takumi\Desktop\test\Nodist>express -e newproject オプション-e でejsが設定された状態でプロジェクトが作成されます。 C:\Users\takumi\Desktop\test\Nodist>cd newproject && npm install 作成されたnewprojectのnode_module ディレクト リの中に必要なモジュールがインストールされます。 packege. json に何をインストールするのか設定してあり、これを参照してインストールを行います。 C:\Users\takumi\Desktop\test\Nodist\newproject>npm start サーバーを起動し、ローカルにWebページを公開します。 http://localhost:3000 と入力するとexpressにデフォルトで入っているhtmlが以下のように表示されます。 express おわりに 今回は、Node.jsのExpressを使ってローカルにWebサーバーの構築をしてみました。 次は、自分でWebアプリを開発してherokuを用いて公開するところまでやってみたいと思います。 参考 https://www.sejuku.net/blog/45745 https://techacademy.jp/magazine/16105 https://techacademy.jp/magazine/16119 Node.jsについての記事 こちらにも詳しい記事があります。 Node.jsの勉強会でお手軽にWebアプリを作った話

id:radiocat です。2/22〜23に開催されたScrum Fest Osaka 2019 へ私たちのチームから3人が参加してきましたのでレポートします。 Scrum Fest Osaka 2019とは？ www.scrumosaka.org 公式サイトには以下のように書かれています。 Scrum Fest Osakaは スクラム の初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。 アジャイル 開発のプロセスのひとつである スクラム のイベントで、関西では初の大型イベントです。約200人が集まって2日間開催されました。 ちなみに、弊社も大阪に拠点があり スクラム に取り組むIT企業のひとつとしてスポンサーをさせて頂きました。 なお、会場となった「 関西大学 梅田キャンパスKANDAI Me RISE」は大阪オフィスの隣のビルでした。その点でも何か不思議なご縁を感じて参加してきました。 登壇レポート 今回は登壇の機会も頂くことができました。せっかく頂いた機会ですので、私たちのチームが取り組んできた スクラム についてたくさん詰め込んで紹介しました。 スクラム はシンプルなルールの 開発プロセス ですが、その実践にはチームに応じた様々な工夫が必要です。私たちのチームもこれまでたくさんの試行錯誤を繰り返してきました。その中で支えとなったのは、既に スクラム に取り組んでいる先人やコーチなどの 有識者 の方々の取り組み事例でした。これまでも同様のイベントが開催されたり、同じ課題を持つ人が集まるコミュニティなどからたくさんの事例が世の中に発信されており、それらの情報を参考にして自分たちのチームに取り入れて スクラム を続けてきました。つまり、私たちの スクラム はこれまで取り組んできた人たちの試行錯誤に支えられているのです。 ですので、今度は私たちの取り組みを、同様に試行錯誤している人やこれから スクラム に取り組む人たちの支えにして頂けるように、たくさん詰め込んでお伝えしたつもりです。幸いなことに発表後の懇親会などで、たくさんの方々から共感のコメントや自分たちも同じ課題を持っていて勇気が湧いたという温かいお言葉を頂き、私たち自身もまたこれから スクラム を続けていくモチベーションを得ることができました。 参加レポート 一緒に参加したメンバーが印象に残ったセッションをまとめてくれているのでご紹介します。 楽楽精算開発チームの岡本です。印象に残ったセッションをまとめました。 プ ラク ティス厨から始める アジャイル 開発 クラスメソッドの 藤村さんのセッションです。 スライドは、こちらで公開されています。 プラクティス厨から始めるアジャイル開発 from Arata Fujimura www.slideshare.net スクラム の本に書いているようなプ ラク ティスについて、まずは、そのまま実行してみて、形骸化してきたと感じたら立ち止まり、 スクラム ガイド等の原典と現状の差分を確認してみればいい、といった内容のセッションでした。 スライド中には「プ ラク ティス厨が許されるのは、形骸化するまで」という言葉が出てきていましたが、うちのチームにも形骸化していそうなプ ラク ティスがちらほら出てきているので、原典との差分の確認時期なのかもしれないです。 スクラム フレームワーク を使用する具体的な方法。僕の場合。 楽天 の 椎葉さんのセッションです。 スライドは公開されていませんが、ブログで内容が公開されています bufferings.hatenablog.com 楽天 の大阪開発チームで実践している スクラム の方法についてのセッションでした。 色々と参考になるセッションで、特に、仕様の決め方や開発の進め方については、うちのチームでも取り入れてみたいと思いました。 仕様の決め方 何を作るのか？だけではなく、なぜ作るのか？をより重視して書く それによって、開発チームはより目的に沿った形で実装することができる。 開発の進め方 実装／テストで役割を分けて、それぞれ並行して進める 実装／テストそれぞれの観点で開発を進めるので見落としやバグを防ぎやすい。 オーディエンスとして参加して来ました、庄禮です。 私自身、現在の スクラム チームに参加してまだ半年ほどで、こういった スクラム のイベントにも参加したことはありませんでしたが、運良く参加枠をいただくことができましたので参加してきました。 以下、拝聴したセッションの中から一部ご紹介します。 お堅い企業で スクラム チームを一から作った話 3年前からチームに スクラム を導入した 三菱電機 株式会社さんのお話。 アナログなカンバンの導入に始まり、少しづつ自分たちの課題点を解消していく軌跡をお話しされていて、チーム体制の変更したり、デジタルなツールを導入して効率化をはかるなど、工夫しながら自分たちの スクラム を形作っており感銘を受けました。 ピンポンゲームで スクラム 体験ワークショップ 「Ball Point Game」というワークショップをおこないました。ワークの詳細は軽く調べるとでてきますので、気になる方は調べてみてください。 限られた時間、初対面の人と協力して目標にむかって行動するのはやりごたえがありました。やってみてダメな点は全員で振り返って、次にプランニングに活かす、といった スクラム の基本を体験学習できる良いワークでした。（ワークということもあり、実際の現場ではおこなわないようなチャレンジも行いました） 所感 交流会やコーヒーブレイクの時間に様々な スクラム 関係者と交流できたことも、参加してよかったと感じているポイントです。まだまだ自分自身の知識も浅く、お話を聞いて参考にさせていただく機会ばかりですが、いつか自分の経験をみなさんにアウトプットできるように精進していきます。 まとめ 2日間 スクラム のテーマにどっぷりと浸かり、参加者それぞれが交流と学びを深めて持ち帰ることができる場所でした。Scrum Festは、その名前のとおりカンファレンスや勉強会とは違った独特のフェス感のある素晴らしいイベントです。次回もぜひ参加したいと思います。 今回のイベントにも関連しますが、関西の アジャイル コミュニティの関係者の皆様には普段から大変お世話になってきました。今後もイベントへの参加だけではなく会場のご提供などでも関係を深めてコミュニティに貢献していきたいと思います。 devlove-kansai.doorkeeper.jp scrumdo-kansai.connpass.com スクラム 道関西さんには既に一度、弊社にお招きしてオープン・ジャムを開催して頂きました。また、3/18にはDevLove関西のイベントを弊社にお招きして開催予定です。 devlove-kansai.doorkeeper.jp また、弊社でも毎月１回エンジニアもくもく勉強会を開催してエンジニアの交流の場をつくっていこうとしています。よろしければぜひご参加ください。 rakus.connpass.com

こんにちは。堀内（ id:yhoriuchi ）です。 弊社が日頃からお世話になっている 株式会社アトラクタ 様が開催された 認定スクラムマスター研修 を受講してきました。講師は Gabrielle Benefield さんで、ジェフ・サザーランド博士が率いるScrum Foundationの共同設立者でもある方です。 Gabrielle Benefieldさん 研修内容が非常に素晴らしかったため、少しでもご紹介できればとの思いで研修の簡単な紹介、学んだこと、現場でやってみたことをお伝えしたいと思います。 研修概要 スクラム マスター研修は2日間のコースです。Gabrielleさんがメイン講師で、株式会社アト ラク タの 原田さん が研修をサポートする体制で行われました。 基本的に研修は英語ですが、プロの通訳の方が同時通訳を行いながら進行します。要所要所で原田さんがご自身の経験や考え方を交えた補足を行なって（日本語）くれましたので、 スクラム を学ぶ上でこれ以上ない講師陣だったと思います。 研修の始まり 研修が始まるとGabrielleさんから「全員と握手」するように言われます。40人ほどの参加者が部屋を歩き回って全員と握手するというワークショップ（？）です。初めて顔を合わせる人たちばかりでしたが、最初に握手をするだけで後の研修が非常にやりやすくなったと感じています。 スクラム マスター研修は多くのワークショップが取り入れられた内容になっているので、こうした 心理的 な障壁を最初に取り除く行動は研修そのものの効果を上げることにつながりました。 次のワークショップ：ピンポン玉回し 研修生が20人ずつくらいの2チームに分かれ、ピンポン玉を特定の時間内に落とさず手渡しで何個回せるか、という簡単なゲームをしました。2チーム同時に始めて優劣を競うのですが、チームごとにやり方が違うため、当然のように差が出ます。その後、一方がもう一方のチームのやり方を観察して自チームのやり方を見直し、改善するということを行いました。この時一番驚いたのが、相手チームを観察して良かったやり方をそのまま真似るのではなく、私が想像していた以上の改善が行われ、無駄がそぎ落とされた方法に一瞬で進化したことでした。観察して振り返り改善することの重要性に気付かされたその時の衝撃は今でも忘れることができません。 やり方は違えど、以前 吉羽さんに社内で実施して頂いたスクラムトレーニング で伝えようとしていたことが改めて理解できた気がします。 色々端折りますが その後は スクラム の全体の流れを説明頂いたり、チームに分かれてワークショップを行ったりして スクラム の理解を深めました。 疑問があれば随時質問を行うこともでき、貴重な意見やアド バイス を受けることができます。知識としての スクラム だけでなく、多くの現場を見て改善されてきた知見を持つ講師からのアド バイス は心に突き刺さるものがあります。私が質問をした回答の最後に、Gabrielleさんが "Good luck"と言ってくれたのは今でも心の支えとなっています。 学びを実践で試すと更に学べたこと 研修に参加すると、不思議と勇気と自信が湧いてきます。そのまま自社に学びを持ち帰り、一番試してみたかったことを早速試してみました。それが「他チームを観察する」です。タイミング的に他チームを観察することが難しかったため少し工夫して、他チームの スクラム マスターをやっている id:radiocat に自チームの振り返りの ファシリテーター をお願いしました。 「人は鏡」といった言葉があるように、人は人との対話を通じて自身の内面に気付かされることが多くあります。 スクラム の振り返りでの開発チームと ファシリテーター という関係性から考えて、チーム外の人が ファシリテーター を行うことにより、自分たちのチームが外からどのように見えているのか気付かされ、新たな改善や行動につながることに期待していました。 結果は思っていた以上のものでした。 開発チームメンバー個別に振り返りの感想を聞いてみたのですが、全員が口を揃えて同じことを言っていたのです。それが 「1週間で課題（problem）が多いのは正常なのか？」 という質問があったということでした。振り返りに KPT を利用しているのですが、“P”に上がる項目が多いように外からは見えるというチームへの見事な問いかけだったんだなと思いました。 感じ方は人それぞれあるようですが、この質問がチームにとって大きな意味があり、各自が深く考えるきっかけを与えてくれました。 更には、他チームの振り返りをファシリテートすることで ファシリテーター 自身も多くの気づきがあったようです。 下記がその一部。 チームの関心事によって出てくるものが全く違う。 振り返りのファシリテートはすごく重要で、すごく難しい。 チームが課題と感じているところを察知して石を投げ込まないと意味がない。 振り返りはプロセスの改善の場であると他チームの課題感を通して改めて認識することができた。 これらを聞いて私自身も学べることが多く、この一連の行動から学びで学びを繰り返すのだと気づかされました。今後はチームとしての学びを最大化するためにも スクラム マスターとしての学びは尽きることがないと気を引き締めた次第です。 そしてその先へ 認定 スクラム マスター研修を受けると、認定 スクラム マスター（CSM）になるための受験資格がもらえます。オンラインで受験できるのですが、私も無事合格することができました。CSMは資格取得して終わりではなく、むしろ果てしなく続ける旅路の始まりだと思っています。このような研修の機会を作ってくれた株式会社アト ラク タ様や自社にも感謝しつつ、これからも スクラム チームを支援していきたいと思います。 ジャーニーは始まったばかりです。

こんにちは、fuj_takです。 エレベーターがなかなか来なくてもやもやすることありませんか？ かく言う私もエレベーター待ちになると、いつ来るんだろうと悩まされます。 自分にエレベーターの制御をやらせれば、もっといい感じにできる 皆さんも一度は考えた事があるのではないでしょうか！ そんなあなたにこちらをご紹介します。 Elevator Saga Elevator Saga - the elevator programming game GitHub にも公開されています。 GitHub - magwo/elevatorsaga: The elevator programming game! ※私の環境だと IE でうまく画面表示できなかったので、 Chrome などのブラウザでお試しください プログラミング内容 ブラウザ上で JavaScript のコードを記述し、エレベーターの操作を行います。 エレベーターに乗った乗客の行先ボタンに応じた制御、 各階での上下ボタンが押された場合のエレベータの制御、 などを行い、時間内に多数の乗客を輸送できるかどうかにチャレンジするという内容。 ブラウザさえあれば誰でもお手軽に試せるので、チーム内ワークショップとかでも使えると思います。 2015年頃に公開されているようなので、一度は触ってみたことがある方もいそうですね。 API も公開されています。 Elevator Saga - help and API documentation やってみた エレベーターの数や各階の数が異なる設定で全18ステージあります。 https://play.elevatorsaga.com/#challenge=1 https://play.elevatorsaga.com/#challenge=2 　～ https://play.elevatorsaga.com/#challenge=18 頑張ってみたのですが、5ステージを超える事ができませんでした。。。。 色々と無駄な動きが多いですね。 エレベーターの制御プログラムを作っている方々、えらそうなことを言ってすみませんでした m(_ _)m 我こそはという方は是非チャレンジしてみてください！！ 参考に API を頼りに作ったコードです。 いけてない点があるのは承知していますが、笑って許してください。 { init: function(elevators, floors) { var waitFloor = []; var queuePush = function(floorNum){ if (waitFloor.indexOf(floorNum) < 0) { waitFloor.push(floorNum); waitFloor.sort(function(a,b){ if( a < b ) return -1; if( a > b ) return 1; return 0; }); } } // 動作対象のエレベーター取得 var getTargetElevetor = function(updown, floorNum){ var target = null; elevators.forEach(function(e) { // エレベータ内の混在率を考慮 if(e.loadFactor() < 1) { if (updown == "up") { if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { target = e; } } else { target = e; } } else if (updown == "down") { if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { target = e; } } else { target = e; } } } }); return target; }; // エレベーターの上昇／下降に合わせて停止階を決める var setStopFloor = function(e, floorNum){ // 上昇中は上階のみ止まる if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { e.goToFloor(floorNum); } // 下降中は上階のみ止まる } else if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { e.goToFloor(floorNum); } // 停止中は指定階に向かう } else { e.goToFloor(floorNum); } }; elevators.forEach(function(e) { // 待機中 e.on("idle", function() { // 1階で待機 e.goToFloor(0); }); // 行先ボタンプッシュ e.on("floor_button_pressed", function(floorNum) { // 上昇中 if(e.goingUpIndicator()) { if(e.currentFloor() < floorNum) { e.goToFloor(floorNum); } // 下降中 } else if(e.goingDownIndicator()) { if(e.currentFloor() > floorNum) { e.goToFloor(floorNum); } } else { e.goToFloor(floorNum); } // 行先を制御 setStopFloor(e, floorNum); }) // 移動中 e.on("passing_floor", function(floorNum) { }); // 到着 e.on("stopped_at_floor", function(floorNum) { // エレベーター待ちをクリアする waitFloor = waitFloor.slice(waitFloor.indexOf(floorNum), 1); }); }); // 各階で上下ボタンがプッシュされた floors.forEach(function(f) { f.on("up_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("up", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); f.on("down_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("down", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); }); }, update: function(dt, elevators, floors) { // We normally don't need to do anything here } } エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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