1台の Mac でマルチアカウントで homebrew を使う

為替の関係なのか apple 製品値上げしそう。

というわけで現在主流である arm 系の Mac をホイホイ買うことが難しくなった。

そうなると当然1台の Mac を複数人で「仲良く」共有ということになる。
本当にできるかどうかは別にしてw

ちょっと引っかかったのは Mac の定番パッケージマネージャー homebrew を複数アカウントで使うとパーミッションの関係で色々と不具合が出るという問題。

ググってみたが、「個々のアカウントのホームにそれぞれ homebrew をインストールする」というのが一番シンプルな解決法のようだ。

なので、ホームに homebrew フォルダをつくり、そこに homebrew を展開して使ってもらうことにした。

$ cd ~
$ mkdir homebrew
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew

これに合わせて、.zprofile に以下の一行を追加。

export PATH=$HOME/homebrew/bin:$PATH

本来の brew コマンドより「優先して」自分の brew コマンドが動くようにする、という理屈ですね。

 

トミーと言ったら、玩具?

Tomcat に JavaEE(JakartaEE) の仕様を追加実装した TomEE というサーブレットコンテナ(と言っていいものなのか?)があるらしい。

なんでも EJB や CDI はおろか JPA も使えるとのことだ。

若い人たちが、あれこれ試していたんだが、JPA のところで突っかかったらしい。

元コードみたけど、「そのやり方は、データベースをローカルで繋ぐときのやり方でしょ? 多分、EE っぽいアプローチは・・・」とやっていったら、まあなんとか動いた。

彼らは、Movie というエンティティを hibernate を介してデータベースに永続化したかったらしいのだが、案の定というべきか Movie2 だの Movie3 だのが大量発生していたw

袋小路に入ったら、「何か根本から考え違いをしている場合が多い」って考えた方がいい。

今回はデータソースの設定を見直すくらいでなんとかなりました。

 

 

PNG連番画像からGIFパラパラアニメをつくる

PNG連番画像からGIFパラパラアニメをつくるのはたまにやるのだが、Mac だと ffmpeg を使うのが便利。
だが、引数の指定方法はけっこう忘れてしまい、その度にググったりするので、忘備録的にメモ。

まず、ffmpeg だが、作業する Mac マシンにインストールされてない場合は、例えば homebrew を使って

brew install ffmpeg

でインストール。

000.png, 001.png, 002png ・・・・ と連番が3桁の場合には、

ffmpeg -i %3d.png -vf palettegen palette.png

として、まず palette.png を生成させる。
連番が4桁のときは、%4d で指定。ここらへんの引数の渡し方は C 系っぽい(単なる感想)。

次に

ffmpeg -f image2 -r 20 -i %3d.png -i palette.png -filter_complex paletteuse robo-umamusume.gif

として、GIFパラパラアニメを作る。

また -r は FPS(Frames Per Second) を指定しているので、例えば、r = 1 とすると1秒毎に画像が切り替わるGIFアニメが得られる。上の場合は 20fps になる。

 

air-h-128k-il

保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について

こういうのをタナボタというのだろうか、かねてから小林慎治(当時、京都大所属)という人から 「OpenOcean は GPL に違反している」という根も葉もない批難を受けていたのだが、別系統でこの件に関して彼の現所属組織(保健医療科学院)から謝罪のメールをいただいた。

単なる彼の事実誤認だと思っていたのとネット上での彼に関するあまり良くない噂(ただし、これ患者さんが一方的にー京都大学ではなくー愛媛大第一内科の小林慎治という名の医師を罵っているだけなので、この情報を頭から信用している訳ではないです)から個人的に関わりたくないと思い放置していたのだが、OpenOcean とは別件のオープンソースのプロジェクトで何かトラブルを起こしたらしく、当方にも現所属先の保健医療科学院の幹部の方から事実確認などの照会を受けた。

なるべく主観的な感情などを入れず、事実と明らかに異なる点に関していくつか返答させてもらった。

そのうちのいくつかを書いておくと

・彼は www.moss.gr.jp というサイトで
「OpenOcean は dolphin-dev の Fork の Fork の Fork」
と紹介していたのだが、これは完全に誤り。
dolphin-dev/opendolphin → Hiroaki-Inomata/OpenDolphin-2.7mOpenOcean
の順で Fork しているので明らかに一つ多い。正確には Fork の Fork。

