Dell XPS 13 の弱点

私はちょっとしたことであれば、XPS 13 というノートパソで諸々の用事をすませて重宝しているのだが、この XPS 13 、長期使用すると弱点が見えてくる。

 

フレームにガタがくる

北米系の youtuber がよく報告している。

水平が出ていない机の上などで長期使用しているとそれに応じて筐体のフレームが歪む。

機能的には問題ないのでいいといえばいいのだが、以降、使用にあたって強度的な不安を覚えるようになる。

やはり、アルミ削り出し+カーボンファイバー張り合わせ、という合わせ技が響いたか。こういう体験をすると Mac 系ノートのアルミ削り出し一体成型の筐体としての優秀さが納得できるようになる。

 

電源はオンなのに画面は真っ暗、キー入力などを受け付けなくなる

使用期間が1年を過ぎたあたりからこの現象が出るようになった。

前面にあるインジケーターも橙色に点滅し、不安を覚えたが、これには解消方法がある。

電源ボタンを長時間(15 秒以上)押して再起動をかける

と何事もなかったかのように立ち上がる。数秒ではダメで15秒以上というのがコツでしょうか。

 

ただ、だからといって XPS 13 がダメダメかというとそんなことはなく、ディスプレイの美しさやフットプリントの小ささなど、他のノートに負けない強みがある。発表からしばらく経ちましたが、いまだに普段使いにちょうど良い機種だと思います。

基本的に win 系ノートは数年で買い換えるものだと考えておいた方がいいのではと思う。

 

 

医療「AI」ソフト

昨今の一般社会に置ける「AI」の認知度や期待は、かなり高いレベルにあるようで、先日、スマフォの操作もままならない田舎の親戚の叔母さんから

「ところで、Ocean や HorliX には、いつになったらAI機能が搭載されるの?」

と真顔で聞かれ、吹きそうになった。まさか貴女の口から「エーアイ」という言葉が出る時代が来るとは….。

ちなみに、Ocean というのは、OpenOcean という電子カルテ。

 

HorliX というのは、「ホーリックス」という名前の医療用の画像ビューア。

暫定公式アイコンはペガサス(ユニコーン? 違いがよくわからない)をあしらった

 

という感じのもの。

両方とも、私が開発にタッチしている。

 

この問いには、こんな風にでも答えればよかったのだろうか?

「やっぱり、プレシンギュラリティの年、2025 年くらいかな。

今は、HorliX で画像自動診断を試しているところ。でも、これは放射線科医の読影に基づく教師あり学習なので放射線科医を超えられない可能性が高い。

時代は強化学習っていうやつなんだよ。

来年あたりには、HorliX-Ocean のシステムに独立したエージェントを持たせる。ORCA (という Ocean と連動する医事会計ソフト)や Ocean の患者転帰が「軽快→死亡」のように変更になったときには、エージェントはそれを見にいって、それを HorliX の AI に伝える。この情報で HorliX は、自分の診断ニューラルネットモデルを最適化していくんだ。

この方式だと放射線科医の読影を超えられる可能性があるね。まあまあ使えるようになるのが 2025 年くらいかな。HorliX が

HorliX
オマエノ読影ヨクマチガウ

ダカラ私ガオマエヲ排除スル

 

と放射線科医を排除と協力するようになるのは、やっぱりシンギュラリティの年、2045 年じゃないかな」

 

一般の人が好きそうな単語を散りばめてみました。

冗談はさておき、一番、実現が早そうな機能は、HorliX 上で稼働するオートセグメント ROI (Region Of Interest…ロイ)でしょうか。

オートセグメント ROI というのは、以前にさる精神科の先生といっしょに開発した臓器抽出ソフトが基になっている。

臨床の場面では、ある特定の臓器の大きさなどを知りたいということがしばしばある。従来までの方法だと、例えば、腹部 CT 写真の画像から人が手動で肝臓などの領域を切り抜いて(この領域のことを ROI という)画像ソフトに処理させていたのだが、この臓器抽出ソフトはそれを自動でやってしまう。

という写真では、肝臓は向かって左にある。この画像を、このソフトは「肝臓抽出」ボタン一発で

と抜いてしまうわけだ。

これを「AI」というのはちょっとどうかと思うのだが、某雑誌のレビュアーなどは絶賛してくれたので、見る人が見ればそれなりの発明なんでしょう、きっと。

今のところ、肝臓だとか大脳だとか特徴的な形状を持つ臓器ではかなりうまいこと抜いているので、もうちょっと普遍化して、HorliX 上で稼働させたいというのが私の意図。

