本セッションでは拡張性に重きを置いたシステムについてお話しします。
マイクロサービス・モジュラモノリスとアーキテクチャスタイルは多様化していますが、重要なのはスタイルではありません。
本セッションではスケーラビリティを重視します。
スケーラビリティはリソース・コード・組織など様々な観点があり、それらのスケーラビリティの向上はいずれもビジネスにポジティブなインパクトを与えます。
本セッションではそれらを担保するために必要な要素が何かを深堀りし、それらを実現する具体的な技術スタックやアーキテクチャを模索します。
その中でPHPを主軸としたとき、活用しやすい箇所・しづらい箇所についても言及します。
得られる知識:
スケーラビリティの多面的な観点の理解
スケーラビリティを担保する重要な要素とその実現方法
スケーラブルなシステムを実現するための実践的な知識と洞察
PHPは裾野の広い言語です。WordPress、Laravelをはじめ、Web開発で広く使われており、コミュニティも非常に活発です。
そんな楽しげなコミュニティに異業種から転職したジョブチェンPHPerだって参加したい!
というわけで今年のPHPerKaigiからプロポーザルを送るようになり、先日無事福岡の地方カンファレンスで登壇デビューを果たしました!
このトークではその中で得られた知見についてお話させて頂きます。
これを機にプロポーザル送ってみようかな?という人が一人でも増えれば幸いです!
フロー効率という言葉を最近耳にしたことはありますか?
その対比としてリソース効率が用いられているのを目にしたことはありませんか?
このトークでは「フロー効率」と「リソース効率」という言葉をキーワードに
という3つのテーマを使って、我々開発者を取り巻く環境における事例を交えながら人間にとって最も重要な資源である「時間」について深掘りしていきます。
タイトル見て共感した人、このトークのターゲットです。
データベースにおいてインデックスとは超重要な要素の1つです。
適切にインデックスを貼ることで処理を効率よく行うことができます。
「なんかよく分かんないけどじゃあとりあえず全部にインデックス貼っとくか」
これはアンチパターンです。
何故闇雲にインデックスを貼ってはいけないのか、適切にインデックス貼るとはどういうことか
実際に計測したデータを交えながらお話したいと思います。
プルリクのサイズは小さい方が良い。
ただし大きい/小さいの定義は人それぞれ。
大きいかな?小さいかな?を自身で気付くタイミングがない。
ということで大きい/小さいを定義して、プルリク作成時に気付ける/意識できるような仕組みをGithub Actionsに作ってみました!
開発していると何かと話に出る「具体と抽象」
何かを説明する時に抽象度ってとても大事だと思います。
例えばWebアプリケーションがどうやって動いているかを説明する際に、説明したい箇所や相手によって話す内容は異なるかと思います。
ネットワークの話が必要か?
Webサーバーの話が必要か?
内部で動いている言語処理の話が必要か?
これが理解できていないと、例えば営業の人にクエリの話を出してしまってポカンとされてしまう訳です。
逆に適切な抽象度で話ができれば人に説明するのがグンとうまくなります。
本LTでは抽象度についてお話したいと思います。
こう思った経験、誰しもあるのではないでしょうか?
恐怖とはつまり「分からなさ」に起因していると私は考えています。
触った時の影響が分からないものは誰しも触りたくないと感じるかと思います。
本LTでは、そんな開発するうえでの恐怖にどうやって立ち向かっていくのか、お話できればと思います。
ブロックチェーンとは、一般的には、「取引履歴を暗号技術によって過去から1本の鎖のようにつなげ、正確な取引履歴を維持しようとする技術」とされています。
今回はPHPを使ってブロックチェーンのサンプルアプリを実装する話をします!具体的にはコミュニティに招待するとトークンが付与されるアプリを作る予定です。
本当にPHPでも実装できるの?と疑問を抱いている方は是非聞いてください!
私は沖縄で約6年間システム開発会社を経営してます。
最初は1人で始めた会社でしたが、今は全体で12人、エンジニアは8人となりました。
これまで採用活動でやってきたことや地方での採用事情をお話しできればと思います。
・エンジニア向けイベント開催
・未経験の人を採用してエンジニアとして育成
・地方に即戦力エンジニアはどれだけいるのか?
・地方でスカウト媒体を使ってエンジニアは採用できるの?
・地方にエンジニア向け勉強会ってあるのか?
長年稼働しているサービスのDBを運用途中からマイグレーション管理した話をします。
PHPでマイグレーションを扱うのに、例えばLaravelのマイグレーションの利用を考えると思います。
複数のサービスアプリケーションで接続しているDB、どのアプリケーションでマイグレーション管理が最適なのかと考えました。
いや、、、サービスアプリケーション側でマイグレーションを持たせず、独立したマイグレーションアプリケーションを立ち上げましょう。
その時に最適だったのがCakePHPが公式に採用しているPhinx。
について話をします。
これまで20年間にわたりPHPで開発したB向けのクラウドサービスを運営してまいりました。
現在はGMO医療予約技術研究所という会社で医療向けDXサービスを開発・運営しています。
今回は、PHPを利用した大規模クラウドサービス運営に関する工夫やノウハウを凝縮して発表したいと考えております。
<コンテンツ>
・アーキテクチャ
→フレームワークの構成
→インフラアーキテクチャ
→セキュリティ対策
・キャパシティ管理
→WEBサーバとメモリの関係、メモリの節約テクニック
→転送量の対策(WEBブラウザ上のメモリや処理効率対策)
・エラー検知
→プロセス実行時間や例外の監視と通知
・マインドセット
→「トラブル時の解決速度」にフォーカス
→ソースコードはラブレター
皆さん、「読みたいな」と思える本に出会えていますか?
私は「趣味は何ですか?」「はい、積ん読を増やすことです」と胸を張って答えられるくらい、ここ数年は家に本が増えています。
読書をしてインプットをする、知識を増やすというのは非常に大事なことです。
それと同じくらい、「自分を高めてくれそうな知識との出会い方」も大事なのではないでしょうか?
題して、「積ん読を増やす技術」です。
このLTでは、実際に体験したことをお伝えしながら
「どうやって本を買っているか、見つけるのか」「積ん読を増やすことで広がる世界」について、紐解いていきます。
新しくツールやルールを整備する際に、導入したツールが全然使われてなかったり、ルールが浸透していないといったことがありませんか?
私たちのチームでは、新しくツールやルールを整備する際に、アンバサダーを任命して導入を主導して貰ってます。
本トークでは、アンバサダーとしてどのような活動をしてツールやルールの導入を進めているかを紹介します!
ディップでは、生成系 AI を全社的に活用しています。
開発チームでは開発の生産性向上のため、GitHub Copilotを導入し活用を進めています。
本トークでは、このような AI ツールの活用による開発生産性向上の効果を測定するための指標をどのように検討し、どのように計測しているかについて紹介します。
これから開発現場にAIツールを導入予定の方、またAIによる生産性向上の効果を測りたい方々におすすめのトークです!
私たちのチームでは、サービスのメトリクス監視やパフォーマンス可視化に New Relic を活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
最近では、AIを用いたツールやサービスを使用することで、チームの生産性がどう向上したかを測る指標も追加しました。
本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を紹介します。
サービスや開発組織のパフォーマンスの可視化に興味のある方におすすめのトークです!
組織に属している人だったら大抵「3年後のキャリアビジョンと目標書いて提出して」と言われたこと、あるのではないでしょうか?
キャリアビジョンって言われても…って人多いと思います。
私は3年前の「3年後のキャリアビジョン」に「マネージャーになる」と書き、今期からマネージャーに就任しました。
がむしゃらに頑張った、のもありますがキャリアの描き方と目標の立て方が良かったのだと思っています。
本LTではキャリアビジョンと良い目標の立て方についてお話できればと思います。
Web開発をしているとChrome Devtoolsは欠かせないツールかと思います。
ただ多機能過ぎて何が何だが分からないという方、多いのではないでしょうか?
本LTではChrome Devtoolsについて私が知っている小技を可能な限り紹介しようと思います。
雰囲気で使っている方、是非本LTを聞いて明日からの開発にお役立てください!
複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ!マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。
「共通基盤だ!」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか?
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ!」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします。
私見ですが、年金は破綻はしないけど、ここに老後を頼れないですよね。一方健康寿命はこれからの20年で10年延びる予想があります。
そして投資で増やしたり、貯金をためても、よほどの金額がないと、くつぶしていく可能性があります。
やはり必要なのは中高年になっても副業や起業で稼げる方法ではないかと思うのです。
もちろんエンジニアの方で技術力があれば食べていけると思うのですが、今と同じ見積方法で工数を見積もったり、時間給で金額をいただくのは、契約が途切れるきっかけが多く、常に営業行為が必要になることが多いです。安定した収入を得るためには、極論、営業をしないで稼げる方法が好ましいと考えています。(ネットワークビジネスの話じゃないですよ!)
そこでこのセッションではエンジニア向けに安定した副業や起業で収入を得られる考え方と私自身が成功した実例を解説したいと考えています。
Laravel に親しんで早ウン年…次のプロジェクトは CakePHP !?
そんな状況から、どうにかE2Eテストを書くところまで至った課程と、
その間に直面した問題・解決策についてお話します。