「Model」を含む日記 RSS

はてなキーワード: Modelとは

2017-10-30

Pimax 8kあやしくなってきた

両目で8kの高解像度HMDのPimax 8kなんだが、リフレッシュレートが宣伝通りの90Hz出ないんじゃないかって疑いが出てきていて、Redditとかで少し炎上している。

HMDで最重要(とされている)のはリフレッシュレートで、これが低いと没入感が薄れたり、酔いの原因になったりする。

現在主流のViveやOculusはこのリフレッシュレートについては問題がないのだが、いかんせん解像度が低く、ドットが目立ち、少し離れた位置メニューが出現したりすると、文字が潰れて読めなかったりすることもままある。

Pimax 8kがこの問題解決してくれるんじゃないかと期待していたんだけど……。

He said that the screens that are installed in both the V2 and V3 HMDs are limited to 75 fps. I asked if this is what will be in the consumer model. His answered by saying what ships will operate inthe range of 75-90 FPS. He then added that it would depend on where the screens are sourced from, adding that the quality can vary manufacturer to manufacturer.

性能が出るかどうかは部品調達先のメーカーによるだそうだ。なにそのガチャ……。

まあまだどうなるかはわからんけど、とりあえずKickstarterには参加しないほうがよさそうである

2017-09-01

https://anond.hatelabo.jp/20170901133144

イーロンマスクは「俺とお前が違うのは資産を数千億円と幅広い投資家仲間を持っているかどうかだけだが、俺にはこれができる。俺の資産はこの場合科学的に言って影響していないからお前にはこれができる。と思う。だからやれ」みたいな中規模ワンマンクソ社長で、牛丼屋の社長がこれは共産主義革命から賃金が低いのは一緒に我慢しようとか居酒屋グループ創業者が私は現場社員たちと一緒に頑張っていきたいとか言っているのとなんも変わらんのだが、恫喝扇動が上手いだけなのにちやほやされているのは滑稽ですらある。

@elonmusk Model S P100D + EAP + FSD + PUP + カーボンスポイラー新車で一台無料でくれたらこエントリは消す。あとクリームインテリアは早く諦めるか値上げでもしろ。醜い。

2017-08-16

以前、ガンショップでGLOCK17とか撃ってた者だけど、店主の強烈なオススメにより、Savage Model 67Hとかいショットガンを買いました。

護身用にピストル買ったところで普段撃つ経験がなければいざという時撃てないし、一撃で倒せなかったら自分自身が辛い思いをすることになるからストッピングパワーが強いショットガンにしとけと強く説得されたので。

2017-04-20

ITエンジニア向けに「最低限これだけは守ってくれリスト」がほしい

ITエンジニアって日本において特殊存在

ほいほいと転職したり他の現場いったりができてしまうんだよ

そうすると、前任者のクソコードをヒントもなしに修正するハメになることが非常に多くなる

なぜなら辞めるときっていうのはだいたい苦しいときで、苦しいときほどクソを生みやすいか

 

AさんがBさんにクソを投げ、BさんがCさんにクソを投げ、CさんがAさんにクソを投げるみたいな

全員で苦しくなってる状況なんだ

 

「全員の技術力を上げるべき」なんていうクソみたいな不可能提案する人も居るけど

そういうクソは放っておいて

仕事するなら最低限これだけはやっておいてくれリストみたいなのがあれば良いんじゃないかと思った 

 

もちろんそれも、仕様書を書けなんていう無理難題じゃなく

例えば「Modelにだけはコメントを必ず書く」くらいのクソ低レベルリスト

それがほしい

 

 

 

そしたら、それ守ってないやつを全力で叩くから

 

__

 

あ。もちろん全員が自衛のためにね。叩くってのは冗談

 

ちなみにこれは宗教論争になるから、1個に定めるのは無理だろうけど

なんていうの、松竹梅で、これほしいよねリスト流行ればいいと思う

 

なお主導はしません

ウンコードを撲滅したくて血涙流してる人頼む

2016-12-12

「::」←これってどういう意味

Webプログラミングしてるとよく見かけるじゃん。Model::find($id);みたいなやつ

この増田ロゴにもあるよな。これはどういう意味なの?inみたいな?

2016-10-17

http://anond.hatelabo.jp/20161017165607

ありがとうございます。読んでみます

Railsの時は黒魔術師コード理解できなかったけど、

何をやっているかは把握できたし、そこに書く理由もそれなりに分かっていたのです。

まさにレールに乗ってる感じ。

特定されないか気になるけど気にしないで書く。

今の案件、Controllerに英数字の画面IDを定数で渡してView指定し、

画面IDと同名のファイル名のviewviewsフォルダに作り、

ロジックはServiceに書いている。

DBアクセスmodelフォルダ内にdaoってフォルダ作ってそこにソース置いてる。

JSのincludeはもうどこでやっているのかわ分からない。

他をまねて書いたら勝手にheader部にincludeされてる。普通にviewに書いちゃダメなのか。

こんなん初見理解できるものなんでしょうか。

理解というのは、使い方というか、なぜこういう構成にしたのかという思想について。

http://anond.hatelabo.jp/20161017164515

ビジネスロジックModelに、とかサービス層に、とか言われて、困る感じか

1画面1機能ならViewとControllerで十分なんだよね

