このセッションでは、ターミナル上で動作するリバーシを作成しつつ、テスト駆動開発(TDD)の基本を解説します。
一部、ライブコーディングを取り入れ、PHPを使用してリバーシを開発するプロセスを実際に見ていく予定です。
セッションの内容 :
主な対象者 :
業務でPHPを使ったバッチを設計することあり、先輩エンジニアから様々なQA指摘を受け、学んだバッチ作成時に考慮する自分的Tipsを紹介したいと思います。
具体的にはエラーハンドリング処理、テスタビリティを意識したメソッド分割、ロギング処理、トランザクション分割、などをPHPのコード例を用いて解説します。
対象は若手エンジニア向けとなっています。自分も3年目のエンジニアでバッチ作成で苦労したためそういった方の助けになればと思っています。
NotionにはデータベースにCSVでレコードを一括投入するための 「CSV取り込み」 という機能が標準で搭載されています。
が、少なくとも2023年11月現在においては正直だいぶ貧弱な機能で、本当に最低限のことしかできません。
(例えば、インポートできるプロパティの種類が限られている、ページ本文はインポートできない、「名前」カラムの値が重複している行があると正常にインポートできない、など)
そこで最近、必要に迫られてPHPでNotionのデータベースにCSVをおインポートするフォームを自作しました。
このトークでは、このフォームの具体的な実装手順を、デモを交えつつサクッと解説します。
どうも、要件ヒアリングに自信ニキです。
私はフリーランスエンジニアとして受託開発のお仕事をよく頂くのですが、お客さんとの対話・ヒアリングを割と得意としています。
お客さんはシステム開発のプロではないので、説明が的を射ないことも多く、複雑なシステム要件のヒアリングには根気と体力を要しますよね。
そればかりか、なかなか合意や結論に辿り着けずいたずらに時間が奪われた挙句、結局失注して悲しみ、といった経験はないでしょうか。
私はよくお客さんから「1しか言ってないのに100のアウトプット出てくるんやが」「話が早すぎてもはや笑える」などと言われます。
一体私はお客さんとの対話中に何を考え、どんな手順でヒアリングを進めているのでしょうか。
このLTでは、お客さんとの対話中の私の頭の中身をまるっと皆さんにシェアします。
明日からのお客さんとの対話・ヒアリングに少しでも役立てていただけると嬉しいです!
Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか?
実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。
このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう!
Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか?
Docker経由でしかPHPを使わないみたいな猛者スタイルで行ければいいのかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
このソリューションはいざ導入しようとするとYak Shavingの嵐が待っていて(実体験)非常に面倒だったりします。
というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います!
令和になっても相変わらず紙の書類の需要は大きく、Webアプリ開発においても帳票印刷機能は多くの案件で要求されます。
しかし、これがとにかく面倒くさい。
帳票印刷機能を実装したことのある方には強く共感していただけると思います。
そんな面倒で難しい帳票印刷ですが、実は私は既に数年前に最強無敵のソリューションを編み出し済みです。
という条件を満たせる唯一(当社調べ)の方法です。
このトークでは、この至高のソリューションを具体的に解説します!
API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、
Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。
このトークでは、API Platformの導入方法から、State Provider・カスタムコントローラ・State Processorといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。
皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです!
API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIを作れてしまう優れもので、
Symfonyのエコシステムにおいては既に決定版となっています。
しかし、ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、
痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあります。
このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。
API Platformの実戦投入、あるいはその検討の一助になれば幸いです!
皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか?
私はあります(※)。
PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。
私が担当しているメール共有サービスのメールディーラーでバージョンアップ後に、一部の受信メールが文字化けをしました。
受信したメールのエンコード時にmb_detect_encodingを使っていたからです。
下位互換性がないため文字化けを回避することができず、結果的にメールヘッダに文字コードの指定がないRFCに準拠していないメールまで対応しました。
メールディーラーの保守運用・顧客対応チームのリーダである私が顧客対応で泣きをみたことを中心にお話いたします。
私と同様に顧客対応されているエンジニアの方々の参考になれば幸いです。
※実際には飛び込んでいません
このトークを通じて、業務等における成長の加速のヒントを提供します。
私はお仕事として「マネジメント」を任された場面がありました。
その一環として、メンバーの成長支援や目標設定、日々の伴走も扱ったりします。
評価の場面では、「何を学んだか」「どんな変化があったか」に興味をもって聞こうとします。
・・が、うまく「学び」を得られている人と、ただ単に「経験した」との区別が進んでいない人も多いと感じました。
「学ぶ」「知る」「気付く」の間には、何があるでしょう?
どれも重要ですが、能力を引き出すのに強く関与するのは「学ぶ」だと考えています。
この違いの認識は、学習や上達の違いをもたらします。
経験を分析し、次に活かせるか?を支えるのが、学びです。
EMの立場から見た際の、「どうして(他の近接概念と比べて)特に重要なのか」「どんな人が、普段の行動を学びに結び付けられているか」をお話します。
良いコード、読みやすいコード…欲しいですよね
経験を積むほどに、コードを書くのは上手くなることでしょう
ですが!!
「1発で綺麗に書ける」とはならないのです
それどころか、「書き直す」のが当たり前になっていきます
つまり、リファクタリングです。長く付き合えるコードを生むには、コイツが欠かせません
みんな、色んな所で、昼夜を問わず、当たり前にリファクタリングに手を出しているのです
1回味わったら、きっと忘れられなくなりますよ
このトークでは、「初めてのリファクタリング」をテーマに、最初の1歩を踏み出すための武器を提供します
一緒に「めちゃ長ぇメソッド」を飼い慣らしていきましょう!
私が最初に出会ったプログラミング言語は大学の授業で勉強したC言語でした。授業や試験で問題を解くためにC言語を勉強していました。
ですが、授業外でHTMLやCSS, JavaScriptでWEBサイトを制作し、そこでPHPに出会いプログラミングが好きになりました。ここで初めて「プログラミング = 授業で勉強するもの」の考え方がなくなりました。プログラミングでWEBアプリケーションを作成し、エラーに苦しんで、実際に動かす体験は嬉しさと楽しさでワクワクしていました。
最初はノンフレームワークのペライチのコードを書き、次はフレームワークで開発、一周回ってノンフレームワークで開発しました。
本セッションでは、PHPで「作ることが楽しい」体験から「コードが書ける、読める楽しさ」に変化していった経験についてお話しします。
SI業界で小規模から大規模開発まで一通り経験し、管理職もこなしてきて、経験値だけは十分に積んだと思っていた私が、SaaS業界ではその経験値を生かすことができたのでしょうか。
SaaS会社でテックリードとして転生した私が、開発視点からマネージメント視点等いろいろな気づきをお話します。
・開発フローやシステム開発の考え方は同じなようで何が違う?
・プロジェクトマネジメントではなくてプロダクトマネジメント
・SI業界の経験値は結局生かすことができたのか?
しばらくPHP界隈から離れていたPHP5上級認定技術者資格者が、久しぶりにPHPの世界に戻ってくると、浦島太郎になっていました。
浦島太郎になって改めて学びなおしたポイントは、これからPHPを学ぼうとしている人や、他の言語からPHPを触ることになった人にもきっと活かせるはず。
PHP5の時代の苦労話も織り交ぜながらお話したいと思います。
・変わっていて驚いた言語仕様の変化
・PSRって何?
・外部ライブラリの使い方
・他の言語とごっちゃになってしまったポイント
古くからあるサービスには、機能強化とともにサブシステムが増えていきました。
最初は良いけれど、
・検証サーバーは共用だったり、個人毎だったりバラバラに存在
・共用サーバーには、交代して使用する為に待ち時間が発生
・複数の人が使うので、テストデータがぐちゃぐちゃに
・サブシステムが増える度にサーバーも増えてくる
・当然、ソース修正や管理、デプロイもややこしくなる
というような問題が、だんだん見えてきました。
では、この問題の改善にチャレンジしよう!とは言いつつ、
「今まで使い慣れたエディタやリポジトリ構成、開発の流れは変えたくないよ」という声もあります。
さて、どの様に改善していったでしょうか。
・Dockerで共用サーバーを廃止して、メンバー毎の環境を整理しましょう
・コンテナ環境でも今まで通りPhpStormで開発作業ができるようにしましょう
・ユニットテストもうまく連携しましょう
業務でサポートの切れた全文検索エンジンSolrが使われていた社内ツールをElasticsearchにリプレースしました。
また、Solrへのインデックス追加は5分おきにバッチで行っていましたがその処理が2か月終わらない問題もありました。
このLTでは既存ツールで使われているライブラリをリプレースするときに考えるべきこと、どのようにバッチ処理を早くしたかを紹介したいと思います。
PHP8.1では、いくつかのリソースがobjectに移行しました。
例えば
pgsql result リソース → PgSql\Result オブジェクト
pgsql link リソース → PgSql\Connection オブジェクト
などです。
私が開発しているMaildealerは、すでに開発から20年以上経過しているレガシープロダクトです。
その中に存在する PgSQL 用の独自ライブラリは、すべてがリソースで扱うことが前提のコードになっていました。
マイナーリリースで気軽に入れられた変更が、レガシープロダクトに与えた影響と、その解決方法をお話します!
みなさんは、PHPでOfficeファイルを取り扱いと思ったことはありますか?
もちろん、ありますよね?
このLTでは、PHPでOfficeファイルを取り扱う方法と、実際にどのようにプロダクトに使用しているかをお伝えします!
このLTで話すこと
・PHPOfficeライブラリの基本的な使い方
・読み込んだOfficeファイルをどのように利用したか
・PHPOfficeライブラリの難点
話さないこと
・Officeファイルの仕様
・PHPOfficeの細かい使い方
このLTを聞いて、みなさんもPHPでOfficeファイルを扱えるようになりましょう!