はじめに はじめまして、新卒一年目のYoshidaMichaelです。 研修でGitの使い方を学び、「家で作ってる Bot もGitで管理しちゃうぞー！」なんて意気込んでいたわけですが、 うっかり トーク ンが載った状態のコードをpushしてしまって大変なことになりそうでした。 今回はそれを GitHub に助けていただいた、そんなお話です。 はじめに シークレットスキャニング 提携サービス 根本対処 方法1: 別のファイルに記述してそれを読み取る 方法2: 環境変数に記述する まとめ シークレットスキャニング シークレットスキャンニングについて - GitHub Docs GitHub は リポジトリ をスキャンして既知のシークレットのタイプを探し、誤ってコミットされたシークレットの不正使用を防止します なんと GitHub ではpushされた際に自動で トーク ン (ここではシークレットと表現されています) が含まれていないか 確認してくれるんですね。 どうやら私のようなうっかりミスをする人は多いらしく、 トーク ンスキャニングを導入してから発見された トーク ン 流出は1年間で10億件にものぼるそうです。 この機能が導入されてなかったと思うと恐ろしい話ですね......。 提携サービス 実は トーク ンが流出した当初、私はシークレットスキャニングが GitHub の機能であることを知りませんでした。 というのも、私が GitHub へpushした際に受けた警告は以下のようなものだったのです。 トーク ン流出時に受け取ったメッセージ これを見て「うわー、Discordって GitHub の投稿まで見てるんだ！すごい！」なんて思ったわけですが、調べてみると GitHub が調査して トーク ンを発見、提携しているサービスと情報を共有しているそうです。 現在 GitHub は32のサービスプロバイダと提携しており、それらのサービスであれば万一 トーク ンが流出しても大惨事になることは防げそうです。 根本対処 今回はシークレットスキャニングが優秀だったおかげで トーク ンを発見してもらい、すぐさまDiscordに トーク ンを リセットしてもらえたわけですが、いつも発見してもらえるかは正直わからないところです。 また、そもそも GitHub と提携していないサービスの トーク ンであれば検出されず、そのまま外部へ流出してしまうこともあるでしょう。 そこでここでは「そもそも トーク ンを流出させない工夫ってないの？」という方法を調べてみましたので紹介しようと 思います。 方法1 : 別のファイルに記述してそれを読み取る Bot を動かす環境に トーク ンの記述されたファイルを用意してそれを読み取る方法です。 ファイルは GitHub にはpushせず、 Bot を動かす環境だけで管理するようにします。 この方法は別の環境で Bot を動かしたい場合全ファイルを動かすだけで良いので楽な反面、そのファイルをうっかり GitHub などにアップしないことは気をつけなければなりません。 方法2: 環境変数 に記述する どうやらメジャーな方法はこちらのようです。 環境変数 自体は Windows でプログラミングをする際にPathを通す過程で触った方も多いのではないでしょうか。 環境変数とは - IT用語辞典 e-Words 環境変数 とは、OSが設定値などを永続的に保存し、利用者や実行されるプログラムから設定・参照できるようにしたもの。プログラムの実行時などに必要となる、利用者やコンピュータごとに内容が異なる設定値などを記録するために用いられる。 Python では標準ライブラリで 環境変数 の設定、取得等が行えるそうなので Python を利用した開発ではこちらの方法も気軽に利用できそうですね。( Python 以外でも気軽かはわかりません。) 私も今後はこちらで トーク ン管理をしようかなと思います。 まとめ 今回は GitHub のシークレットスキャニングと トーク ン管理の方法について紹介しました。 皆さんの トーク ン流出によるリスクを少しでも下げることに貢献できましたら幸いです。 それでは！

はじめに いつも ラク スエンジニアブログをご覧いただき、ありがとうございます！ 技術広報のitoken1013です。 今回は8月第2回目のMeetup 『 SaaS 新規プロダクトの技術』 のコンテンツを紹介させていただきます。 当日は ラク スMeetup史上、最多の120名超の方々にご参加いただき、熱いイベントとなりました。 ご参加いただきました方々、本当にありがとうございました！ rakus.connpass.com イベントテーマ概要 ラク スでは多くの to B向け SaaS を展開し続ける傍ら、新たな領域のサービス立ち上げに向けて企画が日々進められています。 今回はイベントテーマの『新規プロダクト』が表す通り、以下の新規 HRTech系プロダクトの開発より得られた知見を紹介させていただきました。 楽楽労務 楽楽勤怠 技術選定・開発・インフラそれぞれの立場より4名のエンジニアが発表させていただき、今までになく幅広いコンテンツを皆様にご提供できたイベントだったのではないかと思います。 ご参加いただきました方の中には新規プロダクト開発に関わっている方も多く、今回のMeetupを通じて日々の開発に役立つ情報をご提供できましたのであれば、大変幸いです。 発表の紹介 それでは今回発表させていただきました内容を紹介させていただきます！ 発表スライドとlogmiから、当日の様子を感じ取っていただけますと幸いです！ 新サービス立ち上げ時の技術選定と、サービス立ち上げに向けた ラク スの取り組み まずは ラク スの先行技術検証を主導しつつ、今年度はオンラインイベントのパーソナリティとしても大活躍中の鈴木より、楽楽 労務 における アーキテクチャ 選定のご紹介からです。 エンジニアであれば新サービス開発にはモダンな先端技術を導入したいものですが、 組織の 全体最適 を考えた結果、技術導入を見送ることも珍しいことではないかと思います。 今回、鈴木の紹介ではこのようなさまざまな経緯を踏まえて「導入しなかった技術」に着目し、 LADR（Lightweight Architecture Decision Records） という手法を紹介させていただきました。 技術検討から判断にいたるまでの意思決定の過程を可視化できるため、多くの ステークホルダー の関わる組織でプロダクト開発にお悩みの方には、ぜひ鈴木作成のテンプレートをご活用いただければと思います。 LADRを導入する上でのメリット・デメリットについても語られているため、多くのエンジニアにお役立ていただけるはずです。 logmi.jp speakerdeck.com はじめてのフロントエンド・バックエンド分離 2本目は楽楽勤怠でバックエンドエンジニアとして関わる西角より、 ラク ス初のフロントエンド・バックエンドを分離したプロダクト開発で得られた知見を紹介させていただきました。 2019年から開発がスタートした楽楽勤怠では、フロントエンドとバックエンドとのインターフェースとなるWeb API の開発を進めるにあたり、チーム間の連携にいくつかの課題を抱えていました。 フロントエンド・バックエンド双方のチームの生産性をより上げるための取り組みは、チーム開発に関わる日本中のエンジニアの皆様に参考にしていただけるはずです。 ラク スにとっても西角と楽楽勤怠チームが試行錯誤を繰り返して得た知見は、今後のプロダクト開発の大きな財産になっていくでしょう。 logmi.jp speakerdeck.com 新規プロダクトの開発速度と品質の両立を支える自動テスト 3本目は福岡より、楽楽 労務 での自動テストの取り組みの紹介です。 タイトルの通り、楽楽 労務 では開発のスピードと品質を両立するためにエンジニアが様々な取り組みを行っています。 今回はその中でも不可欠な3種類の自動テストを語らせていただきました。 各テストがもたらす恩恵、またどんな観点での品質担保を目的としてテストを作っていくのが最適なのか、開発の最前線に関わる福岡が詳細に紹介しています。 ユニットテスト （ JUnit ） アーキテクチャ テスト（ArchUnit） E2Eテスト（Puppeteer） テストコードを書くことが当たり前の文化となっている楽楽 労務 の開発チームから、品質担保と早期のプロダクトマーケットフィットの両立を実現する理想的な開発フローを知っていただけると幸いです。 logmi.jp speakerdeck.com 積極的に AWS サービスと自動化を使ってto Bの SaaS をローンチしたその後 最後はインフラエンジニアの柏木より、to B向け SaaS に AWS を活用する際のポイントを紹介させていただきました。 いまや IaaS の王道である AWS では数多くのサービスを利用可能ですが、楽楽 労務 をはじめとした大規模 SaaS を運用する柏木はインフラエンジニアとしてより長期的な目線に立ち、本質を捉えた利用ポイントを語っています。 後半に紹介される事例でも単に自動化を行うのではなく「なぜ？」を追求しており、柏木の理論から ラク スに根付く戦略志向を感じ取っていただけるはずです。 logmi.jp speakerdeck.com おわりに 新規プロダクトにおける ラク スの取り組み、いかがでしたでしょうか？ 新たなプロダクトの開発に奮闘するエンジニアの皆様に参考となる情報があれば幸いです。 さて、次回9/16(水)のMeetupでは 『プロダクトを持続的に開発・運用し続けるための取り組み』 を紹介する予定です。 長く幅広く SaaS を展開する ラク スだからこそできる開発戦略にご注目いただければと思います。 皆様のご参加をお待ちしています！ rakus.connpass.com

先日行われました、フロントエンドLT会 vol.1 -2020夏祭り-　にて初LTを無事終えました。logy0704です。 rakus.connpass.com 今回はLT会で発表した内容に加えて、スライドには収めきれなかった話について書きたいと思います。 speakerdeck.com Nuxt.jsとfirebaseに興味を持ったきっかけ 他にハマったこと RealtimeDatabase vs FireStore おわりに Nuxt.jsとfirebaseに興味を持ったきっかけ vue.jsとfirebaseの組み合わせについては、過去のエンジニアブログでも何度か触れられていたこともあり、いつか触りたいという思いがありました。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 加えて、環境構築周りの負荷軽減(vuex, vue-router)、将来的にPWAにも触れてみたいというモチベーションでNuxt.jsとfirebaseの組み合わせに至りました。 他にNuxt.jsを採用する理由としては、 SSR （サーバーサイド レンダリング ）が思い浮かびますが、今回の学習ではSPAモードを利用し、 SSR は採用しませんでした。 理由は、スライドにもある通り、バックエンド周りのことを極力気にしたくなかったからです。 他にハマったこと RealtimeDatabase vs FireStore これはハマったことというよりも知見がなかったため、考察に時間がかかったというほうが正しいです。 どちらもFirebaseによって提供される クラウド ホスト型 NoSQL データベースですが、似て非なる特徴を持っています。 具体的な選定ポイントについては、こちらのページを参考にさせていただきました。 firebase.google.com ページの記載からは、ややFireStore推しであるようにも受け取れますが、それぞれの特徴を踏まえた選択を行う必要があります。 特に、データモデルが異なるため、一度片方を利用し始めた後に、もう一方に乗り換えるのはなかなか難しいため注意が必要です。 今回のアプリでは、Realtime databaseを選択しました。 理由は、簡易なTODOアプリとしての利用であれば、FireStoreのような複雑なクエリは必要ないと判断したからです。 実際の商用レベルのアプリであれば、将来の機能拡張を加味した検討が必要になると思います。 おわりに 100人以上が聞いてくれている中での発表でLTデビューというのは多少緊張しましたが、良い経験になりました。 他の方の発表が良い刺激になったことは勿論、いざ自分が発表するとなると、あれこれ準備したりする分、やりっぱなしよりも知識が定着する気がします。 これが登壇駆動開発…！

