2023年振り返り
年末年始なぜか忙しいのでサクッと書いておく
娘が無事1歳になった
去年の12月に娘が産まれて半年間の育休を取った。
いろんな話を聞いてると多分、育てやすい部類の娘っぽくて親としては助かりつつスクスク育ってくれた。かわいい。
歳をとるごとに1年が経つ早さが加速してたけど今年は情報量が多くてちょっと長く感じた1年でした。
娘の存在を免罪符にいろんなアクションをこっそりしてるんだけど、そのうちの1つでキリンおもちゃを集めまくった1年でした。下記の写真はその成果の一部です。
セキュリティチームとして頑張った
育休前もそうだったが、セキュリティチームの一員として頑張った。
育休前との差分としてはAs managerでなくAs individual contributorとして頑張ったのが大きい。
キャッチアップの一環でセキスペを取ったり、色々本を読んだり読むfeedを増やしたりと限られた可処分時間の大半をキャッチアップに注ぎ込んだ気がする。
業務としてはめちゃくちゃ楽しいし、セキュリティへの取り組みに一定のリソースを投資することの必要性を認識してる10Xの経営レイヤには非常に感謝してます。
ギター始めた
Podcastでも話したんだけど、娘が産まれたことで変わった意識の1つにN年後どうありたいか、みたいなのを考えるようになったことがある。
娘が生まれる前は「いつかギター弾けるようになりたいね」「いつかヨーロッパ一周旅行したいね」みたいな感じでいつかやりたいだったんだけど娘が生まれると5年後は5歳、10年後は10歳、といった感じでN年後の家庭はこうなってる、というのが想像つきやすくなったゆえにいろんなアクションをいつやるべきか。いつならやれるかを意識するようになった。
ギターは高校生の時に挫折したんだけどロックバンドライブジャンキーとしては楽器を触ってみたいとずっと思いつつ仕事のインプットもあるしなーと手をつけてなかったんだが「娘が物心つく前にそれなりに弾ける状態になりたい」という時間軸での目標が自分の中で湧いてきたので練習をし始めました。
かれこれ半年以上は練習してることになってるんだけど難しすぎて全然形になってなかったり、育休明けてからはなかなか練習時間を取れてないんですが楽しいので補足長く続けていきます。
交通事故にあった
自転車乗ってたら車に轢かれるという体験をした。幸い怪我はほとんどないので良かったが被害者側に暗黙的に課せられるTODOが多すぎて2週間ぐらいメンタルが死んでた。
弁護士特約を使える保険、かつ軽傷でも適用できる保険に入っておくことを全力で進めたい。そんな保険あるのかわからないので要調査ですが…。
滋賀生活約1年の所感
いろんな人に聞かれるたびに言ってるんだが、本当に特筆して悪い点が東京と比べてない。逆にめっちゃおすすめってところもないんだけど感覚的には東京で感じてた不満が全部解消された感じでいいです。
具体的には人多すぎ、自然に触れ合えなすぎ、家賃高すぎ、週末車で出かけたら渋滞でしんどすぎ、等々の悩みがなくなった。
一方で元々わかってたことだけど友達少なすぎ問題と、最近はオフライン勉強会が戻ってきたことで行きたい勉強会が東京で開催されすぎ問題がある。
子育て観点だと間違いなく今がベストな一方、上記の問題をどうにか解決できたらいいな〜とぼんやり思いつつ琵琶湖眺められる眺望での暮らしが最高すぎてダラダラこのまま過ごすかもしれない。知らんけど。
ライブ
今年は流石に去年からグッと減って24本のライブに行った。
その分、本当に好きなバンドや見てみたいアーティストに絞ったので良かった。
全部良かったけど、10/6のROTTENGRAFFTY@KYOTO MUSEがコロナ明け全解禁で見た初ロットンだったのでまじで楽しかった。本当に楽しかった。京都で観るロットンからしか得られない栄養があった。
フェスに行く回数が激減したのが寂しいけど子供が大きくなった時の楽しみに取っておこうという気持ちです。
来年
半年の休みはあったものの、来年の8月で10Xが一番長く勤めた会社になりそう。とてもとても楽しくモチベーションを持って働けてるので自分の足りてない技術を伸ばしながら引き続き頑張りたい。
プライベートはなんかバタバタというか可処分時間がやっぱり減ったので最適化していく年にしたいなーと思ってます。ちゃんと生きるぞ。
お世話になった方々本当に今年もありがとうございました。来年もよろしくお願いします💪
自分のREADMEを書いた
書いた。
いわゆる職務経歴書的なもの。
なぜ書いたか
- いつか書こうと思ってた
- 社会人経験もそれなりに長くなってきたので自分のやってきたこと/できなかったことを覚えてるうちに記録していく場所が欲しかった
- 副業や転職で半永久的に使えて保守しやすい資料が欲しかった ※ 現状、転職の意思は全くないです
転職する気はないし副業を探してるわけでもないけど、慢性的に人手不足な業界なのでリクルーティングのDMやメールを頂くことがあって、それはありがたいけど毎回「自分はこういうスタンスです」というのを示すのもコストがかかってきて、でもぞんざいに扱ってどこかで一緒に仕事をするときに「あの時の…」ってなるのも嫌なのでそういうものに対する免責として作っておきたかった、というのもあります。
ゆえにページの上の方に現在のステータスをなるべく情報量少なめで書いたので今後は「これ読んでください」で済ませられたらいいなと思ってます。
工夫した点とかは特になくて、強いていうならNotion力が上がったので書くときに楽できる仕組みとかテンプレとかを作ってみたという感じです。詳しくは興味があれば読んでください 🙏
以上
Podcastの内容をChatGPTに要約させる
2023/04/16 追記
そもそも ChatGPTで外部URLは読み込めないので全て勘違いだった🙄
ChatGPT自身に聞いたらできると言ったので勘違いしました、もうChatGPTの言うことを何でもかんでも信じないぞ…
流行りに乗ってみた、というより楽がしたいと思ってやってみた 自分用のメモ程度なので雑に
手順
whisperを使ってPodcastの内容を文字起こしする
以下の記事を参考にColaboratryでやった。
サクッとできたけどスペック足りずで上手くいかないのでGPUに課金した。
GitHubにアップロードする
文字起こしした文量が多すぎてChatGPTが受け付けなかった。また、分割してもうまく解釈してくれなかったのでGitHubにアップロードしてそのURLを読んでもらうようにした。
公開前にpublic repositoryに置くのは微妙かなと思いつつ、人間が読みやすいものではないし特に秘密情報でもないので気にせずあげることにした。
ChatGPTに食わせる
以下、試行錯誤の履歴(これを残すためだけにpost書いたと言っても過言ではない)。
- 言語処理100本ノック、どこから出てきたの
- ごめんだけどこんなに真面目な話はしてない
- フォーマットをガン無視された
悪くないけどフォーマットは相変わらず無視される
少し条件を変えたがあまり変わらず。 よく読むと話した覚えがないなーという感じもある。
ここまで15分程度の時間を使ったが、もう面倒だし自分で書くかとなった。
所感
- いわゆるプロンプトエンジニアリングを洗練することで望む答えは得られるのかも
- ChatGPTの気持ちをまだ理解できないのでもう少し使っていきたい
- レスポンスの速さはすごい
- 雑に使ってそこそこの内容が出てくるのでサクッと新しいサービス実現できそうな感じはある
少し早いけど2022年の振り返り
まだ1ヶ月ほどありますが、もうあっという間なので今のうちにね。
THE MANZAIのおぎやはぎがネタで言ってた「まだ実質8月だよね」にめちゃくちゃ共感してます。
ざっくり
- 10Xで頑張って楽しく働いた
- 今年もライブにたくさん行った
- 推しを推すために摂取するアルバムを記録し始めた
- 滋賀に引っ越した
- 子供が生まれた
10Xで頑張って楽しく働いた
これらに大体まとめたので特に言うことはないです。
とにかく楽しく、タフに働けてよかったです。
自分がギリギリ達成できないかもと思える課題に取り組み続けられるのは個人として学びになっているし、事業の可能性も会社全体で信じ続けながら走れてるのがとてもいい。
引き続き頑張ってまずは日本国内で欠かせない存在となっていきたい。
今年もライブにたくさん行った
たくさんいきました。コロナ禍になってからかれこれ2年近く経過し、ライブも少しずつ元の形に戻り始めてる感覚があります。
ここからはただの老害発言ですが、コロナ禍になった年の9月に勇気を持って行ったライブはキャパ1/10、観客からステージは10列分ほどの距離を空けて30分に1回、5分間の換気タイムを設けての開催でした。
ここから並々ならぬ努力でここまで来れたのは本当に感慨深いです。
推しを推すために摂取するアルバムを記録し始めた
いろんなフェスやいろんなライブに行く中で、芋づる式で推しが増え続けてました。
ただ、その過程で「新しい推しの音源を摂取しきれない」というIssueが顕在化してきました。
そこで推しの全ての音源を聴き切るには人生は短いので不可能、という前提の元以下を試しました。
- 毎週月曜日、その週に聴くアルバムを決める
- アルバムは気分で決めるが、その時に一番聴きたいものを聴く
- それ以外を聴いてはいけないわけではない、他のが聴きたくなったら存分に聴く
- オタク特有のコンプリート感を演出するためにNotionでまとめる
やってみた結果としてはよかったかなと思います。
- 「あ、これ聴きたい！」という本能を生かしつつ、理性的に聴きたいものを効率よく聴けた
- アルバムを聴き尽くすのに1週間はちょうどよかった
- 結果としてaikoを聴く時間が減ってしまった(Spotify調べ)
- 一方でデータ的には偏りなく満遍なく聴いてるみたいで我ながら染み付いてるなと思った
滋賀に引っ越した
琵琶湖の見える素敵な部屋です。
理由は以下です。
- いつか関東圏外に住むという夢があった
- 神奈川東京にしか住んだことがなかった
- 昔は海外に住みたいと思ってたがその欲は減ってしまった
- 引っ越し先の選び方は以下
- aikoがツアーで必ず来る
- 大きめのライブハウスがある
- 住みやすい
- あともう1回くらい引っ越したいので、永住の地に相応しくなくてもよい
滋賀県ライブハウスなくない？と思うかもですが、大津市周辺で場所を選ぶと実は京都まですぐに行ける(京都駅までdoor to doorで20分)ことに気づき、家賃も安いしいい感じに田舎っぽいしで決めました。
あと京都出身の推しバンドがちょくちょくいるので、彼らが育った地を巡ってみたいという気持ちもあります。住むの京都じゃないけど。
関西に遊びに来る人いたら声かけてください。あと東京にちょくちょく行く気もするので構ってほしいです。
(友達が一切いないのが唯一の懸念)
子供が生まれた
上記の引っ越しを検討したきっかけがこれでした。
先日、12/7に元気な娘が生まれました。というわけで半年間の育休を取ります！
仕事から離れるのはそこまで不安はなくて、まぁどうにかなるでしょと思ってます。会社のメンバーも頼もしいので半年後が楽しみです。
子育ての先輩方は色々教えてください！
生まれたらやっぱりめちゃくちゃかわいいし、子育ても楽じゃないと思うので今までと時間の使い方は変えないといけないと思ってるんですが、それでもたまに一緒にご飯に行ってくれると嬉しいです。
最後に
お約束です
(宛先が福井県なのは仕様です🙇♀️)
notion-sdk-jsをチョット便利に使えるnpm package書いた
書いた
notion-sdk-jsとは
Notion APIを叩くためのTypeScriptのライブラリ。多分公式。
何を解決したいのか
Pageを作成するAPIを叩く際にJSONを組み立てるのがめんどくさいのが一番だった。
型定義で守られてはいるものの、ドキュメントを見ないとまず書けないし後は書く分量がどうしても多い。
例えばHeading 1, Paragraphの2つだけで構成した下記のページを作る
この場合、こんなコードを書く必要がある。
import { Client } from '@notionhq/client'; const client = new Client({ auth: 'YOUR_NOTION_API_TOKEN', }); await client.pages.create({ parent: { databse_id: 'DATABASE_ID', }, properties: {}, children: [ { type: 'heading_1', heading_1: { rich_text: [ { type: 'text', text: { content: 'Section1', }, }, ], }, }, { type: 'paragraph', paragraph: { rich_text: [ { type: 'text', text: { content: 'I am ', }, }, { type: 'text', text: { content: 'engineer', }, annotations: { bold: true, }, }, ], }, }, ], });
長くないですか？僕は長いと思って毎回書いてられん…と思ってしまいました。
また、地味に仕様上めんどくさいなと思ったポイントとしては文字列を渡す際、ほとんどはRich textを配列形式で渡す必要があることです。
上記のコードから抜粋すると以下です
await client.pages.create({ // ... children: [ // ... { type: 'paragraph', paragraph: { rich_text: [ { type: 'text', text: { content: 'I am ', }, }, { type: 'text', text: { content: 'engineer', }, annotations: { bold: true, }, }, ], }, }, ], });
ここで配列で渡す理由は、文章としては1つでも文字1つ1つにDecorateion(Notion APIの言葉で言うとAnnotations)が振られる可能性があるため、それを仕様として吸収するために配列形式になってます。
Notionの仕様上、しょうがないのは納得できたんですがAPIを利用時に毎回そこそこ大きめなObjectを羅列するのは辛いなと思いました。
ちょっとでも楽しようと思って作った
と言うわけで作った。
先ほどのコード例はこれを使うとこうなる。
import { BlockObjects, RichTextObjects, CustomTypes } from '@sota1235/notion-sdk-js-helper'; import { Client } from '@notionhq/client'; const { heading1, paragraph, } = BlockObjects; const client = new Client({ auth: 'YOUR_NOTION_API_TOKEN', }); // Use helper methods when create page await client.pages.create({ parent: { databse_id: 'DATABASE_ID', }, properties: {}, children: [ heading1('Section 1'), paragraph([ RichTextObjects.richText('I am '), RichTextObjects.richText('engineer', { bold: true, }), ]), ], });
さっきよりは書きやすい & 読みやすくなりました。
この量だと書けばいいじゃん、となるかもしれませんが実際に作りたいページはもう少し複雑なのでこれがあるだけでだいぶ書き味が変わるはずです。
下記ページに大体のBlockのサンプルコードを載せてるのでそちらを読むとよりイメージが湧くと思います。
Example page for notion-sdk-js-helper
地味に面倒だと思ってた文字列の配列に関しても、少しでも楽に書けるようfunctionの入口はstring | RichText | RichText[](RichTextの型)を受け付けつつ、各部分でその部分を吸収するようにしました。
await client.pages.create({ parent: { databse_id: 'DATABASE_ID', }, properties: {}, children: [ paragraph('text'), // stringだけ渡すのでもOK paragraph(RichTextObjects.richText('engineer', { bold: true, }), ), // RichTextだけ渡すのでもOK paragraph([ RichTextObjects.richText('I am '), RichTextObjects.richText('engineer', { bold: true, }), ]), // RichTextの配列もOK(これが元々の仕様) ], });
これでだいぶストレスフリーに書けるはずです。
※ サンプルコードを書いてて気づいたけどstringとRichTextが混ぜこぜの配列も渡せるようにした方が楽そうなので改善しておきます
作るにあたり
ここからは苦労談義なので興味がなければ読み飛ばしてください
型定義をどうするか
ブロック1つ1つのObjectを生成するfunctionsを作るにあたり、それぞれのブロックの型定義が欲しくなります。
notion-sdk-jsは結構、堅牢な型定義があるのでそれを利用すればすんなりいけるだろうと思ったら「これが欲しい…！」と言う型はexportされていませんでした。
exportするだけだしPull Request出そうかなと思ったんですが質問はなぜかメールでしか受け付けておらず、質問してみたら「いいアイディアだね！いつかは検討するけど他にもいろんなfeature requestがあるから待っててね！(意訳)」と言う感じの回答が返ってきたので本家のコードを直すのは諦めた。
代わりに欲しい型を取り出すAdHocな方法を教えてもらったのでいまいちとは思いつつそれを参考に型定義を作った。
具体的には以下のファイルに色々書いてて、読むと分かるんですがあまり綺麗な方法ではないです。
Undocumentedな仕様がたまに紛れてる
直感的にはいけそうなんだけど、実際にAPIを叩くとうまくいかない部分がちょいちょいありました。
つまるところ、notion-sdk-jsの型通りに使ってれば壊れることはないので利用者は特に意識する必要はないのですが例えばColumn Listの子BlockにTableは突っ込めないという制約があったりします(手動で書くと当然作れる)。
まとめ
- 楽したいので自分のために作ったけど似たような需要があれば使ってください
- メンテナンス頑張りますけどバグってたらIssueかPRください
- 普段お世話になってるyhatt/jsx-slackから発想を得たりしました。JSXで書けるようにしたらおもろそうだし勉強になりそうだなと思ったけど流石に高級だなと思って愚直に書くだけの実装にとどめました