・「(皆川和史という人の)著作権表示を隠蔽しているから GPL 違反」という主張をしているのだが、おそらくこれはスプラッシュ画面で (C) air-h-128k-il という表示をしたことに起因していると思う。が、これに関しては当時の LSC に確認を取ったところ「配布元がわかりにくくなるので、むしろスプラッシュ画面の(C) 表示は変えてくれ」という返答をもらっていた。その旨の回答をさせてもらった。
また、ついでで言っておくと LSC からは「皆川は現在では会社にも出勤しておらず、OpenDolphin の担当ではないから、気にしなくてもいい」という回答ももらっている。
さらにいうと、現在では、後期 LSC やメドレーからは「皆川が OpenDolphin の著作権者であるという主張はかつてはなされていたが、現在では確かめる術もない。いわゆる原始著作権者ではなく、著作権表示を契約上保持していただけのようだ」との回答をもらっている。
(要するに皆川は本来の意味での著作権者ではないという示唆です。あれだけのコード量ですから、全部が全部皆川さんが書いたとは私も思ってませんが、当初考えていたよりコードを著作権ごと買い取っていた部分が多かったようです。もちろん、こういった部分の著作権は今後は-契約にもよるのですが-メドレーが保持することになります)

・上に関することでもあるが、GitHub 上で「一般公開」していたソースコード上では、author 表示の類は一切変えていない。

・GitHub 上で OpenOcean のメンテナをしていた際、小林慎治がプルリクエストを送ってきたのだが、一方的に「マージせよ」と言い張るのみで迷惑したこと。(一般的にオープンソースのプロジェクトでは、メンテナがレビューしたのち、メンテナの責任においてマージする)

と言ったところだろうか。
他にも細かい点も指摘したのだが、主な点はそんなところだろうか。

保健医療科学院の担当の方はかなり丁寧に調べてくれたようで、他のプロジェクトの関係者にも調査をしてくれたようだ。
もちろん、他のプロジェクトの調査内容の詳細は私はわからないのだが、なかには、法律違反を煽る内容もあったとか。
何が決定打になったかわからないが、結果としては「国家公務員法違反(守秘義務違反、信用失墜行為の禁止、政治的行為の制限に関する違反)の疑いがあるので厳重注意をした」という処分になったということだ。

なお、担当者からのメールには「不快な思いをさせて申し訳ありません」という謝罪の言葉も添えられていた。
この言葉には、いくらか救われた。有り難かったですね。

 

air-h-128k-il

(参考1)これは特に誰というわけではないですが、けっこう SNS のアイコンなどに無頓着な人がいるようなので、一般的なお願いということで挙げておきます。

著作権法違反が疑われるコメントの掲載はできかねます

(参考2)ちょっとマニアックですが GitHub も SNS 的要素はあります。プルリクエストを送る場合やイシューを立てる場合、内容もさることながら、アイコンなどにもやはり気を使いましょう。

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

(補足)若干、マニアックな内容なのでわかりにくいかもしれません。
プログラムで表記される (C) マークについて(すごく大雑把にいうと)、これは通常は「財産権としての著作権を管理している組織若しくは個人」を表示していると理解されていると思います。LSC やメドレーの担当者が「配布元がわかりにくくなるので、むしろスプラッシュ画面の(C) 表示は変えてくれ」と言っていたのはこの考えが背後にあるためでしょう。
もうちょっとわかりやすい例でいうと適当なPCでコマンドラインを操作しているときに

(C) Microsoft
(C) FSF

といった表示が出てくることがあります。
これは「このシステムや個々のコマンドの著作権を管理しているのは、以下の組織です」と言った程度の意味です。
ライセンス上表記しなければならない人(著作者人格権を持っている法人や個人)がいたとしても、このような表記になっています。
なお、プログラムの著作権法上の取り扱いのかなり基本的なことですが、日本の著作権法の場合、ソースコードの著作者は法人であってもかまいません(ここが小説や歌謡曲などの文芸作品と違う点です)。必ずしも著作者=著作権者になるわけではないです。