こんにちわ @kawanamiyuu です。今回は私の所属する 楽楽労務 の開発チームで運用している コードレビュー ガイドライン とコードレビューにまつわる少し変わった取り組みについて紹介しようと思います。 楽楽労務の開発体制 コードレビューガイドライン策定の背景 コードレビューガイドライン策定の目的 レビュー指摘の重要度 コードレビューの工夫 「おやつ」という発明 おわりに 楽楽 労務 の開発体制 チーム 開発拠点は東京と大阪 1 チームあたり 3 〜 5 名の、合計 3 チーム（＋ スクラム マスター等）で スクラム 開発 *1 私はそのうちの 1 チームのリーダーを担当 ツール GitLab でソース管理し、Merge Request *2 を活用してコードレビューを実施 レビューを通ったコードがメインブランチにマージされる 開発タスク（PBI *3 、SBI *4 ）は Trello で管理 コードレビュー ガイドライン 策定の背景 開発規模拡大のための人員増とそれに伴う複数チーム体制への移行により、 チームごとにコードレビュー指摘の重要度や観点にばらつきがある 開発メンバーが自身の成長を測る指標として、Merge Request の差し戻し回数より細かい粒度の情報を収集しづらい といった課題が出てきていました。 コードレビュー ガイドライン 策定の目的 これらの課題を解決するためのコードレビュー ガイドライン を策定し、次の実現を目指しています。 開発チーム全体で同じ基準でコードレビューを行い、修正要否を判断できるようにする 開発メンバーがレビュー指摘を重要度や観点ごとに分析し、自身のふりかえりに活かせるようにする 観点を明文化することで、レビューイーのセルフチェックやレビュアー育成のインプットとして使えるようにする レビュー指摘の重要度 コードレビューで発生する指摘には必ず優先度を付け、プロダクト品質に対する重要度を表現します。 重要度 説明 MUST 必ず修正すべき。われわれが期待する当たり前品質に達しておらず、そのままではリリースできない。今放置するとあとで大きな負債になる SHOULD 可能なら修正すべき。リリーススケジュールを優先するため戦略的に修正を見送ることもできるが、その場合は次バージョンで修正を検討すべき IMO 修正判断はレビューイーに委ねられる。別解の提案や現時点では判断が難しい課題など、レビュアーの意見に過ぎない レビュアーはこれらの「重要度」に「観点」 *5 を加えて、Merge Request 上のコードに対してレビュー指摘を記述します。 ＜レビュー指摘の記述例＞ コードレビューの工夫 MUST レベルのレビュー指摘はリリース品質を満たしていないことを意味するため、必ず修正する必要がありますが、SHOULD レベルのレビュー指摘の修正判断には裁量があります。 私がリーダーを担当するチームでは 「SHOULD レベルのレビュー指摘はすぐには修正せずいったん負債として積み上げる」 という運用を試みています。平たくいうと、未修正の SHOULD レベルのレビュー指摘が残っていても Merge Request をマージしてよいことにしています。 これは、 まずはリリース可能品質到達を最速で目指すことで、開発の後工程のスケジュール上のリスクを減らしたい コードの問題を「いつ」「どの程度ちゃんと」修正するかという意思決定によって開発速度と品質のバランスを調整したい という考えが背景にあり、担当チームメンバーと開発チーム全体に説明のうえ、このような工夫を試しています。 この運用によって後回しにした負債タスクも Trello 上で管理しています。 その名も「 SHOULD 」レーン（まんま）です。 このレーンのタスクは、実装タスクのレビュー待ち時間やスプリントの切れ目など、主に開発業務のリードタイムが発生したときに、開発業務の 箸休め的なタスク として、各自が自主的に取って解消していく運用としています。 「おやつ」という発明 さて、いよいよ本題ですが、最近のスプリント終了時の振り返りで、私のチームのあるメンバーが「今回のスプリントはタイミングよく負債タスクを消化できた。おやつ感覚だった。」と発言しました。その瞬間、メンバー全員が「これだ！」と思いました。 そして 爆誕 したのが「 おやつ 」レーン（名前変えただけ）です。 この並びに「おやつ」の文字が並ぶのは面白いですね。 プログラマー にとって名前付けはとても重要です。 その対象の特徴を適切に捉えた良い名前が与えられることで、非常にすっきりとその世界観を理解することができます。 また、今回、負債タスクに「おやつ」という名前がついたことで、負債というネガティブなイメージがポジティブなイメージに変わり、負債解消に前向きに取り組むことができるようになりました。 おわりに 今回紹介したコードレビューに対する取り組みは、現状うまく回っています。開発中に発生した一部のレビュー指摘を負債として一時的に後回しにはするものの、「おやつ」感覚で適宜消化し、負債を溜め込まない状態をキープできています。 私たちの取り組みが、開発速度と品質を両立し、技術的負債に対して前向きに取り組みむためのア イデア となれば嬉しいです。 -- P.S. その後、次のような名言（迷言）も生まれています。 おやつの鮮度が落ちると背景理解に時間がかかる ＝ 負債を放置すると、実際に修正しようとしたときにどんなコンテキストでの指摘だったのか思い出して理解するのに時間がかかる おやつを食べすぎた ＝ メインの実装タスクよりも負債の解消を優先してしまい、実装タスクの完了が遅れた *1 : LeSS のようなイメージ *2 : GitHub でいうところの Pull Request のこと *3 : Product Backlog Item *4 : Sprint Backlog Item *5 : 外部品質上の指摘観点：「不具合」「互換性」etc。内部品質上の指摘観点：「理解容易性」「変更容易性」etc。

はじめに こんにちは。dd_fortです。 前回に引き続き、Dockerについての話になります。 Dockerの学習中に詰まった権限についての問題と、その解決法を紹介します。 はじめに ボリューム(Data Volume)とは permission denied が発生する問題 解決法 解決法1：マウントしたボリュームの権限を書き換える 解決法2：ユーザ情報の書かれたファイルを読み込み専用でマウントする 解決法3：コンテナ作成時にユーザとグループを追加する まとめ ボリューム(Data Volume)とは ボリュームとは、データを永続化できる場所を指します。 Dockerのコンテナ内部のデータはコンテナ破棄をすると消えてしまうため、 データを永続化させるための手段として ボリューム(volume) が存在します。 コンテナ内部の永続化の詳しい内容については、こちらの記事を参照ください。 tech-blog.rakus.co.jp permission denied が発生する問題 Linux 上でDockerコンテナ内でボリュームをマウントした際に、ホストからアクセスした場合に パーミッション の問題が発生することがあります。 ホストOSで使っているユーザとコンテナ内で使っているユーザのUIDと GID が不一致になることが原因のようです。 そのため、Docker for Mac / Windows ではほとんど発生しません。 $ id uid=1000(test) gid=1000(test) groups=0(test) # (コンテナ内) # id uid=0(root) gid=0(root) groups=0(root) 発生する環境 Linux ( Ubuntu , CentOS etc) WSL2 解決法 解決法1：マウントしたボリュームの権限を書き換える permission deniedが発生した ディレクト リ、ファイルの権限を直接書き換えることで解決することができます。 $ chmod 777 /var/project しかし、permission denied が発生しているファイル、フォルダのすべての権限を書き換えないといけないため、根本的な解決にはなりません。 解決法2：ユーザ情報の書かれたファイルを読み込み専用でマウントする コンテナ内のUIDと GID がホストOSと同じになるように、コンテナ起動時にUIDと GID を指定します。 また、 /etc/passwd との不整合が起きないようにホストOSの /etc/passwd をマウントする必要があります。 最後に、コンテナから /etc/passwd を書き換えないようにread only ( :ro ) でマウントします。 $docker run \ -u "$(id -u $USER):$(id -g $USER)" \ -v /etc/passwd:/etc/passwd:ro \ -v /etc/group:/etc/group:ro \ -it ubuntu 実行結果 $ id uid=1000(test) gid=1000(test) groups=1000(test) # (コンテナ内) test@hogehoge:~$ id uid=1000(test) gid=1000(test) groups=1000(test) 問題なくコンテナ内とホストOSでユーザ情報が共 通化 されていることが確認できました。 ただしこの方法のデメリットとして、別プラットフォーム間ではDockerファイル等を共有することができなくなります。 解決法3：コンテナ作成時にユーザとグループを追加する ホストOSのユーザ(UID)、グループ( GID )を 環境変数 として渡し、コンテナ内でユーザとグループを追加します。 # Dockerfile FROM ubuntu:latest RUN apt update \ && apt -yq dist-upgrade \ && apt install -yq --no-install-recommends \ sudo COPY entrypoint.sh /var/tmp CMD bash -E /var/tmp/entrypoint.sh && /bin/bash コンテナが終了しないように /bin/bash で対話モードで動かし続けます。 # docker-compose.yml version: "3" services: override: image: example/override-ids build: . container_name: override environment: - USER_NAME - USER_ID - GROUP_NAME - GROUP_ID volumes: - ./:/mnt/working tty: true 環境変数 で、ユーザ(UID)、グループ( GID )を渡すように設定します。 # entrypoint.sh useradd -s /bin/bash -m ${USER_NAME} export HOME=/home/${USER_NAME} usermod -u ${USER_ID} ${USER_NAME} groupadd -g ${GROUP_ID} ${GROUP_NAME} usermod -g ${GROUP_NAME} ${USER_NAME} useradd 、 groupadd でユーザとグループを追加。 usermod でユーザとグループを設定。 コンテナをビルドして実行します。 $ docker-compose build $ USER_NAME=$(id -un) \ USER_ID=$(id -u) \ GROUP_NAME=$(id -gn) \ GROUP_ID=$(id -g) \ sudo -E docker-compose up -d 実行結果 $ id uid=1000(test) gid=1000(test) groups=1000(test) $ docker exec -it override su - $(id -un) test@hogehoge:~$ id uid=1000(test) gid=1000(test) groups=1000(test) まとめ Dockerのコンテナ内にvolumeをマウントする際は、UID/ GID を正しく設定しなければなりません。 簡単な手段としての解決法は1,2ですが、解決法3を使うとほとんどの問題を解決することができます。 Dockerではまだまだ勉強を始めたばかりなので学習を進めていこうと考えています。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは、yk_itgです。 これまでいくつか PostgreSQL の記事を作成しましたが、今回は知っていると便利だと思う テーブル・DBの閲覧・コピー に関するtipsをまとめてみました。 私はテストを実施する時に結果を確認したり、データを用意する際によく使います。 PostgreSQL ユーザなら必須のテクニックを紹介していきますので、どうぞお役立てください！ はじめに テーブルを閲覧する テーブルの情報を確認したい：\d テーブルの一覧を確認したい：\dt 実行結果を見やすくしたい：\x 実行結果をファイルに出力して確認したい：\o DBを閲覧する DBの一覧を確認したい：\l テーブルをコピーする テーブルの構造をコピーしたい：CREATE TABLE (LIKE) テーブルのレコードをコピーしたい：INSERT INTO SELECT DBをコピーする DBをコピーしたい：createdb -T DBをコピーしたい：pg_dump 最後に 関連記事 テーブルを閲覧する テーブルの情報を確認したい： \d \d {テーブル名} を psql 上で実行するとテーブルの情報を表示することができます。 インデックスやシーケンスなどテーブル以外のリレーションを表示することも可能です。 postgres=# \d test テーブル "public.test" 列 | 型 | 照合順序 | Null 値を許容 | デフォルト ------+---------+----------+---------------+------------ id | integer | | not null | hoge | text | | | 'a'::text インデックス: "test_pkey" PRIMARY KEY, btree (id) "test_hoge_idx" btree (hoge) postgres=# \d test_pkey インデックス "public.test_pkey" 列 | 型 | キー? | 定義 ----+---------+-------+------ id | integer | はい | id プライマリキー, btree, テーブル "public.test" 用 テーブルの一覧を確認したい： \dt \dt を psql 上で実行するとテーブルの一覧を表示することができます。 テーブル以外にも \di 、 \ds 、 \dv を使えば、それぞれインデックス、シーケンス、ビューの一覧を表示することができます。 postgres=# \dt リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+------+----------+---------- public | test | テーブル | postgres (1 行) 実行結果を見やすくしたい： \x \x を psql 上で実行すると SQL やメタコマンド等の実行結果を拡張表示（縦に表示）することができます。 例えば、カラムが多すぎてターミナルで折り返して表示されてしまう場合に便利です。 逆に見づらい場合には、もう一度 \x を実行すると元の表示に戻ります。 postgres=# SELECT * FROM test; id | hoge1 | hoge2 | hoge3 | hoge4 | hoge5 | hoge6 | hoge7 | hoge8 | hoge9 | hoge10 | hoge11 | hoge12 | hoge13 | hoge14 | hoge15 | hoge16 | hoge17 | hoge18 | hoge19 | hoge20 ----+------------+-------+-------+-------+-------+-------+-------+-------+-------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+-------- 1 | ABCDEFGHIJ | | | | | | | | | | | | | | | | | | | (1 行) postgres=# \x 拡張表示は on です。 postgres=# SELECT * FROM test; -[ RECORD 1 ]------ id | 6 hoge1 | ABCDEFGHIJ hoge2 | hoge3 | hoge4 | hoge5 | hoge6 | hoge7 | hoge8 | hoge9 | hoge10 | hoge11 | hoge12 | hoge13 | hoge14 | hoge15 | hoge16 | hoge17 | hoge18 | hoge19 | hoge20 | 実行結果をファイルに出力して確認したい： \o \o {ファイルパス} を psql 上で実行すると実行結果を指定したファイルに出力することができます。 ターミナル以外で実行結果を確認したい場合や保存したい場合に便利です。 SQL 実行後に \o を実行すると出力先を標準出力に戻すことができます。 postgres=# \o result.txt postgres=# SELECT * FROM test; postgres=# \o postgres=# SELECT * FROM test; id | hoge ----+------------ 8 | ABCDEFGHIJ (1 行) result.txt id | hoge ----+------------ 8 | ABCDEFGHIJ (1 行) DBを閲覧する DBの一覧を確認したい： \l \l を psql *1 上で実行するとDBの一覧を表示することができます。 または psql -l でターミナルを起動せずに表示することもできます。 postgres=# \l データベース一覧 名前 | 所有者 | エンコーディング | 照合順序 | Ctype(変換演算子) | アクセス権限 -----------------------------------+----------+------------------+----------+-------------------+----------------------- postgres | postgres | UTF8 | C | C | template0 | postgres | UTF8 | C | C | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | C | C | =c/postgres + | | | | | postgres=CTc/postgres (3 行) テーブルをコピーする 続いてはコピー作業のテクニック、まずはテーブル編の紹介です。 なお、これからご紹介する内容は、本番環境での利用は想定していません。 誤って重要なデータの書き替えが発生してしまう可能性もありますので、ご利用にはくれぐれもご注意ください。 テーブルの構造をコピーしたい： CREATE TABLE (LIKE) CREATE TABLE {コピー先} (LIKE {コピー元} ) *2 の SQL を実行するとコピー元と同じ構造のテーブルを作成することができます。 LIKEの中で INCLUDING ALL を指定すると構造だけでなく、制約やデフォルト値、付与されているインデックス等もコピーすることができます。 postgres=# CREATE TABLE test2 (LIKE test); CREATE TABLE postgres=# \d test2 テーブル "public.test2" 列 | 型 | 照合順序 | Null 値を許容 | デフォルト ------+---------+----------+---------------+------------ id | integer | | not null | hoge | text | | | postgres=# CREATE TABLE test3 (LIKE test INCLUDING ALL); CREATE TABLE postgres=# \d test3 テーブル "public.test3" 列 | 型 | 照合順序 | Null 値を許容 | デフォルト ------+---------+----------+---------------+------------ id | integer | | not null | hoge | text | | | 'a'::text インデックス: "test3_pkey" PRIMARY KEY, btree (id) "test3_hoge_idx" btree (hoge) テーブルのレコードをコピーしたい： INSERT INTO SELECT INSERT INTO {テーブル名} SELECT * FROM {テーブル名} の SQL を実行するとSELECTの結果をそのままコピーすることができます。 そのままコピーすると主キー制約に引っかかる場合には、 CREATE TABLE {コピー先} (LIKE {コピー元} ) を使ってtempテーブルを作成し、変更したいカラムのみをUPDATEしてからINSERTすると主キーのカラム以外を考えずにコピーすることができます。 postgres=# SELECT * FROM test2; id | hoge ----+------------ 10 | ABCDEFGHIJ (1 行) postgres=# INSERT INTO test2 SELECT * FROM test2; INSERT 0 1 postgres=# SELECT * FROM test2; id | hoge ----+------------ 10 | ABCDEFGHIJ 10 | ABCDEFGHIJ (2 行) postgres=# SELECT * FROM test; id | hoge ----+------------ 1 | ABCDEFGHIJ (1 行) postgres=# CREATE TEMPORARY TABLE temp_test (LIKE test); CREATE TABLE postgres=# INSERT INTO temp_test SELECT * FROM test WHERE id = 1; INSERT 0 1 postgres=# UPDATE temp_test SET id = 2; UPDATE 1 postgres=# INSERT INTO test SELECT * FROM temp_test; INSERT 0 1 postgres=# SELECT * FROM test; id | hoge ----+------------ 1 | ABCDEFGHIJ 2 | ABCDEFGHIJ (2 行) DBをコピーする テーブルの次はDB編のご紹介です。 こちらもテーブル編と同様、本番環境での利用は想定したものではありません。 環境へ重大な影響を及ぼす内容となりますため、ご注意の上での利用をお願いします。 DBをコピーしたい： createdb -T createdb -T {コピー元} {コピー先} *3 のコマンドを実行するとコピー元DBの内容でコピー先DBを作成することができます。 後述の pg_dump と比較すると実行速度が速い印象です。 >psql -U postgres -d postgres postgres=# \dt リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+-------+----------+---------- public | test | テーブル | postgres public | test2 | テーブル | postgres public | test3 | テーブル | postgres (3 行) >createdb -T postgres -U postgres postgres2 >psql -U postgres -d postgres2 postgres2=# \dt リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+-------+----------+---------- public | test | テーブル | postgres public | test2 | テーブル | postgres public | test3 | テーブル | postgres (3 行) DBをコピーしたい： pg_dump pg_dump {コピー元DB} > {dumpファイル} *4 のコマンドを利用するとデータベースをバックアップするdumpファイルを作成することができます。 作成したdumpファイルを psql {コピー先DB} < {dumpファイル} でリストアすることによってコピー先のDBにコピー元のDBをデータを再現することができます。 前述の createdb -T と比較すると、dumpファイルがあれば同じサーバにコピー元のDBがなくてもコピーできる点で汎用的です。 また、 -n や -t のオプションを指定すると一致する スキーマ やテーブル単位でコピーすることもできます。 > pg_dump -U postgres postgres > postgres_dump > ls -1 | grep postgres_dump postgres_dump > createdb -U postgres -T template0 postgres3 > psql -U postgres -d postgres3 < postgres_dump > psql -U postgres -d postgres3 postgres3=# \dt リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+-------+----------+---------- public | test | テーブル | postgres public | test2 | テーブル | postgres public | test3 | テーブル | postgres (3 行) 最後に PostgreSQL でのテーブル・DBの閲覧・コピーに関してご紹介してみましたが、いかがでしたでしょうか。 効率的な作業のお役に立てば幸いです。 関連記事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp tech-blog.rakus.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : https://www.postgresql.jp/document/9.3/html/app-psql.html *2 : https://www.postgresql.jp/document/9.3/html/sql-createtable.html *3 : https://www.postgresql.jp/document/9.2/html/app-createdb.html *4 : https://www.postgresql.jp/document/9.2/html/app-pgdump.html

