  |
はてなキーワード: Modelとは
ありがとうございます。読んでみます。
何をやっているかは把握できたし、そこに書く理由もそれなりに分かっていたのです。
まさにレールに乗ってる感じ。
今の案件、Controllerに英数字の画面IDを定数で渡してViewを指定し、
画面IDと同名のファイル名のviewをviewsフォルダに作り、
ロジックはServiceに書いている。
DBアクセスはmodelフォルダ内にdaoってフォルダ作ってそこにソース置いてる。
JSのincludeはもうどこでやっているのかわ分からない。
他をまねて書いたら勝手にheader部にincludeされてる。普通にviewに書いちゃダメなのか。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
http://elm-lang.org/examples/time
view : Model -> Html Msg view model = let angle = turns (Time.inMinutes model) handX = toString (50 + 40 * cos angle) handY = toString (50 + 40 * sin angle) in svg [ viewBox "0 0 100 100", width "300px" ] [ circle [ cx "50", cy "50", r "45", fill "#0B79CE" ] [] , line [ x1 "50", y1 "50", x2 handX, y2 handY, stroke "#023963" ] [] ]
HaskellのライブラリもElmのような言語も、サンプルもJavaScript実装も
https://en.wikipedia.org/wiki/Functional_reactive_programming#Implementations
いや、おかしいでしょ。なんでPlaceが流通になるの。なんとか頭文字を合わせようとしただけじゃないの。
で、さらに顧客志向のマーケティングミックスとして後に生まれたのが4C。
サービスのマーケティングミックスでは4Pに3つのPが加えられ、7Pになる。
Physical Evidenceが分かりにくすぎる。2単語になってるし。
さらに共生マーケティングにおける4Cは上記の4Cとは違うとか、共生マーケティングの分野には7Cs COMPASS MODELなるものもあるとか。
7Cs COMPASS MODELが何を言ってるか分かる人います？
無理やりかっこよく頭文字を合わせてなんの得があるというのか。
はてなブックマーク - ノーベル賞受賞の梶田隆章教授、NEWS小山慶一郎に「意味が分からない」 - ライブドアニュース
において「ニュートリノ振動は役に立つのか？」が話題になっていました。
以下に個人的な考えを述べます。できる限り誠実に書いてみます。
まずはニュートリノ振動がノーベル賞を受賞した理由を振り返ってみましょう。
研究者達は世界の全てを記述する究極理論を目指しています。その理論においては自然界における４つの力、重力、電磁気力（電場＋磁場）、強い力、弱い力を統一されているはずだと考えられています。
1970年代に電磁気力と弱い相互作用の統一まで完成し、現在では強い相互作用を記述する量子色力学とあわせて標準理論と呼ばれています。そしてこの後、人類は長い停滞期を迎えました。標準理論は実験と合いすぎたのです。
人類はこれまで実験により理論の破れを見つけ、それをヒントにして次の理論を作り上げてきました。マイケルソンモーリーの実験は相対論に、光電効果の実験は量子力学へと繋がりました。標準理論を超えて大統一理論に進むには理論の破れを見つける事が不可欠なのですが、長い間それを見つける事ができませんでした。こんな中で唯一見つかった標準理論の破れ目がニュートリノ振動だったのです。現在私たちの手にする数少ない、 beyond the standard model へ繋がる鍵と呼べるでしょう。
以上より「ニュートリノ振動は何の役に立つのか」は「大統一理論は何の役に立つのか」に言い換える事が出来るでしょう。
しかし残念ながら大統一理論は（候補は日々研究されているものの）まだ完成もしていません。これはちょっと早すぎる質問でしょう。その前にまずは現在の素粒子理論——標準理論は役に立つのか？ を考えてみることにしましょう。
実をいうと僕は素粒子理論は実社会には全く役に立たないのではないかと思っていました。
ところが癌医療への応用や火山研究への応用、加速器の副産物といえる放射光を利用した品種改良や材料開発といった産業利用が次々と成されるのを見て心の中でジャンピング土下座をしました。
いや、僕が「素粒子は役に立たない」と考えたのは単に僕に才能がなかっただけであって、世の中には僕の思いもよらない利用法を考えつくすごい人達がたくさんいるのだと思い知らされました。
ここでようやく表題に戻るのですが、「ニュートリノ振動は役に立つのか？」「大統一理論が完成したとしてそれは役に立つのか？」といった質問に僕なりに誠実に答えてみると以下のようになります。
「正直に言うと僕には役に立つようには思えないし、どう使われるかも全く想像つきません。そして役に立たないと言い切る自信もありません。」
「ただ、これまでの歴史を振り返ると誰かが利用法を考えるかもしれません。世の中には凄い人たちがたくさんいるのですから」
これだけだと誠実じゃないと思ったので追記します。
仮に大統一理論が完成したとしてもお金にはなりません。理論や定理を使う上で特許料は発生しないからです。研究成果は世界に公開されます。
My girlfriend left me
What plays a invaluable role for our study
What plays an invaluable role in our study
a large number of the descriptions
numerous descriptions
me and her
her and me
the way how
how
卒業研究がまるでうまく言ってなくて来週提出の卒論アブストが全く書けない現実逃避に。
I was rejected by my best girl nine months ago. It has been unclear the reason why they broke up despite the each other's intense love. In this thesis, we provide a clear explanation about the event.
What plays a invaluable role for our study is descriptions gathered from me about each incident that had happened along them. We were able to obtain a large number of the descriptions, since a winter chill in the air reminded me the divine memories of the days with her. We carefully examined each of them and arranged the incidents into some categories. By combing chronological order and categories of the incidents, we analyzed the emotional changes of me and her.
We propose a simple model that explain the breakup between them, based on the above mentioned analysis. From discussions about the model with some people, the model is considered to be capturing major matters. We also present our attempt to match the model to the existing collection of patterns of the way how once loved people would break up. Even though this attempt is not much succeeded, at least it reveals that what I experienced was quite ordinal breakup.
私は九ヶ月前に恋人から別れを告げられた．互いに強く想いあっていたにも関わらず彼らが別れることとなった理由は，不明瞭であった．本論文において，我々はこの出来事についての明瞭な解釈を提示する．
我々の研究にとって非常に重要な役割を果たしたのは，彼らに起こった事象に関する多くの私から収集された叙述である．冬の寒さが私に彼女と過ごしたかけがえのない日々を思い出させたおかげで，我々は多くの叙述を得ることができた．我々はそれらの一つ一つを注意深く調べて，幾つかの分類へと整理した．各事象についての時系列順と分類を組み合わせることで，我々は私と彼女の感情的な移り変わりを分析した．
この分析に基いて，我々は彼らの別れを解釈する単純なモデルを提案する．本モデルについて幾人かと行った議論から，本モデルは重要な問題を捉えていると考えられる．さらに，かつて愛し合った人々がどのようにして別れるかのパターンを集めた既存研究と，本モデルを照らし合わせる試みを示す．この試みは十分に成功してはいないものの，少なくとも私が経験したことがありきたりな別れであったことを明らかにしている．
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
表現の自由をどうこう言って反発するのもいいが、
私の意見としては子供が見てトラウマになるような映像は教育に”良い”影響があると思うから規制には反対だ。
悪夢にうなされたり、エロすぎて目に焼き付いて取れなくなる経験は大人になるために絶対必要である。
殴られもぜずに大人になった奴がどこにいるのか！
さて、なぜこのような暴論が幅を利かせているのか。
もしかしたら、この問題を扱う新しい切り口を見つけたかもしれないので報告する。
アニメなどの表現にはある程度の規制は必要だが、今のままで十分である。
にも関わらず、なぜ暴力的とも言える過剰な表現規制を唱える人が出るのか。
それは、人間の心理の持つ”慣れ”という性質にから来るのではないか。
人間は同じ刺激を受け続けると、徐々に慣れて何も感じなくなる。
より詳しくは以下の文献を参考にされたし。
Thompson, Richard; Spencer, William (1966). "Habituation: a model phenomenon for the study of neuronal substrates of behavior". Psychological Review. No.1 73: 16–43.
http://www.cns.nyu.edu/~david/courses/perceptionGrad/Readings/ThompsonSpencer-PsychRev1966.pdf
アニメの表現規制を唱える人々は、馴化によって現状でも十分表現は規制されているという認識を持てないでいるのではないか？
おそらく、昨今のアニメ表現規制を推進したい人々は、過去にも同じように何らかの表現規制の運動に参加していたはずである。
自分たちの運動が実を結んで社会を動かしたというのは、言いようのない快感であっただろう。
だがそれも、２度、３度と繰り返す度に馴化によって何も感じなくなってしまったのではないか？
一度オナニーを覚えたら、定期的にせずにはいられなくなるようなものだ。
ダイエットという問題を克服した快感が忘れられず、ダイエット中毒になって骨と皮だけになる女子高生だっている。
同じことではないか？
彼らが理性的な表現規制不要論に耳を貸さず、なんら科学的、統計的な根拠のないアニメと犯罪の因果に固執する原因となってはいないだろうか？
私には彼らこそ、十分な休養を取りながら広い社会と交わり、自らの偏狭的な関心と生産性のない快楽主義を克服すべき存在に見える。
Twitter を見てると、太陽系の天体が螺旋運動するこのデマ動画が、いまだにRTされたりして拡散しているのでうんざりしてきた。
「太陽系 公転」「太陽系 運動」「太陽系 移動」「太陽系 回転」などで検索すると、この動画を真に受けて紹介しているブログなどが検索上位にヒットしてきて、さらに誤解を広める一因となっている。
あまつさえニコニコ動画にも転載され、字幕までつけられている。
結論から言うと、これはトンデモ信者が思い込みだけで作った信憑性ゼロの動画である。映像の出来だけはよいからか、昨年の3月頃からかなり広まっており、天文学者フィリップ・プレイト氏がブログでその間違いを指摘した記事を出している。プレイト氏は『イケナイ宇宙学 間違いだらけの天文常識』の著者で、世にはびこる間違った天文・宇宙ネタを斬って解説するブログ Bad Astronomy で知られている人。
この記事の和訳版が以下にあり、大変ありがたいのだが（動画が話題になってすぐのタイミングで和訳まで出たのは本当に感謝している）、残念なことに誤訳が目立つという指摘があり、いまもって修正されていない。
翻訳が不自然な箇所を以下にテキストで逐一指摘してくれている方がいたが、行きつ戻りつ確認しながら読むのが大変なので、勝手ながら指摘箇所を中心に翻訳を修正して以下にまとめ直した。いまだに信じて動画を広めてしまっている人に「それ間違いですよ」と指摘しようにも、記事の誤訳が多かったりするとちょっとなぁ、となるので。
なお、もし元の翻訳記事が適切に修正されれば本記事は消すつもりだが、和訳した方は当時Twitter で指摘されてこの校正テキストを読んだはずなのに、もう1年半ほど放置されているのであまり期待していない。
間違いを打ち消すために、まともな太陽系の公転運動を描いた動画があれば知りたいものである。
なめらかな動きでコンピューターアニメーションが太陽の周りを周る惑星の動きを、天の川銀河を周る太陽軌道のように解説する動画について、ツイートやメールがたくさん来ている。とてもきれいな動画に、説得力のある音楽、ていねいな作りの画像。
しかし、問題がひとつある。間違っているのだ。間違いは表面的なものではなく、間違った前提からきた根本的なものだ。中にはいくつかの有益な視覚情報があるが、私は(銀河サイズの)話題のタネだと思っておくよう警告する。
なぜか? 彼の主張の基礎は、「惑星は太陽中心の軌道を描いているのではなく、銀河の周りを渦巻き状に移動している」というものだ。
私は普段、こうした話題の間違いを暴くような面倒なことはしない。奇抜な主張はいつでもあるし、たいていは自滅していくからだ。しかし、この件についてはたくさんの人が私に知らせてきたし、明らかにかなり人気を博している――たぶん表面上は正しく見えるし、画像も大変きれいだからだろう。また、科学を知りつつもそこから離れて久しい人たちによって広まっているのではないかと見ている。このような話題を扱うときには、いつも少し深く掘り下げる手間がかかる。
そこで、シャベルを取り出してみよう。
動画の作者DJ Sadhuは明らかにコンピュータグラフィックスの才能がある。しかし科学は……まあ。私にはすぐさまこの動画が何を目指しているのかわかった。彼は率直に、太陽系の太陽中心モデルは間違っている、と述べている。しかしながら、この Sadhuの主張ははなはだしく間違っている。重力は存在しないと言っているようなものだ。
地動説とは、太陽が太陽系の中心にあるという考え方で、惑星はその周りを周っている(他にもいくつか大事なことがあり、たとえば惑星の軌道は楕円であるとか、軌道は同一平面上にあるのではなくて互いに傾いているとか)。この考え方は、地球が太陽系の中心だという古い天動説にとってかわった。天動説は、それをちゃんとした物理のモデルだと考えると、あらゆる種類の奇妙な仮定をしてやらないとちゃんと機能しない、とてつもなく複雑で考えすぎの物理モデルになってしまう(タイレノールなどの頭痛薬があるなら、epicyclesの項を見てみよう)。地動説はそれよりもずっと物理的に正しいし、ずっとうまく機能している。
私は、どちらのモデルにもそれぞれの使い道があると言いたいのだ。もし特定の惑星が天のどこにあるのか知りたいなら、天動説の座標を使うことになる。われわれは地球に住んでいて、地球は動かずに天の車輪が頭上を回転して動いているように見える、それは理にかなっている。しかし、もし惑星へ宇宙探査機を送りたいなら、太陽中心のシステムが必要なのだ。地球も惑星も両方とも動いていると考える方が、はるかに計算は簡単になる。
Sadhuは、地動説が間違っていて、実は惑星は渦を描きながら太陽を周る動きをしているのだと主張している。彼が実際に言わんとしているものは、渦ではなくらせんである。この2つは名前が違うだけでなく、物理的な動きもその特徴も全く異なる。らせん軌道を描く粒子は、太陽系のようにお互いには干渉していなくてもよいが、渦を描く粒子は抗力と摩擦を通じて互いに干渉している。
しかし、意味論的な論争はよそう。もう一度動画を見てみよう。Sadhuは太陽が惑星を先導しているかのように、太陽が惑星よりも前方に出て銀河を回っているかのように描いている(2番目のビデオだともっとそれは明白だ)。これは単に誤解を招くだけでなく、完全に間違っている。惑星は、われわれが銀河系の中を巡るとき、ときどき確かに太陽の前に出たり、ときどきその後ろをついてゆく(太陽を周回する軌道上のどこにいるかによる)。実際に夜空の惑星を見たことのある人にとっては明白な真実である。なぜなら夜空の一部は、地球や太陽が銀河系を周るときの進行方向にあたるわけだが、惑星はその部分にだって観測されるのだ。
ここでも、細かいことをあれこれ議論するのはやめよう。後述するように（「こうした考え方はどこからもたらされたのか?」の項）、惑星が銀河系内を動くときに太陽の後ろをついていくという考え方は、Sadhuがらせんについて述べるときの思考基盤となっている。しかしまずは、もうちょっと見てみよう。
太陽が銀河の中を移動していく様子を示している、彼が二番目に公表した動画では、もっとひどい状況だ。
公平のために言うと、今回彼は惑星の動きについて「らせん状」だと正しく記述している。しかし、まだ惑星が太陽の後ろをついていくように描いていて、これは間違っている。また特に動画の冒頭では、太陽中心モデルと、らせん運動についての彼の説明を具体的に比較しており、誤った「太陽主導」の考え方を補強している。
彼の動画における太陽中心モデルの動きを注意深く見てみよう。銀河を周る太陽が動く方向は、惑星の軌道平面と同じに描かれている。しかし、こうではないのだ。太陽系の平面は、車の前方への動きに対してフロントガラスが作る角度のように、銀河系に対して約60度で傾いている。
これは本当に重要な点だ。らせんモデルでは、銀河を周る太陽の動きにあわせて、太陽を垂直に周回するような惑星が描かれている。お好みなら「正面向き」といってもいい。これが間違っている。なぜなら、惑星の軌道は60度で傾いていて、90度ではない。惑星はときに太陽の前に、ときに後ろになる。これだけで、らせん描写が正しくないことがわかる。地動説という現実のモデルにおいても、順行-逆行運動というものは存在し、現実の空できちんと観測できる〔訳注:詳しくはこちら参照〕。
しかしそれだけではない。動画では、太陽が銀河を周ることを見せていて、らせんに沿って上昇、下降している。最初の動画のように、一部正しいところもあるが、大方は事実からかけ離れている。
われわれの銀河は、中心部が膨らんでいる平たい円盤で、端から端まで約10万光年の距離がある。この円盤は無数の星を内包し、その重力が合わさって、銀河中心を周る軌道に太陽を留めている。ちょうど、太陽の重力が惑星を軌道に留めているのと同じだ。
太陽が銀河系を一周する軌道の長さは、およそ2.4億光年ではない。銀河を周回するときには、だいたい動画にあるように、太陽は実際ぴょこぴょこアップダウンを繰り返している(とはいえ大体1周につき4回ぐらいなのに、Sadhuは動画内で数十回もアップダウンするように描いている)。〔訳注:太陽系が銀河系内を周回する軌道の図参照（垂直方向は強調されている）〕
このような運動が起きるのは、銀河円盤での重力の働き方のせいだ。ここが非常にクールなところだ。円盤よりほんのわずか上にあるものは、円盤に向かって全体的に下へと引っ張られる。円盤が巨大な物質の板であると想像してみて、太陽がその円盤よりも上にあるとする。円盤の重力は太陽を下へと引っ張る。星と星の間は遠く離れているので、太陽は円盤の間を通り抜けて下へ降りていく。そうすると今度は、下に来てしまった太陽を円盤がまた引っ張り上げる。このとき、太陽の動きはだんだん遅くなり、そして止まり、向きを逆にしてまた円盤へと急激に突入する。太陽は、銀河円盤の中心から上下にそれぞれ200光年ぐらいの浮き沈みをするが、円盤は1000光年の厚みをもっているので、結局私たちは銀河円盤の中にしっかり留まっている。しかしこうした摂動は永遠に続き、太陽は大海のコルクのように浮き沈みを続ける。
太陽は銀河を周回しているので、合わさった動きはすてきな波のパターンになり、浮きつ沈みつ回転木馬のようにまわり続ける。ゆえに、Sadhuはこの部分に関しては(多かれ少なかれ)正しい。
だいたいはね。しかしここに3つ目の要素が加えられている。ひねったらせんを描く太陽の道筋を、彼は歳差運動の性質だとしている。この部分は間違っている。非常に間違っている。
歳差運動は物体が回転するときにてっぺんをぐらぐらさせる動きで、回転の中心軸からずれた向きの力をてっぺんに加えたときに起きるものだ。コマのてっぺんを突くとぐらつく、それが歳差運動だ。地球自身も太陽と月の重力に引っ張られて歳差運動をしており、その軸の1回の揺れ周期は2万6000年だ。
明らかにSadhuは、動画の中でこれを表現している。しかし、ぐらつきは太陽にまったくなんの影響も与えていない。それはただ、地球が何かしているだけだ。しかし、Sadhuは銀河を周る太陽の動きに付け加えていて、それは意味をなさない。動画では銀河を周るコークスクリュー(コルク栓抜きのような螺旋運動)を描いているが、ときには銀河の中心に寄り、ときには遠くへ離れる動きを何度も何度も繰り返している。回転木馬のたとえでいえば、馬が真ん中で回って、上下に、また左右に動いているようなものだ。しかし、それは太陽の本当の動きではない。左右の運動なんてない(軌道ごと何度も銀河の中心に向かったり離れたりするなんて)。Sadhuの示すコークスクリューパターンは、間違っているのだ。
動画と解説文において、Sadhuはかなり頻繁に、座標系と力と運動を混乱させている。
彼はなぜこんな正しくない運動を描くのだろうか。それを掴むため、彼が元にした文献をあたってみた。
動画と彼のサイトによると、SadhuはPallathadka Keshava Bhatという人から学んだそうだ。Bhatによる「らせんの渦巻き:太陽系の動的プロセス」(“Helical Helix: Solar System a Dynamic Process”〔リンク切れのためこちら参照〕)と題された文章にこの考え方はすべて説明してあり、細かすぎる点は指摘しないが、ちんぷんかんぷんなものだった。まじめな話、どれもまったく意味をなさない。Bhatは地動説は間違っていると主張しているのだが、その主張を補強するために、虚偽のアイディアを次から次へと用いているのだ。彼の主張の間違いを暴くためにページを割くこともできるが、ここは短くまとめてみよう。
私はBhatの主張を何度も読んで、可能な限り好意的に考えようとした。私がかき集めたところでは、彼が言っているのは、太陽の動きによって、太陽を先頭にして惑星が後をついていくという形で、惑星は銀河系内でコルク栓抜き状のらせん運動をする、よって地動説は間違っているというものだ。Sadhuの動画の解説文によると、こうした動きをうまく描いているという。しかし、どれも完全に間違っている。もしそれが正しいのなら、外惑星(太陽から地球よりも遠くにある、火星や木星など)は太陽の反対側に遠く離れて見えないだろう。しかしいつだって、私たちには見えている。
それに、私たちは何度もほかの惑星へ宇宙探査機を送っていて、どれもいまだその軌道上にある。もしBhatがいうように地動説が間違っているのなら、探査機はいつになっても目的の惑星に到達できない。探査機を送るための軌道計算が間違っていることになるからだ。探査機の道筋を計算するときに銀河を周る太陽の動きを考慮する必要なんて全くないから、Bhat氏のいうことは正しくない。
太陽が太陽系の先頭で、惑星はその後ろをついていくという主張も、明らかに間違っている。太陽は、Bhatが主張し(Sadhuが動画で示して)いるように、銀河系を突き進む弾頭のように太陽系を主導したりしていない。惑星は太陽の周囲を周り、全体が一つのユニットとして銀河系を60度の傾きで移動している。これは、銀河の軌道に沿って惑星はときに太陽の前になり、ときに後ろに続くということだ。
これはそう、道を歩くあなたの頭の周りを、端にボールの付いた紐がぐるぐる周っているようなものだ(この円は60度傾いている)。ボールはときに頭の前になり、ときに後ろになる。道を歩くときには常にあなたと一緒だが、歩く速さには関係なく、相対的にはあなたと同じ速さでいつも移動している。あなたが自分の動きを線で表すとすると、ボールは傾いたらせんを描くだろう。これこそBhatとSadhuが説明しようとしたことなのだが、しかし間違った説明になってしまった。
Bhatは、その文章の中でいくつもの間違いと論理的誤ちを犯している。たとえば、Sadhuの地球歳差運動の誤用についてBhatが何と言っているか読み取ろうとした。しかし、とても不明瞭で(それに単純なミスもあり、彼は歳差運動の周期を22万5000年としているが、実際には2万6000年)ゴルディアスの結び目を解いているみたいだった。まだほかにも。彼は、もし地動説が正しいなら、日食は1カ月に1回起きなければならないと考えている(46ページと134ページを参照。ちなみに日蝕が一ヶ月に1回起きないのは、月の軌道が傾いているため)。また、彼は「太陽中心軌道は不可能であると意味しなければならない」と結論付けた部分で、地球が太陽の周りを周る回転について根本的な勘違いをしているようだ(文書の30ページを参照のこと)。実質、私が読んだ文章の1ページごとに基本的・根本的な間違いがあった。
そしてこれが、Sadhuの(間違っているにしてもステキな)動画が基礎としているものなのだ、いいかい? いっておくが、もしSadhuのサイトをのぞいてみたら、あらゆる種類の……んー、おかしな陰謀論……9.11陰謀説から、ケムトレイルから、デイヴィッド・アイク(本気で爬虫類型異星人がデンバー空港の地下に住んでいて世界を支配していると主張している)が怒り狂いそうなのから、名前しかない程度のものまで見つかるだろう。私は、彼のほかの考え方を念頭に置くことにした。
DJ Sadhuの動画は、とてもステキで、そのうちいくつかは真実を元にしたものだ。しかし、私の意見ではBhatのゆがんだ宇宙に対する見方のせいで、その核心が失われてしまっている。
彼の動画は正しいように見える。クールであるように見える。ものごとはこうでなくっちゃ、というセンスに訴えかけるものがある。しかし、物事がどうあるべきかと、実際にどうなのかということはいつも重なり合うわけではない。宇宙は本当にクールな場所で、とてもよく出来た一連の法則に基づいて動いている。私たちはこうした法則を「物理」と呼んでいて、それは数学で記述されている。そしてそういうこと全部を理解しようとする試みが、科学である。
クールなものがすべて科学ではない。しかし科学の全てはクールだ。これは普遍的な法則ではないかもしれない。けれども、私の見てきた限り、これは真実なのだ。
http://individualist.link/ （←ドメインかっこいいでしょ）
〜 居酒屋にて 〜
A「やっぱり若者が稼ぐにはアプリ作るしかないと思うんですよ」
B「あー分かる」
C「ゲームは当たると大きくていいよね」
A「いいですよね」
A「そういう人の話聞いてみたいんですけどなかなか出てこないですね」
B「どういう人がどういうサービスで当てたのかまとめたい」
A「いいですねえ。Wiki 的な」
B「Google Docs とかでやってみる？」
A「おお、やりましょう」
B「Webサービスにしてもいいかも」
B「できた」
B「ドメイン取ろう」
アルコール入ってるから話のディティールうろ覚えだけどこんな流れで作りました。
当てたいなら先例を見るのが一番参考になるはずだし、僕は個人で作ったものが流行っているのを見るのが好きだし、そういうのとても興味ある。
このサイトを見ていると、どういう人がこのサービス作ったんだとか、これ個人で作ってたんだという発見があっておもしろいと思います。
１時間で出来たというのはほとんど誇張ではなくて、デザインに拘る時間とサーバーに設置する時間を抜かせば本当に１時間でできます。
・画像保存
・タグ付け
・JavaScriptで動き付ける
・CSS整える
・デザイン
というような感じになる。これらを実直にいちいち実装してたら１日で終わるか分かりません。
本を読む一番はやい方法は、文字を読まないことです。
ちょっとコードが書けると実装する道筋が思いついちゃうからライブラリを探す考えに及ばず実装しちゃう事があると思います。
そういう事は避けて、アプリを書くならアプリの本体を最小に済ませるか、ライブラリ自体を作ることに力を入れましょう。
こちらのサイトではRailsのレールに乗っかって開発しました。
以下の例はRailsを使った方法ですが、モダンなフレームワークを使っているのであればだいたい似たような話になると思う。
手に馴染んだフレームワークがあるならなんでもいい。
クソ小さなロジックと数ページしかないならPHPでもいいけど、
とにかくはやく作ることがしたいなら何かしらフレームワーク使ったほうがいい。
秘伝の Rails Application Template を用意しておくのも良い。
モダンなフレームワークなら何も考えずにデータベース接続できるはず。
Rails なら config/database.yml に接続情報書いて rake db:create && rails g model User name:string です。
ソーシャルアカウントでログインする要件が出たら、何も考えずに「あ、OmniAuth」となりましょう。
・画像保存
画像保存が必要になったら反射的に「Paperclip か CarrierWave どっにしよう」となりましょう。
・タグ付け
ActsAsTaggableOn を使います。
has_many :through のめんどくさいタグの実装ですが
これ入れて rake acts_as_taggable_on_engine:install:migrations && rake db:migrate を打てば一発で完成します。
・JavaScript で動き付ける
早くつくりたいんなら JavaScript は捨てましょう。
少なくとも生の JavaScript 書く時代ではないので CoffeeScript 使うと良いです。
・CSS 整える
とりあえず Bootstrap 入れましょう。
クラスの付け方を覚えちゃうと CSS 弄って HTML リロードして確認なんてことしなくても形は整います。
Bourbon gem 使って mixin ライブラリ組み込んじゃうのもいいですね。
HTML 書くのやめましょう。
Haml や Slim のようなテンプレートエンジンを使います。
Zen Coding でもいいけど、結局出力されるのが HTML じゃ見通し悪くて辛いと思う。
Web Components の時代になったらもっと簡単になるんだろうな。
・デザイン
ただ、Webページやアプリというのはだいたい決まったパターンがあるので、いろいろな事例を見るとよいでしょう。
正直レイアウト自体は他のサイト真似るのは悪くない判断だと思います。
むしろその方がユーザーにとって慣れ親しんだ分かりやすいサイトでもあります。
http://individualist.link/ の場合、http://www.producthunt.com/ を異常なほど参考にしました。
まあここまで書いてなんだけど、前提知識として Rails が使えるようになってないといけないのは敷居高くて悪かったと思う。
なお、今回つくったこのサイト、ぜひともみなさんにも投稿していただきたいのですが現在投稿者は承認制としております。
私本当に個人が作って運営しているというアプリやサイトというのが好きでして、
こちらのサイトにリストアップする行為に儲けやがってといった悪意は一切ありません。
元増田です。ありがとうございます。
ここの所は、今回の例ではいまいち見えづらい気がする。
たしかに、そうですね…
攻撃を支持した時点で刀をふりあげて、そのあいだに毒でモンスターが死んだら、納刀する、のような場合では、モデル・ビューの関連が密になる例になるでしょうか。
これは知りませんでした。基本クラスのレベルでObserverパターンがサポートされる！しかもタイプセーフ…
Mac OS X のCocoaフレームワークにも KVO という同様の仕組みがありますが、型のチェックは自分でする必要があります。
MOVEは望まれなかった子 - the sea of fertility
を読んで、MVCを理解した(つもりになった)ので、MOVEの設計方針自体はスルーしていました。
ここの所は、今回の例ではいまいち見えづらい気がする。今回の例で複雑になっているのはモデルだけである。ビューがやる事は、「納刀する」「変色した血が飛び散る」イベントをlistenして画面に描画するだけのはず。MVCのイベント機構は、モデル→ビューとコントロール→モデルのメッセージ通知を行うためのもので、モデル同士の通信についてはノータッチ。モデル内での相互作用に、単なるメソッド呼び出しを超えたあれこれが必要なら、DSLを作るなり自前でイベント機構を作るなり好きにして下さい、というスタンスかなあと思われ。
といってもQtのsignal/slotなんかはモデル同士の通信にも使えるわけで、そういう意味で最近のGUIエンジンはMVCの範囲を超えつつある。具体的に「Controllerからの入力もModelの自発的な状態遷移も、同じイベント機構で扱いましょう」というのはMOVEの考え方に非常に近い。
http://blog.neo.jp/dnblog/index.php?module=Blog&action=Entry&blog=pg&entry=3442&rand=9193a
MOVEの考え方からいえば、モデルの責務が吸い出されて単なるデータになってしまうのは、むしろコンセプト通りであるとも言える。
なお、単純な例を超えてRPGの実装を自分が考えるなら、オブジェクト指向設計としては攻撃方法型や特殊作用型（毒とか呪いとか）同士の相互作用を主眼に置いた感じになって、モンスターや勇者は単なるデータに近付いていくだろうなあ、と予想してみる。組んでみないと分からない事もあるだろうけれども。
ご意見くださって、ありがとうございます。
例にあげたRPGのモデル設計はhttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1178047006を参考にしました。
ですが自分で書くとしても、十中八九そのような設計にするでしょう。
モンスター.attack(勇者.attackPower)
勇者.attack(モンスター)
主語.動詞(目的語)
モデルに対する命令は、ふつう入力Controllerのイベントハンドラに書かれる。attackに関する命令はどちらの設計をとったとしても"攻撃が選択された"イベントハンドラに書かれるだろう。
モンスター.attack(勇者.attackPower)
だと、たとえばモンスターにダメージを与える要素として、他に「すばやさ」などを加えようとしたら、モンスターのattackメソッドを変更する必要が生じる。
また、FF5には"竜騎士のジャンプ"という攻撃方法があった。ジャンプを選択すると、竜騎士は空高く飛び、一定時間が経ったのちに落ちてきて、空中からモンスターを攻撃する、というもの。これを実装しようとすると、入力Controllerのイベントハンドラの直前の部分で別スレッドに投げるなり、タイマーを起こすなりして処理したくなる。
味方同士の”連携攻撃”を実装しようとするとやはり、入力Controllerのイベントハンドラを修正したくなるだろう。
つまり、悪い方の設計ではModel「勇者」への設計変更の都合で、Model「モンスター」や入力Controllerを修正する必要が出てきてしまう。
勇者.attack(モンスター)
では、どの設計変更の例でも、勇者側を変更するだけで良い。この設計には、クラス間の責任の分担がはっきりするという利点がある。
list.append(elem)でしょ。
リストは実質的にはオブジェクトというより、ただのデータ構造。
リストやディクショナリ(連想配列)は便利な道具だが、これを前面に押し出した設計は複雑さを招く場合がある。
たとえば、"複数のモンスターの集まり"や"ソートされたリスト"を、リストを継承して実装しようとすると、とたんにドツボにハマる。
Onスライムが仲間を呼んだ(){ スライムの集まり.append(スライム) スライムの個数ラベル.更新(スライムの集まり.length) if(スライムの集まり.length == 1 and スライムの集まり.get(0).name == "キングスライム"){ スライムの名前ラベル.更新("キングスライム") } }
スライムは8匹集まるとキングスライムになるので、最初の一行でスライムの集まりを変更して以降、スライムの個数を気にする必要があることに注意して欲しい。
上記のコードを洗練させるために、Model「スライムの集まり」で個数が変わった時にイベント"OnLengthChange"を発行するようにしても良いが、そのようにすると、lengthメソッドを安全に呼べるのはそのイベントハンドラのみ、ということになる。プログラマに注意を促すために、lengthメソッドのコメントにその旨を注意書きしておく必要がある。
"スライムの集まり"リストクラスは、プログラマが期待するだろうリストクラスの振る舞い《append後の個数はappend前+1》を破壊している。
"ソートされたリスト"は、appendメソッドをオーバーライドして、追加時に勝手に順番を並び替えてくれるようなものだが、これも《リストに要素を追加した時には、その要素は末尾に置かれる》というリストクラスの振る舞いを破壊する。スライムの例と同じように、イベントの発行とメソッドの注意書きが必要になる。プログラマはそれらのクラスを使うときに、より注意深くならなくてはいけない。
このように、クラスの振る舞いを壊してしまうようなクラス設計は、プログラマを地雷原におくりこむことになる。
とはいえ、リストのようなデータ構造を便利に使えるシーンもある。
はじめからおわりまで100行程度のスクリプトで、とくにイベントドリブンにするほどの複雑さがない場合。順序を追って読めるので、時間的な流れがわかりやすい。
一方、RPGの例で示したような設計は、オブジェクト指向をフルに使って、コードを責任に応じて役割分担しやすくなる利点がある。
前者は"トランザクションスクリプト"的設計と呼ばれ、後者は"ドメインモデル"設計と呼ばれる。
例えばスーファミのFFみたいな、古典的なRPGの戦闘シーンを作っていて、「勇者がモンスターを攻撃する」。
勇者.attack(モンスター);
という設計だったとする。
これに「モンスターが毒を受けて、自死する」という挙動を追加するケースを考える。
毒.attack(モンスター);
やや複雑な変更になりそうだが、勇者の攻撃とのタイミングの差で、
のようになるとしよう。
まず、インターフェイス"攻撃者"をつくって、「勇者」、「毒」をその実装とする。加えて...
斬撃後に死んでいた場合(*) 、納刀する
攻撃前に既に死んでいた場合、攻撃できないようにする
この設計変更によって、
が、
の４パターンに増えた(※ただし最後のパターンに関しては今回特に修正の必要はなかった)
攻撃者がひとつ増えるごとに、これらの分岐は倍、倍に増えていく怖れがある。
あらたに攻撃者を追加すると、既存の攻撃者を変更しなければならない。
この変更によって、全体の時間的な流れがよくわからなくなった。
等々の分岐が並ぶことになる。この分かりにくさは単にStateパターンを導入しただけでは本質的には改善しないだろう。
MVCにおけるモデル、は振る舞いを持ったデータだ。モデルが状態変化したとき、イベントが発生する。
しかしその状態変化が別のモデルの状態変化のタイミングに影響をうけるとき、モデルの設計はとても複雑になり、読みにくくなってしまう。
モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。
このような複雑さをプログラマが支配するのは、とても大変だ。
みなさんも体験したことがないだろうか、GUIで「ホニャララしているときにホゲホゲするとバグる」みたいな挙動を。
すると、上部に表示される「更新時刻」の表示位置がおかしくなる。
RPGの設計は、たとえば下記のように記述できるDSLを導入すると、劇的に改善する。
タイミング：毒 ⇒ 死ぬ ⇒ 斬撃 の順なら、納刀する タイミング：毒 ⇒ 斬撃 ⇒ 死ぬ の順なら、変色した血が飛び散る
オブジェクト指向ではこれはStateパターンとStrategyパターンを組み合わせることで実現できる。
でも、このような設計にすると、勇者やモンスターのモデルオブジェクトの責任は極端に少なくなってしまう。
加えてオブジェクト間のやりとりの複雑さがDSLに押し込められるので、オブジェクトの主体性も殆ど無くなってしまい、
うん、ただのデータでいいや。
---------------------------
(*) 攻撃時に相手の状態を問い合わせるのが醜い。これを避けるには、モンスターが毒で死んだ時に勇者にイベントを通知して、勇者を”戦意喪失”状態に変化させる手がある。
月刊"Model Graphix"誌上で、もっともエクスキューズの少ない（というか皆無の）ページは明貴美加の『MS少女』である。
ミリタリーやオート・モデリングはいわゆる"大人のホビー"としての正当性を主張し、
キャラクター・モデリングは"メディアミックスがどうたら……"と詭弁をたれることが可能（僕のことだ）でも、
「キャッ♡♡」の前には、どんな言い訳も成り立たない。一網打尽。万事窮す。
ということはすなわち、『MS少女』が、模型雑誌といういわゆる"病気"の世界の、
そして僕らの欲望の、もっとも"生"な部分であるということだ。
『MS少女』にの生理的拒否反応を示す"良識的な"ミリタリー・ファン（じゃあ自衛隊にでも入ればいいのに…）が多いのも、
明貴美加の『MS少女』がその部分を、無邪気に暴露してしまうからに違いない。
社会派でもある宮崎駿御大と同じ雑誌に連載されているという事実なのである。）
この８年の間に、もともとの『ガンダム』というブランドも、あの手この手で消費され続け、
TVアニメーションとその周辺のトレンド自体も二転三転している。
それどころか、ビデオ・アニメ・ゲームソフトとメディア自体が拡散しつつある。
その内容はつまるところは"メカ＋コスチュームつけたキレーなネーちゃん"に尽きてしまうのである。
とくに最近は、後者さえあれば、前者は"魔法"や"スポーツ"でも代用できる。
世代にかかわらず「ファンである」と口にするのが気恥ずかしい。
だが、一見大人向け…とかシリアスなテーマ（もし、あれば…だが）の作品も、
それを抜いてしまえば、つまるところ残るのは、『MS少女』と同じなのだ。
いや、それどころか、ヤマトと森雪、ガンタンク（死語）とセイラさん、
過去の名作／ヒット作も実はこの鉄則を守り続けているのであった。
つまり、『MS少女』の存在は、一見ＴＶアニメの副産物のように見えて、
明貴美加自身が知ると知らずとにかかわらず、
実はかなり正確な批評として機能していたことに気がつかなくてはならない。
実は（量的にはともかく精神的に）かなり貧しい我々のアニメ文化を、
知らず知らずのうちに語っているのである。
そして、その文化の本当の名は"特筆することのなさ"という文化であり、
そこに童話の『裸の王様』の中の聡明な少年のように君臨しているのが
最終的に笑われているのは僕のような
"特筆することのなさ"にまぎれもなく属しながら、
理解出来ない者なのかもしれない。
『超音速のＭＳ少女 明貴美加ファースト・イラストレーションズ』（大日本絵画、1994）より
http://www.amazon.co.jp/dp/449922635X
（ただし、ブラウザ上での可読性を考え、引用者が適宜改行を加え、
各段落間にスペースを挿入した）
「ストパン」「ガルパン」「艦これ」とミリタリー美少女ものが大流行で、
hakohakoは、バンド好きのためのライブ日程共有サービスです。ツイッターでフォローしている人のライブ日程をカレンダー形式でお届けします。ちょっとでも気になるバンドを見にいきましょう！
すみません。google chromeでしか検証していません。
３つあります。
一つ目は、一人でスクラッチで作りたいからです。プログラムを書くことは楽しいです(たいしたものはかけませんが)。しかし、デザインや運用のことは苦手で経験不足でした。これを期にやってみようと思いました。
二つ目は、少しでも気になるバンドを見逃したくないからです。不精なこともありますが、すべてのバンドをチェックできません。いつのまにか来てたりとか、来る前に解散してました。バンドの魅力は、小野ほりでい先生も認めてます。
一人で小さくwebserviceを作るためにはどうしているかを他の人にも書いてほしいため、自分から書いてみます。
言語はpythonで、web aplication frameworkはflaskを使いました。rubyやphpよりpythonが楽だと思いました。flaskはmicroframeworkで、rubyのSinatraと似ていて、小さいアプリを作成するのに適していました。
永続化のところは、redisを使いました。結果、redisを使った何かになってしまいました。。。mysqlでもpostgresでも、rdbを使った方がよかったです。ただ、sessionの管理やmessage queueを実装できるので、そちらで功を奏しました。
amazon ec2 のmicroで、nginxもuwsgiのreidsもworkerも動かしてます。dot cloudも試していたんですが、無料枠は4月末で終了してました。
デザインが苦手なので、bootstrap、bootswach、font awesomeを使いました。しかし、基礎ができてないためイケてない感があります。ノンデナイザーズブックを読んで出直してきます。
javascriptも苦手なので、coffeescriptを利用しました。pythonを使っているせいか、書きやすいし読みやすいです。mvcframeworkは利用していませんが、modelとviewを意識して書きました。
githubとgitの代わりに、bitbucketとhgを使いました。私にはgithubとgitの敷居は高かったようです。bitbucketは日本語で利用できるので、楽ですね。hgもgitよりも複雑なことを感じないです。ただ、gitの方が日本語ドキュメントは多いです。
gruntは、lessとcoffeescriptのコンパイルで使いました。リアルタイムで変更を通知するlivereloadも併用しました。
楽しいです！
Rails + Twitter bootstrapでエロ動画ソーシャルブックマークWebサービス、ソーシャルオナニー＝ソシャニーを作りました。
こちらです http://www.socianie.com
【なにこれ？】
かっこつけた言い方をすると、
「いっぱいエロ動画あるけど結局みんなどんなお宝動画で抜いてるの？という日常的な疑問への答え」
とかでしょうか。
実際どんな事が出来るサービスかというと、基本的には、はてなブックマークのようにエロいページをブックマークする（その時に、コメントを付記することができる）というものです。
サイト内の他のユーザーをフォローすることができ、TwitterのようにTimelineのようなものがあってそこにフォローしている人がブックマークしたページが表示されます（そのページが、xvideos,fc2などの有名サイトならば埋め込みプレーヤーですぐ再生出来ます。）
つまり、フォローしてる人の最新お気に入りエロ動画がチェックできます。
ブックマークされたページはそれぞれが固有のページを持っており、タグを付ける事ができます。
全ユーザーのブックマークしたものは動画一覧で横断的に見ることができ、並び替え・検索などが出来ます。
ブックマーク数で今日のランキング今週のランキングなどが見れます。
あと、累計ブックマーク数によってユーザーのランクが上がったりします。
TwitterのOAuth認証でログインが出来ます（Twitterにツイート投稿などはしません。また、サイト内の名前アイコンもTwitterのものを流用するかどうかも自分で決められます。）
①ソーシャルな機能。他にも世の中に色々素晴らしいエロサイトがありますがそれらはソーシャル機能を持つものが少ない。
②上記の話とちょっと被ってますが、他のサイトは基本コンテンツ自体を自動クローリングするけれどソシャニーはそこをユーザー自身に委譲しているため、集まってくる動画の質はそれに比べて上がるんじゃないかというのと、
③エロサイトにありがちな出来るだけごちゃっと感を無く広告も無しでTwitter bootstrap使って小綺麗な感じ
【作成後記】
Webサービス作るならRailsかな楽で便利らしいしというざっくりとしたイメージからRailsで作り始めましたが、
ネットの情報や入門書に取り組んでもサンプルと同じモノは作れても実際自分が作りたいモノになると、で、どうやるの？となりなかなか進みませんでした。
Railsは色々と勝手によろしくやってくれる機能が多すぎて実際何が起きてんの？というのがわかりづらいというのが第一印象でした。
色々試行錯誤した結果、一番参考になったのはRails tutorial( http://ruby.railstutorial.org/ruby-on-rails-tutorial-book )でした。
英語ですがバージョンは新しいしBootstrapの使い方もわかるしサンプルがTwitterクローンサービスを作ろうというなかなかおもしろいものなので途中で飽きること無く取り組めました。
何かを学ぶ時は、モチベーションが続く形の学び方が一番いいと思いました。
僕はエロ動画が大好きなので、エロサイトというのもモチベーションの1つです（ただ、作業中に脱線して気づいたらキーボードではなく下半身に手が伸びているという事もありました。）
また、上記のチュートリアルはテスト駆動開発なのでSpecのテストをモリモリ書いているのですが、とりあえずはテストに関しては何をやってるのかざっと眺める程度で精読しませんでした。
まずは全体像を把握して何が必要か把握したかったからです。結果的に最後までやりきれたので良かったと思います。
あとは、Rails固有の知識ではなくWebサービス全般の知識で足りないな、と思ったときはネット上や本屋の立ち読みで済ましました。
ネットで細切れにお勉強している場合、本屋で体系的にまとまっている本をざっと読むと意外に抜けてる知識が保管されたり脳内にインデックスが作れるのでいいと思いました。
理由はみんなが良い良いというので乗っておくかという安易なものです。
実際のところgitの良い所を使い倒せているのかというと全くそんな事ないですね。
せいぜいstash位でしょうか。あとbisectとか。
リポジトリは最初はDropBoxに作ってたのですが、途中からBitbucketを使いました。
GitHubを使わなかった理由はBitbucketはプライベートリポジトリが無料で持てるからです。
また、恥ずかしがり屋なのでGithubで公開は敷居が高いと感じたからです。
初のRailsプロジェクトというのもありソースがイケてないので恥ずかしいのです。
いつかイケメンなコードをGithubで公開してオレツエーしたいものです。
サーバーはエロOKのところを探すのがなかなか難しく結局海外のVPSを使いました。
Linodeというところですが、他との違いを挙げるとiPhoneアプリ経由で再起動などが出来たりします。あまりこの機能使ってないですが。
構成はpassenger+apacheで、DBはSQLiteで特にLBなどはないです。
諸々構築後に人気が出た時困らないように負荷分散のお勉強なんぞもやりかけましたがまずは不要かなということで辞めました。
ちなみにサーバーがUS西海岸なのでSSHで作業するとエディタがちょっともっさりすることがありました。
プロジェクト管理は、会社でも使ってるのでRedmineかなと思ったのですがどうせ一人だしRedmineのUIすきじゃないのでTrello（ https://trello.com/ ）を使いました。
TODO,Doing,Done,Bug,Suspendのリストを作ってやること忘れないように管理しました。
ふと出先で思いついた機能とかをiPhoneでスイっと追加など出来て便利でした。
正月に公開してお友達界隈で見てもらったんですが、よかれと思って作ったChrome拡張にCSRFの対策が不備あり結局ブックマークレットにしたり、
ソースを見てもらったら設計がRestfulじゃないとかControllerがfat過ぎるModelに押しこめなどアドバイスをもらえたり無知な僕には色々とお勉強になりました。
出来たものはしょぼいものですが、「Webサービス作ったことないコンプ」は少し解消出来た気がします。
以上、月19ドルも払ってるのにお友達だけで使われてるのも寂しいので増田でまとめついでに宣伝してみました。
叩かれるんでしょうか。怖いです。いじめないで。
よくわからないんだけど
http://ja.wikipedia.org/wiki/Model_View_Controller
※右図の写真でModelからControllerへの戻りはないよ？
別に ModelとViewが通信しちゃいけないわけじゃないし
ModelからViewおよびContollerへ飛ばすのは EventとCallbackであって、処理依頼ではないので・・・
もしくは、イベントドリブンとファンクションモデルを誤解してない？
たとえば、ListView の ListModelとListViewがあったときに Modelでデーターが更新されたらControllerに通知しないでViewに通知してデーターを更新すればいい。
Controllerというのは ユーザからの入力を受ける装置 であって、Modelを操作する装置ではないのだが・・・ ControllerをModelの操作装置として定義してないかなぁと思って。
Controllerが何かというのは、ここでは単にRailsとかCakePHPとかのウェブアプリケーションフレームワークのControllerのつもりです。
ウェブアプリケーションの場合処理の結果に応じて画面にいろいろ表示しないといけないわけですが、その画面表示の部分（表示するViewの選択とか、表示するメッセージの設定とか）はControllerに書かないといけないわけですよね。
そうすると、Modelで何か起こったときにControllerにそのことを通知して、それに応じたViewへの仲介をControllerに書かないといけないのですが、これがめんどくさいわけです。
正常系だけならいいですけど、途中で異常が起こって処理が中断されるなんてところを考えると、その部分を全部Model→Controller→Viewの2段階で書くのが大変に感じてしまって。
よかったら、教えて欲しいのですが Controller の定義を 教えて欲しいのですが
Controller って コレのことですよね？
http://pur.store.sony.jp/Qnavi/Product/CECH-ZC2J/
Controller ＝ 入力装置 （View以外の出力装置） （パッド）
Arrow ＝ Event/Call back （電気信号）
という認識で良いですか？
いえ、たいていの処理はModelに書かれてしまうので、Controller が厚くなる時って どんな時かな？と思ったので。
PS3のパッドが モニターの電源ON/OFFなどを見ることはないですよね。 という感じで。
PS3のパッド内にも当然CPUもどきは入っていて、そこでも処理しますが、 PS3のパッド内部に相当でかい処理を入れる とか でかくなるといわれても、想像がつかない感じです。
http://ugaya40.net/architecture/dis_mov.html
Fat Controllerはダメというのは昔から言われている話で、自分も昔読んだときになるほどと思ったので「なるべくControllerを薄く」を頭に置いているのだけど、どうもうまくいった感じがしなくて挫折感があった。その理由だけど、自分の経験から言うと、「Viewに変数を渡すのがめんどくさい」「途中で処理を中断するのがめんどくさい」の2点だと思う。
たとえばRailsだとController内でインスタンス変数に代入することによってViewに変数を渡すことができる。処理をModelに移すとModelからControllerに変数を返して、ControllerでViewに変数を渡すという二段階が必要になるのでこれがめんどくさい。（正確には、ControllerからModelの状態を取れるように作るのが正しいのだろうけど、Viewで必要となるあらゆる状況を想定してModelの状態を取れるようにするのはなかなか大変。それだったらControllerで処理しちゃって……としてしまいがち）
「途中で処理を中断するのがめんどくさい」
たとえばRailsの場合、Controllerからreturnすればその時点で処理が中断されるし、レスポンスもそこでrenderしておけばよい。しかし処理をControllerに移した場合、Model内で起こったことに応じて適切なレスポンスを返すコードをControllerに書かなくてはいけないが、これがめんどくさいように思う。Modelから直接レスポンスやViewを指定したくなってしまう。（もちろんそれはできないし、Modelの分離の観点からするべきでもない）
O/RマッパーのModelに一切処理を追加しないなんてことはなくて、Modelで処理できることは極力Modelに移しているつもりではいるのだが、どうしてもすっきり書けた感じがしない。
もちろんわかっている人ならこんなところでひっかからず、自分がわかってないだけの可能性が高いのだが、自分が上のような理由で挫折してしまったのは事実なので、何とかしたいとは思っている。
自分としては、理屈はわかるけど実際のコードはどうなんだという感じなので、「これは手本にすべきMVCのウェブアプリケーションだ」というのがあれば読んでぜひ参考にしたいのだけど、何かないものだろうか。
