追加ボタンを押してもパーマリンクが作成されません。

せっかくCIまわるようになったのでバッジを

https://circleci.com/docs/ja/2.0/status-badges/

target="_blank"を使っている箇所がいくつかありますが、target="_blank"はrel=”noopener”とセットで使うべきかと思います。

README.md のリンク先が生みの親のリポジトリになっているので、それ含め記述を直したいです。

2020/01/13 10:45 現在

• リンク先が親リポジトリになっている → de45963 で修正済み
• Origin は @hidao80 さんである旨を盛り込む
• その他 → 緩募

PR #86 で対応＆マージ済み

コントリビューターのためのガイドライン

CONTRIBUTING.md をルートに設置してはどうでしょう？

リポジトリコントリビューターのためのガイドラインを定める

プロジェクトに人々がどのようにコントリビュートするべきかを伝えるガイドラインを作成できます。

^{（『リポジトリコントリビューターのためのガイドラインを定める』 @ GitHub ヘルプより）}

ATOM のガイドラインのようなガチマッチョなものでなくて、ブランチの役割やプルリクエスト（以下 PR）先くらいのもので良いと思うのです。

👍×3 or 5項目くらい挙がったら叩き台を作って master に PR したいと思います。

▼ 2020/01/11 16:30 更新

進捗

• コミット 7b96b0e で CONTRIBUTING.md を設置 & Close

議題

• 1. Linter をどうするか【済】
  • JS には Linter は必要ではないか？
    → #50 で ESLint の CI を実装済み。
• 2. 基本ブランチをどうするか【済】
  • そもそも feature-dev と design-dev にわける必要はあるのか？
    → 今後は gh-pages と master の２本立てブランチにする。
• 3. 作業ブランチ名の命名ルール【済】
  • そもそもブランチに命名ルールを設ける必要があるか
    → #65 で議論中（投票受付中）
    → ブランチの命名ルールは記載しない。ブランチ名よりはコミット・メッセージや PR 時の書き方の方が大事
• 4. Draft PR 時に必要なコミット【済】
  • → https://github.com/hidao80/mastogetter/issues/54#issuecomment-572872373 で議論中
    → ソースコードに概要をコメントして Draft PR を始める
• 5. コミット・メッセージの推奨する書き方
• 6. PR 時の推奨する書き方

リンク URL が長いとき、改行されず画面外まで文字列が伸びてしまう不具合があります。

https://qithub-bot.github.io/mastogetter/p.html?i=https://qiitadon.com&t=1,2,3,4,5,6,7,8,9,0
みたいなのを沢山伸ばすと、たくさんデータを取りに行きます。
ページネーションの仕組みと合わせて OR 別に何らかの対応をしてもよいかもしれません。（そもそも、そんな風に使う人がいるのかという話はあるので、課題としては劣後でよいと思いますが）

外部APIを叩いて取得したtoot（JSON）をパースしてそのまま表示していますが、エスケープ処理がされていないため悪意のあるJSONデータが返却された場合に任意のjavascriptを実行することが可能です。

Qiitadon以外のインスタンスも指定できる仕様ですので、外部データは常に危険であるという前提でエスケープ処理を行う必要があります。

xss payload : https://api.myjson.com/bins/158yga

現象

インスタンス名が https://hogedon.com のときに、トゥートID or URLに https://hogedon.com/web/statuses/012345678901234567 の形式で toot を取得すると、
その toot が他所のインスタンスの toot でも、
ユーザー名が @[email protected] に固定されてしまっています。

原因

https://github.com/hidao80/mastogetter/blob/4750bd7571272b8292050be20323bf118aa8c234/js/common.js#L96
にて、入力されたインスタンス名を表示にしようしていますが、
おそらく API レスポンスから正しい値を取得する必要があります。

ID だけコピペするのめんどい

Tootの日時が表示されるといいですね。
（急ぎませんので、お時間あるときにご検討お願いいたします）from @[email protected] 様

まとめの作成中、途中でやめたい・作成中の状態で保存したい。

from #72

現在、Toot IDについて「1.0+E18より小さければ、id の途中で url が切れたと判断してエラーに」という仕様があるが、これは誤りではないか。

反例: https://qiitadon.com/@tomoasleep/1

「まとめを読み込む」ボタン押下時にコンソールに Uncaught ReferenceError toot_ids is not defined エラーが出ます。

原因

「まとめを読み込む」ボタンの関数内で、グローバルのつもりで toot_ids を見に行っている。

https://github.com/hidao80/mastogetter/blob/1e8fadb0883761f3638fb3d0b5adb228d961731a/js/index.js#L65-L73

