ブックマーク / studist.tech (13)

  • MacのDocker Desktop代替としてRancher DesktopとPodman Desktopを試して諦めた話

    どうも。最近Dockerのことばかり書いてるビジネステクノロジーユニットのおかしんです。今回はDocker Desktopの代替としてRancher DesktopPodman Desktopを試したのですが、それぞれ解決できない問題があり諦めた話をします。

    MacのDocker Desktop代替としてRancher DesktopとPodman Desktopを試して諦めた話
    toshikish
    toshikish 2023/04/18
  • Docker Desktopの有料化が企業に与える影響と、企業における適切なDockerの利用方法

    Photo by Mohammad Rahmani on Unsplashどうもビジネステクノロジーユニットの @おかしん です。 今や世の中のあらゆるシステムの開発現場においてコンテナ技術は無くてはならないものになっています。コンテナ技術の中で最も広く利用されているのはDockerコンテナですが、昨年オープンソースソフトウェアであるDockerを開発しているDocker社が「Docker Desktop」というアプリケーションを有料化しました。 そこで、企業においてはどのように対応すべきか?また回避策はあるのか?を考えてみました。 Docker Desktopとは何かDocker DesktopDocker社が提供しているソフトウェアでオープンソースソフトウェアであるDockerWindowsMacOSにおいて簡単にインストールし利用できるアプリケーションです。 DockerはLi

    Docker Desktopの有料化が企業に与える影響と、企業における適切なDockerの利用方法
    toshikish
    toshikish 2022/10/24
  • 機能開発を止めずに、500コンポーネント規模の Vue 3 移行を完了させた開発プロセス

    スタディスト 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2022年上半期、およそ500コンポーネントを持つ Vue 2 プロダクトである Teachme Biz を、半年間に渡る単独作業を経て、 Vue 3 に移行することに成功しました。 記事では、私達がどのようにして、機能開発は止めずにバージョンアップや破壊的変更への対応を行えたのかを簡単に振り返ろうと思います。 昨年の TypeScript 移行の次のステップとして、今年は Vue 3 移行を実現することにより、相乗効果でのフロントエンド開発体験の向上を実現しました。 モチベーションTeachme Biz をVue 3 に移行するモチベーションは概ね以下になります。 モダンブラウザに合わせてリアーキテクチャリングされた Vue 3 の恩恵を受けることVue 2 への機能追加・改修が 2.7 で終了してしまった

    機能開発を止めずに、500コンポーネント規模の Vue 3 移行を完了させた開発プロセス
    toshikish
    toshikish 2022/08/03
  • 社内ツール kyafuコマンド の紹介

    kyafu呼び出しに対する応答画像はSlack上でkyafu deployコマンドが叩かれている様子です。work1–10のどのインスタンスを利用するのかと検証したいブランチ名を指定しています。 構成を簡単に示すと以下のようになります。 簡易な構成図InfraやCI/CDについての知識がほとんどなかった私にとって、kyafuは魔法のコマンドでした。簡単に検証環境のデプロイや起動ができ、実行完了後に通知まで送ってくれるのでとても便利です。 ですが、当時のkyafu(というか検証環境の運用)には課題感もありました。それは、使用する環境の衝突が起きないように調整する必要があったことです。 大体どのチームがどの番号のインスタンスを使うのか、までは決まっていましたが、同一チーム内に検証したい機能が複数あった場合、検証用のインスタンス数に限りがあるため、待ちが発生することがありました。 Kuberne

    社内ツール kyafuコマンド の紹介
    toshikish
    toshikish 2021/12/16
  • Terraform Cloud から GitHub Actions に移行したお話

    スタディスト開発ブログ 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

    Terraform Cloud から GitHub Actions に移行したお話
    toshikish
    toshikish 2021/12/13
  • Web開発者のみでCapacitor を利用し、3ヶ月でモバイルアプリをリリースした話と、展望

    スタディスト開発ブログ Advent Calendar 2021 8日目の記事です。Hansoku Cloud 開発グループのマネージャーをしている zuckey が担当します。2020年の末にHansoku Cloudという新規事業のアプリケーションをリリースしたのち、そのプロダクトおよびサービスのグロースに力を入れてきました。 エントリでは、Hansoku Cloud で今年の6月に検討を開始し、9月にリリースにこぎつけたモバイルアプリの開発全般について書きます。 TL;DR“ガワネイティブ” からネイティブAPIへのブリッジ部分を提供してくれるライブラリ Capacitor を利用してiOS / Android向けのモバイルアプリをリリースしたWeb開発者がモバイルアプリを開発するにはどのようなツールを使うにしても、チームで学習を深めていく必要がある。Full Stack なチーム

    Web開発者のみでCapacitor を利用し、3ヶ月でモバイルアプリをリリースした話と、展望
    toshikish
    toshikish 2021/12/09
  • Serverless Framework から lambroll + Terraform に移行しているお話

    はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。 これまでの開発の流れスタディストでは AWS Lambda および周辺リソース(AWS IAM や Amazon API Gateway など)の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。 Lambda の開発serverless.yml を作成開発者がデプロイ担当者に連絡する担当者がローカルの環境から serverless deploy を手動実行Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりません

    Serverless Framework から lambroll + Terraform に移行しているお話
    toshikish
    toshikish 2021/10/27
  • 機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス

    スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。 記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。 なお、記事の内容は、移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” と、移行完了後の登壇資料 “6万行の TypeScript 移行とその後” と重複する内容を含んでいます。 Teachme Biz と TypeScript弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/AndroidWindows など、マルチプラットフォームで提供されています。 その中でも、作成・管理に多く使われて

    機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス
    toshikish
    toshikish 2021/09/25
  • Timestreamを利用した詳細版レポート機能をリリースしました

    皆さんは、レポート機能を活用してますか? マニュアルの中には「季節限定新メニューのレシピ」「あたらしく導入した機械設備の操作方法」など 必ず閲覧してほしいマニュアル ってありますよね。 「作成したマニュアルの閲覧数は伸びているけど、… 今回はこの詳細版レポート機能の中身のポイントと、そこに至るまでについてお話いたします。 詳細版レポート機能のポイントデータストアにTimestreamを利用しているTimestreamにデータ投入するにあたり Fluentd 用プラグインをOSSで開発NestJS を採用したマイクロサービスで提供順番に説明します。 データストアに Timestream を採用した理由従来のレポート機能は以下のようになっていました。 ユーザがマニュアル作成/閲覧などサービスを利用すると(①)、Fluentd経由で Amazon Kinesis Data Firehose にア

    Timestreamを利用した詳細版レポート機能をリリースしました
    toshikish
    toshikish 2021/09/09
  • 「信頼」がQAの価値を生む

    こんにちは、QAグループマネージャーの岩崎です。 以前「モダンなQA組織を目指して」という記事を投稿してから、ブログみたよ!と連絡を貰えることがあり嬉しく思います。 今回はQA組織の成長、QAエンジニアとして成長するために意識してきたことや、普段行っている業務や考え方を整理し、「QAの価値」と「QAにとって重要な要素」を言語化した話をします。 前提:顧客価値を正しく提供するためのQA前提としてスタディストQAにおける品質についての話をします。 スタディストQAでは「顧客価値」を重視した品質活動をしています。 そのため下流のテスト活動にとどまらず、上流での品質担保を試行錯誤し、「顧客価値」を正しく提供・担保できるように日々尽力しています。 当然下流におけるテスト活動も重要ではありますが、上流工程でのアプローチが「顧客価値」を提供する上で最も重要だと考えているためです。 その上流工程での作業を

    「信頼」がQAの価値を生む
    toshikish
    toshikish 2021/08/23
  • webpack時代にクロスオリジンという戦場でpdf.jsのweb workerを動かす

    初めにスタディスト開発部、フロントエンドグループの小宮山です。先日タイ出張する機会があったので、ついでにルンピニー公園を走ってきました。 タイでランニング、タイでラン、タイラン、タイランドだけに。 微妙なギャグにタイランレイブやりたかったこと概要タイトルの通り、今回やりたかったことはpdf.jsを使ってブラウザ環境にてpdfファイルを表示することです。pdfファイルはFile Apiを利用して取得します。 JavaScriptpdfファイルを扱うことなんてできるのかと不安でしたが、なんとMozilla様がpdf.jsという素晴らしいライブラリを提供してくれていました。

    webpack時代にクロスオリジンという戦場でpdf.jsのweb workerを動かす
    toshikish
    toshikish 2021/03/10
  • スタディスト開発部が目指す SRE の未来と現状と Kubernetes

    (上記ブログ執筆時は、EKS on EC2 へ移行予定でしたが、EKS on Fargate への移行を行う方針に切り替えました。) Kubernetes 移行に関連する技術面の話題についてはご紹介してきた一方で、これまでの記事では、 「なぜ Kubernetes 移行を行っているか?」「スタディスト開発部は、最終的に何を目指しているのか?」といった背景には触れておりませんでした。そこで記事では、スタディスト開発部が目指す世界観と、その過程として歩んでいる Kubernetes 移行の位置づけについてご紹介します。 目次Teachme Biz における Infra の現在と抱えている課題スタディスト開発部が目指す世界観Kubernetes 移行の位置づけ今後のやりたいことTeachme Biz における Infra の現在と抱えている課題現在 Teachme Biz の大部分(以降、

    スタディスト開発部が目指す SRE の未来と現状と Kubernetes
    toshikish
    toshikish 2020/10/05
  • ドメイン駆動Vuexで複雑さに立ち向かう

    スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex(さらにその他Flux状態管理も)を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs

    ドメイン駆動Vuexで複雑さに立ち向かう
    toshikish
    toshikish 2018/09/18
  • 1