はじめに こんにちは 入社２年目のEngawaです。タイトルに記載の通り5/18(土)に開催された JJUG CCC 2019 Springに参加してきました。 様々なセッションを見てきましたがその中でも特に印象に残ったものを紹介したいと思います。 http://www.java-users.jp/ccc2019spring/#/ www.java-users.jp ちなみに今回の JJUG には ラク ス社員も登壇しました！！ 発表資料は下記からご確認ください。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 印象に残ったセッション テストエンジニアが教える　 JUnit を書き始める前に考えるべきテスト JUnit の書き方についてではなくテストの目的は何か、なぜ早期のテストをするのかなどのテストコード作成の前に考えることについてのセッションでした。 提示された例題からどのようなテストを行うのか実際に考え、それをほかの方と共有することも行いました。大体似たり寄ったりな部分はあったのですが、細かな部分で目の付け所が違い、自分では思いつかないようなテストケースもありました。 テストケースを考える際はどこのテストを行うのか、なぜ行うのかを考えるのは当然だと思っていたのですが、それがどれくらい重要なことなのかを改めて実感しました。 今日から始めるカジュアルな ソースコード 解析 JavaParserという Java の 構文解析 ツールを使って、 ソースコード 解析の入門的な内容から、簡単な実用例までご紹介していくセッションでした。 構文解析 はいままで行ったことがなく、なんとなく敷居が高そうだなくらいの認識でしたが、そこまで難しくないのではないかと印象を受けたので手を出してみるいい機会になったかもしれません。 終わりに 今回初めて JJUG に参加しました。所々理解できなかったこともあり、自身の知識の乏しさを痛感させられました。 これを機にどのような技術が流行っているのかを把握し、今後のために学習を行っていこうと思います。

RAKUS Meetup のロゴ こんにちは、鈴木です。先日 RAKUS Meetup Tokyo #3 を開催いたしましたので、そちらのイベントレポートを投稿します。 当日の様子 発表の紹介 オブジェクトストレージ導入にあたり、ネットワークエンジニア観点で工夫した事、苦労した事。 売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 懇親会 次回開催について 当日の様子 RAKUS Meetup Tokyo #3 会場の様子 今回は弊社本社オフィスの セミ ナールームでの開催でした。 当日は雨も降る 悪天候 の中ご参加いただきありがとうございました。RAKUS Meetup Tokyoは毎回雨が降っている気がします。次回は晴れて欲しいですね。 発表の紹介 オブジェクトストレージ導入にあたり、ネットワークエンジニア観点で工夫した事、苦労した事。 弊社インフラエンジニアの永易の発表です。 楽楽精算 にオブジェクトストレージを導入するにあたり考慮した内容を、情報セキュリティの3要素（機密性、完全性、可用性）に沿って発表しました。 プロダクト選定 ハードウェア構成 レプリケーション 設定 バージョニング設定 といった観点について発表しました。 売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 弊社エンジニアの西角の発表です。 オブジェクトストレージの導入移行時に注意したことや、発生したトラブルについて発表しました。この発表は 先日のJJUG で発表した内容の再演＋αになっています。 ファイルストレージをオブジェクトストレージにした際の実装上の影響範囲 20日 かけてデータ移行 移行後に発生したトラブル メンテナンス時間が約90%削減 といった観点について発表しました。 懇親会 お約束の Sushi と Pizza と Beer に加えて RED BULL を用意しました 次回開催について 次回の東京での開催は8月に 「納涼肝試し！ WEBサービス 運用の怖い話」 をテーマに開催予定です。 今月6月の後半には募集を開始できると思います。 Connpassのグループ に入っていただけると通知が飛びますのでそちらもよろしくおねがいします。

