MDT(Marketing/Design/Programming) 良記事まとめ(Weekly)
以前よりは減ったものの、あいかわらず情報の海に溺れてアウトプットを怠って情報肥満になっているのでダイエットの意味をこめて
Plan（企画・マーケ）
Design（デザイン）
Programming（プログラミング）
という切り口で、weeklyで二度読みの価値アリな記事を独断と偏見を第一にまとめていく。MDTってまとめかたはいくらなんでもナンセンスなので検討中。
#----------------------------------------------------------------------------------
# Selected Articles
#----------------------------------------------------------------------------------
# Plan -> 来年こそWebサービスを作りたい人に伝えたい９つのこと - パパパパ
# Design -> デザイナーに贈る、世界の最新デザイン : Designer Founders Bookの取り組み
# Programming -> Essential JavaScript And jQuery Design Patterns – A Free New Book
#----------------------------------------------------------------------------------
# Plan
#----------------------------------------------------------------------------------
来年こそWebサービスを作りたい人に伝えたい９つのこと - パパパパ http://d.hatena.ne.jp/hajimeataka/20111215/1323919612
筆者の方は、基本一人でデザインから企画、開発をやっているそうでその独特の知見が面白いしとても参考にしている。
その内容もさることながら、個人でやっている開発にかんして刺さることがたくさんあった。偶然にも筆者の方も文系。まずはつくって出すこと。それまでの折れないココロが一番大事だと最近は思う。
#----------------------------------------------------------------------------------
# Design
#----------------------------------------------------------------------------------
デザイナーに贈る、世界の最新デザイン : Designer Founders Bookの取り組み http://tinyurl.com/787rqpc
“デザイナーが社会にインパクトを与える会社を創業するために、起業家が自分の思い描くデザインを現実のものにするために、その方法を世界中の人へ分け与えること”
デザイナーによるデザイナーのためのファンドという新鮮なコンセプトと共に、今後のDesigner Founders Book の活動をぜったいwatchしていきたい。「デザインの価値は、まだまだ本当の意味で認識されていない」「“複雑なことをシンプルに伝えること”」などとても共感できるキーワードもいろいろあった。
とくに複雑をシンプルに、というのは知識としては簡単だが、実際に自分がつくりたいもの、かかわっているものに関して行うことは非常に難しく常に意識しなくてはいけないなと感じている。そのためには、「これをとったらこのサービスがなりたたなくなるか？」という問いをさまざまな機能に問いかけしっかり考える必要がある。
#----------------------------------------------------------------------------------
# Programming
#----------------------------------------------------------------------------------
Essential JavaScript And jQuery Design Patterns – A Free New Book http://addyosmani.com/blog/essentialjsdesignpatterns/
programmingはかじってみて、関数やらcallbackやらフレームワークやらちょっとわかってきたけど、デザインパターンの会話に
全然ついていけていない僕のようなビギナーのあなたはすぐこれをDL。
きっと中級者以上の方にはもはや「お作法」程度の知識のようですが、コミュニケーションの土台となる知識は早めに
いれておきたいところ。AS3.0のデザインパターン本がいいとすすめられたのでMVCのとこだけ一緒に読んだりしている。
以上。ちょっとづつ考察なんかも今後は追加できていけるといいなとか思っている。
はてなblogデビュー
hoge
コンテキストとグローバル関数らへんについて
最近JapaScriptの勉強がてら、Titanium mobileつかって趣味でアプリでもつくろうかと思い、悪戦苦闘中。
とりあえずWindowにviewを埋め込んでつくっていくTitaniumの大枠はわかったので、もうちょっと凝ったのつくろうかと思ったらグローバル変数とか名前空間でハマりまくったのでメモ。
＃目次
・シングルコンテキストとマルチコンテキストの使い分け
・即時関数の意味がようやく分かりだした
・グローバル変数の導入
＃内容
■コンテキスト・マルチコンテキストちょいちょい勉強していると出てくるであろうwindow.url。これをを使って別のファイルにwindowを記述することができます。これがマルチコンテキスト。
メリットとしては、app.jsの肥大化を防いて、メンテしやすいコードがかけること。あと入門書とかがこっちでだいたい書かれているので勉強しやすい。
でもデメリットとして、コンテキストが違うためにおたがいの変数が見えず、画面遷移するとき前の画面のオブジェクトわたしたいとか、グローバルで使う
モジュールをロードしときたいとかできないのが不便。これが結構こまった。
調べてみると、windowオブジェクトに
newWindow = Ti.UI.createWindow
title:'hogehoge'
backgroundColor:'#fff'
url:'hoge.js'
hoge:'hoge'
ってやって渡せるらしいので、問題解決ではあるのですが、先のことも考えてこのあたりコンテキストについて調べていて次のシングルコンテキストとやらがあることを知る。
・シングルコンテキストマルチと逆で、window.urlを使わない方法。
デメリットとしてファイルを切り出さないのでメンテしにくいこと、Ti.include()して切り出したとしても、windowが増えていったとき、変数名が衝突してこれまた面倒なことになる。というかなった。
ファイルの肥大化についてはさっき書いた Ti.includeで教科書通り対応。
変数名については即時関数を使って、ブロックスコープで対応するとよいらしい。
参考：[ti.devs.me] window.urlを使わないプログラミング
http://blog.mogya.com/2011/09/tidevsme-windowurl.html
■即時関数
そこで即時関数を使って、ブロックスコープで変数名のかぶりをふせぐ。
即時関数はここがめっちゃ勉強になりました。
「知ってて当然？初級者のためのJavaScriptで使う即時関数(function(){...})()の全て」
http://d.hatena.ne.jp/sandai/20110824/p1
どんなものかというと
(function(){ var hoge = 1; var huga = function (){ return hoge; }; })()
ってやつです。定義と実行を一緒にやるやつです。
よし、これでメンテもしやすく、変数名もかわらず幸せになれる！
と思ったんですがまだ余ったです。
・グローバル変数の導入
includeFile内で即時関数内で定義すると、include先でぜんぜん関数が呼び出せないようです；
なので、include先、またはincludeファイルの先頭でグローバルオブジェクトを宣言しておきます。
tt.UI.create~
って感じでttがグローバルオブジェクト。こちらのコードがシングルコンテキストを美しく使ってて参考になりました。
https://github.com/appcelerator-titans/tweetanium
結局は、画面ごとが独立していて、すべてをグローバルにして管理するまでもないとしてマルチコンテキストを主体に使って、さらにここを参考に1つの画面をつくるのに
・hoge.js（処理）
・hoge_view.js（UI構成）
・hoge_style.js（プロパティ一式を切り出し）
って感じでファイルを分割していこうかということになりました。
最初値は渡せないしコンテキストは思うように扱えずエラーがでるしで、ここまでが長かった。。
勉強不足な初歩的な疑問なんですが、シングルコンテキストってあんなに一度にファイル読み込んでメモリのことって大丈夫なんですかね？
便利そうだけど抜本的に書きなおさなきゃだったのと、サーバーとのやりとりが主でそこまで共通部分が多くなかったので今回はwindowごとにシングルコンテキストっぽいことをして名前が散らばるのを防ぐことにしました。
coffeescriptがやっとなれてきて記述がだいぶ楽になってきた気がする。
以上メモでした。
一年後、世界を変えたwondershakeに聞いてみたい3つの質問
2012年末。
何人が一年前に予想していただろう、日本発のwebサービスが世界を着々と変えている。
wondershakeがやってのけた。去年の夏の米国でのリリース後、みるみるうちにユーザー数は増え、一ヶ月で10万ユーザー、半年で50万、なんと今では世界で200万人が、一日平均一回shakeしてHi!している。
「なんだ、まだまだたった数百万人じゃないか」と思った方は次のデータを見たことがある？foursquereは6万ユーザー集めるのに7ヶ月、twitterrは100万ユーザーに2年もかかった、と聞けばスマートなあなたは世界がwondershakeを中心に少しまわり出していることに気づくはず。
今日はそんなwondershakeの快進撃を、ファウンダーの@Dou・・・・
もちろん上記はフィクション。TechCrouchの引用では決して無い。でも現実になってもおかしくないな、と不思議にそう思わせてくれるwondershakeの鈴木くんがゲストのSUM（StartUpMorning）に昨日いってきた。
@Ihayatoさんや、言っていいのかわからない tech界隈の超大物ゲストと共に非常に面白いディスカッションと美味しい朝食を食べる会は、非常に有意義で刺激的でした。@umekidayoさんいつもありがとうございます。
そこでwondershakeに付いていろいろ聞いて、いろいろ思ったので書いてみる。
よくわからない人は、この動画を見ればどんな世界があなたを待ってるかすぐに分かる。
まず大前提として、メディアで多大な注目を浴び、多くのアーリーアダプター層が注目するサービスであること.まだ本当にリリースしたばかりでヒットしているか、という視点で議論する時期でないこと。サービスについては良記事がすでにあるのでどうぞ。
あえて客観的にwondershakeの立ち位置を見ると、yobongoやdemo、colorと同じ文脈のテイストグラフ、もしくはローカルグラフといった分野のプロダクトだろう。このまえサンフランシスコに行った際にどちらの競合のプロダクトも使ったが、どれもまだまだ大ヒットは飛ばしていないし、まだいろいろ問題点があるなと感じた。ヒットの芽がありそうで見えてこない状態が続いている分野である。
サービス紹介でも書こうかなーとおもっていたが、よい記事を書いてるかたがすでにいるので、ミーハーな自分としては、「大ヒットをとげたwondershake」という仮定のもとに未来のwondershakeに聞いてみたい3つの質問について考えてみた。このあたりが実はすでに明確な答えがあるのであれば、僕はwondershakeの成功を今以上に信じてやまないだろう。きっと下記の三つのうちひとつは気になってる人も多いはずだ。
■「なぜユーザーはwondershakeをリピートして使うのか？」
■「なぜwondershakeをついつい紹介してしまうのか？」
■「color？yobongo?belga?いやいやwondershakeがやっぱcoolでしょ。」の理由は？
ひとつひとつ簡単に考察しながら、意図を紹介していく。
■「なぜユーザーはwondershakeをリピートして使うのか？」
個人的に、位置情報、コミュニケーションなどのエンタメサービスで必ず差が出ているポイント。今もヘビーにつかってしまっているサービスをもう一度使う明確な理由が思いつく。
facebookはいつでも友達に会えるし、twitterは予想もしなかった知識や情報との出会いがあるし、foursquereも、ゲーム特有の依存（はまり）現象にうまくはまり、ついついやってしまう。
wondershakeはなんだろうか？
まっさきに候補に上がるのはセレンティビティ、twitterに見られるような偶発性のある体験だろう。しかしこれを一定の質と頻度で発生させるのは非常に難しい課題だ。まだこの土俵で価値をだすなら、「tumblr, twitterではないよねー」がほしいところ。
「とりあえずshakeしとけば、けっこう面白い人と会えるよ」
っという文脈がユーザーに根付く、というのが今のところ一番想像しやすい。この点に関してどんなことが聞けるようになっているのかまず興味がある。
■なぜユーザーはwondershakeをついつい紹介してしまうのか？
wondershakeはテイストであってソーシャルグラフの構築を目的としたサービスではないと解釈しているが、口コミによる広がりはマストな課題だろう。ファウンダーのカリスマ性、コンセプトのユニークさなどすでに平均以上にクチコミの理由はあるが、目標をさらに上にして、あえて批判的な視点から考えを始めてみる。
多くの人が感じるであろうクチコミの第一のネックはなんだろうか。簡単にいえばwondershakeは「出会い系」なのだが、それが社会通念上良くない国もあることだろうか。でもきっとそんな点はwondershakeチームもとうの昔にクリアした問題であろうから置いておこう。
そこで、僕個人の最近の学びと見解としてはだが、シンプルで口から出やすいクチコミ文がどれだけ浸透するかだと思う。いわゆるアクションに落ちるようなニーズに明確に刺さるキャッチフレーズを明確にしてあげて、ユーザー自らがこのサービスを広めやすくする。wondershakeの紹介はコンセプトも新しいだけに超簡単、とはいえない。ミーハーの僕としてはぜひとも紹介したいのだが、tech系の情報がまったくなくiphoneは持ってるけどtwitterくらいしかアプリはやらないよーという普通の大学生に対して、シンプルで分かりやすい言葉がまだ思い浮かんでいない。一点目の心理的なハードルに加え、この「howの部分」がいつのまにかユーザーに浸透しているか、まだ楽しいけど友達には説明しにくいアプリかで、ユーザー数のはね方はだいぶ変わってくると勝手に予想している。
陳腐なjust ideaとしては4つくらいある。
1:ユースケースを誰でもわかるレベルで明確にして伝えるのがひとつ。 （たとえば「カフェで暇なときに押してみると面白いよ！」「合コンで最初にやるとけっこう盛り上がるしそのあとの雰囲気もいい！」など。）
2:ユーザー価値の似たものに例えて、伝えやすくしてみる。
3:コンセプトからはずれてしまうと思うが友人間で使うイメージを設定するベタなクチコミ。(「wondershake使ってよー授業中けっこうみな使ってるよー」から「ここのこのタグ、よく可愛い子いるよ」→「マジ？タグって？wondershakeをDLしてshakeってやるだけ？わかった！」など）
4:mustではないが、サービスにまつわるつい話したくなるストーリーがあること。一番ハードルがあるがappleやtwitterはこの力も大きい。ぜひとってもwonderなユーザーストーリーが出てくるといいなと思う。
今回の地域を限定したオープンはうまーく焦らしがきいて、twitter上では非常に話題になっていてさすがだなぁという印象でした。
いったいどんなwonderな方法でこの課題をwondershakeチームはクリアして見せてくれるのだろうか？
■「color？yobongo?beluga?いやいやwondershakeがやっぱcoolでしょ。」の理由は？これは英語圏での話で、きっとこの一年でみえてくる部分なんだろうなと思う点。
正直自分は全然まだ答えが出ていない。しっかりとwondershakeもやりこめていないし、日本以外の英語圏のマーケットやユーザー心理が残念ながら理解しきれていないからこれといった見解がもててないからきになるというのもある。
狙う本質的なユーザーニーズ？は、他のサービスと似たところにある程度は収束するのかなとも思う。一般の人からみたら特に最初はデザイン以上の違いは感じにくいのかなと今は感じる感じる.
しかし、2,3年後、数十万人レベルに成長できたと仮定すると、やはりこの問いの答えはきっと見えているころだろう。そこで聞いてみたい質問だ。単純なユーザー体験での差というより、いかにムーブメントを先に起こして広めて先駆者になり、そして「サービスは似てるけどみんなつかっているから私も使ってる〜」、というストーリーに乗って100万人レベルへ成長していく、というスピードの勝負のようにも感じる。
どのターゲット層を狙うんだろう、マネタイズの方向性は？世界展開など、まだまだ話題はつきないがこれくらいに。
こう見ると一件難しそうな雰囲気もあるが、最初の前提で書いたようにまだ誰にもわからないフェーズだ。しかし誰もがいつも以上にワクワクしてwondershakeを見ているのはすでに普通でない何かがある。
しかもwondershakeには、coolなデザイン、独自のテイストマッチングの考え方、すばらしいチーム、そして人を自然と巻き込むfunderがいる。あとかわいすぎるイルカくん（名前はないんだろうか。。。）。ぜひとも僕の陳腐な妄想をはるかに超える活躍をしてほしい。
上の予言が実現すると僕は願っているが、本当になったら当てた景品としてmacに貼るwondershakeのシールほしいな、、、なんて。
時間を取るときは、localtime（）を使っていたけど、Time::localtimeを使ったほうが良さそう。
localtime()だと
my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime();
もしくは
my ($mday, $mon, $year) = (localtime)[3..5];
といつもやっていたが、Time::localtimeならオブジェクトとして値をとって扱える。
#! /usr/bin/perl use strict; use warnings; use Time::localtime; my $tm = localtime; my ( $day, $month, $year ) = ( $tm->mday, $tm->mon, $tm->year ); printf ("the current date is %04d-%02d-%02d\n", $year+1900, ($tm->mon)+1, $tm->mday); #the current date is 2011-07-10
そう大差はないのかもしれないが、よく使う処理と考えると要素番号をいちいち調べる必要もなくなるし、localtimeの複数の要素を使うほど便利そうです。
Devel::NYTProfのインストールから結果表示までmemo
先日勉強会で id:gfx 先生からプロファイラ（性能解析ツール）の紹介があったので忘れないようにメモしておく。
ちなみにプロファイラってなんじゃ？状態だったので調べると
動作中のプログラムがどの処理をどういった順序で実行したかを監視するプログラム。コンパイラやデバッガなどと共に、プログラミング言語の開発環境の一部として提供されることが多い。
例えば、プログラムはまずAという関数を呼び出し、次いでBの計算を実行し…というように、逐一記録が残される。それぞれの処理にかかった時間などを監視できるものもある。
ユーザはこうした記録を分析することで、プログラムが自分の意図通りに動作しているか、またプログラムのどの部分がボトルネックとなって処理に時間がかかっているのか、などを知ることができる。
プログラムの障害を見つけるために用いられるよりも、プログラムの余計な部分を削るなどして高速化するために用いられることが多い。
といった感じで、いろいろ幸せになれるとのこと。
devel::NYTProfのインストールをインストールからですが、
cpanm Devel::NYTProf
のはず。ちょっと前にやったので記憶が確かではないですが。
で、さっそくチェックしたいスクリプトを引数に置いて実行。
perl -d:NYTProf index.cgi
そうすると,nytprof.outというファイルができる。そしたら
nytprofhtml
とすると、mytprofというディレクトリができて、その中に結果が表示されるindex.htmlが作成されました。今回はファイル名をmytprofhtmlのあとに指定してませんが、プロセスごとに結果を出したりするとレポート(nytprof〜ファイルのこと）がでるのでその場合は指定してあげればおｋらしい。
で、今回はおまけでわざわざwebサーバーのディレクトリに持っていくのがめんどいので,Plack::App::Directoryを使うとのことでした。
cpanm Plack::App::Directory
してインストールしたら、今のnytprofとかがあるディレクトリでいいので
plackup -MPlack::App::Directory -e 'Plack::App::Directory->new({root => "."})->to_app'すると、なんかwebサーバーっぽい挙動があらわれて、書いてあるがままに
http://（ローカルホスト）:5000/nytprof/index.html
とすると、プロファイラのレポートがHTMLで見れた！
そのあとの詳しい見方とか、plackの詳しい動きやらは理解しきれていませんが、ここまでメモということで。
実際のレポート画面や、その後の見方なども学んだ際には追記予定。毎度貴重な勉強の機会をつくってくれる先輩プログラマーの同期に日々感謝
３つの関数定義の仕方とスコープにかんしてmemo
今週の学習メモ。JavaScriptの基礎をひと通りおさらいしたら多々しらないことが出てきて勉強になった。
とくにJSでは自由度が高いため関数が様々な形で使われるためどうもしっくりきていなかった。今回関数の呼び出し方にもだいぶ曖昧だったところの知識が整理され、よりコードを呼んでいるときに意味がとれるようになってきた。
方法としては
・function命令で定義
function hoge(){}
・functionコンストラクタを使う
var hoge = new function (hoo,huga,'return 1 + 1;');
・関数リテラルで定義
var hoge = function(){}
の三つがある。
functionオブジェクトを使う２つめのコンストラクタでの定義はあまり目立ったメリットがなく通常使わないこと、function~は直接だが、関数リテラルは無形関数を変数に定義しているという違いがある模様。
またfunction hoge(){} は静的な定義であって、コードが解析/コンパイルのタイミングで関数登録されている。
funtion ~ で定義。
■JavaScriptでの独特なスコープ
Javascriptではローカルのスコープの意味がperlとは違う。具体的には
・ローカル変数とは関数内で定義された変数。その場合その関数の内部をスコープとする。
・スコープ内であれば位置に関係なく変数が呼ばれる。なので先頭に書いてわかりやすくする。
・ブロックレベルのスコープがない。if分の{}内はスコープにならない。関数のブロックだけがローカルになる。
トリッキーな方法としてwithをつかった擬似的なブロックスコープは生成できるようだがあんまり使うものではないみたい。
