Small Changes

週刊ニュース Lv1(2022年11月14日~2022年11月18日)


Metadata


記念すべき週刊ニュース1回目。

ここでは、RoamResearchのデイリーノートでフリーライティングしたものや作業のメモの中から公開できそうなものを適当にピックアップして箇条書きではなく文章で書くことを意識しようと思います。

思考しながら書くことが多いため、内容はそのメモをちょっとだけ整えたレベルになるかと思います。

11/14(月)

最近アトミックノートという概念を知り、使い捨てメモとアトミックノートをどう活用していくべきかということを考えていました。というのも、二クラス・ルーマンという人が作ったZettelkastenというメモ取りのためのシステムについて学びRoamResearchで運用するための仕組みまで構築したもののその仕組みに乗ろうとすると、書く前に考えてしまい書けなくなるということがあったからです。書く量が減ってしまうと頭の中で思考が進まないのでとにかく書くためのハードルを限りなくしつつ、アトミックノートも作成しつつ一つずつ自分の知識を積み上げていくためのいいところどりの仕組みを考えているところです。

また、チームギークという本を読んだのですが、自分自身がHRT原則を実践できていない出来事がありました。HRT原則とは他人とうまくやるためのHackで、謙虚・尊敬・信頼の英語の頭文字を取ったものです。そのときは、自分たちのことを考えてくれた相手に対してリスペクトがない言葉使いをしてしまったので、少しずつ意識し改善中です。

11/15(火)

この日はアトミックノートにしたいものをひたすらあげていき、何をアトミックノートにすべきだとか、あのノートもアトミックノートにできそうだとかを考えていました。どの粒度でどの程度まとめるかにもよりますが、ほとんどのものはアトミックノートにできそうだと思いました。例えば、その日RoamResearchでblock embedという機能の良さに改めて気づいたのですが、いつもだと、よく使うチートシートなどにトリガーとなるようにblock embedについて書いておくのですが、これもアトミックノートとして書いておくとただのメモよりは使い回しが効くようになりますし、何よりいつもだとコピペレベルでしかまとめないところをアトミックノートにするためには一つのことだけについて書く必要があるので記憶の定着もよさそうなどと思ったのでした。

11/16(水)

自社サービスを開発する会社で働いているのですが、まだまだサービスとしてはシステムもリリース前の開発段階で今はMVPで検証した価値を与えられる仕組みを別のツールなどを使ってユーザーに届けている段階なのですが、価値を感じてお金を払い続けているユーザーがいるという気づきをBizDevチームから共有してもらいました。

この話を聞いて思い出したのは、Inkdropの作者の方のお話です。この記事を受けて、1000人が熱狂できるサービスを個人で作りたいと思っていた時期が懐かしいです笑 いま1人のユーザーが熱狂してくれています。この熱狂は周囲の人達に伝播して、また熱狂するユーザーを1人また一人と連れてくれてきてくれることを願っています。

個人としてその中で生き残るには、ニッチの領域で自分の価値観を大事にして、それに共感してくれる人を集めることが一つの方法だと思います。幸いにも継続課金モデルがウェブサービス以外のアプリでも受け入れられつつあります。それは大量のユーザを無理に集めなくてもビジネスが継続して成立する可能性を示しています。ネットによって広告に頼らなくても影響力が得られるようになった今、1000人のファンを集めることは大変ですが不可能ではないでしょう。 参考:MarkdownノートアプリInkdropで家賃の半分が賄えるようになりました

11/17(木)

ある会議で実装中の機能のパフォーマンスについて検討していることを話してくれるエンジニアに対して、リスペクトがない回答をしているのを間近で観測しました。最近チームギークを読んでいるので、こういうのを観測すると何とも言えない気持ちになります。白か黒かで言うことは簡単ですがその前に早いうちから最適化について検討したという素晴らしい事実についてまずはリスペクトがあるといいなと思いました。常にHRT原則を忘れないようにしていきたいですね。

11/18(金)

この日はとても素晴らしい日でした。最近よくVimがクラッシュしてしまいVimの思考の速度で開発するという開発体験が最悪の開発体験になっていたのですが、原因が排除できて最高の開発体験が戻ってきたからです。原因はVimではなく、Windows Terminal + MicrosoftIMEの相性が悪かったようです。今はGoogle日本語入力を使うことで回避できました。

また、久しぶりにSQLを書きました。親レコードに子レコードが複数紐づくことがあるという1対多のテーブルがあり、子レコードは複数のtypeを持っています。やりたいのはAというtypeのみを持っている親レコードだけを取得したいです。でも1対多のテーブルのため、Aだけで絞り込みをかけると、AとBも持っていた場合にも該当しています。そのため、EXISTSでサブクエリを使い、サブクエリで親のidでGROUP BYしてAのカウントが1 かつ Aの以外のカウントが0という条件で絞り込むことでやりたいことを達成しました。とりあえず動くコードは書けたのですが、サブクエリはパフォーマンスが悪いときもあったり、あとは、サブクエリで関連テーブルをSELECTするときはなぜかJOINしなくても動くなどよくわかっていないところもあるので、もっとSQL知りたいと思いました。

References