【js】Parseのデータをランダムで1件だけ取得する

ちょっと前からParseというBaaS（ややこしい）で遊んでいます。

www.parse.com

前にmilkcocoaというBaaSで遊んでみて、あまりの簡単さ（コーディングもそうだし、静的ページで済むからサーバーが要らないっていうのもかなり大きい）に味をしめた感じですね。
というわけで、今回はParseを使ってデータベース上のデータを1件だけランダムで取得する方法。
javascriptです。

function loadRandomData() {
	var ObjCnt = Parse.Object.extend("Hoge");
	var queryCnt = new Parse.Query(ObjCnt);
	queryCnt.count({
		success: function(number) {
			var Hoge = Parse.Object.extend("Hoge");
			var query = new Parse.Query(Hoge);
			query.skip(Math.floor(Math.random() * number));
			query.limit(1);
			query.find({
				success: function(results) {
					var object = results[0];
					//処理
				},
				error: function(error) {
					alert("Error: " + error.code + " " + error.message);
				}
			});
		},
		error: function(error) {
			alert("Error: " + error.code + " " + error.message);
		}
	});
}

こんな感じ。
まず件数取得用のqueryCntで件数を取得して、件数をベースに乱数を出す。
で、skip()を使って乱数分データを飛ばして、limit(1)で1件だけ取得する、という構造。

データ数少なければ全件取得した上で乱数でインデックス決めて配列にアクセスしても良いんですが、
それだと10万超えたくらいからきつくなりそうな感じです。

おわり。

【読書感想文】How Google Works を読んだ その4

随分と間が空きましたが、How Google Worksの読書メモその4です。

その1はこちら⇒【読書感想文】How Google Works を読んだ その1 - 16bit!

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

※引用と個人的な感想が混合しています。ご注意ください。

事前の収益分析を行わない

それまでジョナサンが働いたことのある会社では、収益分析で良い結果が出てからでなければ、まず新プロダクトにゴーサインは出なかった。（中略）それがグーグルでは（中略）誰も詳細な収益分析をしていなかったのだ。ユーザーにとってすばらしい機能なのは明らかだったので、それを実施するのが正しい経営判断であると誰もが考えたのだ。

その2か3に書いた、「ナレッジグラフ」の話と同様ですが、1番最初に考えることが「ユーザーにとって良いかどうか」であって、「利益が上がるか」は二の次、どころか、誰も考えもしていないという例です。

まぁ基本的には、「ユーザーにとって良い」⇒「ユーザーが増える」⇒「売上アップ」なのですが、製品やサービスを考える時点で利益のことを考えると、結局費用対効果を考えることになってしまって、ずば抜けて良いものというのはなかなか出てこなくなるし、何よりイノベーティブな製品というのはこれまでになかったものなので、そもそも収益分析をすること自体が無理、もしくは難しいです。それなのに、「収益分析でちゃんと利益が出るという確証が得られてないのに、ゴーサインは出せないなぁ」とか言ってると、絶対にイノベーションは起きないですよね。

これまでの投資額にかかわらず、負け組への支援は打ち切る

経営陣の役割は、これまでの投資額にかかわらず勝者を支援し、敗者への支援を打ち切ることだ。

上の話とも関わりますが、事前の収益分析をせずにリリースし、ユーザーの反応やフィードバックを受けながら手直ししていくという手法は、特にWebサービスなどではよくあることですが、これをやっていると、どうしても「リリースしたものの、いまいち伸び悩んでいる」みたいなことが普通に起こります（収益分析してても起こります）。
その際、経営陣やプロダクトリーダーとしては、このままサービスを継続して改善していくのか、それとも撤退するのかといった判断をすることになりますが、この時重要なのは、「それまでの投資額に関係なく」それを判断することです。どんな製品にもそれまでに投資額や従業員の頑張りといったものがあり、それが大きければ大きいほど、撤退したくなくなりますが、これまでに10億投資してようが100億投資してようが、打ち切る判断は公平に行わなくてはいけません。

「テクノロジーはツールに過ぎない」か

