はじめに チームトポロジーとは プラットフォーム開発組織に存在した課題 SRE何でも屋問題 中長期課題に取り組めない問題 チームトポロジーを元にした組織見直し SRE Deskを3つのDeskに分割 SRE DeskとPlatform Engineering Deskの違いを明文化 見直しの効果 見直しを通じての所感 最後に はじめに こんにちは。enechainでCTOを務めている@sutochin26です。 enechainでは、組織拡大に伴いSRE/Platform関連業務を行うチームの体制見直しを行ないました。 その際に、チームトポロジーの考え方を参考にする事で方針の言語化がしやすくなり、認識合わせの助けになりました。 SREとPlatform Engineeringをチームトポロジー視点で定義すること自体は新しくはないですが、本記事では実際に現場で生じていた課題と共にお話します。
PHP の use 文では、クラス名や関数名、定数、名前空間などのエイリアスを設定できます。 <?php use App\Foo; use App\Bar as ABar; $foo = new Foo(); $bar = new ABar(); https://www.php.net/manual/ja/language.namespaces.importing.php この use 文は指定したシンボルにエイリアスを設定する、言い方を変えると名前空間をインポートするもので、オートロードでクラス定義 PHP ファイルを読み込むものではありません。*1 例えば、上記コードの場合、use 文の時点で App\Foo や App\Bar に対するオートロードは動作しません。 この動きを確認してみます。 use 文のみを実行 use 文でオートロードが動作するかは下記のようなコードで簡単に確かめ
こんにちは、クラウド&ネットワークサービス部の福岡です。 SDPF(Smart Data Platform) クラウドの IaaS である、ベアメタルサーバー・ハイパーバイザーサービス開発のソフトウェアエンジニアとして働いています。 本記事では、リリースプロセスの改善を目指して QA チームが実施している試験の一部を自動化したことで、チームの底力が爆上がりした事例について紹介します。 SDPF ベアメタルサーバーサービスのミッション 機能リリースまでの流れと課題 課題1: 価値提供までのリードタイムが長くなる 課題2: QA チームの稼働がひっ迫する QA 削減に向けた取り組み 〜自動テストによる代替〜 思いがけない困難 どうやってこの困難に立ち向かったのか 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 2. チームでサービス説明書の読み合わせ会を実施 取り組みの成果 1
はじめに こんにちは、バックエンドエンジニアのSakiです!バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL(InnoDB)についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
Go のキャッシュライブラリの一つである golang-lru のソースコードリーディングを通して、LRUキャッシュアルゴリズムを自分なりにまとめたメモです。 記事公開前に追記 つい2週間前にv2がリリースされ、expirable な LRU キャッシュ機能が追加されたようです。 後で読みます。 LRUキャッシュアルゴリズムとは LRU(Least Recently Used)キャッシュアルゴリズムは、使われていないデータから削除するキャッシュアルゴリズムです。 Wikipedia 参考としたライブラリ Go でLRUキャッシュを採用している HashiCorp 社のライブラリを読んでみました。 サンプルコードを追ってみる README のサンプルコードを追ってみます。 サンプルコードでは、はじめにキャッシュエントリーを128個保存できるキャッシュインスタンスを作成します。 その後、for
サーバーサイドエンジニアの鬼木です! 今回はGoのin-memory cache packageについて調べてみた記事になります。既存機能の拡張でin-memory cacheを使う必要があり調査したことが背景としてあります。 以下について比較、調査しました。 github.com/allegro/bigcache github.com/coocood/freecache github.com/hashicorp/golang-lru github.com/dgraph-io/ristretto また今回の拡張にあたってはcacheの有効期限を設定できるかという点が重要であり、その観点についてまとめたものが以下になります。 TTL: 各Itemのcache保存後に有効期限切れするまでの時間の一律設定可否 TTL(item単位): cache保存時に保存するitemごとに有効期限切れするまで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く