データベースの寿命は、アプリケーションよりも長い。
多くの人が感覚として持っているのではないでしょうか。
この10年間で多くの技術が生まれ、そして変化し、開発の現場も進化してきました。
そんな中、データベースの世界では何十年もRDBMSが活躍しています。
それはなぜでしょうか。
この10年間のRDBMSの変化から開発に必要なことが見えてくるはずです。
そして、そこからこの先の10年を見据えたシステム開発の勘所を紐解きます。
OracleDBやSQL Serverのような商用データベースに対して、MySQLやPostgreSQLのようなOSSデータベースは如何に追従しているのでしょうか。
そしてAmazon AuroraやGCPのCloud Spannerのようにクラウドならではの新しい形のデータベースも次々に生まれています。
これらを題材に今、あなたが新しいサービスを作る時、10年戦えるデータベースの作り方を見つけていきましょう。
キャッシュはパフォーマンスを劇的に改善する効果がある反面、使うと簡単にはやめられない複雑性と中毒性があります。
その特性から キャッシュは麻薬 と言われ、安易な利用は忌避されています。
しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。
そこで今回は、キャッシュの手法と有効な場面での活用方法、逆に失敗してしまいやすい注意事項を説明しながら、実務の中でのキャッシュとの付き合い方を説明します。
皆さん普段どのようにPHP実行環境を組んでますか?私はなんだかんだLAMP推しです。もうCDNが前段にいればええやろ。
さておき、PHPはモジュラ式に拡張できるしインタプリタ(諸説あります)だし、php.iniは山ほどあるし、httpdは別途に必要だしで実は非常に複雑です。
つまりメンドウ。なので多くの人がパッケージマネージャでいれてると思います。
よって、気になる人は「なんかPHPの環境構築は{所定のブログ記事}のコピペでやってるな〜秘伝のタレだな〜」みたいな感じと思います、どうですか?
(まあ私もremiったりondrejつかったりもしますのでそれは間違いではありません)
しかし「PHP環境のビルド」は色々出来るんです。今回は真心を込めて「カリっとしたPHPをつくる」そういう遊びをしてみませんか?
WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。
WEBセキュリティの情報や教科書はたくさんありますが、全てを勉強するのは大変です。
実際に現場であった事故やコードの例を紹介し、最近のフレームワークを活用したWEB開発で起こりがちなセキュリティ事例をお話しします。
◆対象者
・ある程度PHPでWEBアプリケーション開発をしているジュニアorミドルエンジニア
・チームが書くコードをセキュアにしたいリードエンジニア
◆書くこと
・コードレビューしてたらこんな危ない書き方があった!
・こんな脆弱性があった!
・こんな攻撃を受けた!
WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。
WEBセキュリティの情報や教科書はたくさんあります。
皆さんも勉強されていることでしょう。
しかし、セキュリティ事故が起きたら一体どんなことが起きるのでしょうか?
PHPで書かれたWEBアプリケーションが攻撃され、実際にセキュリティ事故が起きた時にとても辛かった思い出を面白おかしく話します。
◆対象者
・ある程度PHPでWEBアプリケーション開発をしている人
◆話すこと
・前提の状況
・実際に起きたこと
・どんな対応が起きたか
・どれだけ寝れなかったか
C 言語で書かれている PHP 処理系の内部にはクラスを表現するもの、オブジェクトを表現するもの、配列を表現するもの、値を表現するもの、実行中のコールフレームを保存するものなど、様々な構造体が存在しています。これらがどのような構造をしているか、各フィールドがどのような意味を持ちどのような使われ方をするか、とりとめなく漫然と書き出してみます
世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか?
PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことを具体的なケーススタディやコード例を交えてお伝えしていきます。
PHPerKaigiでは上級者向けの面白いトークや記事が沢山ありますが、技術コミュニティとして裾野を広げるためには、初中級者向けのコンテンツも有用と考えます。
これらの方々へ有益な情報をなることを期待します。
◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者
◆書くこと
・バグを生み出しづらい書き方
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・コーディング規約
・エラーメッセージの見方
チームの成長と改善を促進するために、定期的なふりかえりは重要です。
しかし、「単なる会議に終わってしまう」、「カイゼンが継続しない」、「なんか微妙な雰囲気で終わってしまう」...など、ふりかえり自体がなんだかうまくいかないことってありませんか?
実際に私も上記の経験をしてきました。その失敗たちを元にカイゼンを重ねていったわたしの「最強のふりかえりファシリテーター法」をお話します!
私が大事にしていること
オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。
どのSOLID原則に違反しているか
自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します!!
開発って実はお金かかるんです!
え、そんなのは知ってる?
じゃあ、新しい機能を作るとき、どのくらいのお金がどこにかかるか、考えたことあります?
私は詳細まで考えたことはないです。なので今から実際のプロダクトを例に考えてみましょう!
たとえば、PHPだけじゃWebサービスは提供できませんよね。
そのWebサービスがAWSなどの従量課金制のプラットフォームで動いているならアクセス量に応じてお金がかかりますよね。
PHPとそのサービスを動かす仕組み自体にも当然運用コストが乗ってきます。
ところでPHPを書いている人は?仕組みを組み立てている人は?そのサービスはエンジニアだけいれば成り立ちます?
つまり、機能の開発にも運用にもお金がかかるのです。
当然時間もかかるので、綺麗事抜きに、これから作る機能は、そのお金を払ってまでも作る価値はありますか?と問いかけて作っていったほうがいいのはないでしょうか。
その機能を作ることでどれだけの人の労力と時間を削減できるのか、それをお金に換算するといくらなのか、を考えることで
あらためて自分たちが生み出すことができる価値の大きさを知ることができるような気がしています。
「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい!」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。
それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。
そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。
本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。
このトークの対象
テストコードの品質は、開発プロセスにおいてとても大事です。
その中でも、適切なAssertionメソッドの使用は、テストコードが読みやすく理解しやすいものにする一歩と言えます。
私は読みやすいテストの一歩は「適切なAssertionを使うこと」だと思っています。
いつも「assertSame」にしちゃっていませんか?Assertionメソッドはたくさんあります!このトークで学んでいきましょう!!
スクラムでの開発にはレビュー会という、スプリント内で実装した価値をお見せする場がある。
決まっていない部分はダミー実装で後回しにして、Interfaceを切ってIOだけを明確にして、とそこまでは順調だった。
だがしかし、レビュー会までにプロダクトは出来上がらなかった。
不確実なことを抽象のままできるだけ後回しにして実装したのに、詳細の実装が間に合わなくなってしまったのはなぜなのかを実装の進め方とともに振り返ってみようと思う。
PHPStan使っていますか? PHPのコードを分析すれば、たちどころに型がつく、イカしたツールです。
現代のPHPStanはPHPコード上でうまくやればかなりの部分が型がつくのですが、とても残念なことにそれだけで完全な開発体験になるようなものでもありません。
本稿では融通のきかないPHPStanを拡張してうまく手なずけれやれるようになるための初歩をまとめます。
AST, ASTというがASTって何かね?
恐らく今や多くの現場でPHPStan, Psalm, Rectorなどの静的解析ツールが利用されているのではないでしょうか。その縁の下にはPHP ParserがいてASTをせっせとつくっています(なんならPHP自体もですがそれはさておき)。PHPの開発現場においてそれは謂わば空気。欠かせないものですが、私たちがそれのことを気に留めることはほとんどありません。
ところで、概念を理解したい時、具体例を確認するという方法があります。そこで、PHPのコードを分析して生成したASTを図示して見える化したいと思います。PHP Parserを用いてAST可視化ツールを実装してみます。せっかくなのでこの9月にpre-releaseなBeta版として公開されたversion 5.xを使ってみます。
PHP Parserから見たPHPの世界をあなたものぞいてみませんか?
このトークでは、ASTを見ます。見ることで理解に迫ります。年に1度、5分だけ、1年分の感謝を込めてASTだけを見つめPHP Parserに想いを馳せる。そんな時間にしたいと思います。
みなさん、サーバレスで動かすPHPはお好きですか? 私は大好きです。
よくサーバレスなマネージドコンテナサービスでWEBアプリを実行しますが、定期実行するジョブもマネージドなサーバレス環境で実行したくありませんか?
そんなあなたのために、3大クラウドそれぞれで定期ジョブ実行するためのポイントやそれぞれのサービスの比較を行い、実際にPHPを動かす際のポイントなどをお話します!
・Dockerなどコンテナについてなんとなく聞いたことがあり、ちょっと動かしてみたい人
・サーバレスでコンテナを使った定期ジョブをしたい方
・サーバレスという言葉に惹かれる人
・各社のサーバレス コンテナサービスの比較(特徴や料金体系など)
・実際にトライしてみての気づき
マネジメント、大変ですよね。
マネジメントはいわゆるヒト、モノ、カネや事業、チームに関わる抽象度が高い課題を無限になんとかしていく必要があります。
様々な事業や企業がありますが、ヒトと向き合うところだけはあらゆるところで共通だと思います。
このLTでは、あくまで自分がやることになったマネージャーの仕事を少しして、エンジニアリングマネージャーに興味がある人にこんな仕事だよとお話した上で、エンジニアがとにかく戸惑うであろうヒトのマネジメントについて話します。
将来エンジニアリングマネージャーやってみようかな〜だったり、なんかメンバーや上司、部下との関係上手く行かないな〜って人に聞いてもらえると嬉しいです。
勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい!
でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ?
発表したいけど発表ネタが浮かばないから、手を挙げられない。
その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ?って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね?
そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。
ハッシュテーブルは、文字列のキーから高速で値を取り出すことができる強力なデータ構造です。私たちの身近なPHPの配列が良い例です。そして、チェイン法はハッシュテーブル実装時に生じるハッシュの衝突という問題を解決するための実装方法です。
これらの技術はPHPの配列の内部実装でも利用されており、PHPerにとって必須の知識であると言っても過言ではありません!
今回は、ハッシュテーブルとチェイン法についてより理解を深めるために、PHPのSplFixedArray(C言語の配列と似たような挙動をもつ)を使ってその実装を行います。
当時、自分の所属する組織では品質チェックのツールが何も入っていなかったため、
PHPStanやPHP CodeSnifferを導入しようと考えました。
ただ、受託開発の場合はとにかく作って終わりのシーンも少なくなく、
中々継続的な改善やチェックツールの導入にメリットを感じてもらえないシーンが多々あります。
それでもメリットを伝え、導入自体はできましたが失敗したことも多く、反省点が色々と見えてきました。
このLTでは導入しようとして失敗したこと、反省して改善したことや現在の状況等をお話しします。