どうやら従来型企業は、選択を迫られているようだ。（中略）テクノロジーは変革のツールではなく、単にオペレーションを最適化し、利益を最大化するために使われる世界にとどまるのだ。こうした企業では、テクノロジーは別館に陣取るちょっと変わった連中が取り仕切るキワモノだ。CEOが毎週、議論の中心テーマに挙げるものではない。

企業におけるテクノロジー（特にIT）はこれまで、基本的に既存のオペレーションを最適化するものに過ぎなかったと思います。人事や会計はもちろん、SCMやCRMなどにおいても、ITは戦略の中心ではなかった。アマゾンなどのように、テクノロジーによる他社との差別化を戦略としている企業はほとんどありませんでした。
「ITはツールに過ぎない」ということが良く言われます。やりたいことを実現するためにITを活用するのであって、実現するための最適な方法がITではないなら、ITなんか必要ないというものです。僕も基本的にはこの考えに賛成なのですが、ITは「過ぎない」と言い切ってしまうにはあまりに強力なツールだとも思います。少なくとも、戦略を考える際におまけにして良いようなものではないと。

聞かれて嫌な質問

企業には必ず「聞かれて嫌な質問」があるが、聞かれないままのケースも多い。良い答えがなく、誰もが不安になるからだ。（中略）少なくとも一つメリットがある。一番嫌な質問は、大企業のリスク回避的な、変化に抵抗する傾向を抑えるのに絶大な効果を発揮することがある。

ここでいう嫌な質問とは、決して「売上下がってますが、大丈夫ですか？」みたいなのではなくて、「今はうまくいってますが、将来こんなことが起こったらどうしますか？」というものです。基本的に企業は、というか人は、うまくいってる時には嫌なことを考えたくないし、考えない。
何か一つイノベーションを起こし、それによって今はうまくいっているとしても、近い将来に他社がそれを上回る何かを起こすかもしれない。常にそれを考え、5年後、10年後の世界を想像し、その世界で自社が何をすべきかを考える必要があります。そして、5年後、10年後の世界が今の世界の漸次的な延長線上にあることはほとんどあり得ず、それはおそらく級数的に進歩した世界になっているはずです。

まとめ

読書感想文記事が4本にも分かれてしまいましたが、それだけ色々と自分の中にメモしておきたいことがある本だったということで、おもしろかったです。「計画を立てない」、「独立採算にしない」、「収益分析をしない」など、単純に経営の上での常識はずれな話から、「ユーザーのことだけ考える」、「技術的アイデアから考える」など、プロダクトを考える上での視点、「ラーニングアニマル」や「5年後を考える」など、自分についての考え方など、本当にいろんなことが載っている本だと思います。

また、これまでの小タイトルには出てきませんでしたが、本書には「テクノロジー楽観主義」という言葉が出てきます。まぁ簡単にいうとテクノロジーが世界を良い方向に変えると信じているということなのですが、このフレーズも個人的にかなり好きです。上にも書きましたが、テクノロジー（特にIT）はツールと呼ぶにはあまりに大きな力を持っていると感じていて、「世界をちょっと便利にする」だけのものであるはずがないと思っています。チームラボの猪子さんも確か「デジタルテクノロジーが世界を変えるとほとんどカルト的に信じている」みたいなことを言ってましたが、割と本気で、テクノロジーのことをもっと信じて良いと思います。

ということで長くなりましたが、『How Google Works』の読書感想文おわり。
その1に書いた人工知能の本も読んだので、そっちも感想文書きたいなぁ。

【js】Webサイトに埋め込んだYouTubeの動画IDをボタンクリックなどで変更する方法

YouTubeのiframeのAPIを使ってWebサイトにプレーヤーを埋め込む方法については、公式リファレンスにサンプルコードがそのまま載ってます。

iframe 組み込みの YouTube Player API リファレンス  |  YouTube IFrame Player API  |  Google Developers

が、再生する動画を動的に変更したい、例えば、

・サーバから再生する動画のIDを読み込んで、それを再生したい
・ボタンを押すと動画が変わるようにしたい（テレビのリモコンのように）