対策

common.js で、card_list と同じようにグローバル空間で宣言しておく。

https://github.com/hidao80/mastogetter/blob/1e8fadb0883761f3638fb3d0b5adb228d961731a/js/common.js#L1-L2

PR #40 に追い PUSH で一緒に直しておきます。

編集中のまとめリストは削除はできるけど、位置の入れ替えができない。

現象

初回作成時、プレビューしてから追加するとトゥートがドラッグ＆ドロッペないです。既存のまとめを読み込んでからだとできます。

原因

追加時の addCard() 内で appendChild() する際に attribue に draggable ＆イベントリスナーを追加していないため。

https://github.com/hidao80/mastogetter/blob/6410e904126bc8b8e3bf0bd5b91c89c610c7e879/js/index.js#L43-L52

対応策

１カード（１トゥート）の要素に以下を追加する関数を用意する。

https://github.com/hidao80/mastogetter/blob/6410e904126bc8b8e3bf0bd5b91c89c610c7e879/js/common.js#L102-L106

これにより、以下の件（#46）も対応が楽になると思います。

#mastogetter の draggable 、表示用ページの方でもモリモリ順番変えられるんだけどええんか……？
https://qiitadon.com/web/statuses/103447056096591220 @ Qiitadon より

日付・時刻は日本の時刻、日本で一般的な表記にしてほしい。

ブラウザの表示を信用しすぎたので要修正

編集画面でトゥート追加時、従来の最下部に追加していくのでなく、上部に追加していく方法にできないか。

であれば、 編集フォームのすぐ隣に追加したトゥートが表示されるので #78 の「追加したことが目視できる」ことにもなると思います。

しかし、これには条件があって #77 の順番のフリップが実装されてから意味があるのかもしれません。

また、上に足すか下に足すかの選択オプションを付けるは煩雑になるので付けたくありません。

わがままですよね。難しい。とりあえず、以下の Issue も見ながらアイデアを練っていきたいと思います。

• #76 URL 欄をクリックしたら選択状態にして欲しい
• #77 トゥートの並び順をフリップできるようにして欲しい
• #78 「トゥートを追加」したらアウトフォーカスもしくはシグナルが欲しい

現在、まとめの並びが追加順（古い→上、新しい→下）になっています。この並びを逆転フリップする機能が欲しいです。

追加順になること自体はいいのですが、TL を過去に辿りながら追加していった時に、全体の並びを逆にしたくなります。

少数ならドラッグ＆ドロップできるのですが、数が多いと並び順もわからなくなり投稿時間を見ないといけなくなります。

まぁ、「TL の一番古い順から現在にさかのぼって追加していけ」と言えば、そうなんですが。追加して見直した時に、逆の方がいいな、と思って。

Activity Pubの仕様上、Aインスタンスにいるaさんの投稿は任意のインスタンスが知っているとは限りません。

現状どのインスタンスから情報を取ることを試行するかはインスタンス名の部分に入れたたった一つのインスタンスに限定されていますが、これだとそのインスタンスが知っている投稿しか取得できないわけです。

購読(mastodon的にはフォロー)やリブログ(mastodon的にはブースト)を活用してどこか単一のインスタンスはまとめたいすべての投稿を知っている状態にしろとまとめるユーザーに求める(現状)ならそれでもいいのですが、そうでない場合は投稿ごとにどのインスタンスに問い合わせるかを保持しなくてはいけません。

ここで、permlinkに問い合わせるべきすべてのインスタンスのリストを含めなければならなくなります。

URLの長さは制限はないとはしつつも2000文字を超えるべきではないとされています。domain 名の最大長は 253文字 (RFC1035)です。つまり最悪値でわずか10の投稿をまとめただけでURLが2000文字を超えるということになります。

情報の保持をURLではなくgistなりpastebinなりどこかそういう外部サービスに依存するか鯖をたてるかしなければ現実的にはなくなります

この辺をどう考えているかお聞きしたいです。

