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 で何かを新規につくるということはもうないかもしれないが、今後も横目でちらちらとチェックくらいはしていきたいものだ。

変更したコードはこちら

 

Responsive-Kifu 使い方

 

air
今日は、Responsive-Kifu の導入の仕方を解説するよ♪

 

github からソースを取ってくる

まず https://github.com/air-h-128k-il/Responsive-Kifu にいってソースを取ってきましょう。

git コマンドで取ってきてもいいのですが、普通の windows マシンなどで git コマンドが使えるとは思えないので、zip ファイルをダウンロードします。

ダウンロードフォルダに Responsive-Kifu-master.zip がダウンロードされているはずなので、適当な場所に解凍してください。

Responsive-Kifu-master というフォルダができるはずなので、適当な名前にリネームしてください。名前はなんでもかまいませんが、ここでは Responsive-Kifu とします。

サイトにアップロード

続いて FFFTP などを使ってお使いのレンタルサーバ上にアップロードしてください。アップロード場所はどこでもかまいませんが、ここではドメイン直下とします。このドメインでいえば、http(s)://phazor.info/Responsive-Kifu ですね。

この時点で Responsive-Kifu/html 内のサンプルページ pagagm584.html がブラウザからも見れるはずです。ブラウザで直接覗くとこんな感じ。もちろん操作もできます。

 

なお、局面はアゲアゲさんが飛車を振り直した15手目です、って関係ないか。




ワードプレスに取り込む

Responsive-Kifu をワードプレスの記事に反映させるには、基本的に上記の html ページをインラインフレームというもので取り込むだけです。いたって簡単。

WordPress の編集ページに進み、画面を「テキスト」編集に切り替えます。

ここで

<iframe src="../Responsive-Kifu/html/pagagm584.html" width="620" height="700" frameborder="0" scrolling="no">

と入力。src 以下は、pagagm584.html が指定できているのであれば形式は問いません。実際の画面ではこんな感じです。WordPress ユーザーにはおなじみの画面ですね。

ここでポスト。すると、実際の投稿記事は以下のようになります。

画面のサイズを変えると駒盤や駒もそれにあわせて大きさを変えると思います。
あとは、地の文を加えるなりなんなり、お好きなように編集してください。

とりあえず、サンプルページを表示させるやり方は以上のようになります。

 

お好きな kif ファイルを表示させたい場合も同様で、

 kif ファイルを data フォルダにアップロード

→html ファイル作成

→投稿ページから上記 html ファイルを取り込む

という流れになります。

air-h-128k-il

 

※…上記は WordPress での導入を前提に説明してありますが、iframe が使えるシステムであれば、原則、なんでもいけると思います。

・てんなんさんが、FC2 ブログで動かしています。

『Responsive-Kifuを貼り付けてみる』

・これは力作。ある時期ネット最強であった dcsyi さんの棋譜164局をこれもやはりてんなんさんが Responsive-Kifu で再現。

【dcsyi】Responsive-Kifuで棋譜164局表示してみる【伝説の棋譜】

・レア棋譜。

▲大橋宗桂 vs △本因坊算砂

・『令和時代』というサイトでひろしさんが、Unutu Server での導入の仕方を解説してくれています。

Resposive-Kifu

・moongift というオープンソースのソフトを紹介するサイトで Responsive-Kifu が取り上げられました。

Responsive-Kifu – レスポンシブ対応の将棋棋譜再生ビューワー

・これは画期的。まりんきょさんが、ソースコードを解析して適宜改変。結果、初期配置として任意の駒配置が設定できるようになりました。これで、詰将棋も表示可能となりました。
まりんきょさん自身が、有名な3手詰の詰将棋をサイトにあげています。

ちょっと難しめですが、まりんきょさんがおこなった改変の技術的な解説は

Responsive-Kifu の紹介

をご覧ください。

 

 


にほんブログ村 その他趣味ブログ 将棋へ

アゲアゲさんの名局をブログで再現してみる

クロノさん、アユムさんときたら、この方の対局も載せないわけにはいかない。

もとは、雁木対左美濃急戦のこの対局。

雁木 vs 左美濃急戦という戦型も興味深いが、やはり圧巻は最後の寄せ。

 ソフトなどで検討すると、決して最短ではないが、最も実践的な寄せ方をしているのがわかる。
最新の対局はこちら。


にほんブログ村 その他趣味ブログ 将棋へ

レスポンシブな棋譜再生ビューア Responsive-Kifu

WordPress 向けのレスポンシブな将棋棋譜再生ビューアつくってみました。
想像していない不具合はあるかと思いますが、以前に比べればかなりマシになったかと。
評判がよければ一般公開を考えますが、誰かメンテしてくれる人が欲しいです!

某所でけっこう「いいね」を集めたのでまずは github 上で公開しました。
https://github.com/air-h-128k-il/Responsive-Kifu

導入記事は『Responsive-Kifu 使い方』で解説してあります。
→ https://phazor.info/air/?p=1072

 

なお、棋譜は将棋実況系 Youtuber の人気者、chrono vs ayumu さんのものです。→ファイル見失いました。絶好調(プロ入りなるか?!→なったーー!!)、アゲアゲさんの棋譜に変更。現在は駒表記が英語になっております。外国の方から要望があったので。駒(盤も)は変更できますので、コメント欄を参照してください。

AWS 使ってみた

諸々の理由で AWS (Amazon Web Service)を使うことになった。
あまり AWS っぽい使い方でないのだが、Ubuntu 16 上に WordPress を走らせている。

WordPress 構築には、ここが大変参考になった。