2022/01/23
nishio.icon
井戸端に日記を書いて24時間経ったら(つまり2日前の日記を)自分のプロジェクトに転記して整理すると言う運用を試してみてる
身体性のない顔アイコン思いついたよnishio.icon前のよりわかりやすくないですかw
草takker.icon
アイコンを見てまず「誰だこれ」と思って、記述を見て「nishioさんだろうな」と見当がついて、user pageにいって答え合わせができました
わかりやすいinajob.iconblu3mo.icon
nishioさんのproject見てて色合いも覚えてるので一瞬でわかりましたｗsta.iconkuuote.iconerniogi.iconteyoda7.icon
顔というと現実の顔を想像するけどこれも確かに顔だkuuote.icon
社会とのレガシーインターフェースとして「実名+顔写真」は今後も使うだろうけど、実名である必要のないところではこっちで活動していこうかな〜
書籍的ナビゲーションをやる上で問題なのは「片方向リンクがない」ではなく「2ホップリンクされてしまう」
どういうことか
「目次から各ページにリンクをしたら巨大なリンクになる！」
これは「それが目次というものの役割だ」
「目次から各ページにリンクしたら、各ページにからも逆リンクが発生する！」
逆リンクが目次ページに対してだけ発生するならなんの問題もない、むしろ便利では？ 問題の本質は「各ページから目次ページを介して他のすべてのページに2hopリンクが生まれること」
そして小さいリンクを優先表示したりしないと「大きなリンクがすべてのリンクを覆い隠す」
いや、目次ページから各ページにしかリンクしていないのだとしたら、2 hop linkは生まれないはずですtakker.icon https://kakeru.app/7df83435ec8f3f659c524dc114bb76c1 https://i.kakeru.app/7df83435ec8f3f659c524dc114bb76c1.svg
2 hop linkになるのは各ページから目次ページリンクが貼られているとき
https://kakeru.app/cdd09c3746dbfd10d63a0d172f679898 https://i.kakeru.app/cdd09c3746dbfd10d63a0d172f679898.svg
なんと！知らなかった！nishio.icon
Scrapboxのリンクの概念難しすぎる
https://gyazo.com/125d983f24f4d3a08e7b21d15da83fe0
ほんとだー
確認ありがとうございます
あっててよかった
なので目次ページを作るのは逆にアリですねtakker.icon
やってみたけどよさそうです
Table of Contents経由の2hopリンクが作られない
本当は各ページの側にもブレッドクラムを付けようかと思ってたんだけどそれは保留することに(やるとしたらそっちだけ片方向リンクにするとかかな) あーなるほど、別タブで開いてしまうのか…
まあビューに関しては公式の実装で自分のニーズが満たせるとは思ってないのでカスタムビューでいじる方針
takker.icon
機能がいまいちだったというより
まだバグはあるが
書いてもなかなか実行しようとしない
結局ふと覗いたどうでもいいコードのrefactoringに5時間くらい費やしたあと寝た
何もできていなくてだいぶ気分が悪い
井戸端でおもしろい話題がいっぱい上がっていたが、何かを考えられる気分じゃなさそう
まあ1年後にでもふと思いついたら書けばいいか
数分後にもうふと思いついたので書いた
今日の予定に入れていた井戸端返信のタスクやった
すぐ返信する時間もなかったり返信できる気分じゃないのであとで書き込みたいけれど、書き込むこと自体を忘れたくないということがあったのでやってみた
そこそこ効果ありそう
まだ詳しくは調べていないのですが、最新バージョンv0.2.1は重大なバグが混入しているので使わないでください
scrapbox本体の動作に影響がでるほどの膨大な通信が一度に発生している
バグが混入していたのは0.2.0で最新バージョンの方じゃなかった
手元で使っているscriptのversionが古いだけだった
それをぬいてもまだ動作が遅いのだが、理由がちょっとわかってきた
cacheが切れたときに、全てのbubbleのページAPI x複数project分を一気に叩き直していたからっぽい
でもだからってそんなに時間かかるかな？
ScrapboxのAPIは100回同時に叩いても大して遅くならない
他にも要因があるような
cache切れのときnetworkから真っ先に取りに行こうとするのは悪い設計。一旦cacheを返してから、後で差し替えるべき
うーん、↑のバグ抜きでも、API待ちが長くて体験が悪くなっている
やっぱりversionを落としたほうが良さそう
inajob.icon
ほかのScrapboxのプロジェクトも気になり始めたが、あんまり入りすぎると時間も注意力も足りなくなりそう
みんなどうしている？そんなにたくさんのプロジェクトに入っていない？
井戸端が活発なだけで、他はそうでもないならそんなに苦ではない？
井戸端+2～3projectに絞ってそれ以外は捨てました（退出）sta.icon
井戸端ほど活発な場所はほとんどないですが、それでもたまに更新されたり気になって見に行ったりしちゃって足りなくなってくる
project違うと切り替える頭も違ってきてて、なんていうか雑にしか読めない・絡めなくなる感じもあった
プロジェクトに入ったからといって活動が義務付けられるわけでもないし、色々入ってみてから考えたらいいんじゃない？
それはそうinajob.icon
mrsekut.icon
スクボに全てを吐き出すので、するとツイートする内容がなくなる
/icons/わかる.iconteyoda7.iconblu3mo.iconsta.icon*3erniogi.iconyosider.icon
nishio.icon
一日は長い
日記ページの冒頭に日記を書いて、その後に下の方に追加された内容を見て加筆したら話の流れが混乱した
ので分裂することにした
最初から個別ページで書き出すのもありかとtakker.icon
あー、でもいきなり個別ページにできそうにない断片(思考の結節点)の場合はページにするのも難しいのか
こういう発展の仕方をするのは一日の最初には予見できないからnishio.icon
えー、どうしよ(英語のknowledgeとknowingの違いを日本語で説明した文章を英訳しようとしてどうしたらいいか)
一旦日本語をローマ字表記してみた
sta.icon
kuuote.icon
takker.iconさんがやってるScrapboxのバックアップみて自分もやってみたくなったのでやっている
通知にも使えないかなという目論見
https://gyazo.com/db0f0ce6b3759787bd5306106a54c89b
Streamに依存しない更新通知を手に入れたぞ
/takkerのような定期的にminifyされたコードが貼られるプロジェクトの更新を追いたかった ちょっと前にSlackのAPIと戯れていた経験が役に立っている
スクリプトできたのでやってみたけどここ33MBものデータがあるのか(プレーンテキストとしてfetchしたデータ) APIに渡すタイトルはURLエンコードしないといけないか、そりゃそうだ(日記ページが拾えてなかったw)
よし直った
encodeURIComponent()使いましょう
ScrapboxのAPIってどれくらいの間隔開けて叩くといいのかわからないな
こういうのを雑に聞ける場所が欲しい
pages APIなら大して間隔をあけないでfetchしても大丈夫
そんなレベルで行けるんですねkuuote.icon
さすがに並列fetchはしないのでwait入れなくてもいいか(失敗時の処理はちゃんとします)
1000回同時にfetchするとおかしくなる
hata6502.iconは安全を見て１fetchあたり３秒のwaitを入れてますね。（個人の発言です、念の為）
かなり時間かかる。6700ページ*3秒≒5時間半。
井戸端の規模だと現実的じゃないなあ。
waitなくてもだいぶかかりましたkuuote.icon
コンソールのログ見たら46分かかっていた、すごい
裏で自動で回す物だし全部舐めるのは初回だけだしまあいいか、wait入れときます
何も考えてなかったけど46分も負荷かけっぱなしはヤバい
2回目以降はページ一覧のupdatedで弾くので普段はそこまでかからない予定
なるほど、差分だけfetchすれば現実的な時間でバックアップできそう。hata6502.icon
それをやるスクリプトはまだ無いので書くkuuote.icon
一般論としてwaitかけずに乱打されたときにパフォーマンスが劣化したら原因の排除を検討するので適当にwaitするのが良さそう基素.icon
たしかにkuuote.icon