山本ゆうごブログ

山本ゆうごの仕事メモ

ユーグレナのコアバリューを考えてみる

この記事 http://www.recomtank.com/entry/euglena をみて、いろいろ思うところあり。

起業から上場までのストーリーはR&Dからのスタートアップということで、注目は浴びておりました。

ただ、ビジネスとしては、健康食品というところで落ち着いている。

元は、食糧問題を解決するためのソリューションだったはず。しかしながら、ガチの貧困地域は金がないので売れない。そもそも貧困地域に直接食い物を渡すのではなく、本当なら貧困地域が貧困でなくするようなソリューションが必要。

一方で、貧困が解消するにつれ国民が金を持ち始めると、完全栄養食品よりも不健康な食事の方がニーズが高く、最終的にはダイエット食品に金が集まる。

本当に貧困地域の課題解決が金になるのなら、今頃アース製薬は超巨大起業になっててもいい(今でも大企業だけど「蚊を退治する」という社会的価値からすればマイクロソフトなみの会社でもいいくらい)。

そんで、ユーグレナです。食糧問題解決は金にならない。もう一つのイノベーションとしては、「燃料が作れる」ということ。石油王になれるとなるとこれは急に見る目変わりますよね。すごいすごいと。

1平方kmの培養プールで生産できるミドリムシは油脂換算で日間約11.4t

とある。一見すごい気がするが、1平方kmってでかすぎる。100万平方メートルなので。現実的には千分の1の1,000平方メートル換算にしましょう。20×50メートルのプールならそのスペースで何できるかが分かる。 改めて計算すると、

1000平方mの培養プールで生産できるミドリムシは油脂換算で日間約11.4キロ

ミドリムシの油脂の密度は知らないが、ざっくり10リットルとする。

ちなみに10リットルの原油がどれくらいかの価格かというと、今は1バレル(160リットル)40ドルだから、1リットルあたり約25円。原油と同じ価格で売るなら(売れるのか?)、一日250円の売上。プール1個の面積から燃料を得ようとすると年間では約8万円の売上。これちょっと厳しい。同じ面積つかうなら別の商売したほうが良さそう。

まとめると、ユーグレナ自体の技術的ブレイクスルーはすごいのだけど、商売を考えると、以下の点が課題。

  • 食料問題の解決はビジネスにはならず、必要とされているのは痩せ薬
  • 今あるエネルギー問題は、エネルギー不足ではなく、エネルギー価格が安すぎて投資が回収できないという問題

元を正せば、食べ物も燃料も原価までたどるとめちゃくちゃ安い。商売しようとすると、ある程度の「期待価値」みたいなのが必要で、結局将来的にも健康食品としてのポジションが一番ビジネスになるとは思う。「完全食品ミドリムシだけで絶食合宿!」みたいな「コト消費」にすれば、客単価15万もありえる。

あとは、日本の自治体が学校給食の地産地消をうたっているわりには地元の農産物の生産能力がないので、学校給食を独占するという手もある。

Google Cloud Strage の東京リージョンができたので、巨大なパラパラ漫画を実装してみた

やっとGoogle Cloud Strageの東京リージョンがオープンしました。 S3+CloudFrontの組み合わせのように使えるので、配信にも便利かも知れません。

手順は以下の通り。

  • バケットを作ります
    • バケット単位でリージョンは選べますが、東京リージョンが選べるのは、Regionalというストレージクラスだけのようです。
  • ファイルのアップロードはコンソールからできる
    • S3でもそうですが、ブラウザからアップロードできます。
    • フォルダのドラッグ&ドロップでもアップロードできます。
  • 一般公開はファイル単位
    • フォルダ単位での公開ができません
    • 「デフォルトのオブジェクトの権限の編集」はできますが、アップロードする前に設定する必要があります

そして、大量のjpegをアップロードして、パラパラ漫画にしてみた

画像を高速に切り替えてアニメーションにするというのは、CSSスプライトでよくやる手法ですが、今回は大きな画像でコマ数も多いので、そのままロードします。アニメーションが始まるちょっと前に、JavaScriptの中で、Image オブジェクトをnewして、srcにセットしておきます。あとは、setTimeoutで、ちょっとずつずらしながら、1個のimgタグのsrcを書き換えていくだけ。

