UUIDを短くするライブラリを作った
のように、22文字程度の短くてスッキリしたIDに変換できます。 これを簡単に行うためのライブラリ「uuid58」を作成しました。 本記事ではuuid58を作った背景や使い方、特徴を紹介します。 動機 データベースの主キーにUUIDを使うことは多いですが、UUIDは36文字（ハイフン込み）と長く、URLに埋め込むと見た目も悪くなりがちです。 「短くしたい！」と思ってBase64エンコードを考える人も多いですが、Base64は/や+、=などURLで使いにくい文字が含まれてしまいます。 そこで、Bitcoinでも使われているBase58（視認性の悪い文字を除外したアルファベット）でエンコードすれば、 最大22文字に短縮できる URLセーフ 見た目もスッキリ という理想的なIDが作れます。 既存のUUID→Base58変換ライブラリを探してみたのですが、 Node.jsのcryptoに依存していて
WebAssembly Core Specification
WebAssembly Core Specification W3C Candidate Recommendation Draft, 18 December 2024 More details about this document This version: https://www.w3.org/TR/2024/CRD-wasm-core-2-20241218/ Latest published version: https://www.w3.org/TR/wasm-core-2/ Editor's Draft: https://webassembly.github.io/spec/core/bikeshed/ History: https://www.w3.org/standards/history/wasm-core-2/ Implementation Report: https:/
OpenSearch 3.0リリース、GPUアクセラレーションにより処理速度が大幅に向上 | gihyo.jp
OpenSearch Software Foundationは2025年5月6日、オープンソースの全文検索・分析エンジンOpenSearchの新バージョンOpenSearch 3.0をリリースした。 Announcing OpenSearch 3.0 OpenSearch 3.0 Enhances Vector Database Performance, Search Infrastructure and Scalability to Meet AI-driven Demand OpenSearchはElasticsearchを元に開発された全文検索エンジン。大規模データの検索、分析を高速に行うことができ、Apache License version 2（ALv2）のもとオープンソースソフトウェアとして公開されている。 OpenSearch 3.0はベクターエンジン向けGPUアクセラレーシ
RubyKaigi 2025 に総勢35名で参加しました！みんなで書く感想レポート - STORES Product Blog
スポンサーボードにみんなの名前を書きました こんにちは、ima1zumiです。RubyKaigi 2025 お疲れさまでした！みなさん、RubyKaigi 2025と松山は楽しんでいただけましたか？私はみなさんの感想ブログを読みながらRubyKaigiの余韻に浸る生活をしています。RubyKaigi 2025が終わらない。 STORES はNursery Sponsorとして、託児所の企画・運営をしました。また、会場ではブースを出したり、会期中にSTORES CAFE for WomenとSTORES CAFE at RubyKaigi 2025を開催したりと、盛りだくさんな3日間でした。 このブログではRubyKaigi 2025に参加したメンバーから印象に残ったセッション、出来事について聞きました。それぞれの視点のレポートをお楽しみください。 ima1zumi (Keynote spe
Remotework.jp
アナログで非効率な配送業務をDXする「TODOCU（トドク）サポーター」の開発・運営を行っています。また「TODOCUサポーター」の運営によって取得した配送効率化データを活用することで、人材不足の物流領域にギグワーカーという新しい配送リソースを提供する事業「スキマ便」も同時に運営しております。ドローンや自動運転といった未来の配送に必要となる「配送効率化データ」と「配送拠点等のリアルオペレーション」の整備を2つの事業を通して行っております。完全フルリモートながら、様々なツールや仕組みによって助け合える自由なカルチャーと、有機的にはたらくメンバーが魅力です。（募集中）
Mission Center
Monitor your CPU, Memory, Disk, Network and GPU usage. Features Monitor overall or per-thread CPU usage See system process, thread, and handle count, uptime, clock speed (base and current), cache sizes Monitor RAM and Swap usage See a breakdown how the memory is being used by the system Monitor Disk utilization and transfer rates Monitor network utilization and transfer speeds See network interfac
RubyKaigi 2025 参加レポート - Ruby で pidfd を利用する - RAKSUL TechBlog
はじめに こんにちは。SRE チームの吉原 哲です。 RubyKaigi 2025 に参加してきました。中でも特別興味のあるセッションがありました。Maciej Mensfeld (@maciejmensfeld) 氏による Bringing Linux pidfd to Ruby です。彼は Karafka の作者で、以前社内の Karafka をアップグレードしたときお世話になった方です。そのときの話はこのブログエントリ (Kafka と Karafka を無事故・無停止でアップグレードした話) をご参照ください。今回 RubyKaigi へ参加するにあたって是非ともお話を聞きたいと思っていました。 本エントリでは pidfd とは何なのか事前調査した内容と、発表の内容を織り交ぜながら解説します。 pidfd とは Linux 5.3 で導入された pidfd (PID File De
Ractorの中からnet/httpsでHTTPSリクエストを送る - osyoyu.com/blog
Ractor (non-main Ractor) からHTTPSリクエストを送る例。Faradayのような便利なライブラリは内部でクラスインスタンス変数 @@nanika を多用している都合、コードの変更なしではRactorの中から使うことができない（Faradayに限らず、世の中のgemのかなりの部分がこの制約で阻まれる）。net/http (net/https) ならぎりぎり Ractor.make_shareable で対応できる。 require 'openssl' require 'net/https' # net/http が使う定数を事前に deep freeze しておく Ractor.make_shareable OpenSSL::SSL::SSLContext::DEFAULT_PARAMS Ractor.make_shareable Net::HTTP::SSL_IV
今日から『自由』にMySQLの性能改善始めます。（MySQL開発チームを退職しました）
前回の在籍も含めると、累計9年半、本家MySQLチームでInnoDBの性能改善をターゲットに開発の仕事してきました。5.7でのb-tree index scaleや、8.0の初期の新機能で入ってしまった性能問題の修正など貢献できましたが、ここ数年は開発が進む度に導入される性能劣化に追いつけなくなってしまいました。悪いコードを見つけて直そうとしても抵抗が大きいのも大きな要因です。（遅くしたいのでしょうか？遅いことが認識できないのでしょうか？） この度、体制変更で退職を勧められたのを機に、別の営みでMySQL/InnoDBの性能を改善していくことにしました。どうせ、性能劣化に(私よりも)無頓着な現体制では私が性能を改善することは困難なので、成果は出ないでしょう。（直しても、同時に導入される新機能・修正による劣化に改善分を喰いつぶされることもしばしばあった、と考えています。キリがありません。そも
ソフトウェアエンジニアが抱えやすい21の苦労 - mtx2s’s blog
ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労することに、そもそも違和感を持てないのだ。 日常化した苦労は、改善されることがない。違和感がないからこそ、問題として扱われない。そして、原因に目が向けられることもなく、風景に溶け込んだまま、空気のようにあり続ける。 つまり、苦労を軽減するには、日常風景の中から問題を見つけ出す必要がある。そのための第一歩が、「気づく」ことだ。問題というのは、気づかなければ解決のしようがない。学校の試験のように、誰かに出題されるものではないのだから。 本記事では、「気づく」ための視点を言語化し、手がかりとして整理している。 ソフトウェアエンジニアリング業務でありがちな苦労を、
Redis 8正式リリース、AGPLのもと再びオープンソースとして利用可能に | gihyo.jp
Redis 8正式リリース、AGPLのもと再びオープンソースとして利用可能に Redisは2025年5月1日、KVSデータベースRedisの最新バージョンRedis 8の一般提供（GA）を開始した。 Redis 8 is now GA, loaded with new features and more than 30 performance improvements Redis is now available under the AGPLv3 open source license 🚨Redis 8 is GA today.🚨 It's fast, loaded with new features, comes with the tools in Redis Stack included, and it's open source. Read more here: https:
3年かけてついに完成した「CUDA」の代替はAI開発を変えるのか
CUDAの代替技術を開発することは、決して簡単なことではない。 ModularのChris Lattner氏が率いる120人の開発チームは、CUDAだけでなくAIソフトウェアスタック全体をゼロから置き換えることを目指し、3年間にわたり取り組んできた。 Lattner氏は米国EE Timesの取材に応じ「そのためには何が必要だろうか。実際、CUDAの代替技術の開発は非常に難しく、何年もかかる。われわれはこの3年間、プログラミング言語やグラフコンパイラ、大規模言語モデル（LLM）の最適化などに取り組み、それを全て整理して、大規模実装や試験、検証などを行ってきた」と述べている。 既存のAIソフトウェアスタックの問題の原因は、それが突然出現して、現在も非常に速く変化しているという事実にある。新しいユースケースやモデルに対応するために、すぐさまレイヤーが追加されるのだ。現在、CUDAの上には、One
Redis is now available under the the OSI-approved AGPLv3 open source license.
The rise of hyperscalers like AWS and GCP has unlocked incredible speed and scale for startups and enterprises alike. But for companies rooted in open source, it has posed a fundamental challenge: how do you keep innovating and investing in OSS projects when cloud providers reap the profits and control the infrastructure without proportional contributions back to the projects that they exploit? To
『技術リーダーシップのための14のヒント』 - snoozer05's blog
編者を担当した電子書籍『技術リーダーシップのための14のヒント』が、2025年5月1日にオライリー・ジャパンより刊行となりました。オライリー・ジャパンさんのサイトから無料でダウンロードいただけます。 技術リーダーシップのための14のヒント - O'Reilly Japan 本書は、Roy Osherove著『Elastic leadership : growing self-organizing teams』（Manning）の翻訳書籍として2017年に出版された拙訳『エラスティックリーダーシップ : 自己組織化チームの育て方』（オライリージャパン）に、日本語版特典として収録させていただいた日本人執筆者による14のエッセイ部分を、独立した形に再編集したものです。 リーダーに求められる立ち振る舞い、コミュニケーションや情報共有をリードする方法、リーダーと開発者の兼任、チームメンバーが自己組織
Protocol Buffersのメディアタイプ ”application/protobuf” がIANA登録へ - ASnoKaze blog
Protocol Buffersのメディアタイプとして”application/protobuf”などをIANAに登録する動きがある。これにより、Protocol Buffersを返すHTTPレスポンスで指定するContent-Typeヘッダの値が明確になる。 Media Type Registration for Protocol Buffers 現在はIETFに『Media Type Registration for Protocol Buffers』というDraftが提出されているところである。(RFC6838によると、Standards TreeではRFCが必要。) Draftでは下記のメディアタイプの登録している application/protobuf application/protobuf+json また、非推奨としつつも慣習的に使われていた下記もエイリアスとして登録してい
RubyKaigi 2025 参加記録 - joker1007’s diary
愛媛県松山市で開催されたRubyKaigi 2025に参加してきました。 今回は、近くに道後温泉があったことやカンファレンス自体が水・木・金開催だったこともあり、月曜日に道後温泉に一泊したりしたので、余裕をもって観光が出来たかなと思います。 沖縄の時はなんだかんだで車が無いと色々厳しいなーという感じだったので、自動車免許持ってない自分にはちょっとやり辛いところがあったんですよね。 来年は函館らしいですが、北海道は土地が何もかも広いので、見て回るには結構大変かもしれないなーとその辺りの点で若干の不安がありますね。 という訳で、今回のRubyKaigiを振り返っていきます。 とりあえず、Day-1からの簡単な記録から。 （人が写ってる写真は基本的にTwitterにツイート済みのものか大丈夫なものを選んでるはず) Day -1 つまり、月曜日。お昼ぐらいに松山の大街道に到着、荷物を何とか預けて宇
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SadServers - Linux & DevOps Troubleshooting Interviews
MCPを理解する
GitMCP
DeepWiki | AI documentation you can talk to, for every repo
