2022/03/22 に Java 18が公式にリリース されたので今回は新しく追加された機能からいくつかをピックアップして紹介していこうかと思います。 また、本記事ではJava18のインストール方法についても書いていきます。 Javaとは Java 18のインストール方法 Java 18の機能紹介 400: UTF-8 by Default 408: Simple Web Server 最後に 参考文献 Java とは Java は1995年にリリースされた歴史の長い プログラミング言語 で、現在までで 18 ものバージョンがリリースされています。 新機能のリリースサイクルは半年に1回で3月と9月に発表されます。 毎回のリリースで様々な新機能が発表されています、例えば Java17: Sealed Classes extends, implements できるクラスの制限 Java15: Text Blocks Java コード内のでテキストブロックの導入 Java14: Switch Expressions switch構文を改良 などなど色々あります。 適当にピックアップしましたが、他にも色々とリリースしています。 気になる方は 公式サイト を見てみてください。(目次の Projects に各バージョンのリリース情報が載ってます。) リリースごとに進化を遂げて来た Java ですが、今回のリリースでも色々と面白い機能が追加されています。 この後それらの紹介をしていきますが、まずはローカルでJava18を使えるようにするためのインストール方法について説明したいと思います！ なお、今回は windows10 を用いて環境構築を行います。 Java 18のインストール方法 インストールの流れは以下です。 Java18のダウンロードページで インストーラ をダウンロード インストーラ を起動して環境設定とインストール まずダウンロードページに移動します。 https://www.oracle.com/java/technologies/downloads/ 今回は windows にJava18をインストールするので、Java18タブ > Windows タブ > x64 Installerをダウンロードします。 java ダウンロードページ 次に インストーラ を起動します。 以下のようなインストールウィザードが表示されるので「次へ」を押下します。 インストールウィザード Java のインストール先を聞かれます。 インストール先を変更したい場合は「変更...」でフォルダを指定した後「次へ」を押下します。 インストール先を選択 以下の画面が出たらインストール完了です。 インストール完了 Java コマンドを使えるようにするためには 環境変数 の設定が必要になります。 インストールの初期設定では、 Java コマンドが格納されているbinフォルダへの シンボリックリンク のPathが自動で 環境変数 に設定されています。 もし シンボリックリンク ではなく、 jdk のbinフォルダに直接指定したい場合は他記事にて詳しい内容が紹介されていますので、別途お調べになっていただけますと幸いです。 インストール方法についてのご紹介は以上になります。 Java 18の機能紹介 以下が今回追加された機能の一覧です。 400: ★ UTF-8 by Default 408: ★ Simple Web Server 413: Code Snippets in Java API Documentation 416: Reimplement Core Reflection with Method Handles 417: Vector API (Third Incubator) 418: Internet-Address Resolution SPI 419: Foreign Function & Memory API (Second Incubator) 420: Pattern Matching for switch (Second Preview ) 421: Deprecate Finalization for Removal openJDK JDK18: https://openjdk.java.net/projects/jdk/18/ 今回はこの中から★の機能をピックアップして紹介していきます。 400: UTF-8 by Default Summary Specify UTF-8 as the default charset of the standard Java APIs. With this change, APIs that depend upon the default charset will behave consistently across all implementations, operating systems, locales, and configurations. 上記の通り、 Java の標準 API のデフォルトの 文字コード が UTF-8 に統一されます。 これによってデフォルトの 文字コード に依存する標準 API が全て実行環境で一貫した動作をするようになります。(引数として 文字コード を指定した場合は従来通りの動きをします。) 「デフォルトの 文字コード 」 というのはアプリケーション実行環境(OSとかユーザー設定とか)に依存していて、これが統一されることでOSが変わると文字化けが発生するみたいな悩みが解消されることになります。 例えば、今までだとOS間で以下のような文字化けが発生していました。 java.io.FileWriter を用いて 文字コード を指定せず書き込みを行った場合 // (macOS)で書き込み FileWriter writer = new java.io.FileWriter( "hello.txt" ); writer.write( "こんにちは" ); writer.close(); java.io.FileReader(“hello.txt”) -> “こんにちは” (macOS) // windowsで文字化け発生 java.io.FileReader(“hello.txt”) -> “縺ォ縺。縺ッ” (Windows (ja-JP)) こういった問題が今回の修正によって減ることになります。 ちなみに、以下のコマンドで現在のデフォルトの 文字コード を調べることができます。 気になる方はぜひコマンドを叩いてみて下さい。 $ java -XshowSettings:properties -version 2>&1 | grep file.encoding 以下にJava8 と Java18 での表示の違いを載せておきます。 Java 8 windows だと以下のように表示されます。 file.encoding = MS932 となっている箇所が 文字コード です。 MS932なので UTF-8 で書き込まれた文字はしっかり文字化けします。 $ java -XshowSettings:properties -version 2>&1 | grep file.encoding file.encoding = MS932 file.encoding.pkg = sun.io Java 18 ちゃんと UTF-8 になっていますね！ $ java -XshowSettings:properties -version 2>&1 | grep file.encoding file.encoding = UTF-8 ただ JDK 18以前との互換性は気になるところで、アプリケーションに与える影響は大きそうです。 公式サイトにも以下のように記載されています。 一応困ったらすぐに、前のバージョンと同じ状態に戻すことは可能になるそうです。 We recognize that this change could have a widespread compatibility impact on programs that migrate to JDK 18. For this reason, it will always be possible to recover the pre-JDK 18 behavior, where the default charset is environment-dependent. 408: Simple Web Server Summary Provide a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts. コマンドを叩くだけで簡易的なwebサーバを立てられるようになりました。 簡易的なサーバなので出来ることとしては、静的ファイル(htmlファイル、画像ファイルとか)をレスポンスとして返すことくらいになります。 HTTPメソッドもGETとHEADのみを受け付ける仕様になっています。 なので、この機能の目的としてはプロトタイプの作成であったり、簡単なテスト、教育用といったものが上げられています。 では使い方を見ていきましょう。 まず、静的ファイルとして簡単なhtmlファイルを用意したいと思います。 index.html <!DOCTYPE html> < html lang = "ja" > < head > < meta charset = "UTF-8" > < title > Java 18 インストールと新機能紹介【最新版】 </ title > </ head > < body > < h1 > Hello Java 18! </ h1 > </ body > </ html > こちら作成後ローカルの /c/java18-test/index.html にファイルを配置します。 次に、webサーバーを立ち上げていきます。 まず、インストールした jdk のフォルダに移動します。 インストール時に指定したフォルダの中にbinフォルダがあるのでそこに入ります。 # binに移動 $ cd /c/Program Files/Java/jdk-18/bin binフォルダの中に jwebserver.exe という実行ファイルがあるので、起動することでサーバーを立ち上げることができます。 以下のようにコマンドを叩きます。 なお、今回 -d オプションによってhtmlファイルを配置した ディレクト リを指定しています。 # サーバー立ち上げ $ ./jwebserver -d /c/java18-test Binding to loopback by default. For all interfaces use "-b 0.0.0.0" or "-b ::". Serving C:\Program Files\Java\jdk-18\bin and subdirectories on 127.0.0.1 port 8000 URL http://127.0.0.1:8000/ http://127.0.0.1:8000/ にブラウザからアクセスすると以下のように表示され、先ほど配置したindex.htmlが表示されているのが分かります。 こんな感じで簡単にwebサーバーを立ち上げられました。 jwebserver 最後に 今回は Java のインストール方法と最新機能を紹介しました。 これからも半年毎にリリースが入りますので、引き続き注目していきたいと思います。 参考文献 openjdk jdk18: https://openjdk.java.net/projects/jdk/18/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の yayawowo です。 突然ですが、 システム開発 を行う中で お客様からの要求/要件漏れが発生し、スケジュール遅延が発生した経験はございますか？ （私は過去、苦労した経験があります…。） システム開発 を着実に成功させるためには、お客様の要求/要件をしっかりと引き出した上で分かりやすく成果物としてまとめることが大切です。 その大事な工程となるのが 要件定義 です。 本記事では、要件定義の概要・進め方だけでなく、重要ワード/ポイント、求められるスキルについてご紹介します。 要件定義とは？ 要件定義の進め方 1. ユーザー要求をヒアリング 2. 要求の深堀 3. 要件定義書の作成 重要ワードとポイント 業務要件 システム要件 機能要件 非機能要件 求められる4つのスキル コミュニケーションスキル 資料作成スキル 分析スキル スケジュール管理スキル おすすめ書籍をご紹介！ 要件定義 まとめ ◆ 関連ブログも合わせてご参考ください。 ・ 「はじめよう！ 要件定義 ～ビギナーからベテランまで」から学ぶ要件定義の始め方 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ ・ PMBOK とは【まとめ】 ・ プロジェクトマネジメント とは 【まとめ】 ・ PdM （プロダクトマネージャー）とは 【まとめ】 ・ 仕様書 とは 【まとめ】 要件定義とは？ 要件定義は、お客様（以下、ユーザー）からの要望をシステムでどのように実現し、どのように進めるかをまとめる工程です。 システム開発 は、お客様の要望を実現することが重要です。 システムの開発を開始させるためには、要件定義にてお客様の要望を基に機能・非機能要件を固めた上で、具体的な進め方を決める必要があります。 そのため、ここで決めた要件を基に開発メンバーが システム開発 のインプットとするため、要件漏れがないようにしなくてはなりません。 【 システム開発 の流れ】 　① 要件定義 　　 　↓ 　② システム設計 　　 　↓ 　③ 開発/実装 　　 　↓ 　④ テスト 　　 　↓ 　⑤ リリース 上記 システム開発 の流れの通り、 要件定義はプロジェクト成功の鍵となる工程 なのです！ また、要件定義と良く似た言葉で 要求定義 があります。 要求定義は、ユーザーが出したシステム要望を整理することを指しており、要件定義を始める前に最初に行う工程となります。 要件定義の進め方 要件定義の進め方をご紹介します。 1. ユーザー要求を ヒアリ ング システムを実際に利用しているユーザーに ヒアリ ングを行います。 ここではユーザーに業務課題だけでなく、システム課題に至るまで細かに ヒアリ ングする必要があります。 何故ならば、ユーザー要求をシステム要件へと変換するのが要件定義であるため、ここでユーザー要求の漏れが発生することはプロジェクトの失敗を意味するからです。 しかしながら、プロジェクトには利用できる予算や期間があります。 ユーザー要求を漏れなく聞くことは重要ですが、限られた中でのシステム実現可能性を判断し、計画を立てることが必要です。 当社で言えば、製品力会議が要件を確認する場として設けられております。 2. 要求の深堀 ユーザーの ヒアリ ングが完了しましたら、要求内容を深堀し、要求の整理を行います。 前述した通り、全ての要求をシステムに落とし込むのは難しいため、ユーザーと話ながら要求の優先度をつけていく必要があります。 優先順位の決め方は各社異なるかと思いますが、例えば以下のようなつけ方があるかと思います。 「必須」：優先度高・・・対応必須 「希望」：優先度中・・・可能であれば対応してほしい 「任意」：優先度低・・・業務課題としては低いため、今後対応してほしい要件 優先度を決める際、ユーザーとの交渉に苦労することがあるかもしれません。 また、要求の深堀をしていく中でゴールの設定をするのも大切です。 システム開発 のプロジェクトが発足した際、ゴールを明確にすることでユーザー/システム担当を含めた関係者の意思決定をする際の合意形成に役立てることができます。 プロジェクトは短期的なものから長期的なものまで様々かと思いますが、このゴール設定が明確になっていることで、目的からの脱線を防ぐことができます。 要求の深堀をするにあたり、当社では ヒアリ ングシートを用いて表面的な要望ではなく、隠れた要求を引き出せるようにしています。 3. 要件定義書の作成 要件定義の成果物は、要件定義書になります。 要件定義工程でユーザーと検討した内容を資料に分かりやすく落とし込み、ユーザーに提出します。 ユーザー側に要件定義書の内容を確認してもらい、承認を得ることで システム開発 に入れるのです。 もし要件定義書に合意した要件がないことに気づくことなく、 システム開発 に入ってしまうとユーザーから不満がでたり、会社間の信用関係にも影響を与えてしまう可能性があります。 要件定義書への要件漏れがないよう、しっかりと要件を整理した上で資料化していくことをおすすめします。 要件定義書にまとめる項目例は以下の通りです。 ※会社によってはテンプレートも準備されていると思いますので、ご参考までにご確認ください。 ◆ 要件定義書の項目例 システムの概要 システム開発 の背景/目的 システム構成 機能要件 非機能要件 スケジュール 予算（見積） 重要ワードとポイント 業務要件 業務要件とは、 システム開発 の対象となる業務の流れを明らかにすること です。 システム化するならこの業務で使っているこの機能を…！ と、システムを意識した業務のお話しをされる方がいらっしゃいますが、この時は業務の流れだけを考えてください。 そのため、システムに詳しい方よりも業務に詳しい方に ヒアリ ングするのが一番だと思います。 ここで業務内容の漏れがでてしまうと、 システム開発 の際にユーザーシステム担当にて認識乖離が発生し、スケジュール遅延等に繋がってしまうので注意が必要です。 システムを導入する業務をどのように行うか、その中でシステムがどのような役割を果たすべきかが定まりましたら業務要件は完了となります。 システム要件 システム要件とは、業務要件にて定義した中でシステムに求める機能・性能等を定めること です。 業務要件にて定義したものを、システムの機能や、システムとしてどこまでできるかを落とし込む工程です。 システムとして「出来ること、出来ないこと」がありますのでそれを明確にし、ユーザーと認識を合わせることが大切です。 機能要件 機能要件は、システムで実装する機能のこと です。 機能要件は実際にシステムを利用するユーザーにとっては、業務効率を上げていくために重要な要件になります。 業務要件にて明確にした業務の流れが、 システム開発 によってどのように変更されるかをユーザーに提示します。 本工程にて定義した機能要件は、後続の設計フェーズでのインプット情報となりますので抜かりなく定義ください。 なお、機能要件にて扱うものとしては以下があります。 画面表示 画面操作 内部処理 外部連携処理 データ構造 データ種類 帳票出力　　　　など 非機能要件 非機能要件は、機能要件以外のもの全般のこと です。 非機能要件はクライアンから直接見えるところでないため、システム担当から提示する必要があります。 通常、 情報処理推進機構（IPA） が出している「非機能要求グレード」以下6つの項目に沿って、非機能要件を定義していきます。 可用性（サービス利用時間、バックアップ方法、障害発生時の復旧方法 など） 性能/拡張性（データ負荷量 など） 運用/保守性（バックアップ形式/頻度、運用時の役割 など） 移行性（停止期間、移行期間 など） セキュリティ（アクセス数、利用数 など） システム環境・ エコロジー （システム設置環境 など） 求められる4つのスキル ここからは、要件定義にて求められるスキルを4つご紹介します！ コミュニケーションスキル まず1つ目に大事なのが、ユーザーの要求を引き出すためのコミュニケーションスキルです。 ユーザーと仲が良いということではなく、如何にユーザーからの要求を細部まで引き出せるかが重要です。 また、システムを理解していないユーザーに対し分かりやすく説明するスキルも欠かせませんし、システム化できない部分に対しては、折衝することもあると思います。 要件定義においてコミュニケーションスキルは欠かせない重要スキルといえます。 資料作成スキル ユーザーと検討した内容を、数値や文章で正確に表現する資料作成スキルが必要です。 たかが資料と侮ってはいけません。 要件定義工程の成果物である要件定義書は、ユーザーへの説明資料だけでなく、後続工程のインプットとなるものです。 要件定義書にて、曖昧な表現やユーザーに理解できない資料を作成してしまうとスケジュール遅延やコスト面に影響がでてしまう可能性があります。 これらのことから、資料作成スキルも欠かせないスキルなのです。 分析スキル 次は、分析スキルです。 ユーザー要求の ヒアリ ングをしていく中で、業務の問題/課題を明らかにします。 システム化にて課題解決があるにもかかわらず、それを明確にできないまま後続の工程に進み、ユーザーとの検討不足や、不具合の発生ということは避けなければなりません。 また、ユーザーからの要求に対し、システム化した際の動きも分析する必要があります。 実現不可能な システム開発 をユーザーと合意してしまい、開発メンバーが苦労する… そんな システム開発 を避けるためにも分析スキルは重要なスキルとなります。 スケジュール管理スキル 最後は、 システム開発 を円滑に進めるためのスケジュール管理スキルです。 限られた期間、予算の中での システム開発 となるため全体的なスケジュール管理はとても大切です。 リリースまでのことを考えると要件定義に長く時間をかけることができません。 進捗管理 やリスクコン トロール を含めたスケジュール管理スキルが必要となります。 おすすめ書籍をご紹介！ 要件定義として参考にすべき、おすすめ書籍をまとめてみました。 『図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書』 『はじめよう! 要件定義 ~ビギナーからベテランまで』 『システムを作らせる技術 エンジニアではないあなたへ』 まだまだ多くの書籍がありますが、今回は3冊のみを紹介しました。 ◆ マネジメントにおすすめの書籍も是非ご参考ください。 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

