トーク

「リーダブルコードさえ書けば, 爆速で開発さえできれば評価される, Code wins arguments...」
こんなイケイケエンジニアになれることを妄想して入社してから約1年が経ちましたが,
この中で学んだのは, キレイなコードを書くことだけがエンジニアの仕事じゃないということです．

このトークでは, がむしゃらに1年間働く中で学んだ, エンジニアとして "本当に評価される" ために理解・実行すべきだと思ったことをお話します．

いわゆる技術の学び方・リーダブルコードの書き方等の技術の話ではなく,
エンジニアが苦手になりがちな「コミュニケーション・マインド・行動」について詳しく触れる予定です．

先日、AWSのLambdaでPHPがサポートされました！

しかし…ネイティブサポートというわけではなかったですね(残念)まあ、色々な都合はわかる所です、PHPのバージョンが固定されないという意味ではよいですよね！

※ 別に5.4に長いことロックされていた某サービスに文句をいっているわけではない

それはそうとして、発表直後こそ大喜びした私ですが、公開されたコードを読んで少々うーん？と思う所もありました。

「これはたしかにPHPだ、PHP-ismになるようにしてある。でも、こうしなくてもよいのでは…？」

他の言語バインディングなどを確認し、PHPならではの設計となっていることに疑問を覚えた私。「こういうふうにしたほうが良いのでは？」というお話をいたします。

また、普通のウェブアプリを普段書く方向けに、構造(使い方ではない)や「一見微妙に見えるこの実装」がなぜ良いのか(勝手なエスパーで)等をお話してみたいと思います。

注意: このトーク自体がLambdaを使う上で直接的に役立つかというと、多分役立ちません！

PHPにはhttpdがない(諸説あります)

そうすると様々な方法で、Httpd(ApacheやNginx)と付き合っていく必要がありますね、

そのあたりの設定についてコピペで済ませる人が多いですが、それってどうなのっておもいませんか？(えっ、おもわない？)

実は「よく知られている(検索で出てくる)設定はセキュリティ的にまずい」、「あるフレームワークだとなんか動かない」とか、しばしば見かける話だったりします。

様々な設定項目を確認して、それぞれの意味を見直してみませんか？

秘伝のconfからの脱出を図りましょう！

私には「Packagist監視おじさん」として活動する顔があります(自称です)。@call_user_funcというTwitter botで、Packagistに投稿されるパッケージを日々監視しています。

Packagistに日々大量に登録されるライブラリですが、私が最近気になっているパッケージをたくさん紹介いたします！

※100連発とかいてありますが、これは「たくさん」という意味で当日100連発になるかは不明です！

聞いたこともない、みたこともない、日本では知られていない、本当に流行っているとは思っていなかった様々なパッケージに付いてご紹介いたします。

PHPがまた早くなった！そういう話結構多いですよね。僕もぐんぐんと伸びるグラフやベンチを貼って「PHPははやくなった！他の言語に負けていない！」とか言ってみる事もしばしば(？)あります。

でも、そうなのかな？本当にPHPって速いのかな？本当に速かったら、皆がgoとかに民族移動しなくてもよいのでは…？(無論、速い以外の理由もあるのでしょうが…！)

いやいやでも結構PHPも速い(ような気がする)し…。

ということでPHPでよく見る「ベンチの欺瞞」あるいは「現実との乖離」、「先入観」についてかんがえてみませんか。

みなさんPHPでサービス提供していますか？何をつかって提供していますか？

Nginx+php-fpm？h2o+php-cgi？IIS+php-fpm？swoole？builtin server？HHVM？Roadrunner？PHP-pm？いやいや、Apache+mod_phpですよね？あるいは諸般の事情でapache+php-cgiかもしれない。

Apache+mod_phpはいろんな人が「いまどきApacheとかないわ〜」とか「もうそもそも考えてもいなかった」とか言っています。でもどう考えてもApache+mod_phpで8割のケースは十分ですよね？？

(勿論、2割のケースにいらっしゃるかもしれません。勿論そうなら泣く泣く(？？)Apacheを使わないのは正しい！！)

これらを比較して、mod_phpを見直してみましょう！

唐突ですがフレームワーク(以後FW)は古代存在しませんでした、よって昭和の人間は自分でFWを書いていたと伝えられています(諸説ある)。

とはいえ今は<?= $php_fw_list; ?>といった素晴らしいFWがありますよね。平成も終わる今、タイトルのようにオレオレフレームワークを書く意味があるのか？その疑問は一理あります。

所でFWとは枠組みで、枠組みは内を支えるものです。つまりFWを書く事で自分の内面を知ることに繋がります。そう、自分を知るためにFWを書くべきです！(？)

平成の終わり、オレオレフレームワークを書き、自分を知りましょう！そして…！

*

• 空のファイルから全部書いたことがない人へ
• FWとはスタイル・ベストプラクティスである
• 最大公約数とパラダイム、時代の移り変わり
• 模倣にはじまり、オリジナルを見出し、はしかにかかり、「大人」になっていく

弊社はクチコミ掲載数日本最大級を誇る結婚準備クチコミ情報サイトのウエディングパークをはじめ、ブライダル専門の5つのメディアを自社で開発・運営しています（主要技術：PHP/Laravel/MySQL/Goなど）。約1年前にQAチームを立ち上げ、不具合を前年度比で半減させることをミッションに日々活動を行っています。特に2004年から運営するウエディングパークでは、長く運用するWebサービスだからこその課題や悩みが多くありました。その中でQAチームとして取り組んだことから成功したこと・失敗したことなどをリアルにお話しさせて頂きます。