デモ

https://storage.googleapis.com/yugoyamamoto/parapara/dance.html

1280pxの巨大な画像を24fpsで動かしてみましたよというデモです。この実装では、3割ほど画像がロードされたらアニメーションが動き始めるロジックにしています。あとは、ロードしながら追いかけてアニメーションします。一応スマホでも動きました。流石にこのサイズのimageオブジェクトが大量になると動きは怪しいですが、画像が一度キャッシュされるとスムーズにアニメーションします。(手元のGALAXY Note3での検証)

影響力の武器をベースにした転職活動

「影響力の武器」というまぁまぁ有名な本がありまして、それを転職活動につかうとどうなるかという話。実際に採用する側もこういうことで左右される。

理由付け

志望動機そのものだが、大した理由でなくてもいい。理由があることそのものが大事。過去の自慢話した後に「なので御社にも貢献できると思ったんです」でいい。

返報性(reciprocation)

何かお土産を持ってく。交渉の現場では、「いい情報」。競合他社の採用現場の状況がわかるといい。やりすぎると秘密の漏洩になるのでほどほどに。

希少性(scarcity)

他社での採用活動が進んでいるように見せると、早く決めなくちゃいけないと思う。

権威(authority)

いわゆるアレオレ詐欺。前職ですごい仕事をしていると思わせる。実際にやっていれば素直に「分かりやすいラベル」でアピールする。

コミットメントと一貫性(consistency and commitment)

一般的な交渉事では、小さな合意を相手から引き出して、「やっぱりヤメ」ということができなくなるようにする。採用の現場では、面接とは別に面談をお願いして、「次の約束」を細かく取りつける。何度も会ってるということ自体が「正式採用間近」に見える。逆に急にアポが取りづらくなったら、「一貫性」を保つために、最終結論もNGの見通しが高い(これは、普通の営業現場でも同じ)。

好意(liking)

そもそも、御社のことが好きですということは最低限言う。

社会的証明(social proof)

本出してたりすると分かりやすい。原稿料が安くてもいいので、共著で何か執筆しているとAmazonに著者として名前が載る。

SQLとO/Rマッパーのポエム

SQLとO/Rマッパーのポエム

http://qiita.com/kantomi/items/f527bc717b10e86335af に関して、最初にO/Rマッパーを見た時の感想としては、同じ印象をもちました。

O/R マッパはSQL知らなくてもいい説には反対

なので新人研修の際には、ActiveRecordを触らせる前には必ず、素のSQLも手書きで一通り書かせている。phpmyadmin やsequel proを使う場合にも素のSQLを書かざるを得ない。そんなのエンジニアじゃなくて今どきのWebディレクターならやってる。

したがって、ORマッパを使ったところで、二重に勉強しないといけないというのが正解かなと。

わたしが作ってる研修メニューでは、 ・素のSQLを一通り覚える ・Railsを通すのではなく、素のRubyにActiveRecordeだけをrequireして、コードの中で接続し、 ActiveRecord::Base.logger = Logger.new(STDOUT) で、どんなSQLが流れているかを一通り眺めながら、ActiveRecordの各メソッドが発行しているSQLを見せる。 ということをしている。

そこまでして二重に学習しなくてはならないの?って質問には、はいすみません、今どきの子大変ですね。でもソースはちょっとだけ見やすいですね。

逆にSQLをとことん高度にしてアプリまで書いちゃうというアプローチ

実はそういうプロダクトがあった。OracleSQLPL/SQLと言って、普通のプログラミングもできる。ストアドプロシジャとか呼んでる奴。プロダクトとしては、KeyWeb Creator という名前だった。しかしながら、そもそもストアドプロシジャの外でPL/SQLをつかう人もいなく、制約も多かったので、陽の目を見ることはなかった。ということで、市場原理の中ではSQLでは最強ではなくなった。

O/Rマッパーをつかうってことは、RDBをNoSQL的に使ってない?

これはYES。複雑なSQL使えないし、基本的な動きは、主キーでダイレクトに取ってくるだけの動きが多い。