はじめに こんにちは。Engawaです。 最近の業務でOAuthについて触れる機会がありました。 それまでの業務では担当経験はなく全く仕組みを理解できていなかったため、これを機に仕組みについてちょっと学習してみました！ 参考にした書籍は以下になります。 https://www.amazon.co.jp/dp/484437818X www.amazon.co.jp OAuthとは OAuthとは「 サードパーティ アプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可 フレームワーク 」です。 上記だけだと意味が分からないので、画像編集アプリを例にします。 画像編集アプリで Google Photo上の画像を編集する際、ログインアカウントには Google アカウントを使いたい場合を考えてみましょう。 　 サードパーティ アプリ→画像編集アプリ HTTPサービス→ Google Photo 限定的なアクセス：ユーザーが許されている操作は画像のダウンロードのみで、それ以外の操作をしようとした場合は、HTTPサービスはアクセスを拒否しなくてはならない 認可 フレームワーク ：アクセス トーク ン発効方法のルール（全てのアクセスに対して、許可していいアクセスかどうかをアクセス トーク ンを用いて判断する。） 上記の例を踏まえてOAuthの「 サードパーティ アプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可 フレームワーク 」を言い換えると 『画像編集アプリによる Google Photoへの限定的なアクセスを可能にするための「アクセス トーク ン発効方法のルール」』となります。 各役割の関係性 各役割 OAuthの基本的な役は大体以下の4つになります。 リソースオーナー リソースの所有者。 サードパーティ アプリにリソースへのアクセス権限を委譲しており、決められた権限の範囲内でリソースへのアクセスが可能になります。 クライアント 保護されたリソースにアクセスしようとするアプリケーション。 リソースサーバー データや機能を提供するサービス。一般的にはWebAPIの形で提供されている。 リソースサーバーはリソースオーナーが許可したアクセスを受け入れる必要があり、その手段がアクセス トーク ンとなります。 アクセスのたびにアクセス トーク ンの確認を行い、許可していいアクセスかどうかを判断する。 認可サーバー 認可サーバーの機能は以下の３つになります リソースオーナーを認証する(ログインの認証ではなく、リソースのオーナーであることを確かめるための認証) クライアントのリソースへのアクセスについてリソースオーナーの同意を得る アクセス トーク ンを発行する 上記例だと、リソースオーナーが Google アカウントにログインし、「画像編集アプリが Google Photoにアクセスすること」について同意すると、クラアントに対してアクセス トーク ンを発行します。 それぞれの関係 続いてそれぞれの関係についてざっくりまとめます。 ① 認可サーバに対して「リソースへのアクセス権」を要求する ② 認可サーバーは「クライアントへのアクセス権の委譲」についてリソースオーナーに確認を行う ③ リソースオーナーはアクセス権の委譲に対して同意をする ④ 認可サーバーはアクセス権が委譲された証であるアクセス トーク ンをクライアントに発行する ⑤ クライアントはアクセス トーク ンをもってリソースへのアクセスを実施する 終わりに 今回はOAuthについて、学習を行った内容を簡単に書かせていただきました。 まだまだ理解できないことがたくさんあるので引き続き学習を行なっていき、OAuthに関する記事の作成を行なっていければなぁと思います。

