約 5,572,027 件
https://w.atwiki.jp/index-index/pages/23.html
注意！ ネタバレ解禁は公式発売日の24：00です。 それ以前に新刊の情報を書き込むのはおやめください。 ページ作成にあたって 新規ページを作成する際は、基本的には『wikiモード』で御願いします。 新規で項目を追加した場合には、 『該当する行のページ・音の列』、 『巻別索引』の該当箇所の２つに項目を加えてください。 項目だけ作って放置されると数だけ増えて不便になりますので、責任を持って内容を記述してください。 空白状態で編集すると、ページ名の『(未編集)』が取れてしまい、 本当に編集されていなくても見落としてしまいがちになるので、本文を記述しないならそのままにしておいて下さい。 関連スレで話題にならない・現段階でwikiに載っていない等のマイナーな情報であっても、 『情報の出典を明確に示すことが出来る』のであれば、自己の裁量でページを作成して構いません。 また、作品・作風の性質上、非常に難解な読み(当て字)の用語が多数出現します。 よってページを作成する際には 例題作成(テンプレート) のように半角括弧で読み仮名を記載してください。 具体的には、 必須 名詞(人名・地名・魔術霊装・超能力 等) 読み方が特殊(幻想殺し→イマジンブレイカー 等) (読みが普通でも)現実に存在しないもの(常盤台中学 等) (実在しても)読み方が難しいもの(大日本沿海與地全図 等) 不要・例外 読み方が明らかに普通(法の書 等) 名詞の組み合わせ(上条当麻の記憶喪失 等) のような方針ですが、最終的には個人の裁量にお任せします。 また英数字・アルファベットは半角で統一しています。 ページ内部の書式 ◆人物ページについては別項を参照 【種別】 人名・現象・etc 等の分類を明記してください。 例えばこのページなら、テンプレート と記します。 【元ネタ】 名前の元になったと思われるもの等、あるのならば出来るだけ簡潔に記述。 冗長に説明するぐらいならwikipedia等の外部リンクを張って誘導するなどしてください。 無ければ項目を作る必要は無し。 スレネタの項目には必ず入れてください。 【初出】 憶えていない場合は空欄を作り、解る人が後から追加してください。 巻数を記載する場合は漢数字で。 ex)三巻 十五巻 ヘヴィーオブジェクトの場合は、禁書各巻との混同を避けるため、サブタイトルを入れて下さい。 ex)ヘヴィーオブジェクト 採用戦争 巨人達の影 【解説】 作中での扱い等を記述。 情報量が増加してきた為、 概略→容姿(外見)→パーソナリティ(性格・具体的な内容など)→作品上の出来事(時系列) のような形式にまとめ直しています(2007年5月22日現在)。 今後新規ページを作成する際にはこの書式に則った編集を御願いします。 なお、ネタの場合はスレ内でどう扱われているのかも記述してください。 また、全ての項目において、句読点・改行のタイミング等、読みやすいよう工夫してください。 (ノートPC等ワイド画面で編集すると改行タイミングがおかしいことが多いです) 基本編集方針としては、「長文で端での自動折り返し」ではなく「細かく改行」を行っています。 『辞典』であることを認識し、客観的に正しいもの、本文中に記述のあるもの、確定的な推論等、 根拠の明確なものを記してください。 コメント欄制度は2010/11/22を持って終了しました。設置しないで下さい。 記述内容について意見、語りたいこと等があれば、本スレ及び禁書板内wikiスレにて行って下さい。 コピペ系等の長文などを引用し書き記す場合には、 半角スペースを文頭においてください。 また、広告と本文が混ざるのを防ぐため、 一番下の行に ---- (半角ハイフン４つ) と入力してください。
https://w.atwiki.jp/fsharpmaster/pages/20.html
オブジェクト指向フレームワークとワークフロー（モナド） 今現在、Javaでフレームワークを設計する仕事をしている以上、今作っているようなものをどのような形にすればF#に持ち込むことができるのか、ということには当然興味の焦点のひとつになってしまいます。 以前、Javaでやっているライブラリを移植しようとあれこれ考えているうちに、結局F#でもオブジェクト指向に走ってしまい、結局プログラムの枠組みが変わらない、そのまま移植したようなプログラムになってしまったことがあります。オブジェクト指向で作っていると、ある程度は破壊的代入を前提としたクラスを作らざるを得ず、「これならC#でもいいじゃないか」と自分で思ってしまうようなプログラムでした。 こういう選択肢を取れることもF#（OCaml）の強みなのかも知れませんが、できることならF#なりのプログラムの形を追及してみたいところです。 ポリモルフィズムを考える オブジェクト指向フレームワークで使われる手法の代表格、ポリモルフィズム（多態性）ですが、この多態性には使い方ベースで二つの分類があることに気づかれているでしょうか？一つは「外側からの多態性」で、もう一つが「内側からの多態性」です。と言う言葉は僕が勝手に使っているもので、他でどう読んでいるかは実はよく知りません。しかしオブジェクト指向でメシを食っている人は、多かれ少なかれ両方を日常的に使いこなしているはずです。 外側からのポリモルフィズム 最も分かりやすく、一般的な使われ方の多態性です。もうサンプルなど乗せる必要もないと思いますが、「外側から」がイメージできるように簡単なものを載せておきます。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace OOPSample { abstract class Animal { abstract public String Bark(); } class Dog Animal { override public String Bark() { return "Bow-wow!"; } } class Coq Animal { override public String Bark() { return "cock-a-doodle-doo!"; } } class Program { static void Main(string[] args) { Animal[] animals = {new Dog(), new Coq()}; foreach (Animal animal in animals) { Console.WriteLine(animal.Bark()); } } } } こうやってC#のコードを貼ると、F#のソースがどれだけ簡潔なものになっているかはっきりと分かりますね。上のコードについては解説するほどのものでもないと思いますが、Mainメソッドの中を見ると、animal.Bark()という風に、仮想関数をオブジェクトの外からCallしているところから、「外からのポリモルフィズム」と呼んでいます。単純明快なので、先に身に付けるポリモルフィズムは普通こちらだと思います。 内側からのポリモルフィズム 今度のポリモルフィズムは、仮想関数を基底クラスから呼び出すものです。 using System; using System.Collections.Generic; using System.Text; namespace OOPSample { abstract class Animal { abstract protected String Bark(); abstract protected int Legs(); public void BarkOperation() { Console.WriteLine(Bark()); Console.WriteLine("I have {0} legs\n", Legs() .ToString()); } } class Dog Animal { override protected String Bark() { return "Bow-wow!"; } override protected int Legs() { return 4; } } class Coq Animal { override protected String Bark() { return "cock-a-doodle-doo!"; } override protected int Legs() { return 2; } } class Program { static void Main(string[] args) { Dog dog = new Dog(); dog.BarkOperation(); Coq coq = new Coq(); coq.BarkOperation(); } } } 長っ！こういう括弧の付け方を強要する言語ってあんまり好きになれないなぁ・・・。 こういうポリモルフィズムは、以下のような状況で使われます。 プログラムの全体の流れは決まっているが、その中の一部の処理だけが処理によって異なる、または決まっていない。 そういうケースで、全体の流れを基底クラスのメソッドで実装し、処理が異なる一部の処理を純粋仮想関数で定義しておく（フレームワーク実装者の仕事）。 派生クラスで純粋仮想関数を実装することで、プログラム全体の定義を完了する（業務実装者の仕事）。 MFCみたいな古典的なフレームワークはこんな作りになってることが多いです。 ちなみに、この基底クラスで実装されているBarkOperationメソッドを別のクラスで実装し、派生クラスのオブジェクトを外から与えるようにしたのがBuilderパターンと言えます。依存性云々の関係でで最近はこっち（Builderパターン）のほうが主流になっているみたいですね。僕は個人的にあんまり好きではないのですが（業務側ソースの絵面がごちゃごちゃするので）。 どっちにしても、なんだかこれはワークフローで書き換えられそうな気がしてきます。 上のAnimalクラスをワークフローに書き直してみましょう。 F#で書き換えたコード type OopTransType = Bark of string | Legs of int | Terminate type OopTransBuilder () = member this.Bind (res OopTransType , cont unit - OopTransType) = match res with | Bark x - printfn "%s" x cont () | Legs x - printfn "I have %d legs" x cont () | Terminate - Terminate member this.Return(x a) = Terminate member this.Delay(restOfComputation unit - OopTransType) = fun () - restOfComputation () let ooplike = OopTransBuilder() let dog = ooplike { do! Bark "bow-wow" do! Legs 4 } let coq = ooplike { do! Bark "cock-a-doodle-doo!" do! Legs 2 } 実行結果 dog ();; bow-wow I have 4 legs val it OopTransType = Terminate 構造的に、サブクラスでオーバーライドされていた部分が後半のooplike{}の中にまとめられ、基底クラスのBarkOperationで実装されていたものがBindに移されたような状況です。 こうしてみると、業務側の記述はオブジェクト指向と比較してずいぶんすっきりしますね。ただ、オブジェクト指向でも抽象化が進んだフレームワークではずいぶん「業務をこのように書くと裏の仕組みがどうなってて動くのか分かりにくい」と言われたものですが、ワークフローではそれに拍車がかかった感じがしないでもありません。ただ、OOPのほうは、仮想関数を実装してもそれがどの順で実行されるのか、基底クラスやDirectorクラスを見ないと分かりませんでしたが、ワークフローではそのあたりが業務側に安心感を感じさせてくれる記述になっている気がします。 プログラムの構造とその変化 「内側からのポリモルフィズム」にしろ「Builderパターン」にしろ「ワークフロー」にしろ、やろうとしていることの元々の形は以下のものです。 業務ごとに処理は異なるが、出力の型は共通している処理Ａ（業務処理Ａ） 業務処理Ａの結果Ａを受け取り、水面下で行われるべき処理ａ（共通処理ａ） 共通処理ａの結果ａもしくは業務処理Ａの結果がパススルーされたもの）を受け取る（もしくはなにも受け取らずに処理する）、業務ごとに処理は異なるが、出力の型は共通している処理Ｂ（業務処理Ｂ） 業務処理Ｂの結果Ｂを受け取り、水面下で行われるべき処理ｂ（共通処理ｂ） このようなプログラムは、まるで刺繍糸が布の表と裏を行き来しながら縫い目のきれいな表面だけを見せるように、イルカが水面を時折ジャンプしながら泳ぐように、見えているこちら側の美意識を守るため、向こう側の処理をあえて見えないようにしておくような構造を持っています。 他の人はどうか知りませんが、僕はなんとなく以下のようなイメージでいつもコーディングしています。作るべきもの全体を見渡して、大きな流れで共通するものを探し、どうしても共通化できない部分をモチのようにつかみ出して水面上に出し、その部分だけインターフェースを書いて業務の人に実装をお願いするイメージです。 オブジェクト指向の場合は上の絵を頭に浮かべてそれでうまくいっていたのですが、ワークフローの場合はこの絵がBindの持つ多重性と全体の再帰的な構造のため奇妙にねじれてしまうのです。まるでクラインの壺のごとく。それのよじれ感をうまく図にしたいのですが。 構造的な変化は大きく分けて二つあると思います。 ビルダーメソッドの重層化 OOPでは、業務と業務の間に水面下で行われる実装は、先ほどの図のようにビルダーメソッドで仮想関数呼び出しの間に記述されていました。 しかし、ワークフローのビルダークラスでは、これがBindメソッドのmatchの中に押し込められます。 この二つの違いは、業務側の実装自由度に現れてきます。OOPでは、業務側の記述がいつどの順番で実行されるかは完全にフレームワークの実装に依存していて、業務側で変更できないようになっていましたが（BuilderパターンにすればDirectorクラスの実装を変えることで対応できますが、水面下の実装はDirecotorクラスに記述されることになるので、このクラスは業務側で書くべきものではないはずです）、ワークフローでは前の関数の戻り値と次の行の引数のつじつまが合えばDSLのようにある程度自由な記述が可能となります。 例えば上のdogコンピュテーション式は let dog = ooplike { do! Legs 4 do! Bark "bow-wow" } のように書き換えても動きますが、「内側からのポリモルフィズム」ではこのような変更を許すことができませんし、BuilderパターンではDirectorクラスの修正が必要になります。 コンピュテーション式の行と行の間でBindの中のどの処理が実行されるかは、前の行が判別共用体のどの型を返すかによって決まります。上の例では「Legs 4」は「Legs of int」を返すので、 | Legs x - printfn "I have %d legs" x cont () にmatchしてこの行が実行されることになります。 Bindメソッドの再帰構造 あまり意識するようなものでもないのかもしれませんが、OOPでは 業務処理Ａ 共通勝利ａ 業務処理Ｂ 共通勝利ｂ のようにベタッと書かれていたものが、ワークフローを使うと 業務処理Ａ 共通勝利ａ 業務処理Ｂ 共通勝利ｂ のように自動的に入れ子構造に展開されます。しかしまぁこれは、OOPでも入れ子構造に書けないことはないのでたいした違いはないかもしれませんが、入れ子（再帰）構造のコードは決して読みやすいものではないので、ベタッと書けば勝手に入れ子にしてくれるのは、コードの保守性という意味ではありがたいと言えるかもしれません。ただ、Bindが入れ子に展開されるということが実装者に分かっていないと、デバッグのときなどに何が起こっているのかわからない、ということになりかねませんが。 とにかくこのような構造を先ほどの図に組み込むと、こんな感じになります。図的な理解と合わせて読んでいただけるとより理解しやすいかもしれません。 この再帰的な構造がイメージしていただけるでしょうか。この図に描ききれていないのですが、一つ重要なことがあります。この図に表れる（青い四角で囲まれた）二つのBindと一つのReturnは、同じオブジェクトのメソッドになります。Bindで呼び出した継続処理の中で、もう一度自分が中から呼ばれているようなちょっと不思議な構造です。業務処理はベタッと縦に並べて書かれていても、実はこのように再帰的な呼ばれ方をしているのです。 まとめ 少なくとも、オブジェクト指向でBuilderパターンと呼ばれているような構造は、ワークフローで書き直せることが分かりました。しかし、業務側にDSL的な自由度を許す必要がない場合は、普通にBuilderパターンや内側からのポリモルフィズムを利用したほうが、プログラムはずっとわかりやすく、メンテしやすくなるでしょう。 しかし、業務側が業務内容に応じてfsxスクリプトで書いて実行するような、業務側に高い自由度と安全性が求められる場合には、ワークフローは非常に強力な手段になり得ます。F#ではこういう手法が取れることを常に頭の隅に置いておき、適切なときにこの仕組みを利用できれば、F#使いの面目躍如といったところです。 （文責：片山 功士 2012/01/10） 今日： - 人 昨日： - 人 トータル： - 人
https://w.atwiki.jp/wdmsmm/pages/13.html
デジタル・メディア論ゼミ SMM（ソーシャルメディアマーケティング）プロジェクトの連絡、共有用ページです。 授業やその他MTGで出た話の共有はもちろん、興味深いネタや情報もどしどし挙げていきましょう。 例：7月2日（木）議事録 ＝＝ 1)水曜6限の内容共有。 主に理論チームの話し合いをしました。 2)アイデアチーム、理論チームの進捗報告。 アイデアチーム まだメンバーで集まれていないので、次回までに集まりをもつ。 漠然としているとアイデアを出しにくいので、なにか基準があると助かる→まずは前期のプロタイプ制作に向けて、前々回のマンガ吹き出しのアイデアなど、面白そうベースでよいのでガシガシ出してほしい。領域としてはソーシャルメディアを用いてWeb上で行えるもので。 理論チームの仮説と合わせて検証を行う、リアルの場での影響なども視野に入れた実施内容を後期の目標に。 理論チーム 1人1人が持ってきた事例＋考察の発表 ※内容に関してはこの後共有します。 もう少し事例、考察を詰めて仮説立てに もっていく。 3)チーム分けの続き ■理論チーム 笠井さん、西沢さん、郷田さん、中村くん、稲毛(仮リーダ)、木村さん、山本さん、ジョンさん ■アイデアチーム 越後くん(仮リーダ)、土井くん、加藤くん、氏田くん、キムさん、小出さん 4)今後の内容共有について みんながそれぞれまとめた内容、その日の各チームのmtg議事録などはまとめwikiで共有し、逐一閲覧できるようにします。 書記担当は笠井さんがやってくれます。 WIKIの使い方や今回のルールについては今夜別途連絡予定ですので、そちらをご確認ください。 ＝＝ 参考映像 ソーシャルメディアには直接的に関係はありませんが、最近見て面白かったので。（稲毛） デレク・シヴァーズ 「社会運動はどうやって起こすか」 ＝＝＝＝ ７月８日、理論班の議事録 前回のゼミ後に報告したソーシャルメディアにおける既存事例の考察を掘り下げてディスカッション。 詳細な内容は記載済みの事例の考察(1)(2)と大幅に重複するのでそちらを参照のこと。 議論はこれら２つの事例をもとに、主にTwitterを題材にしながら、ややアイディア寄りに論点をシフトさせて進行。 主な論点は、プロジェクトが内輪で終らないために、また根本的に人を動かすにどんな要素が仕組み・コンツンツ・操作方法・デザインなどに必要かという点。 以下、意見。 ソーシャルメディアの操作(=投稿・コミュニティへの参加など)が簡単であること 解りやすいこと 自分のアクションと他者のアクションが比較できること(Ex 診断メーカーで他者の診断結果を見られるような面白さ) プロジェクトに参加する前に「見た目」でそれが面白いと分かること(=直感で面白いと感じさせること、例えばデザインで目を引くというのも一つの手であるはず) プロジェクトをデザインする上で、参加者の主体性を保持すること=参加者の手でプロジェクトが完成するような仕組みをデザインして、参加者の内部に達成感の生成を狙う 占いや診断メーカーのように結果に正確さや意味がなくても「なんとなくやりたい」という気持ちを生むようなものが有効なのでは？ 「今ここ」時代に、あえてリアルな時間を流す mixiのサンシャイン牧場のように「日課」化するようなコンテンツを考える→ほっとけない感を創造する ユーザーの想像を超えるような「見せ方」をする exユニクロ、colortweet sportweet( http //www.uniqlo.com/uniqlotweet/) 今後の理論班の活動としてはあと１週ほどは事例の考察をして、その後仮説立てに取りかかる予定。 ＝＝＝＝＝ ■理論チームによる事例の考察 （１）#kizuku-VOICE OF AWARENESS（twitter）についての考察 #kizuku-VOICE OF AWARENESS（twitter）とは？ 「#kizuku」とつけられた“つぶやき”を「日刊気づき新聞」としてシェアする事を目的としたtwitter上でのプロジェクト。単なるシェアにとどまらず、他人の「気づき」にインスパイアされて新たな発見＝気づきを生むことを期待したソーシャルプロジェクト。 大勢のユーザーが#kizukuをつけるのはなぜか＝「日刊気づき新聞」が成立するのはなぜか？ ここで問題とするtwitter上での「日刊気づき新聞」は#kizuku付きのつぶやきなしには“刊行”され得ない。当然、より面白い記事（＝#kizuku付きのつぶやき）が掲載されるためには、つまり「日刊気づき新聞」のクオリティを保つためには、大勢のユーザーのつぶやきを集めてその中で選りすぐりを発掘する必要がある。と言うのも、記事が選択される上で“選ぶ余地”がないほど投稿が少なければ淘汰もなく、その内容が貧困化することは当然と思われるからである。しかし現在見る限りにおいては、この「日刊気づき新聞」にそうした兆候は見られない。つまり面白い記事が幾多のつぶやきの中から台頭しているのである。こう言うと「そんなにレベルが高いのなら、玄人が投稿しなければ記事は載らないのではないか」だとか「一般のユーザーによる投稿は少ないのではないか」という疑問が生じるかもしれない。しかしそのような事はなく、実際に一般のユーザーから発信されたつぶやきも掲載されているようである。 ではなぜいわゆる玄人・素人を問わずに多くのtwitterユーザーが「日刊気づき新聞」プロジェクトに“乗る”のか。私はここにネットの普及や情報技術の安価化（チープ革命）を契機とした総表現者時代（または万人表現者時代）が背景にあると考える。かつての“表現”はごく一部の人による特権的な行為であったことは言うまでもない。執筆、音楽、美術などに代表されるあらゆる表現行為は“誰かに認められたり”、“その道の有名な師に弟子入りしたり”する事で後ろ盾を得てはじめて成功するものだった。しかもこの頃は「表現の場」も“リアル”に限られていた。しかし今は違う。人々はインターネットによりリアル以外の世界を得て、また安価なＩＴ技術によって表現の手段を得た。このように表現の場と手段が整ったことで表現行為は一部の特権的な行為ではなく、万民に開かれる行為となったのである。 そしてこのように表現する環境が整ったならば、人が表現する事を望むのは自然である。と言うのもせっかく表現する手だてがあるのなら「やってみたい」と思うだろうし、人はもともと表現（≒芸術）や表現者（≒アーティスト）に憧れるものである。そして憧れを超越できる手段を得たことによって、単に憧れるだけでなくアーティストと同じように（あるいはそれ以上に）自分の言葉や考えを大勢の人の目に触れさせ、それを認めさせ、楽しませることができるならと思っても不思議はない。 つまり#kizuku-VOICE OF AWARENESSは、極めて手軽に実現できる表現の場を提供しているため、表現意欲や創作意欲を持った人がこぞって乗ってくるのである。「日刊気づき新聞」につぶやきが載った場合、幾多の投稿を押しのけて「自分のつぶやき」が載ったという優越感や特別感が投稿者に芽生え、これが彼らのさらなる意欲や精神的な報酬となって新たな表現を促す。従って人の潜在的な表現・創作意欲を利用し、手軽に出来ること・精神的な報酬（達成感・優越感など）が得られることを実現できる仕組みを備えたソーシャルメディアならば、総表現者時代を生きる人々を巻き込むことは可能かもしれない。 (2)http //www.uniqlo.com/colortweet/ http //www.uniqlo.com/sportweet/uk/について 上記のサイトのように、自分のつぶやきがお洒落に表示されたり、面白く表示されたりすると、実益はないもののやってみたくなる。（←ｔｗｉｔｔｅｒのもともとのサイトがあまり工夫されていないため、お洒落や面白く表示する余地がたくさんある！） 自分のアカウントを入力するだけで、勝手に表示されるのでアクセスするのに躊躇なし（←なるべく多くの人にアクセスされ認知度を高めるためには、アクセスする為の手間がなるべく少ない方がいい。もしソーシャルメディア班でこういったサイトを作ることになったら、完成一歩手前で終わらせて、利用者に最後の工程をやらせる！） 一人ひとりのつぶやきの内容によって出てくる結果も変わると面白いかも（ｔｗｉｔｔｅｒ診断からも分かるように、結果がでたらめであれ、一人ひとり違った結果が出ると自分だけの結果という特別感が出たり、他の人がやったらどんな結果になるんだろう？とＲＴしたくなったり、周りに広めたりしたくなるのでは？？） ＝＝＝＝＝ 7/8 議事録（アイデアチーム） ソーシャルメディアに留まらずにリアルと連動したもの さらには新しい流行が作れたらベスト。 ■注目の事例 「NIKE TASUKI TWITTER W＆K tokyo」 http //www.wktokyo.jp/blog/?p=2362 TwitterとUSTとリアルがうまく連動した事例。 今まででてきたものや今回のたすきの事例を踏まえたうえでのキーワードは “あちら側とこちら側”をつなぐもの ■新しい叩き台になりそうなアイデア 「ワセ女２４」 大学生が食いつく話題としてワセ女、ミスコンなどの女子大生系。 そこでワセ女のプライベートに密着する ただし単純に全部見れるのではなく、コメント数によって見れる範囲が増えるなどの参加型に 「女の子の化粧をリアルタイム中継する」 スッピン→フルメイク（もしくは逆） 化粧に詳しい男子を増やそう。もっと女の子の化粧に理解を！ 次回までに、さらに「あちら側とこちら側をつなぐ」というキーワードを意識したアイデアを出す ＝＝＝＝ ■理論チーム課題 事例２つ １）DOMMUNE DOMMUNEとはー 宇川直宏（グラフィックデザイナー、映像作家、VJ、現代美術家、文筆家）が主宰する、東京・渋谷のライブストリーミングスタジオ。 すべての番組は動画中継サービス「Ustream」と、連動している「Twitter」で発信される。配信番組は視聴無料で、日曜〜木曜に放送される。 金曜・土曜に放送がないのは「リアルなクラブへ足を運んでほしい」という意向によるもの。 Ustream上で配信されるクラブイベント。クラブイベントでありながらUST上の配信のみで、 リアルの場でのパフォーマンスは行われない。告知などは基本的にTwitter上で行われ、毎回同時視聴数5000人弱と UST上のコンテンツとしてもかなりの規模を持った企画。 考察 コンテンツのクオリティやネームバリューは真似できないとして、USTという緩い配信の中で しっかり作りこまれた番組であることは人気のひとつの理由であると思われる。 またクラブイベントの生配信というマスメディアでは難しいジャンルを扱っている点も人気の理由か。 参考にできるポイントとしては「音楽」か。 特にクラブミュージック、アニソンなどネットユーザーに刺さりやすいジャンルの 視聴数はコンスタントに多いように思われる。「みんなで好きな音楽をリアルタイムで聞いて盛り上がる」 というまさにライブの面白さがネットで実現出来るようになったのも大きいかと。 でも発展性はないかなぁ。 おわり。 （稲毛） 2)ミクシィ年賀状 ちょっと古いけど。 マイミクさんにミクシィ経由で年賀状を送れるサービス。 最大のポイントは、送り手は相手の住所を知らなくても年賀状を送ることが出来ること、 受け手は個人情報を守りつつ年賀状を受け取ることができること。 間にミクシィがかむことでそのような形式を可能にした。 考察 ネット上の縁、をリアルの場に繋ぐことに成功したことがこの施策のすごいところかと。 内容自体は年賀状離れをミクシィという繋がりに強いSNSを利用することでなんとかしよう、 というものでそこまで面白くはないけど、リアルとネットのどちらも利用、影響を与えるという点では 今回のプロジェクトにもなにかしら利用出来るかも。 ポイントとしては年賀状のような「ごあいさつ」「季節の行事」「繋がり感」「もらったら嫌な気はしない」 というポジティブで誰もが手を出しやすいツールを、ネットというより繋がりやすい場を使ってやらせたことかと。 ０ベースのアイデアだけでなく、今ある要素（特にみんなが知ってて取っ付きやすいもの）を ソーシャルメディアと絡めることで以外と大きな反響を得られるかも。 おわり。 （稲毛） 参考文献 使ってもらえる広告 須田和博 ＝＝＝＝＝＝ ミクシイ「サンシャイン牧場」×爽健美茶 http //japan.cnet.com/marketing/story/0,3800080523,20410991,00.htm ４月９日までの期間限定企画。 植物由来素材を一部使用した次世代型ペットボトル「プラントボトル」とプラントボトル を採用した爽健美茶の認知拡大を目指し、mixi内で 「爽健美茶ビンゴ大会」を開催。ユーザーがこれに参加す ると、サンシャイン牧場で利用できる「爽健美茶の種コー ド」がもらえる。種コードをサンシャイン牧場に登録すれば牧場にプラントボトルの爽健美茶が作物として育つ仕組みだ。 ビンゴ大会に友人を招待すると種コードがもらえたり、ほかのユーザーのビンゴカードが見えたり、mixi内の友人関係を介してキャンペーン が広がるような仕掛けも。 （考察） 前回も出た話だけど、「他の人の状態がわかる」友人を招待したり広げれば広げる程自分にいい事がある、後「期間限定」 というのも人を惹きつける要素かなと思います。爽健美茶育ててるぜっていう優越感も。 （山本） ココロ、クリア、ラボ。（NIKKA WHISKY） http //www.nikka.com/world/kob/index.html 宅飲みで恋に落ちた人が多かった事から恋愛と宅飲みに焦点を当てたキャンペーン。 恋愛中の心のモヤモヤを「＃ClearLabo」でつぶやいて解消する。 twitter上で恋愛に関するアンケートも行っている。 UST「ココロクリアライブ」（宅飲み形式ガールズトーク）とも連動していて、twitterでつぶやいた恋愛に関するアンケート結果 についてゲストが話したりするらしい。 （考察） 恋愛関連のモヤモヤ＝誰かに言いたい、つぶやきたい、ガールズトークしたい！ という欲求を上手く利用してる気がする。 恋愛に関するガールズトーク、ボーイズトークとか大学生が食いつきそう。 （山本） ＝＝＝＝＝＝＝＝ （１）ニコ生化粧配信 この前アイディア班がが挙げてくれたやつと似てるかもしれないけど・・・ 今ｔｗｉｔｔｅｒでもｍｉｘｉでも大きな反響を呼んでいるもので スッピンから完全メイクまでの過程を放送したニコニコ生放送 どスッピンのｂｅｆｏｒｅを移した後に リアルタイムでどの様に化粧が行われていくのかが分かる 特に反響を呼んでいる理由として女性のｂｅｆｏｒｅとａｆｔｅｒの振り幅 匠の技だなｗｗｗ なんという画力 キラーだったのか ニコニコ技術部 ここまで化粧塗りたくるんだな ナンパしてスッピン見たらショックだろうなぁｗｗｗ なんてコメントも。 考察 男子からしてみれば、未知の世界に踏み込んだものだった為大きな反響を呼んだけど 女子からしてみれば、毎日自分もやってることをただ流しているだけの動画 でも女子からも大きな反響を呼んでいたので その理由として「のぞき見」している感覚があるからなのかも 女子でも自分以外の化粧過程なんて見る機会はほとんどないから ちょっと似ているものとして挙げられるのがこの前ｍｉｘｉニュースで紹介されていた キャバ嬢の顔をこすると化粧が取れてスッピンになるというアプリ これも普段のキャバ嬢の裏の顔を「のぞき見」している感覚になるのかも？ 西沢 （２）TBS「革命×テレビ」 まさに今の時代に生まれましたっ！て感じのテレビ番組 以下番組ＨＰからの抜粋 ―――――――――――――――――――――――――――――――――――― 地球上のあらゆる場所で起こっている“今”をリアルタイムでお伝えします。 日曜日夜11時30分・・・静まり返っている日本。しかし『世界は動いています！』 おもしろ情報からすごい現象まで、全世界で起こっている・話題になっている現場に革命特派員が向かいリアルタイムで情報をお伝えしようという番組。 革命特派員は秘密のリュック「LIVE PACK」を背負い現場に向かいます。この「LIVEPACK」とインターネットのライブ配信サービス「Ustream」を使って全世界から生中継。 生中継は毎週8ヶ所程度を予定、スタジオにいる雨上がり決死隊と小林麻耶が中継内容の見出しから面白そうなものだけを勝手にチョイス、それだけが放送されます。現場の革命特派員は採用して欲しい思いから、おもしろ情報や驚きの情報を世界中から探し配信します。 さらにあのゲストもTwitterで自由に発言、今までのテレビではなかった展開で番組が進行していきます。 もちろん視聴者のみなさまもTwitterを使って番組に参加する事ができます。 更に更に！放送時間の前後30分程度、公式ホームページ上では番組とは違ったオリジナル中継をお送りします。 『革命×テレビ 地球同時多発情報SHOW』どうぞお楽しみに！ これを読んでも良く判らないという貴方、まず番組を見てください。 ―――――――――――――――――――――――――――――――――――― 考察 なんかこの番組紹介だけ読むとめっちゃ楽しそうなんだけど 実際みるとそうでもない、終始ぐだぐだしてる 「全世界から生中継！」て言うけど今までのテレビの生中継とどう違うの？ ｕｓｔならでは！の生中継の仕方？みたいのをもっと生かすべき 「ｔｗｉｔｔｅｒで番組に参加！」て言うけど たとえばみのさんの奥さんと電話で悩み相談したりするのとどう違うの？ ｔｗｉｔｔｅｒならでは！の番組への参加の仕方をもっと考えるべきかも じゃーｕｓｔならでは、ｔｗｉｔｔｅｒならではのやり方て何？てなると よくわからないんだけど＞＜ごめんんさい！中途半端！ 西沢 ＝＝＝＝＝＝＝＝ ガールズログ http //girlslog.jp/ ガールズログとは？ Twitterで恋愛・美容・ファッションなどいわゆる「ガールズトーク」を発信しようというもので、レギュラーメンバーとしてのガールズ88、一般会員としてのメンバーズ、企業会員としてのスポンサーズの3つの構成からなり、それぞれのポジションからの情報発信を行っている。またガールズ88とは、ガールズログのオフィシャルメンターとして、ガールズログ事務局とともにガールズログの運営に携わる女の子たちであり、Twitterを使って思いのままに毎日楽しいつぶやきを発信する。 ガールズ88は、その名の通り、最終的には88名のチーム編成となります（現在は25名）。ガールズ88のチームメンバーは皆、情報感度が高く、オシャレで前向きな、セレクトガールズとのことだが、都内近郊に在住の１８歳以上の女子なら誰でも応募可能なので、いわゆる「普通の女の子」で構成されている。 考察 Twitterを「ガールズトーク」に特化して利用したもので、このプロジェクトに食いついてくる性別・年代を絞っているところが特徴。おそらく女子が普遍的に興味を持つと思われる恋愛・美容・ファッションというネタを餌にして年頃女子の興味をひこうというものだろうが、イマイチ成功しているのかは疑問。 私見としては完全に失敗しているように見える。（もしガールズログやっている人いたらごめんなさい）原因としてはまず、既存のソーシャルメディアとコンテンツが被っていることが挙げられる。例えば美容に関しては「＠コスメhttp //www.cosme.net/」がすでにコミュニティとして確固たる地位を築いているので、あえてガールズログで美容ネタを話す必要性を感じないということだろうと思う。 またガールズログのつぶやきの質やガールズ８８のレベルが低いのも大きな原因では？多少辛口で言うと、ガールズ８８には確かに可愛い人もいるがサイトのデザイン共々（キャバ嬢とかメイドの紹介みたい）どこか安っぽい感が否めない。 「ガールズトーク」という特定の層に需要のありそうなネタを選択したところは有効だと思うが、安易すぎるように思う。ネタ選びやサイトの見せ方にも十分注意する必要がありそう。 笠井 「AXE EFFECT」 制汗剤？のアックスのweb上でのコンテンツ。「良いにおいがする男の子は好きですか？」という質問をかわいい女の子に聞くという企画。女の子はペラペラしゃべるのではなく、ただ一言「好きです」としか言わない。ただそのシンプル感がwebを見ている男子にはたまらない。 考察 この企画のキーワードは「かわいい」と「好きですの一言」というところにあると思う。普通の街頭インタビューなら質問内容に対して、ちょっと話とかもきてみたいはず。しかし、これはただ一言「好きです」としか言わない。でも、たくさんのかわいい女の子の連続で言われたら、正直男の子はたまらない。自分も見ましたが、ニヤニヤが止まりませんでした。このサイト見たら、「アックス買ってみようかな！」ってなる人結構といると思います。そういう意味では、ネットユーザの購買意欲を喚起させるなって思いました。男子必見です。ここから、なんかサブリミナル効果的な感じで、何回も連続で同じこと（プラスイメージな言葉、がんばってとか、好きですとか）を言ってくれるような企画とかシンプルでおもしろいんではないかと。ちょっと二次元ぽいですが笑毎朝、寝る前、試験勉強中の励み企画的な・・・。 http //www.axeeffect.jp/lab/ （中村） ＝＝＝＝＝＝＝ 7/22(木)5限MTG 参加者 稲毛、笠井、山本、西沢 ＝＝＝＝＝ 7/29 ２年生向けゼミガイダンス担当する。 6限 36号館581教室 時間 5分 参加者 稲毛、笠井、山本、木村、西沢、木村、越後、小出 １）ゼミの説明（1分） ２）去年のプロジェクト（2分） さとちゃんの映像流す。 ３）今年のプロジェクト（1分） 写真と映像 ４）草原先生のメッセージ（1分） ■資料 パワポ 映像 写真 メッセージビデオ ※1度打ち合わせをする。 ＝＝＝＝＝＝＝ ■理論チーム ■アイデアチーム ＝＝＝＝＝＝＝ 7/22 議事録 今後の予定 7/29(ゼミ説明会) →私たちｓｍ班が担当 8/6(プロジェクト実施) →実施に向けて、理論班は仮説立ての文章化作業をする。アイディア班は後述する実施アイディアプランをつめる。 アイディア ①「あなたの欲望かなえます」 twitterでみんなが実現させたい「欲望」を募る。 そこから適宜集まった「欲望」を実現可/不可に区分けし、可なものは私たちがリアル世界で欲望の主の代わりに実現化させる。(あるいはバーチャルリアリティの場を提供し、バーチャル上で欲望を自分の手で叶えてもらう ex 文キャンにでかく絵を描きたい) 不可なものは「欲望の森」みたいな感じでWEBサイト上で可視化させて共有する形で残す。 ②悩内Twitter 根幹にある考え方としては、普段みんなが隠している(あるいは、わからないけど知りたい)こと=「ある場面における本音」を可視化するというもの。 方法としては、立場が対照的な人が会す場面を想定し、WEB上にその場面とtwitterのタイムラインを提示する。 その場面から想像できる台詞を自由につぶやいてもらい、時々ふきだしのような形で画面上でランダムな会話を構想してみる。 (文字の説明は大変なので想像できない人は越後くんor稲毛くんor私に質問) 想定した場面(☆印が実施予定のもの) ☆合コン ドライブ プロポーズ 上司・部下 ☆面接 トイレの個室 嫁・姑 ☆犬・飼い主 ショップ店員・客室 電車内(カップル・化粧) ☆美容室・客 ナンパ ☆アイドル握手会 問題点 ①想定場面に自分たちの顔だすのには抵抗あり ②ネタ的な格好しすぎると炎上する可能性あり 今後は理論・アイディアの仕事が一段落したのち、新たな役割分担で動く予定。 ＝＝＝＝＝＝＝ 7/26(月) 3限MTG＠36号館ラウンジ 議事録 ■参加者 稲毛、越後、氏田、木村 ■議題 29日ゼミ説明会について 脳内Twitterについて ■29日ゼミ説明会について 準備の進捗状況と今後すべきことについての確認など。 １）ゼミの説明（1分） →いなげんが担当。 ２）去年のプロジェクト（2分） さとちゃんの映像流す。 →映像を流しつつ、４年生１人(担当者未定)が口頭で軽く説明を入れる。 ３）今年のプロジェクト（1分） 写真と映像 →３年生１人(担当者未定)が説明をする。 ４）草原先生のメッセージ（1分） →前回の授業で越後が撮影してくれたものを使用。 担当者未定箇所については今日の時点で当日の参加者が確定しないので各自の予定を調べた上、具体的な発表内容含め、後ほど改めて決定。 ■脳内Twitterについて ▼前回のアイディアを更に面白くするための提案をディスカッション 写真１枚だけを使うのではなく、映像かスライド形式にして同じシチュエーション内でもいくつかシーンを切り替えられるようにする。 共感したtweetに投票出来るシステムを作り、人気tweetランキングにする。 脳内tweet一覧を表示するのではなく、ふきだし型の枠を作りその中にランダムにtweetが表示されるシステムを作る。 挙がったアイディアとしては以上だが、これ以外にも改善の余地はありそうなので、今後はひとまず形にしてから見えた問題点を洗い出しブラッシュアップしていく方法で作り始めることで決定。 ▼今後準備すべきもの ウェブサイト 各シーンの写真(または映像など) Twitterアカウント ロケ地(渡井邸を希望。８月頭にお借りしたいが、予定を調べ次第再度調整。) など。 ▼今後の方針 ロケチーム(撮影・キャスティングなど)、制作チーム(flashなど)の２班に分かれ作業を進める。理論はこれに並行し要素を洗い出すなどして内容を詰める。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 議事録：12/9 ゼミ内 発表：１月２０日 今日の活動：メンバー分担・使う写真決め 全員：一人１つシチュエーション写真をアップする。 稲毛：プログラミング(一枚絵が動けるようにする) 小出：広報戦略大臣 西澤：スケジュール 越後：ウェブ設計(機能・デザイン周り) 現段階：吹き出しに、文字を入れることができるシステム もっとウェブサイトとしての体裁を整えたほうがいいんじゃない？ 広報は制作者がおしていくのではなくて、身の回りの人にお願いしていく方向性がいいんじゃない？ 宿題：来週までに一人1シチュエーションを考える。 各担当のまとめを考えてアップする。 今後のスケジュール：発表準備で１月１５日は空けてください。
https://w.atwiki.jp/anime_wiki/pages/15270.html
■ゴールデンタイム 作画監督 22(香・小川・河・片・川・中・張・吉) 24(香・松・谷・小川・中) ■LOVE STAGE!! 作画監督 7(河・都) ■selector spread WIXOSS 作画監督 3(都・松・佐) ■食戟のソーマ 作画監督 17(河・能・谷・都・佐・小・香・林) 23(山・谷・都・奥・小・永) 作画監督補佐 3(山・都・福・小・林・石・中・廣) ■下ネタという概念が存在しない退屈な世界 作画監督 5(松・石・山) 10(松・小・森・和) 12(和・森・田・廣) ■ヘヴィーオブジェクト 作画監督 8(芝・徳・藤・谷) ■食戟のソーマ 弐ノ皿 作画監督 6(八・廣・中・河) 9(八・廣・舘・中・河) 12(鈴・谷・河・林・廣・中・鶴・小・八・舘・都) 13(都・谷・河・林・廣・八・青・中・小・谷・中・舘) ■関連タイトル Blu-ray ゴールデンタイム vol.1 特典CD付き初回限定生産版
https://w.atwiki.jp/wiki6_w-zero3/pages/12.html
W-ZERO3 Wiki AirWiki WILLCOM/WS003SH
https://w.atwiki.jp/gugu/pages/5.html
Gugu鯖の攻略WIKIです 右にあるメニューからどうぞ
https://w.atwiki.jp/steph/pages/150.html
初心者用のSteph @Wikiの使い方を説明するページです。 Steph @Wiki 新しいページを作成する Steph @Wiki の編集方法 Steph @Wiki へのアップロード方法 Steph @Wiki 新しいページを作成する Steph @Wikiに新規ページを作成するための簡単なチュートリアルです。 新たにプロジェクトの立ち上げ、またはプロジェクトのページに更に詳細説明のページを作りたい際には新しいページの作成を行います。 操作方法は簡単です。 1.Steph @Wikiを一番下までスクロールさせるとある「新しいページ」のリンクをクリックします。 2.ページ名を入力します。わかりやすく短い名前がいいでしょう。 ステフとして新たにプロジェクトを立ち上げる際には、自分のステフ名を入力しましょう。 3.「新規ページ作成」ボタンをクリックします。 ※5の投稿ボタンのクリックまで実行しないと実際のページは作成されません。 4.4の枠がページに表示される内容になります。掲載したい内容を入力してください。 文字を装飾したり、見出しをつけたりすることもできます。 ページを下にスクロールするとヘルプがあるので参考にしてください。 5.投稿ボタンを押すと実際のページが作成されます。 6.うまく表示されるか気になる場合は、プレビューボタンで表示予定の内容を確認することも可能です。 プレビューを押しただけでは実際のページには反映されません。 ページをスクロールすると下の方に編集画面があるので、問題がなければ投稿ボタンを押します。 7.作成したページは右メニューの少し下にある更新履歴に表示されているはずです。 これでページの作成は完了です。 Steph @Wiki の編集方法 Steph @Wikiを編集するための簡単なチュートリアルです。 既存のページを編集する方法を説明します。 操作方法は簡単です。 1.編集したいページの上部にある、「このページを編集する」のリンクをクリックします。 2.2の枠がページに表示される内容になります。変更したい内容に編集してください。 文字を装飾したり、見出しをつけたりすることもできます。 ページを下にスクロールするとヘルプがあるので参考にしてください。 3.投稿ボタンを押すと実際のページに反映されます。これで完了です。 4.うまく表示されるか気になる場合は、プレビューボタンで表示予定の内容を確認することも可能です。 プレビューを押しただけでは実際のページには反映されません。 ページをスクロールすると下の方に編集画面があるので、問題がなければ投稿ボタンを押します。 Steph @Wiki へのアップロード方法 Steph @Wikiへ画像やテキスト文書などをアップロードするための、簡単なチュートリアルです。 ページ内にタイトル画像やキャライメージなどを表示させたい場合にお勧めです。 その他の一時的なファイルや、大きめなファイルは外部のアップローダを使用してリンクを貼るだけにするといいでしょう。 ''ゲムデヴあぷろだ'' http //gamdev.org/up/ ファイルのアップロードはページ単位になるので、アップロードしたいページへ移動してから行ってください。 また、削除は管理人さんしか行えないので必要な場合はこちらからお願いしてください。 http //www8.atwiki.jp/steph/pages/19.html#id_4661dfc5 1.アップロードしたいページの下部にあるプルダウンリストから、「アップロード」を選択。 2.「参照」ボタンをクリックし、自分のパソコン上にあるアップロードしたいファイルを選択。 3.「submit」ボタンをクリックすると、アップロードが完了します。 4.アップロードした画像ファイルはページの編集で#ref(ファイル名)を入力することで表示できます。 名前 コメント @wikiへ
https://w.atwiki.jp/skyrim_jpn/pages/18.html
アイテム・オブジェクト：世界 （Items and Objects - World） 目次 House Decorations - Plants and Flowers Increase Torch Range No Quest Items Riverwood Smelter Useful Stuff of Usefulness House Decorations - Plants and Flowers アイテムとして飾ることのできる鉢植えを追加します。ホワイトランかソリチュードの店で購入できます。 日本語化 v2.0用 Increase Torch Range たいまつの照射距離を伸ばします。 日本語化されるのは，オプションファイルのExtra_Rangeの方のみです。 Extra_Rangeはたいまつの照射距離をさらに伸ばします。 日本語化 v1.0 Extra_Range用 No Quest Items すべてのクエストアイテムからクエスト属性を削除します。クエストアイテムが捨てられるようになるので注意してください。 また、クエスト属性が外れることによって重量が発生します（クエスト属性付きは常に重量0です）。 日本語化 v1.1用 Riverwood Smelter リバーウッドの鍛冶屋の横に溶鉱炉を追加します。 日本語化 v1.1用 Useful Stuff of Usefulness アイテムの価値や効果を調整します。 レアなものや入手しづらいアイテム、銀やドワーフ製食器の価値を上げ、食料・飲料の効果を向上させます。 睡眠ボーナスを向上させます。 日本語化 v1.2用
https://w.atwiki.jp/index-index/pages/2370.html
【種別】 オブジェクト 【初出】 ヘヴィーオブジェクト 【元ネタ】 Baby Magnum＝「赤ん坊のマグナム」 【性能】 全長…約75メートル(主砲最大展開時) 最高速度…時速530キロ 装甲…2センチ×500層(溶接など不純物含む) 用途…戦場制圧用兵器 分類…総合マルチロール型(第一世代) 運用者…正統王国第37機動整備大隊 仕様…静電気+レーザー型推進システム 主砲…回転アーム式兵装×7 副砲…レーザー、コイルガンなど コードネーム…ベイビーマグナム メインカラーリング…ホワイト 【解説】 正統王国所属の総合マルチロール型オブジェクトの一種。 操縦するエリートはミリンダ＝ブランティーニ。 本体だけで全長50メートル。 砲の長さまで含めればそれ以上のサイズを誇る。 レーザービーム、下位安定式プラズマ砲、レールガン、コイルガンなどを備えた、 本体後部から伸びる七本のアームがメイン兵装である。 他にも球体状の本体から100門近い砲が伸びており、 地対空全方向からの攻撃に対処することが可能。 推進装置は静電気とレーザーを応用した推進装置を使い、縦横無尽に敵を迎撃する。 カラーリングは白で統一されている。
https://w.atwiki.jp/tanken/pages/123.html
TITLE レンタルWIKI #nomenubar - 2008年04月25日 (金) 15時10分52秒 無料うぃき #showrss2 うぃき運営 選択肢 投票 ある (0) ない (0) notimestamp (0) おすすめうぃき 順位 選択肢 得票数 得票率 投票 1 0 (0%) その他 投票総数 0