こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 プレスリリース掲載ページ、キーワード検索ページに続き、PR TIMESのトップページを PHP + Smarty + jQuery から Next.js(Pages Router)にリプレイスしました。
![PR TIMESのトップページをNext.jsにリプレイスしました | PR TIMES 開発者ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/becdba091ee152dc1fb3d5e7aaf24e334f4530cf/height=288;version=1;width=512/https%3A%2F%2Fdevelopers.prtimes.jp%2Fwp-content%2Fuploads%2F2024%2F06%2Freplace-top-page-with-nextjs.jpg)
CypressからPlaywrightに移行しました こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、... 前提 PR TIMESは、React + Vite製のアプリケーション(主に企業様の管理画面)とNext.js製のアプリケーション(SEOが重要なページ)が存在します。 本エントリーで紹介するのは、React + Vite製のアプリケーションに対するVRTとなります。 VRTの実行環境 VRT(Playwright)は公式のDocker Imageを用いて、Docker上で実行するようにしています。 { "scripts": { "_docker": "docker run --rm --ipc=host -v $(pwd):/
こんにちは、フロントエンドエンジニアの小張です。Renovateを使ってフロントエンドのパッケージやライブラリのバージョンアップを改善したことについて紹介します。 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 このリポジトリは作成されてから2年ほどしか経っておらず、使っているライブラリも比較的新しいため、今までバージョンアップの仕組みを特に整備していませんでした。 ただフロントエンドのライブラリはバージョンアップの頻度が多く、異なるライブラリ間でバージョンの依存関係があることもあり、将来のことを考えればライブラリのバージョンを更新する仕組みを作ることはほぼ必須でした。 また、monorepoであるためライブラリのバージョンを大きくあげようとした際の対応コストも大きく、最新との差が小さいうちに細
自己紹介 本名:金子達哉 株式会社PR TIMES開発本部長CTO 2021/4入社 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践(技術評論社)(通称:ISUCON本)の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 catatsuyというIDで各種SNSをやっています かたついと呼ばれることが多いです 数年前のPR TIMES デプロイは1週間に1度あるかどうかという頻度 リリース時のメンテナンスにより、大きな変更をリリース PHPのバージョンが非常に古く、ソースコードにも問題があり機能追加が困難で開発効率が低い フロントエンドもほぼすべて古いjQueryベースで作られており、バグ修正すらできていない ⇒開発速度向上のために、すべて変えたのでざっくり紹介 デプロイ頻度を上げる 小さいPRをど
こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、その理由や実際に移行してみて感じたメリットなどをご紹介いたします。 なぜ移行したのか いくつか理由はありますが、大きな理由の1つとして Cypress は並列でテストを実行することができなかったことがあります。 Cypress で書かれた Integration Test はAPIリクエストを全てモックしているため、データベースの状態などにテスト結果が左右されることがなく、全てのテストを並列で実行可能でした。しかし、Cypressは並列でテストを実行することができず、テストを直列で実行するしかなかったため、テストの完了までに時間がかかってしまう問題がありました。
こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについて紹介します。 CDNの基本的な情報は割愛するので、もしCDNについて基本的なことを知りたいという方はググるなりChatGPTるなりしてください。 なぜ移行する必要があったのか まずCloudFrontからFastlyに移行した理由について説明します。 prtimes.jp のプレスリリース詳細ページは現在SmartyテンプレートとjQueryというレガシーな技術で構成されています。 今後このプレスリリース詳細ページをReact化することでフロントエンドの開発スピードを向上させることを予定しています。 しかしReact化を行うと、検索エンジンのクローラーがJavaScriptを実行できない場合にページの内
こんにちは。PR TIMES フロントエンドエンジニアの岩元 (@yoiwamoto) です。 PR TIMES ではいくつかのページが React で実装されており、Webpack でビルドを行っていました。 今回は、一部のページを除いてこの Webpack を Vite へ置き換えたので、その経緯や結果を共有します。 まとめ ビルド時間が長いことが課題で移行を行い、結果として開発体験・デプロイ時間等が大幅に改善されました。 開発環境のみの移行 → フィーチャートグルでの本番試験 → リリース → Webpack の廃止と、移行は段階的に進めました。 なぜ Webpack をやめたのか 一番はやはり、ビルド時間の遅さです。 今回、当時の環境を再現することが難しく、改めて計測はできなかったのですが、本番用のビルドはおおよそ3~4分、開発環境での watch ビルドで変更が反映 (HMR)
こんにちは、開発本部インフラチームテックリードの櫻井です。 今回は2022年9月に行ったオンプレミスからAWSへの移行プロジェクトについて紹介したいと思います。 オンプレ環境の抱えていた課題 弊社の主力サービスである prtimes.jp はAWSなどのクラウドサービスではなく、自社サーバーをデータセンターに置くオンプレミスで運用してきました。 ほとんどのサーバーはVMware vShereを使って仮想サーバーとして構築されていましたが、データベース(PostgreSQL)だけは物理サーバーとして構築されていました。 このデータベースには750GBほどのストレージがありましたがそのうち90%近いデータが保存されており、なおかつ物理的にこれ以上ストレージを増設することができなかったため、データベースのストレージの枯渇を防ぐために早急に別のサーバーに移行する必要がありました。 またデータベース
はじめまして、PR TIMESの開発本部でインターンをさせて頂いている永井と申します。 現在はパフォーマンス改善のタスクをしています。 はじめに 自分は今回のタスクをやるまでSQLをあまり書いたことがありませんでした(ORマッパーしか使っていませんでした)。しかし、今回のタスクをやることで直接SQLを書くことが多くなりSQLはもちろんPostgreSQLの構造はどうなっていて、何がメモリを消費しているかなどについての理解も深まりました。本当に良い経験をさせて頂きました。 なぜ削減することになったのか PostgreSQLのストレージがとても逼迫していました。さらにPostgreSQLはオンプレの物理サーバーで動いていてストレージの増設も難しいため、AWSに移行するまでの延命措置としてデータ量を削減することになりました。 まずは状況確認 一番容量を使っているテーブルはどれか 以下のクエリで、
prtimes ├── config ├── file-cache ├── frontend <-- 旧フロントエンドのコード(JS,jQuery,Vue.js,SCSS,etc...) ├── htdocs ├── replace <-- 新しいフロントエンドのコード(React) ├── scss ├── serviceworkers ├── tests ├── tmp ├── upload_files ├── uploads └── vendor この構成にすることで、PR TIMESの既存のフロントエンドコード(JavaScript,jQuery,SCSSなど)のデプロイフローをそのまま利用できるため、インフラや CI/CD を新しく構築せずにReactを導入することができました。 旧デプロイフロー しかし、この構成には以下の課題がありました。 フロントエンドの実装が一つのリポジト
<? include("abc.php"); include("def.php"); include("conf.php"); include("db.php"); include("some.php"); include("what.php"); Define("NUM", 100); class super_calc extends great_calc { /* * * * コンストラクタ * * * * */ public function super_calc($initial_num){ $this->db = DB::getDb(DSN); $this->initial_num = $initial_num; } /* * * * チェック * * * * */ public add_ok($add_num){ $res = $this->addable($add_num);
こんにちは、業務委託でPR TIMESにJOINしているuzulla (”うずら”, twitter, GitHub)です。本エントリではPR TIMESで行っているリファクタリングデーについてお話したいと思います。 リファクタリングデーとは?なぜ必要か? PR TIMESは歴史あるサービスです。サービス・機能は追加され、削除され、結果古いコードが大量に存在します。今後もスピード感を維持しつつ成長を続けるためにはそれらの整理・改善・削除、つまりリファクタリングが重要なことはいうまでもありません。 日々の業務においてリファクタリングが行われていれば問題ありませんが、日々サービスの成長にフォーカスしていくとやはり後回しになりがちで、タイミングを失います。 その為に「リファクタリングデー」という「リファクタリング作業を定期的に実施する日」をとりきめて実施しています。現在は月に一回程度開催され、3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く