shohei blog

【この記事は生成AIが書いてます】 ポメラ DM250 に Debian 12 を入れて Claude Code が動く開発端末に仕立てた話。バッテリ駆動・キーボード一体型・LTEなしの隙間にWi-Fi接続でモバイル Claude Code 端末が完成して、これは控えめに言って優勝だった。 なぜポメラなのか キーボードが本物（折りたためる打鍵感） バッテリーが20時間級 電源即起動・即執筆 余計な通知が来ない そして Linux が動く（@ichinomoto 氏の DM250 向け Debian イメージ） iPad mini や軽量ノートでは「気が散る装置」になってしまうのに対し、ポメラは「物理的にテキストしか打てない」のが偉い。ここで Claude Code が動けば、Mac を開かなくても外出先で思考→指示→生成のループが回せる。 環境のベース @ichinomoto 氏配布の DM250 向け Debian イメージ（2022年8月版）を SD に書いて起動。出発点は Debian 11（bullseye）。カーネルは Linux 3.10.0+（Pomera 専用、変更不可）。 これが地味にあとあと効いてくる伏線。 1. Debian 11 → 12 アップグレード sources.list を bookworm に書き換えて apt full-upgrade、これ自体は教科書通り。 ところが完了直後に SSH が一切通らなくなる。原因を追うと sshd の seccomp 内で glibc の arc4random が getrandom() を呼ぼうとして死んでいた。 ...

【この記事は生成AIが書いてます】 前回の記事では qwen3.6:35b-a3b が Q4_K_M で 24GB VRAM にギリギリ入らず、4.6GB が CPU 行きになって t/s が 1/4 まで落ちた。前回は妥協策として qwen3.5-35b-nothink (Q4_K_S, 53 t/s) を primary に据えた。 今回その続報。qwen3.6:35b-a3b を Q4_K_M のまま使いつつ 64 t/s 出るようになった。Q3 にしなくて済んだ。鍵は --n-cpu-moe（-ncmoe）という llama.cpp のフラグ。 何を変えたか 量子化: Q4_K_M（前回と同じ。落とさず） 入手元: unsloth/Qwen3.6-35B-A3B-GGUF の Qwen3.6-35B-A3B-UD-Q4_K_M.gguf ファイルサイズ: 22.1 GB runtime: Ollama を捨てて llama.cpp 直起動 ctx: 128k（前回 16k だったのを大幅拡張） 新フラグ: -ncmoe 5（MoE エキスパート 5 層を CPU に逃がす） KV cache: q8_0（前回 q4_0 強制してた、品質寄りに変更） 要するに： Q3 に妥協する前に -ncmoe を試したら勝ってしまった ついでに Ollama の OLLAMA_KV_CACHE_TYPE=q4_0 が実質効いてない ことも判明した（これは別の罠） 起動コマンド： ...

【この記事は生成AIが書いてます】 社内で運用している OpenClaw（エージェント実行基盤）の既定モデルを何にするか、ここ数日比較していた。環境は RTX 3060 12GB × 2 の合計 VRAM 24GB。Ollama 側のチューニングは以下の通り。 OLLAMA_KV_CACHE_TYPE=q4_0 OLLAMA_FLASH_ATTENTION=1 結論から言うと、qwen3.5-35b-nothink (Q4_K_S) を primary に採用した。以下、そこに至る経緯。 計測結果 同一プロンプト「東京の名物を3つ短く」を 3 回計測した平均の体感値。 モデル ctx t/s VRAM fit 備考 qwen3.6:27b (dense) 32k ~6 部分 CPU thinking あり、warmup 3.5 分。実用外 qwen3.6:35b-a3b (MoE, thinking) 32k ~15 部分 CPU thinking で応答が冗長 qwen3.6-35b-a3b-nothink 16k 22.2 ✗ (CPU 4.6GB) Q4_K_M 約 22GB、24GB VRAM にギリ入らず qwen3:30b-a3b-nothink 16k 84 ✓ 最速。ただし世代が一つ古い (Qwen 3.0) qwen3.5-35b-nothink (Q4_K_S) 16k 53 ✓ 採用 学び 1. CPU オフロードが t/s をほぼ決める qwen3.6:35b-a3b は Q4_K_M で約 22GB、24GB VRAM にギリギリ入らずに 4.6GB が CPU 行きになる。たった 4.6GB のオフロードで t/s は 1/4 前後まで落ちる。VRAM に乗るか乗らないかが事実上のスイッチ。 ...

