GitHub - profet23/atreus62: Design files for the atreus62 keyboard Design files for the atreus62 keyboard. Contribute to profet23/atreus62 development by creating an account on GitHub.

構成 #昨年から変更があった要素には 追加は青 で、 入れ替えは黄色 でそれぞれ網掛けしている。 変更の詳細については後述。 スマートデバイスマップ 2025年版 昨年からの変化 #Alexa の導入 #スマートスピーカーとしては長らく Google Home Mini を使っていたが、ここ最近音声の聞き取りが不安定になっていた。 タイマーを止めようにも音声操作を受け付けずになり続けたり、そもそもタイマーのアラート音が途切れ途切れだったり (経年劣化でそこが調子が悪くなることがあるんだろうか。ファームウェアアップデートでメモリが足りなくなった？)。 せっかくだから Alexa も試してみるかということで、Prime デーで Echo Show 5 を購入。

Obsidian Advent Calendar 2025、15日目の記事。 タスク管理を Todoist から Obsidian に移行して、1年以上経ったのでその後の様子をまとめてみる。 移行直後から新しく取り入れた項目については 🆕 をつけている。 逆に不要になった項目には取り消し線を入れている。 Todoist から移行した理由などは去年の記事を参照のこと。 タスク管理のルール # すべて Obsidian 上で管理する 🆕 PARAメソッド に則り、タスクを Project として扱う 今年の5月頃から PARA メソッドを導入した。 メモを以下の4つに分類するというもの。 Project 締切のあるタスク Area of Responsibility 長期的な責務 Resource 関心があるもの Archive 完了あるいは流れたタスク、関心がなくなったもの SNS(確か

Go で AST を扱う時に便利なツールを作ったはなし。 AST をいじりたいが・・・ #テストをいい感じに実行ツールを go/ast を使ってやりたかったのだが、実は今までまともにASTを扱ったことがない。 何をしなければいけないのかは何となく分かるが、何を対象に処理を行えばいいのかのイメージがぼんやりしていた。 どの枝のどのノードを探しに行けばいいんだろうか、とか、そもそも目的のノードを表す名前がわからない、とか。 godoc を読んだり、実際にコードを書いていじっていればそのうち覚えるのだろうが、 そこにあまり時間をかけたくないなというのが正直な気持ちだった。 AST を眺めるためのツールを作った #上記のようなモチベーションから、Go Ast Inspector というブラウザで動作するツールを作った。 go-ast-inspector ブラウザの Web インスペクタのように、コ

Goで開発をしているとしばしば遭遇する問題の一つに循環インポート（cycle import）がある。 今回は、あらかじめ import 宣言をしておくことで cycle import を防ぐという発想から、 ドキュメント（Markdown）から import 宣言を生成するツールを Zed の AI Agent で作ったという話。 Go の cycle import 問題 #Go で適当にパッケージを作っていると cycle import が発生する。 適当に作るのが悪いというのはもっともだが、できればこれを機械的に抑制したい。 また、開発チームに途中からジョインしてアプリケーションの構造に不慣れな場合に、 いちいちパッケージ間の依存関係を調べるのはめんどうだし、 コードレビューで都度間違いを指摘してもらうのも申し訳なさがある。 ドキュメント実装が乖離する問題 #レイヤー間の依存関係がドキ

といっても特に機能追加などはなく、開発用のセットアップ手段やビルド周りを更新しただけ。 以下、行った変更の簡単な説明。 latest タグを latest に # 今回の本命。 katsubushi は Docker Hub にもイメージを公開しているが、latest タグが付けられたものは実は最新ではなく、 6年前のバージョンである v1.5.3 だった。 今回の変更で、最新のイメージに latest タグが付けられるようになった。 このため今まで latest タグを使っていた環境ではいきなり最新の v2.1.0 に上がることになる。 とはいえこの変更で困る人はまずいないだろう。 katsubushi は主に Memcached プロトコルを提供するツールだが、 それらのインターフェイスは v1 系から v2 系になっても非互換はない。 v2 からは gRPC と HTTP のインター

長年やろうやろうと思ってできていないことの一つに、障害対応訓練がある。 今回はその訓練をChatGPT上でやってみたという話。 もちろん、Claudeなどの他の対話型生成AIサービスでもできるはず。 障害対応は実際にやらないとできるようにならない #Webサービスなどのシステムを運用している場合、避けては通れないものとして 障害 がある。 負荷の増加やシステムの変更、オペレーションミスなどで発生するこれらの障害は、 程度にもよるが少なからずシステムの運用に支障をきたすため、迅速に解消する必要がある。 いわゆる 「障害対応」 である。 障害発生時には、まず何が起こっているのかを把握する必要がある。 各種ログやメトリクスから原因となっている箇所を特定し、解消・緩和するための変更を行う。 原因は場合によって様々で、アプリケーションの不具合であることもあるし、 ネットワークなどプラットフォームに近

