  |
はてなキーワード: 送信とは
だから俺は嫌いなんだよね、「対面で会話した時にこそ人間の本質が出る」みたいな事ドヤ顔で言ってる奴らが。
まあソイツらって結局は「考える時間があったら卑怯な嘘を沢山繰り返してしまう人間なので（自分が）、まともに考える間もないスピードで会話した時に本性が出る（ので他人もそうだと思っている」でしかないわけで。
人間はやっぱゆっくりと文字を書きながら、自分の発したものを自分で読み返しつつ物を考えなきゃ駄目だよ。
誰もがノイマンみたいな広大なメモリを脳に持っていないんだから。
数字７つ覚えるのが精一杯のポンコツがさ、そのリミットの中で四苦八苦しながら考えたって、あとで振り返ったら「こんな話をするつもりじゃなかったのに」って後悔するばかりでしょ。
それは喋る速度じゃない。
書く速度でなければならない。
少なくとも、発信する前に自分が何を発しようとしているのかを、実際に自分の体の外に出た状態のものとして見返せる形にするべきだ。
喋りってのは出力と発信を同時にやることだ。
idを出さなくても特定可能性があって当事者からの申請があれば削除されるぞ
具体的には、問い合わせフォームにログインして該当する内容タブを『お問い合わせ』に選択、件名に『はてな匿名ダイアリーの削除依頼』、サービス名のタブを『はてな匿名ダイアリー』に選択、「問題が起きたページ」にこの増田のURL貼り付けて本文に
・はてな匿名ダイアリーにおいて自分のブックマークコメントが引用されている、つまり自分に対して言及されている旨(該当エントリのURLや自分のブコメURLを貼付すると尚良し)
・投稿者に対して自分が削除依頼したことを通達することに同意する旨
上記3点を押さえて書いたものを送信したら、ちゃっちゃと削除して貰える(逆に不備があったら何往復かやり取りしなきゃいかん)
そうすると1kmは5μsだとすぐに分かるし、1000kmで5msです。（単位を上げるだけ）
東京-大阪間はざっくり500kmなので2.5msで到達できます。
片道の遅延を計測するのは難しいのでpingで往復を測ると5msぐらいです。
実際にはルーターを通過する時間なんかがあるので10msとかになったりします。（30msはちょっと遅い気がする）
ちなみにLTEとかWiFiを挟むと平気で100msぐらい増えます。
電波は共有資源なので誰かが使ってる間は使えないから、使えるようになるまで待つからです。
待ち時間が100msとかになります。5GとかWiFi6はその辺が早かったりします。
東京-サンフランシスコ間だと8000kmぐらいあるので40msです。往復で80msなので、まぁ100msぐらいです。
TCPの場合は送信前に3wayハンドシェイクっていうのをするので2往復ぐらい事前にやりとりします。
なので200msecぐらいかかりますが、最近はFast Openっていうのもあるので多分もっと早いです。
1GBのデータを送るとして、送り始めの先頭データが到達するのにこれだけの遅延がかかります。
1byteだけ送って、届いた確認が来たら次の1byteを送って・・・なんてやってたらいつまで経っても送れないので
届いてるかどうかは後回しにしてとにかくドンドン送るとします。
この場合、1GBのデータを送り終わるまでかかる時間は、使える帯域によって変わります。
1Gbps使えるなら、1GB送るのにざっくり8secの計算になりますが、まぁ諸々あってそんなわけはなくてもうちょっとかかります。
ちなみにUDPの場合、使える帯域以上にデータを送ると途中で捨てられるだけです。
パケットなので順番が逆転する可能性もありますが、それでも気付かずそのまま送ります。
TCPだと途中で「ここまでOK？」っていう確認をするのでその分の遅延が入りそうですが、SACKっていう仕組みで良い感じに遅延が少なく通信できます。
去年人生で初めて彼女ができて、そんで今年の春別れたんですがそれまでの事を書こうと思います。
長々しい惚気と後悔の文でできた自分語りです。
※このような日記を書くのは初めてのため、至らぬ点もありますがご容赦ください。
去年たまたまゲームで知り合った人間にLINEを交換しようと言われた。(インターネットでこういう事を気軽にするのは良くないけども、)自分は結構インターネットで知り合った人間とLINE交換をするタイプだったので二つ返事で承諾し、交換した。何回か通話もしたので、女性だというのは分かっていた。
そこから、結構毎日会話をする様になった。「おはよう」とか「今日は〇〇を食べた」とかまあ普通の会話だったと思うが、時々「好き」とかいう言葉が送られてくることがあった。最初は少し驚いたものの、過去にLINEを交換した女性の中にもこういった人がおり、その人はまあ「仲良し」とか友情の意味で気軽に使ってくるタイプだったので(まあ今回もそういう感じだろう)と思っていた。
しかしあまりにもLINEが毎日送られてくるので、チョロかった私は愚かにも「この人...自分のこと好きなんじゃねえの...？」とうっすら思い始めてていた。
ある日、また普通の会話の合間に「好きです」と送られてきており、今までは気に留めなかったもののこの一言だけ何故か引っかかったためつい好きというのはどういう意味か聞いてしまった。すると「恋愛的に」と返ってきた。この時、人生で初めて人から恋愛的な好意を向けられていると気づき、ビックリするほど気が動転していた。その日は朝から気が沈むようなことがあったというのに、もうすっかり告白されたことで頭がいっぱいだった。オスというのは薄情で単純な生き物だと思う。
そして、気が多少落ち着いてから「インターネットで知り合った顔も知らない人間と恋愛するのはどうなんだ」とか、「うまくいかなかったらどうしよう」だとか、「そもそも自分はこの人のこと好きなのか？」とか色々考えてしまって、何も分からなくなっていた。もう何も分からなかったし、(告白されたからだけど)なんだかこの人の事を好きだった気がしてきたし、もしかしたらこの先彼女ができる機会など一生来ないのでは⁉️と思ったのでOKした。
晴れて人生初の彼女ができた私はメチャクチャ浮かれていた。それはもうメチャクチャに浮かれていたものの、どこか現実味を帯びず夢でも見ているのではとも思っていた。
そんな気分でバカみたいにふわふわと過ごしていると「会わないか」という提案をされた。もちろん会いたい。私は二つ返事でOKを出し、付き合って2週間ほどで彼女と初めて会うことになった。正直この時点では
という可能性を考えていた。
②に関しては、まあ会ってみないと分からないがせっかく自分みたいな人間を好きになってくれたのに失礼なので見た目は好き・嫌いの尺度に入れないようにしようと思いつつ①だったら立ち直れないな...という考えのまま、服を買ったり美容室に行ったりと慣れない事をして当日が来てしまった。
慣れない格好で窮屈な電車に乗っていると1通の通知がが届いた。「〇〇さんが画像を送信しました」
なんだろう...と思ったのも束の間、「人が多くてわかんないと思うから、写真を送ります！」
服装とか場所の写真かと思ったので開くと自撮りだった。え⁉️⁉️ビックリしてしまったのでまともに見る前に思わず目を逸らしてしまった。意を決して画像に目を戻す。うわ、美人だ...
どタイプだった。いいのかな、自分みたいなどうしようもない人間がこんな美人と付き合えて...とネガティブになってしまいそうなほど美人だった。誰に似てるとかは分からないけど、自分の中ではかなり美人な方だった。遠回しにこちらの画像も送るよう催促された。どうしよう。自分は不細工で肉付きも良いし、オマケにネガティブだ。自撮りなんて変顔でしかしたことが無く、自分の真顔に向き合うのなんて久々だった。とりあえず分からないなりに頑張って撮った自撮りを送った。なんて返信が返ってくるのか見たくなかったのでスマホを閉じて急いで目的地まで向かう。「着いた」とのことなので人混みを探す。いた。
現実に見ると余計に美人に見えてくる。こういうのって現実のが写真よりも美人に見えることあるんだ...と思っていると、手を繋がれた。もうぶっ飛びそうだった。気絶しそうだった。
気づいたらデートが終わっていた。緊張しすぎていて、何も分からなかった。
その後は、相手は楽しくなかったんじゃないかなどの不安や初デートした事への興奮などがないなぜになった感情を抱えて帰宅した。
死ぬほど使いづらくて死ぬ。会社のPCがMacBookなので、Windows環境では問題にならないかもしれないが、Teamsを使っていてとにかく不満なことを述べていく。
これが一番不満なところ。ミスタイプすると中途半端な文章で送られてしまう。相手にメンションも飛んでしまう。デフォルトでEnter送信にするのはいいけど、Ctrl+Enterで送れるようにキーバインドの設定用意しとけ。エディタ開けばいいだけなんだけど面倒。こういうUIの作り込みの甘さが使っててカスだと感じる。
反応絵文字の種類がカス。👍❤️😆😲☹️😡、誰が使うねんって絵文字ばっかり。使えるのは👍❤️だが、ハートは女性社員に使うことはできないので（セクハラに当たるため）だいたい👍になる。だがOKでもいろんな意味のOKがあるはずで、Slackでは「確認しました」「承知しました」「完了しました」のスタンプがあって、それで反応するだけで完結できた。👍で対応できないところは文章で返さないといけないので、無駄なチャットが増えていると思う。
ミーティングで喋らないときは常にミュートすると思うんだが、ミュートボタンが画面中央下にないのが使いづらい。カメラボタン、ミュート、共有の並びになってて真ん中にあるのもいちいち見て確認して押さなければいけないので動作が遅れる。理想ならミーティング中はSpaceでミュート切り替えをトグルできて欲しいが、Teamsはここでも面倒なショートカットキーが設定されてる上にキーバインドは当然変えられない。カス。
ほぇ～
認証を受けたり、販売された時点では、どこをどう調べても真っ白なハードウェアなんだけど、
実用的に使われ始めてから、NPTやDNS経由でなんらかの通信文を受け取ると、ファームウェアアップデートのフリをして
収集された情報は、そのネットワークで最もバレにくい手段で外部に送信されたり、
あるいは、内部にため込んだ挙句、故障修理という名目で持ち去られる。
認証を受けたり、販売された時点では、どこをどう調べても真っ白なハードウェアなんだけど、
実用的に使われ始めてから、NPTやDNS経由でなんらかの通信文を受け取ると、ファームウェアアップデートのフリをして
収集された情報は、そのネットワークで最もバレにくい手段で外部に送信されたり、
あるいは、内部にため込んだ挙句、故障修理という名目で持ち去られる。
アメリカが、どの経路を把握しているのかを中国に知られないようにするために、詳細は伏せられているが、
｢日本人の8割がTwitterの短文すら理解できない?｣…急増する"バカ"の正体
https://president.jp/articles/-/63846?page=3
「ITスキル」のレベル3は「メールを読み会議室の予約処理をする」という、事務系の仕事では最低限必要な能力を試す課題ですが、これをクリアできた日本人はたったの8.3％……。
これらの結果をまとめると、以下のようになります。
この文章を読んでITスキル問題がどんなものか興味が湧いたので調べた
初見のシステムでこの問題はできない人が多くても仕方ないのではないか…?
全体像が分からないので断言はできないが、自分ならとりあえず受けられる予約だけ全部登録して終わってしまう気がする
問題文
あなたが受信した3月16日分の申込みに関するメールを全て確認してください。
会議室予約システムを使い、これらの会議申込みを、可能な限り登録してください。
全ての申込みを処理したら、「次へ」をクリックして進んでください。
解説文
このタスクは、会議室予約システムを使って、特定の日の予約申込みに対応するものである。
予約申込みの中に応じられないものがあることが判明した場合、解答者は申込みを拒否するという電子メールのメッセージを送らなければならない。
タスクを正しく完了するためには、複数の制約（使える会議室の数と既存の予約の数等）を考慮にいれなければならない。
最初の制約のため、予約申込みのうちの一つには応じられないという行き詰まりが存在する。
行き詰まりを解消する方法は、リクエストのうちの1つに対して断りのメッセージを送信するという、新たな副次目標（サブ・ゴール）を設定することである。
環境の中には、会議室の予約リクエストが受信トレイに入った電子メールソフトと、会議の時間に合わせて会議室を割り振ることができる、ウェブ形式の予約ツールという、2つのアプリケーションが存在する。
この問題項目が要求するのは、行き詰まりを解消しなければならないようなスケジュール問題を解決するために、ウェブ・アプリケーションといくつかの電子メールの情報を使う
こと、基準を定めて適用すること、及び調整の結果を知らせることである。
複数のアプリケーション、多数のステップが存在し、行き詰まりが組み込まれており、新たな環境（会議室予約システム）の中で状況にあったコマンドを探し出して利用することが求められる。
原典：https://www.tumblr.com/numberonecatwinner/701567544684855296/elon-wyd
私は何年か前SpaceXのインターンをしていて、そのころSpaceXは今よりずっと小さい会社だった。イーロンが植毛をしたのよりは後で、イーロンを個人崇拝するカルトが盛り上がるのよりは前のことだ。なので知ってることをいくつか語ってみようと思う。
私がSpaceXにいたころ、イーロンは基本的には子供の王様だった。彼は会社に金と権力とPRをもたらす大切な傀儡だったが、毎日の意思決定をするのに必要な知識や（率直に言えば）成熟した人格を持っていなかったし、そのことをみんな知っていた。彼の周辺の人々の仕事は、本質的には、まともな意思決定をするよう彼をうまく操ることだった。
イーロンを管理することは会社の文化の大きな部分を占めていた。私のような底辺のインターンでさえ、会議でそういう会話が大っぴらにされているのを聞けた。社員はイーロンが食いつくようにアイデアをプレゼンする方法を知っていたし、イーロンの気が狂っているとしか思えない要求をうまく再解釈する（もしくは無視する）クリエイティブな方法を知っていたし、更にはイーロンが気に入るようにオフィス内を「演出」する方法も知っていた。
記憶にある一番面白い「演出」の例は、あるITセキュリティ部門の社員だ。彼は自分がコンピューターで何かすごいことをしているように見せるため、モニターの一つでマトリックス風のランダムなでたらめな表示をし続けるスクリプトを走らせ続けていた。二番目に面白かったのは、遅くまで働いているように見せようと午後5時以降にオフィスでWorld of Warcraftをプレイしていた社員たちだ。
SpaceX社員がこういうことをしていたのは、宇宙に進出するという社員にとっても重要な仕事のために、イーロンが金（と誇大広告）をもたらしてくれるからだ。会社はイーロンと一緒に大きくなったし、イーロンの周囲の組織も大きくなった。イーロンと末端の従業員の間には、何層にもなるマネージャーの組織が存在したし、彼らは経験豊富なイーロンの管理者だった。繰り返しになるが、社内の文化のどれほど多くの部分がこの一人の男をうまく管理するために捧げられていたか、どれだけ強調してもしすぎることはできない。
Twitterにはこれらの要素が存在しない。Twitterにはイーロン・マスクを管理するという問題に対処するための社内文化も組織も存在しない。私が思うに、部下がこの男の言うことを真剣に聞いてそのまま行動するとどうなるか、おそらく我々は初めて目撃しているのだ。更に悪いのは、このちょっとした実験が、この男が数十年に渡って自分の複数の会社でうまくやってきた後で起きていることだ。これらの会社では、社員が自分たち自身をこの男から守るためにかなりの労力を費やしてきたのだが、この男はあまりにナルシシストなのでそのことに気づけないのだ。
長い投稿になったのでついでにイーロンについてお気に入りの話をしよう。ある日会社で、今日はイーロンの誕生日なので強制参加のサプライズパーティを食堂で行うという一斉送信のメールを受け取った。おそらくイーロンも同じメールを受け取ったと思うのだが、ともかく、我々は食堂に行って照明を暗くして待っていた。イーロンは（まだクビにしていなかった）秘書につれられてやってきて、私たちが待っていたことについて嘘の驚きと感動を大げさに表現した。そしてケーキが運ばれてきた。
ここで、あなたが今までに見た中で一番大きなペニス型のケーキというものを想像してみてほしい。奇抜な性的なケーキの王様といったやつだ。ただし、それは砂糖で白く覆われていて、きんたまの部分は炎と煙に見えるような模様になっている。これがイーロンの「ロケット」誕生日ケーキだ。
生きている限り、あの場にいた人々の表情を私は忘れないだろう。ほぼ男のエンジニアばかりの暗い室内で、イーロンが願い事をしながら先端にナイフを入れた瞬間を。
「Tumblr、マストドンと接続へ。分散型SNS標準プロトコルを採用し、Twitterからの脱出受け入れ強化（CloseBox）」のブコメページ
https://b.hatena.ne.jp/entry/s/www.techno-edge.net/article/2022/11/22/522.html
Mastodonが実装されたとき投稿キーワード検索や引用リツイートなどの弊害を創始者のオイゲン・ロチコは問題視し実装しなかったという経緯があります。
投稿キーワード検索や引用リツイートの弊害とは何か？を現在のTwitterと比較して考えてみると興味深い気付きや、その気付きからMastodonの現状を考えてみると良いかも知れません。
今のところActivityPubネットワークを全文検索できるActivityPub互換SNSは存在しませんが全文検索できる検索サービスは存在するものの制限付きです。
仰るとおりでActivityPubプロトコルは正確性を廃してイメージだけで伝えるならばE-Mailネットワークへ近く、Mastodonを中心に流行る流行らないと議論されがちですが、実態としては物凄く極々小さなサービスであれActivityPub対応サービスが増えていくと時間と共にActivityPubネットワーク参加者が増えるという建付けになっています。
技術的な面に興味のない普通の平均的一般人からするとActivityPubネットワークはある日突然目の前に現れる巨大なネットワークになっている可能性が少なからずあります。
ちなみにActivityPubプロトコルが抱えている問題も個人が設置する小規模サーバーだと24時間動作保証がない、スパムメッセージなどを代表にE-Mailネットワークと一部同種の問題を抱えています。
逆に言えばE-Mailネットワークで用いられている解決手法を応用できるという意味でもあります。
必要リソース削減は常に必要とされるものですが、Mastodonは個人規模であればRaspberry Pi 3でも動くので思いのほか軽量です。
ただしRuby実装なのでC++実装などよりも軽いわけではありません。
むしろ「所属というアイデンティティ」を希薄化させて個々人のアイデンティティへフォーカスすることが是であるのではないか？という試みをしているものに「Fedibird」と名付けられたMastodonサーバーが存在します。
これは良い悪いではなく1つの例えとしての言葉ですが「アナタは相手が日本人だから関係性を持つのですか？」ということです。
再度言いますが、これは良い悪いという話ではございません。当然ながら「日本人であれば母語が日本語である可能性が高いし関係性を持ちやすい」と言う人も居るでしょうし「その個々人を気に入ったから関係性を持ちたいんだ所属など関係ない」と言う人も居るでしょう。
個々人の考えを尊重するからこそ良い悪いという話ではないのです。
ActivityPubプロトコルとは「ことば」です。
日本語話者同士であれば日本語で会話できるように、ActivityPubプロトコル対応SNS同士であれば別サービスとして成立しているSNSは相互に通信しあえるのです。MastodonはそのActivityPubプロトコルに対応しているミニブログSNSなのです。
ActivityPubプロトコルに対応しているWebサービスはMastodonだけではありません。
例えばYoutubeにような動画共有サービスのPeerTubeや、Instagramのような画像共有サービスのPixelFedはActivityPubプロトコルに対応しており、ミニブログSNSのMastodonのタイムラインにはPeerTubeに動画やPixelFedの画像が流れてきます。
そしてそれら動画や画像へ対してMastodonからコメントを送信することができるのです。
Mastodonのタイムラインに流れてきたPeerTube動画へコメントをすると、大本のPeerTube動画のコメント欄にはMastodonから送信されたコメントが掲載されるのです。
PeerTubeへ動画を投稿した動画主はMastodonから送信されたコメントを見てリプライします。するとMastodonでそのリプライを受け取ることが可能で、コメント主はMastodonでリプライを見ることが出来るのです。
ActivityPubプロトコルは対応しているとWebサービスの垣根を超えてコミュニケーションを取れる共通の「ことば」なのです。
そして今回その「ことば」にTumblrが対応したことで、TumblrはMastodonのほかPeerTubeやPixelFedなどともコミュニケーションが取れるようになりました。
TumblrのタイムラインにはMastodonの投稿が流れるようになり、コメントやリプライをTumblrから付けられます。
ただ実際のところ、Tumblrオリジナルの機能とActivityPubプロトコルの規格へどのように整合させるか？というのはわかってません。
理由としてはActivityPubプロトコルの規格はかなり柔軟な仕様で定められておりActivityPubプロトコルの規格には「解釈の余地」があるからです。
仕様として解釈の余地がない「厳密性」はそこまで高くないのでTumblrがどのようにActivityPubを解釈してくるか？というのも注目ポイントだったりするんですね。
もし他に何か疑問点があれば気が向いた時に答えるかも知れないので気軽にどうぞ。
https://www.itmedia.co.jp/news/articles/2211/21/news144.html を見て思い出したので、供養のために書いてみる。
当時、Webサービスの開発会社に勤めていてサービスの開発を行っていたが、特にインフラまわり、メール配信システムあたりを担当していた。
今でこそSaaSがたくさんあるが当時はSaaSを使うのはあまり一般的ではなく、自前でMTAを立ててサービスのメールを配信するのが一般的だったと思う。
MTAの自前運用の苦労はいろいろあるが、その中でも避けられないのがバウンスメール、つまり何らかの理由で配達できなかったメールの対応だ。
メールアドレスの間違いやユーザーの退会、大量送信でBANを食らったり、送信元IPがブロックリストに載ってしまって受信を拒否される…等々。
特に3キャリアは送信制限が厳しくて苦労した。ドコモは特定接続サービスという、みかじめ料徴収みたいなサービスをやっていたが、いまでもあるんだろうか？
そういうわけでMTAのバウンスメールを監視するのが日常的な作業になっていた。
監視ツールを使ってモニタリングはしていたが、それはそれとしてMTAの送信エラーログを見て問題がないか調べるということも毎日行っていた。
別にドコモ宛のバウンスは前述の通り送信制限やらユーザー不明やらで珍しいことではないが、そのエラーログではなぜがGoogleがエラーメッセージを返していた。
「はぁ？」となって dig mx を実行するとたしかにGoogleのMXサーバが出てくる。
頭の中に「？」がたくさん浮かんでしばらく画面とにらめっこしていたが、よーくみると「docomo.ne.jp」ではなくて「dokomo.ne.jp」になっていることに気がついた。
しょうもなー、と思ってnmapでポートスキャンをしたら、80か443が空いていたのでホームページをブラウザで見てみると、なんか個人っぽいシンプルな感じのホームページが表示された記憶がある。
そのことは悪意のある人間がdokomo.ne.jpを運用しているわけではない…と思えたのでそのまま放置した。
しかし、後日、気になって別のキャリアの一文字違いのドメインを調べたら、MXがあるドメインがそれなりにはあった。
結構なメールがそれらのドメインに吸い込まれていったように思うが、今となっては調べるすべもない。
whoisを調べた限り、過去はともかく現状ではdokomo.ne.jpを運用している人間はいないみたいだし、多分もう取れないように思うが