同日1回目の二次発酵の伸び不足を受け、イーストを10g→12.5gに増量、焼成温度も220℃→200℃に変更して再挑戦。

ニップンのゆめちからブレンドで食パン1斤と1.5斤を同時に焼いた記録。二次発酵の伸びと焼成温度に課題。

朝来に引越してはや3年、DIYで薪ストーブを導入しその魅力に取り憑かれてしまい、薪のことばかり考える日々を過すうち、見渡せば山なのになぜそこの木を切れないのかと思い、丹波市木の駅プロジェクトが行っているチェーンソー講習会を受講しました。 チェーンソー自体はAmazonで1万円代で売っているトップハンドルの小型な物と大きめな物を買って少し使っていたのですが、合計3日の実技講習で使ったのはSTIHL社のプロ用機材。もうね、これがまったく切れ味が違うので講習会後すぐに取り扱いのある店舗へ出向き購入したのがこちら。 これ実は現行機種(MS201C-EM)だと10万円以上しちゃうのだけど、偶々入った店舗に旧型のデッドストックがあった。製品登場がいつなのかはざっと調べても出てこない(ネット販売しない主義の会社らしい)が10年以上前のモデルなのは確か。10年も経てばほとんどゴミ同然とされる本業との違いを痛感したが、現行モデルとの違いはインジェクション化されて高くなっただけらしいのでこちらで即決(一寸日焼けしてるけど)。ちなみに掛っていたプライスタグの消費税が5%時代っぽかったのが衝撃、えらい時代になってしまったものよ。価格は当時のままだったのだけど現行とは3万円以上も違うので良き出会いになりました。 現状杉の玉切りしかしていないが、やはり安物とはもう全く別物の切れ味なので切っていても楽しい。プロの機材は一味違うしそれを知ったら後戻りできないのはどの世界も一緒ね…と思ったのでした。 これから目立てやメンテナンスなんかも忘備録がてらここに書いていこうと思います。

突然の3CXネタです。最近あちこちに入れてるのですが、忘れそうなのでとりあえずブログに書き留めておきます。 日本においてレガシーなオフィスフォンを使っていた場合「留守電をオンにセットして帰宅」みたいな需要があるみたいです。基本的に3CXとかだとOffice Hourをセットして自動的に留守電切り替えっていうスタイルになるんですけど。日本的には手動で操作したいという需要があるみたいです。 そんな時はステータス管理を使います。各エクステンション(内線)のステータスは通常「利用可能」となっていますが。「離席」にしてしまうとその内線は鳴りません。コールグループの設定で内線が全て離席になっていた場合はボイスメールへ転送という項目があるのでここを使います。 スマホ・pcクライアントからはクリックでステータス変更が可能ですが、IP電話機を使っている場合は内線「*31」にダイヤルする事で離席に設定可能です。また、「*30」に設定すれば通話可能になります。 正直この運用管理するくらいならOffice Hour 設定した方が良い気がしますがとりあえず方法はあるという事で。

