サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
studist.tech
注: Firebase Dynamic Links は非推奨になっているため、新しいプロジェクトでは使用しないでください。サービスは 2025 年 8 月 25 日に廃止されます。 Google は 7 年以上前に、URL… スタディストが提供しているTeachme Bizでは、一部でFDLを利用していたので本格的に移行を検討し始めました。 # 1年前に移行検討する理由このブログを書いているのが2024年7月なので、EOLまでまだ1年の猶予があります。なぜ今移行を検討するのかというと、Teachme Bizではモバイルアプリを提供しており、1年以内にリリースされたバージョンがサポート対象となっているためです。 リリースから1年以内のバージョンをサポート対象とします https://help.teachme.jp/hc/ja/articles/22205089652121 # FDLの利用状
背景弊社では効率的で迅速な開発プロセスを維持するためにコンテナ技術を使用しています。 これまでもコンテナイメージのビルド時間を短縮するための改善を行ってきましたが、今回のDocker Build Cloudの導入により、ビルド時間を大幅に短縮することができました。この改善によって、プルリクエストごとの検証環境を迅速に作成し、デプロイフローをより速くすることが可能となりました。 成果まず最初に成果を共有します。 今回、Docker Build Cloudを活用することで、コンテナイメージビルド時間を劇的に短縮することに成功しました。具体的には、従来約6分30秒かかっていたイメージのフルビルド時間が、約1分10秒まで短縮されました。この結果、ビルド時間を80%削減することができました。 コンテナイメージビルドにおける課題今まではコンテナイメージビルドの高速化のため Registry cache
皆さん、こんにちは。開発本部のリサーチ&デザイン室(以下リサデ)の室長の磯野です。今回は、私たちがプロダクトデザイングループ(以下プロデザ)からリサデへと生まれ変わった経緯と、これからの目標について紹介します。 設立の背景と目的開発組織が成長するにつれ、プロダクトの提供価値をより早く、より大きく高めるためにユーザーリサーチ活動の重要性が増してきました。しかし、従来の開発案件に紐づくリサーチだけでは、以下のような課題が生じていました。 リサーチ活動が開発のボトルネックになってしまう戦略的な意思決定へのリサーチ活動の貢献が限定的になってしまうこれらの課題を解消するために、開発案件とは別に幅広い顧客理解や、顧客のビジネス成功につながる課題発見を目的とした、より広範なリサーチ活動が必要とされるようになりました。 また組織のVisionとして「Design boosts」を掲げて、以下のように目指す
Photo by Dim Hou on UnsplashTeachme Biz にはCSVファイルをアップロードすることでアカウントの一括作成・一括更新ができる機能があります。先日、サービスをご利用中のお客様からのお問い合わせで「特定のCSVファイルのアップロードが 403 エラーになる」という事象が発覚しました。 アクセスログ等を調査した結果、この403エラーを返していたのはアプリケーションサーバーではなくその前段にある ALB (Application Load Balancer) であることが分かりました。ALBが、設定された WAF (Web Application Firewall) のルールに従いリクエストを終端していたのです。 ログを読んでみようAWS WAF の場合、ログの terminatingRuleId にリクエストを終端したルールが記録されます。問題のリクエストは
どうも。最近Dockerのことばかり書いてるビジネステクノロジーユニットのおかしんです。今回はDocker Desktopの代替としてRancher DesktopやPodman Desktopを試したのですが、それぞれ解決できない問題があり諦めた話をします。
Photo by Mohammad Rahmani on Unsplashどうもビジネステクノロジーユニットの @おかしん です。 今や世の中のあらゆるシステムの開発現場においてコンテナ技術は無くてはならないものになっています。コンテナ技術の中で最も広く利用されているのはDockerコンテナですが、昨年オープンソースソフトウェアであるDockerを開発しているDocker社が「Docker Desktop」というアプリケーションを有料化しました。 そこで、企業においてはどのように対応すべきか?また回避策はあるのか?を考えてみました。 Docker Desktopとは何かDocker DesktopはDocker社が提供しているソフトウェアでオープンソースソフトウェアであるDockerをWindowsやMacOSにおいて簡単にインストールし利用できるアプリケーションです。 DockerはLi
開発プロセスより大事なことこのような背景からClean Craftsmanshipの発売を楽しみにしていました。 Clean Craftsmanshipの概要Clean Craftsmanshipについて簡単に紹介します。 Marc AndreessenのWhy Software Is Eating the Worldが示す通り、ソフトウェア開発者が世界に持つ影響力は日に日に大きくなっています。 また、ソフトウェア開発の最も有名な手法の1つとしてアジャイルソフトウェア開発宣言があると思います。 本書は、このような世界でアジャイルソフトウェア開発宣言では触れられていないソフトウェア開発者のクラフトマンシップ(職人気質)について書かれた本です。 Clean Craftsmanshipの感想本書の中で、プログラマーが関係する事故としてボーイング737 MAXの事故やトヨタの急加速事故などが紹介さ
スタディスト 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2022年上半期、およそ500コンポーネントを持つ Vue 2 プロダクトである Teachme Biz を、半年間に渡る単独作業を経て、 Vue 3 に移行することに成功しました。 本記事では、私達がどのようにして、機能開発は止めずにバージョンアップや破壊的変更への対応を行えたのかを簡単に振り返ろうと思います。 昨年の TypeScript 移行の次のステップとして、今年は Vue 3 移行を実現することにより、相乗効果でのフロントエンド開発体験の向上を実現しました。 モチベーションTeachme Biz をVue 3 に移行するモチベーションは概ね以下になります。 モダンブラウザに合わせてリアーキテクチャリングされた Vue 3 の恩恵を受けることVue 2 への機能追加・改修が 2.7 で終了してしまった
IE サポートとは一体… スタディスト 開発本部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 Microsoft による Internet Explorer (以下 IE) のサポート終了(2022/06)を 目前(執筆時点) とし、フロントエンドエンジニアの皆様はウッキウキの日々を過ごされていることでしょう。 今回は、弊社の主要プロダクトである Teachme Biz における「IE サポート終了」が何を指しているのかを明らかにし、その範囲内で開発体験を最大限良くするために行った仕組み作りについてお話します。 TL;DRTeachme Biz は IE の「サポートを終了」するが、ビルドターゲットから IE を除外する「提供終了」をするわけではないVue 3 を採用したいが、そのためには IE への「提供終了」が必須IE 用ブランチを切ってコードフリーズし、IE 用
スタディスト開発ブログ Advent Calendar 2021の20日目の記事です。本日は技術支援ユニットの笹木(@s_sasaki_0529) が、開発環境で Rails を立ち上げずに、リモートAPIサーバに接続してフロントエンド開発を行えるようにした話をします。 TL;DRSPA なのに Rails と Vue が密になってるアプリケーションを開発してるせめて開発環境ぐらいはフロントエンド単体で開発できる状態にしたい様々な問題を対処し、理想のフロントエンド開発環境を実現したTeachme Biz の現状のアーキテクチャスタディストが開発・運用する、マニュアル作成・共有システム Teachme Biz は、Vue.js (≠ Nuxt.js) によるフロントエンドと、Ruby on Rails によるバックエンドで構成されています。 Teachme Biz (Web) の大雑把な構成
VPoEの@katsuhisa_です。毎日空き時間をみつけてはポケモンを捕まえています。さて記事タイトルにもあるように、スタディストの社内勉強会(社内では 「Studist Lightning Talks」というイベント名で運営しています)が50回目を迎えました。 ※厳密には50回目ではなく、もっとたくさん実施しています。詳細は後述。 せっかくなのでこれまでを振り返りつつ、「社内勉強会を長く続けるコツ」についてまとめてみます。ちなみに長く続けるコツをまだ思いついていないので、このブログを書きながら整理を試みます。 そもそも社内勉強会をなぜやるか「社内勉強会、やったほうが良いよね、あると良いよね」と、ソフトウェアエンジニアの界隈では一定の認識がされているように思えます。では、なぜそういった場が求められているのでしょう。私が意識しているのは、次のようなものです。 社内勉強会は、良い文化資本を生
スタディスト開発部の松野です。最近GitHub Actions上でGitHub GraphQL APIを使って情報を取得する機会が多くありました。そこでGitHub Appsなるものを知り、使ってみたのでその紹介をしたいと思います。 結論(TL;DR)GitHub Actions から GitHub API を叩く際の認証と認可でどの仕組みを使うか検討したPersonal Access TokenやOAuth Appを使うと、ユーザー個人に紐づく仕組みのため色々やり辛い社内用の GitHub Appsを作成し、そのPrivate keyからAccess Tokenを生成する方法で解決GitHubと連携するための仕組みGitHubには、作成しているツールとGitHubとの連携を容易にする仕組みとして、GitHub Apps、OAuth App、Personal Access Tokenがあり
ESLint の設定、見直せてますか? スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 今回は ESLint の設定を ESLint でテストする という一見奇妙な表題で、 ESLint 設定周りの課題を解決したお話をします。 https://eslint.org/課題感ESLint には標準で多数のルールが組み込まれており、それぞれに詳細なオプションが用意されています。それに加えて、豊富なサードパーティ製のルールや、設定を継承する仕組み(extends) まで揃っているため、設定パターンは無限にあると言っても良いでしょう。 コードベースが小さいうちは、 eslint:recommended のような推奨設定を継承するだけで、すぐにベストプラクティスを実践することができます。 しかし、Vue や TypeScript といった技術構成や、Pretti
Power Automateでスラッシュコマンドこんにちはビジネステクノロジーユニットのおかしんです。 私の所属するビジネステクノロジーユニットでは、主に社内情報システム、ITデバイスの管理、セキュリティなどを担っており、私は最近は様々なシステム間連携の構築や自動化に取り組んでいます。 Microsoft Power AutomateについてMicrosoft Power Automateをご存知でしょうか?以前はMicrosoft Flowという名前でしたが、いわゆるIPaaS(Integration Platform as a Service)というジャンルで、様々なWebサービスをつなぎ合わせて、ノーコードもしくはローコードで自動化を実現するサービスです。 toC向けだとIFTTTなどが有名でしょうか。 toB向けのプロダクトでは Zapierautomate.iointegroma
昨年(2021年)11月に入社した、モバイルエンジニアの岡本です。気がつけば、入社して3ヶ月が経ちました。 3ヶ月の節目のタイミングでふりかえりをしてみたところ、エンジニアリングマネージャ(以下、EM)として取り組めて良かったと感じることがあったので、この記事で紹介したいと思います。 また、前提となる、EMとして転職することに対して抱いていた不安についてもはじめに紹介します。 ## 転職時に抱えていた不安 Photo by S Migaj on Unsplash今回の転職は人生初のEMとしての転職だったこともあり、以下のような不安を抱えていました。 ・EMに何を期待しているのだろうか ・EMに対する現場と上司の期待値はあっているのだろうか ・他にEMを目指したい人はいないのだろうか ・上記の内容を正直に話してもらえるだろうか ・EMが参画し不要な摩擦は起きないだろうか ・何から手を付け、ど
Photo by Christopher Gower on Unsplashこんにちは、SRE Unit の wind-up-bird です。少し前に Terraform Cloud から GitHub Actions に移行したお話というタイトルでブログを書きました。今回はその後日談を少し紹介したいと思います。 # これまでの state 運用今までは Terraform の state の操作は手動で実施していました。具体的には、terraform import, state mv, state rm をローカルで実行した後、PR を作成して state と tf ファイルの差分を埋めるという運用でした。 # 課題ここで以下のような問題が出てきます。 誰がどのような state 操作をした(しようとしているか)分からない。また、誤操作してしまう可能性もある。PRのレビュー後 tf ファ
kyafu呼び出しに対する応答画像はSlack上でkyafu deployコマンドが叩かれている様子です。work1–10のどのインスタンスを利用するのかと検証したいブランチ名を指定しています。 構成を簡単に示すと以下のようになります。 簡易な構成図InfraやCI/CDについての知識がほとんどなかった私にとって、kyafuは魔法のコマンドでした。簡単に検証環境のデプロイや起動ができ、実行完了後に通知まで送ってくれるのでとても便利です。 ですが、当時のkyafu(というか検証環境の運用)には課題感もありました。それは、使用する環境の衝突が起きないように調整する必要があったことです。 大体どのチームがどの番号のインスタンスを使うのか、までは決まっていましたが、同一チーム内に検証したい機能が複数あった場合、検証用のインスタンス数に限りがあるため、待ちが発生することがありました。 Kuberne
Photo by Ludde Lorentz on Unsplashスタディスト開発ブログ Advent Calendar 2021 14日目担当の島田(@m0sh1dawa)です。好きなNBA選手はシェーン・バティエです。今回は技術寄りの話ではなく、VPoEの記事と同様にこの一年で感じたことを書き散らしていこうと思います。 これまでまず、私のスタディストにおける略歴を紹介します。 2017年にTeachme BizのWindowsアプリ開発担当として入社2019年からは組織変更に伴いネイティブアプリグループ(※)のエンジニアリングマネージャーを兼務2020年には二か月間の育休を取得育休復帰後は、課題解決の手札を増やすためにマネージャーからいちエンジニアにジョブチェンジし、現在に至る※Teachme BizにはWebアプリとは別に iOS, Android, Windows の各プラットフ
スタディスト開発ブログ Advent Calendar 2021の13日目の記事です。 こんにちは、SRE Unit の wind-up-bird です。以前、 Serverless Framework を移行しているお話を書きましたが、今回は移行シリーズ第2弾ということで、 Terraform Cloud を Terraform on GitHub Actions に移行したお話をお届けしたいと思います。 # 移行前の運用スタディストではこれまで Terraform Cloud の Team & Governance プランを契約していました。移行前の Terraform による開発の流れは、以下のとおりです。 Terraform Cloud 上で Workspace を作成し、Version control workflow を利用する。Workspace には環境変数として、 AWS
スタディスト開発ブログ Advent Calendar 2021 8日目の記事です。Hansoku Cloud 開発グループのマネージャーをしている zuckey が担当します。2020年の末にHansoku Cloudという新規事業のアプリケーションをリリースしたのち、そのプロダクトおよびサービスのグロースに力を入れてきました。 本エントリでは、Hansoku Cloud で今年の6月に検討を開始し、9月にリリースにこぎつけたモバイルアプリの開発全般について書きます。 TL;DR“ガワネイティブ” からネイティブAPIへのブリッジ部分を提供してくれるライブラリ Capacitor を利用してiOS / Android向けのモバイルアプリをリリースしたWeb開発者がモバイルアプリを開発するにはどのようなツールを使うにしても、チームで学習を深めていく必要がある。Full Stack なチーム
そうした中で、私が感じていることとしては、 VPoEの役割に限らないが、 VPoEのスタイルに唯一の解はないただし、CTOに比べると、問題空間はより限定される傾向にあるのではないかその中でも、採用・組織づくりについては特に期待が大きいというものです。CTOはフェーズによって期待が大きく変わりますが、VPoEはフェーズによっても問題空間はそれほど大きく変わらないが、より大規模に実行することが求められ続けるのではないか…と現時点では考えています。 各社ごとに特殊性があるその一方で、各社ごとに特殊性はあり、私がスタディストで担当している領域を改めて振り返ると、以下が一般的なVPoEの役割からは連想しづらい部分だと思います。 技術横断的な施策を推進するチームのマネージャーの役割人事領域のタスク推進にあたっての、全社関連部門とのハブ役前者は世の中的にはCTO室としてCTO管掌で整理されるケースがあり
はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。 これまでの開発の流れスタディストでは AWS Lambda および周辺リソース(AWS IAM や Amazon API Gateway など)の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。 Lambda の開発serverless.yml を作成開発者がデプロイ担当者に連絡する担当者がローカルの環境から serverless deploy を手動実行Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりません
スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。 本記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。 なお、本記事の内容は、移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” と、移行完了後の登壇資料 “6万行の TypeScript 移行とその後” と重複する内容を含んでいます。 Teachme Biz と TypeScript弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/Android や Windows など、マルチプラットフォームで提供されています。 その中でも、作成・管理に多く使われて
皆さんは、レポート機能を活用してますか? マニュアルの中には「季節限定新メニューのレシピ」「あたらしく導入した機械設備の操作方法」など 必ず閲覧してほしいマニュアル ってありますよね。 「作成したマニュアルの閲覧数は伸びているけど、… 今回はこの詳細版レポート機能の中身のポイントと、そこに至るまでについてお話いたします。 詳細版レポート機能のポイントデータストアにTimestreamを利用しているTimestreamにデータ投入するにあたり Fluentd 用プラグインをOSSで開発NestJS を採用したマイクロサービスで提供順番に説明します。 データストアに Timestream を採用した理由従来のレポート機能は以下のようになっていました。 ユーザがマニュアル作成/閲覧などサービスを利用すると(①)、Fluentd経由で Amazon Kinesis Data Firehose にア
こんにちは、QAグループマネージャーの岩崎です。 以前「モダンなQA組織を目指して」という記事を投稿してから、ブログみたよ!と連絡を貰えることがあり嬉しく思います。 今回はQA組織の成長、QAエンジニアとして成長するために意識してきたことや、普段行っている業務や考え方を整理し、「QAの価値」と「QAにとって重要な要素」を言語化した話をします。 前提:顧客価値を正しく提供するためのQA前提としてスタディストQAにおける品質についての話をします。 スタディストQAでは「顧客価値」を重視した品質活動をしています。 そのため下流のテスト活動にとどまらず、上流での品質担保を試行錯誤し、「顧客価値」を正しく提供・担保できるように日々尽力しています。 当然下流におけるテスト活動も重要ではありますが、上流工程でのアプローチが「顧客価値」を提供する上で最も重要だと考えているためです。 その上流工程での作業を
スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 今回は、弊社が開発・運用している TeachmeBiz でも使用している、webpack を 4系から5系にアップグレードし、開発体験を向上させたお話です。 webpackwebpack 4 -> 5 のアップグレードについては、既に多くの事例がありますが、移行の手順や発生する問題というのは、プロダクトの特性や現在の構成に大きく依存するところもあるため、スタディストではどうだったかを改めて紹介致します。 TL;DRwebpack 4.x から webpack 5.x へのアップグレードはすんなりできたビルドコストを 1/3 削減することができたDependabot から通知される脆弱性のほとんどに対応もできたTeachmeBiz の技術構成TeachmeBiz のフロントエンドは、主に以下の技術構成とな
スタディスト 開発部 技術支援グループの笹木(@s_sasaki_0529) です。 技術支援グループ(旧 開発基盤チーム) では、開発チームを横断した技術的なサポートや、生産性向上のための仕組み作りを行っています。 前回、以下の記事にて、弊社でのフロントエンド技術の変化をご紹介致しました。
どうしたの?スタディストwebアプリグループでは、毎朝「エラーを見る会」というものを実施しています。「エラーを見る会」は、日々発生しているサーバーエラーを把握し、顧客影響(被害)を最小限にする目的の元、webアプリグループメンバーで行われている会です。そこでは、サーバー上で出たエラーを見て、「このエラーは早めになおしたいね」とか「このエラーはバックログに積んであとでなおそう」といった話し合いを行っています。 「エラーを見る会」で、以前より「ActiveRecord::Deadlocked」の発生を確認していましたが、詳細な原因を特定できていませんでした。そこで原因特定のために、ログ出力を行った事例について今回ご紹介します。 デッドロック情報を出力する弊社では、Amazon RDS Aurora MySQLを使用しております。 原因を調べるにあたり、ストレージエンジン(InnoDB)に関する
次のページ
このページを最初にブックマークしてみませんか?
『スタディスト Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く