最近、1993年発売のX68030というパソコンを買って動かして遊んでいます。
大学生当時に憧れだったけど高くてとても買えなかったX68030ですが大人になり財力が付いた今なら…と思ってフリマサイトを監視していたら良さそうな機体が出品されたのを発見してつい…。
X68030はHDDにSCSIを採用しHDD内蔵モデルであるX68030-HDには80MB(GBじゃないですよ)のHDDが内蔵されていました。
翻って現代、2022年。世の中には「Raspberry PiでSCSIデバイスをエミュレートする」とか「Compact Flashに格納したファイルをSCSI HDDとして見せる」とか「Raspberry Pi でFDDをエミュレートする」みたいな同人ハードウェアが生み出され、当時とはまったく異なる快適なX680x0環境を構築することができます。
このトークではX68030の紹介と、2022の今、X68030を楽しむにはどうすると良いかをお伝えします。
今でも十分通用するX680x0の魅力がみなさまに伝わり、X680x0ユーザが増えることを期待しています!(ねえよ)
Cybernetically enhanced web apps【Svelte】とは、一つのファイルにJavaScriptとかCSSとかHTMLをまとめて書いてエイッ!ってやるとWebアプリになるあのReactとかVue的存在です。
ではなぜここでSvelteの話をするのか? それは、何か使ってみたら便利で楽しかったしこれは内緒にしておこうとおもったけど、使う人が増えたほうがもっと便利になるので、ぜひ皆様もこの春PHPにSvelteをCyberneticallyにenhancedしてWebをappsしてみませんか?
今回は次の2つの事例を5分間でご紹介します。
・SvelteをPHPの非同期アーマーとしてREST装着したアプリケーション
・既存PHPアプリケーションへの追加UIとして、HTMLタグのデータ属性でSvelteコンポーネントを接続
※非同期アーマーという言葉はありません。
QAエンジニア業務をやり始めて4年目になります。
大規模では、テストの自動化やQA業務の課題を可視化させてワークフローの最適化を経験し、小規模では、ワンオペによる俗人化やそもそもQA業務がマニュアル化されていないQA環境の整備するなど、様々なQAの現場でQA業務を経験してきました。
最近では、QAメンバーの採用で苦戦しており、とくにエンジニア採用で苦戦している以上にQAエンジニアやテストエンジニアがいない問題が深刻になっています。
本トークでは、QAエンジニア奮闘記と題してこれまでとこれからのフリーのQAエンジニアとして奮闘する話ができたら嬉しいです。
20分のレビュラートークでは以下のように主にOOUIモデリングをエンジニアとデザイナで行う過程の話になっています。
40分の本トークではそれに加えてOOUIのモデリングをどう実装に落とし込んで幸せになったのかを弊社BASEでの事例を元にお話させて頂きます。
CakePHP 2 系のサポート終了に伴い、関わっているプロジェクトを Laravel でリプレースしました。
当時、 Laravel は触ったことがない状態だったものの、PHP のイベントを聞いて興味を持ちました。
Laravel は器用なことができるフレームワークだと感じていますが、その反面、Laravel を導入したばかりの時にはチームで決めていくことがいくつかありました。
また、 Laravel 化に合わせ、CI の拡充やインフラの整備、 PHP 8 対応なども進めたため、本トークではこれらの知見の共有を行う予定です。
チームで会話している時にデザイナとエンジニアでは同じ名詞に対してでも頭に浮かべているものが異なります。
デザイナはユーザのメンタルモデルを元に、エンジニアはシステム設計や要件を元に会話していることがほとんどだったので常にお互いの話が理解しにくく、デザイナをチームの中でも孤立させてしまっていました。
そのような問題を解決すべく、私のチームではエンジニアとデザイナで定期的にプロダクトに対してOOUIでのモデリングを行ってきました。
本トークではこの取り組みから以下のことをまとめて発表する予定です。
コードフォーマッターや静的解析ツールなどを使ってコードレビューの手間を減らすことの重要性はしばしば強調されます。しかし、ツールによるコードレビューの自動化には、単なる工数削減だけでなく「意見の衝突、およびそれによる対人ストレスの緩和」にもどうやら効果があるようです。
「デウス・エクス・マキナ」パターンは、この仮説にわたしが勝手に命名したものです。この仮説に至るきっかけになった現場でのエピソードや、関連して考えていることについてお話ししたいと思っています。
フルサーバーレスな構成を取る場合、必要な様々なクラウドサービスの知識に加え
実践的な利用方法が求められます。
フルサーバーレスの恩恵を受けたいが、その第一歩が難しい。
その悩みをAWS Amplifyは解消してくれます。
AWS Amplify で出来ることをご紹介しながらReact + GraphQLで作成するログイン付きの
サンプルWebアプリケーションを作成する流れについてご説明します。
具体的な手法をなぞることで、
どの様にフルサーバーレスなアプリケーションを作成するかを学びましょう!
このLTではFFIやANTLRによる言語実装など、あらゆる手段を使ってPHPからGoを呼び出す方法を紹介します。
実用性は皆無です。
PHPを通じて技術を楽しむLTとなっております。
フルサーバーレスな構成を取る場合、必要な様々なクラウドサービスの知識に加え
実践的な利用方法が求められます。
フルサーバーレスの恩恵を受けたいが、その第一歩が難しい。
そのような悩みを、定まったフレームワーク上でフルサーバーレスな構成を簡単に実現出来るAWS Amplifyを利用することで解決出来ます。
今回はその流れについてReact + GraphQLで作成するログイン付きの
Webアプリケーションをバックエンドアプリケーションを開発することなく爆速で構築する手法について、
フルサーバーレスにしたことで得られたメリット・デメリットも含めてお話します。
Webアプリケーションはどうして動くのでしょうか。
ブラウザ等のクライアントから送信されたHTTPリクエストを契機に、
Webアプリケーションでは様々なレイヤーでの情報処理が行われます。
今回はその情報処理の流れをLaravelを例に追うことで、
Webサーバー、Laravelアプリケーション、データーベースと
レイヤー毎で行われている処理とそのレイヤー毎のつなぎ込み部分に迫ります。
HTTPヘッダーを含むHTTPリクエストの流れを追って、真にWebアプリケーションがどうして動くのかを知り、
必要な処理をどこに組み込むことが効果的なのかを知る一助になれば幸いです。
コロナ禍でリモートワークになったエンジニアは数多くいらっしゃる事と思います。
そろそろ2年が経とうとしていて、少しずつリモートワークに慣れてきても、やっぱりオンラインとオフラインの差はある。
それぞれのメリット・デメリットを認識した上で、ワークライフバランスを上げつつ仕事を進める方法を、リモートワーク経験20年超&フルリモート転職の経験を踏まえてお話したいと思います。
スタッフには興味あるけど「スタッフってつよつよエンジニアばかりなんじゃないの?」とか「自分なんかにもできるのかな?」なんて不安を感じて応募を躊躇ってしまっていませんか?
いつもお世話になるばかりだった私が、当日スタッフに応募しようと思った動機と、実際にやってみてどうだったかをお話ししたいと思います。
2018年のGitHub UniverseでGitHub Actionsが発表されてから約3年、今ではGitHubを代表するなくてはならない機能の1つになっています。
発表者もv2(not HCL)から使い始めており、作成したOSSのCI/CD環境として有効に活用するだけでなく、独自に作成したActionもいくつかGitHub Marketplaceに公開しています。
本発表では「PHPで独自Actionを作成する」ことを通じて、GitHub Actionsを使いこなすに当たって、私の知る知見を時間の許す限り紹介します。
細かすぎて全く必要のなさそうな情報ばかりかもしれません。しかし、あなたがGitHub Actionsを使いつづけていくといつか必要になる情報かもしれません。
GitHub Actionsをより深く知ってCI/CDだけでなくさまざまな自動化効率化を実現しましょう。
phpを書く人はphpstormを使う人が多いと思いますが、別のテキストエディタでも同じようなことができます。
私はemacsユーザなのでemacsユーザならではの話をしたいと思います。
具体的には以下のような話
2019年11月にGAとなった Cloud Run。
それから2年となる最近、とある案件で「GCPで、Laravelアプリを」というオーダーに巡り会いました。
「AWS Fargate 上に Laravel プロダクトを載せる」ことをやりきっていた自分は、
Compute Engine ではなく Cloud Run 上に、Terraform module を利用して構築することにしました。
やると決めてから、久しぶりのGCPのインフラを、初めてIaCで構築していきました。
今のところ、順調に進んでいると思います。
このLTでは、その過程で感じてきた
といったあたりの、新サービス構築試行事例をご紹介したいと思います。
「DOT言語」
あまり聞くことがない言語だと思います。
ではこのように言い換えたらどうでしょう?
「Graphvizで使うDSL」
以下の検索結果をみて「何かのツールの出力でみたことがある画像」と思うかもしれません。
https://www.google.com/search?q=graphviz&tbm=isch
DOT言語はGraphvizのための言語です。
本発表は「Graphvizを使ってみたい」という方が対象です。
「難しそう」と思った方へ。
私のDOT言語のイメージは、
です。
「PHPと親和性高そう」と思った方。その通りです。
DOT言語の世界へようこそ!
Laravel Octane(Swoole版)でPharをつかってワンバイナリアプリケーションにして運用してみた話です
過去、PHPカンファレンス北海道(2019)にて
「pharによるワンバイナリアプリケーションの可能性を探ってみた」
でお話ししましたが、そのリベンジ(現実版)になります
Laravel OctaneをPharで固めたときにつまづいた話を中心にお話しします!
PHPだけど、Buildして(Pharでpackして)、Deployして運用してみよう!
プロジェクトとしてSREを実施することになったので、プロダクトにSLOを定めてみました。
実際に定めた内容の他、SLOを定義するまでに至る経緯、現運用の課題や、アプリケーションエンジニアとのコミュニケーションに関する今後の展望など、弊社エンジニア組織の文化的背景など踏まえお話しします。
普段、受託の案件(特に業務システム)に携わるエンジニアだと、大量のアクセスを想定したアプリケーションを実装する機会が多くありません。
私は今回初めて数万ユーザーが利用するtoCのLaravelアプリケーションの構築に携わりました。
数万ユーザーのアクセスに耐えうるインフラ、アプリケーションを構築できたのか!?
「実際どれくらいの秒間リクエストに耐えうるのか???」をLocustというツールを用いて負荷試験を実施して、試行錯誤したことお話しします!
・ 想定する聴講者