とかを実現しようと思うと、公式リファレンスのそのままコピペが使えず、ちょっと手を入れてあげる必要がありますので、メモ程度に書いておきます。

備忘メモ

まずはサーバ等から動画IDを取得し、それを引数にしてプレーヤーを生成する方法の一例。

var vId;

//画面ロード時に動画IDの読み込み処理を行う
window.onload = function(){
	loadVideoData();
}

//動画情報ロード
function loadVideoData() {
	//1.コールバックでプレイヤーの読込を呼ぶとか
	dataManager.load(function() {
		loadPlayer(vId);
	});

	//2.普通に読み込み > プレイヤー呼び出しするとか
	vId = dataManager.load();
	loadPlayer(vId);
}

//プレイヤーの生成
function loadPlayer(v_Id) {
	//プレイヤー生成
	player = new YT.Player('player', {
	height: '360',
	width: '640',
	videoId: v_Id,
	events: {
		'onReady': onPlayerReady,
		'onStateChange': onPlayerStateChange
		}
	});	
}

こんな感じ。
公式リファレンスのサンプルだと、「2」のAPIのコードのダウンロードが完了した瞬間にプレーヤーの生成が行われてしまい、動画IDをセットしてあげている暇がないので、「3」の部分を丸々削除して、自分でプレイヤーの生成を呼ぶようにしてあげることで、任意の動画IDを指定してプレーヤーを埋め込むことができます。

次、ボタンクリックとかで動画を切り替える方法。

function onClickButton(){
	setVId();
	playNewVideo();
}

function playNewVideo() {
	player.clearVideo();
	player.loadVideoById(vid);
	player.playVideo();
}

こんな感じ。
clear > load > play というシンプルな流れですね。

終わり。

【js】milkcocoaを使って「見てるYoutubeの動画が勝手に同期されるページ」を作ったよ

先日、milkcocoaがパワーアップしたと聞いたので、またちょっと遊んでみました。
ただし、パワーアップした部分の機能は全く使っていませんww

milkcocoaとは

https://mlkcca.com/

BaaS(Backend as a Service)に分類されるサービス。
Javascriptを1行書くだけで、データアクセス周りのバックエンドを肩代わりしてくれるというものです。
アクセスの方法もシンプルで分かりやすい（APIのドキュメントも結構充実してる）のと、
複数端末からの同時アクセスでもリアルタイムに同期されるのが素晴らしいです。
ほんとにビックリするくらい簡単なので、趣味プログラミングやプロトタイプ作成にはもってこいかと思います。

つくったもの

MilcoTube

milkcocoaとYoutubeのiframe埋め込みAPIを使って、
「誰かが見ている動画を変更したら同時にアクセスしている他の人が見ている動画まで変わってしまうページ」を作りました。（プロトタイプですが）

上記からアクセスできるので、せっかくなので動画を差し替えるなりチャット欄にコメント残すなりしていただけると幸いです。

なお、正直何の役に立つのか分かりませんが、思いつくものとしては以下のような使い方が出来るかなぁと。

・何らかの作業用BGMが常に流れてるページ
動画はリピートされるようになっているので、作業用BGMとして何かの動画を流しておいて、誰かがBGMを差し替えたいなと思ったら他の人のも変わる、という使い方。
作業用BGMって、「正直何でも良い」って人も結構いると思うんですが、そういう人にとっては毎回探すのも面倒なので、誰かがセレクトした楽曲が常に流れているページ（しかも時々勝手に変わる）というのはちょっと便利かもなと。

職場とかで、「作業用BGMは欲しいけど、探すのはめんどくさい」という人が何人かいたら、これを使うといいかもしれません。
また、休憩時間を各自で勝手に決めて取っているような場合は、チャット欄でコミュニケーションが生まれるかもしれません。

・同じ動画を見ながらチャットしてコミュニケーションを楽しむページ
面白いと思った動画などをコミットして、それを見ながらチャットするという使い方。
お気に入りのお笑い動画とかを見て欲しい時の、
「あれ面白いから！URL（または検索ワード）送るから見て！」→「見たよ！面白かった」
というやりとりが1ページで完結するから、ちょっと便利かも。
上記と違って、見ながらチャットもできるし。