心配な点としは、RDBはKVSにくらべて機能が大きいために主キーダイレクトで引っ張ってくるにしても、オーバーヘッドも大きいのではないかという懸念。これはエンジンごとにすごく違う。mysqlはスレッドタイプのコネクションなので、コネクションの接続からしてめちゃくちゃ軽い。

この辺の経験値というのが、業務アプリとユーザーサービスと結構違っている。 業務アプリでは、DBエンジンはOracleバッチ処理性能が大事 ユーザーサービスは、 DBエンジンはMySQLで、ユーザーレスポンスが大事 ユーザレスポンスを大事にするときって、凝ったSQLを書かないというのが割りと大事。レコードの件数によって、プランが変わるようなのは避けたい。

例えば、画面には数十件しかでないのだから、JOINせずに、主キーダイレクトで20回くらいアクセスが発生しても一向にかまわないのだ。

ここでも、RDBをNoSQLみたいに使ってるという批判はアリそうだけれど、主キーで高速にデータを取ってくるってこと自体は、mysqlに関しては超高速。甘えていい。

NoSQLを使えばいい場面でも、マスタの管理とか、主キーそのものがintで管理されていたりとか、実装レベルで便利だったりする。

プログラミングをゼロから始める人のためのRubyプログラミング

目的

プログラミングの基礎を学ぶ

なぜRuby

Ruby意外のしんどさを書いてく。

言語 しんどさ
Java IDEなしに素のプログラミングをやらせるの辛い。IDE経由だと何しているかわかりにくい
PHP Apache経由の動きだけになりがち。一番最初はレイヤーが浅い方がいい
Perl もう情報が少ない(リファレンス/デリファレンス/UTF8フラグが無駄にしんどい)
Python 次点としてありだが、Python3が完全普及するまで待っていいのでは?
C 自分はここから入ったのでいいけど、業務では使ってないので遠回りがすぎる。core dumpは初心者には遠回りがすぎる。

ということで、ターミナル上で、標準入出力を使ったプログラミングの基礎を学ぶには、Rubyが「ちょうどいい」。

標準入出力にとことんこだわる

  • 業務でも十分使える
  • いきなりMVCフレームワークを使うと階層がわからず迷子になる
  • Webフレームワークの環境構築で悩まなくていい
  • 多言語言語でも通用する考えなので、OS/IOとプログラミング言語の階層構造が理解しやすい。

標準入出力をベースにしたプログラミングの試験はスタンダード

PaisaやAtCorderやCodeIQなどのサイトは標準入出力で答え合わせをしている。それくらい「スタンダード」

学習の順番

  • Hello World
  • 引数をもらって「こんにちは◯◯さん」と出力
  • 標準入力をもらって「こんにちは◯◯さん」と出力
  • 標準入力で入ってきた小文字アルファベットを大文字にして出力
  • 標準入力で入ってきた数字を倍にして出力
  • 標準入出力をつかって対話型じゃんけん

次に覚えるのはSQL

AcitveRecordをいきなり触らない。裏で流れているSQLを知らないで開発できるかっていうと、直接SQLつかう機会は多い。ゲームのディレクターはエンジニアでなくてもちょっとしたSQLは書ける。もはやエクセルみたいなもん。

次に覚えるのはHTML

  • フォームヘルパーは使わない。まずはformタグを全部かく。
  • GETとPOSTの違いをしる。
  • input、select 、radio、checkbox、texture、hiddenを一通り手で作ってみる
  • Webアプリケーションフレームワークとしてはシナトラでお勉強する。Railsは何してるか分からないので。

