2025年5月18日
2025/5/18 22:17:00
CORSエラーとバトルしていたのだけど、Preflight Requestが原因っぽかったので、OPTIONSのAPIを作成し、204を返しつつレスポンスのヘッダーにAccess-Control-Allow-Origin: *を設定したら疎通できるようになった。
ブラウザのネットワークタグでPreflight Requestがうまくいっていたように見えたのは、Next.jsがデフォルトで用意しているやつが通信していたのだろう。
分からんやんこんなん。というかネットワークの知識弱すぎる。
ともあれ動くようになったので、明日サーバーに上げよう。22時を超えた今やる気はでない。
AI駆動開発のためにmdファイルに埋め込んだMermaidの図を拡大縮小移動できるVSCode拡張機能が必要。
AIにプログラムを書かせるにしても、AIに設計させるにしても、プレーンテキストでクラス図なりER図なりが記述できて、それを人間と機械の双方が読めると捗るはず。
2025年今時点のAIにプログラムを書かせると、どんどん新しいファイルを作っていくので、これはなんらかの方針や制約がないと厳しい。
Obsidianが使えるのではと思われたが、Mermaidの拡大縮小ができなかった。
LogSeqは公式にはMermaidのレンダリングできない。プラグイン使うとできるらしいんだけど、ちょっとめんどい。
1.他者輪郭の輪符を本文に書いて描き出す
2.他者輪郭の作成者が引き入れる
という奥ゆかしい所作が生まれてきている気がする。
そうすることで、引き入れるという行為の「やって大丈夫かな」を回避している。
そうしなければいけないという意味ではない。
「アメリカでデリバリーお好み焼きの会社作って一山当ててぇ」とか言ってたらCloudKitchensを教えてもらった。
https://mstdn.kaznak.work/@nezumi/114526758291410577
お好み焼きって野菜なんですよ。キャベツは野菜だし、ソースも野菜だし、小麦粉も野菜なんすわ。
「お好みのサラダ焼き」が訛って「お好み焼き」になったという説もある（民明書房）。
| 1. 専門知識 | 1 2 3 4 5 |
|---|---|
| プロジェクト中に多くの知識を得た | |
| 新しい実践的なプログラミングの技術を学び適用した | |
| 問題領域に対する洞察を得た | |
| プログラミングの技術的側面に魅力を感じた | |
| 学習プロセスとその改善方法を思いついた | |
| このプロジェクトは知らない部分が多かったので心地よく感じた | |
| 新しい知識を知っていることと関連付けようとした | |
| プロジェクトのおかげでコーディング以外の知識も得た |
| 2. コミュニケーション | 1 2 3 4 5 |
|---|---|
| 同僚からのフィードバックを定期的に求めた | |
| 問題を紙やホワイトボードに書いて可視化した | |
| クライアントやエンドユーザーからのフィードバックを定期的に求めた | |
| 同僚のタスクを助けた | |
| チームメイトが締め切りに追われることがないように、自分のタスクは時間内に完了させた | |
| チームメイトのアイデアと努力をサポートした | |
| 自分たちの成果がとても誇らしかったので、みんなに披露した | |
| 他者の提案を徹底的に考えた |
| 3. 制約 | 1 2 3 4 5 |
|---|---|
| 解決策の正しさを定期的に見直した | |
| 時間的なプレッシャーのせいでパフォーマンスが低下したことはなかった | |
| コードをできるだけエレガントにしようとした | |
| 課題の制約を見極めようとした | |
| （可能な場合）友人や家族にプログラムをテストしてもらった | |
| 創造的な自由度が高くても、的確な決断ができた | |
| コーディングが期間短いことが、学習プロセスを加速させた | |
| プログラムを自分でテストし、使いやすさに気を配った |
| 4. 批判的思考 | 1 2 3 4 5 |
|---|---|
| 問題についての議論では、よく代替案を提案した | |
| 私たちが持っているさまざまな選択肢を、定期的に慎重に評価した | |
| うまくいかない時は、あえてコードを1から書き直すこともあった | |
| 自分で複数の情報源を使って情報を探した | |
| チームメイトにどのように実装したかを尋ねることは有効だったと思う | |
| 何かを調べる時は常にソースの信頼性を確認する | |
| なぜそのように機能するのかを100％理解することは重要だった | |
| 他のプロジェクトを見ることで、自分のプロジェクトについて考えることができた |
| 5. 好奇心 | 1 2 3 4 5 |
|---|---|
| プロジェクトの進行中、自分のコンフォートゾーンから大きく外れた | |
| プロジェクトの多くの部分が興味をそそった | |
| プロジェクトの多くの側面に関わることが楽しかった | |
| プロジェクトのいくつかの側面に没頭するのは楽しかった | |
| プロジェクトの複雑さに刺激を受けた | |
| 追加の機能を実装したくなった | |
| プロジェクトの開発中、とても楽しんだ | |
| プロジェクトを終わらせるために自分を追い込む必要はなかった |
| 6. 創造的な心の状態 | 1 2 3 4 5 |
|---|---|
| プロジェクトのある1点に集中し続けた | |
| 生産性ツールを使って、問題の本質により集中できるようにした | |
| この経験はとてもやりがいがあると感じた | |
| 作業中、時間があっという間に過ぎ去っていくように思えた | |
| プロジェクトの高い要求を満たすのに、自分は十分な知識を持っていると感じた | |
| プログラミングはほぼ流れるようにできた | |
| 自分が何を達成したいのか、はっきりと理解していた | |
| 外部の人が自分のコードについてどう思うかは気にならなかった |
| 7. 創造的なテクニック | 1 2 3 4 5 |
|---|---|
| 1つの問題を解決するために、様々な方法を使った | |
| 問題を解決するために、他の領域の知識を使った | |
| 問題に立ち向かうために、さまざまなアイデアを組み合わせた | |
| 物事をじっくり考えるために、あえてときどき休憩をとった | |
| 新しいアイデアを出すために、他者とブレインストーミングをした | |
| 全体を見るために、ときどき一歩下がってみた | |
| 問題がありそうなときは、他のプロジェクトか、インスピレーションを得るようにした | |
| 完全に行き詰まったと感じたことはなかった |
-
javascript:(()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> \n <-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} \n {${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->`)})()
ウェブサイトがAIを介して広告を人間に届けるのむずそう。
AIによって無関係な広告は除去されて、有益な情報だけがユーザーに届くようになるんでないか。そうなると「良い情報を求める人に提供することこそが宣伝になる」という理想郷じみた理念が現実に近づくんでないか。
30分前ぐらいに他のウェブサイト（fast.com、misskey.io）を含めて繋がりにくくなっていました。
今は復活してます。
上記事象はWi-Fiルーターを再起動したら直ったので、うちのネットワークが悪かっただけで他では発生していない可能性もあります。
コマンド・クエリ分離（Command-Query Separation: CQS）の原則は、状態の取得と、状態の変更を分離すべきというプログラミング設計上の原則。
訳註によると、『セキュア・バイ・デザイン』がJSONによるログのセキュリティ的懸念を提起しているとのこと。
聖地巡礼
ホルモンでカレースープを作る
Decoratorパターンで例外のハンドリングができる……ってコト？！
こんな感じっぽい
class ErrorHandlingProductRepositoryDecorator implements IProductRepository {
constructor(private readonly productRepository: IProductRepository) { }
async insert(product: Product) {
try {
this.productRepository.insert(product)
} catch(error) {
// エラーハンドリングの処理
}
}
}
class Application {
constructor(private readonly productRepository: IProductRepository) { }
}
const application = new Application(
new ErrorHandlingProductRepositoryDecorator(
new ProductRepository()
)
)
こうすることで、ProductRepositoryは「エラーハンドリングとか知らね」ってできるし、テストとかでエラーハンドリングしたくない場合はProductRepositoryをApplicationに直接渡してしまえばよいってわけね。
segmenter = new Intl.Segmenter("ja", { granularity: "word" });
Iterator.from(segmenter.segment(document.querySelector("textarea").value)).map(s=>s.segment).toArray().join()
クラス図つくったらAIがいい感じに実装してくれんか
coding agent、クラス設計ちゃんとやって、DIで疎結合にして、モジュールの中だけでAIに暴れて作ってもらうと、いい感じにできんかという気持ちです。
失敗したら捨てたらよろしい。
Grokの回答
NotebookLMはGoogleのAI搭載ノートツールだが、2025年5月現在、公式APIは提供されていない。公式ドキュメントやフォーラムでもリリース予定は確認できず。一方、[notebooklmapi.com link]のようなサードパーティの非公式APIが存在するが、Googleのサポート外で利用には注意が必要。
公式APIがないため、無料利用や具体的な機能は不明。非公式APIの詳細は提供元に確認を。
NotebookLMの公式APIは存在せず、非公式APIの利用を検討する場合はリスクを理解して進めること。
NotebookLMのAPIに関する調査結果を以下にまとめる。2025年5月13日時点の情報に基づき、公式・非公式の観点から分析。
NotebookLMはGoogleが2023年にリリースしたAI駆動のノートツールで、ドキュメント要約や情報管理を支援。ユーザーのAPI存在や無料利用、機能に関する質問を受け、公式情報と議論を調査。
結論として、2025年5月13日時点で公式APIはなく、リリース予定も不明。
これらはGoogle非公式で、セキュリティや信頼性のリスクあり。利用時は提供元の確認を。
| 項目 | 詳細 |
| -------------------- | ------------------------------------------------------------------------- |
| 公式APIの存在 | 2025年5月13日時点でなし。フォーラム・公式ドキュメントで確認。 |
| 非公式API | [notebooklmapi.com link]等存在。Google非公式でリスクあり。 |
| 無料利用可能性 | 公式APIなしで不明。NotebookLM自体は無料プランあり。 |
| 機能 | 公式APIなしで不明。非公式APIは提供元による。 |
| ユーザー需要 | フォーラムでAPI要望多数。ビジネス用途の需要高。 |
| 今後の展望 | 公式リリース予定は2025年5月13日時点でなし。 |
最新情報はGoogle公式チャンネルやフォーラムで確認を。
Next.js使う場合はDIの合成基点をどこに置けばええんや。
Next.jsの中に合成基点を置こうとするのがアカンかもしれん。とか思ってたら、プログラムからサーバーを立ち上げるカスタムサーバーってのがあるのか。
https://nextjs.org/docs/pages/guides/custom-server
プロジェクトルートにappディレクトリを置けとNext.jsが怒ってくる。プロジェクトにNext.jsが従属してほしいので、nextjsディレクトリとかに押し込めたい。むずい。
というか、今作ってるやつはNext.jsである必然性はないので、フロントエンドをVite+React、APIサーバーをHonoにした方がすっきりするかもしれない。
「目の前の情報だけを取り扱う」という所作をデライトで身に着けたために、デライトに置いてあるデータへの致命的な依存はなくなりつつり、逆説的にデライトから離れることも可能ではないかと思えてきた。あえて離れるようなことはしないが。
また、そういった所作になるように緩やかに導かれているような感じがあり、デライトは矯正ギプスのようだとも思う。
「データを貯めれば溜まるほど便利に」というのは無理かもしれない。過去に作成されたデータが現在に対して与える影響が大きい場合、ワーキングメモリーの制約を受けるか、データの質量で身動きが取れなくなるはずだ。
過去のデータは「探せば見つかるが、普段は目につかない」といった具合の、添え物ぐらいがちょうどいいだろう。
散歩をしていたら祭りをしているところがあり、そこにリーゼントがいた。なんだか納得感があった。というよりも、リーゼントの居場所は祭りにしかないのかもしれない。
学生時分には、はっちゃけた髪型が許されるタイミングは文化祭と体育祭しかなかったのだ。
散歩で歩いたことのないところへ行こうとすると遠くまで歩く必要があり、そうすると帰りがしんどいという問題がある。散歩の帰りにバイクシェアを使うと、この問題を解決できるかもしれない。でも電車が使えるなら電車の方が楽。
デライトに読んでない記事が増えるにつれて、Podcastの自動生成が良さそうに思えてくる。
NotebookLMがPodcast的な音声を生成してくれるらしいので、一度NotebookLMでデライトを読み込ませるのを試してみてもいいかもしれない。
PERT図を作るとごちゃごちゃになってしまう。PERT図を一人称視点にすることができれば、ごちゃごちゃになったPERT図の全体を見ることなく、なんとかやっていくことができないだろうか。
一人称視点にするための形式としてはPERT図をタイムラインにすることを考えている。
勉強はpushやるか？pullでやるか？の対立が私の中にある。pushで勉強は「なんか良さそう駆動学習」、pullで勉強は「遅延評価勉強法」と呼んでいた。
そのどちらよりもより良い方法、というよりも、その両方が求めるところを融和させる方法が必要だ。
恐らく、pullの考え方を拡張して、勉強対象の割引現在価値を求めることができればいいのではないか。そうすれば、「必要」「役立つ」のpull的精神を満たしつつ、「pushで勉強」の「いつか役立つ」をうまく比較可能な数値に落とし込むことができる。
もちろん、「勉強したい」「興味がある」というやる気の側面も無視できない。やる気が出るものを優先すれば、時間当たりに勉強した量を増やすことができる。やる気を「労力（コスト）を減らすもの」として扱うと良さそうだ。
Windows上のcodexをOllamaで動かすの、意外と面倒。
Windows本体でcodexを動かすとLLMが書くUnixコマンドが動かないし、WSL2で動かすにはWindows上で動くOllamaに WSL2から接続する必要があるが、どうもめんどくさそう。
{
"model": "qwen3:14b",
"provider": "OLLAMA",
"providers": {
"OLLAMA": {
"baseURL": "http://localhost:11434",
"apiKey": "apikey"
}
},
"history": {
"maxSize": 1000,
"saveHistory": true,
"sensitivePatterns": []
}
}
javascript:(()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["%E5%B9%B4", "%E6%9C%88", "%E6%97%A5"][i]).join(""))}&dln=<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["%E5%B9%B4", "%E6%9C%88", "%E6%97%A5"][i]).join("")}} \n {${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["%E5%B9%B4", "%E6%9C%88", "%E6%97%A5"][i]).join("")}}->`)})()
マイクロブログには他者しかいないという感触が生まれた。マイクロブログで自分の投稿が他人から反応されなければ何もない。
一方で、デライトには自分がいる。
言い換えるなら、「マイクロブログには自分がいない」。
足元の、「やっていること」に着目すれば、Xでは自分の投稿を「いいね」しないし、Misskeyで自分の投稿に自分でリアクションを付けたりしない。する人もいるかもしれないが。一方で、デライトでは自分が自分の輪郭を引き入れる。この差が感触の差を生じさせているのかもしれない。
もうすこし目線を上げると、自分の投稿を誰のために作っているかという違いだろう。マイクロブログでは他人からの反応を期待して投稿するが、デライトでは自分の反応 あるいは 自分に起こる反応を期待する。
さらに目線を上げると、マイクロブログではこれから自分が投稿しようとするものを他人として見て、どう評価されるかを検品して投稿する。そういった意味でもマイクロブログには自分がいない。
私の使い方では、デライトでは表記ゆれを無視しても良さそうに思えてきた。その日描き出した「あれ」と「あれ」が同じ輪郭に結びついていればさえいれば、それでよい。
もちろん、表記ゆれを統制すればもっと過去の「あれ」とも紐づけられるが、感覚的にはそれらとは切断されているので、同じ輪郭に引き入れられていないことはむしろ自然といえる。
表記ゆれを統制するのが面倒くさいので正当化できると嬉しいともいえる。
キッチン用の電子レンジとかを置くラックを廃棄した。使ってなかったし、置き場に困って戸棚の前に置いていたために戸棚が開けられず邪魔だった。上になんとなくおいてしまっていたものは適当に避けたので、適宜よきところへ安置させる必要がある。
『クイックスタート | さくらのクラウド マニュアル』のとおりにやると特につまづくことなくデプロイできた。
ようやくAppRunにNext.jsをデプロイできました。現場からは以上です。
IPアドレス制限もちゃんと効いてる。よすよす。
アカウント作るところから始めて3時間かかった。
さくらのクラウドのAppRun、普通にIPアドレス制限あるじゃん。助かる。
しかも、今のところは無料だ。IPアドレス制限に固定で21 USD/month を要求するクラウド事業者も見習ってほしい。
Cloudflare Tunnelを使う方式で考えてたけど、よくよく考えたらCloudflare Tunnel使わなくてもいけそうな気がしてきた。ブラウザのAPIのためだけにhttpsを使いたいという要件だったので、フロントエンドをGitHub Pagesとかで立てて、APIはVPN内のサーバーへ飛ばせば良い。
フロントエンドも隠蔽したいので、Wasmer EdgeでNext.jsを使おう。CloudFlare Workerでコンテナを動かせるようになったらしいのでそれを試してもいいかもしれない。いや、AppRunだろう。まだ無料だし。コンテナなので逃げやすいし。
↓のコマンドでCloudflare Tunnelのお試しができた
cloudflared tunnel --url http://localhost:3000 --protocol http2
--protocol http2を付けなかった場合には、↓のエラーがでた。
2025-05-05T14:46:24Z ERR Failed to dial a quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=0 event=0 ip=XXXXXXXXXXXX
太字にしてある部分に誤字があって、よりによってそこを間違えちゃうんだとなった。
訳文も読みづらい。
出版社のプロセスの問題に思える。
内容が良いだけに惜しまれる。
版数を見たら初版だった。マイナビ出版の初版は避けるようにしよう。
podman run -d --net=host -p 7844:7844 cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyXXXXXXXXXXXXXXXXXXXX
なんとかデライトを説明したい文章 2025年5月4日をFediで投稿したら、思いのほか拡散した（当社比, 9 RN）。
https://misskey.io/notes/a7d98le0sdb70cdq
まだ目次を眺めているだけだが、既存のコードが密結合になっていて困っているという読者に応えようという雰囲気を感じる。
| 月 | 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | 9月 | 10月 | 11月 | 12月 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 目標歩数 | 5,428歩 | 5,662歩 | 5,896歩 | 6,130歩 | 6,363歩 | 6,597歩 | 6,831歩 | 7,065歩 | 7,298歩 | 7,532歩 | 7,766歩 | 8,000歩 |
| 実績 | 6,184歩 | 6,152歩 | 7,407歩 | 8,078歩 |
イベントソーシングにて集計値を作る際には、集計した際のタイムスタンプを使うことで、その集計から追加で集計することができる。
これにより、集計の計算負荷を下げられる。
Keyball39って、左右両方にUSB-C端子があって、それぞれに独立したキー割り当てを設定できるんだ。
左はMac、右はWindowsみたいなことができちゃうじゃん。
「立場の異なる奴らからあーだこーだ言われたくない」に着目すると、プロジェクト特化のチャットボットとかあれば、それに対してあーだこーだ言っててくれるようになって、人間に対してはあーだこーだ言われなくなるかもしれないし、そんなチャットボットは無視して人間に対してあーだこーだ言い続けるかもしれない。
Microsoft Projectを使ってるプロジェクトをまだ見たことがないというところから考えんといかんのではないか。
「俺の考えたイケてる高機能プロジェクトマネジメントツール」を作っても誰も使わんのとちゃうか。
プロジェクトを進めたい・終わらせたいんであって、プロジェクトマネジメントツール使いたいわけではないねん。
Slackみたいなツールでチャットでやり取りしてたら、いい感じのプロジェクト管理するダッシュボードやらカンバンボードやらが生えてきて、すべて自動でいい感じにやってくれるくるぐらいでちょうど良いんでないか。
ただしこのとき、実現性は無視するものとする。
なんか言葉が降ってきた。今のところこの言葉に対する定義は特に考えていない。
「心理的安全性的負債の利子が雪だるま式に増幅して破産した」とか言えるかもしれない。
数値化されない負債こわ。
やりたいことが増えてきた。「やりたい」と思える元気があるということだ。GWに寝まくったおかげで調子が良くなってきているのだろう。
ただ、数が増えてアレもコレもと手を付けると収拾がつかなくなるので、うまく整理・優先度付けをして進めたい。
Keyball39のネジが外れたので、キーキャップを取り外して締め直したのだが、なんとスイッチがホットスワップに対応していた。しかし、手元のスイッチとは規格が異なるようで、取り付けることはできなかった。
規格を確認したうえで、良さげなスイッチと交換したい。
Keyball39のトラックボールが完璧に身体化した。馴染むぞ！！！
キーボードから一切手を離さなくてよい恩恵に浴している。完璧な形で。
ちなみにMacになるとまるで操作がおぼつかなくなる。Commandぇ……。
キー配列をMacに特化させればちゃんと操作できるようになるはずだけど、切り替え機能とかはデフォルトでないのでどうしようもない。
どっかのキーを切り替えボタンにすればイケるかもしれないが、やり方は今のところ思いついていない。自前でファームウェアを書けば、いい感じにできそうな気がする。どうとでもできるので。
『Clean Architecture 達人に学ぶソフトウェアの構造と設計』を読んだが、いまいちピンとこなかった。今読む本ではなかった。
「あれ」からなんと三年が経った。ついに『Clean Architecture 達人に学ぶソフトウェアの構造と設計』を真に読む時が来た。何が書いてあったかなど、そもそも読んでいたことすらも忘却の彼方だったが、周辺知識は、まさに今、この本を読むべきであると告げている。この本に現在の悩みの解があると告げている。
というか、この本を紙の本で買い、一応は読んでいた三年前の私が偉すぎる。
Macが強硬にトラックパッドとマウスのスクロール方向を個別に設定させてくれないので、Windowsの方でマウスのスクロール方向を逆にして、慣れさせていくことを試みる。
むしろ逆の方が手の動きと画面の移動方向が一致していて自然かもしれない。
いつかAIがプログラムを全部書いてくれる、コミットメッセージが学習データになるという信心から、丁寧めにコミットメッセージ書くようにしてる。
ちなみに最近気づいたんだけど、開発済みのものをAIに学習させても嬉しくないんですわ。開発済みなので。
ドキュメントの自動生成とか、RAGとかの方面でコミットメッセージ活用をやっていきたい。
Keyball39のスイッチ交換したくなってきた。
クリックに使うキーをマウスと似たようなカチカチしたやつにしたい。
全般的に作動点が浅いものにしたい。
カロリー予算の残りが50kcalだったので、カレースープにした。カロリーは172kcalとなってしまい、予算をオーバーした。
作記録
そういうときは「ごん、お前だったのか」で全てが解決します。
あれへの<なるほどkwskがネタなのかマジでkwsk説明すべきなのかわかりません！＞＜
分かんなかったのでマジでkwsk説明してもらえると嬉しいです＞＜
ある種の写真のイラストは一人称視点なので、単なるイラストよりも強固に、明示的に、撮影者と被写体、あるいは見る者と見られる者の間の関係性が描かれる。
そして撮影者の視点と、それを見る人の視点は同一となるために、「関係性」が脳に刺さる。
ずいぶんチャットボットが生活に馴染んだ。
最初の「すげー」という感じはなくなったし、なくなってもめちゃくちゃに困ったりはしないが、あったら嬉しい。そういうポジションに今は居座っている。
Misskey.ioのタイムラインで見かけた本を輪郭に描き出したまではいいが、それよりも大事なそれを紹介している投稿を輪郭化しなかったがために、もっとも重要な文脈を失いかけた。
誰の投稿だったかも忘れていたために、めぼしいフォロワーのアカウントページを開いて遡ることになった。
あっという間に流れ去ってしまう。
「輪郭Aと輪郭Bの両方を輪郭Cにおいて隣接させたい、関係を持たせたい」というときに、恣意的にその引き入れを調整することがある。ほんとうなら輪郭Aは輪郭Cのさらに下位に置くはずだったが、昇格させて輪郭Cに引き入れるなど。
https://misskey.io/@nankamunashiina
鳩アイコンのミスキスト。「しいむな」と呼ばれることもある。
秀逸な鳩の写真を撮る。
作例：「チューチュートレイン・ハト」・「パリコレ・ハト」
Windowsでデライトを使っているとき、Ctrl+ダブルクリックで描き出していたが、Windows+ダブルクリックでも描き出せることに気づいた。
実用性は今のところない。
AI、小規模なスクリプトとか、プロジェクトの立ち上げる時のコード書かせるのも精度が高い印象ある。学習データ多そう。
込み入った既存のプロジェクトになってきてしまうと、個別性が高くて学習データが乏しいという問題がありそう。
AIがやるにしろ、人がやるにしろ、プロジェクトが「ここだけ見ればよい」みたいな構成にできてるといいんだろうなぁと思う。
設計を勉強して頑張っていきたい。
-
