タグ

ブックマーク / developers.prtimes.jp (11)

  • フロントエンドのGitHub Actions実行時間を削減するために取り組んだこと | PR TIMES 開発者ブログ

    こんにちは、フロントエンドエンジニアの小張です。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

  • 開発生産性可視化の意義とPR TIMESの事例 発表資料 | PR TIMES 開発者ブログ

    自己紹介 名:金子達哉 株式会社PR TIMES開発部長CTO 2021/4入社 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践(技術評論社)(通称:ISUCON)の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 catatsuyというIDで各種SNSをやっています かたついと呼ばれることが多いです 数年前のPR TIMES デプロイは1週間に1度あるかどうかという頻度 リリース時のメンテナンスにより、大きな変更をリリース PHPのバージョンが非常に古く、ソースコードにも問題があり機能追加が困難で開発効率が低い フロントエンドもほぼすべて古いjQueryベースで作られており、バグ修正すらできていない ⇒開発速度向上のために、すべて変えたのでざっくり紹介 デプロイ頻度を上げる 小さいPRをど

    開発生産性可視化の意義とPR TIMESの事例 発表資料 | PR TIMES 開発者ブログ
  • 【月間9000万PVのPR TIMES】プレスリリース掲載ページの Next.js 移行でやったこと | PR TIMES 開発者ブログ

    こんにちは!PR TIMES 開発フロントエンドエンジニアの岩元 (@yoiwamoto) です。 先日、月間9000万 PV のプレスリリース配信サイト PR TIMES で、もっともアクセスが多い「プレスリリースページ」の実装を、PHP + Smarty + jQuery から Next.js に移行しました。 今回はこれについての詳細や難しかったことなどを共有します。 背景と目的 PR TIMES の Web アプリケーションのフロントエンドは、この数年、必要な部分から随時ページ単位で React 実装へのリプレイスが進んでいる状態で、まだ多くのページでバックエンド生成の HTML + jQuery の実装が残っています。 ご利用企業様のプレスリリースを掲載するプレスリリースページ(下スクリーンショット)もその一つで、機能追加や改修のニーズはありながら、大きな変更を行うことが難し

    【月間9000万PVのPR TIMES】プレスリリース掲載ページの Next.js 移行でやったこと | PR TIMES 開発者ブログ
  • PR TIMESのCDNをCloudFrontからFastlyに移行しました | PR TIMES 開発者ブログ

    こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについて紹介します。 CDNの基的な情報は割愛するので、もしCDNについて基的なことを知りたいという方はググるなりChatGPTるなりしてください。 なぜ移行する必要があったのか まずCloudFrontからFastlyに移行した理由について説明します。 prtimes.jp のプレスリリース詳細ページは現在SmartyテンプレートとjQueryというレガシーな技術で構成されています。 今後このプレスリリース詳細ページをReact化することでフロントエンドの開発スピードを向上させることを予定しています。 しかしReact化を行うと、検索エンジンのクローラーがJavaScriptを実行できない場合にページの内

  • CypressからPlaywrightに移行しました | PR TIMES 開発者ブログ

    こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、その理由や実際に移行してみて感じたメリットなどをご紹介いたします。 なぜ移行したのか いくつか理由はありますが、大きな理由の1つとして Cypress は並列でテストを実行することができなかったことがあります。 Cypress で書かれた Integration Test はAPIリクエストを全てモックしているため、データベースの状態などにテスト結果が左右されることがなく、全てのテストを並列で実行可能でした。しかし、Cypressは並列でテストを実行することができず、テストを直列で実行するしかなかったため、テストの完了までに時間がかかってしまう問題がありました。

    CypressからPlaywrightに移行しました | PR TIMES 開発者ブログ
  • PR TIMESをオンプレミスからAWSに移行しました | PR TIMES 開発者ブログ

    こんにちは、開発部インフラチームテックリードの櫻井です。 今回は2022年9月に行ったオンプレミスからAWSへの移行プロジェクトについて紹介したいと思います。 オンプレ環境の抱えていた課題 弊社の主力サービスである prtimes.jp はAWSなどのクラウドサービスではなく、自社サーバーをデータセンターに置くオンプレミスで運用してきました。 ほとんどのサーバーはVMware vShereを使って仮想サーバーとして構築されていましたが、データベース(PostgreSQL)だけは物理サーバーとして構築されていました。 このデータベースには750GBほどのストレージがありましたがそのうち90%近いデータが保存されており、なおかつ物理的にこれ以上ストレージを増設することができなかったため、データベースのストレージの枯渇を防ぐために早急に別のサーバーに移行する必要がありました。 またデータベース

  • ECSでマルチステージング環境を実現した設計と実装 | PR TIMES 開発者ブログ

    こんにちは、普段PR TIMES STORY(以下STORY)の開発リーダーをしている岩下(@iwashi623)です。 PR TIMES STORYは弊社のMissionである「行動者発の情報が、人の心を揺さぶる時代へ」をそのまま体現したようなプロダクトで、「創業ストーリー」や「開発秘話」などの行動者の熱量をそのまま配信して、企業とメディア、生活者のより良い・多くのリレーションが生まれることを目的としています。 PR TIMES STORYトップページ 記事では、私も今月から2年目となったので新卒の時よりさらにチームに貢献していきたい!と思っていたところ、STORYの現状の環境では開発速度が出しづらい状況を抱えていたので、そちらを解消するためにチームで行ったことを書いていきます。 現状 STORYは一部PR TIMESとは別リポジトリ、別インフラで独立して管理されており、独立している部

  • PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ

    <? 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);

    PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ
  • 挑戦する組織にするためにCTOになってからやったこと | PR TIMES 開発者ブログ

    件は実装に漏れがあった状態で放置してしまっていました。お客様に多大な迷惑をかける前に防ぐことができず、申し訳ございませんでした。 今回の事象が発覚してすぐに総点検・改修プロジェクトが開始され、調査と改修を行っていきました。 こういったことが起こった時にすぐに調査できるようにBigQueryの導入を進めていたり、リファクタリングデーの設定により古いソースコードにも目を触れる機会を作っていこうとしていたのですが、いずれも間に合わず、かなり悔しい思いをしました。 しかしそんな中でも各メンバーが頑張り、1つずつ問題を解消していき、何とか終わらせることができました。こんな大変な状況でも対応をし続けてくれた人には当に感謝の気持ちでいっぱいです。 セキュリティ対策で唯一間に合ったと言えるのはKENROの導入でした。 KENROは新卒+希望者の人に受けてもらいましたが、KENROで得た知識を今回のプロ

  • 旧ストレージ廃止大作戦−2900万超のファイルリストを取得する | PR TIMES 開発者ブログ

    株式会社PR TIMES 執行役員CTOの@catatsuyこと金子です。今回は先日私が作ったGo製のCLIを社内で利用した話を紹介します。 旧ストレージサーバー廃止失敗 現在のPR TIMESの主要なシステムはデータセンター上にあり、ストレージサーバーはアプライアンスのシステムを使用し、アプリケーションサーバーからはNFSでマウントされています。 PR TIMESは日々様々なプレスリリースが配信されており、当然それに伴い画像などのストレージに保存されるファイルが日々増えています。そのためいつかストレージサーバーのディスク容量が枯渇してしまいます。ディスク容量が枯渇すれば当然新しいストレージサーバーへの移行が必要です。 弊社も先日旧ストレージサーバーの容量が枯渇してしまい、新ストレージサーバーに移行する必要がありました。しかしここで問題が発覚します。それは 1つのディレクトリにものすごい量

  • 「一人じゃない」と思えるチームビルディングが鍵 PHPバージョンアップのために欠かせない“精神論” | PR TIMES 開発者ブログ

    PR TIMESで定期開催されている社内勉強会。先日は執行役員CTO金子達哉主催で、社内のPHPバージョンアップkickoffイベントを開催しました。今回は編後半に実施したCTO金子達哉、山岡広幸氏、uzulla氏の座談会の記録をお届けします。 不平不満をオブラートに包んで、情報として共有していく uzulla:スライドでも話しましたが、まずは、精神論をします。僕は「PHPの新しい機能を使いたいから、絶対バージョンアップしてやる!」みたいな、無限のモチベーションにプッシュされる人間ですから、モチベーションは自己回復していくタイプです。無茶なスケジュールを切らなければなんとかこなしていける。 それでも、レガシーシステムの改善ってあまり高くは評価されないし、デプロイで壊せば落ち込みます。それを「気にするな」と言うのは無理な話なんです。「辛いな」と思った時に、うまく「辛い」という感情を共有して

    「一人じゃない」と思えるチームビルディングが鍵 PHPバージョンアップのために欠かせない“精神論” | PR TIMES 開発者ブログ
  • 1