ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ HashiCorpの創業者の一人であるミッチェル・ハシモト氏は、個人のプロジェクトとして開発してきたターミナルエミュレータ「Ghostty」のバージョン1.0を今年（2024年）12月にリリースし、合わせてオープンソースとして公開することを明らかにしました。 ハシモト氏は2023年12月にHashiCorpを退職。その後、個人プロジェクトとしてターミナルエミュレータの開発をしていることをX/Twitterなどで以前から発信していました。 これは2023年5月のポストです。「ここ数年、なんとなく自分用のターミナルエミュレーターを作っていた。過去18カ月、これを自分だけのターミナルとしてフルタイムで使っている」と書いていることから分かるとおり、Hashi
上の問題について、取組み状況を記録していくサイトです。 各問題が細かく難易度付けされており、必要な知識を段階的に習得できます。
このとき、最初(左)から数えて、 o の連続して出た数を数え、その最大値に注目します。上記の例では、 Aさんが最も多く、2回ですね。 さて、コイントスの表裏が出る確率がそれぞれ 50% (つまり、完全にランダム)であったと仮定した場合、連続して2回表が出る確率は以下ですよね。 (1/2)^2 = 1/4 そうすると、どれだけコイントスを試行したか （≒どれだけの人数がいたか） 考えたときに、最も確率が高いのは4回です。つまり総人数は4人！ こう数えることには、大きな利点があります。それは、 ある人が既にカウントされたかどうかを記録しておく必要がない ということです。なぜなら、 o が続いた最大数だけを覚えておけばいいので。これは、特に大きな人数集団であった場合には特に嬉しいですよね。 いやいや、大雑把すぎるだろとか、色々聞こえてきそうです。それは次のセクション以降で説明していきます。ただし
1. 初めにDBにおける処理はSQLによって記述しますが、データの取得するために具体的にどのような内部処理を行うかという点までは記述しません。 ここでいう内部処理とは「SQLの書き換え」「インデックスの使用」「結合アルゴリズムの選択」などがDBMSのオプティマイザによって選択されて実施されることを指します。 SQLのパフォーマンスを見るにあたっては上記の内部処理について正しく理解する必要があります。 本Blogでは、重要なアルゴリズムであるにもかかわらず、まとまった情報が少ないSQL実行時におけるブルームフィルタ(Bloom Filter)についてOracleをもとに紹介を行います。 Bloom Filterは結合処理を効率化するために、結合の前段階で利用される技術になります。 公式なドキュメントとしては以下になります。 Oracle Database SQLチューニング・ガイド 12cリ
ブルームフィルター(Bloom Filter)とは ブルームフィルターというのは1970年にブルームさんが作った確率的データ構造と呼ばれるデータ構造の1つです。 データ構造というのは 配列 連想配列 リスト などをイメージしてもらえば良いのですが、確率的データ構造という言葉はあまり聞き馴染みがありません。 確率的データ構造というのは簡単に言えば「値がデータ構造に入っているか、いないかをを知ることが出来るデータ構造」のことをいいます。 以下の例では5の値がlstに含まれているかを判定したいとします。pythonであればsearch_val in lstとすれば5の値がlstに含まれているかを簡単に判定することが出来るので、リスト(lst)は確率的データ構造の1つであるといえます。 search_val = 5 lst = [1,2,3,4,5,6,7,8,9] ブルームフィルターの最大の特徴
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
本書では、64-bit ARM (ARMv8/AArch64) アーキテクチャを前提としたハイパーバイザの仕組みをできるだけ分かりやすく解説し、実際にラズベリーパイ4やQEMUで動作するハイパーバイザ (Type1) を自作する方法を解説しています。 ソースコード: https://github.com/HidenoriMatsubayashi/evisor ⬛︎ 注意 本書はまだ作成中（現在5章を作成中）ですが、モチベーション維持のために公開している状態です（章立てなど今後変わる可能性ありです）。内容は随時更新していますので、気になる方はウォッチやコメント等をお願いします。 ⬛︎ 学べること ・ハイパーバイザとその仕組みと原理 ・64-bit ARM (ARMv8/AArch64) アーキテクチャの仮想化支援機構 ・自作ハイパーバイザの作り方 ⬛︎ コミュニティ 質問や間違い指摘など本書
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
この記事は、CYBOZU SUMMER BLOG FES '24 (クラウド基盤本部 Stage) DAY 9 の記事です。 こんにちは。DBRE チーム の山下です。 サイボウズではサービスを運用する上で多くのバッチ処理を実行しています。 Kubernetes 基盤を利用するにあたって、バッチ処理によく使われるのが Job だと思います。サイボウズでも多くの Job を活用しています。 そんな Kubernetes の Job ですが、リトライに関して想定と異なる挙動が見つかったためコードリーディング、kind での検証の両面から調査しました。 今回は調査によって得られた Kubernetes の Job のリトライの挙動に関する知見をご紹介します。 Job の概要 まずは簡単に Job について説明します。 Job は単発のジョブを実現するための Kubernetes リソースです。
将来のIntel製CPUに搭載される命令セット拡張、AVX10.2の情報が先日出ました。 Intel® Advanced Vector Extensions 10.2 (Intel® AVX10.2) Architecture Specification この記事では、AVX10.2の新機能をざっくりと紹介します。 静的な丸め指定 浮動小数点演算において演算結果を浮動小数点形式で正確に表現できない場合は丸めが発生します。この丸めのやり方はIEEE 754でいくつか定義されており、x86系では4つが利用可能です。丸めのやり方は通常は浮動小数点演算器の制御レジスターで選択されますが、AVX-512では、命令の機械語で丸め方を指定できるようになりました。 （宣伝：丸め方を静的に指定する話は「Binary Hacks Rebooted」にも書いたので是非読んでください。） ただ、機械語のエンコード
TL;DR 弾幕をシュッと書けるGoのコルーチン楽しい最高～～～！！ makiuchi-d/arelo などのライブリロードツールと組み合わせて使えば開発体験でもLuaに見劣りしないため、実用性も高そう！ 【CM】～ゆるい勉強会「Ebitengine ぷちConf」#3 8/30に開催します～ イベント詳細 「Go初心者もゲーム開発初心者でも誰でも参加できる、Ebitengine のゆるいLT/交流会」である Ebitengine ぷちConf の第三回が、8/30に開催されます。参加をご希望の方は、下記ページより登録してください！ 今回もオフライン（渋谷）とオンライン（YouTube Live）のハイブリッド開催です。 また今回は、Ebitengine 開発者星さんへのお便り・質問を大募集中！頂いた質問の中からいくつかを現地でお答えいたします。こちらの Google Form から応募で
離心数 無向グラブ\(G=(V,E)\)と正の辺の長さが与えられたとき、各頂点\(v\)に対して離心数\(\epsilon (v)\)を以下のように定義する \(\epsilon (v) = \displaystyle{\max_{w \in V} d(v,w)}\) ※但し\(d(v,w)\)は最短\(v-w\)路の長さ 半径 \( \displaystyle{\min_{v \in V}\epsilon(v)}\) 直径 \( \displaystyle{\max_{v \in V}\epsilon(v)}\) 中心 半径を定義する頂点 こんにちは！しゅんです！ 今回の記事ではグラフの離心数・半径・直径・中心について解説していきます！ これらはグラフ理論で登場する用語で、グラフの特徴を把握するときに使うことができます。 ということでこの記事ではグラフの離心数・半径・直径・中心がどんなも
IEEE浮動小数点数における演算では、丸め誤差が不可避です。特に、複数回の演算を繰り返すと丸め誤差が積もっていき、正確な値と大きく離れた答えを得てしまうことがあります。しかし、次の演算については、（数学的に）正確な値を求めた後、一回だけの丸めが発生することが、IEEE標準で規定されています。 四則演算 積和演算 Fused multiply add (FMA) 平方根演算（正の平方根を求める*1） 浮動小数点数演算のできるCPUであれば、普通、四則演算や積和演算を行う命令を持っています。 しかし、平方根を正確に計算する命令を持たない命令セットも存在します。 そのような場合、平方根関数はライブラリ実装となるわけですが、どのように実装すれば要求を満たせるのでしょうか？ C++のstd::sqrtは正確に計算しているのか？ 結論 しています。 標準の丸めモード、つまり最近接丸め（ぴったり半分なら
Introducing postgres.new, the in-browser Postgres sandbox with AI assistance. With postgres.new, you can instantly spin up an unlimited number of Postgres databases that run directly in your browser (and soon, deploy them to S3). Each database is paired with a large language model (LLM) which opens the door to some interesting use cases: Drag-and-drop CSV import (generate table on the fly) Generat
はじめに こんにちは！Google CloudでオブザーバビリティやSRE関連の担当をしているエンジニアです。この記事はGoアドベントカレンダーの22日目の記事です。 Goとオブザーバビリティ 私は業務でオブザーバビリティを中心として啓蒙活動や開発を行っているわけですが、その中で常に「改善にはまず計測が必要です」というメッセージをさまざまな方々にお伝えしています。 Goでは計測のための仕組みとして（ testing.B あるいは go test -bench として知られる）ベンチマーク[1]や pprof が最初期から[2]用意されていて、パフォーマンス計測はかなり標準が充実した言語になっています。 そして近年もそれに満足せず、Goを改善するための計測の仕組みがいくつも提案されています。 たとえばruntime/metricsはdesign #37112で提案されてGo 1.16から導入
Go: sync.Map's LoadAndDelete and LoadOrStore. Why are they needed? Read this to understand how sync.Map works internally: https://sreramk.medium.com/go-inside-sync-map-how-does-sync-map-work-internally-97e87b8e6bf To anyone new to concurrency, it might not seem obvious that just the methods Load , Store and Delete cannot be used to perform the basic read, write and delete operations commonly done
A while back my friend recommended that I try WezTerm. I’d been an iTerm 2 stalwart for the better part of a decade, but not to be too narrow-minded I conceded, started it up, and saw this: Does the job, sure, but doesn’t feel quite right. Okay then, experiment over. Back to iTerm… Fast forward a couple of months and I got the itch to try a new terminal again. I wanted to use one whose config was
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
