外的要因、自分の中から生まれる動機じゃないものがインセンティブ?(言葉があってるのかわからないし理解もあってるかわからない)
外的要因、自分の中から生まれる動機じゃないものがインセンティブ?(言葉があってるのかわからないし理解もあってるかわからない)
nginxでlocalhostをupstreamにしてたらresolverで::1:3000にされて困ったってやつをそのままやらかしてエラーログたまりまくってたなの(6時間前に直した)
@mimikun configファイル的なのにもそういうのはない感じ?(最近変わったenvでソースコードのリポジトリ変更できるような感じで
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
これめっちゃわかるになってる(skipすればいいに気がつくまでの無駄になる時間)
https://don.inux39.me/users/inux39/statuses/102048552828121656
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
fetchしてマージコミットでmergetool使えば大抵なんとかなる。なんとかなるし見栄えも綺麗になると思う(なおbackportのhashが違うコミット
このアカウントは、notestockで公開設定になっていません。
どこかでpullじゃなくてfetch/mergeしろみたいな話見てからちょっと警戒してるんだけどあまりそうじゃない人が多いのかな>git pullして更新する
(たまにmasterブランチも消してupstream/masterとupstreamのtagだけ追ってるんだけどこれどうなんだろう)
このアカウントは、notestockで公開設定になっていません。
せっかくなので本家に寄与するのが一番だと思うけどあえて本家とは違う機能とか実装しようとするなら本家のレポジトリをGit submoduleに入れて管理するのはどうでしょう
RE: https://dtp-mstdn.jp/users/noellabo/statuses/102048101167023152
upstreamをわざわざmasterに取っておく意味はあんまりないと思うからremoteにupstream追加してgit fetch --allすればいいかなぁって
このアカウントは、notestockで公開設定になっていません。
error.logにconnection refused出てるなぁって昨晩ボケーっとしてたらlocalhostでproxy_pass設定してた。無駄なエラー発生させてたよ…
いま、一気に知見が集まったけど、LTLチャットじゃなくて見事に連合を跨いでやってるから、分散してるんだよね。全然良い意味じゃなくて……。
私がブーストした分は拾えているかもしれないけど。
go modulesはgemみたいなイメージ
それ以前の管理は…やったことがないので想像だけどsrcで管理しないといけないの地獄じゃん…とか思う
このアカウントは、notestockで公開設定になっていません。
以前、PHP製のデータベース管理アプリケーションAdminerにテーブルを横スクロール可能にするPR開いて、マージされたというかRebaseで実装されたというかみたいな感じになったんですが、実装後に通常マウスのWindowsではすごく不便ってなってRevertというかスクロールはデフォルトで向こうになったんですよね
なのでスクロール系を弄るの何もわからないってなってる
このアカウントは、notestockで公開設定になっていません。
歴戦の鯖缶たちで、これっしょ常考、とか定番が定まらないのに、見よう見まねで更新の度に死にそうな(時々死ぬ)鯖缶勢、どうやってgit使っていけばいいのか……。
ぜんぜんわからない。俺たちは雰囲気でgitをやっている。
notestockの公開ページにあるここのリンクを開くと、その付近が開くようになっていて話の流れが分かりやすくなってるんですよー。後者のリンクは、以下のgreasemonkeyスクリプトで。 https://github.com/osapon/mastodon2notestock
あー機能ごとに最新とかタグに合わせてrebaseとかマージコミットすればその機能ブランチを最新に適用させ続けられるのか(青天の霹靂)(誇張表現)
まあURLを併記したエアリプならまだましかな, だと"なぜか"通知が言ってしまうので使いにくいが丼ではそんなこともないので気兼ねなく使える
直リプ,ためらいが生じるので使いにくいたしかにそれはそうだけど,いざ自分がエアリプされる段になると,文脈見えなくなるのでできるだけメンションするようにしてる(つもり)
自分のブランチにmergeしてくの、アップストリームをmasterにしてるから楽なのかもしれない。タグをmergeしてくとコミットが巻き戻ったりあるかもだね。
こういう、わりとみんなが興味ありそうな話題だというのに、エアリプばかり。
言及を収集するとなると大変だし、みんなお互いのコメント読めなくてみんな不便じゃないの?
これってトリビアになりませんか?
晩御飯レシピ開発
master: 今までの蓄積。とても良いレシピの集合
trial/etc: レシピ開発。新しいレシピの提案
→PRでレビュー(値段とか?わからない)してよくないレシピはリジェクト
なるほど出来そう(?)
このアカウントは、notestockで公開設定になっていません。
開発のためのフローは本当に効率化して機能の追加をしやすくする指針だからちょっとしたコード変更を公開したり維持するのもやっぱりそれを意識した方が楽
機能ごとにブランチ切るのはどれをどこまでやったかみたいなことを明確にするので…
いろんな変更をごちゃ混ぜにしながら一つのブランチで維持するのはとっ散らかるだけだからその雰囲気のフローは消耗しそう
追加した機能や変更のブランチ名を切って自分用の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用意すればいいと思うんだけど
フォロワーがいっぱいいるユーザーが、自分のフォロー範囲内を世界の全てのように勘違いして代表ぶってるのはTwitterでいくらでも見かけた光景だけど、丼だと最初からLTLが見えるので、フォロー/フォロワーを増やすまでもなく任意のユーザーが代表ぶれる可能性ある。
自分、サーバーからプログラミング始めてる(PHP)から、Nginxとかcertbotとかデータベースとかでやらかしても何とか自己処理できて今の所cutls.comを既存リソースだけで建てられてるけども
今でこそリレーがあるけど、1人1鯖だとLTLは使い物にならないしFTLもはじめのうちは使い物にならないからハードル高すぎるとおもうんだよね
;はただの改行だから実行される。&&はexit code 0のみ次に行く
shell scriptで複数行の&&みたいなことするときは$?で制御する
このアカウントは、notestockで公開設定になっていません。
ここで昔話なんですが、Mastodonが流行る前、Misskey民の間でちょっとだけGNU Socialが話題になったことがあるんですよ。私はGNU Socialの連合に感銘を受けてMisskeyにもああいう連合の仕組みを入れようとか言ってたんですが(皆さんご存知の通りOStatusは非常に難解なので誰も実装できる人間がおらず実現されることはなかった)、まさか日本でこんなにGNU Socialを基とした連合SNSが流行るとは思ってなかった。その点ではあの頃の俺はいい線いってたのかもしれない。
/etc/nginx/nginx.confにあるuserディレクティブで指定されてるユーザーをオーナーにしてグループをrootにしてあげるとnginxの方は解決しそうだけどどうだろう
このアカウントは、notestockで公開設定になっていません。
そう言えばgroupで権限もらえるみたいなことをわかってない頃にnginxサーバー建てた名残で
user <loginユーザー名> <loginユーザー名>
ってなってるのめっちゃ恥ずかしい
@toneji アクセスログ側が06/May/2019:02:00:00 +9000、エラーログ側が2019/05/06 02:00:00みたいになってたので
公式のやつ改造せずに使うならbuildフィールドをcomposeから消して使うのすごい快適そうなんだけど誰もやってなさそうよね
このアカウントは、notestockで公開設定になっていません。
@Cutls vim して
"/ 500 "
とかで見つからんのよね。そう言えばステータスエラーじゃなくて時間でしか探したことないなとか
@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で画像置いとくわけじゃないだろうし
@Cutls `.toot>p{line-height:20px;}`で`.area-toot .emoji-img{margin:-1px 0;}`にしたら消えたv・。・
このアカウントは、notestockで公開設定になっていません。
@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ちゃんと確認してないんだけどおひとりさまインスタンスを利用するユーザーって誰を指すんだろう。連合組んでるインスタンスの利用者もその「利用者」に含まれるんだろうか?(そうじゃないなら利用者自分だし自分はソース持ってるから公開する必要も無くなるのでは
Nginxのconfいじってやってる→Mastodonのコードいじってないしファイルの差し替えしてない→ソース公開しなくてもライセンス違反にならない
でいいよね…?