  |
はてなキーワード: インターフェイスとは
その完成度は、やはり先駆者であるMicrosoft、Windows Phoneにはかなわない印象。
途中からUIデザイン方針を変更した他者とは違って、初めからメトロデザインという方針を打ち出し、しっかり整備した上で発表された。サードパーティー製アプリであっても、そのデザインランゲージに則って作られており統一感が違う。UXにおいて、デザインの優劣だけでなく、それが統一されているかどうかは極めて重要。
よくある批判として、フラットデザインはどこがクリッカブルなのか分からないというのがあるが、実際にWindows Phoneを使ってみるとそういったストレスは皆無。
あらためて画面を眺めると、確かにどこが押せるかを判別するのは不可能なように思える。にも関わらずUXに問題を感じないのは、押せるか押せないかが分からないのは問題ではないからだろう。クリッカブルなテキストを使用するのはナビゲーション部分なので、ミスオペレーションは戻るボタンを押すだけで復帰できる。たとえ押して何も起きなくとも、思いのほかストレスは少ないように感じる。
ちなみに押すと何らかのアクションが発生するリンクについては、○で囲まれたピクトグラムを使用する決まりになっている。
加えてこれもUIの統一性の成果だろうか。不思議なことにある程度習熟したユーザーにはなんとなく押せるか押せないかの予測が効く。Officeのリボンインターフェイスの時のように、Microsoftはユーザーエクスペリエンスに関して相当な統計的解析を行ったのだろう。その辺の蓄積も効いているのかもしれない。
そういえば小飼ナントカさんがIS12T発売当時に同様の批判をしていたが、どれもユーザーにとっては的外れなものであった。批判を受けた部分は全て共通UI部分なので、ある程度触ったことのあるユーザーであれば全く誤解なく操作できる。
他2社のフラットデザインはスキューモーフィズムとの折半といった印象であるが、Windows Phoneは非常にラディカルに自らのデザインを推し進めている。真のアーリーアダプターは銀座アップルストアに並んでいないで、ヨドバシでIS12Tを買うべきだった。
mixiに限らず徒然なるままに。
思いついたまま書いてます。見返してません。
だいたい10年前
アルバイトをしていて店長からmixiしてる？と聞かれたのがmixiを知ったきっかけ。
そこはかとなく興味を惹かれつつも、頼み込んでまで利用したいと思っていなかったし実際に使わなかった。
友だちの間では、携帯サイト制作が流行っていて、バンドの紹介サイトや個人サイトが乱立し、みんな思い出を日記やアルバムでアップしまくっていた。
更新のモチベーションは「俺らの青春天晴れ」という、周囲へのリア充アピール。
友だち(当時は"仲間"って感じだったけど）とのコミュニティを楽しむのと
女子と交流するきっかけを掴みたいという淡い期待が8対2くらい。
mixiは、登録をしたものの携帯サイトのほうがデザインを自由に変えれる点を面白く感じていて、気まぐれで更新する程度だった。
学校は、電車で30分くらいかかる県内で一番大きな駅が最寄りで
登下校を毎日おこなう内に、他校学生が見知った顔になり少しづづ繋がりができる。
そういう友だちは、メアドを教えるよりも早く向こうからマイミク申請が来たりする。
今でいうLINEでいきなり連絡がくる感じ。
mixiは、マイミク数が露出されていて「自分はリア充だ！」というのをPRするために数増やしのために活動する人たちがいる。
■友だちの友だちの知らない女子
友人のページから女子が経由してページに来てくれるので、次第にmixiでの更新回数が増えていく。
そんな感じで、携帯サイトで培っていたコミュニティが集落ごとmixiに引っ越し始めた時期があった。
友人のページから女子は、足あとで確認するし日記をチェックしてくれるのは知っているけど互いに話しかけない残像のような存在だったりする。
仲の良い友だちとは、面白い写真や日記をアップし、互いにコメントをしあう猿の毛づくろい的な関係が続く。
1日のメールが200通、300通になり送信制限に引っかかるなど携帯が主人格のような時期はこの辺りがピーク。
■メル友
話はずれるんだけど、高校時代にはメル友交流が盛んで、他校の女子とメールしては会ってメールしては会ってをひたすら繰り返していた。
みんなwebで表立ってそういうことは書かないから、気づいたら他校の彼女がいるとかザラにある。
2人のホームページをシコシコつくって
(耳すまの最後で「こいつら絶対すぐ別れる」 と直感する感じ。）
こういうのは電車通学で様々な地方の学生が一箇所に集う環境ならでの感じもするけど、どうなんだろう。
■mixiを触らなくなる
「地元でのテンションが伝わらない」というカルチャーショックに打ちのめされる。
新しく作られたコミュニティ向けに文章を書くのがあまり楽しくなく感じる。
でも、それ自体はコミュニティの成長のためには関係ないものだった。
それで少しづつ
「日記書くのがバカらしい」という気持ちと
「ネットでわざわざコミュニケーションとらなくてもいーじゃん！」という気持ちが
相まってmixiに触らなくなっていった。
■蛇足
mixiのコミュニティで、「○○年度入学生集まれ〜〜＊」というコミュニティがあった。
「入学式DOKIDOKIです！」「みなさんはバイトしますか〜〜☆」みたいな、
エネルギッシュな文章を予想外な人が書いていたりして卒業後に眺めるとめちゃくちゃ面白い。
-----------------------------------------------------------------
適当に。
・mixiが流行った背景は自分の感覚で上みたいな感じで、mixiの衰退には
機能が使いにくくなったとかTwitterの影響とか関係なく、コミュニティの開放と一緒に自分もmixiから開放された感じ。
・mixiは「マイミク」という単語を使わなくなった? 女子受けするデザインはmixiの流行に欠かせないものでワードセンテンスも大事だと思う。
・facebookが日本で流行らないと言われていたときに、「テーマ」を導入すれば流行るんじゃねって思ってた。SNSは頻繁に使うものだからオッサン臭いインターフェイスは嫌なんじゃないかな。
勉強会を探したり趣味友が欲しいときにmixiのコミュニティ機能は最適だと思います。
管理されないコミュニティは、ノイズが増えすぎて利用者は減る。
コミュニティの管理人にインセンティブを与える仕組みを作れないのかな。
金を絡ませるとまとめサイトみたいのが増えんのかな。
うざいかもな。
アンサイクロペディアとか攻略wikiとかさ。
・友人間コミュニティのためのSNSというポジションは諦めていただいて
コミュニティ機能を使用させるのに特化させればいけるんじゃないでしょうか。
発信したい人は発信するし、勝手に繋がるので友だち機能は消さないでいいと思うけど。
どうでもいい。でも儲かっているようなので存続のために続けてください。
-----------------------------------------------------------------
質問が2つ
・mixiの流行った時期、ビジネスマンはどんな使い方をしていた?
ビジネスマンはどういう使い方をしていたんだろう。
出会い系?
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
○朝食
なし。申請書を書いたりで忙しく食べられなかった。
先月書いた文字と今月書いた文字を見比べると、自分が回復したことがよくわかる。
○病院
新しい薬が本当によく効くことを伝えた。
こうして日記を書くことは認知療法としても良いことらしい、これからも続けていこうと思う。
今一番楽しい時間がブルードラゴンのビルドを考えているときです！
こんな感じかなあ。個人的には前衛を減らしたいので、マルマロを魔法職に変更するかも。（今更感あるけど）
ただ、さすがにレベルを上げすぎたようなので、そろそろちゃっちゃっと進めようかなあ。
午後から集中してやる予定。
「チャプター１３蜂起」をクリア。
残り二章。
コルタナの自己犠牲心と、それが機械だからとわかった上で、正しいと判断した上で否定しようとするもできないマスターチーフが
今日はもう本当駄目駄目だった、先手をとったタイマンにも関わらずシールドを割ることすらできなかった。
三戦ぐらいして素直に辞めた。
○ハッピーウォーズ
魔法使い熱とは何だったのか？ ログインボーナスとトレジャーだけやって終わり。
○カタン
アイドルマスターのニコニコ動画の卓ゲー動画を見て興味をもって購入。
まだまだ初心者なので手探りで二ゲームほどやったけど、両方勝てた。
特に二回目は羊港を作り、羊の産地をほぼすべて抑えて、羊ゲーとなって勝利して気持ちよかった、亜美みたい（え？）
交渉のインターフェイスがわかりにくいのが難点だった。
○昼食
うどんを作る。今はお湯をわかしている。
午前中に対人戦で負けたのが悔しかったので、キャンペーンをプレイ。
コルタナの「女の子に約束しちゃだめ、できない約束はね」という台詞で一気に世界に引き込まれた。
コルタナーーーーーーーーーーーーー！（涙）
マスターチーフの兵士としてのかっこうよさ、コルタナのAIとしてのかっこうよさ、すべてが詰まった名シーンだなあ。
「チャプター１５大いなる旅」
たしかに、アービターの投獄から始まったHalo2を閉めるのはタルタロスとの対決だよなあ。（一騎打ちじゃないのが少し残念）
そして名誤訳「けりをつけてきました」を聞き、感動のスタッフロール。
また、エンディングが良い曲なんだこれ。
序盤と中盤はマスターチーフの出番が少なめかなあ、と思ってたけど、チャプター１４のコルタナとの別れでもうチーフオタクとしては大満足です。
フィギュアとか欲しいなあ。
やってるときは文句たらたらでしたが、ストーリーやエリートを操作できるところなど良い所もたくさんありました。
いやあ、やっぱりヘイロー大好きだ！
まったく盛り上がっていないようですが調べたのでまとめておきます。
（現在は削除済み）
@sally_ism
『羽生結弦くんは碇シンジ君のプラグスーツ着て残酷な天使のテーゼで踊ったら世界が涙するから絶対やったほうがいい』っていうツイートに激しく同意したのでとりあえず画像つくりました。渚カヲルくんの画像しかなかったごめん。でも、あの、やばい…！
緒方恵美 @3/8・9_Live！
@Megumi_Ogata
Σ(゜ロ゜;)違和感ﾅｻｽｷﾞ RT @sally_ism 『羽生結弦くんは碇シンジ君のプラグスーツ着て残酷な天使のテーゼで踊ったら世界が涙するから絶対やったほうがいい』っていうツイートに激しく同意したのでとりあえず画像つくりました。 http://twitter.com/sally_ism/status/431821531224621057/photo/1pic.twitter.com/QQyj0ESa9S
まとめにも着火。
【中の人も納得】フィギュアスケート選手・羽生結弦さんが碇シンジに似てると話題にｗｗｗｗｗｗｗ : はちま起稿
【画像】羽生結弦くん、碇シンジに似てると話題 中の人も絶賛しててワロタｗｗｗｗｗｗｗｗ
男子フィギュアの羽生くんがエヴァンゲリヲンのプラグスーツが似合いすぎると話題 | 男子ハック
@sally_ism
さっきの羽生結弦×プラグスーツ画像、なんか足らないなーとおもったら、インターフェイスヘッドセットつけるの忘れてた！くやしい！でも無くてもかわいいのでよし！ https://pic.twitter.com/QYOFG7uBSu
posted at 03:46:09
（↑削除済み）
@sally_ism
さっき自分で羽生くんプラグスーツコラ画像つくったけど、地味に蒼穹のファフナーのシナジェティックスーツも着てほしい。露出高くて申し訳ないけどあれかっこいいから好き。
@sally_ism
森ミャン丸
@morino_kage
@sally_ism @pinkjyoudai RTよりしつれいします
元画像の方の加工許可は取ったのでしょうか？ご本人の呟きを見るとそうではないらしいですが…
顔を挿げ替えても本人や周囲の方々には分かりますよ？
確認の為教えて下さい
元画像がこちら
est
@est_ll
@sally_ism
わーすいません思った以上に広まっててご迷惑をおかけしてしまいました！該当のツイートは消しました。海外サイトでの拾い画だったので出典がわからなかったんですが、元画像の方は日本の方だったんですね。ごめんなさい。今日はバイトなので、後日改めて対応いたします。
最初↑のツイートだけ見て、おっ無断転載案件か？「ワシがつくった」連呼しといて？（ｹﾞｽ顔）と思って調べ始めたら予想外の展開。
加工済みの画像が「拾い画」なんじゃなくて、首をすげかえた元のコスプレ画像が「拾い画」だったと。
レイヤー本人（est氏）ではなく森ミャン丸という第三者？が激おこで、さりーちゃんにぶっこんだ結果→削除という流れだった模様。
まあ突っ込もうと思えば、首から上の羽生選手の写真だってどこから持ってきたの？カメラマンの許可は取ってるの？と言えるわけで…
ソーシャルにネットワークされちまっている昨今、どんなところから弾が飛んでくるかわからないもんですね。
こちらからは以上です。
est
@est_ll
わかりやすさについてとやかく言わないけどさ、攻撃するってことは、モンスターのHPだとかが減るんだよね？
勇者.attack(モンスター)
って書いたとしてもさ、勇者.attackメソッドの中で、モンスターのHPを直接書き換えるわけじゃないでしょ？
直接書き換えてたら、モンスターに守備力だとか、耐性追加した時に、勇者側を書き換えないといけなくなる。
守備力だとか、耐性だとかは、モンスターの属性なので、影響はモンスター側で面倒見てもらいたいから、
攻撃でHPを減らすのは、モンスターのメソッド経由になると思う。
結局、
class 勇者 : method attack(モンスター: monster): monster.attackedBy(self.attackPower)
みたいなコードになると思うんだけど。
例えば、攻撃力取得メソッド。
interface 攻撃方法: /** 攻撃力取得 */ method getAttackPower();
フィールドは、攻撃方法によって違うかもしれないが、攻撃者を持っとけば汎用的かな。
/** 通常攻撃は力=攻撃力 */ class 通常攻撃 implements 攻撃方法: field _attacker constructor(攻撃者: attacker): self._attacker = attacker method getAttackPower(): return self._attacker.strength
/** 突撃は力*すばやさ=攻撃力 */ class 突撃 implements 攻撃方法: field _attacker constructor(攻撃者: attacker): self._attacker = attacker method getAttackPower(): return self._attacker.strength * self._attacker.agility
そうすると、攻撃方法が違っても、モンスターのattackedByメソッドの処理は共通
class モンスター: method attackedBy(攻撃方法: attackMethod): self._hp = self._hp - attackMethod.getAttackPower()
monster.attackedBy(new 通常攻撃(player)); monster.attackedBy(new 突撃(player));
例えばスーファミのFFみたいな、古典的なRPGの戦闘シーンを作っていて、「勇者がモンスターを攻撃する」。
勇者.attack(モンスター);
という設計だったとする。
これに「モンスターが毒を受けて、自死する」という挙動を追加するケースを考える。
毒.attack(モンスター);
やや複雑な変更になりそうだが、勇者の攻撃とのタイミングの差で、
のようになるとしよう。
まず、インターフェイス"攻撃者"をつくって、「勇者」、「毒」をその実装とする。加えて...
斬撃後に死んでいた場合(*) 、納刀する
攻撃前に既に死んでいた場合、攻撃できないようにする
この設計変更によって、
が、
の４パターンに増えた(※ただし最後のパターンに関しては今回特に修正の必要はなかった)
攻撃者がひとつ増えるごとに、これらの分岐は倍、倍に増えていく怖れがある。
あらたに攻撃者を追加すると、既存の攻撃者を変更しなければならない。
この変更によって、全体の時間的な流れがよくわからなくなった。
等々の分岐が並ぶことになる。この分かりにくさは単にStateパターンを導入しただけでは本質的には改善しないだろう。
MVCにおけるモデル、は振る舞いを持ったデータだ。モデルが状態変化したとき、イベントが発生する。
しかしその状態変化が別のモデルの状態変化のタイミングに影響をうけるとき、モデルの設計はとても複雑になり、読みにくくなってしまう。
モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。
このような複雑さをプログラマが支配するのは、とても大変だ。
みなさんも体験したことがないだろうか、GUIで「ホニャララしているときにホゲホゲするとバグる」みたいな挙動を。
すると、上部に表示される「更新時刻」の表示位置がおかしくなる。
RPGの設計は、たとえば下記のように記述できるDSLを導入すると、劇的に改善する。
タイミング：毒 ⇒ 死ぬ ⇒ 斬撃 の順なら、納刀する タイミング：毒 ⇒ 斬撃 ⇒ 死ぬ の順なら、変色した血が飛び散る
オブジェクト指向ではこれはStateパターンとStrategyパターンを組み合わせることで実現できる。
でも、このような設計にすると、勇者やモンスターのモデルオブジェクトの責任は極端に少なくなってしまう。
加えてオブジェクト間のやりとりの複雑さがDSLに押し込められるので、オブジェクトの主体性も殆ど無くなってしまい、
うん、ただのデータでいいや。
---------------------------
(*) 攻撃時に相手の状態を問い合わせるのが醜い。これを避けるには、モンスターが毒で死んだ時に勇者にイベントを通知して、勇者を”戦意喪失”状態に変化させる手がある。
アイデア一緒＝セーフ
コード流用＝アウト？
http://d.hatena.ne.jp/gorokuma/20130804/1375643345
悪質デベロッパーによる「アイコンメモ」の丸パクリ、「アイコン付箋紙」
Appleに直訴してもメール中継してくれるだけでなんにもしてくれないそうです。これは悪質。
パクられ元は「Tinder」
http://www.ikedahayato.com/index.php/archives/21521
公開は春だそうですが、ここまでインターフェイスが同一でも独自性をアピールして良いものなんでしょうか？日本人離れした印象。
以下開発者の方の主張
https://www.facebook.com/ko.miyagawa.roadofhope/posts/10203040745246465
---------------
なんでわざわざ出会い系やるのってあたり、今年の抱負がてら話させて下さい。
出会い系。
婚活／恋活という言葉が出てきて、出会いのためには何らかのアクションが必要だと認知された現代ですが、残念ながら、出会い系という言葉には未だ、胡散臭いイメージが付きまとっているようです。また、過去１５年ほどは、胡散臭さに見合う実態もありました。
ですが、実は、それら出会い系サービスが抱えていた問題、ソーシャルが前提となった今の時代には、ほぼ完全に解決することが出来るようになっています。
詳しく説明します。
従来は、素性が分からない相手と会う必要がありましたから、ウェブ上でメッセージのやり取りを1カ月程度続けて、女性側が信頼できそうだなと思ったら、会ってみましょうかという流れでした。
それが、変わりました。
素性を明かせる人間のみとやり取りが出来るようになりました。ウェブベースだと誰が使ってるかわからないのでそれが無理なのですが、facebook認証や、アプリの認証を活用することで、未成年は排除できますし、経歴詐称はほぼ防げるようになりました。
にもかかわらず、既存のサービスのユーザー体験はというと、従来型の素性が分からない相手とのやり取りを前提としたものから変わっておらず、ウェブ上で相手との相性を見極めるという非常に難しい作業を強いる仕組みになってしまっているのが出会い系領域の現状です。
ウェブ上のみで理想の相手を見つけたり、相性を見極めるって面倒だし、不可能に近い。
となると、出会い欲求が異常に強い人、リアルで良い出会いにめぐり合うのが難しい人しか使いません。面倒くさいですから。 そんなサービス、クソですよね。
実は、出会い系は真面目に・・・という方向性ではなく、カジュアルな方向性に進化していく必要があるのではないかと思っています。アメリカでは2500万人程度がオンラインデーティングサービスを利用していますが、日本だとコアユーザーは100～200万人程度。そうじゃなく、一般に使われるサービスになっていかないといけない。アプリ使った出会いと、偶然をベースとした出会い、変わらないじゃない・・・となっていかないといけないと思っています。じゃないと、リアルで偶然会うよりリスク高いはずですよ、今の現状だと。
そんなことを考えながら・・・
世の中、良く観察してみると、街コンとかって、その場で知り合った初対面の人と30分程度しゃべるじゃないですか。そこで、会話を楽しみながら、相手を知る。前提共有なしで、いきなりしゃべっても結構、コミュニケーションって成立するみたいなんですよね。
となると、従来型のウェブ上での面倒くさいやり取りって何なんだ、男性からメッセージ送信あたりで課金し、女性にメッセージが届きまくるあの仕組みって何なんだ、あんなんじゃ、出会い欲求が異常に強い男しか利用しないじゃないか。となりまして。
そう、相手が素性のわかる相手であれば、まず会ってみたらいいじゃないっていう設計思想へと至った。やり方次第では、カジュアルな出会いを、安心／安全に演出できるだろうと。それがこの、「恋カフェ２０」です。
プロフィール入力すら必要ないくらい、これ以上ないというくらい、極限までプロセスを削り、儲けを求めることなく、素敵な出会いをたくさん生みだすことを目的に、作り込みました。
出会い系のイメージを変え、世の中をもっと楽しい場に変えることができるか。
ps マーケティングはもっと柔らかい感じでやりますｗ が、理念とか信念とかを大切にして日々を生きたいお年頃なので、説明しておきたいのでした。
この日記見つかるだろうか。
富山県のとある”にいかわ若者サポートステーション”（以下サポステ）のサイトがお察しなのが改善されないから適当に書く。特に次の４点は重症と考える。
１．厚生労働省認可事業であるのに、厚生労働省の当該ページへのリンクがない
自らのサイトより信頼性の高いサイトからリンクされているのであるなら、それを利用して自らのサイトの信用性を上げるのは重要と考える。EV-SSLなど第三者認証を利用できないのであれば、コストのかからない方法により信頼性を高めるのが重要である。以下に厚生労働省の当該ページの１例を示す。
http://www.mhlw.go.jp/bunya/nouryoku/ys-station/
使われる技術（WordPress）が優秀でもインターフェイス設計（サイトデザイン）が伴わないと使う意味は薄いと考える。
デザインの流行は常に移り変わるため常に研究が欠かせない。容易に研究できコストのかからない方法として、大手企業のサイトは参考になる。
プライバシーポリシーや利用規約など運営の基本となるページのアドレスが、デフォルト設定のまま２バイト文字列がエンコードされたアドレスで作成されている。
個人情報管理が最重要であるにもかかわらず、これら重要情報が明記されたページがこれでは信用性が下がると考える。検索エンジンや各種通知方法により直接リンクを貼り付けるさいにも支障をきたすため、英数字による固有アドレスへの変更が重要である。
Googleストリートビューのほうが遥かに分かりやすい、と書きたいがストリートビュー未対応エリアであった。
アクセス情報で重要なのは、近隣の重要な点となる「主要道路の交差点」や「最寄り駅・バス停」からの道のりであると考える。映像開始がすでにビルの前から始まるので、ここまで来れる人であれば動画を見なくても辿り着ける。また、基本的に画面がズームのままで見にくく、周囲の情報が見えないので案内になっていない。
そのほか、
・「キカクル」ってなに、説明が何もない。
スケジュールやお知らせに見かける「キカクル」の説明がない。
・職員紹介の動画でシーン切り替えが雑。
フェードイン・アウトがなく唐突に黒画面になる。黒画面に意味があるのか分からない。
無断使用を禁じるのであればPDF変換し文書セキュリティをかければよい。閲覧者としてもPPTよりもPDFのほうが閲覧環境が普及していると考える。
・PDFのみは基本手抜きに思える
IR情報など情報の改変・表示のずれが重要な問題となるならば分かるのだが、そうでないならば閲覧者としては普通のページとして構築して欲しい。PDFは改変されにくく作成者の意図通りに表示できるのが利点であるが、これらは作成者の都合である。
・終了したプログラムと継続してるプログラムが区別無くリストされてる
すでに終了した「集中訓練プログラム」と、現在も継続されている「スポーツプログラム」が同一のカテゴリに表示され区別されていない。
この日記自体個人的なことを書いているが、それでもなお個人的であるがページトップにある電話のアイコン画像がうさんくさいサイトに仕立て上げてるように見える。
などと書いてきてはいるが、日本社会としてはこの程度のサイトが一般的なのだろうか？
こんな二次嫁が実現して欲しい
同僚の方はロードバランサタイプではなく、処理を分散するタイプか
思っているんじゃないでしょうか？
ngnixやsquidとかを組んで、代理で応答してくれるサーバを
複数用意するような考え方の負荷分散構成で元サーバのファイルを
画像だけでも数万点で何十GBもあるような場合は手入れが簡単で結構効きます。
特別手当が必要な外向け高負荷webサイトの場合は、知識の範囲と、調整にかかる
そこまでやるのは100件に1件くらいで、やり方も多岐にわたります。
実績も豊富で、推奨設定などが明確なためロードバランサを用いた方が
スタートアップが早くなります。同時接続数250くらいがしきい値です。
ロードバランサのキャパシティ(主にネットワーク帯域がボトルネック)を
超えてしまう場合も多く、処理系や画像データなどの分散配置もしなければ
ならない事もあります。
そうかと思えば、ハイスペック機の２重化で十分な現場も多いですし、
分業していて畑違いでやってきたのかもしれません。
通常インフラ屋さんが集中的に取り組むのでプログラマ系の人は知らなくても問題ないかと。
むしろ知らないならその方が都合がいいことも。専門的な実績が蓄積されている中、下手に
動かれると壊れたりします。失敗すると全面的に影響してしまうリスクの大きな部分なので、
最近はAWSなどのサービスも充実してきていますし、ちょうど手分けが出来る分岐点でもあるので
コードを書いて動くものを作る系の人にまで求めない方がいい知識かも知れません。
アップデートサイクルが短く覚えた頃には陳腐化してしまうこともしばしば
負荷分散のパターンは流行り廃りが激しく最新事情は随時調べ直しが必要です。
飲みにいくような仲ならば、不満を抱えるよりも、ここの場合は、
こうやって負荷分散してるなど擦り合わせしておくといいかもしれませんね。
そこまでカバーできる人になってほしければ、調査を依頼する形で知識を得てもらう
と言う手もあります。
知っててもいいけれど手は出せない事も多いです。西海岸までの光ケーブルの接続が
どうなっているかまで知らなくてもできる仕事はたくさんあります。
ためになるってこともありますし、自分と同等であればわざわざ群れる必要も無いという
意見もあります。個人的にはヒアリングしてコードを書く人の場合、サーバ周りは
分からなくてもいいと思っています。#それが得意な人が結構見つかるし手分けが出来る
50人いるクラスだったら50人とも活かせるやり方を模索するのも悪くないアプローチかと思います。
これはあの人が得意だから深く突っ込まなくていいよなどの力加減とか
餅は餅屋に任せて踏みとどまろうみたいな感覚も意識した方が不要な処理をスキップできます。
似たような話だと、ビデオを快適にハンドリングしようとした場合のネットワーク構成があります。
出来る人がいるけど、みんな知っていなければいけない話ではない 手分けして取り組めばインターフェイスは
ここにファイルをアップロードすればうまくいく というところまで簡略化できる など
５人くらいで専門的に取り組めば、残りの45人は特に知識を習得する事なく、別の事に取り組み
一段上を目指せるようなケースです。みんな同等の技術やスキルが必要かというと、そうでもない
ブログの仕組みがあるから記事に専念できるというのも、言われていないけれど、
分業、協力関係みたいなものです。ブログシステム（箱）を作った人と作文した人(本)のコラボですね。
みんなで箱を作るより、5人で箱を作って残り45人で記事を書いた方がいい結果が出そうです。
分業するのも簡単で、箱作るから記事書いてというだけで済みます。
個人の能力にとやかく不満を持つのは結構疲れてしまうので、集団のうち誰も分からないというのは
避けようと中間目標を持っておくと気が楽になるかもしれません。得意な人を見つけておくなど
一部スーパースターがいますが、契約に比べると個人の能力差はそんなに影響しないような気もします。。。
賛否両論あるかと思いますが、人は一定数いて減らないものだから、うまくやろうくらいに思っていた方が気が楽ですよ。
気を病むようならば、組織から査定しろと言われていない限りは人の能力の評価はしない方がいいかもしれません。
やりたいし、できそうだけど、契約上できない事（予算が足りなかったり）やらなくてよいこと
あとほとんどのシステムは、変数がなんだか分からない人をモデルとしてチューニングされていきます。
システムものを使用するユーザにはそういう人の方が多いんです。作った人の高度なテクニックや技術よりも
使いやすさを重視してきますのでその辺も視野に入れておくことをお勧めします。
最初はlanguage exchangeっていう、英会話の勉強を目的としたSNSで、アメリカ人やフィリピン人と知り合いになって
お前FBやってないのか？ なんでやってないんだ？ みたいなところから、よく分かんない外人と友達になっていった
当時のFBはインターフェイスも結構わけわからずだったけど、一時のYouTubeみたいな
なんか英語が書いてあるサイト使ってるからかっこ良くない？ 的なノリだった
ふーん つって過ごしてたけど
SNS疲れとかどうとかそんなんじゃねー
やめてから１ヶ月、、、 早くやめておきゃよかったよ
（LINEは俺にとってはSNSじゃない、あれもう電話とメールの変わりじゃね？）
んで、最近職場のOLちゃんがFBの話はじめて、「あれ、見ました？」って聞かれたから
俺「やめたわ」
OLちゃん「え？なんで？」
俺「いや、逆になんでやってんの？」
OLちゃん「...私も辞めたいーっ」
実はみんなそう思ってんでしょ
１）インターフェイスが会話っぽくて短文でもOK
-電話番号で登録？
３）画像添付が簡単
４）友人間の掲示板替り？友人の友人と出会える？（この辺は仕組みがよく分からない）
こんなところ？
要は「操作簡単」てのが一番受けてるのかな。
メンバー登録が面倒だったり送信先が簡単に登録できないのは、手もみ洗いで洗濯していたのを自動洗濯機にしたとか、その手の利便性とはまったく意味が違うと思う。
関係ないけどゲームだってとにかく画面を擦るだけの操作が流行してるしね。
面倒な操作や知識をブラックボックス化するという意味では、新手の技術革新と言えるんじゃないだろうか。
オリジナルの画像作成＆添付だって自力でなんとかすればどうにかなるもんだけど、それを簡単にしただけに留まらず複製された印刷もできないクオリティの画像にお金払わせるって、すごい商売だなぁと感心する。
なんでコミュニケーションに絵文字だとかスタンプがここまで重要視されるのかって話はかなり複雑そうなんで割愛。
UIはiOSのメッセージアプリみたいで機能的にもほぼ代替可能だけど、なぜメッセージアプリでなくLINEなのか。
異なるOS間でも利用可能とかアドレス帳とID検索で送信先特定簡単とかその辺だけではちょっと理由が弱い。
たぶん、メッセージアプリは微妙なところで致命的にユーザーフレンドリーでないのがダメなんだと思う。
SNSとiCloud送信の何が違うのかとか、iCloud登録の手順が微妙に面倒とか。もしかして、そうゆう面倒さのせいで「iPhoneのメッセージアプリで違うキャリアにスタンプ送ると有料だよ」なんて思われてるのかもしれない。
ネタ画像を自分で探して保存・添付するのも面倒だろうし、セリフ付きの画像用意するなんてなるととてつもなくハードル上がるに違いない。
ぱっと見シンプルでなんか簡単そうだなーと思わせといて、肝心なところで知識がないと使えないってのは、海外のWebサービスでままあることのような気がする。
ともかく「小難しい話は抜きにして簡単に誰でもすぐに使えること」すべからくここに行き着くのが、ソーシャル系に限らずECでさえも今の日本で流行るための必須要件なんだろう。
正直個人的には、LINEのようなWebサービスがここまで流行るようなものなのか、流行るだけでなくリリースする会社が上場しちゃったり株価にすごい値ついたりとか、そうゆう状況には甚だ疑問なんですけど、お役所さん方面も、LINE流行による未成年の風紀の乱れが〜とかSNS規制が〜云々騒ぐなら、まずはその辺、きちんと教育するようにすればいいだけじゃないんですかね。
規制したって、そうゆう需要があるならまた別のが出てくるだけでしょ。
なんで需要があるのかって言えば、端末とネット使うのに必要な教育が足りていないだけ（あとコミュニケーション方面の何か？）。
ほんとになんとかしたいと思うなら、足りない代替物（情報・知識）を供給すれば需要が衰えるんでないのかな。
それをなんで規制の方向に向ってしまうのか、LINEが流行ることより、まったくもって理解不能な今日この頃です。
あと、親がまともに使えないのに流行ってるからって理由だけで子どもにiPod touchとかスマートフォン買い与えるのはほんとやめたほうがいいと思う。
MTV81なるサイトにクリプトン・フューチャー・メディアの伊藤社長インタビューが載っていた。初音ミクの英語版が発売される直前のタイミングで掲載されたようだが、ちょっと探しても日本語訳が見当たらなかったので適当に訳してみた。URLは以下の通り。
＊＊＊＊＊引用はじめ＊＊＊＊＊
Mark Jarnes 2013年８月30日
J-ファンはおそらく今では「初音ミク」が何であるかご存知だろう――もしかしたら「違う！ 初音ミクが『誰』であるか、だ！」とすら思っているかもしれない。
CGアイドルの６回目の誕生日（彼女が最初に発売された2007年以来）を――そして「初音ミクV3英語版」の発売を――記念し、僕らは彼女のお父さんと会った。伊藤博之、クリプトン・フューチャー・メディア創業者――初音ミクの創造者に。
MTV81は今年のジャパン・エキスポ・パリで、ソフトウエアとしての、歌手としての、そしてミューズ［音楽の女神］としての初音ミクについて聞くため、日本で最も先端的な考えを持つ人物の１人にどうにか会うことができた。また、伊藤との会見は滅多にないため、僕らは彼に、音楽とあらゆるものの未来に関する展望についてもまさに訊ねることにした。
まず、初音ミクの６回目の誕生日おめでとうございます！ そしてもちろん「初音ミクV3英語版」の発売も。
ありがとう。ご存知の通り長くもあり短くもある難しい時間が経ったけど、ミクがデビューして以来の６年間、私たちはいくつかの試行錯誤をくぐり抜けることができ、そしてどうにか成功裏にシーンをつくりあげてきました。思うに私たちは、技術的な意味でも企業としても次の一歩を踏み出す時なのでしょう。引き続き掘り進めるけど、おそらくは違う角度で。
そしてもちろん、私たちはミクのムーブメントを拡大し築き上げていきます。より大きな言い方をするなら未来を作り続けます――コンテンツを統合する場所を人々に提供するだけでなく、明るい未来を作ります。
日本には本当の意味で伝統的文化と技術の混合物があります。ミクが日本のために、そしてこれだけ多くの技術の出発点であるその企業のために、物事をエキサイティングにしてくれることを期待しています。今から将来に目を向け、よりよい未来を作ることに集中する必要があると考えています。
壮大な展望ですね。1995年にクリプトン・フューチャー・メディアを設立した時からそう考えていましたか？ それとも事態の進行に合わせてそう思うようになったのですか？
95年の時からぼんやりとしたビジョンは持っていました。今ではそのままにしないよう、それを補完しようと試みています。今や変化を引き起こせる立場にいるため、未来を私たちの手で作るような方向に向かうことは魅力的だろうと考えています。
私たちが初音ミクを創造し世界に紹介したのはそのようなものとしてであり、以来彼女が成長し続けるよう挑戦しています。いくらかの波紋を起こすことはできたと考えていますし、今は次の一歩を考えるべき時です。
音楽制作の世界から人間の声を排除するのがあなたの意図ですか？
違います。結局のところボーカロイドは人間の声に代わるものではなく、むしろシンセサイザーです。不完全さの中に魅力があり――時に本当に機械っぽい音がすることがその声に『個性』を与えているのだと思います。完全に人間の声を真似られるのなら、それは魅力的ではないでしょう。
たくさんの初音ミク動画の製作者であり、自身アイドルファンだと公言しているわかむらPは、初音ミクは「理想的なアイドル」だと言っています。それについてどう思います？
多くの異なった価値と考え方があり、もし100万人のユーザーがいるのなら100万の異なった考え方がある筈です。
私は特定の価値にこだわりすぎないようにしています。多くの考え方こそがより豊かでより多様な創造に至ると考えています。重要なのは多様な切り口を持つことで――そこから進化が始まります。初音ミクは多様な創造、例えば音楽、動画及び他の種類の技術のハブになってきました。
音声合成技術は日本の音楽制作シーンにとても巨大な衝撃をもたらしてきました。ボーカロイドとあなたのクリプトンでの仕事は、音楽制作の世界における進化でしょうか？
そうだと思います。それは人間の声を代用する目的で始まった技術ですが、人々が印刷された文章としてすぐに同じ情報を共有することを可能にしたワープロの発明のように――ただし音楽的な意味で、重要な効果をもたらすようになると思います（微笑）。
初音ミク英語版の発売とインターフェイスの改善により、より多くの人々が使うことで、それは音楽を作るクリエーターの標準的な道具になるでしょう。それとともに、予想不能な、全くユニークなミクの使い方をした、より多くのタイプの音楽が制作されるでしょう。
次に何が起きるか私には分かりませんが、これがある種の音楽革命であると私は信じており、そしてこの革命的技術に私たちは貢献し続けたいと思っています。
どのようにして英語圏の国々に革命を持ち込もうと計画していますか？
文化は国ごとに違います。日本では「サブカル」が本当に人気が出るようになり――多くの場合それがほとんどメインストリームになっています。音楽と同様に、人気のあるジャンルも異なります。米国と欧州では、おそらくそれはEDMであり、その前にポスト＝ロックでしょう。
従ってそこが成功のカギとなるでしょう。誰が初音ミクを使い、どのような音楽を彼らが支持しているかが。
彼女は国際的に連携した活動をすべきだと聞いたことがあります。それについてコメントはありますか？
初音ミクは国ごとに異なった受け取られ方をしています。ひとたびミクが誤解されると、それがデフォルトの理解となってしまうでしょう。
不幸なことに、特に外国で彼女はしばしば誤解されています。何人かの人が動画サイトで初音ミクのコンサートに対する嫌悪感を表明しているのを見ました――ですが、数十万のアーティストとクリエーターが参加し貢献しているイベントの象徴がミクであると適切に紹介すれば、共感を得られると私は確信しています。
バーチャル・アーティストというアイデアに警戒感を持つ人がいます。だから彼らにコンサートの映像を示すだけではうまくいかないでしょう。彼女を注意深く紹介する必要があります。それが私たちの意図です――各国のアーティストと協力し関係をつくることで、各国とその文化的分野における彼女への確かな入り口を作り出すのが。
あなたが見たい他の国々での初音ミクの使われ方というのはありますか？
私たち日本人がミクについて興味を抱いた点と全世界の人々の受け止め方は全く違うでしょう。
より重要なのは私たちの望みより彼らが何を見たいと望むかだと思います。だから今のところ私は明確な考えを持っていません――そして異なる文化において何が受け入れられ支持されるか、想像することもできません。考えるのも恐ろしいほどです！
初音ミクは日本をリードする何人かの実験的なクリエーター、例えば冨田勲や渋谷慶一郎に使われてきました。これまでミクに対して「ミューズ」という言葉が使われています――あなたにとっても彼女はミューズですか？
（微笑）そうだと思っています。初音ミクは多くのインプットとアウトプットを持つコンテンツで、人々が彼女を通じていくらでも作品を創造できる基盤を生み出しています。ソフトウエアはしばしばアップデートされてきましたが、私たちは最初の段階で特定の戦略を抱いていたわけではありません。「へえ、そうなるのか、ならその場合はこうしなくちゃな」
インプットとアウトプットについては、我々技術の供給者にできるのはユーザーポリシーを発展させることだけです。なぜなら私たちは実際には自らコンテンツを創造できる立場にないからです。事態から学ぶのは本当に興奮します。増加するアウトプットを通じて何年も気づいてきたことに取り組むことで、私たちは刺激を受けてきました。
もっと未来を見てください！ そういえば「フューチャー」は御社の名前でもありましたね――初音ミクとそして全般的な未来に対するあなたのビジョンを、ぜひとも聞きたいです！
多くの人々がコンピューターを使い始めてたったの20年です。そして今ではそれらは私たちの生活に完全に組み入れられています。私たちは今や「ネット」と呼ぶ透明なクリスタルのディスプレーを通じて大量の情報を共有し、リアルタイムでニュースをアップデートしています。
そしてそれが過去たった20年に起きたことなのです。続く20年の期間を、そしてさらに50年や100年の未来を考えたとき、私たちは本当にまだスタート地点にいるだけです。コンピューターの発明から一時しか経過しておらず、そして本当の衝撃は今から数十年、あるいはおそらく数世紀を経てようやく気づかれるのでしょう。
その時には我々の身体構造も発展していると想像します。例えば私たちは今、衣服を着ています。当然のことです。しかしそれは私たちの体毛が進化あるいはある意味退化の結果として著しく減ったためなのです――私たちはもはや裸ではいられないのです。
もっと話してください！ どこでコンピューターが関わってくるようになるのでしょう？
コンピューターは人間の脳の拡張です。従ってそれは私たちの芸術的本能や、あるいはむしろ特別な判断に関わる何かを発展させるのにもっともふさわしいと思います。なぜならそれらはコンピューターができないことだからです。私たちはこれらの物事にのみ取り組み、自分たちに必要ない機能と縁を切り、残りをコンピューターに任せるべきなのです。
過去の人間の進化過程においては２つの大きな跳躍がありました。まず農業が人間の生活に劇的な変化をもたらしました。［ここで産業革命の話が入ったと見られるが、インタビューには掲載されていない］そして情報革命です――しかしそのインパクトを私たちはまだ評価しきれていません。革命が起きていること、そしてたとえ数十年あるいは数百年かかるとしてもそれが私たちの人生を形作っていることは明白だと私は信じています。
コンピューターがよりよい仕事としてできる暗記、あるいは「１＋１」のような計算は重要ではありません。私たちはコンピューターができないことを向上させるべきなのです――私たちを人間にしていることを。それが人間の頭脳を人工的なものと区別しているのです。遠い未来における私たちの生活と技術を想像するのは私たちなのですから、それこそが不可欠なのです。
私たちは今まさに過程の中にあり、初音ミクもそれに深くかかわり得る、というのが未来の創造についての私の考えです。それは音楽産業の変化に関する狭い視野の話にとどまりません――私たちは変化と進化のより大きな波の中におり、そして私はこの動きに貢献する機会を失いたくありません。
ですが私は近い未来、次の２、３年について正確には分かりません――それはちょっとした調整の問題だと私は思っています。
＊＊＊＊＊引用終わり＊＊＊＊＊
せっかくクリプトンの人が大好きなトフラーの「第三の波」について話しているのに、その肝心な部分をインタビューに収用しきれていないってのはどうなのよ。それとも最近の人はトフラーも知らないんだろうか。
ハリウッドのSF映画に登場したPCのモニター画面はこれまで何を写してきたのでしょうか？
The Vergeの記事『Tour Hollywood's craziest computer UIs, from '2001' to 'The Matrix'』によれば、WiredとWaxy.orgのライターでキュレーターでもあるAndy Baio氏が、様々な古い映画から集めたコンピューターのインターフェイスのスクリーンショットを1200枚以上公開してるそうです。
http://screen.waxy.org/screenshots/
主な映画のタイトルはHackers, 2001, Alien, Jurassic Park, The Matrix, AI
などなど。
『（ハリウッド）デザイナーが映画の一場面をさらに興味を引くように、"未来的"にするために取った、様々に異なった方法はとても魅力的です。』
It's a pretty fascinating look at the wildly different ways designers choose to make shots of a screen more interesting and "futuristic."
私が個人的に一番好きなUIデザインは、トップをねらえ！のように、意味のない円グラフや棒グラフが背景でピコピコしてるやつ。次点でHOSが起動してるところですねー。
そりゃ「慣れないから使いづらい」とそのまま言ったら単なる我儘だしね。
なんとか理屈を付けようとして、色彩がー視線誘導がーとか言ってたけど、
なんでそんなに「慣れ」だけの問題にしたがるのか？
通常のサイトのリニューアルで、ここまで拒否反応が出ることって珍しいと思うんだよね。
クックパッドとか、しょっちゅうインターフェイスもデザインも変えているけど、あまり話題になっていない。
