さっきの変な表、話題になってたのこの日だ＞＜
orange(@.orange_in_space)/2017年10月19日 - Twilog https://twilog.org/orange_in_space/date-171019
さっきの変な表、話題になってたのこの日だ＞＜
orange(@.orange_in_space)/2017年10月19日 - Twilog https://twilog.org/orange_in_space/date-171019
前にツイッターちょっと話題になって、オレンジだけ「これおかしいでしょ？＞＜；」ってぶちきれた謎の表がまた話題に＞＜
世の中の職業に必須な数学の単元が一目でわかるネットサービス「100の職業で利用する数学」 - GIGAZINE https://gigazine.net/news/20190206-100-jobs-need-mathematics/
少数と分数が不要なパイロットってなんじゃそりゃ＞＜ 航法がわからないで飛行機飛ばせるとでも思ってるのかね＞＜
「この表おかしい」って方向での話題にならなかったのものすごく謎＞＜
Android 2.x辺りのスマホとかタブレットとか、ハードウェア的にAndroidが既に重いしウェブブラウザももう重すぎて無理からAndroidじゃなくなってもいいじゃん的な＞＜
こういう古いキーボードつきAndroidスマホをハードウェアだけ再利用できるシンプルなLinuxディストリビューションってあったらいいと思うんだけど無理なのかな・・・・＞＜
シンプルなって、操作とかがじゃなく、実際に使うアプリを自分で書きたい人向けの差し替えOS的なの＞＜
Optimus Chatはマジでサイズ感といいキーボードの感じといい本当に最高だったがエントリー機としての扱いだったのが本当に残念…
このアカウントは、notestockで公開設定になっていません。
スライド式QWERTYキーボード付きスマホ、徐々にスペックが明らかに - ITmedia Mobile http://www.itmedia.co.jp/mobile/articles/1902/07/news080.html
なるほど
ホームのはそのままLEDってことは、逆に考えると駅舎内なら見易さをある程度コントロールできるかもって判断かも？＞＜（照明の工夫とか＞＜）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Joetsu Shinkansen Series E7 Debut.pdf https://www.jrniigata.co.jp/press/Joetsu%20Shinkansen%20Series%20E7%20Debut.pdf
ときかんせん、かなり控えめな感じだった
ていうか、いままでは作業方法のラベルを貼ってなくて説明書を見る必要があったとか、そんなの技術的都合とか以前に、自動車の特に安全に関するデザインの常識として最初からやって当たり前の事でしょ＞＜ ひどすぎる＞＜
JPN TAXIの車いす乗降改善対応について | TOYOTA | トヨタグローバルニュースルーム https://newsroom.toyota.co.jp/jp/toyota/26431670.html?padid=ag001_tjptop_info_news_contents
改良後で当たり前であって、その前の仕様のものにゴーサイン出した人が頭悪すぎるというか謝罪会見を開くべきレベルかも＞＜
トヨタ、「ジャパンタクシー」の車いす乗車をカイゼン | スラド https://srad.jp/story/19/02/07/0547216/
車椅子での利用時「乗るまでに30分以上」と指摘の『ジャパンタクシー』 3月に改良車が登場 - FNN.jpプライムオンライン https://www.fnn.jp/posts/3990THK
このアカウントは、notestockで公開設定になっていません。
これら、たぶんプログラミング時の命名とかでも同じことが言えるはず＞＜
(お金無くてそっち方面の本が買えてないからわかんないけど、同じような事を書いてる本ありそう＞＜)
穴開けドリルそのもので言うならば、まず「穴を開ける道具」であって「ドリルビットを回転させる機械」という情報は後回しにしないとダメかも＞＜
ユーザーに道具の後ろがどうなっているのかを考慮させる必要はないし、もし考慮させるにしても、先に使用時に必要なモデルを理解してもらわないと、「それでなにが出来るのか？」「それをするとなにが起こるのか？」を道具を作った側と共有できない＞＜
お約束の「プロダクトとソリューションの違い」のドリルと穴の話にもちょっと似てるかも＞＜
ていうか、こういう用語は「ユーザーからどういうモデルとして見えるのか？(どう見えるようにデザインしたのか？)」で考えないとダメだから、そう考えるとインスタンスって語よりも、サーバーの語の方がよりユーザーが正しく対象をモデル通りにあれかもだし、例えばプロバイダって語でもあれかも？＞＜
・・・だけど、ISPとややこしすぎるかも＞＜
データベースインスタンスとか、EC2インスタンスという言葉が既にあったので、マストドンのインスタンスをインスタンスと呼ぶことにも一応抵抗はあった。インスタンスのドメインを「サービスドメイン」、インスタンス名を「サービス名」とかなら個人的にはしっくり。
サーバはある程度低いレイヤーの単位なので、複数サーバからひとつの Mastodon サービスが運用されうる状況で Mastodon::インスタンスを「サーバ」と呼ぶことに違和感がある
固定tootと普通のの境目を、罫線？(hrタグっぽいの)を1本から2本で間に空白行入れたのにしても、かなり見やすくなりそうな気がする＞＜
自分でリプライツリーを伸ばして関連トゥートを繋げるやつをやると、「トゥートと返信」を開かないと見えなくて不便。固定トゥートを飛ばすために「トゥートと返信」を開く人。 #いろいろなトゥートと返信 だ。トゥートと返信をデフォルトにした方がいい気もするが、リプライしまくってる人を開くときはトゥートだけ見たくなるだろうし、固定トゥートはえあいさんのスクリプトみたいに右に出せば良いのではって思うけど、スマホの表示だとまたアレだし、難しいわね。
不穏っぽいから言及してなかったけど他の人(？)が話題にしてる・・・＞＜
ぼくはこれ使ってます（宣伝）
https://github.com/eai04191/mastodon-pin-a-side
微妙に解決しました＞＜；（トゥートと返信から見れば固定toot表示されないって気づかなかった＞＜；）
これ、しかもマストドンは『全部読みたい場合にはウェブから見てね！！！』方式なので、専用クライアントアプリ側で工夫できない＞＜
