クラウド的なアレ

Obsidianというエディターを使い始めた。 使い初めは軽いノリだった。まずはこのページを見てほしい。 Obsidian: A knowledge base that works on local Markdown files. Obsidian – A knowledge base that works on local Markdown file obsidian.md 他のエディターであまり見かけることのない特徴的な機能としては次のあたり。 グラフ表示でドキュメント同士の関係性を表示できる（Graph Viewと呼ばれている） あるドキュメントに別のドキュメントから来ているリンクを一覧として見ることができる（Backlinksと呼ばれている） あるドキュメントから別のドキュメントへのリンクを一覧として見ることができる（Outgoing Linksと呼ばれている） ドキュメントのリンクを [[]]と打って貼ればもうそれだけでグラフにも表示され、BacklinksやOutgoing Linksとして整理されるし、 #noteのようにすればタグもつけられて、それがグラフ表示でも見れる、というあたりも結構直感的で最高だった。 そのほかに気に入った点としては次のような内容。（順不同） そもそもMarkdownで書ける 検索が簡単（タグとか） 標準プラグインの機能で毎日自動でその日用のページをオープンする機能がサポートされている モバイルアプリもデスクトップアプリもサポートされている 保存され方が明確（Vaultという名称のディレクトリ以下に配置するだけ、各ファイルは.md形式） 立ち上げが比較的速い YAML形式のFront matter（このドキュメントがどんな内容を含むかといったメタ情報を書くための形式）も使える 設定も全てCasC（JSON形式） PDFでの出力も簡単 Vim（エディター）のKey Bindingsが使える かつて、DITAと呼ばれる技術ドキュメントを書く際の書き方の構造・考え方にはまっていた。 1ドキュメントに1トピックという単位で書く。トピックには例えば概念としての説明、How-toなどの手順の説明、リファレンスとして列挙などの情報、でそれぞれ分けて記載し、各トピック間の関係を別途mapと呼ばれるリンク集のようなものを作ってつなげることでトピ

振り返ること数か月。自分の無能感とたたかっている。たまには意味のない話をだらだらと記してみる。 新しいロールをアサインされた。スクラムのプロダクトオーナー（PO）だった。 これまでスクラムではメンバーとして振る舞ってきていたからPOが何かやることを決めてくれて、その決めてくれた範囲内で最大限のバリューを出せるように過ごしていた。 が、今回はPO。自分がその範囲を決め、優先度を決める立場。任されたのは新しいプロダクト。スクラムも新しく立ち上がった。新生チーム、新生PO。 少しわくわくしながら最初の1-2週間を過ごしたが、そもそもこれは何をするのか、そのために何をしなければいけないのか、中長期のためには何がリスクになるのかが全くわからなかった。 その上、使用する技術や適用される規格類は今までのキャリアで触れてきたことのないものしかなかった。 突然のパニックゾーン到来。（こういうやつ） スクラムに目を向けると、領域の知識が自分より明らかにあるメンバー、技術経験の豊富なメンバーなどがいて、とにかく自分が無能であると知らしめさせられる機会としか思えないくらいだった。 大抵なら遅くとも1か月もあれば未知のものにもなんらかキャッチアップを果たせるというのが過去の経験だったけれど、未知のものが多すぎて、いまだに暗中模索している。ずっとパニック状態なので、心としても疲弊しているように思う。なかなかに、厳しい。（一時に多くのものを変化させすぎなんだよ……！） 自分のことを有能と信じたいし、そうあり続けたいという気持ちに対して、現実的に自分が出せているパフォーマンスに満足できずに明けても暮れても先が見えない何かをキャッチアップしている。 この苦しさについて然るべき人々に助けを求めたが、得られたのは、自分がやりたいことをやればいいよとか、今は苦しいと思うけど超えていけば必ず楽になるからとか、助けになるものとは程遠い種類ものだけだった。 いっそ色々と諦めて無能と認めるか、あるいはできるだけ頑張って期待を満たし有能となるか。その途中で折れてやはり無能となるか。そんなことをぼんやりと考えている。 ただ、ここで自分にとって救いなのは、自分の周囲には、自分が無能でも存在を認めてくれる人がいるということ。 無能になった、としても何もかもを失わないというのは、ある面走る準備としてはこの上ない。後ろ楯があ