ただ、動画IDが連携されるだけでシークバーとかは同期されないので、全く同時に見ながらリアルタイム実況みたいなことはやりづらい。
別々の場所にいる人が映画とかアニメ見ながらリアルタイムにチャットできたら結構いいかなと思うんですが、そういう使い方にはやや不便です。
huluとかを完全に同期して見れるととても良いと思うんですけどねー。

プロトタイプには実装しなかったけどあったらいいなと思うもの

プロトタイプには付けていませんが、チャンネル機能があるといいなと思います。
ユーザー管理を付けてユーザーごとにチャンネルを持てるようにするとか、
ジャンル毎にチャンネルを作っておいて、同じ作業用BGMでもジャンルや傾向で分けておくと、
「BGMなんでもいいけど、うるさいのは集中できないから嫌」みたいなのにも対応できるので。

あとはYoutubeの動画を検索できるようにもなっていると便利、というかそれが無いと実質Youtubeと2タブ開いてないと何も出来ないのですが、
動画検索の方のAPIは埋め込みのAPIよりもややこしそうだったので実装できていません。

感想

正直何の役にも立たないものを作ったなぁと思っているのですが、何の役にも立たないものを作るのって楽しいです。
もちろんプロのえんじにゃーとしては役に立つもの、価値があるもの、メリットがあるものを作るのが当然なのですが、
趣味プログラミングで何の役にも立たないものを作るのはそれはそれですげー楽しい。
誰か一緒に趣味プログラミングしてくれる人いないかなぁ。

Youtubeのiframeの埋め込みの部分とか細かいソースの話は時間があれば今度書きます。

終わり。

【読書感想文】How Google Works を読んだ その3

How Google Worksの読書メモその3です。

その1はこちら⇒【読書感想文】How Google Works を読んだ その1 - 16bit!

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

※引用と個人的な感想が混合しています。ご注意ください。

五年後の自分をイメージする

まず、現在ではなく五年後の自分に取って理想の仕事を考えてみよう。どこで、何をしていたいか。（中略）たとえばその仕事を転職サイトに載せるとしたら、どんな説明になるだろう。

僕が新卒で就職活動をした約5年前には、「死ぬまでに何をしたいか」をゴールとして決めたり、「10年後にどんな人間になっていたか」を考えて逆算したりしていましたが、実際に社会人になってみると、これはちょっと無駄に長過ぎる視点だったなぁと思います。
実際数年間で自分の理想とするゴールなんてころころ変わったし、内的要因だけじゃなくて外的要因もどんどん変わる。
そんな中で10年以上先のことを決め打ちするなんて無駄だし、むしろそれに引っ張られる方がリスクがある。
そういう意味でも5年後くらいのイメージというのはギリギリ見通せる長さとしてちょうど良いと思うので、常に5年後くらいのマイルストーンを意識しながら、都度都度方向修正するのが良いような気がします。

あと、自分の仕事内容をちゃんとシンプルに言語化することっていうのも、キャリアの上では結構大事なことだなと個人的には思います。
「どこで、何を、どのくらいやっていた」という説明で、他人に「自分に何ができるのか」をイメージしてもらうことが、市場価値を見いだしてもらうためには必要なんだろうなと。

データに基づいて決定する

事例の複数形はデータである。

さまざまな選択肢や見解について議論する会議では、まずデータを見るところから始める。他の人を説得するのに「私が思うに…」という言い方はしない。「ちょっとこれを見てください」と言うのだ。

誤解を恐れずに言えば、意思決定のための情報は多ければ多いほど良いはずです。
母数が大きくなればなるほど異常値がもたらず影響が小さくなり、正しい事実に近くなるので。

確かにこれまではあまりにも多くのデータはむしろ判断を遅くする原因でもありましたが、これは技術の発達によって解消されつつあるので、「全てのデータ」を分析して意思決定に利用することが現実に可能になってきました。
これはとてもありがたいことで、少数の事例（しかも属人的な）による判断だと、どうしても主観による意思決定になりがちで、その場合、どうしても組織内でヒエラルキーの高い人間の意見が重要視されることになるのを、事例をデータとして分析することで、主観やヒエラルキーの影響を抑えられるようになる。
その結果、例えばヒエラルキーの高い人物が持っていた事例が異常値であった場合などの誤った意思決定を防ぐことができます。

