サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
developers.prtimes.jp
こんにちは、フロントエンドエンジニアのやなぎ（@apple_yagi）です。 PR TIMESではフロントエンドのスタイリングライブラリにEmotionを使用していましたが、4ヶ月ほど前からCSS Modulesへの移行作業を開始しました（移行の経緯などについては別エントリーで紹介する予定なので、本エントリーでは割愛させていただきます）。その際にhappy-css-modulesを使用してCSS Modulesの型定義を生成する選択を取りました。 しかし、happy-css-modulesには一つ改善したい点がありました。本エントリーではその点を解消するためにhappy-css-modulesに機能追加をし、実際にプロダクトで使った話を紹介します。 happy-css-modulesについては以下の記事にわかりやすくまとまっています。
こんにちは。コーポレートチームの大村です。 PR TIMESの情報システム部門を担当しています。 当社では社員個人に貸与しているPCの他に、イベントやカンファレンスなどで資料を投影したり、サービス画面のデモを行うために、持ち出し用のPCを貸してほしいというリクエストがたまに発生します。 2024年の初旬から、このような用途で社外に持ち出すPCをChromebookで運用することを始めました。 この記事では、Chromebookを社内で運用した感想や、利点や課題についてお話しします。 Chromebookでできること Chromebookは、Chrome OSを搭載したPCです。このOSに触れたことの無い人でも、ChromeブラウザやGoogleドライブを知っている人なら簡単に操作ができるはずです。 導入のきっかけとして着目したChromebookの特徴は、セキュリティ機能の強さと管理のしや
Technical Advisor の @1000ch です。私がジョインしたのが 2021-09 なので、気付けば PR TIMES に関わって丸 3 年が経過していました。3 年間という月日は組織や事業を変化させるには十分な時間です。普段は気が付きにくいですが、改めて 3 年前と今を比較すると大きな前進を感じますので、その変化に主観を交えて記事を書きます。 今日現在までの 3 年間で起こった出来事 PR TIMES はプレスやニュースの配信サービスとして広く利用されています。今も昔も開発部が PR TIMES のプロダクト開発を支えていることに変わりはありませんが、昔は（3 年前時点では少なくとも）、組織としてもシステムとしても、今よりずっと不安定な状況でした。 古くアップデートできていない PHP に jQuery を使った Frontend 実装、ホストしているオンプレミス環境への
ここんにちはPR TIMES開発本部のインターンの Chanoknan です。 PR TIMESについてフロントエンドのCI パイプラインを改善についてお話しします。 PR TIMESでは、Reactで書かれたすべてのフロントエンドのコードのコードはMonorepo として管理しています。 そのMonorepoのCI パイプラインは、システム全体のLint、Type Check、Test、Buildを行うようにCIパイプラインが設定されており、これにはかなりの時間がかかり、GitHub ActionsのBillable Timeにも影響を与えます。これを緩和するため、CI処理時間を減らすためのいくつかの戦略を実施しています。詳細については、以下の記事を参照してください。 改善できる点を特定する この作業に取り組む前、私はCIパイプラインやGitHub Actionsについて詳しくありません
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 先日、PR TIMES上で企業アカウントを作成する際に情報を入力する企業登録申請フォームをReact + Viteにリプレイスしました。 企業登録申請フォームをリプレイスする難しさ 企業登録申請フォームは入力項目が30項目あり、データ量が多いフォームとなっています。このようなフォームをシングルページアプリケーションで実装する時に難しくなるのが、フロントエンドとバックエンドのバリデーションをどのように同期させるかです。すでに登録済みのメールアドレスかどうかを確認するバリデーションなどはフロントエンドだけでは完結することはできないため、フロントエンドのバリデーションがゆるくなるのが一般的だと思います。今回のリプレイスでもフロントエンドのバリデーションをバックエンドよりもゆるくする対応を行いましたが、そこでさらに問
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 プレスリリース掲載ページ、キーワード検索ページに続き、PR TIMESのトップページを PHP + Smarty + jQuery から Next.js（Pages Router）にリプレイスしました。
import {css} from '@emotion/react'; import * as RadixPopover from '@radix-ui/react-popover'; import type {ReactNode} from 'react'; const defaultSideOffset = 4; type SideType = 'top' | 'right' | 'bottom' | 'left'; type AlignType = 'start' | 'center' | 'end'; type Props = { /** popoverを表示させるトリガー */ readonly trigger: ReactNode; /** popoverの中身 */ readonly children: ReactNode; /** popoverを開いた状態にするか否か *
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):/
こんにちは、インフラチームテックリードの櫻井です。 今回はFluentdプラグインの暴走によってサーバーのストレージが枯渇しかけた話について紹介したいと思います。 アラート通知は突然に とある土曜日の夕方ごろ、1件のアラート通知がスマホに届きました。 “Filesystem % 90.19% > 90%” どうやら本番環境のバッチサーバーのストレージ使用率が90%を超えてしまったようです。 直近のストレージ使用量の推移を見てみると、朝の10時ごろからものすごいペースで増え続けており、あと30分ほどでストレージが枯渇してしまうという状況でした。 あいにく私は当時私用で外出中だったため手元にPCがなく、Slackで他のメンバーに助けを求めました。 するとちょうどPHPerKaigi 2024に参加中だったCTOの金子がこれに気づき、原因となっていたログファイルの削除などの対応をすることで、なん
こんにちは。開発本部で主にバックエンドの開発をしている ueeda です。 PR TIMES Webクリッピングというサービスで使用していた MongoDB を AWS のマネージドサービスである Amazon DocumentDB（以降 DocumentDB） に移行させるプロジェクトを進めていたのですが、先日移行が終了したので、紹介したいと思います。 PR TIMES Webクリッピング（以降クリッピング）とは様々なサイトから記事をクロールし、その記事にユーザーが設定したキーワードが含まれていればクリップしたりなど、メディア露出の調査・分析などが可能なWebアプリケーションです。
こんにちは、フロントエンドエンジニアの小張です。Renovateを使ってフロントエンドのパッケージやライブラリのバージョンアップを改善したことについて紹介します。 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 このリポジトリは作成されてから2年ほどしか経っておらず、使っているライブラリも比較的新しいため、今までバージョンアップの仕組みを特に整備していませんでした。 ただフロントエンドのライブラリはバージョンアップの頻度が多く、異なるライブラリ間でバージョンの依存関係があることもあり、将来のことを考えればライブラリのバージョンを更新する仕組みを作ることはほぼ必須でした。 また、monorepoであるためライブラリのバージョンを大きくあげようとした際の対応コストも大きく、最新との差が小さいうちに細
こんにちは、フロントエンドエンジニアの小張です。GitHub Actionsの実行時間を削減するために取り組んだことについて紹介します。 経緯 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 GitHub Enterprise Cloudプランでは月50,000分のGitHub Actionsを無料で実行することができますが、prtimes-frontendだけで7割近い時間を消費してしまっていました。またCIに時間がかかることで、Pull Requestを作成した後、10分近く待たないとコードレビューに回すことができず、開発効率が落ちてしまっていました。 そこで現状の使い方を見直して、billable timeの削減に取り組むことになりました。 billable time削減の改善点を探す b
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 PR TIMESではこれまでLintツールとしてESLintを使用していましたが、2023年9月からXOを使うようにし始めました。本エントリーでは、XOを導入した経緯や進め方、そして導入した結果についてご紹介します。 導入をした経緯 これまでPR TIMESでは .eslintrc.jsを自分たちで一から作り、ESLintルールを運用していました。しかし、その設定は最初期の環境構築時に色々なドキュメントを見ながら、つぎはぎで作成したものになっており、なぜこのルールが入っているのかや、このルールは必要なのかなどの疑問がありました。 そのような状況であったため、各々がESLintの設定を自由に変え、本来であればエラーになって欲しいルールもoffにされていたりしました。 そこでアドバイザーとして入って頂いている 1
自己紹介 本名：金子達哉 株式会社PR TIMES開発本部長CTO 2021/4入社 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践（技術評論社）（通称：ISUCON本）の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 catatsuyというIDで各種SNSをやっています かたついと呼ばれることが多いです 数年前のPR TIMES デプロイは1週間に1度あるかどうかという頻度 リリース時のメンテナンスにより、大きな変更をリリース PHPのバージョンが非常に古く、ソースコードにも問題があり機能追加が困難で開発効率が低い フロントエンドもほぼすべて古いjQueryベースで作られており、バグ修正すらできていない ⇒開発速度向上のために、すべて変えたのでざっくり紹介 デプロイ頻度を上げる 小さいPRをど
こんにちは。PR TIMES でエンジニアをしている岩元 (@yoiwamoto) です！ プレスリリース配信サイト PR TIMES のフロントエンドは、一昨年ごろまでほぼ全てのページが Smarty + jQuery on PHP で実装されており、直近1、2年は機能追加・改修に合わせてこれらを順次 React 実装にリプレイスを進めています。 このような取り組みをどのような技術構成で行っているか、2023年の振り返りの意味も込めてざっくりと紹介します！ リポジトリ構成 React 実装は、これまでメインのバックエンドサーバーとのモノリスで構成していたリポジトリとは分けて、prtimes-frontend というリポジトリを使用しています。 PR TIMES STORY というサービスも自社で開発が行われていますが、実装は別リポジトリであり技術構成も異なるため、このエントリでは詳細に触
こんにちは、開発本部でインターンをしている田中 湧大です。 今回は認証機能をPR TIMES上で実装し、企業・事業主ユーザーとメディアユーザーでログインするときにJWTを発行するようにしたのでその紹介をします。 JWT（JSON Web Token）とは JSON Web Tokenは以下のようなドットで結合された文字列です。${HEADER}.${PAYLOAD}.${SIGNATURE}で構成されており、それぞれbase64エンコードされています。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlRhbmFrYSIsInVybCI6InBydGltZXMuanAifQ. NVG3MT6djcCjv1Q39Q-QfdZafDA45YYzDiVeknO4KjM JWTはログインシステム、
Next.jsに移行した初期の実装 Next.jsに移行した初期の実装ではgetServerSidePropsで検索結果の1ページ目を取得し、そのデータをTanstack Queryにhydrateするといった形で実装しました（この実装方法自体はUX改善後も変わりません）。 import { dehydrate, type DehydratedState, QueryClient, Hydrate } from '@tanstack/react-query'; export const getServerSideProps = async ({req, res, query}) => { const {search_word: searchWord} = query; const queryClient = new QueryClient(); const searchResultResp
こんにちは！PR TIMES 開発本部フロントエンドエンジニアの岩元 (@yoiwamoto) です。 先日、月間9000万 PV のプレスリリース配信サイト PR TIMES で、もっともアクセスが多い「プレスリリースページ」の実装を、PHP + Smarty + jQuery から Next.js に移行しました。 今回はこれについての詳細や難しかったことなどを共有します。 背景と目的 PR TIMES の Web アプリケーションのフロントエンドは、この数年、必要な部分から随時ページ単位で React 実装へのリプレイスが進んでいる状態で、まだ多くのページでバックエンド生成の HTML + jQuery の実装が残っています。 ご利用企業様のプレスリリースを掲載するプレスリリースページ（下スクリーンショット）もその一つで、機能追加や改修のニーズはありながら、大きな変更を行うことが難し
こんにちは、インフラチーム テックリードの櫻井です。 今回はアプリケーションモニタリングのために導入しているNew RelicにLogs in ContextとInfinite Tracingとカスタム属性を導入して、システムのObservabilityを向上させたことについて紹介したいと思います。 Observability（可観測性）とは まずObservability（可観測性）とは処理時間やエラーなどシステム内部の状態がどれだけ可視化されているかを示す指標です。 Observabilityが高ければボトルネック解消や障害発生時の迅速な対応が可能になり、より安定してサービスを運用することが可能になります。 New Relicについて New Relicは様々な機能を備えたObservability Platformです。 APMやBrowserでバックエンドやフロントエンドのパフォー
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 GitHub ActionsのBillable timeの削減のために、複数に分けて実行していたJobを、ある程度の粒度でまとめて実行するようにしたので紹介します。 経緯 弊社ではGitHub Enterpriseプランを契約しており、GitHub Actionsを月50,000分使用することができますが、先月（2023/07）使用時間の上限に達したため、一時的にGitHub Actionsが使用できない状況が発生しました。 その月は追加で課金を行なったため、すぐに使えるようになりましたが、そもそも現状の使い方で無駄な箇所がないかを調査することとなりました。 そして調査した結果、Jobを複数に分けて実行することでBillable timeが余分に増えていたことがわかりました。 Billable timeの消費
こんにちは、インフラチームテックリードの櫻井です。 今回はDockerとfirewalldを使って内部ネットワークへのアクセスを制限し、SSRF攻撃を防ぐ方法について紹介します。 SSRF攻撃とは SSRF（Server Side Request Forgery）攻撃はWebアプリケーションに対する攻撃の一種で、公開されたサーバーを経由して公開されていない内部ネットワークのサーバーにアクセスする手法です。 SSRFの概略図 具体例 例えば以下のように外部から指定されたURLにcurlでリクエストを行い、その結果を出力するプログラムがあるとします（このプログラムにはXSS脆弱性も含まれていますが今回は割愛します）。 <?php $ch = curl_init(); curl_setopt_array($ch, [ CURLOPT_URL => 'http://' . $_REQUEST['u
こんにちは。PR TIMES 開発本部フロントエンドエンジニアのいわもと (@yoiwamoto) です。 ChatGPT を業務で利用するために、OSS の chatbot-ui を社内でセルフホストして公開しました。 以下は2023年4月5日時点の情報で、今後組織向けにプランなどが改善される可能性は大いにあります。 ChatGPT を会社で利用するハードル ChatGPT は OpenAI が公開した大規模言語モデルおよびチャットアプリケーションで、うまく活用すれば業務効率を大きく向上させる余地があります。 ただし、会社などでの業務利用となると、少なくとも現時点で以下のようなハードルがあります。 データ活用のオプトアウトは個人で申請する必要がある OpenAI の利用規約では、ChatGPT 公式のブラウザ UI からのユーザー入力は、サービスの開発や改善に活用され、API 経由の入力
それに伴い他のメンバーが書いたテストを修正する機会が増えたのですが、修正が難しい場合には一時的にtest.todoとしたり、テストを書いた人に修正を依頼するなどの現象が発生していました。 テストの修正が難しい一因として、testing-libraryが行った画面操作を視覚で確認できないことがありました。そこで昨年導入したStorybookを使って、動作を画面で確認しながらテストを書いていく取り組みをはじめました。 Storybook導入当初の目的についてはこちらに詳しくまとめています。
こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについて紹介します。 CDNの基本的な情報は割愛するので、もしCDNについて基本的なことを知りたいという方はググるなりChatGPTるなりしてください。 なぜ移行する必要があったのか まずCloudFrontからFastlyに移行した理由について説明します。 prtimes.jp のプレスリリース詳細ページは現在SmartyテンプレートとjQueryというレガシーな技術で構成されています。 今後このプレスリリース詳細ページをReact化することでフロントエンドの開発スピードを向上させることを予定しています。 しかしReact化を行うと、検索エンジンのクローラーがJavaScriptを実行できない場合にページの内
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、その理由や実際に移行してみて感じたメリットなどをご紹介いたします。 なぜ移行したのか いくつか理由はありますが、大きな理由の1つとして Cypress は並列でテストを実行することができなかったことがあります。 Cypress で書かれた Integration Test はAPIリクエストを全てモックしているため、データベースの状態などにテスト結果が左右されることがなく、全てのテストを並列で実行可能でした。しかし、Cypressは並列でテストを実行することができず、テストを直列で実行するしかなかったため、テストの完了までに時間がかかってしまう問題がありました。
PR TIMESはYAPC::Kyoto 2023でGold Sponsorsとして協賛します PR TIMESでCTOをやっている金子 (@catatsuy) です。 PR TIMESが2023/3/19に開催されるYAPC::Kyoto 2023のGold Sponsorsとして協賛することになりました。 当日は私も登... YAPCはコロナ禍で長らくオンラインでの開催が続いていたため、オフラインでのカンファレンスは久しぶりの開催でした。会場では、オフラインらしく相互コミュニケーションが多く、カンファレンス独特の溢れかえるエネルギーに満ちていました。 このようなオフラインイベントは、Webエンジニア同士の横のつながりを作ってきたコミュニティの復活を目指す運営の強い意思があってこそ実現したものです。運営の皆さんには心から感謝の気持ちでいっぱいです。
こんにちは。PR TIMES フロントエンドエンジニアの岩元 (@yoiwamoto) です。 PR TIMES ではいくつかのページが React で実装されており、Webpack でビルドを行っていました。 今回は、一部のページを除いてこの Webpack を Vite へ置き換えたので、その経緯や結果を共有します。 まとめ ビルド時間が長いことが課題で移行を行い、結果として開発体験・デプロイ時間等が大幅に改善されました。 開発環境のみの移行 → フィーチャートグルでの本番試験 → リリース → Webpack の廃止と、移行は段階的に進めました。 なぜ Webpack をやめたのか 一番はやはり、ビルド時間の遅さです。 今回、当時の環境を再現することが難しく、改めて計測はできなかったのですが、本番用のビルドはおおよそ3~4分、開発環境での watch ビルドで変更が反映 (HMR)
背景 STORYではバックエンドのPull Request作成をトリガーにして、CircleCi上でTestを実行していました。Testの実行時間は11〜13分ほどでした。 常々、このTestの実行時間が長すぎて開発体験の質が落ちているような気がしていました。 Testの実行時間が長すぎると何が問題になるのでしょうか？ 以下がSTORYチームがSlack上でしばしば発生していた会話です。 岩下「あ、Aさん！☓☓☓の件について、Pull Requestを作ったのでお手すき時にレビューお願いします！」 A「OKです、手が空いたら見ておきます〜」 〜〜〜1時間後〜〜〜 A「岩下さん、Pull Requestを見ようとしたら、TestがFailしているところがありました、確認してもらえますか？」 岩下「えっ、あっ、はい承知しました！」 この状況の問題点は、私がTestの実行結果を待たずにPull
こんにちは、開発本部インフラチームテックリードの櫻井です。 今回は2022年9月に行ったオンプレミスからAWSへの移行プロジェクトについて紹介したいと思います。 オンプレ環境の抱えていた課題 弊社の主力サービスである prtimes.jp はAWSなどのクラウドサービスではなく、自社サーバーをデータセンターに置くオンプレミスで運用してきました。 ほとんどのサーバーはVMware vShereを使って仮想サーバーとして構築されていましたが、データベース(PostgreSQL)だけは物理サーバーとして構築されていました。 このデータベースには750GBほどのストレージがありましたがそのうち90%近いデータが保存されており、なおかつ物理的にこれ以上ストレージを増設することができなかったため、データベースのストレージの枯渇を防ぐために早急に別のサーバーに移行する必要がありました。 またデータベース
次のページ
このページを最初にブックマークしてみませんか？
『PR TIMES 開発者ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
