ラク スの配配メールの開発・運用に従事しているJazumaです。 2021/10/02 (土) 10/03 (日)に PHPカンファレンス 2021がオンライン開催されました。 このイベントは 日本PHPユーザ会 が開催しているイベントで、2000人以上が参加しました。 ラク スはスポンサーとして協賛させて頂いています。 phpcon.php.gr.jp 弊社からも3人が登壇し、多数の PHP エンジニアが参加いたしました。 今回は参加者から集めたレポートをご紹介させていただきます。 ではご覧ください。 10/2（土） 1日目 PHPの今とこれから2021 PHPにおけるコーディング規約と自動整形 13年物プロダクトの監視を起点とした改善活動 独自フレームワークPHPアプリケーションの改善戦略 10/3（日） 2日目 配列、ジェネリクス、PHPで書けない型 SVG画像をPHPで生成しよう What is new in PHP 8 巨大なモノリスの静的解析をレベルMaxにする方法 続) 改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り いよいよ開始！徳丸実務試験、PHP8上級試験の模擬問題解説 OpenAPI × LaravelでAPI開発を各段に便利にする方法 PHPで書いて覚える非同期処理 【IMO】コードレビューって難しいよね サービス運用エンジニアによるPHP8バージョンアップ奮闘記 抽象のはしごの上手な登り方～使いやすい汎用ライブラリを作るために～ 弊社の登壇セッションのご紹介 レガシーシステムにおけるPHP8バージョンアップのアプリ対応記録 20年モノの巨大Webサービスの開発継続戦略 - ミドルウェアのバージョンアップとの向き合い方 技術コミュニティ運営戦線〜継続して勉強会を運営するために〜 まとめ 10/2（土） 1日目 1日目は11:00からキーノートがあり、午後から4トラック並行でセッションが行われました。 fortee.jp PHP の今とこれから2021 report by id:radiocat PHP ユーザー会の廣川氏によって「 PHP の今とこれから」が語られる、 PHPカンファレンス ではおなじみのキーノートです。 PHPの今とこれから2021 from Rui Hirokawa www.slideshare.net まず冒頭ではサーバーサイドの プログラミング言語 でシェア8割弱で、 Wordpress を中心に広く使われていることが紹介されました。そして PHP のバージョンアップの歴史をおさらいしたあと、今年の11/25にリリース予定の最新バージョンPHP8.1の機能が紹介されました。まずは、簡易的な並列処理が実現できるFiberが紹介されました。 一般の開発者向けではありませんが、エキスパートな参加者からは注目されているようでした。次に列挙型（ enum ）、交差型、never型、readonly、finalクラス定数といった、コードの可視性やメンテナンス性の向上につながる期待のある機能が紹介され、参加者からは 　「安全になる」 　「書きやすくなる」 　「PHPDocが不要になるかも」 といった声があがっていました。 最後に、 PHP の将来については、従来の C言語 ではなく PHP そのもので記述できるようになる PHP エクステンション（ FFI ）と、 機械学習 ・AIの実装が実現に向けて動いていることが紹介されました。これらについても多くの参加者から期待の声があがっていました。 PHP におけるコーディング規約と自動整形 report by id:hirobex GMOインターネットグループ の橋口巧さんによるセッションです。 youtu.be コーディング規約の必要性から始まり、 PHP Standards Recommendations、通称PSRの紹介です。 PSRに沿った形に整形してくれるツールである PHS CS Fixer と PHP _CodeSniffer の動作を実演を交えながら紹介してくださりました。 13年物プロダクトの監視を起点とした改善活動 report by id:Jazuma Hamee株式会社 日野陽平さん 大島淳司さんによるセッションです。 speakerdeck.com Hameeで開発されている ネクス トエンジンはEC運営を支援するサービスです。 2007年提供開始以来長くユーザに利用され続けてきましたが、課題も蓄積されていました。 特定機能で問題が起きた時にエラーメールが送信される仕組みで監視されていたため、ユーザからの問い合わせで初めて障害が検知される・対応要否が判断しづらいという課題がありました。 課題の改善にあたってまずは 「エラーやログが1か所に集計、緊急度の高いもの・低いものに分類されてSlackに通知される」 という理想の状態が定義されます。 その上で2つのアプローチで課題の改善が進められました。 1. 監視ツールとしてDATADOGを採用 DATADOGとは システム・アプリケーション横断で監視可能な監視プラットフォーム。 AWS との連携が可能・アラート機能が高性能 社内に経験者がいる、UIが優れているといったことが採用理由となりました。 メンバー間で認識を統一し、「ユーザの業務に支障が出ているもの」を緊急度が高いものと定義してSlackのAlertチャンネルに通知される仕組みが構築されます。 この取り組みにより、障害検知早期化・ユーザからの問い合わせ起因のバグが減るという成果が得られました。 2. パフォーマンス定点観測会 パフォーマンス定点観測会 パフォーマンスの問題点を確認する週次 MTG 。SREのみで実施していたものをアプリケーション開発チームでも導入 ユーザの業務への影響を最優先事項とする(ユーザ思考)・手作業を減らすといった心得のもと、改善が図られました。 この取り組みは、ログレベルの適性化(不要なログをAlertしないように修正)・ユーザの操作ミス発見などの成果につながりました。 独自 フレームワーク PHP アプリケーションの改善戦略 report by id:hirobex 株式会社ヤプリの田実誠さんによるセッションです。 speakerdeck.com include Orientedな独自 フレームワーク で 親ファイル→子ファイル→孫ファイルのようにincludeリレーが行われており 機能追加、 リファクタリング がしづらい 冗長な重複コードがあり共通処理を入れにくい ログレベルが入っておらず、監視やトレースがしづらい といった課題を抱えていたサーバーを解決した手法を紹介してくださりました。 解決方法 自動テスト 実サーバーを立ち上げた API テスト auto_prepend_fileによるモックと カバレッジ 取得 静的解析導入 PHPStanの導入 PHPDocによる型情報の付与 PHPStan x PHPDocで本体より強力型付けが付与できる 重複コード 定義した関数ファイルをincludeやrequireして読み込んでいたのを、autoload化 静的解析導入後にやったので安心して リファクタリング curl 関数メインのHTTPリク エス トをGuzzleにより共 通化 ロギング error_log()関数でロギングしていたのをMonologによるロギング共 通化 プロダクトをより良くしていくためには、オーナーシップを持って改善に取り組んでいくことが大事だと述べられていました。 10/3（日） 2日目 2日目は10:00から4トラックでセッションが開始されました。17:00からは恒例の大LT大会も開催されて2日間のイベントが締めくくられました。 fortee.jp 配列、 ジェネリクス 、 PHP で書けない型 report by id:radiocat 技術誌で PHP の記事を担当されているうさみさんによる PHP の型についての講義的な発表でした。 youtu.be PHP に型が取り入れられてきた歴史的背景から基礎的な知識と実装方法、実践的なライブコーディング、Discordで参加者と対話しながら最後はスライドもライブで作りながら発表されるという、臨場感のある密度の濃い発表でした。もともと動的型付け言語の PHP も最新のPHP8ではしっかり型を扱うことができるようになってきています。 実行時に起きる事故を防ぐためにしっかり型宣言して品質を保つためのコードの書き方と、型注釈を入れることでPHPStanによる静的解析などの事前のチェックで回避する手法をバランスよく扱って棲み分けていく考え方を学ぶことができる内容でした。 SVG 画像を PHP で生成しよう report by id:ryo479 SVG 画像編集の Webサービス 開発・運営経験をお持ちのmotookaさんによるセッションです。 youtu.be 以下の項目について解説して下さっています。 SVG とは？ 何が嬉しいの？ PHP で SVG を書く方法 ラスタライズする SVG とは何か？についてから解説されているため、普段 SVG に馴染みのない方でも理解しやすい内容です。 また、 SVG 画像のメリット・デメリットや使用例についても解説されているため、実際に使用するイメージを持ちやすく、開発に SVG を取り入れてみたくなる内容でした。 「 PHP で SVG を書く方法」では、簡単なコードを使用して SVG 画像の動的な生成を実演されており、実装における注意点についても解説されています。 また、 ソースコード は github で公開して下さっているようです。 What is new in PHP 8 report by id:ryo479 Remote Dev ForceのCTO、Joshua Copeland さんによるセッションです。 youtu.be PHP8で新しく備わった機能について、コードを交えてスライドで分かりやすく解説して下さっています。 特に以下の8つの大きなアップグレードについては詳しく解説されています。 The JIT Compiler Attributes Named Arguments Match Expression Throw expression static Return Type Union Types mixed type これからPHP8で開発を行うエンジニアにとっては非常に役に立つ、実践的な内容でした。 巨大な モノリス の静的解析をレベルMaxにする方法 report by id:hirobex 株式会社ホワイトプラスの古賀敦士さんによるセッションです。 speakerdeck.com 低いレベルで運用されていたPHPStanの静的解析レベルを上げていく取り組みについて紹介してくださりました。 はじめに、一度にすべてのモジュールの解析レベルを上げていくのは難しいため モジュール毎に設定したレベルで静的解析を行えるようにPHPStanの実 行基 盤を整えたそうです。 その後、解決できそうなデッドコードは削除したり、型宣言など対応に時間がかかりすぎるものはBaselineでエラーをまとめて無視して一旦レベルを上げるという手法でレベルをMaxにしたそうです。 また、付録としてレベル上げのロードマップやレベル別のルールについての資料も載せてくださっています！ 続) 改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り report by id:Jazuma サイボウズ 株式会社 中田 雄大 さんによるセッションです。 youtu.be Garoon(20年目・PHP7.4・テーブル数850(!))というプロジェクトの改善記録を披露していただきました。 実施した施策 1. Controlloer改善 ○ 改善前の問題 リク エス トパラメータに配列ベースでアクセスしている 手動で型変換をしている クラス同士が密結合で再利用しづらい ControllerでViewを生成している → ユニットテスト が書けない ・保守性が低い ○ 実施したこと リク エス トの取り扱いやレスポンスデータ取り扱いを標準化する基底クラス作成 View描画用のクラスを追加し、描画処理を隔離 DIコンテナ導入： 環境別の依存性注入や処理を制御 →冗長なコードが削除され、 ユニットテスト が書けるように 2. フロントエンド改善 ○実行したこと ES2015 / TS以降 レガシーなコードの改善 スパゲッティコード なくす 不明確な階層構造脱却 インラインJSを抜きだす リファクタリング 後に ユニットテスト 実装 ReactJS導入 改善により得られた知見 自動テスト( ユニットテスト だけでなく、E2Eテストも含む)が重要 改善にあたっての課題 新機能の実装と改善を両方やる 工数 が確保しづらい 改善タスクの粒度が大きく、着地点が見えない 他のメンバーがやっている改善が分からない(何をやっているか・何のためにやっているか) これらの課題から「チームとして改善を継続していくための仕組みが必要」という教訓が得られました。 改善継続のために、 進捗状況を共有するためのミーティングをする・割り込みタスクの対応ルールを決める といった仕組みができました。 改善を続けるためには技術的な取り組みだけでなく、チームビルディングとしての取り組みも必要だと思いました。 いよいよ開始！徳丸実務試験、PHP8上級試験の模擬問題解説 report by id:kuwa_38 youtu.be セッション概要： 吉政さんからのPHP8上級試験と徳丸実務試験の概要説明、特典が紹介されました。 徳丸さんから徳丸実務試験の模擬問題2問とその解説が行われました。 古圧さんからPHP8上級試験の模擬問題2問とその解説が行われました。 模擬問題の概要： 徳丸さんから出題 1問目：認証にBearer トーク ンを使うウェブ API 呼び出しにおいて、 JavaScript 側、 API サーバー側で必要なプロパティ、ヘッダを問う問題 2問目： PHP の API のコード例が表示され、 クロスサイトスクリプティング （ XSS ）について正しい記述を選択する問題 古圧さんからの出題 1問目：クラスの継承やトレイトの正否を問う問題 2問目：PHP8への移行に関する問題として、名前付き引数やnullsafe 演算子 、match式について正否を問う問題 視聴後の所感： 大まかには知っているものの「あれ？どうだっけ」という問題や選択肢もあり、知識の再確認や学習にはよいと感じました。 API のプロパティやヘッダ、 XSS などの 脆弱性 、 php の性質やphp8への移行に伴う変更や新機能など、興味がある方は アーカイブ から一度見て頂ければと思います。 OpenAPI × Laravelで API 開発を各段に便利にする方法 report by id:Jazuma 株式会社ゆめみ 皆川泰陽さんによるセッションです。 youtu.be OpenAPI仕様書を"半"自動生成する OpenAPI仕様書を API テストのAssertに使う OpenAPIを案件で使った感想 という内容の発表でした。 ○ openAPI仕様書"半"自動生成 半自動生成と GUI ツーるはどっこいどっこい キー名やコメントが統一された実装であれば半自動生成は便利 laravel-openapiはまだ成長中の OSS なのでない内部実装を読んでいる人が欲しい ○ API テストのAssert 使わない理由が無いほど便利 assertの量が減るのが便利 先にopenAPI仕様書がある場合でも使える 仕様書に不備があると困る OpenAPI仕様書の半自動生成はまだまだ発展途上・OpenAPI仕様書を使うことは現時点でもメリットが大きい、というのが現状のようです。 PHP で書いて覚える非同期処理 report by id:radiocat speakerdeck.com PHP8.1から非同期処理が書けるようになったことを踏まえて非同期処理の概念を理解し、今後の活用に向けて実装イメージと技術動向をおさえたい人のためのセッションです。 JavaScript のようなUIを扱う処理では非同期処理が主流となっています。一方で PHP のようなバックエンド処理ではデータの整合性を維持するために同期処理が一般的です。 PHP での非同期処理の主な使い方としてIO処理が考えられます。その中でも今回は以下の3つのIOモデルについて PHP の実装イメージを交えて解説されました。 ブロッキング IO ノン ブロッキング IO IO多重化 PHP8.1で実現できる非同期処理はまだまだほんの一部で、一般開発者が扱える機能ではなさそうです。ただ、 Xdebug が動くことによって デバッグ しやすくなるというメリットはありそうなので、将来の活用にそなえて非同期処理を勉強しておきたい人には参考になる情報がスライドで多数紹介されています。 【IMO】コードレビューって難しいよね report by id:tsudachantan speakerdeck.com コードレビューを効果的に実施するにあたり、コードレビューに対する苦手意識をなくしていこう！というセッションです。 苦手意識の原因として、他のメンバーよりも時間がかかる、コードの改善提案の回数が少ない、違和感があっても改善案までコメントできない、そもそも自分の理解力の問題のような気がする…などなど コードレビューに自信がないという悩みを解決するため、体験談を踏まえて克服への道 のりを お話していただけました！ 個人的に共感できる悩みばかりで大変ためになりました。 実際にコードレビューでの改善提案が多い方の意見を踏まえ、すぐに実践できる観点をたくさん解説していただけました。 自分ならこう実装すると答え合わせする 可能な限りコードジャンプする 自分の理解が合っているか確認するためのコメント 実装に疑問があれば デバッグ する といった風に、疑問点をなくして自信がない状態を抜け出すための具体的なヒントを頂けました。 「効果的なコードレビューがチームの成熟度やプロダクトの品質に影響を及ぼすといっても過言ではない」とおっしゃられていました。 このセッションを踏まえて今後のコードレビューに取り組んで、苦手意識を克服していきたいです。 サービス運用エンジニアによるPHP8バージョンアップ奮闘記 report by id:richardwagner youtu.be 弊社と同様にPHP8へのバージョンアップに取り組まれたヒエ イカ ザトさんのセッションでした。 弊社でもかなり苦しめられたバージョンアップ、いったいどのように取り組まれたのだろう？と興味津々で聴講させてもらいました。 弊社と共通する事例もありつつ、具体的なアプローチ方法まで踏み込んだ充実したセッションでした。 予定よりも少ない 工数 （予想：3か月⇒実際：2.5か月）で完了された技術力はさすがと感じました。 以下、「なるほど！」と感じ入ったポイントです。 Dockerなどを駆使してローカル検証しておくと、後から本格検証するのが楽 PHP のバージョンアップと技術的負債の返済を同時にやりすぎると、バグったときに切り分けが大変になるので注意 バージョンアップは怠ると後が大変 こまめなバージョンアップそれ自体を組織の文化・体質にしてしまうのがよい 製品ロードマップにあらかじめ組み込んでおくと、ビジネスサイドとの合意が取りやすい チームで担当を回す（属人化排除大切！） 抽象のはしごの上手な登り方～使いやすい汎用ライブラリを作るために～ report by id:richardwagner youtu.be PHP によるログ実装を題材にした抽象的プログラミングについてのセッションでした。 「抽象度は高ければいいというものではない。」という提言は、ともすれば理想に走ってしまいがちな私たちエンジニアの視点に警鐘をならしてくれました。 どの程度まで抽象化したらいいのかという「正解」について迷うことは確かに多く、その際に考える際の一つのヒントになりそうです。 抽象度は「はしご」で表現しやすい。そのままの姿勢で、ちょっと上る／下りるの微調整が簡単 抽象度は高ければいいというものではない。抽象度は必要十分なレベルにする ブログや登壇は抽象度を上げるうえでよい訓練になる 弊社の登壇セッションのご紹介 ここからは弊社から登壇させて頂いたセッションの内容をご紹介します。 レガシーシステム におけるPHP8バージョンアップのアプリ対応記録 youtu.be speakerdeck.com 弊社の楽楽販売の開発チームからPHP8へのバージョンアップの取り組みついて発表しました。 今年EOLを迎える7.3からのバージョンアップのため開発期間が限られた中で、下位互換のない変更点が多く存在しているという難易度の高い状態でした。特に影響の大きい変更点は次の2つです。 緩やかな比較 演算子 の挙動変更 警告レベルの変更 前者は == の比較結果が変更になるパターンに絞って影響箇所を洗い出してコードを修正し、後者はまず影響箇所を動作させてログを出力してエラー担った箇所に絞って修正しました。いずれも膨大な影響範囲から重大な問題箇所に絞って対策を行っています。それでも前回のバージョンアップの2倍以上のコストがかかったとのことで、今後に向けては普段からの静的な型を意識した実装とこまめな リファクタリング が重要であると締めくくりました。 20年モノの巨大 Webサービス の開発継続戦略 - ミドルウェア のバージョンアップとの向き合い方 youtu.be speakerdeck.com 弊社の最長寿サービスであるメールディーラー開発チームからレガシーなサービスにおける ミドルウェア のバージョンアップへの向き合い方について発表しました。 我々はなぜ長い年月をかけて開発を続けているのかというと、ユーザーにとって価値があるビジネスの一部だからです。ところが リファクタリング などの改善はすぐにコストが回収できず新しい価値を生み出しにくいため取り組みづらさがあります。一方で ミドルウェア のバージョンアップは実施しなければ明確に価値が下がるため実施せざるを得ません。 とりあえずサービスを継続し生き続けるために最小限のコストでバージョンアップをやりきろうというのが今回の発表で紹介された戦略でした。 技術コミュニティ運営戦線〜継続して勉強会を運営するために〜 youtu.be speakerdeck.com 弊社で毎月1回開催している PHP TechCafeの運営メンバーが技術コミュニティの運営について発表しました。 社内のもくもく勉強会を社外にも発展させていく中で、エンジニア同士の交流を広げるために弊社の技術領域である PHP をテーマに据えて関西で一番盛り上がる PHP コミュニティを目指して試行錯誤してきました。毎月開催のコミュニティを継続させるためには省力化が大事です。主催者だけが頑張りすぎては続かないので、参加者や社内のメンバーを巻き込んでコンテンツを作っています。そうやってコミュニティを運営していくモチベーションはどこにあるのかというと、結局は「やりたいから、やる」ということです。 コミュニティを運営していく熱意を持ちつつ、一人で抱え込まずにテーマや目的に沿って周りを巻き込みながら運営するのが継続のポイントであるという話でした。 まとめ レガシーシステム の改善から最新技術の導入事例に至るまでバリエーション豊かな発表内容でした。 参加のハードルが低いのがオンラインイベントの大きなメリットだと思うので、オフラインイベントが開催できるようになってもオンライン参加もできるような体制が続いてほしいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

