カテゴリー: IT

投稿日:

曖昧な日本のユーザー

私の所属する会社（休眠がちだが）は、集まったメンバー（学生バイト含む）の仲がよく、とてもよくまとまっていると思う。
この点に関してはなんの不満もないのだが、リリースしたソフトのユーザーについては、なんの不満もないかと言われるとちょっと微妙。

お行儀の良いユーザーたち

ユーザーに関しては、一般的な水準で見れば良質だとは思う。なにしろクレーマーのようなユーザーは一人もいなかった。みんな、お行儀よい。おとなしいと言っていいかもしれない。
無い物ねだりかもしれないが、おとなしすぎて物足りない感じは正直ある。

例えば、OpenDolphin-2.7m 系列（ただし、これは代表のまったくの個人制作）に関しては、最近のユーザーの関心はもっぱらデータ移行だろう。
具体的にどことは言わないが基本設計自体がもはや古臭く、新規の導入は勧めていないし、私たちの興味も「標準型電子カルテ」を意識した新規のシステムに向かっていて、実際、2.7m シリーズはメンテ程度しかやっていない。
だから、データ移行の必要が生じた際には「◯ヶ月程度を目処に、XXという電子カルテ向けにデータコンバートしてほしい」と明快に意思表示してもらわないと動きようがないのだ。準備にもそれなりの時間がかかるのだから。
どうも見ていると、OpenDolphin HTML/PDF Viewer あたりをばら撒いてくれることを期待しているようなのだ。
あちこちで「できない」とはっきりと言っていると思うんだけど？

Q4 データ移行ツールのバイナリ・ソースコードなどは配布・公開しないのか？

A4 これ、過去に商用開発元の方から似たような要望を受けたことがあります。 一瞬、私もそうしようかと思いました。が、

OpenDolphin のカルテを途中経過版も含めて一括書き出し

→途中経過版の一部を削除など加工

→加工したデータを再度、OpenDolphin などの電子カルテデータベースに戻す

という使い方をしてしまうと立派な「改竄」ツールになってしまうので、思い直してやめました。”

『OpenDolphin-2.7m（系列）FAQ』より

これはおそらく
・以前に実行可能なファイルバックアップシステム付き OpenDolphin-2.7m クライアント
（いわゆる OpenOcean クライアント）を無料で配布した
・オープンソースプロダクツに「無料」というニュアンスを強く感じている
から、「どうせ、そのうち無料で配布してくれるんだろう」と安心しちゃっているからなのかなあと思う。

大事なことなので２回言いますが、ないですよ。

あとメンズ陣がたまに言うには「全然、勉強してないし、その痕跡も見せない。作業現場に来て暗い感じで、突っ立っているようなものなので、何も言葉がかけられない」んだそうだ。
ここら辺は、彼らはシビアだ。

与えられることに慣れすぎていると・・・

私たちのグループに専業従事者は一人もいない。

だから、ユーザーが反応してくれない箇所などは最悪放置すらあり得る。

日本のユーザーは、成熟したメーカーのそれなりによくできた製品（尖った部分はないが全体として８０点みたいな製品）を使うことに慣れている。サポートも手厚い。
私の個人的な印象かもしれないが、アメリカはここら辺はかなり違う。
名もなきベンチャーのピーキーな製品がしれっと販売され、一般市民もそれにチャレンジする。いかにダメな部分があろうが、魅力的な機能があれば、その製品のファンになってくれる。

このような消費行動の差が、日本のユーザーの一種の甘えにつながっているのかもしれない。

人生の多くの場面で当てはまることかもしれないが、「与えられることに慣れすぎている」と何かを失うのかもしれない。

 

AXIA

投稿日:

反オープンソース評論家

常々、「IT 評論家」のような人が嫌いだった。

特にオープンソース評論家のような人は、その主張が激しく界隈ではある種の「武闘派」とみなされていると思う。

その点で、いわゆる OpenOcean 騒動はチェックしていた。
OpenOcean 騒動というのは、air-h-128k-il さんたちが OpenDolphin という GPL でライセンスされた電子カルテの独自カスタマイズバージョン OpenOcean をソース・バイナリともに公開・配布した際に、小林慎治（医師、現岐阜大医学部特任講師）というオープンソース評論家のような人が、「OpenOcean は GPL に違反している！」と難癖つけた事件のことだ。

この難癖というのがなんと言っていいやら・・・。

まあ、トンデモの類。

最近になって、当時の開発陣からかなりまとまった反論が提出されている。
（例えば『小林慎治氏の OpenOcean に関する事実誤認』、『OpenOcean 騒動』、『OpenOcean 騒動 #27』）

