昔は近所のスーパーにデカいのがあったのでそれを使っていたけど、いつのまにか取っ手付きのデカい袋がラインナップから消えていたというだけの話です
昔は近所のスーパーにデカいのがあったのでそれを使っていたけど、いつのまにか取っ手付きのデカい袋がラインナップから消えていたというだけの話です
どのくらいの大きさを指してるのかわかんないけど、amazonとかで売ってる30Lとか45Lのとってつきのゴミ袋じゃダメなの・・・？＞＜
私はゴミをできるだけ溜めて出すタイプなのでそこそこ大きなゴミ袋が必要なんだけど、取っ手が付いていて台所に設置しやすいやつはレジ袋サイズしかないのよね……
一方買い物も週1以下で済ませているのでレジ袋は小さすぎてクソデカエコバッグくらい欲しくなるし。
よく考えたらエキスパートシステムの一種だ・・・＞＜；
やだなあ、人工無脳系人力キャラクター構築ソフトウェア組んでる人にとってはエキスパートシステムのほうが新しいわけですよほら
ワコムのペンタブの不具合って、Edgeの更新のタイミングで起きたのかWindowsの更新のタイミングで起きたのかペンタブのドライバの更新のタイミングで起きたのかどれなんだろう？＞＜
ていうか、URLを全く公表していないとかなら一億歩譲ってあれかもだけど、URLを明かしておいてアクセスしてきた人を「ユーザーでは無い」って逃げはAGPLの第13項ではたぶん使えないかも＞＜
ていうか、そんな回避ができるのであれば特定のユーザーを想定した場面(会員制のオンラインサービス等)以外では常にAGPLを回避出来てしまうことになる＞＜
prominentlyの意味・使い方・読み方 | Weblio英和辞書 https://ejje.weblio.jp/content/prominently
"...your modified version must prominently offer all users interacting with it remotely through a computer network..."
どっちにしても、オンラインにした時点でアクセスする人がソースコードを受けとる機会を明示的に与えなければならないので、あとでやりますはそもそも通用しないっぽさ感＞＜
日本語難しい・・・＞＜
https://gpl.mhatta.org/agpl.ja.html
"13. リモートネットワークインタラクション、および GNU 一般公衆利用許諾書との利用"
(略)"...そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする（あなたのソフトウェアがそのようなインタラクションをサポートしている場合）すべてのユーザに対して、ネットワークサーバから、あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければなければならない。"(以下略)
英語も日本語も難しくてよくわかんないけど、第13項？の記述からするとAGPLの場合はオンラインでのソースコード提供が必須ってことなのかも・・・？＞＜
GNUアフェロ一般公衆ライセンス - GNUプロジェクト - フリーソフトウェアファウンデーション
https://www.gnu.org/licenses/agpl-3.0.ja.html
非公式日本語訳
https://gpl.mhatta.org/agpl.ja.html
This account is not set to public on notestock.
吊り材よりも桁が先に破壊されたのであれば、崩落するときにもっと桁がバラバラになってそう？＞＜
画質低すぎてアレだけど、オレンジが最初に考えた吊り材破断説もありうる崩れ方っぽさ・・・？＞＜
[和歌山 6万戸断水 崩落した送水用の橋 復旧工事の方針決定へ]
和歌山市で3日、水道水の送水用の橋が崩落し市内の4割近くにあたるおよそ6万戸が断水していて、今も復旧の見通しは立っていません。市は応急の復旧工事の方針を4日夜中にも決めることにしています。
http://www3.nhk.or.jp/news/html/20211004/k10013290941000.html
https://mastodon.cardina1.red/@lo48576/102972291781866639
なのでまあ、 “いわゆるｴｰｱｲ” が重宝されるのはよくわかる
ｺﾞｯｺﾞﾖの関連する検索キーワードとして「nvidia ドライバ わからない」が出てきて、いやお前ら「わからない」で調べて何がわかると思ってんの……という気持ちになってしまった
ちゃんと情報を提示できるユーザならｴｷｽﾊﾟｰﾄｼｽﾃﾑ的なものの方が使いやすそうだけど、大半の “一般” ユーザはそこまでリテラシがないという問題はありそう。
ていうか真面目な話として、発端の話のような機械のトラブルシューティングの場面で、1980年代風の古典的アプローチといまどきのAI()のアプローチってどっちの方が向いてるんだろ？＞＜(データ用意する手間とか正答率とかハードウェアリソース辺りの性能とか＞＜)
むしろ古典的なのでって話のつもりだったからオレンジ特に変な事言ってないと思うけど、そう考えてくれる老人が少なくてつらい・・・＞＜
ｴｰｱｲはコンピュータではできなそうなタスクをこなす仮想的な存在の呼称なので、まあ
This account is not set to public on notestock.
近年の若造は皆 “ディープラーニング“ に夢中なので
エキスパートシステムという言葉を使っている老人 (←失礼) 105万年ぶりに見た
"髪が伸びたからです"も、そりゃそうだで済ませずにちゃんと髪の伸びる速さとか真面目に検証してるのおもしろい＞＜＞＜＞＜
記事書いたライターの人、オレンジと笑いの趣味が近そう＞＜；
大声出たw
（リンクたどるほどでもないんだけど、一応ソース付きで）ttp://selfishdiary.com/komurokei-hairstyle/
航空宇宙分野や外科手術の現場でも通用するような作業デザインにすれば、わりと発達障害の人でもちゃんと作業できる可能性が高くなるって事かも＞＜；
なんというか、航空宇宙関連や医療(主に手術チーム)でのチーム形成や作業デザインの話でよく出てきそうな内容＞＜；
https://mstdn.nere9.help/@orange_in_space/107042509013461393
P.28
"...以上、職務配置や人的サポートについて述べてきましたが、発達障害のある方を受
け入れる職場においては、もう一つ環境や作業課題の手順等の「構造化」の視点が有
効になります。
構造化というと難しく聞こえるかも知れませんが、「構造化」とは、コミュニケーシ
ョンや社会性が十分でない発達障害のある方のために、職場や職務の意味を理解し、
「自分に何を求められているかをわかりやすく提示するための工夫」として、本人を
とくまく職場環境をわかりやすく再構成することをいいます。
"
(略)
"構造化には、例えば「（１） 物理的構造化」、「（２） スケジュールの提示法」、「（３）
ワークシステム」、「（４） 視覚的構造化」があります。"(以下略)
発達障害を理解するために～支援者のためのQ&A～｜障害者職業総合センター NIVR https://www.nivr.jeed.go.jp/center/report/practice14.html
発達障害向けの配慮の研究成果って、UXデザイン研究の成果とか作業に関するデザインの研究分野とわりと似たような事を言ってるっぽさ＞＜
(『一般的な』人間が対象か否かの違いだけだろうから当たり前かもだけど＞＜；)
複雑性の範囲がその機械と作業の範囲におさまるので＞＜；
技術的に可能かであって、現実に導入されるかは別＞＜；
自動車の自動運転のようなフレーム問題に現実的にぶつかるとか、そういった障碍が比較的少ない分野だよねって＞＜；
電話口でどうにかできるレベルのトラブル対応はだいたいエキスパートシステム的なものでどうにかできる説…がふつうに言えるような世の中になるといいなあ（願望）
https://mstdn.nere9.help/@orange_in_space/107042272738479388
発達障害を理解するために～支援者のためのQ&A～｜障害者職業総合センター NIVR https://www.nivr.jeed.go.jp/center/report/practice14.html
きつい言い方で言うなら、口頭で指示を出してる事自体が配慮出来ていないと言ってもいいかも＞＜
宮崎県：障がい者の就労・雇用に関するお役立ち情報 https://www.pref.miyazaki.lg.jp/shogaifukushi/kenko/shogaisha/20200128105034.html
発達障がい者雇用受入れマニュアル（実践編）（PDF：2,658KB）
[pdf] https://www.pref.miyazaki.lg.jp/shogaifukushi/kenko/shogaisha/documents/49650_20200303144324-1.pdf
職場での知恵と工夫｜発達障害を生き抜くために - 大人の発達障害｜NHK福祉ポータル ハートネット https://www.nhk.or.jp/heart-net/hattatsu-otona/survive/device.html
"・口頭ではなく、メモやメールなどの「文書」でひとつずつ伝えてもらうようにする"(以下略)
脱線するけど、現場猫で検索したらこれが出てきたんだけど、
#.現場猫 夜中に機械の故障でベテラン猫にヘルプ→電話だけで的確な現状把握と対応に「どうして…どうして…」「全猫が泣いた」 - Togetter https://togetter.com/li/1578700
(一部の)人間が低コストで優れたエキスパートシステムであるのはその通りだけど、エキスパートシステムが得意とする事例だろうから技術的視点で見ると「AI化出来ない」わけでもないよね感・・・＞＜
現実的なコストを考えるとその通りかもしれないけど＞＜
チェックリストへの記入自体を課題にして提出させるのも大切かも＞＜
じゃないと現場猫になっちゃう＞＜
あとついでに、チェックリスト式の指示にするのも有用かも＞＜
チェックリストならワーキングメモリーが少ないタイプの人でも比較的混乱が少なく目標に適合してるか判断できる＞＜
オレンジも口頭で説明されるの苦手なので、ログを読み返せるテキストチャットの方が助かるし、口頭の議論よりもテキストチャットの議論の方が得意＞＜
あと、オンラインの場合は読み返せるようにテキストチャット使うとか＞＜
口頭で言っても覚えてられないタイプの人、書類等で渡すの重要かも＞＜(そして書類を無くす＞＜；)
＼ ヽ ｜ / ／
＼ ヽ ｜ / ／
＼ ／
＿ わ た し で す ＿
／￣＼
― ｜^ｏ^｜ ―
＼＿／
￣ ￣
／ ＼
／ / ｜ ヽ ＼
／ / ｜ ヽ ＼
おさぽん様@osapon@mstdn.nere9.help 特性のnotestockのお陰で今回の大災害で失われた半年のノートを無傷で取り戻すことができました。本當にありがたうございます🙏
RE: https://mstdn.nere9.help/users/osapon/statuses/103643803125432121
(日本語おかしすぎる文章になってたのなおした＞＜；)
WEB特集 「妹がジャングルジムから落ちた」 | 事件 | NHKニュース https://www3.nhk.or.jp/news/html/20211004/k10013285481000.html
(↓の参考記事)アメリカが正しいって事じゃなく記事の最後にむしろ日本と逆方向にぶっとび過ぎてる問題がちゃんと指摘されてるけど、大津の事例で親が犯罪にならないのもまたおかしい(法整備が必要)ってオレンジは思うかも＞＜
2020年03月03日 世界一過保護な国アメリカでは、日本の親は全員ネグレクト | ワールド | for WOMAN | ニューズウィーク日本版 オフィシャルサイト｜ニューズウィーク日本版 オフィシャルサイト https://www.newsweekjapan.jp/stories/woman/2020/03/post-344.php
Linux Mint 20.3、コードネームは「Una」 | スラド Linux https://linux.srad.jp/story/21/10/03/1757231/
カコイイナウい路面電車もシステムとしてはLRT(light rail transit)で車両はLRV(light rail vehicle)でビークル＞＜
ビークルと聞くと、なんとなく座って乗るイメージがあって、立ち乗りEVと聞くと違和感がある。調べてみたら車両の総称らしい。じゃあ電車もEVか。
ぶち折れた水管橋の径間、ちょうどバルブ（空気弁）があったところだという話が出てて、とりあえず確認はできた。
パイプの強度も橋の強度部材に含む感じなので、ここが老朽化して圧力と荷重に負けてめげたというストーリーは割と可能性としてありそうね。
車体のアンチクライマも必ずつけてたりとかこだわりがすごいのがあれかも＞＜；
推進してた頑固な人(名前忘れた)が亡くなってから？、先頭電動台車以外のこだわりは捨てたっぽいけど＞＜；
軌道回路説も脱線時の被害軽減説も、なんかどっちも乗り入れ各社に要求するほどのことか！？って感じなんだけどどうなんですかね…
話の流れがよくわかんないけど、京急の先頭の台車が電動台車じゃなきゃダメって事故時の脱線防止じゃなかったっけ？＞＜
京急の先頭車はモハ/デハ要請、エンジニアとしてはいまいち腑に落ちないまま今まで来てる…
軌道回路1両分の検知遅れが問題になるようなダイヤ組んじゃいけないでしょというかなんというか。
只見線沿線って土木的におもしろいものがもっとたくさんあったはずだけど思い出せない＞＜；
トンネルって普通は山になってるけど、この辺なトンネルは海底トンネルみたいに谷になってて、一番底に水力発電所の入り口がある＞＜
【山さ行がねが】ミニレポート第231回 福島県道237号小栗山宮下線 沼沢トンネルと旧道 https://yamaiga.com/mini/231/main.html
あと、どこ通るのかわかんないけど、ルートによっては超おもしろいトンネル寄れるかも？＞＜；
駐車場がある草地が駅だったっぽい＞＜
草地をよく探せば凹凸が遺構として残ってそう＞＜
只見線が特集の鉄道ピクトリアル2010年11月号持ってきた＞＜；
x工事用軌道
o電源開発田子倉専用鉄道
だった＞＜；
その写真撮ってる道路、工事用軌道の廃線跡かも？＞＜
酸欠もチェックリストに無理に足したらIMSAAFEEになっちゃう？＞＜；
IMSAFEチェックリスト＞＜
IMSAFE - Wikipedia https://en.wikipedia.org/wiki/IMSAFE
(オレンジ版はIMSAFEE＞＜(なんでそうなるかもwikipediaに書いてある))
睡眠と食事(血糖値管理)と酸素(深呼吸もいいかも)って、安全に大切＞＜
「ほったらかしでもいいからさっさと寝る」も鯖管スキルとして大事ですからね。
私らが加工機操るのと一緒で、ミスったときの事故が怖いので。
元のツイートをふぁぼってる人のたぶん8割くらい？は「だよね！ ゴテゴテ足されてないフラットデザインが正しい！」とか思ってそうなイメージ＞＜(イメージ)
https://mobile.twitter.com/manabuueno/status/1025319303501860864
で、足りなかったら、ノーマンの「誰のためのデザイン？」とか、そうじゃなければこのモーメントの方が書いた本(オレンジは読んだことないけど＞＜；)を買えばいいかも＞＜；
UXデザインの分野に限って言えば「シンプル」とか「KISS原則」とか「引き算」みたいな 適用対象が誤解されまくりの言葉は一旦全部忘れてからこのモーメント読んでほしい＞＜
ソシオメディア 上野学さんの「デザイン憲章」と「デザイン原則」 / Twitter https://mobile.twitter.com/i/moments/1029584676581560320
同じ形のスイッチをずらっと横に並べるとかは見た目と実装はシンプルでも操作は複雑なのでダメはこの辺＞＜
https://mobile.twitter.com/manabuueno/status/1025327159416483840
https://mobile.twitter.com/manabuueno/status/1027040038444396545
https://mobile.twitter.com/manabuueno/status/1027480440372748288
特にこの3個目のやつは、しっかりやろうとすると実装はかなり複雑になるって、GUIを作るプログラミングしてる人は実感してるはず＞＜(実感してなければ、ヒューマンエラーに至る穴が残ってないか再点検すべき＞＜)
このモーメント素晴らしすぎてオレンジの台詞なくなりそう＞＜；
ていうか、この方の説明オレンジが普段書きまくってる事とほぼ同じ事書いてるでしょ？＞＜；
オレンジの説明は下手すぎて全然伝わってないかもしれないけど、このモーメント読めばオレンジが変な事言ってないってわかるかも？＞＜；
https://mstdn.nere9.help/@orange_in_space/107040831689786660
ていうか、話の発端の人自身が過去にそういうのっぽいの(微妙に違う点もあるけど)わかりやすく説明してる＞＜
ソシオメディア 上野学さんの「デザイン憲章」と「デザイン原則」 / Twitter https://mobile.twitter.com/i/moments/1029584676581560320
『見せ方や操作をシンプルのする』のと『見た目をシンプルにする』のと『実装をシンプルにする』は全部違うし、UXデザインの場面で実装をシンプルにする為に操作が複雑になってしまったら本末転倒＞＜
あと元の文脈ってUXデザインの話( https://mobile.twitter.com/manabuueno/status/1444693583135592455 )だけどこの方はちゃんとしたデザインの人なのでわかってて言ってるだろうけど、単純に実装をシンプルにするんでは優れたデザインにはならないので、ゴテゴテ無意味に足すのは論外だけど、本来の意図通りにシンプルにするための機能は省いちゃいけない＞＜
「シンプルにしよう！」で同じ形のスイッチを横に並べるみたいな事は、見かけはシンプルでも操作はシンプルにはならない＞＜
ので、多くの場合、現実的にマンマシンインタフェースの実装の場面ではKISS原則は常には通用しない＞＜
創作界からわざわざ持ってこなくても工学にはKISS原則というものが＞＜
KISSの原則 - Wikipedia https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87
This account is not set to public on notestock.
橋以外ではわりとあるけど、橋梁では部分的に早く壊れるようにして発見させるってあんまりない気がする・・・＞＜
This account is not set to public on notestock.
本来は一ヶ所破断したくらいですぐ落ちちゃダメだけど、他も腐食して弱ってたら当然余裕なくて連鎖的に＞＜；
上下の吊り材の1箇所が限界迎えてブチッといって、そのショックで複数箇所の吊り材が破断して、アーチ材に一気に強烈な負荷がかかって外側に弾け飛んだとか？
https://mstdn.nere9.help/@orange_in_space/107040700833268106
こういうパターンの崩落、教科書通り的には破断時の冗長性を考えた構造にするのがよいとは言うけど、冗長化しまくるのもキリ無いし、水管橋って道路橋ほどの余裕は必要とされないだろうし、あれだよね＞＜
ていうかちゃんと冗長化した設計でも、部材が破断しても発見されないままさらに別の部材も破断してったら結局落ちるし、結局メンテが大切＞＜；
ていうか残ってる側の吊り材が、上下の部材の接続部が壊れてるし錆が多目に見えるけど、この部分が写ってる部分を中心に複数壊れたのが発端っぽく感じるかも＞＜
そうであればその上のアーチが大きく壊れるのもあれかもって＞＜
ふつーに目視点検でわかんない系の老朽化破断じゃないかなあ。
六十谷ってもうだいぶ海近くだし塩害もシャレにならんからね…
https://mstdn.nere9.help/@orange_in_space/107040611097078670
その近所のやまいが物件情報＞＜(？)
【山さ行がねが】廃線レポート 会津線旧線 大川ダム水没区間 http://yamaiga.com/rail/ookawa/main.html
もうひとつのパターンに思い至った！＞＜；
何らかの理由で残ってる側に引っ張られて形が維持される形でまるごと落ちた場合でも結果的にこういう形になるかも＞＜；(残った側がアーチが大きく歪む)
ただ、その場合そもそもなんで壊れず落ちたの？＞＜； ってなるかも・・・＞＜(大地震で間隔が大きく広がってって例ならあるけど)
桁がボキッて折れてもこうなるかもだけど、壊れ方と壊れやすさを考えると、吊ってる所が破断した可能性が高いと思う＞＜
アーチリブ側から壊れた場合はこういう風には壊れない気がする・・・＞＜
ああ、アーチの垂直の部材を継ぎ合わせてる部分が破断したとかなのね。
https://mstdn.nere9.help/@orange_in_space/107040482016745866
たぶん、縦の吊ってる部材(名前忘れた＞＜；)が破断したのかも？＞＜；
アーチが上に跳ね上がってて壊れ方がちゃんと下路アーチの壊れ方になってておもしろい＞＜
えっ…いやまって…なんでこんなド派手にボキッと折れたの…
https://www3.nhk.or.jp/news/html/20211003/k10013289651000.html
こういうのの0％表記って0.5％未満ってことなのかな？＞＜(さすがに誰も到達してない選択肢ではないよね？＞＜；)
激レアエンディングというか選択した人の割合の表示が0％のエンディングでおもしろかった＞＜
"【Detroit: Become Human】最終回！？人生はプレイヤーの選択次第！？ミスる度魂抜かれるゲーム実況【瀬島るい/ あにまーれ】" を YouTube で見る https://youtu.be/J8ATX7-F-u8
