 
|
はてなキーワード: オープンとは
今、Twitterでは日本でだけ話題なGumroadについて。Gumroadってのは、お手軽なクレカの現金化からカジュアルな転載でのお小遣い稼ぎまでが期待できる、出来たてホヤホヤの新しいサービスです。で、今回はその悪い使い方を考えてみようかと
Gumroadの新規性…は余りないんだけど、一番の既存のシステムとの違いは「購入のURLがクローズドに近い」ってところで。所詮はオープンなWebなんで、その気になれば掘り当てることは出来るけど(購入ページのurlは確認出来た範囲で最大5桁の英字の文字列だった筈)、トップから一覧が見れるとかそういうことはないので見つかりにくい
ということで、簡単に分かるけどそもそも無断転載されたページを発見しにくい。これは転載する側からしたら非常にメリットが大きいことかと
次に、中身が分からない
サムネイルですら、関係ないものを設定出来るので、偽装さえしてしまえば「知らない人間」からしたらスルー対象にもなりやすい。中身が何か分かるのは、転売の場の買う側と、Gumroadの運営だけだ。だから、片っ端からチェックして善意の通報をしようにも、中身を確認することが出来ないのでかなりハードルが上がる
で、そもそも権利者から以外の通報は受け付けないというスタンスが明示されているんで、善意の通報ってのが成立しない。権利者に連絡して、その権利者が動ければ良いけど、ここでまた向こうは英語だったりと面倒なことになる
ということで、売る場所と対象さえしっかりと考えられたら、簡単に転載を金儲けに組み込めるんじゃないかな、とか。別にPayPalでも同じことが出来ただろ、とか言われそうだけど、売るurl自体はGumroadのものなので、よりカジュアルにそれが達成できる感じかな、と。なんならメールとかチャットとか、そういう場所でも良いんだし
転載ビジネス、として今例えば挙げられるのは2chのまとめブログとか。あれだって「お金が手に入るから」こそあそこまで必死になってやる人間がいるわけで、金が絡んだ時の人間のモチベーション舐めんな、という話ですよね
雪崩は、たった一粒の小石によって引き起こされることもある。
1月21日、ケンブリッジ大学の数学者 Timothy Gowers が、
長年に渡ってエルゼビア社の論文誌をボイコットしている理由について、ブログに書いた。
オランダに本社を置く同社は、一流誌 Cell や Lancet をはじめとする定期刊行誌を2000誌所有している。
ノーベル賞の数学版とされるフィールズ賞を受賞した Gowers 博士は、この状況を望ましくないと考え、
今回のブログ記事が他の学者もボイコットに参加するきっかけになれば、と望んでいた。
実際、それが起こった。
Gowers のブログに感化されて、数学者 Tyler Neylon がオンライン署名サイトを設置し、
そのサイトを通じて研究者2700人以上（訳注：日本語訳執筆時点では5300人以上）が署名し、
自分の研究をエルゼビアの論文誌に投稿せず、エルゼビアに投稿された論文を査読せず、エルゼビアの編集作業にも協力しない、と誓約した。
その数は、数学者の表現を借りるならば、指数的に増大している。
実効性をともなっていくとすれば、大出版社にとってこれは、革命をつきつけられたようなものである。
Gowers 博士による非難は3点に集約される。
第一点として、エルゼビアの製品の料金は高すぎるということ。
第二点として、論文誌の「抱き合わせ」が広く行われているために、図書館はある論文誌を購読しようとするとき、興味のない他の論文誌もセットで買わなければならないこと。
第三点として、公的資金による研究に対して政府がフリーアクセスを要求することを禁じる法案（たとえば米国議会で審議に入る Research Works Act など）を支持していること。
エルゼビア側によれば、これは誤解を招く言い方だと言う。
2010年には、20億ポンドの収益に対して7億2400万ポンド（11億6000万ドル）の利益を得た。利益率は36%。
しかし、同社の Director of global academic relations の Nick Fowler は、
購読料水準は業界の平均であり、ここ数年の値上げ幅は他社より低いとしている。
Fowler 博士によれば、人もうらやむエルゼビアの利益率は、同社の効率的な経営の結果以外のなにものでもないという。
Neylon 博士による動議は、より広い文脈での学者と出版社の衝突の表れのひとつと見ることができる。
その衝突は、オンライン出版の台頭によって、ますます鮮やかに描き出されてきた。
学者は情報の自由と流動性に重きを置く文化に属しており（そもそも論文の査読と編集を無償で行っており）、
出版社は情報へのアクセスに課金して利益を最大化しようとする組織であり、
同時に権威ある論文誌の（すべてではないにしろ）ほとんどを掌握しているからである。
一触即発の状況は長年続いていた。
2006年には、 エルゼビアが出版する数学論文誌 Topology の編集委員会の全員が、アクセスの囲い込みと料金高騰への懸念を表明して辞任した。
ドイツの出版社シュプリンガーによる論文誌 K-theory の編集委員会は2007年に解散した。
多くの人は、ことが荒立てられるまでにこれほど長くかかったことに驚いている。
出版社をそのサイクルから追い出すことができる環境は十分に整っていた。
実際、商業出版の代替物をつくろうとする動きは何度か起こった。
コーネル大学のウェブサイト arXiv （X はカイの音のギリシャ文字を模しており、「アーカイブ」と発音される）は1991年にできた。
研究者は、まだ論文誌で出版されていない物理学の論文をそこに投稿することができ、
Public Library of Science (PLoS) は2000年にできた。
そこでは生物学と医学の分野でフリーの論文誌が7誌出版されている。
こうした動きへの熱意があったにも関わらず、伝統的な出版社の支配が続いたことには理由がある。
arXiv の論文は、公開後に容赦ない批判にさらされることは確かなものの、投稿前に正式なピアレビューは行われない。
PLoS は一部を寄付金でまかないながらも、論文1件あたり2900ドルの掲載料を課す。
これは著者の負担となり、金策に悩む大学にとっては無視できない金額である。
少なくなりつつあるとはいえ、電子版のみの出版に対する偏見もある。
こうしたことが重要なのは、大学と個々の研究者が、出版した論文の数と掲載された論文誌の名声に応じて評価されるからだ。
ともすれば新しい道具に挑戦することが期待される若手研究者は、その前に既存の権威ある論文誌で出版しなければならない。
さもなければ、発言力もなく昇進もない。
そして、新しい論文の運命を決める力のほとんどが権威の高い論文誌にあるために、「権威」の定義は少しずつしか変わらない。
商業出版社は、たとえば読者ではなく著者から料金をとるなどといったオープンアクセスのアイデアを試そうとしている。
しかしボイコットが広まっていけば、ことは急激に進展する可能性もある。
けっきょくのところ、学者が出版社を必要としている以上に、出版社には学者が必要なのである。
突然失脚する直前まで、えてして体制側は無敵に見えるものだ。
来たる学術の春にはご用心を。
ライブドアが金払ってるらしいじゃん。
犬
アフィリエイトやってませんよね？ 正直、やりたいと思ったことないですか？
ぶっちゃけ最初はやりたいと思ってましたけど、今はやりたくないです。というかやりません。
犬
それはなぜ？ｗ
僕、人に褒められるのとか好きなんで、ｺﾒﾝﾄ欄だけで十分なんですよｗ
たまにくるメールとかｗ
犬
はいｗ
ライブドアの内情に詳しい人、おちえてー
追記 2009/10/19
Kamekiti
絶対に貼らないといけない広告じゃないのかな
それはありえない。
広告の非表示 FREE PRO ADVANCE PREMIUM 記事下広告 × ○ ○ ○ ブログサイドバーのバナー × × ○ ○ ブログ共通ヘッダーの広告 × × ○ ○ 管理ページの広告 × × ○ ○
確かに、VIPPERな俺は有料ではなくFREEブログで、強制的に広告は表示される。
しかし、
ブログサイドのバナーとはサイドバー下部の POWERED BY livedoor Blog という小さなバナーのこと。
少なくとも
(省略されました・・全てを読むにはここを押してください) をクリックしたときに
わざわざ、Ads by Google というサイドメニューを作って張るデカい広告のことではない！
っていうか、本当は id:kamekiti も気づいてるでしょ？
↓この記事いくらもらったんだろ？
VIPPERな俺 : 位置情報サービス「ロケタッチ」がオープン。色々と捗るぞ。
http://blog.livedoor.jp/news23vip/archives/2836522.html
研修を終えて、いまの営業部に配属されて３ヶ月が過ぎた。
営業現場のビジネスモデルは研修現場で学んだものとは全く関係がなく、
営業現場のルールは採用現場が唱えているグローバルとかダイバーシティとかにも全く関係がない。
他の会社にも当てはまると信じているが、修正点があれば指摘して欲しい。
社長：株主に対する責任があり、会社を守るために、数々の「言い訳」を作る。
（それが本当であっても、嘘であってもよい。）
事業部長：社長の方針に近い形で事業部方針を作り、数字目標をたてる。
（たいてい方針も数字も前年を踏まえた形で作られる。社内の部長報告や社外の重役との会食が仕事。）
部長：営業部毎に数字が与えられており、その数字の責任者となる。
（上とは調整、下には強制である。ただし、下のトラブルには部長が対処する。）
課長・係長：上の立てた方針は営業現場に適用できないので、目先の計画をたてる。
（上から「宿題」を与えられたら、それに答える。雑用は末端にどんどんやらせる。）
係長・末端：タスクがどんどん降ってくるので、残業してでも終わらせる。
（課長・係長は指示をするのを嫌がるので、末端は課長・係長の指示を予め予測する。）
つまり、現場は現場で動いており、会社全体と現場は別物、という印象である。
入社前は上述した日本企業的ルールに従う全てを「社畜」と言っていたが、
こうしたルールから逸脱した途端、会社からパージされる。ルールに従わなければ会社にいる意味がない。
知り合いは、「海外に行きたい」と言ってドメスティックな部署に配属されたり、
「上司が無能力」と言って閑散とした新設部署に配属されたりしている。
奴隷になりえない「わがままなやつ」は扱いにくいからパージする。
ただし、こうしたルールのもとで前例踏襲が横行し、社内変化がなく、景気変動に一喜一憂しているように見える。
現場は現場で動いており、会社内が縦割り、サイロ化しているようにも見える。
ここで、クエスチョン。
採用現場でいう「グローバル」や「クリエイティビティ」など含む「異色の人材」はどこで活かされるか。
学歴採用、リクルータ採用や推薦採用では「一色の人材」になってしまうため、オープン採用に変化したはずだ。
ところが、現場では「一色の人材」が求められているような気がする。
異色の人材はどこに消えたのか。あるいは、どこに生きているのか。
実際エロ小説書いてネット上にアップロードしているような女子中学生っていうのは、ロリコン男が大好きな清楚で可愛い女子中学生じゃなく
不遇な学校生活を送っているデブスキモオタ女子中学生が大半なのが現実なわけで、この記事に萌えとか興奮なんてものは期待しないで欲しいわけですけど、
そういう「残念処女の妄想」みたいなエロ小説に特徴的な要素をいくつか発見したのでご報告しておきます。
女主人公が他の男と話していて、相手役の男がそれを見聞きして嫉妬し、
「お前はオレだけのものだ！」みたいなことを言いだして、強引にセックス。この流れ、本当に多すぎます。
セックス展開に繋がらなくても、恋愛経験の少ない女の書いた恋愛小説には本当に頻繁に男の嫉妬描写がある。
もてない男ほど「ヤンデレ」が好きなのと似たようなものかもしれませんね。
自分に自信がないほど、よりしつこく・重く求められたいのでしょう。
これ、男性向け作品にはちっとも出てきませんよね。キモオタ童貞は存在すら知らないのでは？
一応説明しておくと、皮膚に吸い付くと出来る内出血のことです。首筋から胸元、太ももあたりが人気のポイント。
これが女子中学生の書いた下手糞なエロ小説には頻出するんですよねー。
相手役の男がまた「お前はオレだけのものだ！」みたいなことを言いだして、女主人公の首筋とかにつけるんです。
話はそこだけでは終わらず、翌日などに女友達に会ったりして、「あんた、首のそれ…キスマークじゃない！」と指摘され、
「えっウソっ…キャッ///」みたいになるところまでがテンプレ。
そうして女主人公と相手男がヤッてることがバレてしまうわけです。
「私は相手男と深い関係で、強い独占欲をもたれていて、超愛されているのよ」ということを周囲にひけらかす演出なのだと思います。
女主人公と相手男がエロい展開になりやすいように、なぜか周囲の人間がセッティングします。
女主人公が着替えているところに相手男が間違って入ってしまうよう騙して誘導するとか。
グループで命じられていたプール掃除当番を数人でブッチして、女主人公と相手男が二人きりで掃除するように仕組み、
終わったあとシャワー室に二人が閉じ込められるようにするとか。
そしてビショ濡れになった女主人公の透けブラに相手男が欲情して、そのまま学校でセックス、みたいな感じ。
周囲の人間が、「相手男を女主人公に欲情させるためのセッティングをする道具」のように扱われています。
相手男が「エロイベント無しでも節操無く欲情しまくっているエロキチガイ」でも嫌だし、
「エロイベントが全く起こらないから女主人公に欲情する機会も無い」というのも嫌なんでしょう。
オープンドスケベや去勢系男子はレアです。相手男は決まってムッツリスケベ。
フェミ男ってそもそも
「ボクだけはよい男だよう。ぷるぷるぷる！」っていうスライムくんでしょ。
童貞でマザコンで精神的な性欲や承認欲求を満たすためにフェミ女に寄って行って
叱ってもらったり名誉女性として認めてもらったりするたびに歓喜に打ち震えつつパンツの中に漏らしてる（ＥＤなのでフニャフニャのまま射精）みたいな例のあいつら。
（その構造を半ば以上自分からオープンにしつつやってた有村さんの鬼才ぶりは評価されるべき。他のスライムくんとは格が２つか３つは違う。）
フェミ女は本当はああいうよわっちい男は全然好きじゃないし軽く見てるけど一応恭順を示してるからボチボチ認めてはやるよ、うぜえけどな、みたいな関係性。
本心のところ、フェミ女さんたちはああいう頭とメンタルの弱い男には敵に回った上でサンドバッグになってほしいと思ってるよ。味方じゃなく。
まあそんなんじゃないフェミ男って言うのもどっかにはいるんだろうけど、ネットでフェミ女にくっついて回ってるのはスライム君タイプしかおらん。
厳密に言うとあいつらはフェミですらないと思うなあ、思想っぽいものの影で個人的な欲求を偸んでるだけで。それはフェミ女もそうだけど、満たしてる欲求がまるっきり別物。
サポート問い合わせ履歴
日付 種別 内容
2011-12-23 20:22:25 送信 プロフィール変更について
へーこどもが興味もってアクセスするのに退会できないんだわかりました通報しますた
2011-12-23 20:20:41 サポート返信 そのような結論としてお答えしているわけではございません。早急に退会をなさって下さいませ。
ログインをすると退会申請が解除となります。退会依頼をした場合はログインをなさらないようお願い致します。
2011-12-23 20:18:47 送信 プロフィール変更について
こどもですがつかっていいということで、警察さんに教えときますね。
2011-12-23 20:15:33 サポート返信 ご利用ありがとうございます。いえ、そのような結論としてお答えしているわけではございません。早急に退会をなさって下さいませ。
2011-12-23 20:14:34 送信 プロフィール変更について
ということは、こどもがつかっていいんですね？？？？？？？
2011-12-23 20:10:52 サポート返信 退会はメニューのサポート画面の下方に【退会依頼】というボタンで表示される専用フォームがございますので、そちらからお願い致します。
翌日以降のシステムメンテナンス時に一括退会処理を致しますのでそれまでにログインされない様お願い致します。一度でもログインされますと退会申請が解除されてしまいますのでご注意下さい。
2011-12-23 20:10:21 送信 プロフィール変更について
2011-12-22 08:12:02 サポート返信 只今写真の認証が完了致しました。
ご利用ありがとうございます。
2011-12-21 19:43:19 サポート返信 退会申請要らないことはございません、退会を希望される場合は退会申請をお願いいたします。
退会はメニューのサポート画面の下方に【退会依頼】というボタンで表示される専用フォームがございますので、そちらからお願い致します。
翌日以降のシステムメンテナンス時に一括退会処理を致しますのでそれまでにログインされない様お願い致します。一度でもログインされますと退会申請が解除されてしまいますのでご注意下さい。
2011-12-21 19:38:07 送信 プロフィール変更について
退会申請
要らないのに勝手に登録されたので年齢は35ではありません
日付 種別 内容
2011-12-21 19:23:49 サポート返信 ご利用ありがとうございます。
お問い合わせの件ですがこちらから重要なご案内をさせて頂く事もございますので、配信の停止は出来ない事となっております。不要な案内やメールは無視するか、削除して頂きます様お願い致します。
当番組をご利用になられない場合は退会手続きをお願い致します。
尚、お客様は年齢を35歳と記載してご利用されているのは嘘だと言うことでしょうか。
2011-12-21 19:22:23 送信 プロフィール変更について
2011-12-21 19:19:59 送信 プロフィール変更について
法律上・規約上このサイトはこどもが利用してもいいとみなしてよろしいですね？
2011-12-16 19:47:51 送信 プロフィール変更について
法律上・規約上このサイトはこどもが利用してもいいとみなしてよろしいですね？
2011-10-09 13:03:15 サポート返信 お問い合わせの件ですが、地域の変更はシステムの関係上できない仕組みとなっております。
ご了承ください。
個人情報ですが、完全に他人のと入れ替わっています。とちぎけんみんになってます。システムおかしいんですか。
2011-10-09 12:54:22 サポート返信 ただいまお申し込みの確認が取れましたのでXYZ様が優良会員となりましたら【グランドリニューアルオープン】が適用となります。
優良会員となる条件は優良会員の詳細に記載の通り、
・登録日数一年以上
上記の条件をXYZ様が満たされましたら、優良会員となり【グランドリニューアルオープン】を適用して頂けます。
宜しくお願い致します。
2011-10-09 12:52:29 送信 プロフィール変更について
今後は完全無料で利用する
2011-10-09 12:29:12 サポート返信 お問い合わせの件ですが、それではお伝えしてますように
再度合言葉をお送りくださいませ。
日付 種別 内容
2011-10-09 12:26:18 サポート返信 先ほどXYZ様からご購入の確認が取れました。ご希望の際は合言葉が必要となりますので、お送りください。
↓詳細はコチラ↓
http://jukux2.jp/t/sitemess.php?id=xxxxxx&pass=xxxx&p=0
2011-10-09 11:48:29 サポート返信 合言葉の確認が取れましたが、購入の確認が取れませんでした。
すぐにお調べ致しますので、どのような購入方法で購入されたのかを教えていただけないでしょうか?
2011-10-09 11:48:08 送信 プロフィール変更について
今後は完全無料で利用する
2011-10-09 11:41:08 サポート返信 プレミアム会員との事ですが、どちらの案内に関してで御座いますか?
僕ってプレミアム会員にとうろくされてないんですか。
もし、されてないなら登録方法を教えてください。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
1500円の壊れる釣竿がなぜ売れるか？
おまいら不思議がってたよな？
お前ら、ほんとなんも知らんでよく言ってるよな！
「情弱がかってるんだろう？」
買うわけないだろうｗｗｗｗ常識的に考えてｗｗｗｗ
ヒントは
コイン
1500円じゃなくて1500コインだ馬鹿。
え？1コイン1円じゃないかって？
そのとおりだ。
だが、それは最近の話で昔は違った。
ソーシャルゲームと言うのは、
ここまで言えば、馬鹿にもわかるだろう？
途中で変わったのだ。
これはモバゲーも同じ
それが、コインに変わったのだ
それが、いまはお金を出しても買える
これがGREEやモバゲーが広告じゃなくて課金収入といってる根拠だ！
そう、漫画読み放題のおまけに2000円キャッシュバックされるのだ！
ただ、これを現金に戻す事は出来ない。
だから、使わないと損なんだ！
ビックカメラのポイントでくだらないおっぱいマウスパッドを買ってしまったことはないか？
あれと同じ心理さ！
もう、盛大に無駄に使うのがいいだろう？
ライバルたちに差をつけて買って気持ちいい思いしたいだろ？
どうせ、入会するつもりだったサイトのおまけだぜ？
何の損もないよな！
さあ、盛大に使おう！！！
それが、ソーシャルゲームなんだ！わかったか、マジで課金してる情弱ども！
情弱はおまえらだ！
２ｃｈだけ見てて情強のつもりになってんじゃねーよ！糞が！
他にも友達を誘ったりしてもキャンペーンときなんか、1500コインとかもらえるんだぜ！
現金なんざ使わなくても遊べるんだよ！
どんどん使え！！
でも、この仕組みにも問題があるんだぜ！油断するなよ馬鹿が！
コインだけが欲しくなるんだよ！必ずな！
それでも、コインがもらえる条件をみたしたら即解約さ！
広告を出してるほうはたまんないよな！
1500コインユーザーがもらえるってことは、それより高額の現金を
これが、だいたい月額サイトだったら、月額の1.5倍くらいはらってるらしい
俺はそこまで詳しく知らないけどな！
1ヶ月で解約されたら赤字になるんだ！
しかたなく、やってるんだ！可愛そうだろ？搾取されてるのは彼らさ！
そして、このリワード広告は、すでに危機にひんしてるんだ！
次に起きる問題は、コインがあまる問題なんだよ！
コインは盛大につかわせた方がいいんだが
コインが欲しくなくなったらもう糞ソーシャルゲームに現金なんざツカワネーヨ！
だから、常にコインを消費させる射幸性をあおるのさ！
コインがなくなったら、またリワード広告にいくだろう？
でも、同じゲームばかりやってれば、いくら射幸性をあおっても、いつかは飽きられるよな
そうなれば、やっぱりリーワド広告を利用してくれなくなるよな。
それは、困るんだ。
だから、ゲーム制作会社に、すげー儲かるからどんどんゲームを出せといって
ゲームを大量につくらせてるんだ！
そういって作らせてるわけだ！わかったか馬鹿！こいつらも可愛そうなんだ！
だまされて、儲かるとそそのかされて作らされてるんだ！
ほんとに儲かってるところは何億と儲かってるからな！
最初のやつらだけが儲かる！後になればどんどん不利になるのさ！
今度はゲームが増えすぎて、ぜんぜん儲からない会社が出てきたんだ！
こんなに儲かってる人もいるから、もっと頑張れってはっぱをかけてるのさ！
正確にはコインを散財してくれないゲームが出てくる！
面白くてもダメなんだ！コインを爽快につかわせる仕組みが大事なんだぜ！
いろいろ方法論はあるが
とは言っても、ほんとのところ、何が当たるかはわかんねーから
これをかっこよく言うとオープン化って言うんだ！
絶対手放したくない！
この仕組みは、別に日本だけじゃなくて世界でもいま大流行してるんだぜ！
海外だとZyngaなんて会社がまさに同じことをやってるのさ！
まあ、これはマメだけどな！知らなくてもいい。
このリワード広告とソーシャルゲーム流れはまだしばらく続くだろうけど、
でも、あやうい仕組みなんだぜ？
商品には興味ないやつが大半になるからさ！
あと、ほんとに欲しいものやサイトの登録が全部おわったらどうなる？
つかわねーよ！もうおさらばさ！
そうして、このリワードをつかった仕組みは減少に転じる！
そうなったら、もうすべての仕組みが、破綻していく！
海外展開とか、リアル商品にコインをつける仕組みなんかもはじめてる。
まあ、本当のところ俺にもいつ頃破綻がはじまるかは分からないんだが
世の中のGREEやDeNAに対する冷たい視線を見たらわかるだろう？
こいつらは儲けすぎたのさ。
つーか、キャッシュバッグの仕組みが景品表示法にひっかかる可能性もある！
どうなるかな？
まあ、おれはとりあえず静観するよ。
この汚れきったソーシャルゲームとリワード広告の蜜月の関係がいつまで続くかをな！
あとはお前ら次第さ！
まとめ
２、リワード広告というキャッシュバックシステムでコインがもらえる
３、コインは現金に戻せないので糞みたいなゲームでも消費される
４、コインを大量消費させないとリワードが破綻する
５、ユーザーは広告よりもコインゲットに興味があるので月額サイトならすぐ解約する
覚えとけ！
この仕組みが糞ゲーを生み出し、いまのゲーム業界をつぶそうとしてる事をな！
おまいらの好きなコンシューマーゲームが、糞みたいなキャッシュバックのおまけのゲーム
に駆逐されるのを、黙って見てるのか？
わかるよな？俺らにできる抵抗は
キャッシュバックなんかにだまされるな！
あれと同じなんだよ！
世の中をよくしたいやつらは、この文章を広めてくれ！
分かったな！
頼むぜ！
自分が落ち込む時のパターンは、大抵以下の４つに分類できることが分かった
この考え方をマスターできれば、もう落ち込まない人間になれるかもしれない
↑
↑
結論：自分が好きという事前条件が成立していれば、モテなくて辛いと感じる事はない
仕事ができなくて辛い
↑
技術力が無い為に、後輩とかの役に立てないし、上司にも怒られてばかり
↑
全く役に立たない、いつも上司に怒られてばかりの人なんていない
優れていないだけで、普通
↑
確かにこれ迄の積み重ねによって優劣は付いてしまう
でもそれは積み重ねだから後悔しても仕方ない
自分にも積み重ねたものはある、それが有益なものでなくても、他人には言えないようなことでも恥じる必要はない
自分も積み重ねている、それを誇れば良い
話し下手
↑
↑
話を聞いてもらった時、認めて貰った時
↑
だから、精一杯聞いてあげればいい、それだけでも（相手は）嬉しい
人見知り、人が怖い
↑
人は誰も自分の評価を落としたくない
↑
（悪い例）
↓
（できなかったとき）
↓
↓
感情（罪悪感）
↓（無限ループ）↑
廃人的行動
対策：すべき思考の撤去
（良い例）
↓
（できなかったとき）
↓
↓
↓（無限ループ）↑
生産的行動
就活はうまくいかなかったみたいだけど、会社員やフリーター以外にも働く方法、食べてく方法はたくさんあるよ。
アイディアがあるなら起業してみるのもいいと思うけど、大学に興味があるんだったら、折角ある貯金を使って大学に行くのもいいと思う。
大学では頑張れば授業料をチャラにしてくれたり、奨学金をタダでくれたり、そういう制度もあるから、うまくいけば使った分の貯金も取り戻せるかも。
まず興味のある学部学科を調べて、そこにどんな教授がいてどんな研究をしてるのかを調べる。
オープンキャンパスとかオープンラボとかに行ってみると、雰囲気が分かっていいよ。先生とか学生さんにどんどん質問できるといいね。
それで、人柄とか研究分野で興味を持てる教授がいる大学に行くといい。
普通の大学生が研究や学問に興味を持ち始めるのは、だいたい研究室配属のある３年か４年になってからなんだけど、１年の時から興味を持ってまじめに勉強してれば、先生にも目にかけて貰えるし、早い段階から研究をやらせてくれるところもある。
理系なんかだと、研究に必要な設備が高価だから、自分独りじゃできないようなことも、研究室の設備を使ってできるから楽しいよ。
研究と言っても、試験管で薬品を調合したりするいわゆるハカセがやってるみたいなことから、調べ物とか、計算とか、ものを作ることとか、ものを評論することとか、とにかくいろんな分野があるから、何かしら興味を持てるものがあるんじゃないかな。勉強好きだったら特に。
研究者は学会で発表しなきゃいけないから、自分の意見をしっかり持たなきゃいけないだとか、論理的に考えられなきゃいけないだとか、そういうのはあるけど、人付き合いは、研究のことだけ喋ってればいいから、研究職には結構人付き合いが苦手な人は多い。
らくなみちではないけど、フリーターだってらくじゃないから、そういう道を選択肢に入れてもいいと思う。
もちろん卒業して会社に勤めてもいいし、学生ベンチャーとか初めてもいいし、NPOでもいいし、青年海外協力隊とか行ってもいいし、公務員になってもいいし、未来は可能性に満ちあふれているよ。
上っ面じゃなくてちゃんとわかっている人教えてください。
▼モバイル版「Flash Player」の開発中止をどう見る？
http://japan.cnet.com/panel/35010348/300015677/
▼Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
http://jp.techcrunch.com/archives/20111109why-adobe-failed/
今後来るhtml5をもてはやす必要もなく、
で“既に代替されている”
html5厨の中にはこのあたりごっちゃにして歓迎してるやつが多数いる
くどいけど、その他の機能はjsとかcssとかhtml5周辺の独自仕様で
解決してることが多いからな！
普通にhtml5が覇権取るにはオーサリングツールがいるんだぞ。
全部含んでるんだ。
html5が現状見えてるのは、
までだ。
「描画系の機能でflash(flex sdk)同等の仕様を用意することになるだろう」
ってだけじゃ劣化flashすぎんだろ。
あとadobe終わったっていってるやつ、
それを一社じゃなくブラウザつくってる各社が実装するんだからな・・・
お前らがflash嫌ってるのと同じ問題が発生して、
flash殺すのはいいけど、html5を中心とした代替環境できんのに何年かかるんだよ。
あと、リッチインターフェース作るのに、いつまでもなんのサポートも受けれないような
jsライブラリ組み合わせて、必死にカスタマイズとデバッグしなきゃいけないのかよ！
業務系のuxデザインつくっていくのに、flex使おうか、html&css中心で行こうか悩んでんだ。
誰か何かアドバイスくれよ…
flexは良いところが多くて工数も減るし、どこかでadobeの5オーサリングツールに乗り換えられるだろうから
普通のweb屋としては、htmlとjsで苦戦しながらも自己責任でスクリプトチマチマいじってる方が、
他にもこの中途半端な状況に困ってる奴いるだろ！
予期せぬ不具合やアクセス集中による影響を考慮してネット系サービスではよく「クローズドベータ」なんて始まり方をする事が多いんだが、全く愚行極まっている。
新サービスをリリースした瞬間は各ニュースサイトでも頻繁に取り上げられて一瞬で初期ユーザー層を固められる最初で最後の機会だ。
そしてちょっと前から始まった「はてなブログ」とやらである。案の定クローズドベータ。
ベータ板出すのがカッコいいなんて時代は2007年に終わってる。
クローズドベータ板出して初期少量のユーザーに不具合を修正してもらうなんてやり方は仮にも大きな志を持ったネット企業のやる事じゃないよ。
そんなものは社内で煮詰めて、最初からユーザーの参加についてはオープンにするべきだ。SNSじゃないんだから。
また冒頭でも述べたように、広告効果の毀損をどう考えているのか。
もったいないぞ。サービス作っただけでわんさかニュースに取り上げられる立場にいることをもっと有効に使うべきだ。
なーんか実効性が薄い（これでも婉曲表現）話ばっかりする人や
何かを罰しよう罰しようというムードで話をする人
こういう人が現れて、
なんだろうと思って少し経過を見たり掘り下げて行ったりすると結局
ご本人がセクマイさんでこれまでの辛い体験が未解決だとか
思春期にお父さんとどうこうがあった人でトラウマがわーわーとか
そういう個人的な話にぶち当たる。
いやそこは、尊重はしたいけども。
現実の案件に破綻気味の論理やオープンリーチな感情で参加してきて
ドラマとかだったら犯人の思い掛けない同情すべき過去が開陳されて
「そうだったのか…」と一同立ち尽くしたりするけど
現実の案件ではあなたはその話題の中心でも犯人でもないんですから。
そういう話を混ぜたいならせめて
参考意見として冷静に添えられるぐらいに傷が癒えてからにしてよ。
お大事にしてほしい。
※ここで言う「ガキ」とは，成年になっても思考が「ガキ」である者も含める
犯罪自慢に限らず，Twitterでなんでも『自慢』する人がいるが，
いざそのツイートがRTされたり引用されたりすると途端に焦って削除する馬鹿が相次いでいる．
お前のその自慢話は，誰に向けて呟いたものなのだ．
Twitterは世界を股に架けているオープンコミュニティだ．
世界中の不特定多数の人物から覗かれる場で，拡散させて欲しくない情報は控えるべきだ．
何故、Twitterでやる必要があるのか．単に流行に乗っているだけだとしたら，それは過ちだ．
ブログやSNSなど，他に代用できるテキストサイトは幾らでもあるだろう．
社会経験，あるいはブログ経験の無い者が，いきなりTwitterを触るのは危険である．
経験を持つ者は，迂闊なツイートを行わない．ネット社会の目を知っているからなのだ．
特に社会人の場合は，社内の人間が偶然目にすることもある．有り得ないと思われる偶然も，起こることは起こるのだ．
ある意味そうかもねｗ
男が全般的に性欲か見栄で女連れてるとまでは思わないけど、あの人はたぶん見栄で女連れたいんだなーって思うもん。
だって女の品定めですよ？ｗ しかもＡＫＢとかミスコンじゃなくて（それでも正直ちょっとどうかと思うが）語学のクラスメートとかだよ。
それも「○○ってどうなの？彼氏いんの？」みたいな好きな子に対する探りとかじゃなくて、「○○ってぜってー彼氏いねーよなーだって体型がアレだし」的なイラつくDisだよ。
楽しいわけないっしょそんな話題が。いるよあの子彼氏、っつっても聞く耳もたないし。
ここまで書いてふと気がついた。
要するに反論しなさそうな人間だと思われたんかなこれは。
身勝手な欲望を撒き散らしてもそれを肯定したっぽくみせかけられる相手だと。
あとそういえば本題はそのカス野郎が如何にカスかという話じゃなくて、欲望したいくせにされるのはイヤだというのはどうかと思うんですけどどうですかって話なので。
ARGについて昨夜ひともりあがりあったので書いとこう。
(問題≠謎として見てください)
SCRAPのリアル脱出ゲームをはじめ、短期のイベントとして成立しているものについては
・「スタート」がはっきりしている
・何をすべきかが結構提示されている（解答用紙が渡されたり、ここの部屋の中でヒントをさがしてくださいといわれたり）
のほかに、
・スタート時がみんな一斉に横並び
だということ。
つまり、みんなが最初にとりかかるものが「全体に対しての第一問」なわけで。
みんなそのイベントに限っては「イベント内での知識」が同じ状態からはじめられる。
そして、導入部分の解決すべき問題というのは、得てして難易度が低かったりするもので。
だけれど、長期のARGにおいては、時間の進行が不可逆である限り、
全員が開始時からとりかかることができるとは限らない。
そのため、途中から入ったユーザが最初に直面する問題が、とても難解な
しかもこれまでの情報から推測したりすることが必要なものとなる可能性は結構高い。
（詰まる箇所って「○○で集まれ」など物理的にすぐには動きづらいもの以外では、非常に難易度高い問題の場合が多数だと思うので）
そこで初めて訪れたユーザは「意味がわからない」「入りづらい」という印象を持ち易くなる。
となると、コアユーザがFAQやまとめ、途中参入のユーザからの質問に逐一答えるべきか？
コアユーザがオープンな空気にしていくことを心がけるのとともに、新しく入るユーザも
教えてもらったらお礼を言う、過去の質問内容を読む。など、基本的なことは行わないといけないと思う。
とはいえ、そもそもARGとはなんぞ？という層に対して、「そんな基本的なことから質問するな」というような投げかけをしても
ROMってろ。というのは、確かに読んでいると参考になることもあるんだが排他的にも感じ、
ARG自体にそこまで魅力を感じていない層の人は確実に「ARGに関わる人＝怖い、内輪で固まってキモい」という
印象を持つだろう。
まずは経験だよ経験。といわれても、「常連さんの邪魔になる」「自分みたいな初心者が・・・」等
発言もしづらいだろう。
的外れな発言したら「それ、もう終わったから」「関係ないよそれ」とか立て板に水的な感じでパシーンと文字で言われちゃうんだよ。
初めての人からしたら怖いっしょ。
http://d.hatena.ne.jp/aureliano/20111019/1318990671
ハックルさんにはフーリッシュさは十分に足りていると思うがハングリーさがが足りない。
ハックルさんの本は、「ハックルさん自身の本としては」駄作ばかりだと思うけど
（ハックル成分が不足しているという意味で。社会的な意味や純粋な小説としての評価とは別に考えています）
記事はいつも面白いと思うのでぜひぜひはてなスターをオープンにしていただきたいと思います。
毎回１００ポイントくらいのカラースターは進呈させて頂きますよ。
あなたを批判するバカのコメントにたくさんのカラースターがつき、
そのスターの収益はハックルさんの下に届けられるという収益倍増を実現することができるでしょう。
今のように、はてブの批判コメントにカラースターが付けられている現状は非常にもったいないです。
著作についても次回作はもっとハックル成分をたっぷりと塗りたくって
「本の内容に文句がある人は専用のサイトから言えます。年会費１００００円です」とやるべき。
一応マジレスしておくと、多分ジョブズレベルのハングリーはただ腹ペコだったら良いというものではない。
自分のホッしているところが相手に正しく伝わってないと貴方が思っているなら、それはハングリーとは程遠いのだと思いますよ。
ジョブズと比較するなら、マーケティングのはなしをするより、もっと本気でハングリーとは何かって考えたらいかがですか？