このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
civ5、難易度皇子までしか勝ったことないけど、（低難易度でも）都市を増やさないで勝つ方法とか戦わずに勝つ方法ぜんぜんわからない＞＜（都市少ないとユニット生産間に合わなくて一方的に裏切られて攻め込まれちゃうし、都市多いと国境問題が起きて成り行きで戦争に・・・＞＜（国交問題から戦争が起きて、反撃しながら内政で勝つみたいなワンパターンにいつもなっちゃう＞＜））
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ま、言うて Mastodon も整数だったフィールドが唐突に文字列になったりするけどなwww
"それについて気にしない人は気にしなくてもいい状態に出来ない" にした時点でデザインとして失敗だし、
「デフォルト設定出来ず選択を迫り」 かつ 「選択肢を排除し固定にできる」って矛盾するから、想定しなくて良い事態(発生した場合デザインに根本的な誤りがある)かも？＞＜；
簡単UIと多機能UIの2段にするデザインってわりと正解の場面多いかも＞＜
それはどっちかというと、最近のシンプルの方向を間違えてるデザイン/ユーザーに選択肢を与えず、選択肢を減らすほど正しいと勘違いしてるデザイン の問題が大きいのような＞＜；(だいたいAppleが原因)
あの辺りの機能、 twitter 社は「多くのユーザは実際活用している」という言い訳をしていて、要するに個々人の体験よりも統計で見た数の大きさが優先されているので、大規模サービスの限界という感想です
気になった(興味を持った)のだけ追えばいいような＞＜ とりあえず目に入りさえすれば、興味の対象(？＞＜；)かは判断するチャンスは発生するかも＞＜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
LTL が「(ユーザが明示的に作らずともそこにある)場」としての役割を提示してしまったことで、エアリプが促進されており、これは良くないことだと感じられますね(その慣習がﾌｮﾖｰ関係に洩れている場合の割合もそれなりに多いのではないかと)
あと、ツイッターの通知で「あなたのツイートを『hogehogeさんがリツイートしたものを』fugafugaさんがふぁぼった」みたいな多段式？になってるのも、ゆるいコミュニティ構築の機能になってるかも＞＜ 同じツイートをふぁぼってる他の人を知れるのも同様かも＞＜
まあ boost が気に要らなければ「ブーストを非表示」なりミュート/ブロックなり使えばよろしいので、システムとしてのサポートはひとまず使えるレベルに達しているかと
たとえば twitter においても、「フォローはしてないけどよく見掛けるアカウント」のようなものはやはり存在するわけで、その例から「boost を積極的に使うことでアカウント間の接続の強さに勾配を作ることができる」ということが示されていると考えています
それはたしかにその通りで、少なくともオレンジの観測範囲では、ツイッターでもっともゆるい繋がりを構築する機能をはたしているのはリツイートで、マストドンではなぜかブースト無しエアリプする人がツイッターと比較して極端に多いかも＞＜(でも、LTL対象のみじゃなくフォロー関係に対してもそういう傾向が極端に多い気が＞＜；)
私はエアリプよりも boost を使ってくださいとお願いしております
つまり LTL は、当該 LTL に参加している人間にとっては、フォローより緩やかな関係を提供しているが、当該 LTL に参加していない人間にとっては、アカウント関係の固定化や局所化を促進する仕組みになる
そして、 LTL でエアリプ会話をするというのは repeat (boost) を避ける方向に働くので、結果としてフォロー関係にないアカウントの投稿が表れる頻度を著しく下げることになり、接続の「on/off 化」を促進することになるのでは
repeat (boost) が活用されるという前提に立てば、アカウント間の接続の強さは距離と repeat 頻度によって重み付けされるから、純粋な on/off にはならない気がする
それはつまり気分か時間か頻度か何かによって、その緩い接続のあるアカウントの投稿が確率的に出現するべき、みたいな……？
見たくない物を見ないとか、自分が書いたものを不特定多数見られたくないとか、ましてや知らない人からツッコミは一切受けたくないみたいな閉じたコミュニティを構築したいのであれば、マストドン等よりツイッターを鍵アカで使う方がまだ適してるし、もっというならツイッターも含むSNSの出番ですら無いかも＞＜
フォローのみ、つまり繋がる繋がらないの2値(ややこしいので単方向の話っぽく書く)で構築されるコミュニティって、気に入った人の意見のみ目にして、気にくわないやつの意見は全く聞きも検討もしないってなっちゃって、とんでもなく硬直したコミュニティと言えるかも＞＜
それって技術的分散が(あるいは分散によって)目指すものと近い方向の発想なのか？＞＜という疑問も＞＜
これは言い方を変えると、マストドン等で実現構築されるコミュニティ群に対して、オンオフ1段階のみで構築されるコミュニティ/ネットワークが果たせる程度の機能しか期待していないからかもって言えるかも＞＜ でも、その程度のコミュニティって、おそらくdiscordとかあの辺りでも構築出来るかも＞＜
コミュニティの要素間の繋がりってオンとオフの１段階じゃないんだよたぶん＞＜(社会学とかゲーム理論とかわかんないから"たぶん"＞＜；)
これはたぶん、オレンジが前にも書いたフォローよりもゆるい関係に注目してないから(おそらく代わりにその機能を果たせるものも含め)LTL等が不要に見える＆なぜ自鯖に他人が登録する事を望む(と言うかなんというか)のか？を理解できないんだと思う・・・＞＜
もっと根本的には、「 LTL を必要とするような使い方をする」ことが間違っていると考えたいですね。
どうせ少数か密接に関連しているアカウント群しか同一インスタンスに存在しないのであれば、互いの存在も当然把握していると仮定していいし、自分で必要なアカウントをフォローしろという話
(分散化の促進のためには、)アカウントは複数持てても、根本的に少人数/個人利用を想定した作りになっているべきだったと考えます。たとえば典型的には LTL が不要
見ず知らずの他人を集めて自分のリソースを提供した挙句彼らの行動の責任まで負うなんて、聖人か何かじゃないと無理ですよ
だってまさか、分散をよしとする SNS で、広告とか商業でやってるわけでもないのに大規模化を目指すなんて、怠惰な私は想像だにしてませんでした
振り返って考えてみると、そもそも個人運営の中小インスタンスが積極的に人を集めようとしたこと自体が私の想定と違っていたので、その時点で私の敗北は確定していた
キオスクで売ってる冷凍みかんは-40℃とかで凍らせてるらしい・・・＞＜；
みかん凍らなかった・・・＞＜ むしろ冷凍庫すごいし、ググったら冷凍庫は-18℃って＞＜；
天才なのでマルチセッションに45分で対応した＞＜（本当の天才はそんな間抜けな修正をする前に気づきます＞＜；）
このアカウントは、notestockで公開設定になっていません。
WinForms用に、貼り付けるだけで自プロセスのレベルメータを表示できるコンポーネントを作ってたけど、よく考えたらひとつのプロセスで複数のオーディオセッションがある時ってどれを表示すれば良いのか？＞＜；（逆に言うと複数のセッションを表示出来るように作らないと駄目じゃん？＞＜；）
private new bool DesignMode
{
get
{
return base.DesignMode | (Process.GetCurrentProcess().ProcessName.ToUpper().Equals("DEVENV"));
}
}
}
これっぽい・・・＞＜ DesignMode の問題 - 憂国なプログラマ - Yahoo!ブログ https://blogs.yahoo.co.jp/hilapon/3074221.html
VS2015+C# でカスタムコントロール開発して弄ってたら、貼り付けたデバッグ用のフォームのデザイナを表示しようとするとIDEが異常終了するようになった・・・・＞＜；
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 奥野 幹也 https://www.amazon.co.jp/dp/4774171972
これおすすめです(なんか鉞投げてる web ページも見たような気はするけど、良い本だと思います)
ていうかもしかして型ありき原理主義の人はSQL苦手な人結構居るのかも？＞＜；という救いを得た気がする＞＜；（DBちゃんと扱えないって恥ずかしくてあんまり公言できなかった＞＜；）
NoSQLよりもさらに推し進めて、型ありきで考える人が考えやすい新しい何かがあったら幸せになれるし、その何かが出来てほしい・・・＞＜（甘え）
わかりすぎる。「理論から学ぶデータベース実践入門」を読んだときも、リレーショナルデータベースの設計思想に基づいて、まあリレーショナルデータベースの事は納得したけど、そうはいっても実際の実装は・・・みたいなお気持ちになった。＞BT https://mastodon.cardina1.red/@lo48576/99337387594093667
SQL 、最適化は DBMS 側にお任せして全部英語っぽく SELECT 一発で書こうという超アグレッシブ設計なのに、結局独自拡張非互換の嵐と DBMS 毎の最適化テクニックのせいで駄目な感じになってるし、人類に「こっちで最適化するから何も考えずに抽象的に書いて！」というのは駄目っぽいという学びを得た