PHP 入門者・プログラミング初心者向けに PHP でforeach構文の使い方を解説します。foreach構文は、配列の要素の数だけ繰り返し処理を行います。 foreachの基本的な解説 から、 連想配列 での使い方 、 繰り返しの途中で処理をスキップする方法 、おまけとして foreachに代わる、スマートに書ける PHP のメソッドの紹介 をします。 目次 目次 foreach構文とは foreach構文を実際に使ってみよう 連想配列での使いかた ループの途中で処理をスキップする方法 while構文やfor構文との違い foreachに代わるループ構文 foreach構文とは foreach文 は 配列に含まれる要素の値をループで順番に取り出して処理 したい場合に便利な繰り返し構文です。 配列は複数のデータをまとめて格納できる変数です。 ※配列については下記ページでわかりやすい解説があります。 PHPの配列機能のまとめ - RAKUS Developers Blog | ラクス エンジニアブログ 繰り返しの処理 を行う他の構文は、 PHP ではfor文やwhile文などがあります が、 foreach構文は繰り返しを終了する条件を記述する必要がなく 、それらに比べて簡潔に記述できます。 foreachは配列の要素の数だけ繰り返し処理を実行したら、ループが終了する という特徴があります。 foreach構文を実際に使ってみよう 構造は次のようになっています。 foreach (要素を取り出す配列 as 配列から取り出した要素を格納する変数){ 実行する処理※配列から取り出した要素を格納する変数が使用できる; } 要素を取り出す配列 ：ループで順番に中身が取り出される配列です。その配列の要素の数だけループが繰り返されます。 配列から取り出した要素を格納する変数 ：ループ1回で配列内にある1つの要素がこの変数に代入されます。毎ループ同じ名前の変数に、配列の中の1つの要素が格納されます。 サンプルプログラムで具体的に動きを見てみましょう <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; foreach ( $ animalList as $ animal ){ print $ animal . "<br>" ; } ?> このときの出力結果は下記のようになります。 犬 猫 うさぎ 先ほどの処理の流れは以下の通りです。 1. 「$animalList」配列に「犬」「猫」「うさぎ」を代入 ---ループ開始（「犬」、「猫」、「うさぎ」の合計3回繰り返す）--- 　-ループ1回目- 　2. foreach文冒頭で「$animalList」から「犬」を取り出し「$animal」に代入 　3. 「print $animal;」で「犬」を出力 　-ループ2回目- 　4. foreach文冒頭で「$animalList」から「猫」を取り出し「$animal」に代入 　5. 「print $animal;」で「猫」を出力 　-ループ3回目- 　6. foreach文冒頭で「$animalList」から「うさぎ」を取り出し「$animal」に代入 　7. 「print $animal;」で「うさぎ」を出力 ---ループ終了--- 使用時の注意 PHP は変数の有効範囲である スコープが他言語と異なることがあり 、その影響でハマるケースもあります。 PHP には 条件分岐内やループ内の ブロックス コープがない ため、上の例では$animalはループを抜けた後でも値が入ったままです。 ループ内でセットした変数についても同様に、ループを抜けた後でも値が入っています。 他の言語とは異なる動きになるため、注意が必要です。 参考： スコープ - Wikipedia 参考： PHP: 変数のスコープ - Manual 連想配列 での使いかた 上記では一次配列を基にループをさせていましたが、 連想配列 でも同じくforeach構文を使用できます。 連想配列 は、下記のように キーと値のペア（キーバリューストア）が格納されています。 $animalList = ["dog" => "犬", "cat" => "猫"] この場合、 キー は「dog」「cat」、 値 は「犬」「猫」となります。 サンプル <?php $ animalList = [ "dog" => "犬" , "cat" => "猫" , "rabbit" => "うさぎ" ] ; foreach ( $ animalList as $ key => $ value ) { print $ key . "は" . $ value . "という意味です<br>" ; } ?> こちらを実行してみると、以下のような結果となります。 dogは犬という意味です catは猫という意味です rabbitはうさぎという意味です ループの途中で処理をスキップする方法 foreach等 の繰り返し処理の途中で、 その繰り返しを抜けたり 、 その回の繰り返しを飛ばして次の繰り返しを行ったりしたいとき があります。 「繰り返しを抜ける」 というのは、例えば、配列の中に"dog"という文字列が1つあり、それを 検索したい場合 です。 "dog"が見つかったら目的を果たしたことになり、 それ以降の繰り返し処理の中での検索は意味がない ので、その ループ自体を抜けたほうが高速で低負荷な処理 が実現できます。 「その回の繰り返しを飛ばして次の繰り返しを行う」 というのは、保存処理で一例を挙げると、 値が入っている場合は保存 して、 値が入っていない場合は保存しない といった場合です。 値が入っていない場合は、保存をする必要がない ため、 現在のループをスキップして次のループに移行した方が不要な処理を行わなくて済みます。 そんな時に使えるのが break文 と continue文 です。 break文 は、繰り返し処理を中断し、 繰り返しの中から抜けます。 continue文 はその回の 処理を飛ばし、次の繰り返し処理へと進めます。 break文 や continue文 は、 foreachだけでなく 、whileやfor等の 他のループでも使用できます。 それでは、実際に動きを見てみましょう。 continue文 foreach ( $fruits as $fruit ) { // 処理A contiue; // 処理B } 処理の流れ ：foreach開始 → 処理A → continue (その回のループをスキップ) → 処理A → continue.... この例では 処理Bはスキップ されて、次のループで処理Aを実行します。 break文 foreach ( $fruits as $fruit ) { // 処理A break; // 処理B } // 処理C 処理の流れ ：foreach開始 → 処理A → break (ループ自体を抜ける) → 処理C 処理Aの直後に 繰り返し処理を抜けて（終了して） 、処理Cを実行します。 while構文やfor構文との違い foreach はわかったけど、 他の繰り返し構文のwhile文やfor文とはどうちがうの？ と思われるかもしれません。 ここでは foreach と while、forを比較 して、 どういう場面で使いやすいのか という解説をしていきます。 これから、同じ結果を出力するコードをforeach、while、forで書き換えてみます。 まずはforeachから foreach <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; foreach ( $ animalList as $ animal ){ print $ animal . "<br>" ; } ?> while <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; $ animalNum = 3 ; //count()などを使って配列の要素数を数えたほうが変更に強いプログラムになります $ index = 0 ; while ( $ index !== $ animalNum ) { print $ animalList [ $ index ] . "<br>" ; $ index ++ ; } ?> for <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; $ animalNum = 2 ; //count()などを使って配列の要素数を数えたほうが変更に強いプログラムになります for ( $ index = 0 ; $ index <= $ animalNum ; $ index ++ ) { print $ animalList [ $ index ] . "<br>" ; } ?> 結果 犬 猫 うさぎ 各繰り返しの構文の特徴をまとめると以下のようになります。繰り返し処理を行うときの参考にしてください。 構文 処理に適している条件 特徴 foreahc 配列の全ての要素に対して繰り返し処理を行いたい。 条件式を意識しなくても繰り返し処理ができる。 while 指定した条件の間は、繰り返し処理を行いたい。 条件式のみで繰り返しができるので、フラグで繰り返し処理を管理する場合は向いている。 for 初期値、条件、増減式を指し、指定した条件になるまで繰り返したいとき。 繰り返しの条件を1行で定義できるので、可読性が高い。配列を使わない繰り返し処理に向いている。 ここまで foreach構文 を中心に繰り返し処理をみてきましたが、 それぞれ得意なことが異なります。 目的に合った構文を使えるようになるとコーディングが楽になります。 繰り返し処理は PHP に限らずプログラム初心者のうちはつまずきやすい箇所なので、最初は画面に要素やキーを出力しながら デバッグ を行うとわかりやすいです。 参考： PHP: while - Manual 参考： PHP: for - Manual foreachに代わるループ構文 foreach で繰り返し処理をさせて、その中で任意の処理を書いていくというのはよくあることです。 ですが、実は PHP には標準関数 として、 便利に配列を処理するarray系の関数 が用意されています。 array_xxxx の形の array系関数 を使うことで、 foreach で任意の処理を書いていくのと比べると 「記述量が減る」「高速処理」「バグの発生を防げる」 というメリットがあります。 開発をする上で、配列の処理をスマートに書けると 大幅な業務効率アップに繋がる でしょう。 知っているだけで大きな強みになります。今後のためにも、 ループの中で配列を扱うときには、一度調べてみることをお勧めします。 今回はたくさんある中から一例をご紹介しますが、他にもたくさん便利なメソッドがあります。 是非 foreach以外の配列ループの世界 にも飛び込んでみてください。 参考： PHP: 配列 関数 - Manual 配列の中の数値の合計値を返してくれる array_sum() //この配列の合計が欲しい場合 $ary = [100, 200, 300]; foreachの場合 $sum = 0; foreach($ary as $num){ $sum += $num; } echo $sum; //出力： 600 array_sumの場合 $sum = array_sum($ary); echo $sum; //出力： 600 4行が1行になりました。 重複を排除した配列を返してくれる array_unique() //この配列を ["a", "b", "c"] にしたい場合 $ary = ["a", "b", "a", "c"]; foreachの場合 $uniq_ary = array(); foreach($ary as $str){ if(!in_array($str, $uniq_ary)){ $uniq_ary[] = $str; } } var_export($uniq_ary); array_uniq()の場合 $uniq_ary = array_unique($ary); var_export($uniq_ary); 6行が1行になりました。 今回は PHP のforeachの基礎の解説から、発展形のarray系関数を紹介しました。 「配列を制する者はプログラミングを制する」というエンジニア界隈のことわざがあります。 皆さんも、 PHP のforeachを使いこなし、配列マスターを目指しましょう。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、株式会社 ラク スで先行技術検証を行っている技術推進課の @t_okkan です。 技術推進課では、新サービス立ち上げ時の開発速度アップを目的に、現在 ラク スでは採用されていない新しい技術の検証を行う、技術推進プロジェクトがあります。 今回はその技術推進プロジェクトで、ドキュメントDBであるMongoDBについて検証を行いましたので、その結果の報告を行います。 なお、別テーマの取り組みや、過去の取り組みに関しては、こちらからご覧ください。 tech-blog.rakus.co.jp ドキュメントDB MongoDB トランザクション WiredTigerストレージエンジン 水平方向と垂直方向へのスケーリング Aggregation Pipline MongDBのスキーマ設計 PostgreSQLのjson型、jsonb型との比較 Javaアプリケーションでの実装例 MongoDBとの接続 定義情報のCRUD処理 RDBとMongoDBのトランザクション まとめ ドキュメントDB ドキュメントDBとは、半構造データを管理するNoSQLなデータベースです。半構造データとは、ある程度データ構造が決まっているが構造が柔軟に変更できる、もしくは変更されるデータのことで、 JSON や XML 形式で表されます。 ドキュメントDBの特徴としては以下のようなことが挙げられます。 スキーマ レスで動的なデータを保存できる 膨大なデータを高速に処理することができる アプリケーションとデータベースの インピーダンス ミスマッチを解消できる リレーショナルデータベースとドキュメントDBなどの非リレーショナルデータベースを併用し、データの特性ごとに適材適所のデータベースを利用する考え方をポリグロット・パーシステンス（複数モデルによる永続化）と呼びます。 今回はドキュメントDBの製品であるMongoDBについて調査し、実際にポリグロット・パーシステンスを実装してみました。 MongoDB MongoDB Incが開発とサポートをしているドキュメントDBです。データをBSONという JSON のバイナリ版の形式で保存することができます。 CouchDB やRavenDBといった、同じドキュメントDBの中では最も人気のあるデータベースとなっています。 それではMongoDBの基礎的な機能などについて説明します。 トランザクション MongoDBではバージョン4.0からマルチドキュメントACID トランザクション をサポートしています。（レプリカセット構成でWidredTiger利用時）デーベース、コレクション、ドキュメント単位から トランザクション を開始できます。以下のような トランザクション レベルが提供されています。 書き込みレベル w:1 ：プライマリにコミットされるとコミット完了とする w:"majority" ：レプリカセットの 過半数 にコミットされると完了とする 読み込みレベル local ：プライマリの最新データを取得する majority ：書き込みレベルが w:"majority" の場合、レプリカセットの 過半数 にコミットされているデータを取得する snapshot ：レプリカセットの 過半数 で反映されているデータから取得する docs.mongodb.com WiredTigerストレージエンジン バージョン3.2からMongoDBのストレージエンジンのデフォルトがWiredTigerに変更されています。 WiredTigerはMVCC アーキテクチャ を採用しており、ドキュメントの書き込みの同時実行が可能になります。 これまでのMMAPv1と比べ、メモリ制限や、データとインデックスの圧縮が可能になっています。 WiredTigerの詳しい動作の説明はこちらのスライドで詳しく説明されています。 WiredTigerを詳しく説明 from Tetsutaro Watanabe www.slideshare.net 水平方向と垂直方向へのスケーリング MongoDBではシャーディングと レプリケーション を組み合わせた、シャードレプリカを構築することで水平方向と垂直方向のスケーリングを行うことができます。これにより、性能と可用性の両面を向上させることができます。 gihyo.jp Aggregation Pipline 1つのコレクション内の複数のドキュメントをグループ化し、複数の処理を実行するパイプラインを実装することができます。データのフィルターや集約、ソート、変換などが可能となります。 SQL の group by や sum 関数といった処理を再現することができます。 docs.mongodb.com MongDBの スキーマ 設計 MongoDBのドキュメントの スキーマ を設計するには、ドキュメントに対するアクセスパターンとクエリを理解する必要があるとされています。WiredTigerのメモリに検索結果をキャッシュするため、必要のないデータをクエリするとメモリの無駄遣いになってしまいます。 そこでMongoDBでは、 スキーマ 設計パターンが提供されており、データの特性やアクセスパターンから最適な設計パターンを選択することが推奨されています。 www.mongodb.com Polymorphic patter ・ Attribute pattern ・ Subset patter の設計パターンが参考になるのではないかと思います。 PostgreSQL の json 型、jsonb型との比較 PostgreSQL では9.2から json 型が、9.4から JSON 形式のデータをバイナリ解析して保存するjsonb型が提供されています。 そのため、 PostgreSQL でも動的なカラムの増減に対応することができます。 以下、MongoDBと PostgreSQL の json 型とjsonb型について比較しました。 比較項目 PostgreSQL json 型 PostgreSQL jsob型 MongoDB インデックスの設定 不可 可能 可能 トランザクション 対応 対応 対応 データ型 JSON型 に準拠 一部のデータ型に 制限あり BSON型 に準拠 全文検索 対応 対応 日本語未対応 MongoDBは PostgreSQL の JSON 型と比べ、豊富なデータ型に対応しています。しかし、MongoDBは日本語での 全文検索 に対応していません。（他の言語には対応） Java アプリケーションでの実装例 今回は以下のようなマスターデータをリレーショナルDB（ PostgreSQL ）に、カスタム項目などのユーザーごとに動的に変更される定義情報をMongoDBに登録するポリグロット・パーシステンスなシステムを実装してみました。 MongoDBの Java Driverは以下のように build.gradle に設定しています。 dependencies { implementation group: 'org.mongodb', name: 'mongodb-driver-sync', version: '4.2.3' } MongoDBとの接続 Java アプリケーションからMongoDBへ接続するには、 RDB 同様にURLを利用して接続します。 レプリカ構成のMongoDBを利用している場合は、メンバーのホスト名とレプリカセット名を指定して接続します。 MongoClient mongoClient = MongoClients.create( "mongodb://ユーザー名:パスワード@ホスト名" ); // レプリカ構成の場合 MongoClient mongoClient = MongoClients.create( "mongodb://ユーザー名:パスワード@プライマリホスト,セカンダリホスト,ターシャリホスト?replicaSet=レプリカ名" ); 定義情報の CRUD 処理 Java アプリケーションからの CRUD 処理の一例を紹介します。前提条件としてユーザーの定義情報は Map<String, Object> 型のデータとしてやりとりされる前提とします。 // 定義情報 Map<String, Object> property1 = new HashMap<>(){ { put( "設定1" , "オプション1" ); put( "設定2" , 3 ); put( "設定3" , true ); } }; Map<String, Object> property2 = new HashMap<>(){ { put( "設定1" , 1 ); put( "設定4" , false ); put( "設定5" , "オプション5" ); } }; // コレクションの取得 MongoCollection<Document> collection = mongoClient.getDatabase( "データベース名" ).getCollection( "コレクション名" ); // ユーザーの定義項目の登録 Document registorData = new Document(); property1.entrySet().stream().forEach(e -> registorData.append(e.getKey(), e.getValue())); registorData.append( "userId" , "user1" ); collection.insertOne(registorData); // ユーザーの定義項目の検索 Document query = new Document( "userId" , "user1" ); Document result = collection.find(query).first(); // ユーザーの定義項目の更新（上書き + 追記） Document query = new Document( "userId" , "user1" ); Document updateData = new Document(); property2.entrySet().stream().forEach(e -> updateData.append(e.getKey(), e.getValue())); collection.updateOne(query, new Document( "$set" , updateData)); // ユーザーの定義項目の削除 Document query = new Document( "userId" , "user1" ); DeleteResult deleteResult = collection.deleteMany(query); その他、 CRUD 処理については以下の チュートリアル で詳しい実装例が紹介されています。 mongodb.github.io RDB とMongoDBの トランザクション MongoDBでの トランザクション の実装は以下のようになります。 ClinetSession の startTransaction メソッドで トランザクション 開始 ClinetSession の close メソッドで トランザクション を終了 MongoDBの処理に失敗すると MongoCommandException がthrowされるのでcatch節で ClinetSession の abortTransaction メソッドを実行しロールバッ // MongoCommandExceptionをロールバック対象の例外に設定 @Transactional(rollbackOn = MongoCommandException.class) public void transactionA() throws MongoCommandException { // MongoDB Sessionの取得 ClientSession session = mongoClient.startSession(); try { // MongoDB トランザクションの開始 session.startTransaction(); // PostgreSQLの処理 // MongoDBの処理 } catch (MongoCommandException e) { // ロールバック処理 session.abortTransaction(); throw e; } finally { // MongoDB トランザクションクローズ session.close(); } } 今回のようにマスターデータは RDB に設定情報はMongoDBに保存されている場合、マスターデータを変更した場合にMongoDBのデータも変更する可能性が出てきます。 上記の実装のように、 PostgreSQL の トランザクション 処理の中にMongoDBの トランザクション 処理を実装することで、どちらかのデータ保存に失敗した場合、両方のDBを ロールバック することができるようになります。 まとめ MongoDBの機能の解説と Java アプリケーションでのサンプルについて解説しました。 日本語での 全文検索 に対応していないものの、 トランザクション への対応など豊富な機能が提供されており、 データ形式 によってはMongoDBが最適解となることもあるのではないでしょうか。 もしMongoDBの導入を検討されている方がいましたら参考にしていただければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに まずはwebpack esbuild swc Snowpack Vite まとめ はじめに こんにちは。フロントエンドチームの岡山です。 私の担当するプロジェクトでは現在Vue2を使っており、webpack(vue- cli )を使ってビルドを行っています。 webpack自体は非常に有用なツールではありますが、あえて不満を挙げるならビルドが遅いことでしょう。 キャッシュや処理の並列化など、高速化のためにビルド設定の最適化を行ってはいますがそれでも遅いです。 小さいプロジェクトでは気にならなくても、大きくなるとともにこの問題が顕在化し、無視できなくなるかもしれません。 この記事では高速なビルドを可能にする新興勢力をいくつかご紹介します。 まずはwebpack 比較対象がないと評価しにくいので、最初にwebpack5 + ts-loaderを使います。 React + TypeScript + Material UIで作られた サンプルプロジェクト をビルドしてみます。 TypeScriptの型チェックは fork-ts-checker-webpack-plugin を使って別プロセスで行うようにします。 // webpack.config.js const path = require( 'path' ) const ForkTsCheckerWebpackPlugin = require( 'fork-ts-checker-webpack-plugin' ) const loaders = { ts: 'ts-loader' } const loaderOptions = { ts: { transpileOnly: true } } module.exports = (env = {} ) => ( { mode: process.env.NODE_ENV, entry: './src/index.tsx' , output: { filename: 'index.js' , path: path.resolve(__dirname, 'dist' ), } , module: { rules: [ { test: /\.tsx?$/ , use: { loader: loaders [ env.loader ] , options: loaderOptions [ env.loader ] } , exclude: /node_modules/ , } , ] , } , resolve: { extensions: [ '.tsx' , '.ts' , '.js' ] , } , plugins: [ env.tscheck == 'yes' ? new ForkTsCheckerWebpackPlugin() : false ] .filter( Boolean ), } ) // package.json " scripts ": { " build:webpack-ts ": " webpack --progress --env loader=ts ", " build:webpack-ts-tscheck ": " webpack --progress --env loader=ts tscheck=yes " , } 結果は以下の通りでした。 後で紹介するesbuildとswcは型チェックを行わないため、型チェックを行わない場合も計測しておきました。 型チェック time あり ~10s なし ~4.5s esbuild esbuild はGoで実装された JavaScript /TypeScriptのビルドツールです。 トランスパイルからバンドル、ミニファイまでやってくれます。そして圧倒的な速さを誇ります。 公式ドキュメントによるとその速さはwebpackやRollupの数十倍。 これまでビルドに1分かかっていた場合、これが1秒くらいになる計算です。圧倒的です。 また、esbuildには プラグイン が利用可能なため、ビルドプロセスの様々な部分に処理を追加することが可能です。 しかし 既存のプラグイン はまだ充実していないため、必要に応じて自作する必要があるかもしれません。 詳しくは こちら を参照ください。 それでは実際にesbuildを使って同じプロジェクトをビルドしてみます。 $ npm i --save-dev esbuild // build.js const { build } = require( "esbuild" ); build( { define: { "process.env.NODE_ENV" : process.env.NODE_ENV } , target: "es2015" , platform: "browser" , entryPoints: [ "src/index.tsx" ] , outdir: "dist" , bundle: true , minify: !process.env.NODE_ENV, sourcemap: process.env.NODE_ENV } ) . catch (() => process.exit(1)) // package.json " scripts ": { " build:esbuild ": " set NODE_ENV= \" development \" && node ./build.js " , } ビルドにかかった時間は ~0.8s ほどになりました。 速いです。数十倍とまでは行きませんでしたが、4.5秒と1秒以下は体感でも結構違います。 とまぁ速いのはわかりましたが、プロダクトへの導入には懸念があります。 公式も言っている通り 、現状v1.0.0に到達していないesbuildはproduction-readyではありません。 そこでwebpackプロジェクトにも比較的気軽に導入できる、 esbuild-loader を使ってみることにします。 これはts-loaderやbabel-loaderの代替となるローダーです。webpackでのビルドでもesbuildの一部をお手軽に利用することができます。 $ npm i --save-dev esbuild-loader // webpack.config.js ... const loaders = { esbuild: 'esbuild-loader' } const loaderOptions = { esbuild: { loader: 'tsx' , target: 'es2015' } , } ... // package.json " scripts ": { " build:webpack-esbuild ": " webpack --progress --env loader=esbuild " , } ts-loaderからesbuild-loaderを使うようにするとビルド時間は ~4.2s ほどでした。 若干速くなった...でしょうか。おそらくesbuild-loaderの導入を検討している方のほとんどはビルド時間の高速化を目的としていると思います。一概には言えませんが、esbuild-loaderの導入だけでは大きな改善は難しいかもしれません。 swc swc は Next.js v11にも組み込まれた JavaScript /TypeScriptトランスパイラです。 こちらはRustで実装されています。swc単体ではバンドラーとしての機能は持っておらず、バンドルするには spack 等を利用する必要があります。 esbuildと同じようにswcにもwebpackで使用可能なローダー swc-loader があったのでこちらを使ってみました。 $ npm i --save-dev @swc/core swc-loader // webpack.config.js ... const loaders = { swc: 'swc-loader' } const loaderOptions = { swc: { sync: true , jsc: { parser: { syntax: "typescript" , tsx : true } } } } ... // package.json " scripts ": { " build:webpack-swc ": " webpack --progress --env loader=swc " , } ビルドにかかった時間は ~4.1s ほどでした。esbuild-loaderと同じような感じですね。 Snowpack Snowpack もwebpackやParcelなどのバンドラーの代替手段として登場しました。 webpackなどの従来のビルドツールは1つのファイルを保存するたびに、アプリケーション全体を再構築してバンドルする必要がありました。 ここでSnowpackは（開発時には）もはやバンドルをしないというアプローチをとりました。 JavaScript のESMを活用することで開発中はバンドルせずに各ファイルを都度読み込みます。これにより、大規模なプロジェクトでも高速に開発サーバを起動することが可能になります。 各ファイルは一度だけビルドされ、キャッシュされます。ファイルが変更されるとそのファイルのみビルドするため、差分更新も一瞬で完了します。 また、Snowpackには先ほどご紹介したesbuildが組み込まれているため、本番ビルド時にesbuildを使ってバンドルすることができます。 ただし、esbuildは先述の通り成熟していないという理由で webpackプラグインを使用することが推奨されています (Rollup プラグイン もあります)。 開発者としては頻繁に行われる開発時のビルド時間が短縮されると特にうれしいため、開発者体験の向上とプロダクトへの導入しやすさの両方を実現していると言えます。 $ npm install --save-dev snowpack @snowpack/plugin-webpack // snowpack.config.js module.exports = { mount: { public : { url: '/' , static : true } , src: '/dist' } , plugins: [ [ '@snowpack/plugin-webpack' , ] ] } // package.json " scripts ": { " start ": " snowpack dev ", " build ": " snowpack build " } 実際にビルドしてみると、開発サーバーが ~1s ほどで起動します。噂通りの速さですね。差分更新なんかは一瞬です。 Vite Vite もSnowpackと非常に似た目的を持ったNo-bundleツールです。 依存関係の事前バンドルにはesbuildを、本番ビルドではRollupを使用します。 $ npm install --save-dev vite @vitejs/plugin-react-refresh // vite.config.ts import { defineConfig } from 'vite' import reactRefresh from '@vitejs/plugin-react-refresh' import path from 'path' export default defineConfig( { root: './' , plugins: [ reactRefresh() ] , resolve: { alias: { '@/' : path.join(__dirname, './src/' ), } , } , } ) // package.json " scripts ": { " start ": " vite ", " build ": " vite build " } Snowpackと同様、開発サーバーが ~1s ほどで起動しました。 まとめ esbuildはトランスパイルもバンドルも高速に動作します。この速さに慣れたらwebpackには戻りたくなくなります。 が、様々な プラグイン を使ったある程度の規模のwebpackプロジェクトをesbuildに置き換えするのは現実的に難しい点もあるでしょう。 swcも高速ではありますが、プロダクトで採用するにはspackが発展途上過ぎるなという印象を感じました。ただ、Next.jsやDenoでは内部で使われているため、開発者は意識しなくてもその恩恵を受けられるようになっています。 SnowpackとViteは高速な開発ビルドによる開発者体験の向上と、安定したwebpackやRollupによる本番ビルドを兼ね備えたツールです。 私が所属するチームではVue2を使っているので、Vue3に上げるタイミングに合わせてViteの導入もできればなーと思っています。 ここでは紹介しきれなかったものもあるので、皆さんもぜひ様々なビルドツールを調べてお試しになってみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」 というプロジェクトがあります。 2021年度は通年で「ユーザー認証」について取り組んでいるので、途中ではありますが紹介したいと思います。 ■ 昔ながらの認証 設計概要 クレデンシャル情報の保持 認証処理 問題点 ■ 用語解説 ■ 認証に関する仕様 OpenID Connect OpenID ConnectとOAuth2.0の違い OpenID ConnectとSAMLの違い FIDO 2.0 OpenID ConnectとFIDO2.0の位置関係 FIDO2.0の対応状況 ■ 認証サーバーソフトウェア ■ まとめ・下半期の予定 ■ 昔ながらの認証 設計概要 まずは古き良き時代の認証ですが、定番の設計としては以下の様なものではないでしょうか。 クレデンシャル情報の保持 IDとパスワードを入力 場合によっては秘密の質問を追加で設定 本質的にはIDとパスワードが2セットあるのと同じ サーバーサイドでパスワードを非可逆変換した文字列を保持 ハッシュ関数 を使うのが一般的 認証処理 ユーザーが入力したIDとパスワードをサーバーに送信 サーバーサイドでパスワードを同じ ハッシュ関数 で変換 IDと、パスワードを変換した文字列同士を比較して一致すれば認証成功 問題点 で、こういったIDとパスワードだけの認証が問題視され始めています。 news.mynavi.jp よくある記事ですが、ユーザーがパスワードを決める以上 パスワード自体に 脆弱性 がある ということなのだと思います。 流石にこのレベルのパスワードは「英数大文字小文字」に加えて「記号を含むこと」くらいの制限かけていれば避けられますが、ターゲットのユーザー層の想定 リテラシ レベルによっては記号入力を必須にできない場合もあると思いますし、本質的にな解決ではないでしょう。 関連して、海外の調査会社もこの様な記事で 多要素認証市場が年平均15％成長する としています。 www.grandviewresearch.com ■ 用語解説 「多要素認証」 というワードが出てきましたが、認証の話題では間違って言葉を使っている人も結構います。なのでまずは主だった用語をおさらいしていきたいと思います。 最初は定番ですが「認証」と「認可」の違いから。 認証 認可 ユーザーが 「誰」 であるか確認すること ユーザーが 「何を出来る」 か権限を与えること 次に「多要素認証」と「多段認証」の違い……と言いたいところですが、その前提として認証に用いる情報の分類を先に説明します。 知識情報（知識要素） 所持情報（所持要素） 生体情報（生体要素） 概要 ユーザーが知っている情報 ユーザーが持っている物の情報 ユーザーが自身の情報 例 パスワード、秘密の質問、 Android のロックパターン PC、 スマホ 、USBセキュリティキー 指紋、網膜、声紋、歩行パターン、タイピングの癖 これらの認証に用いる情報のことを「クレデンシャル情報」といいます。 そして、これらを前提として 多要素認証 上記3種類の情報から2種類以上を組み合わせた認証のこと 必然的に多段認証となる 多段認証 上記3種類の情報によらず、2種類の認証を組み合わせた認証のこと 「パスワード」＋「秘密の質問」はどちらも知識情報だが、多段認証となる 関係性としてはこんなイメージです。 ただ、紛らわしい用語といして「パスワードレス認証」があります。おそらく原義的な意味では「知識情報以外による認証」という意味だったと思うのですが、今日では実質的に多要素認証を指している様です。注意しなければいけないのは 「パスワードレス認証＝生体認証（生体情報を用いた認証）」とは限らない ということです。 ■ 認証に関する仕様 認証に関連する仕様としては OAuth 2.0 SAML OpenID Connect FIDO 2.0 といろいろありますが、 既存環境との互換性などの考慮が不要であれば 現状では OpenID Connect と必要に応じて FIDO 2.0 の組み合わせが無難だと判断しています。判断した理由と併せて、それぞれの比較検討をまとめてみます。 OpenID Connect OpenID Foundation によって規定されている認証認可に関する仕様です。 OpenID と OpenID Connectは別物なので注意、略す場合はOIDCと略すのが一般的です。 ざっくりいうと既存の仕様を統合して規定された仕様になります。詳細は OpenID Foundation Japan 工藤氏のスライド（各仕様との関係性については33スライド目）が詳しいです。 なぜOpenID Connectが必要となったのか、その歴史的背景 from Tatsuo Kudo OpenID ConnectとOAuth2.0の違い 先述のスライドにある様に OpenID ConnectはOAuth 2.0を拡張した仕様でもあります。OAuth 2.0の挙動である サーバーに認可コードをリク エス ト 認可コードを取得 認可コードを用いて、サーバーにアクセス トーク ンをリク エス ト アクセス トーク ンを取得 という挙動は OpenID Connectにも仕様として含まれています。さらに OpenID Connectではさらに サーバーに認可コードをリク エス ト 認可コードと ID トーク ン を取得 認可コードを用いて、サーバーにアクセス トーク ンをリク エス ト アクセス トーク ンと ID トーク ン を取得 という挙動も規定されています（選択可、 OpenID Connectを利用する場合はID トーク ンを使う方が一般的だと思います）。 ID トーク ンには 「誰」が認証されたか 「どのサーバー」で認証されたか 「いつ」認証されたか 「どの様な基準」で認証されたか 認証されたユーザーの「属性情報（姓名、メールアドレスなど）」 が含まれています。 OAuth 2.0は「認可の仕様であって認証の仕様ではない」と言われますが、OAuth 2.0ではID トーク ンは規定されていないので 「誰についての認可コードなのか」はわからない （OAuth 2.0の外で認証は行う前提）のです。 この辺りの挙動の説明については Authlete 川崎氏の動画解説が詳しいです。 ID トーク ンについては同氏のQiita記事も併せて確認すると良いでしょう。 qiita.com OpenID Connectと SAML の違い シングルサインオン （SSO）を実現する仕様として SAML がよく使われますが、 OpenID Connectでも実現でき近年は Google や Facebook , GitHub など着々と OpenID Connect でのSSOに対応するサービスが増えてきました。 前述の通り OpenID Connect は SAML の流れも組んでいますが、 SAML はその生い立ちから社内ネットワーク 1 での利用を想定しています。そのため SAML での認証処理はユーザーの同意を必要とせずに処理することができます。認証処理は信頼されているサービスで行われるという前提です。 社内サービスの間でのみ用いられる場合であれば問題ありませんが、社外のサービスとの間でもSSOするのであればユーザーの同意処理は挟みたいところです。 あとは実装者の観点でいくと SAML が XML ベースの通信フォーマットなのに対して、 OpenID Connectは JSON ベースの通信フォーマットとなります。 FIDO 2.0 FIDO Alliance によって規定されているパスワードレスに関する仕様。 FIDO 1.0ではFIDO UAF, FIDO U2Fという2つの仕様から構成されていましたが、それぞれ Paypal と Google が推進していて、さらに Apple が別仕様としてTouchIDを推進するという分断状態だったようです。そしてこの状況を解決するためにFIDO U2Fをベースとして、FIDO 2.0が規定されました。 FIDO 2.0は大きく2つの仕様によって構成されています。 WebAuthn CTAP2 サーバーとクライアント間の 通信プロトコル 。 W3C に提案され RFC として標準化。 クライアントと認証デ バイス 間の 通信プロトコル 。FIDO Allianceにより規定。 特徴としては、FIDO 2.0ではサーバーとクライアントの間で クレデンシャル情報を直接通信することがないこと です。FIDO 2.0ではクライアントサイドで 認証処理を行なった結果のみ をサーバーに送信します。これにより通信経路からのクレデンシャル情報の流出を避けることができます。 ちなみにFIDO U2Fが改名されてCTAP1となっています。 OpenID ConnectとFIDO2.0の位置関係 OpenID ConnectとFIDO 2.0の関係は以下の様になっています。 OpenID Connectはサービス間（サーバー間）での認証 プロトコル 2 、FIDO2.0はサーバーとクライアントの間で認証情報をやり取りするWebAuthnとクライアントと認証デ バイス の間で認証処理を行うCTAP2となります。 FIDO2.0の対応状況 FIDO 2.0はクライアントサイドで動作するため対応するOSとブラウザが必要になります。2021/10現在では主な環境では対応済みです。 OS Windows 10 Version 1903以降 macOS Big Sur以降 Android 7.0以降 iOS /iPadOS 14以降 ブラウザ Google Chrome Mozilla Firefox Microsoft Edge Apple Safari ■ 認証サーバーソフトウェア OpenID ConnectやFIDO 2.0はそれぞれ多くの仕様によって詳細が規定されています。これらをゼロから実装するのはサービスの開発効率として非現実的です 3 。 認証サーバーとして利用できる ミドルウェア として OpenAM と Keycloak があります。どちらも OSS ですが概要を調べてKeycloakを試すことにしました。 OpenAM Sun社の商用製品 OpenSSO が起源 ForgeRock社とOpensource Solution Technology社がフォークして OSS 化 先発なこともありシェア的にはKeycloakよりも多い様子 Keycloak コミュニティベースの OSS で比較的後発 国内では NRI が積極的に情報発信し、保守ベンダにもなっている OpenAMとKeycloakの比較については NRI 和田氏の以下スライドが詳しいです。タイトルでは翻訳プロジェクトの紹介となっていますが、前半部分はOpenAMからKeycloakへの移行プロジェクトについて書かれています。 Keycloakの実際・翻訳プロジェクト紹介 from Hiroyuki Wada ■ まとめ・下半期の予定 さてここまで2021年上半期で調査検討した内容をまとめました。引き続き下半期では以下のような検証を行っていこうと考えています。 実際に検証用のシステムを構築して運用を想定した検証 Keycloakはどの程度サーバースペック要求するのか検証 Keycloakでのユーザー属性情報の管理はできるのか、ユーザー属性に独自項目の追加はできるのか クライアント側の認証手法によって挙動や運用に差異が出ないか それではまた下半期末に検証の結果をまとめたいと思います。 認証技術の調査や選定を行なっている方の助けになれれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com イントラネット という表現は最近めっきり聞かなくなりました……。 ↩ 厳密にはサーバー間の通信のみというわけではないですが。 ↩ 認証処理をビジネスにするならともかく、大体の場合は認証処理の実装を頑張ってもセールスポイントにはならないですし。 ↩

こんにちは、技術広報チームです！ ラク スの開発組織ではこの1年半、技術広報に力を入れ、会社の技術的な取り組みの発信を行ってきました。 ちょうど2021年8月末に エンジニア・デザイナー採用サイト の技術コンテンツを強化してリニューアルしたタイミングでもあり、 ここまでの取り組みを振り返ってみたいと思います。 ラクスの技術広報について 取り組みのきっかけ ゴールの考え方 やってきたこと 採用Webサイトを技術情報のハブにアップデート 外部イベント登壇 エンジニア登壇実績のご紹介（一部） 主催イベント 10月の技術イベントのご案内 社内登壇メンバーのスライド、動画も公開 テックブログ まとめ そして最後に宣伝 ラク スの技術広報について 皆様の会社には「技術広報」を担当されている方はいらっしゃいますか？ 担当領域こそ各社それぞれかと思いますが、技術広報の仕事は 「エンジニアやデザイナーに対する、専門領域の情報提供を通じた マーケティング 」 といえると思います。 具体的活動内容は メディア戦略・運用（テックブログ、自社サイト） 外部イベント登壇 自社のイベント主催 などが挙げられ、 ラク スも上記を中心としています。 技術広報活動はエンジニア、採用、 マーケティング 各部門との幅広い調整が必要な他、技術の理解や興味関心も求められます。したがって、技術広報活動を現場エンジニアが担当するケース、しないケースでメリット／デメリットがあります。その点当社では「技術広報と兼務のエンジニア」はおらず、専任体制となっています。 それにより、スピーディな部門間調整やエンジニア登壇のコーディネートやサポート、広報活動量を確保しようとしています。現場感覚の裏付けは開発チームのエンジニアとしっかり協力して担保しているほか、技術広報チームにもSE出身者がいて、その経験を活かしています。 取り組みのきっかけ ラク ス開発本部のビジョンは 「日本を代表する SaaS エンジニア集団になる」 です。展開中のプロダクトが成長中で、 一人でも多くのエンジニア、デザイナーの方に仲間に加わっていただきたい と日々思っています。一方で、 ラク スが提供するのはBtoBの業務効率化／付加価値向上プロダクトです。普段会社の経費精算や勤怠打刻などで使うなど、日常接点のないエンジニアに対しては 社名認知率が上がらない という課題がありました。そこで、開発本部からの技術情報発信を増やすべきという方向性からスタートしました。 ゴールの考え方 そこで認知率向上を目標にして、下記メインで活動を行うことにしました。 エンジニア・デザイナー採用Webサイト 外部イベント登壇 主催イベント テックブログ ここで技術広報の貢献をどう定義、計測するかについては、各社個性が出るところではないかと思います。 ①定性指標・ 定量 指標、②プロセス指標・結果指標の組み合わせ で設計するケースが多いのではないでしょうか。 ラク スはといえば、 技術広報自身が開発組織の成長に主体的に貢献する意識を持つため、 定量 的なKPI、結果指標への力点が大きい ように思います。 もっとも本記事を読んでいただいている方のフェーズによっては、データが存在しないとか、アウトプットする文化がないというケースもあると思います。その場合は記事投稿数などのプロセス指標を一旦重視していくのも手かもしれません。KPIの数値は最初から完璧なものではないので、スモールスタートで随時見直していく可能性はあります。これらを開発マネジメント層と合意を取ったうえで、アウトプットの強化が始まりました。以降に実際の取り組みをご紹介します。 やってきたこと 採用Webサイトを技術情報のハブにアップデート エンジニア・デザイナー採用Webサイト 自体は過去の早い段階でリリースしていました。 ただ、当社の技術的な取り組みを知っていただくために、これまでのエンジニアの活動を一挙に見られるコンテンツが欠かせず、それはまだまだ不十分と考えていました。 そんな「技術情報のハブを作りたい！」という思いをもとに8月末にリリースしたのが、こちらのコンテンツです！ TECH INFO（技術・デザイン情報）： スペシャ リストが最前線で取り組む実務課題インタビュー career-recruit.rakus.co.jp MEDIA（メディア掲載）： 外部メディアに掲載されたエンジニアインタビュー career-recruit.rakus.co.jp SLIDE（資料）：自社イベントへの登壇資料（後述） career-recruit.rakus.co.jp VIDEO（動画）：自社イベントの動画 アーカイブ （後述） career-recruit.rakus.co.jp SPONSOR（協賛実績）：外部イベントの協賛実績（後述） career-recruit.rakus.co.jp つい最近リリースしたばかりなのでこれからのコンテンツですが、いろいろな視点から当社のエンジニアの活動を知っていただけるような企画を進めていきます。 外部イベント登壇 昨年、今年はコロナの影響で外部イベント全体も影響を受けてしまいましたが、当社技術スタックや開発スタイルに関わるカンファレンスを中心に継続的に協賛を行っています。技術広報はイベントの検討や登壇のコーディネートなどを行っています。過去のイベント協賛実績は こちら にまとめていますので、ご覧ください。 エンジニア登壇実績のご紹介（一部） 2021/6/25 Scrum Fest Osaka 2021 経験ゼロからはじめる！10年以上続くプロダクトのアウトカム創出戦略 2020/12/12 PHPカンファレンス 2020 レガシーシステムに自動テストを導入する第一歩 2020/8/27 Developers Summit 2020 KANSAI 関西的なノリで変化の波をノリこなすチームの取り組み 2020/6/26 Scrum Fest Osaka 2020 スクラムちゃうがなと言われてもやってみぃひん？ 2020/5/20 Agile Japan 2020 「中小企業のエンジニアチームを”楽”にする」を目指す組織マネジメントの変わる勇気と変えない勇気 主催イベント Rakus MeetUpやLT会、TechCafeなど、各種コンセプトでイベントを年50回強開催しています。これらは主に connpass で展開しています。技術広報は企画立案や年間スケジュールの策定、ご登壇者様への各種ご依頼・連絡、司会・運営にかかわっています。年間計画は関係者がいつでも見られるようになっているほか、登壇に関する困りごとなどがないか技術広報が主体的かつ気軽にコミュニケーションする工夫もしています。 connpass開催のイベントの例 大変有難く嬉しいことに、フロントエンド、UI/UX、自動化、リーダブルコードなど、オンラインになっても回を重ね、多くの方にご視聴いただけるシリーズとなりました。connpassのメンバー登録いただいている方は6,000名に近づき、イベントには延べ7,000名弱もの方にご参加いただくまでに成長しました。これらのイベントは多数の登壇者様のお力添えあってこそ実現できております。この場を借りて改めて厚く御礼申し上げます。 10月の技術イベントのご案内 例えば、下記のようなテーマで定期開催しております。ご興味をお持ちいただけるものがございましたら、是非ご視聴ください！ 10/6開催 大規模SaaSのフロントエンド開発／レガシー改善、Vue.js、マルチブラウザ対応 10/13開催 PHPerのための「Laravel 入門を語り合う」PHP TechCafe 10/20開催 UI/UXデザイナーLT会 - vol.5 10/27開催 エンジニアの勉強法ハックLT- vol.6 社内登壇メンバーのスライド、動画も公開 コロナの影響でなかなかオフィスにお越しいただいての開催ができないのですが、逆にオンラインの良さを生かして、リニューアルしたサイトで過去のRakus MeetUpでの当社エンジニアの トーク やスライドを公開することにしました。今後も随時追加していきますので、是非見てみてください。 登壇動画一覧はこちら Rakus MeetUp スライド一覧はこちら 是非ご覧ください！ テックブログ このテックブログは2017年から運営していますが、技術広報は直近ではブログのテーマ策定や構成設定のサポート、一部記事執筆やKPIの運営を行っています。 主催イベントでの話は実務から得られた 中長期的な課題 が多いのですが、こちらは最近のエンジニア界隈での技術的なTipsも多くなっています。 まとめ 以上、駆け足ではありますが ラク スでの技術広報活動のご紹介でした。実際に活動を行ってみて、 定量 的なKPIで見てもより多くの方に当社の名前や技術的な取り組みを認知していただけ始めているという実感がでてきました。採用説明会でも、技術イベントに参加して当社のことを知ったという方がいらっしゃいました。 もちろん、まだまだ改善すべき点はあります。一層満足いただけるコンテンツ・体験をご提供し、さらには「ともに ラク スで働く仲間」という選択肢を検討していただくために、地道な努力を続けていきたいと思います。　　 簡単ではありましたが、 ラク スの「技術広報」という存在について知っていただけましたなら何よりです。それではまた、イベント等でお会いできることを楽しみにしております！ そして最後に宣伝 ラク スでは 一緒に技術広報を盛り上げていただける方もお待ちしています ！ 技術コミュニティが大好きかつ、仮説を追いながら広報観点で開発組織・事業成長に取り組んでみたいという方！是非こちらまでお気軽にご連絡ください↓↓ forms.gle お待ちしております！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/

こんにちは この記事ではLaravelの環境構築を行い、ごくシンプルなWebAPIを作成します。 Larevelはバックエンドのロジックから画面の描画まで行うことができますが、今回は画面の開発は行わず API の開発のみを行います。 バックエンドを API として開発することで、外部アプリケーションと連携することができる・ フロントエンドと 疎結合 になり保守性が高くなる・フロントエンドと並行して開発することができるといった恩恵を享受することができます。 Laravelは MVC モデルに準じた フレームワーク ですが、 API を開発する際は画面(View)が不要になります。したがってこの記事ではModelとControllerのみを作成します。 環境・MWのバージョン 作業手順 1. Laravelの環境構築 2. LaravelでAPIを作成・動作確認 ※ Laravel8 ではこの記法が使えません。Laravel8で開発をする際はご注意ください。 create メソッド indexメソッド show メソッド update メソッド delete メソッド 3. PostmanでLaravelで作成したAPIの動作確認 終わりに 環境・MWのバージョン Ubuntu 20.04 PHP 8.0.10 Laravel 6.20.34 sqlite3 ※ 2021年9月現在Laravelはバージョン8系までリリースされていますが、LTSはバージョン6系です。また、リリースから一定期間が経過しており動作が安定している・ 日本語情報が充実しているというメリットがあるのでLaravel 6系を採用しています。 作業手順 Laravelの環境構築 Laravelで API を作成 PostmanでLaravelで作成した API の動作確認 1. Laravelの環境構築 ① PHP およびLaravelの動作に必要なパッケージのインストール 以下のコマンドを実行します。 sudo apt-get update apt install -y software-properties-common add-apt-repository -y ppa:ondrej/php apt-get update # Laravelの動作に必要なパッケージおよびsqliteをインストール apt install -y php8.0 sqlite3 php8.0-bcmath php8.0-mbstring php8.0-xml php8.0-zip php8.0-sqlite コマンド実行後、 PHP とLaravel稼働用の各種パッケージが正常にインストールされていることを確認します。 $ php -v PHP 8.0.10 (cli) (built: Aug 26 2021 15:50:07) ( NTS ) Copyright (c) The PHP Group Zend Engine v4.0.10, Copyright (c) Zend Technologies with Zend OPcache v8.0.10, Copyright (c), by Zend Technologies $ php -m [PHP Modules] . . . . (長いので省略します) ② Composer のインストール・Laravel プロジェクトの作成 composerをインストールするために以下のコマンドを実行します。 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php composer-setup.php php -r "unlink('composer-setup.php');" sudo mv composer.phar /usr/local/bin/composer composerがインストールされていることを確認します。 $ composer -v ______ / ____/___ ____ ___ ____ ____ ________ _____ / / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/ / /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ / \____/\____/_/ /_/ /_/ .___/\____/____/\___/_/ /_/ Composer version 2.1.8 2021-09-15 13:55:14 続いて、Laravelプロジェクトを格納する ディレクト リを作成してその ディレクト リ内でLaravelのプロジェクトを作成します。 $ mkdir /usr/local/project cd /usr/local/project composer create-project --prefer-dist laravel/laravel blog "6.*" ※ "6.*" のように数字を設定することで利用するLaravelのバージョンを指定することができます。 コマンド実行後、Laravelのプロジェクトが作業 ディレクト リにできています。 Laravelプロジェクトの ディレクト リに移動してサーバを起動します。 $ cd /usr/local/project/blog php artisan serve Laravel development server started: http://127.0.0.1:8000 [Tue Sep 21 23:02:11 2021] PHP 8.0.10 Development Server (http://127.0.0.1:8000) started URLにアクセスしてLaravelの初期画面が表示されれば環境構築は完了です。 2. Laravelで API を作成・動作確認 次にLaravelで API を作成します。 API の要件は以下の通りです。 タイトルと本文を投稿する(Create) 投稿一覧を表示する(Read) 指定したidの投稿を表示する(Read) 投稿を編集する(Update) 投稿を削除する(Delete) では作業に移ります。 ⑴ データベース設定 Laravelはデフォルトでは mysql を使用するように設定されていますが、今回はより手軽に使える sqlite を使用します。 ・ データベース用ファイルを作成 $ touch database/database.sqlite ・ 設定ファイルの変更 変更前 # Laravelのデフォルト設定 DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=laravel DB_USERNAME=root DB_PASSWORD= 変更後 DB_CONNECTION=sqlite ・ マイグレーション ファイルの作成 テーブル作成用の マイグレーション ファイルを作成します。 $ php artisan make:migration craete_posts_table マイグレーション ファイルを下記のように変更して、テーブルを作成します。 # 変更箇所のみ記載 public function up() { Schema::create('posts', function (Blueprint $table) { $table- > increments('id'); $table- > string('title'); $table- > string('content'); $table- > timestamps(); }); } $ php artisan migration コマンドを実行してエラーが表示されなければ成功です。 ・ モデルクラス作成 続いてモデルクラスを作成します。 Laravelはモデルクラスに ビジネスロジック を配置することが多いですが、今回はコードの量自体が少ないのでほとんど使いません。 $ php artisan make:model Post <?php namespace App; use Illuminate\Database\Eloquent\Model; class Post extends Model { // fillableに指定したプロパティは入力可能になる protected $ fillable = [ 'title' , 'content' , ] ; } ・　ルーティングの設定 Laravelのルーティングは`通常``route/web. php に定義しますが、APIは route/ api . php ```に定義します。 api . php にルーティングを定義すると、URLのはじめに/ api が自動的につきます。 (例： '/ hoge /fuga' と定義すると実際のエンドポイントは'/ api / hoge /fuge' になります。) API のURL設計もサポートする親切さがLaravelの魅力の1つだと思いました。 Route::middleware(['middleware' = > 'api'])- > group(function () { # 投稿作成 Route::post('/posts/create', 'PostController@create'); # 投稿一覧表示 Route::get('/posts', 'PostController@index'); # 投稿表示 Route::get('/posts/{id}', 'PostController@show'); # 投稿編集 Route::patch('/posts/update/{id}' , 'PostController@update'); # 投稿削除 Route::delete('/posts/{id}', 'PostController@delete'); }); ※ Laravel8 ではこの記法が使えません。Laravel8で開発をする際はご注意ください。 このルーティングにより、 ・ http://127.0.0.1:8000/api/posts へのGETリク エス トはPostController に定義されているindex メソッドで処理 ・ http://127.0.0.1:8000/api/posts/create へのPOSTリク エス トはPostControllerに定義されているcreateメソッドで処理 されるようになります。 GETメソッドとPOSTメソッドは広く使われているHTTPメソッドですので特に説明は不要かと思います。 PATCHメソッドはリソースの一部を変更するためのメソッドです。 DELETEメソッドは読んで字のごとくリソースを削除するメソッドです。 PATCHメソッドやDELETEメソッドではなく、POSTメソッドで実装しても問題ありませんが、PATCHやDELETEを使用する方がそのリソースが何をするかが明確に なるのでより望ましいと思います。 ルーティングが設定できたので次はコントローラを作成します。 ・ コントローラの作成 コントローラはViewからリク エス トを受けてModelにデータを渡します。 まず、以下のコマンドでコントロー ラク ラスを作成します。 php artisan make:controller PostController PostContoroller. php を以下のように変更します。 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; use App\Post; class PostController extends Controller { # 投稿作成 public function create ( Request $ request ) { $ post = new Post () ; $ post -> title = $ request -> input ( 'title' ) ; $ post -> content = $ request -> input ( 'content' ) ; $ post -> created_at = now () ; $ post -> updated_at = now () ; $ post -> save () ; return response () -> json ( Post :: all ()) ; } # 全件取得 public function index () { $ posts = Post :: all () ; return response () -> json ( $ posts ) ; } # 投稿表示 public function show ( Int $ id ) { $ post = Post :: find ( $ id ) ; return response () -> json ( $ post ) ; } # 投稿編集 public function update ( Int $ id , Request $ request ) { $ post = Post :: find ( $ id ) ; $ post -> title = $ request -> input ( 'title' ) ; $ post -> content = $ request -> input ( 'content' ) ; $ post -> updated_at = now () ; $ post -> save () ; return response () -> json ( $ post ) ; } # 投稿削除 public function delete ( Int $ id ) { $ post = Post :: find ( $ id ) -> delete () ; return response () -> json ( Post :: all ()) ; } } create メソッド Laravelが MVC モデルに準拠した フレームワーク であるのを考えると、リク エス トを受け取る・受け取ったデータをDBに保存するといった処理はモデルクラスやサービスクラスに記載すべきですが、今回はお試しということで直接コントロー ラク ラスに書きます。 また、リク エス トパラメータの入力値チェックやエラーハンドリングも今回は省略します。 リク エス トで送られてきた投稿をPostテーブルに保存し、indexメソッドと同じように投稿一覧を json 形式で返します。 Laravelで json をリク エス トを受け取る際には特に特別な下処理は必要ありません。 リク エス トパラメータの Content-Type ヘッダを application/json と指定し、 json を送ればinputメソッドでその値を取得することができます。 indexメソッド 投稿一覧を json 形式でレスポンスとして返します。 json ()メソッドはLaravelで用意されているメソッドです。 引数に配列を渡すと自動的に json に変換してくれます。 (第二引数にレスポンスの ステータスコード を、第三引数にContent-Typeヘッダを指定することもできます。省略した場合はそれぞれ200 , application/ json がデフォルトでセットされます。) show メソッド Post::find() メソッドは引数に渡したidで投稿を検索します。 (idしか渡すことができないことに注意してください。 id以外のカラムで検索する際はwhere メソッドを使用します。) update メソッド findメソッドで変更対象の投稿を検索し、プロパティの値にリク エス トパラメータを代入します。 delete メソッド deleteメソッドで指定したリソースを削除します。 レスポンスをどのようなものにするかは選択の余地があると思いますが、今回は対象の投稿が正常に削除されたことを確認しやすいように 投稿一覧を返すようにします。 3. PostmanでLaravelで作成した API の動作確認 API の動作確認を行います。 curl コマンドでLaravelのサーバにリク エス トを送っても良いですがパラメータを指定するのがやや面倒です。 そこで、 API の動作確認ツールPostmanを使用します。 www.postman.com Postmanを動かすまでの手順はこちらの記事に分かりやすく記載されています。 www.tairaengineer-note.com 試しにLaravelで作成した投稿作成 API にリク エス トを送ってみます。 画像のようにHTTPメソッド・エンドポイント・リク エス トパラメータを指定してSendボタンを押します。 レスポンスが正常に返ってきていれば成功です。 続いて先ほど作成した投稿を取得します。 投稿表示 API はGETメソッドでリク エス トを送ります。 投稿が表示されています。 終わりに 今回はLaravelでWebAPIを作成しました。 フルスタックフレームワーク というイメージの強いLaravelでしたが、WebAPIも特に苦心せず作成することができました。( API の開発にLaravelを採用すべきなのかという問題はあると思いますが...) 個人的な感想としては api . php にルーティングを定義することでURLに/ api を付与してくれる機能が良いと思いました。 Laravelのような高性能な フレームワーク を使うと自然とセオリーに沿った設計になりやすいです。 皆さんもWebアプリケーションだけではなく、WebAPIの開発にもLaravel を利用してみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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年8月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「PHP8.1の新機能」について語り合いました。 rakus.connpass.com PHP8.1の新機能は8.0に比べれば少ないとはいえ、順番に追いかけてみると思ったより大きなボリュームになったためイベント内容を2回に分けてレポートします。今回は後編として後半の半分をご紹介します。 前編はこちら。 tech-blog.rakus.co.jp PHP8.1 新機能について Pure intersection Types 他の言語ではあまりない機能 New never type 静的解析などで役立つ期待あり New array_is_list function ネーミングに関する議論 Final class constants New fsync function エラーで落ちても書き込みは保証 Explisit octal integerliteral notation 利用シーンは少ないが事故を防げそう Restrict $GLOBALS usage パフォーマンス向上のための使用制限 Deprecate passing null to non-nullable arguments of internal functions nullが入りうるパターンに要注意 その他の変更点 今後はPHPUnitやLaravelをテーマに開催予定 PHP8.1 新機能について PHP8.1の新機能は弊社のメンバーが事前にShowNoteにまとめています。今回はこの後半部分の新機能をみていきました。 hackmd.io Pure intersection Types 交差型 と呼ばれ、型AとBがあるときに、AでありかつBの（両方の性質をもつ）型を表すときに A&B のように記述します。 「AまたはB」のような表現は8.0で Union Type という型が導入されており、 縦棒で A|B のように記述します。 「それの逆版が8.1で入ります。」と紹介されました。 ※参考：PHP8.0で導入されたUnion Type wiki.php.net この交差型に対しては次のような意見が出ました。 新しく型を定義しなくても良くなる インターフェース名から両方の特性を持っているっていうのがひと目でわかるので、意図が分かりやすくなるし、管理もしやすくなるのかな？ 色々と賛否や考え方が出るかもしれません 交差型のサンプルコード（ ShowNote より抜粋） <?php class A { private Traversable & Countable $ countableIterator ; public function setIterator ( Traversable & Countable $ countableIterator ) : void { $ this -> countableIterator = $ countableIterator ; } public function getIterator () : Traversable & Countable { return $ this -> countableIterator; } } ※参考：サンプルコードで使われている Traversable と Countable インターフェースについて www.php.net www.php.net 上記のコードを元に詳しく解説されました。今までは Traversable と Countable という2つの振る舞いを持つオブジェクトを作るようなケースでは両方を継承する新しいインターフェースを作る必要がありました。バリエーションが増えてくると、この振る舞いとこの振る舞いとこの振る舞いの組み合わせで…というように、どんどん複雑な インターフェイス が増えてきます。交差型を使うことで新しく型を定義しなくても良くなり、上記のように Traversable と Countable の両方を持っているというのがひと目でわかりやすくなります。 ただし、使う上では注意も必要です。 ループできる Traversable とカウントできる Countable はセットになりがちと思えますが、全然関係ないAとBという属性が Traversable でくっつけると密結合になるのかなと思うので、気をつけないと変な設計になる。 実は嬉しいところがあんまりない。 あまり使いすぎると複雑な設計になるので注意が必要です。交差型が必要になるようなシーンでは以下のような疑問を持ってみるのも良さそうです。 そもそもここまで細分化していることがおかしいのでは 連想できない無関係なものが一つのオブジェクトにまとまっているのがうまく ドメイン を分解できていないって事なのでは 他の言語ではあまりない機能 また、 PHP 以外の プログラミング言語 にも目を向けた議論がありました。 普通の静的型付言語でもあまりない機能。 どちらかといえば動的型付言語に拡張で導入される例が多い気がします。 多重継承が前提の機能なのでいきなり使うようなものじゃないですが、使えると便利。 正直ここまでやるなら Haskell 系の言語や Scala とか、多重継承が普通にできる設計かつ強い静的型付の言語を使うほうが良い気もしますが、TypeScriptでも導入されているので動的型付言語ならではの使いどころがあるのではないでしょうか？ 「便利だけど、あまり使うシーンはない？」という、やや消極的な意見が多かったものの、 RFC をみてみると賛成意見がほとんどで採択されていました。 RFC では賛成30で採択 交差型は「もともとPhpStormやPHPDocでサポートされていたもの」とのことで、交差型が導入されることで何かを壊すということもなく、「表現の幅が広がる」ということから受け入れられやすかったのではないか？とのことでした。 ※参考：PHPStanの作者のブログ（PHP8.1の機能ではできないが多重継承的なことができる事例も紹介されている） medium.com New never type 常に例外出したり、exitで終わってしまうような処理の返り値に never と書いて表せるようになります。「レガシーなコードであればあり得る話だよなあと思うので、かなり使い所が多いんじゃないか」とのことです。 <?php function redirect ( string $ uri ) : never { header ( 'Location: ' . $ uri ) ; exit () ; } RFC 段階では never と noreturn の二案があったそうですが、最終的に never になりました。参加者からも「 noreturn のほうがわかりやすい気もするんですけどね。」という意見がありました。「悪くなかったと思うんですけど、二語になるからややこしいって話があった」「（noとreturnの）間にハイフン入れるのか、アンダーバー入れるのか？ってなって一語にしようって話になったようです。」とのことです。「静的解析などをするうえでは never は別の目的で使いたいので noreturn を推していたみたいです」という背景もあったようです。 静的解析などで役立つ期待あり 上記のサンプルコードのように、リダイレクトしたり exit() で終わってしまうときに書いておけば「静的解析とかでもうまく使えそうな気がしますね。」とのことです。PhpStormで「 redirect を呼んだ次の行とかに違う処理があると実行されない ステートメント という警告が出せる。」という実現イメージです。 最終的に never が採用されましたが、静的解析に関しては役立つ期待が持てそうです。「個人的にはReadonlyに並んで期待している機能ですね。」とのことでした。 New array_is_list function 配列のキーが0番目からスタートする配列なのか 連想配列 なのかを判定する機能です。 array_is_list という関数を使うことで、0番目から始まる配列なら true 、それ以外は false が返ります。 <?php $ list = [ "a" , "b" , "c" ] ; array_is_list ( $ list ) ; // true $ notAList = [ 1 => "a" , 2 => "b" , 3 => "c" ] ; array_is_list ( $ notAList ) ; // false 参加者から質問がありましたが、 [0=>"A", 2=>"B", 3=>"C"] という 連想配列 でも false が返るようです。 ネーミングに関する議論 array_is_list というネーミングに関しては様々な議論があったようです。 RFC の議論を読むと is_list という候補もあったことが書かれています。 wiki.php.net 参加者からも「名前がすごいですよね。」「何だろう？同じことを言っている感じがする。」「名前を見れば見るほどモヤモヤしますね。」という声があがっていました。 ここで議論しているものは「 コンピュータサイエンス でいう連結Listとは違う」「これまでList構造というのは分割代入のために使われていた」が、そうではなく「純粋な配列」とのことです。「静的解析などではlistという型が使えるようになっていて連番で表す」ということで、そういう経緯もあってこういう名前になったのではないか？、「奇跡的なバランスでできた名前ですね。」と解説されました。 Final class constants 継承したclassの定数をオーバーライドすることを禁止することが出来るようになります。これまではclass間で定数を書き換えることができたため、親classの設計者の意図に反して「一定ではない」状態が起こりうるようになっていました。 <?php class Foo { final public const X = "foo" ; } class Bar extends Foo { public const X = "bar" ; } // Fatal error: Bar::X cannot override final constant Foo::X 前編の「 Readonly Properties 」で final の使い方との違いが紹介されましたが、「 Readonly とはまた使い所が違う」とのことです。 New fsync function ファイルの書き込み内容をメモリから実際にファイルへ書き込む機能です。 これは内部実装が変わって、「細かく言うとI/Oの順番が変わった」ことで、「途中で処理が止まっても書き込みをちゃんとしてくれる」とのことです。 エラーで落ちても書き込みは保証 ここでは「趣味で PHP でDBを作っている」という参加者から利用シーンの一例が紹介されました。 キャッシュメモリ からディスクに書き込むところでエラーハンドリングとかで fsync が使えたらな、と思っていた そういう用途でしかあまり使わない たしかに用途は少なそうですが、使い方がイメージできて他の参加者も納得していました。 Explisit octal integerliteral notation 0o （ゼロ・オー）という接頭詞を置くことで8進数と明示できるようになりました。 元々、 0 で始まる場合は8進数として扱われ、例えば 16 == 016 の 016 は8進数と解釈されるためfalseになります。 0o が使えるようになり視覚的にわかりやすく表記できます。 利用シーンは少ないが事故を防げそう 8進数を使う場所は限られるのでいつ使うのだろう？という疑問もありますが、一例として chmod の利用シーンが紹介されました。 chmod でファイルの パーミッション を設定するとき 0755 と書くと正しく パーミッション を設定できますが、間違えて 755 と書くと意図しない動作になります。 「誰かが 0755 の 0 が邪魔じゃない？と思って消したら事故になる、というケースを防げるんじゃないかと思います。」と、 0o と明記することで事故が防ぎやすくなるメリットの一例が紹介されました。 ※参考： chmod 関数 PHP: chmod - Manual また、他にも「 PHP のバージョンアップしようとした時に、8進数や16進数の振る舞いが変わりますとなった時にどうやって探せば良いんだと思ったんですが、接頭詞を置けば探しやすくなりますね。」という意見もありました。 そのほか、なぜ 0 と o という見間違えやすい文字を連続して使うのか？という意見もありましたが、8進数＝octaという意味から来ていることが解説されました。16進数はHexの x を使って 0x です。このあたりは PHP 以外の言語でも採用されている表記法でもあります。 Restrict $GLOBALS usage ここからは仕様変更の機能についての紹介です。スーパーグローバルの $GLOBALS で他の変数にアクセスできる特殊な変数ですが、一部の使い方ができなくなります。 <?php $ a = 1 ; $ GLOBALS [ 'a' ] = 2 ; var_dump （ $ a ）; // int（2） // Generates compile-time error: $ GLOBALS = [] ; $ GLOBALS += [] ; $ GLOBALS =& $ x ; $ x =& $ GLOBALS ; unset ( $ GLOBALS ) ; パフォーマンス向上のための使用制限 なぜこのような変更が行われたのかについて、次のように解説されました。 他の変数にはない特殊な使い方が出来るようにしていたことで、 PHP 全体の配列アクセスへの ボトルネック になっていた 見るからに誰も使わなさそうな処理が PHP ユーザー全体の処理の足かせになっていた 世に転がっているライブラリを覗くとそんな使い方しているやつほとんど無いやとなった じゃあ消しちゃおうということで使えなくしようとなった PHP 全体の配列アクセスのパフォーマンス向上のため、「元々はできていたんだけど今後はできなくなります。」とのことです。誰も使わなそうではありますが、「ある種便利な機能だったと思うんですよね。 $GLOBALS 経由でなんでもアクセスできましたし。テストで変数全部吹っ飛ばすとか。」「無理やりいじるとかはあるのかなと。 WordPress のカスタマイズ案件とかで、ベース部分はさわれないけどどうにかこうにかしたいみたいなケースとか。」という意見もあり、使わないだろうと決めつけるのも危険かもしれません。 なお、「 PHP8.1でいきなりエラーになります 」とのことで、非推奨化による警告などではない点も注意が必要です。 なお、 $GLOBALS の使用については上記のような特殊なケースで使用することはあるかもしれませんが、本来は「これ自体使うべきではないですね。」という意見も出ていました。今回の変更の影響にかかわらず、 なるべく $GLOBALS を使わず別の方法を検討するほうが良さそうです。 Deprecate passing null to non-nullable arguments of internal functions str_contents という標準関数の第2引数に null を指定することが非推奨化されます。 <?php // PHP8.1 では非推奨、PHP9 では警告が出力される str_contains ( "string" , null ) ; str_contents はPHP8.0から導入された標準関数で、第1引数の文字列中に第2引数の文字列が存在する場合にtrueが返されます。 PHP: str_contains - Manual PHP8.0では第2引数にnullを指定するとtrueが返されていましたが、これ自体が不具合だったようです。「 PHP のユーザー定義関数とかだと普通はStringって型宣言しているので通らないんですが、 PHP のネイティブな関数だからこそ入っちゃったバグですね。」とのことです。内部的にnullをキャストしたことで空文字列として処理され、「空文字列はあらゆる文字列の部分集合なのでtrueになる」ようです。 nullが入りうるパターンに要注意 str_contents に対して直接的にnullを指定するケースはあまりなさそうですが、参加者からは以下のような注意点も共有されました。 未定義変数とかがnullが入りうるパターンなので要注意ですね （PHP8.0から導入されたので）そんなに使っていないと思いますが、便利な関数なので発生しうるかな？ だから（PHP8.1で）一回警告を挟むんでしょうね PHP8.0で早速使い始めたけど、特定のパターンで未定義変数が紛れ込むことはありそうです。万が一そのようなパターンがあってもPHP8.1の間は警告が出るので見つけたらすぐに対処しておくと良さそうです。 その他の変更点 時間の関係ですべては紹介できませんでしたが、これ以外の変更点も以下にまとめられているのでご確認ください。また、機会があれば次回以降のPHPTechCafeで話題にあがるかもしれません。 hackmd.io 今後は PHPUnit やLaravelをテーマに開催予定 次回以降は9月と10月のテーマと開催日が既に決まっており参加者を募集中です。参加頂くとブログには掲載しきれない細かい情報や、 PHP の最新動向のニュースの紹介などもありますのでぜひご参加ください。 rakus.connpass.com rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに おすすめの読者層 要件定義とは よくある問題 要求が不足している 要求が曖昧 そもそも要求を叶えるのが不可能 要件定義の始め方 おわりに はじめに こんにちは。rs_chankoです。 最近はもっぱらオフショア管理の業務をしています。 最初は納品物のチェックがメインだったんですが、ここ数か月、案件の依頼を出すことが増えました。 最初は見様見真似でリーダーのやっていることをやってみてはいろいろ指摘を受けていたのですが、 自分の持っている技法や観点では思うように内容を拾いきれず、依頼内容がいまいちになってしまうことが多いことに気付きました。 「このままではだめだ！」と思いいったん本を読んでみようということで要件定義についての本に手を出してみました。 作業依頼って要件定義の簡易版って感じなんですよね。体感的にですが。 そこで今回はその本がなかなか初級者に易しく、さっそく実践しているので記事にしてみようかなと思い書いているといったところです。 今回読んだ本はこちらです。(これもリーダーのお勧めで決めたのは秘密です。) www.amazon.co.jp 表紙の通り、前半は目玉焼きを作る工程で要件定義とは何ぞやという説明がされている本です。(とってもとっつきやすい) ◆ 関連ブログも合わせてご参考ください。 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ おすすめの読者層 これから要件定義に参画する人 要件定義をするメンバーに教育する人 ふわっとしている案件を形にして依頼する人(私はこれです) 要件定義とは そのまま要件を定義することなんですが、実際その「要件」を「定義する」とは何なんでしょうか。 ■要件=注文 依頼する人(ユーザーや企画部など)が開発に対して「こういうものを作ってほしい」「こんな機能があったら便利」というところから、プロダクトの開発は始まると思います。 個人であればそのふわっとしたものからあれやこれやとつけたい機能をつけてアプリなりなんなりを作成しますよね。 ただグループや企業だと最初に認識を合わせておかないと大きな齟齬が起きたり、大量のバグの温床になりかねません。 そういったことを避けるために 作ってほしい人が作る人に出す要望 が要件になります。 例えばの話にはなりますが、なんでもできる万能な車を作ろうと考えています。 依頼主からの要望は * 空を10m飛びたい * ベースは日本製の一般車にしたい * 陸上は通常通り走れるようにする * ガソリンが燃料 これらの要望が 要件 です。 ただ、お客さんが要件を並べたらすべてが叶うというわけではありません。 魔法の力で何とか空を飛ぶ車は作ることができるとします。 日本製の車に空を飛ぶ 拡張機能 を付けました。 余分なパーツをつける場所もなくなり、完璧な形に仕上げることができました！ しかし、あとから依頼主が「水上も走れるようにできないかな」と言い出しました。 事前に決まっていればそれ用に作ることもできましたが、 空陸用に作り上げてしまったため、水上を走れるようにというのは叶えられませんでした。 このため、こちらの要望は諦めてもらうことにしました。 本来であれば、水上も走れるようにしたいと言うのは、要望をまとめる段階で出しておいてもらうべきです。 ただ、その部分を完璧に詰めずに車を作ってしまったため、依頼主は渋々諦めることになりました。 このような「できること」「してほしいこと」「できないこと」をはっきりとしておくことが 要件定義 なんですね。 よくある問題 現実的な開発の話に戻します。 事業部や取引先などから新しい製品や、新しい機能を作る話が開発に降りてくるでしょう。 要件定義の場を設けて、仕様についてまぁまぁ詰めた状態まで持っていったかなというところで、 「これやってください」が決まったとします。 開発者はそれを実現するために動くと思います。 ただ、次のような問題が往々にしてあるはずです。 要求が不足している 実際に作ってみたものはいいものの、既存の機能の考慮が足りていませんでした。 「あれ、この既存機能も新機能反映しないといけないんだっけ？」「え、無視していいんじゃないの？」 といった具合に後から要件の見直しをすることもあるんじゃないでしょうか 要求が曖昧 どんなものを作るかイメージはつきました。 イメージはついたものの、仕様が虫穴で「この条件は付けるべきなのか」「この時の動作はこれでいいのか」が分からず、設計段階で詰みますね。 もっと酷ければ実装してテストしているときに気付いたりすることもあります。 そもそも要求を叶えるのが不可能 要件定義の時点で不可能やないかーい！といった事態。 技術的な物だったり、既存機能を壊してしまったりなど、様々な理由でできないことがあったり。 基本はスタートの段階で気づくとは思いますが、作ってみて気づくなんてことも現場では起きますね。 要件定義ではじゃあいざ設計だ！実装だ！より前に今あるものに対してどのように対応していくのか、そこまで考える必要が出てきます。 今ある機能や実現したい機能と、バッティングする場合どちらを生かすか、どう共生させるか 実現したい機能が今の製品や機能に与える影響はどの程度がいいのか そもそも実現したい機能の細かなつくりはどこまで考慮すればいいのか これでいいのでは？で進めてしまうことで、正しく作ったつもりが依頼主との間で出来上がりに乖離が出てしまいますよね。 依頼主からの要求が足りていないのであれば要件定義の段階ですり合わせていくというフェーズが必要です。 各会社や個人で流儀や手法はあると思いますが、 画面のモックなどのイメージや、システム部分の仮設計を使いながら、不足している要求を引き出すことが開発側の要件定義です。 要件定義の始め方 まずは実現したいことを一覧にしてわかりやすくする必要があります。 書籍では企画書の作り方として書かれていましたが、ユーザーや事業部の望んでいるものがふわっとしているときには開発側でそこまでまとめる場合もあると思います。 書籍で書かれているような技法を、アレンジして業務に取り入れたりもしているため、 ブログ用にさらにアレンジして、書籍の技法を簡単にまとめてみました。 今回は記事用に遠い昔にアルバイト時代の店長にアプリを作って！と言われた際の要求をまとめてみます。( アプリ制作 自体は諸事情あってやっていませんが。。。) その時に店長が作ってくれといったアプリの要求は以下のようなものです。 外国人メンバーのためのマニュアルアプリ メンバー同士で注意点を共有できるように、記事を投稿できる いいねボタンみたいに参考になったよボタンを設置してポイント制にする 当時こんなふわっとしたオーダーだけでアプリ作って！と言われ困惑しましたが、それは置いておきます。 これだけ聞いた際にどんなことが実現できればいいかなと思って ヒアリ ングをしたので、そこから要求をまとめてみました。 概要 外国人・新人メンバーのための手順書・注意事項共有アプリ 目的 ・会社から提供される手順書はつぶれた写真だったり、白黒で分かりにくい ・文字での説明はついているけど、外国人にはニュアンスで伝わりにくい ・上位メンバーが知ってるコツを集約してどのメンバーでもわかるように動画などで共有したい 現状 ・紙のマニュアルのみで、上位メンバーがつきっきりで教える必要がある ・複数のメンバーに手順書には書いていない同じ注意をしたことがある ・メモを自発的にするメンバーと全くしないメンバーがいる あるべき姿 ・上位メンバーでない人でも教育ができるようになる ・誰かに一度説明したら、メンバー同士にその内容が共有される ・メモをしないメンバーでも手元に情報が残っている 目標達成に必要な要素 ・ twitter などのように各メンバーが記事を投稿できるアプリ ・動画付きで投稿ができる ・参考になる度合いでソートすることができる(必要性の高いものから見ることができる) 無視していい要素 ・投稿に対するコメント機能は必要ない 例なのでかなり荒いですがこんな感じで「できること」「してほしいこと」「できないこと(厳密にいえばしなくていいことですが)」を並べました。 視覚的に何をすればいいのかがわかるため、実現したいこと／実現できないことを早い段階で拾うことができるようになります。 これが要件定義の第一歩、スタートです。 こちらを元に実装や設計をする開発側と依頼主側で、実際に出来上がるもののイメージをすり合わせていきます。 出来上がってから「あれはできないの？」「これはできないの？」となってしまうと、最悪一から作り直して倍の 工数 がかかって納品が大幅に遅れてしまうと言うこともありますね。 そういうことを避けるためにも、じっくり要件定義で時間をかけて、設計、実装はすんなり、サクサク進めて後から余計な工程が起きないようにすることを心がけることが大事です。 そのためにも要件定義のスキルを習得して、確実な状態でのスタートを切れるようにすることが上手な開発の第一歩です！ おわりに 最近はあまり大きな機能を扱っていないので、例で程度示した程度の粒度のものを複数打っています。 仕事でもオフショア先に依頼する際にも上記のように文面を組み立ててパターン化して以来前の確認もしやすいようにしています。 なのであんまりテクいこと書けてないんですが、要件定義や作業の依頼に重要なのは上記の表みたいな内容だということが本を読んで確信を持てた、といった感じです。(やっていることが、世間的に使われるような技法だったと言う裏どり、心強く感じて大事だと思います。) 目的(何がしたいのか、) 現状(問題点、不足しているところ) あるべき姿(問題が解消された状態、できるようになること) 必要な要素(あるべき姿にするためにすべきこと、付随してできるべきであること) 不要な要素(考慮する必要のないこと、対応できるけどしなくてよいこと) この辺をはっきりしておくことでいざ設計だ！実装だ！ってなった時に迷うことも減りますし、 納品だ！って時に「いやそれは要件として提示されていないので」という材料になるんですね。 逆に言えばですが、はっきりしていないと「え、これは当然じゃないの？」と押し切られ、ネットでよく見るn次受けの地獄現場みたいなことが起こるんですよね。。。 自分の身を守るため、クライアントと良好な関係を築くためにも、要件定義の技法は自分の物にしていきたいと思いました。 皆さんも気持ちよく、無駄のないスマートな開発をするためにも、こちらの本読んでみてください。 使える技法から徐々に取り込んでいくことで現状を打破するきっかけになるかもしれませんね。。。 さらに細かいこと、設計チックな話は紹介した書籍に細かに書いてあるのでぜひ読んでみてください。 内容的にも読みやすいのでどんな方にもおすすめです。 まず第一に抑えるところ！的な記事になってしまいました。 あまり細かく書きすぎると盗作になってしまいそうなのでこんな感じで悪しからず…。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 iPhone や iPod のモバイルデ バイス をお持ちの皆様、 「 Podcast（ポッドキャスト） 」という無料のアプリをご存知でしょうか？ 是非ご自身のモバイルデ バイス をご確認ください。 Podcast （ ポッドキャスト ）がデフォルトで既にインストールされているはずです。 インターネットを通じて配信された音声や動画を無料で視聴できるサービスとなっており、暇つぶしや勉強にも役立つ 最強アプリ なんです！ 今回は、エンジニアやデザイナーの皆様向けにTech系の Podcast （ ポッドキャスト ）番組をにまとめてみました。 本ブログを通して、是非おうち時間を有効活用する一つの手段に Podcast （ ポッドキャスト ）を追加していただけますと幸いです。 国内外のTech系 Youtube チャンネルをまとめた記事は以下になります！ 【2021年版】国内外Tech系YouTubeチャンネル10選 - 登録者数順まとめ！ - - RAKUS Developers Blog | ラクス エンジニアブログ Podcast（ポッドキャスト）を始めてみよう！ Tech系Podcast人気番組 Apple Events Rebuild Apple Events (video) Apple News Radio ワンボタンの声 backspace.fm Image Cast texta.fm TEDTalks テクノロジー TED Radio Hourt 電脳タイガー飯店 Off Topic // オフトピック 石川温のスマホNo.1メディア 弊社エンジニアおすすめ番組 fukabori.fm UIT INSIDE EM . FM #EMFM PHPの現場 ajitofm 終わりに Podcast （ ポッドキャスト ）を始めてみよう！ Podcast （ ポッドキャスト ）は Apple 社が提供しているアプリケーションとなります。 名前の由来は、ポータブルマルチ メディアプレーヤー である iPod （ アイポッド ）と、放送を意味するbroadcast（ブロードキャスト）を組み合わせた造語とのことです。 最近では、 Apple 社だけでなくGoolgeや Spotify でも Podcast がでております。 Google Podcasts Spotify for Podcasters 今回は、 Apple 社が提供している Podcast の始め方をご説明します。 1. Apple Store で「 Podcast （ ポッドキャスト ）」を検索し、アプリを開く 図１： Apple Store 画面 2. Podcast （ ポッドキャスト ）のアプリが起動する 図２： Podcast 起動画面 3. 見たいカテゴリ or キーワードを検索する 図３： Podcast 検索画面 たったこれだけです。簡単ですよね。 次にエンジニアやデザイナーの皆様に見ていただきたい、Tech系 Podcast （ ポッドキャスト ）の番組をご紹介します！ Tech系 Podcast 人気番組 Podcast の「テク ノロ ジー 」人気番組ランキングは以下の通りです。 順位 番組名 1 Apple Event 2 Rebuild 3 Apple Events (video) 4 Apple News Radio ワンボタンの声 5 backspace.fm 6 Image Cast 7 texta.fm 8 TEDTalks テク ノロ ジー 9 TED Radio Hour 10 電脳タイガー飯店 11 Off Topic 12 石川温の スマホ No.1メディア ※2021/9/17時点での情報です。 では、早速番組ごとに紹介していきます！ Apple Events Apple Events (audio) Apple テク ノロ ジー ¥0 podcasts.apple.com 秋の新製品を発表した Apple 社が配信する番組「 Apple Events」が堂々の1位！ 番組説明 The Apple Events podcast is home to the latest keynote addresses. Listen to announcements of new products and services and browse the archive of past events to relive revolutionary moments in the history of personal technology. 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング Apple Inc. 2019年 8 Apple Events 不定 期（新製品が発表された時） ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎Apple Events (audio)：Apple Podcast内のApple Event, September 2021 ２． ‎Apple Events (audio)：Apple Podcast内のWWDC21 Keynote ３． ‎Apple Events (audio)：Apple Podcast内のApple Event, April 2021 ※2021/9/17時点での情報です。 こちらの番組は音声のみの配信となっています。 もし動画、日本語字幕と合わせて視聴したい場合は、これからご紹介する「 Apple Events (video)」番組をご確認ください！ Rebuild Rebuild Tatsuhiko Miyagawa テク ノロ ジー ¥0 podcasts.apple.com Tech系番組の日本で一番有名と言われているのが、「Rebuild」です！ 番組説明 ウェブ開発、プログラミング、モバイル、ガジェットなどにフォーカスしたテク ノロ ジー 系 ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Tatsuhiko Miyagawa 2013年 441 rebuild.fm 不定 期(月に3回くらい) ※2021/9/17時点での情報です。 rebulid.fmの中で最新のエピソードは以下になります。 最新エピソード １． ‎Rebuild：Apple Podcast内の316: Domestic Violence Camcorder (N) ２． ‎Rebuild：Apple Podcast内の315: Our Bank Doesn't Like Your Voice Service (higepon) ３． ‎Rebuild：Apple Podcast内の314: Takeda Shingen of Silicon Valley (hak) ※2021/9/17時点での情報です。 rebuild.fmは、色々なジャンルのゲストを交えた トーク が聞けるのでどのエピソードも楽しく聞くことができる番組となっております！ 9/14に最新エポソードも上がっていますので、こちらも見逃せませんね！ Apple Events (video) Apple Events (video) Apple テク ノロ ジー ¥0 podcasts.apple.com 1位に続き、 Apple 社の新製品や新サービスの発表を アーカイブ 動画として配信している Podcast の番組が「 Apple Events (video) 」です！ Apple 製品好きの方には有難い番組ですね。 番組説明 The Apple Events podcast is home to the latest keynote addresses. Watch announcements of new products and services and browse the archive of past events to relive revolutionary moments in the history of personal technology. 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング Apple Inc. 2008年 53 Apple Events (video) 不定 期（新製品が発表された時） ※2021/9/17時点での情報です。 最新エピソード １． ‎Apple Events (video)：Apple Podcast内のApple Event, September 2021 ２． ‎Apple Events (video)：Apple Podcast内のWWDC21 Keynote ３． ‎Apple Events (video)：Apple Podcast内のApple Event, April 2021 ※2021/9/17時点での情報です。 こちらの番組は前述した通り音源だけでなく、動画の配信も行っております。 また、 スマートフォン で視聴すると字幕もついてみれますので英語の解説でも問題なく理解できます！ Apple 製品だけでなく、英語学習にも使える良い番組です！ Apple News Radio ワンボタンの声 Apple News Radio ワンボタンの声 ワンボタンの声制作委員会 テク ノロ ジー ¥0 podcasts.apple.com Apple 関連のニュースを中心にユーザー目線で紹介している Podcast が「 Apple News Radio ワンボタンの声」という番組です！ やはりどの番組も、話題は Apple の新商品についてばかりですね。 番組説明 Mac , iPod , iPhone , iPad , Apple watch , Apple TVなど Apple にまつわるニュースをもとにリスナーと一緒に楽しむ podcast です。Old Mac ユーザーには懐かしい往年の Apple 製品を振り返る"Time machine radio"も好評です。30分間の番組を火・木・土の早朝に配信していますので通勤、通学のお供にお楽しみください。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング ワンボタンの声制作委員会 2009年 15 Apple News Radio ワンボタンの声 火・木・土の早朝 ※2021/9/17時点での情報です。 最新エピソード １． ‎Apple Podcast内のApple News Radio ワンボタンの声 ２． ‎Apple Podcast内のApple News Radio ワンボタンの声 ３． ‎Apple Podcast内のApple News Radio ワンボタンの声 ※2021/9/17時点での情報です。 30分という尺で配信を行っていますので、通勤・通学期間にぴったしのコンテンツとなっております。 Apple ユーザの皆様、是非ご視聴ください！ backspace.fm backspace.fm backspace.fm テク ノロ ジー ¥0 podcasts.apple.com 続きまして、 フェンリル 株式会社さんが提供している「backspace.fm」です！ 番組説明 一週間分のテック・ガジェットニュースを配信する ポッドキャスト 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Koichi Aoki 2014年 664 backspace.fm 不定 期(3日に1回くらい) ※2021/9/17時点での情報です。 以下が最新エピソードになります。 最新エピソード １． ‎backspace.fm：Apple Podcast内の#411:【後編】次が人生最後のクルマなら、あなたは何を買いますか？ ２． ‎backspace.fm：Apple Podcast内の#411:【前編】次が人生最後のクルマなら、あなたは何を買いますか？ ３． ‎backspace.fm：Apple Podcast内の#410:【お便りコーナー】転職ホヤホヤの山川記者と議論する最近のカメラ事情とコロナ禍での働き方 ※2021/9/17時点での情報です。 1週間分のテック・ガジェットニュースを配信していると記載がありますが、更新頻度を見ると3日に1回くらいと頻度は高めです。 つまり、最新情報がすぐに入ってくる良いコンテンツということになりますので是非ご興味あればご視聴ください！ Image Cast Image Cast Image Club テク ノロ ジー ¥0 podcasts.apple.com クリエイティブな話を聞きたい方におすすめなのが、「Image Cast」です！ 番組説明 Image Castは、個人でものを作る人の集まりImage Clubとして活動しているあずまと鉄塔が自宅からお送りする30分ほどの Podcast です。技術・デザイン・制作・表現などに関係のあるような無いようなトピックを中心に、毎週二人が気になったもの、発見したことをそれぞれ持ち寄っておしゃべりします。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Image Club 2020年 52 Image Club 毎週土曜日朝 ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎Image Cast：Apple Podcast内の#49 うまくいかないのが自分のせいか世界のせいかは気分で決めていい ２． ‎Image Cast：Apple Podcast内の#48 全ての道はマリオペイントに通ず ３． ‎Image Cast：Apple Podcast内の#47 ポイントカードお持ちですか？ ※2021/9/17時点での情報です。 制作、表現、技術、デザインなどに関係のある話が30分～1時間くらいで聞けるので通勤やお昼休憩の際に最適なコンテンツとなっております。 毎週土曜日に更新されるそうですので、気になった方はフォローしてみてくださいね！ texta.fm texta.fm Design and Engineering team at PIXTA テク ノロ ジー ¥0 podcasts.apple.com 動画・動画の素材サイトを運営しているピクスタ株式会社さんの「texta.fm」です！ Podcast で配信しているなんてすごいですね…。 番組説明 texta.fmは、ピクスタで働くデザイナー・エンジニアによる技術ブログ「てくすた」の ポッドキャスト 版です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Design and Engineering team at PIXTA 2020年 11 texta.fm 不定 期(2か月に1回くらい) ※2021/9/17時点での情報です。 最新エピソードはこちら！ 最新エピソード １． ‎texta.fm：Apple Podcast内のSideshow 7. Jbuilder was Right ２． ‎texta.fm：Apple Podcast内の7. Fat Controllers and Models ３． ‎texta.fm：Apple Podcast内の6. 1on1 in Public ※2021/9/17時点での情報です。 テスト駆動開発 （TDD）の スペシャ リストとして知られる和田卓人さんとの トーク が聞けます。 ラジオ感覚で学習ができるとても良いコンテンツです！ TEDTalks テク ノロ ジー TEDTalks テクノロジー TED テク ノロ ジー ¥0 podcasts.apple.com 世界中の発明家や研究者たちが技術発信をしている番組が「TEDTalks テク ノロ ジー 」です！ 番組説明 TEDカンファレンス、TEDxイベント、世界中の提携イベントのステージから、世界最先端の発明家、研究者たちが、デモや発見やビジョンを披露してくれます。これらに加え、たくさんのビデオが、英語の スクリプト や最大80の言語から選んだ字幕を付けてTED.comから無料でダウンロードできます。TEDは「広める価値のあるア イデア 」を追い求める非営利組織です。 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング TED Talks 2012年 120 TEDTalks テクノロジー 不定 期 ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎TEDTalks テクノロジー：Apple Podcast内の電化による素晴らしい未来の空の移動 | コリー・コウムズ ２． ‎TEDTalks テクノロジー：Apple Podcast内の都市が交通機関をデトックスする | モニカ・アラヤ ３． ‎TEDTalks テクノロジー：Apple Podcast内のパンデミックを乗り越え、公衆衛生を再考する上でテック企業にできること | カレン・デサルヴォ、ホイットニー・ペニントン・ロジャース、クリス・アンダーソン ※2021/9/17時点での情報です。 5分程で終わる内容や、1時間語り続けているものまでエポソードは様々あります。 ご興味のある分野から是非ご視聴ください！ なお、日本語の字幕も設定できますのでご活用ください。 TED Radio Hourt TED Radio Hour NPR テク ノロ ジー ¥0 podcasts.apple.com アメリ カで放送しているラジオの Podcast 「TED Radio Hourt」です！ 番組説明 Exploring the biggest questions of our time with the help of the world's greatest thinkers. Host Manoush Zomorodi inspires us to learn more about the world, our communities, and most importantly, ourselves. 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング NPR 2012年 150 TED Radio Hour 毎週金曜日 ※2021/9/17時点での情報です。 最新のエピソードはこちら。 最新エピソード １． ‎TED Radio Hour：Apple Podcast内のListen Again: The Gratitude Chain: A.J. Jacobs ２． ‎TED Radio Hour：Apple Podcast内のThe Food Connection ３． ‎TED Radio Hour：Apple Podcast内のListen Again — Esther Perel: Building Resilient Relationships (2020) ※2021/9/17時点での情報です。 アメリ カのラジオ局が配信しているということもあり、全エピソード英語となっております。 英語が得意な方にとっては面白い番組なのではないでしょうか？ 電脳タイガー飯店 秘密結社 電脳タイガー飯店 dentora テク ノロ ジー ¥0 podcasts.apple.com 次はなんと2021/8月から配信を開始したばかりの「電脳タイガー飯店」という番組です！ 始めたばかりにも関わらず、Tech系ランキングで上位にきている番組となっております。 番組説明 毎回、テク ノロ ジー ×何かで世界征服が実現できないかをテーマに語る世界征服系 Podcast 番組です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング 電脳タイガー 2021年 5 電脳タイガー飯店 毎週火曜20時 ※2021/9/17時点での情報です。 最新エピソード １． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#05 全人類をテックで秘密結社に入社させる方法（前編） ２． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#04 テック×占いで世界征服できるのか（後編） ３． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#03 テック×占いで世界征服できるのか（前編） ※2021/9/17時点での情報です。 前述にも記載しましたが、配信を開始したばかりの番組となっておりますのでエピソード数もまだまだ一桁です。 これから話題となってきそうな番組となっておりますので、是非ご確認ください！ Off Topic // オフトピック Off Topic // オフトピック Off Topic テク ノロ ジー ¥0 podcasts.apple.com アメリ カスタートアップに詳しい「Off Topic // オフトピック」番組です！ 番組説明 Off Topicは、米国を中心に最新テックニュースやスタートアップ、ビジネス情報、たまにカルチャーをゆるーく深堀りしながら解説する番組です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Off Topic 2018年 84 Off Topic // オフトピック 毎週木曜 ※2021/9/17時点での情報です。 では、最新エピソードです！ 最新エピソード １． ‎Off Topic // オフトピック：Apple Podcast内の#83 Bored ApesやCryptoPunksに秘めたNFTアバターの可能性 ２． ‎Off Topic // オフトピック：Apple Podcast内の#82 NFTとオーナーシップ経済 ３． ‎Off Topic // オフトピック：Apple Podcast内の#81 注目のクリエイターたちに学ぶ ファンとの向き合い方 ※2021/9/17時点での情報です。 注目は米国の最新テックニュースを分かりやすく解説してくれるところだと思います。 海外のトレンドやニュースを知りたい方におすすめの番組です！ 石川温の スマホ No.1メディア 石川温のスマホNo.1メディア ラジオNIKKEI テク ノロ ジー ¥0 podcasts.apple.com ラジオNIKKEI がお送りする番組が「石川温の スマホ No.1メディア」です！ スマホ に関する最新情報を発信しております！ 番組説明 世界中を飛び回って取材する スマホ ／ケータイジャーナリストの石川温さんをパーソナリティに迎えてお送りする スマホ 情報番組。最新情報からお役立ち情報まで、 スマートフォン に関連する幅広い情報をお届けします。 ラジオNIKKEI 第1で毎週木曜日20:20～20:50放送中！ 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング ラジオNIKKEI 2014年 364 石川温のスマホNo.1メディア 毎週木曜日 ※2021/9/17時点での情報です。 最新エピソード １． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.16・第364回「iPhone 13発表。Apple秋のスペシャルイベント」 ２． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.9・第363回「片手に収まるハイスペック。ASUS『Zenfone 8』」 ３． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.2・第362回「PayPay、これからのスマホ決済」 ※2021/9/17時点での情報です。 毎週放送＝毎週更新される Podcast のため最新情報をすぐにインプットできるコンテンツです！ スマホ にご興味がある方は是非ご視聴ください！ 弊社エンジニアおすすめ番組 fukabori.fm fukabori.fm iwashi テク ノロ ジー ¥0 podcasts.apple.com アジャイル / スクラム /デザイン/マネジメント/コンテナ/ 自然言語 など様々な技術を深堀して発信しているのが「fukabori.fm」です！ 番組説明 技術などを深掘りして楽しむ Podcast です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング iwashi 2018年 57 fukabori.fm 不定 期（月1程度） ※2021/9/17時点での情報です。 最新エピソード １． ‎fukabori.fm：Apple Podcast内の56. 自然言語処理(NLP)の歴史、BERT w/ Takahiro Omi ２． ‎fukabori.fm：Apple Podcast内の55. コンテナランタイム(後編) w/ TokunagaKohei ３． ‎fukabori.fm：Apple Podcast内の54. コンテナランタイム(前編) w/ TokunagaKohei ※2021/9/17時点での情報です。 更新頻度は低いですが、1コンテンツの配信内容はとても濃いです。 約40分程で1技術を学べるとなれば聞くしかないですよね？ UIT INSIDE UIT INSIDE UIT テク ノロ ジー ¥0 podcasts.apple.com 人気のフロントエンドに関する技術をLINE株式会社のエンジニアが配信している番組、「UIT INSIDE」！ UITとは、 User Interface + Technology の頭文字を取っているとのこと。 番組説明 LINE UIT の開発者による「最新のフロントエンド」をキャッチアップできる Podcast 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング UIT 2019年 94 UIT INSIDE 金曜日（月3回くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎UIT INSIDE：Apple Podcast内のep.97『フロントエンドに詳しい CTO がいてよかったことは？heyのフロントエンド事情を聞いてみた』 ２． ‎UIT INSIDE：Apple Podcast内のep.96 『Shell scriptがもっと身近に！ zx活用術』 ３． ‎UIT INSIDE：Apple Podcast内のep.95 Front-End Tooling 実践！最新のツールチェインで長大なビルド時間の改善に挑む ※2021/9/17時点での情報です。 変化が速いフロントエンド技術に注目し、配信してくれるのはとても有難いです。 約30分で最新のフロントエンドの知識をインプットできる優れたコンテンツとなっております！ EM . FM #EMFM EM . FM #EMFM EM.FM テク ノロ ジー ¥0 podcasts.apple.com エンジニア リングマ ネージャー（EM）のための番組、「EM . FM」！ （名前のまんまです） 番組説明 Engineering ManagerによるEngineering Managerのための Podcast 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング EM.FM 2018年 50 EM . FM #EMFM 不定 期（2か月に1回くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎EM . FM #EMFM：Apple Podcast内のlv12. ユニークなキャリアは代替ができない ２． ‎EM . FM #EMFM：Apple Podcast内のlv11. 「自分で考える」ことの脆弱性 ３． ‎EM . FM #EMFM：Apple Podcast内のlv10. 『EMが必要だからやる』から『EMになりたい』へ ※2021/9/17時点での情報です。 マネジメント向けの内容を1時間ほど語っている番組となりますが、聞いといて損はないと思います！ ご興味ありましたら是非！ PHP の現場 PHPの現場 Masashi Shinbara テク ノロ ジー ¥0 podcasts.apple.com PHP コミュニティの中では有名な番組、「 PHP の現場」！ PHP の現場で開発してる中級者以上向けの内容となっております。 番組説明 PHP の現場にいる人と話す ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Masashi Shinbara 2017年 44 PHPの現場 不定 期（2か月に1回くらい ※2021/9/17時点での情報です。 最新エピソード １． ‎PHPの現場：Apple Podcast内の44. ちゃんとしなきゃいけない呪い（hanhan1978） ２． ‎PHPの現場：Apple Podcast内の43. ゲーム開発での DDD 実装パターンの活用（n_1215） ３． ‎PHPの現場：Apple Podcast内の42. Laravel 本と開発現場（ytake / kurikazu / omoon） ※2021/9/17時点での情報です。 開発現場で活躍する現役 PHP エンジニアの皆様が出演しているため、エピソード毎に雰囲気が異なり面白く視聴できます！ PHPerの皆様、お時間ある際にご視聴ください！ ajitofm ajitofm Kenta Suzuki テク ノロ ジー ¥0 podcasts.apple.com 続いて、VOYAGE GROUPの社内バーでの語りを収録している「ajitofm」です！ 更新頻度は低めですが、ゲスト参加するエンジニアの皆さんのレベルが高いためアップされると注目される番組となっております。 番組説明 技術・ガジェット・エンジニアリング・組織などに関する ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts 作成者 配信開始 エピソード Webサイト 更新タイミング Kenta Suzuki 2017年 58 ajitofm 不定 期（1年に3本くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎ajitofm：Apple Podcast内のajitofm 58: Engineer in VOYAGE 出版しました #voyagebook ２． ‎ajitofm：Apple Podcast内のajitofm 57: Nature Remoのシステムの裏側をsongmuさんに聞いてみた ３． ‎ajitofm：Apple Podcast内のajitofm 56: DX Criteriaやってみた ※2021/9/17時点での情報です。 エンジニアの皆様におすすめの番組です！ 最新がアップされる前にまずは過去のエピソードをご視聴ください！ 終わりに Tech系 Podcast はいかがでしたでしょうか？ 今回は Podcast 内の「テク ノロ ジー 」で人気の番組だけでなく、弊社エンジニアおすすめの番組も紹介させていただきました。 おうち時間が増えている今、 Podcast は技術の情報収集を行うにあたりとても便利なコンテンツです！ 無料且つ、最新トレンドをいち早く収集するのに最適な Podcast …是非本日からお楽しみいただければと思います。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは。west-cです。 オブジェクト指向 を意識した開発を行うようになって からし ばらく経ちました。 当初に比べると手続き的な考え方からいくらかは脱却できたかと思いますが、 オブジェクト指向 的な設計手法やコーディング方法が完璧に身に付いたと言える自信はまだありません。 そこで今回は、 オブジェクト指向 的な考え方を鍛えることができると言われている「 オブジェクト指向 エクササイズ 」を試してみることにしました。 オブジェクト指向とは オブジェクト指向エクササイズとは オブジェクト指向エクササイズをやってみた ・すべてのプリミティブ型と文字列型をラップすること ・ファーストクラスコレクションを使用すること ・Getter、Setter、プロパティを使用しないこと ・else句を使用しないこと ・名前を省略しないこと ・1行につきドットは1つまでにすること おわりに 参考文献・参考資料 オブジェクト指向 とは オブジェクト指向 とは、システムで扱う事柄をオブジェクトとして捉える技法と言えます。 オブジェクト指向 が普及する以前に用いられていた手続き型の設計の場合、システムの機能全体の手順を徐々に分解して小さな部品を作り上げていくような、いわゆる トップダウン 的なアプローチとなります。 手続き型での開発手法の場合、改修時の影響範囲が広くなると一般に言われています。 一方、 オブジェクト指向 では部品（オブジェクト）を中心に考えます。 まず、システムの実現を担う個々の部品を定義し、その部品自身に振る舞いをもたせます。 そして、定義した部品同士を組み合わせることでシステムを実現します。 手続き型とは正反対の、 ボトムアップ のアプローチを取ることが特徴的です。 個々の部品の独立性が高いため、改修時の影響範囲も限られ、コードの保守性や再利用性が高まることが期待できます。 オブジェクト指向 エクササイズとは オブジェクト指向 エクササイズとは、書籍『 ThoughtWorksアンソロジー 』で紹介されている オブジェクト指向設計 を理解し実際に使えるようになるためのエクササイズです。 オブジェクト指向 エクササイズの具体的な方法は、以下に定められた9つのルールを適用してコードを書く、というものになります。 1つのメソッドにつきインデントは1段階までにすること else句を使用しないこと すべてのプリミティブ型と文字列型をラップすること 1行につきドットは1つまでにすること 名前を省略しないこと すべてのエンティティを小さくすること 1つのクラスにつき インスタンス 変数は2つまでにすること ファーストクラスコレクションを使用すること Getter、Setter、プロパティを使用しないこと オブジェクト指向 エクササイズをやってみた お題には「 チケット料金モデリング 」を利用し、映画のチケットとその料金を決定するコードを、 オブジェクト指向 エクササイズの9つのルールを守った上で書いてみました。なお使用言語は Java です。 作成したコードは以下に置いてあります。 github.com 以下、ルールのうちいくつかをコードを交えて紹介します。 ・すべてのプリミティブ型と文字列型をラップすること いわゆる Value Object の考え方です。 今回の場合、チケット料金の決定には上映日（平日か・土日祝か・ 映画の日 か）や上映時間（レイトショーかどうか）が必要になります。 そこで、 LocalDate や LocalTime をそのまま利用するのではなく、これらをラップした ScreenTime オブジェクトを作成しました。 これにより上映日時にまつわる必要な振る舞いを ScreenTime に閉じ込めることができ、「 映画の日 かどうか」や「レイトショーかどうか」といった業務固有の振る舞いもオブジェクト内で表現することができました。 public class ScreenTime { private final LocalDate date; private final LocalTime time; // 略 /** * 映画の日かどうか. */ public boolean isCinemaDay() { return date.getDayOfMonth() == 1 ; } /** * レイトショーかどうか. */ public boolean isLateShow() { return time.getHour() >= 20 ; } } ・ファーストクラスコレクションを使用すること ファーストクラスコレクションとは、 Java でいう java.util.List のようなプリミティブなコレクション型をラップしたクラスのことを指します。 ファーストクラスコレクションを作成しシステムに必要な振る舞いに限定したメソッドを提供することで、このコレクションの意図を明確にすることができます。 チケットの種類の決定には年齢・学生かどうかに加えて、各種会員か・ 障がい者 かなども関係します。 今回は、「各種会員か」「 障がい者 か」といった割引要素を Discount という Enum で定義することにしました。 public enum Discount { CINEMA_CITIZEN, HANDICAPPED, MICARD } 1人で複数の割引要素を持つことも考えられるためファーストクラスコレクション DiscountList を作成し、チケット種類の決定にはこのモデルを利用するようにしました。 今回は各種要素が含まれているかどうか程度でしか利用していないため恩恵は少ないですが、外部からの意図せぬコレクション操作を防ぐことができるという点は保守性の向上にも繋がると思います。 public class DiscountList { private final List<Discount> discounts; public DiscountList(Discount ... discounts) { this .discounts = Arrays.asList(discounts); } /** * シネマシティズン会員かどうか. */ public boolean isCinemaCitizen() { return contains(Discount.CINEMA_CITIZEN); } /** * 障がい者かどうか. */ public boolean isHandicapped() { return contains(Discount.HANDICAPPED); } /** * エムアイカード会員かどうか. */ public boolean isMicard() { return contains(Discount.MICARD); } private boolean contains(Discount type) { return discounts.contains(type); } } ・Getter、Setter、プロパティを使用しないこと 今回、観客を表す Audience モデルに Age という名前で年齢を持たせることにしました。 このAgeを利用して「70才以上か」「幼児か」といった判定を行いたいのですが、 Audience には Age を取得するようなgetterメソッドは作成せず、 Audience 経由で年齢にまつわる必要な振る舞いを提供するようにしました。 前述の「すべてのプリミティブ型と文字列型をラップすること」「ファーストクラスコレクションを使用すること」のルールとセットで、Tell, Don’t Ask の原則に沿ったコードとするために押さえておきたい考え方だと思いました。 public class Audience { private final Age age; private final StudentType studentType; public Audience(Age age, StudentType studentType) { this .age = age; this .studentType = studentType; } /** * 指定した年齢以上かどうか. */ public boolean isYearsAndOver( int other) { return age.isYearsAndOver(other); } /** * 幼児かどうか. */ public boolean isInfant() { return age.isInfant(); } // 略 } ・else句を使用しないこと 上映日時（ ScreenTime ）からどの日時・時間帯の料金を適用すべきかを決定するために、料金のタイプを表す PriceType という Enum を定義しました。 ScreenTime をもとに PriceType を適用するファクトリメソッドは分岐が多くなってしまいましたが、else句を利用せず、かつなるべく可読性が高くなるよう早期returnやprivateメソッドへの抽出を行うようにしました。 ただ、 Enum で定義している定数自体が多くなってしまったこともあり、工夫したところでやはり可読性が低いことには変わりない点は課題に感じています。 改善の余地ありと感じている部分です。 public enum PriceType { WEEKDAY, WEEKDAY_LATE, WEEKEND_AND_HOLIDAY, WEEKEND_AND_HOLIDAY_LATE, CINEMA_DAY_ON_WEEKDAY, CINEMA_DAY_ON_WEEKDAY_LATE, CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY, CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY_LATE; public static PriceType of(ScreenTime screenTime) { if (screenTime.isCinemaDay()) { return priceTypeOfCinemaDay(screenTime); } if (screenTime.isWeekDay()) { return priceTypeOfWeekDay(screenTime); } return priceTypeOfWeekend(screenTime); } private static PriceType priceTypeOfCinemaDay(ScreenTime screenTime) { if (!screenTime.isLateShow()) { return screenTime.isWeekDay() ? CINEMA_DAY_ON_WEEKDAY : CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY; } return screenTime.isWeekDay() ? CINEMA_DAY_ON_WEEKDAY_LATE : CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY_LATE; } private static PriceType priceTypeOfWeekDay(ScreenTime screenTime) { return screenTime.isLateShow() ? WEEKDAY_LATE : WEEKDAY; } private static PriceType priceTypeOfWeekend(ScreenTime screenTime) { return screenTime.isLateShow() ? WEEKEND_AND_HOLIDAY_LATE : WEEKEND_AND_HOLIDAY; } } ・名前を省略しないこと 「名前を省略しないこと」とありますが、このルールの本来の趣旨は「省略したくなるような長い名前を付けないこと」と言えると思います。 『すべてのエンティティの名前には1つか2つの単語だけを使い、省略しないでください』とありますが、今回は厳守はできませんでした。 例えば、チケット種別「中・高生」を表すクラスでは JuniorAndHighSchool という名前を利用してしまっています。 もしかすると Teenager などでの言い換えが可能かもしれないですが、本当にイコールとして扱って良いのかの判別がつかなかったため、一旦このままとしました。 たかが 命名 されど 命名 ということで、実際の開発時にはより良い 命名 をチーム内で模索していく活動が必要なのだと感じました。 ・1行につきドットは1つまでにすること このルールでは「複数のドットを使っているコードは責務の配置を間違っているはず」ということに基づいていると言えると思います。 一方、このルールを文字通りに受け取ると、以下のようなStream処理もルール違反とみなされてしまいます。 private List<TicketPlan> sortByPrice(PriceType priceType) { return plans.stream() .sorted(Comparator.comparing(plan -> plan.price(priceType))) .collect(Collectors.toList()); } 今回はルールに従うため、Streamは利用せず以下のようにComparatorを別途作成したうえでソートを行うようにしました。 ただ、メソッド名等からその操作の意図が分かるようであれば、盲目的にルールに従うのではなくある程度許容するのもアリなのではと感じた部分です。 private List<TicketPlan> sortByPrice(PriceType priceType) { Comparator<TicketPlan> ticketPriceComparator = TicketPriceComparatorFactory.create(priceType); List<TicketPlan> sortedList = new ArrayList<>(plans); sortedList.sort(ticketPriceComparator); return sortedList; } おわりに 今回 オブジェクト指向 エクササイズを実践したことで、今まで以上にモデルの責務等について思考を巡らせることができました。 エクササイズ実践後の自身の考え方にも変化があったと思っており、たとえば実務のコードでプリミティブ型をメソッド間で引き回しているようなコードを見かけると違和感を覚えるようになり、よりよい概念で モデリング ができるのではないかといった考えが生まれるようになりました。 一方で、「 オブジェクト指向 エクササイズのルールを守ったからといって必ずしも オブジェクト指向設計 ができるとは限らない」ということも同時に感じました。 出来上がったモデルを見直してみるとぎこちなさや違和感を覚えるものも多くあり、自身の モデリング 力の不足を痛感しています。 今回は自身の未知の ドメイン 領域ということで、余計にぎこちなさを感じる モデリング になってしまったと思います。 実務においては担当領域の ドメイン 知識習得に励むとともに、 オブジェクト指向 エクササイズのルールを頭の片隅に入れながら モデリング 力の向上にも努めていきたいです。 皆さんもぜひ、 オブジェクト指向 エクササイズを試してみてはいかがでしょうか。 参考文献・参考資料 ThoughtWorksアンソロジー オブジェクト指向エクササイズのススメ オブジェクト指向でなぜつくるのか 第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

弊社で毎月開催し、 PHP エンジニアの間で好評いただいている PHP TechCafe。2021年8月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「PHP8.1の新機能」について語り合いました。 rakus.connpass.com PHP8.1の新機能は8.0に比べれば少ないとはいえ、順番に追いかけてみると思ったより大きなボリュームになったためイベント内容を2回に分けてレポートします。今回は前編として前半の半分をご紹介します。 PHP8.1 新機能について Enums Enumの実現は10年以上かかった Fibers 恩恵を受けるのはまだ先 Performance improvements パフォーマンスが約20%向上 Array Unpacking with string keys 覚えておけば得することもある書き方 new in initializer PHP8.0から拡張されて進化している Readonly Properties 今まではPHPDocなどに頼っていた First-class Callable Syntax 静的解析が可能になる 後編へ続く PHP8.1 新機能について PHP8.1の新機能は弊社のメンバーが事前にShowNoteにまとめていました。今回はこれに従って新機能をみていきました。 hackmd.io Enums 複数の定数をまとめる「列挙型」がサポートされるようになりました。「昔から話としては上がっていたが、ついに正式に実装されます。」と紹介されて、8.1の中でも特に大きく取り上げられています。 ここではまず以下のようなコードを使って解説されました。 Enum の書き方 <?php enum CardsMark { case DIAMOND; case HEART; case SPADE; case CLOVER; } Enum の実装例 <?php class Card { public function __construct ( public CardsMark $ mark , ) {} } $ card = new Card ( CardsMark :: DIAMOND ) ; この例をもとに、 Enum を使うことで以下のような実装ができると説明がありました。 コンスト ラク タで引数を持つときに Enum のカードマークに適しているものしか受け付けないようなクラスをつくることが出来る オブジェクト作るときにはカードマークを付けてオブジェクトを作る形にできる （上記の例のCardクラスのように）入ってくる値が Enum で列挙されたものに固定されるので、意図しないものが入ってくることを防げる また、以下のような特徴も紹介されました。 定数をまとめるだけじゃなくて、メソッドも定義できる インターフェイス を実装することもできる （上記のCardsMarkのような）存在するパターンを実装した Enum ですよという書き方ができる 意図しない実装を防ぎ、意図が伝わりやすい実装になるというコメントが紹介されました。 Enum の実現は10年以上かかった 基礎知識の解説のあとは Enum が PHP の機能に追加されるまでの歴史的背景の話題で盛り上がりました。 Enum は2010年頃から提案されていた ずっと提案されていたし、ユーザからも色々あった どの Enum 実装にするかは数あるライブラリのどれを使うか議論があった PHP の内部実装的に実現が難しかった 「 Java とかには普通にある機能なんですよね。はるか昔からある機能で、 Effective Java みたいな『とりあえずこれ読んどけ』みたいな本には『有限要素の表現をするときにはまず Enum 使え』とか書いてありましたね。」というコメントもあり、他の言語では早くから取り入れられた Enum が PHP でもやっと使えるようになったことは、参加したPHPerにとっては感慨深いものがあるようでした。 ※各言語で採用されている Enum （残念ながら Wikipedia の列挙型のページにはまだ PHP の例が掲載されていない） ja.wikipedia.org オフショア開発を担当しているエンジニアからは、「日本人で、しかもその時いたメンバーなら『あのときあの経緯で作ったから、ここにはこの値しか入れないよね』という暗黙の了解がいつの間にか新しいメンバーや国境を超えたメンバーには伝わってなくて、いつの間にか全く知らない値が入るようになっちゃったりして。そういう使い方のつもりじゃなかったんだ！？ってことが防げますね。」という意見もありました。 一方で、他の言語に似てきていることから「 PHP らしくない」という意見もありました。 Enum が導入されたことで「他の言語へ乗り換えも検討するレベルかな？」という意見も出てきましたが、大半の意見は「 PHP の中で出来る方が絶対いい」「今から新しい言語に乗り換えるってなったら…」と、他の言語へ乗り換えるのは別の懸念も多く予想され消極的な様子でした。 ただし、もともと PHP で書いてたものを Scala にリプレイスしたサービスの事例が取り上げられ、「（可能性は）0%ではない」「 PHP だとパフォーマンスが出しにくいので、他の言語のほうがパフォーマンスも出る」などのニーズにもよるという意見がありました。 ※ PHP から Scala へ乗り換えたチャットワークさんの事例 チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ いずれにしても、 Enum が導入されたことで「安全にかつ意図を表現できるようになった。」「喜ばしい変更ですね。」「 PHP の流れに沿っていますね。」「まず使ってみて、身体を慣らしてもらえれば。」という前向きな意見が大半でした。 Fibers Fibersという非同期処理を実行するための仕組みが導入されます。ただし、この機能によって PHP で非同期処理ができて、処理パフォーマンスが向上するかというとまだそうではないようです。1つのプロセスの中で処理を切り替えているだけなので、他の処理をブロックしてしまう機能がまだあり、同時並行で重い処理をこなすというのは現時点ではまだ難しいと RFC には書かれているようです。このあたりも、そのうちブロックされないライブラリを使ったり、コアの方もどんどん解消されていくことで理想に近づいていくのではないか、ということが RFC に書かれているようです。 これで夢が開けるかっていうとまだちょっと早い。もうちょっと先かな。 実際に同時並列でっていうのはまだ実現できない。 ずっと試しているんですけどめちゃくちゃセグフォ（セグメンテーション違反）が出てですね…… 人によると思うんですけどいわゆる普通レベルの恩恵に預かるにはライブラリ経由で預かることになるかなと。 恩恵を受けるのはまだ先 ライブラリなどの開発向けの機能であり、一般のPHPerが恩恵を受けるにはまだ先になりそうです。 また、Fiberという名前の由来についても紹介されました。「軽量スレッドと言われていて、スレッドより細いからFiberだそうです。」とのことで、「縫い糸」という意味のスレッドより細いものということで「細長い糸」という意味のFiberが採用されたようです。 Performance improvements パフォーマンスが約20%向上 ZendEngineのパフォーマンス向上により、 ベンチマーク 結果では約20%向上したそうです。大幅な進化というわけではありませんが、参加者からは以下のような意見がありました。 正直天井、 PHP の限界みたいなことを聞いてましたが、まだ20%上がる余地があったんですね。 ZendEngine自体の高速化だからなんにもしなくても恩恵を得られますよね。 PHP は遅い言語ではない、ということですね。 ただし、特定の ベンチマーク の結果なので、「全部のシチュエーションで20%向上ってわけではない」とのことです。 wiki.php.net Array Unpacking with string keys PHP 8.1 では文字列のキーでも配列のマージができるようになりました。書き方が変わったよという機能です。 <?php $ array1 = [ "a" => 1 ] ; $ array2 = [ "a" => 2 ] ; $ array = [ "a" => 0 , ...$ array1 , ...$ array2 ] ; var_dump ( $ array ) ; // ["a" => 2] 覚えておけば得することもある書き方 ここでは今回のような「こんな書き方できたんだったな」という機能がいくつかあるよね、という話題で盛り上がりました。「こういうの出てくるたびに、覚えとかないとってなりますね。」とのことですが、一方で「どう調べたら良いかわからないですね。これはどういう意味なの？っていう。」という意見もありました。「名前が分からないとググれないですね。点々でつなげているのでググりようがない。」ということで、検索するのは難しいですが、 PHP のマニュアルが親切なので配列のマニュアルをしっかり読めばわかるとのことなので、まずはマニュアルを熟読したいところです。 www.php.net new in initializer デフォルト引数はもともと PHP にある機能で、引数を渡されていない場合のデフォルト値を指定できますが、これまではオブジェクト指定することができませんでした。8.1からはデフォルト値に新しいオブジェクトの インスタンス を持たせることが出来るようになります。 <?php class Test { public function __construct ( private Logger $ logger = new NullLogger, ) {} } 「これまでは便宜的にnullとかにしておいて、nullだったらこのデフォルトのオブジェクト入れる、みたいなちょっと冗長な書き方をしていたけど、もう少し意図が分かる形で表現できるようになるし、簡潔に書けるようになる。」と、この新機能のメリットが説明されました。 一方で、上記の例では「Testクラスが NullLogger と密結合してしまうので、そういう 疎結合 にできなくなって無意識に結合しちゃうっていうのはあると思います。」というデメリットも紹介されました。 PHP8.0から拡張されて進化している コンスト ラク タのProperty設定を引数のところで書けるというのがPHP8.0から出来るようになっています。とはいえ、このオブジェクトを初期化することができなかった課題から今回の拡張が取り入れられたようです。 「単発でも使えるけれど、Attributeの拡張みたいな側面もあって、今までAttributeの中では定数式、文字列とか、配列の中にさらに文字列等しか入っていないものしか入れてられなかったけれど、そこにオブジェクトの初期化も入れられるようになった。Attributeの 入れ子 みたいなことも出来るようになりますね。」と具体的な活用方法の例が紹介されました。 「PHP8でできたばかりの機能がどんどん拡張されていくスタイルなんですね。進化が目覚ましい。」と期待の声もあがっていました。 Readonly Properties 宣言後に一度だけ初期化出来るプロパティを追加できる機能です。読み取りだけ出来るプロパティを作るというのが今までなかったため、「かゆいところに手が届く」と紹介されました。ただし、型付のプロパティのみ使用可能という条件付きです。型がついていないプロパティの初期値がNullになってそこから変更できないため、それはできないとのことです。 ここでは「もとからfinalを使ったら駄目なのか？」という疑問点もあがりました。これに対しては、「finalはメソッドでも使えるもので、上書きできないという意味なので、final使うとプロパティの定義を上書きできないというふうに誤読できてしまう。」と、finalの使い方とreadonlyの使い方の違いが解説されました。 今まではPHPDocなどに頼っていた Readonly Propertiesは「8.1の変更の中で使い所の多そうなものの一つ」と活用シーンが多そうな期待の声があがっていました。 「今まではPHPDocに @property-read って書くことで読み取る専用というのを書いたりしてましたね。」と過去のやりかたが紹介されました。これまではPHPDocなどの別の方法で実現していたことが、 PHP の言語仕様で実現できるようになります。「自分のプロパティ内でも書き込みができない、上書きができないってことなのでimmutableなClassが作りやすくなります。」と活用シーンの期待が説明されました。 First-class Callable Syntax クロージャ ーを作るときに ... を書くだけで作れるようになります。 <?php function foo ( int $ a , int $ b ) { /* … */ } $ foo = foo ( ... ) ; $ foo ( a : 1 , b : 2 ) ; 引数を受け取るようになっていたときに クロージャ ーが作れるようになります。 前述のArray Unpackingの書き方と似ているので、「読み慣れないうちは見間違えるんじゃないかという意見もあるようです。」と懸念が紹介されました。 静的解析が可能になる 読みづらそうだし、使い方がイメージしづらい懸念の声がありましたが、メリットとして上記のコードの例をもとに次のように解説されました。 今までは文字列のfooっていうのを書いたりしなきゃいけなかったけど、野暮ったいし静的解析できない ちゃんと静的に書けるようになったのが嬉しいですね。 例えばArrayマップとかで助かる 静的解析が可能な書き方になるのがポイントのようです。 後編へ続く PHP8.1の新機能はまだまだあります。後編では以下についてご紹介していますので是非ご確認ください！ Pure intersection Types New never type New Array_is_list_function final class constants New fsync function Explisit octal integerliteral notation Restrict $GLOBALS usage 後編の記事は以下になります。 PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、takaramです。 突然ですが、 OSS へコントリビュートした経験はありますか？ 今回は主に、 OSS （ オープンソース ソフトウェア）へのコントリビュートに興味はあるけどまだしたことがない、という人へ向けて、まず第一歩を踏み出してみよう！というお話をしたいと思います。 OSS（オープンソースソフトウェア）について オープンソースソフトウェアとは？ オープンソースソフトウェアのメリット OSSコントリビュート ドキュメントの修正 ケース1：誤記修正 ケース2：ドキュメントページの表示改善 最後に OSS （ オープンソース ソフトウェア）について オープンソース ソフトウェアとは？ ソフトウェアのうち、 ソースコード が一般に公開されていなかったり、利用が有償であるものを「 プロプライエタリ ソフトウェア」と呼びます。有名なところでは Windows や macOS 、 Oracle database、 Adobe Photoshop なども プロプライエタリ ソフトウェアです。 それらに対し、利用者が ソースコード の入手、利用、修正、再配布等を自由に行えるソフトウェアを「 オープンソース ソフトウェア ( Open Source Software )」と言い、一般的に頭文字を取って OSS と呼びます。単に ソースコード が公開されているだけでなく、その改変なども自由に行えるところが特徴です。 PHP や Ruby などの プログラミング言語 の処理系、 MySQL や PostgreSQL などの DBMS 、 Firefox のような Webブラウザ も OSS （ オープンソース ソフトウェア）です。 厳密には、 オープンソース イニシアティブという団体によって オープンソース の定義が決められており、これら10の条件に当てはまるものが OSS （ オープンソース ソフトウェア）ということになります。 The Open Source Definition | Open Source Initiative 逆に言えば、この定義に沿うように公開すれば先述したような大規模なものでなくとも、一個人が開発したものでも OSS （ オープンソース ソフトウェア）にすることができます。 オープンソース ソフトウェアのメリット OSS （ オープンソース ソフトウェア）を利用するメリットとしては、以下のようなものがあると言われています。 基本的に無償のためコストを抑えられる 問題があっても自分で修正できる 提供元の倒産、買収で突然使えなくなる心配がない 今や様々な種類のソフトウェアが オープンソース になっており、 OSS （ オープンソース ソフトウェア）を使ったことのないエンジニアはいないと言っても過言ではないほどに普及しています。 OSS コントリビュート OSS の開発に関わることを OSS 活動といいます。自分で開発したソフトウェアを公開することもそうですし、既存の OSS にバグ報告や機能追加の提案、修正パッチを送ることで貢献（コントリビュート）することも OSS 活動になります。 自分が利用している OSS に対してコントリビュートすれば、そのまま自分たちの利益になるのはもちろんですが、その他にも OSS 活動を行うことで、 自分の技術力の向上につながる 就職・転職の際に評価してもらえる などのメリットがあります。そのため最近では自社のエンジニアに対し OSS 活動を推奨するIT企業も増えてきています。（弊社 ラク スの開発部でも、社員の自己研鑽の一環として OSS 活動が推奨されています！） とはいえ、「なんだか難しそう」と漠然とハードルの高さを感じている人も多いのではないでしょうか。確かにいきなりバグ修正などに挑むのは少し難易度が高いかもしれません。 そこで、 OSS 活動の第一歩としてドキュメント修正から始めてみる ことをオススメしたいと思います。 ドキュメントの修正 仕事・趣味を問わず、コーディングを行う際は利用する プログラミング言語 やライブラリの公式ドキュメントを参照することが多いのではないでしょうか？ OSS の場合、そのドキュメントもまた オープンソース としてメンテナンスされている場合が多いです。小、中規模の OSS であれば ソースコード とドキュメントが同じ リポジトリ にあることが多いですが、大規模なライブラリや プログラミング言語 であれば、ドキュメントが別 リポジトリ になっているパターンもよくあります。 ドキュメントも当然人が作っているものですので、間違いや抜けがあることもあります。普段からドキュメントを読んでいる中で、そうしたミスや改善点を見つけることができれば、それが OSS ドキュメントへのコントリビュートチャンスです！ コードの修正に比べれば難易度、 心理的 なハードルとも幾分か低いのではないでしょうか。それでもその OSS の利用者にとっては役に立つ、立派なコントリビュートと言えるはずです。 ここからは、筆者が実際に OSS のドキュメントを修正しプルリク エス トを送った実際の事例を紹介したいと思います。 ケース1：誤記修正 筆者は普段の仕事では PHP を使っているのですが、 PHP のマニュアルは英語版を元として日本語を含む複数の言語に翻訳されています。ある時日本語版マニュアルを読んでいると、誤った説明になっている箇所があることに気が付きました。英語版を確認してみると正しい記述になっていて、翻訳時のミスのようだったので、修正のプルリク エス トを送ってみることにしました。 PHP 日本語版マニュアルは PHP: PHP マニュアル - Manual にありますが、これはDocBookという XML の一種で書かれた文書をHTMLに変換したもので、DocBookファイル自体は GitHub で管理されています。修正するためにはまずその リポジトリ を探さなければいけないわけですが、たいていの場合ドキュメントのどこかに リポジトリ へのリンクが存在します PHP の場合、ページの右上の Submit a Pull Request というリンクをクリックすると、該当のファイルを GitHub で閲覧することができます。 日本語版なら php/doc-ja リポジトリ の該当ファイルが開きます。 PHP マニュアルの"Submit a Pull Requst"リンク バグ修正などであれば、ここで リポジトリ をforkしてローカルにcloneして……などを行うのですが *1 、今回は一文程度の修正なので、 GitHub 上で修正してしまうことにしました。 詳しいやり方は GitHubの公式ドキュメント に載っているためそちらをご確認いただければと思いますが、 Webブラウザ 上で手軽に修正からプルリク エス トの送信まで済ませてしまうことができます。 なお、 リポジトリ によってはプルリク エス トを送る際の作法や注意点を記載している場合があります。 PHP 日本語版マニュアルの場合は README.md に記載がありましたが、他のプロジェクトだと CONTRIBUTING.md のような名前のファイルに書かれていたり、 GitHub の Wiki に記載されていたりというパターンもあります。 プルリク エス トを送る前には一度確認しておいて方がいいでしょう。 さて、プルリク エス トの送信まで完了すれば、あとは リポジトリ へのコミット権限を持つメンテナが修正内容を確認してくれるのを待ちます。どのくらいで確認してもらえるかは一概には言えませんが、今回送ったプルリク エス トは半日程度で見ていただき、そのまま問題なくマージされました。 github.com このような大規模 OSS の日本語版ドキュメントの場合、 リポジトリ の管理者も基本的に日本語が通じるので、プルリク エス ト等でのやり取りも日本語で行えます。 英語に苦手意識がある人でも問題ありません。 ケース2：ドキュメントページの表示改善 こちらは Ruby の日本語版リファレンスにプルリク エス トを送った事例です。 Ruby は日本生まれの言語ということもあってか、日本語の公式リファレンスが英語版とは独立して存在しています。 docs.ruby-lang.org このリファレンスを参照している際に、一部のページで若干表示が崩れる箇所があるのを発見しました。よくよく見たところ、 Chrome では発生せず、 IE と Firefox でのみ起こるようでしたが、HTMLと CSS をいじれば対応できそうだということがわかったため、プルリク エス トを送ることにしました。 Ruby のリファレンスも PHP と同様、別形式（ Ruby リファレンスの場合は RD 形式）で書かれたファイルをプログラムでHTMLに変換しています。今回はHTMLを修正する必要があったため、この変換プログラム側に手を加える必要がありました。調べたところ、このプログラムはドキュメント ( rurema/doctree ) とは別の リポジトリ ( rurema/bitclust )になっているようです *2 。 今回は GitHub でブラウザ上で修正、とはいかなかったので、ローカルにcloneしてきて修正を行いました。初めて見る リポジトリ で多数のファイルがありましたが、今回は出力されるHTMLと CSS さえ変更できればよかったので、全部を把握する必要はないと判断し、それっぽい箇所を検索で探し当てながら修正を行いました。 そうして修正を終え、手元で実際に試して問題ないことを確認してプルリク エス トを作成しました。 github.com すると3日後にコメントが付き、少し違った修正方法の提案を頂くことができました。確かにそちらの修正のほうが良さそうだと考えたため、コミットの修正を行いました *3 。その後少し時間は空きましたが、無事にマージされました！ この事例ではプログラムの修正を行っているので、1つ目の誤記修正に比べればハードルが高そうにも思えますが、万が一自分の修正に問題があった場合でも言語やライブラリ本体の修正ほどは影響が大きくないはずです。そう考えれば少し手を出しやすいのではないでしょうか？ 最後に OSS へのコントリビュートの第一歩として、まずドキュメントの修正から入ることのメリットをお伝えしました。普段使っている言語やライブラリのマニュアルに間違いや誤字脱字を見つけたら、「そのうち誰かが直すだろう」ではなく自分で修正してみるのはいかがでしょう？ そうして OSS にプルリク エス トを送ることに慣れてくれば、次のステップとして ソースコード の機能追加やバグ修正にも踏み出しやすくなることと思います。 ちなみに、先日弊社で開催した OSS LT会 vol.2 でも同じテーマでお話ししましたので、よければこちらのスライドも合わせてご覧ください。 www.docswell.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : もっとも最近は GitHub Codespacesを利用すれば、ローカルへのcloneは必須ではないかもしれませんが *2 : PHP マニュアルの場合もやはりHTMLへの変換プログラムは別 リポジトリ になっています *3 : 個人的な印象ですが、 OSS ではコミット履歴をきれいにするためこうしたレビュー後の修正は 別コミ ットにせず1コミットにまとめてforce pushすることが多い気がします

こんにちは！社会人4年目のaa-cryingです。 現在は開発チームの小チームのリーダーとしてチーム内のプロジェクトマネジメントを行っています。 あらすじ プロジェクトマネジメントとは PMBOK 10個の知識エリア 統合マネジメント スコープマネジメント リスクマネジメント コミュニケーションマネジメント ステークホルダーマネジメント スケジュールマネジメント コストマネジメント 品質マネジメント 資源マネジメント 調達マネジメント PMBOK 5つのプロセス 立ち上げプロセス 計画プロセス 実行プロセス 監視・コントロールプロセス 終結プロセス 初めてのプロジェクトマネジメント スケジュール・タスク管理(下流以降) リーダーへの報連相 チームマネジメント フワっと概算で算出し、スケジュールを組んだ 書籍を読んで得たエッセンス 担当になったら知っておきたい「プロジェクトマネジメント」実践講座 スケジュールの建て方 まとめ あらすじ まず、私がプロジェクトマネジメント業務に携わるようになった経緯をご説明します。 昨年度11月より、新機能の上流工程に携わりました。 下流 工程に入るタイミングでチームの再編があり、 3人チームのリーダーとして、新機能のプロジェクトリーダーに任命されプロジェクトマネジメント業務にあたることになりました。 急に任されたこともあり、そもそもプロジェクトマネジメントの知識が乏しかった私は、基本の基から学んでみることにしました。 プロジェクトマネジメントとは プロジェクトマネジメントとは、その字の如く「プロジェクトをマネジメント（管理）すること」を意味します。 もう少し噛み砕くと、「計画、進捗、作業系統化、コスト、リソース（人、物）、時間、リスクといった制約条件を管理しながら、プロジェクト完了までチームを効率的にリードしていくこと」です。 現在は PMBOK （Project Management Body of Knowledge・プロジェクトマネジメント知識体系ガイド）」という、プロジェクトマネジメントの知識を体系的にまとめた参考書のようなものが定義されています。 PMBOK は「QCD」（品質・コスト・納期）の管理のため「立上げ」「計画」「遂行」「コンロール」「集結」の「５つのプロセス」を敷き、 その為に必要な知識を「10個の知識エリア」として分類しています。 PMBOK 10個の知識エリア 統合マネジメント プロジェクト全体の方針を決めて、目標やプロセスを調整したり管理したりする分野です。 他の9つの知識エリアをその名の通り統合して、全体をマネジメントする位置づけとされています。 スコープマネジメント スコープとはプロジェクトの範囲を意味し、プロジェクトを成功させるために必要な作成物とタスクを定義して、目標の達成する確率を高めるために行う分野です。その定義は必要に応じて常に見直されます。 ここを的確に定めることがプロジェクトの成否に大きく影響するため、10個の中でも 最重要項目 ともいわれています。 リスクマネジメント プロジェクトを進めていく中で発生する可能性があるリスクを管理する分野です。 リスクはチャンスも包括することが多いため、避けてばかりいるのではなく上手くコン トロール しながら管理・調整しなければなりません。 また、想定できるリスクを事前に予防することも重要です。 コミュニケーションマネジメント ステークホルダー （利害関係者）とのスムーズなコミュニケーションを行うために管理する分野です。 プロジェクトマネジメントでは、相手にただ状況伝達するだけでなく、相手の理解を得ることができるレベルのコミュニケーションスキルが求められます。 ステークホルダー マネジメント ステークホルダー （利害関係者）にとって必要な情報を収集し、保管・伝達を管理する分野です。 プロジェクトでは、社内・社外問わずさまざまな ステークホルダー が存在します。 2012年に公表された PMBOK ガイド第5版により、「 ステークホルダー マネジメント」は「コミュニケージョンマネジメント」から独立して新しく設定された知識エリアです。 スケジュールマネジメント プロジェクト成功させるためのスケジュール管理や生産性を向上させるために時間の使い方を管理する分野です。 スケジュール管理を行うだけではなく、時間あたりの成果を高めるためのマネジメントでもあるのがポイントです。 なお、2017年に PMBOK 第6版のリリースに伴い、「 タイムマネジメント 」から「スケジュールマネジメント」に名称が変わりました。 コストマネジメント プロジェクトにかかる費用を適切に見積り・予算を設定して管理する分野です。 現実的な予算を設定することが重要であり、予算を超えないようにマネジメントを実施します。 品質マネジメント プロジェクトのプロセスやプロジェクトの作成物における品質の管理を実施する分野です。 プロジェクトにおける品質とは、作成物がクライアントが求めているものと合致しており、使用するのに適していることを指します。 資源マネジメント プロジェクトを成功させるために人材(リソース)だけでなく物的資源の調達および管理を実施して、プロジェクトを遂行できるチーム編成を行う分野です。 2017年の PMBOK 第6版のリリースに伴い、「人的資源マネジメント」から「資源マネジメント」に名称と内容が変わりました。 調達マネジメント 調達マネジメントは、プロジェクトの業務を進めていく中で必要なサービスやプロダクトの調達を管理する分野です。 調達の多くは契約が必要ですが、契約のみが目的ではありません。 調達先の選定から、納品の 進捗管理 ・ 検収 まで調達に関する全ての管理を行います。 PMBOK 5つのプロセス PMBOK では、プロジェクトの開始から終了までの流れを 立ち上げ 計画 実行 監視・コン トロール 終結 という5つのプロセスに分類して定義しています。 ここでは、それぞれのプロセスについて詳しく紹介します。 立ち上げプロセス プロジェクトを発足する前に許可を得るプロセスのことです。 立ち上げプロセスの段階では、プロジェクトを始める際に必要な情報である目的・目標・予算・成果などを定義します。 また、プロジェクト憲章の作成や ステークホルダー の特定も行います。 計画プロセス プロジェクトを成功させるための作業計画を企画して実際に設計するプロセスです。 計画プロセスの中に、20の詳細なプロセスが定義されています。 計画プロセスの段階では、目標の定義や、プロジェクトを進める際の一連の行動の流れも規定します。 実行プロセス 企画・設計した計画に基づいて人材と資源の調達を行い、プロジェクトを実際に実行するプロセスです。 5つのプロセスの中で最もリソースを消費するプロセスであり、進捗状況次第では計画の練り直しや更新を行ってベースラインを再度設定する必要があります。 監視・コン トロール プロセス プロジェクトを進めていく中の作業で計画との差異が発生していないかについて継続的にチェックを行います。 差異が検出された場合は、その改正を実施します。 終結 プロセス 規定のプロセスがきちんと完了していることを検証して、プロジェクトや工程を正式に完了させるプロセスです。 ただプロジェクトや工程を終了させるだけではなく、プロジェクトの中で獲得したノウハウを保管して、次のプロジェクトに役立たせることが大切とされています。 初めてのプロジェクトマネジメント プロジェクトマネジメントの基本をおさらいしたところで、私の 経験談 についてお話させていただければと思います。 私が今回実施した内容はプロジェクトマネジメントと言っても 下流 工程のみのため、5つのプロセスの中で言うと 「実行プロセス」以降 になります。 知識エリアで言うと 「スケジュールマネジメント」「コミュニケーションマネジメント(開発内)」「資源マネジメント(一部)」 になりますね。 具体的な業務内容をあげると、以下の3つになります。 スケジュール・タスク管理( 下流 以降) スケジュールを策定し、チームメンバーにタスクを采配 タスクの進捗をウォッチし、進捗が芳しくないようなら適宜フォローをし、原因を取り除く 原因について自チーム内での完結が難しい場合は上のリーダー層へ相談 リーダーへの 報連相 日々の進捗を報告 タスクや進捗に問題がある場合は整理した上で相談し、解決を図る。 チームマネジメント チームメンバーの開発歴や得意分野を考慮してタスクを アサイ ン 当然機能開発以外にもやることはあるため、それらについてもタスクの アサイ ンや進捗の管理を行う 機能開発以外にもチームメンバーの困っていることや問題の解決 他チームの方やリーダーに助けられ、最終的にはスケジュールから何とか遅れずに開発完了できましたが、その中で 失敗 もありました。 フワっと概算で算出し、スケジュールを組んだ 一番にあげるならこれです。 スケジュールを立てる方法が分からず、過去の似たような箇所を改修している案件から概算でおおまかなスケジュールを組んでしまいました。 その後、いざ実装に入るタイミングで見積もりを見直したところ、見立ての2倍くらいの 工数 に跳ね上がりました。 当然リスケをすることに... 書籍を読んで得たエッセンス スケジュールマネジメントには課題感が大きく、どうすれば良いか悩んでいました。 上長やリーダーの方の勧めもあって書籍を読んでみることに... 担当になったら知っておきたい「プロジェクトマネジメント」実践講座 読んでみた書籍はこちら。 選んだ理由は Amazon で検索して1番左上に出てきたのと、 担当になったばかりだったのでタイトルと自分の状況があってそうだなと思ったことです。 全部読んだわけではなく、課題に感じていたスケジュールや見積もりに関する箇所を中心に読んでみました。 以降は書籍に記載されていたエッセンスとそれに基づいた失敗の分析等をまとめています。 スケジュールの建て方 まず、書籍にて紹介されていたスケジュールの建て方を紹介します。 WBS の構成要素・最終目標を書き出す 要素を出し終わったら各要素の成果物を書き出す 各要素の成果物を更に分割し、要素成果物(ワーク・パッケージ)を書き出す その要素成果物(ワーク・パッケージ)を生み出すための活動(アクティビティ)を書き出す 活動の順序付けを行う 順序付けを行ったアクティビティ一つ一つについて 工数 見積もりを行う アクティビティの単位で開始日と終了日を決める アクティビティ⇒ワーク・パッケージ⇒成果物⇒最終目標と 工数 を積み上げていき、全体の完了日を設定する 参考文献：「プロジェクトマネジメント」実践講座の3章 ...と結構多く段階を踏む必要があるそうです。 ここで気づいたのが、 私達のチームでは、 開発の工程を細かくタスクに分割した一覧として Redmine のチケットテンプレートが存在する こと。 基本的に機能開発の 下流 工程を開始する際は、そのテンプレートからチケットを登録しています。 100%達成すれば、基本的に開発工程が漏れなく完了できるというものです。 なんと、開発準備の段階で既にアクティビティまで分割と順序付けまで出来ていました。 先の機能開発でも使用はしていたのですが、 WBS の構成要素について過去の案件からおおよそのスケジュールを定め、 それをもとに Redmine チケットの1つ1つの開始日・期限を設定していくという方法を取ってしまっていました。 上記書籍の手法の逆をやっていることになるので、そりゃあ見積もり精度に問題が出るわけですね。 まとめ 今回はプロジェクトマネジメントの基本の基として PMBOK の「10個の知識エリア」「5つのプロセス」を紹介し、その上でスケジュールマネジメント(主にスケジュール策定)の手法について経験を交えながら少し掘り下げてみました。 本来なら書籍に記載の手法に則って策定したスケジュールに沿って進めて実際にどうだったかまで記載できれば良かったのですが、プロジェクトは現在進行中なので、プロジェクトが完了した際に振り返ってみて、また記事にしたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは技術広報の syoneshin です。 最近「Notion」を利用した情報収集や管理を聞く機会が増え 個人的に興味の沸いた「Notion」について基本情報や使い方を調べまとめました。 本記事は Notionをはじめて知った方 Notionのを使い方を知りたい方 向けにNotionの基本的な使い方と事例をご紹介します。 Notionとは Sign upしよう Step1.メールアドレス入力 Step2.ログイン Step3.アカウント情報入力・パスワード Step4.利用プランの選択 Step5.Notionの登録完了 Notion基本の使い方 ドキュメント/メモ作成 タスク管理 データ管理 情報共有 Notionの使い方事例 事例① 事例② 事例③ 事例④ さいごに Notionとは Notionは、2018年に アメリ カのNotion Labsによって開発された情報管理・共有アプリケーションです。 メモなどのドキュメント作成 タスクやデータの管理 チームでのマニュアルやナレッジ共有 などなど、多く機能を備えており これまで複数のツールやアプリで管理・共有していた情報を まとめて一元管理・共有できる優れたサービスです。 Notionはオールインワンの情報共有ツールを掲げているだけあって、具体的には以下のような機能と利便性が評価されて利用ユーザーは既に全世界で1000万人を超えています。 ■具体的な機能例 ドキュメント管理・編集機能（ Google ドキュメント） ファイル保存機能（ Google ドライブ、 Dropbox ） データベース管理機能（ Excel 、 Access ） タスク管理機能（Trello、Asana） To Doリスト作成管理機能 メモ作成機能 カレンダー登録管理機能 マークダウン記法機能 各種コードの埋め込み機能 Webクリップ機能 画像ギャラリー 2021年9月現在、残念ながらNotionの日本語版はございません。 今後は、日本版リリースにも期待したいところです。 Sign upしよう ここからはNotionの使い方を具体的な利用手順に沿って紹介します。 初めて利用される方は、Notionに Sign upする必要があります。 普段利用しているメールアドレスがあれば、 Sign upできます。 ※ Gmail アカウントなら簡単です。 Step1.メールアドレス入力 アカウントを新規作成される方は、上記で入力したメールアドレスに自動メールが届きます。 Step2.ログイン メールに届いたURLをクリック、もしくはパスコードをsing up画面で入力すると Notionにログインでき、アカウント情報入力画面に遷移します。 Step3.アカウント情報入力・パスワード ご自身のアカウント情報を所定箇所に入力し、ログ インパス ワードを設定します。 Step4.利用プランの選択 以下利用プランから1つを選択します。 With my team :　複数名のグループで使用する場合に選択　※無料トライアルは1週間、その後は有料 For myself　:　個人から2~3人に共有する場合に選択 Step5.Notionの登録完了 以下、Notion管理画面でGetting Startedページが出れば サインアップ(登録)は完了となり、Notionを使う事ができます。 Notion基本の使い方 ここからはNotionの基本的な使い方を紹介します。 「Notion」はマルチブラウザ対応で、アプリでも利用できます。 ※本記事では Google Chrome での使い方をご紹介。 ドキュメント/メモ作成 Notionの使い方、まずはドキュメント/メモの作成です。 Notionのドキュメント/メモの大きな魅力は、カスタマイズの自由度が高いことです。 では、ドキュメント/メモの使い方を説明します。 ページを新規作成する Notion管理画面左のサイドバーにページ一覧があり、ドキュメント/メモを追加作成するには「＋Add a page」、もしくは「＋New page」をクリックするとドキュメント/メモ作成ができます。 白紙でドキュメントを作成したければ、表示されたページにある「Empty」を選択すればOKです。 「Enpty」を選択すると以下のようなページが生成されます。 「Untitled」にドキュメント/メモのタイトルを、テキスト箇所にテキストを入力すればOKです。 テキストの入力方法にはマークダウン記法が使えます。 ※マークダウン記法について知りたい方は以下記事も参考にしてみて下さい。 tech-blog.rakus.co.jp ドキュメント内のタイトル上部にカーソルを合わせると、アイコン、カバー画像、コメントを設定できるメニューが表示され、クリックするとドキュメント/メモの装飾もできます。 ドキュメント/メモの装飾例 またNotionは各ドキュメントをツリー構造で管理できるのが大きな特色です。 その他、URLのブックマーク保存、Googlemap、 YouTube やgsuiteのドキュメント・スライド・スプレットシート、PDF、などの埋め込みもできます。 タスク管理 Notionはタスク管理ツールとしても利用可能です。 それでは使い方を紹介します。 ページを新規作成する まずはドキュメント/メモ作成と同じく、以下の手順でページを新規作成します。 「+New Page」をクリック ページのタイトルを入力 ページテキスト内のメニューから「Table」をクリック すると以下の様なテーブルが生成されます。 表の項目を作成する Table（表）が表示されたら、Name、Tags、Filesの名前を変更して、項目を作成します。 Property Typeは、その項目の入力規制(例えば締切ならDate、テキストならTextなど）を設定します。 以下のようなイメージになります。 また表示タイプはテーブル表示ではなく 1: カンバン方式 型 2:カレンダー型 3:ギャラリー型 4:リスト型 などにしたい場合は 「+Add a View」から追加できますのでお試し下さい。 以下は各表示形式のイメージです。 データ管理 Notionの使い方でも、コア機能であるデータベース機能を使ったデータ管理はとても人気です。 情報の蓄積と検索を可視化でき、必要な情報を取り出しやすくできます。 例えばデータベース機能を使って 読書リスト ニュースリスト 顧客管理リスト などが作れ、情報管理と引出しが容易にできます。 データベースをカスタマイズできる自由度が高いため、さまざまな利用用途で使え、自分だけの独自なデータ管理ができるので便利です。 私は読みたい本や読了した本の要約メモをリスト化して、読書リストとして利用しております。 情報共有 Notionで作ったドキュメントやデータは他者やチームへの情報共有、またWEB上での公開も可能です。 Notionを既に利用している人であれば、複数人でどんなページでもすぐに共有が可能です。 まず共有メンバーの追加方法は以下 Workspace全体を共有したい場合 サイドバーの Settings & Members をクリック Add a Member ボタンをクリック 追加したいメンバーのメールアドレスを入力し enter をクリック 追加したいメンバーにNotionへの招待メールが届く 特定のページのみ共有したい場合 ページ右上の Share をクリック Invite a Person ボタンをクリック 追加したいメンバーのメールアドレスを入力し、ドロップダウンから権限(full access , can comment, can read)を選択して Invite をクリック 追加したいメンバーにNotionへの招待メールが届く ページ共有を一人に、複数人に、WEB上で共有・公開する方法や編集・閲覧権限は以下に詳しい記載がございますので、ご確認下さい。 extns.notion.site チームでのタスク・ナレッジ共有だけでなく 最近ではサービスページやFAQとして WEB公開している事例もございます。 Notionの使い方事例 ここではNotionの使い方について 個人や法人ではどのように使われているのか？ いくつか事例をご紹介します。 事例① こちらは当社主催イベント「情報収集ハックLT会」で紹介されたNotionの使い方事例です。 情報をどう集め、どう整理するか？ 特に情報どう活かすのか までご紹介されている事例で大変参考になります。 speakerdeck.com 事例② こちらは当社開発メンバーがNotionの使い方を紹介した事例になります。 RSSリーダー 「Inoreader」とNotionを組み合わせたニュースや技術情報の クリッピング と整理方法を紹介しております。 speakerdeck.com 事例③ 最近ではNotionを使った採用ページやFAQサイト、コーポレートサイト、サービスサイトなども出始めております。 以下ではNotionで作られたサイトやページ情報を集約されております。 こちらをみるとNotionは、改めて自由度が高いと感じます。 www.notion.so また法人企業での利用例で以下も参考になる記事です。 seleck.cc 事例④ こちらは YouTube で紹介されていたNotionの使い方事例です。 こちらのチャンネルではNotionの使い方事例が多く取り上げられており参考になります。 www.youtube.com さいごに ご紹介の「Notionの使い方 まとめ」は、いかがだったでしょうか？ Notionの使い方を詳しく知るには以下 『公式ヘルプ 日本語版 | Npedia』 が参考になります。 extns.notion.site 本ブログが、これからNotionを使いたいという方のお役にななれば、幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに Twitter API Twitter API利用申請 アプリケーション作成 データの取得 タイムラインのツイートを取得 ツイートIDを指定して検索 キーワード検索 地域のトレンド取得 まとめ 参考 はじめに こんにちは。taku_76です。 前回は API について記事作成し 食べログ API を使ってみましたが、他の API も触れてみたいと思い、 今回は Twitter API を使ってみました。本記事では Twitter API の利用申請から Twitter API を使用したデータ取得方法を紹介したいと思います。 Twitter API Twitter API を使用することで、ツイートの取得であったり、投稿、フォローなど行うことができます。また、自動でフォローやいいねもすることができます。 今回は Python で Twitter API を利用する際に使える、Tweepyを使用して主にデータの取得を例に紹介します。 Twitter API 利用申請 以下からDeveloperサイトにアクセスして、「Create an app」ボタンを押下します。 次の画面で デベロッパ ーツールの利用目的を聞かれます。 私の場合は Twitter API を使用したかったので、「Hobbyist > Exploring the API 」を選択しました。 選択肢はいろいろありますので自分の目的に応じて選択してください。 ただ他のサイトでも確認しましたが、厳密でなくてもよいみたいです。 選択できましたら、画面下部の「Get started」ボタンを押下して次に進みます。 この画面では以下について確認します。 ・アカウント ・メールアドレス ・個人開発者アカウント or チーム開発者アカウント ・ニックネーム ・住んでいる国 ・自身のコーディングスキルレベル 5つの質問に英語で回答します。 ・ Twitter API または Twitter データをどのように使用しますか？ 私の場合は、トレンドのツイートを取得して分析するであったり、 Python の学習のためといった内容を英語に翻訳しました。 ・ Twitter のデータを分析する予定はありますか？ YESと回答すると、データを分析する方法を説明する必要があります。 トレンドのツイートやそれに含まれているキーワードを分析して特徴を調べるといった内容を記載しました。 残り以下の質問がありますが、今回使用する予定がなかったのでNoとしました。 ・アプリはツイート、 リツイート 、いいね、フォロー、ダイレクトメッセージ機能を使用しますか？ ・ Twitter 以外の Twitter コンテンツに関するツイートや集計データを表示する予定はありますか？ ・あなたの製品、サービス、または分析により、 Twitter のコンテンツまたは派生情報を政府機関が利用できるようになりますか？ 全て入力が完了したら「Next」ボタンを押下します。 入力内容の確認をします。問題なければ「Next」ボタンから次に進みます。 最後に 利用規約 の確認を行い、「Submit Application」ボタンを押下して申請は完了です。 アプリケーション作成 Twitter API の利用申請が完了すると、 Twitter アカウントのメールアドレス宛にメールが届いていますので 「Confirm your email」ボタンを押下して デベロッパ ーサイトにアクセスします。 「Create project」ボタンを押下してプロジェクト作成画面に進みます。 プロジェクトの名前を入力して次に進みます。 Twitter 開発者プラットフォームを使用する方法を選択します。 今回は Twitter API を使用するので「Exploring the API 」を選択しました。 プロジェクトについて説明します。 Twitter API 利用申請時の目的と同じような内容で良いと思います。 最後にアプリ名を入力します。 次の画面で Twitter API キーと API シークレットキーが表示され、それらを使用することで Twitter API を利用することができます。 データの取得 Twitter API ではアカウントをフォローしたり、ツイートを投稿したり様々な機能を利用できますが、今回はデータの取得に絞って例を紹介します。 Twitter API を使用するためのコードですが、まずはTweepyを利用するために以下の設定を行います。 import tweepy # 取得したキーを格納 CK = "APIキー" CS = "APIシークレットキー" AT = "アクセストークン" AS = "アクセストークンシークレットキー" # Tweepy設定 auth = tweepy.OAuthHandler(CK, CS) # Twitter API認証 auth.set_access_token(AT, AS) # アクセストークン設定 api = tweepy.API(auth) # オブジェクト設定 これで設定が完了しましたので、実際に Twitter API を使用していきます。 タイムラインのツイートを取得 タイムラインの取得には以下の３つのメソッドがあります。 ・ API .home_timeline：自分自身のタイムライン ・ API .user_timeline：指定したユーザのタイムライン ・ API .mentions_timeline：自分へのリプライのタイムライン API .home_timelineメソッドの引数としては以下があります。 ・since_id：指定したIDより最近のツイートが取得される（IDは最近のものほど大きくなる） ・max_id：指定したIDよりも古いツイートが取得される ・count：取得件数指定 ・page：取得する結果のページを指定 API .home_timelineを使用した例が以下となります。 #タイムライン取得 result = api.home_timeline(count=1) for tweet in result: print('='*80) print('ツイートID : ', tweet.id) print('ツイート時間 : ', tweet.created_at) print('ツイート本文 : ', tweet.text) print('ユーザ名 : ', tweet.user.name) print('スクリーンネーム : ', tweet.user.screen_name) print('フォロー数 : ', tweet.user.friends_count) print('フォロワー数 : ', tweet.user.followers_count) print('概要 : ', tweet.user.description) print('='*80) ツイートIDを指定して検索 API .get_statusメソッドを使用することでツイートIDからツイートの情報を取得できます。 以下が例となっています。（TWEETIDを検索したいツイートIDに指定してください） #ツイートIDを指定 TWEETID = 'xxxxxxxxxxxxxxxxx' #ツイートの取得 tweet = api.get_status(TWEETID) #JSON形式に変換 result = tweet._json #表示 print('作成日 : ', result["created_at"]) print('スクリーンネーム : ', result['user']['screen_name']) print('ツイートテキスト : ', result['text']) キーワード検索 検索を行うには API .searchメソッドを使用します。引数は以下のようになっています。 ・q：検索するキーワード ・geocode：ツイートした場所 ・lang；言語指定 ・locale：クエリの言語指定 ・result_type：取得ツイートの種類指定 ・count：取得件数指定 ・until：ツイート時期の指定 ・since_id：指定したIDより最近のツイートが取得される ・max_id：指定したIDよりも古いツイートが取得される ・include_entities：entitiesの有無 以下が例となります。 tweet _mode = 'extended'とありますが、これを指定することで140字を超えた場合でもツイートの本文全て取得できます。 tweets = api.search(q = "Twitter API", include_entities = True, tweet_mode = 'extended', lang = 'ja', count = 1) for tweet in tweets: print('='*80) print('ツイートID : ', tweet.id) print('ユーザ名 : ', tweet.user.screen_name) print('日時 : ', tweet.created_at) print(tweet.full_text) print('いいね数 : ', tweet.favorite_count) print('リツイート数 : ', tweet.retweet_count) print('='*80) 地域のトレンド取得 地域のトレンドを取得するには、 API .trends_placeメソッドを使用します。引数としてはwoeidと呼ばれるidを指定します。 これはYahooから提供されているIDを指します。 以下が例となっています。検索結果を少なくするためにwoeidを日本だけにしています。 woeid = { "日本": 23424856 } for area, wid in woeid.items(): print("--" + area + "--") trends = api.trends_place(wid)[0] for i, content in enumerate(trends["trends"]): print(i+1, content['name']) 出力結果は以下になります。 --日本-- 1 #佐久間宣行ANN0 2 #乃木坂46ANN 3 #CRWIN 4 #寝ローンズ 5 打順と守備位置 6 #SMAP30YEARS 7 香山リカ 8 津田大介 9 署名運動 10 愛知県知事 11 PS5pro 12 えむちゃん 13 中京テレビＮＥＷＳ 14 記述削除 15 中京テレビNEWS 16 アナスタシア 17 膳場貴子アナ戦闘態勢 18 相田さん 19 レジライリリィ 20 インターバル 21 高市早苗氏笑顔 22 HO診断 23 痛烈質問 24 コルデー 25 他人のそら似 26 従軍慰安婦 27 テイルズ 28 まいちゅん 29 両刃の剣 30 閣議決定 31 沖田オルタ 32 中村悠一 33 アクシア 34 なぎこさん 35 オツカレサマデシタ 36 レザーくん 37 通信障害 38 ちゃん誕生日 39 まじんさん 40 万里くん 41 世界大会 42 書類送検 43 守護のため 44 教科書会社5社 45 久保ちゃん 46 最新研究 47 スペースおつこれ 48 カイニス 49 沖田さん 50 記述削除 まとめ いかがだったでしょうか。今回は Twitter API の利用申請からデータ取得までを紹介させていただきました。 Twitter API の利用申請は入力事項が多く苦労しましたが、以前は審査が厳しくもっと苦労することがあったみたいです。 Twitter API についてまだ簡単な部分しか触れられていないため、他の使い方も試していこうかと思います。 参考 Twitter APIで遊んでみた ~1. 各種キーの申請と取得~ | SIOS Tech. Lab APIリファレンス — tweepy 3.6.0 ドキュメント 2021年度版 Twitter API利用申請の例文からAPIキーの取得まで詳しく解説 | 新宿のホームページ制作会社 ITTI（イッティ） エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 目標 前提条件 雛形作成 APIモック作成 Vuex導入 コンポーネント作成 アイテム追加機能作成 おわりに はじめに こんにちは。新卒１年目のrksmskです。本記事はVue.jsを学び始めたばかりで実際に手を動かして簡単なアプリケーションを作成してみたい方のためのハンズオン チュートリアル となっております。 是非手を動かしながら本記事をお読みください。なお、本記事はVue3でコードを記述しています。Vue.jsはVue2とVue3で記述方法が大きく異なるため、ご留意ください。 目標 Vue.jsを使ってTodoListの表示と追加が出来る簡単なTodoListアプリケーションが作れるようになること。 前提条件 Node.jsがインストールされていること(Node.jsの説明やインストール方法については以下の記事に詳しく記載されています) 雛形作成 まず、Vueの環境を作成して雛形の画面を表示します。 TodoList作業用 ディレクト リを作成します。 ここからはターミナル上で作業を行います。TodoList作業用 ディレクト リ下でターミナルから npm install -g @vue/cli@next を実行し、Vueをインストールします(インストールが上手くいかない場合にはNode.jsのバージョン等をご確認ください)。 vue create todo-list を実行し、Vueの環境を作成します。その際にVueのバージョンを確認されるので、Vue3を選択します。パッケージマネージャはnpmを選択します。 環境作成が完了しましたら、 cd todo-list を実行してVueの環境に移った後、 npm run serve を実行してローカルのテストサーバを起動します。 立ち上がったサーバにブラウザからアクセスします。基本的には http://localhost:8080/ にサーバが立ち上がります。 下記のような雛形の画面が表示されることを確認します。 雛形画面 これで雛形画面の作成が完了しました。 API モック作成 続いて、TodoListのアイテムを作成します。今回は JSON Serverを使用して API モックを作成し、作成した API モックを通じてアイテムの CRUD (Create、Read、Update、Delete)操作を行います。 ここからはターミナル上で作業を行います。 npm i json-server を実行し、 json -serverをインストールします。 mkdir webapi を実行し *1 、webapi ディレクト リを作成します。 cd ./webapi を実行した後、 touch db.json を実行し *2 、db. json ファイルを作成します。 db. json ファイルに以下を記入します。 { " todos ": [ { " id ": 1 , " text ": " 働く ", " categoryId ": 1 } , { " id ": 2 , " text ": " 寝る ", " categoryId ": 1 } , { " id ": 3 , " text ": " 起きる ", " categoryId ": 2 } ] , " categories ": [ { " id ": 1 , " title ": " やること " } , { " id ": 2 , " title ": " やったこと " } ] } webapi下で npx json-server --watch db.json を実行し、 API モックサーバーを起動します。 立ち上がったサーバにアクセスします。基本的には http://localhost:3000/ にサーバが立ち上がります。 下記のような JSON Serverの起動画面が表示されることを確認します。 JSON Server起動画面 これで API モックの起動が完了しました。 Vuex導入 ここまでで、雛形画面の作成と API モックの起動が完了しました。ですので、ここからは API モックを通じてTodoListを取得し、雛形画面に表示することを行います。その際に、後々状態管理を行う上で便利になるため、Vuexを導入したいと思います。Vuexは共有状態の管理を行うライブラリで、異なる コンポーネント 間で同一のデータを共有する際に重宝します。 ここからはターミナル上で作業を行います。現在の ディレクト リをtodo-listに変更した後、 npm install vuex@next --save を実行し、Vuexライブラリをインストールします。 cd ./src を実行した後、 mkdir store を実行し、todo-list/src ディレクト リ下にstore ディレクト リを作成します。 touch store.js を実行し、store.jsファイルを作成します。本ファイルがVuexで共有状態を管理するコードを記述するファイルとなります。 store.jsを以下のように書き換えます。 import { createStore } from "vuex" ; export default createStore( { state() { return { categoryList: [] , cardList: [] } } , mutations: { setCategoryList(state, categoryList) { state.categoryList = categoryList; } , setCardList(state, cardList) { state.cardList = cardList; } } , actions: { async fetchCategoryList(context) { const categoryList = await fetchItems( "http://localhost:3000/categories" ); context.commit( "setCategoryList" , categoryList); } , async fetchCardList(context) { const cardList = await fetchItems( "http://localhost:3000/todos" ); context.commit( "setCardList" , cardList); } , } } ); actionsに記載されているfetchXXXメソッドでは API から情報を取得し、取得した情報を引数にmutationsのメソッドを呼び出しています。mutationsではstateの変更を行っています。 ここで注意したいこととして、mutationsでは非同期処理を行わないこと、actionsではstateの更新を直接行わないことです。これらの注意点の詳しい説明は以下の記事に詳しく記載されているため、そちらも併せてご覧ください。 Vuexの設定をアプリケーションに反映させるため、main.jsファイルを以下のように書き換えます。 import { createApp } from 'vue' import Store from './store/store.js' ; import App from './App.vue' createApp(App).use(Store).mount( '#app' ) これでVuexでTodoListの状態管理をする仕組みが出来たため、後は API からデータを取得するfetchXXXメソッドを作成し、雛形画面に表示させます。 現在の ディレクト リをtodo-listに変更した後、 mkdir utils を実行し、todo-list下にutils ディレクト リを作成します。 *3 cd ./utils を実行した後、 touch http.js を実行し、todo-list/utils ディレクト リ下にhttp.jsファイルを作成します。 http.jsを以下のように書き換えます。 export const fetchItems = async (url) => { try { // API通信でデータを取得する const response = await fetch(url); // 取得したデータをjson形式で返す return await response.json(); } catch (error) { // API通信でデータを上手く取得できなかった場合、コンソールにエラーを表示 console.error( "データを取得出来ませんでした" ); console.error(error); } } ; store.jsにhttp.jsをインポートするため、store.jsの二行目に以下を追加します。 import { fetchItems } from "../../utils/http" ; App.vueを以下のように書き換えます。 <template> <div> カード一覧： {{ cardList }} <br /> カテゴリ一覧： {{ categoryList }} </div> </template> <script> import { computed, onMounted } from "vue" ; import { useStore } from "vuex" ; export default { name: "App" , components: {} , setup() { // Vuexを使う設定 const store = useStore(); // コンポーネントがマウントされた時にcategoryListとcardListをAPIから取得 onMounted(store.dispatch( "fetchCategoryList" )); onMounted(store.dispatch( "fetchCardList" )); return { cardList: computed(() => store.state.cardList), categoryList: computed(() => store.state.categoryList) } ; } } ; </script> <style></style> 上記の記法は単一ファイル コンポーネント と呼ばれる記述方法で、 templateタグ内に画面に表示するHTMLを記述する。 scriptタグ内にデータの定義や処理を記述する。 styleタグ内に css でスタイルを記述する。 といったようにHTML、 JavaScript 、 CSS の処理をまとめて一つのファイルに記述することが出来ます。これにより、一つ一つの コンポーネント の保守がし易くなっています。 ローカルのテストサーバを再起動し、下記のようなデータが画面に表示されることを確認します。 カード一覧：[ { "id": 1, "text": "働く", "categoryId": 1 }, { "id": 2, "text": "寝る", "categoryId": 1 }, { "id": 3, "text": "起きる", "categoryId": 2 } ] カテゴリ一覧：[ { "id": 1, "title": "やること" }, { "id": 2, "title": "やったこと" } ] これでTodoListの表示が完了しました。 コンポーネント 作成 ここまででTodoListの表示は出来ましたが、現状はデータがそのまま表示されているだけで、非常に見づらいです。 ですので、ここからはTodoListをカード形式で表示するように変更していきたいと思います。その際に、Vueに備わっている一つ一つの部品を コンポーネント として切り出すことで管理し易くする機能を利用します。 今回の コンポーネント は以下のようにボード、リスト、カードで分割を行います。 コンポーネント 分割例 components下のHelloWorld.vueを削除します。 components下にBoard.vue、List.vue、Card.vueを作成します。 App.vueを以下のように書き換えます。 <template> <div> <board></board> </div> </template> <script> import Board from "./components/Board.vue" ; export default { name: "App" , components: { Board } } ; </script> <style></style> 少しだけVue2とVue3の違いを説明すると、Vue2では値はdataプロパティに、関数はmethodsにといったようにプロパティ毎に役割を分けていましたが、Vue3では新しく追加されたComposition API の機能によってsetup関数にこれらの処理をまとめて記述することが出来ます。 そのsetup関数内ではVuexで定義したactions内のメソッドをstore.dispatch("メソッド名")によって呼び出します。その結果、VuexのcardListとcategoryListの状態が変化するため、その状態変化をcomputed関数によって検知し、データの反映を行っています。 Board.vueを以下のように書き換えます。 <template> <div class = "board-style" > <list v- for = "category in categoryList" :key= "category.id" :category= "category" ></list> </div> </template> <script> import { computed, onMounted } from "vue" ; import { useStore } from "vuex" ; import List from "./List.vue" ; export default { components: { List } , setup() { const store = useStore(); onMounted(store.dispatch( "fetchCategoryList" )); return { categoryList: computed(() => store.state.categoryList) } ; } } ; </script> <style scoped> .board-style { display: flex; gap: 10px; } </style> Board.vueではv-forディレクティブによってカテゴリ毎にList コンポーネント を生成しています。その際にList コンポーネント にはカテゴリの情報を渡しています。 List.vueを以下のように書き換えます。 <template> <div class = "list-style" > {{ category.title }} <card v- for = "card in cardList" :key= "card.id" :card= "card" ></card> </div> </template> <script> import { computed, onMounted } from "vue" ; import { useStore } from "vuex" ; import Card from "./Card.vue" ; export default { components: { Card } , props: { category: Object } , setup(props) { const store = useStore(); onMounted(store.dispatch( "fetchCardList" )); const cardList = computed(() => store.state.cardList.filter(card => card.categoryId === props.category.id) ); return { cardList, } ; } } ; </script> <style scoped> .list-style { display: inline-flex; flex-direction: column; text-align: center; background-color: silver; min-width: 200px; min-height: 400px; } </style> List コンポーネント はBoard コンポーネント から渡ってきたカテゴリの情報をもとに、カテゴリIDと一致するカードをArrayオブジェクトの標準ライブラリであるfilterを用いて抽出し、v-forディレクティブによって抽出したカード毎にCard コンポーネント を生成しています。 Card.vueを以下のように書き換えます。 <template> <div class = "card-style" > {{ card.text }} </div> </template> <script> export default { props: { card: Object , } } ; </script> <style scoped> .card-style { display: flex; flex-direction: column; background-color: yellowgreen; margin: 10px; height: 10vh; align-items: center; justify-content: center; border-radius: 10px; } </style> Card コンポーネント はList コンポーネント から渡ってきたカードのテキストを表示しています。 ローカルのテストサーバを再起動し、下記のような完成画面が表示されることを確認します。 完成画面 これで、 コンポーネント 分割が完了し、TodoListが見やすくなりました。 アイテム追加機能作成 現状、アイテムの追加はwebapi下のdb. json をエディタ等で直接書き換えるか、POSTメソッドでHttpRequestを送る必要があり、少々手間がかかります。 そこで、空のカードを用意し、そのカードにテキストを入力して追加ボタンを押したら新しいカードが追加されるようにして利便性を上げたいと思います。 http.jsを以下のように書き換えます。 export const fetchItems = async (url) => { try { // API通信でデータを取得する const response = await fetch(url); // 取得したデータをjson形式で返す return await response.json(); } catch (error) { // API通信でデータを上手く取得できなかった場合、コンソールにエラーを表示 console.error("データを取得出来ませんでした"); console.error(error); } }; +export const insertItems = async (url, data) => { + const response = await fetch(url, { + // json形式でPOSTでデータを送る + method: 'POST', + headers: { + 'Content-Type': 'application/json;charset=utf-8' + }, + body: JSON.stringify(data) + }).catch(() => { + // 上手くいかなかった場合、コンソールにエラーを表示 + console.error(response.json()) + return; + }) +}; store.jsを以下のように書き換えます。 import { createStore } from "vuex"; -import { fetchItems } from "../../utils/http"; +import { fetchItems, insertItems } from "../../utils/http"; export default createStore({ state() { return { categoryList: [], cardList: [] } }, mutations: { setCategoryList(state, categoryList) { state.categoryList = categoryList; }, setCardList(state, cardList) { state.cardList = cardList; }, }, actions: { async fetchCategoryList(context) { const categoryList = await fetchItems("http://localhost:3000/categories"); context.commit("setCategoryList", categoryList); }, async fetchCardList(context) { const cardList = await fetchItems("http://localhost:3000/todos"); context.commit("setCardList", cardList); }, + async addCard(context, data) { + await insertItems("http://localhost:3000/todos", data); + } } }); List.vueを以下のように書き換えます。 <template> <div class="list-style"> {{ category.title }} - <card v-for="card in cardList" :key="card.id" :card="card"></card> + <card + v-for="card in cardList" + :key="card.id" + :card="card" + :isNew="false" + ></card> + <card :card="newCard" :isNew="true"></card> </div> </template> <script> import { computed, onMounted } from "vue"; import { useStore } from "vuex"; import Card from "./Card.vue"; export default { components: { Card }, props: { category: Object }, setup(props) { const store = useStore(); onMounted(store.dispatch("fetchCardList")); const cardList = computed(() => store.state.cardList.filter(card => card.categoryId === props.category.id) ); + const newCard = { + id: -1, + text: "", + categoryId: props.category.id + }; return { cardList, + newCard }; } }; </script> <style scoped> .list-style { display: inline-flex; flex-direction: column; text-align: center; background-color: silver; min-width: 200px; min-height: 400px; } </style> List コンポーネント では、新しく追加するカードの雛形オブジェクトであるnewCardを定義し、Card コンポーネント に渡しています。また、Card コンポーネント には対象のカードが新しく追加するカードなのか否かを識別できるようにboolean型の変数isNewも渡しています。 Card.vueを以下のように書き換えます。 <template> <div class="card-style"> + <input type="text" v-if="isNew" v-model="text" /> + <button @click="addCard" v-if="isNew">追加</button> + <span v-else> {{ card.text }} + </span> </div> </template> <script> +import { ref } from "@vue/reactivity"; +import { useStore } from "vuex"; export default { props: { card: Object, + isNew: Boolean + }, + setup(props) { + const store = useStore(); + let text = ref(""); + const addCard = async () => { + const data = { + text: text.value, + categoryId: props.card.categoryId + }; + await store.dispatch("addCard", data); + await store.dispatch("fetchCardList"); + text.value = ""; + }; + return { + text, + addCard + }; } }; </script> <style scoped> .card-style { display: flex; flex-direction: column; background-color: yellowgreen; margin: 10px; height: 10vh; align-items: center; justify-content: center; border-radius: 10px; } </style> Card コンポーネント のtemplateタグ内では、isNewがTrueの場合に【追加】ボタンが表示されるようにしています。 scriptタグ内では、【追加】ボタンが押された場合にaddCardメソッドを実行する処理を記述しています。addCardメソッドではカードの情報をdataオブジェクトに格納し、Vuexのactionsをdisptach関数によって呼び出しています。 なお、dataオブジェクトのidプロパティについては、 json -serverでは自動で割り振られるようになっているため追加していません。 ローカルのテストサーバを再起動し、下記のように新しいカードの追加が出来ることを確認します。 *4 カード追加前 カード追加後 これで、カードの追加機能が完成しました。 おわりに 今回はVue.jsを使ったTodoList チュートリアル を紹介しました。本記事ではTodoListの表示とアイテムの追加という基本機能だけでしたが、その他にも カードの更新、削除機能 カテゴリ追加機能 カードが API を通じて読み込まれるまでの間のロード画面 カード移動機能( ドラッグ&ドロップ 可能だとより良いと思います) タイトルの色変更機能 デザイン変更(Vuetify等の マテリアルデザイン フレームワーク を利用するだけでもリッチになります) 等々様々な拡張が可能だと思うので、是非拡張してみてください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : ディレクト リが作成出来ればmkdirコマンドでなくても問題ありません。 *2 : ファイルが作成出来ればtouchコマンドでなくても問題ありません。 *3 : API 通信のような汎用的に使われるメソッドはutils ディレクト リ下に配置することが多いです。 *4 : Board.vueには変更はありません。

こんにちは、技術広報の yayawowo です。 皆様、お気に入りの技術書はありますか？ 今回は、弊社主催で開催している「おすすめの技術書LT会」にて、エンジニア/デザイナーの皆さんに紹介いただいた技術書を一挙公開します！ おすすめの技術書 LT会 - vol.1 おすすめの技術書 LT会 - vol.2 積読 が増える可能性がある、エンジニア/デザイナーが厳選した技術書が盛り沢山…お読みになる際は覚悟ください！ ラク ス開発メンバーが選んだ技術書は以下をご確認ください。 ・ 開発メンバーが選ぶ、おすすめの技術書【2020年度】 - RAKUS Developers Blog | ラクス エンジニアブログ 入門シリーズ 『C++プログラミング入門（湯田幸八）』 『ドメイン駆動設計入門』 『実践SQL教科書』 『ソフトウェアデザイン 2021年3月号』 『独習C 新版』 『PHPの絵本 第2版 Webアプリ作りが楽しくなる新しい9つの扉』 『コンピュータシステムの理論と実装』 『初めてのPHP』 『Vue.js3超入門』 『リファクタリング(第2版)』 『「実践ドメイン駆動設計」から学ぶDDDの実装入門』 『テスト駆動開発』 『ふつうのLinuxプログラミング 第2版』 『エキスパートPythonプログラミング 改訂3版』 『Go言語による並行処理』 『Linuxによる並行プログラミング入門』 『Goならわかるシステムプログラミング』 『Linuxシステムプログラミング』 『CPUの気持ちが知りたいですか？』 『n月刊ラムダノート Vol.3, No.1(2021)』 『Webを支える技術』 『フロントエンド開発入門: プロフェッショナルな開発ツールと設計・実装』 『プリンシプル オブ プログラミング』 『CSS設計完全ガイド』 応用シリーズ 『体系的に学ぶ安全なWebアプリケーションの作り方』 『デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチ』 『インターフェースデザインの心理学』 『なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー』 『OSS-DB Silver Ver.2.0対応』 『SQLアンチパターン』 『Joel on Software』 『文芸的プログラミング』 『機械学習を解釈する技術』 『プログラマの数学』 『GPT-3 完全初心者への徹底解説: 最強の文章生成AIの実像』 『進化的アーキテクチャ』 『計算できるもの、計算できないもの』 『エクストリームプログラミング』と『組織パターン』 『UNIX A History and a Memoir』 終わりに 入門シリーズ 『 C++ プログラミング入門（湯田幸八）』 図解や例題を多く取り入れ、入門者向けに分かりやすく解説している技術書です。 オブジェクト指向 を意識しない初歩的な解説から、 オブジェクト指向 の概念を導入した本格的なプログラミングを解説しています。 発表者からは、 発表者厳選ポイント！ ・VisualStudioの VC++ を使い、簡単に実行環境の構築ができる ・Cで構造プログラミング、 C++ で オブジェクト指向 プログラミング ・ステップアップしながら学習できる1冊 とのコメントをいただきました！ 『 ドメイン 駆動設計入門』 ドメイン 駆動設計をやさしく学べる入門書です。 まず、 こんな方におすすめ！ ・『エリック・ エヴァ ンスの ドメイン 駆動設計』や『実践 ドメイン 駆動設計』をこれから読もうとしている方 ・少しやさしい入門書を読みたいと感じている方 発表者厳選ポイント！ ・現場で働くエンジニアが理解しやすい ・実践的なDDD解説本 ・貴重な C# での解説本 Web版もあるとのことですので、まずは試し読み からし てみませんか？ 『実践 SQL 教科書』 データベース言語 SQL の基礎・歴史を解説している書籍。 また、 SQL に纏わる内容をわかりやすく解説しています。 発表者厳選ポイント！ ・古い本だが時代を超えた説得力がある本 ・ SQL の仕組みを丁寧に解説 と、発表者からおすすめポイントをいただきました！ 『ソフトウェアデザイン 2021年3月号』 Software Design (ソフトウェアデザイン) とは、ITエンジニアの スキルアップ 総合情報誌です。 その2021年3月号の特集ページ「 Java でもう一度学びなおす オブジェクト指向 プログラミング」を紹介いただきました。 コメントは以下の通り。 発表者厳選ポイント！ ・全 プログラマー は読むべき特集 ・使っている言語、関数型は関係なく、必読書レベルの内容がここに！ ・まずは雑誌を買って読んで！ と、熱いコメントをいただきました。 記載の通り、皆さんまずは雑誌を買ってみましょう！ ◆ 『 C++ プログラミング入門』・『 ドメイン 駆動設計入門』・『実践 SQL 教科書』・『ソフトウェアデザイン』 　の発表資料 speakerdeck.com 『独習C 新版』 独習Ｃの完全新作。 早速発表者からのコメントです。 こんな方におすすめ！ ・独学で C言語 について学びたい方 ・学生や社会人1年目の方 発表者厳選ポイント！ ・古くからある定番書籍 ・体系化された章立て ・「やりたいことを探せる」 ・ 言語の仕様が載っている ・ 手元に一冊あると安心感がある 『 PHP の絵本 第2版 Webアプリ作りが楽しくなる新しい9つの扉』 Web開発言語 PHP の解説書『 PHP の絵本』は、プログラム経験のない人でも勉強が始められるように考えられた、とてもやさしい入門書です。 こんな方におすすめ！ ・ PHP を学びたい方 ・Web開発を始めてみたい方 発表者厳選ポイント！ ・手順を追って言語の気を学べる ・基本的に「やさしい」本 ・XAMPPの説明がある 弊社イベントではお馴染の白柳さんおすすめの2冊です！ Youtube でほぼ毎日（平日のみ）世間のニュースを、エンジニアとしての経験・視点で解説しているそうなのでご興味ありましたら是非ご確認ください。 エンジニアカウンセラーが教える合わないカウンセリングを避けるコツ - YouTube ◆ 『独習C 新版』・『 PHP の絵本 第2版』の発表資料 speakerdeck.com 『コンピュータシステムの理論と実装』 次は、技術書でお馴染みO'REILLY社が出している書籍です。 本書では、コンピュータの構成要素であるハードウェア、ソフトウェア、 コンパイラ 、OSをひとつずつ組み立てることでコンピュータ アーキテクチャ の概要を理解できます。 早速、発表者からのコメントを見てましょう。 こんな方におすすめ！ ・初心者（駆け出し）から中級車にステップアップしたい方 ・これから コンピュータサイエンス を勉強したい方 ・優れた開発者になりたい方 発表者厳選ポイント！ ・コンピュータ アーキテクチャ の全体概要を理解できる ・各章に実装演習があるため、初心者でも脱落しにくい ・アプリケーション開発者がコンピュータ アーキテクチャ を学びやすい構成となっている 　① ボトムアップ と トップダウン を組み合わせた学び方ができる 　②ハードウェアは基礎からの ボトムアップ 、ソフトウェアは トップダウン で学習できる より詳細を知りたい方は、以下の発表資料をご確認ください。 ◆ 『コンピュータシステムの理論と実装』の発表資料 speakerdeck.com 『初めての PHP 』 動的なWebサイトを構築するための PHP プログラミングの基本を解説しています。 また、サンプルコードや演習問題もついているのが特徴です。 発表者からのコメントは以下の通り。 こんな方におすすめ！ ・実務が不安な新人エンジニア ・新人に何を教えれば良いか不安な教育担当社員 発表者厳選ポイント！ ・配列の解説が丁寧 ・ファイル処理を解説 ・クッキー、セッションの解説が充実 ◆ 『初めての PHP 』の発表資料 speakerdeck.com どんどんいきます。 『Vue.js3超入門』 フロントエンジニアにとってはお馴染のMVVMと呼ばれる設計パターンを採用している フレームワーク 、「Vue.js」について書かれています。 また本書を読むことで、簡単なWebアプリの開発ができるようになる優れた書籍です。 こんな方におすすめ！ ・初心者の方 ・既存の入門書に挫折した方 発表者厳選ポイント！ ・プロジェクト作成の段階から解説が丁寧 ・サンプルコードを都度、全行見せてくれる ・ コンポーネント 作成の従来式と新式(Composition API )について、どう付き合うべきか解説がある ・一緒に利用するライブラリ(Vue-Router、Vuex）の解説がある 発表を聞いていた方からも「コードを都度見せてくれるのは嬉しい！」や「過去にお世話になりました」とのコメントも飛び交いました。 ◆ 『Vue.js3超入門』の発表資料 speakerdeck.com 『 リファクタリング (第2版)』 ソフトウェア開発の名著、第2版となります。 約20年前のオリジナル原稿の構成は変わらないものの、現代的にアレンジされている書籍です。 こんな方におすすめ！ ・ リファクタリング の基礎を学びたい方 ・ リファクタリング を行っているエンジニア 発表者厳選ポイント！ ・関数 命名 のセオリーが学べる ・イマイチなコードに気づくための知識がつく ・良いコードを書くための知識がつく こちらは弊社エンジニア2名がおすすめしている書籍です。 リファクタリング に悩まれている方は、是非ご参考いただけますと幸いです。 ◆ 『 リファクタリング (第2版)』の発表資料 speakerdeck.com speakerdeck.com 『「実践 ドメイン 駆動設計」から学ぶDDDの実装入門』 普段の開発においてDDDで実装を始める方法を、分かりやすく解説している書籍。 電子書籍 とWeb版もあるとのことです。 こんな方におすすめ！ ・ ドメイン 駆動開発を学びたい方 ・輪読会を社内でされたい方 発表者厳選ポイント！ ・1章、10分～20分で一読できる ・1時間ほどで資料にまとめられる 発表者の方は本書を使い、輪読会を行ったところ ドメイン マスターの悩みが聞けて良い取り組みとなったそうです。 おすすめポイントにもあります通り、輪読会向けの書籍となりますので是非お試しください！ ※本発表の発表資料はありません。 『 テスト駆動開発 』 テスト駆動開発 (TDD)の実践方法を解説した書籍。 ユニットテスト と リファクタリング を何回も繰り返してプロダクトを成長させていく開発手法の1つである テスト駆動開発 の実例を通して、学ぶことができます。 発表者からのコメントは以下の通りです。 こんな方におすすめ！ ・ テスト駆動開発 未経験の人 ・ビギナーの開発エンジニア 発表者厳選ポイント！ ・テストコードを書くメリットが分かる ・ デザインパターン を学べる ・コツコツとコードを良くする過程を学べる ・汚いコードから洗練されたコードへ書き換えるノウハウがある ・章が短いため、少しずつ進めていける ・ ソースコード を少しずつ書いていくので間違いにくい ・優れたエンジニアの振る舞い、思考を学べる おすすめポイントが盛り沢山ですね。 発表者は、本書を読んだ後「テストコードがあると安心なんだ」と実感したそうです。 テスト駆動開発 に対する認識を変えてくれる良本、読みましょう！ ◆ 『 テスト駆動開発 』の発表資料 speakerdeck.com 『ふつうの Linux プログラミング 第2版』 Linux プログラミングの入門書。 本書は、「 Linux 世界が何によってできているのか」を教えることを目標にしているのこと。 おすすめポイントは以下の通りです。 こんな方におすすめ！ ・ Linux 触ったけどよくわからない人 ・現場で何となく Linux 触っている人 発表者厳選ポイント！ ・ Linux を構成する三大概念を学べる 　①プロセス 　② ファイルシステム 　③ストリーム ・コマンドを自作しながら概念の理解を深める ・学んだ内容と自身の経験が繋げやすくなる 　→三大概念とそれを裏付ける演習があり、丁寧な構造となっているため 発表内容からも伝わる熱いコメント…！ Linux を触っている方でピンっときた方は是非ご一読を！ ◆ 『ふつうの Linux プログラミング 第2版』の発表資料 speakerdeck.com 『エキスパート Python プログラミング 改訂3版』 ここからは、 いろんなレイヤーを学習ための書籍を7冊一気にご紹介します。 まずは、 Python プログラマ になるためには必読の書籍！ 最新の Python 環境に合わせて改訂され、更に読みやすくなりました。 発表者厳選ポイント！ ・15章と16章が並列/並行処理の内容 　- マルチプロセル/マルチスレッド 　- イベント駆動プログラミング ・実装例がバッチリ載っているので学習に最適 ・2021年7月に出版されたので情報鮮度が高い PDFが欲しい方は 達人出版会 にてご購入ください！ 『Go言語による並行処理』 昨今、サーバーサイドでのプログラミングやコンテナツールの実装言語など、多種多様な分野で活用されているGo言語。 発表者厳選ポイント！ ・GOの並行処理に対するアプローチがわかる ・並行処理のパターンもまとめられている ・第1章、第2章の理論も良い！ ・訳注が豊富 PDFや EPUB 版は、 O'REILLY でお得に買えるそうです！ 『 Linux による並行プログラミング入門』 続いておすすめするのが、『 Linux による並行プログラミング入門』です。 Linux をベースとしたOSの概念を解説し,演習によって並行プログラミングの感覚を体得することを目標しているとのこと。 発表者厳選ポイント！ ・章ごとのボリュームが小さいので進めやすい ・第1章から並行処理が体験できる 　- プロセスのfork システムコール ・ システムプロ グラミング的要素もある ・ C言語 のライブラリpthreadを利用した並行プログラミングを体験できる 悩むなら購入し、読みましょう！ 『Goならわかる システムプロ グラミング』 低レイヤであるOSの世界をGo言語を使って解説している書籍です。 様々なライブラリを利用しているコンピュータシステムの基本的概念や、アプリケーション開発者の視点で低レイヤの仕組み内容となっております！ 発表者厳選ポイント！ ・ システムプロ グラミングをGo視点で理解する ・ C言語 じゃなてもわかるが、 C言語 もやりたくなる ・プログラミングを支えるている下位のレイヤーを プログラマー 視点で学べる Lambda Note なら、紙本とPDFがセットでお得とのことです！ 『 Linux システムプロ グラミング』 本書は、 プログラマ の観点から実践的なトピック（Lnuxの概要、 カーネル 、Cライブラリ、ファイルI/Oなど）が多く含まれている1冊です。 発表者厳選ポイント！ ・サンプルコードは多くはない ・辞書的に持っておくと何かと便利！ ・ 英語版 は2nd Edtionがある 『CPUの気持ちが知りたいですか？』 タイトルがキャッチーでつい読みたくなる書籍です。 本書では、CPUの気持ちを知るために押さえておくべき技術を解説しています。 発表者厳選ポイント！ ・カジュアルな語り口でCPUの説明をしてくれる ・ アセンブリ の解説があるのも嬉しい ・背景や歴史的な話もあるのがGreat ・ページ量がコンパクトなのも魅力 「第3回 刺され！技術書アワード大賞」を受賞した書籍だそうです。 Amazon には売っていない商品となります。 ご購入は BOOTH からどうぞ！ 『n月刊ラムダノート Vol.3, No.1(2021)』 計算機好きのための技術解説情報誌が「n月刊ラムダノート」。 発表者が厳選したのは、Vol.3になります！ 発表者厳選ポイント！ ・3章がCPUの話 ・CPUの動作原理だけでなく、いかにして効率良くするかが丁寧に解説されている ・ システムプロ グラミングを学ぶ上でも有用 こちらも Amazon で購入できない商品となりますので、ご興味ある方は Lambda Note よりお願いいたします！ ◆ 『エキスパート Python プログラミング』・『Go言語による並行処理』 　・『 Linux による並行プログラミング入門』・『Goならわかる システムプロ グラミング』 　・『 Linux システムプロ グラミング』・『CPUの気持ちが知りたいですか？』 　・『n月刊ラムダノート Vol.3, No.1(2021)』の発表資料 docs.google.com 『Webを支える技術』 Webサービス の実践的な設計をテーマにした書籍です。 RESTとRESTfulの違いやWebAPI設計において重要なことなどを整理できる良本となっております！ こんな方におすすめ！ ・ Webサービス の開発に関わる方で、実業務に取り組んで数か月～1年など比較的経験の浅い方 ・新規 Webサービス の開発に携わる方 ・WebAPIを新規に作成する方 発表者厳選ポイント！ ・普遍的なWeb構造、設計思想（HTTP、 URI 、HTML、Restなど）が分かりやすい言葉で説明されている 　- 普段何となく使っているWebの言葉や知識の基礎を学べる 　- 技術者は日々新しいことを学ぶ必要があり、知識のアップデートも非常に多い、本書の知識は長持ちする ・ Webサービス 開発の設計に役立つ 　- 例） URI 名どうしよう？、WebAPIのWebらしい良い設計って？ Webサービス の開発に携わる方は、早めに読むことをおすすめします！ ◆ 『Webを支える技術』の発表資料 speakerdeck.com 『フロントエンド開発入門: プロフェッショナルな開発ツールと設計・実装』 Web開発で必須となるフロントエンド技術ですが、年々アップデートされていく新しい要素や属性などを拾い、自身の知識もアップデートする必要があります。 本書では、初心者向けにフロントエンド開発を行う上で便利なツールの選び方や、その使いこなし方を身に着けるノウハウを集約しております！ 発表者厳選ポイント！ ・ツールを紹介する時に必ず「そのツールが解決してくれること」のセクションが設けられている ・歴史、周辺環境、コミュニケーション、情報キャッチアップ、フロントエンドエンジニアとしての姿勢など、幅広く触れている ・「最近のフロントエンド開発はどんな感じですか？」という質問に、ツール技術に留まらず答えてくれる 支援ツールを有効的に使いこなし、効率的に実装するためにも本書は一度読むべきだと思いました！ ◆ 『フロントエンド開発入門: プロフェッショナルな開発ツールと設計・実装』の発表資料 speakerdeck.com 『プリンシプル オブ プログラミング』 日本語訳だと「プログラミングの原理」となる書籍。 よいコードを書く上で指針となる前提・原則・思想を解説しています。 こんな方におすすめ！ ・学習を始めたばかりの初心者の方 ・知識の再確認をされたい中堅以上の方 発表者厳選ポイント！ ・網羅性が高い！ 　- 一般的な原理・原則はほとんど網羅されている 　- 見出しが細かく、辞書的に使える ・書籍の紹介が豊富 　- セクションごとに最低2,3冊紹介されている 　- 例）エリック・ エヴァ ンスの ドメイン 駆動設計、達人 プログラマー など 注意点！ ・「この1冊あれば完璧！」とはならない 　- 網羅性が高い＝1つ1つは深堀りしていない 　- コード例が出ていない 厳選したポイントもあれば、注意点も紹介いただきました。 この点を踏まえ、購入するか否かをご検討いただけますと幸いです！ ◆ 『プリンシプル オブ プログラミング』の発表資料 speakerdeck.com 『 CSS 設計完全ガイド』 悩みが尽きないCCS設計を丁寧に解説している書籍です。 様々な設計手法や考え方、実践する上でのポイントだけでなく実践的なコードも紹介しています！ こんな方におすすめ！ ・ CSS 設計本で挫折した方 ・ CSS 初心者の方 ・コーダー教育する方 発表者厳選ポイント！ ・ CSS 設計について理解を深めることができる 　- OOCSS、SMACSS、BEM 　- モジュール（ボタン、ラベル、見出しなど） 　- レイアウト（ヘッダー、フッターなど） ・社内の輪読会に適している 　- 意見の共有を行うことで、より理解を深めることができる 　- 過去の課題を参考に具体的な解決方法を見つけることができる CSS 設計に悩まれるフロントエンドエンジニアや Webデザイナー は、是非ご一読ください！ ◆ 『 CSS 設計完全ガイド』の発表資料 speakerdeck.com 応用シリーズ 『体系的に学ぶ安全なWebアプリケーションの作り方』 Webアプリケーションを開発する上で必要なセキュリティに関する基礎知識や、代表的なセキュリティ対策の知識を学習できる書籍です！ こんな方におすすめ！ ・これからWebセキュリティを学ぼうと考えている方 ・Webアプリケーションの基礎的な開発技術を学びたい方 ・改めて 脆弱性 について復習したいと考えている方 発表者厳選ポイント！ ・具体的な 脆弱性 への攻撃の例と対策があるため、理解しやすい！ ・約650Pと量が多いですが、基本的なWebアプリケーション開発の実務に必要なセキュリティ知識が学習できる！ これからWebアプリケーション開発の実務に携われる方、セキュリティ意識を高めたい方は是非！ ◆ 『体系的に学ぶ安全なWebアプリケーションの作り方』の発表資料 speakerdeck.com 『デザイニング Webアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチ』 Webコンテンツを作るうえで必要な アクセシビリティ について、要件定義～実装でつまづく疑問や解決手段を解説している書籍です。 発表者厳選ポイント！ ・ アクセシビリティ と ユーザビリティ の違いが分かる ・ Webアクセシビリティ の今を海外と日本を比べて説明している ・ Webアクセシビリティ を取り組む前の心構えが分かる ・意識を変える初めの一歩となる書籍！ 928ページとまぁまぁの量ではありますが、デザイナー以外にも読んでもらいたい、良本となっています！ ◆ 『デザイニング Webアクセシビリティ 』の発表資料 speakerdeck.com 『インターフェースデザインの心理学』 本書は、人間の思考や行動、遊び方にマッチした直感的で人を引き付けるプロダクトをデザインするための必読書です！ 発表者厳選ポイント！ ・人間の行動原理を100個にまとめたTips集 ・読んだ上で重要となるポイントは以下の通り 　① 人はどう考えるか 　② 間違えない人はいない 　③ 人はどう決断するのか 相手から無意識の反応を誘い出すための大事な要素であるデザインについて、再度学びなおしてみませんか？ ◆ 『インターフェースデザインの心理学』の発表資料 speakerdeck.com 『なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー』 間違ったレビューをされていませんか？ 本書は、誰にでもできる効果的なレビューの手順や、成果が上がらないれby－の共通点を解説しています！ 発表者厳選ポイント！ ・陥りやすいミスが学べる ・ アンチパターン が学べる ・設計レビューの本質が学べる ・心構えが学べる ・設計レビューのノウハウが学べる 　1. 優先度をつける 　2. 1種類の検出に集中する 　3. 時間を決める 　4. 幻のレビューアー 　5. 「あえての見逃し」をしない 　6. 段取りと仕切りを大切に 　7. テクニカルレビューとウォークスルー 発表者から最後に、「良い設計レビューにするために協力が大事」というコメントがありました。 昨日より今日、今日より明日のレビューをより良いものにするために、本書の購読をおすすめします！ ◆ 『なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー』の発表資料 speakerdeck.com 『 OSS -DB Silver Ver.2.0対応』 OSS -DB Silverは、LPI-Japanが主催するデータベース資格の1つです。 PostgreSQL の使い方に重きが置かれているので、実務にも直結する内容となっています！ こんな方におすすめ！ ・データベース（ SQL ）の基本を学べる ・資格を取りたい方 ・資格を取られない方も是非！ 発表者厳選ポイント！ ・ PostgreSQL の基本仕様が網羅されており、業務の流れを知ることができる ・重要な部分がまとまっているので、本書で大枠を知り、公式ドキュメントで詳細を学ぶという学習方法がおすすめ 資格勉強で培った知識を業務で活かせるのは、とても効率が良い勉強法だと思いました。 Silverに合格された方は、ワンランク上のGoldにもチャレンジされてみてはいかがでしょうか？ ◆ 『 OSS -DB Silver Ver.2.0対応』の発表資料 speakerdeck.com 『 SQL アンチパターン 』 本書は、DB設計や SQL 記述の避けるべき事柄を25個紹介している書籍です。 気になる章だけ読み返すのに便利な構成となっております！ こんな方におすすめ！ ・DBや SQL に関わる方 発表者厳選ポイント！ ・先人たちの失敗から学ぶことができる！ ・本の構成が分かりやすい 　- 以下のような構成で「 アンチパターン 」を紹介している 　　1.目的 　　2. アンチパターン 　　3. アンチパターン の見つけ方 　　4. アンチパターン を用いても良い例外 　　5.解決策 本書を読むことで、常に アンチパターン に陥っていないかを考えるこができ、より品質の良い SQL を実装することができるようになるとのことです。 是非ご参考ください！ ◆ 『 SQL アンチパターン 』の発表資料 SQLで陥りがちなアンチパターンを知ろう「SQLアンチパターン」 from Tomotaka Suzuki(御成門プログラマー) www.slideshare.net 『Joel on Software』 システム開発 にまつわるTipsが45個集約された書籍です。 元ネタは著者であるJoelさんのブログだとか。 発表者厳選ポイント！ ・1冊で45個ものTipsを学べる ・以下のような面白いTipsが盛り沢山！ 　① 射撃しつつ前進 　② ビックマック 対 裸のシェフ 　③ 下っ端でも何かを成し遂げる方法 　④ Microsoft はいかにして API 戦争に負けたのか　　などなど 上記のタイトルをみるだけでも面白そうなTipsが多いです。 1,000円ちょっとの書籍で45個のTipsが学べる…もう、買うしかないですね！ ◆ 『joel on software』の発表資料 speakerdeck.com 『文芸的プログラミング』 「プログラミングは、芸術であり、文学である」と言っている書籍。 今だからこそ読んで欲しいとっておきの1冊です！ 発表者厳選ポイント！ ・ドナルド・E. クヌース の論文集 ・誰にとっての「分かりやすさ」なのかを考えるきっかけとなる ・アートとサイエンスは一見相反するような立場に見えるが、コンピュータプログラミングにとって大切であることが分かる 本書は、とても深い内容となってますが、「分かりやすさ」を考える良いきっかけになると思います！ ◆ 『文芸的プログラミング』の発表資料 speakerdeck.com 『 機械学習 を解釈する技術』 予測精度は高いものの、モデルの解釈性が低いという欠点がある 機械学習 モデル。 どのような予測を行っているかを探ろうとしても、 ブラックボックス モデルとなっているため解読は困難です。 本書では、上記の予測精度と解釈性の トレードオフ を克服する手法を厳選し紹介しています！ 発表者厳選ポイント！ ・ 機械学習 モデルを説明できるようになる ・有用な解釈性が分かる ・ ブラックボックス モデルに解釈性を与える手法が紹介されている 注意点！ ・以下については本書に書かれていないので注意が必要 　- PFI 、PD、ICE、SHAP以外の機会学習の手法 　- 画像認識や 自然言語処理 　- 統計学 や 機械学習 の理論面 　- 予測精度を向上させるためのテクニック 　- 因果推論 個人的には予測精度を向上させるためのテクニックを知りたいと思いましたが、本書には書かれていないようです。 注意点を確認いただいた上で、購入を検討ください！ ◆ 『 機械学習 を解釈する技術』の発表資料 t.co 『 プログラマ の数学』 プログラミングをする上で必要となる「数学的な考え方」を身につけることができる1冊です。 こんな方におすすめ！ ・プログラミング初心者の方 ・数学が苦手な方 ・ 機械学習 を学び始めた方 発表者厳選ポイント！ ・数式はほとんど出てこないので、数学アレルギーの人でも読めるはず ・付録の「読書案内」がとても良い 数学が苦手な方でも読みやすいというのは、とても興味が湧きます。 機械学習 を学び始めたいけど、数学が苦手…という方は是非是非ご参考ください！ 『GPT-3 完全初心者への徹底解説: 最強の文章生成AIの実像』 GPT-3は、文章を自動生成できる 人工知能 のことを言います。 そのGPTについて解説しているのが本書です。 発表者厳選ポイント！ ・易しすぎず詳しすぎず、ちょうどよい温度感 ・今世間を賑わせているGPTという技術について一気にキャッチアップできる ・実例が載っているのも良い！ お恥ずかしながらGPTという言葉を初めて聞きましたが、そんな私でも読んでみたいと思える一冊でした。 丁度良い温度感、惹かれます！ 『進化的 アーキテクチャ 』 本書は、 アーキテクチャ を「進化的 アーキテクチャ 」と名付け、その構築に必要な考え方や技術、実践方法などについて解説しています。 発表者厳選ポイント！ ・構築したシステムをどうやって「成長」させていくかが学べる ・「継続的」ではなく「進化的」 アーキテクチャ が学べる ・サービス運用をしているエンジニアは必読かも？ ・ アンチパターン が掲載されているも良い 是非サービス運用をされているエンジニアの皆様、ご参考ください！ 『計算できるもの、計算できないもの』 本書では、 アラン・チューリング とリチャード・ カープ の論文を基に計算理論を学べます。 こんな方におすすめ！ ・ コンピュータサイエンス を学びたいエンジニアの方 発表者厳選ポイント！ ・既存のシステム、ツールなどで計算理論は広く使われていることが分かる ・ コンピュータサイエンス 、計算理論の知識が学べる 昨今、 コンピュータサイエンス を学ばれている方は多いのではないのでしょうか？ 少しでも興味持たれましたら、是非ご一読ください！ ◆ 『 プログラマ の数学』・『GPT-3 完全初心者への徹底解説: 最強の文章生成AIの実像』・ 　『進化的 アーキテクチャ 』・『計算できるもの、計算できないもの』の発表資料 t.co 『 エクストリームプログラミング 』と『組織パターン』 本を読むことで仕事に活かしていますか？ と、始まった発表。 今回は、「ケント ベック」と 「ジム・コピリエン」が執筆した書籍を読み比べながら、ソフトウェア開発の論点を探っていきます。 　 発表者厳選ポイント！ ・書籍を読み比べるのにおすすめ ・現代のソフトウェア開発の重要な開拓者である2人の考えが強く異なっていることが分かる 　①コードの所有権 　　ケント ベック　　：あらゆる部分をいつでも改善できる 　　ジム・コピリエン ：修正するのはその所有者だけにする 　②テスト 　　ケント ベック　　：プログラムを変更するたび 　　ジム・コピリエン ： ユースケース が変わった部分だけ ◆ 『 エクストリームプログラミング 』・『組織パターン』の発表資料 speakerdeck.com 『 UNIX A History and a Memoir』 Kindle Unlimitedで無料で読める書籍です。 英語の書籍となりますので、英語学習とともにいかがでしょうか？ 発表者厳選ポイント！ ・ Unix の歴史が書かれている ・ ブライアン・カー ニハンや ベル研究所 の雰囲気がつかめる ・The Soul of a New Machineもおすすめ ※本発表の発表資料はありません。 終わりに エンジニアとデザイナーが厳選した技術書はいかがでしたでしょうか？ 今回、40冊もの技術書を紹介させていただきましたが、技術書の相性や好みはその方によって異なります。 40冊の内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

はじめに こんにちは！楽楽精算開発チームのnkumaです。 今回は 「初心者」におすすめのカンファレンスの聴講の仕方 をご紹介いたします。 はじめに 初心者なりのマインド カンファレンスへのハードル 「分からないことを恥じない」 初心者なりの方法 知らない単語を回収する ■メリット①：昨今の流れが分かる ■メリット②：知識が蓄えられる ■メリット③：知らない分野でもとっつきやすい 注意点 単語をメモするときの工夫 1. 自分のPCにマークを「単語の追加」する。 2.カンファレンスに参加し、マークをつけつつ分からない単語をメモする 3.聴講終了後、ctrl + fでマークを検索して単語を振り返りつつ、調べる。 まとめ 初心者なりのマインド カンファレンスへのハードル カンファレンスに参加しようとする初心者の不安あるあるとして、 「何を言っているかさっぱり」 初心者がカンファレンスについていくのは多くの場合困難です。 それ故、尻込みしてしまいます。 しかし、ついていけないなりの聴講の仕方があります。 ついていけないから参加してはいけないということはありません！ その方法については、下記にてご紹介いたします。 「分からないなら時間の無駄ではないのか」 参加しても分からないなら、その時間で勉強した方がよいのでは？という意見は大いにあります。 しかし、自分一人だと見えない分野があります。 知見を広げるためにはカンファレンスが有用です。 下記の方法なら、前提知識がなくとも知見を広げることができます。 「何のために参加するのか？」 個々人で様々な理由がありますが、初心者にとっては２つの大きな理由が考えられます。 初心者でも、初心者だからこそ参加した方が良いといえます。 モチベーション 自分以上に頑張っているひとがいることを知り、また、その世界の深さを垣間見ることで、モチベーションが上がります。 知見を広げる 一人で学習しているだけでは見えない分野を知ることができます。 「分からないことを恥じない」 初心者がカンファレンスに参加しない根底には「理解できないだろう」という考えがあると予想できます。 しかし、私は 理解できなければそれでいいじゃないか 、と思います。 「最初は分からない」というのは誰しもあることで自明の理です。 分からないことは当たり前と考えましょう。 分からないなりに参加するというのが大事です。 分からないから参加しない、は勿体ない！まずは参加してみましょう！ 初心者なりの方法 しかし、せっかく参加するなら少しでも多く成長したいと思うものです。 では何をすればいいのでしょうか？ 知らない単語を回収する これに尽きます。 知らない単語を聞いたら確実にメモをして、後で調べましょう。 スライドにある単語だけではなく、話者の話す言葉にも注意しましょう！ むしろ、初心者にとっては書くまでもない当たり前の単語こそ知りたいことだったりします。 当然のことかもしれませんが、意識しなければ内容理解に重きを置いて、おろそかにしがちなところです。 もちろん初めて聞く単語だけという縛りはないです。 １度聞いただけで定着することは中々ありません。 「分からないことを恥じず」に、同じ言葉だとしてもピンと来なければ、繰り返しメモしていきましょう。 以下は「知らない単語を回収する」ことのメリットと注意点です。 ■メリット①：昨今の流れが分かる キーワードを回収するだけでも今のトレンドは分かるものです。 「この単語はよく聞くから覚えたよ」というのがあるかもしれません。 そうしたら、それが現在のトレンドです。 知らない単語を回収することを意識してIT業界の流れを掴みましょう！ ■メリット②：知識が蓄えられる IT業界では一見、想像もつかないような専門用語が数多くあります。 単語が分からなければ、内容を推測しても前提が違うかもしれません。 1つ知らない単語を知れば、以前よりも少しだけ話を理解することができ、分からないことがまた増えます。 それを繰り返すことで知識が蓄えられていくことでしょう。 ■メリット③：知らない分野でもとっつきやすい 知らない分野の話を初っ端から理解するというのは苦戦するものです。 心が折れる かもしれません。 特にIT業界に慣れていない初心者なら尚更です。 いっそのこと話を理解することを放棄しましょう！ 単語だけに注目して、分からない単語を確実にメモします。 知らない単語を回収するだけなら知らない分野でもとっつきやすいでしょう。 注意点 正直なことを言うと、上記の方法では 表面的な理解しかできません。 しかしながら、何事も表面から少しずつ知ることで、気づいたら深く理解していたということは皆さんも経験があると思います。 最初の一歩として「単語を回収する」ということを意識してみてください。 単語をメモするときの工夫 分からない単語をメモする際に、私がしている工夫を紹介いたします。 これまた当たり前のことかもしれませんが、「あとで振り返りやすいようにマークをつける」ことです。 検索しやすいよう普段使わないようなマークにしましょう。（例：🏁[ハタ]） しかし、メモする際に毎回「はた」と打って変換していたら、面倒ですし、次の単語聞き逃すかもしれないし、マークを変換ミスして後で検索できないかもしれません。 また、初心者ならあとでマークを検索する方法も分からないかもしれません。 そのための工夫があります！ 具体的な手順としては以下の通りです。 自分のPCにマークを「単語の追加」する。 カンファレンスに参加し、マークをつけつつ分からない単語をメモする 聴講終了後、 ctrl + f でマークを検索して単語を振り返りつつ、調べる。 1. 自分のPCにマークを「単語の追加」する。 1-1.タスクバーの IME で右クリック（画面右下に常にある「A」または「あ」と表示されている箇所） 1-2.メニューから「単語の追加」を選択 1-3.以下の該当箇所を記入し、登録をクリック ・単語：使いたいマークを記入（例：🚩） ・よみ：変換元の文字を記入（例：ｔ） ・※ユーザーコメント：変換の一覧に補足説明として見えるもの（分からない単語のマークとしてもいいかも） ・品詞：短縮よみを選択 以上のようにすれば、どこでもマークのショートカットができるようになっています！ *1 (上記の例では、ｔで変換するとすぐに🚩となる) 2.カンファレンスに参加し、マークをつけつつ分からない単語をメモする エディタは何を使ってもＯＫです。 とにかくカンファレンスに参加して、分からない単語にマークをつけながらメモしましょう。 文中の単語でも、単語単体でも関係なくマークをつけてください。 単語だけでなく文章でも、あとで調べたいことにはマークをするのが良いです。 3.聴講終了後、 ctrl + f でマークを検索して単語を振り返りつつ、調べる。 メモしたエディタで、マークを検索して振り返りましょう！ メモしたことに満足して、放置しないよう注意です！ エディタを開き、文章にカーソルしてから ctrl + f を押すと検索することができます。 これでマークを検索して効率よく振り返ることができます。 まとめ 前述の内容を意識し、繰り返し参加することによって段々とカンファレンスについていけるようになります。 私は学生時代から「単語を回収すること」を意識して参加していますが、少しずつ分かるようなっていることを実感しています。（それでもまだまだで、精進の日々ですが…） 初心者なりのマインド「分からないことを恥じない」と方法「単語を回収する」ことでカンファレンスに参加しましょう！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 他の使い方も可能です。「大事なところには★をつける」など、自分なりの工夫を考えてみてください！

技術広報の yayawowo です。 エンジニアの皆さん、プログラミングの勉強は捗っていますか？ 効率的な学習ができていますか？ 本記事では、昨今盛り上がり続けている YouTube 市場で、 プログラミング学習をメインで配信している国内・国外のチャンネルをご紹介します。 動画を見ながらコーディング学習もできるので、一石二鳥？いや、三鳥なレベルで効率的な学習ができますよ。 また、 YouTube の高度な検索方法にも触れていますので是非最後までお読みいただけますと幸いです！ では、スタート！ 国内チャンネル プログラミング全般を学習するなら？ たにぐち まことのともすたチャンネル フロントエンドを学習するなら？ しまぶーのIT大学 【とらゼミ】トラハックのエンジニア学習講座 バックエンドを学習するなら？ キノコード / プログラミング学習チャンネル プログラミングアカデミー 渋谷で働くエンジニア福の「実践で学ぶプログラミング入門」 コンピュータサイエンスの基礎を学習するなら？ 早稲田大学 早水桃子研究室 海外チャンネル 英語が苦手な方へ freeCodeCamp.org CS Dojo Derek Banas 当社ラクスのチャンネル YouTubeの高度な検索方法 検索演算子を使う方法 OR検索 除外検索 タイトル検索 ハッシュタグ検索 まとめ 国内チャンネル 国内外問わず YouTube 上には、数多くあるプログラミング学習を配信しているチャンネルがあります。 まずは、国内の YouTube チャンネルを厳選しました！ ・キノコード / プログラミング学習チャンネル ・ しまぶー のIT大学 ・たにぐち まことのともすたチャンネル ・ 早稲田大学 早水桃子研究室 ・プログラミングアカデミー ・【とらゼミ】トラハックのエンジニア学習講座 ・渋谷で働くエンジニア福の「実践で学ぶプログラミング入門」 上記は、2021/9/3時点でのチャンネル登録が多い順で並べております。 ではチャンネルの詳細を見ていきましょう。 プログラミング全般を学習するなら？ まずは、エンジニアや プログラマー になるために見ておくと良い おすすめのチャンネル をご紹介！ たにぐち まことのともすたチャンネル youtu.be まずおすすめしたいのが、チャンネル登録者数3.98万の 『たにぐち まことのともすたチャンネル』 です。 ※チャンネル登録者数は、2021/9/3時点の情報です。 おすすめポイントは以下の通り。 ◆本チャンネルのおすすめポイント ・プログラミングの基礎/入門を学べる ・コーディングしながら学べる ・開発環境の設定方法も学べる 以下の動画視聴数ランキングを見てわかる通り、 Visual Studio Code やBootstrap、 WordPress など様々な分野を学べることが分かります。 順位 タイトル 視聴数 1 Visual Studio Code入門 #01：環境設定と、VSCodeの起動方法いろいろ - YouTube 25万回 2 Bootstrap 4入門 #01：コンテナとスペーシング - YouTube 10万回 3 WordPress開発講座 #01：WordPressの開発環境と最小テーマをつくろう - YouTube 7.6万回 4 Vue.js入門 #01： 一番最初のプログラム - YouTube 7万回 5 AWS EC2入門 #01： AWSを始めよう - YouTube 5.9万回 ※視聴数は、2021/9/3時点の情報です。 プログラミングを始めたばかりの方にとっては、とても参考になる動画だと思いました。 他にも、 オブジェクト指向 の簡単な解説やLaravel、Reactの内容もありましたので是非ご確認ください！ フロントエンドを学習するなら？ 続いて、フロントエンド技術を学習するのにあたり見ておきたい おすすめのチャンネル3選 をご紹介！ しまぶー のIT大学 youtu.be 現時点でのチャンネル登録者数は9.75万人ですが、年々人気を高めているのが『 しまぶー のIT大学 』です。 大手IT企業で プログラマー を経験後、起業。 自身の経験と知識をもとにIT関係の情報を発信しています。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・HTML、 CSS 、 JavaScript 、Webデザインの基礎を学べる ・コーディングしながら学べる ・短い時間（10分～30分ほど）で要点がまとめられている こちらのチャンネルも、人気の高い動画を以下にまとめました。 今回は、プログラミング学習に特化した動画のTOP5です！ 順位 タイトル 視聴数 1 【基礎から学ぶ JavaScript 入門 #1】フロントエンド開発でJavaScriptが必要な理由を解説！【ヤフー出身エンジニアが教える初心者向けプログラミング講座】 - YouTube 30万回 2 【HTML #1】基礎からちゃんと学ぶ HTML 入門！タグの要素を理解してコーディングしよう！【ヤフー出身エンジニアが教える初心者向けプログラミング講座】 - YouTube 21万回 3 【CSS #1】基礎からちゃんと学ぶ CSS 入門！基本構文を抑えよう！【ヤフー出身エンジニアが教える初心者向けプログラミング講座】 - YouTube 11万回 4 【基礎から学ぶ JavaScript 入門 #2】Twitterを例にJavaScriptがどんな働きをするのか理解しよう【ヤフー出身エンジニアが教える初心者向けプログラミング講座】 - YouTube 11万回 5 【HTML/CSSレイアウト】聖杯レイアウトのコーディング実践、デザイン解説【ヤフー出身エンジニアの初心者向けプログラミング講座】 - YouTube 11万回 ※視聴数は、2021/9/3時点の情報です。 独学でフロントエンド領域を学ばれる方は、書籍を読みながらコーディングされる方が多いのではないでしょうか？ 本チャネルの動画では、実際にコーディングをしている様子を見つつ学習することができますので学習意欲がとても高まります。 また、各動画コンテンツの時間が短いのにも関わらず、ポイントを押さえた解説をしているのもおすすめできる点だと思いました！ 【とらゼミ】トラハックのエンジニア学習講座 youtu.be フロントエンド技術の学習コンテンツを中心に配信しているのが、『 【とらゼミ】トラハックのエンジニア学習講座 』です。 配信者であるトラハックさんは、 ベンチャー企業 に勤めている現役フロントエンドエンジニア。 TypeScript, React, Next.js, Firebaseでの開発がメインとのことです。 配信を開始したのは2019年からで、チャンネル登録者数は1.23万人とこちらも年々数を増やしてきているチャンネルになります！ ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・フロントエンド開発の技術を学べる ・TypeScript、React、Next.js、Firebaseの基礎を学べる ・コーディングしながら学べる 視聴数が多い人気の動画を以下の通り並べてみましたが、React入門がほぼ占めていますね。 順位 タイトル 視聴数 1 日本一わかりやすいReact入門#1...Reactの基礎知識 - YouTube 4.3万回 2 日本一わかりやすいReact入門#4...コンポーネント間でデータの受け渡しと再利用をしよう - YouTube 2.4万回 3 日本一わかりやすいReact入門#3...create-react-appで環境構築しよう - YouTube 2.3万回 4 【ガジェット好き集合】現役エンジニアのデスク周り紹介 - YouTube 2.1万回 5 日本一わかりやすいReact入門#2...Reactに欠かせないJSXの解説 - YouTube 2万回 ※視聴数は、2021/9/3時点の情報です。 フロントエンドの3大 フレームワーク であるAngular、React、Vueの中でも、採用ニーズの高いのがReactと言われています。 駆け出しのフロントエンドエンジニアにとっては、とても有難いコンテンツ内容ではないのでしょうか。 私も時間を作って視聴してみようと思いました！ バックエンドを学習するなら？ どんどんいきます！ 次は、バックエンド技術を学習するのにあたり見ておきたい おすすめのチャンネル3選 です！ キノコード / プログラミング学習チャンネル youtu.be 「 YouTube プログラミング」 ググる と上位にもでてくるのが、『 キノコード / プログラミング学習チャンネル 』。 チャンネル登録者数は、今回ご紹介するチャンネルの中で一番多い12.5万人。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・ Python 、 Ruby 、 PHP 、 Java などの基礎を学べる ・特に Python を学びたい方におすすめ ・IT用語を学べる ・コーディングしながら学べる おすすめポイントにも記載しましたが、 Python を学びたい方にとっては嬉しい学習コンテンツが盛り沢山です。 視聴数TOP5を一通り見るだけでも Python の知識がつきそうです。 順位 タイトル 視聴数 1 Python超入門コース 合併版｜Pythonの超基本的な部分をたった1時間で学べます【プログラミング初心者向け入門講座】 - YouTube 101万回 2 Pythonで面倒なExcelの仕事を自動化しよう( 第一弾 )｜一瞬で仕事がおわるプログラミング活用術 - YouTube 56万回 3 Pythonで面倒な「ブラウザ操作」や「データ収集」の作業を自動化しよう｜Webスクレイピングの基本的な内容をわかりやすく解説｜PythonでWebスクレイピング第01回 - YouTube 27万回 4 Pythonの便利ライブラリ「Pandas入門講座」合併版｜Pandasの基本的なこと3時間で学べます【Python超入門コースの次におすすめの入門講座】 - YouTube 20万回 5 【Python超入門コース】03.環境構築 for Windows｜プログラミングをする準備をしよう！【プログラミング初心者向け入門講座】 - YouTube 13万回 ※視聴数は、2021/9/3時点の情報です。 Python は プログラミング言語 の中でも学びやすい言語の1つとされており、学生の方が多く学習されている印象が強いです。 また、昨今近年注目を集めている「Infrastructure as Code」という考え方でもインフラエンジニアが業務効率化という観点で物事をプログラム化（ツール化）する際に利用しています。 今後も、 Python の需要は高まり続けると思いますのでこの機会に本チャンネルで学習されてみてはいかがでしょうか。 プログラミングアカデミー youtu.be 次におすすめしたいのが、現役ITエンジニアが運営する 『プログラミングアカデミー』 。 チャンネル登録者数1.22万人で、こちらも今後期待のチャンネルです。 Webに関する様々なことを動画にして発信しています。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・Web アプリ開発 の入門を学べる ・ PHP 、 MySQL 、 JavaScript など基礎を学べる ・コーディングしながら学べる 視聴率が上位の動画は、2時間～4時間と超大作となるコンテンツではありますがとても分かりやすい内容となっています！ 特に配信者である、おさないさんがあげてくれる"例え"が分かりやすいです。 順位 タイトル 視聴数 1 【PHP入門決定版】4時間で学ぶ初心者向けPHPプログラミングチュートリアル【PHPの基礎を徹底的にマスター】 - YouTube 9.1万回 2 【MySQL入門決定版】2時間半で学ぶ初心者向けMySQLデータベースチュートリアル【MySQLの基本とSQLの基礎文法の徹底的にマスター】 - YouTube 2.9万回 3 PHPってそもそも何が出来るの？PHPとは？【PHPによるWebアプリケーション開発講座#1】 - YouTube 1.8万回 4 JSONについてわかりやすく説明します - YouTube 1.4万回 5 初心者こそ競技プログラミングで勉強することをオススメします【競プロ】 - YouTube 1.2万回 ※視聴数は、2021/9/3時点の情報です。 Webアプリを開発を勉強する際、結構詰まりがちな知識を本チャンネルの動画では丁寧に説明しております。 また、駆け出しエンジニアの方でWeb アプリ開発 をしてみたいという方は、是非視聴数1位、2位の動画を見て学ばれてはいかがでしょうか。 Web アプリ開発 の基本のきが、6時間半で学べる良いコンテンツだと思いますよ！ 渋谷で働くエンジニア福の「実践で学ぶプログラミング入門」 youtu.be バックエンドを学習するにあたり、最後におすすめしたいのが『 渋谷で働くエンジニア福の「実践で学ぶプログラミング入門」 』チャンネルです。 チャンネル登録者数は5270人と少なく感じられると思いますが、駆け出しエンジニアの中では話題のチャンネルとなっています。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・ PHP 、 MySQL 、Laravelの基礎を学べる ・特に、 PHP 初心者の方におすすめ ・短時間で学べる ・コーディングしながら実践的に学べる 本チャンネルは2020年から配信を開始し、多くても週1ペースで更新されています。 その中でも人気の動画が以下の通り。 順位 タイトル 視聴数 1 【Laravel入門・準備編】LaravelインストールとComposer #01 - YouTube 2.1万回 2 【PHP初級】ログイン機能作成手順とユーザテーブル作成 ~ログイン機能をつくろう！~ #01 - YouTube 1.8万回 3 【Laravel入門・準備編】PHPフレームワークの種類と人気を紹介 #00 - YouTube 1.7万回 4 【PHP/MySQL入門】MAMPのphpMyAdminでデータベースを使う準備 ~ブログアプリ作成~ #01 - YouTube 1.7万回 5 【PHP/MySQL入門】PDOを使ってMySQLデータベースに接続しよう！ ~ブログアプリ作成~ #03 - YouTube 1.7万回 ※視聴数は、2021/9/3時点の情報です。 チャンネル名の通り、 PHP を 実践で学ぶ ことができる動画コンテンツが盛り沢山です。 また、質問があるときは動画のコメント欄に記載すると、配信者の福さんからご丁寧に返信が返ってくるようです。 1人だと挫けそうになるときがありますが、この仕組みでしたら学習意欲も上がりますね。 もし PHP を学習し始めたい方がいましたら、是非ご参考ください！ コンピュータサイエンス の基礎を学習するなら？ プログラミングを始めたら、理論や数学に興味が向く方も多いのではないでしょうか。 そんな方に おすすめのチャンネル をご紹介！ 早稲田大学 早水桃子研究室 youtu.be 早稲田大学 の専任講師が コンピュータサイエンス の注目トピックの一つ「 離散数学 」を中心に配信を行っているのが、 『 早稲田大学 早水桃子研究室』 です。 ここで扱われている数学はレコメンドエンジンやWebクローリングなど幅広く応用されています。 チャンネル登録者数は2.84万人ですが、これから伸びてきそうなチャンネルです！ ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・ 離散数学 の入門が学べる ・ グラフ理論 やグラフ アルゴリズム の初歩を学べる ・データサイエンス、データ分析、 機械学習 に必要な基礎知識が学べる ・ 早稲田大学 の授業が無料で受けられる 本チャンネルの視聴数TOP5は以下の通りです。 順位 タイトル 視聴数 1 Lecture 1: Combinatorial problems on trees inside phylogenetic networks - YouTube 31万回 2 離散数学入門#0: グラフ理論へのイントロダクション，授業ガイダンス・基本的な用語の準備 - YouTube 18万回 3 早稲田大学 生医＆建築(1) 数学B1(微分積分) 第1回・第2回 学習の道案内（担当教員：早水 桃子）【日本語字幕有り】 - YouTube 6.3万回 4 早稲田大学 生医＆建築(1) 数学B1(微分積分) 2020年度オンライン授業ガイダンス（担当教員：早水 桃子）【日本語字幕有り】 - YouTube 5.6万回 5 離散数学入門#1: グラフの基礎知識（前編），握手補題の証明と応用 - YouTube 5.5万回 ※視聴数は、2021/9/3時点の情報です。 エンジニア、 プログラマ の思考で重要となる 離散数学 を、無料且つ、学校や専門スクールに通わずに学べるのは驚きました。 しかも、各動画のコメントにもありますが、解説がとても分かりやすいです。 昨今、ビジネスシーンで重要となってきているデータ分析領域にも必要な知識となりますので、今後注目のチャンネルです！ 海外チャンネル 続きまして、海外のおすすめチャンネルをご紹介します！ ・freeCodeCamp.org ・CS Dojo ・CS Dojo 上記は、2021/9/3時点でのチャンネル登録が多い順で並べております。 早速、チャンネルの詳細を見ていきたいのですが海外のチャンネルだと英語が…と抵抗を持つ方も多いはず。 まずは、英語が苦手な方向けの対策をお伝えします！ 英語が苦手な方へ 海外のチャンネルを見たいけど英語が苦手… そんな方は、 YouTube の字幕機能を利用し、日本語で学習をしてみてはいかがでしょうか。 設定方法方は以下の通りです。 見たい動画をクリック 字幕をオン 設定→字幕をクリック 英語→日本語をクリック Learn Python - Full Course for Beginners [Tutorial]の字幕画像　出典： YouTube より引用 正確な翻訳とまではいきませんが、少しでも理解が進むと思います。 是非お試しください。 freeCodeCamp.org youtu.be 日本でいうProgate似たようなプログラミング学習サイト「 freeCodeCamp 」の講座を YouTube にて配信しているのが『 freeCodeCamp.org 』です。 チャンネル登録者数は、412万人と驚異の数字となっています。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・HTML、 CSS 、 JavaScript 、Node.js、 Python 、React、 PHP が学べる ・データサイエンス、大学レベルの 線形代数 なども学べる ・他チャンネルに比べて、圧倒的な量の動画コンテンツがある ・初心者～上級者までレベルが幅広い 本チャンネルは記載の通り、超大型チャンネルです。 では、視聴数はどうなっているでしょうか？ 順位 タイトル 視聴数 1 Learn Python - Full Course for Beginners [Tutorial] - YouTube 2663万回 2 SQL Tutorial - Full Database Course for Beginners - YouTube 783万回 3 Learn JavaScript - Full Course for Beginners - YouTube 696万回 4 C++ Tutorial for Beginners - Full Course - YouTube 681万回 5 C Programming Tutorial for Beginners - YouTube 485万回 ※視聴数は、2021/9/3時点の情報です。 TOP5の視聴数が日本の YouTube チャンネルと比べて、圧倒的な数字ですね…。 また海外のチャンネルではありますが、英語の発音も比較的聞き取りやすいのも特徴ですのでご興味ありました是非ご視聴ください！ CS Dojo youtu.be 次は元 Google エンジニアのYK Sugishitaさんが配信を行っている『 CS Dojo 』チャンネルです。 チャンネル登録者数は171万人とやはり多いですね。 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・ Python を学べる ・特に、 Python の フレームワーク Django の アプリ開発 が学べる ・ アルゴリズム とデータ構造が学べる ・ 動的計画法 が学べる 人気の動画は以下の通り。 順位 タイトル 視聴数 1 Python Tutorial for Absolute Beginners #1 - What Are Variables? - YouTube 701万回 2 Why I Left My $100,000+ Job at Google - YouTube 582万回 3 How I Learned to Code - and Got a Job at Google! - YouTube 444万回 4 What Can You Do with Python? - The 3 Main Applications - YouTube 297万回 5 Top 5 Programming Languages to Learn to Get a Job at Google, Facebook, Microsoft, etc. - YouTube 274万回 ※視聴数は、2021/9/3時点の情報です。 海外では Python をメインで学ばれている方が多いようですね。 前述したfreeCodeCamp.orgチャンネルと同様、本チャンネルも比較的聞き取りやすい英語ですので、是非 Python を学びたい方はご視聴されてみてはいかがでしょうか？ Derek Banas youtu.be チャンネル概要 チャンネル登録者数：114万人 ※チャンネル登録者数は、2021/9/3時点の情報です。 ◆本チャンネルのおすすめポイント ・ Python 、 Java 、 C++ 、 PHP 、HTML、 CSS 、 MySQL などが学べる ・Git、 GitHub 、 Android , iOS などが学べる ・デザイン知識（ デザインパターン 、 WordPress 、WebDesign）が学べる ・コーディングしながら学べる ・ゲームの作り方も学べる おすすめポイントが多すぎて書ききれないほどです…。 ではこちらの視聴数も見てみましょう。 順位 タイトル 視聴数 1 Python Programming - YouTube 536万人 2 Java Programming - YouTube 482万人 3 C++ Programming - YouTube 467万人 4 PHP Programming - YouTube 189万人 5 Visual Basic Tutorial 2017 - YouTube 172万人 ※視聴数は、2021/9/3時点の情報です。 配信者であるDerek Banasさんは、現在データサイエンスと 機械学習 に関するシリーズをメインで配信しているそうです。 しかし…ほぼ全てプログラム言語をマスターしていると言っても過言ではないですね。驚きです。 動画コンテンツが多いので、まずは学ばれている言語の チュートリアル からご確認いただくと良いかもしれません！ 当社 ラク スのチャンネル 当社では、定期的に SaaS 領域で培った知見や先端技術の研究成果をConnpass上で開催しております。 イベント当日の様子を アーカイブ 動画として残し、 メール会員（ ラク スDevelopers会員） 限定で無償提供しています。 ご興味ある方は是非イベントへ参加の上、 メール会員（ ラク スDevelopers会員） へご登録をお願いします。 rakus.connpass.com そんな アーカイブ 動画ですが、実は YouTube の ラク スチャンネルで一部公開しています。 現在人気の動画は・・・ 20/10/28 SaaS プロダクトのフロントエンド／Vue.js、React、TypeScript、E2Eテスト youtu.be 本イベントでは、 ラク スの現役フロンエンドエンジニアが登壇 チャットディーラー 楽楽勤怠 楽楽明細 発表タイトル テスト稼働の削減とフロントエンドの品質担保を行うE2Eテスト Vue.js + TypeScriptによる新規サービス開発ふりかえり 息の長いサービスのフロントエンドを少しずつ改善していく営み を、フロントエンド技術をどのように活用しながらサービスを成長させているか、またモダンなフロントエンド技術をどのように大規模 SaaS に取り入れていくかをメインテーマとし、発表しております。 こちらの発表内容の詳細は、別のブログでも紹介しております。 【Meetup】SaaSプロダクトのフロントエンド／Vue.js、React、TypeScript、E2Eテスト - RAKUS Developers Blog | ラクス エンジニアブログ 前述しました通り、最新の アーカイブ 動画を見たい場合は メール会員（ ラク スDevelopers会員） に登録することをおすすめします！ YouTube の高度な検索方法 YouTube を検索する際のちょっとしたテクニックをご紹介します。 検索 演算子 を使う方法 YouTube を利用する際、見たい動画コンテンツのキーボードを検索ボックスに入力するのがオーソドックスな検索方法です。 フィルタを使うことで、アップロード日・タイプ・時間・特徴・並び替えも一般的に使われていると思います。 ここでは、検索 演算子 を使うことによってより便利な YouTube ライフを充実させる方法をご紹介します。 まず、 YouTube で使える検索 演算子 は以下の通りです。 OR検索 除外検索 タイトル検索 ハッシュタグ 検索 OR検索 複数キーワードのどちらか1つに一致する動画を検索したい際に使用します。 OR検索をする場合、検索ボックスに「 キーワード OR キーワード 」と入力してください。 YouTube の検索方法（OR検索） 出典： YouTube より引用 「楽楽精算」又は「楽楽明細」のどちらかが含まれる動画が表示されました。 YouTube の検索結果（OR検索）　出典： YouTube より引用 是非機会があれば活用してみてください。 除外検索 見たい動画を検索したけど、検索結果に別のキーボードが含まれてしまうことありませんか？ そんな時は、除外検索方法をご活用下さい。 除外検索をする場合、検索ボックスに「 検索したいキーワード -除外したいキーワード 」と入力してください。 YouTube の検索方法（除外検索）　出典： YouTube より引用 検索結果から「楽楽明細」が除外され、表示されました。 YouTube の検索結果（除外検索）　出典： YouTube より引用 YouTube は、膨大な動画コンテンツ量があるため除外検索は覚えておいて損はないと思いました。 タイトル検索 検索ボックスにキーボードを入れた際は、タイトル以外の箇所も見たうえで検索結果に表示しています。 動画コンテンツのタイトルのみで検索したい場合は、タイトル検索が便利です。 タイトル検索をする場合、検索ボックスに「 intitle:キーワード 」と入力してください。 YouTube の検索方法（タイトル検索）　出典： YouTube より引用 タイトルに「楽楽精算」が含まれているもののみ、表示されました。 YouTube の検索結果（タイトル検索）　出典： YouTube より引用 このタイトル検索を使うことにより、説明文に含まれるキーワードは拾ってきません。 検索結果の量が多い場合は、是非お試しください。 ハッシュタグ 検索 YouTube の動画に ハッシュタグ # を含めることができることをご存知でしょうか？ ハッシュタグ # を使ってグループ化されたコンテンツを検索できます。 ハッシュタグ 検索をする場合、検索ボックスに「 #キーワード 」と入力してください。 YouTube の検索方法（ ハッシュタグ 検索）　出典： YouTube より引用 以下のような検索結果が表示されます。 YouTube の検索結果（ ハッシュタグ 検索①）　出典： YouTube より引用 「# ラク ス」のような ハッシュタグ は、動画クリエイターが動画を公開する際に設定を行っていれば使える検索機能です。 設定された ハッシュタグ は、動画コンテンツタイトルの上に表示されています。 YouTube の検索結果 （ ハッシュタグ 検索②）　出典： YouTube より引用 本ブログにて紹介させていただいた動画コンテンツには、 ハッシュタグ の設定が多くされていました。 以下の「# PHP 」のように、学びたい言語の ハッシュタグ を検索し、絞り込みをすることで、ご自身にあった動画コンテンツを見つけてみてください！ YouTube の検索結果（ ハッシュタグ 検索③）　出典： YouTube より引用 まとめ 今回プログラミング学習をするにあたって、おすすめの国内外 YouTube チャンネルをご紹介させていただきました。 多くの動画コンテンツの中でもコーディングしながら学習できるものに多くフォーカスをあてましたがいかがでしたでしょうか？ 本ブログがエンジニア、 プログラマー 、デザイナーを目指している方の一助となれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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