新入社員がテストコードを書けない場合、どのように教えますか?
日頃書く人は感覚的に書けますが、書いたことのない人はコツを掴むまで時間がかかってしまうものと思います。
皆様も経験があるのではないでしょうか?
本セッションでは、そんなテストコードのチュートリアルをpublicリポジトリとして公開・そのリポジトリの利用方法のお話をします。
Dockerを利用することで、Docker環境さえ整っていれば誰でもLaravelフレームワーク内でPHPUnitのテストを書くための問題集にチャレンジできる内容となっております。
全ての操作用のコマンドやREADMEを用意しているので、Dockerの知識がなくてもテストの実行やテスト用DBの中身を確認できます。
これを機にテストコードを書けるようになってみませんか?
対象者:
・テストコードを知りたい方
・育成コストに悩んでいる方
SEOとは、検索エンジンを通じてWebサイトへの集客を増やし、成果を向上させるマーケティング手法の一つです。
私はh1タグの改修から新規コンテンツの追加まで、これまで大小関わらずSEO領域の開発に携わってきました。
しかし、あるとき「SEOのためのこのプログラム改修が、システムにとって本当に良い選択なのか?」と疑問を抱いたことがありました。
このトークでは、私の経験から "SEO施策を実行する中で感じたエンジニア的ジレンマ" についてご紹介します。
ビジネス要件をテクニカルな仕様に落とし込む際、
「SEOの考え方」と「最適なプログラム設計」の間で陥った葛藤にどう向き合うことにしたのか。
SEO領域でエンジニアリングするPHPerの考え方の変化を、SEOの魅力とともにお伝えします!
\ 日々葛藤しとるけど、やっぱしSEO好きやけん!みんなに知ってほしいっちゃ〜٩('ω')و //
自身の書いたコードを誰かに伝わりやすいものにするための補足として、コメントを残すことがあります。
しかし運用や改修を重ねていくと、実装ばかりに気を取られてしまい、気づいたらコメントがすらごついーになっている可能性があります。
本セッションでは、すらごついーコメントアウトを生まないために、コードを書く上で残すべきコメント・残さないべきコメントについてお話します。
また、コメントを残さないようにするためのリファクタリングのテクニックや、コメントとの向き合い方についての考え方を紹介できればと思います。
対象者:
・コメントを添えるのが癖になっている方
・すらごついーコメントを見かけたことがある方
みなさんは技術イベントに参加する際、オンラインで参加したことはありますか?
オンライン配信はイベントが開催されるオフラインの現地に足を運ばずともイベントを楽しむことができるというとても優れた手段ではありますが、
その要望に応え、参加者の方が見やすい形で広く提供するためには様々な課題があります。
昨年末から、いきなり「技術カンファレンス」や「技術イベント」などの配信を始めた初心者が、わずか半年で15回もの大小さまざまなオンライン配信をしてきました。
様々な形態の配信をする中で直面したトラブルで得た学びや、オンライン配信を作る側としての面白い裏側の秘密をお届けします!
【実績】
・PHP勉強会@東京
・PHPcon小田原2024(北海道、関西も当日協力)
など
【このトークをおすすめしたい人】
・オンライン配信を自らやる事に興味がある人
・普段、何気なくイベントにオンライン参加している人
私が異業種からITエンジニアを目指した頃は、転職希望者が多くいわば駆け出しエンジニア戦国時代。
その時代の波に揉まれながらエンジニアを目指す旅路は冒険の連続でした。
プログラミングの基礎を学びながら転職活動をするも難航してなかなか決まらず、
当初ITエンジニアとしてのキャリアは積めそうに無い状況にありました。
そんな状況だった私がITエンジニアとしてのキャリアパスをどのように築いていったのか、
それぞれのステップで直面した課題と乗り越えた方法についてお話しします。
道は一直線ではありません。様々な選択肢があり、選んだ道によって結果は大きく変わります。
私の経験がこれからのキャリアを考える皆さんの一助となれば幸いです。
QAエンジニアの経験に基づく「勘」や「独自の観点」は、製品の問題点を見つけ出すのに役立つことがあります。
しかし、このような知見は、そのままではチームメンバーに伝達するのが困難です。
結果として、チーム内でのよりよい役割分担が妨げられてしまったり、新しくチームに参加したメンバーに有用な情報を伝えられなかったりすることがあります。
そこで、本トークでは、(あくまで私の経験をベースにして)「QAエンジニアの勘」と呼ばれているものを言語化し、伝達可能にすることを試みようと思います。
開発をしていると手が止まることがあります。
実装したい機能を実現するための技術的課題がある場合は当然ですが、そうでないときも手が止まることがあります。
そんなとき何に悩んでいると思いますか?
いざ聞いてみると「そんなの今悩む必要ないよ」と、思いきや実は今悩んでいたほうがいいことがあるんです。というかあると思って悩んで手が止まっています。
N=1ですが、ある開発者の手が止まりポイントを紹介します。
理由を聞いて、何かしら得られることがあるかもしれません(し、そんなこともないかもしれません)。
皆さんの「手が止まりポイント」も聞きたいです。語りましょう。
弊社ではCakePHP1.3を使用しています。
CakePHP1.3では、DBから取得したデータは配列となって返されます。
その取得した配列をそのままviewファイルに渡して、それを使ってHTMLを生成します。
それだけならまだいいんです。
今となっては度重なる機能追加によって、その配列に様々なデータが追加されています。
その配列内にはテーブルのカラムとしては存在しないデータも含まれており、非常にカオスな配列と化しています。
その状態を改善すべく、なるべくオブジェクトを使用して、既存のコードに立ち向かっていっているという話をします。
あなたはいくつのプログラミング言語を使えますか?
プログラミング言語にはさまざまな異なった特徴があり、「達人プログラマー」という書籍では、年にひとつの言語を学ぶことを薦めています。
Lispというプログラミング言語は1959年括弧まみれと揶揄されますが、PHPとは異なる多くの言語的特徴、多くの機能を持っています。
このトークでは、PhelというPHP向けに実装されたLisp方言をテーマに、Lisp言語の初歩とPHPとの関わりについて学んでいきましょう。
エンジニアがサービスを理解するタイミングは、果たして機能開発やバグ修正に限られるのでしょうか?
私はそれに加えて、機能を整理する際にも深い理解が必要だと考えています。
実際、既存のリソースを統合または削除する行為は、機能追加やバグ修正と比較してもより高いリスクを伴います。
なぜなら誤って必要な機能を削除してしまった場合、予期せぬ障害につながる可能性があるからです。
そのため、これらの作業を安全に進めるには、インフラやドメインを含む広範な知識が必要不可欠です。
本トークでは創業当初から運用されているサービスの統合や整理を通じて、サービスそのものへの理解を深めた経験を共有します。
「レガシーなコードは嫌」「リファクタリングして認知負荷の低いコードにしたい」と思っていませんか?
でもいざリファクタリングして、使ってないと思って消したコードが実は使われてて危うく障害になりかけたり、
テストコードを書こうにも、テストコードが書きづらいためにリファクタリングし辛いことも多々あるはずです。
このセッションでは、そういったレガシーなコードに対し、どのようにリファクタリングをしていくとよいか、具体的なテクニックについて話します。
皆さんは「Azalea(アゼリア)」というPHPフレームワークをご存知でしょうか?
…すみません、多分知っている方はほぼいないと思います。
なぜならこれはサイボウズのGaroonというプロダクトで使用されている独自フレームワークだからです。
GaroonはPHP4の時代から提供されてきた、20年以上の歴史を持つプロダクトです。
昔はフレームワークの選択肢もなく、Garoonでは独自のフレームワークを構築して開発がされてきました、それがAzaleaです。
Garoonは今でも同じフレームワークで動いています。これはやばいです、色んな意味で。
このトークでは、なぜ今でもこのフレームワークが使われ、動いているのかについてお話しします。
■ 話すこと
みなさん、PHPカンファレンス登壇してますかー?
私はまだ登壇したことがありません!
これまで私はPHPカンファレンスに参加し、登壇者の皆さんのプレゼンテーションを楽しみながらも、自分自身が登壇することには一歩踏み出せませんでした。。
しかし、あるきっかけが私の心を動かし、登壇に向けたハードルを一つずつ乗り越えてきました。その過程で得た経験や気づき、そして成長の過程を皆さんにご紹介します!
登壇に興味があるけれども踏み出せない方、自分の学びを話してみたいけれど不安を感じている方、ぜひこのLTでお待ちしております!
PHPには様々なフレームワークが存在します。
Laravel, Symfony, CakePHP, BEAR.Sunday etc..
Composer化したライブラリが、特定のフレームワークに依存してしまっては、利用ユーザーが限定されてしまうことになります。
汎用的にライブラリが扱えるように機能提供できたら素晴らしいことです。
本トークではとある自作ライブラリをフレームワークを乗り換えしても利用可能な様に見直しを行うことを題材に試行錯誤する内容を発表します。
【概要】
チームへ質問する心理的ハードル、高くないですか?「自分で調べても分からなかったからチームに聞いてみよう、質問の文章も分かりやすく書けたぞ!」それでもいざ質問を投げる時に怖くなりませんか?
チームの人間関係は良いはずなのに、なぜこうなってしまうのでしょうか。
本トークでは、チームへの質問が怖く感じる原因と解決方法、さらに質問を通じてチームへ貢献する方法についてご紹介します。
【トークの対象者】
・チームへ質問するのが怖いと感じている方
【トークの目的】
・チームへ質問する心理的ハードルを下げる
【内容】
・なぜ質問するのが怖いのか〜過去のトラウマ?もう新人ではないから?自分ばかり質問している気がする…
・質問のハードルを下げる方法〜質問者は自信、チームは心理的安全性を高めよう
・質問を通じてチームへ貢献する方法〜その「分からない」は貴重です!チームに知見を共有しよう
Dockerにリバースプロキシを導入することで、異なるプロジェクトの開発環境を同時に複数立ち上げられるようになった話をします。
私が主催するカンファレンスではSNSアイコンが印刷された名札をご用意しています。
この名札は「バリアブル印刷」といって印刷所に「このIllustratorデータをテンプレートにしてココにアイコンをココに名前を入れて下さい」的にお願いして作っていますが、なかなかツラく時間がかかる作業です。
今年3月に開催されたPHPerKaigi 2024ではカンファレンス運営支援ツールforteeに名札生成機能を実装し、印刷所への依頼から作業完了までの日数を3営業日まで縮めることができました。
このトークでは印刷所に入稿できる名札データをPHPでいかにして作るかをお話しします。透明色入りPDFデータ、CMYK変換、フォント埋込など、泥臭く手探りの世界でどう苦しみ、どう解決したかをお楽しみください。
あなたの好きなエディタは何ですか?
自分は長らくVSCodeを愛して生きてきたのですが、
先日とあるKaigiでPHPStormを勧められて以来、PHPStormに恋をしてしまいました。
このトークでは、PHPStormのライセンスがあるにも関わらず頑なにVSCodeを使ってきた自分なりに
PHPStormのいいところや、うまく乗り換えたり使い分けたりするためのあれこれをお伝えします。
話すこと
・ PHPStormについて
・ VSCodeとの比較
・ 乗り換え・使い分けのためのTips
こんな人におすすめ
・ PHPStormに興味があるひと
・ 開発を効率よく進めたいひと
・ VSCodeを愛してやまないひと(損はしないはず…!)
開発に携わりコミットを続けているオープンソースCMSであるbaserCMSの歴史を辿り紹介します。
東京に予定があったため、私はロマンスカーが来るのを待っていた。
数分ほどすると、ロマンスカーの到着を知らせるアナウンス音が流れ始めたので、ボーッと目の前のドアが開くのを待っていた。
ティントン。ティントン。ティントン。
電車のドアがあく音。
ドアは、開かなかった。
「あれ?」と周りを見渡すと、そんなことはなくて、私の目の前にあるドアが開かなかったのだ。
そう、7号車の前のドアは開かなかったのである。そうか、なんか開くドアと開かないドアがあるのか、と少し先まで歩いて電車に乗った時、私は閃いた・・・・・。
「MVCのその先へ」
話すこと
・Controllerとは何で、Modelとは何であるか
・MVCだけでは表現しきれない世界(アーキテクチャ)を表現する
・もし”奇数号車”のドアしか開かなかった場合、どこのレイヤーに変更があると嬉しいのか