同じ機能複数画面で提供しようとすると、Controllerに処理書くスタイルだとコードが重複だらけになるんだよね

それを共通化しようってしたときに、ソフトウェアアーキテクチャとかが出てくるんだよね

教科書としては「エンタープライズ アプリケーションアーキテクチャパターン」とかあるけど、難しいし、理解してない人のほうが多いし、人によって言ってること変わるんだよね

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-17

http://anond.hatelabo.jp/20160516152330

それをユーザから見て命令変数への破壊的代入ではなく

参照透明な関数インターフェースで実現するのが

いわゆるモナドや(誰かの独自解釈ではない本来の)FRP

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実装

ググればWikipediaで出てくるレベル

https://en.wikipedia.org/wiki/Functional_reactive_programming#Implementations

2015-11-29

4Pマーケティングミックスの要素

企業は以下の4Pを適切に操作して顧客にモノを売る。

いや、おかしいでしょ。なんでPlaceが流通になるの。なんとか頭文字を合わせようとしただけじゃないの。

で、さら顧客志向マーケティングミックスとして後に生まれたのが4C。

Consumer万能すぎでしょ。もっと狭い言葉を使おうよ。

サービスマーケティングミックスでは4Pに3つのPが加えられ、7Pになる。

Physical Evidenceが分かりにくすぎる。2単語になってるし。

さら共生マーケティングにおける4Cは上記の4Cとは違うとか、共生マーケティングの分野には7Cs COMPASS MODELなるものもあるとか。

https://ja.wikipedia.org/wiki/%E5%85%B1%E7%94%9F%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

7Cs COMPASS MODELが何を言ってるか分かる人います

無理やりかっこよく頭文字を合わせてなんの得があるというのか。

こんなことしているから、ビジネス寄りの学問うさんくさい金稼ぎの手段だという偏見が抜けないんだ。

2015-10-15

ニュートリノ振動は役に立つのか?

はてなブックマーク - ノーベル賞受賞の梶田隆章教授、NEWS小山慶一郎に「意味が分からない」 - ライブドアニュース

において「ニュートリノ振動は役に立つのか?」が話題になっていました。

以下に個人的な考えを述べます。できる限り誠実に書いてみます

ノーベル賞受賞の理由

まずはニュートリノ振動ノーベル賞を受賞した理由を振り返ってみましょう。

研究者達は世界の全てを記述する究極理論を目指しています。その理論においては自然界における4つの力、重力電磁気力(電場磁場)、強い力、弱い力を統一されているはずだと考えられています

1970年代電磁気力と弱い相互作用統一まで完成し、現在では強い相互作用記述する量子色力学とあわせて標準理論と呼ばれています。そしてこの後、人類は長い停滞期を迎えました。標準理論実験と合いすぎたのです。

人類はこれまで実験により理論の破れを見つけ、それをヒントにして次の理論を作り上げてきました。マイケルンモーリーの実験相対論に、光電効果実験量子力学へと繋がりました。標準理論を超えて大統一理論に進むには理論の破れを見つける事が不可欠なのですが、長い間それを見つける事ができませんでした。こんな中で唯一見つかった標準理論の破れ目がニュートリノ振動だったのです。現在私たちの手にする数少ない、 beyond the standard model へ繋がる鍵と呼べるでしょう。

ニュートリノ振動は役に立つのか?

以上より「ニュートリノ振動は何の役に立つのか」は「大統一理論は何の役に立つのか」に言い換える事が出来るでしょう。

しかし残念ながら大統一理論は(候補は日々研究されているものの)まだ完成もしていません。これはちょっと早すぎる質問でしょう。その前にまずは現在素粒子理論——標準理論は役に立つのか? を考えてみることにしましょう。

素粒子理論は役に立つのか?

実をいうと僕は素粒子理論は実社会には全く役に立たないのではないかと思っていました。

ところが癌医療への応用火山研究への応用加速器副産物といえる放射光を利用した品種改良材料開発といった産業利用が次々と成されるのを見て心の中でジャンピング土下座しました。

いや、僕が「素粒子は役に立たない」と考えたのは単に僕に才能がなかっただけであって、世の中には僕の思いもよらない利用法を考えつくすごい人達がたくさんいるのだと思い知らされました。

それでニュートリノ振動は役に立つのか?

ここでようやく表題に戻るのですが、「ニュートリノ振動は役に立つのか?」「大統一理論が完成したとしてそれは役に立つのか?」といった質問に僕なりに誠実に答えてみると以下のようになります

「正直に言うと僕には役に立つようには思えないし、どう使われるかも全く想像つきません。そして役に立たないと言い切る自信もありません。」

「ただ、これまでの歴史を振り返ると誰かが利用法を考えるかもしれません。世の中には凄い人たちがたくさんいるのですから

追記

これだけだと誠実じゃないと思ったので追記します。

仮に大統一理論が完成したとしてもお金にはなりません。理論定理を使う上で特許料は発生しないからです。研究成果は世界に公開されます

素粒子研究人類の貢献にはなるかもしれませんが、国益にはならないでしょう。

2015-05-08

志村多様体整数論を整理するために発見されたのだよ

