外的要因、自分の中から生まれる動機じゃないものがインセンティブ？（言葉があってるのかわからないし理解もあってるかわからない）
外的要因、自分の中から生まれる動機じゃないものがインセンティブ？（言葉があってるのかわからないし理解もあってるかわからない）
nginxでlocalhostをupstreamにしてたらresolverで::1:3000にされて困ったってやつをそのままやらかしてエラーログたまりまくってたなの（6時間前に直した）
Pleromaはデフォ5000で自由に変えられる設定なのよね。5000文字も何を書き込むというのか
@mimikun configファイル的なのにもそういうのはない感じ？（最近変わったenvでソースコードのリポジトリ変更できるような感じで
これ何
/socket/websocket?token=undefined&vsn=2.0.0
homebrew-cask、PRでTravisCI走るのでテンプレートのauditとstyleをそこに任せていくスタイル
QUIC対応Webサーバー
- caddy
- litespeed
どっちがいいんだろう
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
sort、re-orderぐらいの感覚だけどわざわざ別の単語になってるから違うんだろうなぁ…うーんみたいな
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
nginxでUDPはまぁ無理だろうなぁってIssueみて思ってるのでcaddy使いたい…となることはある
This account is not set to public on notestock.
これめっちゃわかるになってる（skipすればいいに気がつくまでの無駄になる時間）
https://don.inux39.me/users/inux39/statuses/102048552828121656
This account is not set to public on notestock.
This account is not set to public on notestock.
やっぱaccountのfullユーザーネーム、一意だし_idに入れる方がいいんじゃないかってなってる
fetchしてマージコミットでmergetool使えば大抵なんとかなる。なんとかなるし見栄えも綺麗になると思う（なおbackportのhashが違うコミット
님의 게시물
mayaeh@taruntarun.net
This account is not set to public on notestock.
どこかでpullじゃなくてfetch/mergeしろみたいな話見てからちょっと警戒してるんだけどあまりそうじゃない人が多いのかな＞git pullして更新する
（たまにmasterブランチも消してupstream/masterとupstreamのtagだけ追ってるんだけどこれどうなんだろう）
This account is not set to public on notestock.
TheDesk Vue、NeDBのIDを使うとしてカラムの順番をどう並べるかとなてり
せっかくなので本家に寄与するのが一番だと思うけどあえて本家とは違う機能とか実装しようとするなら本家のレポジトリをGit submoduleに入れて管理するのはどうでしょう
RE: https://dtp-mstdn.jp/users/noellabo/statuses/102048101167023152
いうのが私の運用だけどremoteが複数あると管理めんどくさいところあるかもなぁみたいな
upstreamをわざわざmasterに取っておく意味はあんまりないと思うからremoteにupstream追加してgit fetch --allすればいいかなぁって
This account is not set to public on notestock.
error.logにconnection refused出てるなぁって昨晩ボケーっとしてたらlocalhostでproxy_pass設定してた。無駄なエラー発生させてたよ…
いま、一気に知見が集まったけど、LTLチャットじゃなくて見事に連合を跨いでやってるから、分散してるんだよね。全然良い意味じゃなくて……。
私がブーストした分は拾えているかもしれないけど。
勢いで実装していったらいつの間にかとっちらかってヤベェブランチ設計失敗した…とはなったが遅かった
まぁ他のパッケージマネージャの方がまだマシなので消耗することは間違いないなぁというか
go modulesはgemみたいなイメージ
それ以前の管理は…やったことがないので想像だけどsrcで管理しないといけないの地獄じゃん…とか思う
This account is not set to public on notestock.
以前、PHP製のデータベース管理アプリケーションAdminerにテーブルを横スクロール可能にするPR開いて、マージされたというかRebaseで実装されたというかみたいな感じになったんですが、実装後に通常マウスのWindowsではすごく不便ってなってRevertというかスクロールはデフォルトで向こうになったんですよね
なのでスクロール系を弄るの何もわからないってなってる
This account is not set to public on notestock.
歴戦の鯖缶たちで、これっしょ常考、とか定番が定まらないのに、見よう見まねで更新の度に死にそうな（時々死ぬ）鯖缶勢、どうやってgit使っていけばいいのか……。
ぜんぜんわからない。俺たちは雰囲気でgitをやっている。
notestockの公開ページにあるここのリンクを開くと、その付近が開くようになっていて話の流れが分かりやすくなってるんですよー。後者のリンクは、以下のgreasemonkeyスクリプトで。 https://github.com/osapon/mastodon2notestock
あー機能ごとに最新とかタグに合わせてrebaseとかマージコミットすればその機能ブランチを最新に適用させ続けられるのか（青天の霹靂）（誇張表現）
まあURLを併記したエアリプならまだましかな， 
だと"なぜか"通知が言ってしまうので使いにくいが丼ではそんなこともないので気兼ねなく使える
Gitのフロー、すでにあるやつ同士で論争が発生することもある気がするからこれっていう一つの方法はないような気がする
直リプ，ためらいが生じるので使いにくいたしかにそれはそうだけど，いざ自分がエアリプされる段になると，文脈見えなくなるのでできるだけメンションするようにしてる（つもり）
タグのマージはなぁブランチ違えばcherry-pickのrebase混じりになるからしんどいだろうなぁ…うーん
自分のブランチにmergeしてくの、アップストリームをmasterにしてるから楽なのかもしれない。タグをmergeしてくとコミットが巻き戻ったりあるかもだね。
おひとりさまやってBT後の言及は繋がってないと見られないということに初めて気がつくなどしてた
そもそも検索しやすいってわけじゃないからやっぱタグつけないと（私にタグ付けの意識が低すぎてア）
こういう、わりとみんなが興味ありそうな話題だというのに、エアリプばかり。
言及を収集するとなると大変だし、みんなお互いのコメント読めなくてみんな不便じゃないの？
これってトリビアになりませんか？
今は活発じゃないけどイメージとしてはpawoo.netのブランチ設計は参考になるとこあるんじゃないかな
晩御飯レシピ開発
master: 今までの蓄積。とても良いレシピの集合
trial/etc: レシピ開発。新しいレシピの提案
→PRでレビュー（値段とか？わからない）してよくないレシピはリジェクト
なるほど出来そう（？）
This account is not set to public on notestock.
さて、こんなこと言ったわけなんですがTheDesk Vueのブランチは一本で開発してます。意味がわかるな？
開発のためのフローは本当に効率化して機能の追加をしやすくする指針だからちょっとしたコード変更を公開したり維持するのもやっぱりそれを意識した方が楽
機能ごとにブランチ切るのはどれをどこまでやったかみたいなことを明確にするので…
いろんな変更をごちゃ混ぜにしながら一つのブランチで維持するのはとっ散らかるだけだからその雰囲気のフローは消耗しそう
貢献するときは自分用のmainブランチは要らんからfeatureブランチとか切ってるけど
追加した機能や変更のブランチ名を切って自分用のmainブランチへマージ（GitHubのPRとかGitLabのMRで番号つけて管理すると楽？）してからバージョン上がる度にmainブランチへマージするのが普通にわかりやすいフローだと思うんだけど
普通にpatchブランチか自分の適用するドメインのブランチ切ってupstream/masterとかorigin/masterとかマージしていけばいいのでは
Mastodonにしても、PleromaもMisskeyもみんなそうだけど、gitで最新版のソースをとってくるじゃん？ 運用のために。（開発じゃなくて）
で、.gitignoreで管理対象外にしてある設定ファイルはともかく、やっぱりちょっとソースコードいじることあると思うんだけど、いじった時に、それをどのように公開したり、維持していったらいいか、こうやればいいよ！ってのある？
GitFlowとかGithubFlow、GitLabFlow、みんな開発のためのフローなのよね。
圧倒的な物量の本家の開発成果を利用し、更新に追従しながら、どこかから借りてきた改造と、自分のあてた小さなパッチ（コミット）を維持していくだけのフロー、だれか提案してない？
（私も色々考えてやっているけど、再発明してもしょうがないので）
これにコメント付いてたけど「は？」である
https://git.pleroma.social/pleroma/pleroma/issues/852
いやまぁ参照してるWIPリクエストで問題なくなるんだろうけど実装するならはよして
pleromaのコマンドはdocs-developのmix tasksみればいいんだろうけどそこに書いてあるコマンドが少なすぎて他にないんか…？ってなる
勝手に消えるもんだと思ってたのが消えなくて正直びっくりしてる。mastodonでも残ってるとしたら人の鯖でプロフ画像変えるの絶対躊躇する
GravatarとかGoogle+みたいに過去のプロフィール画像から再選択できるみたいな仕組みなら残っててもいいしそこに削除するUI用意すればいいと思うんだけど
投稿に紐づく画像とかはまぁいいんだけどプロフ画像とか(今のUIだと)絶対再利用しないんだし消える方が助かる
（間違えてあげた2M超えの背景画像が消えてなくて5秒くらい考えた結果cat /dev/nullで上書きする暴挙）
プロフィール画像とかバナーとか背景とか、変更しても未使用のまま残ってるのをどうやって整理するのかなって
っていうのをここ2-3日調べてるけど調べ方が悪いから答えの得られるIssueにたどり着いてない
ConoHaは初期状態でUbuntu19.04使わせてくれないのかな。まぁ初手アップグレードでもいいんだけど
フォロワーがいっぱいいるユーザーが、自分のフォロー範囲内を世界の全てのように勘違いして代表ぶってるのはTwitterでいくらでも見かけた光景だけど、丼だと最初からLTLが見えるので、フォロー/フォロワーを増やすまでもなく任意のユーザーが代表ぶれる可能性ある。
サーバーからプログラミング始めるとある程度のWebサーバーインフラとかで自己処理できるのわかる
自分、サーバーからプログラミング始めてる(PHP)から、Nginxとかcertbotとかデータベースとかでやらかしても何とか自己処理できて今の所cutls.comを既存リソースだけで建てられてるけども
今でこそリレーがあるけど、1人1鯖だとLTLは使い物にならないしFTLもはじめのうちは使い物にならないからハードル高すぎるとおもうんだよね
apt update、定期的にしてるか知らんけどmot.dがログイン時に更新可能なパッケージ数表示してるなぁみたいな
TypeScript、interfaceにgoみたいに変数つけられない…？（何を言ってるんだ
;はただの改行だから実行される。&&はexit code 0のみ次に行く
shell scriptで複数行の&&みたいなことするときは$?で制御する
This account is not set to public on notestock.
ここで昔話なんですが、Mastodonが流行る前、Misskey民の間でちょっとだけGNU Socialが話題になったことがあるんですよ。私はGNU Socialの連合に感銘を受けてMisskeyにもああいう連合の仕組みを入れようとか言ってたんですが(皆さんご存知の通りOStatusは非常に難解なので誰も実装できる人間がおらず実現されることはなかった)、まさか日本でこんなにGNU Socialを基とした連合SNSが流行るとは思ってなかった。その点ではあの頃の俺はいい線いってたのかもしれない。
ぷれろま、とくに弄らずにやってるのでリモートメディアが保存されない。いいのか悪いのか
/etc/nginx/nginx.confにあるuserディレクティブで指定されてるユーザーをオーナーにしてグループをrootにしてあげるとnginxの方は解決しそうだけどどうだろう
（Powerline、python版よりgoのやつ使いたいけどVPSのやつだからあんまり手が回ってないのよね…）
This account is not set to public on notestock.
そう言えばgroupで権限もらえるみたいなことをわかってない頃にnginxサーバー建てた名残で
user <loginユーザー名> <loginユーザー名>
ってなってるのめっちゃ恥ずかしい
@toneji アクセスログ側が06/May/2019:02:00:00 +9000、エラーログ側が2019/05/06 02:00:00みたいになってたので
@Cutls pawooからの/push/subscriptions/2で500出まくってて🤔ってなってた
公式のやつ改造せずに使うならbuildフィールドをcomposeから消して使うのすごい快適そうなんだけど誰もやってなさそうよね
This account is not set to public on notestock.
@Cutls vim して
"/ 500 "
とかで見つからんのよね。そう言えばステータスエラーじゃなくて時間でしか探したことないなとか
そう言えばtootsuite/mastodonがdocker hubに上がってたりせんのって思ったりしてた
@Cutls なんかうちのerror.log、111: Connection refusedばっか書いてある(´・ω・`)
nginxで複数の仮想ホストでエラーログ指定してたら/var/log/nginx/error.logほとんど書き込まれてない(´・ω・`)
前mastodon建てて画像うp出来なかった時はmastodon側でpermission deniedしてて422？が帰ってたからあまり参考にならない
webuiから出来ないようなら開発者ツールを開いてhttpステータスをまず確認したほうがいいかなー。その後でWebサーバーのログ確認
major.minor.patch
1.0.0 < 1.1.0 < 1.1.1 < 1.2.0 < 2.0.0
major: 破壊的変更
minor: 機能追加
patch: 小さな修正
画像のUploadに失敗するのにぽすぐれのマイナーアップデートはたいして関係ないんじゃないかな…（blobで画像置いとくわけじゃないだろうし
意外とdb:migrateが必要になるかどうかみたいな理由は鯖缶でもわかってなかったりするのかな
@Cutls margin: -1px 0 0
じゃなくて
margin: -1px 0
で線が消える
@Cutls `.toot>p{line-height:20px;}`で`.area-toot .emoji-img{margin:-1px 0;}`にしたら消えたv・。・
This account is not set to public on notestock.
インスタンス運営をしたいのかインスタンスを決められた環境で建てるRTAとか勉強がしたいのかって感じのあれ
@toneji 確かに原因がわからぬまま放置するのは今後の懸念ではあるでしょうね…
CentOSは新しい環境に対応していくには厳しそうというのが外野の私の感想です。OSを変えることを検討していいかもしれませんね
epelもsclも詳しくないからbashの常識で話してきたけど
source scl_source enable
でsclを有効にできるってやつ、PATHを上書きしてんのかな
Some people have reported problems installing Mastodon v2.8.1 due to gem compilation.
This and a few other small bugs have been fixed in #Mastodon v2.8.2:
AGPLちゃんと確認してないんだけどおひとりさまインスタンスを利用するユーザーって誰を指すんだろう。連合組んでるインスタンスの利用者もその「利用者」に含まれるんだろうか？（そうじゃないなら利用者自分だし自分はソース持ってるから公開する必要も無くなるのでは
tootsuite/mastodonをそのまま利用してるならそちらにリンク向けたままで大丈夫
Nginxのconfいじってやってる→Mastodonのコードいじってないしファイルの差し替えしてない→ソース公開しなくてもライセンス違反にならない
でいいよね…？