配配メール開発課Jazumaです。 2022/04/09(土) ~ 04/11(月)の3日間に渡ってPHPerKaigi2022が開催されました。 今回は初のハイブリッド開催となり、現地・配信ともに大盛況でした。 このイベントは 日本PHPユーザ会 主催のイベントで、 ラク スはスポンサーとして協賛させていただいています。 phperkaigi.jp ラク スからは3人が登壇した他、多くのメンバーが参加しました。 そこで今回は参加者によるレポートを紹介させていただきます。 PHP 関連の取り組みは以下をご確認ください！ 　 ◆ PHP イベント PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe 参加申込はこちら forms.gle ◆ PHP 関連記事 ・ 毎月開催しているPHPerのための学習コミュニティ、PHPTechCafe【21年度 まとめ】 ・ ラクスによる The PHP Foundation への寄付について 4/9 (土) 前夜祭 PHPのエラーを理解して適切なエラーハンドリングを学ぼう エラー監視とテスト体制への改善作戦 4/10 (日) 1日目 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント MongoDB に溜まった約1.6億レコード、データ量1TBのあらゆるサイトの記事データを BigQuery で高速検索できるようにした話 PHPとGraphQL 新卒 Laravel 初心者が成長していく中で感じたコレジャナイ感 メルカリ、巨大モノリスにおける複雑性をリリース9年目にしてどう解決するか PHPで「時間がかかる処理」を並列でブン回す 作って遊ぼう！Composer Plugin 計測ことはじめ 〜アプリケーションを知るために〜 何でもキレイにiterationする方法を考える in PHP 割とアプリケーションが大きくなってから PHPStan を入れた時の体験談 Webサービスのバウンスメール処理の事始め 本当にあった怖いPHPコード7選 Predefined Interfacesを使って便利な独自クラスを作りましょう！ PHPerだってPHPから「OKグーグル」したい！ 4/11 (月) 2日目 PHPとゆかいな「型」たち PSR-7とPSR-15によるWebアプリケーション実装パターン ラクスからの登壇セッションのご紹介 今だから話せるPHP8バージョンアップの裏側～全5サービスの事例紹介～ 新卒PHPer奮闘記 ～配属されたのは3歳違いのプロダクト！？～ どんとこい、PhpStorm　〜Why don't you do IDE's best!〜 / Don't KOI PhpStorm!! Why don't you do IDE's best!! まとめ PHPerのためのコミュニティ PHPTechCafe 4/9 (土) 前夜祭 PHP のエラーを理解して適切なエラーハンドリングを学ぼう report by id:Jazuma 株式会社弁護士ドットコム 所属並里さんによるセッションです。 PHP のエラーとエラーハンドリングがテーマでしたが、特にエラーハンドリングの部分が興味深かったです。 speakerdeck.com エラーハンドリングについて エラーハンドリングの目的 エラー発生箇所・原因の特定 処理を中断する ユーザにエラーを知らせる エラーハンドリングで大事なこと 例外を握りつぶさずに適切に対応する。 エラーハンドリングのスコープを狭くする。 捕捉すべきものとそうでないものを区別する。 エラーハンドリングのスコープを狭くするとエラーの原因特定がやりやすくなると思いました。 エラー監視とテスト体制への改善作戦 report by id:Jazuma 株式会社ウエディングパーク所属ヒエ イカ ザトさんによる発表です。 speakerdeck.com エラー監視体制 (改善前) エラーを監視する仕組み自体はあったものの、監視が不十分だった。(既存エラーは非対応・自分が担当した機能以外は無視等) (改善後) エラー内容や日付別のエラー数・内容を集計して、発生回数の多いものから対応する監視体制を整備した。 テストコード エラー監視体制はできたので、次のステップとしてテストコードの整備に取り組む。 実施した作業 Dockerでテスト実行 モックを使って外部アプリケーションに依存しないテストコードを設計 GitLab CI上での自動テスト 当初は カバレッジ 向上が目的となり、品質が向上しなかったが ペアプロ や認識合わせにより解消 施策の活性化 多職種へのアピール テックブログでの情報発信 エラー数や カバレッジ を 定量 化しつつ、 定量 化だけでは解決できない品質や施策の拡大をチームの運用フローでカバーする取り組みが印象的でした。 4/10 (日) 1日目 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント report by id:Jazuma 和田卓人さんによる発表です。 Takuto Wada (@t_wada) / Twitter speakerdeck.com よくある防御的プログラミングの誤解 ひたすら入力値をチェックする 不正な入力値を自分で何とかしようとする コメントやPHPDocで補足する 防御的プログラミングとは既存の悪いコードへの対処療法ではなく、 問題発生を事前に防ぐためのコーディングスタイル 正しい防御的プログラミング 型や enum による防御 (不正な値をはじくのではなく、不正な値が来ないようにする) クラスのプロパティで仕様を表現する 不変オブジェクトで予期しない変更を防ぐ(値を変更する際はプロパティを変更するのではなく、新しい インスタンス を返す) 常に正しいオブジェクトのみ存在させる(コンスト ラク タに不正な値が渡された場合、例外を送出して インスタンス を生成させない) 責務の配置(結果の正しさを担保するレイヤーと動作を担保するレイヤーを分ける) 不正な値を存在させるのはついやってしまいがちな設計だと反省しました。 MongoDB に溜まった約1.6億レコード、データ量1TBのあらゆるサイトの記事データを BigQuery で高速検索できるようにした話 reported by id:hirobex 植江田和成 ( @developer_kazu )さんによる発表です。 MongoDBに溜まった1.6億レコード、データ量1TBの記事データを BigQuery に移行しようとした際に出た課題と、解決方法を紹介していただきました！ 昔のデータと最近のデータでカラム数が違うため、エラーが出る カラムの順番が違い、型エラーが発生した 壊れたデータ存在していて、エラーがでる などといった課題に対し、 カラムの存在チェックを行い、存在しない場合はnullを代入 配列の構造を固定化する データを小分けにすることで、エラー発生箇所を特定 といった方法で解決したとのことでした！ 動的 スキーマ のMongoDBから、静的 スキーマ のBigQueryへデータ移行するのは一筋縄ではいかないことがわかりました。 PHP とGraphQL reported by id:hirobex 永野 峻輔 ( @glassmonekey )さんによる発表です。 speakerdeck.com GraphQLと REST API の違い GraphQLを採用することのメリット・デメリット といった、GraphQLの解説をした上で、 PHP でGraphQLを採用するための話をしていただきました！ 非常にわかりやすく、 PHP でGraphQLに挑戦したい人におすすめの発表でした！ 新卒 Laravel 初心者が成長していく中で感じたコレジャナイ感 reported by id:hirobex ふわせぐ ( @fuwasegu )さんによる発表です。 speakerdeck.com Laravelはすごく便利なライブラリですが、考えずに使ってしまった結果、感じるようになってしまったデメリットと それに対する解決のアプローチを紹介していただきました！ 簡単にまとめると 依存関係の混沌化 Facade離れをしよう 責務の肥大化 Model・Controllerだけではなく、UseCaseを導入しよう 重くなるテスト Featureテストだけでなく、Unitテストを適宜導入しよう という内容でした。 Laravelを使っていて、同様の課題を感じている方は、ぜひ聞いてみてください！ メルカリ、巨大 モノリス における複雑性をリリース9年目にしてどう解決するか reported by id:hirobex 安達 勇太 ( @uadachi )さんによる発表です。 speakerdeck.com 巨大 モノリス における課題と、モジュラー モノリス に移行するための戦術を紹介していただきました！ 依存関係の分析/ 定量 化 コンポーネント 間のやりとりに使用する API の策定 サブ コンポーネント 分割 といった具体例をあげて説明していただきました。 モジュラー モノリス を扱ったセッションは多く、多くの長寿サービスで使われている PHP の課題なのかもしれませんね PHP で「時間がかかる処理」を並列でブン回す reported by id:MasaKu kiridarumaさん（ @kiridaruma ）によるセッションです。 www.kiridaruma.net 並列処理を実行する上での基礎的な知識や PHP での並列処理の実現方法などのご紹介でした。 まず、知識の整理として以下のようなことをご説明いただきました。 並列処理 同時に複数の処理を進めること 並行処理 複数の処理を直列で少しずつ進める PHP では Generator や Fiber という仕組みを利用することで並行処理が実現できますが、並列処理を実現するためにはOSの力を借りることになります。 また、ここで重要なキーワードとして「スレッド」と「プロセス」という言葉が登場します。 スレッド 他のスレッドとメモリを共有する うまく利用しないと意図しない挙動を起こす プロセス 他のプロセスからメモリは隔離される 入出力周りに気を付ければ何とかなる 基本的にはマルチスレッドにしてもパフォーマンスはそこまで大きな差がないレベルとのことですので、マルチプロセスでコードを書いた方がバグを生みにくいため、まずはマルチプロセスを実現できるようになることが重要かと思いました。 PHP でマルチプロセスを実現する以下のコマンドが紹介されていました。 exec() , passthru() , system() など 一番簡単に外部コマンドが実行可能 popen() ファイルと同じように読み書き可能 proc_open() 他の関数に比べて一番詳細に設定できる いくつかの違いがありますが、 php .net を読んで自分の用途に合ったものを利用するのが良いとのことでした。 実例としてまして、DBで大量のデータ移行等をされる際はマルチプロセスで並列実行したほうが良いとのことでしたが、サーバスペックに依存するため、比較的サーバスペックに余裕があるサーバを利用されたようでした。 また、長時間走行するような バッチ処理 でありがちなこととして、よくわからないタイミングで失敗していることなどが紹介されておりました。 そんな時に便利なのが、ログ出力をしっかりとしておくこと、とのことでした。ログ出力時はプロセスごとに詳細なログを出力することが重要ですが、ログファイルを出力する際はファイルのロックに注意が必要とのことです。 また、 バッチ処理 を作成する上での基本的なこととして、シグナルハンドラは必ず設定することが挙げられていました。 例えば、親のプロセスを終了した際に子のプロセスも併せて終了する、などもしっかりと定義しておくべきとのことでした。特に、正常終了した際と異常終了した際のexitコードは当たり前のお作法として今後も気を付けていきたいです。 どういうときに並列処理でコードを書くべきか、また、実現時はどのようなことに気を付ければよいのか、ということの気づきになるご発表と感じました！ 作って遊ぼう！Composer Plugin reported by id:takaram きんじょうひできさん ( @o0h_ ) によるセッションです。 speakerdeck.com 今や PHP での開発にほぼ必須ともいえるcomposer（今年で10周年！）ですが、実は プラグイン を作るといろんなことができるよ、というお話です。 composer プラグイン には大きく以下の2種類があります。 独自コマンド（ composer hogehoge みたいなもの）を登録するもの composer の各種イベントをフックするもの 2つ目については、composer でフックできるイベントはかなりいろいろあるようで、 各種コマンドの実行前 パッケージのインストール前後 autoload. php の更新前後 や、他にも種々のタイミングで処理を差し込めるようです。 これがすぐに役立つかはわかりませんが、どんなことができるか知っておけばいざというときの選択肢として使えるかもしれませんね！ 計測ことはじめ 〜アプリケーションを知るために〜 reported by id:hirobex 清家史郎 ( @seike460 )さんによる発表です。 speakerdeck.com なぜ計測するのか なにを計測するのか どのように計測するのか といった、計測についての基本を教えていただきました！ パフォーマンスに課題感を持っている方は解決の一端になるかも……？ 何でもキレイにiterationする方法を考える in PHP reported by id:hiro_ji ぬさしさん( @nukisashineko )による LT です。 speakerdeck.com PHP のforeachをシンプルにするポイントをご紹介いただきました。 配列操作を分類整理して、1つのforeachで1つのことだけ行う 変換、グルーピング、集約等の配列操作はひとつのforeachで行わない 記述が 冗長化 した場合は関数化 遅延処理にはGenaratorを利用する 並列処理にはPromise + Genarator を利用する 思い返してみると、私自身もスパゲティ気味な繰り返し処理を書いた記憶があるので、 foreachにフォーカスした今回の内容はとてもためになりました！ 割とアプリケーションが大きくなってから PHPStan を入れた時の体験談 reported by id:takaram 株式会社 DROBE の都筑さんによる LT です。 プロジェクトの途中から PHPStan を導入した経験を語ってくださいました。 Level と Baseline を調整していきながら、以下のように段階的に PHPStan を導入していったそうです。 コマンドライン から手動実行する形で導入 CI に導入 Level を 0→1→3→5 と上げていく 方針として掲げた「頑張りすぎない！」が大事なところだろうと思いました。 こういうツールを導入するときは、つい張り切ってあれもこれもやりたくなってしまいがちな気がするのですが、一足飛びせず無理しない程度に一歩ずつやっていく「急がば廻れ」を心に留めておきたいですね。 Webサービス のバウンスメール処理の事始め reported by id:hiro_ji BASE株式会社の炭田さん( @tac_tanden )による LT です。 speakerdeck.com Webサービス におけるバウンスメール処理について、その役割と利用方法をご紹介いただきました。 バウンスメールとは 何らかの理由で正常に配信されなかったメールのこと バウンスメールが極端に多い（バウンス率が高い）と... 送信者の評価が下がり、スパム扱いになってしまう可能性 ユーザに届けたいメールが届かない バウンス率を抑制するには バウンス回数が多い傾向にあるアドレスリスト（サプレッションリスト）への配信を停止する 弊社のメール配信サービスでもバウンスメール処理を扱っていますが、より確実にユーザにメールを届けるうえで重要な役割を担っていると改めて感じました。 本当にあった怖い PHP コード7選 report by id:ryo479 speakerdeck.com 実際に開発現場で見かけた怖いコード(可読性、保守性が明らかに低いコードなど)を７つ紹介されました。 メソッドの引数が７個以上あって、変数名はアルファベットを並べただけ if文のネストが６個以上ある 変数名がわかりにくい 一つのアクションメソッドに裏で３つのエンドポイントが存在している コメントアウト 地獄 マジックナンバー 地獄 一つのファイルに２つのクラスが定義されている たしかに怖いですね...。 分かりにくい変数名は割と見かける気もします。 自分では分かりやすく書いているつもりでも、他人からは分かりにくいということも往々にしてあるので、コードレビューは重要ですね。 Predefined Interfacesを使って便利な独自クラスを作りましょう！ report by id:ryo479 speakerdeck.com PHP の言語側に定義済みのインターフェースである「Predefined Interfaces」についての発表です。 Predefined Interfacesとは PHP 側に定義済みのインターフェース。実装すると、 PHP エンジン自体の機能が提供される。 www.php.net 発表では、定義済みインターフェースの「Stringable」「Traversable」「 Iterator 」を使用したコードを元に説明されました。 定義済みインターフェースをどのように使用すればいいのか、どのようなメリットがあるのかがよく分かる内容でした。 PHPerだって PHP から「OKグーグル」したい！ report by id:ryo479 speakerdeck.com Googleアシスタント に PHP プログラムからアクセスして、「OKグーグル」するという遊び心あふれる発表です。 Googleアシスタント の裏側はgRPCなので、 Python やGoで実装されることが多いとのこと。 しかし PHP もgRPCの正式サポート言語なので、やればできるはずなのでやってみようという試みです。 発表では実際に Googleアシスタント に PHP でアクセスし、アレクサを操作して部屋の照明を消すというデモンストレーションもあり、興味を惹かれる内容でした。 4/11 (月) 2日目 PHP とゆかいな「型」たち report by id:tsudachantan 株式会社ユニラボの石揚千洋さん（あげさん）によるセッションです。 改めて PHP の「型」の種類や使い方、メリットデメリットや実践についてわかりやすくお話いただきました。 fortee.jp 型って何？ プログラミング言語 における型（静的型付け、動的型付け） 静的型付け プログラムの実行前に型が決まっていて、人間がコーディング時に型を指定する 関数の引数や返却の型指定が合っていないと コンパイル 時点でエラーになる 型安全性がある 動的型付け プログラムの実行前に型が決まっておらず、実行時に内部で型定義される 設定や書き方によるが型安全性が少し弱い 強い動的と弱い動的がある PHP は インタープリタ 言語 PHP のゆかいな型の紹介 動的型付けだけでなくコーディング時に型宣言できる 型宣言の使い方(メリット、デメリット） 引数の型指定ができる ！！実は PHP は型指定しても、キャスト可能なものはキャストしている！！ 型変換がうまくいかない場合にエラーになる（ PHP のデフォルトはこれ） 強い型付け（型が違うとそもそもエラー）にするには PHP の場合設定が必要→strict_types=1 型宣言のメリット、デメリット 〇型がわかるので変数を使いやすい 〇 IDE など使えば候補を出してくれて便利 〇大規模開発は大きなメリット 〇型安全でバグが出にくいかも ×設定次第で暗黙的に型変換 ×arrayを使うと何でもよくなってしまう ×きちんと設計しないと破綻する ×小規模開発ではメリット薄い 型とは何か？というとこから PHP での型の挙動までおさらいすることができました。 「型」をあまり意識せずプログラムしてもなんとかなる時代は過ぎ去り、ほんの少しの抜け穴が大損失になるレベルまでインターネットは広まり、 PHP でもバージョンアップにつれてかっちり型を縛ったstrictプログラミングがほぼ主流となりつつあります。 PHP の柔軟性を理解したコーディングに役立つ内容ですので、ぜひ聞いてみてください。 PSR-7とPSR-15によるWebアプリケーション実装パターン reported by id:takaram うさみけんたさん ( @tadsan ) による トーク です。 tadsan.fanbox.cc PHP で HTTP を扱う際によく登場する PSR-7 / PSR-15 とは何で、どんなメリットがあるのか、どうやって使うのか？といったことを解説する内容です。 PSR-7 HTTP リク エス ト、レスポンス、 URI など、HTTP メッセージに関わるインターフェースを定義している PSR-15 HTTP ハンドラ、 ミドルウェア など、Web サーバの実装に関連するインターフェースを定義している PHP は フレームワーク を使わなくても簡単に、 $_GET , $_COOKIE 等でリク エス ト情報を取得し、 header() , setcookie() , echo 等で HTTP レスポンスを作れるわけですが、簡単で自由度が高すぎるがゆえに、無秩序になりやすいという面もあります。 そこで PSR-7, 15 やそれを使った フレームワーク を利用することで、以下のようなメリットを得られるということです。 コードの見通しがよくなる テストがしやすくなる 従来の mod_ php , PHP -FPM のような、リク エス トごとに状態がリセットされる環境 以外 でも動かしやすい RoadRunner, Swoole など 節冒頭の URL には、スライドの他にサンプルプログラムの リポジトリ URL も掲載されているので、一度見てみると PSR での HTTP の扱いへの理解が深まりそうです！ ラク スからの登壇セッションのご紹介 ここからは弊社から登壇させて頂いたセッションの内容をご紹介します。 今だから話せるPHP8バージョンアップの裏側～全5サービスの事例紹介～ report by id:radiocat speakerdeck.com PHP で開発されている弊社の全5サービスの事例をもとにPHP8バージョンアップをどのように行ったのか、その裏側をご紹介する内容でした。PHP8では様々な新機能がリリースされていますが、特に影響が大きいのが「下位互換性がなくなる変更」です。「==」の比較結果や関数に指定する引数の型の扱いなど、これまで緩やかに扱われてきたものが厳格化され、挙動が変わったり、エラーになったりします。 そのような影響の大きなバージョンアップに対して全サービスから代表者が選抜されて密に情報共有しながら対応を進めました。特に、これまでの緩やかな仕様を受け入れてきた歴史の長いサービスでは影響が大きく、ツールなどの仕組みでの対応も難しく、調査範囲、テスト範囲とも大きくなったようです。最終的にこれまでのバージョンアップ対応よりも最大で約10倍の 工数 がかかったとのことでした。それでも防ぎきれなかった不具合も今後PHP8バージョンアップに取り組む際に役立つ情報として共有されています。 影響は大きいものの、近年 PHP が取り入れている新機能を使えるメリットもあるため、 情報共有を大切にしながらポジティブに取り組むことが大切 とのことでした。 発表者： 久山勝生 ／（ @MasaKu_e ） ◆ 登壇を終えて PHPerKaigi は以前より参加させていただいているイベントで、昨年は残念ながら非採択であったこともあり、今年こそは是非ともスピーカーとして参加したいという気持ちで登壇にチャレンジしました。 　 今回発表させていただいた、PHP8バージョンアップは規模の大きな対応であったため、各商材のノウハウや苦労などが詰まった内容になるという印象がありましたが、それゆえに情報の取りまとめやストーリーの組み立てには苦労しました。 発表当日は、弊社の取り組みについて共感してもらえる声や決められたタイミングでバージョンアップが計画されている点に賛同の声が頂けて嬉しかったです。 「次の PHP バージョンアップの対応についても共有を待っている！」とのコメントも見受けられましたので、機会があれば再チャレンジできればと思いました！ 新卒PHPer奮闘記 ～配属されたのは3歳違いのプロダクト！？～ report by id:ryo479 speakerdeck.com 2021卒で新卒入社した弊社社員が、2001年リリースのプロダクト開発に携わるにあたって苦労した経験と、その乗り越え方を発表しました。 苦労した点としては以下を上げています。 PHP の書き方 ノン フレームワーク レガシーコード 外部システム連携機能 ノン フレームワーク で独自の実装がされていたり、レガシーコードだったりすると苦労しますよね。 新卒であればなおさらです。 改善を進めようにもある程度大きなシステムだと、簡単にはいかないのが難しいところです。 研修内容やドキュメントの整理、そして周りの方のサポートが重要だと再確認できました。 発表者： 廣部知生 ／ @tomoki2135 ◆ 登壇を終えて PHPerKaigiに初参加、初LT登壇をしました！ 新卒入社後初めて PHP に触れたため、勉強兼PHPerコミュニティを知るということで参加を申し込みました。 CfP作成からスライド資料の作成まで、登壇なれした先輩方にレビューしていただいたおかげで無事採択され、LTも盛況に終わりました！ 個人的には、 小桜エツ子 さんに自分の名前を読んでいただけたのが嬉しかったです。 次回も機会があれば挑戦したいなと思います！ どんとこい、PhpStorm　〜Why don't you do IDE 's best!〜 / Don't KOI PhpStorm!! Why don't you do IDE 's best!! report by id:radiocat speakerdeck.com PhpStormは PHP の代表的な IDE の1つでJetBrains社が開発しています。稀に「PHPStorm」と表記されることがありますが、JetBrains社のブラン ドガ イドラインには「大文字と小文字を区別してください」と書かれており、まず「PhpStorm」と覚えてくださいと呼びかけられました。 そして、脱PhpStorm初心者を目指すための3段階のテクニックが紹介されました。 Level1：補完機能を使いこなす Level2：検索を使いこなす Level3： リファクタリング 機能を活用する しかし、何よりも先に 「PHPStrom」じゃなくて「PhpStorm」 という事を覚えておきましょう。 発表者： 加納悠史 ／ @YKanoh65 ◆ 登壇を終えて いつも参加させていただいているイベントなので、今回もぜひ登壇者として参加したいと思い、応募しました。 今回、CfPは3案出したのですが、実は一番 トーク 内容に自信がないものが採用されたので、自分自身が普段使っている PhpStorm の小技だけでなく、チームの PhpStorm に強いメンバーへの ヒアリ ング結果も併せて記載することで、普段から使いこなしている人でもなにか新しい発見がある発表にできるようにしました。 　 当日は、久々のオフラインイベントでの登壇だったため緊張しました。 無事ウケてよかった... 普段 PHP TechCafe などでお話させていただいている方々も多く、イベント期間中は、始終楽しく過ごすことができたとともに、いろいろなセッション、LT、アンカンファレンスを聞いて刺激を受けることができました。 　 次回もチャレンジしたいと思います！ まとめ コードの内部品質向上・既存プロジェクトへの新ツールの導入等、今あるプロダクトをいかに改善していくかという観点の登壇が多かったように思います。 また、弊社の PHP バージョンアップに関して、多くの方に言及していただきました。 PHP という技術が成熟していることの現れなのかもしれませんね。 PHPerのためのコミュニティ PHPTechCafe ラク スでは PHP に特化したイベントを毎月開催しております。その名も「 PHPTechCafe 」！！ 次回は4/22(金)に『「PHPer Kaigi 2022 を振り返る」』 をテーマに開催します！ まだまだ参加者を募集していますので、ぜひお気軽にご参加ください。 👉 PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe」PHPTechCafe 参加申込は以下フォームよりお願いします！ forms.gle 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の yayawowo です。 プロジェクトを進める上で重要な プロジェクトマネジメント 。 プロジェクトマネージャー(PM)に任命された方はどのように学習、スキル習得をされていますでしょうか？ 実務での経験を通じてという方が多いと思いますが、弊社にて開催しているイベントもおすすめです！ 今回は、プロジェクトマネジメントのTipsを共有しあう「プロジェクトマネジメント Tips LT会」の過去開催分の発表資料と、次回イベントについてまとめて紹介させていただきます！ 「プロジェクトマネジメント Tips LT会 vol.4」が5/11(水)開催！ ご興味ある方は、 参加申込フォーム より申込をお願いします。 過去開催イベント プロジェクトマネジメント Tips LT会 vol.1 プロジェクトマネジメント Tips LT会 vol.2 プロジェクトマネジメント Tips LT会 vol.3 5/11(水)開催！プロジェクトマネジメント Tips LT会 vol.4 発表者・タイトル一覧 イベントに参加する 終わりに ◆ 関連ブログも合わせてご参考ください。 ・ 要件定義 とは【まとめ】 ・ 「はじめよう！ 要件定義 ～ビギナーからベテランまで」から学ぶ要件定義の始め方 ・ PdM （プロダクトマネージャー）とは 【まとめ】 ・ 仕様書 とは 【まとめ】 過去開催イベント プロジェクトマネジメント Tips LT会 vol.1 rakus.connpass.com 『痛みから学ぶ Working Agreement の つくりかた　〜チームビルディングの失敗から得た、親切さという教訓〜』 発表者： 面川泰明 さん speakerdeck.com ☞ チームの合意を得る良い方法は、親切な情報共有と、メンバーの自主性の尊重である 『オフショア開発のマネジメント（ いつもここから ）』 発表者： iketomo1207 さん speakerdeck.com ☞ 外国人がマネージャーとして信頼されるためにやったこと ☞ 自立型組織を目指してやったこと 『全職種混合で社内LTを開催した話』 発表者： ryu さん speakerdeck.com ☞ LTという文化を、エンジニア・デザイナーで独り占めせず広げてみたら良かった話 『Retty流大規模プロジェクトマネジメントのお話』 発表者： tnkdaito さん Retty流大規模プロジェクトマネジメントのお話 from Daito Tanaka www.slideshare.net ☞ 現状を直ちに把握できること ☞ 認識が揃った状態を維持すること 『一番安い子だーれだ？ ～黒字化のための無慈悲なタスク配分～』 発表者： すずき さん speakerdeck.com ☞ チームのキャパシティを把握 ☞ 給与制度とタスク割り当ての溝 ☞ タスク割り当てひとつとっても戦略的である 『数字からプロジェクトの健康を管理する』 発表者： komik さん speakerdeck.com ☞ プロジェクトにおいても数字を見ていくことで健康管理を 『1on1を120%有効活用する方法』 発表者： masahiro_f さん note.com ☞ マネジメント課題の解決手段として1on1を活用している話 プロジェクトマネジメント Tips LT会 vol.2 rakus.connpass.com 『性格診断と価値観分析ではじめる1on1』 発表者： 面川泰明 さん speakerdeck.com ☞ 人の成長を支援するには、その人の価値観を指針にすると良い ☞ 価値観を指針にしてすべらない1on1をしよう 『 プレイングマネージャー の葛藤』 発表者： Pep299 さん speakerdeck.com ☞ プレイングマネージャー の葛藤における対処法、得られたもの、次のステップ 『 アジャイル なチームへの道 はじめの一歩』 発表者： sakamoto-k さん speakerdeck.com ☞ ユーザーストーリーとスプリングゴールを導入することで、小さな価値単位で反復的に検証しやすくなり、自然にスウォーミングできるようになった ☞ プロジェクトの不確実性を前倒しで減少させることができた 『 SaaS 開発と受託開発におけるプロジェクトマネジメントの違い』 発表者： komik さん speakerdeck.com ☞ 受託開発と SaaS 開発における品質/コスト/タイムの比較 『「終わらせる」から考えるマネジメント』 発表者： 白柳隆司 さん speakerdeck.com ☞ 「成功条件」へ向かいつつ「失敗条件」を回避する ☞ 最初だけでなく、 マイルストーン ごとに行う 『心配性の僕が チームメンバーに任せる良さについて』 発表者： ShoheiKun さん speakerdeck.com ☞ 心配性の人は勇気を出し手イケイケの人に任せてみよう ☞ 心配性を利用して改善ポイントを提案し、貢献 ☞ チームでイケイケと心配性のバランスをとろう 『メンバーと一緒に進めるマネジメントの学び方と伝え方』 発表者： Mazawa_Hajime さん speakerdeck.com ☞ 学には時間をきちんと確保する、計画を立てる ☞ 楽しめること、自分ごとにしてもらうこと ☞ 得たインプットは自分たちの過去事例に当てはめて強い手触り感を作る ☞ 読むだけでなく、みんなでやってみて紹介し合うと良い 『プロジェクトメンバーのモチベーション』 発表者： moriyama_jun さん speakerdeck.com ☞ 幸福度を使ってメンバーのモチベーションをマネジメントする ◆ 関連記事はこちら tech-blog.rakus.co.jp プロジェクトマネジメント Tips LT会 vol.3 rakus.connpass.com 『チームの成功を加速するために、1on1で個人を成長させてみた』 発表者： 面川泰明 さん speakerdeck.com ☞ 人の成長とは、自己理解に伴う視野の拡大 ☞ 他者に貢献したい気持ちがモチベーションを上げる 『利己主義と裏切りが支配する世界で称賛文化が生まれるチームとは』 発表者： satoshi okami さん speakerdeck.com ☞ 褒めるとチームは協力する ☞ 協力は成果を高める 『チームが大きくなったので、 開発プロセス を運用してみた』 発表者： ミツカワ さん speakerdeck.com ☞ 標準化することにより、組織全体の底上げに繋がる ☞ プロセスをみんなで育てると浸透しやすい 『辛くない受託開発』 発表者： GHKEN さん speakerdeck.com ☞ 「何を作るか」だけでなく、「なぜ作るか」「どう成長させるか」を踏まえた提案をして、辛くない受託開発を実現させる 『Fantia開発チームのマネジメント改善』 発表者： かのたん さん Fantia開発チームのマネジメント改善 from かの たん www.slideshare.net ☞ 「何を改善するか」を外から引っ張ってくるのではなく「なぜ改善するか」や「どうすれば改善できるか」を考えること 5/11(水)開催！プロジェクトマネジメント Tips LT会 vol.4 rakus.connpass.com 「プロジェクトマネジメント Tips LT会」の第4回目が5/11(水)19時から開催します！ ラク スからも2名登壇する他、現時点で5名の登壇が決まっております。 タイトルは未定のものが多いですが、当日は充実な時間を過ごせること間違いなしです！ 是非この機会にご参加ください。 LT枠も空きがございますので、こちらも合わせて検討をお願いします！ 発表者・タイトル一覧 登壇者 タイトル misato_kii_3 さん 考え中 dach さん 考え中 はち さん 考え中 komkom さん 考え中 miure さん システム開発 体験 ボードゲーム 「ペジテの自転車」 ※2022/4/13時点での情報です。 発表内容が変更する可能性がありますので、ご了承ください。 イベントに参加する ラク スが主催する「プロジェクトマネジメント Tips LT会 vol.4」にご興味を持ち、是非とも参加したい！という方は以下フォームより申し込みをお願いします。 forms.gle 開催日が近づきましたら、当日の視聴URLなどをお送りさせていただきます！ 終わりに 「プロジェクトマネジメント Tips LT会」のまとめはいかがでしたでしょうか？ ラク スでは、定期的(週1回を目途)に技術イベントを開催しており、エンジニア/デザイナーの皆様の学習の場を提供させていただいております。 最後にはなりますが、イベントを開催する側としても、参加する皆さんの一助となる情報がありましたら幸いです。 お読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 皆さんはじめまして！ 今回 Rakus Developers Blog 初投稿となる株式会社 ラク スの大原(kzak_24)と申します。 インフラ開発部 SRE課に所属しております。 どうぞよろしくお願いいたします。 先日、 アサイ ンされているプロジェクトにて、CIツールに GitHub Actionsを採用する運びとなり、 AWS のサービスと連携しての技術検証を終えました。結論、想像していたよりも簡単にCIパイプラインを構築することができ、非常に便利だと感じました。そこで今回は、検証内容や実装ポイントなどをご紹介していきたいと思います。 情報量が多く、すべてをお伝えすることはできませんが、 GitHub Actionsと AWS を使って、CIを始めたいという方のご参考となれば幸いです。 目次 はじめに 目次 GitHub Actionsとは？ 検証環境の構成 事前準備 ワークフローの定義ファイルの作成 個人用アクセストークンの取得 リポジトリのSecrets作成 workflowファイルの作成 Eventの定義 Jobの定義 AWSサービスとの連携 buildspec ワークフローの実行 テスト用ワークフローを実行 ビルド用ワークフローを実行 終わりに 参考文献 GitHub Actions とは？ GitHub のドキュメントには次のように記載されています。 GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production. Google先生 による翻訳 GitHub Actionsは、 継続的インテグレーション および継続的デリバリー（CI / CD）プラットフォームであり、ビルド、テスト、およびデプロイのパイプラインを自動化できます。 リポジトリ へのすべてのプルリク エス トをビルドしてテストするワークフローを作成したり、マージされたプルリク エス トを本番環境にデプロイしたりできます。 簡単に言うと、 GitHub リポジトリ で起きるイベントをトリガーにしたCI/CDパイプラインを構築できるプラットフォームということになります。 GitHub Actionsには以下のような構成要素があります。 Workflow GitHub Actionsの一連の処理をまとめた単位。1つのファイルで1つのワークフローを定義できる Event ワークフローを実行するトリガー Job ランナー上で実行される処理の単位。ジョブが分かれると別の環境で処理が実行される Step ジョブが実行する処理の集合。 Actions ワークフローの最小構成要素。コマンドの実行やアクションという一連の処置がまとまったライブラリのようなものを実行することができる Runner 処理を実行する環境 検証環境の構成 今回の検証では以下のような構成でCIパイプラインを構築しました。 開発者のPR作成から、最終的に Amazon ECRにコンテナイメージをプッシュするところまで、このパイプラインでは実行します。 CIは以下のような流れで実行されます。 開発者がアプリケーション リポジトリ でPRを作成 PRマージというEventを検知し、CIが起動 Test Workflowが実行される Build Workflowが実行され、 AWS CodeBuildが実行される CodeBuildで作成されたコンテナイメージを Amazon ECRにプッシュ 事前準備 それでは、CIを動作させる為の準備をしていきましょう。 今回必要なものは以下の通りです。 アプリケーション用の リポジトリ ワークフローの定義ファイル GitHub の個人用アクセス トーク ン リポジトリ のSecrets AWS サービスのリソース AWS クレデンシャル ※ 今回は以下の項目の作成、取得については完了済みという前提で、説明を省略します。 アプリケーション用の リポジトリ AWS サービスのリソース AWS クレデンシャル ワークフローの定義ファイルの作成 ワークフローを実行するアプリケーションのルート ディレクト リに .github/workflows/ という ディレクト リを作成します。 test_workflow.yaml 、 build_workflow.yaml を .github/workflows/ 配下に作成します。 GitHub Actionsのワークフローは YAML 形式で定義し、 .github/workflows/ に配置することで、ワークフローとして管理されます。 個人用アクセス トーク ンの取得 GitHub Actionsの中で リポジトリ に特定の操作を行う際、アクセス トーク ンが必要になる為、個人用アクセス トーク ンを取得します。(今回は後述するrepository_dispatchという処理で使用します)。 まず GitHub のページにアクセスし、ページ右上隅のプロフィールをクリックし、 「Settings」 をクリックします。 スライダー最下の 「Developer settings」 をクリックします。 スライダーから、 「Personal access tokens」 をクリックします。 「Generate new token」 をクリックします。 パスワード入力を求められるので、入力します。 作成するアクセス トーク ンの説明や有効期限、権限スコープを設定します。 今回は リポジトリ に関する操作権限をスコープに設定します。 ページ下部の 「Generate token」 をクリックします。 作成したアクセス トーク ンの値が表示されます。 このタイミングでしか表示されないので、注意してください。 再度アクセス トーク ンのページにアクセスすると、 トーク ンが作成されていることが確認できます。 有効期限の延長や権限スコープの変更もここから行えます。 リポジトリ のSecrets作成 GitHub Actionsの中で使用する AWS のクレデンシャルやアクセス トーク ンなどの情報は、 Secrets という機能で暗号化したシークレットとして使用します。 取得した AWS クレデンシャルと個人用アクセス トーク ンをSecretsに登録します。 リポジトリ のメインページにアクセスします。 リポジトリ 名の下の 「Settings」 をクリックします。 スライダーから 「Secrets」 をクリックし、 「Actions」 をクリックします。 シークレットの管理ページが表示されるので、 「New repository secret」 をクリックします。 Name にシークレットの名前(任意)を設定し、 Value に取得したアクセスキーIDの値を入力します。 「Add Secrets」 をクリックし、 Repository secrets に作成したシークレットがあることを確認します。 同様にシークレットアクセスキー、個人用アクセス トーク ンも登録します。 workflowファイル 今回の検証で作成したワークフローファイルは以下のようになっています。 test_workflow.yaml name : Test Workflow on : pull_request : branches : - main types : - closed jobs : Lint-Test : runs-on : ubuntu-latest steps : - name : Checkout Repository uses : actions/checkout@v2 - name : Run Lint run : | docker-compose up -d --remove-orphans docker-compose exec -T next npm run lint echo "Lint succees!." - name : Run Test run : | docker-compose exec -T next npm run test echo "Test succees!." - name : Dispatch Build Workflow uses : peter-evans/repository-dispatch@v1 with : token : ${{secrets.REPO_ACCESS_TOKEN}} repository : 検証用のリポジトリ event-type : ci-sample build_workflow.yaml name : Build Workflow on : repository_dispatch : types : - ci-sample env : REGION : ap-northeast-1 PROJECT_NAME : example_CI_build_project IMAGE_TAG : ci-sample jobs : Build : runs-on : ubuntu-latest steps : - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v1 with : aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY }} aws-secret-access-key : ${{ secrets.AWS_SECRET_KEY }} aws-region : ${{ env.REGION }} - name : Run CodeBuild uses : aws-actions/aws-codebuild-run-build@v1 with : project-name : ${{ env.PROJECT_NAME }} env-vars-for-codebuild : IMAGE_TAG env : IMAGE_TAG : ${{ env.IMAGE_TAG }} それでは、中身について説明していきます。 Eventの定義 まずは、ワークフローを実行するトリガーとなるイベントの定義です。 test_workflow.yaml (一部抜粋) on : pull_request : branches : - main types : - closed GitHub Actionsでは、 on セクションにイベントを定義します。 上記のように定義することで、mainブランチへPRをマージしたことをトリガーにワークフローを実行できます。 pull_request の他にも、 push や手動実行を行う workflow_dispatch というイベントも定義できます。 また、 repository_dispatch というイベントを定義することで、あるワークフローから別のワークフローを実行するイベントを送信できます。 test_workflow.yaml (一部抜粋) - name : Dispatch Build Workflow uses : peter-evans/repository-dispatch@v1 with : token : ${{secrets.REPO_ACCESS_TOKEN}} repository : 検証用のリポジトリ event-type : ci-sample build_workflow.yaml (一部抜粋) on : repository_dispatch : types : - ci-sample テスト用ワークフローの中で ci-sample というパラメーターが設定された repository_dispatch イベントをビルド用ワークフローに送信しています。 指定されたイベントが送信されたことをトリガーにビルド用のワークフローが実行されるようになっています。 また、 uses を使用することで、アクションという一連の処置をまとめたライブラリのような機能を使用できます。 テスト用ワークフローでは peter-evans/repository-dispatch というアクションを使用して、repository_dispatchイベントを送信しています。 Jobの定義 続いて、ジョブの定義について見ていきましょう。 test_workflow.yaml (一部抜粋) jobs : Lint-Test : runs-on : ubuntu-latest steps : - name : Checkout Repository uses : actions/checkout@v2 - name : Run Lint run : | docker-compose up -d --remove-orphans docker-compose exec -T next npm run lint echo "Lint succees!." ジョブは jobs セクションに定義します。 Lint-Test でジョブの名前を定義しており。ジョブは複数作成することが可能です。 runs-on でそのジョブが実行されるランナーの仮想環境を指定できます。 steps セクションでジョブが実行するステップを定義します。 steps は name でそれぞれ名前を指定することができ、順次実行されます。 uses 、 run で実行するアクションやコマンドを定義しています。 AWS サービスとの連携 続いて、 AWS サービスと連携する処理について見ていきましょう。 build_workflow.yaml (一部抜粋) - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v1 with : aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY }} aws-secret-access-key : ${{ secrets.AWS_SECRET_KEY }} aws-region : ${{ env.REGION }} ここでは、 aws-actions/configure-aws-credentials というアクションを使用して、 GitHub Actionsのランナーから AWS サービスを操作できるように、 AWS クレデンシャルを設定しています。 secrets.AWS_ACCESS_KEY で リポジトリ に設定した Secrets から値を取得しています。 build_workflow.yaml (一部抜粋) - name : Run CodeBuild uses : aws-actions/aws-codebuild-run-build@v1 with : project-name : ${{ env.PROJECT_NAME }} env-vars-for-codebuild : IMAGE_TAG env : IMAGE_TAG : ${{ env.IMAGE_TAG }} ここでは、 aws-actions/aws-codebuild-run-build というアクションを使用して、 GitHub Actionsから AWS CodeBuildを実行しています。 また、 env-vars-for-codebuild に 環境変数 を渡すと、CodeBuild側の 環境変数 として設定してくれるので、ワークフローで定義した値がコンテナイメージにタグ付けされます(今回の場合、 ci-sample がタグ付けされます)。 buildspec ワークフローを実行する前に、 buildspec について、少し説明します。 buildspecとはCodeBuildで実行する上でのビルド仕様のことです。 buildspec.yaml を作成し、プロジェクトのルート ディレクト リに配置することで、CodeBuildは自動で buildspec.yaml を検知し、定義された内容通りに処理を実行してくれます。 今回の検証で作成したbuildspecファイルは以下の通りになります。 buildspec.yaml version : 0.2 env : parameter-store : DOCKER_USER : dockerhub-user DOCKER_TOKEN : dockerhub-token phases : install : runtime-versions : docker : 19 pre_build : commands : - echo Logging in to Amazon ECR... - aws ecr get-login-password --region ${AWS_DEFAULT_REGION} | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com - echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin build : commands : - echo Build start - echo Building the Docker image... - docker-compose build - docker tag リポジトリ名_next:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${IMAGE_REPO_NAME}:${IMAGE_TAG} post_build : commands : - echo Build completed - echo Pushing the Docker image... - docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${IMAGE_REPO_NAME}:${IMAGE_TAG} 少し省略しますが、各セクションがそれぞれ何をしているか、簡単に説明します。 pre_build : ECRにログイン build : docker-compose でコンテナイメージをビルドし、ワークフローから渡された値でタグ付け post_build : build セクションで作成したコンテナイメージをECRにプッシュ ワークフローの実行 それではワークフローを実行し、ECRプッシュまで実行できているか確認していきましょう！ 今回は リポジトリ ページ上で確認していきます。 テスト用ワークフローを実行 ますはテスト用ワークフローについて確認していきましょう。 mainブランチに対して、PRを作成します。 PRをマージします。 リポジトリ のトップページから、 「Actions」 をクリックします。 Workflowの一覧から、 「Test workflow」 をクリックします。 mainブランチへのPRマージをトリガーにワークフローが実行されていることが確認できます。 赤枠部分(実行中のワークフロー)をクリックします。 実行中のジョブ一覧が表示されるので、赤枠部分(実行中のジョブ)をクリックします。 経過時間やステータスなどを確認できます。 実行中のStep一覧が表示されます。 Stepごとにコマンドやアクションのログを確認できます。 Lintとテストが正常に完了していることが確認できます。 Stepがすべて正常に終了すると、緑色のチェックが入ります。 Dispatch Build Workflow というStepで、ビルド用のワークフローが実行されるトリガーとなる repository_dispatch イベントを送信している為、 Test workflow の実行が終了すると、 Build workflow が自動的に実行されます。 ビルド用ワークフローを実行 続いてビルド用ワークフローについて確認していきましょう。 前述した通り、ビルド用のワークフローはテスト用のワークフローの中で、 repository_dispatch イベントが送信されることをトリガーに実行されます。 処理の確認の流れは先ほどのテスト用ワークフローと同様です。 リポジトリ のトップページから、 「Actions」 をクリックします。 Workflowの一覧から、 「Build workflow」 をクリックします。 repository_dispatch イベントをトリガーにビルド用ワークフローが起動していることが確認できます(Repository dispatch triggered と記載されていますね) 赤枠部分(実行中のワークフロー)をクリックします。 実行中のジョブ一覧が表示されるので、赤枠部分(実行中のジョブ)をクリックします。 実行中のStep一覧が表示されます。 Run CodeBuild のログからCodeBuildが実行されていることが確認できます( GitHub ActionsからCodeBuildのログを確認できます)。 ECRへのプッシュが完了していることが確認できます ECRにプッシュされたコンテナイメージを確認します。 想定通り、タグに ci-sample が設定されたイメージがプッシュされていることを確認できました！ 終わりに 最後までご覧いただきありがとうございます。 今回は GitHub Actionsと AWS サービスを連携したCIパイプラインの構築について、ご紹介しました。 CIパイプラインの整備は開発サイクルの高速化に繋がるので、今後もしっかりと学んでいきたいと思います。 GitHub Actionsでは他にもPR作成やコミットの自動化など、便利な機能がたくさんあるので、今後も記事の発信を継続していきたいです 参考文献 GitHub Docs GitHub Actionsの使い方メモ AWS 公式ドキュメント CodeBuildのビルド仕様に関するリファレンス 　　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」 というプロジェクトがあります。 このプロジェクトで「認証」にまつわる検証を行ったので、その成果を共有しようかと思います。 なお半年前に書いた以下の記事の続きになりますので併せて御覧ください。 tech-blog.rakus.co.jp 認証関連の標準について OpenID Connect (OIDC) FIDO 2.0 認証サーバー（OP）ミドルウェア 現状ではKeycloakが最有力候補 OpenAM, Keycloakの比較 Keycloakの必要スペック サービス（RP）側ライブラリ Java PHP Node.js 注意点 認証アーキテクチャ 現状の課題 検討しているアーキテクチャ構成 顧客側認証サーバーを用いる場合 まとめ 認証関連の標準について 認可 プロトコル のOAuth2.0や、SSOで用いられる SAML などがありますが、 後方互換 性の制約がなくこれから新しく構築するシステムであれば OpenID Connect と FIDO 2.0 の組み合わせで対応することを最優先で検討しましょう。 OpenID Connect (OIDC) 複数の認証関連の標準を組み合わせていた状況から OpenID Connectに標準が集約されています。 NRI社製作の資料より抜粋 FIDO 2.0 いわゆるパスワードレス認証の標準です。 初めてサービスを利用する際にクライアントと鍵情報を登録することで、その後のサービス利用時には 認証結果だけを通信 し、クレデンシャル情報（ID/パスワードとか、指紋パターンとか）は通信せずに済む仕組み。 通信経路にもサーバーにもクレデンシャル情報を保持する必要がないため、万が一通信内容の盗聴や、サーバーデータの流出があった場合にもなりすまされる心配がない。 上図は非エンジニア向けに説明した資料から抜粋しているため「暗号鍵／復号鍵」となっていますが、 SSH の鍵認証などと同様のいわゆる 公開鍵暗号方式 です。 認証サーバー（OP） ミドルウェア 現状ではKeycloakが最有力候補 OpenID Connect, FIDO2.0に対応した認証サーバー ミドルウェア としては OpenAM 2008年、 OpenSSO として米Sun社からリリース 2010年、OpenAMとして米Forgerock社によりfork 2018年、日OpenAMコンソーシアムによりfork Java による実装 Keycloak 2014年、 JBoss コミュニティよりリリース Java による実装 ZITADEL 2020年3月リリース Go言語による実装 Casdoor 2021年8月リリース Go言語による実装 authelia 2020年1月リリース？（3.7.0までしか辿れなかった） Go言語による実装 といったものが現在存在しています。 ただし、このうちZITADEL, Casdoor, autheliaは検証開始当初は新しすぎた（機能も不足していた）ため検証対象としていません。 かなり活発に開発は進んでいるようなので、数年後に再評価するとしたら有力候補になっている可能性があります 1 。 特にZITADELはKeycloakの対抗馬となるべく意識しているようで、OIDC, FIDO2.0への対応はもちろん、マルチテナンシー対応、Identity Brokering機能（後述）など Saas での利用を意識しているようです（ vs Keycloak ）。 OpenAM, Keycloakの比較 検討対象となったのはOpenAM, Keycloakです。 機能的には両者とも充実しています。 OpenAMについては普及度合いや枯れ具合は良かったものの、開発はセキュリティアップデート中心という状況であり、開発母体の規模に不安があったために採用を見送りました。最終リリースも2019年で止まっています。 Keycloakは現状でも活発に機能追加リリースが行われており、 K8s などコンテナ環境での利用も想定された設計になっているようなので将来性も問題ないと判断しています。 Keycloakの必要スペック 実験環境ではそれほど多くのスペックは要求されませんでしたが、環境構築当初 VM のメモリをケチって128MBにしたら起動シーケンスでエラーを吐いて起動できませんでした。その後ちょっと余裕を見て512MBで動作させていましたが、512MBあれば今回の検証内容については全く問題なく動作していました。 Java のアプリケーションはメモリを消費するイメージがありますが、メモリに関しては多めに確保するのが良いかもしれません。 サービス（RP）側ライブラリ OpenID Connect用のライブラリはCertifiedなライブラリやUncertifiedなライブラリが公式で紹介されています。 openid.net openid.net Java Spring Securityを使う場合 spring-boot-starter-oauth2-client Spring Securityを使わない場合（非Spring環境） Nimbus OAuth 2.0 & 2.1 SDK with OpenID Connect extensions Java 用のライブラリはOAuth2.0用のライブラリが拡張されて使われているという経緯から名前がわかりにくいのが難点です。 Spring(Spring Boot含む)を利用している場合は公式ページで紹介されているspring-boot-starter-oauth2-clientを利用しましょう。紹介ページではOAuth2.0での紹介となっていますが、 OpenID Connectにも言及があります。 spring.pleiades.io Springを利用していない場合は Nimbus OAuth 2.0 & 2.1 SDK with OpenID Connect extensions が現在もメンテナンスされているライブラリとなっています。 PHP phpOIDC NRI 社が 総務省 のプロジェクトの一環で作成したライブラリ実装。 OpenID Connect Certifiedなライブラリなので PHP の場合はこちらを使うと良さそうです。 Node.js panva / node-openid-client OpenID Connect Certifiedなライブラリで後述しますが、Keycloakの公式からも言及されている（後述）ライブラリ。 Passport.js と組み合わせて利用します。 個人が中心になって開発している部分に若干の不安はあるもののnode.jsではこちらが最有力。 注意点 実はKeycloakからも各言語用にOIDCアダプターとしてライブラリが提供されています。 しかしこれらは2023年にはおおかたサポート対象から外れる予定なので利用してはいけません。上述のライブラリ群から選ぶのが良いでしょう。 Keycloak release plans for 2023 Deprecation of Keycloak adapters ちなみにNode.js用のライブラリについては2つ目の記事の中で openid-client が優れた代替手段であるように見えます。これはKeycloakが提供するOIDCアダプターよりも豊富な機能を持っています。 と触れられています。 認証 アーキテクチャ 現状の課題 現状はサービスごとに認証の実装、ID管理を行っている 複数サービスを契約してもらうとID管理の負担が増えていく 同じ会社のサービスなのだから一括で管理したいという自然な要求 検討している アーキテクチャ 構成 現状は各サービス内に持っている認証機能を外部のサービスとして切り出すことで認証機能を統一できないか検討しています。構成としてはオーソドックスな外出しですね。 ちなみに便宜上「楽楽認証（仮）」としていますが、新サービスとして提供する予定はありません。 楽楽認証（仮）は先述の通り、Keycloakをベースとしてラップするように管理サービスを用意してあげれば良いと考えています。今回は機能面の検証にフォーカスしていたため、ラップするサービス部分は構築していませんが実運用上はスタッフの操作手順を補助したり、ミスを予防するためにも内部向けのサービスとして構築すると思います。 顧客側認証サーバーを用いる場合 認証機能の外出しについてですが、現状でも一部のサービス（楽楽精算や楽楽販売、メールディーラーなど）では顧客側認証サーバーを利用する構成（いわゆるSSO構成）が可能になっています。 顧客側認証サーバーを使うかどうかは、当然顧客ごとに設定可能になっています。この場合に顧客によって「顧客側認証サーバーで認証処理を行うのか」「楽楽認証（仮）で認証処理を行うのか」という場合分けが必要になります。これに対応するために ラク スサービスから接続する先のサーバーを顧客ごとの設定に持たせることになりそうですが、外部接続先を切り替える実装は自前では行いたくないものです。 そこでIdentity Brokeringという機能が役立ちます。この機能を用いることで「 ラク スサービス→楽楽認証（仮）→顧客認証サーバー」と認証処理をバケツリレーのように更に他の認証サーバーに委託することが可能になります。今回検証していたKeycloakにもIdentity Brokeringが備わっています。 Keycloakではマルチテナンシー機能の中でこのIdentity Brokering設定ができるようなので、顧客ごとに「楽楽認証（仮）」で認証するのか「顧客管理の認証サーバー」で認証するのか設定できそうです。 この機能についてはまだ継続した検証を行っているところなので、またの機会に触れられればと思います。 まとめ OIDC + FIDO 2.0の採用 認証サーバーはKeycloak メモリは最低512MB確保 この記事が書かれたタイミング（2022年3月）から数年後に検討するなら新興ソフトウェア（ZITADELとか）も検討 使用ライブラリは OpenID Connect公式が紹介しているものから選ぶ Keycloakから提供されているものは使わない 認証部分はサービス運用上のクリティカルな部分（コケたらサービスが使えなくなる）なので、シビアに検討を重ねる必要があります 2 。共通認証基盤として利用するなら全サービスに影響が出るためなおさらです。 現状のままサービスごとに独立した管理にしておけば一度にすべてが使えなくなることはありませんが、どうしても利便性で劣ることになります。当然他社でも同じような動きがあると考えられるので、将来的には認証を共 通化 して利便性を上げる必要があると考えています。 その際には同時に多要素認証（MFA）やパスワードレスといった高いセキュリティ機能にも対応できると考えています。 　　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 なぜ近年になってこんなに認証サーバー ミドルウェア のリリースラッシュなのでしょうか？ あとサーバーサイド ミドルウェア のGo言語人気がすごい……。 ↩ Keycloakも クラスタリング に対応しているようですが検証はまだこれから。 ↩

