qithub-bot / mastogetter Goto Github PK
View Code? Open in Web Editor NEW✅ togetter for Mastodon.
Home Page: https://qithub-bot.github.io/mastogetter/
License: MIT License
✅ togetter for Mastodon.
Home Page: https://qithub-bot.github.io/mastogetter/
License: MIT License
現在、どのブランチが皆さん的にベストな状態になっているのかわかりまてん。
https://github.com/hidao80/mastogetter/issues/54#issuecomment-572590606 の gh-pages
master
2本立て化のステップとして DEV
系ブランチを削除して減量して欲しいです。
もし、その作業で消えてしまったものが出ても「消せらセラ」でまた皆んなで直すということで。
👍 ×4 以上 or @hidao さんの裁量で判断願います。
Activity Pubの仕様上、Aインスタンスにいるaさんの投稿は任意のインスタンスが知っているとは限りません。
現状どのインスタンスから情報を取ることを試行するかはインスタンス名の部分に入れたたった一つのインスタンスに限定されていますが、これだとそのインスタンスが知っている投稿しか取得できないわけです。
購読(mastodon的にはフォロー)やリブログ(mastodon的にはブースト)を活用してどこか単一のインスタンスはまとめたいすべての投稿を知っている状態にしろとまとめるユーザーに求める(現状)ならそれでもいいのですが、そうでない場合は投稿ごとにどのインスタンスに問い合わせるかを保持しなくてはいけません。
ここで、permlinkに問い合わせるべきすべてのインスタンスのリストを含めなければならなくなります。
URLの長さは制限はないとはしつつも2000文字を超えるべきではないとされています。domain 名の最大長は 253文字 (RFC1035)です。つまり最悪値でわずか10の投稿をまとめただけでURLが2000文字を超えるということになります。
情報の保持をURLではなくgistなりpastebinなりどこかそういう外部サービスに依存するか鯖をたてるかしなければ現実的にはなくなります
この辺をどう考えているかお聞きしたいです。
Windows10 + Chrome
コミット: de45963
https://qithub-bot.github.io/mastogetter/p.html
で表示される toot をダブルクリックで削除できてしまう
ついでに表示されているまとめのURLを読み込みフォームに突っ込んでおいてくれるとなおよし。
CONTRIBUTING.md をルートに設置してはどうでしょう?
リポジトリコントリビューターのためのガイドラインを定める
プロジェクトに人々がどのようにコントリビュートするべきかを伝えるガイドラインを作成できます。
(『リポジトリコントリビューターのためのガイドラインを定める』 @ GitHub ヘルプより)
ATOM のガイドラインのようなガチマッチョなものでなくて、ブランチの役割やプルリクエスト(以下 PR)先くらいのもので良いと思うのです。
👍×3 or 5項目くらい挙がったら叩き台を作って master
に PR したいと思います。
▼ 2020/01/11 16:30 更新
feature-dev
と design-dev
にわける必要はあるのか?gh-pages
と master
の2本立てブランチにする。入力画面のフォームに対してスタイルを指定していないため、デザインが冴えないのを改善したい。
https://hidao80.github.io/mastogetter/ は *.github.io
ドメインなので https://git.io/ の短縮 URL が使える。パーマリンクを短縮 URL で発行したらどうか。
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
日付・時刻は日本の時刻、日本で一般的な表記にしてほしい。
発行済みパーマリンクに追加されまてん。
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,
2連続「プレビュー中のトゥートを追加」を押下すると、同じトゥートが追加されるので、リセットして追記しているわけではないようです。
https://hidao80.github.io/mastogetter/p.html?i=https://qiitadon.com&t=103433642368719830,103433642368719830,
「パーマリンク読込」の「読込」ボタン押下時は、右側ペイン上部の input フィールドに既存のパーマリンクは流し込まれているようなので、初回「プレビュー中のトゥートを追加」時に消えてしまいます。
おそらく、パーマリンク読込ボタンの loadPermalink()
時に genPermalink()
でパーマリンク作成後、toot_list
もちくは card_list
に追加していないからなのかな、と思います。
#62 (comment)
話がそれますが互換性破壊せずともget paramの名前変えれば済んだのでは・・・?
と書いたのですが、get paramの名前変えるまでもなく互換性を維持できると思ったのでIssue立てました。
現状Get Paramは
i
: instance 名t
: Toot id の配列(,区切り)となっていると思うのですがv2で互換性を破壊したのは
Lines 118 to 131 in 241b81d
_
を含めば36進数変換処理が入っていると区別ができるので単にその処理を追加すればよかったはずです。
つまり、まとめの表示とまとめ作成時の読み込み機能については両対応し、新規生成は36進数変換に変更すれば互換性は壊れていないものと思います。
Google検索にかけた感じ、v2
は使われてる形跡がないので削除し、上記の様に統合しませんか?
症状: まとめを複数回読み込んで、permalinkをコピーすると、最後に読み込んだまとめと同じものになる。(すでに存在しているtootが存在しないかのように振る舞う)
原因: まとめを読み込むと、リストの後ろに追加されるけれど、
permalink的には、既存のものがなかったことになって、読み込んだものだけになってしまっている。
対策:
追加ボタンを押してもパーマリンクが作成されません。
サイト内にまとめを埋め込むために、コンテンツだけを取得できるREST APIが欲しい。
URL から物理的に id を消す方法で削除できなくは無いですが、
編集ページで削除ができるようになってほしい。
追加された toot が最下段に追加されるため、目視で追加されたかがわかりにくく、
複数回同じ toot を追加してしまったので。
せっかくCIまわるようになったのでバッジを
ヒントの表示はラベルの横に❓アイコンみたいのを置いてそこをマウスオーバーしたときに出したりするのが一般的かなと思いました(入力するたびにヘルプが出るのはつらい)by まちカドまえかわ さん
#54 の「CONTRIBUTING.md のファイルの設置」とは関係がないので新たに本 Issue を立てました。
以下をこの Issue で議論にしたいと思います。
議題 1 に関しては以下のリアクションでお願いします。
(× 5 以上 or 土曜 01/11 の昼の最多で決定です) 👍= 0 で「作業ブランチの命名ルールは必要なし」となりました。(2020/01/10 18:20)
👍 = 設けた方がいい
👎 = 設けなくてもいい
👀 = 見つめていたい
🚀 = がんばってモチベあげて
🎉 = パーリーピーポー
😕 = そのノリも意味もよくわかりません
叩き台では、「推奨」するスタイルとして以下をあげました。(hidao80@18a5930#diff-6a3371457528722a734f3c51d9238c13R32-R43 より)
[]
は任意です)
issue
-<Issue番号>
-<担当者名>
[-<作業概要>
]
issue
-<Issue番号>
[-<作業概要>
]
typo
-<担当者名>
refactor
-<担当者名>
[-<対象>
]
叩き台で「ブランチ名に担当者名はいらないのではないか」という意見 https://github.com/hidao80/mastogetter/pull/64#issuecomment-572845728 をいただきました。実は、叩き台に間違いがありまして、担当者名は任意のつもりでした。
- `issue`-`<Issue番号>`-`<担当者名>`[-`<作業概要>`]
+ `issue`-`<Issue番号>[`-`<担当者名>`-`<作業概要>`]
この <担当者名>
を付ける・付けないですが、
<担当者名>
あり:「作業ブランチへの他者コミットを希望している」という意思表示<担当者名>
なし:「レビューまで俺にまかせておくれ」にしたいと考えました。
基本的に「PR を投げた人が1人で作業するもの」というのはわかっています。しかし LTL や今までのやりとりを見て、このリポジトリにおいては以下を念頭におかないといけないと思います。
そういう意味で、「ブランチ名を一見して条件がわかるといいのに」と思い、叩き台に記載しました。
ただ ... ここまで書いておいて何ですが、ブランチ名よりは PR 時のタイトルの方が大事なんじゃね?と思ってきました。本文に「途中コミットキボンヌ」と書いておけばいいんだし。ブランチ名いらないってそういうことだったのか。とほほ。とりあえず土曜の夜まで意見募集お昼に決定しまーす。
「追加」ボタンのラベルを「プレビューを追加」にするべき。
Tootの日時が表示されるといいですね。
(急ぎませんので、お時間あるときにご検討お願いいたします)from @[email protected] 様
ユーザ名をクリックしたらユーザページへ飛んでほしい。
今はユーザ名にリンクが貼られていない。
CircleCI をパスして、レビューに n
件の LGTM(Approve
)が付いたら、もぅ強制的に master
にマージさせたい。 (👍 ×3 以上で可決)
また、Approve できるレビューアーはコラボレーター(リポジトリ大臣)に限定せず、コントリビューター(ユーザー)も参加できるようにする。
P.S.
リリース(master
を gh-pages
にマージ)するタイミングは、コラボレーターの多数決で適宜行うこととする。可能なら、これも自動化につなげていきたい。
初回作成時、プレビューしてから追加するとトゥートがドラッグ&ドロッペないです。既存のまとめを読み込んでからだとできます。
追加時の addCard()
内で appendChild()
する際に attribue
に draggable
&イベントリスナーを追加していないため。
1カード(1トゥート)の要素に以下を追加する関数を用意する。
これにより、以下の件(#46)も対応が楽になると思います。
#mastogetter の draggable 、表示用ページの方でもモリモリ順番変えられるんだけどええんか……?
https://qiitadon.com/web/statuses/103447056096591220 @ Qiitadon より
編集中のまとめリストは削除はできるけど、位置の入れ替えができない。
https://qithub-bot.github.io/mastogetter/p.html?i=https://qiitadon.com&t=1,2,3,4,5,6,7,8,9,0
みたいなのを沢山伸ばすと、たくさんデータを取りに行きます。
ページネーションの仕組みと合わせて OR 別に何らかの対応をしてもよいかもしれません。(そもそも、そんな風に使う人がいるのかという話はあるので、課題としては劣後でよいと思いますが)
ID だけコピペするのめんどい
target="_blank"を使っている箇所がいくつかありますが、target="_blank"はrel=”noopener”とセットで使うべきかと思います。
JavaScriptのProjectでは一般にcamel caseを採用することが多く、ESLintもcamelCaseであることを要求するルールはあるものの
https://eslint.org/docs/rules/camelcase#
snale_caseであることを要求するルールは存在しません。もちろんそういうpluginはあった気がしますが。
そこでcamelCaseを採用することで統一してはどうかと提案します。
外部APIを叩いて取得したtoot(JSON)をパースしてそのまま表示していますが、エスケープ処理がされていないため悪意のあるJSONデータが返却された場合に任意のjavascriptを実行することが可能です。
Qiitadon以外のインスタンスも指定できる仕様ですので、外部データは常に危険であるという前提でエスケープ処理を行う必要があります。
xss payload : https://api.myjson.com/bins/158yga
現在、まとめの並びが追加順(古い→上、新しい→下)になっています。この並びを逆転フリップする機能が欲しいです。
追加順になること自体はいいのですが、TL を過去に辿りながら追加していった時に、全体の並びを逆にしたくなります。
少数ならドラッグ&ドロップできるのですが、数が多いと並び順もわからなくなり投稿時間を見ないといけなくなります。
まぁ、「TL の一番古い順から現在にさかのぼって追加していけ」と言えば、そうなんですが。追加して見直した時に、逆の方がいいな、と思って。
netlify.comを使うとPRに対して自動的にpreview用のWeb siteを作ってくれる。
例としては
asciidwango/js-primer#1005
というPRに対してbot-userが生成完了を教えてくれて
https://deploy-preview-1005--js-primer.netlify.com/
みたいにPR番号を含むURLを吐いてくれる。
レビューしやすくなるのではないか。
オムニボックス化すれば、レイアウトもすっきりするのではないか
環境: Windows10+Chrome
確認したバージョン: バージョン1
確認時のコミットハッシュ: 1e8fadb
おそらく CSS の
position: absolute;
bottom: 200%;
によって画面外に吹っ飛んでいそう
file://だとCORSとかの関係で扱いに困るので適当なlocal serverを選出したほうがいいのではないかと思いました
ref:
候補としては
など?webpack使ってないので軽量なやつで十分ですし。(後者のほうがメンテされていそう)
npm scriptを書いてnpm run start
とかするとブラウザで見れるようにするのをイメージしてます。
ページネーションしないため、件数が多いまとめを見るときは初期ロードに時間がかかる。
また、全件一括取得した場合、サーバに負担がかかる。
複数のインスタンスのトゥートを1つのまとめ(仮に「スレッド」と呼ぶ)にしたい。
インスタンス名が 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 レスポンスから正しい値を取得する必要があります。
入力画面のまとめ欄にある項目を削除するのはダブルクリックのほうが安全ではないか。
リンク URL が長いとき、改行されず画面外まで文字列が伸びてしまう不具合があります。
トゥートが追加されたら input
フィールドにフォーカスが戻って欲しい。
まとめ編集画面と TL の2画面で、左から右へのコピペ作業に入ると、まとめ一覧が縦にどんどん伸びて行きます。
この時、トゥートが最下部に追加されるので「あれ?今のちゃんと追加されたかな?」となる時があります。
ポンポン作業していると Qiitadon のレスポンスが一瞬遅くなる時があるのですが、私の場合、この時テンポが崩れ不安になりチェックしにスクロール作業が発生します。
無事追加されたら、何かしらのシグナルが欲しいです。色が変わるとかでも良いです。
個人的には最後に触った Input フィールドにフォーカスが戻ってくれると、まとめ作業が捗ります。
右側のまとめ一覧をインラインフレームにする要望もありますが、それはまた今度別の Issue で。
この初期 Issue には下記の2つの要件が入っていました。
2020/01/12 現在、1 に関しては #80 (comment) の対応で網羅できそうなので、この issue では 2 について議論しています。
まとめの作成中、途中でやめたい・作成中の状態で保存したい。
from #72
現在、Toot IDについて「1.0+E18より小さければ、id の途中で url が切れたと判断してエラーに」という仕様があるが、これは誤りではないか。
入力画面のまとめ欄で、カードの移動ができないのはつらすぎる。
トゥートのIDやURLが入力されたときに「埋め込みカードのプレビュー」がシュッと表示されると良さそう。都度プレビューのボタンを押すのは面倒なので。
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.