志村多様体とは,Hermite対称領域の数論商として得られる代数多様体のことであり,複素上半平面の商であるモジュラー曲線の一般化にあたるものです.モジュラー曲線の定義方程式代数体に係数を持つことは古典的によく知られた事実ですが,それと同様に,志村多様体代数体上の自然モデル(正準モデルcanonical model)を持つことが知られています

この正準モデル理論は,志村五郎氏によって,[Shi67a]や[Shi67b]等の先駆的な仕事を経て,[Shi70a],[Shi70b]において導入されました.正準モデル存在によって,種々の正則保型形式の持つ有理性・数論性を統一的に捉えることが可能になります.また,志村多様体のエタールコホモロジーへのGalois群およびHecke作用素作用を通して,Galois表現と保型形式・保型表現を結び付けることもできます.これは,いわゆる大域ラングランズ対応に対する,現状で最も有効アプローチの一つであると考えられています.近年,数論幾何学・保型表現論双方の進歩によって,以前は予想であった志村多様体の諸性質が多くの場合証明されつつあり,また,その発展に伴い,さらに多くの応用が発見されてきています.今や,志村多様体論は現代整数論における標準的な道具立てとなった感があります.そこで,今回の整数論サマースクールでは,志村多様体の基礎理論から始めて,それが最近整数論にどのように応用されるかというところまでを扱いたいと思います

前半部で扱う志村多様体の基礎理論は,現在標準的に用いられている,Deligneによる再定式化[Del71a]に基づいて紹介を行います.このDeligneの定式化は,その抽象性・一般性のため,定義を見ただけではそれが意味するところをなかなか理解しづらいように感じます.そこでサマースクールでは,モジュラー曲線の最も単純な高次元であるSiegelモジュラー多様体から始めるとともに,なるべく分かりやすく,かつ実際の研究で使われている例を多く含めることで,この理論に初めて触れる参加者の方々にも十分に理解できるよう努めたいと思っています.後半部では,ここ数年間の進展も含む最近話題が主なテーマとなりますが,過度に技術的な内容は避け,理論本質を見据えた講演を設けることで,多くの参加者にとって有意義情報収集意見交換の場を提供できるようにしたいと考えています

2015-05-07

氏名:Mikhail Kapranov(カプラノフ,ミハイル

分野名:代数幾何

キーワード:モジュライ空間オペラッド,導来圏,非可換幾何

現在研究概要

My background is in algebra, algebraic geometry and category theory.

I am interested in interactions among these areas such as:

Abstract algebraic structures (operads and their generalizations)

arising from moduli spaces in algebraic geometry, including mod-

uli spaces of curves and moduli space of hypersurfaces (leading to

combinatorics of secondary polytopes).

• Relations between algebraic geometry and representation theory

(Hall algebras of categories of coherent sheaves).

• Infinite-dimensional objects in algebraic geometry, especially algebro-

geometric model spaces of paths and loops.

• Derived algebraic geometry, in particular derived moduli spaces of

algebro-geometric objects and analysis on such derived spaces.

• Nom-commutative and categorical methods in algebraic geometry.

学生への要望

Ideally, I would like the students wishing to work with me to have

some basic background in algebraic geometry (schemes, algebraic curves)

and homological algebra (sheaf cohomology). Additional background in

category theory (e.g., derived categories, higher categories and so on)

would be welcome but not strictly necessary.

2015-05-05

数理物理における「可積分非線形方程式」,特にソリトン方程式パンルヴェ方程式とそれらの離散化について研究を行っている.広田の双線形化法と佐藤理論研究重要ツールである広田の双線形化法によって,新しい連続方程式や離散可積分系特殊解を考察し, 連続系の場合によく理解されている概念方程式対称性,保存量等)とよく利用されている手法(逆散乱法, ダルブー変換等)を可積分非線形差分方程式及びそれらの超離散極限で得られたセルオートマトン拡張することは重要研究課題である.(差分方程式の可積分性の特徴は連続的な可積分系より基本的であると思われるのに,離散可積分系に関する知識は連続系と比べてきわめて少ないといわざるを得ない.)

最近,様々な自然現象記述するために用いられている連続模型の離散化についても研究を行っている. 特に連続系の超離散化可能な有理写像による離散化を行って,コンピュータシミュレーションと解析的な手法を用いながらその連続模型の離散的な表現の忠実さを考察している.さらに,得られた離散系の超離散極限として構成できるセルオートマトン性質研究している.

主要論文 1."Generalised QRT mappings with periodic coefficients'', R. Ramani,B. Grammaticos and R. Willox,Nonlinearity 24 (2011) 113-126.

2."Solving the ultradiscrete KdV equation'',R. Willox, Y. Nakata,J. Satsuma, R. Ramani and B. Grammaticos, J. Phys. A: Math. Theor. 43 (2010) FT 482003.

3."Yang-Baxter maps from the discrete BKP equation''',S. Kakei, J.J.C. Nimmo and R. Willox, SIGMA 6 (2010) 028, 11 pages.

4."A discrete-time model for cryptic oscillations in predator-prey systems''', R. Willox, A. Ramani and B. Grammaticos, Physica D 238 (2009), 2238--2245.

5."On two (not so) new integrable partial difference equations''', A. Ramani,B. Grammaticos, J. Satsuma and R. Willox, J. Phys. A: Math. Theor. 42 (2009) FT 282002 (6pp).