こんにちは。d-t-kong と申します。 最近、趣味で Django を触っているのですが、 Django のライブラリに Django Rest Framework というWebAPIを開発できるライブラリがあることを知りました。 これを使えばWebAPIを簡単に作成できるということなので、実際にサンプルのアプリケーションを 作って API を自作してみました。 今回は、その手順やポイントなどを紹介していきたいと思います。 Django REST Frameworkとは RESTful API とは 事前準備 使用環境 プロジェクト・アプリケーションを作成 モデルを定義 データベースを構築 管理アカウント作成 DRFでAPIを作成 REST Framework をアプリケーションに追加 DRFの主要コンポーネントを作成 1.Serializer 2.ViewSets 3.Router APIにアクセスしてみる 参考文献 ◆ Python 関連ブログ tech-blog.rakus.co.jp Django REST Frameworkとは Django REST Framework(以下、 DRF ) とは、 Django を使って RESTful API を作成するための フレームワーク です。 RESTful API とは RESTful API とは 、 「REST」 という以下の4つの原則に基づいて設計される API のことを指します。 統一インターフェース（HTTPメソッドの利用し、 JSON 形式でデータのやりとりをする） アクセス可能なURLが公開されている ステートレスである 接続結果が HTTPステータスコード で通知されること 事前準備 では、実際に DRF で API を作ってみたいと思います。 しかしその前に、今回使うアプリケーションを実装します。 使用環境 Python3 ：3.10.1 Django ：4.0.2 プロジェクト・アプリケーションを作成 まず、今回 API を作成する用のプロジェクト、アプリケーションを作成します。 プロジェクト名 api_test 、アプリケーション名 drf_test_app という名前で作成します。 django-admin startproject api_test cd api_test/ python3 manage.py drf_test_app モデルを定義 次に、Modelクラスを定義します。 今回はユーザ情報を持った UserInfo モデルをWebAPIテスト用のサンプルとして作成します。 drf_test_app/models.py from unicodedata import category, name from django.db import models # ユーザ情報を格納する class UserInfo (models.Model): user_name = models.CharField(verbose_name= 'ユーザ名' ,max_length= 32 ) # ユーザ名 birth_day = models.DateField(verbose_name= '生年月日' ) # 生年月日 age = models.PositiveSmallIntegerField(verbose_name= '年齢' ,null= True ,unique= False ) # 年齢 created_at = models.DateTimeField(verbose_name= '作成日時' ,auto_now_add= True ) # 登録日時 データベースを構築 Modelを作成したら、データベースを構築します。 まず、 settings.py にアプリケーションを追加します。 api_test/settings.py INSTALLED_APPS = [ 'django.contrib.admin' , 'django.contrib.auth' , 'django.contrib.contenttypes' , 'django.contrib.sessions' , 'django.contrib.messages' , 'django.contrib.staticfiles' , 'drf_test_app' , # 追加する ] アプリケーションを追加したら、以下のコマンドを入力してデータベースをマイグレートします。 % python3 manage.py makemigrations % python3 manage.py migrate マイグレートが完了したら、 admin.py に以下のコードを追記します。 drf_test_app/admin.py from django.contrib import admin from .models import UserInfo # 以下追記 admin.site.register(UserInfo) 管理アカウント作成 次に、管理者用のアカウントを作成します。 以下のコマンドを入力して下さい。 % python3 manage.py createsuperuser Username (leave blank to use 'root'): [管理ユーザ名] Email address: [メールアドレス] Password: [パスワード] Password (agein): [再パスワード] Superuser created successfully. これで Django の管理サイトにアクセスできるはずなので、以下のコマンドから開発サーバーを立ち上げて、 http://localhost:8000/admin にアクセスします。 % python3 manage.py runserver ログイン画面に遷移できたら先ほど作成した管理ユーザのユーザ名・パスワードを入力してログインします。 管理者用サイト　ログイン画面 ログイン後、先ほどマイグレートしたモデルが管理画面上に追加されていればOKです。 管理者用画面 DRF で API を作成 アプリケーションの準備が終わったので、ここからは実際に API を作っていきます。 REST Framework をアプリケーションに追加 まず、pip コマンドで DRF をインストールします。 % pip install djangorestframework インストール後、 settings.py のINSTALLED_APPSにアプリケーションを追加します。 INSTALLED_APPS = [ ・・・ 'rest_framework' , # 追記 ] DRF の主要 コンポーネント を作成 DRF で API を作成する際、以下の3つの コンポーネント を定義する必要があります。 Serializer ViewSets Router 1.Serializer Serializer クラスは、データベースから取り出したモデルのオブジェクトを JSON に serialize したり、ユーザから送られた JSON を deserialize するためのクラスです。 drf_test_app/serializer.py を新規に作成し、以下を記述します。 drf_test_app/serializer.py from dataclasses import fields from pyexpat import model from rest_framework import serializers from .models import UserInfo class UserInfoSerializer (serializers.ModelSerializer): class Meta : model = UserInfo # json で出力するフィールド fields = ( 'id' , 'user_name' , 'birth_day' , 'age' , 'created_at' ) 2.ViewSets Serializerクラスを定義して、 serialize や deserialize ができるようになったら、次は Viewクラスを定義します。 DRF ではいくつかViewSetクラスが存在します。 今回は rest_framework.viewsets.ModelViewSet を継承したクラスを作成します。 ModelViewSet クラスはモデルに対して CRUD 処理(新規追加、読み込み、更新、削除)を一括で作成 できるクラスです。 なお、 ModelViewSet 以外には CRUD 機能のうち、特定の機能のみを提供する GenericView などがあります。 参考： Django REST framework 公式ドキュメント #ModelViewSet ちなみに、 ModelViewSet クラスを用いて API を作成した場合の CRUD 機能、HTTPメソッド、URLは以下の通りとなります。 CRUD 機能 HTTP メソッド URL Read(全レコード) GET / api /userInfo Create POST / api /userInfo Read（単一レコード） GET / api /userInfo/(pk) Update（一部レコード） PUT / api /userInfo/(pk) UPDATE（全レコード） PATCH / api /userInfo/(pk) DELETE GET / api /userInfo/(pk) ※ pk = Primary Key です。モデルで定義していない場合も自動で付与されます drf_test_app/views.py に以下の記述を追加します。 drf_test_app/views.py from rest_framework import viewsets from .models import UserInfo from .serializer import UserInfoSerializer class UserInfoViewSet (viewsets.ModelViewSet): # モデルのオブジェクトを取得 queryset = UserInfo.objects.all() # シリアライザーを取得 serializer_class = UserInfoSerializer 3.Router DRF では API へのルーティングを行うためのRouterクラスを実装する必要があります。 urls.py に Router クラスを インスタンス 化し、ViewSets オブジェクトをルーティングします。 api_test/urls.py from django.contrib import admin from django.urls import path,include from rest_framework import routers from drf_test_app.api_views import UserInfoViewSet # DefaultRouter クラスのインスタンスを代入 defaultRouter = routers.DefaultRouter() # userInfo/ にUserInfoViewSetをルーティングする defaultRouter.register( 'userInfo' ,UserInfoViewSet) urlpatterns = [ path( 'admin/' ,admin.site.urls), # defaultRouter をinclude する path( 'api/' ,include(defaultRouter.urls)), ] API にアクセスしてみる コンポーネント の作成が完了したら、 API にアクセスしてみましょう。 manage.py runserver でサーバーを立ち上げ、 http://localhost:8000/api/userInfo にアクセスします。 以下のような画面に遷移できればルーティング成功です。 http://localhost:8000/api/userInfo API コンソール画面 DRF では JSON のレスポンスをブラウザ用にページで閲覧でき、 GUI で各種 API の動作確認ができます。 試しに、画面下部のリク エス トフォームから API にPOSTリク エス トを送り、レコード登録を試みます。 http://localhost:8000/api/userInfo リク エス トフォーム リク エス トを送信すると、 API からのHTTPレスポンスがコンソール画面に表示されます。 http://localhost:8000/api/userInfo POST メソッドのレスポンス また、 http://localhost:8000/api/userInfo/(pk)/ にアクセスすると、pk に マッピング したレコード一件のみの情報を表示する画面に遷移できます。 また、この画面では右上の DELETE ボタン、PUT、PATCHボタンが配置されているので、レコードの更新、削除を行うことができます。 http://localhost:8000/api/userInfo/2/ 単一レコードの参照 参考文献 最後に、今回の記事を書く上で参考にした文献を紹介します。 REST APIとは？ざっくりと理解してみる【初心者向け】 芝田 将(2021).『実践 Django Python による本格Webアプリケーション開発 』.株式会社 翔泳社 Django REST framework 公式ドキュメント ご覧いただき、誠にありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

