はてなキーワード: タイムスタンプとは
などなど。今だと個人のサイトよりTwitterやFacebookのほうがいいのかしら。
http://anond.hatelabo.jp/20150723161942
タイムスタンプを見るとツイッターで反応したわずか8分後に増田が投稿されているけどまさかそんな馬鹿なことは。
かのせサンダー(唐突な大振りネタ) / 他128コメント http://t.co/iAth5CB4hx “『GATE』は2chまとめサイトを鵜呑みにしたような世界観&政治観がきつい - Togetterまとめ” http://t.co/aFsJb7vUvE— 三沢文也@こっちは本気で遊んでるんだ! (@tm2501) 2015, 7月 23
以前に青二才さんが書いたって自分で認めてる増田と雰囲気がよく似てるけどまさかそんな馬鹿なことは。
http://anond.hatelabo.jp/20150720104531
でもいくら青二才さんがkanose嫌いで粘着してるからって増田で晒しなんて卑怯なことはしないよね。
その場合下手をすると下のずさんな記事も青二才さんによるもの?まさかそんな馬鹿なことは。
業務で作成するワードやエクセルのファイル名の最初に20150515のような8桁の数字を入れることは、推奨されることが多く、事実よく行われているが、これは本当に意味あり役立つことなのだろうか。
http://anond.hatelabo.jp/20141130202457
はてな匿名ダイアリーは、その名の通り匿名の日記サービスです。説明するまでもありませんが、匿名というのは誰が書いたのか分からないということです。
しかし、誰が書いたのか分からないというのは、なにも匿名サービスだけの特徴ではありません。はてなや、Twitterや、Facebookなどでも、同一アカウントだからといって、同じ人物が書き込んでいる保証はどこにもありません。同一アカウントだったら同じ人が書いているという前提でネットは成り立っているのです。本当に誰が書いたのかを知っているのは当人だけで、基本的に第三者はそれを確認することはできません。
もしかしたら、回線の向こう側にいるのは、知らない誰かなのかもしれないし、ただのプログラムなのかもしれないし、それとも、もっと別の何かなんてことも――。
今年の夏、私が体験した話です。
八月の中頃、時刻は夜の十一時すぎだったと思います。とても暑い夜でした。いつもよりクーラーの設定温度を下げて、扇風機を首振りさせず、直接身体に風を当てるようにしていました。
この時、私は特に何もしていませんでした。メインPCの前に座って、Steamのゲームを触ったり、Twitterのタイムラインを眺めたり、はてなブックマークから気になる記事を読んだり、ゲーム配信を見たり、色々やってはいましたが、ただ暇をつぶしていただけ、これといった目的はありませんでした。
はてなブックマークのリンクをたどっていく内に、はてな匿名ダイアリー、いわゆる増田の記事を開きました。記事は程度の低い釣りでした。反応するのも馬鹿らしいので、私は早々に読むのをやめて増田のトップページを開きました。ざっと流し読みして、面白そうな記事を探しましたが、何もありませんでした。3ページほどで見切りをつけて、何か文章を投稿しようと思ってログインしました。
「あれ?」
一人なのに思わず声をあげてしまいました。日記の一番上に見慣れない記事があったのです。
まんまんまんまるまんこ
なんでちんこはおおきくなるの
それはまんまんまんこへいれるためさ
レッツピストン!
ぬっぷぬっぷぬぷぬっぷ
ずっぽずっぽずっぽずっぽ
どぴゅどっぴゅどっぴゅっぴゅー
当然、トラックバックもブックマークもついていませんでした。タイムスタンプは朝の六時半過ぎです。その時間は寝ているので、私が書き込んでないことは明白でした。
パスワードが漏れて不正ログインされたのか、もしくは、増田のシステムにバグがあって別の誰かの文章が表示されているのか。
私はF5キーを押してリロードしてみました。画面に変化はありません。ログアウトして、再ログインしました。先ほどの文章はまだあります。表示のバグではないようです。
そもそも、はてな匿名ダイアリーは古いシステムです。今になってこんなバグが出てくるとは思えません。つまり、不正ログインされた可能性が高いということになります。
私は、すぐにはてなのアカウントのパスワードを変更しました。ひとまずこれで様子を見ようと思いました。
増田に戻って自分の日記一覧を見ると、あの下らない文章が居座り続けています。だんだんと腹が立ってきました。はてな側に私が書いたと思われるのが苦痛でした。私は編集画面を開いて、何のためらいもなく削除ボタンを押しました。
一秒程度の通信待ち時間が入って、日記の一覧画面へ戻ります。あの文章は消えていました。しかし、一番上には別の見覚えのない文章がありました。
消すなよ
たった四文字でしたが、私は呼吸もまばたきも忘れ、数秒間、その文字から目を離すことができませんでした。少し視線をずらしてタイムスタンプを確認すると、たった今、PCの時刻と同じ数字が表示されています。
編集画面を開いて、削除ボタンを押し、日記一覧画面へ戻るまで、せいぜい五秒程度しかかかっていないはずです。たとえアカウントを乗っ取っていたとしても、私が日記を削除しようとしたことを察知してから、五秒以内に「消すなよ」と日記を投稿することができるはずがありません。
こんなの人間業ではありません。
人間ではない。
急に肌寒くなりました。鳥肌が立っています。私は扇風機とクーラーの電源を切りました。
ウィルスに感染してPCが乗っ取られている可能性も否定できません。私はメインPCの電源を落としてMacBook Airの前へ移動しました。
私は増田にログインして自分の日記一覧ページを開き、「消すなよ」の編集ページを開いて削除しました。メインPCが乗っ取られていたのなら、こちらのマシンからの削除に反応できるはずがありません。
そして、一覧ページに切り替わり、
消すな
新しい書き込みがありました。
心臓が激しく鼓動しています。指先が震えてきました。私は混乱していました。電源ボタンを長押ししてmacをシャットダウンさせました。
iPhoneを持ってベッドに寝転びました。ブラウザから増田にログインして編集ページを開き削除。これでもう大丈夫だ。私は根拠もなく確信していました。
ページが切り替わりました。
お前を消すぞ
私はiPhoneを投げ捨てました。そのままベッドで震えながら朝を迎えました。
さいわい、私が消されることはありませんでした。
これを機に、私はネットをやめました。通販ができないのは多少不便でしたが、また同じようなことが起こるのを想像すると、恐ろしくてネットへ接続する気になりませんでした。仕事中も必要な情報を検索する以上のことはしませんでした。個人のメールもブログもSNSも全部放置していました。
今回、私がこうしてネットに繋いで書き込んでいるのは理由があります。
先日、実家から電話がかかってきて、メールぐらい確認しろと怒られました。しかたなく、私はネットに繋いでGmailを開きました。山のようにたまったメールから実家からのメールを探して処理しました。
ふと、はてなから来ているメールに目が止まりました。はてなスターのレポートです。スターが押されたURLからそのブックマークは、ごく最近にブックマークされたことが分かります。
私は愕然としました。
私は八月中旬から今まで、ずっとネットに繋いでいなかったのです。だから、私のaoi_tomoyukiというアカウントは、ずっと沈黙しているのが当然だと思っていました。しかし、私のアカウントはネットに繋いでいなかった期間もそれまでのように、私が書き込んだかのようなコメントを残しているのです。
八月にアカウントを乗っ取った何者かが、ずっと私のふりをして書き込んでいたということでしょうか。なぜそんな意味のないことをするのでしょう。それに、あの時の「消すな」と書き込んだ早さは、人間がやったとは思えません。
いったい、何者が私のアカウントを乗っ取ったのでしょうか。
その何者かは、私が繋いでいない期間、ずっと私の代わりに書き込んでいました。私がいなくても、私のアカウントは平常運行していました。ということは、私は必要なかったことになります。私がいなくても、私のアカウントは活動し続ける。
お前を消すぞ
私のアカウントは私がいなくても存続できる。
私が消えてしまった。
私は誰なのでしょう。
私が偽物なのでしょうか。
おしえてください。
9/19、現地時間で深夜0時を周る少し手前から異変は生じた。
全国各地に散らばっていたはずの電子妖精のトラッキング情報が同一座標を差し始めた。
そして、時間を少し置いて、タイムスタンプ以外全く同一のデータが送られてきた。
まるでDDosのように、一分間に40というスピードで、的確に。
20^3という重さが空白のテーブルを食いつぶしていく。
数の暴力と時間推移がもたらすマトリクスは傾斜をなだらかに描き、
頂きをみることも、それに至る歩みをも、依然とやめようとはしない。
午前7時、朝のテレビは高らかに告げる。
そして、林檎は投げられる。
地図上の侵略拠点から、戦士達と"林檎"の個数がグラフィックスとともに天高く聳え立つ卒塔婆のように伸びていく。出陣の時間だ。
彼らはやがて、あらゆる戸口の鐘を鳴らし、押し入り、一口齧った林檎を証明書として渡す。そして高らかに叫ぶのだ。今ここで一人の人間が林檎帝国に魂を売ったと。その声は電子妖精を通じてモニターに犇き、占有していく。
林檎中心。
一年に数回、泡のように現れ、消えていく戦士達の母艦の名前である。
午後10時過ぎ、お祭りはいつしか過ぎ、蜘蛛の巣のようにマッピングテクスチャを這い回っていた戦士達と電子妖精達は帰る場所に帰ってきた。体力を限界まで減らし、最後に蚊の鳴くような声で終了の時報を告げると電子妖精は己の揺りかごに帰っていく。翌日の5:00にマスターの声に起こされるまでの束の間、彼女達は浅い夢を見るのだ。
最初に言っておきますが、当然ながらSTAP細胞の存在には極めて否定的で、関係者を擁護する気持ちはありません。
いまさらですが、早稲田の学位論文問題について思うところがあったので書きます。
私が書く内容は部分的には全て他者の意見としてさんざん既出ですが、全体を通して私と同様の意見を見たことがありません。
結論からいうと、私が望む結論は、
1. 小保方の学位は取り消す
2. 博士課程に復学させたうえで再度の学位審査とそれにかかる指導を無料で行う(姿勢を示す)
3. それでも下書きだと見え透いたウソをつくのなら退学にする
(4. たぶん結果的に小保方だけ学位剥奪、他のコピペ博士は再審査で生き延びる)
当該学位論文が博士の学位に値しないことは明白です。したがって学位は剥奪すべきです。
学位は資格に準ずるものですから、過失の有無を問わず温情措置はあり得ません。
しかしながら、博士号取得時点でまともな英語論文を自力で執筆できる大学院生が、特に理系の実験系で、現実問題としてどのぐらいいるでしょうか。
私の大学は「出版された査読付英語原著論文に日本語要約を添えたもの」を学位論文と認める規定でしたので、学位論文自体には苦労しませんでした。
一方でその根拠となる査読付英語原著論文については、指導教官によって徹底的に修正されました。面積比で赤:黒=8:2ぐらいでしょうか(笑)。
それでも兄弟弟子よりは大まかな文章構造がはるかに残っていて、褒められたぐらいです。
私の大学は超一流大ではありませんが底辺でもないので、感覚としては博士号取得前後の一般的な研究者はせいぜいマテメソとFigure legendを自分で書けるぐらいでいーとこじゃないでしょうか。
したがってこの問題の本質は、大学側によるネグレクトであって、書いた小保方よりも、あの論文を通した教授会と、あの論文を提出させた指導教官の責任が重いと考えます。
もちろん、いくら下書きとはいえ序章をまるまるコピペするとか、試薬会社のカタログからとった図を流用するなんてもってのほかです。
ですが普通は指導教官が気付いて一喝すればいい話です。「おまえふざけんなよ。」で済むところでしょう。
だから単純に学位を剥奪して、「学位が欲しいなら入学し直してもう3年下積みしろ」というのは理不尽に感じます。授業料の対価としての指導を怠ったのは学位の発行側なわけですから。
学位の取り消し、留年扱いで復学、その間の授業料無料、というのが落としどころだと思います。
しかしながらその上で、製本された論文が下書きであるとか、タイムスタンプが直前のファイルを完成版と言い張り、しかもそれも不十分とか、その辺もろもろによって、「品行が悪いことを理由にして退学」にすればよいでしょう。
そうすれば早稲田ひいては日本の博士号の価値はほどほどに守られ、すでに研究職についている他のコピペ博士の立場も保全されます。
いかがでしょうか。
内部犯行だったとのこと。
ではなぜ内部犯行がおきたのか?そこを調べないと同様の事件は続く。
犯人はいつもの業務と同じように顧客データベースにアクセスして、難なく入手した。
ではどうすればよいのか?
以下のようにすればよい。
・個人情報を扱う端末は幾重にも認証が必要な特別な建物の中の特別な部屋に置いてある。
・USBなどメディアの持ち込みには、特別な許可を必要とし、内容を検査した上で使用可能。
・入室、退室の際には全裸になりケツの穴まで調べる。
・操作は必ずオペーレータ1名につき監視役の2名の最低3名以上で行われる。
・全ての操作は操作履歴に残し、なおかつビデオ(画面ビデオ、操作ビデオ)にも録画する。
・万が一漏れた場合に備え、ダミーデータを90%以上混入させておく(本物は10%のみ)。
・ダミーデータにはタイムスタンプを押した透かしを入れて、流出の時期、散らばりを容易に特定できるようにしておく。
・オペーレータ、監視役は個人情報取扱主任的な資格保持者のみに限定
・オペーレータ、監視役は既婚で専業主婦の妻と18未満の子を持つ男性のみに限定(家のローンがあればなお良い)
・オペーレータ、監視役は年収800万円以上得ている人物のみに限定(金が理由の流出は防げる)
このシステムを構築するのに数十億、運用費も年間数十億かかる。
今回の事件、仮に1000万人に5000円払ったとしたら、500億。
年数十億払って今回のような事故をなくし企業価値を上げるか、5年に1回500億払い企業価値を下げるか、どっちがいいのかは歴然。
ここ一ヶ月間私は気になって仕方がない。
もう一度言おう。sendとreciveだ。
誰かをお忘れではないですか。
(゚∀゚)ラヴィ!!
reciveから逃亡していたのだった。
ところで、私はSEだ。IT業界の雑用係として名を馳せている。エクセルシートでレポートを書き、エクセルで調査表を作成し、excelで仕様書を修正し、Excelでソースコードを打ち込んでいる。エクセルでチャットに励むのも、エクセルに目覚まし時計を頼むこともエクセルでコーヒーを沸かすことも、、、できる。そんなエクセル戦士たる我が日々戦っているものはなんであろうか。難解なシステムか?不毛なレビュー会議か?睡眠時間か?……いや、どれもそうであるが、どれもそうではない。一番は誤字脱字、二番目は文言の不統一だ。レビューで誤字脱字が一つ見つかると平均して五分時間が伸びる。たった六つで三十分だ。鬼の首でも取った勢いで指摘する人もいれば、淡々と告げる人もいる。だが、これだけは共通している。間違えれば、確実に時間が伸びる。
そこは本質ではない、そこはレビューで確認してほしい点ではないんだ。内心でどう喚こうと、口に出していかに取り繕うと、誤字脱字の指摘にレビュアーは時間を最大限に割く。どいつもこいつもだ。修正は終わるところを知らない。
今いる場所もまぁ似たようなところだ。どこも一緒。だが、IFなんつー物騒なところにアホくさいスペルミス。これはどういうことだ?使用箇所は軽くgrep検索しただけで200行以上。ソースコードのタイムスタンプを見るに八年前はすでにこのフォルダ…ディレクトリ名を使用していた。
これだけ省略形?
今気づいた。
聞いていて、こっちが間違っているような気がした。何でたかが一ディレクトリの名前が違うことに義憤とも私怨ともつかぬものを燃やせばならんのだ。アホらし、アホらし。
その数時間後、仕様変更の連絡違いで30ファイルのエラーログを修正しなければいけないことをレビューで告げられて、闇の炎は再燃することになる。何の因果から、レビュー議事録を送ろうと開いたメールボックスには、TOEIC団体申し込みの最終案内が入っていた。
少なくとも八年前、ディレクトリ名にreciveと名付け、魔のレビュアーの監視を全て逃れて、見事システムに組み込むことに成功した名も無きエンジニアよ。私が今、敬意さえ込めた眼差しで見つめていることをあなた様は知る由もないだろう。人が多ければ多いほどいい。そうすれば、猫は犬に変わり、日本語はJanglishになる。あなた様は確かに、間違いを正しさへ変えたのだ。工数、信用、評価、どれも欠けることなく。
凄いよ、くそったれ。
幼稚で愚かな底辺SEの一人より。
見出しはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1288765389/232
232 :名無しさん@お腹いっぱい。:2012/03/25(日) 15:05:26.72 今月はじめ、職場に新しいPC(Pentium4の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSにオープン系を採用するのは 聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのは UNIXのインストールパッケージでした。 「うへぇ~、よりによってUNIXかよ」 デバイスドライバがない、コマンドが変・オプションがない、X環境が古い、 今の奴は日本語入力大丈夫なのか(Wnn/Canna/kinput2)、将来の64bit移行はどうなのか、 今時のネットで必須のflashのプラグインは存在するのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一CADなどのエンジニアリング環境が充実していたUNIXは大学など 教育機関に浸透していて、日本のUNIX界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去10年のUNIX界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPlamoでもDebianでもRedHatでもKondaraでも Slackwareでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1355909018/4
4 :名無しさん@お腹いっぱい。:2012/12/19(水) 18:44:07.79 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、複数マシンでファイルを共有するのは 聞いていたのですが、起動したマシンの/etc/fstabの項目に書かれていたのは nfsという文字でした。 「うへぇ~、よりによってNFSかよ」 ファイルロックすると刺さる、ファイルを消したのに.nfsXXXが残る、 今の奴はACL大丈夫なのか、ファイルのCapabilityに対応してるのか、 今時のLAN上で使ってもセキュリティは大丈夫なのか不安はつきませんし、 ユーザーが減ってるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一ローカルディスクかネットワーク上かの区別なく透過的にファイルに アクセスできたNFSは大学など教育機関に浸透していて、日本のストレージ界に 多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ファイルに書き込んだら所有者がnobodyに なっちゃったよとか、タイムスタンプがずれるよとか、NFSv4にしたらマウント できなくなったよとか、TCPよりUDPの方がオーバーヘッドが無い分速いはずだよね などと、鯖管気取りの偏ったどうでもいい我侭を言いだし、 (だからNFS鯖にするんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のNFS界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではSambaでもNetatalkでもFTPでもなんでもいいですが 安定してユーザーが多いファイル共有システムにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1351627596/3
3 :名無しさん@お腹いっぱい。:2012/10/31(水) 10:57:28.82 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSに*BSDを採用するのは聞いていたのですが、 搬入されたPCのダンホール箱に乗っかっていたのはFreeBSDのインストールパッケージ でした。 「うへぇ~、よりによってFreeBSDかよ」 カーネルが変、日本語環境がない、ソフトが変・揃ってない、今の奴は 日本語文字コード大丈夫なのか(utf-8)、x86_64環境は大丈夫なのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一PC98環境が充実していたFreeBSDは大学など教育機関に浸透していて、 日本のFreeBSD界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ポーツ(笑)でemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかとかなどと、 鯖管気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のFreeBSD界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではUbuntuでもdebianでもFedoraでもRHELでも OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1209056071/887
887 :名無しさん@お腹いっぱい。:2012/10/21(日) 11:56:55.61 今月はじめ、職場に新しい組み込みマシン(ファン付きだけど結構省スペース構成)が 入りました。多分私が開発全般をまかされそうな雰囲気です。業務的にとある 構造分析やシミュレーションなど行う必要があり、プログラムにアセンブラを 使用するのは聞いていたのですが、添付のサンプルソースコードからチラッと 見えたのはsethi %hi(hoge),%o0という命令でした。 「うへぇ~、よりによってSPARCかよ」 長くなるバイナリーコード、奇数アドレスワードアクセス不可、使いにくい レジスタウィンドウ、今時の素早いコンテキストスイッチに対応できるのか不安は つきませんし、今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にSPARCに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、32bitCPUでRISCでM68K系よりも高速で動作したSPARCは 大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、16bitイミーディエイト値すら1命令でロード できかないのかよとか、関数呼出しのたびになんで約100バイトもスタックフレームが 要るんだよとか、フラグレジスタの読み出しがなんで特権命令なんだよとか、 %g0ってレジスタ値変わらないし壊れてるよ、初期不良で交換だよとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからSPARC使うんじゃ ねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去25年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://anond.hatelabo.jp/20120916100440
への返信。トラックバックってどうやんの?
>>「13:22」って書かれても、その時刻がどのタイムゾーンなのか、(略)いちいち確認しないといけない。
いいえ。twitterのAPIから返ってくるデータは常にGMTですので特定できます。
>>仮にニューヨークだとしてもスマホの時刻設定が十分正確なのかは、いちいち確認しないといけない。
>>新しいスマホは自動的にタイムゾーンをあわせてくれるけど、古い携帯や、簡素なノートパソコンだとあわせてくれない可能性がある。だったら、相対表記の方がわかりやすい。
いいえ。nowとか「3時間前」という表記はapiに入っていません。クライアント側で処理しています。
ので、パソコンの時間がズレていたら「3時間前」という表記も当然ズレます。
>>例えば、「サンフランシスコからスマホを持ってニューヨークへ飛行機で移動、その間に中央部の友達がツイートを投稿、それをニューヨークで降りてから閲覧」というシチュエーションを考えると、「13:22」とかいう絶対時刻表記よりも「3時間前」という相対時刻表記の方がわかりやすい。
前提
・サンフランシスコ(西部)はGMT-8。中央部はGMT-6時間。ニューヨーク(東部)はGMT-5。
・時刻は[GMTの10時:シスコ2時:中央4時:NY5時]と表記します。
・NYに到着した時のスマホのタイムゾーンはシスコのままorNYに修正済み。
・[GMTの 9時:シスコ1時:中央3時:NY4時]に私はシスコを出発しました
・[GMTの10時:シスコ2時:中央4時:NY5時]に友達が投稿しました
・[GMTの11時:シスコ3時:中央5時:NY6時]に私はNYに到着しました
その時twitter鯖に登録されるタイムスタンプは"GMTの10時"です。
さて私はNYに到着しました。到着時刻は[GMTの11時:シスコ3時:中央5時:NY6時]です。
スマホの時刻設定をシスコのそれのままにしてtwitterで友達の発言を閲覧してみます。
取得した友人の発言には「GMTの10時に投稿」と記録されています。
よってスマホは「2時に投稿」もしくは「1時間前に投稿」と表示されます。
同じく取得した友人の発言には「GMTの10時に投稿」と記録されていますので
スマホは「5時に投稿」もしくは「1時間前に投稿」と表示されます。
相対時間の表記が変わっていないのは、n時間前の計算がGMT時間で行われている為です。
スマホのタイムゾーンがなんであれ「今はGMT11時。投稿された日時はGMT10時」ですので1時間前の答えは変わりません。
あれ、絶対時刻を持ち上げようとしたのに相対時刻を持ち上げたみたいな形になってしまった。
相対時刻の優位性は分かった。でも強制しないでくれって主張に変わりはないし
http://anond.hatelabo.jp/20120511124327
論点1,論点2について。
レアケースとして、難病、特殊な性癖等、それ単体で自分で珍しい属性と思えるよって個人の特定が発生するという話になっています。人に寄っては「自分はそんな特殊な属性なんか持ってないその他大勢だから問題ない」と考えている人がいるかもしれませんね。また、武雄市市長は
僕が言っているのは、「5月6日20時40分、42歳の市内在住の男性が、「深夜特急」「下町ロケット」「善の研究」」を借りた。」ということそのものについては、個人が特定できない
と述べています。(http://hiwa1118.exblog.jp/15827483/)これを見て「この程度の属性ならば個人情報は特定できない。安心だ」と思っている人も多いかも知れません。
が、実際にはそんなこと無く、普通の属性の人でも、いくつかの条件を組み合わせていくと簡単に個人が特定できるよと言う話をします。図書館側から、CCCに対して、上記武雄市市長が挙げている情報が渡ると仮定した場合、ある程度の行動に法則性がある人であれば、かなりの確率で個人の特定ができます。
例えば、
これらはみな高確率で本人の特定が可能です。
簡単に言うと
これらはそれぞればらばらには該当する人間は多数います。しかし、これが組み合わさると(さらに5月6日20時40分に図書館を利用、タイムスタンプ情報が組み合わさると)どんどん対象は絞り込まれていきます。非常に尖ったそれ単体で個人を特定できる様な属性がなくとも、複数の属性が一致する人というのは少ないため、さらにそれを通常のTカード利用履歴データと照合すると、本人の特定ができてしまうと言う事です。
なお、私も武雄市の市政の問題と言うより、プライバシーやセキュリティの問題にのみ関心があるので、以下は架空の市「武雌市」を舞台としておきます。
武雌市立中学校に通う武雌太郎君(14)は、学校帰りに図書館に寄ることがあります。両親共に仕事が夕方シフトの仕事で帰宅も遅く食事も遅いので帰宅途中にあるファミリーマートで軽食を買って帰るのが日課です。
ある日、太郎君は図書館で本を借りました。この場合、図書館から出て行く情報は、仮に以下の様になるとします。
△月○日16時32分、14歳の市内在住の男性が、『暗黒神話体系シリーズ クトゥルー 第1巻』『這い寄れ!ニャル子さん(1)』を借りた。
次に彼はいつものようにファミマで買い物をします。するとこちらは以下の様な情報が記録されると思われます。
△月○日16:48分
会員IDxxxxxxxxx
購入品目
当然ながら後者のファミマの利用履歴にある会員IDを照合すると、登録時に申告した個人情報、氏名や年齢、住所、電話番号などと結びつきます。
この時、『時間16時台で、年齢14歳男性、武雄市内または周辺で使われたTカード履歴』と言う、図書館から得られる範囲の条件でTカードの利用履歴からデータを引き出してみます。利用状況にも寄りますが、この時点で確率的にそんなにたくさんが引っかからないと思われます。まず武雌市の14歳男性は国勢調査によると約300人でした。さらにこの中から、16時台に武雄市周辺でTカードを利用した人というのはどれだけのいるのでしょうか。
さらに「クトゥルーとニャル子さんを借りている事から、彼はオタクが好むアイテムを購入している可能性がある」としたとき、ヴァイシュスバルツ(アニメ・ゲームなどのキャラクターを題材にしたカードゲーム)を購入しているので引っかかります。こうなると、ほぼ間違いなく誰が借りたか特定ができてしまうでしょう。このオタク属性等と言うのはレアな属性でもなんでもありません。またこの他、例えばここで車好きでもいいし、スポーツ好きでもかまいません。そう言うありふれた属性で良いのですが、年齢と性別、時間と地理という条件が重なると、絞り込みの条件になって、特定がより簡単になっていくのです。
次に彼がまた同じ行動をとったとします。
図書館で本を借りて、ファミマで買い食いして以下の履歴が残りました。
△月×日16時28分、14歳の市内在住の男性が、『暗黒神話体系シリーズ クトゥルー 第2巻』『這い寄れ!ニャル子さん(2)』を借りた。
△月○日16:48分、会員IDxxxxxxxxx
購入品目
この時、前回と同じ条件『時間16時台で、年齢14歳男性、武雄市内または周辺で使われたTカード履歴』でTカードの利用履歴情報を引き出します。さらに、これを以前の記録の中から、ほぼ同一の行動パターンをとっている人物を引き出してきます。すると、ほぼ一人が浮かび上がってくるのではないでしょうか。
この時点で逆のアプローチが可能になります。つまり『会員IDxxxxxxxxがファミマを利用するとき、同一の属性の人物が同じ時間帯で図書館を利用している場合、高確率で同一人物である』と言う事が言えるようになります。これでファミマで利用が合った時、図書館から出された情報を検索すれば彼の利用履歴が作れる事になります。
さらに何回も似たような行動を繰り返します。するとどんどん彼の行動パターンができあがっていきます。行動パターンの積み上げにより太郎君を特定するための情報がどんどん積み上がっていきます。こうして積み上がった情報から、例えば彼がファミマを利用しなかったとしても特定が可能になっていくでしょう。「16時台に、同一シリーズのニャル子さん4巻を借りている。履歴から照合すると高い確率で会員IDxxxxxxxxの情報である」と判断することができる様になっていくのです。
武雌市内にある和平電機につとめている女性、小町花子さん(29)。在所は隣接する小町町で、勤務先の和平電機は毎週火曜日がノー残業デー、定時で退社する日と決まっています。協定でいつも1時間程度は必ず残業があるお仕事ですが、この日は17時に退社できるので、いつもこの日に用事を済ましています。
彼女は節約上手なのでポイントカードの提示を忘れません。Tポイントカードも例外ではなく、たくさんポイントを貯めるためにあちこちでポイントカードを使っていました。勤務先のある武雌市の図書館も利用しています。
この条件の場合、上記太郎君の場合のパターンでも特定が可能ですが、実はさらにそれより一発で特定ができてしまう可能性があります。それは、普段が彼女がTカードを使って作り上げた、行動パターンがあるから。
花子さんの利用履歴では、最近カメラのキタムラで高価なカメラを購入している情報、地元のTSUTAYAでカメラ関連の本を購入していたりする履歴があると、花子さんは最近カメラにはまっているようだ、と言う事が見えてきます。またガストではドリンクバーは2つのことが多いだとか行った情報から2人暮らしである事、一度名義を変更していることから結婚している事、ウエルシアでは愛犬用の用品をよく買っている事、などから犬を飼っている事、等々、どんどん情報が見えてきます。
△月×日17時20分、29歳の小町町在住の女性が、『デジタルカメラ入門 -2- 愛猫、愛犬を撮る』『なぜか夫婦がうまくいく3つの習慣―二人の危機を救う本』を借りた。
この時Tカードのデータベースから『デジカメ好きの30前後の女性、ペットを飼っている。既婚者』という検索条件で検索した場合、花子さんのTカード利用情報からの情報と、図書館の利用履歴の両方が抽出される事になります。
ここから、小町町の住人の29歳女性、と言うカテゴリで見ると、ほぼ間違いなく同一人物の情報だという事が分かる事になります。ちなみに小町町に在住する29歳女性は国勢調査によると約40人でした。
ここで彼女のTカードの情報には「図書館利用者である」という属性が蓄積される事になります。この後は豊富に蓄積された情報を元に、彼女の図書館利用履歴のトラッキングは比較的簡単に、高精度にできることになります。
武雌市に在住の、武雌和也さん(41)は、最近母親が難病にかかってしまいました。何しろ情報が無いのであらゆる手段を使って調べています。Yahoo!で検索して見たりしているのですが、欲しい情報が見つからりません。普段は全然利用していませんが、思い立って図書館に行ってみることにした。図書館では興味深い話を見つけましたが、情報が若干古いのでさらにYahoo!で検索をして新しい情報も仕入れたりもしています。ちなみに和也さんは、普段は奥さん任せでほとんど買い物などはしない人です。
和也さんの場合、ほとんどTカードを提示する機会は無い人ですので情報が少なくて照合などできないように見えます。が、ここで出てくるのがYahoo!IDです。和也さんは以前、Yahoo!で趣味の釣りの道具を購入したことがありました。その時、市が図書館カードとしてアピールしていた時に惰性で作ったTカードと結びつけを行っていました。
それによって、Yahoo! IDにTカードの情報が結びついている状態になっていたのです。
実はこのように、Tカードというのは非常に広範囲に利用域が広がっています。一度しか使ったことが無くても、使用した時に別のIDと結びつくような形になっているのであれば、TカードのIDそのものを利用しなくても、芋づる式に情報がつながってしまうと言う事が起きます。
Tカードは絶対に図書館以外で使わない、と言うのが一番シンプルです。図書館専用のTカードと、図書館以外のTカードを別けてもあまり意味がありません。Tカードによって記録されるデータベースに、図書館以外の部分で乗るような事をしてはいけません。従って、今、Tカードを利用している人が、図書館でTカードを利用し、尚且つTカードと図書館のデータを結びつけたくない人は、どちらかあきらめる事が必要です。図書館をあきらめるか、Tカードの利用を停止するか、どちらかになります。すでにTカードを利用しながら、結びつけたくない人は、図書館にて利用を開始する前に、一度CCCに個人情報保護法に基づく情報削除を依頼しておくことも忘れてはいけません。
おそらくこれらの指摘に対しては
情報分析については、コンピュータの大容量化、高速化によって不可能ではなくなりつつあります。近頃「ビッグデータ」処理システムなどを用いることによって実際に行われています。
これが「容易に」と言えるかどうかと言う事になるのですが、個人的な見解としては容易だと言って良いと思います。完全にデータベース上だけで照合が完結できてしまうと言う時点で、後はリソースの問題であるからです。コンピュータのリソースなどは数年もたてば倍にと言った世界です。そして毎回膨大なデータを処理しておかなくても、あらかじめデータをあらかじめ整理してあれば、許可を受けた店舗のマーケティング担当者レベルでも情報を引き出せるようになるでしょう。さらに言えば、観覧したい個人がすでに決まっていて、本人を知っている場合(標的を絞っている場合)はもっと簡単に情報を引き出せます。そこにダイレクトに個人を特定するID(名前も含む)が含まれているかどうかは関係ありません。
また情報を際限なく結びつける事を許さないので問題ない、と言う話についてはまず、Tカードの利用規約がすでにそれを許す形になっていることがあります。もちろん企業の内規等でそれができないようにしている可能性はあります。しかし、そこは行政が直接的に知る事も、コントロールする事もできません。何しろTカードの加盟店は膨大ですのでそれら全てに行政が行うべき情報保護に対する規律を求める事ができるのか、と言うと不可能でしょう。
であれば、共通的にTカードの規約を変更する等が必要になるでしょう。また技術的な原則論を超えて、特別な条例を作ってそれによってCCCを縛る事をするだとか、そういった政治的解決法はあります。しかし裾野が広いだけあって、規約だけでは駄目で、実際には不可能な形にしておかないと不十分である、と私は思います。
これはプライバシー問題の特殊さ、難しさが絡んでいます。プライバシー問題の難しさは、観覧された時点ですでに侵害が発生しており、さらに原状回復が不可能である(予防しかない)事、さらに発覚しにくいためです。
ちなみにこれは、公共サービスをそのような民間ベースのID認証に付け加えると、毎回このような情報の取り扱いについて問題が発生していくことになりますし、それらが適正に処理されているかの確認は行政側が行わなければなりません。住基ネットの住民票コードが民間利用禁止されているのもこう言った難しい問題があるからです。
次に「これらの事は民間ではすでに当たり前である」という話もあります。何を今更、と言う事ですね。これは全く持ってその通りで「俺はそうであっても気にしない」と同じような立場になります。しかし、事問題が行政サービスに関わる事であると言う事を忘れてはなりません。また、気にする気にしないと言う話は本質的には個人情報かどうかには直接関係はしないと思います。
もはや落としどころとしては、Tポイントカードを単なるユニークなIDが振られたカードとしてのみ図書館で利用する形にするしかないと思います。情報の流れを一方通行にする。図書館側からは一切CCCに情報を渡さない事ですね。
ではポイントの付加はどうするのか、と言う事になりますが、これはあきらめるか、さもなくば独立したシステムでポイントを加えるしかないでしょう。これでも「このIDは図書館を利用した」という情報は発生することになります。これも解釈によっては個人情報ですが、独立したシステムにすることによって、情報を渡したくないからポイントをつけない、と言う選択肢も可能にするべきです。当然Tカード以外のカードでも利用可能になっていないといけません。
こうなると「図書カードとTカードを別々に持つ必要がない」程度しかメリットが残りませんが仕方が無いでしょう。
最後に。セキュリティ論じゃないところに踏み込むと…正直CCCが戦略を誤ったとしか思えませんね。Tカードの話なんか出さなけりゃ良かったんですよ。あとポイントも。分かり易いメリットのつもりで市長に売り込んで、市長がそれを大々的に宣伝してこうなったのです。本を買わずにレンタルで済ます層の情報に商売としてのうまみがそれほどあるとは思えませんし。CCCグループはTSUTAYAを始めとした幅広い販売チャンネルから得られるPOS情報に、自前の取次MPD、流用出来るノウハウなども多数持っているんだからそっちで責めれば良かった。その上で競争入札に入れば良かったんですよ。
確かに「Tカードを全面に出さなければならなかったと言う事は、その他のメリットがなかったためでは?」と言う話はありますけど、それならば他の既存の業者を選んだ方が市のためになるわけですから今より悪い事にはならないはずです。
アニメやゲームのキャラクター情報をまとめてるサイトがないから作りたいなぁって
思ってたんだけどhtmlは初歩しか分からないしプログラミングもできないので構想するだけで作れなかった。
ゼロから4ヶ月でWEBサービスをリリースした人の記事を見つけて「自分にもできるかな!」なんて思い挑戦してみたけど理解できず挫折・・・orz
それでもWEBサイトを作りたかったので制作会社に発注してみようと思い立った。
ただのキャラクターのデータベースだけではつまらないのでコミュニティ要素なども付けて
ネットで見つけた制作会社に見積もってもらうと下記のようになった。
合計1,483,125円
以前、SNS「ウェブカレ」のサイト制作費が1千万円で安く仕上がった(潰れたけど・・・)という話があったから
なんとなく3~400万くらいかかるんじゃないかなと不安だったんだけど予想より安い見積もりだったので、
このくらいの金額ならなんとか出せる!ということで制作してもらうことにしました。
本当は何社かに見積もってもらって比較しようと思ったんだけど面倒だったのでそのまま制作をお願いすることにした。
(最初はもう少し高かったけど機能の簡略化とオープンソースのライブラリを使用してもらう事で費用を抑えてもらった。)
去年の10月の頭くらいから打ち合わせを始めて第1フェーズでワイヤーフレーム作成と仕様策定をして第2フェーズのhtml、システム開発に
移ったのは中旬だったかな?その段階で前金で4割の580,650円を支払いました。
制作会社には3回くらい打ち合せに行って、あとはメールでやり取りしていました。
当初は12月中にリリースを予定してたんだけど、なんだかんだで伸びてあらかた出来上がったのが2月の中旬くらい。
ちなみに僕はヒッキー(どれくらいヒッキーかというと外出は3日に1回くらい)なので制作してもらっている間は
↓作ったサイト
サーバはさくらのVPS 8Gを使用。CentOS5の64bit
設定した項目は以下のとおり
HDDが3つあって、普通に/var/wwwにコンテンツを入れていくとHDDが溢れそうだったので、容量の大きいものを使うように工夫したりなど。
メモリもそこそこ積んであるサーバなので、mysql、php、apcに多めにメモリを割り当てる設定をした。
本当はmyISMやInnoDBエンジンでLIKE "%word%"のようなクエリーを投げて十分なパフォーマンスが出ればいいんですけどね。
それはムリなので、全文検索エンジンとしてgroongaを使用。
groongaを使用するために先にインストールしたのはこんな感じ
この時点でいざ、groonga!と思ってgroongaをインストールしようとすると競合を起こして入らない。
epel、remiレポジトリからインストールしてあったmysqlと衝突してたのでyum remove "mysql*"で
一旦mysqlを消して、groongaレポジトリからmysqlとgroongaをインストール。
するとgroongaは入ったものの、今度はphpから使おうとしてもphp-mysqlパッケージが入らない。
あちらを立てればこちらが立たぬ状態で本当にこまった。
どうしようもないので、やりたくないけどyum-downloadonlyを使ってパッケージに含まれる設定やら、soファイルなどを直接とってきて入れた。
mysql.so、mysqli.so、pdo_mysql.soを/usr/lib64/php/modules/にコピーしたり、設定をコピーしたり、少しずついじりながら、なんとか動いてくれた。
状態としてはmysqlとgroongaはgroongaレポジトリから、phpと本来php-mysqlパッケージでインストールされるmysql.soは手動で置いたことになる。
シェルから直接mysqlにログインするときはgroongaレポジトリのやつを、phpからmysqlを呼ぶときは手動で置いたmysql.soを使うことになっている。
ちょっと心境的にしんどい。別の方法があったかもしれないけど、調べても分からず結局1日くらいかかった。
アクセスは、サイト全体(トータル)、サイト全体(当日分)、各コンテンツ日別、各コンテンツ週間、各コンテンツトータルのアクセスをとるようにしています。
検討した候補はmemcaced、apc、mysql、redis、fileあたりなんですが、
fileは候補にあがったものの、メンドウ、、どうせなら楽な既製品がいい。と思って候補から外しました。
残るはmysqlかredisだけど、redisが高速って聞いていたのでredisにしてみました。
最初全部redisに入れて、集計した結果をmysqlに入れるつもりでしたが、週間ランキングなどはINSERT INTO .. DUPLICATE ONを使って、
アクセスした週の月曜日00:00:00のタイムスタンプとコンテンツIDをキーにしたレコードを作ればそのまま週間ランキングになるなー。と思ってmysqlを使っています。
コンテンツのトータルアクセス数もコンテンツのレコードにpvという項目をつくってUPDATE table SET pv=pv+1 WHERE id = ? のようにしました。
最初難しく考えていたけど、こうすることによって大分楽になったなーといった感じ。
全文検索エンジンや対話検索、ここにこのリンクがあればなぁ。。という所に何とかしてリンクを作るのが本当に大変だった。
使い勝手を良くするために、ここにこの機能をなど、さくっと思いつくのは簡単でもそれを実現するために、あーでもない、こーでもないと
DB・プログラムとにらめっこしながら「あ!こうすればできる!でもそうすると今度はこっちが・・・」みたいなのがあったりでとても大変だった。