はじめに こんにちは、新卒3年目エンジニアのkasuke18です。 私は昨年度の1年間、ビアバッシュ運営委員の一員として抜擢され、活動していました。 運営する中で見つかったとある課題に対して、Webアプリを導入することで カイゼン できそうだということになり、せっかくなのでビアバッシュ運営委員でWebアプリを作ることになりました。 現在その開発の真っ最中ですが、振り返ってみて得られた気付きをご紹介しようと思います。 はじめに やってみての気づき 一人で学習するよりも効率がよい わからないことは全員で考える 作業時間を作るのが大変 まとめ やってみての気づき 一人で学習するよりも効率がよい エンジニアとして自己学習は大切です。とはいえモチベーション維持が難しく、特に新しい技術を学ぶ場合は、一人では資料を見て手を動かすのが限界でマンネリ化してしまうことが多いです。その点、チームで開発することによって相互にレビューできるので、フィードバックをしたりされたりで、一人でやっていては気づけないことにも気づけます。そこからさらに個人的に気になったところを追加で学習することもあります。 　 わからないことは全員で考える チームメンバー内に詳しい人がおらず、若手メンバーのみで開発しているため、わからないことを相談しようにも全員わからないという場面があります。そのようなときは全員で ベストプラクティスは何だろう？ などと考えながら進めています。三人寄れば 文殊 の知恵、というほどうまくいかなくとも全員で考えた結果なので納得感を持って進められます。 作業時間を作るのが大変 手元に開発環境がなければ確認できないので、まとまった時間を作って自宅で作業（実装・レビュー）することが多くなります。とはいえ、他にもやりたいことがあるので、基本的には週末以外ではまとまった時間が取れません。この課題はチームメンバー内でも認識しており、 もくもく勉強会 などの集まれる時間を作ってモブプロ的に開発をすることで、差し戻しの手間を減らし、効率的に進められるように対策しています。 また、個人でも通勤時間中にコードを見るだけなら スマートフォン でもできるので、コードレビューだけやることにしています。先にできることはやっておいて、週末は動作確認と自分の実装に集中して取り組むというようにしています。 まとめ この記事を書くにあたって、個人的に振り返ってみました。 今回の開発で採用した新しい技術は、個人的には一人で学習するにはハードルが高く、おそらく中途半端に学習するだけで終わってしまうことになってしまいそうですが、チームで開発することでそのような状況を回避できました。 毎回このような機会があるわけではないので、次に未経験の技術を学習する際は 勉強会 に参加するなどして、意見交換ができる場に身を置くことを選択肢として考えようと思います。

こんにちわ @kawanamiyuu です。先日 ブログでお知らせ しました通り、5/18 (土) に開催された JJUG CCC 2019 Spring で登壇してきました。 もうひとりの登壇者である西角さんの登壇レポートはこちら↓ tech-blog.rakus.co.jp 登壇資料 speakerdeck.com 登壇に対する反応 #ccc_i2b hashtag on Twitter ありがたいことに満席でした！ 立ち見出てます！！ #ccc_i2b #jjug_ccc — yaaka (@yaaka4) 2019年5月18日 人が多すぎてびっくり #ccc_i2b — tea (@tethon) 2019年5月18日 セッションの冒頭で ArchUnit を知っているか問いかけてみたところ、ほぼ全員の方が ArchUnit を知らなかったようでした。 ArchUnit。 初めて聞いた。 — すめらぎ (@sumeragizzz) 2019年5月18日 アーキテクチャ の品質維持関する悩み、ArchUnit の魅力、テストコードのア イデア や事例を共有できる絶好の機会となりました。 アーキテクトの悩み めっちゃわかる 初期の設計がいつの間にか守られなくなる 新規メンバーへの周知ができていない レビュー負担 #ccc_i2b — hituzi3939 (@hituzi3939) 2019年5月18日 commonがいつの間にかcommonでなくなるのは、あるある過ぎる #ccc_i2b #jjug_ccc — yaaka (@yaaka4) 2019年5月18日 ArchUnit、 アーキテクチャ だけじゃなくてアプリケーション・チーム固有のルールも適応度関数化できてだいぶよさそう #ccc_i2b — enk (@enk_enk) 2019年5月18日 普段、ドキュメントに書いてるような開発標準をテストコードで表現して自動チェックできる感じっぽくてよさそう > ArchUnit #jjuc_ccc #ccc_i2b — kntmr (@knt_mr) 2019年5月18日 ArchUnit をぜひプロダクトで活用していただきたい！ ArchUnit これは使えそう。 — かわぬん (@chronos2074) 2019年5月18日 セッションは聞いてないんだけど、ArchUnit が良さそうだったなー。一度は評価してみたい。 — Hirotaka Ikoma (@hikoma) 2019年5月18日 さいごに （登壇資料の結びの言葉より） 自動テストで アーキテクチャ の品質を担保しつつ、プロダクト開発を通じて継続的に アーキテクチャ を磨いていくことができるとしたら... どうでしょうか。わくわくしないでしょうか？ 😄

