トーク

最近、1993年発売のX68030というパソコンを買って動かして遊んでいます。
大学生当時に憧れだったけど高くてとても買えなかったX68030ですが大人になり財力が付いた今なら…と思ってフリマサイトを監視していたら良さそうな機体が出品されたのを発見してつい…。

X68030はHDDにSCSIを採用しHDD内蔵モデルであるX68030-HDには80MB（GBじゃないですよ）のHDDが内蔵されていました。

翻って現代、2022年。世の中には「Raspberry PiでSCSIデバイスをエミュレートする」とか「Compact Flashに格納したファイルをSCSI HDDとして見せる」とか「Raspberry Pi でFDDをエミュレートする」みたいな同人ハードウェアが生み出され、当時とはまったく異なる快適なX680x0環境を構築することができます。

このトークではX68030の紹介と、2022の今、X68030を楽しむにはどうすると良いかをお伝えします。
今でも十分通用するX680x0の魅力がみなさまに伝わり、X680x0ユーザが増えることを期待しています！（ねえよ）

QAエンジニア業務をやり始めて4年目になります。
大規模では、テストの自動化やQA業務の課題を可視化させてワークフローの最適化を経験し、小規模では、ワンオペによる俗人化やそもそもQA業務がマニュアル化されていないQA環境の整備するなど、様々なQAの現場でQA業務を経験してきました。
最近では、QAメンバーの採用で苦戦しており、とくにエンジニア採用で苦戦している以上にQAエンジニアやテストエンジニアがいない問題が深刻になっています。
本トークでは、QAエンジニア奮闘記と題してこれまでとこれからのフリーのQAエンジニアとして奮闘する話ができたら嬉しいです。

CakePHP 2 系のサポート終了に伴い、関わっているプロジェクトを Laravel でリプレースしました。
当時、 Laravel は触ったことがない状態だったものの、PHP のイベントを聞いて興味を持ちました。
Laravel は器用なことができるフレームワークだと感じていますが、その反面、Laravel を導入したばかりの時にはチームで決めていくことがいくつかありました。

また、 Laravel 化に合わせ、CI の拡充やインフラの整備、 PHP 8 対応なども進めたため、本トークではこれらの知見の共有を行う予定です。

チームで会話している時にデザイナとエンジニアでは同じ名詞に対してでも頭に浮かべているものが異なります。
デザイナはユーザのメンタルモデルを元に、エンジニアはシステム設計や要件を元に会話していることがほとんどだったので常にお互いの話が理解しにくく、デザイナをチームの中でも孤立させてしまっていました。

そのような問題を解決すべく、私のチームではエンジニアとデザイナで定期的にプロダクトに対してOOUIでのモデリングを行ってきました。
本トークではこの取り組みから以下のことをまとめて発表する予定です。

• OOUIモデリングの簡単な説明
• チーム状況と課題
• OOUIモデリングで得られた効果
• ドメインモデリングとの対比
• チームで行っていく中で感じた課題
• 副次的に得られた効果

フルサーバーレスな構成を取る場合、必要な様々なクラウドサービスの知識に加え
実践的な利用方法が求められます。

フルサーバーレスの恩恵を受けたいが、その第一歩が難しい。
その悩みをAWS Amplifyは解消してくれます。

AWS Amplify で出来ることをご紹介しながらReact + GraphQLで作成するログイン付きの
サンプルWebアプリケーションを作成する流れについてご説明します。

具体的な手法をなぞることで、
どの様にフルサーバーレスなアプリケーションを作成するかを学びましょう！

• 想定する聴講者
  • フルサーバーレスアプリケーションに興味がある方
  • 具体的なフルサーバーレスアプリケーション開発の始め方を知りたい方

Webアプリケーションはどうして動くのでしょうか。

ブラウザ等のクライアントから送信されたHTTPリクエストを契機に、
Webアプリケーションでは様々なレイヤーでの情報処理が行われます。

今回はその情報処理の流れをLaravelを例に追うことで、
Webサーバー、Laravelアプリケーション、データーベースと
レイヤー毎で行われている処理とそのレイヤー毎のつなぎ込み部分に迫ります。

HTTPヘッダーを含むHTTPリクエストの流れを追って、真にWebアプリケーションがどうして動くのかを知り、
必要な処理をどこに組み込むことが効果的なのかを知る一助になれば幸いです。

• 想定する聴講者
  • HTTPリクエストからレスポンスまでの流れをよく知らない方
  • HTTPヘッダーについて知りたい方
  • ウェブアプリケーションにおけるレイヤー毎の役割を整理したい方

