はてなブックマーク

ITエンジニアリングに対する理解が深く、開発チームと(embededレベルで)密接に連携しながら、ユーザーに伝わるヘルプドキュメント・マニュアルを機能リリースと同期して出していく職種ってどうだろう、と妄想していた。 <妄想> プロダクトをよく理解していて開発チームにガッツリ入り、プランニング時点でドキュメント準備にかかる。デイリー報告やチーム議論に加わり、開発チームの言葉・デザイナーの言葉を咀嚼しながら、プロダクトユーザーへの伝わりやすさを常に考えてドキュメントを組み立てる。スプリントレビュー時点でドキュメントの作業を完成させ、機能リリースと同時にドキュメントも公開される。ドキュメントができていなければ、オーナーと協議して機能リリースを遅らせることもある。 ライティングや文章構成、ユーザーにとってのわかりやすさについて知見があり、ドキュメント関連に専念し、ユーザー視点での機能のわかりやすさ

OpenTelemetryのzero-code計装として公式に言及されているGo、.NET、Java、Python、PHP、JavaScriptについて、同系統の簡単なWebサーバーを立てながら試してきた。 kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com 「簡単なWebサーバー」の作りがいろいろ大雑把だったので、フレームワークで作ったものだといろいろ出るし、基本ライブラリに近いコーディングだとあまり出ない。ORMなデータベースが絡めばサービス間通信っぽさが出るけど、別段不要な場合は自己完結で終わってトレースとしてはいまいち面白さはない(簡単なWebサーバーなのに、裏でデータベースアクセスを

技術書をいろいろ買いはするものの、集中して読む時間がとれなくて、乱読的に読みかけた本で積ん読が解消できていない(今は『つくって壊して、直して学ぶKubernetes入門』(翔泳社)を断続的に写経中。内容は面白い)。 そんな中で@ymotongpooさんの某作の査読をしばらく前にやったんだけど、査読の場合、以下の制約が強制的に発生する。 締切時間が決まっている 全体をひととおり読む必要がある 金銭報酬目的ではないしお願いベースなので過剰にならなくてもというところではあるが、興味関心の高い分野だったこともあり、夜間や土日などで集中して読んで、コメントをだいぶ入れてご協力はできたかなと思う。 編集業務に近い性質ではあるものの、編集業務だと作業者自身が細々手を入れないといけない、下手すると木を見て森を見ずになるのに対し、査読者という立場だと「ちょっと不自然」「こうでは?以降も同」的に言いっぱなしで

MackerelでのOpenTelemetry対応パブリックベータの提供が開始したので、Mackerel CREの私も習熟すべくいろいろと実験をしています。 mackerel.io ホストやミドルウェアのメトリックを取得しようというときにはOpenTelemetry CollectorのReceiverでメトリックを収集し、ExporterにMackerelのOTLPエンドポイントを示して投稿、というのが王道なのですが、今回はあえて「Mackerelの既存のメトリックプラグインの出力をOpenTelemetryのメトリックとして送ってみる」ということを試してみました。 結論から言えば、(加工は少し必要ですが)ContribにあるCarbon Receiverで実現できます。 Carbon Receiverとは OpenTelemetry Collector ContribのReceiver

3行 現時点ではOpenTofu 1.6.0はユーザー体験としてはほぼTerraform 1.6なので、コマンドがterraform→tofuになった以外はユーザー側で感じる変化はなさそう(設定ファイルやstateファイルなどもTerraformそのまま)。Mackerel Providerも動く。 Provider側としては、すでに登録されているProviderであれば、当面は何もしなくてもGitHubリリースしたものがOpenTofuレジストリに最新反映される模様(GPG署名している場合は公開鍵をレジストリにサブミットする必要あり)。 今の時点では問題ないと言っても、OpenTofu/Terraformの乖離が進んで互換性が失われると、Providerは別リポジトリを用意する必要がありそう or Terraform/OpenTofuどちらかを諦めることになりそう。 3行 背景 ユーザー

これはMackerel Advent Calendar 2023 14日目の記事です。昨日はinommmさんでした。 要約 アラート時刻近辺の重量プロセス一覧をMackerelのアラートメモかグラフアノテーションに投稿する、「sabanote」(さばのて)というプラグインを作ったよ。あと、Mackerel Meetup #15やるよ。 前置き 改めまして、はてな社でMackerel CREを務めて1年になる id:kmuto です。SaaS型監視サービスのMackerel。そのユーザーの抱える課題の解決支援を担うCRE(Customer Reliability Engineer)のカスタマーサクセスユニットの一員として、ユーザーと直にMackerelのご利用についてお話しし、ご意見・ご要望をいただく機会が多いです。 そんな日々の中で、最近よく挙がっていたのが「アラートが発生した際のサーバー

OSSのアンチウイルス/アンチマルウェアサービスとして、ClamAVというものがあり、そこそこ広く使われている(私も昔は物理サーバーに入れていたが、CPUやメモリ負荷がかなり高いサービスで、VPSにしてからはメモリあふれが多発してしまうので普段は使っていない)。 現在はCiscoがスポンサーしているようだ。 つい先日、このClamAVのデータベース更新で入ったパターンで、Mackerelエージェントのmackerel-agentバイナリがマルウェア判定されてしまうという現象が発生した。 私のほうでFalse Positiveとして報告したところ、今日の更新で解除になっていた。ほかにも多数報告があっての解除かもしれないが、今後も同様のケースはありそうなので、ざっくり手順をまとめておく。 パターンデータベース更新はおおよそ1日1回はあるので、まず報告しようとしている時点ですでに直っていないかど

(結論はなく、ダラダラ昔話を書いただけ。) サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア(OSS)を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin

blog.jxck.io で(md2inao→md2indesignの進行は過去にもちょっとかかわりがあってウォッチした) もうすでにそういう製品があったり、知らないだけで全コードがハイライトされた書籍を出してる出版社はあるのかもしれないが、そういう本を少なくとも自分は見てない。 という記載があったのでちょっと書いてみる。 オーム社さん、オライリー・ジャパンさん、インプレスさん、羊土社さん、講談社サイエンティフィク社さんなどの一部の書籍では、コードハイライト付きになっていて、さらにそのうちいくつかは紙版では白黒、電子版ではカラーを使い分けていたりする。 というのも、前職の制作会社時代に私がその仕組みを作ってきたから。 組版はInDesignを使うのもあれば、TeXを使っているのもある。紙白黒/電子カラーのような使い分けは、TeXではOK、InDesignではもしデータを2種類管理しなければ

1行で カジュアルな気持ちでk8sの翻訳に関わり始めたよ。 背景 YAPC KYOTO 2023はYouTubeで視聴していて、Linux Conferenceの主催側立場だったりした頃を思い出したり、Debian ConferenceやRuby会議も楽しかったなーなどと感慨にふけっていた(今年のRuby会議はちょっと行きたいなと思ったんだけど、業務とつなげるのが現状では難しそうなのもあって見送り)。 yapcjapan.org 発表はどれも印象深かったのだけれども、最後のLTで@nasa9084さんの「Kubernetesの翻訳協力者募集!」を聞いて「Kubernetes使える人は英語で特段問題なさそうだなぁ」と感想を呟いたところ、@nasa9084さんに拾っていただいて反応をもらった。 speakerdeck.com そもそも翻訳をできる人は日本語のドキュメントを必要としてないので、コ

他者のGit管理下のプロジェクトに対して、ローカルでのビルドでpackage.jsonが変わってしまうとか、.rbenvでのバージョンが微妙なのでそこはいじったとかな場面で、うっかりコミット候補に入ってしまわないよう注意深さを必要とするのが、地味に手間だった(怠惰)。 .gitignoreのローカル向けの.git/info/excludeは未コミットのものを最初から除外しておくものなので、すでに追跡されているもの向けではない。 サブコマンドで何かあったような気が......と探したところ、skip-worktreeサブコマンドを使うのが良いようだ(記事ありがとうございます)。 qiita.com 最初。 $ git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for c

業務でGitのリポジトリを多数扱っていて、サポートのお手伝いのためにエラーメッセージからコードリーディングを串し刺しで探すことがある。で、このときに 「うぉー見つからねーどれが出してるんだー」「まったくわからん」「pullしてないやん...」 「なるほどーこれはあかんね」「いや確か直したってこの前聞いたよな」「pullしてないやん...」 といった悲しい出来事がまれによくあるケースになりそうなので、カレント直下のGitリポジトリ群をともかく最新にpullするツールを書くことにした。 この手のツールといえば、debian-installer開発の頃に使っていた、Joey Hessの通称mr、myreposが思い浮かぶのだが(パッケージはまだ配布されていてbrewにもある)、Perl依存はあまりしたくないというのと、ちょっとアレは用途に対して大きすぎる(VCS乱立期だったので、ほぼ全部のVCSに対応し

つくりおきAdvent Calender 2022、15日目。昨日はsawa-kazさんでした。 はてな社に先月に転職し、最初は情報量をさばくのに目が回り、1ヶ月後の今になってようやく一息ついているという状況です。一食入魂の精神であまりつくりおきはしないのですが、たまに作るつくりおきが「フムス」。 フムス(ホンモス、フンムスなどとも呼ばれる。ḥummuṣ)は、中東を中心にトルコ、ヨーロッパなどでもよく食べられているひよこ豆のペーストです。起源を巡ってはイスラエルやレバノンで争ってたりして掘り下げるといろいろ地雷になる模様。 材料 ひよこ豆。ガルバンゾ、カブリチャナとも呼びます。普通のスーパーや輸入食材店だとお高めですが、現地出身の方々がやっているお店だと乾物で安く入手できます。Amazonでもわりと安いですね。 レモン。生でもポッカレモンでもいいですが、最近では冷凍レモンがベストだなという

退職から少しのお休みを経て、本日から株式会社はてな https://hatena.co.jp/ のMackerel CRE(Customer Reliability Engineer)としてのキャリアを始めた。 Mackerel https://ja.mackerel.io/ は、はてな社が開発・運用しているサーバ監視SaaSで、オンプレミスや各種クラウドのサーバ群を一貫したインターフェイスで手軽かつ高度に監視できるサービス。 ja.mackerel.io CREチームはこのMackerelのユーザー企業のみなさまへのテクニカルサポートのほか、導入支援やドキュメンテーション、コーディング、そしてユーザー企業の成功のために継続的な活用サポートを提案・提供していくことが主なミッションとなる。 ja.mackerel.io 転職ふりかえりなどはいずれ載せていくつもりだけど、まずは速やかに即戦力と

本日で株式会社トップスタジオ https://www.topstudio.co.jp/ の勤務を終え、これから有給消化に入る。 SIerからの転職で1999年に入社し、3年くらいかなーと思っていたのが5年となり、10年となり、......といつのまにかずいぶんと長く在籍していた。 仕事的には自由度が高く、先端の技術分野の書籍を制作しながら知識を得て血肉にすることができ、私にはとてもフィットする職場だった。同僚にも恵まれて楽しかったので、離れるのは寂しい思いがある。 トップスタジオで何をやってきたの? 長くいたこともあり、それなりに成果を積んできたとは思う。 入社当初より、編集者として、各社のIT書籍の請負制作をしてきた。Linux、OSS、ネットワーク、セキュリティ、ソフトウェア工学、エンジニアリング、そして最近だと機械学習が多い。翻訳の監修や、執筆なども関連して担当。企画はあまりやっていない。

kmuto.hatenablog.com でも書いたけど、『最高のおうちオフィスではたらくvol.2』 techbookfest.org のマウントアーム+PCトレイ戦略を導入することにした。 Linuxデスクトップが主、Macbook Airが副として作業を行き来していたけれども、業務的にMacbook側を触るほうが増えそう。となると、正面で外付けモニタ・外付けキーボード・マウスで正対するようにしないと腰をまたいわしてしまう。 macでのビデオミーティングで机上に置いている場合だと、仰ぎ見るような視点になってイマイチ。 モニタのDELL U3219QではDPにLinuxをつないでいる。USB-CでMacbookにパワーサプライと画面出力ができることは確認済み。切り替えはオートでもできるが、両方それぞれへの物理ショートカットボタンをモニタ側で持てることがわかった。 ということで、ある程度素

去年の会社引越しに伴うオンプレ→VPS+SaaSの切り替え決意のときにかなり大々的にサービス類を作り直し、まだまだ現役でいけそうな1Uサーバ類やラックなども全部捨てて、それが当時としては大正解ではあった。しかし、それでもVPSという、IaaS的に全部管理しなければいけないものはやはり管理コストが高い(自分の技術関心方向と合っていたので格安で済んでいるが、企業としては隠れ管理コストになっていてよろしくない)。 ということで、いろいろヘンテコピタゴラ技術でやっていたところは諦めたりSaaSに切り替えたり(DNS bindをついに追放)というのを最近の作業の1つとしているのだが、厄介な問題としてずっと引き継いできた社内用データチェックツールの存在がある。 中身的には、ログインしてLinux CUIで動かすコマンド類(VPSでは証明書+shellinaboxで入って作業。データはNextCloud