タグ

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

  • Looker Studioで開発者ブログの可視化・分析しました | PR TIMES 開発者ブログ

    こんにちは、しゅんそく(@shunsock)です。今回はLooker StudioでPR TIMESの開発者ブログの可視化・分析を行いましたので紹介します。 Looker StudioでGoogle Analyticsのデータ可視化の紹介記事を書いていたこともあり、Looker Studioを用いました。Looker Studioは、いわゆるBI (Business Intelligence) ツールで、データソースとの接続から可視化、通知を簡単に行うことができます。 今回は、PR TIMESの開発者ブログのGoogle Analyticsをデータソースとして、Looker Studioで探索的な分析を行います。 尚、今回紹介する記事で用いた手法は、下記の記事に記載しております(該当記事は個人で執筆したものです)。 作成したLooker Studioのレポート 概要 まず初めに見るページと

  • フロントエンドの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のCDNをCloudFrontからFastlyに移行しました | PR TIMES 開発者ブログ

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

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

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

    mapk0y
    mapk0y 2022/12/02
  • 挑戦する組織にするためにCTOになってからやったこと | PR TIMES 開発者ブログ

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

  • MySQLアップグレード後に出たスロークエリ改善の話 | PR TIMES 開発者ブログ

    こんにちは、開発部の植江田和成です。 私は2021年8月ごろより WebClipping の開発リーダーとして業務を行なっています。 WebClipping とは様々なサイトから記事をクロールし、その記事にユーザーが設定したキーワードが含まれていればクリップしたりなど、メディア露出の調査・分析などがおこえるWebアプリケーションです。https://webclipping.jp/ 今回は、そのWebClippingでAmazon RDS for MySQL(以降MySQL)のアップグレードを実施した後に発生したスロークエリとその改善を行なったことを書きます。 RDS for MySQLは5.6のサポートが終了するため、2022年3月1日までにバージョン5.7までアップグレードすることが強く推奨されています。WebClippingではMySQLバージョン 5.6を使用していたため、この対応

    MySQLアップグレード後に出たスロークエリ改善の話 | PR TIMES 開発者ブログ
    mapk0y
    mapk0y 2021/12/01
  • 1台のサーバーで複数のステージング環境を同時に使えるようにする | PR TIMES 開発者ブログ

    こんにちは、インフラチームテックリードの櫻井です。 今回は1台のサーバーで複数のステージング環境を同時に使用できるように設定を変更したので、その方法について紹介したいと思います。 背景 PR TIMESでは現在開発チームとは別にQAチームが存在し、開発チームの実装したコードが正しいことをステージング環境で検証しています。 しかし今まではステージング環境のサーバーが1台しかなく、誰かがステージング環境を使用している間、他の人は別のブランチをデプロイすることができないという問題がありました。 この状況ではQAチームの人員を増やしたところで検証作業のスピードを上げることができず、QAが開発フローの中でボトルネックになることは避けられない状況でした。 この状況を打破するため、複数のステージング環境を同時に使うことができるようにする必要がありました。 Apache設定の変更 今回サーバー1台で複数の

    1台のサーバーで複数のステージング環境を同時に使えるようにする | PR TIMES 開発者ブログ
  • 旧ストレージ廃止大作戦−2900万超のファイルリストを取得する | PR TIMES 開発者ブログ

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

  • 本番環境で新機能・旧機能を自由に切り替えたい | PR TIMES 開発者ブログ

    こんにちは、開発部でバックエンドエンジニアをしています。江間です。 IPアドレスCookieを使って、機能の切り替えが出来る仕組みを実装したので、それについてお話します。 導入の背景 1度のリリースでの変更箇所を少なくしたい これまで変更内容が大きいリリースを行う場合、数カ月間メインのブランチから独立して作業を行ってきました。しかし、このやり方では以下の様な問題がありました。 変更箇所が多いので、コンフリクトが起こりやすくなる作業ブランチ間に依存関係が生じて、ブランチの関係性が複雑になる これらの問題を解決するには、1度のリリースの変更箇所を少なくして、メインのブランチにmergeすることです。 例として、今年6月に行った企業ページのリニューアルではいくつかの修正が加わりました。 これに伴い、企業ユーザー向けの管理画面も多くの修正が加わりました。 企業ページの新機能は管理画面に依存して

  • 1