1. どこか単一のインスタンスはまとめたいすべての投稿を知っている状態にしろとまとめるユーザーに求める(現状)
2. N個のインスタンスに問い合れば(N<9程度?)まとめたいすべての投稿を誰かは知っている状態にしろとまとめるユーザーに求める (#37 の実装は面倒くさくなりそう)(関係なかった)
3. 各投稿ごとにどのインスタンスに問い合わせるかを保持する
   1. URLで頑張る→圧倒的死
   2. 外部サービスに依存
   3. 自鯖を建てる
   4. まとめ主はMastodonの垢を持っていると仮定してTooTに必要な情報を保持する→TLが荒れる
4. その他

https://hidao80.github.io/mastogetter/ は *.github.io ドメインなので https://git.io/ の短縮 URL が使える。パーマリンクを短縮 URL で発行したらどうか。

https://git.io/Jej7j

• cURL でフォームを送信する例

curl -s -L -i https://git.io -F "url=https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103422588059240282,103422611462024633,103422832136585995,103423069795875723,103423087302441993,103423091368850281,103423137489223891,103423155290513020"

• レスポンスヘッダの Location で短縮 URL を取得できる。

$ curl -s -L -i https://git.io -F "url=https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103422588059240282,103422611462024633,103422832136585995,103423069795875723,103423087302441993,103423091368850281,103423137489223891,103423155290513020" | grep Location
Location: https://git.io/Jej7j

• パーマリンクに固有名を付ける例

$ curl -s -L \
$  -i https://git.io \
$  -F "url=https://hidao80.github.io/mastogetter/" \
$  -F "code=mastogetter" | grep Location
Location: https://git.io/mastogetter

複数のインスタンスのトゥートを1つのまとめ（仮に「スレッド」と呼ぶ）にしたい。

環境： Windows10+Chrome
確認したバージョン： バージョン1
確認時のコミットハッシュ： 1e8fadb

おそらく CSS の

	position: absolute;
	bottom: 200%;

によって画面外に吹っ飛んでいそう

https://github.com/hidao80/mastogetter/blob/1e8fadb0883761f3638fb3d0b5adb228d961731a/css/style.css#L201-L206

編集画面の「トゥートID or URL」で、URL をコピペするときに１つ前の URL があった場合、いったん全文選択 or 削除しないとペーストが差し込みになってしまう。

フィールドをクリック（フォーカス）が当たったら全文選択（ctrl+a or ⌘+a を押した）状態にして欲しい。

確認環境

Windows10 + Chrome
コミット: de45963

現象

https://qithub-bot.github.io/mastogetter/p.html で表示される toot をダブルクリックで削除できてしまう

トゥートが追加されたら input フィールドにフォーカスが戻って欲しい。

まとめ編集画面と TL の2画面で、左から右へのコピペ作業に入ると、まとめ一覧が縦にどんどん伸びて行きます。

この時、トゥートが最下部に追加されるので「あれ？今のちゃんと追加されたかな？」となる時があります。

ポンポン作業していると Qiitadon のレスポンスが一瞬遅くなる時があるのですが、私の場合、この時テンポが崩れ不安になりチェックしにスクロール作業が発生します。

無事追加されたら、何かしらのシグナルが欲しいです。色が変わるとかでも良いです。

個人的には最後に触った Input フィールドにフォーカスが戻ってくれると、まとめ作業が捗ります。

右側のまとめ一覧をインラインフレームにする要望もありますが、それはまた今度別の Issue で。

この初期 Issue には下記の２つの要件が入っていました。

1. 無事トゥートが追加されたことが目視でわかるようにして欲しい。
2. 連続でトゥートを追加するため、無事トゥートが追加されたら URL のインプットフィールドにフォーカスが当たって欲しい。

2020/01/12 現在、1 に関しては #80 (comment) の対応で網羅できそうなので、この issue では 2 について議論しています。

現在、どのブランチが皆さん的にベストな状態になっているのかわかりまてん。

https://github.com/hidao80/mastogetter/issues/54#issuecomment-572590606 の gh-pages master ２本立て化のステップとして DEV 系ブランチを削除して減量して欲しいです。

もし、その作業で消えてしまったものが出ても「消せらセラ」でまた皆んなで直すということで。

👍 ×4 以上 or @hidao さんの裁量で判断願います。

JavaScriptのProjectでは一般にcamel caseを採用することが多く、ESLintもcamelCaseであることを要求するルールはあるものの
https://eslint.org/docs/rules/camelcase#
snale_caseであることを要求するルールは存在しません。もちろんそういうpluginはあった気がしますが。

そこでcamelCaseを採用することで統一してはどうかと提案します。

ヒントの表示はラベルの横に❓アイコンみたいのを置いてそこをマウスオーバーしたときに出したりするのが一般的かなと思いました（入力するたびにヘルプが出るのはつらい）by まちカドまえかわ さん

「追加」ボタンのラベルを「プレビューを追加」にするべき。

オムニボックス化すれば、レイアウトもすっきりするのではないか

ユーザ名をクリックしたらユーザページへ飛んでほしい。
今はユーザ名にリンクが貼られていない。

#54 の「CONTRIBUTING.md のファイルの設置」とは関係がないので新たに本 Issue を立てました。

議題

以下をこの Issue で議論にしたいと思います。

1. そもそも作業ブランチ名に命名ルールを設ける必要があるのか
2. 設ける場合は「ブランチの命名ルール」

議題 1 に関しては以下のリアクションでお願いします。

（× 5 以上 or 土曜 01/11 の昼の最多で決定です） 👍= 0 で「作業ブランチの命名ルールは必要なし」となりました。（2020/01/10 18:20）

👍 = 設けた方がいい
👎 = 設けなくてもいい
👀 = 見つめていたい
🚀 = がんばってモチベあげて
🎉 = パーリーピーポー
😕 = そのノリも意味もよくわかりません

叩き台の初回内容と意図

叩き台では、「推奨」するスタイルとして以下をあげました。（hidao80@18a5930#diff-6a3371457528722a734f3c51d9238c13R32-R43 より）

• 推奨するブランチ名の付け方（[] は任意です）
  • issue-<Issue番号>-<担当者名>[-<作業概要>]
    • 特定 Issue の対応を行う。
    • Issue の一部の作業である場合は、作業の概要がわかる名前を付けてください。
  • issue-<Issue番号>[-<作業概要>]
    • 担当者名を付けない場合は「他のコラボレーターからも差し込みをして欲しいブランチ」である意味になります。
    • Issue の一部の作業である場合は、作業の概要がわかる名前を付けてください。
  • typo-<担当者名>
    • 単純な誤字脱字の修正する。
  • refactor-<担当者名>[-<対象>]
    • リファクタリングをする。
      • 特定ファイルのリファクタの場合は、対象がわかる名前を付けてください。

叩き台で「ブランチ名に担当者名はいらないのではないか」という意見 https://github.com/hidao80/mastogetter/pull/64#issuecomment-572845728 をいただきました。実は、叩き台に間違いがありまして、担当者名は任意のつもりでした。

- `issue`-`<Issue番号>`-`<担当者名>`[-`<作業概要>`]
+ `issue`-`<Issue番号>[`-`<担当者名>`-`<作業概要>`]