もちろん、(C) マークとは別に、著作者人格権に基づく(and/or GPL などに基づく)クレジットをしなければならない場合も多いです。
ですが、これは、それが従うべき各国の法やライセンスに従って publish すればよい話で、著作権の、特に (C) マークの表記に関連づけて議論するような話ではありません。
特に上記の件では、説明したように当事者間で「それでよい」という合意ができている以上、第三者が口を挟むような案件ではありません。

 

MacOS に elmo + やねうら王 + 将棋ぶらうざQ を「clang」で導入

ひさしぶりの将棋ネタ。
Mac を触る時間が長くなってきたので、将棋 AI も刷新したくなったから(過去に「技巧」を入れてます)。

導入方法の基本的な流れ自体は、
Mac にコンピュータ将棋ソフト「elmo」を導入した
MacOS に elmo + やねうら王 + 将棋ぶらうざQ をインストールする
あたりをご参考に。

ただ、やねさんの Makefile を見たら、

# clangでコンパイルしたほうがgccより数%速いっぽい。
#COMPILER = g++
COMPILER = clang++

 

とデフォルト設定で clang になっている。
何もわざわざ gcc に変えなくても良いのでは?
(ただし、llvm は諸々の事情で ver10 を使ってますが、デフォの llvm でも実行ファイルはできてました。gcc とか llvm とかよくわからんという人はこちらなども参照ください)

あとは、標準ライブラリを stdlibc++ ではなく libc++ に変えただけ。

こんだけで、一応、ビルドできましたが。

 

なお、アイキャッチは、藤井(聡太)-渡辺(明)棋聖戦第二局で藤井七段(当時)が△三1銀打と金取りを受けたところ。

 

解析させると AI 的にもここから流れが変わったのがわかりますね。

 

 

air-h-128k-il

 

北極圏コード貯蔵庫コントリビューター -Arctic Code Vault Contributor-

GitHub が北極圏にデータセンターみたいなのをつくって、そこに GitHub 上にあるほぼ全てのリボジトリのスナップショットを収蔵したらしい。
【参考】『Arctic Code Vault が実施段階へ突入』(GitHub ブログ)

MS すげーな。

また、このとき収められたリポジトリのオーナーやそれらプロジェクトにソースコードを(正式な形で)提供した者には、

Arctic Code Vault Contributor

の肩書きが与えられたようだ。「北極圏コード貯蔵庫コントリビューター」とでも訳せばいいだろうか。

私も OsiriX や Horos にはソースコードを提供したことがあるので、認定されたようだ。
大したものではないが、ちょっとは誇らしい気持ちになれる。

最近(2021 上半期)だと専用ロゴ?もついた。

air-h-128k-il

 

OpenBSD で GCC が廃止・Clang/LLVM に移行

タイトルの通り、とうとう OpenBSD 6.6 で、GCC が廃止・LLVM/Clang に移行になったようです。

OpenBSD 6.6登場、GCCの廃止とLLVM Clangへの移行進む

はっきりいって地味なネタ。実際、普通にパソコン使っている限りにおいては、何の影響もでないでしょう。

ちょっと関係するとすれば、Mac ユーザー(の中でも開発よりの人)。

ご存知のように OS X (MacOS)は、BSD(というUnix OS)の上に Cocoa というレイヤーを被せたかっこうになっている。
もともとアップルは Clang/LLVM 推しで、Objective-C(++) においては、.m と .mm (++ では拡張子はこちら) コードを Clang →LLVM という流れでビルドする。
なお、Objective-C(++) は C(++) の上位互換とされており、通常の C(++) の文法でコードを書いてもコンパイルはできる。
だから、実務的には、ソースが C(++) だったとしても拡張子を m や mm にしておいた方がいい

Clang がフロントエンドでソースコードの解析を担当し、LLVM(元は Low Level Virtual Machine の略。今は何の略でもないとされていいる)がバックエンドとなり、最終的な機械語コードを吐き出す。
また、LLVM は Virtual Machine から連想されるように Java と同様、特定のマシンから独立した中間コードをまず生成し、次にそれを各々のマシン向けの機械語に変換するという仕組みになっている。

話が逸れた。

