2021/12/09
今日のn年前
やばい教師の話があったのはこの日だったかtakker.icon 懐かしい
yuki_minoh.icon
たとえば「ページの新規作成」だけでもかなりの方法が思いつく
locationを移動する
DOMを操作する
window.open APIを利用する
websocketベース
import API
それぞれの良し悪しも、使えるリソースがどこにあるのかもぜんぜんまとまっていないと思う
観測範囲ではなさそうtakker.icon
開発者ならそれなりにいるけど
本格的に開発するならやはりGitHub(とか)にまとめるのがいい気がするが、Scrapboxとの連携がつらい？yosider.icon
実行するのにコードをコピペしてこないといけないとか
Scrapboxで議論したいけどコードはGitHubにあるとか
簡単なJavascriptならscrapboxにベタ打してもいいけど、ScrapBubbleレベルの規模になると、scrapboxでベタ打ちするのが辛くなってくるtakker.icon 以前のversionを試したくても試せない
文字列の復元だけなら容易ですtakker.icon
URLを発行できないのが問題
つまりツール作ればできないこともない、みたいな感じかyuki_minoh.icon
とりあえずメリットを記事にまとめとくんで、どう思うか聞いてみたいですね
versionごとにページを変えるという方法もあるし、実際に何回かそれをやってきたが今度は議論がversionごとのページに分散するという致命的な問題が生じる
versionごとにページを変えている例：
version特有のバグや追加した機能ならそのversionのページに書いてもまあいいけど、共通する機能のことを別々のversionのページにバラバラに書いてしまうと、どこに何が書いてあるのか全くわからなくなる
忘れてた
どうですか？不都合とかまだあります？それとも満足している？yuki_minoh.icon
不都合はコードの更新の手間が増えたくらいですねtakker.icon
ふーんじゃGitHubに書いてコード更新のためのユーティリティを考えるのがベストプラクティスなのかなyuki_minoh.icon 更新の手間といっても、PCでterminalを立ち上げるのとbundleしてから自分のprojectに貼り付けるくらいですtakker.icon
なるほどyuki_minoh.icon*2
そのへんコード書く側だけじゃなくて使う側としてもベストプラクティスなんでしたっけ
あんま整理ついてないけど
「不特定多数が編集できる場所に非可読形式のソースをおかない」というふうに気を付けていればいいのか
きづかないうちにすごいいっぱい経験談がある。。。！
めっちゃ多いｗ
予想してたよりぜんぜん多かった
teyoda7.icon
いいなあtakker.icon
yuki_minoh.icon/icons/fastparrot.icon
悲しみの41番.icon
この先両者を間違える未来が見える
ざっと見出しだけ見てますが、これどういう視点でお読みになってるんですか？yuki_minoh.icon
要点とかあればぜひお聞きしたいですね
maichan.icon