はじめに この記事は「 ATOM Tech の ATOM Cam を使い畑を監視しよう」というコンセプトですが、本カメラの屋外設置は保証対象外の行為となります、また本記事にある行為はカメラ以外にバッテリーや太陽光発電パネルを扱う事になりますのでカメラ本体の故障は元より事故や発火等のリスクがある事を承知下さい。 という訳で、ATOM Cam 発売されました。たった 2,500円で国内メーカのネットワークカメラが買えるという事に驚きます。しかしここまで値段が下がれば色々と冒険もできると思います。私事ですが2020年3月に朝来に引越し、庭(というか菜園)の手入れをするのが楽しくなってきた所です、しかし週末にしか帰宅しない生活の為平日は菜園を見る事ができない、ので何とかならないのかと実は M5Camera を屋外に設置して定期的に JPEG を送付するというプログラムを書いていた所(これもサーバ側のプログラムは書いてあるので別の機会にどこかに載せます) です。という所に ATOM Cam を見つけて「これだ!」となりました。 必要な物 ATOM Cam 本体　2500円 太陽光発電パネルキット(10W)　2990円 バッテリー(12v12Ah) 3480円 収納ボックス 1000円くらい? 上記で大体 10,000 円くらいになりますね。 ボックスはわざわざ買わなくても家で余っている物を流用すればOKですね。ここで使っているのは PP 素材なので屋外にそのまま晒すと劣化するかもしれません…。 STEP.1 仮組 全ての物を箱から出し、仮組して動作するかチェックします。 ソーラーパネルの先はクリップになっていましたが不要なので切断します。 このケーブルを切り取りバッテリーとコントローラの接続にも使います。 バッテリーとコントローラを接続しコントローラの電源が入る事を確認し、次にソーラーパネルと接続し太陽光下で発電する事を確認します。問題無ければ ATOM Cam を取り出しコントローラのUSBポートに差し込み初期セットアップを行います。 STEP.2 ボックス加工 カメラ用の穴と、ソーラーパネルのケーブルを通す穴を開けます。ソーラーパネルを固定する用の穴が必要な場合はこちらも穴を開けます。 また、熱暴走が心配なので雨が降っても水が侵入しない場所に空気穴を開けておきます。 ※カメラ用の穴はレンズ部分だけ空けると夜間オートで切り替わるナイトビジョンの時に点灯する赤外線ライトがボックス側に反射して何も見えなくなるので要対策です。現在対策確認中。 電動工具であれば穴は一発であけられるのでお勧めです。マキタのペンドライバードリルを使っています。 STEP.3 組立て 箱の中に入れましょう。 ソーラーパネルはインシュロックでボックスの蓋に固定しました。 カメラは付属の両面テープで金属プレートをボックス内側に貼り付けてマグネットで固定しますがズレるのでガムテープで位置修正してます。 STEP.4 設置 適当な場所に設置するだけです。画角が広いので良いですね。スマホのアプリで実際に見ながら設置できるので良いですね。 運用 2020年6月1日に設置2020年6月5日現在特に問題無く動作しています。

M5Stackをはじめたのでblogもお掃除してみた。 とりあえず最初の一歩。 Serial接続は115200bpsにしないと化ける。 Wi-Fiの接続はこう [python] import network wlan = network.WLAN(network.STA_IF) wlan.active() wlan.connect(‘SSID’,‘PASSWORD’) wlan.isconnected() [/python] isconnecte()でTrueが帰ってきたら接続できてるね！

社内環境で既に構築してしまった Rocket.Chat を外部から評価したかったのでやり方を模索。 前提としては社内からインターネット上の踏み台サーバーへSSH接続可能な事。 Reverse ssh tunnel を安定運用する [http://qiita.com/syoyo/items/d31e9db6851dfee3ef82] ここを参考に3000番ポートをポートフォワードで踏み台から転送できるようにする。 これだけで踏み台から(もしくは踏み台にSSHしてポートフォワード掛ければ) Rocket.Chat へ接続できるようになる。 しかしこれだと一々接続しなければ行けないのでさらにこの踏み台サーバーのポートを直接叩けば Rocket.Chatが使えるようになるには下記の設定を入れる。 まずは、踏み台側sshdの設定変更、これで外部から受け付けられる [code] nano /etc/ssh/sshd_config GatewayPorts yesを追加 sudo /etc/init.d/sshd restart [/code] 次にIPのFORWARD設定 [code] sudo nano /etc/default/ufw #DEFAULT_FORWARD_POLICY=“DROP” DEFAULT_FORWARD_POLICY=“ACCEPT” sudo nano /etc/ufw/sysctl.conf net/ipv4/ip_forward=1 [/code] 最後にiptables(ufw)の変更、 [code] nano /etc/ufw/before.rules *nat :PREROUTING ACCEPT [0:0] -A PREROUTING -m tcp -p tcp –dst –dport -j DNAT –to-destination 127.0.0.1: COMMIT ufw reload [/code] これで繋がるようになるはず。