この <担当者名> を付ける・付けないですが、

1. <担当者名> あり：「作業ブランチへの他者コミットを希望している」という意思表示
2. <担当者名> なし：「レビューまで俺にまかせておくれ」

にしたいと考えました。

基本的に「PR を投げた人が１人で作業するもの」というのはわかっています。しかし LTL や今までのやりとりを見て、このリポジトリにおいては以下を念頭におかないといけないと思います。

• GitHub でコラボったことない
• 作業フローが各々慣れたものと違う
• コミット履歴をトレースするの面倒
• 本業もあるので、なかなか PR を仕上げられない
• 叩き台は作ったからあとは任せた
• ちっ何やってんだよ。俺にやらせてみな。ほらよっ。じゃな
• 進捗確認箇所が多い（ LTL, 特定トゥートのスレッド, Issue など）

そういう意味で、「ブランチ名を一見して条件がわかるといいのに」と思い、叩き台に記載しました。

ただ ... ここまで書いておいて何ですが、ブランチ名よりは PR 時のタイトルの方が大事なんじゃね？と思ってきました。本文に「途中コミットキボンヌ」と書いておけばいいんだし。ブランチ名いらないってそういうことだったのか。とほほ。とりあえず土曜の夜まで意見募集お昼に決定しまーす。

症状: まとめを複数回読み込んで、permalinkをコピーすると、最後に読み込んだまとめと同じものになる。(すでに存在しているtootが存在しないかのように振る舞う)

原因: まとめを読み込むと、リストの後ろに追加されるけれど、
permalink的には、既存のものがなかったことになって、読み込んだものだけになってしまっている。

対策:

• 読み込んだ際に表示を一旦クリアし、仕様とする。
• card_list に読み込んだ toot_ids を追加する。

URL から物理的に id を消す方法で削除できなくは無いですが、
編集ページで削除ができるようになってほしい。

追加された toot が最下段に追加されるため、目視で追加されたかがわかりにくく、
複数回同じ toot を追加してしまったので。

入力画面のまとめ欄にある項目を削除するのはダブルクリックのほうが安全ではないか。

file://だとCORSとかの関係で扱いに困るので適当なlocal serverを選出したほうがいいのではないかと思いました

ref:

• https://twitter.com/yumetodo/status/706071299508973568
• https://qiitadon.com/@blhsrwznrghfzpr/103456997228914696

候補としては

• https://www.npmjs.com/package/koko
• https://www.npmjs.com/package/@js-primer/local-server

など？webpack使ってないので軽量なやつで十分ですし。(後者のほうがメンテされていそう)