プログラミング未経験の大学生がとあるスタートアップでエンジニアを志し、時に挫折し、時に成長を実感しながら歩んだ1年間の物語です。
現在のインターン先では、ソースコードレビューを行う文化があり、インターンを始めてソースコードレビューを知り、経験しました。
インターンを通してレビューには意義のあるレビューと意義のないレビューがあると気づきました。意義のあるレビューはより良いソースコードにしていくために議論を重ねる場、意義のないレビューは本来レビューで指摘されるべきではないつまらないミスだと思います。
ある時、レビューワーが自分のつまらないミスのためにレビュワーの時間を奪っていることに気づきました。そこで、ソースコードレビューで指摘を受ける回数をカウントをして、指摘を減らすために思考錯誤をしていきました。
今回はそんな話をしていきたいと思います。

エンジニアにとって、日常業務の中で様々な成長のきっかけがあると思いますが、業務外の活動においても、自ら楽しみながら学ぶことも重要かと思います。新卒入社後この 2 年間で自主的に取り組んできたことのうち、特に成長を実感できたアクションとして「社内ブログへの投稿」「定期開催されるビアバッシュへの参加」「個人開発」があります。この発表では、どのように考えてこれらを実行してきたか、どのような面で成長できたと感じているか、そしてこれからどうしていくのか、もうすぐ 3 年目を迎える新人エンジニアの想いをお話しようと思います。

NoSQL を勉強したいという動機から MongoDB に興味を持ちました。そのスキーマレス、ドキュメント指向という特徴から学生時代に興味を持っていた、オープンデータのストアに適しているのではという気づきにつながり、そして、世の中でまだつながっていないオープンデータをつなげて活用したいというアイデアへつながりました。技術とアイデアが、オープンデータとオープンデータが、つながるその過程と成果について発表します。

PHP Ver.upの際、システム移行時につまづいた内容を現場の環境を含めてお伝えしたいと思います。
時間があれば他、プラグインの以降も含めてお伝えできればと思います。

専門学校の講師として3年、Laravel を使ったアプリケーション開発の講師をやってきました。

エンジニア教育とはちょっと違う、専門学校でのIT教育みたいな話をします。

日ごろからお世話になっているインターネット。
そのインターネットはネットワーク同士を接続した巨大なネットワークです。
そのネットワーク内でルータがどう動いているのか、ネットワークをつなげるためルータがどれだけ頑張っているのかを少しでも理解したいと思い、ソフトウェアルータを自作しました。
コアな部分はErlangで実装し、追加のモジュール部分はElixirで実装しました。
内容はL2、L3の実装、ルーティングの実装を行い、さらにL4以上をコントロールするためのモジュール実装をどのように行ったのかを話せればと思います。

ネットワークはアプリケーションにない面白いところが沢山あります。
あまり意識することのないネットワークに焦点を当ててみてはどうですか。

少しでもネットワークのことに興味を持ってもらえると嬉しいです。

僕たちが幾度となくお世話になったvar_dump()
ちょっとまって、この関数すごくない?
var_dump()半端ないって。どんなオブジェクト入れても表示するもん。そんなんできひんやん、普通。

ということでvar_dump()のルーツ(実装)を探りにgithub/php-srcに向かった僕だった

人気沸騰中のLaravel。どんどん追加される新機能。そして、Laravel自体のバージョンアップ（5.3⇒5.4⇒5.5⇒5.6⇒5.7）。
Laravel内で変化を追従しながらも、人知れずレガシー化している自身のコードの書き方。
例えば、私の書式『5.3』、現行『5.7』。
そして、5.3と5.7のバージョン間の互換性のロスト。
この互換性の問題にどう立ち向かえば良いか。ソフトウェア設計の互換性を考慮した私の提案と問題提起を行います。

LTも登壇もめっちゃ面白いよ！さあレッツぽちっとな。え？マサカリが怖い？
今から教えるたった一つの心得があればきっと大丈夫さ
（お酒が入ってるノリ推奨）

お気に入りのOSがサポート切れになって早x年、OSを変えるのも面倒…もとい気に入っているのでオフラインで使いたい…！
ネットワークに繋げないオフラインのマシンでPython、PHP、Docker等の開発環境を整える・開発をする辛みや面白みについて語ります。

リファクタリング、ナビゲーション、ファイルの移動、PhpStormをマウスを使って操作していませんか？
マウス、トラックパッドは窓から投げ捨ててしまいましょう。

マウスフリーになるPhpStormの知ってトクするショートカット、並びに便利技100選を紹介します。
このセッションを受講すれば明日から開発速度が100倍くらいになる！かもしれません。

PHPでURLルーティングをつくってみた話をします。
普段フレームワークを活用していると、ルーティングの実装はフレームワークが用意したパッケージや外部ライブラリ依存であることが多く、自作するモチベーションやメリットはあまり浮かばないかもしれません。
今回、実用性のあるものを作り上げるのは難しかったですが、敢えて車輪の再発明に挑戦することで
様々なライブラリの実装パターンや実行速度のパフォーマンスの懸念点を知る機会になったり、
アルゴリズムの実装力（エンジニアの基礎体力）を鍛える良い練習にもなりました。
5分の時間内でURLルーティングを自作するメリットと楽しさについて凝縮したお話をできればと思います。