ウマ娘と Unity と物理法則

ちょっとした話題になっているウマ娘だが、少なくとも win 版は Unity というプラットフォームで開発されているようだ。
ウマ娘を win にインストールするとユーザーホーム直下に umamusume というディリクトリがつくられる。ここに Unityxxx というファイルが含まれているので推測できる。
試しに先ほど Unity をインストしてみた。これからちょっと触ってみようと思う。
なんかレーシングゲームのひな型はすでにあるような・・・。

日本人は Unity のような枠組みをつくるのは下手でも、それ使ってコンテンツつくるのは上手だなとは思う。
アイキャッチのスクショの左がウマ娘、右が Unity の画面。
ちなみにウマ娘はアグネスタキオンw

あと、気になったのは、ヲタ気味の人がつくっている「考察」動画の類で、私もプレイするときに参考程度にチラ見したが、ちょっと物足りないかな。

例えば、ある物体が等加速度運動をしている場合、時刻 t でのその速度 v は、初速度を v0、加速度を a とすると
v = v0 + a * t
で与えられる。

実際には推進力は変わるなどして等加速度運動しているわけではないだろうが、どこかにこのような基本方程式というものがある、という視点がないとちょっと物足りない。

というか、ないとゲーム自体がつくれないでしょ。

 

接触確認アプリ cocoa とオープンソース

某所でコメントしたことの転載。


cocoa はバグが枯れてきた印象はあるんですが、今後も継続的に適切な保守開発が行われるかというと若干疑問もあります。
契約の詳細まではわかりませんが、実際に保守開発を行っているであろうデザイアードには405万の費用しか渡っていないからです。
https://www.tokyo-np.co.jp/article/87051/

エンジニアを一人 40 万/月でアサインして 10 ヶ月保守したら、予算尽きてしまいます。
今後どういう運営をするつもりなのかの説明がまったくないのでこのままでは信用できません。

そして、このプロジェクトが興味深い点は、元はオープンソースで、献身的なエンジニアがバグなどをボランティア的に見つけ、その改善策を提案しているところです。
今回の修正もおそらくそれらを参考になされたものだと思いますが、その点をいっさい伏せて、さも「自分たちで修正しました」というのは、ちょっとどうかと個人的には思います。

そして、これが一番ダメなんじゃないかと思うのは、プルリクエスト(コードの修正依頼)に対して、厚労省側のレビューが全くない点です。
これされると(=オープンソース性の喪失)今後バグが出てもその責任箇所を指摘できないし、どう修正していいかといった提案も当然できません。
これやって失敗したプロジェクトはけっこうあります。

最後に、ボランティアで参加したエンジニアの方の意見を一つあげておきます。

Issueとは直接関係ないのでコメントとして記載します。

現在のCOCOAの状況を大変、憂慮しています。

このIssueを見ている関係者の方は居られないのかもしれません。しかし、もし居られるならば、今一度、オープンソースのやり方でCOCOAを継続的に改善する方向へ舵を切ることを何卒ご検討ください。

もしそうなったならば、ぼくはAndroidアプリ開発に携わるソフトウェア開発者の一人として、お力になれるものと確信しています。

https://github.com/cocoa-mhlw/cocoa/issues/21?#issuecomment-780502093

 

猪股弘明
医師:精神科

 

オープンソースの世界 〜残酷な自由さ〜

オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。

開発者目線では…

例えば、以前評判になったこの記事。

筆者の megamouth さんによれば、contributor(ソースコードを提供した者)にも序列があるという。


OSSへのコントリビューターにもカーストがあって、ついでに書いておくと

カーネルメンテナ>言語メンテナ>カーネルコミッター>言語コミッター>有名ライブラリメンテナ>色々>ユーザーグループ主催者>ブログでアプリへの文句だけ書奴~

みたいな序列である。

ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。

曰く、


アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。

プルリクエスト(Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと)送るだけでも大変なのだ。

さらに、新機能の提案などになると・・・

新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。

単に PR 送るより大変なのがわかる。

きっかけは個人的な欲求から始まる

ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。


そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、(カーネルなどへ contribution するのに比べたら)かなり楽だ。

ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。

だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。

ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか?」みたいな記事は見つかるのだが、逆に「これやっちゃあかん!」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。

マージされなかった Pull Request の例

以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。


一目でわかる通り、単純に特定行を delete したのみ(文頭の – は削除した印)。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。

一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。(この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由)

だから、これは bug (バグ)ではない。

確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。

だから、この PR はマージできない。

逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う(例え、この噂が本当であったとしても、だ)。

つまり、相手(レビュアーやメンテナー:PR を評価しリポジトリを管理する人たち)の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。

(付記)その他の理由 -著作権に対する配慮-

上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの2次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には2次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが(京都大の小林慎治という人。現在は、保健医療科学院に所属)、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範(CODE of CONDUCT)のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。(蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。)
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。