はじめに はじめまして。 ラク スの iketomo （いけとも） と申します。 弊社のオフショア開発拠点（ ラク ス ベトナム ）は2014年に新規で立ち上がり、今期で7年目に突入してます。 私は4年目～6年目までの3年間を拠点長として ベトナム 現地で務めさせていただき、今年6月に帰任させていただきました。 私自身 ベトナム では色々と楽しいことや、苦労したこともありました。 そこでの実体験・経験を踏まえたお話をさせていただきます。 ネット記事を漁ればオフショア開発に関する記事は散見されると思います。 そういった あるある記事 と、 ベトナム 現地での3年間の オレオレ経験 とを照らし合わせて紹介させていただきます。 そこからオフショア開発の現実・真実を感じ取ってもらえればと思います。 下記の5つの観点からご紹介させていただ、最後にまとめとして感想を少し述べさせていただきます。 はじめに (1). コスト (2). 技術・品質 (3). コミュニケ―ション (4). IT人材 (5). 離職・定着率 ベトナム現地での3年間のオレオレまとめ この記事では ベトナム （ ホーチミン ）での弊社での経験が主軸となっており、他の国の事とは事情が異なる点や、主観が混ざっている点もありますのでご了承ください。 いきなり話が脱線しますが ベトナム人 に「いけとも」と自己紹介しても「いけもと」って呼ぶ人が多かったです。 なぜかというと ベトナム では 味の素（ あじ のもと） が昔から根付いていて「いけもと」の方が呼びやすいのでしょう。に気づくのに3年かかりました。 では主軸の話へと移らさせていただきます。 (1). コスト ● あるある記事 一般的にオフショア開発では コストが安価 だとされています。 現在の ベトナム において、IT人材は初任給で言えば日本の 1/4 ～ 1/3 といったところでしょうか。 ただし成果を鑑みると、そのまま人件費がそのまま直結してコストが 1/4 ～ 1/3となりません。 ITにおいて、日本と同じ成果がでるわけではないので、上記の給与差がそのまま反映されることはないです。 ●オレオレ経験 弊社でも3年前は日本の 1/4 ～ 1/5 位の給与でした。 が、後述しますが、 ベトナム においてIT人材は売り手市場であり、年々給与アップしています。 現在では日本の 1/4 ～ 1/3 位まで上がりました。 ではコストはどうでしょう。 弊社では成果から計算した開発コストを日本と比べると、日本の 1/1.5 ～ 1/2 となっております。 現状において ベトナム のオフショア開発をやればコストメリットは出ると確実に言えます。 ただし、給与が上がっていくので、数年後にコストメリットがでるかどうかは、オフショア開発拠点の成果と品質によるところが大きなウエイトを占めると言えます。 給与の増加と共に、成果を大きくしないと、コストメリットはどんどん下がっていきます。 なので 給与アップに負けない成長や独自性 が必須だと言えるでしょう。 弊社においては ラク スの クラウド サービスの開発において、成長と独自性を追求する事としました。 半期、通期で ベトナム の成果や目指すべき方向（ ベトナム においての Saas 開発No1）、そして本社の業績を定期的に報告・共有しメンバーと会社の成長を感じてもらうようにしました。 最近ではコストメリットというところを脱し、 ラク スの クラウド サービス拡大していく中で純粋に絶対必要な開発チームという位置づけに変わりつつあります。 ※普段は陽気ですが仕事中は真剣 (2). 技術・品質 ● あるある記事 一般的には、日本よりオフショア開発拠点の技術・品質は低いと言われています。 ただし ベトナム の IT技術 者は他の東南 アジア諸国 より技術力が高い とされています。 ベトナム ではテストを苦手とするエンジニアもおり、案件によっては品質が高かったり、低くなる時もあります。 QC(テスター)を実装を行うメンバーとは別に アサイ ンすることもあります。 ●オレオレ経験 弊社のオフショア開発立ち上げの初期では、技術・品質が低いと感じることも多くありました。 が、年数を重ね ベトナム の 開発メンバーが成長することで、日本の技術・品質に近づいていくことができました。 最近では技術・品質が日本を上回っているケースも散見され、 一部のメンバーは日本メンバーよりもコード・仕様に詳しくなってきています。 ベトナム人 の IT技術 者のレベルが低いか？と聞かれれば、個人的にそうではないと考えています。 では何の差があるかと言うと 「日本と持っているスキルセットが違う」 「日本のベテランメンバーが近くに居てすぐに聞きアド バイス を貰うということができない」 という2点の差があります。 「日本と持っているスキルセットが違う」 日本人は品質の部分では優位性を持っています。 一方で ベトナム人 は新しい技術をすぐに吸収するといった特性があります。 それぞれに良いところがあり、どちらが優れているという優劣はないと感じています。 日本では新卒は研修を数か月した後に、ようやく開発に入ったりすることがありますが ベトナム では新卒が入社後に直ぐに開発に入って活躍することができます。 スキルセットは環境が整えば日本と同様のスキルセットを吸収します。若ければ若いほど吸収の速度が速いのは自明の理でしょう。 「日本のベテランメンバーが近くに居てすぐに聞きアド バイス を貰うということができない」 これは日本でも開発メンバーが離れていたり、コミュニケーションが上手くいかないと同様のことが発生すると思います。 聞ける人が近くにいて認識齟齬をなくして開発できる。これが良い開発環境における大きくウエイトを占める部分と考えています。 言葉・文化が違い、距離が離れている異国間ではこういった良い環境を保ちづらいデメリットがあります。 こういった日本との差は、日本側の開発メンバーとのコミュニケーションの風通しが良くしたり、オフショア開発拠点にベテランメンバー（該当会社での在籍が3年以上）が増えてくれば徐々に環境の差を縮めることができます。 また日本化することもできます。なぜなら ベトナム人 は向上心が強く、日本をリスペクトしており日本から学ぼうとする姿勢が強いからです。 日本→ ベトナム または ベトナム →日本へ出張することで日本風のやり方・文化を学んでもらうことも効果があります。 弊社では改善・ PDCA ・振り返りを繰り返し行うことで次第にメンバーは自発的に考えながら自己成長していく組織へと変貌していきました。 ※コードレビュー指摘の振り返り (3). コミュニケ―ション ● あるある記事 オフショア開発ではどういったコミュニケーションをするのでしょう。 コミュニケーションをするには以下の方法があります。 「コミュニケーター（通訳兼翻訳）を介す」 「 BSE (ブリッジSE)を介す」 「英語でやりとりする」 リソースとスキルによりいずれかの方法を選択することになります。 コミュニケーターでもＯＫですし。 社内の英語スキルが高ければ英語でやるのも良し。 優秀な BSE を採用できるのであれば BSE でも良し。 ベトナム は 親日 な人が多く日本語ができるコミュニケーター、 BSE が数多くいるといった特徴があります。 時に言葉・文化の違いからか時に認識齟齬が発生することもあり、思ったように指示が通らなかったり、思った成果がでないこともあります。 ●オレオレ経験 弊社では 「コミュニケーターを介す」 を選択しました。 設計書などのドキュメントは日本語←→ ベトナム語 に翻訳します。 単純な質問は英語で行っています。 難しい質問は、チャット上で翻訳してもらうか、 MTG を開いてコミュニケーターに通訳してもらいます。 で、結果がどうだったかと言われると、現在では幸いなことにコミュニケーションによる認識齟齬は殆ど発生していません。 がそこに至るまでは、色々な障壁があり対応してきました。 ●コーディングなどの専門的な難しい内容になると通訳の品質が落ちる。 これに対しては週１でIT勉強会をして、通訳を BSE に近い状態になってもらいました。 Webサーバとはなんぞや？というところからプログラミング演習まで行い、ＩＴ知識を自学できるとこまで成長してもらいました。 コミュニケーターは沢山いても、ITコミュニケーターは多くはいないという考えで自ら育てるという方針でいきました。 ●わからない時でも質問をせずに進め、後に認識齟齬が発生する。 これには2つの要因があります。 「なるべく早くすることを良しとする ベトナム 文化」 開発においては認識齟齬が一番駄目だ！ 報連相 が大事だ！ということを繰り返し伝え、質問文化を醸成しました。 もう1つは「日本との上下関係から委縮して質問できなくなってしまう」ことです。 日本メンバーが ベトナム人 を褒めたり、質問には即答してもらうことで、質問しやすい状況を作り、徐々に解決していきました。 ●大事な内容が伝わっていない。 重要な事と認識するポイントに文化間の差があり、日本が重要視することが見落とされていて、逆に重要視しないところに重きを置くことがあります。 私は難しい話をする時は、先にコミュニケーターにじっくりと説明して理解してもらい、実際の通訳の時に落ち着いて通訳してもらうようにしました。簡易でもいいので口頭だけではなくアウトプットがあるとさらに通訳の難易度が下がり理解度が上がります。 通訳はリアルタイムで難しい作業です。いきなり専門的な難しい話をして、口頭で話して、はいこれを通訳してくださいと言っても、なかなかできるものではありません。 まずは内容を理解するという時間でしっかり理解してもらい、それをベースに通訳してもらえば、私たちの意図を効率よく伝えてもらうことができます。 ※チームワークとコミュニケーションが大切 (4). IT人材 ●あるある記事 オフショア開発と言ってもいろいろな国があります。 ベトナム は他の東南アジアより優秀なIT人材が豊富に揃っていると言われています。 若く優秀な人材を安いコストで獲得することができるというのが通説です。 が、日系や欧米企業の参画が多く近年では 「需要 ＞ 供給」 で売り手市場となっており 年々給与ベースが上がってきています。 ●オレオレ経験 優秀なIT人材が他の東南アジアの国より多いというのは事実です。 また日本よりIT人材を獲得しやすいか問われればその通りです。 では自社が求めるIT人材を簡易に獲得できるかと言われれば、そんなことはないです。 上記しましたが「需要 ＞ 供給」 となっている中では各社で創意工夫が必要です。 ただし、 親日 の国であり、日本企業に入りたい！日本企業で学びたい！と思うIT人材も数多くいます。 そういった人材の中から自社に合った人材を獲得することになります。 スキルや性格にこだわりがなければ、簡易に獲得することができますが 弊社では求める部分も多く、色々な努力をしつつ、なんとか獲得できているといったところです。 「良い人材へのオファーは当日中に出す」「 Facebook で魅力アピール」「過去の面接者にも再度連絡」「 リファラル採用 のキャンペーン」等、できることはなんでもトライしました。 ※表彰することでモチベーションアップ (5). 離職・定着率 ●あるある記事 ベトナム においては 日本と比べてIT人材の 離職率 は高く、定着率は低い とされています。 ジョブ ホッピング も当たり前で、新卒は2年位で転職することが普通とされています。 せっかく育てたメンバーが、、、と各日本企業の頭を悩ませています。 離職が多くとも成り立つ組織。または離職しない組織を目指すことになります。 ●オレオレ経験 弊社でも例にもれず、2年、3年前は 離職率 が高かったですが、最近ではかなり低くなってきました。 離職率 が高くなると、会社としてのノウハウの蓄積ができず、組織としての成長は望めませません。 離職率 が高く、定着率が低いことは、どの会社でも大きな課題 です。 弊社では最初の3年間はスタートアップということもあり、それ程 離職率 は高くありませんでした。 その後、弊社での経験をベースに他社に転職することもあり、 離職率 が高くなりました。 そして現在 離職率 は低くなっています。 では、何が変わったのか？変えたのか？ 弊社では 「会社の独自性と居心地の良さ」というところを強め他社との差別化を図りました。 「自発的な組織」 言われたことをやるだけではなく自発的に動く。 トップダウン ではなく ボトムアップ の行動をより評価する。 「改善・ PDCA 」 の徹底。昔は拒否感が強かったですが、繰り返し実施することでチームとしての成長を感じてくれ、今ではこれが普通になり何も言わずとも振り返りＭＴＧを行ってくれます。 「とにかく楽しい」 を目指す。何が楽しいかを自分たちで議論させ、実行・主催してもらうようにしました。 「給与アップ」することである程度転職を防ぐことはできます、がそれは青天井で限界があります。 給与を求めるメンバーは給与アップしたとしても、さらに高い給与を目指して転職してしまいます。 そういったメンバーはいつか去る事になるので引き留めない方が良いでしょう。 ※コアバリューの浸透で社内文化の醸成 ベトナム 現地での3年間のオレオレまとめ 他文化・他言語ということもあり、いろいろ苦労した側面がありました。 が、いつでも ベトナム人 の優しさと明るさ が私を支えてくれました。 結果としては私が想像していた以上に、 ベトナム人 の向上心は強く、大きく成長してくれ 、今では思った以上の成果を出せる誇らしい組織と変貌することができました。 個人的には 安易にコストメリットだけを見てオフショア開発をやってみることはおススメできません。 コストメリットは何もしなければ風化していくからです。 彼らと一心同体となって成長することを決心してください。 その気持ちが伝わり、適切な仕組みやアド バイス をすれば必ず成長してコストメリットを超えた 期待以上の成長と成果を出してくれます。 会社独自の戦略で社員の定着率を高めてください。 離職率 を抑えることができたなら、あとは成長が待つのみです。 上記のご紹介した内容が皆様のオフショア開発を始めるきっかけや、課題や懸念の解決の糸口になれば幸いです。 長文になりました。最後まで読んでくださった方ありがとうございます！ ※誕生日はちょっとした社内パー ティー エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、itoken1013です。暑い毎日が続きますね！ 今回紹介するのは、実務でも個人開発でもオススメのHeroku（ヘロク）の基礎的な使い方になります。 Herokuを使うことで、開発したWEBアプリケーションを手軽に公開することができます。 この記事ではHerokuの概要を説明した後、簡単な公開（デプロイ）の手順を紹介することで、初心者でもHerokuを使った開発者に入門できる内容となっています。 今回の記事を参考に、ステイホーム中の スキルアップ を進めていただければ幸いです！ はじめに Herokuの概要 まず、PaaSとは それでは、Herokuとは 多様な言語・FWをサポートしている プランによっては無料で使える Gitコマンドで操作できる 拡張機能が非常に多い Herokuを使ってみる Herokuのアカウントを登録する Heroku CLIをインストールする Windows の場合 Mac の場合 Herokuにログインする デプロイを行う アプリケーションの取得 デプロイ実施 動作確認 おわりに Herokuの概要 まず、PaaSとは クラウド サービスは大きく SaaS 、PaaS、IaaSの3種類に大別されますが、Herokuはこのうち、PaaS（Platform as a Service）に分類されます。 PaaSとは、開発したWEBアプリケーションを開発・実行するための基盤（プラットフォーム）を提供するサービスを指します。 PaaSを利用することで、それまで必要だったサーバーの購入やOS、DB、WEBサーバなどの ミドルウェア 類のセットアップが不要となり、開発者はインターネット越しでPaaSを操作するだけで、手軽にWEBアプリケーションの ホスティング ができるようになりました。 また画面や コマンドライン 上でスケールアップ／アウトを手軽に行うことができ、この点もWEBアプリケーションの公開のハードルを下げた一因です。 このようにPaaSが普及したことで、開発者は本質的な開発作業に集中することが可能になりました。 それでは、Herokuとは 上記で説明しましたPaaSであるHerokuを使うことで、作成したアプリケーションを手軽に公開することが可能となります。 他のPaaSと比較した際のHerokuの特徴には、以下の点が挙げられます。 多様な言語・FWをサポートしている 元々は Ruby 向けのPaaSだったHerokuですが、現在では国内で扱われている主要言語とFW（以下）をほぼカバーしています。 この対応言語の広さが、PaaSの中でもHerokuが多く活用される一因でしょう。 Ruby （ Rails 含む） PHP Java Node.js Python Go Scala （Play含む） Clojure また公式サポートされている上記以外にも、buildpackと呼ばれる機能を利用することで、希望の言語・FWをHeroku上で利用することもできます。 jp.heroku.com プランによっては 無料 で使える Herokuが普及した最大の要因といっても過言ではないのが、利用プランです。 Herokuには数種類の利用プランがありますが、 Freeプランを利用の場合、無料でHerokuを利用することができます。 もちろん無料であるが故に制約は存在しますが、個人的な スキルアップ を目的とした利用にあたってはFreeプランで差し支えないはずです。 （少なくとも私がプライベートで個人利用している中では、一度もプラン変更は発生していません） 収入を目的にアプリケーションを公開する場合ではFreeプランでは耐えられないかと思いますが、あくまで スキルアップ のための利用であれば、Herokuを無料活用することが可能です。 ただし、今後プランの見直しが発生する可能性はありますので、ご利用の際は事前に以下の公式ページを参照いただければと思います。 jp.heroku.com Gitコマンドで操作できる Herokuではアプリケーションをデプロイする操作として、エンジニアならお馴染みのGitコマンドを利用します。 このため、Herokuへのデプロイ作業のために覚えることは最小限で済みます。 Herokuをリモー トリポジ トリとして git push するイメージですので、普段からエンジニアの手慣れた操作で手軽にアプリケーションを公開することができます。 なお、後続の手順ではGitを使った操作が必要となります。 Gitを未インストールの方、Gitコマンドの利用経験が浅い方は、まずはこちらを参照いただければと思います。 tech-blog.rakus.co.jp 拡張機能 が非常に多い 今回は紹介しませんが、Herokuには数多くの 拡張機能 （アドオン）が存在おり、自前で実装せずに便利な機能を利用することができます。 中には無料のプランを提供している機能もあり、代表的な 拡張機能 を以下に紹介しておきます。 興味のある方は、ぜひご自身の開発で活用してみてください。 SendGrid：メール配信 PaperTrail：ログ管理 New Relic APM ：監視 Herokuを使ってみる Herokuのアカウントを登録する それではここから、Herokuを利用するための操作を簡単に紹介していきます。 まずはHerokuのアカウントを取得しましょう。 以下の画面より必要事項を入力の上、「無料アカウント作成」をクリックしてください。 signup.heroku.com 上記で入力したメールアドレスに認証メールが届きますので、メール内のリンクをクリックしてアカウントを有効化します。 最後にパスワード設定を求められますので、任意のパスワードを設定してください。 ここまで完了し、以下の画面が表示されればアカウント登録の作業は完了です。 Heroku CLI をインストールする 次にHerokuを コマンドライン 上から操作するためのツールをインストールします。 後続のデプロイ作業には、こちらのツールが必要となります。 以下のページにアクセスし、ご利用のOSに応じた手順でインストールを行っていきます。 devcenter.heroku.com Windows の場合 Windows 用の インストーラ が提供されていますので、ダウンロードの上、 インストーラ を起動してください。 今回は全てデフォルトの状態で進んでいただき、「Install」ボタンをクリックいただければ問題ありません。 Mac の場合 Mac では インストーラ を用いず、上記ページにあるコマンドをターミナル上で入力してください。 ※パッケージマネージャである Homebrew がインストール済である必要があります。 brew tap heroku/brew && brew install heroku ここまで完了しましたら、 CLI を起動してみましょう。 Windows であれば コマンドプロンプト やGit Bash 、 Mac であればターミナルを起動し、以下のコマンドを入力してください。 無事にバージョン情報が表示されれば、 CLI のインストールは完了です。 $ heroku --version heroku/7.42.6 win32-x64 node-v12.16.2 Herokuにログインする 先ほど作成したアカウントを使い、 CLI 上でHerokuにログインします。 heroku login -i を入力すると コマンドライン 上でログインを求められますので、アカウント作成時のメールアドレスとパスワードを入力してください。 ※ iオプション を付けない場合、ブラウザ上にHerokuのログイン画面が立ち上がりますが、同様にログイン認証を進めれば問題ありません。 $ heroku login -i heroku: Enter your login credentials Email: メールアドレス Password: パスワード Logged in as メールアドレス デプロイを行う ここからは、実際にHeroku上にアプリケーションをデプロイしてみましょう。 GitHub 上のサンプルプログラムを使い、デプロイの手順を紹介していきます。 簡単なデプロイのイメージを示します。 アプリケーションの取得 まずは任意の場所に ディレクト リを用意しましょう。 今回は「rakus」という ディレクト リ配下で作業を進めていきます。 $ mkdir rakus rakus ディレクト リへ移動後、次にデプロイ用のアプリケーションを GitHub より取得します。 git clone を使い、任意の リポジトリ （今回はHerokuのサンプルアプリケーションを使います）からクローンを行います。 ※実際の開発ではここが開発対象の リポジトリ となり、ローカル リポジトリ を最新化しておく必要があります。 $ git clone 'https://github.com/heroku/java-getting-started.git' Cloning into 'java-getting-started'... ・ ・ ・ Resolving deltas: 100% (179/179), done. デプロイ実施 Heroku上にデプロイを行うためのアプリケーション作成を実施します。 まずはクローンしたアプリケーション配下へ移動します。 $ cd java-getting-started/ 次に heroku create コマンドを入力すると、デプロイ用のアプリケーションが作成されます。 この際、 コマンドライン 上に表示されるURLを控えておいてください。 また、以下に示す XXXX-ZZZZ-123456 （例）が作成したアプリケーション名を表しています。 ※アプリケーション名は heroku create コマンドの引数で指定可能です。 指定がない場合、「XXXX-ZZZZ-123456」のようなランダムな名称が割り振られます。 $ heroku create Creating app... done, XXXX-ZZZZ-123456 https://XXXX-ZZZZ-123456.herokuapp.com/ | https://git.heroku.com/XXXX-ZZZZ-123456.git 最後に git push heroku master を入力すると、Heroku上へのデプロイが行われます。 $ git push heroku master Enumerating objects: 400, done. Counting objects: 100% (400/400), done. Delta compression using up to 4 threads. Compressing objects: 100% (190/190), done. Writing objects: 100% (400/400), 178.59 KiB | 25.51 MiB/s, done. Total 400 (delta 152), reused 400 (delta 152) remote: Compressing source files... done. ・ ・ ・ remote: https://XXXX-ZZZZ-123456.herokuapp.com/ deployed to Heroku remote: remote: Verifying deploy... done. To https://git.heroku.com/XXXX-ZZZZ-123456.git * [new branch] master -> master これでデプロイ作業は完了です。 動作確認 ここまででデプロイ作業は完了ですが、最後にデプロイしたアプリケーションを確認してみましょう。 上記の デプロイ実施 で表示されたURL（上記であれば https://XXXX-ZZZZ-123456.herokuapp.com/ ）をブラウザに入力してください。 以下のような画面が表示されれば、正常にデプロイが完了しています。 無事に画面が表示されましたか？ 今回の作業は以上で完了となります。 お疲れ様でした！ おわりに 今回はHerokuを使ったアプリケーションの公開手順を紹介してきましたが、いかがでしたでしょうか？ 思っていたよりも簡単な手順だと感じた方が多いのではないでしょうか？ 実際の開発でHerokuを応用的に活用していくためには、Heroku固有の概念（DynoやHeroku Flowなど）への理解がまだまだ必要です。 ですが、最低限のプラットフォームとしての機能と利便性は、この記事を使って理解いただけたはずです。 今回の内容を足がかりにしていただき、今後の開発にお役立ていただけると幸いです。 ではでは、またの機会に。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 技術広報のitoken1013です。こんにちは。 いつも ラク スのイベントにご参加いただいている方々、本当にありがとうございます！ 今回は8月1回目のMeetup 『レガシーを吹き飛ばすPHPer実践テクニック』 について、コンテンツを紹介させていただきます！ イベントテーマ概要 今回は 『レガシーを吹き飛ばす』 という強力なイベントタイトルを掲げさせていただき、 リリースから10年以上 の以下サービスに携わるエンジニア3名が登壇させていただきました。 これらのサービスは多くのお客様に長くご利用いただき、現在でも新たな機能追加を進めています。 その一方で長い開発で蓄積しているレガシーな面とも向き合う必要性が高まっており、開発速度と品質を落とさないための取り組みが求められています。 今回はそんな取り組みの中でも、より実践的なテクニックを紹介させていただきました。 楽楽販売 メールディーラー 配配メール ちなみにご参加の方へ利用言語をお聞きしたところ、（当然ではございますが…）大半が PHP 使いの方でした。 また、登壇者と同じように レガシーシステム の開発に携わっている方もいらっしゃり、今回のイベントで得たテクニックを早速活用したいと言っていただける場面もありました。 ラク スでは PHP 中心のイベントを頻繁に開催しておりますので、今後もイベントにご参加いただけますと嬉しいです！ 発表の紹介 それでは3名のエンジニアによる発表を簡単に紹介させていただきます！ 「指摘の 見える化 」SonarQubeを使って、新規不良コードをデビューさせない仕組みづくり 楽楽販売の開発に携わる凪から、静的コード解析ツール 「SonarQube」 を使ったコードレビューの改善についての発表となります。 主にレビューを中心に担当する凪ですが、日に日に増大するレビュー負荷という課題を踏まえ、静的コード解析ツールの導入を決定しました。 数あるツールからSonarQubeを選択した背景、実際に運用を開始してからの効果について詳細に語られています。 サービスの急拡大に伴ってレビューが追い付かない！、という悩みをお抱えの方には是非ご参考にしていただきたい内容です。 speakerdeck.com PHP 標準関数との闘い PHP のバージョンアップ（7.1 から 7.3）に伴う count()関数 の仕様変更にまつわる、 ラク ス最古参のサービスであるメールディーラー（2001年4月リリース）でのエピソードを加納より紹介させていただきました。 リリースよりおよそ20年、メールディーラーではありとあらゆる場所でcount()関数を呼び出しており（呼び出し数は、ぜひ資料をご覧ください…）、あるべき論だけでは語れない戦いが繰り広げられることとなりました。 さらには開発体制に起因する新たな問題も生まれてしまい…という苦労を抱えたエピソードになっております。 言語や フレームワーク の仕様変更は、ソフトフェア開発では避けては通れない戦いです。 今回は歴史を抱えたサービスを支えるための戦いではありますが、ご紹介のノウハウはどの開発でも活用できるはずです。 ぜひ多くのエンジニアに役立てていただければと思います。 speakerdeck.com 13年続くレガシーサービスを安全にリリースし続けるための、E2Eテストと カバレッジ ツールを利用したテスト戦略について リリースから13年が経過した配配メールにおける、吉元が取り組むテスト戦略をお話させていただきました。 名著のレガシーコード改善ガイドでは『自動テストが無いコードはレガシーコードである』と触れられていますが、吉元の携わる配配メールではまさに自動テスト環境が存在せず、高い品質を保ったリリースに課題を抱えていました。 www.amazon.co.jp 「プロダクトコードの複雑性」や「計画の不確実性」といった課題を抱えていた開発チームですが、これらに向き合った「重要機能テストの自動化」や「 テスト駆動開発 」などの戦略が語られています。 詳細で実践的な内容であるため、ご自身の開発現場でも活用できそうと感じていただけるはずです。 speakerdeck.com おわりに レガシーに向き合う ラク スエンジニアの取り組み、いかがだったでしょうか。 簡単な課題は1つも存在しませんが、多くのお客様にご利用いただける期待に応えるため、日々レガシーを吹き飛ばすテクニックに取り組んでいます。 さて、次回のMeetup（8/25開催予定）は 『新サービス』 がテーマです！ すでに100人以上の方に申し込みいただけており、大イベントになりそうな予感がしています。 rakus.connpass.com また PHP に関するイベントも8月中に2回開催予定です。 こちらもたくさんのご参加をお待ちしています！ rakus.connpass.com rakus.connpass.com