タイトルが長いということはニッチな内容ということ。 Obsidianのファイル名をUID形式にしている場合にしか困らないリンク作成問題とその対応について。 前提 #以前書いたように、Obsidian内のnoteファイル名をUIDにして運用している。 note作成後にTemplatorでUID形式にリネームする方式。 この方式自体は1年以上快適に運用できている。 日本語のファイル名を使わなくて済むし、ファイル名(=noteタイトル)の重複に悩む必要もない。 問題 #ただし、先の記事にも書いたように、リンク先が存在しないリンクの挙動に難がある。 何かを書いているときに別のnoteを作ってリンクしたくなったときに、編集中のnoteを離れて新たにnoteを作りに行くのは面倒なので、 [[Wikilink形式]] でとりあえず書いておくという運用をしたくなる。 リンクを書くところまではもちろん問題が

生成AIとの上手な付き合い方 by ChatGPT バックエンドエンジニア兼SREとして今年Natureにジョインした長田です。 よろしくお願いします。 先日、社内向けに生成AI入門者向けのワークショップがありました。 このワークショップの中で、前提知識を共有する講座として「生成AIとの上手な付き合い方」というトークを担当しました。 その際にスライド資料を用意したのですが、そこそこのボリュームになったことと、公開しても問題ない内容ということで、せっかくなので公開することにしました。 本スライドのターゲットは生成AI入門者です。 そのため、すでに生成AIを使いこなしている方には物足りない内容かもしれません。 また、入門者にわかりやすく伝えるため説明を簡略化した部分もあり、厳密さを欠く表現もあります。 あらかじめご了承ください。 ※スライド下部の小さな字は、公開用に口頭で説明した内容を追記した

モバイルエンジニアインターン生の筒井です。 本記事では、私が入社して行ってきたReact Nativeプロジェクトの、GitHub Actions上でのスクリーンショットテスト実装についてお話しします。 これによりGithub Actions上でReact Nativeアプリが動き、そのスクリーンショットが保存され、確認できるようになります。 背景 アプリ開発において、自動テストを行うことでコード内のエラーなどに気づくことができます。 しかし、Natureでは自動テストでロジックの確認は行なっていますが、現状、画面のレイアウト崩れは検知することができません。 そのため、実際に実装画面を見てみないと分からないデザインの崩れや画面遷移の確認などは、手元で動かして確認しています。 手元での確認は、 ただ、この確認作業はビルド→起動→遷移の確認...と手順が多く手間な作業です。 そこで、GitHu

ここ半年ほど、メインのエディタとしてZedを使っている。 動作が軽快で、生成AI関連の機能も標準でサポートされているなど、使い勝手が良いので気に入っている。 しかし、まだまだ発展途上ということもあり、乗り換え前に使っていたVSCodeと比べると、 どうしても機能的に足りない部分があるのは否めない。 足りないものの一つとして、テスト実行とそのレポート機能が挙げられる。 今回は、これを Zed の Task 定義によって補おうという話。 VSCodeのテスト実行機能 #VSCode上でテストを実行すると、テストケースごとに成功・失敗が表示され、 各ケースの出力を個別に表示したり失敗したテストコードにジャンプしたりすることができる1。 VSCode上のテスト実行結果表示。整理されて表示されるので見やすい。 一方、Zed にはいまのところテストレポートを表示する機能はない2。 Task 実行機能を

Obsidianでシンプルにタスクを管理するためのプラグイン. Contribute to tadashi-aikawa/silhouette development by creating an account on GitHub. Daily note を開いて Silhouette: Insert tasks を実行すると、 設定されたルールに基づいて繰り返しタスクリストを挿入してくれるすぐれもの。 曜日指定の繰り返しや、「月内最後の平日」のような指定もできるので、たいていのケースに対応できる。 ただ、Daily note を開くたびに上記のコマンドを手動で実行するのは面倒だ。 毎日のことなのでなおさら。 これを自動化したい。 タスクリストを自動挿入する #Silhouette には、挿入対象のファイル名を見てどの日のタスクを挿入するかを判定する機能がある。 これとおなじみの Tem

バックエンドエンジニアインターン生の倉永です。インターン期間中、DynamoDBへAuto Scalingを導入するか検討した際に、色々と気づきが多かったので、それについてお話しします。 背景 NatureではNature Remo Eという商品を販売しています。Nature Remo Eを使うと、家庭で消費した電力のグラフを以下のようにアプリで確認できるようになります。 これを実現するために、Nature Remo Eは計測した電力の時系列データをサーバへ送信し、送信されたデータはDynamoDBのテーブルで管理をしています。 このテーブルは以前、プロビジョンドキャパシティモード（当時はAuto Scalingなし）で運用されていたのですが、これがサーバ障害の原因となってしまいました。別の障害に起因してテーブルへの書き込み負荷が増加し、スロットリングによる遅延が発生することでデータを書き