Fork の効用・意味

また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある(当たり前だがユーザーには「好み」があるから)。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。

まとめ? 残酷でもあるが自由でもある

既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。

 

他にも面白い話もあるので、また続き書きます。

 

猪股弘明

オープンソースの世界

オープンソース(Open Source)ソフトウェアに関する軽めの話など。

まず、オープンソースって何ぞやって人は、『伽藍とバザール』あたりを読むと雰囲気掴めると思います。このエッセイ自体、お話として抜群に面白い。
筆者のエリックレイモンドさんが自身が開始したプロジェクトでオープンソース開発方式を意識的に選んだときの経験談やコードを書く際の箴言めいた教訓が語られています。

Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった(中略)。そしてそこから一貫した安定なシステムが出てくる なんて、奇跡がいくつも続かなければ不可能に思えた。
このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

目玉の数さえ十分あれば、どんなバグも深刻ではない

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

ところで、OSI (Open Source Initiative) という団体が認めたライセンスに合致したソフトしか「オープンソース」としては言わないとかという面倒くさい主張もあるんですが、ここでは「ソースコードが公開されていて、改変・再配布などの自由も認められているソフト」程度の意味で使います。
特に後で出てくる OpenDolphin に関しては、当初は GPL という OSI お墨付きのライセンスが適用されていましたが、現在ではそうなってはいません。
この話は説明しだすと長いのでここでは詳しくは触れませんが、経過を追うと日本においてオープンソースのソフトが成立しにくいと言われる理由がよくわかると思います。

話が横道に逸れました。オープンソースそのものの定義とかという半ば宗教論争みたいな議論をここでしたいわけではありません。
ソースコードが公開されていること、それを自由に改変してもかまわないことという特徴からどんなメリットが生まれてくるのでしょうか。
ここでは、この点に注目します。
実際、ユーザー視点や運営視点に立つと、ライセンスがどーのこーのと難しく考えるより、ソースコードを自由にいじれるかどうかという視点でみた方がわかりやすかったりします。

例を一つ。

Dynamics(ダイナミクス)

医療用のソフトの領域で Dynamics(ダイナミクス)という電子カルテ&レセコンのソフトがあります。


画像はHPトップのものですが、”開業医が開発した診療所発のソフト” とあるように、メーカー製のソフトの使いにくさに嫌気がさした診療所の先生が独自に作成し発展してきたソフトです。

だから、コミュニティ運営的は診療所開業医の先生方の相互扶助的な面が重視されています。「データの囲い込み」などもちろん持ってのほか。
HPにはこんな記載もあります。

Dynamics はプログラム内容などをすべてオープンにしていますので、ちょっとしたプログラムの知識があれば、好きなように画面や文字をレイアウトしたり、データを抽出したり、ときにはオリジナルの機能なども追加することが可能です。
このウィッキッキサイトでは全国のダイナユーザーが作成した独自プログラムやノウハウが多数、掲載されております。Dynamics の機能にはなくても、このウィッキッキサイトで解決するようなプログラムもあるかもしれません。是非、ご活用ください。

ね。開業医さんの立場にたてば、活用してみたくなるでしょう?

このような経緯があるので、ダイナミクス自体は OSI 認定のライセンスではライセンスされていません。
あくまで商用ユーザーにソースコードを公開しているのみです。
ですが、ソースコードを自由に改変してもいいという特徴は十分に「オープンソース」的です。
そして、この特徴は対象となるユーザーを何か強く惹きつけるところがあるようです。

実際、このダイナミクスというソフト、数あるメーカー製のソフトに負けない人気があります。導入数ランキングや購入後満足度ランキングなどでは、例年、上位にきています。

1998 年頃より配布を開始して、現在は導入実績が 4000 超。
データベースが MicroSoft Access に依存しているため windows OS でしか動かなくて不便とか電子カルテ部が使いにくいといった声もありますが、立派なものです。

これは、OpenDolphin(オープンドルフィン)という電子カルテと比較した場合、顕著になるでしょうか。

OpenDolphin(オープンドルフィン)

OpenDolphin という電子カルテがどういうものなのかは見てもらった方が早いでしょうか。

使ったことのない人にうまく伝わるかわかりませんが、ダイナミクスより UI などは凝ってますし、医師目線でもかなり使いやすい電子カルテです。

ライセンス的な観点でいううと、一時期の OpenDolphin は、GPL でライセンスされていたオープンソースの ORCA 連動型電子カルテでした(ただし、現在ではこのプロジェクトが GPL として妥当であったかは疑問が呈されているし、運営している会社も何度か変わっていますが、変わるたびに、この点に関してはむしろ同様に否定的な見解を示しいています)。

(一時時的だったとはいえ)OSI お墨付きのライセンスはあるし、ユーザーフレンドリーな設計だしで、普及しそうな要素はあったと思うんですが、残念ながらそうはなりませんでした。

