はじめに GAS(Google Apps Script)とは 今回やること GASの実行結果を書き込むSpreadSheetの作成 GASの作成 POSTする設定 補足：承認を求められたら curlからPOSTする おわりに はじめに kuwa_38です。この記事では Google Apple Scriptとして作成した スクリプト を curl コマンドから実行する方法を紹介します。 GAS( Google Apps Script)とは 以前このブログで書かれていた記事の中に分かりやすい説明があったので引用します。 「 Google の各種アプリ( Google スプレッドシート / Google ドキュメントなど)をアプリ内ではなく外から操作できるJSライクな プログラミング言語 」です。 エクセルに対する VBA の関係と一緒です。 tech-blog.rakus.co.jp 上の記事は入門として スクリプト エディタ上から作成した スクリプト を実行しています。本記事では スクリプト エディタ上からでなく、外部( curl コマンド)から実行する方法の紹介となります。 今回やること curl コマンドからGASを実行するための大まかな手順は以下です。 GASの実行結果を書き込むSpreadSheetの作成 GASの作成 POSTする設定 curl からPOSTする GASの実行結果を書き込むSpreadSheetの作成 今回は以下のようなシートを作成し、果物(fruit)と値段(price)を末尾に追記します。 書き込むSpreadSheet GASの作成 以下を スクリプト エディタに記載します。 /** * POSTされた時に実行されるメソッド. * 行の最後に受け取った値を挿入する * @param e 下記のJSONを想定 * fruit:フルーツ名 * price:価格 * @return なし */ function doPost(e) { var ss = SpreadsheetApp.getActiveSpreadsheet(); var sheet = ss.getSheetByName( 'シート名' ); var PostData = JSON.parse(e.postData.contents); // 行の最後に値を追加 sheet.appendRow( [ PostData.fruit, PostData.price ] ); } 参考： qiita.com POSTする設定 POSTする前に作成した スクリプト にアクセスできるように設定します。 公開 > ウェブアプリケーション として導入 スクリプト 許可1 次のユーザとしてアプリケーションを実行：自分 アプリケーションにアクセスできるユーザ：全員(匿名ユーザを含む) スクリプト 許可2 更新ボタンを押すと、接続するためのURLが作成されます curl で接続する際に使用するのでコピーしておくと良いです スクリプト 許可3 参考： yamap55.hatenablog.com 補足：承認を求められたら 承認を求められた場合は下記を参考に承認してください。 tonari-it.com curl からPOSTする 以下の curl を実行し、POSTします。 curl -X POST -H "Content-Type: application/json" -d '{"fruit":"peach", "price":"650" }' -L https://script.google.com/macros/s/xxxx/exec スクリプト 実行結果 おわりに この記事では curl コマンドを使ってPOSTし、GAS( Google Apple Script)を実行する方法を紹介しました。今回は curl コマンドを直打ちでしたが、自作アプリなどからPOSTする仕組みにしておけば、SpreadSheetへの操作をより手軽にできるようになるかと思います（何か作りたいなと思案中）。 気になった方はぜひ試してみてください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちわ @kawanamiyuu です。来週末に開催される、日本最大の Java コミュニティイベント JJUG CCC 2019 Spring に ラク スのエンジニアが 2 名登壇しますのでお知らせします。 イベント概要 日時：2019 年 5 月 18 日 (土) 会場： ベルサール 新宿グランドコンファレンスセンター 公式 HP： http://www.java-users.jp/ccc2019spring/ ハッシュタグ ： #jjug_ccc www.java-users.jp goo.gl 登壇セッション セッション一覧はコチラ　→　 http://www.java-users.jp/ccc2019spring/#/sessions １．売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 登壇者：西角知佳（東京拠点エンジニア） セッション詳細 ＜概要＞ 「楽楽精算」 は株式会社 ラク スが提供する経費精算 クラウド サービスです。市場の成長や 働き方改革 といった社会情勢とともにサービスも成長を続けています。その一方で、売れているサービスであるがゆえに蓄積した技術的負債やビジネスのスケールに伴う運用課題もまた抱えています。 その課題の１つとして、増え続ける顧客データのバックアップ肥大化およびバックアップ時間増大という課題が深刻化していました。リリースメンテナンス時間への影響も無視できなくなってきたことから、 Amazon S3 ...ではなく、 Amazon S3 互換のプライベートオブジェクトストレージへのデータ移行に踏み切りました。 オブジェクトストレージ導入にあたりどのように技術選択をし、どのように大切な顧客データを安全確実に移行したのか。また、リリース後に発生した問題にどのように対処したのか。サービスローンチから10年が経過し、オンプレミス、某 Java フレームワーク と決して今をときめく技術スタックで構成されたサービスではない楽楽精算にとっての技術的なチャレンジについて、成長を続けるサービスが必ず通りうるであろう現実的で泥臭いお話を具体的に発表します。 翌週に開催予定の RAKUS Meetup Tokyo #3 のリードセッションを JJUG CCC 2019 Spring という特別な場所からひと足早くお届けします。 ２．ArchUnit で Java / Kotlin アプリケーションの アーキテクチャ を CI する 登壇者：かわなみゆう（大阪拠点エンジニア） セッション詳細 ＜概要＞ ArchUnit とは一言でいうと、 Java / Kotlin アプリケーションのパッケージやクラスの依存関係や、アプリケーション固有の実装ルールを JUnit のテストコードして表現しテストできるテスト フレームワーク です。 我々にとって ArchUnit はなにが嬉しいのか。ArchUnit でできることは人間によるコードレビューや静的解析によってもチェックできそうに思えます。 この発表では、実際に私たちのプロダクトの CI に組み込まれているテストコードの実例と合わせて、アーキテクトの観点、開発チームの観点から ArchUnit のウレシみについてお話します。 最後に 今回が ラク スとして初めて Java のイベントへの登壇です。そして、東京拠点エンジニアからの社外イベント登壇も初です。今年度も ラク スはイベント登壇への取り組みを更に加速させていきます。 最後になりましたが、当日、セッションでお会いできるのを楽しみにしています！

id:radiocat です。大阪でエンジニアもくもく勉強会の運営をしています。令和も継続して開催しますのでぜひご参加ください。 rakus.connpass.com 初開催から予想より多くの方々に参加して頂き、今回はありがたいことに早くも定員に達してしまいましたので増枠しています。様々なエンジニアの方にお会いできて、一緒に参加する弊社の社員も楽しませて頂いています。 4月のレポート 平成最後のエンジニアもくもく勉強会の様子を少しだけご紹介します。 参加頂いた方々はご覧のようなテーマで自習されていたようです。 付箋の内容は自己紹介も兼ねて簡単に共有して頂くようにしています。 PHP 関係のテーマが比較的多かった印象で、参加者同士の情報交換なども行われていました。他にも Rails やJS、 Java を扱う内容もあって、自分の好きなテーマで自由に取り組んで頂くことができます。 エンジニア経歴も、お聞きする限り様々で、若手からベテラン、そして学生のかたも参加されています。弊社の運営も次回から若手メンバーにも手伝ってもらう予定で、幅広くサポートしていければと思います。 終業後の小腹が空く時間帯ですので、真ん中のテーブルでお菓子をご自由にお取り頂けるようになっています。気軽に立ち寄れて、エンジニアが楽しめる場づくりを目指しています。一緒に楽しんで頂けるエンジニアの皆様のご参加をお待ちしております。

はじめに こんにちは。令和最初の記事は sts -250rrからお届けします。 私ごとですが、プロジェクトが変わり5月から アジャイル 開発を行うことになりました。 アジャイル 開発の中でも スクラム をやるとのことだったので、GWの期間を利用して、SCRUM BOOT CAMP の本を読んでみました。 今回は自身の頭の中の整理を記事に残しておこうと思います。 実際にやってみるのはこれからになりますので、間違いもあるかと思いますがご容赦ください。 はじめに アジャイル開発とは スクラムとは？ スクラムの特徴 スクラムの全体像 スクラムでの開発チームの役割 開発チームの進め方 スプリントの進め方 リリース判断可能 スプリントレビュー スプリントレトロスペクティブ（振り返り） 終わりに 参考 アジャイル 開発とは アジャイル 開発では、「事前にすべてを正確に予測し、計画することはできない」という前提のもと以下のような進め方を行います。 関係者は目的達成のためにお互いに協力しあいながら進める 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。 一度にまとめてではなく、少しずつくくる。そして実際に出来上がったものが求めているものであるかを頻繁に確認する。 アジャイル ではおおよその全体像は明らかにした上で、重要なものやリスクの高いものを優先し、重要度の低いものは後に回すことで、要求の分析や設計に対して必要以上の時間をかけないことで開発スピードを上げていく手法です。 ユーザが求めているものを素早く提供するようなサービスに向いている手法かと思います。 スクラム とは？ スクラム は アジャイル 開発の中の手法の1つで、関係者の進む方向を常に調整しながら目的を達成するため、 作業、会議、成果物を定めた 手法です。 あくまで仕事の進め方にフォーカスをしたものであるため、細かなルール（コーディング規約やテストの方法など）は自分たちで決める必要があります。 書籍に記載の スクラム の特徴を記載します。 スクラム の特徴 要求を常に順番に並び替え、その順にプロダクトを作ることで成果を最大化する 実現されることの価値やリスク、必要性を基準にする 固定の短い時間に区切って作業を進める 現時点の進捗や問題点を常に明らかにする 定期的に今進めているものが正しいのか、進め方に誤りはないのかの確認を行う 進め方に問題があったり、もっと良い方法があった場合にはやり方を変更する スクラム の全体像 SCRUM BOOT CAMP の著者でもある @ryuzee さんの図を見ていただくのが良いかと思います。 www.ryuzee.com この図を見て感じたことは、1スプリントでプロダクトオーナーのレビューを受ける必要があるため、どの程度の作業ができるのかをよく把握しておかなければならないという点です。 こうなってくると、1スプリントのなかでどこまでのことができるかを決めるスプリントプランニングや、今どこまでできているかを確認するデイリー スクラム が重要になってくることもうなずけます。 スクラム での開発チームの役割 私は開発チームとして スクラム に関わることになるので、開発チームの役割を掘り下げていきます。 開発チームの役割は以下の点です。 リリース判断ができるプロダクトを作る 6名（±3名）で構成する 全員揃えばプロダクトを作れる 上下関係はない また、開発チームは要求の分析・設計・コーディング・サーバの構築・ドキュメントの作成といった システム開発 に必要なことが全てできる必要があります。 これは各作業に個人を割り当てるというものではなく、個人が複数のことができるようになるということです。 開発チームの進め方 開発チームはプロダクトの作っていくためにスプリントを進めていくわけですが、1スプリントでどこまで作業を行うのかを決める スプリントプランニング を実施します。 スプリントプランニングは、プロダクトオーナーを含めて何が欲しいのか、開発チームではどこまでできるのかをすり合わせる第１部。 第１部で決まったことをどのように実現するのかを開発チーム内ですり合わせる第２部で構成されています。 ここで決定したことを スプリント バックログ という形でタスクの一覧を用意し、スプリントの中で実施していきます。 スプリントの進め方 スプリントを行なっていく上でのポイントですが、開発チームはスプリントプランニングの中で合意した内容を達成することに全力を尽くす必要がありますが、全てを完了することを約束するものではないということです。 全てを完了することを目的に作業をしてしまうと、不測の事態が発生したり、必要な作業を飛ばしてしまったりといった問題が発生し、「本当に欲しいもの」が作れない可能性があるためです。 この場合はプロダクトオーナーと相談し、プロダクト バックログ のリストを見直したりすることで計画を調整します。 リリース判断可能 スプリントが終わった後には リリース判断可能なプロダクト ができていることが求められます。 リリース判断可能というものがどのような状態を指すものであるかを示すために 完了の定義 を明確にしておきます。 スプリントレビュー スプリントの最後にプロダクトオーナーがスプリントの成果物を確認する機会です。 ここで 実際に動くもの をプロダクトオーナーが確認し、プロダクト バックログ であげていた項目通りのものであれば作業完了となります。 想定通りのものでなかった場合には、次回のスプリントに含むなどの形でプロダクト バックログ に戻します。 スプリントレトロスペクティブ（振り返り） スプリントレビューが終わると、今回のスプリントの振り返りを行います。うまくいったことやよくなかった点を洗い出して今後のスプリントに生かしていきます。 スプリントレトロスペクティブまで完了して1スプリントとなり、プロダクトの完成まで繰り返していくことになります。 終わりに ここまで淡々と スクラム について書いてきましたが、最後に所感を述べて終わりたいと思います。 開発チームの役割で「全員揃えばプロダクトを作れる」というものがありましたが、実際 全員が揃う ことは保証できないですし、 あるキーパーソンがいないと作業が進まないような状況は「属人化」の典型ですし、望ましいものではないです。 そのような状況を改善していくために 個人が複数のことができるようになる 必要があると言えます。 その道のプロフェッショナルであることももちろん重要なことですが、 スクラム では幅広い知識を持った上で参加する必要がありそうです。 また、今学習した部分では スクラム の中には「運用・保守」といった観点は除かれているように感じました。 　 短期間でリリースをする可能性のある アジャイル 開発において「運用・保守」に与える影響は小さいものではないと考えます。 このような点を解決する考え方として DevOps が生まれてきているわけなので、DevOpsの視点も考慮して開発を進めていく必要がありそうです。 ただし、まだ私は スクラム を体験していませんので間違ったことも多々記載しているかと思います。 実際の スクラム はこれからやっていくことになりますので、次回は実体験から得られたものをご紹介したいと思います。 参考 SCRUM BOOT CAMP THE BOOK スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com

はじめに こんにちは。最近 iPhoneアプリ 開発のため Mac に手を出し始めた @rs_tukki です。 前回の記事でも書きましたが、エンジニアは学び続けることが大切です。 ラク スでもTechブログを通したアウトプットを推奨しており、 年齢、拠点に関係なく、 ラク スに所属する全てのエンジニアの方に記事を書いてもらっています。 tech-blog.rakus.co.jp そして、アウトプットを推奨するキャンペーンの一環として先日、ブログの年間表彰式を実施しました！ 表彰式の様子 2018年4月1日から2019年3月31日までに記事を投稿された全ての方を対象に、 多くの記事を投稿した方 投稿した記事のアクセス総数が多い方 記事の投稿から一週間のうちに多くのアクセスを獲得した方 その他、ブログの活動に貢献された方 を表彰します。 受賞者には表彰盾のほか、 Kindle など豪華副賞も送られました。 授賞した記事やカテゴリはこちら。 終わらないスクラム カテゴリーの記事一覧 - RAKUS Developers Blog | ラクス エンジニアブログ 5分で理解する！Google Apps Script超入門 - RAKUS Developers Blog | ラクス エンジニアブログ マイクロサービスアーキテクチャにおけるサービス分割の難しさ - RAKUS Developers Blog | ラクス エンジニアブログ 【図多め】APIを使ってGoogleサービスを操る - RAKUS Developers Blog | ラクス エンジニアブログ Android Studioで天気情報を表示するアプリを作ってみた - RAKUS Developers Blog | ラクス エンジニアブログ ラク スでは今後もエンジニア全体で学びを発信していきますので、今後ともよろしくお願いいたします！ おまけ 表彰式に参加された方には、このような参加賞もお配りいたしました(笑)

中小企業の業務効率化に貢献する複数の クラウド サービスを提供する「株式会社 ラク ス」です。東京での3回目の開催となる Meetup イベント RAKUS Meetup #3 を 5/21(火) ラク ス本社＠新宿にて開催します。 今回のテーマ 「 Amazon S3 互換ストレージエンジンの導入事例紹介」です。 Amazon S3 はほぼ無制限にスケールするストレージサービスとして広く使われていると思いますが、 セキュリティ上の都合 クライアントとの契約内容 などの理由で クラウド サービスである Amazon S3 が利用できないケースも多々あります。 そんな場合に自前でオブジェクトストレージを構築するという選択があるかと思います。 自前でオブジェクトストレージを構築する際には MinIO 社の minio だとか、 クラウディアン社 の Cloudian Hyperstore などのプロダクトがありますが、今回弊社サービスの 楽楽精算 にて採用されたクラウディアン社の Cloudian Hyperstore の導入事例についてアプリケーションサイド、インフラサイドのそれぞれから紹介させていただこうと思います。 こんな人におすすめ S3などのオブジェクトストレージを導入したいが各種事情からオンプレで構築する必要があるサービスのエンジニア バックエンドエンジニア インフラエンジニア 主にBtoBサービスを提供していて、各種制約のなかサービスをスケールするため日々奮闘しているエンジニア、プロダクトマネージャー、ディレクター BtoBサービス開発者同士の横のつながりを作りたい方 前回の様子 前回開催時の様子は RAKUS Meetup Tokyo #2 フロントエンドNight : イベントレポート をご参照くだい。 開催概要と申し込み 日時: 2019/5/21(火) 19:00-21:00 開場は30分前の18:30からとなります 会場: ラクス 東京本社 セミ ナールーム 〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F 参加費: 無料 ハッシュタグ : #RAKUSMeetup 主催: ラクス 申込みは Connpass のイベントページ からお願いします。

はじめに id:FM_Harmony です、Rakus Developers Blogでは久々の投稿になります。 前回の投稿は 東京開発ビアバッシュに参加しました～2019年2月編～ でした。 tech-blog.rakus.co.jp さて、最近Node.jsの学習を個人的に行っているのですが、学習を進めていく内にJenkinsを用いたCI環境が思いのほか簡単に構築できることが分かりました。 そこで今回は、Jenkinsを用いたNode.jsアプリのCI環境の構築手順について記事を書きました。Node.jsでアプリを開発されている方の参考になれば幸いです。 なお、Jenkinsのバージョンは ver. 2.173 を利用しているため、それ以外のバージョンを利用している場合、設定内容等に差異があるかもしれません。 目次 はじめに 目次 Jenkinsの設定 NodeJS Pluginの導入 NodeJSの設定項目 Install from nodejs.orgの設定項目 ジョブでインストール状況を確認する 自動テストを試してみる サンプルプロジェクトの作成 単体テストの作成 レポートファイルを出力する JenkinsでCI用ジョブを作成する おわりに 参考 Jenkinsの設定 NodeJS Pluginの導入 「NodeJS Plugin」を利用することでJenkinsがNode.jsを実行するための設定を簡潔に行うことができます。 Top画面 > Jenkinsの管理 > プラグインの管理 から「NodeJS Plugin」をJenkinsにインストールします。 NodeJS Pluginのインストール 導入後、再起動したらPluginが反映されるので、次にJenkinsで利用するNode.jsの設定を行います。 Top画面 > Jenkinsの管理 > Global Tool Configuration に、「NodeJS」という項目が増えているはずなので、そこから設定を行います。 何も設定していなければ、「NodeJS追加」ボタンを押下することで、Node.jsの設定を追加することができます。また、複数バージョンのNode.jsを利用するように設定することもできます NodeJSの設定項目 名前 Jenkinsのジョブで利用する際に指定する 自動インストール チェックを入れるとJenkinsが自動でNode.jsをインストールする。初期の インストーラ として「Install from nodejs.org」が設定されており、基本的には インストーラ を変更する必要はない インストール ディレクト リ 自動インストールにチェックを入れない場合は入力、今回は利用しない Install from nodejs.orgの設定項目 Version 利用するNode.jsのバージョン Force 32bit architecture 今回は利用しないが、32bitOSの場合は必要かもしれない Global npm packages to install npmで利用するグローバルパッケージの指定。基本的にパッケージ名を指定すればよいが、 packageName@version と記載することで指定のバージョンをインストールさせることができる？ Global npm packages refresh hours 初期値で問題なかったので、しっかりとは調べていない... 今回は記事作成時点で最新かつ安定のNode.jsを利用する、mochaで 単体テスト を行いJenkinsでレポートを集計するようにするため、以下のように設定しました。 NodeJS Pluginの設定 ジョブでインストール状況を確認する 以下の設定内容でフリースタイル・プロジェクトのビルドジョブを作成してNode.jsのバージョンやnpmパッケージのインストール状況を確認してみます。 ビルド環境 Provide Node & npm bin/ folder to PATHにチェックを入れ、以下の通り設定 NodeJS Installation NodeJSの設定項目で「名前」に入力したもの npmrc file 特別に設定していなければ、 -use system default- しか表示されていないはず ビルド 以下の シェルスクリプト を実行する node --version npm ls --depth=0 -g ビルド実行が成功し、ビルドのコンソール出力に以下のような内容が表示されていれば設定は期待通りになっているはずです。（今回はJenkinsを tomcat に載せています） Started by user xxx Running as SYSTEM Building in workspace /home/tomcat/.jenkins/workspace/NodeJSConfigurationCheck [WS-CLEANUP] Deleting project workspace... [WS-CLEANUP] Deferred wipeout is used... [WS-CLEANUP] Done [NodeJSConfigurationCheck] $ /bin/sh -xe /opt/tomcat/temp/jenkins8667759308635013491.sh + node --version v10.15.3 + npm ls --depth=0 -g /home/tomcat/.jenkins/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/NodeJS_v10.15.3/lib ├── mocha@6.1.3 ├── mocha-junit-reporter@1.21.0 └── npm@6.4.1 Finished: SUCCESS 自動テストを試してみる サンプルプロジェクトの作成 今回は以下のような構成のプロジェクトを作成してみます。 サンプルプロジェクト ├─node_modules ├─src │ ├─index.js │ └─calc.js ├─test │ └─calcTest.js ├─package.json └─package-lock.json 各ファイルの説明は以下の通りです。 src/index.js アプリケーションのエントリポイント src/calc.js 計算を行うモジュール test/calcTest.js src/calc.js の 単体テスト それ以外はnpmで自動的に作成されるファイルです。 まずは、 mocha + power-assert で 単体テスト を行いたいので、プロジェクトのルート ディレクト リで以下を実行します。 npm init npm install -g mocha mocha-junit-reporter npm install --save-dev power-assert intelli-espower-loader 次に、 index.js 、 calc.js を作成します。今回は、index.jsをnodeで起動して、引数として渡した2つの数値を足したものがコンソールに表示されるようにします。 // index.js 'use strict' ; var calc = require( './calc' ); if (require.main === module) { main( { argv: process.argv } ); } function main(options) { var argv = options.argv; var x = parseInt(argv [ 2 ] ); var y = parseInt(argv [ 3 ] ); var result = calc.add(x, y); console.log(x + '+' + y + '=' + result); } // calc.js 'use strict' exports.add = function (x, y) { return x + y; } ; ルート ディレクト リでindex.jsを実行してみると、以下のようにコンソール表示が行われるはずです。 $ node src/index.js 1 2 1+2=3 単体テスト の作成 次に、 calc.js の 単体テスト を作成します。今回は、テストとして 1+1=2を満たす ことをテスト成功の条件にしてみます。 //calcTest.js 'use strict' var assert = require( 'power-assert' ); var calc = require( '../src/calc' ); describe( 'addファンクションの単体テスト' , function () { it( 'add(1, 1) = 2' , function () { var result = calc.add(1, 1); assert.strictEqual(result, 2); } ); } ); ローカルで 単体テスト を実行してみます。ルート ディレクト リで mocha を実行すれば良いです。 $ mocha addファンクションの単体テスト √ add(1, 1) = 2 1 passing (15ms) レポートファイルを出力する package. json を編集してレポートファイルを出力するようにします、以下の設定を追記して npm test を実行すると、デフォルトではルート ディレクト リの test-results.xml にテスト結果が出力されるはずです。 " scripts ": { " test ": " mocha test --reporter mocha-junit-reporter " } , // test-results.xml <?xml version="1.0" encoding="UTF-8"?> <testsuites name="Mocha Tests" time="0.001" tests="1" failures="0"> <testsuite name="Root Suite" timestamp="2019-04-16T04:39:33" tests="0" failures="0" time="0"> </testsuite> <testsuite name="addファンクションの単体テスト" timestamp="2019-04-16T04:39:33" tests="1" file="C:\Users\kazuki.hirayama\Desktop\NodeJSCISample\test\calcTest.js" failures="0" time="0.001"> <testcase name="addファンクションの単体テスト add(1, 1) = 2" time="0.001" classname="add(1, 1) = 2"> </testcase> </testsuite> </testsuites> この時点で、CI連携用に Github の リポジトリ へpushしておきます。 JenkinsでCI用ジョブを作成する 最後にCI用のジョブを作成しましょう。フリースタイルビルドジョブを以下のように設定します。 ※ Github との連携に関するところは割愛します ビルド環境 「ジョブでインストール状況を確認する」の際に設定したもの ビルド シェルの実行 npm install npm test ビルド後の処理 JUnit テスト結果の集計 テスト結果 XML デフォルトであれば、 test-results.xml を入力 それ以外の項目 とくに変更しない この後、 Github の リポジトリ へpushを行うとビルドが始まるはずです。ビルドが成功して、成功後のコンソール出力が以下のようになっていれば期待通りです。 Started by GitHub push by xxx Running as SYSTEM Building in workspace /home/tomcat/.jenkins/workspace/NodeJSSampleCI No credentials specified Cloning the remote Git repository Cloning repository xxx > git init /home/tomcat/.jenkins/workspace/NodeJSSampleCI # timeout=10 Fetching upstream changes from xxx > git --version # timeout=10 > git fetch --tags --progress xxx +refs/heads/*:refs/remotes/origin/* > git config remote.origin.url xxx # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url xxx # timeout=10 Fetching upstream changes from xxx > git fetch --tags --progress xxx +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 9600a7cf391f3aea917dc06db88b84851d7de87b (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 9600a7cf391f3aea917dc06db88b84851d7de87b Commit message: "test commit" First time build. Skipping changelog. [NodeJSSampleCI] $ /bin/sh -xe /opt/tomcat/temp/jenkins7429977434779181980.sh + npm install npm WARN nodejscisample@1.0.0 No description added 79 packages from 155 contributors and audited 280 packages in 2.283s found 0 vulnerabilities + npm test > nodejscisample@1.0.0 test /home/tomcat/.jenkins/workspace/NodeJSSampleCI > mocha test --reporter mocha-junit-reporter Recording test results Finished: SUCCESS また、ビルドの「テスト結果」から下記画像のようなテスト結果を取得できるはずです。 テスト結果 おわりに いかがでしたでしょうか、「NodeJS Plugin」を利用することでNode.jsのアプリケーションをJenkinsでCIする環境が容易に構築できることがお分かりいただけたかと思います。基本的に プラグイン の設定のみで完結するため、 個人的にはサーバで直接作業をする必要がないのが嬉しいと感じています。 まだまだ自身もCIやJenkinsについて不勉強な面がありますので、今後も学習していこうと思います。 参考 爆速でJenkinsをマスターしよう(NodeJS編) ~ JenkinsセットアップからNodeJS自動テスト、Job DSLまで ~ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは 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