はじめに 技術広報のitoken1013です。こんにちは。 6月に多くの方にご参加いただきました ラク スMeetup、7/29(水)にも 『 SaaS 開発リーダーが実践する開発速度向上プ ラク ティス/海外拠点、 スクラム 、時間管理』 をタイトルにオンライン開催させていただきました。 今回も当日の発表を簡単に紹介させていただきます！ イベントテーマ概要 ラク スでは『企業で働く人々の生産性を向上し、より豊かな社会の実現』を掲げて、多様な SaaS をお客様に展開しています。 そのために ラク スのエンジニア自身も日々、開発速度や生産性向上に向けたプ ラク ティスに取り組んでいます。 今回は多くのお客様にご支持をいただいています 楽楽精算 と 楽楽明細 の開発に携わるエンジニア3名が登壇し、それぞれが挑戦中の取り組みをご紹介させていただきました。 個人・チーム・オフショアの3つの視点からのプ ラク ティスが紹介され、多様なポジションの参加者の方からコメントをお寄せいただけました。 発表の紹介 25 + 5分で開発速度を上げる時間管理術！ ポモドーロテクニック の紹介 まず楽楽精算で開発・運用とマルチな役割を担う平山から、作業時間を管理するための ポモドーロテクニック を紹介させていただきました。 開発に限らず生産性向上のテクニックとして広く知られる ポモドーロテクニック ですが、今回は平山の具体的な課題のエピソードと実践後の効果が語られることで、日々のお仕事で取り入れてみたいと感じていただけたのではないでしょうか。 若手・中堅・ベテランのどのエンジニアにもお勧めしたいテクニックです。 www.slideshare.net スクラム 開発ドキュメンタリー ～なぜなぜ、落ちる スクラム 開発速度～ 次は楽楽明細で スクラム 開発を実践中の柴田より、開発デモで起きてしまった、とある苦いエピソードを紹介させていただきました。 開発サイドとビジネスサイド（もしくはユーザー）で生まれる認識のズレややり直しは、どの企業様に所属するエンジニアの方でもご経験のあるトラブルかと思います。 柴田が所属する楽楽明細チームではこれらのトラブルに対し、 スクラム の枠組みに捕らわれずに柔軟に開発スタイルを変更することで改善を図っていきました。 いまだ試行錯誤を続けながらの取り組み、今後の成果に期待です。 speakerdeck.com Quality First & Fastを実現するオフショア開発のポイント9選 今回のラストは、楽楽明細の開発リーダーを務める樋口です。 ラク スの子会社である ベトナム の『RAKUS Vietnam Co., Ltd.』のエンジニア陣をマネジメントする樋口ですが、開発速度と品質の両立のために駆使するテクニックを具体的に紹介させていただきました。 『日本が特殊な国だということを理解する』『日本の設計観点を伝える』など、複数国の方との仕事経験が豊富な樋口ならではの発表でした。 またオフショアをテーマにした内容ではありますが、日本人のエンジニア同士でも参考にしていただけるプ ラク ティスを見つけていただけるはずです。 speakerdeck.com おわりに 今回は特定の技術スタックに偏ったイベントテーマではなかったこともあり、さまざまなレイヤーの方にご参加いただけました。 プロジェクトマネジメントに課題を抱える方、個人のスケジュール管理がうまくいかない方などの参考にしていただけますと幸いです。 ラク スでは8月以降もMeetupやLT・勉強会の開催を予定しています。 すでに多くの方にお申し込みいただき、ありがとうございます！ 今後も ラク スエンジニアからの情報発信をどうぞお楽しみに！！ rakus.connpass.com rakus.connpass.com

技術広報の syoeshin です。 当社では最近、下記２つの定期的な読書会を企画し、スタートしました。 社内の有志達がリードして、それぞれが好きな本を読み/紹介しあう読書会 社内の 有識者 達がリードして、選定した技術書の理解を深める読書会 定期的な読書会を組織の取組みとして始めた目的は "個と組織の成長" です。 成長のプロセスは 知識を得る (勉強会で話を聞く、本を読む、ニュース/記事を読む など) 訓練する (繰り返し修練、習慣にする など) 実践する に分解できます。 定期的な読書会の機会をつくり、参加してもらう事で 成長の源泉となる 知識を得る 　 × 　 訓練する のサイクルは定着させる事ができます。 もちろん 実践する はとても重要ですが 私たちの開発組織は 支援の厚い実践シーンの連続 ですので 知識を得る 　 × 　 訓練する サイクルが定着すれば 個の成長が加速する事は、言うまでもありません。 さて まずは 知識を得る 　 × 　 訓練する のサイクル定着を目的として始めた読書会は 早速、以下のようなうれしい副次効果も見られ始めました。 組織内コミュニケーションの ダイバーシティ 化 要約/意見をまとめる/人前で話すスキルの向上とリーダーシップの育成 組織内での専門性/ アイデンティティ の確立 ーー組織内コミュニケーションの ダイバーシティ 化 私たちの開発拠点は 東京・大阪・ ベトナム と分かれており これまで社内イベントは拠点を中心とした開催が主で 業務外のコミュニケーションも拠点が中心となっておりました。 密を避けるべき状況下で、読書会はオンライン開催となったため これまでの様に拠点別の開催ではなく 東京、大阪、 ベトナム から社員が一斉参加できる読書会は 拠点を問わず、若手・中堅・ベテランを問わず 業務外コミュニケーションも交わせる機会の一つとなりました。 ーー要約/意見をまとめる/人前で話すスキルの向上とリーダーシップの育成 読書会にはさまざまな形式がありますが、当社が実施している 社内の有志達がリードして、それぞれが好きな本を読み/紹介しあう読書会 の参加目的は「それぞれの自由でよし」としています。 こちら読書会の参加者には 会の冒頭で 「今日はどこまで読む」と読書宣言をしてもらい 1~1.5ｈの読書後 に 読んだ本/部分を要約し、参加メンバーに伝えてもらうようにしております。 また、参加者から ファシリテーター (簡単な司会進行)を選出し 会の進行をしてもらいます。 ・読書宣言 ・読んだ本/部分の要約を発表 ・読書会の司会進行 をしてもらう事で　 知識を得るためだけの読書会ではなく ・人前で話す ・意見をまとめる ・人の意見を聞きながら結論を導く場を作る というト レーニン グになり、スキルを磨くことができる仕組みで 参加者は 心理的 負担が小さい中で リーダーシップに必要な要素が身に付けられるようになってます。 ーー組織内での専門性/ アイデンティティ の確立 社内では ・ アーキテクチャ に詳しい 人 ・ アジャイル 開発や スクラム に詳しい 人 ・フロントエンドに詳しい 人 等々 おりますが そういったメンバーは”特定分野の知識と経験が豊富”と社内で認識されており 特に知識面では、その分野に関わるたくさんの本を何度も深く読んでいる事が多いです。 社内の 有識者 達がリードして、選定した技術書の理解を深める読書会 では 特定分野や技術テーマに沿って読書会が開催されており 読書会を主催するメンバー達は、 ”特定分野に詳しい人” と社内で認識され 自身の専門性と アイデンティティ を確立しています。 また 当社では有志達が始めた社内勉強会から発展した 「 TechCafe※ 」という 社外向け勉強会コミュニ ティー を運営しており 社外向けに特定分野/技術のベントを主催する事で 社内だけでなく社外にも自身の専門性と アイデンティティ の確立を進めています。 ※TechCafe詳細「TechCafeができるまで」 tech-blog.rakus.co.jp ーーまとめ 読書会の開催/参加メリットは世間でさまざまに言われてますが 社内で読書会を開催してみて 世間で言われているどのメリットも得られる というのが現時点での所感です。 まだまだ開催の実績は少ないですが 中核メンバーや管理職、開発組織以外メンバーの参加が増えていけば ・組織コミュニケーションの ダイバーシティ 化 ・組織メンバーのリーダーシップ育成 ・組織メンバーの専門性/ アイデンティティ の確立 の進化ができ ”個と組織の成長”を加速できる と考えているため 今後もより多くのメンバーが参加しやすく 何より楽しめる「読書会」を企画していこうと考えております。 当社運営の勉強会コミュニ ティー は以下サイトからご参加ください。 rakus.connpass.com また、私たちは一緒に働くメンバーを募集しています。 ご興味を持たれましたら以下のサイトからお問い合わせください。 career-recruit.rakus.co.jp