ここで注目したいのは、オープンソースの責任性について。

彼は怪文書の中で言っている。

OpenOceanのWebには2018年12月までの試用期間であると記載とされています。ユーザーはこの指示に従うべきものとも考えられますが、このままだと使用期限が近づいてもクライアントに何の警告も表示されずに2019年1月以降起動しなくなってしまいます。GUIなインタラクティブメニューを持つソフトウェアであれば、1ヶ月以上前から警告を表示しておくのが親切ではないでしょうか。
Webに記載される試用期間を見落とすほうが悪いのかもしれませんが、使用期限を過ぎて起動しないソフトウェアに対してどのように対処すべきかも書かれていませんので、ユーザーである医師には対応できずに医療事故につながる危険性があります。

ここだけ取り出すと提案の一つとしてあってもいいかなと思えなくもないが、実際に彼の取った行動は理解不能。

なんと、使用期限に関するコードを削除したものをプルリクエスト（PR）として OpenOcean リポジトリに送ってしまったのだった。「残り X 日です」とアラートウインドウを出すような実務的なコードではなくて。
その PR は今もリポジトリに記録されている。こういうものだ。

expired() というメソッドで使用期限を設定しているわけだが、この機能に関するコードを削除しただけ。

すごいでしょ。

issue あたりで改善要望出しておけばいいだけだし、そんなに使用期限がいやなら使用期限のないバージョンを自分でビルドしてユーザーに提供すればいいだけ。後者は、ほぼパクリとも言える行為だが、air さんたちだったら許していたと思う。

その一方で怪文書は、

第三者にその製品を提供することは著作権法が定める頒布権の侵害であり、公衆の場であるGitHubにソースコードを置くことは著作権法が定める公衆送信権侵害です。

とソースコードの公開停止を主張している。
PR 送ったのが 2018/11/4 で、怪文書が公開されたのが 2018/11/26 のことだ。
俗っぽい言い方をするならば「PR がマージされなかったので、逆ギレして公開停止を主張した」ということになる。

ところで、そもそもオープンソースは、ビルド産物に関しては責任は限定的だし無保証だ。
この点に関してある人が面白いことを言っていた。

OpenOceanの試用期限表示とオープンソースの責任について

1. OpenOceanの試用期限表示について

OpenOcean配布サイトには「使用期限は、2018/12/31 までです。」と明記されているので、「警告なく起動しなくなる仕様」という批判は不当であると言えます。情報が公開されていた以上、利用者はその条件を理解した上で使用を開始する責任があります。

2. オープンソースにおける開発者の責任について

多くのオープンソースソフトウェア（OSS）のライセンスには、開発者による保証の放棄（無保証）と責任の限定が明確に記載されています。

無保証の原則: OSSは一般的に「あるがまま（as-is）」で提供され、品質保証や機能保証は行われません。利用者は自己責任においてソフトウェアの品質や安全性を確認し、利用する必要があります。

責任の限定: ほとんどのOSSライセンスは、開発者がソフトウェアの利用によって生じた損害に対して責任を負わない旨を規定しています。これは、オープンソース活動がボランティアベースで行われることが多く、開発者に過度な負担をかけないための措置でもあります。

新機能の搭載: 開発者が責任に限定的である立場にあるからこそ、新機能や実験的な仕様を導入しやすいという側面があります。

実際、OpenOcean には、ファイルバックアップ機能などそれまでのドルフィンになかった新機能が搭載されていた。

どれが正しいのだかもわかりにくい著作権表記だのでワーワー騒いで、OpenOcean 開発陣からユーザーによる新機能の評価を得る機会を奪ってしまった。

「小林慎治はオープンソースの足を引っ張っているだけ」という批判がなされている一つの根拠になっている。

おそらくこの人のスキルからしてオープンソースといった開発現場に近い位置での論評は無理がある。
それを自覚したのか、小林氏、最近では初学者向けに「医療Dx」に関して語ることが多く、一時の「オープンソース」偏重とは異なる態度をとっている。
言い方を変えれば、実務家が彼を「オープンソース」領域から追っ払ったとも言えるわけで、反「オープンソース評論家」のささやかな勝利といえるだろう。

 

（追記）本稿では、責任性について触れたが、私がのけぞったのは、そもそも怪文書の根拠となっていた著作権表記が改竄されたものであったという事実。
そして怪文書の「是正勧告」とやらに従った場合、まるでミステリのような犯罪が成立していたという指摘。
『OpenOcean 怪文書 -GPL 誤用による違法行為教唆-』に詳しく書かれていますので、興味のある方はそちらをご覧ください。
OSS は無保証・限定責任ですが、OSS に関して語ったことは語った人の責任です。
どう責任取るつもりなんでしょうか？
でも、この人のことだから、言いっ放しで終わりそう。

