SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
信頼性目標とシステムアーキテクチャー / Reliability Objective and System Architecture
SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
ChatGPTでPythonのdiagramsを使ってAWSのサービス構成図生成コードを作ってもらう - Taste of Tech Topics
夏の暑さもだいぶ落ち着いてきていよいよ秋めいてきました、そろそろサンマがおいしい季節ですね、菅野です。 AWSを用いて様々なアーキテクチャを作成することが可能ですが、どういった構成になっているのかを一目で表すには図が効果的です。 手動でPowerPointや、draw.io等の作図ツールを用いて作成することも多いのではないか、と思いますが、ChatGPTで簡単に出力できたら便利ですよね。 Advanced Data Analysysの動作環境ではDiagramsライブラリがインストールされていないため、Pythonコードを直接ChatGPTで動かして構成図を出力してもらうことはできませんでした。 なので、今回はChatGPTにPythonのライブラリDiagramsを用いてクラウドの構成図を作成するPythonコードを作成してもらいましょう。 今回の検証ではGPT-4モデルを利用します。
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
はじめに - Writing an OS in 1,000 Lines
1000行でOSを作ってみよう 本書では、小さなOSをゼロから少しずつ作っていきます。 OSと聞くと腰が引けるかもしれませんが、OS (特にカーネル) の基本機能は案外単純です。巨大なオープンソースソフトウェアとしてよく挙げられるLinuxでさえ、バージョン0.01はたった8413行でした。様々な要求に応えるために次第に肥大化していっただけで、当初は大変素朴な実装になっていました。 本書ではコンテキストスイッチ、ページング、ユーザーモード、コマンドラインシェル、ディスクデバイスドライバ、ファイルの読み書きをC言語で実装します。これだけ様々な機能が詰め込まれているのに、コードは合計でたった1000行未満です。 「1000行なら1日でできそう」と思うかもしれませんが、初学者には少なくとも3日はかかるでしょう。OS自作のハマりポイントは「デバッグ」です。アプリケーション開発とは違うデバッグ手法
少しずつ育てるGo言語のプロジェクト構成
23/9/21追記：この記事を読む前に ついにGoチームから、プロジェクト構成に関するガイドが公開されました！ 本記事を読んでくださることも大変嬉しいですが、ぜひこちらのガイドもご一読ください！ この記事は何 Go言語を書いたことがある方も、興味はあるけど触ったことがない方もこんにちは。 Goに限った話ではないと思いますが、ガリガリコードを書いていて、あるタイミングで気になるのがプロジェクト構成（ここではディレクトリ構成の意図）ではないでしょうか？ それを裏付けるかのように、Go界隈では以下のリポジトリが話題に上がることがあります。Star数すごいですね😇 リポジトリ名から公式感が漂いますが、そういう訳ではないのがミソです。 こちらのリポジトリ冒頭にも記載されていますが、次の点に留意する必要があるでしょう。 これは、Goアプリケーションプロジェクトの基本的なレイアウトです。これは、コアと
Linux システムコール 徹底入門
Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
強い思想: Go を Web 開発に採用する上で
フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の公式リポジトリや有名ライブラリなんかも，Java などの言語に比べたらずっとパッケージ階層が浅く，ネストしていないものが多いと思う。 しかし，それも 「コードベースを小さく保つ」 を大前提としていることを忘れてはならない。 DDD やクリーンアーキテクチャといった言葉が飛び交うぐらいの規模であれば，パッケージを切ることに関して後ろめたさを感じる必要はない。 むしろ，大きなコードベースが誕生することが開発初期から簡単に予見できるような状況で， YAGNI という言葉に甘んじて設計を放棄するのは極めて悪手であると私は断言する。身を以て失敗を経験した私の口から伝えたい。
Pythonの開発環境の3つの観点をおさえよう
先日 "Python の「仮想環境」を完全に理解しよう" というスライドを公開したらかなり反響がありました。 Python の開発環境の構築は、正直言ってかなり複雑だと思います。 pip・venv・pyenv・Pipenv などなど、似たような名前・似たような役割のツールがたくさん登場して、最初は全然意味が分かりません。 慣れればなんとかなるのですが、慣れるまではかなり苦しいです。 このようにとても難解であるにも関わらず、Python は機械学習などでよく使われることから、避けられないことも多いです。 そこでこの記事には、「そもそも Python の開発環境にはどんな観点があるんだ？このツールはなにを解決してくれるんだ？」という話をまとめます。
Go 言語でアニメーション GIF を作成する
Golang でアニメーション GIF を作る手順を 3 通り紹介します。 フレームごとの画像から生成 ビデオから生成 Go 言語で最初から生成 フレームごとの画像から生成 こんな GIF 画像があったとします (ここ より拝借)。 変換結果はこんな感じ。 生成するためのコードはこんな感じ。 package main import "image" import "image/gif" import "os" func main() { files := []string{"g1.gif", "g2.gif","g3.gif", "g2.gif"} // 各フレームの画像を GIF で読み込んで outGif を構築する outGif := &gif.GIF{} for _, name := range files { f, _ := os.Open(name) inGif, _ := gi
今さら聞けないログの基本と設計指針 - Qiita
ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基本的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基本的に、外部ログ管理システ
コミットメッセージを書く時にgitmojiを使うのをやめた話 - Pepabo Tech Portal
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
コードレビューをAIに手伝ってもらい楽をしてみる - 技術探し
GitHub Next GitHub Next investigates the future of software development この機能の登場により、PR でのレビューのオーバヘッドを少なくすることが期待されます。この PR では何を変更したのかを説明したり、更には review の依頼を投げることもできます。 また、Issue でも AI にどうしたらよいか？を聞くこともできるそうです。詳しくは公式の動画を見てください。 How many times have you submitted a change and forgot to update the unit tests? Or the documentation? Or introduced linter errors. Perhaps we can fix that for you….watch this spa
Choose the Right Python Concurrency API - Super Fast Python
How to Choose the Right Python Concurrency API Python standard library offers 3 concurrency APIs. How do you know which API to use in your project? In this tutorial, you will discover a helpful step-by-step procedure and helpful questions to guide you to the most appropriate concurrency API. After reading this guide, you will also know how to choose the right Python concurrency API for current and
「コンセプトから理解するRust」を読んでRustに入門する - パンダのプログラミングブログ
パンダとおくだが、Web業界の当たり前を「これって本当にそうだっけ？」と問い直すラジオを配信しています 3年前に抱いていた Rust に対するイメージ 「コンセプトから理解するRust」（Amazon）という書籍を読んで Rust に再入門してみました。 実は2019年に Rust のチュートリアルである「The Rust Programming Language」（通称 TRPL）を写経したことがあります（GitHub）。 しかし、当時の自分は PHP のバックエンドエンジニアとしての経験が2年ちょっとあるくらいで、TypeScript にもまだ入門しておらず静的型付け言語の経験はほとんどなかったように記憶しています。 当時から Rust は所有権などの概念が難解で初心者を拒むものの、 Stack Overflow のアンケートで開発者から人気な言語として高い地位を誇っているというイメー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
あなたのPHPアプリ、ログはでてますか？あるいはログをだしてますか？ / Are you writing a log? Or just out a log?
https://engineering.mercari.com/blog/entry/20220418-e406d51f15/
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
『達人プログラマー 第2版』/ Pragmatic Programmer 2nd Ed.