こんにちは。西角（west-c）です。 先日告知がありました通り 、5月18日（土）に開催された JJUG CCC 2019 Spring にて「売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話」というタイトルで登壇しました。 当日発表を見に来てくださった皆様、ありがとうございました。 発表資料 登壇レポート 今年でサービス開始10周年を迎える「 楽楽精算 」にオブジェクトストレージを導入したプロジェクトでの一部始終として、以下のようなお話をしました。 オブジェクトストレージ導入の要因となった楽楽精算が抱えていた課題 クラウド サービス（ Amazon S3 など）ではなくオンプレミスのストレージを選択した理由 導入時にアプリケーションの設計面で意識した点 導入後に発生したトラブルから意識すべきだった点 アプリケーションの設計に着手したのはちょうど去年の今頃でしたが、今回の私達のようにオブジェクトストレージへファイルデータ移行を行った事例はあまり見当たらず、手探り状態で設計を進めていたと記憶しています。 今回の登壇が決まってから、同じような課題・悩みを抱える（または今後抱かれるかもしれない）方向けにできる限り生身の情報をお届けしたいと考え、準備を進めました。 拙い発表ではありましたが、発表を聞いてくださったり資料を見てくださった皆様にとって何かしらの知見が得られる内容になれば幸いです。 また、こちらは個人的な話ですが、私にとって今回が初めての外部技術イベントでの登壇でした。 緊張こそしましたが、大きな問題も起きず発表を終えることができて良かったです。 これも資料作成や発表練習に付き合っていただいたり当日応援に来てくれた弊社メンバーの協力のおかげです 🙇 一方で、登壇の場に慣れていないことによる反省点も多々感じましたので、今後もこういった場に参加することで腕を磨いていきたいと思いました！