（追記２）X の TL みてたら、佐渡秀治という人が引っかかってきたようだ。

「流れは知らんけど」って。追補されているのだから、流れは重要だろう。
これ、反撃されるとみた。
→案の定、『OpenOcean 怪文書 – 適切な GPL 使用のために-』で追記されてた。
ところで、ネットで検索してたら、この人のことを評した情報はほとんどない。
あの言動では当然そうなるよなあというのが感想。

 

投稿日:

オープンソース考

「オープンソースの素晴らしさ」みたいな記事はどこにでも落ちていると思うので、ここでは書かない。
そうではなくてあの業界の性善説的な寛大さにつけこんでよからむことを考えている連中がいるので、それに関して述べる。

よく遊んでくれるお姉さんが書いた記事が印象に残っているので、まずは再録。（許可取ってます）

OPENSAUCE/OPENSOURCE

X(twitter)の投稿はそんなに頻繁にしておらず、だから、バズるみたいな現象とは無縁なのだが、例外的にこのポストにはちらほら反応があった。

要するに
「OPENSAUCE 社が公開レシピのプラットフォームとして OPENSAUCE を商標登録しようとしたが、OPENSOURCE が既に登録されていたため、拒絶された。
が、OPENSOURCE の使用実態がなかったため、不使用取消審判を請求した。
しかし、この件を OPENSOURCE 商標を保持している OSDN 社及び同社代表佐渡秀治が、誤解を招くようにアナウンスしている」
というものだ。
詳しく知りたい方は、リンク先の OPENSAUCE 社のこのページからどうぞ。

これを見つけた時の私の第一感は、（ポストにもそのニュアンスは出しているが）「うわぁ、またやっているよ」というもの。

以下、ちょっとした感想。

松尾研究室オープンソースAI事件とその副産物

また、というのは、ちょっと前に（時系列的には、これより後なんだが）生成AIで有名な松尾研究室が、同研究室開発のソフトを「オープンソース」と広報したときに、オープンソースな方々が「Creative Commons ライセンスは OSI 基準のオープンソースライセンスに当てはまらないので、この AI はオープンソースではない」と騒ぎを起こしたことがあったから。

ちなみにこの騒ぎは松尾研究室が「オープンソース」の旗を下ろすことで幕が降りた。

個人的には、（この手の論争はよく起こることなので一定の結論を出すという意味で）もっとやり合って欲しかったのだが、そこまでには至らず、松尾研究室が大人の対応をすることでこの件はクローズとなってしまったのだった。

だが、論争相手が現在勢いのある松尾研究室であったため、いくつかの副産物が生まれた。
X(twitter)を漁ればわかると思うが、かなり優秀な人々がこの件に関してコメントしている。この点はいつもの「オープンソース」論争とは一味違っていたのだ。

副産物の一つは、「open source という単語は、OSI などオープンソース関連団体が特別な意味を付与する以前から、『ソースコードが公開されている』程度の意味合いで普通に使われていた」という事実が発覚したことだ。

open も source もごく一般的な名詞にすぎない。
「ソースコードが公開されている」程度の意味で「open source」という一般単語組み合わせワードを使うことは、商標が成立する以前から使われていたわけだから、仮に商標があったとしても、禁じることはできない、というように解釈するのが普通だろう。

もう一つの大きな副産物は
「そもそも、プログラム領域では商標自体が成立していなかった」
というかなり身も蓋もないもの。
拒絶された理由も、わかりやすく書けば
「open も source も一般的に使われている。それらを組み合わせた open source は特別な知識なしでも「ソースコードが公開されている」という意味に解釈できるよね。なんでそんなものに特別な権利を与えなきゃならんの？」
とかなり明快だ。

佐渡秀治氏の立ち回りが政治的すぎて生理的に受け付けない

松尾事件勃発直後の末端オープンソース信者のおおよその反応は
「オープンソースTM の商標は我らが教祖様が保有しているのだから、松尾研究室のネーミングは法的にも許されない」
というような感じだった。

しかし、これは色んな意味で間違えている。
教祖様はプログラム領域では商標は保持していない。

私が佐渡氏に生理的な嫌悪感を持つのは、こういうときに「それは誤解であって、私は、プログラム領域では、商標保有者ではないんだよ」と直接信者には語らないから。
実際、そのことに触れた書き物は公開されていたりもするのだが、佐渡氏はこの存在にほとんど言及しない。