2015-05-04

戦争に行ってまで研究するのは数学者だけにしてほしいものだ

戦争に行って,やらなきゃ死ぬような境地で研究しているのは,こういう数学者だけにしてほしいね。ほかの分野の学者が,やらなきゃ死ぬと思って研究していても気持ち悪いだけ。数学だけは,戦争に行かないと,なかなかできない。

講   座 数理解学大講座 教授

研究分野 確率統計学

研究テーマ 1.マリアバン解析と漸近展開,条件付き漸近展開

2.確率微分方程式など確率過程統計推測論

3.漸近決定理

4.セミマルチンゲールの漸近分布

5.確率過程サンプリング問題

6.確率数値解析,漸近分布論のファイナンスへの応用

7.保険数理

研究概要 観測に対して行動を対応させる規則(決定関数)のもとで起こる確率現象を解析するのが数理統計学課題である統計的定理論は決定関数総体における最適性,許容性の問題を扱うが,その基礎となるのが分布計算である確率過程のように分布構造が複雑な場合は漸近的決定理論に頼ることになり,その適用のためには確率過程クラスマルコフ過程ミキシング過程,セミマルチンゲール,弱および強従属過程摂動モデル,...)に応じた極限定理の研究必要となる.

  高次の極限定である漸近展開が重要になっている.これは分布の近似精度の改善のみならず,多変量解析,時系列解析,高次漸近決定理論,ブートストラップ法,情報量規準統計的予測情報幾何などの研究の基礎となる.セミマルチンゲールのような連続時間確率過程に対して(分布論的)漸近展開を与え,これを基礎に確率微分方程式の高次統計推測論が現在発展しており,統計量の有効性の証明モデル選択における情報量規準構成などに役立っている.展開公式の解析的正当性(validity)の証明には無限次元確率解析(マリアバン解析)が用いられる.

  オプション価格の漸近展開の方法は,ファイナンスに現れる多くのモデル適用されており,保険数理におけるCTEなどのリスク尺度の近似計算,条件つき漸近展開および非線形フィルタへの応用も研究している.

主要論文 1.Yoshida, N.: Asymptotic behavior of M-estimator and related random field for diffusion process, Annals of the Institute of Statistical Mathematics, 42, 221-251 (1990).

2.Yoshida, N.: Asymptotic expansions of maximum likelihood estimators for small diffusions via the theory of Malliavin-Watanabe, Probab. Theory Related Fields, 92, 275-311 (1992).

3.Yoshida, N.: Asymptotic expansion for statistics related to small diffusions. J. Japan Statist. Soc. 22, 139-159 (1992).

4.Yoshida, N.: Estimation for diffusion processes from discrete observation, J. Multivariate Analysis, 41, 220-242 (1992).

5.Yoshida, N.: Asymptotic expansion of Bayes estimators for small diffusions, Probab. Theory Related Fields, 95 , 429-450 (1993).

6.Yoshida, N.: Malliavin calculus and asymptotic expansion for martingales, Probab. Theory Related Fields, 109, 301-342 (1997).

7.Kusuoka, S., Yoshida, N.: Malliavin calculus, strong mixing, and expansion of diffusion functionals. Prob. Theory Related Fields 116, 457-484 (2000).

8.Uchida, M., Yoshida, N.: Information criteria in model selection for mixing processes. Statistical Inference for Stochastic Processes, 4, 73-98 (2001).

9.Yoshida, N.: Conditional expansions and their applications. Stochastic Processes and their Applications 107, 53-81 (2003).

10.Sakamoto, Y., Yoshida, N.: Asymptotic expansion formulas for functionals of epsilon-Markov processes with a mixing property. Annals of the Institute of Statistical Mathematics, 56, 545-597 (2004).

11.Yoshida, N.: Partial mixing and conditional Edgeworth expansion for diffusions with jumps. Probab. Theory Related Fields 129, 559-624 (2004).

12.Hayashi, T., Yoshida, N.: On covariance estimation of nonsynchronously observed diffusion processes. Bernoulli, 11, 359-379 (2005).

13.Masuda, H., Yoshida, N.: Asymptotic expansion for Barndorff-Nielsen and Shephard's stochastic volatility model. Stochastic Processes and their Applications 115, 1167-1186 (2005).

14.Shimizu, Y., Yoshida, N.: Estimation of parameters for diffusion processes with jumps from discrete observations. Stat. Inferecne Stoch. Process., 9, 227-277 (2006).

 

著書 数理統計学朝倉書店 2006

学会 日本数学会日本統計学会,International Statistical Institute.

受賞 日本数学会2006年解析学賞,

第1回日本統計学研究業績賞(2007),

第14回日本統計学会賞(2009)

活動 Bernoulli Society, Executive Committee,

統計数理研究所リスク解析戦略研究センター客員教授,

日本統計学評議員

日本アクチュアリー会評議員

Statistical Inference for Stochastic Processes, editorial board,

8th World Congress in Probability and Statistics, Istanbul, Program Committee

2014-12-19

http://anond.hatelabo.jp/20141219020034

I was rejected by my best girl

My girlfriend left me

What plays a invaluable role for our study

What plays an invaluable role in our study

a simple model that explain

a simple model that explains

a large number of the descriptions

numerous descriptions