なお、この機能に関しては、既に特許が成立しているアルゴリズムを使用するため(あるいは新規の特許取得もありうるため)、この機能にかかる部分や場合によっては HorliX 全体のソース公開を停止するということもありえます。(Ocean に関しても同様。ただし、本格的なテキストマイニング研究はやったことがないので、やったとしても当分先)

というか特許保有機関から、公開の「待った」がかかること必至。判断としても妥当なんじゃないかと思うんだが、いわゆる日本の「オープンソース信者」はこういう具体的なケースに関して何ら議論しないよね。謎です。

 

(追記)…臓器抽出ソフトには「機械学習」の手法はまったく使ってません。どちらかといえば古典的な「知識ベース」の AI です。ここらへんの違いをもっと知りたい方は

Reversi -AI の基本-

をどうぞ。リバーシで遊んだだけでも両者の違いが感覚的にわかってくるかと思います。この程度のゲームなら、慣れた人なら背後にあるアルゴリズムを推測できるんじゃないでしょうか。

私は、医療系の AI にはこれが重要だと思っています。

しばしば指摘されていることですが、最先端の機械学習(特にニューラルネットを用いたもの)は、その処理過程を説明するのが苦手です。最終結果は素晴らしいものの、途中で何をやっているのかわからない、という特性があります。一方、古典的な知識ベースの AI は、マックスの性能では機械学習にかなわないものの、その動作を人間が理解しやすいという特徴があります。

医療の説明責任性を考えた場合、古典的な手法も簡単には捨てられないと私は思っています。

(追記)…HorliX のダウンロードページは、こちらです。

(追記)…HorliX は OsiriX (直接的には Horos )をベースにしたオープンソースのソフトです。OpenOcean は OpenDolphin をベースにしたオープンソースのソフトです。これ書いとかないと、最後、何言ってるかわからないよね。失礼しました。

 

 

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

奇跡のコード

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

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

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

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

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

 

分類:製薬支援ソフト

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

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

 

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

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

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

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

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

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

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

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

 

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

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

 

 

設計図共有サイト

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

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

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

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

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

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

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

 

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

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

Wow…your idea is great!

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

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

 

OpenDolphin2.7m → OpenOcean

電子カルテ OpenDolphin に関する話。

どうやら私は今まで勘違いしていたようなのだが、ドルフィンプロジェクトの開発元の LSC は、ドルフィン「亜種」には「ドルフィン」という名称は使ってほしくないようなのだ。

私なんかからすると、それぞれの特徴をいかした「〇×ドルフィン」があった方が多様性があって賑やかで良いように思うのだが、そこらへんは考え方の違いか。

細かな事情はよくわかりませんが、某先生からフォークした私の OpenDolphin-2.7m は、今後 OpenOcean と名前を変えますので、今後はこれでお願いします。

 

先ほど github のリポジトリ名を変えてきましたが、ある意味、気が楽かもしれませんね。ドルフィンの看板が外れるので。

 

これからは、ダイコムビューア HorliX ともども電子カルテ OpenOcean の方もよろしくお願いします。(大事なことなので2回言いました)

 

オープンソースと知財権に関するちょっと小難しい話

前回の記事『電子カルテ Dolphin Evolution をテスト』で Dolphin Evolution™ などとわざわざ™つまりトレードマーク表記したのは、この開発元の会社と「本家」が商標をめぐって対立したことがあるからだ。

登録第5656156号商標の商標登録に対する登録異議の申立てについて

固い文章なので読みにくいが、かいつまんで言えば「 オープンドルフィン( openDolphin ) を商標登録していたのに ドルフィンやドルフィンエボリューションが商標登録されてしまった。これは、 openDolphin™ の周知性のただ乗りである」という異議申し立てである。

商標は、専用権と禁止権から構成され、この組み合わせのおかげでそれなりに強い排他的独占権を持つ。要するに有名ブランドの登録商標を紛らわしく使ってはいけないということだ。計算機プログラムは原則として著作権で保護されているが、著作権の排他的独占権は弱く(特に特許権に比べた場合、その差は顕著)、オープンソースのプロジェクトがそれなりに育ってくると同一性を維持するため商標を登録しておくことはよく使われる手法だ。

しかし、商標にはかなり実際的な効力の限界があり、この例のように一般的な名詞を持ってきた場合、商標としての機能は著しい制限を受ける。この言葉を一般的な使う場合にはまったく制限を受けないからだ。