ある程度の誠実さがあるのなら、「商標的には成立していないが、ライセンス限定という意味でなら、オープンソースライセンスはその定義が広く普及しているのだから、その観点から松尾研のネーミングを検討してみてほしい」と言えばいいだけではないか？

それをしていないのは、彼や彼の取り巻きにとっては、信者に意図的に誤解させたままにしておくほうが都合がいいからなのだろう。

私は、こういった立ち回りを生理的に受け付けない。

なお、見出しは「佐渡、キモっ」という意味ではないので、念の為。

フォントなどは適宜改変した。

何でこの記事が興味深かったかというと、オープンソースの思想みたいなものに触れず、その周囲に生息している人たちのやり方に焦点を当て、その醜悪さにフォーカスしているから。

考えてみれば日本でバリバリにオープンソースプロジェクトに貢献している人はそれほどおらず、どちらかといえば「オープンソースは素晴らしい。そん活動に深くコミットしている私も素晴らしい」みたいなナルシスト活動家が多いのが実情だろう。

ナルシスティックに自分に酔っている程度なら実害は少ないのだがオープンソース利権までなっていたプロジェクトがあるので紹介したいのだが、これはまたの機会に。

 

秋葉

 

 

投稿日:

NSUserDefaults

サンプル

AppDelegate.m
@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Insert code here to initialize your application
    NSUserDefaults *ud = [NSUserDefaults standardUserDefaults]; // 取得
    [ud setObject:@"hoge" forKey:@"KEY_S"];
    [ud synchronize];
}

 

参考：https://glassonion.hatenablog.com/entry/20110920/1316473990

保存場所

Non SandBox: /Users/ユーザ名/Library/Preferences

SandBox: /Users/ユーザ名/Library/Containers/アプリ名/Data/Library/Preferences/

なのだそうだが、デバッグ時にそれらしいファイルはなかったな？？？

→registerDefaults メソッドはファイルに書き出しません！

しかし、standard と shared の違いがわからんなあ。

→shared は文字どおり「共有」ということらしい。
何と共有するかは、この記事によれば、同じグループ間で、ということらしいのだが、使ったことはない。

 

投稿日:

Objective-C 諸々

objective-c や cocoa の割と独自仕様っぽいところ。

delegate

見かける割にいまいち理解できていなかったデリゲート。

「MTKView のデリゲートがレンダラー」と気がつき、ああそういうことかと納得。

大抵の場合、ViewController が MTKView を呼び出す前に

_view.delegate = _renderer;

などとしているはずだ。

メタルの表示用ビューとして MTKView は存在しているが、各アプリでのこのビューの使い方は様々だろうから、そこら辺は自分で DrawInMTKView を実装してね、プロトコルは準備しておくから・・・ということなんだと思う。

わかりにくくなるのは、プロトコルが明示されているわけではないので、その仕組みに気が付きにくいからじゃないでしょうか。

本来であれば以下のような記述が必要なようだ。

委譲する側（のヘッダ）

@protocol HogeDelegate

@property (weak, nonatomic) id delegate;

@protpcol HogeDelegate <NSObject>
-(void)FugaMethod;
@end

以下のように明示的にぶん投げるときもある。

委譲する側（の .m ファイル）

[self.delegate FugaMethod] //こうやって使うようだ

ぶん投げられる側はプロトコル準拠を明示しておく。

委譲される側（のヘッダ）

@interface Fuga: NSObject <HogeDelegate>

ところで、これが面白いのは、ある種の情報の通知として利用できる点。
上の例なら、Hoge の情報を Fuga で受けられる。
ViewerController に受け持たせてしまい、あるオブジェクトでの情報をビューに反映させるといった使い方ができる。

参考：https://dev.classmethod.jp/articles/ios-delegate/

マルチスレッド処理

NSTread を使う方法、dispatch_async – queue の系を使う方法などいくつかあるようだ。

（続く）

KVO

https://qiita.com/mitsu9/items/e738c41a8d87cc71ec3e

KVOとはキー値監視(Key-Value Observing)のことを指します。
アプリ開発をかじったことのある人ならMVCという言葉を聞いたことがあると思いますが、KVOはModelの変更をControllerやViewに通知し、反映させるための仕組みです。
他の通知システムとしてはdelegateやNSNotificationを利用した方法などがあります。

なるほど。

サンプルとして MCV を意識したメモアプリあり。

インスタンス変数の宣言

『Objective-Cでは、インスタンス変数をどこに宣言するのが正しいのか？ 』が興味深かった。

やはり、みなさん疑問に思っていたんですね。

参考

phorlix100 の github issues 。
いやー、大変参考になりました！