me and her

her and me

the way how

how

アブストを1 wordも書けてないけど彼女と別れたことをアブストっぽく書く

卒業研究がまるでうまく言ってなくて来週提出の卒論アブストが全く書けない現実逃避に。

English

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.

日本語

私は九ヶ月前に恋人から別れを告げられた.互いに強く想いあっていたにも関わらず彼らが別れることとなった理由は,不明瞭であった.本論文において,我々はこの出来事についての明瞭な解釈提示する.

我々の研究にとって非常に重要役割を果たしたのは,彼らに起こった事象に関する多くの私から収集された叙述である.冬の寒さが私に彼女と過ごしたかけがえのない日々を思い出させたおかげで,我々は多くの叙述を得ることができた.我々はそれらの一つ一つを注意深く調べて,幾つかの分類へと整理した.各事象についての時系列順と分類を組み合わせることで,我々は私と彼女感情的な移り変わりを分析した.

この分析に基いて,我々は彼らの別れを解釈する単純なモデルを提案する.本モデルについて幾人かと行った議論から,本モデル重要問題を捉えていると考えられる.さらに,かつて愛し合った人々がどのようにして別れるかのパターンを集めた既存研究と,本モデルを照らし合わせる試みを示す.この試みは十分に成功してはいないものの,少なくとも私が経験したことがありきたりな別れであったことを明らかにしている.

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-09-03

過剰なアニメ規制議論が巻き起こる原因に関する一考察

なぜか”良識派”と呼ばれる人々はアニメ規制したがる。

犯罪助長うんぬんと。

表現の自由をどうこう言って反発するのもいいが、

私の意見としては子供が見てトラウマになるような映像教育に”良い”影響があると思うから規制には反対だ。

悪夢にうなされたり、エロすぎて目に焼き付いて取れなくなる経験は大人になるために絶対必要である

殴られもぜずに大人になった奴がどこにいるのか!

さて、なぜこのような暴論が幅を利かせているのか。

しかしたら、この問題を扱う新しい切り口を見つけたかもしれないので報告する。

アニメなどの表現にはある程度の規制必要だが、今のままで十分である

にも関わらず、なぜ暴力的とも言える過剰な表現規制を唱える人が出るのか。

それは、人間の心理の持つ”慣れ”という性質から来るのではないか。

人間は同じ刺激を受け続けると、徐々に慣れて何も感じなくなる。

これを心理学用語では馴化と言う。

より詳しくは以下の文献を参考にされたし。

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

アニメ表現規制を唱える人々は、馴化によって現状でも十分表現規制されているという認識を持てないでいるのではないか?

おそらく、昨今のアニメ表現規制を推進したい人々は、過去にも同じように何らかの表現規制運動に参加していたはずである

そして規制強化という成果を勝ち取ってきたはずである

自分たち運動が実を結んで社会を動かしたというのは、言いようのない快感であっただろう。

おそらくは非情に強いエクスタシーを感じたはずである

さら活動を続け、さらなる規制を獲得したことだろう。

そうやって日本表現はつまらないものになり続けてきた。

だがそれも、2度、3度と繰り返す度に馴化によって何も感じなくなってしまったのではないか?

彼らは表現規制中毒となっている可能性がある。

一度オナニーを覚えたら、定期的にせずにはいられなくなるようなものだ。

努力問題を克服した時の快感は何にも代えがたい。

ダイエットという問題を克服した快感が忘れられず、ダイエット中毒になって骨と皮だけになる女子高生だっている。

同じことではないか?

彼らが理性的表現規制不要論に耳を貸さず、なんら科学的、統計的な根拠のないアニメ犯罪因果に固執する原因となってはいないだろうか?

私には彼らこそ、十分な休養を取りながら広い社会と交わり、自らの偏狭的な関心と生産性のない快楽主義を克服すべき存在に見える。

2014-08-30

違う、太陽系は渦巻きではない [BAD ASTRONOMY翻訳記事]【勝手修正版】

Twitter を見てると、太陽系天体螺旋運動するこのデマ動画が、いまだにRTされたりして拡散しているのでうんざりしてきた。

太陽系 公転」「太陽系 運動」「太陽系 移動」「太陽系 回転」などで検索すると、この動画を真に受けて紹介しているブログなどが検索上位にヒットしてきて、さらに誤解を広める一因となっている。

あまつさえニコニコ動画にも転載され、字幕までつけられている。

結論から言うと、これはトンデモ信者思い込みだけで作った信憑性ゼロ動画である映像の出来だけはよいからか、昨年の3月からかなり広まっており、天文学者フィリッププレイト氏がブログでその間違いを指摘した記事を出している。プレイト氏は『イケナイ宇宙学 間違いだらけの天文常識』の著者で、世にはびこる間違った天文宇宙ネタを斬って解説するブログ Bad Astronomy で知られている人。

この記事和訳版が以下にあり、大変ありがたいのだが(動画話題になってすぐのタイミング和訳まで出たのは本当に感謝している)、残念なことに誤訳が目立つという指摘があり、いまもって修正されていない。

翻訳が不自然な箇所を以下にテキストで逐一指摘してくれている方がいたが、行きつ戻りつ確認しながら読むのが大変なので、勝手ながら指摘箇所を中心に翻訳修正して以下にまとめ直した。いまだに信じて動画を広めてしまっている人に「それ間違いですよ」と指摘しようにも、記事誤訳が多かったりするとちょっとなぁ、となるので。