はじめに はじめまして。 ラク スのインフラエンジニアのcappy_potterと申します。 弊社で提供している クラウド サービスを担うサーバに（ クラスタ ）ついて、どの程度のアクセスまでであれば 問題なくサービス提供できるのか、という限界値を知るための 負荷試験 を過去に実施しました。 Webシステムを構成するサーバ群に対し、どのようにして負荷をかけ、限界値を探るのか、いろいろ方法は あると思いますが、実際に弊社で試したやり方をご紹介しますので、参考にしていただければと思います。 はじめに サーバ構成 負荷試験環境準備 負荷試験パターンの検討とJMeter用シナリオの作成 JMeterで負荷をかける ボトルネックの調査 おわりに サーバ構成 今回負荷をかけるサーバの構成は下図のようになっています。 対象のシステムは複数のサーバからなっていますが、外部からのアクセスは全てロードバランサで受けて、 配下のサーバに通信を振り分ける形となっています。 負荷試験 環境準備 ● 本番システムと同じ構成（台数、スペック）の 負荷試験 用サーバを用意する。 今回、負荷限界値を正確に測るため、本番環境と全く同じハード構成・台数の試験用サーバを用意しました。 リソースが足りず難しい場合は、各サーバのスペックを同じ割合で落としたものを用意して試験を行うことで とりあえず「 ボトルネック はどこか」を探ることはできると思います。 ● Apache JMeter サーバの用意 試験用サーバに対して負荷をかけるためのサーバとして、 Apache JMeter サーバを用意しました。 このとき、同時に大量のアクセスをかけられるようにするため、上図のようにマスタサーバ以外に 4台のスレーブサーバを用意しました。 　※ JMeter サーバ側が貧弱だと、負荷限界に達する前に JMeter サーバ側の方が先に限界に達する 可能性が 　　ありますので、そうならないように考慮しました。 ● 各サーバのパフォーマンスデータ収集準備 負荷試験 対象の各サーバにはZabbixエージェントをインストールし、パフォーマンスデータを取得できるようにしました。 弊社では、もともとサーバの監視用としてZabbixを利用していますので、これを用いて、各サーバのCPU使用率、 ロードアベレージ 、Disk I/O、swap使用量、ネットワーク帯域のデータを収集するようにしました。 　→ 負荷をかけたときに、どのサーバの何のリソースが ボトルネック になっているかを確かめるため。 なお、データの取得間隔は30秒にしました。間隔を短くした方がブレが少ないデータとなりますが、短くしすぎると データ取得自体も負荷になる可能性があるためです。 負荷試験 パターンの検討と JMeter 用シナリオの作成 今回、 負荷試験 を行うことにより、大きく分けると以下の2パターンの限界値を求めたいと考えました。 　① Webサーバ1台あたり、秒間何アクセスまで耐えられるのか 　② システム全体として秒間何アクセスまで耐えられるのか ただ、ひと口に「秒間何アクセスまで耐えられるのか」といっても、アクセスするページやユーザの操作内容によって 変わってきますので、基準を設けなければなりません。 基本的には最もアクセスが多いページや、標準的なユーザの操作内容がわかっているのであれば、それを基準にすればよい と思いますが、定まらない場合はいくつかのパターンについて試験を行い、その結果をもとに判断するしかありません。 弊社では、①の試験を行うために9パターンのシナリオを作成しました。また、①の試験はWebサーバ1台だけに対して アクセスが流れるようにするため、 ロードバランサー での振り分け先を1台のWebサーバのみとなるように設定を変更して試験を行いました。 （②の試験のときは、3台のWebサーバに対して均等にアクセスが振り分けられるようにしました。） JMeter で負荷をかける 作成した JMeter のシナリオを使って負荷をかけますが、秒間のアクセス数限界値を探るのが目的ですので、 以下のような流れで負荷をかけていきました。 （各シナリオで同じように試験を行い、それぞれのシナリオでの限界値を探りました。） 　 １）対象のサーバに対して、まずは「おおよそこれぐらいではないか」と思う秒間のアクセス数を5分間かける。 　　　→例えば、秒間20アクセスを5分間かける場合、 JMeter の設定は以下のようになります。 　　【Ramp-Up期間：】負荷をかける時間 ＝ 300(秒) 　　【スレッド数：】Ramp-Up期間(秒) × 秒間アクセス数 ÷ 負荷をかける JMeter サーバの台数 ＝ 300×20÷4 ＝ 1500 　 ２）5分間負荷をかけた結果、 JMeter でエラーを検知しているようであれば、秒間のアクセス数を減らし、 　　　 再度負荷をかける。エラーを検知していなければ秒間のアクセス数を増やして再度負荷をかける。 JMeter でエラーを検知しているかどうかは、実行結果の画面で「Status」の部分をクリックして、 ステータス別に並び替えすることにより判断できます。 （下図のように赤い「×」マークがあれば、エラーが発生しているということになります。） 　 ３）上記２）で秒間のアクセス数を増減させながら何度かテストを行い、最終的に「これ以上秒間のアクセス数を 　　　 増やすとエラーが出る」という値が判明すれば、それが限界値となる。 ボトルネック の調査 限界となる負荷をかけられているときのZabbixデータを確認し、どのサーバの何が ボトルネック になっているか 確認します。 下図は、負荷をかけている間の各サーバのパフォーマンスデータを記録した資料の抜粋ですが、これを見ると Webサーバの CPU使用率が100% に達していることがわかります。 そのため、この場合は、「WebサーバのCPUを増設する」「Webサーバの台数を増やす」などすれば、システム全体としての 限界値は延びることが予想されます。 おわりに 本記事では、 負荷試験 によってサーバの限界値を求めるための方法に絞って記載していますが、実際は試験を実施する前に 負荷試験 を行う目的、求められた 負荷試験 結果をもとに今後どう運用していくのか 、ということを明らかにしてから 実施しないと、何度も 負荷試験 を実施しなければならなくなる可能性があるため、これらをしっかり認識したうえで 実行するようにして下さい。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、 ラク スひぐちです。 07/21(火) に開催された「 Developers Summit 2020 Summer」に参加しました。 https://event.shoeisha.jp/devsumi/20200721#outline 今回はオンライン開催ということで参加された方も多かったのでないでしょうか。 参加した4つのセッションの中で特に気になったセッションについて感想を書いていこうと思います。 エンジニアリングが組織に広がる「乳化」を目指すための取り組み READYFOR株式会社 VPoE伊藤 博志(通称：いとひろ)さんが登壇してらっしゃいました。 開発プロセス 枠ですね。 スライドは下記になります。 speakerdeck.com READYFORさんが掲げる「乳化」とは、 * 組織の中にエンジニアリングが自然に溶け込んでいる状態 * 既存の価値観とテク ノロ ジー が融合することによる イノベーション の創造を目指す 組織間の隔たりなく、ミッションのために協力し合える状態かなと解釈しました。 確かに同じ会社といえど、仕事の取り組み方や文化を合わせていくのって大変ですもんね。 そんな文化の中、注目すべきなのはこれです。 BPMN B usiness P rocess M odeling and N otation 訳すと「ビジネスプロセス モデリング 化と記法」で国際標準規格(ISO/IEC19510)にも指定されている概念です。 「さまざまなビジネスチームがBPMNを活用してフローを可視化してくれるようになった」 これが目からウロコの取り組みでした。 ビジネスチーム、要は営業や製品企画、サポートなどの事業部ですね。 ビジネスチームと開発間で認識合わせをするんですが、これが結構ふわっとしがちです。 開発から業務シナリオなどを図示するときにDraw.ioなんかを使ってビジネスチームに見せることは結構やります。 しかしビジネスチームがBPMNツールを使ってフローを可視化してくれる、この価値がかなり高いです。 ビジネスチームから言葉で要求の説明を受ける、開発が企画に ヒアリ ングする 上記の結果から開発が要件を文書や図に起こす 認識齟齬があるところを削る、変更する だいたい2～3を繰り返し行います。 ビジネスチームが思い描いている図示をさっとできる状況が上記の工程を短縮することにつながりますね。 もちろんはじめは開発やデザインチームのフォローが入るので、 より簡単で使いやすいツールを選ぶのが重要になってきます。 設計を図示するツールはいくつかありますが、READYFORさんが利用しているツールはこちら。 「 Camunda Modeler 」 いとひろさんが使い方をレクチャーしてくれています。 http://itohiro73.hatenablog.com/entry/2018/01/15/082158 さっそくやってみました。 すごい簡単です。 Camundaで図示 UIが直観的で触りやすいこと 無駄なツールがないこと あるとかえって使いづらくなります 図示して、というと急に足が重くなってしまいそうですが、 これならツールを利用する精神的なハードルも低く取り組めると思います。 さっそくビジネスチームにレクチャーしながら進めていきたいですね。 もう一つの取り組み、Slackの Reacji Channeler も魅力的でした。 絵文字を押すだけで特定のチャンネルに飛べるんですって。 slack.com 残念ながら弊社はSlackではないので導入ハードルが高そうですが、Slackご利用の方はぜひ使ってみてください。 こうしたいくつかの取り組みがあって、組織の乳化が進めば、開発に着手するまでの上流工程をスムーズになると思います。 READYFORさんの取り組み、必見です。 他のセッションも個性的で魅力的でした。素晴らしかったです。 自分で気づかない観点を取り入れる勉強会ってやっぱり大事ですね。 次回もぜひ参加したいです。

