  |
はてなキーワード: おKとは
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
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に)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
寝付けない夜、どこからともなくやってくる嫌な記憶。一度思い出すと関連する記憶が永遠と湧き出てきて、もう寝付けない。お前らも体験したことあるよな。俺もこれに苦戦してて、色々な対処法を試してきた。その中でマシな方法を見つけたから、紹介する。即効性があるし、かなり手軽だから、とりあえずやってみ。
結論から言うぞ。海馬を鍛えるんだ。海馬っていうのは記憶を司る部分ってのはぽまえらも知ってる通り。そこが働くと、記憶をコントロールできるらしい。逆にストレスが溜まると、海馬が萎縮する。PCで例えるとメインメモリってやつ。そこが小さいと、１つのことだけにとらわれてネガティブにネガティブになっちまう。逆にそこが大きいと、おおらかに考えられるようになるらしい。by Google
まぁいくら理論がご立派でも、効果を実感できなきゃどうしようもないよな。さっそく実践に移ろう。
方法を言うぞ。「脳トレ」をするんだ。その中でも「記憶系」のやつ。フラッシュゲームとかでもあるけど、今回は寝てる時にもできる海馬トレーニングを紹介する。２つあるから、好きな方をやってみてくれ。
１、多重しりとり
頭の中でしりとりをする。このとき、２つ前の単語も思い出す。例えば、「しりとり」「りんご」ってやるよな。次に「ゴリラ」って言う前に、「しりとり」「りんご」を思い出す。そして「ごりら」。 次は「りんご」「ごりら」「ラッパ」とか。『なんだ簡単じゃんww』と思ったそこのぽまえ。意外と難しいぞ。やる回数や、即出単語とかもあんまり気にしなくていい。適当に疲れたらやめる。
２、除算乗算チェーン
暗算だ。かけ算と割り算を交互にやっていく。例えば
100/7=14
14*8=96
96/6=...
こんな感じだな。あまりは気にしないし、忘れたら適当な数字からはじめる。これも無理しすぎず、疲れたらやめる。やりずらいなら足し算やら引き算やらに切り替えてもおk。
どちらの方法も単語や数字で頭が一杯になる感覚が大事。はじめは脳が疲れて嫌なことを思い出さなくなる。だがしばらくやると脳が広くなった感覚（こうとしか言いようがない）がになって嫌なことは思い出すんだが、なんだかすぐ頭から消えるようになる。客観的に考えられるようになるっていうか・・・説明しづらいが、嫌なことをいつまでも考えなくなることは保証する。
やってみてダメだったらどうぞ叩いてくれ。だが、もし効果があったなら、同じことで悩んでる奴らに、この方法を教えてやってくれ。
MikuMikuPenguinというMikuMikuDanceのクローンソフト？ があるらしい
MMDはソースコードは公開されてないが、MMPはオープンソースらしい。で、開発者はアメリカ人。
詳しくはググって欲しいんだが、私はこれに関してなんか妙な違和感を覚えてる。とくにいわゆるMMDerの反応に。
あ、ちなみに私はMMDerじゃないけどMMDの動画を見るのは好きだし、第12回MMD杯はすげー楽しみにしてる、OSSにもちょっと関わりのある人間なんで、そういう目線で書くことになるかも？ わかんない。
何が違和感を覚えるかって、うまく言えないんやけど、「お前はお前でMMDを自由にしてあげたいんやな？ おk。俺はお前のやり方は気に食わないが、まあ文句は言わん。俺の迷惑にならん程度にやればええ。俺もお前の迷惑にならん程度に動画作るから」って感じで、俺は俺、お前はお前って感じで、さくっと割り切れないのかなぁって。まあ私もこういうの書いてる時点で割り切れてないけど。けど、なんやろ、やりすぎなんじゃないかなって、思うんだよね。MMPのニコニコ大百科見ててそう思った。
たしかに、「自由にしてあげる」って言い方は気に食わないのはわかる。自由ってめんどいし、場合によっては危ない。モデルを勝手に配布されちゃった経緯もあって、警戒するのはわかる。
けどこれって、モデルを配布するとかやなくて、単にアプリケーション作るだけでしょ？
オープンソースだからいやなの？ だったらMMDAIはどうなるの？
それともGPLが嫌い？ 嫌いなら使わなければいいじゃん。もう使いやすいMMDクローンソフトは存在してる。MikuMikuMovingとか。
それとも、作者の言い分が嫌い？ まあ、動画とか小説とかその辺って、作者の人格とその人の作品は分けて考えんと辛いよね。。。
私は両方好きだからさ。MMDを取り巻くあれこれも、OSSの考え方の一部も。
だから、なんかうまく丸くまとまらんかなぁって、そう思っちゃう。
いちいち新しいものをボコボコにしてたら、育つものも育たない、第二第三の樋口Mさんみたいなプログラマは育たないんじゃないかなって、そう思っちゃうのでした。
認めるのも自由、認めたくないのも自由。けどなんか、もっと仲良くするなり放っておくなりして、上手く回せたらもっと楽しいんじゃないかなって。辛い思いしてMMDやオープンソースの世界から去る人が減れば、なんか幸せな気がしてる。
そうだよ。
なのに元増田のスタンスは「幸せな結婚を目指すにはどうしたらいいのか？むずかしいよね」という感じだから「そんなもんはそもそも不可能なんだよ」という話をしただけだよ。
そもそも多くの人が地獄を背負い込んでくれないと困るシステムなのに、「自由に生きる道もありますよ」なんてオプションが出てきちゃったんだから絶対破綻する。
この構造がシンプルすぎるので、どんなに細かい理屈をこねても絶対に覆せない流れになってると思う。
という感じか。
俺も坊主だけど、
ただ、何で坊主なの？みたいな話は、前職だとよく聞かれたね。
上長から一年目で坊主で世間的には生意気みたいに思われるから気をつけた方がいいよ、みたいな涼しげな顔して忠告された時は、
絶対お前が思ってんだろうとうざかったな。
それもあって、会社移って、今は私服だし、自由だし、色々職場は快適だわ。なにより俺以外にも坊主いるし!!
世間的には、みたいな考えは正直好きではないけど、働いていたら企業風土みたいなのは免れないし、
お客さんによっては髪型でNGとかわけわからない人って絶対いるから。
要するに、TPO的に坊主もおkな楽園的職場を探した方がいいんじゃないかな。職業にもよるけど。
http://anond.hatelabo.jp/20130520191133
元増田です。
筋トレして体鍛えて、
合コンに行こうかな。
キモい、長い
夜書いた文章を朝読み返すと
「なんじゃこりゃああ～～、キモッww」とかなって
お手軽に黒歴史体験が出来るけど
正しくそんな感じw
キモいって言われてんのは主に
ダメだったんだろうなww
あと草が沢山生えてたり、オタクっぽいところかww
とても冷静ではいられないほど
後半にそれが書いてあるから
読後感がキモい一色なんだろうww
こりゃあ叩かれるww
こっちの方がしっくりくる。)
これはサクラでしょ
実際に会う日程を予約できない。相手は本人確認してた。
定額で引き伸ばすのならば、何故話を引き伸ばさずに出会おうとする?
しかもブッちされちゃったりしたら、その人高確率で辞めちゃうので目的と反するのでは。
本人確認とか安全性をウリにしているのに
インセンティブはないのでは。
この状況でさくらって考える根拠が
定額制の有料サービスにして
相手の人柄を判断する際に重要となるのが
メッセージを送って、気に入れば実際に会いましょう
見事カップルが成立すると
うおお、きめえーーーーwwww
おまえが断られたのは身長じゃない、服装や声だ
そういう風に言っている奴は多分俺と同じかそれ以下の身長だから
他に起因させたいんだろうな。
どう当たってる?
あと同じ理屈で
外面でジャッジされたことを認めたくないんだろ。
何故ならば書いてる本人は
ぶっちゃけ服装でも声でも雰囲気でも何でもいい。そこは論点じゃない。
そういうのを引っ括めた性的魅力の欠如で
俺は足切りにあったということ。
メールは続いてたし、
内面は現時点では及第点だったんだろうと思う。
電話とかして探り入れてくるはず。
シークレットブーツ履いていけ
例えそれで上手く行っても脱いだら終わりじゃね?
バレた時印象悪いし。本質的な解決策じゃないよね。
俺は真面目に付き合いたいだけで、
ヤリ目じゃねえだよ。
というのは冗談で
例え本当に迷ったとしても
何とかしようとする意志があれば何とかなったはずです。
相手は悪態ついたり、着信拒否したりしていて悪意があり
何とかしようとする意志を微塵も感じませんでした。
(でも後で連絡はしてよねww)
写真を交換しておけ
写真なしでやりとりが始まったので
ここで交換して止まったら嫌だなと思って
ペンディングしてたのです。
その結果がこのざまですwww
それは相手が悪態ついて、会おうとする意志を感じなかった末です。
最初は向こうのターンで攻撃してきた
俺のターンだったわけじゃねえ。
すいません、書き方間違ってた。下落率です。
http://info.finance.yahoo.co.jp/ranking/?kd=2&tm=d&mk=1
20分ほどでガチしょんぼり沈殿丸(featuring 激おこぷんぷん丸)状態に
叩き落とされたわけですよ。
何か規制されてて上手くスレ立てられんかったww 立て方がわからんww
産む前より産んだあと（子育て）の方がもっとめんどくさくて長期間に渡る作業だと思うが……
自分はアーヴの繁殖方法がいいなぁ。気に入った適当な相手と遺伝子を掛け合わせて好きなだけ調整して人工子宮に突っ込み、、健康で才能あふれるイケメンおよび美女の遺伝子を持った子供を、衣食住全部自動でやってくれる（親は愛情と躾と教育だけ与えてれば済む）育児室みたいなので育てればおkってやつ。
アーヴの子は「自分の子を作りたいと申告した方」に親権が与えられるので、グダグダ子供の取り合いでもめる心配もないし、世の中の人間全員が遺伝子操作で優秀なのしか産まれなくなれば「私は優秀だ、お前は劣ってる」なんて格付けをして自尊心を満たし合うようなくだらないことも起きなくなるだろうし、ホントあの世界うらやましい。
無粋な全レスをしてみようと思う。
そうこだわらずにそこそこの味のものを食べたいだけなら割とコスパいいと思うよ。
こったもの作ろうとしたり、極端に賞味期限を重視したりすると値段跳ね上がるけど。
調理時間や後片付けに発生する手間、時間などのコストを無視するべきではない
→同意する。ただし、個人的には残業するより自炊してたほうが楽しいのでそうする。趣味の範囲
一人暮らしは忙しくて料理する時間が限られており、特に深夜は料理の音も外に響いてうるさい
また、他人から急に外食に誘われた場合、食べる予定だった食品を腐らせるリスクがある
一人暮らしの部屋に調理器具をたくさん買っても置くスペースが存在しない
一人暮らしの部屋は台所が有り得ない程に狭くコンロが1個しか設置してないとか普通にあるので不便
→まな板置くスペースだけどうしても狭いけど、他は慣れる。
2口コンロ欲しい時もあるけど、あっても洗い物面倒だしたまにしか使わないと思う
一人暮らしの部屋で料理すると部屋が非常に狭いので換気扇をつけても料理の匂いが部屋全体に充満しやすい
→正直、ワンルームだとやめといたほうがいいと思う。1K～ならまぁそこまで気にならん。
大抵のレシピは家庭向けで一人分の量が書いてないので計算するのが面倒くさい
→いちいちレシピなんか見ないでおk。ノリと勢いと雰囲気が大事
大抵のレシピの料理は一人分の少ない量で作るにはあまりにコスパが悪すぎて絶望する
→炒めもの系は一人分作ったほうがおいしい。煮物は2,3日分作って食べ続ける。
一人暮らしだと、長期保存できない食べ物（生鮮食料品など）は量が多く賞味期限内に食べきれない場合が多い
あと、にくかったら同じ肉を味付け変えて2,3日食べ続ければ消費しきれないってことはないはず
安く抑えるために2,3人分の量を作り、残りを冷凍保存するとしても、一人用冷蔵庫では狭くて多くは入らない
→5人分作って5日同じもん食べればおｋ。
これは私がずぼらなだけだけど、一度冷凍すると忘れるから、あまり冷凍保存はしない
最近よく見かける一人分にカットされた野菜果物などはグラム単価が高い
卵、肉、調味料等も小分けにされているものほど製造コストが高くなるので当然グラム単価が高い
一人暮らしで期限内に確実に消費できる量を買おうとするとどうしても相対的に高くなってしまう
→普通のかって何日かかけて食べれば良いと思う
面白くないよね？と思って検索したら、駄作だとかクソだとかつまらんという意見もあったけど、
感動したとか泣いたとかいう意見の方のほうがたくさんある気がして、ドギマギ。
おおかみおとことのセックス、これは別にいいかな。おおかみの舌でベロベロしたほうが気持ちよさそうじゃん。
おおかみチンコにあうコンドームがないのか、知識がないのか、本能のおもむくままなんだろうな。
で、自室で産んで、またすぐ妊娠。
え？まじで避妊知らないの？と思ったけど、やったーハッピーみたいな感じだったからおkなんだな。
奨学金とバイトで大学行くくらいだから、わたしもっと勉強したいのとかはなかったんかな？
父おおかみがあっさり死んで、あっさり処理されて、
みんなもっと「うわっおおかみじゃん！」っつーのは、ないんだね。
都会では暮らしにくくなって山奥に移住して、しばらく貯金でやりくりって結構ため込んでたんだな、やるな。
あのあばら家があそこまで人が住めるようになるには、全部自分でやったとしてもお金かかると思うんです。
弟、川に流されたけど「どうせ死なないんだろ」とボワーっとした気持ちで、そのシーンをながめてた。
まだ思ったことあったけど、いいや。
中国にとってアメリカはいいお客様だし、アメリカにとってもそう。
日本人1億3千万を相手に商売するより、中国人13億人の上位2割の2億6千万人と商売したほうが美味しいんじゃね？
と考えたりも時々してる。
そういう意味で、調子こいてるからしめてやるかっていう感じだった第二次世界大戦の時とも、イラク戦争のときともちょっと違う。
なにしろ、原潜+核の合わせ技は凶悪。
本土が焦土にされても、確実に報復できる。ある意味で負けはない。
で、日本に住んでると理解できないが、その「ある意味」とやらにやたらこだわる。
で、こんな感じなんじゃね？
中国「すまん、やりすぎたわ。許して。」
アメリカ「てめぇ、人民元切り上げろやコラ、そんなわけでアメリカ製品買え(#ﾟДﾟ)ｺﾞﾙｧ!!」
アメリカ「代わりにってなんだよおい。テメエの領海を増やさせるわけにゃいかねえよ」
アメリカ「あ？ま、そんくらい認めてやんよ。おい日本、そういうことだから、尖閣はお前のだけど地下資源は折半ってことでハンコ押せ」
日本「そりゃ困りますよ。ちょっと、勘弁してくんないっすかね(´Д` )」
台湾・ベトナム・フィリピン「ガンバレ日本！領海侵犯を許すな」
アメリカ「何回も言わせるな」
ロシア「可哀想に可哀想に。助けてやろうか？それから、北方領土だったら相場の10倍ほど出せば売ってやってもいいよ（・∀・）ﾆﾔﾆﾔ」
EU＆イギリス「ロシアにつけあがらせるなよ。ロシアは叩き続けないとダメなんだって。死んでも言うことを聞くな」
世界「え？」
（この記事を書いているうちに元まとめが消えた…）
あくまでそれは｢今後のコミックマーケットへの参加におかれましては｣と言っているように、｢今度参加する時は今回みたいに、法人JANコードを付けて応募しないでね｣というお願いにすぎないように取れる
これで合ってると思う。もっと言うと、「JANコード自体、紛らわしいからできればつけないでね」かな。
「JANコードついてるんだけど…しかも法人の… てかJANって商業流通で使うものだからいらなくね？」
↓
「あーゴメンゴメンJAN個人のにしといたよ！いいでしょ？」
↓
「あー個人のになってるね…うーんまあいっか…でも次から、JANコード自体、紛らわしいからできればつけないでね」
と読めた。
だが、コミケで売った商品のその後の処遇については何も触れていない
あくまで法人発行の商品を売ってはならないと言っているだけで、コミケで売った後に法人で売ってはならないとは言っていない
俺は手元に｢参加申込セット｣を持っていないので確認のしようがないが
これに関しても合ってると思う。というか、コミケで売った後に法人で売ってはならないのであれば、ほとんどの同人誌（とらやめろんでの委託）がNGになると思うから。
最初の問題点としてあげられたJANに関しては、上記で手打ちになっているはず。
ただ、コミケ側の言い分（今後はできれば～）と、うしじま側の認識（個人JANならOK）がちょっと食い違っているかと。
https://twitter.com/gtk/status/246233145089859584
「同人として売ったものと同一パッケで、”当該法人を経由して”書店等に卸した」
が問題だといっているが（これ以外の疑問点に関しては解決済みかと）、うしじまの主張は、
個人→法人（書店）だろうが、個人→法人→法人（書店）だろうが、変わらないのじゃないか？ってことだよな？
@gtk氏の言うように、二次卸的なものになると「同人じゃない」と見なされるのか否か。
話を広げてしまって申し訳ないが、例えば参考までに、東方の言う商業流通（http://kourindou.exblog.jp/14218252/）
はこの認識？
商業流通とは「とらのあな」や「メロンブックス」などの同人作品専門店等や、一般的な同人販売方法を除く流通方法のことを指す。例えばコンビニや家電量販店、海外向けのダウンロード販売等はダメ。
初見。
（20年くらい前に、ロケットマン？同じような趣向の映画がなかったかな。 すごく好きだった！）
（追記）
