orange
さんがブースト
DTP鯖管
私は大規模・中規模な同人誌即売会において、既によく名の知られた壁配置・似壁のサークルではなく、無名の島中のサークルをくまなく見て回り、心を動かす作品、作り手と出会うのが好きである。（小規模な即売会は全てのサークルを見ることができるので除外）
同人誌即売会は、その歴史的経緯により、新規参加者や、人気や評価が低い人にも、参加者としての約束が守られる限りは、平等に機会を提供し、多様性を維持するように設計されている。
願わくは、インターネットにおいても、既に有名で評価の高いものではなく、目立たないが素晴らしいコンテンツ、作り手と出会いたいものである。
故に、 @vaginaplant 氏のレコメンデーションフェアネスの研究・提言には関心が高い。
他方、本質的にナマケモノであるため、受動的に、自ら考えなくても提供される、ハズレの少ない情報のありがたみも理解できる。自身が関心の低い領域においては特に顕著である。
アンフェアなものの需要も無視すべきではなく、全てを肯定しつつ、それでもフェアな仕組みを絶やさないよう、上手に共存させていく方策が必要ではないかと思う。 #dtp
miniITXです！＞＜
メンテ性を犠牲にした小さいPCケースが好き派！＞＜(？)
マストドンのAPIの長期的互換性も、オイゲン氏の行動パターンを観測してる限りではかなり怪しい気がするし＞＜
何が言いたいかというと、例えばツイッタークライアントで多くのツイッタークライアントがそういうのを使っていたら、ツイッターの仕様で全員バラバラに右往左往しないでそのライブラリをいじれば一応苦し紛れに使えただろうし、さらに今回の事実上のAPI廃止でも、各クライアントのコードを弄らなくてもライブラリ側で頑張れば強引にどうにかマストドンで使えた訳じゃん？＞＜(もちろんかなり強引な動作になるだろうけど、とりあえずマストドンでも動くって段階からの方が対応する作業もめげないじゃん？＞＜)
各マストドン等クライアント←(互換性をとにかく重視した仕様)→共用ライブラリ←→マストドンAPI等
的な・・・＞＜
まためんどくさいこと言い出すけど、マストドン直接のAPIじゃなく、将来マストドンのAPIが死んだとしてもコードがゴミにならないようにする中間ライブラリ(＆仕様)みたいなのつくったら、例えば直接マストドンAPIを使わずそのライブラリを使えば、そこだけ新たなAPIに対応させれば互換性が保ててアプリがゴミになりにくいかも？＞＜
ソースコードちょっと読んだけど、C# だけどハイカラだ・・・＞＜
オープンソースらしい？からフォークしてマストドン用に改造して差分はCC0にして原作者に投げつける手も？＞＜(強引なプラットフォーム移行勧誘)
orange
さんがブースト
Krileも提供終了になるのかー
orange
さんがブースト
無理なのかな？＞＜(括弧内に無理って自分で書いてる)
オレンジの脳内妄想的には、新幹線版、逆ほくほく線みたいなのって無理なのかな？＞＜って気がしてる＞＜(2～3両編成の高加減速で低めな最高速度のローカル用新幹線車輌を作って、それ専用の駅にだけ止まる＞＜
(車輌価格がとんでもなく高いとか、保安上の問題とか、専用の小規模な駅でも待避線つきのをかなり作らないとと避けきれないよねとか、待避線つけたら駅の設置コストがとか保線費用の高騰とか、何らかの地元補償の形態だとしても、どう考えても赤字だけどどこがお金出すのかとか＞＜；))
めちゃくちゃ混んでるならたしかに＞＜；
山陽新幹線普通に16両で走れるし新幹線通勤需要もそれほど無さそうだから総2階建てにするメリット無さそう＞＜；
宇部興産専用道路とかも、なぜ日本では機関車が牽引する旅客列車がほぼ無くなってしまったのか？＞＜という話につながる＞＜(長すぎる話に＞＜；)
orange
さんがブースト
物流も関係してくるからなあ
電車の付随車も電車かも＞＜(システム上『客車』には入らない＞＜(電車(電動客車)の電動じゃないやつになるはず？＞＜(電動客車ではなく付随車だっけ？＞＜(わかんない＞＜；))))
orange
さんがブースト
動力分散方式においては島秀雄さん、東海道新幹線の実現においては十河総裁の尽力（色々アレなことやったりして）、れ、連結器においては柴田兄弟（柴田式）が…
なぜ客車列車がって、鉄オタ向けというよりもすごく社会科って話題で、突き詰めるとインターネットの方じゃないガチ蟹工船方面の話題にもかなり強く関連する話題・・・・＞＜
- ＠orange_in_space
2017年 4月に登録