なお、もし元の翻訳記事が適切に修正されれば本記事は消すつもりだが、和訳した方は当時Twitter で指摘されてこの校正テキストを読んだはずなのに、もう1年半ほど放置されているのであまり期待していない。

間違いを打ち消すために、まともな太陽系の公転運動を描いた動画があれば知りたいものである


違う、太陽系は渦巻きではない [BAD ASTRONOMY翻訳記事]

なめらかな動きでコンピューターアニメーション太陽の周りを周る惑星の動きを、天の川銀河を周る太陽軌道のように解説する動画について、ツイートメールがたくさん来ている。とてもきれいな動画に、説得力のある音楽、ていねいな作りの画像

しかし、問題ひとつある。間違っているのだ。間違いは表面的なものではなく、間違った前提からきた根本的なものだ。中にはいくつかの有益視覚情報があるが、私は(銀河サイズの)話題のタネだと思っておくよう警告する。

なぜか? 彼の主張の基礎は、「惑星太陽中心の軌道を描いているのではなく、銀河の周りを渦巻き状に移動している」というものだ。

私は普段、こうした話題の間違いを暴くような面倒なことはしない。奇抜な主張はいつでもあるし、たいていは自滅していくからだ。しかし、この件についてはたくさんの人が私に知らせてきたし、明らかにかなり人気を博している――たぶん表面上は正しく見えるし、画像も大変きれいだからだろう。また、科学を知りつつもそこから離れて久しい人たちによって広まっているのではないかと見ている。このような話題を扱うときには、いつも少し深く掘り下げる手間がかかる。

そこで、シャベルを取り出してみよう。

制御不能のらせん

まずは動画を見てみよう。数分程度のものだ。

動画の作者DJ Sadhuは明らかにコンピュータグラフィックスの才能がある。しか科学は……まあ。私にはすぐさまこの動画が何を目指しているのかわかった。彼は率直に、太陽系太陽中心モデルは間違っている、と述べている。しかしながら、この Sadhuの主張ははなはだしく間違っている。重力存在しないと言っているようなものだ。

地動説とは、太陽太陽系の中心にあるという考え方で、惑星はその周りを周っている(他にもいくつか大事なことがあり、たとえば惑星軌道は楕円であるとか、軌道は同一平面上にあるのではなくて互いに傾いているとか)。この考え方は、地球太陽系の中心だという古い天動説にとってかわった。天動説は、それをちゃんとした物理モデルだと考えると、あらゆる種類の奇妙な仮定をしてやらないとちゃんと機能しない、とてつもなく複雑で考えすぎの物理モデルになってしまう(タイレノールなどの頭痛薬があるなら、epicyclesの項を見てみよう)。地動説はそれよりもずっと物理的に正しいし、ずっとうまく機能している。

私は、どちらのモデルにもそれぞれの使い道があると言いたいのだ。もし特定惑星が天のどこにあるのか知りたいなら、天動説の座標を使うことになる。われわれは地球に住んでいて、地球は動かずに天の車輪が頭上を回転して動いているように見える、それは理にかなっている。しかし、もし惑星宇宙探査機を送りたいなら、太陽中心のシステム必要なのだ地球惑星も両方とも動いていると考える方が、はるか計算は簡単になる。

Sadhuは、地動説が間違っていて、実は惑星は渦を描きながら太陽を周る動きをしているのだと主張している。彼が実際に言わんとしているものは、渦ではなくらせんである。この2つは名前が違うだけでなく、物理的な動きもその特徴も全く異なる。らせん軌道を描く粒子は、太陽系のようにお互いには干渉していなくてもよいが、渦を描く粒子は抗力と摩擦を通じて互いに干渉している。

しかし、意味論的な論争はよそう。もう一度動画を見てみよう。Sadhuは太陽惑星を先導しているかのように、太陽惑星よりも前方に出て銀河を回っているかのように描いている(2番目のビデオだともっとそれは明白だ)。これは単に誤解を招くだけでなく、完全に間違っている。惑星は、われわれが銀河系の中を巡るときときどき確かに太陽の前に出たり、ときどきその後ろをついてゆく(太陽を周回する軌道上のどこにいるかによる)。実際に夜空の惑星を見たことのある人にとっては明白な真実である。なぜなら夜空の一部は、地球太陽銀河系を周るときの進行方向にあたるわけだが、惑星はその部分にだって観測されるのだ。

ここでも、細かいことをあれこれ議論するのはやめよう。後述するように(「こうした考え方はどこからもたらされたのか?」の項)、惑星銀河系内を動くとき太陽の後ろをついていくという考え方は、Sadhuがらせんについて述べるとき思考基盤となっている。しかしまずは、もうちょっと見てみよう。

テイク2

太陽銀河の中を移動していく様子を示している、彼が二番目に公表した動画では、もっとひどい状況だ。

公平のために言うと、今回彼は惑星の動きについて「らせん状」だと正しく記述している。しかし、まだ惑星太陽の後ろをついていくように描いていて、これは間違っている。また特に動画の冒頭では、太陽中心モデルと、らせん運動についての彼の説明を具体的に比較しており、誤った「太陽主導」の考え方を補強している。

