  |
はてなキーワード: デファクトとは
「携帯」は浸透してないでしょ。「ケータイ」だったよね。今はさらに「スマホ」に取って代わられたけど。
この類の「って略すな問題」はMMORPGとかWikipediaとかUSBメモリとかいろいろあるけど、
デファクトはデファクトスタンダードと略すがデファクトでしょ、とか言ってる奴が同じ口で、
どういう場面でどう使ってるって言えないわけで。
それを法令に準ずることとは別の標準があってそっちをやることだ、とか
馬鹿すぎると思わない、説明の仕方？
で、その概念的な所を使う場面を聞いてるんだよ。
元増田の一番最初の話も、そもそも「デファクト」とか全く関係ないし、
ってか「スタンダード」の使い方すら違う。
ただ単に何処が主流か、とかだろ。Main streamとかだろ、使うなら。
あの例でどこのサイトが標準ですか、なんて日本語じゃ絶対わない。
カタカナだから分からんくてなんとなくかっこよさげだからそれっぽく使ってるだけ。
お前が「法律破る」と取れる話をしたからなんでそんな話したんですか？
という問なんですが、それにお答えいただけませんか？
そこを矛盾なく説明していただけませんか？
えーとさ、お前馬鹿なの？
だからなんで「破る」前提なんだよ。
法令と違うものが「デファクトスタンダード」としてお前の会社の中で
なってるなら、それは法律を「破ってる」んじゃねーか。
法律で手順までは決まってないけど、みんながこの手順で処理している、っていう標準はありうるだろうがよー。
手順が他で決まってないんだったら、それが単なる「標準」じゃねーか？
理解できねーのかクソが。
どこまで馬鹿なの？
ってお前が言ってるんだが？
（等）で逃げてるが、それを前面に出したからには
少なくとも「法令」で処理することとしてることに対し、
「みんながしてるから」という理由でそれを破ることがあるってことだよな？
そうじゃなきゃ、「ゲームなどで」とにしないと日本語がおかしい。
それとももう今はりかいしちゃったけど今認めたら負けちゃういやだーぼくは負けないー最強なんだもん、なのか
どれなのか教えてくれない？
「その手続きはこの手順で処理するのが標準ですよ」
という時
「デファクト」で「デファクトスタンダード」のことだって、増田もわかったんだよね？
コレ1回きりじゃないから。
始めて見た時には何のことやら分からなかった。
デファクトななんなんだ、で。
デファクト自体は英語じゃないけど英語の会話の中じゃある程度使う。
それをスタンダードと必ずセットだなんて思わない。
あほらしすぎる。
わかんねーなら使うなよ。
デファクトもクソもねーだろ。単に標準って言ってりゃ済む話じゃないの？
増田が「でふぁくとすたんだーど」って言ってる話で、デファクトスタンダードだけど「標準」、とは言い切れないことなんて今までにあった？？？
でもさ、「デファクトスタンダード」なんて日常会話でまず使わないじゃん？
プログラマとかIT系の人は仕事上の会話だか文書だかで割と使ってて、社内とかでは「なんとなく略す」ようになったんじゃない？
で社外でもつい使っちゃうとか。
企画書・提案書なんかだとたまに使うんじゃないかなぁ。
「デファクト」で「デファクトスタンダード」のことだって、増田もわかったんだよね？
確実にさしてるように思えるけど。
それとも他の何かと混同しそうになった？
少なくとも俺は他に誤解されそうな選択肢は思いつかないなぁ。
いやね、「携帯」みたいに一般の人が何となく使う様になってなんとなく略す、っていのはいいよ。
そりゃそういうのも沢山あるさ。中には気持ち悪いのもあるけども。
でもさ、「デファクトスタンダード」なんて日常会話でまず使わないじゃん？
ってか、そもそもデファクト自体は英語でも無いから授業で習うものでもないじゃん？
で、そんな余り人が使ってるものでもない中で、
で、それ見て何も考えずに真似してみたり。
ヘタすると「デファクトスタンダード」って意味も全く分かってない。
「携帯」って言ったら携帯電話を確実にさすけど、それともやっぱりぜんぜん違う。
そういう気持ち悪さ。
なんで「携帯」で電話のことになるんだ、「携帯○○」は他にもあるだろ、って突っ込んでた人が初期にはいたけど、浸透しちゃったよね
なんで「デファクト」で「スタンダード」なんだ、って気持ちは分かるけど日本人の日常会話で「デファクト」つったら99％以上「スタンダード」だろうし
省略形だと思えばまぁ、そんなもんかとも思う（俺は使わないけどね）
…個人的には、「defact」とか「difact」みたいな単語かと思い込んで「ディファクトゥ」（アクセント「ィ」の上ｗ）みたいな発音する奴の方が気持ち悪いｗ
ぷろぐらまーとかに多いよね、真面目に勉強とかしてこなかったから英語すらまともに出来ないのに、
ぷろぐらむ書いてるとなんとなく英語出来る様な気になって。。。
んで、さらにカタカナを色々見てるうちにしっかりとした定義も知らんと使う。
最近ホントよく見るのが「デファクト」だよね、とか言ってるバカ。
http://q.hatena.ne.jp/1406632587
ここではそもそも論、最初の「デファクトスタンダード」とほざいてるバカが意味をよく知らんで
「スタンダードのぷろぐらまのカッコいい版」程度にしか理解してないだろうな使い方だけど、
その後で「確かにデファクトですが」って。。。
アホか
ほんとキモイ。
ふむ、「学会に論文を出す」とな。。。トップカンファ、って最近の日本馬鹿ウェブ業界では流行ってる日本語英語なんだろうか？
（ちょっとまえに「これはデファクトになりつつある」という言葉を使った記事が合って誰も突っ込んで無いまま結構人が呼んでたみたいなんだけど、
プレゼンスとか、普通に使うのか？なんで存在感じゃダメなん？プレゼンスを大きくしろ、とか言うこと、会議で言うん？？？
どういうこっちゃねん。
話全部むちゃくちゃすぎておもろいなｗ
益田って妄想記事ばかりでビビる。そしてそれを賞賛するトラバ、ブコメが多くてホントビビる。
みんな夢見てんのなぁ。。。
でもそれは、お金には本質的には価値がないと言っているようなもの。
お金があることで、信用どうこうでなくお互いを信用できて通商できる。 物の価値は物を見る目が無いとダマされるけど、お金の価値は誤魔化しようが無いので、お金で取引すればよい。 となるから。
社会常識もこれと同じで。 時間を守ったりといったものを守ることで交渉できる。
② 社会性を叫ばれるとうざいのは何故？
社会人としての常識 などと言われると非常にいやな気分になる。 そんなもの本当には価値が無いというのは少し考えれば分かるから。
もちろん、心の問題では本質的には価値が無いけど、お互いが交渉するために必要だから身につけろ、というのは理解できる。
だけど、発言してる人が、『社会性がないヒトは軽蔑します』 のような感情や人間性を叩くような事を言うのが気に入らなくなる。
そんな根拠の無いものでヒトを判断するのはおかしいやん、と感じてしまうから。
逆に、それをやられてしまうと、 『あんた社会常識で俺を判断するけど、それをやってる時点で人間の心についてまともに考えたことが無いの丸出しやン。 なんでそんな人が人間性がどうこうっていうの？ おかしいやろ』 となってしまう。
③ 本当の人間性
文学で、まあなんでもいいんだけど、主人公はたいてい社会性が無い。 ドストエフスキーでもチェーホフでもなんでもいいんだけど。
そういうのは社会性を余り問題にしていないというか、むしろ社会性でヒトを判断するのは危ないみたいな感じになっている。
国家に裏切られたヒトとかが、なんでだろう？ と考えた末に、そういう考えになるんだろうと思う。
それをそのまま肯定してるのがたいていの文学のように思う。
と思うし、実際そうなってるようなので、だからこそ、『社会人としての常識が守れないのは人間性が無い、他人の事を考えられない自己中心だ 』 と言われると、 『あんたは心を学ぼうとしたのか？ なぜ根拠も無いのに否定するの？』 となる。
お金が物の真贋を問わなくしたように、 社会性が人間の心の真贋を問わなくしてしまった。
俺の考える理想の流れは、OSは有志が作ってオープンソース。世界中の有志または企業が問題修正してメンテ。自己責任で無料で使用可。営利企業から購入すればサポートが受けられる。Linuxと全く同じ状態。ていうかLinuxでいい。LinuxがPC界におけるデファクトになれば全く問題ない。
今何故そうなっていないかと言うとMSが強大な力で妨害していたからに過ぎない。その力がなくなれば、Linuxが広まってソフトもハードもそちらに対応するように流れる。
「もうOSは儲からない」となってMSが撤退、Linuxがデファクトになった世界が、健全なPC社会だと思う。そういう未来が来て欲しい。一営利企業がOSを牛耳るって絶対よくないよ。
結構昔からこの手の要望はあったと思うけど、100文字のまんまだよね
でもさー、今は140文字がある種のデファクトでしょ？
そこに不足という形で合わせてないのはダメダメだと思うし
文字数多い方がコメントの質も良くなるだろうし
誰も損しないと思うんだよー
というか物議醸したリニューアルだったけど結局どう落ち着いた？
ある程度、期間経つと冷静な見方も出来るって言うじゃない
自分は「嫌々ながらも慣れはした」という感じです
今は「元に戻して欲しい」より「軌道修正はして」な気持ちが強い
反省会というか考察というか、そういう記事があったらいいのにな
てか、「いやいや140文字いけるよ」だったらゴメン
わかっている人には今さらなことなんだろうけど。
AWSを最近調べていて、すげーなーと感心するのだけど、これって、かつてIBMが作った「PC」の21世紀版になるのだろうか。
ご存じのようにIBMは80年代にパソコン事業を手掛けて、その際に独禁法などの絡みで仕様を公開する。そのために周辺機器文化が生まれるが、その仕様に合わせた互換機ブームが起き、これに乗じてMSやIntelが躍進、動きの遅かったIBMは、コンパックなどの新興事業者に出し抜かれ、一転大赤字を生む。ここで作られた標準は今のパソコンの原型となって今に続き、世界中に普及することになりましたとさ。
もしかすると、AWSもこれと同じように、「クラウド」という分野でのデファクトになって、Amazonが作った仕様が後々までコンピュータの標準として利用されていくのではないかな、と。実際に、AmazonのAPIに合わせて他社がクラウド事業を行っている。IBMと違うのは、Amazonがスピードを失うことなくサービスの開発や料金の改定を行い、他社が追いつけない速さで成長しているというところか。もしくは、Intel CPUなどの必須のパーツがなく、「庇を貸して母屋を取られる」みたいなことが起きにくいところとか。
スマホ、タブレットがメインのデバイスになり、ネットワーク指向のソフトウェア開発が必須となる現在、クラウドで開発を行うことが標準となっており、ますますインフラからアプリケーションまでインターネット上に置くことが普通になっていく。ここで、Amazonは、かつてのIBMのように、始祖としての立場をとることができるようになるのだろうか。
カネの力ねぇ。
デファクトになるにカネは必要だが、カネを得るには良い所がなきゃダメだろ。
つか、言語言語ってやる事出来る事は五十歩百歩だろ。要はやり易いか否か。
後は文法が単純単機能なことだな。言語としては単純で、標準ライブラリが多機能でそっちで何でもできる。それが一番。
無駄に文法多くて自由に書けるとかいったらカオスってクソになってくに決まってるだろ。
後付けライブラリが沢山、自由に選べる作れるってのもカオス。自由って何求めてるの？
C++はCの資産あるうちは良かったよ。でもそれだけ。あとに碌なライブラリ残さなかった。
javaはライブラリに力入れてたし、文法もまあまあすっきりしてる。PHPも近い所はある。
javascriptはダメだ。ただDOMがある、それだけだ。
pythonはライブラリがそこそこいい。ただ、言語自体は下手に色々ありすぎ。
それでもperlよりマシ。あれはCとshしかなかった時代だからこそのもの。
perlの後釜なんにするの？python以外あるの？つか、日本に選択権ないって言ってるじゃん。
つか、javascriptはDOMなきゃ意味ないし、javaはVMなきゃ意味ないし、PHPはHTMLなきゃ意味ないし、
C#はMicrosoftなきゃ意味ないし、Objective-CはAppleなきゃ意味ないし。
棲み分け出来てるのに、それ以外どうするの？
つか、SQLどうにかしろよ。
そもそも言語としての良さとその言語のシェアとの間に関係なんて全くねーだろ。
関係ある(べき)と思ってるところが根本的に間違ってる。
デファクトになったもん勝ちだし、何がデファクトになるかは金持ってる奴が決める。
(特に日本の)エンジニアは金持ってねーから持ってる奴の言うこと聞くしかないだろ。
そういうことだよ。
Pythonが一部でデファクト化してるのはGoogleのパワー(=金)が結構効いてる気がするけど、日本じゃ無理だろそんなの。
C++は自業自得な面もある気がするけどな。とにかく高速で自由度が高くてオブジェクト指向もできるだけで良かったのに、
エンジニアの自己満で凄まじい量のカオスを積み上げてそびえ立つクソになった。
金持ってる奴は誰もそんなの求めてないのにな。
寿司なら認定出来るんじゃね。
そういや、こんな記事があったな。
http://business.nikkeibp.co.jp/article/manage/20091127/210774/
アメリカに住む友人で「SUSHIが好き」というひとに、なにがいちばん好きか？ と聞いたときに「マグロ」「トロ」「イクラ」のような答えが返ってくることはまずありえません（ニューヨークやサンフランシスコ、ロサンゼルスなどの一部ではそうした「知日派」寿司ラバーが存在しますが、それは非常にわずかです）
はたまた筆者がシアトル、テキサス、シカゴ、デトロイト、ヒューストンの街角のSUSHIレストランにふらっと入り、筆者のようなアジアの顔の客がウェイターに「この店のSUSHIは何がお勧め？」と聞いても、答えは同じです。
1位は、圧倒的に「Spicy Tuna」です。さきほどのサイトのSUSHIメニューの下部Hand Rollsのリストを見てください。Spicy Tuna, Spicy Shrimp, Spicy Scallop, Spicy Yellowtailと「スパイシー」モノが最初に4つズラッと並びます。友人に尋ねても、ウェイターに尋ねても、「スパイシーツナ」を最初に言わないヤツはむしろSUSHIのモグリと断言しても良い（笑）。
実はこのスパイシー＆クランチーな「他者」、アメリカに住む日本企業の駐在員（こうした方々は、こちらのSUSHIレストランに入っても敢えて日本流の握りや新鮮なネタを選び出して食します）も見向きもしないうちに、さらに妙な「進化」の現象を見せているのです。
それは、メニューが「世界共通」に出来上がりつつあるという事実です。
（中略）
アメリカの大都市やロンドン、パリ、シンガポール、香港、上海などのSUSHIレストランにおいて共通で見かけるメジャーのロール、トップ5は下記です。
（中略）
このようなメニュー名がどこから発信され、いかにして七つの海を渡って人口に膾炙し、多少のアレンジはあるにしても各メニュー共通の具材が使われるようになったか、興味をもつ考古学者の方の登場を待ちたいと思いますが、ビジネスマンにとって大切なのは、少なくとも日本人抜きでこの「デファクト」スタンダードのフォーマットは成立し、市場を流通しているということです。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