2025 年に入ってから AI の、特にエージェントによる支援を強く受けられる開発環境の導入を進められた方は多いのではないかと思っています。 僕が働いている Ubie でも、先日お伝えした通り Cursor や Cline の検討を行っていました。 そしてこのたび、 Ubie では Cursor の Business プラン を導入するに至りました。 本記事では Ubie で Business プランを導入するに至るまでの検討・調整と、導入から二週間経過した上での所感をお伝えします。 AI による強力な開発支援を受けたい方々の検討材料になったら嬉しいです。 TL;DR Ubieは、AIコーディング支援ツール「Cursor Business」を迅速に導入し、すでに40名以上の開発者が活用を開始しています。 一人当たり月額 $40 というコストながら、AIエージェントの活用により、開発の生産性

id:cohalzです。この記事は、はてなのSREが毎月交代で書いているSRE連載の2025年1月号の記事です。 2024年にはこのHatena Developer BlogにてSRE連載と言う毎月一回交代でSRE関連のブログ記事を書く企画を開始しました。 今回はその連載記事の紹介と工夫について紹介していきます。 記事一覧 id:hagihala はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 developer.hatenastaff.com readonlyメンテはめちゃくちゃ強力な武器だなと思っているので社内外でももっと広まって欲しいですね。あと0年や10000年も考慮しないといけないというのはまず役に立たない知識でこれも面白かったです。 id:masayosu はてなにおけるEKSの運用と自動化 (2024年版) developer.haten

この記事はTech KAYAC Advent Calendar 2024の25日目の記事です。 こんにちは、@commojunです。 www.kayac.com 私がサーバサイドエンジニアとしてずっと従事してきたソーシャルゲームサービス「ぼくらの甲子園！ポケット」が、2025年1月8日でサービスを終了します。 prtimes.jp ぼくらの甲子園！ポケット（以下ぼくポケ）開発チームでは、これまで遊んでくださった皆様への感謝を伝えるため、2024年10月1日から、「天下一甲子園大会」という特別なイベントを開催していました。そしてつい数日前の12月22日、イベントのすべての内容が終了しました。 この天下一甲子園大会というイベントの開発は、たった3ヶ月のイベントのためにこれまでの運用の10年間、いっさい手を加えられなかった聖域みたいな箇所に多くの破壊的な変更を入れ、ほとんど一発勝負でリリースする

この記事はMackerel Advent Calendar 2024 の17日目です。 こんにちは、SREチーム所属の@mashiikeです。 今年のMackerel Advent Calendarは、OpenTelemetry関連の記事が多くて私も流行りに乗ろうかと思いましたが、ネタが間に合いませんでした！ この記事では、Mackerelの機能の中でも個人的に一押しのグラフアノテーションについて、弊社内での使い方の事例を紹介します。 グラフアノテーションとは グラフアノテーションは2017年1月にリリースされた機能で、サービスやロールに関連する注釈をグラフ中に記述することができる機能です。 mackerel.io 上記の画像では、私が作成しているOSS prepalertを使って、グラフ中に関連するMackerelアラートを注釈として記入しています。 前年の今の時期に、アップデートでカス

技術部の長田です。 このエントリは面白法人グループ Advent Calendar 2024の6日目の記事です。 みなさん、ふだん技術系の最新情報ってどこから手に入れているでしょうか？ 私は家事育児の忙しさにかまけて自力での情報収集をサボり、もっぱら社内Slackの情報を頼りにしています。 コンテキストが近い人達がわざわざ共有してくれる情報ということで、精度は間違いありません。 が、そろそろ自分も共有する側に回れるようにならないとなということで、 まずは社内のエンジニアにどうやって情報を得ているのかを聞いてみることにしました。 アンケートを取ってみた と、いうことで社内のエンジニア向けに以下のようなアンケートを取ってみました。 期間: 11/25〜12/1の1週間 アンケート内容: 職能(フロントエンドorバックエンド) 情報源名 情報源のURL その情報源を参照する目的 コメント 結果、

SREチームの長田です。 今回はAWSのVPC(Virtual Private Network)内で作業する時の話です。 VPC内で作業したい VPC内で作業したいこと、ありますよね。 環境構築中の動作確認とか、不具合・障害調査のための定形外作業とか、メンテナンスためのイレギュラーな作業とか。 定常的に行うほどではないですが、AWSでVPCに絡んだサービスを使用しているなら、VPC内での作業は少なからずあると思います。 VPC内に閉じたリソースにアクセスする場合は、当然ですがVPC内からアクセスする必要があります。 VPC外からアクセスするための経路を用意すればそれも可能ですが、アプリケーションが使っている経路とは異なる経路を使うことになるため、 不具合調査時の再現確認などでは余計な要素となることがあります。 VPC内からの操作は、AWSであればCloudShellで VPC環境を作るのが

SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