コロナ禍でリモートワークになったエンジニアは数多くいらっしゃる事と思います。
そろそろ2年が経とうとしていて、少しずつリモートワークに慣れてきても、やっぱりオンラインとオフラインの差はある。
それぞれのメリット・デメリットを認識した上で、ワークライフバランスを上げつつ仕事を進める方法を、リモートワーク経験20年超&フルリモート転職の経験を踏まえてお話したいと思います。

2018年のGitHub UniverseでGitHub Actionsが発表されてから約3年、今ではGitHubを代表するなくてはならない機能の1つになっています。

発表者もv2（not HCL）から使い始めており、作成したOSSのCI/CD環境として有効に活用するだけでなく、独自に作成したActionもいくつかGitHub Marketplaceに公開しています。

本発表では「PHPで独自Actionを作成する」ことを通じて、GitHub Actionsを使いこなすに当たって、私の知る知見を時間の許す限り紹介します。

細かすぎて全く必要のなさそうな情報ばかりかもしれません。しかし、あなたがGitHub Actionsを使いつづけていくといつか必要になる情報かもしれません。

GitHub Actionsをより深く知ってCI/CDだけでなくさまざまな自動化効率化を実現しましょう。

「DOT言語」

あまり聞くことがない言語だと思います。
ではこのように言い換えたらどうでしょう？

「Graphvizで使うDSL」

以下の検索結果をみて「何かのツールの出力でみたことがある画像」と思うかもしれません。

https://www.google.com/search?q=graphviz&tbm=isch

DOT言語はGraphvizのための言語です。
本発表は「Graphvizを使ってみたい」という方が対象です。

「難しそう」と思った方へ。

私のDOT言語のイメージは、

• DOT言語はプログラミング言語というよりHTMLのようなマークアップ言語
• HTMLをブラウザがレンダリングするようにDOT言語で書かれたコードをGraphvizがグラフ画像に変換する

です。

「PHPと親和性高そう」と思った方。その通りです。

DOT言語の世界へようこそ！

プロジェクトとしてSREを実施することになったので、プロダクトにSLOを定めてみました。

実際に定めた内容の他、SLOを定義するまでに至る経緯、現運用の課題や、アプリケーションエンジニアとのコミュニケーションに関する今後の展望など、弊社エンジニア組織の文化的背景など踏まえお話しします。

普段、受託の案件（特に業務システム）に携わるエンジニアだと、大量のアクセスを想定したアプリケーションを実装する機会が多くありません。
私は今回初めて数万ユーザーが利用するtoCのLaravelアプリケーションの構築に携わりました。
数万ユーザーのアクセスに耐えうるインフラ、アプリケーションを構築できたのか！？
「実際どれくらいの秒間リクエストに耐えうるのか？？？」をLocustというツールを用いて負荷試験を実施して、試行錯誤したことお話しします！

・ 想定する聴講者

• アプリケーションの負荷試験にまだ挑戦したことのない人
• 普段業務システム系が多く、大量のユーザーアクセスを想定したアーキテクチャ設計をやったことのない人
• Laravelで負荷試験の際に気をつけていきたいことを知りたい人

既存サービスにフレームワークを導入するとなると、さまざまな障壁が立ちはだかります。
導入によるコスト、品質への影響、ビジネスサイドとの合意形成など。
弊社では、リリース後21年目になるレガシーサービスにLaravelを導入しました。
このセッションでは、導入に至った経緯、ビジネスサイドとの調整、戦略、アーキテクチャ選定、導入手順とその結果や成果などを紹介させていただきます。
レガシーサービスだけど、フレームワークを導入してみたい開発者向けの内容となります。

みなさん、あなたが保守しているコードベースで一番バグが混入しやすいファイルが何か知っていますか？

このトークでは、保守容易性指数（Maintainability Index)とGitHubのコミット数を用いて、
保守性が低くて、よく変更されているファイル(= バグが混入しやすいファイル)を見つけ出す方法についてご紹介します。

みなさん Composer 使ってますか？使ってますよね〜〜〜？？
Composer のようなパッケージマネージャのおかげで、パッケージの依存関係を明らかにしたりパッケージの依存関係や実行環境の依存関係にあわせてパッケージを適切なバージョンにアップデートすることもできます。

一方で、定期的にパッケージのバージョンアップを行うのは手間ではあります。その一手間を減らしてくれる dependabot や WhiteSource Renovate といった自動でパッケージのアップデートを Pull Request にしてくれるツールが登場します。

本トークでは、 Composer を利用しているプロジェクトにおいて、 WhiteSource Renovate を用いたアップデートに関する Pull Request の自動作成戦略についてお話しできればと思います。