npm scriptを書いてnpm run startとかするとブラウザで見れるようにするのをイメージしてます。

ページネーションしないため、件数が多いまとめを見るときは初期ロードに時間がかかる。
また、全件一括取得した場合、サーバに負担がかかる。

netlify.comを使うとPRに対して自動的にpreview用のWeb siteを作ってくれる。
例としては
asciidwango/js-primer#1005
というPRに対してbot-userが生成完了を教えてくれて
https://deploy-preview-1005--js-primer.netlify.com/
みたいにPR番号を含むURLを吐いてくれる。

レビューしやすくなるのではないか。

コミット 241b81d の時点で、パーマリンクの URL が絶対パスになっています。

MIT であるため派生 mastogetter も生まれる可能性もありますし、何よりローカルで確認する際にドメインのベース部分をローカルに書き換える必要もあります。

• 参考： https://qiitadon.com/web/statuses/103462233615180595

提案

• パーマリンクの URL のベースを、現在開いている URL のものにする。

CircleCI をパスして、レビューに n 件の LGTM（Approve）が付いたら、もぅ強制的に master にマージさせたい。 （👍 ×3 以上で可決）

また、Approve できるレビューアーはコラボレーター（リポジトリ大臣）に限定せず、コントリビューター（ユーザー）も参加できるようにする。

• GitHub で CI をパスしたら自動的にマージさせたい。 @ Qiita
• Github レビューでの Approve / Request Changes / Comment の使い方 @ Qiita

P.S.
リリース（master を gh-pages にマージ）するタイミングは、コラボレーターの多数決で適宜行うこととする。可能なら、これも自動化につなげていきたい。

入力画面のフォームに対してスタイルを指定していないため、デザインが冴えないのを改善したい。

サイト内にまとめを埋め込むために、コンテンツだけを取得できるREST APIが欲しい。

入力画面のまとめ欄で、カードの移動ができないのはつらすぎる。

#10 の副作用に気づいてませんでした。

プレビュー画面のカードまで順番入れ替え可能になっているのを止めます。

@hidao80 が対応中です。💪

ついでに表示されているまとめのURLを読み込みフォームに突っ込んでおいてくれるとなおよし。

トゥートのIDやURLが入力されたときに「埋め込みカードのプレビュー」がシュッと表示されると良さそう。都度プレビューのボタンを押すのは面倒なので。

#62 (comment)
話がそれますが互換性破壊せずともget paramの名前変えれば済んだのでは・・・？

と書いたのですが、get paramの名前変えるまでもなく互換性を維持できると思ったのでIssue立てました。

現状Get Paramは

• i: instance 名
• t: Toot id の配列(,区切り)

となっていると思うのですがv2で互換性を破壊したのは

つまり、まとめの表示とまとめ作成時の読み込み機能については両対応し、新規生成は36進数変換に変更すれば互換性は壊れていないものと思います。

Google検索にかけた感じ、v2は使われてる形跡がないので削除し、上記の様に統合しませんか？

TL;DR

発行済みパーマリンクに追加されまてん。

• Chrome v79.0.3945.88, macOS Mojave

TS;DR

再現方法

https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103422588059240282,103422611462024633,103422832136585995,103423069795875723,103423087302441993,103423091368850281,103423137489223891,103423155290513020,103423839710682996

上記パーマリンクを、ますとげったーの「パーマリンク読込」に貼り付け、追加したいトゥート
https://qiitadon.com/web/statuses/103433642368719830
を「トゥートID or URL」に貼り付けました。

「プレビュー」でちゃんと表示されたので、「プレビュー中のトゥートを追加」したところ、右側ペイン（トゥート一覧）の最後尾に追加されました。

しかし、右側ペイン上部にある「パーマリンク」の input フィールドが最後に追加したトゥート ID のみになってしまいます。

https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103433642368719830,

２連続「プレビュー中のトゥートを追加」を押下すると、同じトゥートが追加されるので、リセットして追記しているわけではないようです。

https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103433642368719830,103433642368719830,

「パーマリンク読込」の「読込」ボタン押下時は、右側ペイン上部の input フィールドに既存のパーマリンクは流し込まれているようなので、初回「プレビュー中のトゥートを追加」時に消えてしまいます。

考えられる原因

おそらく、パーマリンク読込ボタンの loadPermalink() 時に genPermalink() でパーマリンク作成後、toot_list もちくは card_list に追加していないからなのかな、と思います。

https://github.com/hidao80/mastogetter/blob/435b615222fe9a606bf15fff8469ee55aa567726/js/index.js#L81-L126