こんにちは。west-cです。 携わっている新規サービスにて ドメイン 駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン 駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ ドメイン ）を中心に据えて開発を行うソフトウェア開発手法のこと DDDを実践することで、 ドメイン 知識がそのままコードへ反映されるようになる ドメイン 知識とコードが地続きになることによって、 変化に強いソフトウェアを構築できる 「変化に強い（保守性の高い）ソフトウェア」と聞いて興味を持った方は、これからご紹介する書籍を読んでみてはいかがでしょうか。 おすすめ書籍 初学者がDDDを学ぶ場合はこの順番で読むのがよいのではと思った順番に紹介します。 なお、学習前の私の状況は以下のとおりです。 Java でのプログラミング経験あり（サンプルコードの読解には苦労しない） オブジェクト指向 的なプログラミングは苦手 DDDはまったく知らない 現場で役立つシステム設計の原則 〜変更を楽で安全にする オブジェクト指向 の実践技法 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田 亨 技術評論社 Amazon 業務アプリケーションの保守性を高めるための設計手法について説明されている書籍です。 DDD学習の前段階におすすめです。 「 リファクタリング 」の内容にも通じるコードの見通しの良さの話から オブジェクト指向設計 による モデリング 方法まで、業務アプリケーションにおけるコードをわかりやすくするための手法が説明されています。 タイトルだけを見るとDDDとは関係無いようにも見えますが、本文中には「業務的な関心事を ドメイン モデルとして表現する」考え方やDDDで見られる実装パターンが導入されていたりと、DDDのエッセンスが要所に詰まっています。 この書籍を読んだ当初の私は オブジェクト指向 的なプログラミングに慣れていなかったため、手続き型の設計からの発想の切り替えに役立ちました。 「DDDおよび オブジェクト指向設計 を取り入れたら保守性の高いコードになりそう」と思うきっかけにもなり、学習のモチベーションにも繋がりました。 ドメイン 駆動設計 モデリング /実装ガイド little-hands.booth.pm DDDの モデリング から実装までの一連の流れが紹介されている書籍です。 全100ページほどでDDDの全体像がコンパクトにまとまっています。 初学者が「DDDとは」を理解するには、まずはこの書籍を一読するとよいのではと思います。 著者の方の YouTube チャンネルに書籍の解説動画が投稿されていますので、まずはこちらを観てみるのもアリかと思います。 動画後半の質問回答コーナーでは視聴者の方からの疑問が多く寄せられており、こちらもためになります。 little_hand_s DDD Channel - YouTube ちなみに、弊社では現在こちらの書籍の読書会を行っています。 DDD初心者から実際にDDDに取り組んでいる・取り組もうとしているサービスのメンバーまで、幅広い層が参加する会となっています。 書籍を読む中で湧き上がる素朴な疑問に対して「うちのサービスではこのような方針にしている」といったリアルな実情を聞くこともでき、活発に意見交換が行われています。 ドメイン 駆動設計入門 ボトムアップ でわかる! ドメイン 駆動設計の基本 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 作者: 成瀬 允宣 翔泳社 Amazon DDDにおける実装パターン（戦術的設計と呼ばれています）を中心に紹介されている書籍です。 戦術的設計の各パターンについて詳しい解説と実装指針が示されています。 戦術的設計の理解のために一読するのはもちろん、実装時にリファレンス的な用途で眺めても参考になります。 私がDDDを実践しはじめた頃はまだ刊行されていなかったため、この書籍の前身である「 ボトムアップドメイン駆動設計 」によくお世話になりました。 DDDに慣れない当初はどのように実装するのが適切なのか迷うことが多々ありましたが、サイトに記載されている詳細な説明が判断材料となり助けられることも多かったです。 ボトムアップドメイン駆動設計 │ nrslib ボトムアップドメイン駆動設計 後編 │ nrslib Domain Driven Design（ ドメイン 駆動設計） Quickly 日本語版 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 後ほど紹介する「エリック・ エヴァ ンスの ドメイン 駆動設計」、通称「 エヴァ ンス本」をコンパクトに要約した書籍です。 重厚な エヴァ ンス本の要点を掴むことができます。 この書籍では、これまで紹介してきた書籍ではあまり詳細には触れられてきていなかった「境界づけられたコンテキスト」などの戦略的設計に関する解説も含まれています。 これから紹介する2冊は戦略的設計に関する話も登場し難易度が高くなるため、この書籍を先に読むとこの後の理解がスムーズに進むのではと思います。 実践 ドメイン 駆動設計 実践ドメイン駆動設計 (Object Oriented SELECTION) 作者: ヴォーン・ヴァーノン 翔泳社 Amazon エヴァ ンス本の内容をコードを交えて具体的に説明している書籍です。 DDDを取り入れた架空のプロジェクトを題材としており、「実際のプロジェクトではどのように実現するのだろう？」と思う部分が実装例つきで解説されています。 サンプルプロジェクトは複数アプリケーション（＝境界づけられたコンテキスト）に分割されており、これまで紹介した書籍でのサンプルプロジェクトの中でも大規模なものとなっています。 「 ドメイン イベント」など、DDDにおけるコンテキスト内外との情報連携の手段に関して詳細に述べられており、まさにDDDを実践する際の具体例が詰まっています。 エヴァ ンス本の説明は抽象的なため、先にこちらを読んでおくと エヴァ ンス本で言っていることのイメージが付きやすい印象です。 ただ、どちらの書籍も難しいため理解を定着させるためにはそれぞれ読み返す必要があると思います。 なお、この書籍の章ごとの要約が「 IDDD本から理解するドメイン駆動設計 」として連載されており、章を読んだ後の分かったようで分かっていない脳内を整理するのに役立ちました。「 「実践ドメイン駆動設計」から学ぶDDDの実装入門 」として書籍化もされているようですので、近いうちにこちらを片手に再読したいと思っています。 「実践ドメイン駆動設計」から学ぶDDDの実装入門 作者: 青木 淳夫 翔泳社 Amazon エリック・ エヴァ ンスの ドメイン 駆動設計 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス 翔泳社 Amazon ドメイン 駆動設計の原典とも呼ばれる書籍です。 原典ですが（原典がゆえに？）書いてある内容が難しく、私はひととおり読了こそしましたが理解できた感覚はありませんでした……。 対象となる ドメイン をどのように モデリング し深いモデルへ到達させてゆくかや戦略的設計について詳細に述べられている書籍は少ないため、その点は一読してみる価値はあると思います。 本文中で例として挙げられているアプリケーションは、筆者が実際に携わった業務アプリケーションが基になっているため、例示される ドメイン 知識にリアリティがある点もこの書籍ならではだと思います。 リアリティのある複雑な ドメイン を対象にしているがゆえに理解が難しい点も無きにしもあらずなのですが、対象分野が違うだけで業務アプリケーションにおける ドメイン 知識は元来複雑なもののはずですので、この内容が理解できればDDDに対する汎用的な知識が身についたということなのかなと個人的に思っています。 なお、前述の「 ドメイン 駆動設計 モデリング /実装ガイド」の読書会の前は、こちらの書籍の読書会が弊社内で開催されていました。 私はこの読書会ではじめて エヴァ ンス本に触れたのですが、「わからない」を参加者の間で共有でき、各々の解釈を語り合うことでモチベーションの維持に大いに繋がりました（一人で読んでいたら挫折していたと思います）。 「 エヴァ ンス本は難しい」という前評判に腰が引けてなかなか手を出せずにいる方（過去の私です）は、身近な方を誘って一緒に読みはじめてみるのもアリだと思います。 おわりに ドメイン 駆動設計と聞くと名前だけで内容がイメージできず難しい印象を受けますが、ここ最近は入門者向けの書籍やスライド、ネット上の記事なども多く見かけるようになり学習のハードルは下がったのではと思います。 かくいう私はDDD歴1年未満の新参者であり”完全に理解した”の域にもまだ到達できていないとは思うのですが、「 ドメイン 知識をそのままコードに落とし込むことでコードの見通しが良くなる」「他の人が書いたコードもどこに何が書いてあるのか理解しやすい」などの恩恵は現時点でも感じています。 まだ戦略的設計に関する知見は浅いと感じていますので、今後も周辺知識の習得含め学習を続けていきます。 みなさんもぜひこの機会にDDDを学んでみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは。「ChatDealer」の開発に携わっているy_kwmtです。 Excel ファイルをプログラムで楽に書き出す方法を調べていたら PHP のライブラリを用いて Excel ファイルを書き出す方法を見つけました。 はじめに PhpSpreadsheetとは PhpSpreadsheetのインストール コーディング PHPファイル実行 最後に 参考にしたサイト PhpSpreadsheetとは PhpSpreadsheetは、 Excel などの様々な スプレッドシート ファイル形式を読み書きできるライブラリです。 今回はその PHP のライブラリ「PhpSpreadsheet」について紹介します。 PhpSpreadsheetのインストール Composer を使用してプロジェクトに「PhpSpreadsheet」をインストールします。 PHP バージョンは 7.2 以降が必須となります。 composer require phpoffice/phpspreadsheet コーディング Excel ファイル作成プログラム「index. php 」を作成します。 下記のコードで簡単な点数表を作成します。 <?php require 'vendor/autoload.php' ; use PhpOffice\PhpSpreadsheet\Spreadsheet; use PhpOffice\PhpSpreadsheet\Writer\Xlsx; // スプレッドシート作成 $ spreadsheet = new Spreadsheet () ; $ sheet = $ spreadsheet -> getActiveSheet () ; // 値とセルを指定 $ sheet -> setCellValue ( 'B1' , '英語' ) ; $ sheet -> setCellValue ( 'C1' , '数学' ) ; $ sheet -> setCellValue ( 'A2' , 'Aさん' ) ; $ sheet -> setCellValue ( 'A3' , 'Bさん' ) ; $ sheet -> setCellValue ( 'B2' , '90' ) ; $ sheet -> setCellValue ( 'B3' , '80' ) ; $ sheet -> setCellValue ( 'C2' , '70' ) ; $ sheet -> setCellValue ( 'C3' , '95' ) ; // Excelファイル書き出し $ writer = new Xlsx ( $ spreadsheet ) ; $ writer -> save ( 'score.xlsx' ) ; PHP ファイル実行 php コマンドで先程作成した「index. php 」を実行します。 php index.php Excel ファイル「score.xlsx」が作成されます。 最後に 今回は「PhpSpreadsheet」を用いて簡単な点数表を作成しました。 この記事が PHP ユーザーの参考になれば幸いです。 今後、作成したコードの改良を行い、複雑な Excel ファイルをコマンド一発で作成できるようにしたいと思います。 参考にしたサイト phpspreadsheet.readthedocs.io blitzgate.co.jp blitzgate.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、YSです。 2020年7月9日にシューマイ　コミュニティにて開催された Laravel の勉強会に参加してきました。 shuuu-mai.connpass.com 普段のプロダクト開発でも関わっている Laravel。 この機会に社外のいろいろな知見にも触れてみたいと思ったのが、参加のきっかけです。 以下、簡単ですがイベント内容と感想をレポートします。 発表内容 Laravel x Herokuによる開発・運用 Laravelのコンテナ運用のベストプラクティスを考えてみた 循環的複雑度80超えの現行システムに Laravel × オニオンアーキテクチャ で立ち向かった話 Laravelで小規模業務システムを作る時の要点 感想 Laravel の導入しやすさ Laravel の豊富な機能例 おわりに 　 発表内容 CTOやリードエンジニアとしてご活躍されている方々が 業務で実際に運用・開発されている Laravel について語って下さいました。 Laravel x Herokuによる開発・運用 株式会社タンバリン CTO　狩野 裕介さん speakerdeck.com Heroku を使用したサービスの設定/運用について語って下さいました。 スケールアウトが設定画面でスライダーを動かすだけで行えたり Git merge で自動デプロイされ、ボタンを押すだけ本番リリースが行える等 Heroku では、とても簡単にサービスの設定・運用が行えるようです。 自動デプロイからの Laravel の Migration の連携はまだ実施できていないとのこと。 工夫が必要な箇所もありそうです。 　 Laravelのコンテナ運用のベストプ ラク ティスを考えてみた 株式会社ROXX CTO　松本 宏太さん slides.com Amazon ECS を使用したコンテナ運用について語って下さいました。 コンテナの使い分けや、ロギングの設定等について 実際の設定値やポイントなどが書かれており、ぜひ参考にしたい情報ばかりでした。 　 循環的複雑度80超えの現行システムに Laravel × オニオン アーキテクチャ で立ち向かった話 株式会社うるる　栗原 史明さん speakerdeck.com オニオン アーキテクチャ を採用するために Laravel を導入された話についての発表でした。 オニオン アーキテクチャ 推進のため最適な フレームワーク として、なぜ Laravel を選んだのか、 実際に導入してみてどうだったのかなど、詳細な事例が興味深かったです。 　 Laravelで小規模業務システムを作る時の要点 株式会社プ ラムザ エンジニア リングマ ネージャ　荒瀧 悠さん speakerdeck.com 長く Laravel での開発に携わってきた荒瀧さんによる発表です。 小規模システムの定義と、Laravel の機能が用途ごとにわかりやすく説明されており、とても参考になる内容でした。 　 感想 今回のイベントでは大きく分けて「運用向け」「開発向け」の2種類のLTがあり、 私には、日ごろ携わっているプロダクト開発に関係する「開発向け」の発表が刺さりました。 私が興味を持った「開発向け」LT は2つあります。 Laravel の導入しやすさ 1つ目は、オニオン アーキテクチャ を採用するために Laravel を導入した話です。 Laravel を採用した観点は、「自由度の高さ」「DI サポート」「 トラブルシューティング がしやすい」という3点、とのことでした。 「自由度の高さ」「 トラブルシューティング がしやすい」という2点は、 私が開発に携わっている製品『チャットディーラー』で、Laravel を採用した条件と類似しており、親近感がわきました。 特に観点「 トラブルシューティング がしやすい」の中で説明されていた 「利用者の多さ」という点は、 フレームワーク の寿命にも関わるため フレームワーク 選定時の重要な要素だと感じています。 また、 ビジネスロジック の分離についても解説されていました。 『チャットディーラー』の開発でも ビジネスロジック の分離を意識したレイヤー設計を取り入れていますが、 より本格的に進められている印象が伝わってきました。 Laravel の豊富な機能例 2つ目は、Laravel での開発に長く携わってきた方ならではの詳細な機能説明でした。 これから Laravel で開発する方向けの発表とのことでしたが すでに見知った機能以外にも、使用したことのない機能の説明もありました。 今後の開発で活かせそうな機能も含まれており、「Laravel って便利だな」と改めて思った次第です。 今回紹介のあった機能以外も含めて、 一度、Laravel の公式リファレンスにあたって、全機能を確認しておく必要がありそうです。 　 おわりに 実は Zoom でのオンライン勉強会参加は人生初の経験でした。 話している方の「間」も普段の勉強会とはまた違った「間」があり、とても新鮮でした。 今回の参加した勉強会は、普段は東京で開催されているそうです。 大阪在住の私としては、参加が難しい勉強会に参加することができたのも、オンライン開催ならでは良い経験でした。 　 最後に宣伝となりますが、 株式会社ラクス でも PHP をはじめとした各種勉強会を開催しています。 オンライン中心となりますので、参加もしやすいと思います。よろしければぜひご参加ください。 詳しくはこちらをご覧ください。 https://rakus.connpass.com/ rakus.connpass.com