世界が Mac だけで完結しているのなら Clnag/LLVM でもいいのだが、デスクトップPCのシェアは MS Windows の方が上で、Windows 向けに書かれた C++プログラムを Mac 上で動かしたいということはよくある。そのような場合、困ったことがおこることがある。
GCC や Windows C コンパイラにはある機能が、実際には Clang/LLVM にないことが度々あるからだ。
そのような場合は、GNU の GCC の使用を余儀なくされるわけだが、今後はその点でさらに使いにくくなるかもってことです。

【参考】Mac で技巧2を使う

air-h-128k-il

奇跡のコード

先日、IT 関係に詳しい出版関係の方とお話していたとき、私が「ああ、あのプロジェクトは、奇跡のソフトで…」と発言したとき、その方から「奇跡とはどういう意味なんですか?」とより詳しい説明を求められた。

その方は、IT に詳しいとはいえ、実際にプログラマや SE として働いたことはなく、その点に関しては一般の人と変わらない。そのとき「一般の人の感覚ってこんなもんなんだ」と認識を新たにしたので、そのことに関して書く。

あるソフトが「動くには動いているのだが、度重なるソースの改変で、もはや常人にはロジックを追うことすら難しく、たとえプロジェクトマネージャーであっても、なんで正常に動いているのかよくわからない」とき、半ば揶揄の意味を込めて「奇跡のソフト」とか「奇跡のコード」とかという言い方をする。

「でも、そういうのはアマチュアや日曜プログラマが作ったソフトで、メーカーが作るソフトにそういうのはないでしょう」という声が聞こえてきそうだが、これもちょっと違う。最近は諸々の事情もあって、かなり有名なメーカーがリリースしたソフトでも、「奇跡のコード」が含まれている可能性はあると思う。

これに関しては、あまり一般的なことを言ってもしょうがないような気がするので、昔、関わったプロジェクトを例に語りたい。

 

分類:創薬支援ソフト

特徴:薬剤候補化合物を Web 画面から投入、官能基を変化させた類似化合物などを自動的に表示、また、その物理化学的性質をシミュレーションした上で表示

経緯:某大学計算化学研究室で開発→某化学系業界団体が支援→大手N社が Web アプリに改変して販売→某大手製薬企業が購入→バグ発覚→支払いでトラブル→両者膠着状態

 

もう10年以上も前の話なので、より詳しく書いても問題ないと思うが、念のため、かなりぼかして書いた。

たぶん、業界に通じている方なら、「某大学計算化学研究室で開発」あたりで危険な香りを感じていると思う。大学研究室は、一般の人が考えるほど研究の継続性はそれほど高くなく、担当院生が卒業してしまうとその部分に精通した人間が一人もいなくなってしまうということはザラだ。実際、このケースでも(後でわかったことだが)原因はそれであった。

上のように経緯をはっきり書いてしまうとわかると思うのだが、N社はこのソフトに関して Web アプリ化したのみで基本的な部分にはいっさい関わっていない。というか、製品全体に渡って一貫して関わっている技術者は一人もいない。大手リリースの製品であっても「奇跡のソフト」が生まれる余地があると書いたのはこういった事情による。

また、上記案件では、Web アプリといっても企業内 LAN 使用が前提のため、tom…ナントカ あたりでことがすんでいたのだが、N 社の経営陣が気まぐれで「これからはネット社会。どうせ Web アプリ化するなら、外部公開も前提に REST も実装しておいてくれ。VPN もお忘れなく(にっこり)」などと言った場合、もっと悲惨なことになっていたことは想像に難くない。(まあ、この時点では REST はなかったわけだが)このとき N 社プロダクトマネージャー(PM)が、例えば、その仕事を外注に出したとしても、また、それが原因で、その後、REST 周りが奇跡のコード化しようとも、私には、この PM を単純に責める気になれない。現代にあって、有償のソフトを限られた時間内でリリースするのは、相当、プレッシャーがかかることなのだ。

なお、上記プロジェクトは、その後、デバッグ作業が外注に出され

  • 大学教養〜学部レベルの化学の知識のあるもの
  • 医学・薬学に関して実務経験かそれに相当する知識のあるもの
  • 一般的なプログラミングのスキルがあるもの
  • 計算化学特有のロジック・アルゴリズムを追える能力のあるもの
  • 主要開発言語である Fortran の経験があるか短期間で習得可能なもの

といった選抜条件の下、東欧系やインド系の会社とのバトルを勝ち抜いた国内某ソフトハウスが受注。紆余曲折を経て、当時、フリーであった私がデバッグ作業を担当することになった、という次第だ。