2000 年代に開発が活発化し、一時期は商用開発元から 200 程度出ていましたが、現在は販売を終了しています。
いわゆるクラウド型では命脈は保っているのですが、2018 年頃よりライセンスは曖昧になったまま、それ以降のバージョンのソースコードは開示はされていません。

実際には、商用開発元を経由せずに使われている例が多かったと思いますが、プロジェクト自体の発展やコミュニティの熟成という意味では、上手くいったとは言い難いものがあるかなあと思います。
この理由に関しては、ここでは触れませんが、いづれどこかの機会にでも書きたいと思います。

(参考)
OpenDolphin -wikipedia 風開設-ANN2B Blog
OpenDolphin-2.7m のこれからPHAZOR.JP Blog

オープンソースプロジェクトが成功する条件

ところで、冒頭で「目玉の数さえ十分あれば、どんなバグも深刻ではない」という箴言を引用しましたが、この言葉は「目玉の数が不十分な場合、バグは深刻なものになりうる」とも取れるでしょう。

やはり、ユーザーの数や活発なコミュニティが重要なんですね。

オープンソースの成功例としてよくあげられる Linux カーネルの開発は、この条件をよく満たしていると思います。
これはソフト自体の特徴、つまり

・誰もが使う機会が多く、汎用的である

・システムの基本部分を受け持ち、透明性への要求が高い

ことから、この要求を満たしやすかったんでしょうね。

一方、医療系のソフトはなかなかこの条件を満たしにくいですね。
ORCA, OpenDolphin, OsiriX は三種の神器だったのか?』あたりも参考にしてください。
かつてはオープンソースであったがクローズドなプロジェクトになったもの、もはやその運営形態を維持できなくなったもの、などの具体例を解説しています。

 

猪股弘明
医師(精神科医:精神保健指定医)
OpenDolphin-2.7m : developer
HorliX : developer
Horos : contributor
OsiriX(open-source version) : contributor

お知らせです 2021/01/27

まったく予定していなかったのだが、新年そうそう書き物することが多かったので軽くまとめ。

感染症 SEIR モデル関係

感染症数理モデルの基本 SEIR をなるべく数式に頼らずに直感的に理解する
とにかくわかりやすく書いた。

無症候性感染者が増えると感染爆発がおこるリスクが増大する
現在(2021年1月)は、昨年春先と感染状況が違うと思うが、何が違うか?何に注目しなければいけないか?をちょっと踏み込んで書いてみた。

きっかけはこれ

Metal 関係

Metal 入門 -初めの一歩-
MacOS/iOS のグラフィック API Metal に関する初歩的内容。
勉強がてら物色していると海外サイトでは Swift の PlayGround で metal のシェーダーをベタ書きする手法がよくみられていたのだが、日本ではあまり見かけない。Metal の基本を学ぶにはこちらの方が理解しやすいと思い、この手法を採用。
サンプルコードもそれに沿って書きおこした。
ついででその解説動画も撮った。日本語で書かれた Metal 関係の記事としてはかなりわかりやすいと思う。

Apple 製品との付き合い方

iPad アプリが落ちる場合、あれこれ試行錯誤するより返品できるなら返品した方が吉
当初は、タイトル通り iPad でアプリで落ちる場合の対処方法を意図していたのだが、ネット上で「交換」や「返品」に言及している記事が少なく(というかまったく見かけなかった)そこらへん厚めの記載になりました。
アップルは勝負所で「攻めた」製品を市場に投入してくるので、不良品も多いはずなんだが、マカーはあまりそういうこと言いませんね。
ちなみに私は Mac は「アップルがつくった Unix マシン」と思っているタイプの人間でマカーでもなんでもないです。ダメな時はダメと言います。
サポートの第一段階のよくわからないフリへの対処方法やラスボスに至るまでなどの話は機会があったら。

OpenDolphin 関係

OpenDolphin コード解説 -FileBackUpSystem と電子カルテのデータ構造-
そこでも書いてますが、これまでの問い合わせを考慮して実際のソースコードを参照しながら、より具体的により体系的にわかりやすく解説してみました。

OpenDolphin-2.7m を M1 Mac にインストールする
タイトル通り。M1(Arm) Mac が評判いいので、M1 Mac への OpenDolphin のインストール&デプロイを試みた。

OpenDolphin-wiki 風解説-
本家(いわゆる dolphin-dev)の著作権表記や運営形態におかしな点があるのではないかと以前から言われていたのだが、とりあえず github リポジトリ上で目についた点を調べ始めた。予想より多かったというのが率直な印象。

OpenDolphin と GitHub
着手。あれこれ言う人もいるかと思いますが、商標権諸々を持っているメドレー自体が「ソースコードは公開も開示もしなくていい。名称も使っていい」とほぼほぼ言っているから。

 

今後は、noteYouTube も活用していきたい。

 

猪股弘明
医師:精神科(精神保健指定医)