ROS2を使用したソフトを扱うことになった。基礎から全く知らないのでひとまず日本語の著書を探してたところ見かけたので読むことにした。 この書籍自体はROS2ではなく、ROSを扱っているので、いくつかの違いがあるけれど、それでも十分に役立つ内容だった。 以下は読書メモ。 ROSグラフというかたちでつながりを表現 - ノードとエッジ（≒まさにグラフに出てくるやつ） - roscoreがdiscoveryの機能を持つ（ノード登録、ノードからの問い合わせで別のノードの情報を提供） - ROSグラフが星形に見えたら、中央のノードにデータを送っているかうけとっているだけになるため、データの流れを見直すなどした方が良い tf(transform)によって座標系を取り扱う topicを公開、pub/sub形式での実装 - ラッチトピックは、最後に配信されたメッセージを自動で受け取り可能 - メッセージの型定義は msg ディレクトリ内にて実施する サービスは同期型のデータ受渡方法 - 入出力定義はメッセージ定義と似たようなサービス定義のファイルを用いる - たまに実行する必要のある処理や同期してリプライする必要のある処理に使う アクションは非同期型のデータ受渡方法 - 要求に応えるまでに時間を要する場合に使う 移動プラットフォーム - 静的に安定 = アクチュエーターなどが動いていなくても倒れない - 動的に安定 = アクチュエーターなどが動いていないと倒れる - スキッドステアリングプラットフォーム＝全部の車輪がアクティブに動く、横移動不可 - アッカーマンプラットフォーム＝後輪は常にまっすぐ、前輪の向きが左右一緒、横移動不可 - 横移動は幌のミックプラットフォームでないと実現できない - ROSではこれら移動プラットフォームとのやり取りにTwistという3次元の線形と回転の速度の表現方法を使う マニピュレーターアーム - 基本的な特性は自由度（degrees of freedom: DOF） - 作業空間内で自由な方向に向ける空間のことをデクストラウス作業空間という センサー - バイナリーセンサーは「オン」か「オフ」か、例えば光線の遮られ状況からオンオフを見たり、単体のスイッチを機械的な圧力でオンオフすることで見たりなど - スカラー値を返すものもある、この場合には各種センサ

所属しているチームでCI/CDの有識者として扱われていて、何かあれば聞かれるような、そういう存在で過ごしている。 とはいえ、これまで培った経験だけではそろそろ厳しくなってきている。 今のチームではJenkinsやGitHub Actionsを使っていて、アプリ等をデプロイするためのインフラはすべてIaCとして管理されている。 のだが、デプロイに時間がすごくかかっている。 例えば統合テストを実施する。そのために、現状だとまっさらなところにリソースをデプロイし、そこに対してテストを実施、その後壊す。 この一連の流れに1-1.5時間かかってる。 これは個人的には、遅い。 この制約もあってか、リリース頻度も週に1回前後となっている。 なにがいけないのだろう、というのがもやもやしているそんなとき、CI/CD Conferenceが行われるということで、いくつかの気になった資料を読み込んで改善の材料を探してる。 まずはこれ。 p.12で触れられている継続的リリースのために必要なことが好き。 - リリースのリスク最小化 - オペレーションの自動化 - デプロイの高速化 特に面白かったものをかいつまんでメモする。 ■リリースのリスク最小化 - SLOとエラーバジェット SLOを設定して監視することで、リリースの品質が悪いときはリスクを減らすとか、取る行動の指針に影響を与えるというのはとても面白い。 - デプロイとリリースの分離 Feature Flagでコードの変更のタイミングと機能追加のタイミングを分けるということでDark Lounchと同じだなと思いつつ、目的が違うので視点がいいなあと思った。 ただ、自分も懸念だったけれど、フラグを増やすと、そのフラグ同士で依存関係が発生してしまうなど、辛いことにもなりうるなあというのが心配どころ。 - 段階的リリース 影響範囲を絞るために対象サーバーを絞ったり、ユーザーを絞ったり、本当に必要な人にのみベータリリースしたり。 ■オペレーションの自動化 - 結合テストの自動実行 定期実行で流していたテストをコミットからのトリガーに変更、ということで最初は確かに定期実行とかするものの、まあコミットからトリガーというのは今時だと当たり前かなという感じ。 より面白かったのは、同じ実装に同じテストを何回も走らせないという話。 職場でも当初、結合テストを