こんにちは、MasaKuです。 先日、 PostgreSQL の運用知識学習として以下の書籍を読みました。 gihyo.jp 書籍内で紹介されていた「 パーティショニング 」について、公式ドキュメントに記載されている内容と照らし合わせて、どのようなケースであればパフォーマンスの向上が見込めるのかを確認してみようと思いました。 なお、PostgreSQL11のパーティショニングについては、弊社の アドベントカレンダー にも掲載されておりますので、あわせてご確認いただけると幸いです。 qiita.com テーブルのパーティショニングとは パーティショニングのメリット データの準備 実践 パーティションのキーを用いた検索の場合 全体検索の場合 パーティション分割のキー以外の検索の場合 おわりに 参考サイト テーブルのパーティショニングとは １つのテーブルを複数のテーブルに分割して管理することをテーブルのパーティショニングといいます。 パーティショニングには以下の種類があります。 ショッピングサイトの購入履歴に関するデータ管理方法を例に説明したいと思います。 レンジ・パーティショニング 指定された範囲の値を基にデータを分散して配置する。 （例: 購入履歴テーブルを１ヶ月単位で分割） レンジ・パーティショニング リスト・パーティショニング テーブルのキーの値を基にデータを分散して配置する （例: 商品カテゴリIDによる分割） リスト・パーティショニング ハッシュ・パーティショニング（ PostgreSQL 11 より） データの挿入時にカラムの ハッシュ値 を元に特定の パーティション にデータが偏らないように分散して配置する （例: レコードIDによる分散） ハッシュ・パーティショニング パーティショニングのメリット PostgreSQLの公式ドキュメント ではパーティショニングのメリットを以下のように説明されています 特定の条件下で問い合わせのパフォーマンスが劇的に向上することがあります。 特にテーブル内のアクセスが集中する行の殆どが単一または少数の パーティション に存在している場合がそうです。 パーティショニングはインデックスの先頭にある列の代わりになり、インデックスの大きさを小さくして、インデックスの頻繁に使われる部分がメモリに収まりやすくなるようにします。 問い合わせや更新が一つの パーティション の大部分にアクセスする場合、インデックスやランダムアクセスを使用してテーブル全体にまたがる読み取りをする代わりに、その パーティション への順次アクセスをすることでパフォーマンスを向上させることができます。 一括挿入や削除について、その要件を パーティション の設計に組み込んでいれば、それを パーティション の追加や削除で実現することが可能です。 ALTER TABLE DETACH PARTITIONを実行する、あるいは個々の パーティション を DROP TABLEで削除するのは、一括の操作をするよりも遥かに高速です。 これらのコマンドはまた、一括のDELETEで引き起こされるVACUUMのオーバーヘッドを完全に回避できます。 滅多に使用されないデータを安価で低速なストレージメディアに移行することができます。 今回は、1つ目の利点に着目して動作を確認してみたいと思います。 データの準備 検証のために以下のテーブルを作成しておきます。 -- 商品カテゴリテーブル CREATE TABLE categories( id SERIAL PRIMARY KEY, name TEXT UNIQUE ); -- 商品カテゴリテーブルのサンプルデータ INSERT INTO categories (name) VALUES ( ' 食品 ' ); INSERT INTO categories (name) VALUES ( ' 衣類 ' ); INSERT INTO categories (name) VALUES ( ' 本 ' ); INSERT INTO categories (name) VALUES ( ' コンピュータ ' ); -- 購入位履歴テーブル CREATE TABLE purchase( id SERIAL PRIMARY KEY, category_id INTEGER , name TEXT, date TIMESTAMP DEFAULT NOW()), FOREIGN KEY (category_id) REFERENCES categories(id) ); 購入履歴テーブルのテストデータは過去５年分で合計50万件とします。 -- 購入履歴テーブルのサンプルデータ INSERT INTO purchase (name, category_id, date ) SELECT ' test ' , TRUNC ((RANDOM() * 4 ):: NUMERIC, 0 ) + 1 , ' 2014-01-01 ' :: DATE + (RANDOM() * 1780 ):: INTEGER AS date FROM GENERATE_SERIES( 1 , 500000 ) ; パーティショニングで作成するテーブルについては後述します。 実践 文章内にもありますとおり、特定条件下とは「特にテーブル内のアクセスが集中する行の殆どが単一または少数の パーティション に存在している場合」です。 購入履歴を例にして考えてみたいと思います。 あるサービスでは、5年分の購入履歴を保管しているとします。 そのうち、直近１年の購入履歴からオススメ商品を提示する機能を実装する場合、購入履歴を一つのテーブルで管理するよりも、年単位で分割されたテーブルで管理しておくほうがパフォーマンスは向上するようです。 今回のケースでは date カラム をキーとするレンジ・ パーティション を行います。 CREATE TABLE purchase_range( id SERIAL, category_id INTEGER , name TEXT, date TIMESTAMP DEFAULT NOW(), FOREIGN KEY (category_id) REFERENCES categories(id) ) PARTITION BY RANGE ( date ); CREATE TABLE purchase_range_y2014 PARTITION OF purchase_range FOR VALUES FROM ( ' 2014-01-01 00:00:00 ' ) TO ( ' 2014-12-31 23:59:59 ' ); CREATE TABLE purchase_range_y2015 PARTITION OF purchase_range FOR VALUES FROM ( ' 2015-01-01 00:00:00 ' ) TO ( ' 2015-12-31 23:59:59 ' ); CREATE TABLE purchase_range_y2016 PARTITION OF purchase_range FOR VALUES FROM ( ' 2016-01-01 00:00:00 ' ) TO ( ' 2016-12-31 23:59:59 ' ); CREATE TABLE purchase_range_y2017 PARTITION OF purchase_range FOR VALUES FROM ( ' 2017-01-01 00:00:00 ' ) TO ( ' 2017-12-31 23:59:59 ' ); CREATE TABLE purchase_range_y2018 PARTITION OF purchase_range FOR VALUES FROM ( ' 2018-01-01 00:00:00 ' ) TO ( ' 2018-12-31 23:59:59 ' ); -- 購入履歴テーブルサンプルデータ（パーティション） INSERT INTO purchase_range (name, category_id, date ) SELECT ' test ' , TRUNC ((RANDOM() * 4 ):: NUMERIC, 0 ) + 1 AS category_id, ' 2014-01-01 ' :: DATE + (RANDOM() * 1780 ):: INTEGER AS date FROM GENERATE_SERIES( 1 , 500000 ) ; パーティション のキーを用いた検索の場合 まずは、2017年12月の購入履歴の件数を取得する SQL を実行した結果を見てみましょう。 -- 単一テーブルで管理されている場合 explain analyze select count (*) from purchase where date > ' 2017-12-01 ' and date < ' 2017-12-31 ' ; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------------- Finalize Aggregate (cost= 6114 . 90 .. 6114 . 91 rows = 1 width= 8 ) (actual time= 125 . 218 .. 125 . 218 rows = 1 loops= 1 ) -> Gather (cost= 6114 . 69 .. 6114 . 90 rows = 2 width= 8 ) (actual time= 120 . 538 .. 125 . 274 rows = 3 loops= 1 ) Workers Planned: 2 Workers Launched: 2 -> Partial Aggregate (cost= 5114 . 69 .. 5114 . 70 rows = 1 width= 8 ) (actual time= 96 . 651 .. 96 . 652 rows = 1 loops= 3 ) -> Parallel Seq Scan on purchase (cost= 0 . 00 .. 5108 . 41 rows = 2513 width= 0 ) (actual time= 0 . 036 .. 96 . 162 rows = 2053 loops= 3 ) Filter: (( date > ' 2017-12-01 00:00:00 ' ::timestamp without time zone) AND ( date < ' 2017-12-31 00:00:00 ' ::timestamp without time zone)) Rows Removed by Filter: 100529 Planning Time: 0 . 215 ms Execution Time: 125 . 323 ms -- パーティションで分割しているテーブルの場合 explain analyze select count (*) from purchase_range where date > ' 2017-12-01 ' and date < ' 2017-12-31 ' ; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost= 26 . 09 .. 26 . 10 rows = 1 width= 8 ) (actual time= 0 . 007 .. 0 . 007 rows = 1 loops= 1 ) -> Append (cost= 0 . 00 .. 26 . 07 rows = 5 width= 0 ) (actual time= 0 . 004 .. 0 . 004 rows = 0 loops= 1 ) -> Seq Scan on purchase_range_y2017 (cost= 0 . 00 .. 26 . 05 rows = 5 width= 0 ) (actual time= 0 . 003 .. 0 . 003 rows = 0 loops= 1 ) Filter: (( date > ' 2017-12-01 00:00:00 ' ::timestamp without time zone) AND ( date < ' 2017-12-31 00:00:00 ' ::timest amp without time zone)) Planning Time: 0 . 667 ms Execution Time: 0 . 034 ms 実行時間は パーティション で分割しているテーブルの方が短くなるという結果になりました。 日時で パーティション を分割しているため、対象外の期間のレコードにはアクセスされないためパフォーマンスが向上しました。 全体検索の場合 今度は、全データの件数を取得する場合を考慮してみました。 -- 単一テーブルで管理されている場合 explain analyze select count (*) from purchase; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------- Finalize Aggregate (cost= 6789 . 38 .. 6789 . 39 rows = 1 width= 8 ) (actual time= 274 . 970 .. 274 . 970 rows = 1 loops= 1 ) -> Gather (cost= 6789 . 17 .. 6789 . 38 rows = 2 width= 8 ) (actual time= 273 . 169 .. 275 . 097 rows = 3 loops= 1 ) Workers Planned: 2 Workers Launched: 2 -> Partial Aggregate (cost= 5789 . 17 .. 5789 . 18 rows = 1 width= 8 ) (actual time= 252 . 091 .. 252 . 092 rows = 1 loops= 3 ) -> Parallel Seq Scan on purchase (cost= 0 . 00 .. 5268 . 33 rows = 208333 width= 0 ) (actual time= 0 . 016 .. 105 . 048 rows = 166667 loops= 3 ) Planning Time: 0 . 135 ms Execution Time: 275 . 149 ms -- パーティションで分割しているテーブルの場合 explain analyze select count (*) from purchase_parent; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------- Finalize Aggregate (cost= 8690 . 90 .. 8690 . 91 rows = 1 width= 8 ) (actual time= 429 . 425 .. 429 . 425 rows = 1 loops= 1 ) -> Gather (cost= 8690 . 68 .. 8690 . 89 rows = 2 width= 8 ) (actual time= 429 . 415 .. 429 . 608 rows = 3 loops= 1 ) Workers Planned: 2 Workers Launched: 2 -> Partial Aggregate (cost= 7690 . 68 .. 7690 . 69 rows = 1 width= 8 ) (actual time= 406 . 901 .. 406 . 901 rows = 1 loops= 3 ) -> Parallel Append (cost= 0 . 00 .. 7169 . 85 rows = 208334 width= 0 ) (actual time= 0 . 018 .. 269 . 589 rows = 166667 loops= 3 ) -> Parallel Seq Scan on purchase_y2017 (cost= 0 . 00 .. 1259 . 81 rows = 60481 width= 0 ) (actual time= 0 . 015 .. 90 . 205 rows = 102817 loops= 1 ) -> Parallel Seq Scan on purchase_y2015 (cost= 0 . 00 .. 1259 . 19 rows = 60419 width= 0 ) (actual time= 0 . 017 .. 112 . 477 rows = 102713 loops= 1 ) -> Parallel Seq Scan on purchase_y2016 (cost= 0 . 00 .. 1257 . 65 rows = 60365 width= 0 ) (actual time= 0 . 016 .. 18 . 776 rows = 34207 loops= 3 ) -> Parallel Seq Scan on purchase_y2014 (cost= 0 . 00 .. 1255 . 53 rows = 60253 width= 0 ) (actual time= 0 . 014 .. 61 . 613 rows = 51215 loops= 2 ) -> Parallel Seq Scan on purchase_y2018 (cost= 0 . 00 .. 1096 . 00 rows = 52600 width= 0 ) (actual time= 0 . 019 .. 76 . 853 rows = 89420 loops= 1 ) Planning Time: 0 . 162 ms Execution Time: 429 . 668 ms ある意味予想通りでしたが、実行時間はパーティショニングしているテーブルのほうが長くなりました。 テーブルを分割しているために、本来一度で完了するシーケンシャルスキャンが パーティション の数だけ実行されるため、パフォーマンスが劣化したと思われます。 購入履歴を検索する、ということに主眼を置く場合は、運用方法次第ではパーティショニングが必ずしも適切ではない場合もあるので注意が必要です。 パーティション 分割のキー以外の検索の場合 最後に、 パーティション 分割に利用したキー以外のカラムを絞込み条件にした場合のパフォーマンスを確認してみます。 今回はカテゴリIDを対象にした検索を行ってみたいと思います。 -- 単一テーブルで管理されている場合 explain analyze delete from purchase where category_id = 1378 ; QUERY PLAN ------------------------------------------------------------------------------------------------------------- Delete on purchase (cost= 0 . 00 .. 7031 . 81 rows = 1 width= 6 ) (actual time= 87 . 803 .. 87 . 803 rows = 0 loops= 1 ) -> Seq Scan on purchase (cost= 0 . 00 .. 7031 . 81 rows = 1 width= 6 ) (actual time= 87 . 801 .. 87 . 801 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 307745 Planning Time: 0 . 062 ms Execution Time: 87 . 829 ms -- パーティションで分割しているテーブルの場合 explain analyze delete from purchase_range where category_id = 1378 ; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------- Delete on purchase_range (cost= 0 . 00 .. 7869 . 12 rows = 5 width= 6 ) (actual time= 103 . 825 .. 103 . 826 rows = 0 loops= 1 ) Delete on purchase_range_y2014 Delete on purchase_range_y2015 Delete on purchase_range_y2016 Delete on purchase_range_y2017 Delete on purchase_range_y2018 -> Seq Scan on purchase_range_y2014 (cost= 0 . 00 .. 1614 . 14 rows = 1 width= 6 ) (actual time= 22 . 576 .. 22 . 576 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 76811 -> Seq Scan on purchase_range_y2015 (cost= 0 . 00 .. 1612 . 55 rows = 1 width= 6 ) (actual time= 21 . 112 .. 21 . 112 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 76844 -> Seq Scan on purchase_range_y2016 (cost= 0 . 00 .. 1627 . 21 rows = 1 width= 6 ) (actual time= 20 . 850 .. 20 . 850 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 77537 -> Seq Scan on purchase_range_y2017 (cost= 0 . 00 .. 1603 . 49 rows = 1 width= 6 ) (actual time= 21 . 146 .. 21 . 146 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 76279 -> Seq Scan on purchase_range_y2018 (cost= 0 . 00 .. 1411 . 74 rows = 1 width= 6 ) (actual time= 18 . 105 .. 18 . 106 rows = 0 loops= 1 ) Filter: (category_id = 1378 ) Rows Removed by Filter: 67099 Planning Time: 0 . 376 ms Execution Time: 103 . 901 ms 多少の差があるもののそこまで大きな差がないという、少し意外な結果となりました。 というのも、今回作成したサンプルデータは日付でパーティショニングしているため、カテゴリIDで絞り込んだ場合は分散配置しているテーブルすべてをチェックしなければならなくなります。 そのため、先ほどの全体検索と同程度のパフォーマンスになると思っていました。 パーティション で分割されているテーブルの数や、１テーブルに格納されているレコードの量によって差が出るのではないでしょうか。 おわりに パーティショニングといっても、データ管理の 銀の弾丸 というものではなく、場合によってはパフォーマンスが劣化する場合があることがわかりました。 今回はレンジ パーティション を例にしましたが、実際のサービスがどのように運用されていくかを考慮することで、どのように パーティション を分割すべきかが見えてくるのではないでしょうか。 （もしくは、 パーティション 分割する必要が無いことも） その他にも、継承パーティショニングの検証や、高負荷状態でのパフォーマンスなど、検証してみたいことがありましたが、その辺はまた別の機会にしたいと思います。 参考サイト ［改訂新版］内部構造から学ぶPostgreSQL 設計・運用計画の鉄則：書籍案内｜技術評論社 第1回「テーブル・パーティショニングが大幅アップデート」 | NTTデータ先端技術株式会社 PostgreSQL 11先行紹介 - パーティション機能のさらなる改善 | NTTテクノクロスブログ PostgreSQL11のパーティショニングを試してみる - Qiita 5.10. テーブルのパーティショニング エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 最近、 オライリー から出版されている「ヘルシー プログラマ 」という書籍を読みました。 エンジニア目線で健康について書かれているのですが、面白い内容だったので紹介してみたいと思います。 www.oreilly.co.jp はじめに 概要 なぜ読もうと思ったのか？ 面白いと思ったポイント まとめ 概要 長時間座ったまま仕事を続ける プログラマ の悩みである、腰痛、手首の痛み、目の痛みや頭痛といった健康問題に対して、食生活や生活習慣を改善する方法や簡単なエクササイズを紹介しているエンジニア向けの書籍になります。 なぜ読もうと思ったのか？ 連休の間に技術書を1冊は読もうと思っていた 本屋へ探しに行ったときに技術書のコーナーでたまたま見つけたからです。 面白そうだと思ったので購入してみました。 最近、健康意識が高めなので少し読んでみて面白かった。 自炊をし始めて3年目に突入し、普段から食習慣には気をつかっています。 広く浅く調べたりしていますが、もう少し知識が欲しいと思っていました。 健康や栄養学に興味があることも大きい理由です。 面白いと思ったポイント エンジニアにウケそうな表現が多くてじわじわくる 健康状態を改善することを リファクタリング と表現されている アジャイル な方法論で書かれている 「体重計はサーバのメモリをモニタリングするのと同じように、健康をモニタリングするためのツール」 説明が科学的であること 学会誌から引用されていたり、数値などによる科学的な裏付けのある説明になっているので説得力がありました。 プログラマ 視点で書かれていることもあり、ロジカルな内容でした。 頭痛、眼精 疲労 、腰痛、手首痛への対策 それぞれ、デスクワークによって引き起こされる原因が科学的に書かれていて、その対策や、エクササイズについて書かれています。 眼精 疲労 やそれによる頭痛は特に悩みなので、以下のような対策を意識してやってみようかなと思いました。 「頭痛は生活を脅かすほどのものでなくても、生産性を下げてしまう」と書かれていましたが、そのとおりだと思います。 こまめに瞬きする 目の運動をする(20分に1回、6メートル先を20秒見つめる) 休憩を頻繁に取る(目を休めるミニ休憩を増やす) メガネを外す(意外と大事！) カフェインは摂りすぎない(頭痛を誘発する、一時的に解消する効果もあるので注意) 水を飲む(1日２リットル) まとめ 健康には気をつけたいけど、何をしたら良いかわからないエンジニアには良い書籍なのではないかと思いました。 新卒3年目になり、健康であることは自分のパフォーマンスに繋がってくるなと日々感じています。 運動しないといけないなーという気持ちになり、生活習慣を改善しようとするきっかけにはなったと思います。 ちょうど健康診断のシーズンでもあるので、 リファクタリング を始めるきっかけの参考になれば幸いです。

はじめに 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」 素晴らしい考え方ですね。素直に参考としたいです。 いろいろと見ていきましたが、共通となりそうな点も多く、自分たちのやっていることにさらに自信が持てそうです。