次に覚えるのはcurlコマンド

  • フォームでPOSTしている内容を、curlコマンドで再現してみる。
  • ここで、ブラウザのデベロッパーツールの使い方を覚える(copy as curl
  • curlのパラメーターを変えて、何をリクエストすると何が帰ってきているかを知る。

・・・・続く。そのうち書く。あとは、そもそものLinuxの使い方として、grepとかlessとかvimとかsshとかscpとかその辺は徐々に覚える。

Googleのレファレンスを見ると自ずと言語の主観的評価が決まる

例えばこれ

https://cloud.google.com/datastore/docs/concepts/transactions

言語別に同じ機能を実現するコードが書かれている。

これを見ると、言語の思想が現れる。

意外なのが、Go言語のきったなさ。try-catchがなく、エラーが戻り値として返ってくる。それが全てifで分岐されているので、ビジネスロジックとしての分岐と、例外の分岐が区別し難い。実装上同じでも、ソースコードは人が見るものなので、ロジックとしてどう分岐されているのかをよみとりたい。

例外の分岐がテスト対象なのかどうかってところもあって、ファイルの読み取りの例外って、言語使用上はありえても運用上ありえなかったりして、テストする意味がないというケースもある。

Googleのレファレンスでは、Rubyが登場したりしなかったりする。海外ではスクリプト言語のデフォルトがPythonになりつつある。もうそれは認めないと仕方ない。

Node.jsもいいんだけど、処理が上から流れるのではなく、コールバックで繋いでいくから、「読む順番」が分かりにくい。コールバックをインデントするもんだから、ネストがどんどん深くなって、こんなコードになる。奥に奥に処理が流れるのつらー。

      });
    });
  });
}

コールバック嵐になるのって、実装上がそうだから仕方ないのかも知れないのだけれど、それは実装上の話で、ソースコードは人間様が読むのだから、多次元で読まなくちゃ行けないのってつれーって思う。

いちいち }); が登場するのが、文字数増えてやだなーとか。瑣末だけど。

まとめとしては、Googleのレファレンスをみていると、結局JavaPythonなのかなーって風にみえる。(Googleが標準で使ってるからそっちによるのも無理ないのかなー)

チャットの使用感比較

グループチャットの問題点

チャットはイイとして、グループチャットで未だにしっくりくるのがない。あれこれ比較しているので、そのメモ。 結論としては、検索機能が充実していて、グループチャットでの通知のレベル感がしっくり来るのがない。チャットでもスレッドが欲しくて、フォローしているスレッドだけ通知が強いというのが理想だなーって思う。

ただ、通知の重さをコントロールできるという一点に置いては、以下の選択肢の中では、Slackが一番まし。持続可能。

PCとスマホで両方でアクセスできるというのが大前提。 (随時更新メモ)

Skack

Slackいいところ

  • チーム > チャンネルという階層で、細かく分類できるので、観ようと思えば見れるという情報と、重めに通知が欲しいところと区別できる
  • Bot作りやすい
  • プログラムソースアップしたらシンタックスハイライトしてくれる

Slackダメなところ

  • 検索すげー面倒
  • デスクトップアプリ落ちがち
  • ラベルが英語なので、プライベートでの友人とやりとりする空気じゃない
  • チームが増え始めると、PCアプリとスマホアプリの両方にチームを登録するの億劫(で漏れていそう)

Skype

Skypeいいところ

  • 通話もシームレスにできる
  • たくさんの人がすでにアカウント持ってる
  • 日本語ラベル

Skypeしんどいところ

  • メンション有無で通知の重さが変わらないので通知ウザ過ぎ(仕事ではじきに使われなくなる)
  • スマホアプリうっかり通話しがち

FaceBookメッセンジャー

FBメッセンジャーいいところ

  • FaceBookのお友達からアカウントが見つかる
  • PCでもFaceBookでやりとりできる(ブラウザで便利)
  • 一時的に通知をとめるインターフェースが分かりやすい

FBメッセンジャーダメなところ

  • やっぱり一度グループチャットになると、通知の重さがコントロールできなくて、他人の雑談も常に通知がくる

LINE

LINEいいところ

  • スマホ持ってりゃほぼ100%に近いインストール率

LINEダメなところ

  • PC版をインストールしてる人少ない(アカウント乗っ取り騒ぎもあって外部ログインを許可しない人も)
  • プライベート過ぎて他の人に教えづらい(連絡取りづらい)
  • 通知の重さコントロールできない

gmailチャット

gmailチャットいいところ

  • gmailアカウント持ってる人やGoogleAppsを使ってる人は多いので使える人は多い

gmailチャットダメなところ

  • グループチャットできるように見えない
  • グループチャット始めてもエスケープ一発で消えて二度と開けない(再表示の導線深すぎ)
  • Google+ハングアウトって名前になってみたり、Google+との関係性が分からない