こんにちはこんばんわ、ログラスで開発のあれやこれやをしているknih(Kenichi Suzuki)です。 クリスマスいかがお過ごしでしょうか?本稿はログラスのプロダクトアドベントカレンダー最終日の投稿になります。 さて、強い組織であるためには情報の伝導率が重要です。意思決定をするにしても現状がどうなっているのか、決定されたことがどうなったのか、情報が錯綜して見通しが立たない状況では何をするにしても動きが悪くなってしまうでしょう。 ソフトウェアも同じく、型の伝導率が重要です。型を無理やり剥がしていては、リファクタリングするときの正確性が損なわれて、改修を重ねるたびにいつの間にか品質が落ちてしまいます。 高信頼で安全、それでいて簡潔で認知負荷の低い、すなわち複雑性に立ち向かえるソフトウェアを作っていくためにはどうしたらよいでしょうか。そのヒントになるやもしれないと、私が近年注目しているFli
https://fortee.jp/phpcon-2026/proposal/fc3d00e7-91ab-431a-94ae-d79601d9d585
2026年7月17日、WordPressを開発するWordPress.orgは、WordPress Coreに認証不要のリモートコード実行(RCE)に至る深刻な脆弱性が確認されたとして、セキュリティリリース版WordPress 7.0.2を公開し、対象バージョンを利用するサイトに自動更新システム経由での強制アップデートを有効化する対応を取りました。これら2件の脆弱性を組み合わせた攻撃は、発見者により「wp2shell」と命名されています。ここでは関連する情報をまとめます。 どんな脆弱性が確認されたの? WordPress Coreでは、REST APIのバッチ処理において、サブリクエストと対応するルート・ハンドラー・検証結果の対応関係がずれる不具合(CVE-2026-63030)と、WP_Queryのauthor__not_inパラメータに攻撃者が制御可能なスカラー値が渡された場合にSQL
昨年に引き続き、関数型まつり2026に二日間参加してきました。去年に引き続き50分枠での登壇もしました。 昨年はPLDIに参加するために最後の講演をスキップして韓国に飛ぶ必要があり泣いていましたが、今年は二日間丸々楽しむことができました。やったぜ〜! 以下まず聴講・登壇した各講演について概要と感想を簡単に。 Day 0 などというものはないんですが、その、スライドの進捗がかなりわるかったので、金曜に有給を取ってガッとスライドを書くなどしていました。 一、二週間前くらいからスライドを書く雰囲気を手に入れようとしていたんですが、なんか全然捗らず、煮詰った(誤用)状態になった挙句次のようなツイートをしていました。 いや、それまでに時間は結構あったんですが、「スライドの前にちゃんと参照実装つくっとかないとね!」と言って実装を作っていたらそっちに夢中になっちゃって気付いたら……という感じになってしま
こんにちは、サイオステクノロジー武井です。今回はasync/awaitの動きをOSカーネルのレイヤーから追うことで理解を深めようとしてみます。 1. async/awaitはむずい async/await、なかなかにとっつきにくい概念だと思います。 「非同期処理には async を付ける」「await しないと結果が取れない」——ルールとしては覚えられます。コードも動きます。でも、こんな疑問にぶつかった経験はないでしょうか。 await している間、プログラムは「止まって」いるの? 止まっていないの? 「待つ」のに、なんで速くなるの? await を付け忘れると Promise が返ってくるのはなぜ? そもそも誰が「処理が終わった」ことに気づいて、続きを実行してくれるの? これらイベントループやepollの仕組みを知っていると、スッキリ解決するのではと思い、今回、一筆したためました。 キー
2021年より前の記憶 振り返ると、2018年あたりは検索界隈にとっての大きな転換期だったような気がします。当時の僕はまだWord2VecやFastTextを使い、なんとかして検索を賢くできないかと試行錯誤をしていましたが、そこにBERTが発表され[1]、翌2019年にはAmazonがセマンティック検索の論文を出しました[2]。なんだかよく分からないけど、今後の検索のあり方が変わってしまうかもしれないと予感したことを、今でもよく覚えています。 一方で、その頃の現場では、検索の主流はあくまでキーワードマッチでした。システム面では、検索エンジンやデータ処理のミドルウェアがJavaのエコシステムを中心に回っていたため、アプリケーションもJavaで書かれるべきという雰囲気がありました。また、検索エンジニアといえば検索エンジンの運用や内部構造に詳しい人、という認識が一般的で、検索×機械学習をやってい
{ if (! this.initialized) { search.start(); this.initialized = true; } if (value) { setTimeout(() => { this.$el.querySelector('input').focus(); }, 100); } }); }, }" x-dialog x-model="searchModalIsOpen" x-cloak class="fixed inset-0 z-10" @keydown.slash.meta.window="searchModalIsOpen = !searchModalIsOpen" @keydown.k.meta.window="searchModalIsOpen = !searchModalIsOpen" @keydown.escape.window="searchM
はじめに 以前投稿した通り TROCCO のジョブ画面に表示されるログは DB に保存されていました。 サービス開始から時間が経ち、保存されたログのサイズが見過ごせない大きさになったため、去年 SRE ではログを S3 に保存する大掛かりなリアーキテクチャを行いました。 その後ログが S3 に保存されるようになったものの、依然として古いログは DB に保存されたままでした。 先日それらログをついに消し去るに至ったので成果と道のりをまとめたいと思います。 結果発表 消したサイズ 9TB 削減したコスト $5,340/month (¥865,080/月 - 162円換算) 消したログ数 推定4億 ※ ログ保存用カラムを NULL or 空文字 に置換しました 内容 ログが保存してある DB のカラムの値を NULL か空文字に置換することでログを削除しています。 また後述する通り削除後に OP
これまでIDE中心だった開発環境を、今年の4月ごろからターミナル中心に切り替え始めた。 ようやく手になじんできて、以前IDEでやっていた作業もターミナル上でかなり素早くできるようになってきた。現時点の構成をまとめておきたい。 特に効いているのは、AIエージェントと一緒に開発を進める時だ。自分がよくやるのは、たとえばこういう作業である。 複数案件対応時の切り替え: 会社Aの作業、会社Bの作業、会社Bの別タスク、という単位で WezTerm のタブを立ち上げている。IDEを複数開くより軽く、切り替えも楽なので、その日の対応を並べておきやすい。 目的のファイルに素早くアクセスする 現状のDBがどうなっているか確認する ローカル開発サーバーのログを確認する 作業環境を worktree で管理し、並列に進める環境を用意する Git の差分や状態を確認する その作業環境で使っているアプリ画面に素早く
TL;DR メールの受信は Cloudflare Email Routing メールの送信は Cloudflare Email Sending メールの閲覧・作成には普段使っているGmailを利用 CloudflareがSMTPをしゃべれるようになったので、Gmailのエイリアスに追加できるぞ! 独自ドメインのメールアドレスにお金かけたくない問題 個人開発をやっているとポコポコ独自ドメインが増えていきますが、メールの送受信は頭が痛い問題です(費用面で)。Google Workspaceを契約するのが一番理想なのですが、ドメインごとに毎月800円も払っていられません。 そのため、この界隈では「なるべく安く独自ドメインのメールを送受信する方法」が定番ネタになっていて、私はPurelymailを使っていました。年間$10で送受信できてありがたかったのですが、それでも「メールのためだけに別のサービ
しかし、明確な目標を持たずにAIツールを導入するだけでは、上記のような生産性の向上にはつながりません。多くのチームはAI導入の過程で以下のような壁にぶつかります。明確な目標がなければ、これらの壁を突破する動力を得るのは困難です。 スキルのばらつき:チームメンバー間でAIツールの活用スキルに差があり、コラボレーションの効率が低下する文脈の欠如:文書化が不十分であるため、AIにプロジェクトの背景知識を適切に伝えられない信頼性の問題:テストコードが不足しているため、AIが生成したコードのデプロイが不安定になる 私たちの組織でも、上記のような壁をどのように突破するかを模索しつつ、組織レベルでAXを推進しています。情報の機密レベルを分類し、セキュリティインフラへ移行する基礎的なステップから始め、AIガイドラインの標準化やCI/CDとの連携といったステップを一つずつ踏みながら、試行錯誤を重ねているとこ
以下、なぜこの結論になるのかを順に書きます。 そもそもVPC内は盗聴できるのか 最初に確認したかったのは、「物理的に同じLANにぶら下がっていて、他人のパケットが流れてくる」という昔のオフィスLANのイメージが、VPCにも当てはまるのか、でした。当てはまりません。 AWSのVPCは物理的な共有LANではなく、SDNの上に作られた仮想ネットワークです。この「オンプレのL2スイッチング(同じセグメントにフレームが流れ、隣の通信も物理的には見え得る)」と「VPCのSDN(パケットが宛先ごとに個別に転送される)」の違いが、今回の議論の出発点です。SDNとしての全体像はIvan Pepelnjak氏の "AWS Networking 101"(ipspace.net, 2020)が分かりやすく、盗聴の可否に直結する挙動は、AWSのLogical Separation on AWS(ホワイトペーパー)
最近、Claude Code や Codex などのコーディングエージェントを使ってコードを書くことが増えていますよね、私もそうです。 しかし、困るのが「PC がスリープすると、エージェントも止まってしまう」ことです。 「あーこの処理が終わったら帰宅するか」「あ、もう一つやってから帰宅しよう」みたいなので延々椅子から離れられないとかよくある。 これを避けるために、私は常時起動の Linux BOX 上でエージェントを動かすようにしています。ただ、sshでやってるのはいかにも面倒。エディタも必要ですからね。 ということでVS Code Remote SSHの出番になるんですが、これも接続が切れたタイミングでターミナル上のプロセスも終了します(しないこともある)。 つらい。 そこで最近使っているのが Shpool です。 コーディングエージェント生存戦略としての Shpool Shpool は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く