#Cosense(旧Scrapbox) #Scrapbox #wip
#Testing #WIP
しかたなくレガシーコードと向き合わなければいけないときの個人的心構えを書いていく
意図がわからないときは歴史をReverse Engeneeringする気持ちで追う
現状のコードが論理的に正しいドメインロジックになっているという幻想を捨てる
レガシーコードの改善やリプレースのコストが効果に見合わなければ手を付けない
#Rust #wip
静的型検査が厳しいコンパイル型言語になっている
人間が気にしなければいけない領域が少なくて済む
外部との境界も、コンパイルできている状態かつserdeのようなserialization用のライブラリを信用さえできれば、煩わしい「境界のテスト」を最小限に済ませられる。
O'Reilly Japan - 脳に収まるコードの書き方 https://www.oreilly.co.jp/books/9784814400799/
wip
これさえ守ればうまく行くということはないが、これを破ってしまったときは大抵後で不都合の出る設計になる
wip
wip
WIP
後で書こうと思ってたけど、エンジニアは何を学ぶべきなのか で大体言いたいこと言ってた。
WIP
Wip
WIP
#WIP
https://www.reddit.com/r/aws/comments/18kyg5v/ecs_vs_eks/
#WIP #Remix
会社でもよくRemixを使っているが、その選定意図とかを会社以外で話すときに資料がないのでちゃんとしたものを作るまでのメモ
RemixがめちゃいいというよりはNext.jsがつらい、もしくは不安感が大きいのが主な原因
印象論みたいになってるところが多いのであとで実例とかエビデンス貼っときたい
Next.jsがつらい
Cosense(旧Scrapbox)をやめてQuartzに移行しようとしていたけど、やはりいつでも気軽に書けるというメンタリティにならなくてやめた
Cosenseに不満がないわけではないが、また再開していく
2 hop linksがあればCosenseである必要はないと思ってしばらく運用してみたが、ローカルファイルとして持つ以上階層構造にして管理したい。しかし、リンクと階層構造はかなり相性が悪いことを身を持って感じた。私は階層構造よりリンクを優先させたいので、またCosenseに戻ってきた。
Cosense(旧Scrapbox)はポータビリティだけが耐え難いほどネックだと思っているので、なるべく平文に近い文書にする運用でカバーをすることにした。
#Vimium
code: (txt)
mapKey J <s-nop>
mapKey K <s-nop>
mapKey b <s-nop>
ObsidianからCosense(旧Scrapbox)に再び戻ってきたことも合って、タイトルの問題について考えていた。
Markdown
Markup
独自記法
Markdownの方言が多すぎる点がなんとかなれば...。
obsidian vs Cosense(旧Scrapbox) vs logseq vs dendron vs zettlr vs Typst
Is Dendron Project Still Active? · Issue https://github.com/dendronhq/dendron/issues/3956
logseqはhotkeyにキーの連続を指定できて良い
Your One-Stop Publication Workbench | Zettlr https://www.zettlr.com/
今のところはObsidianにハマっているので、かなりObsidian贔屓の比較になっている。
Cosense(旧Scrapbox)でいうところのこういうやつ→GitHub
Markdownでいうところのこういうやつ
code: link.md
[GitHub](https://github.com)
code: link.html