こんにちは、エンジニアの id:eichisanden です。 CentOS6からCentOS7にバージョンアップした時に謎の性能劣化に苦しめられたことがありました。 今更CentOS7という感じもありますが、恐らくCentOS8にも通じる話なのと、 CentOS6のサポートが2020/11/30に切れるのでバージョンアップする方もいると思い記事にしてみました。 同じ条件で性能を比較してみる 特定の処理が顕著に性能劣化した そもそもOS単体の性能はどうなのか ターボ・ブーストが有効になっているかの確認 ターボ・ブーストは有効だった CPUガバナーをperformanceに変更してみる tunedの設定を変更する CPUの脆弱性パッチの存在に気づく 試しに脆弱性パッチを無効にしてみる さいごに 同じ条件で性能を比較してみる まず、ほぼ同じスペックの物理サーバを2台用意して、同じアプリ、同じデータ、同じ処理を流して性能比較を行いました。 特定の処理が顕著に性能劣化した ある バッチ処理 はCentOS6では148秒で終わっていたのにCentOS7では168秒もかかる結果になりました。 ちょっと取得タイミングがずれちゃってますがvmstatをグラフ化して見てみます。 CentOS7 CentOS6 やけにCPUのsys（ Linux カーネル が使っているCPU使用率）の赤が目立つのと若干 コンテキストスイッチ が多いことが目についたのでCPU周りを疑うことにしました。 そもそもOS単体の性能はどうなのか OS単体の性能はどうなのかということでUnixBenchを取得しました。 結果をみると、 Dhrystone 2 using register variables という整数演算以外はCentOS6の圧勝という結果に。 測定したアプリに違いはないため環境自体の問題と疑っていましたので予想通りの結果になりました。 と言うことで、続けてOSの設定にミスがないかを見ていきます。 ターボ・ブーストが有効になっているかの確認 ターボ・ブースト というのは負荷がかかっているコアに対して定格の動作周波数よりも高い周波数で動かす インテル のCPUの仕組みです。 検証に使用したのはターボ・ブーストに対応した Xeon ですが、これが無効になっていないのでは？と疑ってみました。 ターボ・ブーストは有効だった cpupowerコマンド見ると、 boost state support が Active: yes になっているので有効になっているようです。 # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 800 MHz - 3.50 GHz available cpufreq governors: performance powersave current policy: frequency should be within 800 MHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 1.20 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes 同時に、このCPUの周波数は3GHzですが、800MHzから3.5GHzの範囲で動くこと、 このコマンドを叩いた瞬間は1.2GHzの周波数で動いていたことがコマンドの結果から分かります。 低い周波数で動作しているのはCPUガバナーが powersave になっていることが原因なようです。 powersave は最 低周波 数に固定して動作するという記事もあったのですが、 UnixBench中の負荷が掛かった状態で見てみると負荷が掛かれば最大周波数で動作するようでした。 # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 800 MHz - 3.50 GHz available cpufreq governors: performance powersave current policy: frequency should be within 800 MHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 3.50 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes 検証に使用したサーバーのCPUは performance と powersave しかサポートしていませんが、 powersave は ondemand を選んだ時のように必要に応じて周波数を上げるような動きをすることが分かりました。 CPUガバナーをperformanceに変更してみる 負荷が掛かれば周波数が最大まで上がるので意味がなさそうと思いつつ performance に変更してみます # cpupower frequency-set --governor performance Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 Setting cpu: 3 再度性能測定したところ、168秒掛かっていたのが、159秒にまで一気に早くなりました！！ powersaveでも最終的にはブーストが効くのでここまで差が出るとは思っておらず意外な結果でした。 ただ、まだ思った性能が出ていないので検証を続けます。 tunedの設定を変更する CPUガバナーだけを設定してもよいのですが、CentOS7から導入されたtunedという各種パラメータを便利に設定できる仕組があるのでそれを使用して設定します。 検証に使用したサーバーは balanced がデフォルトで設定されていたので、 throughput-performance に変更しました。 # デフォルトの設定 # tuned-adm recommend balanced # 現在の設定を確認 # tuned-adm active Current active profile: balanced # throughput-performanceに変更 # tuned-adm profile throughput-performance CPUガバナーがperformanceになる以外にもいくつかのパラメータがパフォーマンス寄りの設定になりますが、どんな設定になるかは設定ファイルで確認できます。 # cat /lib/tuned/throughput-performance/tuned.conf |grep -e "^[^#]" [main] summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads [cpu] governor=performance energy_perf_bias=performance min_perf_pct=100 [disk] readahead=>4096 [sysctl] kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000 vm.dirty_ratio = 40 vm.dirty_background_ratio = 10 vm.swappiness=10 CPUの 脆弱性 パッチの存在に気づく まだCentOS6の性能に及ばないので色々調べていると、2018年はじめに問題になったSpectreとMeltdown対策のパッチで性能劣化するという記事を見つけました。 IntelがSpectreとMeltdown修正による0〜21パーセントのパフォーマンス低下を公表 この観点で見ていくとCentOS6の検証に使ったサーバの カーネル はアップデートされておらず、 対してCentOS7は 脆弱性 パッチがしっかり当たっているので、 それが速度の違いの要因だといういうことが見えてきました。 試しに 脆弱性 パッチを無効にしてみる 本番環境の 脆弱性 のパッチを無効にするつもりはありませんが、 Meltdownのパッチを無効にすることが設定ファイルの書き換えだけで出来たので試しにやってみました。 # cat /sys/kernel/debug/x86/pti_enabled 1 # cat /sys/kernel/debug/x86/retp_enabled 1 # cat /sys/kernel/debug/x86/ibrs_enabled 0 # echo 0 > /sys/kernel/debug/x86/pti_enabled # echo 0 > /sys/kernel/debug/x86/retp_enabled 無効にして ベンチマーク を取ると僅かですが性能向上していました。 CentOS7の方は他にいくつもCPU関連の 脆弱性 パッチが当たっており、 全てのパッチを無効にしての検証が出来ないため想像になりますが、性能劣化の原因はこのあたりという結論に自分の中では落ち着きました。 ここから先はチューニングで補う方向に方針を切り替え、調査としては一旦完了としました。 さいごに 大きな構成変更をした時には前後の性能比較をすることが非常に大事だと改めて感じました。 性能測定する環境の条件は極力揃えるというのも教訓になりました。 原因が分かれば対策のしようがあるので、しつこく調べた甲斐がありました。 以上になります。最後まで読んでいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、takaramです。 最近業務で PHPUnit を使ったテストを書く機会が増えてきました。初めは assertEquals しか知らなかったわけですが、最近は適切な アサーション メソッドを選択できるようになってきました。そこで今回は数ある PHPUnit の アサーション メソッドの中から、一般的によく使いそうなものを独断と偏見で選んでご紹介します！ なお、以下の内容は執筆時点の最新版の PHPUnit (v9.2.6) に基づいています。 PHPUnitのアサーションメソッド assertEquals assertSame assertTrue, assertFalse, assertNull assertCount assertStringStartsWith, assertStringEndsWith, assertStringContainsString assertRegExp assertIsXXX, assertInstanceOf 最後に PHPUnit の アサーション メソッド assertEquals ある値が期待した値と等しいかどうかを判定します。 PHPUnit の初心者向け資料にもよく出てくるおなじみのメソッドですが、 基本的にはほぼ使いません 。というのも、これは 暗黙の型変換が行われる からです *1 。たとえば、以下の アサーション は全て成功します。 $this- > assertEquals(1, '1'); $this- > assertEquals(null, ''); $this- > assertEquals(null, false); $this- > assertEquals(null, 0); $this- > assertEquals('1', true); テストにおいては、こうした型変換は嬉しい場面よりも困る場面のほうが多いのではないでしょうか。引数の内容によっては型変換が起こらないケースもありますが、特に理由がない限りは使わないと思っていいでしょう。 assertSame では assertEquals の代わりに何を使うかというと、この assertSame です。型も含めた比較が行われます。 PHPUnit 初心者なら、とりあえずこれさえ知っていれば何とかなります。 $this- > assertSame('hoge', 'hoge'); // OK $this- > assertSame(0, 0); // OK $this- > assertSame(false, false); // OK $this- > assertSame('hoge', 'fuga'); // NG $this- > assertSame(0, false); // NG $this- > assertSame(7, '7'); // NG assertTrue, assertFalse, assertNull それぞれ true , false , null と等しいことを判定します。型変換は行われません。つまり、以下の2つはほぼ同等です。 $this- > assertTrue($actualValue); $this- > assertSame(true, $actualValue); どちらでもテストの成功・失敗は変わりませんが、失敗時のメッセージが assertTrue などの方が多少分かりやすくなります。 # assertSame(true, false) のメッセージ Failed asserting that false is identical to true. # assertTrue(false) のメッセージ Failed asserting that false is true. assertCount 配列や countable なオブジェクトの要 素数 を検査します。 assertSame の引数に count() の結果を渡すことでも同じテストはできますが、これもやはり失敗時メッセージが assertCount の方が分かりやすくなっています。 # assertSame(1, count([])) のメッセージ Failed asserting that 0 is identical to 1. # assertCount(1, []) のメッセージ Failed asserting that actual size 0 matches expected size 1. assertStringStartsWith, assertStringEndsWith, assertStringContainsString 文字列の内容を部分一致で検査する アサーション です。同じことを assertSame でやろうと思うと strpos() や substr() を使うことになりますが、これらの アサーション メソッドを利用したほうがテストコード上も意図がわかりやすくなりますね。 // 以下2つは同じ内容のテスト $this- > assertStringStartsWith('foo', $string); $this- > assertSame(0, strpos($string, 'foo')); // 何をテストしたいのかすぐ理解しにくい // 以下2つは同じ内容のテスト $this- > assertStringEndsWith('bar', $string); $this- > assertSame('bar', substr($string, -3)); // これも理解しにくい assertRegExp 文字列が 正規表現 にマッチするか検査します。上記の assertStringContainsString などよりも条件が複雑な場合に使えます。 assertIsXXX, assertInstanceOf 値が配列かどうかを検査するために、 assertTrue(is_array($value)) とする代わりに assertIsArray($value) と書くことができます。 is_array 以外にも is_int , is_numeric , is_string , is_bool , is_callable , is_object など、 is_xxx の関数に対応する アサーション メソッドは一通り用意されています。 また、オブジェクトの型を検査したい場合は assertInstanceOf(SomeClass::class, $value) が使えます。 最後に 今回紹介した アサーション メソッドはごく一部です。 アサーションメソッドの一覧 がマニュアルにあるので、どんなメソッドが用意されているのか、ぜひ一度見てみてください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : PHP の== 演算子 に似ていますが、以下の記事で解説されているように、厳密には異なります。 https://qiita.com/aminevsky/items/238b7ed77766a3d3023d

はじめに 初めまして、ntthuatと申します。 ラク スに入社して3年目になりました。時間が過ぎるのは早いですね。 さて、2020年12月末に Flash のサポートが終了するという話は皆さんもご存知かと思います。 今回、私が開発担当している「楽楽精算」で、 Flash の代わりに WebUSB という技術を用いて、 ICカード 履歴を取り込む機能をリリースすることになりました。 この記事ではその WebUSB について試したことを一部ご紹介させていただきます。 はじめに 動作確認環境 WebUSBとは PaSoRi RC-S380/Sのドライバーをインストールする WebUSBの動作確認 おわりに 動作確認環境 以下の環境で WebUSB の動作を確認します。 Windows 10 Google Chrome 83 PaSoRi RC-S380/S WebUSB とは 簡単に言うと、 WebUSB は javascript で書かれている API です。 WebUSB はPCに接続されたUSBデ バイス に Chromium 系ブラウザ（ Chrome など）から直接アクセスすることができる技術です。 USBデ バイス の認識、読み出しなどを行うことができます。 Edgeは Chromium ベースで開発していますのでEdgeでも WebUSB が使用できます。 Chrome のDeveloper Toolsで WebUSB の API を実行してみましょう。 await navigator.usb.requestDevice( { 'filters' : []} ) ドライバーをインストールせずにブラウザ自体のみでUSBデ バイス を認識できます。 今回は PaSoRi RC-S380/S経由で WebUSB の動作を確認しますので PaSoRi RC-S380/Sのドライバーのドライバーが必要です。 PaSoRi RC-S380/Sのドライバーをインストールする ソニー株式会社 | FeliCa | 法人のお客様 | 製品情報 |ソフトウェア開発環境 |ICS-DCWE9 SDK for NFC Web Client | 個人情報取得同意説明 で評価版をダウンロードできます。 Sony サイトでのマニュアルのとおり実行します。 コマンドプロンプト 等で、 NFC ポートソフトウェアを以下のオプションを指定してインストールしてください。 NFCPortWithDriver.exe /WinUSB　 注意点： NFCPortWithDriver.exeをダブルクリックすると、WinUSBを含めないドライバーをインストールしてしまいますので、WinUSBに付けて実行してください。 ドライバーインストールが完了したら、 NFC ポート自己診断(ドライバ切り換え)でWinUSBドライバーに切り換えができます。 WinUSBに切り替えしてください。 WebUSB の動作確認 PaSoRi RC-S380/S経由で ICカード を取り込みを確認しましょう。 ソニー のサポートサイトで提供されているサンプルプログラムを実行してみます。 サンプルプログラムの ソースコード につきましては、詳しくは Sony サイトでご覧ください。 PaSoRi RC-S380/SをPCに繋げてExecuteボタンをクリックすると、デ バイス を選択するダイアログが出て、RC-S380/Sを認識して ICカード 履歴を読み取りできます。 実行結果は以下のようです。 レスポンスのデータはhexのフォーマットですが、分析して日付や距離、金額などを取得できます。 おわりに Flash のドアーが閉まると WebUSB のドアーが開かれますね。(^_^) WebUSB でブラウザからUSBデ バイス を読取りできて素晴らしかったです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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