Y-Kanoh です。 普段は PHP による開発を行っています。 今回は、PHPer のための学習コミュニティとして毎月開催している、 『 PHP TechCafe』について2021年度開催した12イベント をまとめました！ なお、4/22(金)開催の『PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe』は まだまだ参加者を募集しています。 ぜひこの機会に、ご参加ください。 👉 PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe」PHPTechCafe 参加申込は以下フォームよりお願いします！ forms.gle 【 目次 】 PHP TechCafeとは 2021年度開催イベント 4月『PHP標準コーディングルール（PSR）について語り合う』 5月『PHPDoc について語り合う』 6月『PHPUnit について語り合う』 7月『PHPerの今とその先を語り合うフォーラム2021』 8月『PHP8.1 の新機能について語り合う』 9月『PHPUnit の始め方について語りあう』 10月『Laravel 入門を語り合う』 11月『PHP カンファレンス 2021を振り返る』 12月『【PHP8.1リリース記念】PHPerのためのPHP8.1をもっと語り合う』 1月『2021年のPHP/Laravel振り返り＋2022年を語る』 2月『Xdebugの活用方法を語る』 3月『Laravel 9 について語る』　※3/30(水)開催！ ４月『PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe』　※4/22(金)開催！ 最後に PHP TechCafeとは 「Web × PHP TechCafe」は、 PHP を軸として、エンジニア同士の学びの場を作り、 エキスパートまでの自己成長を支援することを目的としたコミュニティであり、 Web や PHP に関わる IT エンジニアが スキルアップ のために LT や情報共有を行っています。 以前は、弊社オフィスに来社いただき、特定のテーマについてディスカッションや、もくもく自習などを行っていましたが、 現在は月一でオンラインでのイベントを開催させていただいています。 主に、 PHP へ入門後の初級エンジニア ～ シニアエンジニア を対象としていますが、 学びの場を一緒に支援していただけるエキスパート以上の方 も大歓迎です！！ ※入門者向けのスクール系領域の方は対象外とさせていただいています。 2021年度開催イベント 4月『 PHP 標準コーディングルール（PSR）について語り合う』 rakus.connpass.com ◆ 内容まとめ ・ PSR とは？ 　・ PHP 標準コーディング 規約 「勧告」のこと 　・採用するときは、100%準拠する必要はない 　・“ PHP Standard Recommendation” の略 　・ PHP -FIG（Framework Interoperability Group）によって策定されている ・ PHP -FIG とは？ 　・PSRの作成を行っている、 PHP の フレームワーク やツールなどのプロジェクト開発者によって構成されている組織 　・ PHP -FIG の目的 　・ PHP -FIG のメンバー ・PSR の策定プロセス 　・登場人物 　・プロセス 　　・Pre-Draft 　　・Draft 　　・Review 　　・Accepted 　　・Deprecated 　　・Abandoned ・どのようなことが書いてあるの？ 　・カテゴリー 　　・オートローディング 　　・インタフェース 　　・HTTP 　　・コーディングスタイル 　・PSR-1 　　・ 1. Basic Coding Standard 　・PSR-12, PSR-2 　　・ 12. Extended Coding Style Guide 　・PSR-8 　　・ 8. Huggable Interface 　・ClockInterface ・PSRの活用状況は？ 　・利用している OSS 　　・Laravel 　　・ Symfony 　　・ CakePHP ・PSRの導入を助けるあれこれ 　・ PHP _CodeSniffer 　・Composer 　・ Packagist 詳細は、以下 ShowNote をご確認ください！ 【ShowNote】 hackmd.io 5月『PHPDoc について語り合う』 rakus.connpass.com ◆ 内容まとめ ・PHPers News 　・ Microsoft、IE（Internet Explorer）サポート終了は2022年6月15日 　・ Google Cloud FunctionsがPHPをサポート開始。PHPでサーバレスの関数が記述可能に などなど ・PHPDoc 　・参考資料 tech-blog.rakus.co.jp 　・PHPDocとは？ 　・活用例 　・記述ルール ・代表的な書き方 　・基本的なタグ 　　・@param：関数またはメソッドの引数について記述 　　・@return：返り値について記述 　　・@throws：例外について記述 　　・@var：変数について記述 　　・@todo：開発でやるべきことがあることを示す 　・型の記述 　　・ リテラル 型 　　・配列型 　 ・その他の書き方 　　・false型 　　・property 　　・ローカル変数の型指定 詳細は、以下 ShowNote をご確認ください！ 【ShowNote】 hackmd.io 6月『 PHPUnit について語り合う』 rakus.connpass.com ◆ 内容まとめ ・PHPers News 　・ IE11がついに2022年6月15日で終了へ　日本でのシェアは？ 　・ Laravel is 10 years old! 　・ PHPカンファレンス沖縄2021【参加レポート】 などなど ・ PHPUnit 　・参考資料 tech-blog.rakus.co.jp 　・テストとは 　・Unit テストとは 　・ PHPUnit とは 　　・ PHP プログラムとして作成可能な ユニットテスト 　　・ PHPUnit マニュアル ・実際にはどう使っている？ 　・参考書籍などの紹介 　　・TDD 　　　・ テスト駆動開発 　　　・TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング ・ PHPUnit アサーション メソッド 　・ アサーション メソッドと アノテーション を組み合わせることでテスト対象のクラスや関数が期待通りに動作しているかを確認 ・ アサーション メソッド 　・ assertEquals 　・ assertSame 　・ assertTrue , assertFalse , assertNull 　・ assertCount 　・ assertStringStartsWith , assertStringEndsWith , ssertStringContainsString 　・ assertRegExp 　・ assertIsXXX , assertInstanceOf 詳細は、以下 ShowNote をご確認ください！ 【ShowNote】 hackmd.io 7月『PHPerの今とその先を語り合うフォーラム2021』 rakus.connpass.com ◆ 内容まとめ 以下イベントレポートをご確認ください！ tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 8月『PHP8.1 の新機能について語り合う』 rakus.connpass.com ◆ 内容まとめ 以下イベントレポートをご確認ください！ tech-blog.rakus.co.jp tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 9月『 PHPUnit の始め方について語りあう』 rakus.connpass.com ◆ 内容まとめ 以下イベントレポートをご確認ください！ tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 10月『Laravel 入門を語り合う』 rakus.connpass.com ◆ 内容まとめ 以下イベントレポートをご確認ください！ tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 11月『 PHP カンファレンス 2021を振り返る』 PHPerのための「PHP カンファレンス 2021を振り返る」PHP TechCafe - connpass ◆ 内容まとめ ・PHPers NEWS 　・ A look at what is coming to Laravel 9 　・ Larastan v1 リリース などなど ・ PHPカンファレンス 公式サイト phpcon.php.gr.jp 　・ タイムテーブル 　・発表一覧 　　・これでリリースも怖くない！フィーチャートグルを導入入門 　　・ PHP でWeb Driver Clientを自作する〜己の手でブラウザ操作自動化を完全理解する方法〜 　　・カンファレンスはフィードバックが大事 　　・【超特急】「 SQL アンチパターン 」 総おさらいLT 【4分で25個】 などなど ・参考資料 tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 12月『【PHP8.1リリース記念】PHPerのためのPHP8.1をもっと語り合う』 rakus.connpass.com ◆ 内容まとめ 以下イベントレポートをご確認ください！ tech-blog.rakus.co.jp 当日の ShowNote はこちら 【ShowNote】 hackmd.io 1月『2021年の PHP /Laravel振り返り＋2022年を語る』 rakus.connpass.com 当日は、2021年度に開催したTechCafeを振り返りました。 詳細は、当日の ShowNote をご確認ください！ 【ShowNote】 hackmd.io 2月『 Xdebug の活用方法を語る』 rakus.connpass.com ◆ 内容まとめ ・PHPer’s NEWS!! 　・ 2021 アドベントカレンダー Laravel 　・ PHP: PHP 8.1.0 Release Announcement などなど ・特集「 Xdebug の活用方法」を語る 　・そもそも デバッグ ツールって何？ 　　・de(除去) - bug(不具合） のためのツール 　　・多くの デバッグ ツールは基本機能として以下を備えている 　　・ デバッグ ツールがないと調査がとても大変。すごく大変。 　・ Xdebug の概要 　　・ Xdebug は、 PHP で デバッグ を行う上で便利な機能を提供する 拡張機能 　　・多機能で、基本的な デバッグ ツールとしての機能だけでなく、様々な機能を持つ 　 　・導入方法 　・Step Debugging 　　・ステップ デバッグ とは、任意の行で処理を止めながら行う デバッグ のこと 　　・ デバッグ 方法　（PhpStorm） 　　・ スタックトレース の追加 　・Tracing xdebug.org 　・Profiling xdebug.org 　・Code Coverage Analysis xdebug.org 当日の ShowNote はこちら 【ShowNote】 hackmd.io 3月『Laravel 9 について語る』　※3/30(水)開催！ rakus.connpass.com 3/30(水)19時～、2021年度最後のPHPTechCafeを開催します！ 私を含む5名の方と、Laravel 9 について語り合います。 また、今回LT枠は3枠満員となっており、以下発表テーマを予定しています。 発表テーマ 発表者 1 Laravel8ユーザーから見たLaravel9の推し機能 shiba さん 2 なぜLaravel9はLTSではないのか KenjiroKubota さん 3 考え中 Suguru Ohki(スー) さん オンラインにて開催していますので、ラジオ感覚で聞いていただいて問題ありません！！ 途中入退出も大歓迎です。 ご参加の皆さまと交流ができるのを楽しみにしています！ ４月『PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe』　※4/22(金)開催！ 4/22(金)に『PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe』を開催します！ まだまだ参加者を募集しています。 ぜひこの機会に、ご参加ください。 rakus.connpass.com 参加申込は以下フォームよりお願いします！ forms.gle 最後に 最初に触れた通り、 PHP TechCafe は PHP 入門後の初級エンジニアを対象にし、エンジニアの自己成長を支援することが目的です。 このように今年度開催したイベントをまとめると、私にとっても PHP TechCafe が情報源になっていることを実感しました。 このコミュニティを通して、イベント開催のための下調べや、参加いただいた方からの情報が自分の知識になっており、とてもありがたく感じます。 PHP TechCafe は来年度も月一で開催予定です！！ ぜひ、我々と一緒に知識を深め、 PHP を盛り上げていきましょう！！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております。 ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして。d-t-kong です。第二開発部・楽楽販売開発課に所属しております。 今回は Python のWeb アプリ開発 用の フレームワーク である Django の環境構築から、テンプレートを表示するまでの手順をまとめましたので、ご紹介させていただきます。 今回は以下のセクションで説明します。 Django の特徴 環境構築 Django をインストール Django プロジェクト作成 開発用サーバーを立ち上げる データベースをセットアップする Django でアプリケーションを作る 新規アプリケーションを作成 ルーティングを設定 view関数を定義 テンプレートを作成 最後に Django の特徴 Django は Python のWebアプリケーション開発用 フレームワーク です。 Django の特徴として主に以下が挙げられます。 以下の機能が標準搭載 Django 管理サイト ユーザ認証 セッション管理 キャッシュシステム ページング データの シリアライズ Python の豊富なライブラリを利用できる MTV パターンを採用 環境構築 では、早速 Django の環境構築を進めていきます。 はじめに、今回の記事で使用する実行環境は以下となります。 OS環境： macOS Monterey 12.3 Python ：3.10.1 Django ：4.0.2 本節は以下の手順で準備を進めます。 Django をインストール Django プロジェクトを作成 開発サーバを立ち上げる データベースのセットアップ Django をインストール まず、pip コマンドを使って Django をインストールします。 % pip install django Django プロジェクト作成 Django をインストールできたら、まず Django プロジェクトを準備します。 Django をインストールすると、 django -admin というコマンドを使用することができるようになります。 この コマンドを使って新規プロジェクトを作成することができます。 今回は helloWorldProject という名前のプロジェクトを作成します。 % django-admin startproject helloWorldProject コマンドを実行することで生成された ディレクト リは以下のようになります。 . ┣ hello_world_project ┃ ┠─ __init__.py ┃ ┠─ asgi.py ┃ ┠─ settings.py ┃ ┠─ urls.py ┃ ┗─ wsgi.py ┗━━━ manage.py 各ファイルの役割は以下のようになります。 __init__.py：[プロジェクト名]フォルダが Python のパッケージであることを証明する。中身派から。 setting.py： Django プロジェクトの様々な設定を記述する。 manage.py： django-admin コマンドを使用する際のショートカット スクリプト 。開発サーバの立ち上げ、 マイグレーション などに使う。 urls.py：ルーティングについて記述する。 asgi.py、 wsgi .py：非同期処理の実装などで使うファイル。 開発用サーバーを立ち上げる プロジェクトが作成できたら開発用サーバを立ち上げてみましょう。 以下のコマンドを実行するとサーバーを起動することができます。 % python3 manage.py runserver コマンドを実行したら、 http://127.0.0.1:8000/ よりトップページにアクセスできます。 以下のトップページにアクセスできたら立ち上げ成功です。 Django のトップページの表示 データベースをセットアップする 次は、データベースの設定を行います。 まず、データベースの設定を setting.py の以下の部分で確認してみます。 DATABASES = { 'default' : { 'ENGINE' : 'django.db.backends.sqlite3' , 'NAME' : BASE_DIR / 'db.sqlite3' , } } ENGINE は、使用するデータベースのエンジンを指定します。 Django のデフォルトは、sqlite3 が指定されています。 NAME は、参照するファイルを指定します。 では、実際にデータベースを用意します。 Django ではデータベースの作成や変更を加える際に、 マイグレーション という機能を利用します。 Django ではデータベースの定義にどのような変更があったのかを表す マイグレーション ファイルを生成します。 セッション管理やユーザ管理といった機能を提供するため、いくつかのモデル定義と マイグレーション ファイルがデフォルトで存在します。 manage.py migrate コマンドを実行することで、これらの マイグレーション ファイルをデータベースに反映させる事ができます。 % python3 manage.py migrate Django でアプリケーションを作る ここまでで、 Django でアプリケーションを作るまでの下準備が整いました。 今回は試しに、 Hello World と表示するアプリケーションを作成します。 本節は以下の手順で進めていきます。 新規アプリケーションを作成 ルーティング設定 view 関数を定義 テンプレートを設定 新規アプリケーションを作成 Django では、Webサイトの機能を アプリケーション（apps） ごとに分割します。 デフォルトで設定されているアプリケーションは settings.py で確認することができます。 hello_world_project/settings.py INSTALLED_APPS = [ 'django.contrib.admin' , 　 # 管理画面機能を持つアプリケーション 'django.contrib.auth' , # 認証機能をもつアプリケーション 'django.contrib.contenttypes' , # Content-Type に関する機能をもつアプリケーション 'django.contrib.sessions' , # セッション管理の機能を持つアプリケーション 'django.contrib.messages' , # フラッシュメッセージ のためのアプリケーション 'django.contrib.staticfiles' , # 静的ファイル（CSS や JavaScript）に関係する機能を持つアプリケーション ] このように、 INSTALLED_APPS の中には既にいくつかアプリケーションが登録されています。 Django に標準で提供されている認証機能や管理者機能などもここで定義されています。 新規にアプリケーションを作る場合は、以下のコマンドを実行します。 今回はサンプルとして helloworldapp という名前のアプリケーションを作成します。 % python3 manage.py startapp helloWorldApp このコマンドを実行すると helloWorldApp アプリケーションが作成されます。 プロジェクトファイルは以下のような構成になります。 . ┣ helloWorldProject ┃ ┠─ (略) ┣━━━ manage.py ┗━━━ helloWorldApp ┠─ __init__.py ┠─ admin.py　　// 管理画面の設定を記述 ┠─ apps.py　　 // アプリケーションの様々な状態にフックする処理を記述 ┠─ migrations/ // マイグレーションファイルを作成 ┠─ models.py // データベースのスキーマを定義 ┠─ tests.py　　// テストを記述 ┗─ views.py　 // ビューを記述 追加することで、アプリケーションとして使用することができます。 helloWorldProject.settings.py INSTALLED_APPS = [ 　　　　・ 　　　　・ 　　　　・ 　 # 追記 　’hellowWorldApp’ ] ルーティングを設定 次に、画面にアクセスするためのルーティングを設定します。 まず、 hello_world_project/urls.py を編集します。 helloWorldApp/urls.py from django.contrib import admin from django.urls import path,include urlpatterns = [ # ルーティングを追加 path( '' ,include( 'hello_world.urls' )), path( 'admin/' , admin.site.urls), ] 次に、 hello_world/urls.py を新規に作成し、 localhost:8000/hello_world/ にアクセス時に後ほど定義する helloWorldApp/views.py のindex() 関数を呼び出すように設定します。 view関数を定義 helloWorldApp/views.py に index() 関数を以下のように定義します。 helloWorldApp/views.py from django.shortcuts import render # 以下を追加 def index (request): return render(request, 'hello_world/index.html' ) index() 関数が呼び出されたら、 templates/index.html を参照するように設定しています。 これは render () 関数の第二引数にテンプレート(htmlファイル)を指定する場合、デフォルトでは templates ディレクト リを参照するように設定されているからです。 しかし、アプリケーション作成時に templates ディレクト リは作成されていなかったので、新規に作成する必要があります。 テンプレートを作成 次に、テンプレートを作成します。 ここでは、 views.py で呼び出すテンプレートファイルを作成します。 まず、 helloWorldApp/ 配下に templates ディレクト リを新規作成し、その配下に hello_world ディレクト リを作成します。 hello_world ディレクト リ配下に index.html を新規作成し、以下の記述を追記します。 helloWorldApp/templates/hello_world/index.html < html lang = "ja" > < head > < meta charset = "utf-8" > < title > Hello World </ title > </ head > < body > < h1 > Hello World </ h1 > </ body > </ html > 最後に、 % python3 manage.py runserver で開発用サーバを立ち上げ、 http://localhost:8000/hello_world にアクセスします。 テンプレートで指定した画面が表示できていれば成功です！ 最後に 最後までご覧いただきありがとうございます。 今回は Django の環境構築から基本的な画面の表示方法までをご紹介しました。 個人的に、今までの経験からMTCパターンのほうが馴染み深かったので、 Django の MTV パターンに慣れるまでに時間がかかりました。 今回は環境構築など初歩的な内容のものをお届けしましたが、 Django には管理サイト機能やユーザ認証機能など便利な機能がたくさんあるので、機会を見つけて Django に関する記事をまた発信していきたいです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

弊社で毎月開催している PHP エンジニアのための勉強会『 PHP TechCafe』。 2021年12月に開催された PHP Tech Cafeでは、 「PHPerのためのPHP8.1をもっと語り合う」をテーマ にして語り合いました。 今回はその内容について@neroblubrosがレポートします！ rakus.connpass.com PHP TechCafeとは PHP8.1の機能について語り合う Enumerations Readonly Properties First-class Callable Syntax version_compare Never return type Explicit Octal numeral notation 非推奨となる機能 編集後記 PHP TechCafeとは 本題に入る前に「 PHP TechCafe」について軽く説明します。 「 PHP TechCafe」とは弊社が主催しているエンジニア向けのイベントで、 エンジニアと技術が交差する憩いの場(カフェ)です。 月に1回開催し、コロナ禍の現在はオンラインで開催しています。 対象者は PHP 入門の初級エンジニアからシニアエンジニアを幅広くカバーし、 学びの場を提供してエキスパートまでの自己成長を支援することを目的にしています。 「 PHP TechCafe」は以下の3部構成です（日によって変わることもあります）。 ライトニング トーク (LT) PHPer's NEWS 特集 2021年12月は前述の通り「PHPerのためのPHP8.1をもっと語り合う」をテーマに開催いたしました。 その中でも特集の「PHP8.1の機能について」語り合った内容のポイントや盛り上がったテーマを中心にレポートします！ PHP8.1の機能について語り合う 今回は公式サイトのPHP8.1リリース情報を見ながら語り合いました。 www.php.net Enumerations まずは PHP 8.1の目玉機能である Enum です。 <?php // PHP < 8.1 class Status { const DRAFT = 'draft' ; const PUBLISHED = 'published' ; const ARCHIVED = 'archived' ; } function acceptStatus ( string $ status ) { ... } //PHP 8.1 enum Status { case Draft; case Published; case Archived; } function acceptStatus ( Status $ status ) { ... } 「 PHP TechCafe」では過去に何度も話題になっている機能ですが、改めて次のような意見が挙がりました。 昔はこうしていたんだよという対比が面白いですね。 Java の Enum の亜種みたいな感じですね。 Readonly Properties 一度だけ値を代入できるという機能です。 弊社は ベトナム でオフショア開発をしているため、弊社のメンバーからは次のような意見があがりました。 「ロケーションの違いやコミュニケーションロスにより、設計の意図を超えた実装になってしまうことがあります。そういうときに言語仕様で制限をかけるというのは有効だと思うので、このような仕組みはどんどん取り入れていきたいです。」 また、 「PropertyがPublicになり、かつ変更できないのが利点であり、いちいちgetterを定義しなくても良いし、書き換えられる不安もなく安心できる。コードの量が減るので可読性が上がる。」 とのメリットを社外の方からご説明いただきました。 First-class Callable Syntax もともと無名関数を書いてその中で呼出とリターンを行っていたものが、この機能を使うことでコードをすっきりさせられます。 <?php // PHP < 8.1 $ foo = [ $ this , 'foo' ] ; $ fn = Closure :: fromCallable ( 'strlen' ) ; // PHP 8.1 $ foo = $ this -> foo ( ... ) ; $ fn = strlen ( ... ) ; 以下のような意見が出ました。 コードがすっきりさせられるけど慣れるまで時間がかかりそう ... と ...$ の違いを理解しておかないと混乱する 部分的には似ているけど全然違う構文っていうのがわかりにくい version_compare 文字通りバージョンの比較をするときに使う構文です。 例えば、 1.0.0 と 1.1.0 の比較をするときに、ドットで分割して数値に置き換えて比較する必要がなくなります。 <?php if ( version_compare ( $ version , '14.3.1' ) >= 0 ) { //14.3.1以上の処理 } else { //14.3.1未満の処理 } 参加者からは「ニーズがあるのか？」という疑問の声が挙がりましたが、 ライブラリを提供しているときや API のクライアントの比較をするときに使っているそうです。 Never return type 「呼び出し元に返らない」ことを明示的に記載できるようになった機能です。 exit やリダイレクトなどで呼び出し元に戻ることがないことを示します。 <?php function redirect () : never { //リダイレクト処理 exit ; } 参加者から「関数を呼び出した後に処理があり、そのコードが実行されると思っていたら、 先に呼び出している関数から処理が返ってこなかった、という経験があるので、 そういうときに never と記載されていると助かる。」という意見が挙がりました。 Explicit Octal numeral notation 8進数の記載方法の変更です。 8進数はいままでは 016 と記載していましたが、 0o16 と書くようになりました。 桁をそろえるためにあえて「0」を記載していたと思って、 削除したら実は8進数でしたということで、エラーになるという不慮の事故を防止するためです。 非推奨となる機能 次の機能が非推奨になります。 日の出・日の入関数の date_sunrise() 、 date_sunset() オブジェクトに対して key() 、 current() 、 next() 、 prev() 、 reset() を呼び出すこと 「今は非推奨だけれども、そのうち使えなくなるので今のうちに消しておく意図だろう。」 という結論になりました。 また、 php .iniの設定で $_GET 、 $_POST 、 $_COOKIE 、 $_REQUEST 、 $_SERVER のデータをフィルタリングすることができていましたが、デフォルト設定である unsafe_raw 以外は全て非推奨となる予定です。 「 php .iniの設定で処理を行うと一見すると便利に見えるけれど、プログラムではなく暗黙的に値を書き換えることになるので、後でコードを読んでも設定箇所がわからず、調査が難しくなる。」 という議論が交わされました。 余談ですが、 「 php .iniの設定で href のリンクに対して PHPSESSIONID を付与することができ、それは ガラケー 向けサイトを作るときに便利でした。」 という紹介がされ、一同「なるほど～」という声が挙がりました。 また、精度が落ちるfloatからintへの暗黙の変換も非推奨となります。 <?php $ a = [] ; $ a [ 15.5 ] //非推奨 $ a [ 15.0 ] //これは15となるのでOK 非推奨となるのは良いけれど、 15.0 は 15 とみなされOKになるのは「ツラい」という意見が挙がりました。 挙げればキリがないのでレポートは以上といたしますが、 外部の方から有益な情報をご提供いただき、今回も有意義なTech Cafeとなりました。 以下レポートの編集後記です。 編集後記 前述の通り外部のエンジニアの方も参加され、社内では知り得ない詳しい情報を得ることで理解が深めることができました。 また、どんなことでもぱっと経緯や実例を挙げて説明いただいたので、その引き出しの多さや瞬発力の凄さに感服いたしました。 また、当該レポートとは別に以前のTech Cafeの関連記事を載せておきますので、 合わせて読んでみてください。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 「 PHP TechCafe」では今後も PHP に関する様々なテーマのイベントを企画していきます。 皆さまのご参加をお待ちしております。 connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

PHP は動的型付け言語に分類されます。 私たちは型を意識することなくプログラミングができます。 要するに PHP 側でいい感じに型変換してくれるので好き勝手できます。 ただ、その暗黙の型変換が呼び起こすデメリットも存在します。 一例を挙げるなら想定外のバグが起こる可能性があるということでしょうか。 想定しない形で関数に値が渡ってしまったり、条件式が想定通りいかなかったり。 型を意識しないというのは保守性・コードの可読性といった場面でも悪影響を及ぼします。 特に複数人で開発している場合は引数の型からも製作者の意図が読めたりします。 過去のコードに今から全部型宣言をしようと言っているわけではありません。 もちろんしている方が好ましいとは思います。 ただ新規でコードを書くときは少し意識して書いてみるのもいかがでしょうかといったところです。 ということで、 本記事では PHP の関数の型宣言について書いていきたいと思います。 はじめに 関数の型宣言 基本の型 よくある型 クラス/インターフェイス名 self parent callable iterable object mixed Null を許容する型宣言 union型 交差型 戻り値のみで使用できる型 void never static おわりに はじめに そもそも PHP で関数書くときはどういった書き方をするでしょうか？ 単純な足し算をする関数を例に見てみましょう。 <?php public function add ( $ a , $ b ) { return $ a + $ b ; } 大体こんな感じでしょうか。 私は最初に PHP の勉強を始めた時、情報が少なすぎて不安になった記憶があります。 例えばですが Java だとこうなります。 public int add( int a, int b) { return a + b } ここで違いを見ていくと、 PHP の方には引数と返り値の型が書いていないことがわかります。 ですので、 PHP のadd関数は整数を渡しても少数を渡しても文字列を渡しても動きます。 結果はさておきとして。 Java の方はint以外はエラーになります。 なぜなら、intで型の指定をしているからです。 この二つを比べて PHP の方が良くないと言いたいわけではありません。 私が言いたいのは、 この関数の引数にどういった値が渡ってきて、どういう結果を返すのか考慮できていますか？ ということです。 それが考慮ができているというのであれば問題はありません。 ただ完璧に考慮できているというなら、もう PHP でも型宣言しちゃえばいいよねという話です。 それでエラーになるというなら考慮パターンが漏れているということなので。 関数の型宣言 ここでは PHP で関数を書くときにどのように型宣言できるか見ていきます。 先程の足し算をする関数を Java の方と同じ形で書くとこうなります。 <?php public function add ( int $ a , int $ b ) : int { return $ a + $ b ; } 引数の型宣言は Java と同じです。 ちょっと違うのは返り値を書く位置です。 個人的には Java やCなどより見やすいと思っているので好きです。 このように書くと、 Java と同じように引数と返り値の型をチェックしてくれてエラーを出してくれます。 と・・・言いたいところなのですがこれが微妙に違います。 このままだと返り値の型が正しくなくても自動的に型変換して返してしまいます。 もちろん引数でも同じことが起こります。 じゃあ意味無いじゃないかと言いたいところですが、ちゃんとエラーにしてくれる設定が PHP には用意されています。 <?php declare ( strict_type = 1 ) このように呼び出し側のファイルにも定義側のファイルにも宣言するとエラーにしてくれます。 片方だけにするとデフォルトの緩い型チェックが優先されるので注意しましょう。 基本の型 そもそも PHP の型は皆さん何があるかご存知でしょうか？ 実際全く知らなくてもコードは書けるので知らない方もいらっしゃるかも知れません。 ここではざっくりとどんな型があるのか見ていきます。 結構たくさん種類がありますが、最初はよくある型とクラス/ インターフェイス 名、mixed辺りを活用していければいいんじゃないかと思います。 ※ここで紹介する以外にもresorceや Enum なども宣言に使えます。 よくある型 array bool float int string これらは大体どんな言語にもある型なので、説明省略します。 クラス/ インターフェイス 名 Java などと同じようにクラス名、 インターフェイス 名も宣言できます。 値はクラス、 インターフェイス の インスタンス でなければいけません。 self クラスの内部でのみ使え、型宣言が行われたクラスと同じクラスの インスタンス でなければいけません。 よくthisと混同されるやつです。これも型宣言に使えます。 parent 型宣言が行われたクラスの親クラスの インスタンス でなければいけません。 オブジェクト指向 と言いますか継承をきちんと使ってクラス設計しているとそれなりに出てきます。 callable コールバック関数であることを示します。 PHP ではcall_user_func()等を使用することでユーザ定義のコールバック関数をコールできます。 iterable 配列かTraversable インターフェイス (クラスの中身が foreach を使用してたどれるかどうかを検出する)を実装したオブジェクトでなければいけません。 簡単にいうとforeachで繰り返し可能な値ならOKという型です。 ※ PHP 7.1.0 以降 object objectでなければなりません。 new命令を使用して作ったものということです。 ※ PHP 7.2.0 以降 mixed あらゆる型を許容します。 なんでも屋 さんです。 厳密にはobject,resource,array,string,int,float,bool,nullのいずれかということになっています。 ※ PHP 8.0.0 以降 Null を許容する型宣言 ここまで PHP で使用できる型をざっと見てきました。 じゃあこれからは型の宣言をしていこうねといきたいのですが、 PHP で開発をしたことのある人ならこれどうしようとなるケースがあると思います。 この関数基本はある型の値が引数として来るんだけど、たまにnullも来るみたいなケースです。 PHP では往々にして考えられるケースです。 そんな時はこのような書き方でカバーできます。 <?php public function add10 ( ? int $ a ) : ? int { if ( is_null ( $ a )) { return null ; } return $ a + 10 ; } 型の前に ? をつけることでnullかその型というような宣言ができます。 これは返り値でも同じように使うことができます。 例の場合だと引数はnullかintを許容。返り値もnullかintを許容という定義になります。 ※ PHP 7.1.0 以降 union型 先程nullを許容する型宣言のやり方がありましたが、いやいや私はnullじゃなくてintかfloatを引数で受け取りたいんだよ。みたいなことも場合によってはあるでしょう。 そういった場合は | を使用して、int|floatのように書くことができます。 先程のnull許容型はint|nullなどの省略形と言えます。 他にもmixedはobject|resource|array|string|int|float|bool|nullということになります。 このunion型を使用するとエラーになるたびに、これをつなげていって許容する型を増やしていくみたいなことが可能ではあるのですが、あまりに多くなる場合は関数そのものを見直した方がいいかも知れません。 ※ PHP 8.0.0 以降 交差型 交差型を使用すると、クラスやインタフェースとして宣言された型を複数同時に許容できます。 型1&型2のように & を使って宣言します。 ※ PHP 8.1.0 以降 戻り値のみで使用できる型 void 関数が値を返さないことを示す型です。 これは Java とかにもあるやつです。 明示的に書いてあげるだけでも他人が見たときにとても見やすいコードになると思います。 ※ PHP 7.1.0 以降 never 関数が戻ってこないことを示す戻り値の型です。 関数の中で exit() がコールされるか、 例外がスローされるか、 無限ループに入るかのいずれかであることを意味します。 ここに来たらプログラム終了するということを基本的には示しています。 ※ PHP 8.1.0 以降 static 値が、メソッドが呼び出されているクラスと同じ インスタンス でないといけません。 selfと混同しないように気をつけましょう。 ※ PHP 8.0.0 以降 おわりに PHP にもこれだけの型が用意されているのがわかりました。 もちろんこれまで通り、型を宣言しなくても PHP は動きます。 しかし、今や PHP は8.00,8.1.0のバージョンアップで交差型やunion型が追加され、静的型付け言語に匹敵する型宣言ができるようになっています。 特に複数人でそれなりの規模の開発を PHP で行っているという場合は、意識して型を使ってみてはいかがでしょうか。 PhpStormを使用すれば最初の一歩もかなり踏み出しやすかったりします。 今後 PHP は、更に型について厳しくなっていくと予想されます。 賛否両論ありますが、動的型付け言語と静的型付け言語のいいとこ取りをしていければ最高なのかなと思ったりします。 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の yayawowo です。 「この分かりにくいコード誰が書いたんだ？」 「あ、3年前の自分じゃないか…」 といった経験はないでしょうか？ 今回は、 システム開発 をする上で大切な可読性の高いコードや リファクタリング をテーマにした、 ラク スが主催する「「リーダブルコード LT会」について発表内容と発表資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・ リーダブルコード LT会 ・ リーダブルコード LT会 - vol.2 　 次回は、3/24(木)開催予定です！ rakus.connpass.com リーダブルコード Tips 10選 賛同者が集まらない俺流『リーダブルコード』 翻訳した英単語をそのまま 使うのは今日で終わりにしよう！ 可音読性と可黙読性 静的解析ではじめる負債コード解消 リーダブルなPHPDocを目指して Code SmellsのPrimitive Obsessionに気を付けて設計する 若手が可読性を上げるために気を付けたこと 全てのコードに意図を持たせよう チームでリーダブルコードを実現するには？ リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する 『リーダブルコード LT会 - vol.3』は3/24(木)19時開催 ラクスのエンジニアと話をしてみたい方へ 最後に リーダブルコード Tips 10選 賛同者が集まらない俺流『リーダブルコード』 発表者： 白柳隆司 さん speakerdeck.com ◆ 発表内容 ・何故リーダブルにするか 　→後で読んだときに脳みそを使いたくない ・リーダブルのレベルを独自に決める ・コードにすべてを書く必要はない ・コードに書くべきもの 　1. ドキュメント化できるIFコメント 　2. 曖昧なものを明確化するための手がかり 　3. 忘れるもの、間違えやすいもの ・リーダブルに正解はない！ 翻訳した英単語をそのまま 使うのは今日で終わりにしよう！ 発表者： mikaijun さん speakerdeck.com ◆ 発表内容 ・リーダブルコードのテクニック 　1. 明確な単語を選ぶ 　2. 汎用的な名前は避ける 　3. 誤解されやすい名前は避ける ・わかりやすい関数名を作るには？ 　🙅　翻訳した英単語をそのまま突っ込む 　🙆　誰もが知っている単語を組み合わせる 可音読性と可黙読性 発表者： joytomo さん speakerdeck.com ◆ 発表内容 ・可読性には可音読性と可黙読性がある ・どちらを重視するかは言語などで異なる ・その先に、リーダブルでビューティフルなコードがある ・美しさは論証できない 静的解析ではじめる負債コード解消 発表者： mushacabbage さん speakerdeck.com ◆ 発表内容 ・Inspectionを活用 　活用事例）未使用の変数や関数を検知、コメントがない関数を検知など… ・自分たちで強いルールを作ることで負債コードが放置されるのを防ぐよう工夫 ・PhpStormだけでも多様な静的解析ができる ・カスタマイズが可能なのでチーム特有のチェックができる リーダブルなPHPDocを目指して 発表者： masato_n さん speakerdeck.com ◆ 発表内容 ・無法地帯となっていたPHPDocをメンテナンスした話 ・何故メンテナンスしようと思ったのか 　1. チームメンバーの入れ替わりで経験則でカバーできなくなってきた 　2. 生産性を上げるために、無駄な時間を使いたくなった 　3. 役に立っていないPHPDocが勿体ない ・メンテナンス方法と効果と所感 ・サボらずPHPDocをメンテしましょう！ 　 ・PHPDocの書き方は以下をご参考ください！ 　 tech-blog.rakus.co.jp Code SmellsのPrimitive Obsessionに気を付けて設計する 発表者： きり丸@ないない さん speakerdeck.com ◆ 発表内容 ・良いコードとは？ 　→良いコードとは悪くないコード 　→悪くないコードにするには、Code Smellsに気を付けたらいい ・例）年度、ISBN、山札/手札/場札 ・コードに業務知識を表現させると可読性が上がる 若手が可読性を上げるために気を付けたこと 発表者： gr_risa さん speakerdeck.com ◆ 発表内容 可読性を良くするためにもらった指摘のコメントランキング 　1. 冗長です 　　・自分一人しか見ないコードはコメントを適当に書いていた 　　・コメント要否の判断の重要性 　2. 名前が分かりにくい 　　 たかが 命名 、されど 命名 　　　・接頭辞を使う 　　　・具体的な名前を使う 　3. コメントが（不要です/必要です） 　　 何日か後の自分は他人です 　　　・何日か後の自分が読みにくいコードが、他人に読めるはずがない 　　　・ネストが深いコードは読みにくい 全てのコードに意図を持たせよう 発表者： Nozomu Otsuka さん speakerdeck.com ◆ 発表内容 ・リーダブルではないコードとは？ ・どうしたらコードに一貫性が出るのか？ ・初心者のうちは既存のルールに従う ・他の人の「意図」を学ぶ 　→他の人の「意図」を考えることで、自分のコードも良くなっていく チームでリーダブルコードを実現するには？ 発表者： MxShun さん speakerdeck.com ◆ 発表内容 ・私たちがやったことの良かったこと/良くなかったこと 　1. 勉強会 　2. PR公開レビュー 　3. PR指摘事項共有 リーダブルコード by DDD モデリング を起点に可読性の高いコードを実現する 発表者： Yoshiki Iida さん speakerdeck.com ◆ 発表内容 変更しやすいシステムの特徴 ・リーダブルであること 　→実装を理解しやすいこと 　→実装の目的を理解しやすいこと 実装アプローチ ・ ドメイン ﾓﾃﾞﾘﾝｸﾞは実装の目的理解にダイレクトに有効 ・責務を理解し、テスト・リファクタを回していくことで結果的にリーダブルになっていく ・参照実装などを充実させることでチーム開発がより効率化 『リーダブルコード LT会 - vol.3』は3/24(木)19時開催 リーダブルコードをテーマにしたLT会の3回目が3/24(木)に開催します。 LT登壇は9枠埋まっており、 チームでレビュー ガイドライン を導入した話や オブジェクト脳への一歩 リーダブルコード輪読会をオススメします などの発表テーマを予定しております。 ※発表内容が変更となる可能性がありますので、ご了承ください。 ご興味ありましたら、connpass又はTECH PLAYから参加申込のほどよろしくお願いいたします！ rakus.connpass.com techplay.jp ラク スのエンジニアと話をしてみたい方へ ラク スでは、フロントエンドエンジニアだけでなく幅広い職種で採用を強化しております。 とはいえ、まだ応募する段階ではないという方には カジュアル面談 をご案内しております！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんとお話をしたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 最後に リーダブルコード Tipsはいかがでしたか？ 可読性の高いコードを書くためのTipsがイベントに参加するだけで、豊富に吸収することができます。 また、当日参加される視聴者と意見交換もできますので、悩みの一つが解消するチャンスかもしれませんよ！ 最後になりますが、イベントを開催する側としても、参加する皆さんの一助となる情報がありましたら幸いです。 お読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに はじめまして。aqli_kuk120と申します。 ラク スの片隅でひっそりとインフラエンジニアをしています。 「エンジニアは常日頃の情報収集が肝要」とよく聞きますが、中々実践できない自分がいました。 技術系のニュースアプリを スマホ に入れてみるも、三日坊主でついつい他の興味あることをネットサーフィンする日々…。 これではいかんと思い、対策を考えた結果、 「人気記事のリンクを スクレイピング して社内のチャットツール(Mattermost)に BOT 投稿するようにしたら、昼休みにご飯食べながらみれるんじゃない？」と思い至りました。 ということで、インフラエンジニアと名乗ったものの、今回は Python を使った スクレイピング とMattermostへの BOT 投稿についてブログを書いていきたいと思います。 はじめに スクレイピングとは Mattermostとは Pythonで今回作るもの 開発環境構築 MattermostでIncoming Webhookの設定 Ptyhonでスクレイピング実装 Mattermostへの投稿 最後に スクレイピング とは 英語のscrapeには「削り取る」「こすり落とす」という意味があります。 ここでの スクレイピング は対象WebサイトのHTMLから収集した情報を削り取って、必要な情報のみを抜き出す処理のことを指します。 今回は Python の BeautifulSoup4 というライブラリを使って スクレイピング を実行し、結果をMattermostに投稿します。 ※※注意※※ 前述のとおり、 スクレイピング を行うとき（HTMLを取得するとき）に対象のWebサーバにアクセスが発生します。 過剰なアクセスはWebサーバに負荷をかけ、サーバをダウンさせてしまう可能性もあります。 過去に逮捕された事例もありますので、実装中の動作検証なども十分に考慮して実施するようにしましょう。 また、 利用規約 で スクレイピング を禁止しているWebサイトもあります。 スクレイピング をする前に対象のWebサイトの 利用規約 を必ず確認するようにしましょう。 Mattermostとは オープンソース のチャットツールで、利用者が自由にチャンネルを作成することができます。 チャンネルごとにIncoming WebhookのURLを作成することができ、そのURLに適切なPOSTリク エス トを送信することで外部アプリケーションから任意の投稿をMattermostに行うことができます。 Python で今回作るもの 開発環境構築 上図のとおりWSL2で ubuntu を動かし、その中で3つのDockerコンテナを立てます。 1． Apache コンテナ httpd のDockerイメージをpull、そのイメージを使ってコンテナを作成・起動します。 # ubuntu上で実行 $ docker pull httpd $ docker run -d -p 8080:80 httpd Web スクレイピング 対象のHTMLファイルを作成し、 Apache コンテナに配置します。 # ubuntu上で実行 $ vi test.html <!DOCTYPE html> < html lang = "ja" > < head > < meta charset = "UTF-8" > < title > TEST PAGE </ title > </ head > < body > < p > 01のリンクをスクレイピングします </ p > < a href = "https://scraping-test01.html" > Scraping Target 01 </ a > < p > 02のリンクをスクレイピングします </ p > < a href = "https://scraping-test02.html" > Scraping Target 02 </ a > </ body > </ html > $ docker ps # ApacheコンテナのCONTAINER IDを確認 $ docker cp test.html [ApacheコンテナのCONTAINER ID]:/usr/local/apache2/htdocs 2. MattermostのDockerコンテナ Mattermost公式ページ で公開されているコマンドを使用してDockerコンテナを作成・起動します。 # ubuntu上で実行 $ docker run --name mattermost-preview -d --publish 8065:8065 mattermost/mattermost-preview 上記コマンドを実行した後、 Webブラウザ で http://localhost:8065/ にアクセスすることで、Mattermostにアクセスすることができます。 →Dockerイメージをカスタマイズしたい場合、DockerfileはMattermostの 公式Github にて公開されていますので、そちらをcloneしてカスタマイズをしてください。 3. Python をインストールしたDockerコンテナ(Web スクレイピング 実行環境) Dockerfileを作成 # ubuntu上で実行 $ vi Dockerfile FROM centos:centos7 RUN yum install -y python3 RUN pip3 install requests BeautifulSoup4 →最低限これだけ入れておけば、とりあえず今回の「 スクレイピング した結果をMattermostに投稿する」は達成できます。 　その他必要なものがあれば、お好みに応じてどうぞ。 Dockerイメージ作成・コンテナの作成・起動 # 先に作成したDockerfileと同じディレクトリで実行 docker build -t scraping . docker run --network=host -itd scraping /bin/bash → scraping という名前でイメージを作成して、そのイメージを指定してコンテナを作成しています。 　このDockerコンテナの中から localhost を通って各コンテナにアクセスがしたいため、 --network=host のオプションをつけています。 MattermostでIncoming Webhookの設定 コンテナが起動していれば Webブラウザ で http://localhost:8065/ にアクセスすることでMattermostにログインすることができます。 初回ログイン時にはメールアドレス、パスワード、チーム名など初期設定をする必要があるので適当に設定します。 設定後、Mattermostのメインページが表示されるので、 BOT 用のチャンネルを作成します。 Incoming WebhookのURLはチャンネルごとに発行することができるので、左上あたりのメニューボタンから Integrations > Incoming Webhooks と進み、 Add Incoming Webhook を選択してWebhook用のURLを発行します。 Ptyhonで スクレイピング 実装 ※普段は bash ぐらいしか使っていないため、コードで「ん？」と思っても多めに見てください…。 コード実装はコンテナに直接ログインしてviでゴリゴリ書く、エディタでコンテナにリモートアクセスして書くなどお好みの方法でどうぞ。 私は VSCode に Remote Development をインストールし、コンテナにリモートアクセスして書きました。 コンテナに直接ログインする場合は以下のコマンドを実行することでログインできます。 # ubuntu上で実施 $ docker exec -it [CONTAINER ID] /bin/bash さて、いよいよ スクレイピング の実装です。 以降の Python のコードはすべて一つのファイルに記述していきます。 まず、 スクレイピング をするために対象のHTMLページを取得する必要があります。 そのための実装が以下です。 import requests # スクレイピング対象のWebページのURLを指定 url = "http://localhost:8080/test.html" # requestsモジュールで指定したURLにGETリクエストを投げてHTMLデータを取得 # 取得したデータはres変数に格納 res = requests.get(url) 次に BeautifulSoup4 を使って取得したHTMLデータの スクレイピング をします。 from bs4 import BeautifulSoup # resに格納されているHTMLの文字列データをBeautifulSoup4のHTMLパーサーで解析 # 解析結果をsoup変数に格納 soup = BeautifulSoup(res.text, 'html.parser' ) # find_allメソッドを使ってHTML内のaタグをすべて抽出し、article_tags変数(リスト型)に格納 article_tags = soup.find_all( 'a' ) # リストにいれたaタグの情報からhref(リンク先のURL)とテキスト(リンクのタイトル)を取得し変数に格納する article_link_list = [] article_title_list = [] for article_tag in article_tags: article_link_list.append(article_tag.get( 'href' )) article_title_list.append(article_tag.get_text( 'a' )) find_all()メソッドは、Tagオブジェクトが持つ子孫要素のうち、引数に一致するすべての要素を検索します。 検索された要素はリスト型で返却されます。 この要素の検索について、BeautifulSoup4にはfind_all()以外にも、 CSS セレクタ を引数に検索するselect()メソッドなど、いくつか種類があります。 日本語訳されたドキュメントも検索すると見つけれますので、ぜひご確認ください。 また、このとき article_tags 、 article_link_list 、 article_title_list にはそれぞれ以下のようにデータが格納されています。 ・article_tags [<a href="https://scraping-test01.html">Scraping Target 01</a>, <a href="https://scraping-test02.html">Scraping Target 02</a>] ・article_link_list ['https://scraping-test01.html', 'https://scraping-test02.html'] ・article_title_list ['Scraping Target 01', 'Scraping Target 02'] 次に、 Python で スクレイピング したデータをMattermostに投稿します。 Mattermostへの投稿 今回は、下図のようにMattermost上で表形式になるように投稿をします。 Mattermostでは Markdown 記法が使えるので、 スクレイピング した結果をそのように加工して一時ファイルに出力します。 # スクレイピング結果を一時ファイルに出力 with open ( 'post_to_mattermost.txt' , 'w' ) as f: # 表の見出しを1行目に記載 f.write( "##### スクレイピング結果 \n |Title| \n |:--|:--| \n " ) # スクレイピング結果を格納したリストの内容をすべてファイルに出力する i = 0 for i in range ( len (article_title_list)): article = "|" + "[" + article_title_list[i] + "]" + "(" + article_link_list[i] + ")" + "|" f.writelines(article + " \n " ) Incoming Webhookを使ってMattermostに投稿する場合は、 JSON 形式でリク エス トを投げる必要があります。 そのため、先ほど作成した一時ファイルを読み込み、 JSON 形式に変換して変数に格納します。 post_data={} with open ( 'post_to_mattermost.txt' , 'r' ) as f: post_data.update({ 'text' :f.read()}) Python の辞書型は JSON として利用することができるので、keyに text を格納し、 value に一時ファイルの内容を格納します。 keyを text にしているのは、投稿本文のkeyは text にするというルールがあるためです。 そのあたりの細かいルールについては Mattermostの公式ドキュメント をご確認ください。 最後に作成したIncoming WebhookのURLに対して、POSTリク エス トを送信する処理を実装して完成です！ webhook_url = "[Incoming WebhookのURL]" headers = { 'Content-Type' : 'application/json' ,} json_post_data = json.dumps(post_data, ensure_ascii= False ).encode( 'utf-8' ) requests.post(webhook_url, headers=headers, data=json_post_data) 最後に 今回はブログ用に スクレイピング 対象のHTMLはかなり簡略化したものを使いましたが、 「必要な要素を取得する」が基本（だと思っている）ので、HTMLが複雑であってもやることはそんなに変わらないと思います。 日頃、 Python でのプログラミングや、こういったブログも書く機会がないので、未熟な点が多々あったと思いますが、なにかの手助けになれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は2021年度最後の ラク スMeetup、 最前線エンジニア達が語るSaaS開発の裏話／API連携、自動化、インフラ の発表内容について紹介させていただきます！ テーマは 『最前線の現場とキャリア』 です。 SaaS サービスの成長と共に、日々の業務で培った経験や、技術ノウハウをご紹介させていただきました。 また、今回登壇したのは、以下プロダクト開発/運用を担当するエンジニアたちです。 楽楽精算 楽楽販売 MailDealer チャットディーラー イベントの詳細は以下をご確認ください。 rakus.connpass.com 発表の紹介 インフラエンジニアとしての成長記 右も左も分からない1年目が上流工程を理解するまでの話 入社して3年間で『Rundeck』を使って自動化した「面倒」な作業たち ラクスのエンジニアと話をしてみたい方へ おわりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ インフラエンジニアとしての成長記 登壇：前川 侑輝 [所属：大阪インフラ開発課] まずは、今年で入社3年目となる前川の発表です。 研修を経て、現在は社内開発環境だけでなく商材の運用業務も行っていますが この3年間での己の成長を振り返ることで得られる新たな気付きやステップアップにつながるヒントがありました。 今回は、 ラク スの研修内容 オンボーディング と、インフラ知識ゼロで配属されてからどんな問題に直面して、どうアプローチしたかについてお話させていただきました。 speakerdeck.com 右も左も分からない1年目が上流工程を理解するまでの話 登壇：永田 光一 [所属：楽楽精算開発2課] 入社1年目の終わりに現行システムの大規模な構成変更の設計・実装、2年目に API 連携機能の要件定義～実装までを担当しました。 開発している製品についてもほとんど把握できていない… 自分のチームの使っているドキュメントのフォーマットでさえほとんど分からない… どこまでできていればいいのか分からない… 楽楽精算開発2課の永田より、 このような状況でどのようにしてリリースまでたどり着くことができたのか、 初めてやることに対してどんなアクションを取ってたのかを振り返り、 お話をさせていただきました。 speakerdeck.com 入社して3年間で『Rundeck』を使って自動化した「面倒」な作業たち 登壇：金森 聖人 [所属：東京インフラ開発3課] 最後は、東京インフラ開発3課の金森からの発表です。 「面倒」な作業というのは、運用担当をしていると避けて通れないものです。 なぜ「面倒」と感じるか。 それは、「定型的な作業」であることや「失敗した場合の影響が大きい作業」であることが要素として含まれていることが多いと考えています。 代り映えのしない同じような作業には変化がなく退屈であり「面倒」であると感じたり、1つのミスで大きな影響が出てしまい、修復に労力がかかることに対する退避として「面倒」であると感じるのではないでしょうか。 しかし、運用作業というのは「定型的な作業」「失敗した場合の影響が大きい作業」の連続です。 今回は、新卒社員として入社し、インフラエンジニアとなった金森が3年間で「面倒」な作業を『Rundeck』というツールを使用して少しずつ自動化した話をご紹介しました。 speakerdeck.com ラク スのエンジニアと話をしてみたい方へ ラク スでは、フロントエンドエンジニアだけでなく幅広い職種で採用を強化しております。 とはいえ、まだ応募する段階ではないという方には カジュアル面談 をご案内しております！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんとお話をしたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 おわりに 「最前線エンジニア達が語る SaaS 開発の裏話」はいかがでしたでしょうか？ 今回登壇した弊社エンジニアは、新卒入社をしてから SaaS の成長共に自身も成長し、今となっては現場で欠かせない存在となっております。 今回ご紹介した入社してから1～4年目までに経験した課題や教訓が、大規模 SaaS の開発に携わりたい方や、 ラク スの技術領域ご興味をお持ちの学生・若手エンジニアの一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

弊社で毎月開催し、 PHP エンジニアの間で好評いただいている PHP TechCafe。 2021年10月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「Laravel 入門を語り合う」のテーマで開催しました。 rakus.connpass.com Laravel導入手段 スグに始められるLaravel ここ一年で勢力図が大きく変わった 環境構築が選べるLaravel 環境構築は語りたいことが多い お隣さんが気になるLaravel Local環境で完結させたい派？Local環境を汚したくない派？ Laravel開発手段 サクっと作れるLaravel ルーティングについて Controller作成 ControllerからViewにパラメータを渡す Migrationについて Modelについて おわりに Laravel導入手段 前半のテーマでは、Laravelの開発環境構築手段についてDocker、ローカルマシン、仮想環境と系統ごとに気になるものを掘り下げながらのディスカッションが行われました。Laravel Sailが便利過ぎて秒で環境構築ができるのでLaravelの学習がスグに始められるというのが話題の中心になりました。 スグに始められるLaravel ここ一年で勢力図が大きく変わった 約一年前の PHP TechCafeで、当時リリースされたばかりの Laravel Sail について話した事を振り返りながら、この一年でLaravel Sailが公式のDocker環境にまで急成長したことが話題になりました。 これには docker-laravel を作られた @ucan_lab さんご自身もLaravel Sailの勢いの凄さについてコメントされていました。 Laravel Sailについては他にも Dockerの知識がなくても使える curl でURLパラメータに指定したサービスのコンテナだけが実装されるのが凄い所 各種DBやRedis、 Memcached などの様々な ミドルウェア をあわせて利用できる インターン の学生にも人気がある などの賞賛する声が多く挙がっていました。 環境構築が選べるLaravel 環境構築は語りたいことが多い 環境構築のテーマは PHP TechCafeの語り合うメンバーでも語りたいことが多く、紹介を兼ねて次のような話題で盛り上がりました。 Docker系 Laradock 全てが詰まったLaravel Docker環境。 黎明期はみんなこれを使っていた。 Docker系 docker-laravel 日本語で解説されているので解りやすかった。 Laravel Sailが主流になるまではお世話になった方も多い筈。 ローカルマシン系 Valet Mac 限定だがとにかく軽量で早い。 仮想環境系 Homestead 以前はこれがスタンダードな環境構築だった（古いバージョンだと公式に書いてあった）。 お隣さんが気になるLaravel 「（案件の本番環境で使うかは別として）勉強する時にどれくらいの人がLaravel Sailを使っているんだろう？」という疑問を切っ掛けに、他の皆さんが環境構築をどうされているかが気になる展開になりました。 Local環境で完結させたい派？Local環境を汚したくない派？ Local環境で完結させたい派「サービスの規模によるがDockerを立ち上げなくて済む」 Local環境を汚したくない派「何でもいいからDockerに入れて困ったら消してしまえってしてますね。」 などの双方の意見が出される中 「５名程度の開発でテストサイトの場合だったら何を使うか？」 とのチャットで寄せられた質問に対して意見を出し合いその場で答える場面もありました。 クライアントやデザイナーとの情報共有レベルなら何でも良さそう Laravel Sailで共通の環境を立ち上げて気軽に使えば良さそう プロダクト開発の中でのテストの目的ならインフラ担当者やマネジメントレベルの議論も必要だろう などの意見が出ていました。 Laravel開発手段 サクっと作れるLaravel ここからは後半のテーマとしてデータの追加・変更・削除が行えるToDoアプリ作成を例に、Laravelで開発を進める手順の解説が行われました。 「Laravelの公式リファレンスは情報量も多く便利だが何から進めて行けば良いのかが掴み辛い」という意見もあり、今回のテーマが参考になりそうな内容でした。 ルーティングについて ViewであるBladeファイルを新たに用意しweb. php にそのルーティングを追加して画面に表示させる実演が行われ、URLパラメータを取得したり、Viewへパラメータを渡す方法なども合わせて紹介されていました。 web. php 実装例 <?php Route :: get ( '/hello' , function () { return view ( 'hello' ) ; }) ; Bladeファイル実装例 < h1 > PHPerのための「Laravel 入門を語り合う」PHP TechCafe </ h1 > < div > < p > Hello World! </ p > </ div > web. php への追加とBladeファイルの作成のみで画面が作れる事から やっぱりサクっと作れるのが良い。 がっつり書き込まなくてもある程度期待通りの動きをしてくれるのは作っていて楽しい。 などの意見が出ていました。 Controller作成 Controllerの作成方法としてLaravel Sailでartisanコマンドを使っての方法が紹介されました。 ./vendor/bin/sail artisan make:controller HelloController ここでは注意点として、 rootユーザで php artisanコマンドを使ってしまうと作成されたControllerファイルの所有者もrootユーザになり、WEBサーバからのアクセスもroot権限でないと出来なくなってしまうので、Laravel Sailの使用がお勧め と説明されました。 「（それは）あるあるだね」などの共感コメントも多く寄せられていました。 関連してResource Controllerについても終盤におまけとして紹介されていました。 Controller作成のartisanコマンドにresourceオプションを付けるとデータの取得、追加、更新、削除を行うメソッドが自動的に追加される機能の事で、今回のToDoアプリに必要なメソッドも一通りまかなってくれる内容との説明がありました。 Controllers - Laravel - The PHP Framework For Web Artisans ControllerからViewにパラメータを渡す Controllerファイル実装例 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; class HelloController extends Controller { public function index () { return view ( 'hello' , [ 'name' => 'Rakus' ]) ; } } ルーティングの項ではリク エス トされた際に直接Viewを表示する解説でしたが、ここではControllerを呼び出しその処理結果をViewに渡す開発に即した作成方法を解説しました。 Controllerクラスのメソッドでリク エス ト情報を受け取る方法や、「機能毎にControllerを割ってファイルを分割する方が管理もしやすく複数人での開発もやりやすい」といった実例紹介もありました。 「RoutingにControllerの処理を書くとどうなるか」 との質問がコメントで寄せられましたが、これに対してrootキャッシュが通らなくなるという回答がありました。 「通常はアクセスが来た時には PHP の コンパイル が走って二回目以降は処理が早くなりますが、それが出来なくなる」と解説されました。 Migrationについて Webアプリに不可欠なデータベースの管理についてMigrationでテーブル作成する解説が行われました。 Laravelのデータベースクエリビルダが用意されているので使用頻度が低めでCreate Table文に馴染みがなくても「これ一つ書いたら作られるんですよね？」となるのが便利な一方で、「 SQL の書き方を忘れるっていうのはありそうだ」などの意見も出ていました。 複雑な結合をさせたい場合、「Modelの使い方をマスターしていない場合でも、LaravelにはDBクラスもあって SQL を直接自分で書くことも可能」との補足説明もありました。 Migrationファイル実装例 <?php use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class CreateTodoTable extends Migration { /** * Run the migrations. * * @return void */ public function up () { Schema :: create ( 'todo' , function ( Blueprint $ table ) { $ table -> id () ; $ table -> timestamps () ; }) ; } /** * Reverse the migrations. * * @return void */ public function down () { Schema :: dropIfExists ( 'todo' ) ; } } Migrate実行時の処理であるup関数で作成するテーブルのTimestamp型カラムについての解説では次のような意見が出ていました。 レコードの作成時や更新時に自動的に日時がセットされるので便利 知らないうちに全部やっているっていうのがLaravelっぽい 「テスト用の環境に SQLite を使っているが、Migrationのコードに手を加えないと SQL が上手く動かない場合があるのですが、どうしていますか？」 とのチャットの質問では参加者の方々に採用しているデータベースについて決を採る場面もありました。 結果は SQLite を使っていない派が多数を占めていました。 Dockerでそのまま入っちゃうからあんまり気にせず PostgreSQL とかでやっちゃいますね… 本番環境でも実行しているMigrationなのであればテスト用環境のデータベースは MySQL などを使い、Migrationファイルをいじらずに済ませるのが無難なのでは？ などの意見が挙がっていました。 Migration実行のartisanコマンド ./vendor/bin/sail artisan migrate テーブルを作り直す場合に ロールバック せずともテーブル削除とMigrate実行をセットで行ってくれる便利なmigrate:freshコマンドや、関連して初期データを投入してくれるseederの紹介も行われていました。 Modelについて ./vendor/bin/sail artisan make:model Todo 内容が盛り沢山で最後は駆け足になりながらも、実際に画面を動かしModelクラスを経由してDBのデータ取得・登録・編集・削除が容易に行える様子を実演して締めくくりました。 今回のTeckCafeで解説した内容はHackMDにまとめられていますので合わせてご覧ください。 hackmd.io おわりに 『 PHP TechCafe』では今後も PHP に関する様々なテーマのイベントを企画していきます。 是非、皆さまのご参加をお待ちしております！ connpass.com ◆ PHPTechCafeの過去公開したイベントレポートも合わせてご確認ください！ ・ PHPerの今とその先について in 2021 【PHP TechCafe イベントレポート】 ・ PHP8.1 の新機能について語り合う・前編【PHP TechCafe イベントレポート】 ・ PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 ・ PHPUnit の始め方について語りあう 【PHP TechCafe イベントレポート】 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

開発本部の本年度（2022年3月期）の取り組みについて １．エキスパート人材の育成・強化 ２. プロダクトマネジメント機能の強化 ３．新しい技術の習得　 こんにちは。 ラク スの開発組織を統括している開発本部長の公手（くで）です。 先月2/8に記念すべき第1回「RAKUS Tech Conference 2022」を開催致しました。 多くの社外のエンジニア様にご参加していただき、大変ありがたく思っております。 そのオープニングセッションで ラク スのエンジニア組織について発表させていただきました。 speakerdeck.com ラク スのエンジニアも何名か聞いてくれており、 「もう少し頻度上げて開発組織全体の取り組みを社外に公表していっても良いのでは？」 というフィードバックもあったことから、早速 ラク スのTechブログに投稿してみることにしました。 今後も、 不定 期ではありますが、投稿できればと思っています。 以下、「RAKUS Tech Conference 2022」のレポートも是非ご確認ください。 tech-blog.rakus.co.jp 開発本部の本年度（2022年3月期）の取り組みについて ラク スの決算期は3月末です。 本年度もあと1か月を残すのみとなりましたが、本年度に重点的に取り組んだことについて書いてみました。 ラク スの開発本部では、毎年9月から部門ごとに翌期の取り組みについて考え始めます。 その後、12月に各部のエンジニア リングマ ネージャーが集い、翌期の重点取り組み事項を決めます。 基本的には会社の5か年の中期経営計画に合わせて、5か年の組織ロードマップや技術ロードマップを作成しています。 ラク スの中期経営計画については以下のIR情報をご覧ください。 www.rakus.co.jp そのロードマップには、5年後の到達地点から逆算して1期目～5期目の取り組み事項が描かれています。 9月からの作業は、内外の状況の変化などもあるため、ロードマップをアップデートし、翌期にやることを具体化していくといったことになります。 ラク スの開発本部は250名の組織であり、20以上の課やチームが存在します。 それぞれの組織で、現場の要望、共通課題などをリストアップし、エンジニア リングマ ネージャーたちが各組織のロードマップを作成しています。 さらにそれらを俯瞰し、抽象化して、開発本部全体の組織ロードマップを作成します。 ロードマップに書かれている翌期の取り組みの中から、より重要なもの、開発組織全体に関わるものを 選び出して重点取り組み事項として5～6つぐらいまで絞り込んでいます。 昨年掲げた、今期の重点取り組み事項は以下の6項目でした。 《今期の重点取り組み事項》 エキスパート人材の育成・強化　 プロダクトマネジメント 機能の強化 新しい技術の習得　 組織 ブランディング オフショアの強化 データセンター移転 今回は、これらのうち、3点を取り上げ、当社の課題感などを共有できればと思っています。 　 １．エキスパート人材の育成・強化 実は ラク スは一つのプロダクト開発組織がそれほど大きくなく、（多いチームでは50名を超えるぐらい）、10名～20名ぐらいで開発しています。 数年前はさらに少人数で開発をしていました。 その時代は、どちらかというとバックエンドもフロントエンドもできてプロジェクトマネージャーもできて要件定義等の上流工程もできるという、全方位に活躍できるようなエンジニアを育成したり、求めたりしていました。 しかしながら、このように何でもできるエンジニアというのは育つのに時間もかかりますし、そういった志向のエンジニアが必ずしも多いわけでもなく、採用も難しいです。 組織の人数を増やしていく必要性から、役割の分化が必要であるということに少し前から気が付きました。 そこで、各領域・領域のエキスパートを育てたり、採用したりする方向に変わってきました。 エキスパートになるために必要とされるスキルセットをまとめ、再現性のある育成プランを作っていく、取組を1昨年前より始めています。 今期も継続して取り組んでおり、一定の成果が出てきています。 具体的には以下のようなエキスパート人材の採用や育成に取り組みました。 プロジェクトマネージャー 各 ドメイン のエキスパート フロントエンドエンジニア モバイルエンジニア QAエンジニア ブリッジSE インフラコア技術(オンプレ仮想化）のエキスパート など。 まだまだ各領域で不足感はあるものの、育成が進み、採用による増員もできました。 ２. プロダクトマネジメント 機能の強化 プロダクトは成熟してくると、何を開発するのかが非常に難しくなってきます。 例えば、市場に後発で投入したプロダクトは、当面は他社と勝負できるように劣後点をつぶしていく必要があり、開発すべきことは山ほどあります。 また、 PMF を達成した後は、顧客からの要望が一気に増え、顧客の要望満たすための開発が当面続きます。 しかしなら。数年も経過すると製品も成熟してきて、お客様の要望も少なくなってきます。 こうなってくると、今度は何を開発するか考えることが難しくなってきます。 ラク スの場合も、リリース後10数年経過したサービスではその領域ではトップシェアを誇り、機能ラインナップでもほぼほぼお客様のニーズを満たせるサービスにもなってきています。 ただ、そこで終わってしまうとプロダクトの成長も終わるので、顧客が気付いていない 潜在的 なニーズを探し新しい付加価値を作って行くことになります。 いくつかの商材ではそういった新しい付加価値をどんどん生み出す力が不足気味です。 数年前から、組織として プロダクトマネジメント 力の強化に取り組んでいます。 今期は、 プロダクトマネジメント 担当者のつくり、プロダクトマネージャーの採用強化を進めるとともに、また、プロダクトマネージャーを強力に補佐ですべき役割であるUIデザイナの拡充も一定進みました。 ３．新しい技術の習得　 クラウド サービスは、10年、20年と開発が続いていくサービスです。 ラク スでもメールディーラーでは18年、配配メールは15年、楽楽精算はで11年と続いています。 その間に、Webの技術はどんどん進化し、新しいことができるようになってきています。 しかしながら、進化の流れに合わせて新しい技術ををどんどん製品に取り入れられるわけではありません。 昨今、当たり前となったマイクロサービスであれば新技術投入はやりやすいですが、レガシーな アーキテクチャ で開発を続ける限り、新技術に触れるたり検証する機会はどうしても少なくなっています。 しかしながら新しい技術は実際に振れて試してみないとなかなか身につきません。 組織として、どんどん後れを取っていきます。 また、いざ新サービスを立ち上げる時に、技術習得から入っているとリードタイムもさらに伸びます。 使ったことがない技術だから、、、ということで、稼働の制約などからも敬遠したりするようなことがありがちです。 ※当社も過去に数度そういう選択をしてきました。リリースの速度感を考えると間違いだったとは思っていませんが、、、 そこで ラク スでは、Webの デファクト スタンダートな技術、あるいは デファクト になり得そうな技術については、各プロダクト開発で使っていなくてもノウハウを習得しておくべきということで、数年前に、有志達により、「かみせん」というプロジェクトが発足し、週に一回数時間だけ集まっての小さな研究活動（というか技術習得活動）がスタートしました。 このプロジェクトで得たノウハウで、実際に新規サービスのリリー スリード タイムに貢献出来たり、プロダクトが抱えていた問題の解決に役立ったりと小さいながらも一定の成果が見え始めました。 今では、その試みを推進する組織（技術推進課）に昇格させ、開発本部の組織的な取り組みとしています。 目新しいもの使ってみるという視点から、既存サービスの抱えている課題感を解決できそうかという視点で研究テーマも選定しています。 今期は以下のようなテーマに取り組み、このうち3件が来期のプロダクト開発に活用されることになりました。 認証関連 コンテナ オーケストレーション 不具合の早期検知（ APM ） CSS プラットフォーム サーキットブレーカパターン ドキュメントDB AI領域 来期も新しいテーマに向けて取り組んでいきます。 技術推進課の取り組みをまとめた記事です。 こちらも合わせご確認ください！** tech-blog.rakus.co.jp また、 ラク スでは一緒に働いてくれるエンジニア・デザイナーを積極募集中です。 まずは相談だけでもという方は、カジュアル面談も大歓迎です！ rakus.hubspotpagebuilder.com お気軽にどうぞ。 では次回は残りの3つについて、ご報告できればと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 第1回 形式 反省点、改善の余地 第2回 形式 第1回から継続 第1回から変更 反省点、今後の展望 アンケート結果 次回以降の輪読会で読みたい本のテーマ 参加メンバーからの意見・感想 おわりに 参考 はじめに こんにちは。mtaaaです。 ラク スのフロントエンドチームでは、2021年上半期に週1回の輪読会を開催していました。 1人では読むハードルの高い、内容重めの書籍を勉強する場としてだけでなく、メンバーの交流の場としても有意義だったため、単発で終わってしまうのはもったいないと考えました。 下半期も開催すべく主導で動いたので、 輪読会のノウハウや改善点、参加メンバーの声を共有したいと思います。 第1回 書籍は「 CSS設計完全ガイド ~詳細解説+実践的モジュール集 」 書籍の選定については、参加するメンバーが担当するプロダクトがそれぞれ異なる状況から、言語や フレームワーク に依存した内容ではなく、フロントエンドエンジニア全般に生かしやすい内容のものとしています 形式 参加人数は10人前後 Google Jamboardに読んだ内容の感想、気付き、派生した情報共有を各々が書き込む 毎週業務時間内で同じ時間に1時間枠を設け、30分間読書&Jamboard書き込み、30分間Jamboardに記載の内容や書籍自体を深掘って内容の理解や各開発者の目線ごとの意見共有 1回で30~40ページを読み進める 主催のメンバーが ファシリテーター を毎回行い、読む範囲の指定やJamboardの作成といった事前の準備や周知、当日の進行を取りまとめていた 完全リモートでの開催(情勢もあり選択肢がこれだけ) 反省点、改善の余地 主催のメンバーに負担が集中してしまっていた 1回のボリュームが多く、読み切れなかったり、予習前提になってしまったりした面があった 発言が一部メンバーに固定されがちだった 第2回 書籍は「 リファクタリング(第2版): 既存のコードを安全に改善する 」 第2回では、上記課題を改善することに加えて、主催を含めメンバーの負担をできるだけ減らして参加しやすくなる会を目指しました 形式 第1回から継続 参加人数は10人前後 Google Jamboardに読んだ内容の感想、気付き、派生した情報共有などを各々が書き込む 毎週業務時間内で同じ時間に1時間枠を設け、30分読書&、30分書籍の特にJamboardに記載の内容を深掘って内容の理解や各開発者の目線ごとの意見共有 第1回から変更 ファシリテーター を当番制にして全メンバーに回るようにし、当日の進行を盛り上げやすいように毎回2人設定した オフィスのオープンスペースでの開催がメイン(途中から情勢を鑑みてリモートでの開催に) →リモート開催をZoomからGatherに移行し、オフィスで開催しているような感覚を得られた 読み切れない場合や、事前の予習が前提となりがちだったため、1回で15~20ページを読み進める →これに伴って輪読会自体の開催期間が伸びたが、参加者は事前準備を気にせず、本だけ持って当日を迎えればいい状態を作れた 元々参加自由ではあったが、これを明言し、回によって参加不参加があっても問題ないことを強調した →メンバーが業務とバランスを取りやすい環境を作れた 開催期間終盤に参加者アンケートを取った →出席率、満足度、形式についての要望、輪読会自体への感想、要望、今後読んでみたい書籍のテーマなど 主催となった私が準備したのは本の発注と読む範囲の選定、日程の周知くらいであり、一度走り出した後は私がいなくとも回る形を作れたので、今後輪読会を開きたい、というメンバーが気軽に主催できるサンプルにはなったように思います。 Gatherでのリモート開催の様子 反省点、今後の展望 読む時間より議論の時間を長めに確保する 発言者が偏りがちだったため、少人数でのグループを作って雑談感覚で意見交換する形式も試してみたい 輪読会数回ごとにメンバーの意見や情報共有をまとめてマガジン化してみたい 各メンバーの業務都合で ファシリテーター の急な変更が何回も発生してしまった →事前にある程度予習しておきたい人もいたため、直前に交代が決まると準備できなかった アンケート結果 輪読会出席率 来期以降の開催について 内容の満足度 次回以降の輪読会で読みたい本のテーマ リーダブルコード React/Vue TypeScript/ JavaScript Git 設計 オブジェクト指向 デザインパターン といったものが挙げられていました。 特にリーダブルコード等プログラミングの基本について学びたい要望が多かったです。 参加メンバーからの意見・感想 異なるプロダクトを担当し、かつバックグラウンドの違うメンバーが揃っており、本の内容から派生したフロントエンド技術全般の情報共有が非常に有意義 普段は積極的には読まないような厚い内容の本が読めた 担当プロダクトが異なるために交流の少ないメンバーの意見や、他プロダクトでの開発ケースでの話を聞ける機会になった 本の内容が開発に生きた 前提知識や、基礎的な内容の復習になった 議論が単純に楽しい、リフレッシュになる おわりに 今回は、社内輪読会での試行錯誤について書いていきました。 輪読会は本来の目的である、1人で読むには難しかったり、重かったりする書籍を読む機会を設けるだけでなく、普段交流の少ないメンバーと話せる場所としての需要が大きいように感じました。 本記事が読んでくださった方の輪読会開催の一助になればと思います。 ここまで読んでいただきありがとうございました。 参考 オンライン輪読会を2回主催して、やめた取り組みのいくつか 技術書の輪読会を定着させるまでの道のりで学んだこと エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の yayawowo です。 突然ですが、変化の多いフロントエンド関連の情報を日頃どのようにインプットされておりますでしょうか？ SNS やWeb記事、最近では Podcast という方もいると思います。 しかしながら「時間に余裕がない！」という方も多くいらっしゃるはずです。 そんな方のために、 ラク スでは フロントエンド関連の最新ニュースや記事を定期的にピックアップし、エンジニア同士が楽しみながら学習するためのコミュニティ『フロントエンドTechCafe』 という憩いの場を定期的にご提供しております。 本記事では、2020年～2021年に開催した「フロントエンドTechCafe」のイベント内容をまとめております！ フロントエンド領域の知見を高めたい方 フロントエンドエンジニアを目指している方 フロントエンドTechCafeにご興味ある方 などなど、是非ご参考いただけますと幸いです。 【目次】 フロントエンドTechCafeとは 2020年度開催 フロントエンドのニュースや記事を紹介して語り合う会@TechCafe（Vue,TS成分多め） 「Vue.js 3.0」を語るフロントエンドTechCafe 「2020年の振り返りイチオシ情報」を語るフロントエンドTechCafe 「フロントエンド開発の便利ツール・設定・プラグインなど」を語るフロントエンドTechCafe 2021年度開催 「フロントエンド開発の便利ツール・設定・プラグインなど」を語るフロントエンドTechCafe #2 「再入門！フロントエンドエンジニアが押さえておくべき技術」を語るフロントエンドTechCafe ラクスのエンジニアと話をしてみたい方へ まとめ フロントエンドTechCafeとは 「”フロントエンド” TechCafe」は、 JavaScript などフロントエンド関連の技術要素を軸としてエンジニアと技術が交差する憩いの場（カフェ）になることを目指しています。 主に、 JavaScript に関して学習中の初級エンジニア～シニアエンジニア を対象としておりますが、 エンジニア同士の学びの場をつくり、エキスパートまでの自己成長を支援 学びの場を一緒に支援して頂けるエキスパート以上の方の参加も大歓迎 私たちと皆さまが共に成長できる場としたい という思いで開催をしております！ なお、 ラク スで採用している技術要素の関係から、 JavaScript やTypeScriptなどの話題が多くなる可能性がございます。 そちらはご承知おきくださいませ。 2020年度開催 フロントエンドのニュースや記事を紹介して語り合う会@TechCafe（Vue,TS成分多め） rakus.connpass.com 初開催したのは、2020/7/31です。 初回の議題は以下のような内容でした。 ＜ 導入トピック ＞ ・2020年の11の必見のフロントエンドトレンド 参考にした記事から注目ポイントを厳選し、今後のトレンドについて意見交換をしました。 ＜ Vue.js関連情報 ＞ ◆ Vue3 RCリリース 新機能である Composition API 、 Teleport 、 Fragments 、 Emits Component Option について紹介。 また、Vue Composition API のメリット/デメリットをまとめた記事を見た上で、コンポ―ネント間でのロジックの断片化などの課題感を実際の現場状況と踏まえ協議しました。 ＜ TypeScript関連情報 ＞ ・ TypeScript4.0で導入された新機能 ・ TypeScript、JavaScritpの誕生背景や歴史 ・ TypeScriptの enum についての評価 などなど ＜ ES関連情報 ＞ ◆ ES2020リリース ・仕様一覧（ Finished Proposals ） ・ JavaScript : Latest Stage-4 features についてご紹介しました。 イベント当時にStage4まで進んでいる提案リストもあるようです。 ＜ サーバーサイド関連情報 ＞ DenoとNodeのパフォーマンス比較記事を紹介。 ＜ JavaScript ・フロントエンド全般 ＞ 残り時間を利用し、 JavaScript ・フロントエンド全般の気になった記事を基に議論しました。 JavaScript ライブラリを読むコツや、DOMとうまく付き合う方法などがありました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「Vue.js 3.0」を語るフロントエンドTechCafe rakus.connpass.com 2020/11/11に、「Vue3」をテーマに2回目のフロントエンドTechCafeを開催し、 リリースノート 、 vue3マイグレーションガイド: イントロダクション 、 RFC を見ながら 以下議題について当社出演者が語り合いました。 Vue3新機能の紹介と現場エンジニアの声 Vue2との比較 Vue2 -> Vue3移行時に気になるポイント 参加者も300名近くなり、 「CompositionAPIは嬉しい」 「プロダクトが大規模化する中でコードの分割をするも、2系のmixinでは難点が多そう・・・」 「UnitTestも書きやすくなりそう」 「Vue3への移行は？」 などが話題となり、大変盛り上がりのあるイベントとなりました。 「2020年の振り返りイチオシ情報」を語るフロントエンドTechCafe rakus.connpass.com 第3回目は2021/2/10に開催！ タイトルの通り、2020年のフロントエンド関連の様々なニュースのうち、出演者イチオシのものを選んで語り合った会です。 ＜ 印象に残った・興味深いトピックス ＞ ◆ Vue3リリース リリースノート 、 マイグレーションガイド などでリリース内容の確認をしました。 ◆ Chromium edge のリリース www.publickey1.jp 旧edgeとの違いや、サポート終了の話で盛り上がりました。 ◆ webpack5リリース webpack.js.org webpack（=モジュールバンドラー）とは？ webpack5変更点とは？ といった観点で記事をピックアップし、語りました。 ◆ TypeScript4.0 のリリース devblogs.microsoft.com 追加機能をまとめたQiitaの記事を見ながら、どのように導入ができそうか話しました。 今回のアップデートは、安全性や利便性を高める比較的安定した機能追加が多かったとこのことです。 弊社メンバーは、「機能よりも VSCode の構文ハイライトの高速化が気になった」とのことでした。 ◆ Vuex4リリース github.com Vue4の基本的な使い方は前バージョンと変わらないが、初期化が大きく変わっているとのこと。 リリース内容だけでなく、その他のエコシステムやUIライブラリなどもピックアップしております！ ◆ Babel 7.9.0リリース 7.9.0 Released: Smaller preset-env output, Typescript 3.8 support and a new JSX transform · Babel 8.0に向けた準備。 JSX変換の最適化やパンドルサイズの縮小が追加されました！ ＜ ツール・ライブラリ ＞ ◆ Vite github.com Viteは、ノーバンドルなビルドツールです。 ビルドが遅いという話がメンバーからよく話に上がるVue CLI と比べてると、開発は楽になりそうであると話題になりました。 ◆ core-jsのメンテナンス再開 core-jsとは、babelのpolyfill内部で使われているモジュール集であり、 ブラウザによっては実装されていないPromiseやArray系の関数を使えるようにするものです。 ここでメンテナンスを取り巻く状況についてをご紹介しました。 5年間、1人のメンテナによってメンテナンスがされ続けていたが、交通事故を起こしてしまい開発が停止。 メンテナが2020/10に復帰し、開発が再開されたのことです。 メンバーからも、 ・多くの人が利用していると思うが開発継続には人員や収益などのリソースが必要 ・開発が終了するリスクを考えると、自身も何かしらの形で利用している OSS へ貢献していきたいと思わされた のような意見がありました。 ◆ StateOfJS2020（10000人のエンジニアによる投票結果） 2020.stateofjs.com それぞれの分野のランキングの推移は…？ ◆ Denoの紹介やNodeとの違いなど Denoは、Node. jas の作者であるRyan Dahlが新たに作った JavaScript の実行環境です。 deno.land 本時間では、Node.jsの問題点やDenoの特徴について、参加者と話をしました。 その他トピックとして、 ES2020とES2021 Moment.js の非推奨化 ReactとVueとSvelteで同じアプリを開発してみて比較した記事 などをピックアップし、限られた時間の中で参加者と一緒に楽しむことができました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe rakus.connpass.com 2021/3/10に開催した本イベントは、参加申込が450名を超える大人気イベントとなりました！ では早速、当日お話しした内容を見てましょう。 ＜ ラク スエンジニア＋参加者の皆さまお薦めのツール類 ＞ ※イベント申込時に、参加者の皆様にアンケートを実施しました。 ◆ VSCode 拡張 live share visualstudio.microsoft.com 複数人同時編集可能 ペアプロ などで使えそう LiveServer marketplace.visualstudio.com 参加者アンケートの結果 ・ vscode の 拡張機能 ・簡単にwebサーバが立ち上げられる ・ローカルで作ったペライチhtmlから API 叩くときに便利。 ・ Chrome のデフォルト設定ではローカルhtmlファイルから外部ソースを参照すると、デフォルトではorigin:nullでCORSエラーにひっかかるため Visual Studio Code Remote Development code.visualstudio.com VSCode の拡張パック 名前はRemoteとあるが、リモートマシン上の開発の他、コンテナやWSL上での開発でも使用できる リモートマシン/コンテナ/WSL上関係なく、同じ感覚で開発ができる 参加者アンケートの結果 ・ Windows 環境でもWSL2( Linux ) + Dockerで開発環境を整えられてとても便利です！ ・ Linux 上なのでDockerのファイルアクセスも物凄く素早いです Regex Previewer marketplace.visualstudio.com 正規表現 チェックが VSCode 上で気軽に行える JSON to TS JSON からTypeScriptの型を生成してくれる Bookmarks シンプルにコードにブックマークをつけてサイドバー管理できる 修正のし忘れ防止や実装揃えたい時にとても便利である Bracket Pair Colorizer 2 marketplace.visualstudio.com 括弧の対応を可視化できる（ex：括弧に色がつく、範囲もわかる） Todo Tree marketplace.visualstudio.com プロジェクト中のTODOコメントなどを一覧化できる indent-rainbow marketplace.visualstudio.com インデントに色づけし深さを可視化できる Auto Rename Tag marketplace.visualstudio.com ペアになっているHTML / XML タグの名前を自動的に変更してくれる拡張である ◆ 開発者ツール / Chrome 拡張 Vue.js Devtools chrome.google.com Vue.jsで書かれたアプリの デバッグ が楽になる Vue.jsの開発をサポートするブラウザの 拡張機能 JavaScript Errors Notifier JSエラーをdevツールを開いていなくても通知してくれる DevTools z-index chrome.google.com devツールでz-indexが確認できるようになる Pesticide for Chrome chrome.google.com 要素に枠線が付くのでUI崩れやpadding,margin調整ミスに気付きやすくなる Firefox の開発ツール developer.mozilla.org Firefox でF12押したら出てくる開発ツール iMacros chrome.google.com 上記、 Chrome 用 参加者アンケートの結果 ・ブラウザマクロのアドオンで、JSソースを3個まで入れることが可能で便利 ◆ Webページ関連（参考情報系） MDN developer.mozilla.org Can I use caniuse.com HTML, CSS , JavaScript の機能についてブラウザの対応状況が分かるのが便利 IE 対応や、新しい機能を利用したい場合に参照すると便利 ◆ JSライブラリ json server www.npmjs.com REST API のモック作成が簡単に行える バックエンドに先行してフロントエンド開発を行う時には便利 htmlhint www.npmjs.com htmlの構文チェックを可能 vue.jsのv-htmlを利用制限を行う際に役に立つ Testing library testing-library.com 実装の詳細に関係なくUIのテストを書けるライブラリ Reactでは公式推奨のテストライブラリとなっている ◆ API 関連 Swagger swagger.io REST API の設計、 ドキュメンテーション 、モック作成などを行うツール群 OpenAPI仕様に準拠 Postman www.postman.com API クライアント 開発時に API のテストなどを行う際に任意のリク エス トを送信しレスポンスを受け取ることが可能 自動テストの機能など、テスト用機能の他、モックや ドキュメンテーション などの用途にも活用可能 WireMock wiremock.org API のモックツール リク エス トに対する多様なマッチング判定による柔軟性 リク エス トの記録／再生による効率的なモック作成可能 参加者アンケートの結果 一番簡単にサーバサイドのモックが作れると思っている Open API generator openapi-generator.tech 定義ファイルから言語に合わせた API リク エス トの ソースコード を生成する その他のツールとしては、 インテリセンス（コード補完など）ツールである Tabnene や kite 、 Bootstrapなどと同じ CSS フレームワーク の一種である tailwindcss などがあげられました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 2021年度開催 「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe #2 rakus.connpass.com 3/10に開催した「「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe」が大好評ということもあり、2021/6/16に同テーマにて再演しました！ ＜ ラク スエンジニアのお薦めのツール類 ＞ ◆ VSCode 拡張 Jest Runner テスト関数ごとに1クリックでrun/debugできるので便利 ◆ Google Chrome 拡張 OneTab chrome.google.com 開発に使うわけではないが、 chrome のタブをストックしておくツール 調べ物などで大量にタブを開いておくと、どこになにがあるかわからなくなったりメモリを使うので一時退避にオススメ Awesome Screenshot chrome.google.com 画像・映像キャプチャの取得、ダウンロード、共有をまとめて行える chrome の画面だけではなく、デスクトップ画面全体やカメラのみにも対応 stylus chrome.google.com ページに好きな CSS を設定でき、保存もできる などなど、前回ご紹介したツール等も踏まえてフロントエンド開発に欠かせない便利ルール・設定・ プラグイン をご紹介させていただきました！ 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「再入門！フロントエンドエンジニアが押さえておくべき技術」を語るフロントエンドTechCafe rakus.connpass.com 2021年度最後のフロントエンドTechCafeは、 ラク スのフロントエンドエンジニアの目線から押さえておくべき技術を6テーマにてご紹介しました。 本テーマは、弊社フロントエンドエンジニアが執筆した以下記事を参考にしておりますので合わせてご確認ください！ tech-blog.rakus.co.jp ＜ JavaScript ＞ ◆ DOM操作の仕方 DOM(DocumentObjectModel）とは、ブラウザが表示しているHTMLの要素を JavaScript で操作しやすいようにしたデータ構造です。 また、「操作しやすい」といっても、最近では直接DOMを扱うこと自体を避けるようにもなってきています。 【DOM操作の例】 <!DOCTYPE html> < html > < head > < meta charset = "utf-8" > < title > タイトル </ title > </ head > < body > < section > < img src = "example.png" > < p > リンクは < a href = "https://foo.example.com/" > こちら </ a ></ p > </ section > </ body > </ html > リンクの要素を取得する const link = document.querySelector('a'); リンクの文字列を変更する link.textContent = 'あちら'; リンクのURLを変更する link.href = 'https://bar.example.com'; ◆ ES6（ES2015）以降の記法 ES( ECMAScript )とは、 JavaScript の標準規格を定めたものです。 JavaScript と ECMAScript の関係ですが、 JavaScript はあくまでブラウザ上で動作する スクリプト言語 で、厳密にはブラウザによって仕様が異なります。 ECMAScript は、 JavaScript の標準規格で、各ブラウザは ECMAScript の仕様に沿って JavaScript を開発しています。 ◆ API 呼び出し フロントエンド開発ではバックエンドの API 呼び出しの知識が必須となります。 この辺りもJS フレームワーク 任せなことが多いが、基礎知識として覚えておくと良いと思います。 API 呼び出しの書き方例は以下の通りです。 【FetchAPI】 // APIを呼び出した結果をconsoleログに出力 const url = 'https://foo.example.com/api' async function callApi() { const res = await fetch(url); const text = await res.text(); console.log(text); } callApi(); XMLHttpRequest （XHR）と jQuery での書き方は、 ShowNote をご確認ください！ ＜ TypeScript ＞ ◆ TypeScriptの特徴 JavaScript に変換されれます。 また、TypeScriptで書かれたプログラムを実行したい場合、TypeScriptをそのまま実行するのではなくTypeScriptを JavaScript に変換させて実行します。 // typescript const foo: string = 'foo' ; 👇 // javascript "use strict" ; var foo = 'foo' ; ＜ フレームワーク ＞ フロントエンド フレームワーク とは、UIの コンポーネント 化やリアクティブなデータバインティング処理をまとめたものです。 ◆ フロントエンド フレームワーク の種類 以下、メジャーなものを抜粋しました。 Vue.js jp.vuejs.org 特徴 公式ドキュメントの日本語訳が多い SFC （単一ファイル コンポーネント ）を採用 React ja.reactjs.org 特徴 公式でUIライブラリと言っているがVue.jsとよく比較される Angular angular.jp 特徴 TypeScript標準採用（＝開発に必須） フルスタックフレームワーク を自称しており、Viewの構成だけでなく一通りの機能が入っている 当日は フレームワーク の世界/日本のシェア率を比較したりしました！ その他に、 コンポーネント 指向や仮想DOMについても分かりやすく整理し、参加者の皆さんで語り合いました。 ＜ ④SPA（Single Page Application） ＞ SPAとは、（極めてざっくり言うと）ユーザーがアクセスするWebページは空の最初の１ページのみで、バックエンドの API を呼び出し動的に画面の要素の構築、画面遷移を行うタイプのアプリケーションことです。 近年では、Webアプリケーションでも、 スマートフォン のアプリのような柔軟で表現に富んだ操作性や体験が求められることが多くなったため、SPAが重要とされております。 ＜ テスト ＞ ◆ テストの種類 テストの種類は以下があげられます。 イベント当日は、各テストのメリット/デメリットについてお話ししました。 静的テスト 単体テスト 結合テスト E2Eテスト ＜ メジャーなブラウザ ＞ 最後にメジャーなブラウザについてご紹介しましたが、時間が限られおり読み上げる程度で終了してしまいました…。 取り上げたブラウザは以下の通りです。 Google Chrome Internet Explorer Firefox Safari Microsoft Edge 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io ラク スのエンジニアと話をしてみたい方へ ラク スでは、フロントエンドエンジニアだけでなく幅広い職種で採用を強化しております。 とはいえ、まだ応募する段階ではないという方には カジュアル面談 をご案内しております！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんとお話をしたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 まとめ フロントエンド関連の最新ニュース・記事について語り合う、「フロントエンドTechCafe」のまとめはいかがでしたでしょうか？ フロントエンドエンジニアを目指している方 フロントエンド領域を学習し始めた方 再度学習されたい方 などにとって本ブログ及び、フロントエンドTechCafeが有意義な情報となっていますと幸いです。 2022年度もフロントエンドTechCafeの開催を予定しております！ ご興味持たれる方がおりましたら、是非ご参加くださいませ。 次回、フロントエンドTechCafeは、 ラクスconnpassページ にてご案内させていただきます。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、クリエイティブ課　木村圭です。 クリエイティブ課は、 ラク スグループ内で提供しているサービスに関するWebサイトやパンフレットなどのデザイン業務を担っています。 現在、マネージャー職をしていますが、前職までUI/UXデザイナーをしておりました。 僕自身が、これまで学習した書籍や最新の関連書籍を含め、ご紹介します。 これから、UI/UXデザイナーを目指したい方やデザインにご興味のある方なども含め、ご参考になればと思います。 最初に読んでほしいUI/UX書籍はこれだ! ノンデザイナーでもわかる UX+理論で作るWebデザイン UI/UXデザインの原則 UIデザイン　みんなで考え、カイゼンする。 SF映画で学ぶインタフェースデザイン アイデアと想像力を鍛え上げるための141のレッスン ほんとに使える「ユーザビリティ」 -より良いデザインへのシンプルなアプローチ UI GRAPHICS 成功事例と思想から学ぶ、これからのインターフェイスデザインとUX UXデザインの教科書 UXデザインの法則 ―最高のプロダクトとサービスを支える心理学 UX戦略 ―ユーザー体験から考えるプロダクト作り インタフェースデザインのお約束 ―優れたUXを実現するための101のルール はじめてのUXリサーチ ユーザーとともに価値あるサービスを作り続けるために UXライティングの教科書 ユーザーの心をひきつけるマイクロコピーの書き方 あわせて読んでほしい書籍はこれだ! バグトリデザイン 事例で学ぶ「行為のデザイン」思考 人間中心設計入門 (HCDライブラリー) インタフェースデザインの心理学 第2版 ―ウェブやアプリに新たな視点をもたらす100の指針 行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する ビジネスデザインのための行動経済学ノート バイアスとナッジでユーザーの心理と行動をデザインする デザインリサーチの教科書 未来ビジネス図解 これからのデザイン思考 はじめてのカスタマージャーニーマップワークショップ「顧客視点」で考えるビジネスの課題と可能性 できたら読んでほしい書籍はこれだ! ノンデザイナーズ・デザインブック なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 DX 時代のサービスデザイン Good Service DX時代における"本当に使いやすい"サービス作りの原則15 「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ 融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 101デザインメソッド ―― 革新的な製品・サービスを生む「アイデアの道具箱」 脳のしくみとユーザー体験 認知科学者が教えるデザインの成功法則 「ユーザーフレンドリー」全史 世界と人間を変えてきた「使いやすいモノ」の法則 カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで コンヴィヴィアル・テクノロジー 人間とテクノロジーが共に生きる社会へ ラクスのデザイナーにもおすすめ書籍を聞いてみました! 大人気のデザイン書シリーズ けっきょく、よはく。 余白を活かしたデザインレイアウトの本 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 誰のためのデザイン？ さいごに ラク スのデザイナーについて知りたい方は、以下記事をご参考ください！ tech-blog.rakus.co.jp 最初に読んでほしいUI/UX書籍はこれだ! 「UI」「UX」に関連した書籍を抜粋しました。 古い書籍もありますが、体系的に学べたり、そこから新しい気づきがあったりすることもあります。 ノンデザイナーでもわかる UX+理論で作るWebデザイン 川合 俊輔 (著), 大本 あかね (著), 菊池 崇 (監修) 「ノンデザイナーでもわかる」と書籍タイトルにある通り、基礎から考え方、実践まで簡潔にまとめられています。 「UX」を理解することから始まり、UXをビジネスに役立たせる方法を紹介し、WebサイトのUI設計への話を進め、具体的なデザイン手法について解説されています。本書にも書かれていますが、章ごとに内容が区切られているため、読みたいところから進めて行くことも可能です。 ・理論に基づいたデザインが実装可能になる ・人間心理をベースに、デザインの良し悪しを判断することができる ・UX設計からUIデザインにする方法が学べる ・Webでのデザイン思考が身につく まずは基礎から学んでみるのはどうでしょうか。 UI/UXデザインの原則 平石 大祐 (著) 「ユーザー心理/行動に則って考える」ことがUI/UXデザインの第一歩である UI/UXデザイナーに求められるレベルも年々あがってきており、UI、UXの違いを理解すること、ユーザーニーズを正しく理解し、それをUI/UXに落としこむことが重要になる。結果、ビジネスの可能性を高めることにつながることが書かれています。実例も紹介されており、内容としても非常に読みやすいです。 UIデザイン　みんなで考え、 カイゼン する。 栄前田 勝太郎 (著), 河西 紀明 (著), 西田 陽子 (著) UIデザインの業務を体系的に学べます。 「デザインプロセス」そのものをプロジェクトチーム全体で共有しながら開発を進めていく手法の具体的な中身と、どのようにして現場で取り入れていけばよいのかを、事例も交えながら、できるだけわかりやすく伝えています。またUIをデザイナーだけでなく「チームで作り上げる」という視点からも解説されています。デザイナーやエンジニア、UI/UXに興味のある方にとって、誰のための「デザイン」なのか、あらためて考えるきっかけになるかもしれません。 SF映画 で学ぶインタフェースデザイン ア イデア と想像力を鍛え上げるための141のレッスン Nathan Shedroff (著), Christopher Noessel (著), 安藤 幸央 (監修, 翻訳), 赤羽 太郎 (翻訳), 飯塚 重善 (翻訳), 他 2014年刊行の古い書籍です。 SF映画 からインターフェースデザインを学ぶというテーマで書かれています。実際、世の中に登場していなかった、携帯電話やタッチパネルなど映画の世界では10数年以上も前に登場していたりします。 「 スター・トレック 」「 スター・ウォーズ 」「アイアンマン」などを実例として、紹介されています。またインターフェースだけでなく、しっかりと作り込みがされていますので、映画の中で配色も学ぶことができるのではと思います。 書籍を通して、現在の SF映画 を観ると新しい発見があったりするのではないでしょうか。 ほんとに使える「 ユーザビリティ 」 -より良いデザインへのシンプルなアプローチ エリック・ライス (著), 浅野 紀予 (翻訳) 「製品やサービスの ユーザビリティ を向上させ、より良い利用体験を実現するための方法とは」 UXデザインの第一人者であるエリック・ライスさんの書籍です。本書にも書かれていますが、思い出したくもないほどの長いことサービスデザインや製品デザインのプロジェクトの数々に首を突っ込んできたそうです。 「 ユーザビリティ 」とは何かからはじまり、豊富な事例をもとに ユーザビリティ の問題を洗い出し、解決するための手法をまとめた実践的ガイドブックとなっています。各章ごとに10箇条のチェックリスト、おすすめ書籍、キーワードが掲載されていて、2013年刊行ではありますが、実用性の高い内容だと思います。 UI GRAPHICS 成功事例と思想から学ぶ、これからの インターフェイス デザインとUX 安藤剛 (著), 水野勝仁 (著), 萩原俊矢 (著), ドミニク・チェン (著), 菅俊一 (著), 鹿野護 (著), 有馬トモユキ (著), 他 インターフェイス に向き合うデザイナーたちの実践と思考を記録した、2015年刊行の新版です。世界の成功実例と、この領域に携わる研究者および実践者の知見を得ることができます。本書は、2018年刊行ですが、僕自身は振り返る場として読んでいたりします。UI/UXデザイナーは、常に世の中のデザインとふれていることが重要だとあらためて実感できると思います。 スクリーンショット など写真が多数掲載されてますので、アプリケーションの時代ごとの配色なんかも気づきがあるかと思います。 UXデザインの教科書 安藤 昌也 (著) 「ユーザーエクス ペリエ ンス(UX)」とは何か。 「ユーザー体験(UX)」を軸とし「UXデザイン」について、1.概要、2.基礎知識、3.プロセス、4.手法と体系的に学んでいくことができます。また教科書というタイトル通り、様々な専門用語の基礎知識から、魅力的な製品・サービスをデザインするための流れとその手法がしっかりと書かれています。人に説明するときにも、内容が活用できたりします。 ・UXデザインをはじめたい人 ・UXデザインに悩んでいる人 ・UXデザインを極めたい人 UXデザインの法則 ―最高のプロダクトとサービスを支える心理学 Jon Yablonski (著), 相島 雅樹 (翻訳), 磯谷 拓也 (翻訳), 反中 望 (翻訳), 松村 草也 (翻訳) 「なぜこのデザインがいいのか?」 著者Jon YablonskiさんがUXデザインと交差する心理学の法則をまとめたウェブサイト「Laws of UX」を元に構成されています。 「意思決定にかかる時間は選択肢の数と複雑さで決まる」、「タッチターゲットに至るまでの時間はターゲットの大きさと近さで決まる」などの10の法則を、各章において、ポイント、概要、起源、事例、結論にまとめて紹介されています。なるほどと思う法則や考え方など事例とともに解説されており、読みやすいです。面白くてあっという間に読み終わると思います。僕はそうでした。 UX戦略 ―ユーザー体験から考えるプロダクト作り Jaime Levy (著), 安藤 幸央 (監修), 長尾 高弘 (翻訳) 本書は、企業戦略としてユーザー体験の価値向上を取り入れ、プロダクトを成功へと導く「UX戦略」についての解説書となります。 UX戦略の考え方にもとづき 潜在的 顧客、競合他社製品、バリュープロポジション(提供価値の創造)といった要素の分析や評価を行い、革新的ユーザー体験を持つプロダクトを作り出す手法について、著者の豊富な経験から実例を使って解説されています。デザインとビジネス戦略を起点とし、何をしていく必要があるか学べると思います。 UXはデザイナーだけでなく、製品開発に関わる全職種のメンバーが考えるべきと書かれており、どちらかというとマネージャーやサービスをリードする方に読んでもらいたい書籍になります。 インタフェースデザインのお約束 ―優れたUXを実現するための101のルール Will Grant (著), 武舎 広幸 (翻訳), 武舎 るみ (翻訳) 「優れたUXを実現するための101のルール」 本書では、デジタル製品のデザインに役立つ広範な指針がまとめられています。 製品の ユーザビリティ や性能を高める上で必須かつ基本のツボをマスターすれば時間を節約し 顧客満足度 をアップできるテクニックがコンパクトなルールとして紹介されています。説明もわかりやすく、読みやすいと思います。 タイポグラフィ 、コン トロール 、カスタマージャーニー、各種要素の統一、UX全般に関わるプ ラク ティスに分類されているのでリファレンス的に読むことも可能です。ユーザーエクス ペリエ ンスを向上させるための指針を学んでいけます。 はじめてのUXリサーチ ユーザーとともに価値あるサービスを作り続けるために 松薗 美帆 (著), 草野 孔希 (著) 弊社にはまだありませんが、職種として「UXリサーチャー」を採用している企業を最近よく見かけると思います。 そもそも「UXリサーチ」とは何をしているのでしょうか。本書では、現役リサーチャーの方が、解説してくれています。適度に図やイラスト、写真なども入っていて、すごく読みやすいです。 「UXリサーチ」に興味がある方、何から始めたらいいか悩んでいる方にお勧めです。 UXライティングの教科書 ユーザーの心をひきつけるマイクロコピーの書き方 仲野 佑希 (監修), キネレット・イフラ (その他), 郷司 陽子 (翻訳) 「マイクロコピー」を知っていますか。 みなさんが目にする、送信フォーム上のボタン、登録フォーム、エラーメッセージなどに表示される1行のテキストのことを指しています。 本書を読むことで、たった1行のマイクロコピーがユーザーの行動に影響することを理解し、どのように書くべきか、どこに配置するべきか学べると思います。 あわせて読んでほしい書籍はこれだ! より人を理解すること、心理学や行動から学べる書籍となります。 バグトリデザイン 事例で学ぶ「行為のデザイン」思考 村田 智明 (著) 「人の行為に注目すればあるべきデザインが見えてくる」 この本を読んだとき、衝撃を受けました。ものすごく整理されており、学びがたくさんあります。人の行為を、時間を追って観察していけば、それを妨げるもの、それが「バグ」。 6つのバクとして定義されており、非効率、迷い、矛盾、負環、心理、誤認で分類されています。それぞれのバグについて、事例をもとに解説されています。「行為のデザイン」のワークショップの ケーススタディ も紹介されており、進め方も記述されています。 人間中心設計入門 (HCDライブラリー) 山崎 和彦 (著), 松原 幸行 (著), 竹内 公啓 (著), 黒須 正明 (編集), 八木 大彦 (編集) 「人間中心設計(HCD)」として初めて刊行された入門書になります。 人間中心設計とは、 ユーザビリティ 、ユーザエクス ペリエ ンス(UX)、デザイン思考の共通の基盤となる考え方です。 本書は、節が見開きで構成されており、図や表が多数配置されていて、初めての方にとっても非常にわかりやすいと思います。シリーズで出版されています。 インタフェースデザインの心理学 第2版 ―ウェブやアプリに新たな視点をもたらす100の指針 Susan Weinschenk (著), 武舎 広幸 (翻訳), 武舎 るみ (翻訳), 阿部 和也 (翻訳) 行動心理学者 スーザン・ワ インチェ ンクさんが2012年に刊行された書籍の改定版です。 人はどう見るのか、人はどう読むのか、人はどう記憶するのか、人はどう考えるのか、人はどう注目するかなど、全10章にわかれて解説されています。科学的な研究から導き出された、100の指針を例とともに紹介されています。デザイナーだけでなく、企画やエンジニアの方にもおすすめの本です。 行動を変えるデザイン ―心理学と 行動経済学 をプロダクトデザインに活用する Stephen Wendel (著), 武山 政直 (監修), 相島 雅樹 (翻訳), 反中 望 (翻訳), 松村 草也 (翻訳) 本書は、 行動経済学 と心理学をもとに、人々の行動、日常習慣を変える「行動変容」を促すプロダクトをデザインしていくための書籍です。実践的な知識や視点を学ぶことができます。行動には、あらかじめ5つのことが直前に生じています。ユーザーの行動が実行されるために通過しないといけない5つのステージ「キュー、反応、評価、アビリティ、タイミング」があり、「CREATEアクションファネル」として紹介されています。このアクションファネルは、どこで人々が離脱したのか把握することができます。デザイナーだけでなく、サービスや製品開発に携わる方も必見です。 ビジネスデザインのための 行動経済学 ノート バイアスとナッジでユーザーの心理と行動をデザインする 中島 亮太郎 (著) 「 行動経済学 の本ですが、むずかしい専門書ではありません。」 と書かれている通り、デザイナー視点で図解されていたり、最初から要約が掲載されており、非常にわかりやすいと思います。 テーマとしては「 行動経済学 をビジネスデザインに活用すること」 行動経済学 の理論を知るだけでなく、新しいサービスやプロダクトの開発に活用することが目的と書かれています。 ・個別の理論ではなく全体構成で仕組みを理解できる ・図で多く用いることで理論がパッと見てわかる ・ 社会心理学 やデザインなどの観点も織り交ぜている ・商品やサービスなどへの活用方法に言及している ・実際のビジネスを想像しながら読むことで楽しく学べる デザインリサーチの教科書 木浦幹雄 (著) 僕自身、「デザインリサーチャー」という職種があることをこの書籍を読むまで知りませんでした。 本書では、「デザインリサーチ」の入門書として、「1章.デザインのトレンド」「2章.デザインリサーチの概要」「3章.デザインリサーチのプロジェクトの進め方」「4章.デザインリサーチの導入・運用」の構成で紹介されています。 読み進めていくことで、デザインリサーチの重要性が理解できると思います。 新しいプロダクトをつくられる方、既存プロダクトを改善を検討されている方、おすすめです。 未来ビジネス図解 これからのデザイン思考 小山田 那由他 (著) 「デザイン思考」とは何か。 そもそも「デザイン」とは何かからはじまり、プロセス、様々な領域の製品・サービスの ケーススタディ ーが掲載されており、事例を通してデザイン思考の実践に役立つ内容を学んでいけます。また、イラストなども豊富で非常にわかりやすくまとめられています。 はじめてのカスタマージャーニーマップワークショップ「顧客視点」で考えるビジネスの課題と可能性 加藤 希尊 (著) 「顧客はどのような体験をし、何を感じているのか?」 顧客視点で始め、自社視点で今の状況を見直し、改善していく。「カスタマージャーニーマップ」の有効性、マップを作成するためのワークショップの方法、まとめ方など解説されています。活用事例も掲載されていてお勧めです。サービスに携わるチームでワークショップを展開することで、チーム内の意識統一やコミュニケーション力向上にもつながる可能性大です。 できたら読んでほしい書籍はこれだ! UI/UX視点から少しずれますが、デザインをしていく方はもちろん、サービスに携わる方にぜひ読んでほしい書籍です。 ノンデザイナーズ・デザインブック Robin Williams (著), 米谷 テツヤ (監修, 翻訳), 小原 司 (監修, 翻訳), 吉川 典秀 (翻訳) 2004年刊行から、第4版まで刊行されているロングセラーの書籍です。 良いデザインの作品に共通している「4つの基本原則」が紹介されています。 読みやすい、伝わる、わかりやすいなど、デザインの見た目をよくしていくためにはどんな点に気をつけるべきか学べます。 デザイナーではない方にも、おすすめの基本となる一冊です。 なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 筒井 美希 (著) デザインに関するものごとを「目で見て楽しめる」形にまとめられた書籍となります。文字組み、言葉、文章、色、写真、グラフ・チャートなど参考事例とともに紹介されています。デザインを良くするヒントが、タイトル通り目で見て学んでいけます。テザイン本ですが、UIデザインにも活用できる学びがあると思います。デザイナーだけでなく、デザインに興味のある人にもおすすめです。 DX 時代のサービスデザイン 廣田章光 (著, 編集), 布施匡章 (著, 編集), 瀨良兼司 (著), 井登 友一 (著), 仙波 真二 (著), 宗平 順己 (著), 山縣 正幸 (著) 本書にも書かれていますが、DXという言葉を目にする機会が増えていると思います。DXとは「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念だそうです。このDX時代に、サービスを受ける人の体験と感情の価値を最大化するためにはどうしたらいいのか。サービスデザインを通して、基礎、顧客理解、事業創造など順序だてて学んでいけると思います。 Good Service DX時代における"本当に使いやすい"サービス作りの原則15 ルー・ダウン (著), ヤナガワ智予 (翻訳) 「サービスとは何か?」 本書は、イギリス政府でデジタル改革を推し進めてきた著者が教える、デジタル・トランスフォーメーション(DX)時代のサービスデザイン入門です。 DX時代における「本当に使いやすい」サービス作りについて15の原則でまとめられています。あらゆるサービスに関わる方にぜひ読んでいただきたい本になります。 「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ 玉樹 真一郎 (著) 「あらゆる人の心を動かす方法」 任天堂 で Wii というゲーム機の企画を担当されていた玉樹真一郎さんが書かれた書籍になります。当時「ゲームはどうやって心を動かしているのか?」について議論・分析・研究を重ね、学び、商品企画に活かしていたそうです。 本書では、1.「つい」やりたくさせてしまう、2.「つい」熱中させてしまう、3.「つい」誰かに言いたくさせてしまう、という3つの手法について体系的に紹介されています。誰もが遊んだことのあるあのゲームから解説されて読み進めていくのも楽しいと思います。 融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 渡邊恵太 (著) 「世界が変わったのだから、デザインも変わらなくてはならない」 2015年刊行の書籍ですが、今読んでも発見があると思います。 テク ノロ ジー の進歩により、ますます変容する世界を捉え、デザインしていくためには? これからのものづくりのための最重要キーワード「自己帰属感」を軸に、情報を中心とした設計の発想手法を解き明かす。UXやIoTの本質を掴みたい人に向けて書かれている本です。 101デザインメソッド ―― 革新的な製品・サービスを生む「ア イデア の道具箱」 ヴィジェイ・クーマー (著), Vijay Kumar (著), 渡部 典子 (翻訳) 本書では、 イノベーション のプロセスを7つのモードにわけています。 「1.目的を見出す、2.コンテクストを知る、3.人々を知る、4. インサイト をまとめる、5.コンセプトを探求する、6.解決策を練る、7.製品・サービスを実現する」 各モードごとに多数のメソッドが紹介されています。プロジェクトを進めるにあたり、チームや仲間と取り組むことで、意識統一や振り返ることなど、活用できそうな内容だと思います。UI/UXデザイナー以外でもおすすめな一冊です。 脳のしくみとユーザー体験 認知科学 者が教えるデザインの成功法則 ジョン・ウェイレン (著), 高崎拓哉 (翻訳) ユーザー体験は、「脳内」で起きている。脳の6つの認知プロセスを知ることで、ユーザーの心をつかむことができ、最高の体験をデザインしていくことができる。 本書では、人の体験を構成する要素「シックス・マインド(視野・関心/記憶/感情/意思決定/言語/空間認識)」を理解し、顧客のニーズや視点をより正確に特定できるようになるための方法が解説されています。その知識を製品やサービスのデザインに応用する方法を学ぶ実践書となります。 「ユーザーフレンドリー」全史 世界と人間を変えてきた「使いやすいモノ」の法則 クリフ・クアン (著), ロバート・ファブ リカント (著), 尼丁 千津子 (翻訳) 「ユーザーフレンドリー」とは、使いやすいこと、わかりやすいこと、扱いやすいこと。経験の浅いユーザーにとって使いやすい、わかりやすいこと。ユーザーのニーズを念頭に置いてデザインされたもの。 コンピューターが登場し、インターネットが普及しはじめ、誰もが情報を取得できるようになり、現代だと、 スマートフォン が登場し、人々の生活をさらに一変させたと思われます。「ユーザフレンドリー」が社会に浸透してきた歴史から、世界と人間を変えてきた「使いやすいモノ」の法則を学んでいけます。 カイゼン ・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 市谷 聡啓 (著), 新井 剛 (著) 本書は、ソフトウェア開発に携わる人を対象として書かれているのですが、チームとして活動していこうとしている方、チームの取り組みで悩まれている方などにとっても気づきのある一冊だと思います。 アジャイル をこれから始める人などにもおすすめです。 コンヴィヴィアル・テク ノロ ジー 人間とテク ノロ ジー が共に生きる社会へ 緒方壽人 (著) 「コンヴィヴィアリティ」 思想家イヴァン・ イリイチ が提唱した概念を足がかりに、これからの人間とテク ノロ ジー のあり方について紹介されています。人間は道具をつかっているつもりで、実は道具に使われていてと冒頭に書かれているのですが、確かに、誰もが スマートフォン をもつ世の中となり、 スマートフォン をさわっていない日はない気がします。第3章「人間とデザイン」でデザインについてふれられています。あらためて考えさせられることがあると思います。 ラク スのデザイナーにもおすすめ書籍を聞いてみました! 以下、 ラク スのデザイナー達が選んだ「おすすめの書籍」です。 前述にてご紹介した書籍も何冊かあるかと思います。 ランキング概要 手法：任意アンケート（ ヒアリ ングシート）　※複数回答可 対象： ラク スのデザイン組織メンバー 有効回答数：24名 ランキング内容：投票数2票以上の技術書 順位 書籍名 投票数 1 なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 8票 2 けっきょく、よはく。 余白を活かしたデザインレイアウトの本 6票 3 オブジェクト指向 UIデザイン──使いやすいソフトウェアの原理 5票 4 ノンデザイナーズ・デザインブック 2票 4 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 2票 4 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 2票 4 誰のためのデザイン？ 2票 『なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉』と『ノンデザイナーズ・デザインブック』は 私の方でも紹介させていただきましたので、それ以外の書籍を簡単にご紹介させていただきます。 大人気のデザイン書シリーズ けっきょく、よはく。 余白を活かしたデザインレイアウトの本 ingectar-e (著) どんなデザインにも余白があると思います。余白をうまく使いこなすことで、情報の整理につながり、結果、洗練されたデザインとなる。事例を紹介しつつ、色、フォントなど学べることがあると思います。 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 ingectar-e (著) 「いいデザインはあしらいがていねいなんだ!」人気シリーズの第3弾です。「あしらい」とは「装飾」「ディテール(細部)」のこと。NG例から問題点を洗い出し、OK例を提案し、どんな修正を行ったかについて解説されています。 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 ingectar-e (著) 人気シリーズの第2弾です。いろんなフォントがあり、どれを選べば、どう使えばいいのか。 「センス」がとわれます。たくさんの使用例とともに、センスを磨いていけると思います。 オブジェクト指向 UIデザイン──使いやすいソフトウェアの原理 ソシオメディア株式会社 (著), 上野 学 (著, 監修), 藤井 幸多 (著) 「 銀の弾丸 、OOUI。」かなり インパク トのある表紙です。 オブジェクト指向 ユーザーインターフェース (OOUI)とは、目当てとなるオブジェクトを起点としてUIを設計することになります。対象を選んでから行動におこす。実践演習も紹介されているので、学びながら理解していけると思います。 誰のためのデザイン？ D.A.ノーマン (著) 初版刊行からロングセラーとなっている書籍です。冒頭にある「どんな新しいテク ノロ ジー が出現するか予測できる人もいない、だが確実に予測できるのは、本書に述べるデザインの原則は変わらず残るということである。」デザイナーだけでなく、製品やサービスに携わる方に読んでほしい一冊です。 さいごに いかがでしたか。気になる書籍は見つかりましたか。 少しでも興味のある本があれば、ぜひ、手にとって読んでいただけると幸いです。 あなたにとって最良の本との出会いがあることを祈っております。 また、 ラク スでは、現在、UIデザイナー、 Webデザイナー を募集中となります。 書籍の購入費補助もあります。 ご興味ある方いましたら、ぜひ、下記採用サイトから、ご連絡ください。 尚、カジュアル面談も大歓迎です。UI/UX、デザインについてお話しましょう。お待ちしております。 クリエイティブ課　木村圭 おすすめの技術書を紹介している、以下関連ブログも是非ご確認ください！ 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

はじめに こんにちは。 ラク スでインフラを担当しております渡邊(kw21)と申します。 今回はサーバ・アプリケーションの 冗長化 に今なお広く利用されているHA クラスタ ソフト「Pacemaker」について、 特にActive/Standby(1+1)構成 クラスタ で発生しうるスプリットブレインに焦点を当ててご紹介いたします。 はじめに HAクラスタとは？ Pacemakerとは？ クラスタノード間の通信とインターコネクト スプリットブレインとは？ クォーラム(定足数)とは？ 2ノード構成でのクォーラムの考え方とPacemakerでスプリットブレインを防ぐ仕組み スプリットブレイン発生後の対処 Pacemaker まとめ 参考 HA クラスタ とは？ HA クラスタ とは「複数のコンピュータをつなげ、全体で1つのコンピュータのように振る舞わせることでシステム全体の 稼働率 を高める技術」のことです( LINUX-HA JAPAN より引用)。HAは「High Availability」の略で日本語で高可用 クラスタ とも呼ばれます。 様々な開発コミュティ及びベンダーからHA クラスタ ソフトが提供されており、古いものでは30年ほど前から存在するパッケージもあります。 昨今では、 パブリッククラウド やコンテナ オーケストレーション を利用したシステム構築が主流になりつつありますが、オンプレミスな環境で冗長システムを構築する際の選択肢としてはHA クラスタ もまだまだ有力な候補のひとつです。 ＜HA クラスタ を利用して可用性を高めた例＞ 下図は2つのサーバでActive/Standby(1+1)構成 クラスタ を実装した例です。 クラスタ に組み込んだサーバは クラスタ ノード と呼ばれ、本記事内では1号機をノード#1、2号機をノード#2と表記しています。 通常運用時はActiveノードであるノード#1へクライアントからのアクセスを受けます。 ノード#1が何らかの障害でダウンした場合、それを検知した クラスタ ソフトがノード#2をStandbyからActiveに切り替え、ノード#2側でクライアントからのアクセスを受けられるようにします。　　 このように、Activeノードがノード#1からノード#2に切り替わることを フェイルオーバー と呼びます。　　 HA クラスタ ソフトでシステムを 冗長化 するとフェイルオーバーにより障害発生時のダウンタイムを最小化させることができます。　　 本記事内では主にActive/Standby(1+1)構成 クラスタ を取り上げていますが、その他にも両現用として稼働させるActive/Active(1+1)構成や、Standbyサーバを複数用意したN+1構成など、ソフトや目的によって様々なシステム構成を選択することができます。 Pacemakerとは？ Pacemaker は OSS の代表的なHA クラスタ ソフトのひとつで、2022年2月現在は ClusterLabs というコミュニティが開発提供しています。 厳密にはPacemakerとはHA クラスタ ソフトを構成する コンポーネント の一つであるリソース制御機能部分の名前のことなのですが、Corosyncなどの他 コンポーネント を含めた クラスタ ソフト全体のことを指して便宜的にPacemakerと呼ばれることもあります。 HA クラスタ の コンポーネント としてPacemakerと組み合わせてよく利用される Corosync は主に クラスタ 制御機能を担っており、 クラスタ 内のメッセージングやクォーラム機能を提供しています。クォーラムについては後ほど詳しく紹介します。 Pacemakerで管理する対象のアプリケーションや IPアドレス のことを リソース と呼び、Active/Standby(1+1)構成 クラスタ ではActiveになったノードでリソースが起動します。 Pacemakerには様々なアプリケーションをPacemakerリソースとして扱うためのリソースエージェント(RA)という コンポーネント も存在し、例として下記のような種々のアプリケーションをリソース登録することができます。 仮想 IPアドレス ：各 クラスタ ノードのローカル IPアドレス とは別に、Activeノードでのみ有効になる IPアドレス を設定できます。「virtual ip」を略して「vip」とも呼ばれます。 共有ディスク ： クラスタ ノードとは別の NFS サーバなどをリソースとして設定します。Activeノードがを NFS サーバの共有領域をマウントして読み書きを行うことで、フェイルオーバーした際に新たにActiveとなったノードからも引き続き NFS サーバ上のデータを読み書きすることができます。 Webサーバ・DBなどの ミドルウェア ： Apache や PostgreSQL など、アプリケーションとして利用したいsystemdサービスを設定できます。ノードがActiveになると同時にリソースとして該当サービスも起動されます。 Pacemakerは クラスタ ノード上のリソースの起動状態を監視しており、リソース故障を検知すると設定に従ってフェイルオーバーやリソースの再起動・停止などを行います。 リソース故障 とは、Pacemakerで管理されるリソースに何らかの異常が発生したことを指しており、例えば「リソース設定した共有ディスクのサーバがダウンし、マウントできなくなった」「リソース設定した PostgreSQL サービスが停止した」などの事象がこれにあたります。 また、Pacemakerの クラスタ やリソースについての設定は pcs というツールを利用します。 pcsはコマンドやWebUIでPacemaker クラスタ を管理するための コンポーネント で、各種設定及びPacemaker クラスタ の起動停止や状態確認の機能も提供しています。 クラスタ ノード間の通信とインターコネクト 各 クラスタ ノードの死活監視・リソース状態監視を行うために、 クラスタ に所属する各ノードは同一ネットワーク上で疎通可能な状態である必要があります。 クラスタ ノード間を通信させるLANのことを インターコネクト (または系間LANやハートビートなど)と呼びます。 構築するサーバやネットワークの設計方針にもよりますが、インターコネクト用のVLANを作成したり通常のLANと兼用させたりする場合もあれば、1+1構成の両サーバをLANケーブルで直接繋いで疎通させるような場合もあります。 ノード間の死活監視がインターコネクトを通して行われている以上、インターコネクトが疎通できなくなることは各ノードにとって対向ノードがダウンしたこととほぼ同義であり、 インターコネクトはHA クラスタ の安定稼働における大変重要な要素 となっています。 例えば、インターコネクトに何らかの異常が発生し クラスタ ノード間の通信が切れた場合、下図のようにノード#1とノード#2はそれぞれお互いのノードの疎通が取れなくなるため、「ノード#2(または#1)がダウンした」という判定になります。 インターコネクトが単一の障害ポイントとならないよう、設計時によく考慮する必要があります。 Pacemaker/Corosyncの クラスタ の場合はcorosync.confで各ノードで利用するインターコネクトの経路を設定することができ、複数の経路を指定することでインターコネクトを 冗長化 することもできます。 Pacemaker クラスタ でノード間の通信が切れてしまった場合に各ノードはどういった挙動をとるのか、次の項で説明します。 スプリットブレインとは？ スプリットブレイン (split brain)とは、インターコネクトが切れるなどの原因でノード間の疎通が取れなくなった際にStandbyノードがActiveに切り替わることにより、同一環境内に本来複数存在してはならないActiveノードが複数発生してしまう状態のことです。 設定されているリソースの内容にもよってはデータ破損やIP競合が発生し、重大な事故に繋がる可能性があります。 下図の例ではActive/Standby(1+1)構成のPacemaker クラスタ でスプリットブレインが発生し、ノード#1とノード#2両方がActiveとなり、リソースが両方のノードで起動してしまった例です。 本来1ノードからの書き込みしか無い設計だったディスクに対し、複数のノードからの書き込みが発生しデータ破損・ロストが発生してしまう可能性があります。 私自身が経験した例だと、Active/Standby(1+1)構成でノード#1の NIC 故障が発生し、一時的にインターコネクトが不安定になった結果、ノード#1がActiveのままノード#2もStandbyからActiveに切り替わってしまったことがありました。 インターコネクト切断時にスプリットブレインが発生するか否かに関わる要素として、次の項ではPacemakerにおいてクォーラムという考え方で各ノードの挙動を制御する設定について紹介します。 クォーラム(定足数)とは？ HA クラスタ における クォーラム (quorum・定足数)とは、一言で表すと「 HA クラスタ として動作できる権利を得るための、自ノードが通信できるノード数の最低数 」のことです。 分かりづらいため、下図で3台構成の クラスタ での例を示します。 クラスタ に所属するノード#1・#2・#3のうち、インターコネクトの異常等によりノード#1のみ疎通できなくなったとします。 この状態から「ノード#1」と「ノード#2・#3」のどちらがHA クラスタ として稼働を継続できるか、投票システムのような形で判定されます。 各ノードは「自分を含めいくつのノードと疎通ができるか」という数を認識しており、図の場合、ノード#1はノード#2・#3とは疎通できないため自分自身のみの投票数で 1 。ノード#2・#3はそれぞれ自分自身とお互いは疎通できるため、投票数はそれぞれ 2 。 通常、3ノードの 過半数 である"2"がクォーラム(定足数)として設定されていることが多いため、クォーラムを獲得した「ノード#2・#3」側の クラスタ パーティション がHA クラスタ として稼働を継続します。 その後、設定に応じてノード#1は クラスタ から切り離され、ノード#2または#3がActiveとなってリソースが起動されます。 では、2ノードで構成されるActive/Standby(1+1)構成 クラスタ の場合はどのように判定されるでしょうか。 2ノード構成でのクォーラムの考え方とPacemakerでスプリットブレインを防ぐ仕組み 2ノード構成の クラスタ の場合、そもそも 過半数 という図式が成り立たないため、ノード#1と#2が切り離されたとしてもどちらもクォーラムを獲得することはできません。 Pacemakerにはクォーラム無しとなった場合の挙動を設定できる「 no-quorum-policy 」という クラスタ プロパティがあります。 no-quorum-policy では下記の4つのポリシーを選択することができます。 ignore 　：全リソースの管理を続行(=リソース起動状態にする) freeze 　：何もしない(動いてるものは動いたまま、止まってたものは止まったまま) stop (デフォルト)　：全リソースを停止する suicide 　：影響を受ける クラスタ ー パーティション 内の全ノードを排他処理(フェンシング)する no-quorum-policy を ignore 以外にしておけばインターコネクト切断時にもリソースが複数ノードで重複して起動する心配は無いのですが、しかしそれではActive/Standby(1+1)構成で突発的にActiveノードがダウンした場合にも同じ挙動が適用されてしまい、Standbyが機能しなくなってしまいます。 PacemakerでActive/Standby(1+1)構成を取る場合、Activeノードがダウンした際にフェイルオーバーして新たにStandbyノード側でリソース起動させるためには、 no-quorum-policy を ignore に設定しておく必要があります。 一方、 no-quorum-policy を ignore に設定した場合、前項で紹介したようなインターコネクト断が発生した際には ノード#1　：クォーラム獲得無しのためリソースは起動状態のまま ノード#2　：クォーラム獲得無しのためリソースは停止状態から起動状態へ という挙動となります。 したがって、PacemakerでActive/Standby(1+1)構成を実装する場合、障害のきっかけ次第ではスプリットブレインが発生し得る構成となります。 その上で、Pacemakerにはスプリットブレインを回避するための仕組みが複数存在します。 ＜スプリットブレインの発生を防ぐ仕組み＞ STONITH 　：制御 不能 となったノードを強制的に停止や再起動(フェンシング)させる機能です。各ノードの電源制御デ バイス へのアクセスが必要です。 SFEX 　：Activeノードが共有ディスク上にフラグを作成することで 排他制御 を行うリソースです。共有ディスクを使う構成で利用可能。 VIPcheck 　：インターコネクトは別の経路で仮想 IPアドレス の割当て状態を確認することで 排他制御 を行うリソースです。仮想 IPアドレス を使う構成で利用可能。 上記の 排他制御 を利用せずスプリットブレインを防ぐことができなかった場合、システムとしては障害となる可能性が非常に高いと考えられます。 次の項では、スプリットブレインが発生してしまった後の対処について考えてみました。 スプリットブレイン発生後の対処 PacemakerのActive/Standby構成で、スプリットブレインが発生してしまったらどう対処すべきでしょうか。 ここではパターンとして ①：一時的に クラスタ ノード間通信が切断され両Activeとなってしまったが、その後再び クラスタ ノード間通信ができるようになった場合 ②：完全にノード間の疎通が切れ、両ノードがActiveで稼働したままとなった場合 の2つについて考えてみます。 ＜①：両Activeとなった後、再び クラスタ ノード間通信ができるようになった場合＞ ノード間通信が復活すると、各ノードは一時的に クラスタ から切り離されていたお互いのノードを再び クラスタ に組み込もうとします。 Pacemaker クラスタ への組み込みが始まりノード間の情報連携が再開すると、リソースが両方のノードで起動されてしまっていることが認識されます。 実際に弊社検証環境のPacemaker Active/Standby構成 クラスタ で再現させてみたところ、Pacemakerのログに以下のようなメッセージが出力されました。 (native_create_actions) 　error: Resource virtual_ip is active on 2 nodes (attempting recovery) (native_create_actions) 　notice: See https://wiki.clusterlabs.org/wiki/FAQ#Resource_is_Too_Active for more information リソースとして登録していたvirtual_ipが2ノードでアクティブとなっているので復旧を試みます、というメッセージです。 Pacemakerではリソースが複数のノードでアクティブとなった場合の挙動を「 multiple-active 」というオプションで設定することができます。 multiple-active はデフォルトでは「 stop_start 」となっており、いったんすべてのノードでリソースを停止させた後、片方のノードで起動するという挙動となります。 つまり、一度スプリットブレインが発生してしまっても瞬時にノード間通信が復活した場合は自動でリソースが再起動し復旧するという機能が備わっています。 ただし、一時的とはいえ両ノードでリソースが起動してしまうことには変わらないため、登録しているリソースごとにクライアントやデータへの影響を考える必要があります。 また、登録しているリソースが再起動 不能 なタイプだと両ノードでリソース故障状態(起動できないor停止できない)となり、STONITHによるノード強制停止や手動復旧が必須となります。 ＜②完全にノード間の疎通が切れ、両ノードがActiveで稼働したままとなった場合＞ サーバやネットワーク構成・インターコネクトの接続方式にもよりますが、スプリットブレイン対策を何もしなかった場合に起こりえるパターンです。 両ノードがActiveのまま稼働し続けているということは、本来複数ノードで起動してはならないリソースが複数ノード上でActiveとなってしまっているということです。 そして、場合によってはリソースとして設定している共有ディスクや IPアドレス 競合等が故障として判定されない限り、異常な状態でクライアントからのアクセスやデータ書き込みをし続けてしまっているかもしれません。 ハードウェアとしての故障はもちろん、本来書き込みされてはならない場所・タイミングでデータが書き込まれるということは、データ不整合やロストといった重大なインシデントに発展する可能性が非常に高いです。 慎重にサービス停止を検討し、システム全体の通信の流れやデータの書き込み方式を基にデータを精査することをおすすめいたします。 ※筆者は未経験です。 Pacemaker まとめ 手軽に冗長構成環境を構築できるPacemakerですが、障害発生時にどのように動作させたいか、またはどのように想定外な異常を防ぐか慎重に検討すべきポイントがいくつも存在します。 本記事でご紹介したもの以外にも、より柔軟にPacemaker クラスタ を制御する設定項目が多数存在します。 開発コミュニティであるClusterLabsのドキュメントや、日本でPacemakerを含む Linux HA クラスタ を普及させている Linux -HA Japanの資料をよく参照し、事故の無い安定したHA クラスタ を楽しみましょう。 参考 ClusterLabs： https://clusterlabs.org/ LINUX -HA JAPAN： https://linux-ha.osdn.jp/wp/manual/pacemaker_outline 過去の セミ ナー資料も多数公開されており、大変参考になります。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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