これは、しごく当たり前の考え方で、日常的な場面で「ドルフィン」あるいは「dolphin」といった場合、これは海洋哺乳類の人気者「いるか」を思い浮かべることがほとんどで、そういった使用をいちいち禁止できないということを意味している。

だから、ドルフィンというかなり一般的な名詞を商標登録すること自体ちょっとどうか?と思う。

また、個人的には、それにいちいち噛みつくのもけっこう違和感がある。私の記憶に間違いがなければ、ドルフィンプロジェクト自体が国の公募事業として採択された経緯があり、一時的にせよ公的な資金が注入されたものに強い排他的独占権を持たせるという考え方には無条件に賛成するわけにはいかないからだ。そして、異議を受けた側の Dolphin Evolution のプロダクツには、UI を JavaFX で設計する、通信ライブラリをクラウド用に工夫するなどのそれなりの独自性を有しているように思えるからだ。

まあ、「Dolphin Evolution」中心に商標登録しておけばよかったのにね、と思わないでもないが、つい大っきめに権利を主張してしまったのだろう。

なお、この異議申し立ての最終的な判断は、

「登録第5656156号商標(エボリューションの方)の商標登録を維持する。」

というもの。

これは、けっこう妥当な判断ではなかろうか。要は、申し立てした側がやりすぎたということだろう。

また、この異議申し立てが教訓的なのは、新規に始めるにせよ、どこかのプロジェクトをフォークするにせよ、ある程度、独自性がでてきたら、そのプロジェクトには類似プロジェクトやフォーク元とは似ても似つかない独自の名前を持たせた方が良い、ということを教えてくれることだ。

こうしておけば、変な絡まれ方をされる可能性はぐっと減るように思う。

 

私が、オープンソースの世界に足を踏み入れて一番驚いたのは、この世界の人々が、こと知財権に関してはかなり素人っぽい考え方をしていることに気がついたことだ。

知財権に関する素人っぽい考え方とは、著作権に関することだ。主に二つ。

・行き過ぎた排他的独占権の主張

・著作物がすべて保護の対象になるという誤まった考え

前者は、「かくかくしかじかというソフトをつくったから、似たようなソフトはすべて私のソフトの剽窃あるいはパクリ。決して許されない行為だ」というような主張だ。なんかできの悪い小学生の図工の時間をみているようで嫌な気分になるのだが、こういう主張をする人は後を絶たない。著作権の場合、実際的には排他的独占は認められていない。意図的に模倣したならともかくたまたま似たような表現になった場合、どちらかの表現の自由を奪うというようなことはできない。このような主張をする人はおそらく著作権と特許権を混同している。

そして、そんなにオリジナリティや排他的独占権を主張したければ、最初からプロジェクトをクローズで作成し、アルゴリズムなりなんなりで特許申請すればいいと思うのだが、この手の主張をする人たちはなぜかそれをしない。

後者は、「私の制作物を使った場合、その使用権はもともとは私にあり、その権利はすべて保護されなければならない」というような考え方だ。これは主張だけをみれば、それなりに正しそうに見える。実際、商業的な音楽やアートはこの考え方に基づいて著作権使用料などを徴収している。だが、それはその著作物がある程度のオリジナリティを有していて他人がおいそれとは思いつかないような場合においてのみだ。著作物がすべて保護の対象になるかといえば、ならない。これは wiki で紹介されていた例だが

 

長い間ご愛読いただきましたBON TONは今月号(5月号)をもって休刊し、誌面を一新して7月発売で新雑誌としてデビューいたします。どうぞ、ご期待ください!!

という表現は、保護の対象にはならない。それはそうだろう。かなりよくある定型的な表現であり、こんなものまで保護の対象にしていたのでは誰もモノを喋れなくなってしまう。

ソフトの世界でここまであからさまな例はそう多くはないが、よくあるのが海外の有名なライブラリやフレームワークのサンプルコードをほぼそのまま組み込んで著作権を主張するような例だ。この手の有力プロジェクトは、他のプロジェクトに「使ってもらう」ことが前提になっていて、ドキュメントやサンプルプログラムが充実している場合が多い。よく「〇×を使って、ハローワールドを表示させてみた」という記事があるが、たいてい元になった〇×ライブラリのサンプルの場合が多い。解説記事の著作権は、それを書いた人にあるかもしれないが、サンプル丸パクリのソースコードには(保護の対象となるような)著作権はない。あるとすれば、それはそのライブラリを作成した人、元々のサンプルのソースを書いた人だろう。

 