彼の動画における太陽中心モデルの動きを注意深く見てみよう。銀河を周る太陽が動く方向は、惑星軌道平面と同じに描かれている。しかし、こうではないのだ。太陽系の平面は、車の前方への動きに対してフロントガラスが作る角度のように、銀河系に対して約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のゆがんだ宇宙に対する見方のせいで、その核心が失われてしまっている。

彼の動画は正しいように見える。クールであるように見える。ものごとはこうでなくっちゃ、というセンスに訴えかけるものがある。しかし、物事がどうあるべきかと、実際にどうなのかということはいつも重なり合うわけではない。宇宙は本当にクール場所で、とてもよく出来た一連の法則に基づいて動いている。私たちはこうした法則を「物理」と呼んでいて、それは数学記述されている。そしてそういうこと全部を理解しようとする試みが、科学である

クールものがすべて科学ではない。しか科学の全てはクールだ。これは普遍的法則ではないかもしれない。けれども、私の見てきた限り、これは真実なのだ

2014-08-01

一発当てた個人開発者をまとめるWebサービス作った

http://individualist.link/ (←ドメインかっこいいでしょ)

居酒屋にて 〜

A「やっぱり若者が稼ぐにはアプリ作るしかないと思うんですよ」

B「あー分かる」

B「スマートフォンアプリWebアプリでもいいの?」

C「ゲームは当たると大きくていいよね」

A「Webアプリでもいいです」

B「当ててそれで暮らしてる人見ますね。羨ましい。」

A「いいですよね」

A「そういう人の話聞いてみたいんですけどなかなか出てこないですね」

B「当てた人が人前で自慢するメリットないからねえ…」

B「どういう人がどういうサービスで当てたのかまとめたい」

A「いいですねえ。Wiki 的な」

B「Google Docs とかでやってみる?」

A「おお、やりましょう」

B「Webサービスにしてもいいかも」

帰宅 & 1時間後 〜

B「できた」

B「ドメイン取ろう」

B「http://individualist.link/

アルコール入ってるから話のディティールうろ覚えだけどこんな流れで作りました

やっぱり若者が稼ぐにはアプリ作るしかないと思う。

当てたいなら先例を見るのが一番参考になるはずだし、僕は個人で作ったもの流行っているのを見るのが好きだし、そういうのとても興味ある。

このサイトを見ていると、どういう人がこのサービス作ったんだとか、これ個人で作ってたんだという発見があっておもしろいと思います

時間で出来た

時間で出来たというのはほとんど誇張ではなくて、デザインに拘る時間サーバーに設置する時間を抜かせば本当に1時間でできます

せっかくなのでちょっと開発について書きます

このサイトコーディングに使う大まかな作業をまとめると

データベース接続

Twitterアカウントユーザー登録

画像保存

タグ付け

JavaScriptで動き付ける

CSS整える

HTMLマークアップ

デザイン

というような感じになる。これらを実直にいちいち実装してたら1日で終わるか分かりません。

本を読む一番はやい方法は、文字を読まないことです。

コーディングせずにライブラリを使いましょう。

ちょっとコードが書けると実装する道筋が思いついちゃうからライブラリを探す考えに及ばず実装しちゃう事があると思います

そういう事は避けて、アプリを書くならアプリ本体を最小に済ませるか、ライブラリ自体を作ることに力を入れましょう。

こちらのサイトではRailsのレールに乗っかって開発しました。

以下の例はRailsを使った方法ですが、モダンフレームワークを使っているのであればだいたい似たような話になると思う。

ライブラリで組み立てよう

Rails

手に馴染んだフレームワークがあるならなんでもいい。

クソ小さなロジックと数ページしかないならPHPでもいいけど、

とにかくはやく作ることがしたいなら何かしらフレームワーク使ったほうがいい。

秘伝の Rails Application Template を用意しておくのも良い。

データベース接続

モダンフレームワークなら何も考えずにデータベース接続できるはず。

Rails なら config/database.yml に接続情報書いて rake db:create && rails g model User name:string です。

scaffold 使うと更に早くできます

Twitterアカウントユーザー登録

OmniAuth gem を使います

ソーシャルアカウントログインする要件が出たら、何も考えずに「あ、OmniAuth」となりましょう。

Device gem を使うと更に早くできます

画像保存

Paperclip gem を使います

画像保存が必要になったら反射的に「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 マークアップ

HTML 書くのやめましょう。

Haml や Slim のようなテンプレートエンジンを使います

Slim が一番タイプ量少なくておすすめ

Zen Coding でもいいけど、結局出力されるのが HTML じゃ見通し悪くて辛いと思う。

Web Components の時代になったらもっと簡単になるんだろうな。

デザイン

こればかりプロっぽいものつくる自信はない…

ただ、Webページやアプリというのはだいたい決まったパターンがあるので、いろいろな事例を見るとよいでしょう。

正直レイアウト自体は他のサイト真似るのは悪くない判断だと思います

しろその方がユーザーにとって慣れ親しんだ分かりやすサイトでもあります

http://individualist.link/場合http://www.producthunt.com/ を異常なほど参考にしました。

まあここまで書いてなんだけど、前提知識として Rails が使えるようになってないといけないのは敷居高くて悪かったと思う。

