「データベース」を含む日記 RSS

はてなキーワード: データベースとは

2016-06-29

anond:20160629151256

なるほど。メモリを読んでやる方法があって、そっちの方が速いんですね。

とても参考になります技術選びもいろいろあるんですね。雑魚くてつらいっす。

web上のデータからすぐに計算できるなら、データベースは確かにいらないっすね。

実際の取引段階ではDB使わないようにします.

データ研究する時に、データベースが使えるけどって感じっすかね)


もしよろしければphpの方が良い理由も教えてくれませんか。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

盲目剣士フィクション

創作に出てくる盲目剣士を一覧にしたい。いつかデータベース化したいとも思う。

とりあえず思いつくのを羅列。



・伊良子清玄

座頭市

・盲剣の宇水

剣聖ハボリム

ブリーチ鈴虫だかコオロギだか言うカタナを使うドレッド黒人



なんか他にもいたと思うんだけどな。

だれか心当たりがあったら教えてください。

古くても、そんなに有名じゃなくてもいいです。

2016-06-12

頭が悪い記事を見た

このような記事ツイートを見た。

http://www.tm2501.com/entry/2016/06/11/192000

https://twitter.com/tm2501/status/741700789794574337

この記事データベース

データベースという言葉意味を分かって使っているのだろうか。

はてな村アクティブユーザー数を考えてみれば、各ゾーン50人程度は抽出しないとデータベースとして機能しないのではないだろうか。

そして一番問題なのは読者登録数と人格という着眼点である

読者登録数は客観的事実であるが、人格考察に関しては青二才主観しかない。

そもそも抽出しているブログ青二才巡回先?であるだけで主観に偏りすぎている。

「飯をおごりたくなる」?

カリスマ性がある」?

「読んで役に立つ」?

よくもまあ、こんなものドヤ顔で書くことができるものだ。

そして反論者には「これが互助会?」とな。

頭がおかしい。

2016-06-10

なぜマンガキャラ覚醒パワーアップすると髪が伸びるのか?

髪が伸びるキャラたち

覚醒したり、パワーアップしたりするときに長髪になるキャラって多いですよね?



ぱっと思い付くだけでも、

ドラゴンボール(1984~)におけるスーパーサイヤ人3

うしおととら(1990~)の潮(獣の槍所持時)

※厳密には髪が伸びているわけではないらしい

幽遊白書(1990~)における幽助

ハンターハンター(1998~)におけるゴン(さん)

BLEACH(2001~)の一護最後の月牙天衝

ぬらりひょんの孫(2008~)のリクオ

などなどたくさんいます

(変身すると髪が長い、というとWILD HALFワイルドハーフ)もそうですね。)



なぜみんな髪が伸びるのでしょう?

演出上の要請

まず、覚醒したり、パワーアップしたりしたことを分かりやすく示すためには、見た目ががらっと変わることが必要です。

そのような演出上の必要性があるから、髪が伸びるのかもしれません。



髪が伸びる以外だと、以下のようなパターンがありますね。



・眼の色が変わる、瞳に模様が浮かぶ



ハンターハンタークラピカNARUTO写輪眼輪廻眼、仙人モードBLEACH虚化Get Backers-奪還屋-の聖痕スティグマ)、新世紀エヴァンゲリオン



ブコメで指摘を受けて、キングブラッドレイは削除しました。



・髪の色が変わる



ドラゴンボールスーパーサイヤ人武装錬金ヴィクター化、東京喰種



・肌の色が変わる、紋様・模様が浮かび上がる


武装錬金ヴィクター化、七つの大罪のメリオダス、アメコミハルクONE PIECEルフィギア4、進撃の巨人金色ガッシュ!!



・光をまとう



ドラゴンボールスーパーサイヤ人テニスの王子様無我の境地



これらのパターンと違って、髪が伸びた場合キャラクターのシルエットそのものが変わるため、使い勝手が良い、ということはありそうです。

ロン毛ブームの影響

江口洋介木村拓哉などに人気が出て、男性の長髪が流行したロン毛ブーム

これが起きたのが1990年代でした。

当時の、男性の長髪がかっこいい、という風潮が影響しているのかもしれません。

野生化の象徴としての長髪

覚醒すると、強力になる代わりに理性を失ったりするのもお約束の一つです。

そういった性質象徴として、髪が伸びて野生化した姿になるのかも。

ライオンのたてがみのイメージ根底にあるのかもしれませんね。

怒りの表現としての長髪

覚醒シーンにおいては、その人物の怒りが伴うことも多いです。

怒髪天を衝く」という言葉もあり、髪の毛が逆立つのは怒りの表現

髪の毛が伸びて逆立つのは、そのキャラの怒りを象徴とも読み取れます

魔法少女モノにおける変身との関係

詳しくは知らないですが、プリキュアシリーズ(2004~)や美少女戦士セーラームーンシリーズ(1992~)など、魔法少女モノでは、変身して髪が伸びるイメージがあります

これらについては、ターゲットとする女児のあこがれ、「大人の女性」の象徴として、髪が伸びている側面もあると思います

ただ、少年漫画等とも、「髪が伸びて、変身・パワーアップ」というところでは共通しているので、こちらの方にルーツがあるのかもしれません。

旧約聖書における力の源としての髪の毛

旧約聖書登場人物サムソンは、怪力の持ち主ですが、その力の源は、髪の毛にあります

髪の毛が力の源という発想は、このあたりから来ているのでしょか。

ブコメでの指摘によると、髪の毛がというより、髪の毛を切らないという誓約問題のようです。

神話宗教呪術・昔話における髪の毛

丑の刻参りの方法として、相手の髪の毛が必要とされる場合があるように、宗教呪術的にも髪の毛が重要場合があります

日本の昔話でも髪が伸びるエピソードがあるようです。

まんが日本昔ばなしデータベース〜 - 山姥の毛

http://nihon.syoukoukai.com/modules/stories/index.php?lid=507



きちんと確認できていませんが、ギルガメシュ叙事詩におけるギルガメシュギルガメッシュ)は、長髪が抜けると力を失うようです。

ブコメで指摘を受けて、「髪を失う」を「力を失う」に修正


ギリシャ神話では、髪の毛に関するエピソードとして、メドゥーサやかみのけ座の話がありますね。



古来から髪の毛には何らかの力が宿るとされきたんですね。

憶測疑問形だらけで結論は分かりませんが、思っていた以上に「覚醒して髪が伸びる」のルーツは古いところにありそうです。



追記

ブコメであがっているワンパンマンは逆のパターンですね。

あれは、アンパンマンビジュアルありきの設定なのと、髪の毛があったころが描かれていない(たしか)のでちょっと事情が違いそうです。

フリーザは、元々髪がないですが、シルエットがすっきりするという意味では逆のパターンですね。


ブコメでは、時間の経過の表現、異形化系の説話と設定上の都合、動物の威嚇、成熟期の発毛、歌舞伎など色々な指摘があって興味深く読ませていただきました。

ありがとうございます

2016-06-06

膨大なブコメ資産が失われた問題

Impress Watchリニューアル(http://www.watch.impress.co.jp/20th/)した。



サイトの見辛さ等は既に語られている事なので割愛するが、

記事URL構造過去記事も含めて変わってしまった事はあまり知られていない。



例えば、以下の記事は次に示すURLリダイレクトされる。

はてななどの各社担当者自作サーバーノウハウを紹介 -BB Watch変更する

http://bb.watch.impress.co.jp/docs/news/20091126_331459.html

http://bb.watch.impress.co.jp/docs/news/331459.html

上記の記事は471usersを集めているが、

リダイレクト先は勿論0user、つまりブクマ無しとなってしまう。

せっかく記事を見つけてブコメも閲覧しようにも見られないのだ。



ではImpress Watchの全過去記事が新URLになっているかと言うとそうではなく、

調べるとPC Wacthでは2009/04/08の記事から変更されているようだ。

リダイレクトされない

富士通フロンテック「FLEPia」試用レポート

http://pc.watch.impress.co.jp/docs/2009/0407/fujitsuf.htm



リダイレクトされる

Acer、初のNVIDIA IONベースの超小型デスクトップAspireRevo

http://pc.watch.impress.co.jp/docs/2009/0408/acer.htm

http://pc.watch.impress.co.jp/docs/news/110556.html

まり2009/04/08〜2016/06/01の7年2ヶ月のブコメ簡単に参照できなくなった。

これは膨大なブコメ資産が失われたと考えている。

同様の問題Wikipediahttps化の時も発生している。



Impressと言えば新聞社等のニュース配信と異なり、過去記事も削除されることな

長期保存(最古は96年4月:http://pc.watch.impress.co.jp/docs/article/960417/index.htm)されているので

その事実にはただただ感謝するしかなく、今回のURL変更に文句を言うつもりもない。



ただWikipediahttps化の時と同様の話ではあるが、

比較的規模の大きなサイトURL構造を変更してリダイレクト対応を行った際には、

はてなブックマーク運営側においては別URL提示を示す等の対応を行って頂きたい。

(詳しく知らないが、これは過去はてブデータベースに対して何らかの書き換えや追記等の作業が発生するかもしれない)



はてな運営要望しても無駄なのは知ってるけど。

2016-05-26

訪問契約率20%のブラック企業の真っ黒な営業手法を書いてみる

数年前、自分はなかなかのブラック企業営業職をしていた。

某有名なX通信社員起業した会社でした。

成績順に4つのグループに分けられて自分は3ヶ月目くらいからはずっと1番上のグループにいました。

でも、入社半年でじんましんが出てきてきたりまつげがピクピクしたり大変でした。

ブラック企業関連のエントリーを見て、あの時を思い出したので振り返ってみようと思う。

 

体制的なブラックとしては20時間のみなし残業はあるけど実際は40時間くらい残業していたこと。

それに加えて土曜日も無給で働いていたこと。

あと健康保険とかなかった。そんな感じ。ブラックとしてはあんまり凄くないかも。

でも、営業のやり方がきつかった。

 

商材はCDに入っている在庫管理ソフトウェア

フリーウェアレベルだけど価格は120万円から

まずは契約までの流れを簡単に書いてみます

 

雑誌インターネットを使ってのリスト作成美容院接骨院サロン飲食店など)

・非通知設定で電話をかけてアポイント(以下、アポ)を取る。

一定時間をおいて上司アポ内容をアポ先に確認する。

訪問して90分くらい話す。

価格交渉を行う。

契約書をその場で書いてもらって終了。

 

提示した内容の前に大事ポイントが3つあるので補足。

1点目。実際に顧客と話をするのはホームページ新規作成またはリニューアル提案です。

無料ホームページ作成するとうたい、月々のサーバー管理費など別途かかると相手には伝えます

2点目。契約は60回払のリース契約にて行います

3点目、契約後、自社の運営するアフィブログ相手特集し、PVを稼ぐことがこちらのメリット相手に伝える。

 

次に、訪問から契約までの詳細を書いてみます

 

リスト作成

古いホームページホームページを持っていないところをリストアップします。

過去訪問先はデータベースにいれているため訪問して怒られた会社電話して怒られた会社リストから除外。

過去に何度電話をかけていようが怒られていなければ再度電話をかけます

訪問して断られていても、断る理由が時期やお金問題だったなら電話をかけます

電話をかける時は一日100件ほどかけるのですぐにリストがなくなる。

数ヶ月もすれば雑誌ネットも使い切る感じになって、リスト作成がとても時間がかかったなあ。

営業先の地域で良さそうな店があったら飛び込んで挨拶して後日電話する許可をもらったりもした。

 

非通知で電話をかける

基本的に”無料で作るんだから話だけ聞いてよ”というのをゴリ押し

実際100件に電話してアポがとれるのは1,2件くらいです。

電話スクリプトがあっていくら工夫しようが改善しようがアポ率はあんまり改善できなかった。悲しい。

ただ、ものすごく声の可愛い女の子が平均の3倍位のアポ獲得率を出しているのを見て驚愕しました。努力して追いつくことができない存在

非通知でかける理由電話をかけて繋がらないことが多く、折り返しを受けるとコストが増えると判断しているためです。

折り返しの電話を受けて対応するよりかけ続けたほうが良い。

かけまくっているから誰がかけたかもわからないことが多くて時間にロスが生まれる。

この非通知戦略が本当に営業効率がいいのかとも疑問が湧きますが、そこはそういう会社でした。

基本は話ができずガチャ切りはよくあったし、話を聞いてもらえず切られたり、明らかに苛立った声で対応されたり色々あったし辛かった。

 

上司によるアポ確認

営業アポを取るのに必死になりすぎて、アポの内容が曖昧なまま電話で話を終えることがあります

ホームページの話をする」ことと「60分の時間を確保する」ことと「良かったらやってもらう」という相手意思契約率に影響するためその内容の確認上司が行います

「そんなガチなら良いや」と断られることもあり、アポを取った人は祈る気持ち確認電話を見守る。

この選別を乗り越えた場合、話を聞く体制ができている場合が多かったので必要事項だったと思います

営業も雇われて2日目から電話をかけるため適当に話をしてアポを獲得する場合が多いです。

そんなに時間はかからないとか言ったり、ホームページの話をしてなかったり、訪問日時が決まってなかったり、などなど。

また、営業成績が出ていない人はとにかくアポをとりたいと思う。

から内容が相手に伝わっておらず内容確認で泣く泣く撃沈というのもよく見る光景

無料というのを怪しむ人にはこのタイミング費用がかかることを伝えて撃沈する。でもホームページ自体に興味があってそのままアポになる場合も稀にある。激アツの客。

 

訪問営業

アポ先への営業

X通信から受け継がれる営業手法を駆使して相手の購買意欲を高めます

営業ポイントをざっくりと書いてみます

アフィブログアクセスを伸ばして稼ぎたいか特集できる相手を探していることを納得してもらう。

アフィブログの知名度を高めたいか相手ホームページアフィブログバナー広告を貼ることを了承してもらう。

・いずれはホームページ制作事業として行いたいので実績作りで無料で作っていることを了承してもらう。

相手がやりたいことがホームページ活用することで実現できるとイメージさせる。

サーバー管理費とかは絶対にかかるものホームページ運用するなら絶対にかかるものだと当然のことのように言って納得してもらう。

契約対象ソフトウェアリース契約というのをさっくりと伝える。重く伝えると相手が慎重になるのでだめ。

 

これだけの話をすると90分は超えます

しか無料だと思って時間をとって話を聞いていたのに費用がかかる。

120万円から240万円をリースで分割月々60回払い!

普通にやっていたら相手はブチ切れます

なのでいかに、アフィブログアクセスを伸ばすことがこちらのメリットになるかということ。

相手がやりたいことが提案したホームページで実現できることをイメージさせることが営業序盤で重要になります

相手との距離を縮めることはとても有効。なくても取れるけどここを突き詰めれば契約率が数%違ってくる。

 

相手も長く話を聞いてるし、成功体験イメージをして興奮したりするので頭が麻痺して判断力が鈍くなってきます

だんだん周りが見えなくなってどこで話していようが個室でふたりきりで話している感覚になっているか確認

なっていなければトークのミスでかけていると思われている説明提案にもどる。

価格交渉の時間がなさそうならば再度アポをとる。

再度アポをとるよりも初訪問のほうが契約率は上がるのであまりオススメできない。

  

価格交渉

ホームページを、ものすごく欲しいかものすごく必要だという状態にさせれば価格面で熱い勝負ができます

メルマガつけるとかRSSつけるとかスライドつけるとか、FLASHやるとかスマホ対応するとか、ページ数増やすかいろんなオプション理由をつけて価格釣り上げ。

大したオプションでもないのに管理費が月々数万違うなんてことは実際はあり得ないけど、インターネット無知な人は当時は多かったのでここまでくると話を通せます

相手が欲しい機能を決めて、具体的な価格提示してから勝負です。

3万円提示して、1万5千円ならだせるとか言ってる場合は、「オプション削りましょう!」とか「顧客を獲得するためこうしましょう!」とか色々提案提案と言うにはアレだけど。

価格面でどうしようもなくなったら上司にその場で電話します。

「今、こういうお客さんのところに訪問していて、すごい方なんです。こんなにすごい方をアフィブログ特集すればPVも伸びます!ページの話でオプションはこれで金額はここまでならだせると言ってるんですがどうにか値引きとかできないでしょうか。」

とかなんとか。

この茶番。こんな胡散臭い意味あるのかと思うだろうし、俺も思っていたよ。

でも実際に困ったときにこれをやることで契約に結びついたことも多々あるので当時は有効手段だった。

 

そして、上司検討させるため一度電話を切って5分か10分また盛り上げる。

上司からの折り返しの電話を受けて「役員たちが決定した」金額提示

基本はここから下がることはなくなり、そこでできるかどうかで勝負を行います

また、オプションの話をしたり提案を繰り返して、相手が根負けすれば契約

結局4時間話すとか終電逃したとかもあった。

ここまで話すには相手に突っ込める領域に入っているのがとても重要だったから、”自分を売る”ことの意味もわかるし言い方を工夫して営業指導を今もする。

 

契約書に書いてもらう

これがとても面倒。

実際にホームページの話で盛り上がっていたのに契約をするのはソフトウェア

相手ホームページのことに夢中なのでここでそこまで問題になることはない。

でも、金額提示で即OKと価格交渉がなかった場合はここでひっかかることがある。

リース契約書は保証人とかも必要になって面倒だけどちゃんと書いてくれるのには驚いた。

 

以上が契約までの流れ。

トップ営業は20%ちょっと契約率で、下のグループでも10%は取れたりしてた。

1ヶ月で契約取れない人はだいたいクビ。

契約解除の話は部署全体で月に2,3件あるかないかだった。

  

やばかったり辛かったと思うポイント

ホームページ製作の話なのに契約がクソみたいなソフトウェアで高額リースだったこと。

・そのことを就職時の面接で伝えられなかったこと。

・週6日勤務なのに週5扱いにされてたこと。

残業代休日出勤代がみなし残業全然足りていなかったこと。

会社用の電話休日でも携帯させられていつ電話がなるかわからなかったこと。

・非通知でかけて怒られたりガチャ切りされたこと。

無料じゃないのに無料と伝えてたいたこと。

リストを作ろうとしても過去訪問した店ばかりになり新しい店を探すのが難しくなっていたこと。

アフィブログアクセスなんてほとんどなかったし、社内の誰も期待していなかったこと。

・実際に作るページは高く見積もっても50万円程度のものだったこと。

詐欺だと罵られたこと。

契約して半年してもトップページすらできていないケースが多かったこと。

アポイントの日時に訪問したら誰もいなくて店の前で1時間待ったこと。

・新しく入った人が1ヶ月生き残る確率が30%くらいだったこと。

・身体に変なブツブツができたり、目がピクピクしたこと。

・残っている人も心や体に異変が起きていたこと。

・全体的に契約数が落ちていって会社全体の雰囲気もピリピリしていたこと。

・退社後に労基署相談して超過勤務代を貰えるかと相談して勤務のログも提出したけどダメだったこと。

・退社して長くないうちに会社が潰れたこと。

被害者の会みたいなのが結成されていたこと。

 

良かったと思うポイント

・とても営業と言えないような稀な経験ができたこと。

上司が部下に物を投げるとかはなかったこと。

自分努力でできる限界を見ることができたこと。

・体の異変はなくなり今も健康でいられていること。

-----------------------------------------------

 

追記:ここで学べた契約を取るために必要な要素も書いてみるので参考になると嬉しい。

 

1.人として気に入ってもらうこと。

2.相手商品サービスものを使っているイメージをしていて、それを現実化したいと思うこと。

3.その商品サービスがすごいと思っていること。

4.買って欲しい旨をうまく伝えること。

これらを抑えれば大体落とせる。

 

補足すると、

1は相性があるけど見た目とか話し方は磨ける部分がある。無理してもそれは相手に伝わるから素の自分は大切に。

2は相手を知る必要がある。限られた時間でどこまで掘り下げられるかがポイント

3は簡単比較できるものより優れている、もしくは同等程度であることが大事

4を伝えなきゃ基本的に始まらない。相手のことを知ってどう切り出すか戦略を練ろう。

 

これでダメなら縁がなかったということで次にいこう。

もちろん改善できることは次に活かして。

2016-05-24

http://anond.hatelabo.jp/20160524134842

お前のおかげで馬鹿データベースがより充実したからこれ以上ない回答だった。

不都合があるのはお前しかないんだ、本当に申し訳ない。

パナマ文書 続・恵比寿関連 SONY、CCC

パナマ文書281809について

http://anond.hatelabo.jp/20160409094753

と関連して、パナマ文書で20法人もの

大量のペーパーカンパニーを持つオフショア登録者

「Ken Kiyoshiという人物がいる。

彼の所在地は以下の通り。

Ken Kiyoshi  ICIJ Offshore Leaks Database
Connected to 1 address
Connected to 20 entities
Linked countries: Japan
Data from: Offshore Leaks
https://offshoreleaks.icij.org/nodes/117463
"281809";番号281809
"ADDRESS";"Room 1009, 4-20-2 Ebisu Shibuya-ku Tokoyo 150-0013 Japan";
所在地 〒150-0013 日本国東京都渋谷区恵比寿4丁目20番2号 1009号室
https://offshoreleaks.icij.org/nodes/281809

 

恵比寿4丁目20番2号は実在日本所在地

パナマ文書が示す「〒150-6010」は、2016年現在郵便番号区分では

恵比寿ガーデンプレイスを除く東京都渋谷区恵比寿を示す地域区分

当該所在地高層建築物は「恵比寿ガーデンテラス弐番館」に特定される。

 

恵比寿ガーデンテラス弐番館は、1994年8月築、地上13階地下2階

建総戸数220戸?の大規模マンション

Googleストリートビュー 〒150-0013 東京都渋谷区恵比寿4丁目20−2

https://goo.gl/maps/9dpcw9Zz3c42

恵比寿ガーデンテラス弐番館10階」の賃料は、公開されている

あたりでは、2LDKで42.2万円、41.4万円、1LDKで34.6万円、1Kで

22.5万円といった相場富裕層向け住宅だ。

http://www.plus-home.co.jp/rent/6509/

http://www.marycorp.co.jp/detail_marycorp_1_marycorp_2_271

http://www.rnt.co.jp/building/detail/1576/

http://concierent.jp/rent/333/48434/

 

国税庁法人番号公表サイトデータによれば

恵比寿ガーデンテラス弐番館を所在地とする法人は以下の三法人

国税庁法人番号公表サイト

http://www.houjin-bangou.nta.go.jp/

3011001064749 株式会社CONTAINER 東京都渋谷区恵比寿4丁目20番2号恵比寿ガーデンテラス弐番館

3011001096420 東京都渋谷区恵比寿4丁目20番2号恵比寿ガーデンテラス弐番館1315

5010401017455 東京都渋谷区恵比寿4丁目20番2号恵比寿ガーデンテラス弐番館411

 

法人番号3011001096420と5010401017455は

パナマ文書が示す部屋番号1009とは異なるので、

株式会社CONTAINER所在地だけが

パナマ文書が示す顧客所在地と一致することになる。

 

株式会社CONTAINERという会社

株式会社CONTAINERは、

韓国人12人に活動している日本男性アイドルグループApeace(エーピース

https://ja.wikipedia.org/wiki/Apeace

などの芸能関係の事業をやっている。

コンサート放送局への出演料、握手会などのイベント

ファン向けグッズの販売などでまとまった儲けがあるようだ。

 

Apeace

http://apeace.jp/apeace_live/

企画制作株式会社CONTAINER/Golden Goose
特別協力:サミー株式会社
協力:文化服装学院 / メイクアップアーチスト学院
衣装協力:NAVAL
■日程
2011年6月18日(金)~ロングラン公演 
■会場
K THEATER TOKYO
東京都渋谷区恵比寿4-20-2 恵比寿ガーデンプレイス内 
■座席・料金
ロングラン公演:¥4,600(税込)

特ラ連レポート122

新規加入会員紹介コーナー

平成23年6月~7月)

http://www.radiomic.org/activity/backnumber/No122/newkaiin.html

株式会社 CONTAINER(K-Theater)	会員番号030-0616
代表取締役 田村孝司	入会:7月25日	移動	AKG … 4本
シュアー … 12本
〒150-0001 東京都渋谷区神宮前4-12-20
担当 支配人 斉藤昇三	TEL 03-5421-7062 FAX 03-5421-7063
〔ひとこと〕厳しいレッスンと数々のオーディション審査より
キャスティングされた精鋭達21名によるエンターテイメント
グループ、「Apeace」が、K-Theater Tokyoロングラン
公演をおこなっております

 

この情報ではCONTAINERの所在地神宮前になっている。

国税庁法人データベースには当該所在地に8件の法人があるようだが

株式会社CONTAINERという会社登記されていない。

K-Theater Tokyo恵比寿ガーデンテラス弐番館の

恵比寿ガーデンシネマの跡地につくられた日本初のK-POP専用劇場

2011年5月27日から営業していたが2014年末に閉店し

今は映画館になっているようだ。

 

国税庁法人番号公表サイト

http://www.houjin-bangou.nta.go.jp/

東京都/渋谷区/神宮前4丁目12-20/登記記録の閉鎖等含める/商号

8件 見つかりました。

1011002035263 有限会社アートビートパブリッシャー東京都渋谷区神宮前4丁目12-20表参道ヒルズゼルコバテラス405

2010401095900 株式会社アルファ・アンド・カンパニー 東京都渋谷区神宮前4丁目12番20号W406

4011001005116 株式会社モテサンド東京都渋谷区神宮前4丁目12番20-W304号

9011001050347 株式会社幸和画廊 東京都渋谷区神宮前4丁目12番20-105号

4011002034898 有限会社後藤繁雄事務所 東京都渋谷区神宮前4丁目12番20-405

4011001072577 ミストラル株式会社 東京都渋谷区神宮前4丁目12番20号

6011001061974 株式会社LAMPO 東京都渋谷区神宮前4丁目12番20号

3011001052051 株式会社OK 東京都渋谷区神宮前4丁目12番20-408号

 

ちなみに特ラ連は特定ラジオマイク利用者設立した非営利団体

任意団体特定ラジオマイク利用者連盟の略称

イベント関連会社等は無線を使う関係で特ラ連とは利益共有の関係にある。

https://ja.wikipedia.org/wiki/%E7%89%B9%E5%AE%9A%E3%83%A9%E3%82%B8%E3%82%AA%E3%83%9E%E3%82%A4%E3%82%AF%E9%81%8B%E7%94%A8%E8%AA%BF%E6%95%B4%E6%A9%9F%E6%A7%8B

 

ディファ有明イベントスケジュール

http://www.differ.co.jp/schedule_20150425.html

ApeaceLIVE2015♯3~Back to the Future~
 日付		4月25日(土)
 チケット料金		8500円 FC先行特典付き
 開場/開始		開場 13:45/18:15 
開演 14:30/19:00
 お問い合わせ先 株式会社CONTAINER http://apeace.jp/
0570-064-257 平日14:00~18:00まで

 

このイベント告知を見ると、

株式会社CONTAINERの問い合わせ電話番号0570-064-257になっている。

0570-064-257という番号は、

ソネットエンタテインメント株式会社事業運営委託会社

コネクトプラス株式会社または株式会社ロム・シェアリングの連絡先と同一だ。

 

特定商取引法に基づく表記 NU'EST JAPAN OFFICIAL FANCLUB

http://www.nuest.jp/info/law.html

役務提供事業者 ソネットエンタテインメント株式会社

運営責任者 代表取締役社長 中野秀紀

住所 東京都品川区大崎2丁目1番1号

運営委託

コネクトプラス株式会社

〒106-8011 東京都港区六本木3-16-35 イースト六本木ビル

株式会社ロム・シェアリング

〒106-0041 東京都港区麻布台2-3-5 ノアビル 1F

電話:0570-064-257(平日14:00~18:00)

サービス内容 会員特典に記載ファンクラブ会員へのサービス提供

サービス提供時期 入会を承認した時点で当会の会員となります

国税庁法人番号公表サイト

9010401061375 株式会社ロム・シェアリング 東京都港区麻布台2丁目3番5号ノアビル1階

http://www.houjin-bangou.nta.go.jp/

 

まり株式会社CONTAINER株式会社ロム・シェアリングという法人

実体として一体的に活動しており、ソニー傘下で仕事をしている。

 

資本元はソニーモバイルコミュニケーションズジャパン株式会社

 

上記NU'EST JAPAN OFFICIAL FANCLUBサイトプライバシーポリシー管理

ソネットエンタテインメント、すなわち日本台湾香港運営している

インターネットサービスプロバイダSo-netで、

そのSo-net2016年完全子会社化した親会社企業名

ソニーモバイルコミュニケーションズ

So-net - Wikipedia

https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%8D%E3%83%83%E3%83%88%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%86%E3%82%A4%E3%83%B3%E3%83%A1%E3%83%B3%E3%83%88

ソニーモバイルコミュニケーションズ - Wikipedia

https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%8B%E3%83%BC%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BA

 

Ken Kiyoshiとは何者なのか?

長江実業グループを率いるアジア有数の大富豪

李嘉誠の次男である李沢楷(リチャード・リー

事業投資会社として創業した会社に、

パシフィックセンチュリー開発(Pacific Century Development / CCD)

というグローバル企業があり、

その日本法人である日本パシフィックセンチュリーグループ株式会社

1998年3月に就任した代表取締役名前は喜吉憲。

パナマ文書に書かれていた名前Ken Kiyoshiと姓名の読みが同一だ。

 

もちろん同姓同名の人物は他にもたくさんいるのは事実だが

租税回避の動機を持っている富裕層となると限られてくる。

 

PCCW - Wikipedia

https://ja.wikipedia.org/wiki/PCCW

李嘉誠 - Wikipedia

https://ja.wikipedia.org/wiki/%E6%9D%8E%E5%98%89%E8%AA%A0

李沢楷 - Wikipedia

https://ja.wikipedia.org/wiki/%E6%9D%8E%E6%B2%A2%E6%A5%B7

メモPCCW&CCC: 日本プロファイル研究所

http://timetide.way-nifty.com/jprofile/2013/07/post-07d0.html

PCCW&CCC
カルチュア・コンビニエンス・クラブ(株)H19有報時の役員抜粋
取締役	日下孝明 サンレジャー港区参照 ご近所シリーズ05参照
 
取締役 喜吉憲 Ken Kiyoshi
国際基督教大学出身
1971年4月-(株)日本興業銀行 入行
1997年4月-同行 香港支店長兼IBJ Asia Limited 副会長
1998年3月-日本パシフィックセンチュリーグループ(株)代表取締役
2003年4月-カルチュア・コンビニエンス・クラブ(株)顧問
2003年6月-同社 常務取締役
2004年6月-同社 代表取締役副社長 管理部門管掌
2006年3月-同社 取締役管理本部2006年7月-同社 取締役社長補佐
 
取締役 三木谷浩史 三極委員会メンバー
取締役	角川歴彦
取締役	奥谷禮子
 
■考察
国際基督教大学出身といえば、神政連の一押し→有村治子議員(公財)ドナルドマクドナルドハウスチャリティーズ・ジャパン 理事
PCCWといえば→パシフィックセンチュリープレイス丸の内

 

日下孝明はワンダーコーポレーション代表というより

TSUTAYAの元社長と書いた方がわかりやすいか

パナマ文書日本の政治はいないという話が独り歩きしていたが、

ほらほら、やっぱり出てきた。

自由民主党公認参議院比例区当選第2次安倍改造内閣

消費者及び食品安全担当大臣規制改革少子化対策

男女共同参画担当大臣有村治子の名が。

だがこの人とパナマとの関係性を考えるにはさらなる調査が必要。

不逮捕特権を持つ人物相手捜査となると特捜以外に考えられない。

 

それはそうと、パナマ文書のKen Kiyoshi支配する

ペーパーカンパニー(バージン諸島)のひとつ

CCCW Japan Limitedがしっかり入っている。

CCCW Japan Limitedの資本の源はもちろんCCCW Limitedだ。

 

PCCW Japan Limited | ICIJ Offshore Leaks Database

https://offshoreleaks.icij.org/nodes/131516

Ken Kiyoshi | ICIJ Offshore Leaks Database

https://offshoreleaks.icij.org/nodes/117463

PCCW Limited | ICIJ Offshore Leaks Database

https://offshoreleaks.icij.org/nodes/294534

 

ここまで出ると香港の件の華人とそれに連なる日本資本

クロ判定するしかないのではないか

 

ここまでのまとめ

 

グローバル企業ソニー系列傘下の芸能イベント会社所在地は、

パナマ文書課税回避顧客所在地と同一。

そしてその所在地にいるとされる人物Ken Kiyoshi

楽天三木谷浩史角川グループ角川歴彦らと役員を務め

日本政界とも関係があるかもしれないPCCW役員&CCC顧問名前と同一。

 

2016-05-23

料理の作り方を集積したサイトはあるみたいだけど、

食べ方を集めたサイトとかあるのだろうか

食事マナーみたいなものではなくて、もっと具体的に個別料理についてのもの

たとえば、

天丼の具とご飯をバランスよく食べ進める方法

レタスみたいな大型の葉物中心の野菜サラダドレッシングが上にしかかかっていない場合に下の方をどうするか

みたいなの。

単発でライフハック的な記事が出ることはあるみたいだけど、

新着でそういったものを拾うことはできても、

データベースのように集積されていて検索が容易にできるようなものはないのかな。

大手まとめサイトなのだ過去記事検索したりしにくくて好きじゃない。

2016-05-22

私が休学を決めるまでというブログを読んで思ったことは

通信費というかインターネットもっとフリーに開かれた場所だったら貧富の差がなく情報が得られていいのにね。

ネットって検索すれば、それこそ中学校から高校までのカリキュラムくらいは学習出来るわけだし。現状検索するのがめんどくさいけど。

あのブログの彼はまさにネットを通じてつながりや情報を得てるし、理想の形だよね。

でも、学校教育カリキュラム学習しずらかったとあのブログには書いてあった。

そういう、ここを見れば初等教育から高等教育までのカリキュラムを学べるって感じのデータベースもっと国や機関に整備してほしいよね。

ネットさえ見られれば、情報教育に対しての十分な福祉となりうるような体系的なシステムを構築して欲しい。

まあ、でも通信業界に従事している人にとっては死活問題だろうけど。

うーん、もはや通信社会インフラなんだからどうにかならんものかね。

通信費負担問題ネットで得られる情報によって格差是正されることへの期待があってほしいと、あのブログを見て思った。

2016-05-21

http://anond.hatelabo.jp/20160521190026

元増田です。

SPAは、クライアントが自立した1プログラムとして状態管理する。サーバUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバサーバサイドページ生成のスタイルを、サーバブラウザでやるようにシフトさせたものともみなせるだろう。

手間がかかりません?さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。

そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。

というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。

まあそれはそれとして、なるほど、JSX別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。

すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

ここわかんないですね。活発なメンテがそんなに重要なのかな?ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか?

http://anond.hatelabo.jp/20160521163144

まずReactの特徴は、「状態データから変換してビューを生成する」スタイル統一されることにある。

これはjQueryをはじめとするDOM操作モデルでの、「初期状態ビューの作成」と「(イベントに伴う)状態変化からの部分ビュー変更」で構成するスタイルから脱却され、たとえば部分処理の積み重ねから想定外状態が生まれることを防ぐ。

SPAは、クライアントが自立した1プログラムとして状態管理する。サーバUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバサーバサイドページ生成のスタイルを、サーバブラウザでやるようにシフトさせたものともみなせるだろう。

そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。

すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

Reactのモデル関数型プログラミングモデルのものであって、そういう観点ではすでに何年も続いたものであり、React自体は消えたとしてもその手法は長く続くことになる。

2016-05-20

さっきのこ

蓮實重彦三島賞事件があったじゃないですか。

候補のメンツニュースで見た時にはお茶吹いたけど、やっぱり蓮實氏が取ったなあと思って、

伯爵夫人」読んでみたくなって、Amazonで探したら。6/22発売で、まだ「BOOKデータベース登録されてないらしく。

紹介文がね、すっごい。



『おそるべき戦場は寝台の上にある――。エロススリルの往還で深さを増す物語東大総長が意を決して書き上げた、衝撃の長篇小説。』



1行目は、三文小説の帯みたいだけどまあいい。

2行目。「エロス」のあとに「スリル」って…スパイ小説じゃないんだから

3行目。wikiったら「東大総長」が出てきたんだろうか。

「意を決して」 …これ。ここすごい。

そして締めが良い。「衝撃の長篇小説」。よくある惹句ですね。



ハスミンの眼にこれが止まらないことを祈る。

2016-05-19

電車への飛び込み自殺者は顔と名前と経歴を晒すことにしてはどうか

彼等の殆どメンタル的に自分のことを広く知られるのは嫌がると思う。

自殺者の顔や個人情報が死後広く晒され当人過去に関わった人間他に周知されているのを見たらかなり嫌になって他の自殺法を選ぶだろう。

メディア晒すのが1番望ましいし

次点では指名手配犯の様に紙で駅に貼りだすのがよいが

手間や良識ぶりっ子の抵抗を考えると最初web検索すればいつでも出てくる感じのデータベース収納が望ましいだろう。

2016-05-07

ドナルドトランプ氏の発言暴言が気になったので一覧にしてみた」の引用元

http://shijinblog.hatenablog.com/entry/2016/05/06/210458

ホッテントリ入りしていたこ記事

ドナルドトランプ氏の発言より引用」とか書いてるけど引用馬鹿にしてるのか。

例えば

「(イスラム教徒データベース登録すべきかという記者質問に) 絶対実施する。データベース以外にも、いろいろなシステムを備えるべきだ。」 「米当局事態を把握できるまでの間、イスラム教徒アメリカ入国禁止にすべきだ。」

http://nyaaat.hatenablog.com/entry/donald-trump-remarks-comments-quotes

http://www.excite.co.jp/News/society_clm/20160304/Mediagong_15423.html?_p=2

から引用だし、

日本人ウォール街アメリカ会社を買い、ニューヨーク不動産を買っている。多分、マンハッタン自分たちのものにしたいんだな。日本人と競り合っても勝てる見こみはない。どうみても彼らはこちらをコケにするためだけに法外な金額を払っているとしか思えない」

http://gendai.ismedia.jp/articles/-/35508

ここ。

他のもどこかのニュースサイトや、2chコピペから引っ張ってきたやつ。

引用」と書くならきちんと引用元を書こう。

2016-05-02

個人情報保護法

個人情報保護法

・今回の注意点

個人情報プライバシー侵害がどう違うか どう関係するか

どこまでが保護されるのか

義務は誰にある?

二段階の判断 (原則)

個人情報個人情報保護法定義に収まるか?

送信した人はこの法律でいう個人情報取り扱い事業者であるか?

事業者でなければ法律適応されない

個人情報とは? ・・責任を負う人を限定している

生存している特定の個人を識別できるもの

氏名など。

⇒亡くなった人はこの法律では無理


学校社会で名簿を作成して配布することは

個人情報侵害になるのでは?

⇒本人の同意を得て作成することができる

カメラ他人勝手撮影することは、個人情報保護法違反か?

動画写真を撮った人は事業者か?

ならない。ただし肖像権違反にはなるかも

別の法律違反になることになる

(他人権利侵害する場合がある)

個人情報保護する義務のある人は?

個人情報取り扱い事業者

5000件以上の個人情報個人情報データベース等として所持し事業に用いている事業者

個人情報ダメならプライバシーの方が限定がなく範囲が広いのでこちらで罰せられる場合がある。プライバシー限定がない。

個人情報保護法個人情報範囲保護義務主体限定している

テストに出すと言っている

Googleストリートビューは個人住宅など プライバシー侵害でないのか、どうなのか なる?ならない?⇒考えて欲しい

2016-04-30

昔、仕事データベースPCインストールしていた時のことだ

それぞれ皆、自分PCインストールしていた

丁寧なインストーラーもなくマニュアルもない状態で、試行錯誤

入れたはいいが表示が英語日本語にならない

言語フォルダらしいところを見ると、同じ構造日本語英語で2つ

日本語フォルダをなんとなく元フォルダに上書きコピーした

表示は日本語になった

別に知識があったわけでもない、そんな経験をしていたわけでもない

なんとなく、だ 確信も何もなく、やってみた程度

それを見ていた同僚が「は?そんなんたまたまじゃん、普通分かんねーよ」と鼻息の荒いコメントをした

しか確信はなかったが無闇矢鱈ではなかったし、なんとなく 感じるものはあった

運とかセンスとか表現されるのはこういうもんなんだと今になって思う

わかりやす努力トレーニングをした結果なわけではないが、何かしらの根拠のあるもの

運が悪いと感じていた自分を振り返りつつ

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

  • 必要以上のアクセス権をサードパーティに与えることになる。
  • 認証情報を格納する場所が増えるということは、盗まれる危険が増える。
  • パスワード等を変更したときに API 利用者側でも更新が必要になる。
  • ひとつアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
  • 特別な認証要素を使っていると、制限が多すぎる。

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、Permalink | トラックバック(3) | 12:44

2016-04-21

テレビで、野球選手名前のみで替え歌する人たちが出てた

母音が何かのデータベースもあるらしい

へーとは思うけど、テレビで取り上げるほど面白いとは思わなかった

深刻なネタ不足だなテレビ

日曜夜のもやさまは親も好きで一緒に見てる

三村マサカズ健康やばいのにガバガバ食ってて心配になる

2016-04-19

カセットテープを大量にデジタル化した時のメモ

色々あって大量のカセットテープデジタル化した時のメモ

なお音質は特段こだわりはなく、数を取り込んだ話です。

再生機器や録音機器

再生機器NR付きの方が後々楽(後述)。

録音形式はある程度の音質で取り込んでしまえば後で加工してしまえばいいのであまり考えない。

音質云々は割愛

後処理

曲分割

ある意味一番時間がかかるのがここ。

NR付きの再生機器ならテープ録音状態によっては機械的に分割処理かけてしまえば簡単に綺麗に分けられる。

ただこれが使えないテープ場合手動で分けることになるがこの場合大変。

このとき必要なのは時間だが、古いと曲名だけで時間は意外と載ってなかったりする。

最近Google先生が気を利かしてくれて、そこそこ有名だとアルバム名で検索すると曲時間が簡単に出てきたりする。

この情報経由で動画等を検索できる便利な情報だが、この表示されている時間情報動画時間から自動生成されているらしく偶に変な情報があったりする。

タグ付け

これが面倒かというとそこそこ有名な曲ならば簡単だったりする。

対象の大半がCD化もされているような音源だったので(ならデジタル化する必要は?とは言わないで)Gracenoteのデータベースを引っ張ってくれば簡単。

今は既存音源からでも検索がかけられるので、適当アルバム単位検索すれば大抵引っかかる。

自分場合この作業にはMedia Goを使っているが、そのままだと引っかからない場合でもアーティスト名やアルバム名のタグ情報を入れて再検索をすればまず存在する。

言語で出ている作品場合、別言語タグ情報に書き換えて検索すると引っかかったりもする。

またGoogle Play Music場合、あちらでデータがない曲で一度間違ったタグ情報で上げると記録されるのでタグ情報を書き換えてアップロードしてもそのままでは反映されないので注意。


ノーマライズ

後でバッチで一度に処理すれば良いという考えで保存用に関しては特にこの処理はしない。

保存等

現代HDDBDなら、FLAC可逆圧縮でもかけておけば一本辺り200MB~500MB程度と大した容量にならないので普段用と別に保存してても大して逼迫しない。

これが今デジタル化しようとしたきっかけの一つ。

保護にはBDならMultiPar等でパリティを付けて保存、ディスクの保管はBD対応した不繊布でもいいが数百本取り込んでも数枚程度なので転写が嫌ならハードケースで保存してもスペースには問題ない。

BDは今のベアディスクタイプですら10年近く経った規格でそれなりに成熟していると考えられるのと、かなり減ってきたがまだ地方だと相次いだメーカー撤退による投げ売りが偶にあるのでネットで買うより処分品狙いで買ったほうが安かったりする。(狙い目はDVDレンタル店)



流れ作業で行う場合

データとともにカセットテープのケースやインデックスカード画像データを保管しておくとアルバム名等を確認する際に現物をいちいち確認する手間がなくなるので捗る

またミスで再取り込みになった時も画像を手掛かりに現物ピックアップできる。

カセットテープ本体はCISスキャナしかない場合取り込みは困難なのでインデックスカードだけでも取り込んでおくだけでもいいが、その場合音声データを取り込む前に本体のラベルインデックスカードが正しい組になっているか確認したほうがいい。

ただ単純なインデックスカード場合スキャナドライバの性能によるがそこまで面倒ではないものの、特別意匠をこらされている場合この作業は凄まじく面倒になる。


結論

自分のような勿体ない症のような人以外は特別もの以外はカセットテープデジタル化は止めておいたほうがいい。

2016-04-16

Excel使えます。っていうな!

事務職面接で「Excel使えます!」ってアピールしてくる人がいるけど、実際できる人がいない。

しょうがないので、入社後せめてvlookup程度の関数についてレクチャーするがそれすら覚えてくれない。

Excelなんてデータベース関連の関数使えなければ意味がないと思うので、それすら使えない人は「Excel使えます」なんていわないでほしい。

そうじゃないと結局、こっちが仕事の仕組みを考えて入力フォーム作って「この書類がきたらこフォーム入力してください」程度まで落とし込まないといけない。

同じような給料でそれはあまりにもと思ってしまう。

2016-04-15

イケてる人工知能研究者の見つけ方

ちまたでは人工知能ブーム

多くの企業人工知能を使ったサービスをやりたいと思っていることだろう

しかし大体の企業人工知能研究者なんか抱えていないのでアカデミックにいる研究者リーチしてくるはずだ

ではどういう研究者リーチすればいいんだろうか?

今だと新聞にも人工知能機械学習研究者へのインタビュー記事が良く掲載されている

そういう研究者リーチすればいいんだろうか?



答えはノーだ

新聞インタビューに出てくるのは「昔すごかったけど今はあんまりタイプ」か「研究派閥がすごいタイプ」のどちらかだ

現役でバリバリやっている研究者を見つけるには業績が一番てっとりばやい

特に人工知能を含むコンピュータ科学の分野では国際会議(カンファレンス)が重要視されている

なかでもトップカンファレンスものすごくレベルが高くグーグルマイクロソフトリサーチなどIT巨人たちが切磋琢磨している世界

分野ごとのトップカンファレンスは大体以下のような感じだと思う

(*がついているものは第一線からすこし落ちる印象)



若手に限らず日本トップカンファレンスに通せている人は多くはない

上の会議に2本以上通せている人がいたらその人はホンモノだ

※細かことをいうと著者順も重要だがそれは省略

2016-03-31

選挙って何とかして減点方式にできないもんかなあ

連日アホのアホ言動ニュースばっかで本当疲弊すんだけど。

得票から減点投票マイナスするとかそういうシステム欲しくね?

正直その方が日本人dis気質にも合ってると思うのよ。

だって少子化対策担当保育園入れねーじゃねえかという意見にヤジとか飛ばしてんだよこの国では。おま言うすぎんだろ。案の定保育関係何も動きないし。

こういうのダメじゃん。ダメって意志表示したいじゃん。

今のやり方だと投票白紙で出しても単なる無効票扱いだろ?

そうじゃなくて、お前はクソだ辞めちまえと思ってるっていうのをちゃんとあらわしたいわけよ。伝えたい、この思い。

あれじゃん、最高裁裁判官はバツつけて出せるじゃん。ああいう感じ。



政策政策政策で直接投票にすればよくね? だってどうせ公約違反とかすんだろ? 属人にする意味あんの?

つーか属人にしてるから未だに労基法違反にろくな罰則がつかねんだろ?

こないだ労基署外国人研修者に金払わねーうえ調査妨害した経営者だかなんだかを逮捕したとき法律上は当たり前のことやっただけなのに「異例」とか報道されてたぞ?

いい加減なんとかしなきゃならないのに誰も動きゃしねえ。動かないもんが投票対象に挙がるはずがねえ。

だったら動かないお前ら全員クソだと表明する仕組みがあってもいいじゃねえか。



あとそれと別件で、やらかした人のやらかしデータベース的なのないんかな。

選挙ときまでちゃんとこいつはダメって覚えておきたい。