これは個人的な意見だが、オープンソースの領域で上記のような子供じみた主張をする人たちの大半のアウトプットは、残念ながら、そこまで(=保護の対象となるような)高い思想性を有しているようには見えない(いわゆる当業者知識の範囲内)。高度な思想性を有していないがゆえに、逆に著作権にかこつけて自己承認欲求を満たそうとしているようにも思える。育ちが悪いというべきか。実際、標準的な工学教育を受けてない人も多いしね。

だからであろうか、一時的にけっこうな隆盛をほこったプロジェクトも分裂して減弱し、確かな基盤を持たないまま終わってしまうことが多い。

うーん。

ま、難しい話はともかく Horos のようなプロジェクトは、ちゃんと育ってほしいなあと思うのだった。

けっこうあやしいこともやっているので完全には信用できないんですけどね。

 

 

電子カルテ Dolphin Evolution をテスト

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

 

ソースは github から落とす。

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

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

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

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

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

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

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

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

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

変更したコードはこちら

 

クラウド化した電子カルテサーバにオンライン診察向きのビデオチャットサーバをたててみる

前回の記事のためにひさびさにクラウド化したドルフィン(という電子カルテ)サーバを走らせたので、ついでで同じマシン上にオンライン診察を意識したビデオチャットサーバを立ててみた。

近年の通信技術の進歩は恐ろしい勢いで進んでいるようで、割と簡単に立てられました。

 

実際に使うとすると以下のような流れになると思います。

まず、自院サーバのどこかにチャットルームをつくり(下の例では http(s)://自院アドレス/test)、そこにブラウザで入室する。ルームの名称はなんでもOK。

 

 

患者さんには、そのアドレスを教え、ブラウザでそのアドレスを踏んでもらう。今回は Mac のクロームで入室。

患者役がいなかったので椅子で代用したのは大目に見て(笑)。

なお、今回の例では、映像・音声データはブラウザ間を流れ、サーバはあくまでそのアシストをしているのみ。とにかく高速でデータを流す。

つくりながらオンライン視察のガイドラインをちらちら眺めましたが、役所的にはこちらの仕様の方がいいようですね(下手にサーバにデータを蓄積させると漏洩のリスクがあるから)。

 

ところでこの手の新技術を取り込む際には、パッケージングというのが頭を悩ます問題。

メドレーのクリニクスというシステムは、電子カルテ+オルカ(というレセコン)+オンライン診察を一体化したそうだが、ガイドライン的なものを横においてもそういう「」なパッケージングがよいのかどうか?

ちなみに国のガイドラインはこの手の「密」なアプローチを推奨していないように思えます。
『オンライン診療の適切な実施に関する指針(案) – 厚生労働省』

この分野がまだ発展段階であることを考えると、各サブシステム同士は「」にゆるく結合させておいた方が将来的な拡張などを考えるといいように思うのだが、どうだろう?

また、実際的な利用場面を想定すると、患者さんの同一性をどう担保するかといった問題がある。

個人的な意見をいわせてもらえれば、

医療等IDの社会的・インフラ的確立→遠隔医療・医薬看介連携システムの整備

と進んだ方がすっきりしたはずだが、リアルポリティクスでは、なかなかそうは理想的にことが運ばないのでしょうね。

ところで、これに関連して電子処方箋のガイドラインもちらっと読みましたが、あのシステムのわかりにくさはいったいなんなんでしょうね?

『JAHIS 電子処方せん実装ガイド Ver.1.0 – 保健医療福祉情報システム

 

にほんブログ村 IT技術ブログへ

電子カルテのなんちゃってクラウド化・多施設化

電子カルテはクラウドが流行っているので dolphin でもできないか検討。

デフォルトの 1.3.6.1.4.1.9414.70.1 のドルフィンクリニック(管理者 admin さん)の他に

追加で    1.3.6.1.4.1.9414.10.1 のイルカクリニックを登録(ついでに管理者 dolphin さんも登録しておく)。

クラウド上に設置したサーバに対して admin さんと dolphin さんが異なる場所から同時に接続を試みる。

するとサーバ側ではこんなログが取れる。

クライアント端末でもしっかりつながってました。

実運用では、セキュリティを高めるため VPN でつなぐなどやらなくてはいけないことはいろいろあるでしょうが、大きな修正なしにクラウド化・多施設化ができるというのは便利ですね。

 

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 ファイルを取り込む

という流れになります。

 

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

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

 


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