このセッションでは、ターミナル上で動作するリバーシを作成しつつ、テスト駆動開発(TDD)の基本を解説します。
一部、ライブコーディングを取り入れ、PHPを使用してリバーシを開発するプロセスを実際に見ていきます。
セッションの内容 :
主な対象者 :
ソフトウェア開発において、モデル化や抽象化と言ったときに、多くの方は実装しようとしているシステムで扱う対象(業務など)に現れる情報や機能の構造をイメージするかと思います。一方で、私のエンジニア経験の中で、扱う対象の見え方がシンプルになるような「道具」としてのモデルを導入できた経験が何度かあります。エヴァンスのドメイン駆動設計でいう「ブレイクスルー」ほど大胆な発明ではないにしても、小さなブレイクスルーと呼んでも良いようなモデルの導入というものがあります。
このトークでは、「日時の範囲」という情報の取り扱いに関して、モデルを導入しない状態から、そのデータと演算とをモデル化して導入していくことで、問題の見え方が変わっていく流れを実際のソースコードを交えてお話します。
Git は、現代のソフトウェア開発において欠かせないツールの1つです。
しかし、一度基本操作から外れると、思いもよらないような複雑な操作を強いられることもあります。
Git の内部構造や仕組みを理解することで、こうしたトラブルを事前に避けたり、トラブルシュートしたりすることが可能になります。
このセッションでは、Git の核となる content-addressable filesystem と commit graph に焦点を当て、それらの仕組みや役割を解説します。
ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。
このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。
このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう!
ここ数年、Raspberry PiでCPUを作っています。
これは、CPUをコンピュータから取り外して代わりに自作CPUを取り付けて動かすというもので、オリジナルのCPUの名前のZ80にちなんでPiZ80と呼んでいます。
PiZ80はZ80採用のパソコン・MSXをあわよくば高速に動かすことを目標にしています。
現在のPiZ80はMSXと同じZ80採用のシングルボードコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。
このトークではCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。
このトークを聞いた方がCPUやハードウェア自作が好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています!
プログラミング言語の処理系は複雑な処理を行っているように見えますが、個別に分解してみれば一つ一つの処理はそれほど難しくありません。
PHP 処理系のソースコードを魔改造して PHP 言語に独自の拡張を施すことで、日ごろ使っている PHP やその他の言語処理系が、内部的にどのような処理を行っているのかを追いかけてみましょう。
Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。
背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。
お話しすること
・そもそも障害と何なのか?障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介
障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです!
弊チームではこのたび、15年間誰も手をつけられなかったレガシーシステムを、バグ0でフルリプレイスすることに成功しました。
チーム発案のオリジナル検証手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、フォールトマスキングなど、
多彩な手法を駆使することで、リスクを最小限に抑えながら安全に倒し切ったリリースを実現することができました。
どのように予期せぬトラブルを未然に防ぎ、計画通りのリプレイスを成し遂げたのか。その実践的なプロセスについて、詳しく解説します。
他のプロジェクトでも応用可能な知見を共有しますので、レガシーシステムへの手入れを検討している方は必見の内容です。
本セッションの対象者
・日々レガシーシステムと向き合っている方
・テストや検証手法に興味のある方
・フルリプレイス挑戦記と聞いてワクワクした方
「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか?
古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。
Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。
本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。
登壇をする内容の概要
プロダクト開発を成功させるには、重要な機能にリソースを集中させることが不可欠です。重要な機能にフォーカスすることで、最大の価値と競合差別化を生み出せます。
一方で、重要でない機能を含む全体的なリファクタリングや、コードベースの保守性向上だけでは、こうした成果は得られません。
この登壇では、重要な機能についての考え方とLaravelを使った重要な機能とそうでない機能のコストをかけない機能の実装方法も提示します。
話を聞いた人に持ちかえってほしいこと
聞いた人には、プロダクトの機能を再評価し、リソース配分の優先順位を考え直すきっかけにしてほしいです。また、その考え方をチームで共有し、ディスカッションを通じて話し合う機会を持っていただきたいです。
主な内容
このセッションのゴールは、オブジェクト指向の再認識です。
SOLID原則を世に広めた、アンクル・ボブことロバート・C・マーチンの新刊、「Functional Design」が登場しました。関数型ブームの影響を受けた現代のプログラミング言語から見ると、この本の登場はむしろ、遅すぎたと言ってもよいかもしれません。しかし一方で、私達は普段の経験で十分に、関数型の本質的な原理を理解したと言えるでしょうか。
改めて関数型とは何なのかを理解し、そこから逆説的に、次のようなテーマを深堀りしていきたいと思います。
(ぜんぶ喋れるんかこれ!?)
ここ数年、LLM の進化とともに、RAG(Retrieval-Augmented Generation:検索拡張生成)の構築・利用が進んでいます。RAG の内側ではよくベクトル検索が使われていますが、ベクトル検索には RAG 以外にもいくつかの使い道があります。
本トークでは、ベクトル検索を理解するのに必要な事項と、PHP から利用する際のサンプルコードについて説明します。
現代はGitHub Copilotなどの生成AI開発支援ツールが普及していますが、簡単に使える一方で、「サンプルを生成して」等の単純な質問しかせず「ChatGPTで十分では?高いし!」という声も聞きます。
もったいないと私は思います!
チャット機能しか使わないのは確かに煩雑で「自分で書いた方が早い」と思うのも理解できます。しかし、ツールは進化を続けています。様々なUIや機能を活用し、AIとより良いコミュニケーションを取ることで、AIという相棒と共に、より効率的な開発をしませんか?
アイザック・アシモフの『鋼鉄都市』では、C(炭素=人間)とFe(鉄=ロボット)がバディになります。最初はR(obot)を嫌っていた人間の主人公も、最終的にロボットとバディとなりました。
それは小説ですが、SWEの皆さんも、人でない生成AIと良きバディになれると思います。共にC/Feの文化を築きましょう!
「複雑で辛いコード」という概念は確かに存在するものの、
その正体がどこにあるか…?を上手く説明できないという事態も、しばしば発生するのではないでしょうか。
プログラミングは往々にして「感覚」「センス」も重要なのは百も承知。
でも、可能なら地に足のついた説明を加えたいですよね。
色々な分析・説明の手法を頭の中の引き出しに入れておくと便利です。
そんな物差しの1つの例として、「LCOM」があります。凝集度を数量化するものです。
定義をしっかり記憶していなくても、
そのコンセプトは、目の前のコードで「何が起きているか」を感じるための大きな助けになります!
このトークでは、
「ざっくりLCOMってなに」を話し
「手書きで図にしてみると分かりやすいね、似た考えを普段から使えそう」を感じてもらい
「抽象化やパターンと絡めて、リファクタリングに取り入れてみるとこんな感じに」をお届けします。
最近またオレオレフレームワークをつくりました、私のフレームワークのポリシーは長生きができることです。
今回私が一晩で作り上げたフレームワーク()をベースに、どのような部分を意識することでコードが理解しやすく、長生きができる工夫をしているかをお話ししたいと思います。
機能が満載のライブラリやフレームワークに慣れている皆様は、「こんな素朴な規約やフレームワークは使いたくない!」と思うかもしれませんが、私は誰でもわかり、5年10年生き延びるフレームワークにしたいのです。
本トークはオレオレフレームワークにかぎらず、特定のライブラリと密結合せずデカップリングするようなコードを書く際にも役立つと思います。
皆さんも手のひらに収まるようなコードにして、暗黙を避け、ジョインした人がすぐにコードをかきはじめられるようにしてみませんか?
今では多くのPHPerが利用している静的解析ツールのPHPStan
このPHPStanについて踏み込み、上手く活用する方法とアンチパターンについて以下を参考にお話します。
モノリシックかつレガシーな肥大化したPHPアプリにお悩みではありませんか?10年近く長年運用されてきたアプリケーションでは、技術負債による開発・運用上の問題に苦しむことが多いのではないでしょうか。これらの問題は短期で簡単に解決できないケースがほとんどです。
そこで、本発表では、「改善」の手立ての一つとして、主にAWS Lambdaを活用したアーキテクチャの変更や機能分割を行うことで得られる開発運用効率化について実体験をもとにご紹介させていただきます。
連想配列に全てを詰め込んで旅をさせるのは良くないとは分かりつつ、
今まで巨大な連想配列をゴリゴリ実装していたチームが、配列からの脱却への一歩に挑戦しました。
完全な配列脱却は難しかったものの、バランスをとったリアルな挑戦ができたのでお話しします。
話すこと