なお、デバッグ自体は、まあまあ上手くいき、ごまかしごまかし動くといった程度までには回復した。が、完全に狙った動作を実現する実装ができたかというと、そこまでは至らなかった。奇跡のコードはどこまでいっても奇跡のコードなのだ。

 

開発元がバグを認識していても、なかなか改善されない、とか、自称「開発者」がバグを直したつもりになっても、全然直っていない、とかといった現象を目の当たりすると、一般の人は、不思議に思うかもしれない。が、背景にある国際分業化とか業務の外注化といった状況を考慮すると、しごく真っ当な事情があったりするのだ。

以上、デバッグだとかバグフィックスだとかに関する IT 業界の昔話でした。

air-h-128k-il

 

にほんブログ村 病気ブログ 医者・医師へ

設計図共有サイト

日経新聞が、github のことを「設計図共有サイト」と紹介して、そのネーミングセンスが一時期ネットで話題になった。

「これだから日本のマスコミの IT リテラシーは….」とかなり揶揄っぽい意見が多かったが、確かに github 的な文化が日本に完全に定着しているとは思えない。

私もいくつかのプロジェクトに参加させてもらっているが、やはり海外の有力プロジェクトは参加がしやすい。

例えば、リポジトリのブランチ構成にしても、「本流」ブランチと「開発者用」ブランチを分けていて、どこにプルリクエストを送ればいいのかわかりやすい。

一方、日本のプロジェクトは、本流ブランチ一つだけ、過去の履歴は一切なし、更新するときは、いったんリポジトリを全消去して、ローカルファイル強制プッシュ、みたいなものが多い。

オープンソースかもしれないが、「共有」する気はいっさいないよね(笑)。

ポーズで「github にソースは公開してます。オープンソースです」ってアピールしてるだけ。

 

また、github は github.jp のようなサイトがないことからわかるように(→その後、github.co.jp というのが開設されたようです。周囲で使っている人見たことないけど)、国際的な地域差を意識する機会が少なく、国際化の文脈で語られることも多い。しかし、日本産のプロジェクトは、これもアピール的な要素として利用されることが多く、例えば、外国の方が issue 欄に書き込んでいるにもかかわらず、ガン無視をきめこんでいるプロジェクトがけっこうある。国内にとどまっている限りにおいては、これでもいいのかもしれないが、その後、他言語リソースが欲しいとか外国の参加者を増やしたいという時に、こういった態度はブーメランのように自分に返ってくる。

なので、私は、外国の方が書き込んでくれた場合には、精一杯のおもてなし精神を発揮するようにしている。

Wow…your idea is great!

とか、なんか無理めのレスをつける。日常生活で ’Wow’ なんて言ったことは生まれてこのかた一度もないが。

github は便利な環境だが、上記のようなアピール的な使い方をしていたのでは、少々、もったいないような気がするのだ。

air-h-128k-il

 

電子カルテ Dolphin Evolution をテスト

JavaFX に若干興味があったので UI が JavaFX で書かれているという Dolphin Evolution™ (Karte Cloud ともいうらしい。開発元はエスアンドアイ株式会社)というオープンソースの電子カルテを試してみた。

 

ソースは github から落とす。

UI が知りたいだけなので今回は client のみコンパイル。

pom.xml を自分の環境に合わせ、適宜修正。NetBeans でビルド。実行すると…

ログインパネルはこっちの方が好みかもしれない。

ついでにサーバを立ち上げ、ログインを試みる。データ構造や通信プロトコル自体は本家と同じらしく、若干エラーは出たものの問題なくつながる。定番の徳川さんを表示。

初期設定は全画面表示だったので、けっこうびびる。

確かに画面構成は通常のドルフィンとは違う。ウィンドウをぱかぱか開くより一画面で操作を完結させたいという意図のようだ。

だが、結局使い慣れたサイズで使用(笑)。

そんなわけで操作上は JavaFX の有難みをそんなに感じることはなかったのだが、JavaFX ではこの手の UI のつくりこみが swing に比べ簡単になるという。

諸々の事情で Java で何かを新規につくるということはもうないかもしれないが、今後も横目でちらちらとチェックくらいはしていきたいものだ。

変更したコードはこちら