初学者に向けてPHPの翻訳が何をしているのかを解説します。
以下の内容を予定しています。
・自然言語処理で自動翻訳が進んできたけどいまだに辞書に基づいた翻訳処理のニーズはある
・PHPの翻訳処理の書き方基本(bindtextdomain, gettextとか)
・Cの処理をPHPがラップして処理している話
・結局上記の処理はmoファイルという翻訳ファイルを読み込んでいる話
・moファイルがどのようにできるのか(pot ->po->mo)
新規:xgettext, msginit, msgfmt
追加:xgettext -j, msgmerge, msgfmt
・EmacsのPOモードとかもあるけど実際に導入する際にどうやってガバナンスをとるべきかの話
(翻訳者は非エンジニアなので、翻訳のやりとりを同管理するか)
・翻訳処理を使用している身近な例(WordPress, PostgreSQL, 他あったら)
依存ライブラリの更新、定期的に実施できていますか?
恥ずかしながら担当プロダクトで更新ができていないケースがありました。
そしていざ更新を試みると対象ライブラリがいくつもあり、大幅なバージョンアップが必要なものも・・・
このような状況はまずいと感じ調べたところRenovateという依存ライブラリの自動更新を行うツールを知り、導入を試みましたが、更新を怠っていたプロジェクトでの素直な導入は難しいと判断。
そこで導入までにステップを置き、ライブラリのバージョン更新・Renovateの導入、そこから定期的に更新するという運用の流れを構築し、現在はライブラリの更新が健全にできていると感じています。
本トークでは依存ライブラリの更新を怠っていたプロジェクトにRenovateというツールを導入した流れと導入後の運用状況をお話させていただき、皆様の依存ライブラリ管理の一助となればと思っております。
便利なものが大好きなので、「Composerを使いこなしたい」「ここ数年で現れた機能も試してみたい」という願望が私にはあります。皆さんもきっとそうです。
その中でも「書き味が良くなるやつ、便利なやつ」と「パフォーマンスが上がりそうなやつ、便利なやつ」がありますよね。
前者について、例えばPHP7.4のプリロードがあります。
プリロードと初めて聞いた時に、「ではフレームワークやライブラリのコードを予めメモリに乗っけちゃおう!」と興奮した人も多いかと思います。
・・・本当に乗せていますか?
さて、そんな時に助けてくれそうなayesh/composer-preloadというパッケージがあります。
see: Packagist
これはComposer Pluginです。
READMEを見ると Composer Preload is a composer plugin aiming to provide and complement PHP opcache warming. と記述されています。
どんなアイディアでそれを実現し、どんな仕組みになっているのでしょうか?
簡単に内部に触れてみましょう。
みなさんは普段からPHPやGo, JavaScript, Java などいろいろな言語でプログラムを書いて実行させていると思います。言語によってコンパイルの様な事前作業が必要だったり、書いたプログラムの実行方法が違ったり、実行速度が違ったりしますが、その違いはどこから来ているでしょうか。そしてそもそもプログラムを実行した時にコンピュータの中では何が起きているでしょうか。
このトークではみなさんがプログラムを実行した時のコンピュータの動作を電気回路から画面表示までに分けて解説します。
このトークを通じてCPUやその他のハードウェア、コンパイラなど「コンピュータの低レイヤ」と言われる領域に興味を持ち語り合える仲間が増えることを期待しています!
今年、ポータルに張りつきついに掴んだ予選出場切符・・・!
初めての参加で、PHPを選択しました。
参加までにやったこと・当日の様子・反省点などお話できたらと思います。
レベルアップするには本を読まなきゃいけない・・・
それはわかっているのだがどうも読書ができなかった私・・・
そんな私が、5月から「あるもの」を手に入れて「あること」をするようになった結果めちゃくちゃ本が読めるようになりました。
「本読みたいけど読めてないんだよな」、そんな昔の私と同じ悩みをもってる方必聴です!!
オンプレ稼働していたPHPアプリケーションをクラウドに移行するにあたって、
バッチのアーキテクチャを変えることになりました。
そこで私が採用したのがEventBridge+ECSの構成でした。
■ EventBridge+ECSで実現した仕組み
■ 他に考慮したAWSアーキテクチャ/ なぜこの構成にしたのか
のような軸でお話できたらと思います!
コロナ禍でフルリモート転職して一年が経ちました。
一度も会社に行ったことがないまま入社を決め、入社日もリモート出勤。誰も知ってる人がいない会社にフルリモートで入るのは、より緊張感があり、戸惑うことも多々ありました。
そんな中、自分なりにコミュニケーションを工夫し、「そういえばフルリモートだったっけ」と言われる程に仕事ができるようになりました。
今回は、リモートで仕事をするメリット・デメリットを中心に、転職したてにはどのような制度が助かったか、リモートで困った事とそれにどう対応したのか、などをお伝えできればと思います。
こんにちは。やまゆです。
月日が経つのは本当に早く、私が PHP を志してからもう 8 年近くが経過しているらしいです。
8 年もあれば、色々と変わるものですよね。 PHP もバージョン 5.3 から 8.1 まで大変遷を遂げました。
今回、様々あった 8 年間の PHP との 愛憎劇(?) を振り返ってみたいと思います。
たくさんの進化を経た私と PHP の歴史を見て、 「 PHP いいなー」 と思っていただければ幸いです。
2021年6月に出版された「PHPフレームワーク Laravel Webアプリケーション開発 バージョン8.x対応」の11章「テスト駆動開発の実践」を、著者自らデモを交えて解説します。TDDを始めたいけれどどうやって始めたら良いのかわからない、実際にどんな感じになるのか想像ができないのでほんとに意味があるのかわからない、なんか面倒くさそう、など、TDDへの興味はあるけれどなかなか最初の一歩が踏み出せない、という方にぜひ見ていただきたいです。(2018年のPHPカンファレンスでのセッションをブラッシュアップし、2020年代のTDD初心者の皆さまに向けて改めてお送りします)
現在多くのWebサービスではメールアドレスをIDとしてユーザー情報を管理しています。
このようなユーザーを管理するDB設計はWeb開発の基礎とも呼べるもので、多くのWebフレームワークも基本機能として備えています。
このようなサービス運用のためにいくつかの考慮事項があります。
要約するとたった二点ですが、実際の要件はサービスの運用形態や提供したいユーザー体験に併せて様々に異なってきます。
たとえば、同じユーザーからの複数回の登録を許容しない、特定のドメインからの登録を禁止するなどです。
明確な要件に見えても、現実にはそう単純に実装できない要素がいくつもあります。
メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。
今回のトークではメールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点についてみつめなおしましょう。
あるアプリケーションをコンテナ化することになりました。
Composerの使い方を試行錯誤していく中で「ど、DockerfileでのComposerの記述は、色んなパターンがある・・・!」という学びと、彼らとの絆を得ました。
そして自分の中でなんとな〜く使っていたComposerのことがほんの少しわかるようになりました!
「なんとなくcomposer install打ったらいい感じになるよね」「なんかDockerfileに書いてあるよね」という方が、このセッションを聞いてComposer、そしてDockerfileともうちょっと仲良くできるような発表をします!
話そうと思っていること
■ Composerってなんだっけ?
■ Dockerfileにどうやって書こう?
■ 最終的に採用した方法とその理由
「オブザーバビリティ」や「可観測性」という言葉は、耳にしたことがある人は増えてきていると思います。
あるいは、「全く知らない、想像もつかないよ」「また新しい "ナンチャラlity" が出たんですか?」なんて人も多そうです。
PHPを趣味や仕事で使っている人は、Webサービスやモバイル等のバックエンドを提供しているケースが中心でしょうか。
「今もどこかの姿が見えない誰かが使っているかも知れない」「その人たちが、自分たちが提供しているサーバーにアクセスしている!!」
というのが、Webサービスの難しさであると同時に単純・嬉しいところでもありますよね。
すなわち、「何が起きているか」は「自分たちの目の届く所に集約されている」と。
オブザーバビリティとは、「いかに状態( = 上手くいっていること・問題が起きていること)が把握可能になっているか」という性質です。
放っておいても実現されるものではありません。
意識して、設計して、運用して・・・初めて手にすることができるものです。
これは単なる「ツール」「技術」の話ではないのです。
チームないし文化まで含めて、「どう向き合っていくか」を突き詰めた先にオブザーバビリティがあると考えています。
本セッションでは、「継続的に、かつ自信を持ってサービスを提供し続ける」ために大事なことを、
書籍「Observability Engineering」の内容をベースにしながら紹介していきます。
「SRE」「インフラ」「運用」 ではない 人達に向けた 、どうしてアプリケーション開発者が向き合っていくべきなのだろう・・?という話です。
こんにちは。やまゆです。
みなさん、 new
してますか?私は、最近はあまりしていないです。なぜなら、インスタンス化はほとんど DI コンテナ に任せてしまうからです。お客様のプロダクトにも DI コンテナが含まれているのではないでしょうか?活用出来ていますか?
昨今の PHP は今や素晴らしい言語になっていると感じています。その一つが private readonly SomeRepositoryInterface $someRepo
とコンストラクタに書けるという話です。
今回は以下の内容を話してみたいと思っています。
こんにちは。やまゆです。
そこの方もあちらの方も、一度は 「PHP でフレームワーク作りたい」 と思った、または 実際に作ってみた のではないでしょうか?
私も例に漏れずフレームワークを作っていました。それも 二つ 。
メンテナンスはしていないですし、そもそもプロダクトに採用していません。 完全に趣味 です。
では、何故作ったのか?使わないものを作るのは一見無駄に見えますが、実はとても重要な作業だと私は考えています。
今回はこの三点を共有したいと思います。
みなさんPHP書いてますか?
書いているということは皆さんVimmerなんですね、わかります。
今回VimでPHPを書いている僕が、皆様にVimのPHP コーディングで使っているプラグインをただただ紹介したりします
それ、Vimで出来るよ
免責事項:みんなが自分の好きなエディターでコーディングをするのがいいと思います。
世の中には様々なふりかえり手法がありますが、
みなさんは「象、死んだ魚、嘔吐」というふりかえり手法を知っていますか?
めちゃくちゃキャッチーなタイトルで聞いた時からやってみたかったふりかえり・・・。
ついに機会を作ることができて、実施してみました!
このふりかえりのオススメタイミング・やる際に工夫したポイントなどを、実体験をもとにご紹介します!
フレームワークの利用方法がわからない…
そんな時にドキュメントを見に行くことになると思います。
フレームワークが内部で何をしているかは理解できないけど利用方法はわかる。
今回はそこから一歩踏み込む為にソースコードリーディングをオススメします。
利用方法がわかることはもちろん、
PHPのフレームワークの内部で行われている処理の理解や
Webアプリケーションが行うべき振る舞いについて学ぶ事が出来るので
より確実にフレームワークを利用することが出来る様になります。
今回はLaravelに関してのソースコードリーディングを例に、
フレームワーク作者の追体験をしてみましょう。
Webアプリケーションを運用する上で、監視の仕組みは欠かせません。
それはWebアプリケーションとして動作する事が多いPHPでも変わりません。
SREの文脈で特に重要性が高まるアプリケーション監視ですが、世の中には様々な監視サービスが存在します。
今回は特にAmazon CloudWatchをコアに据え、どの様にWebアプリケーションを監視する事が出来るのかを考察します。
PHP利用したアプリケーションに対してAWS以外のオンプレミスも対象とした、
コストメリットも含めた監視サービスについてお話します。
フルサーバーレスな構成を取る場合、様々なクラウドサービスの知識に加え
実践的な利用方法が求められます
またAWS上でフルサーバーレスなアプリケーションを作成しようとしても、
AWS LambdaのネイティブランタイムにPHPはありません
フルサーバーレスの恩恵を受けたいが、その第一歩が難しい
その悩みをAWS Amplifyは解消してくれます
普段はPHPで実装するバックエンドをAWS Amplifyに任せることで、
React + GraphQLで作成するログイン付きのサンプルWebアプリケーションを作成する流れについてご説明します
具体的な手法をなぞることでフルサーバーレスなアプリケーションを作成手法を学びましょう