世は大 Laravel 時代を迎えています。業務でも Laravel を採用している会社はそれなりにいるのではないでしょうか。
しかし、「依存を増やす」ということは「障害点を増やす」ことと同義です。
「Laravel は安定しているからロックインされてもいい」とみなすことも出来ますが、業務では「最悪の場合」も想定して選択していく必要があります。
DDD の文脈では（私は DDD 初心者ですが）、ビジネスロジック(ドメインロジック)を重要視します。フレームワークはビジネスロジックをサポートしますが、直接依存しない方が安全です。
このトークでは、「いつでも Laravel を捨てることもできる疎結合な設計」を紹介します。

対象者

• OSS フレームワーク・ライブラリを利用する全ての皆様
• アプリケーションを疎結合にしたい方

成長するためにアウトプットというのは非常に重要ですが僕のまわりでは
・プライベートで開発ほとんどしてないからネタがない
・公開できるようなネタがない
・とにかくネタがない
ということが非常に多いです。

僕も最近はプライベートで開発できてないので、めちゃくちゃ気持ち分かります。
でも我々は日々業務で技術に触れていますし、日々学んでいますよね？
だったらそれをアウトプットすればいいのです！

もちろん業務で得た知識をそのまま一般公開することはできませんし危険です。
外部に出してはいけない情報もあるでしょうし、場合によっては情報漏えいにも繋がります。
そういう知識をアウトプットするには「抽象化する」ことがとても重要です。

本セッションでは「知識の抽象化」の仕方を実際に僕が経験したことを例に説明します。
このセッションで少しでもアウトプットへのハードルが下がると嬉しいです！

昨今のプロダクトの改善・開発を実施していくためには、データを可視化・分析することはこの時代必須といえます。
特に、アプリケーションエンジニアにも一定のリテラシーが求められている時代だと考えられます。
しかし、そのために必要なデータはRDB、ログなどの様々な形式、場所にあり横断的な分析をすることは容易ではありません。

そこで、私たちのアプリケーションの分析環境をBigQueryに構築したエピソードをもとに、以下の知見についてトークします。

• embulkを使ったBigQueryへの転送パターン
• 便利な集計クエリのパターン
• BigQueryの権限管理ついて
• BIツールのLookerを用いたデータ監視について

NoSQLのような可用性・柔軟性を持ちながらSQL・トランザクションをサポートすると言われているNewSQL（Cloud Spanner, CockroachDBなど）の導入事例が最近目につくようになってきました。
ですが、NewSQLと既存のNoSQLとの違い、また実際どのようなメリットがあるのか、よくわからない部分も多いと思います。
今回の発表ではNewSQLの1つであり、MySQL互換のTiDB(タイデービー)をローカル環境でセットアップして、PHPのアプリケーションからつないで使ってみるところまでを、発表したいと思います。

アプリケーションエンジニアの視点から調査した以下の内容をまとめて発表予定です

• NoSQL, RDBとの違いとNewSQLのメリット
• TiDBをPHPから動かしてみる

突然、元気に呼びかけて申し訳ありません！
言いたいことは掲題のとおりでございます。

Web業界やソフトウェア産業、とっても忙しいと思うんですよね。
やる事が多い！巷では、やれアジャイルだ、リーンだ、DXだ・・・と騒がれて久しい。
なんでも、「コードを書いてりゃOK」ではないような雰囲気がムンムンしちゃって。
「視座の高さ」「視野の広さ」がより求められている感じがします。

そんな幅広い職業に居る我々の「生産性」ってなんでしょうね？
(私、ここ1年ほど、職場でそんなことばっか考えてる。)
そのヒント、書籍「LeanとDevOpsの科学」にあります。
価値を届ける、確実性を上げる、無駄を削ぎ落とす・・「それって何？」に真っ向から向き合った1冊です。
ソフトウェア開発の「生産性」について考える、「改善」について考える、そんな取っ掛かりになるように書籍の紹介をします。

コードレビューは難しいですね！
異なる考え方・レベルにある他者同士、ぶつかってばかりではいられないけど「何も言えない」のでは意味がない─
そんな複雑で繊細な仕事に、どう向き合えばよいでしょうか？

本セッションでは「レビューは何が難しくて、"怖い"のか」について考えます。
その上で、コミュニケーションやチーム作りの分野にヒントを求めて「明日からできそうなこと」を紹介します。

以下のような書籍をヒントの元として想定しています(一例)。

• アジャイルプラクティス
• 学習する組織
• NVC 人と人との関係にいのちを吹き込む法
• あなたのチームは、機能してますか？

お届けしたい事

• 「威圧したい訳ではない！でも妥協もしたくもない！！」を両取りするためのヒント

扱わない事

• プログラミングの知識、技術
• コードのクオリティを高めるためのノウハウ