ドリー

そこで「ドリー」という名前のシステムが誕生した。

これは単純に面白い仕組みだとと思ったのでメモ。
Googleの社内で利用している経営陣への質問ツールで、誰でも匿名で質問をドリーに投稿でき、社員が良い質問か悪い質問かを投票し、毎週開催される全社向けのミーティングにて、投票で上位になった質問から経営陣は答えていく、というもの。
経営陣への意見や質問を吸い上げる仕組みは色々な会社で工夫されていると思いますが、投票によって質問が決まるというこの仕組みはなかなか良いなと思います。
目安箱を透明化したみたいなシステムですが、多くの質疑応答の時間が限られている多くの場合において、この仕組みは活用できるのではないかと。

イノベーションを起こすなら、競合がひしめく市場で

イノベーションにふさわしい環境とは、たいてい急速に拡大しており、たくさんの競合企業がひしめく市場だ。（中略）からっぽな市場にはたいていそれなりの理由がある。企業の成長を維持するだけの規模がないのだ。

起業する場合のある種の定石として、大企業が手を伸ばしていないニッチな市場を狙うというのがありますが、それとは反対の考え方。
確かに、パイが小さい割に市場の変化が速かったりして割に合わないため、大企業が手を出していないニッチな市場にスピーディに参入して、臨機応変にニーズの変化にも対応することで利益を上げることはできるが、これだとどうしても企業の成長はある一定のところで止まってしまう。
逆に大きな市場だと競合も多いが、技術的イノベーションによって他社との明確な競争優位を確率できれば得られるものも大きいし、企業もかなり大きなところまで成長できる。
「目を付ける速さ」で勝負するにはよくない市場ですが、前のパートで述べたみたいに、技術的アイデアに基づくイノベーションで勝負するなら、既存のパイが大きな市場ほどチャンスが大きいということになる。

また、ちょっと話は変わりますが、最近のWEBサービスやスマートフォンアプリとかを見ていても、「これはちょっと便利になるな」とは思うのですが、「これはものすごく便利だな！」というものはあんまり無いよなぁと感じています。
ニッチなところを狙っていたり、かゆいところに手が届いていたりはするのですが、やはりそれだけだと既存の競合を駆逐してしまえるようなインパクトは無くて、「ちょっと便利」ばっかりが起こっているのが個人的にはもにゃっとします。

アイデアの自然淘汰（ダーウィンの進化論）

とても生き残れないほど多くの「アイデア」が生まれる。その結果、生存のための闘いが繰り返される、複雑で、ときには変化する状況においては、たとえわずかでも自己保存に適した変化を遂げた「アイデア」ほど生き残る可能性が高まり、自然選択される。

上記はダーウィンの『種の起源』の一説を、「アイデアの自然淘汰」に書き換えたもので、「たくさん生まれたアイデアの内、環境に適した進化を遂げたものがイノベーションへと辿り着く」ということを表している。
アイデアは生まれた時点ではちょっとした単発の改善でしかないので、それが進化していって大きなイノベーションにつながるという考え方は割としっくりきます。

つまりアイデアはなるべく多く、それこそ淘汰されること（＝失敗すること）を前提として出てくる必要があり、そういう意味では全ての社員に、アイデアを発信し、他者を巻き込んでも良いだけの自由と権限、そして失敗を許される権利を与えることが必要になります。
さらに言えば、アイデアの優劣を決めるのは純粋な自然淘汰によってなされるべきで、誰のアイデアかといった政治的な要因に影響されてはいけない。
これらは全て企業文化によってもたらされるもので、したがってイノベーションというものは一朝一夕では成せないということになりますね。

//
その3はここまで。
長さとメモしたいことの数的にはあと1つで終わる予定です。
書き留めておきたいことがたくさんあって長くなっていますが、基本的には自分宛の読書メモが主目的なので、まぁいいかな。

いったんおわり。