僕も最初アプリ作るのに途方も無い時間かかってた。

慣れればはやくなるから、たくさんアプリ作って一発当てよう。

思いついたときにすぐ作れるようになれるといろいろ捗るぞ。

なお、今回つくったこのサイト、ぜひともみなさんにも投稿していただきたいのですが現在投稿者承認制としております

質を保ちたいので、捨て垢に荒らされても困りますからね。

私本当に個人が作って運営しているというアプリサイトというのが好きでして、

こちらのサイトリストアップする行為に儲けやがってといった悪意は一切ありません。

私にとっては好きな人達をまとめるサイトなので質はしっかりしておきたいのです。

2014-07-27

http://anond.hatelabo.jp/20140727223317

http://www.mini-log.jp/gh/calera/

calera カレラ

さなお庭にナイスフォット!組立て簡単、おしゃれなデザイン

洗練されたデザイン一坪タイプのお手軽パネルハウス。木肌が美しい北欧ホワイトパイン材を使用。 屋根材・釘・ビス・棟部板金もキット内に入っています画期的パネル式(床パネル・壁パネル屋根パネル) の校正で組立て簡単。 日本語組立てマニュアルも完備。

MODEL DATA

カレラ

•高さ 2.14m

建築面積 3.24

延床面積 3.24

セルフビルド平均所用日数

2人で2日

※基礎(簡易独立基礎)、木工事塗装工事の参考日数

販売価格 \198,000

2014-01-17

http://anond.hatelabo.jp/20140117000313

元増田です。ありがとうございます

モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。

ここの所は、今回の例ではいまいち見えづらい気がする。

しかに、そうですね… 

攻撃を支持した時点で刀をふりあげて、そのあいだに毒でモンスターが死んだら、納刀する、のような場合では、モデル・ビューの関連が密になる例になるでしょうか。

いや、そのときModel「刀」をつくればいいのか…

Qtsignal/slotなんかはモデル同士の通信にも使える

これは知りませんでした。基本クラスレベルObserverパターンサポートされる!しかタイプセーフ…

Mac OS XCocoaフレームワークにも KVO という同様の仕組みがありますが、型のチェックは自分でする必要があります

MOVEの考え方からいえば、モデルの責務が吸い出されて単なるデータになってしま

MOVEは望まれなかった子 - the sea of fertility

を読んで、MVCを理解した(つもりになった)ので、MOVE設計方針自体スルーしていました。

Modelから責務が吸いだされて、なくなるのが予定調和なら、OVEでよいのでは

http://anond.hatelabo.jp/20140116013407

モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。

ここの所は、今回の例ではいまいち見えづらい気がする。今回の例で複雑になっているのはモデルだけである。ビューがやる事は、「納刀する」「変色した血が飛び散る」イベントをlistenして画面に描画するだけのはず。MVCイベント機構は、モデル→ビューとコントロールモデルメッセージ通知を行うためのもので、モデル同士の通信についてはノータッチモデル内での相互作用に、単なるメソッド呼び出しを超えたあれこれが必要なら、DSLを作るなり自前でイベント機構を作るなり好きにして下さい、というスタンスかなあと思われ。

といってもQtsignal/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の実装を自分が考えるなら、オブジェクト指向設計としては攻撃方法型や特殊作用型(毒とか呪いとか)同士の相互作用を主眼に置いた感じになって、モンスター勇者は単なるデータに近付いていくだろうなあ、と予想してみる。組んでみないと分からない事もあるだろうけれども。

2014-01-16

http://anond.hatelabo.jp/20140116080422

意見くださって、ありがとうございます

例にあげたRPGモデル設計http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1178047006を参考にしました。

ですが自分で書くとしても、十中八九そのような設計にするでしょう。

X
モンスター.attack(勇者.attackPower)
O
勇者.attack(モンスター)

だと主張します。その根拠を説明します。

理由1: 読みやす

主語.動詞(目的語)

英語の文のようで読みやすい。

理由2: 変更が分散しにくい

モデルに対する命令は、ふつう入力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メソッドオーバーライドして、追加時に勝手に順番を並び替えてくれるようなものだが、これも《リストに要素を追加した時には、その要素は末尾に置かれる》というリストクラスの振る舞いを破壊する。スライムの例と同じように、イベントの発行とメソッドの注意書きが必要になる。プログラマはそれらのクラスを使うときに、より注意深くならなくてはいけない。

このように、クラスの振る舞いを壊してしまうようなクラス設計は、プログラマ地雷原におくりこむことになる。

時間的な流れの分かりやすさ v.s. 責任分担

はいえ、リストのようなデータ構造を便利に使えるシーンもある。

はじめからおわりまで100行程度のスクリプトで、とくにイベントリブンにするほどの複雑さがない場合。順序を追って読めるので、時間的な流れがわかりやすい。

一方、RPGの例で示したような設計は、オブジェクト指向をフルに使って、コード責任に応じて役割分担しやすくなる利点がある。

前者は"トランザクションスクリプト"的設計と呼ばれ、後者は"ドメインモデル"設計と呼ばれる。

よく利点・欠点比較され、それぞれを推進する派閥があったりする。

google:トランザクションスクリプト ドメインモデル

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん