皆さんはサービスを運用していますか?
運用は日々継続して行う必要があるため、とても大切な仕事の1つです。
私は新卒でエンジニアになる前は、新しい技術でサービスを立ち上げたり新しい機能を開発しユーザーに価値を提供する新規開発が、エンジニアの主な仕事だと思っていました。
しかし実際に経験した業務は、既存のサービスをメンテナンスやリファクタリング、ライブラリをアップデートするなどの運用の業務も多かったです。
そのような運用の仕事は、新規開発に比べると地道なものです。
日々の運用をこなす中で「運用の中にエンジニアとして成長できる要素や面白さがある」と気づきました。
本LTでは、新卒2年目のエンジニアがサービスを運用・改善を行う中で得られた成長と技術的な面白さについてお話しします。
※ 本LTの内容はPHPに関連しません。
エンジニアの生産性には、優秀な人とそうでない人との間に大きな差があると言われています。
その差はどこからくるのでしょうか?
今回は「学習」という側面にフォーカスしながら、生産性の高いエンジニアであり続けるための戦略について考えてみます。
エンジニアの生産性の差は、ひとつには教わるだけの人と自ら学ぶ人との学習姿勢の差が反映されたものです。
自ら学ぶ人は常に教わるだけの人の先を行きます。それどころか「学び方を学ぶ人」はさらにさらに先を行くことになるのです。
技術・環境・ツールの変化が激しく既存のスキルがすぐに陳腐化してしまう現代において、「学び方の学び方」こそが重要なスキルになります。
このトークでは、エンジニアに欠かせない学び方の学び方と、自ら学ぶ集団の作り方について共有し、みなさんと共に考えていければと思います。
エンジニアの生産性には、優秀な人とそうでない人との間に大きな差があると言われています。
その差はどこからくるのでしょうか?
今回は「学習」という側面にフォーカスしながら、生産性の高いエンジニアであり続けるための戦略について考えてみます。
エンジニアの生産性の差は、ひとつには教わるだけの人と自ら学ぶ人との学習姿勢の差が反映されたものです。
自ら学ぶ人は常に教わるだけの人の先を行きます。それどころか「学び方を学ぶ人」はさらにさらに先を行くことになるのです。
技術・環境・ツールの変化が激しく既存のスキルがすぐに陳腐化してしまう現代において、「学び方の学び方」こそが重要なスキルになります。
このトークでは、エンジニアに欠かせない学び方の学び方と、自ら学ぶ集団の作り方について共有し、みなさんと共に考えていければと思います。
人生は後悔の連続です。
それはシステム開発の現場においても同様と言えます。
Minimum Viable Product だ!必要最低限の機能に絞って実装しよう!
データベースは正規化して、nullable は排除、データベースで整合性を担保しよう!
CI/CD 環境を整えて不安の無いデプロイを実現しよう!
全て3年前のプロジェクトメンバーが聞いたら納得する内容です。
実際に私も納得して開発していました。
しかし、システム開発において想定外の事態というものは必ず存在します。
1つのシステムを横展開するという企画から始まったシステムも、
今や50を超える類似システムが存在します。
「類似」システム……。
そう、何一つとして同一のものはないのです。
度重なる仕様変更。
崩れる正規化。
壊れるブランチ戦略。
そんな、横展開の闇に揉まれながら、血を流しながら、システムを改善していく、
「システム開発現場のリアル」
についてお話したいと思います。
海外カンファレンスに登壇したいと思ったことはありませんか?Laraconは世界中のLaravelユーザーが集まるLaravel公式のカンファレンスです。
Laracon US, EU, AU, India, Onlineなど毎年に世界各地で開催されています。僕は留学経験などありませんが、今までに2回Laraconに登壇する機会をいただきました (Laracon Online 2022の動画)。英語がペラペラでなくても、面白いトピックと熱意さえあれば誰にでも登壇するチャンスはあります。このトークでは、Laraconへのプロポーザルの提出から、採択されてから本番までの準備、登壇本番までの経験談などをお話します。海外カンファレンスでの登壇に興味がある方にとって、一歩を踏み出すきっかけになれば嬉しいです。
データベースのレコードがどのような経緯で現在の状態になったのか分からず、困ったことはありませんか?
Event Sourcingは、アプリケーションの状態変更をイベントとして記録し、それを用いてアプリケーションの状態を再構築するアーキテクチャパターンです。このトークでは、LaravelでEvent Sourcingを実装する方法について、具体的な手順と実践的なパターンを紹介します。
みなさん、 Web 、してますか? Web アプリケーションの一つに 「 3D リアルタイムレンダリング」 があります。 WebGL と呼ばれる技術を用いて、ネイティブアプリのように滑らかに動作するゲームやショーケースなどを作ることが出来ます。
その中でも今話題沸騰なのが WebGPU という新しい規格です!これは Vulkan や Metal のように GPU を直接呼び出す新しい技術で、今まで WebGL1, 2 で作られてきたものよりも効率的に 3D レンダリングを行うことが出来るようになります。
これは現在 Google Chrome の最新版に 4 月中にリリースされる予定となっていて、もうエンドユーザーに届けられる段階にあります。
その WebGPU を一足先に、一年前から対応していた 3D リアルタイムレンダリングライブラリが Babylon.js です。これは皆さんおなじみ(?) TypeScript で作られているフレームワークで、非常に簡単な API で豪華なアニメーションや VR/AR 表現を行うことが出来る素晴らしいプロダクトです。
しかし、悲しいことに Babylon.js の採用事例はまだ国内外ともに少なく、もったいない状態になっています。そこで、普段 PHPer である皆さんにも是非触って欲しい。ゲーム作ってみて欲しいということで、今回紹介させて頂きたいと思います!
皆さんはCTO、VPoE、部長、本部長などの役職に就いていたり、キャリアの中でそういったロールに就任することを目標としていますか?
一般的には、役職への就任はポジティブなものとして受け取られることが多いのではないでしょうか。
しかし、私を含めた私の周囲にいる前述のような役職に就いたエンジニアに話を聞くと、どうも本人が望んでいないのにそうなってしまったケースが多いです。
そういった事例を見聞きする中で、本人が望む望まないに関わらず役職に就いてしまうエンジニアの共通点を理解してきました。
PHPカンファレンスに出席するような勉強熱心な方は、出世などせずにIndividual Contributorとしてキャリアを続けたいと考える方も多いのではないでしょうか。
実は、そういった指向の方こそが役職に就いてしまう傾向があると私は考えています。
本トークでは、私がキャリアの中で出会ってきた「気づいたら役職に就いていた」ソフトウェアエンジニアのケースを元に、そういったキャリアを望んでる方には今後目指すためのヒントを、役職に就いてしまった方には出口戦略について考える機会を作れたらと思います。
エンジニアは継続して勉強する必要があると言われています[要出典]。ただじゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。
そんなふうに思っていた自分は今では、年間で、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。
ValueObject という実装パターンをご存知でしょうか。特にドメイン駆動設計(DDD)の流行以降、基本的な実装パターンとして多くの場面で活用されています。PHP における ValueObject の実装方法は、ある程度は共有されているものではありますが、細部において意見の相違や迷うポイントが存在します。さらに、PHP 8 において Constructor property promotionやreadonlyなどの新しい言語機能が追加されたことで、実装方法が変化しました。
本発表では、ValueObjectを改めて考察し、PHP 8 での実装方法やトレードオフについて議論します。
考古学(こうこがく、英語: archeology)は、「人類」が残した「遺跡」から出土した「遺構」などの「物質文化」の研究を通し、「人類の活動」とその変化を研究する学問である。(Wikipedia)
つまりアーキテクチャ考古学とは、「先人」が残した「コード」から出土した「遺産・負債」などの「アーキテクチャ」の研究を通し、「プロダクト」とその変化を研究する学問である。(Akito.Tsukahara)
みなさん、こんにちはアーキテクチャ考古学者のAkito.Tsukaharaです。
この登壇では、新しく入社してくれたメンバー達へのオンボーディングをするために、考古学した(弊社のプロダクトのアーキテクチャを研究、文言化して、社内で勉強会)取り組みについて発表させていただきます!
考古学することには、「システムの理解とドメイン知識の向上」や「技術的負債の認知」をオンボーディングで伝えることで
新メンバーが少しでも楽に現場の開発に慣れてもらう意図があります。
この発表をご覧いただくことで以下の情報をお届けできます。
・考古学のやり方
・アーキテクチャに関する知識・ノウハウ
・レイヤードアーキテクチャ
・テスト設計 etc...
・オンボーディング資料の作り方
・社内勉強会でチームの巻き込み
など
考古学(こうこがく、英語: archeology)は、「人類」が残した「遺跡」から出土した「遺構」などの「物質文化」の研究を通し、「人類の活動」とその変化を研究する学問である。(Wikipedia)
つまりアーキテクチャ考古学とは、「先人」が残した「コード」から出土した「遺産・負債」などの「アーキテクチャ」の研究を通し、「プロダクト」とその変化を研究する学問である。(Akito.Tsukahara)
みなさん、こんにちはアーキテクチャ考古学者のAkito.Tsukaharaです。
この登壇では、新しく入社してくれたメンバー達へのオンボーディングをするために、考古学した(弊社のプロダクトのアーキテクチャを研究、文言化して、社内で勉強会)取り組みについて発表させていただきます!
考古学することには、「システムの理解とドメイン知識の向上」や「技術的負債の認知」をオンボーディングで伝えることで
新メンバーが少しでも楽に現場の開発に慣れてもらう意図があります。
この発表をご覧いただくことで以下の情報をお届けできます。
・考古学のやり方
・アーキテクチャに関する知識・ノウハウ
・レイヤードアーキテクチャ
・テスト設計 etc...
・オンボーディング資料の作り方
・社内勉強会でチームの巻き込み
など
我々アプリケーションエンジニアにとってデータは非常に重要なものです。
皆さんもRDBのデータ、ログデータ、分析データといった色々な種類ものを扱うことが多いのではないでしょうか?
しかし、これらのデータはエンジニアだけのものではなく、マーケター、事業責任者といったプロダクトに関わる全員が関わるべきものではないでしょうか?
そのためには、SQLの習得といったスキルの問題や、業務サービスへのアクセス権限といったガバナンスの問題もあり、なかなか難しい課題なのではないでしょうか?
そこで、我々の開発チームでは、開発だけでなくプロダクト全てのサイクルに関わる"Fullcycle Developers"という標語を抱えています。
その一環で、我々が作ったプロダクトの成果をデータ含めてフィードバックループを作るようにしています。
その結果、BIツールを用いて、SQLを出来る限り書かずともチームの皆がデータを可視化・確認できるようになり、開発に関する議論も職種問わず活発化しました。
そこで今回のトークでは、我々のチームが、どのようにデータの民主化を進めていったのか、データの民主化によってどのような変化があったかをお伝えします。
具体的なBIツールなどの使い方などに関しては話さない予定です。
発表者の会社では、複数のWebサービスをオンプレミスの複数のKubernetesクラスタ上で運用しています。
手元からのkubectlなどKubernetesクラスタへのアクセス権が必要となります。そのため、生産性を損なわずに安全性を担保してアクセス権を得られる仕組みを用意しています。
本セッションでは、以下のお話をします。
みなさんのアプリケーションではUIがいつの間にか壊れている、ということはありませんか?
とあるUIコンポーネントが予想しなかった箇所で段落ちして崩れていたり、はみ出ていたり。CSS完全に理解したTシャツよろしくなことになったことはありませんか?
このトークではマイクロソフトのOSSであるPlaywrightの試験的な機能であるコンポーネントテストのスクリーンショットテストを用いた、リグレッションテストについての使い方・運用方法などを紹介します。
スクリーンショットによるリグレッションテストを行うことで、UIが期待した状態で描画されているかを視覚的に確認することができます。
またプルリクエスト時にもスクリーンショットによる視覚的なレビューを行うことが容易になるためスムーズなコミュニケーションにも期待できます。
本トークはPlaywrightによるリグレッションテストを実際のプロダクションで使っている事例を紹介します。
※このトークではPHPの話はありません。
少数を整数にしたり、大きな数字を有効数字にしたりするために四捨五入(丸め)をすると思いますが、その時にPHPでは「round()」関数を用いると思います。
round関数には第三引数にオプション値がありますが、引数を省略した場合、文字通りの四捨五入(有効桁より一つ下の桁が5以上なら有効桁が1大きくなる : PHP_ROUND_HALF_UP)となります。
実はその丸め処理、安直に四捨五入を選ぶと計算や動作に問題が出ることがあります。
先日ちょっとした問題になり、良い機会なので発表したいと思います。
当方ン十年エンジニアをしていましたがずっと意識したことがなく、多分皆様もそうじゃないかと思いますので。
※今回の話はPHPに限らずどの言語でも当てはまると思います
GitOpsによるAptリポジトリの自動管理
発表者のチームでは、数百台のサーバに対して独自ビルドしたプライベートなDEBパッケージを配信する必要があります。
私が所属するチームでは、GitのPull Requestベースの開発フローに則るだけでAptリポジトリへの自動リリースをする仕組みを開発しました。パッケージングやAptリポジトリの生成といった複雑なオペレーションを開発者が意識しなくて良くなっています。
また、Aptリポジトリをイミュータブルなアーキテクチャで構成しているため、障害発生時に簡単に復元できるようになっています。
本セッションでは、以下のお話をします。
応募者の業務中に最近起きた話を共有します。フリーランスである応募者は PHP-5.5、FuelPHP-1.8、AWS RDS MySQL 5.6 というレガシー環境で社内システム向け Web アプリを開発していました。
AWS は2022年2月に RDS での MySQL 5.6 のサポートを終了し、2022年3月以降に MySQL 5.7 への自動アップグレードを開始しました。いざ MySQL 5.7 にアップデートを行うと、アプリケーションの特性が要因となって、ORマッパーが生成する SQL に対して、いくつかの問題が発生しました。JOIN を多用する SQL に対して、内部的に生成するテンポラリテーブルの、カラム数やバイト数が限界に達したのです。この問題に対してシンプルな回避策は見つからず、DB 管理者は MySQL 8 へのアップグレードすることでの解決を模索します。実際に MySQL 8 との組み合わせを検証すると、今度は PHP の古さが原因となった問題点が発生しました。MySQL 8 から標準文字セットとなった utf8mb4 を PHP-5.5 の mysqlnd は理解できず、接続時にエラーとなってしまうのです。utf8mb4 がサポートされた mysqlnd は PHP-7.0.19 からです。PHP-7 に一気に上げると、おそらく他の部分にも様々な修正が必要となってくるでしょう。この八方塞がりな状況をいかに解決したかというお話をさせていただきます。
オチを少しだけバラすと、このシステムは PHP-5.6 と MySQL 8 の組み合わせで現在動作しています。
"品質"
IT業界では長らく「ふわっと」利用されてきた言葉です。
ですが、"品質"には定義があります。
あなたは"品質"について説明できていますか。
このトークでは"品質"の定義とシステム開発において要求される"品質"の満たし方についてお話します。