rilmiah

[rilmiah]

クラウドメモ

ここのところ、クラウドメモをまた変更しました。 最初はWindows標準のOneNoteでした。 それからEvernoteに移り、無料では2アカウントしか使えないという制限ができたのでDropbox Paperに移動。

しかし、Dropbox Paperは当初こそ同期の速さが良いと感じていたのに、段々と重くなりました。 PC側（Web）で削除するとスマートフォン側で同期エラーが発生したりする。 URLを貼り付けると勝手にプレビューを作る機能なんて要らないって…。 とくにスマートフォンアプリの出来が悪いが、更新自体がごく稀（フリーなので文句は言えませんが）。

というわけで色々と探した結果…Simplenoteに移動しました。 画像も何も要らない、とにかくテキスト情報だけを確実に同期したい人間にとって、これは現状の最適解では？と考えています。

唯一、タグの一覧を常に表示しておけないことだけが、少しだけ不満です。スマートフォン版はともかくPC版（Web）は表示しっぱなしにさせて欲しい。

[rilmiah]

仕方が無いところですが

ちょんまげは、どのサービスでも現状まともに作成できません。 Japanese topknotやtraditional Japanese topknotなど、だめでした。 ただ頭の上に結び目があるだけになってしまう。 特徴的なあの形も、左右の剃り込みも出ません。残念。

10/1 加えて、CRTモニタが出せません。

[rilmiah]

続・画像生成AI

本当にありがたい存在です。細かいところは無視してくるし、まったく作れないものも色々ありますが、それでもこの1か月で既に100くらいのキャラに画像を付けることができました。

Firefly、Pix.Ai、Tensor.Artそれぞれの、個人的に感じた特徴と比較。

Fireflyは人間が弱い。極々稀に、そのまま使えるものを出してくれますが、後は手がなかったりグチャグチャだったりというものを平気で掲載してきます。強調もネガティブプロンプトもないので「最低限従って欲しいもの」「出て欲しくないもの」を教えることはできず。ただ、一番モノを知っていて、一番「それっぽいもの」を出してくれる気はします。そして、回数制限なく何度でも試せるのもありがたい。大抵の場合、まずEmEditorでプロンプトを作ってFireflyで何度か試してから、PixまたはTensorにそのプロンプトを持って行くという使い方をしています。英単語のミスなんかの無駄打ちを減らせる。

Pixはモデルの選択が悪くなければ「思い切りハズレ」はそう多くありません。人間の顔を一番きれいに出してくれるので、リアル風味の美形・美少女を描かせるなら、この3つの中では一番だと思います。ただしみんな同じ顔で、年齢も比較的低めです。女性への偏りが大きくて男性を指示したのに女性が出てくることも多い。そして（1,000ptの高優先度を付けないと）待ち時間が長い。30分以上待たされることもある。毎日固定で10,000pt配布されて、4枚出力なら800pt消費なので、無駄打ちが少なければ0にはならない（というか待ち時間が長いので、「これはPixの美少女でないと」というキャラ以外はどうしてもTensorメインになる）。モデルを変えるとネガティブプロンプトがリセットされるのが面倒くさい。

Tensorはモデル数が多すぎかつ選択UIが悪いので毎回「どれだっけ…」と何回か無駄打ちしてしまいますが、Pixよりは絵柄の幅が出せます。しかしやはりモノを知らない。そして、顔が潰れてしまう確率が結構高い。ADetailerという顔修復専用のフィルタが最初から付いているのが、提供側としても問題点を把握してるからでしょう。とはいえ、ADetailerを1回、多くて2回通せばほぼ見られる顔になるので、そう大きな問題ではありません。どちらかというと、ネガティブで指定しても手が3本になったり指が4本/6本になったりが多い方が、修復できない分面倒くさい。毎日使えるのは100ptカッキリ（翌日消費分が補充される）しかないので、無駄打ちが多いとあっという間に使い切ります。

このうち、エルフの耳が一番期待どおりなのはFireFlyです。継いでモデルによってはTensorも割と。

[rilmiah]

画像生成AI

エルヴァートのキャラ画像に、画像生成AIを使用することにしました。 実のところ、その有用性は感じつつも、エルヴァートの画像生成に使用することへのためらいがありました。資金不足という個人的な問題でそれを使用することは、これまで描いていただいていた作家様たちに対してある意味裏切ることになりはしないかと。 また、著作権の懸念もありました。エルヴァートはすべて非商用ですし、そこまで深刻な問題になることはないと思いつつですが。 最初は著作権問題がないとされるAdobe Fireflyを使い、さらにその限界を感じてPix.Ai、Tensor.Artを加えていろいろと作成しました。 Fireflyは著作権への配慮をうたうために学習数が制限されているのか、非常に「ありがち」なものしかうまく生み出せません。また、類似画像を作成したりするとすぐに品質が劣化してしまいます。これは、高品質なそのものの画像ではなく「アイディアを提供する」という方針を示したものかも知れません。

いずれにしても、これらのサイトのおかげで結構な数の画像を付与することができました。ただし、元ネタが限定されているためか、人間以外のものはやはりうまく作れません。 例えばoriental dragon(Chinese dragon)はFireflyではまったくダメで、西洋の竜ばかりが出ます。NautilusやEttinは3サイトいずれもダメでした（EttinはD&Dのものなので仕方が無いといえば仕方が無いですが）。

今のところ生成できないもの：目玉のない人物、首のない人形、頭に布を巻く、オウムガイ、エティン、東洋竜、エラスモサウルス、3本腕、4本腕、人間型の黒い物体、腰の曲がった人物、紫色の髪の男、貧相で貧弱、片眼鏡、モグラ等々。

→東洋竜は、対応しているモデルが存在したので作成できました。

いずれも色の指定は3つくらいが限界のようで、2箇所でも無視されることが結構あるようですね。とくにFireflyでは強調カッコを使えないし、Negative Promptもないのでかなり無理があるのが分かりました。 また、髭の長さはどうもある程度までしか長くできないようで、地面に着くような長さが狙って出せません。

一部「これは」というキャラについては、これまで通り作家様にお願いするつもりです。 とくに、個人的に非常に悩んでいたルミスデン9天使についても、敬愛する作家様に依頼することにしました。

正直なところ、ココナラやSKIMAで依頼するのはもうそろそろ終了かなとも思っています。 というのも、手数料が非常に大きいからです。

[rilmiah]

イラストその後

やはりそううまくは行きません。ココナラでの受注はここ数ヶ月なく、ついにポイントは0になりました。と言って、仕事の合間に一人でできることなので、受注内容を大幅に変えて、発注したくなるような内容にまで持って行くこともできません（私の知識も追いつかないし）。

もっとも、最近さらに月日の経つのが早く感じられ、今月も気がつくと20日になっているといったところで、発注にもあまり気が向かなくなっている実態があります。 発注するには設定が必要で、これが中途半端だと受注側でうまくイメージできないことになります。学生時代から名前と小さな設定だけで人物が増えて来たため、発注に際してある程度加筆はするものの、「これはまだ依頼できない」というキャラばかりなのが実状。

主要なキャラには既に画像が付いており（ツール画像を含め、ですが）、そこまで強く欲しいと思えるキャラがいなくなっているのも確かです。

私の最愛の（語弊あり）作家様も、最近再び値上げを検討されているようです。この方の作品は本当に魅力的で、私にとっていろんな意味で「刺さる」女の子を何人も描いていただいています。どのキャラがということではなく「もっと描いて欲しい」と思うのですが、残念ながらそろそろ軍資金の面で無理になりつつあります。

[rilmiah]

不満点

というわけで、新しいマシンはとても良い買い物だったのですが、すべて理想どおりにはなっていません。

RAM：64GBにしたかったけれど、ひとまず旧マシンと同じ32GBで据え置き。予算の都合です。まあ、現状でもPhotoshopはパフォーマンスアップしているので、当面よしとしています。

データドライブ：旧マシンでは3.5″ HDD 4TBだったのが、SSD 2TBになりました。これも予算の都合です（もっとも、同容量でも同じくらい頻繁にアクセスはしたくないですが）。 このため、移動はエルヴァートや個人データに限り、半分以上は旧HDDに置き去りになりました。 現状では、旧マシンからくり抜いたHDDをお立ち台で接続しています。 これまでは他のHDDを常時差していたのですが、いちいち差し替えが必要になりました。

m.2か、せめて2.5″であれば…やはり3.5″はでかいし重い。何とかしたいです。 他のHDDを全部m.2で置き換えて、前面のtype-Cへ接続できれば完璧ですが、合計20TBくらいはあるので現実的ではありません。

Windows11：Win10まで可能だった、タスクバーのツールバーが使えないという問題がありました。ショートカットを詰めた3つのフォルダをツールバーとして使っていました。 タスクバーをWin10風に切り替えるフリーソフトを入れて解決かと思ったのですが、エクスプローラ自体が不安定になってしまい、やむなくアンインストール。 最終的に、簡易ランチャー（上記フォルダを読み込んでプルダウンで表示する）をPythonで作り、画面右上あたりに常に最前面で置いておくようにしました。まあ何とか…。

Officeが2013だったため、インストールできません（Win10からのアップグレードならそのまま使えるらしい）。 普段使うものは基本的にLibreOfficeのため、今のところ影響はありませんが。 今後どこかの時点で、最新のOfficeを購入する必要はでてきそうです。

[rilmiah]

初Win11

KP41病でどうにも不安定だったPhotoshopマシンを、2月にリプレースしました。 Minisforum  HX90M（RAM 32GB m.2 SSD 512GB）で、これに旭東エレクトロニクスのm.2 SSD 2TBを増設しました。最新のHX99Gにしなかったのは、予算の都合よりもディスプレイの関係です。 現状DisplayPort、HDMIの2画面なのですが、HX99GはHDMIとtype-C出力だったため、ディスプレイも考える必要がでてきます。 1画面しか使わないにしても、メイン側にHDMIの空きはないので…。

使い勝手。

まずなんと言っても本体のサイズと重さ。Fractal Design Define R4は安定していて良いケースですが、移動やケース内アクセスはやはり苦痛でした。段違いです。

動作音は非常に静かで満足。動画エンコード時のみ、それなりのファン音が聞こえますが、ここでも素晴らしい結果が。

旧マシンで25分（ほぼ実時間）かかっていたエンコードが、なんと2分で終わるのです。異常なほどの高速化です。 まとめてエンコードしてもあっさりと終わるので、これまでのように一晩起動しっぱなしにして翌朝確認なんてこともなくなりました。

消費電力は電源W数比で半分以下。 これまではKP41病でのフリーズを減らす目的で常時起動していることが多かった（それでも不定期にフリーズした）のが、使うときだけ起動するように。 上述エンコード時間超短縮もあり、起動時間自体が短くなっています。 トータルの消費電力はかなり減っているでしょう。9年の技術の進歩は素晴らしいです。

肝心のPhotoshop。 CPUのA10-7800→Ryzen9 5900HXが大きいのか、全体的にキビキビと動くようになりました（GPUのGTX-1660→RX 6600Mはほぼ同等のようです…これも同マシンを選定した理由）。 Win11でも、マクロは当然ながらそのまま動いています。

また、Splashtopのリモートデスクトップも問題なく動作。実はWin11ProなのでMicrosoft標準のRDPが使えるんですけどね。

[rilmiah]

現在の悩みどころ

様々なツールやマクロ等を使って自動化を図っているエルヴァートの創作ですが、いくつか悩みどころは残っています。とりあえず2つ思いついたので書き留めてみます。

まず一つ目が、エルヴァートマップの8マイル/hex版の制作です。 24マイル/hexのものを縦横3倍したものを順次細かく描き直しています。その際、海岸線や川岸、新たな（細い）川、崖のライン等はピクセル単位での描画になっており、これが結構な労力のためになかなか進みません。 機械学習して自動的に生成なんてことができれば良いのですが、そういう知識はありません。

次にHTMLファイルの管理です。 現状HTMLファイルはEmEditorのプロジェクトプラグインでツリー表示しています。 しかし、EmEditorのプロジェクトはディレクトリ構成と一対一でないため、 ・ファイルの新規作成やリネーム、コピー、移動が二度手間 ・とくに新規作成をツリー上で行なうことができないのが面倒 ・ディレクトリ・ファイル数が多い（ファイルだけで1,000弱）ので、1ツリーで管理するには無理がある ・画像等非テキスト要素は相変わらずエクスプローラで管理している ・EmEditorを再起動すると、最後に開いていたノード以外すべて閉じてしまう といったあたりがきついと感じています。 編集自体はEmEditorで行ないたい（マクロも多数使っている）ですが、管理は別の方が良いのかも知れません。

[rilmiah]

リモートデスクトップ変更

少し前に、リモートデスクトップアプリをBrynhildrからAnyDeskに変更しました。概ね満足していたのですが、いくつか問題がありました。

まず、どうもサーバ側が不安定で、時折クラッシュすることがありました。再起動してもクライアント側からの要求を受け付けてくれません（無認証のはずなのに「許可を求めています」という確認が出て、しかも許可してもつながらない）。 また、これと同時かどうか検証していないのですが、膨大な数のイベントを出力してイベントビュアが埋め尽くされることがあります。 そして操作自体についても、ディスプレイ切り替え（サーバ側もディスプレイ2枚のため）にはいちいちマウスでボタンをクリックしないといけない。Brynhildrはディスプレイ2枚分を1ウィンドウで表示できて、AnyDeskで当初から不満な点でした。「まあ、慣れるだろう」と思っていたのですが、慣れませんでしたね。

そこで、別のRDPアプリを試してみることにしました。結論から言うとSplashtopに変えました。

まず試したのが、Chromeリモートデスクトップ。最初に少しだけ混乱がありましたが、インストール・設定自体は簡単なものでした。ブラウザのタブを使うのは良いのか悪いのか…と思いつつ。 まず気づいたのが、マウスカーソルが見えない。正確には小さな点です。これについては簡単に情報が手に入り、サーバ側でキーボードのマウスキー機能を有効にすれば良い、と。 確かに表示されました。ただ小さいのでマウスポインタのサイズを変更…変わらない。これはつらいです。 Chrome RDPを見切ったのは、ディスプレイ切り替えでした。別のディスプレイの内容が大半残って、当初切り替えられたことに気づけなかったくらいです。キャッシュがおかしいのでしょう。マウスを動かしたり、ウィンドウを動かしたりすればそこだけ再表示が掛かって表示中のディスプレイの情報になる。これは無理です。 そしてしばらく放置すると切れてしまう模様。

次にSplashtop。まずは速度…速い。その分CPUリソースは食いまくりで常時1コアは100%のようです。 AnyDeskよりも速い。どれくらい違うかというと、AnyDeskではサーバ側の動画再生ウィンドウは2kくらいが限度でした。Splashtopでは、2.5〜3kでもそれなりにスムーズ（4kはさすがにカクつきます）。 ディスプレイ切り替え。ctrl+alt+←/→で切り替えられます。これはとても快適です。 ハードウェアアクセラレータの設定があるのでONにした影響か、何度か落ちたのですが、OFFに戻した後は一度も落ちません。 というわけで、切り替えるには十分な性能を見せてくれました。

思えば、以前Splashtopの製品でiPad mini 4をPhotoshop機の液タブ代わりにして使っていたことがありました（たしか有償アプリが無料になっていたのだったような）。

10/22追記

Slashtop、しばらく使ってから思ったのは、 ・ツールバーの自動非表示が欲しい ・最小化のキーボードショートカットが欲しい ・ツールバーで、最小化とツールバー非表示のボタンを縦に並べているが、感覚的にはツールバー非表示が上、最小化が下では？（そもそも縦に並べる必要性もなさそうですが）

というところでしょうか。ともあれ非常に安定しており満足しています。

[rilmiah]

仮想スレッドその後

エルヴァートマップの分割ツールは、複数のスレッドプールを使用しています。1つ目は各ファイル処理のメイン、2つ目はパーツ分割、3つ目はアップロード。

前回、仮想スレッドに置き換えたと書いたのですが、アップロードのみ、どうにも処理が安定しませんでした。エラーが出ることは少ないのですが、なぜか肝心のアップロードがなされないことがありました。

仮想スレッドと相性の悪い設計があることは確実ですが、それがどこか、なかなか見つけられません。本質的ではない箇所に時間を使うのも何なので、仮想スレッドを諦め、アップロードのみプラットフォームスレッドに戻しました。

加えて以前はスレッドローカルで保持していたFTPクライアントのインスタンスは、新たにクライアントプールとでも言うべきものを作りました。仮想スレッド導入より前と比較しても処理が安定した気がします…が、これはまあプラシーボでしょう。

ところで、Javaと比較してPythonの方が良いと感じるもう一つの点があります。それは、Pythonがスクリプト言語であるところからもたらされるものです。

Javaの場合、開発環境を起動すると、classファイルを自動で再作成することがあります。それだけならツールを再起動すれば良いのですが、たまになんらかの原因でビルドが途中で止まり、classファイルが作成されないことがあります。こうなると、ツールが起動できなくなってしまうわけです（classファイルを別の場所へコピーして使えば別ですが）。

Pythonでは、言ってみればソースをそのまま実行するので、開発環境を起動しようが何をしようが、ツールの実行が阻害されることはありません。

上記分割ツールも、そのうちリプレースできればなと考えています。ただ、大サイズのファイルに対する重い処理なので、Javaに分があるのも確かです。

[rilmiah]

マルチスレッドと仮想スレッド

現在エルヴァートマップは、 Javaで作成した常駐ツールで分割・アップロードしています。このツールは特定のフォルダを監視しており、Photoshopマクロ（jsx）でpngファイルが更新されると、読み込んで処理するのです。ツールの内容は以下のとおりです。

更新されたファイルを画像として読み込み、8640x3840をマルチスレッドで144x160のパーツに分割します。個々のタスクは既存のファイルをキャッシュから読み込み、画素に変更がないかどうか確認します。変更があればファイルを保存（とキャッシュ置き換え）し、アップロード用のタスクを生成します。タスクはすべてスレッドプールで実行します。

FTPアップロード中はCPUやネットワークの使用率が高くなります。PCの不安定さ（フリーズ、ネットワーク切断）の原因の一つはこれではないかと考え、今回、このスレッドプールをJava19で導入された仮想スレッドに変えてみました。

仮想スレッドは機能的にはスレッドプールと類似ですが、プラットフォームスレッド （以下スレッド） を直接扱わずにVM内でタスク管理し、適宜割り当てることでCPUのコンテキストスイッチを回避し、効率低下を抑止します。ブロッキングによるスレッド占有も解消されます。

変更の結果、 ピークではCPUやネットワークの使用率に変化はないようですが、山が急峻になり、全体的にややスムーズに動作するようになったと感じています。ただ、落とし穴がありました。初回から「socket closed」というメッセージが出て、その後も不定期に出ていました。正常動作しているし…と放っておいたのですが、今日、そのメッセージの後に「アップロード失敗」のメッセージが出たのです。

調査したところ、FTPクライアントにThreadLocalを使用しているのが原因でした。これまでスレッドとFTPクライアントのインスタンスは1:1でした。しかし仮想スレッドに変更したことにより、タスクの処理中に別のスレッドが割り当てられる可能性が生まれました。新たに割り当てられたスレッドに、既にクローズされたFTPクライアントが紐付いていたのです。正常動作していたのは、リトライによるものでした。今回リトライがことごとく失敗し、「アップロード失敗」になったということです。

仮想スレッドの解説には、「仮想スレッドを使うならThreadLocalを使うな」とありました。まさにそのままでした。

ひとまず、FTPクライアントをThreadLocalから取るのをやめ、タスクごとに毎回生成するようにしました。効率を考えればプールだろうと考えています。

[rilmiah]

名前

エルヴァートは、30数年前にTRPGの舞台として作った設定です（正確にはその少し前に、漫画を描こうとして描いた世界地図が原型ですが）。

当初は小さな島ひとつで、名前は思いつくままに適当に当てはめていたのが大半でした。前述の漫画のように、その前に考えていた話から名前を引っ張ってきたものも多いです。まずここで、好きな響きを適当に採用して文化圏など考えていなかったのが1つ問題。

その後プレイヤーキャラクターの成長とともに（D&D公式設定の影響もあり）舞台を世界つまり惑星規模に広げ、それに伴って膨大な数のキャラクターを増やして行きました。このとき、私を含めプレイヤーたちが「銀河英雄伝説」にはまっていたこともあり、キャラ名としてドイツ語圏のものが大量にできました。それだけでなく、考えなしに「フォン」を入れた名前を沢山考えたのです。

ここ5年くらい、いろいろと設定の齟齬や粗を見直してきたのですが、世界中のあっちこっちにドイツ語圏があり、貴族でもないのに「フォン」が入っているというところで頭を抱えました（元NPCだけでなく、プレイヤーが付けた名前にもいました）。

まず、大別して3箇所（コルコランド、エルドレス〜ミュンハイム、ドバヌール）に存在する理由付けをしました。エルヴァートでは古代にコリントが星ほ半分近くを征服したという歴史があるので、エルドレス方面からコルコランド方面やドバヌール方面に強制移住させた、という設定を作りました。

次に、「フォン」が入っている名前です。フォンはそのほとんどがコルコランドとドバヌールであり、エルドレス方面には存在しません。加えてコルコランドは「貴族」が歴史に組み込まれているのに比べ、ドバヌールはドバヌール王国が存在した期間しか「フォン」が設定されていません。そのため、ドバヌール方面の「フォン」はいずれもコルコランドの貴族の噂を聞きつけた人たちが、自己満足で入れたという設定にしました。

上記3箇所以外、フェルナンドやアマリスにあるフォン入りの名前は、ごっそりフォンを削除しました。これらは系統的にコルコランドとは関係がなく、また趣味で「フォン」を入れるような人々がそんなに何カ所にもいるわけがない、と考えたためです。プレイヤー設定の名前クラウス・フォン・ローゼンベルクも、この理由でフォンを外しました。

同じく英語系の名前も広く、オージャス、ホーメルト、スメルの3大陸にまたがっているのですが、それは現状諦めています。脇役の多いドイツ語圏の名前と比べ、英語圏は主要人物にも多く用いているため、改名は無理だと考えました。

まだまだ、「それっぽくする変更」は続きます。

[rilmiah]

メンテナンス画面

pythonに移植したメンテナンス画面ですが、今回新たにキーワード検索を追加しました。メンテナンスに対応したテーブル（誕生日、作品、作者、イモータル、過去勢力図、国旗）のTEXT型カラムに対して、入力キーワードを部分一致させて取得するというものです。検索結果はこれまでと同様左側に一覧を表示し、クリックするとそのデータのタブへ遷移し、あたかも登録済みリストをクリックしたように編集状態になるようにしました。

加えてもう一つ改良を入れました。

これまで、上記登録済みリストは<select size=“?”>で表現していました。ところがこれをAndroidのモバイルChromeで表示したところ、なんと高さだけが広がって表示されているのは1行だけ（タップするとリストがオーバーレイ表示される）なのですね。「<select>のsize=“?”をどう扱うかはブラウザの自由（必ずしもリスト形式にならない）」という仕様を、認識していませんでした。HTMLとはかれこれ25年以上付き合っていますが、まだまだ知らないことがあります。

元々1行では使いづらいからリスト表示にしたので、「モバイル版では1行表示」では解決になりません。そこで今回これを、<div style=“overflow-x:hidden;overflow-y:scroll”><ul><li>に作り替えました。DOM構造が変わるのでJavaScript/CSSにもいろいろと修正は必要でしたが。ともかくも、これでデスクトップとモバイルとで、同じ画面になるようにできました。

それから、不具合修正…。python側でURLエンコーディングを失念しており、データに % が含まれている場合にJavaScript側で変換エラーが発生し、欠損する状態でした。画像の追加CSSで % を含む値が消えたことで気づきました。

当初はJSON変換に入れようとしましたが、strはデフォルト変換なので割り込むのは面倒だと考え、まずはその直前の「オブジェクト中のNoneを’’に置き換えてる」処理に追記しました。結果、同じデータを2回3回クリックすると、URLエンコードが複数回掛かった文字列が降りてくるようになりました。

DBから取得したdict型データは、DBアクセスを減らす目的でセッションキャッシュに保存しています。これは同一のオブジェクトなので、 初回：DB取得→キャッシュ登録→dict中のURLエンコード（キャッシュも書き換わる）→JSON変換 二度目：キャッシュ取得（変換済）→dict中のURLエンコード （キャッシュが再度書き換わる） →JSON変換 となってしまったのです。

順番を入れ替えて完成。 初回：DB取得→dict中のURLエンコード→キャッシュ登録→JSON変換 二度目：キャッシュ取得（変換済）→JSON変換

Noneを’’に置換する処理は二度目は空振りしていますが、JSON変換と共に共通部品レイヤーで行なっているため制御が面倒で、今回は手を付けませんでした。

[rilmiah]

イラスト発注

その後、ココナラでプログラミングのサービスを出品し、この売り上げをイラスト発注に回すことにしました。

サービス：https://coconala.com/services/2297572

しばらくは「出しているだけ」でしたが、ありがたいことに、現時点で3件の購入をいただいています（うち1件はリピートで取引中）。 ある程度の規模のものがコンスタントに来てくれれば、ココナラでの発注がある程度賄えるようになります。まあ、今のところ夢ですが。 それに、ココナラ以外では使えないという問題もあります。ココナラでの依頼が多いとは言え、SKIMAも複数の方に依頼しており、またKyashで個人間送金してお願いしている方、Amazonギフト券をお送りしている方もいます。 現金化して振り込んでもらえば使用可能ですが、確定申告にも反映する必要が出てくるため、現状はココナラ内で消費する想定です。

現時点で依頼したいイラストで一番高価になりそうなのは、「ルミスデン9天使」というキャラ群です。ルミスデン教という宗教に現れる9人の天使という設定ですが、1人1人描いてもらうのではなく、本物の美術絵よろしく9人まとめて描いてもらいたいという野望(?)です。 依頼先は随分前から秋川ひぐらし（https://www.pixiv.net/users/22344051）様にと決めており、少し前にご本人にもお伺いを立てています。順序付けのようなことはしたくないのですが、この方の描かれる作品は「刺さり」過ぎて、もはや別格になっています。

次に高価になりそうなのは、グレーデンの少女たちです。キャリー、メアリ、ローラ、クリスティアという4人の女学校に通う少女たちの集合絵を描いて頂こうと思っています。 こちらは彼女たち1人1人のイラストを 花兎*（https://www.pixiv.net/users/3198439） 様に描いていただいているため、集合絵もお願いするつもりです（こちらも、ご本人様にお話を通し済みです）。

これまで作家様に描いていただいた作品は、http://mylph.my.coocan.jp/elvert/misc/illusts.html でご覧いただけます。

[rilmiah]

JavaScript処理の見落とし

長くやっていると、サイトの構造を途中で変更することがあります。かつて国のデータはトップディレクトリに並列に並べていたのですが、これを大陸ごとに分けたことでいくつか不具合を出しました。

昨夜見つけたのは、百科事典に組み込んであった、「他項目参照」のリンク（ジャンプ指定）が働かなくなっていた不具合です。原因は、元々1ファイルだったHTMLが1.6MB程度にまで膨れ上がったため、あいうえお…の各ファイルに分割した（そしてAjaxで取得するようにした）ことです。これにより、「最初の段階でジャンプ指定が存在する」「ジャンプ先が必ずファイル内に存在する」という前提が崩れるのを、��落としていました。分割はもう半年くらいは前だったと思います。

元々は、全体ページロード後に、各ジャンプ指定について、ジャンプ先テキストが完全一致する<h3>へのリンクを指定していました。 この処理を、まずはAjaxによるサブページロード後に変更。ただ、これだけではジャンプ先がまだ存在しない可能性があるため、ジャンプ先テキストの先頭1文字を拾ってそのロード後にリンクを設定するように変更（Ajaxロードは最初の一回しか発生しません）。

さらにもう一つ、作り込む必要がありました。ジャンプ先テキストが、ひらがな始まりとは限らない、というよりカタカナの方が多いわけです。そこでカタカナ→ひらがなの変換を作成、加えて濁点半濁点のカタカナは清音のひらがなになるようにもしました。アルファベットは「Ａ」に、数字は「数」にという変換も必要。

漢字は読み方がとれないため、data属性を用いて直接指定することにしました。漢字のジャンプ指定は数が少ないので、まあ良いか…と。ジャンプ指定は全体で1,000以上ありましたが、こうしたことで各タグの修正は20〜30で済みました。

個人で作っていると、どうしてもこういう見落としがありますし、それに気づくのにも時間が掛かってしまいます。

[rilmiah]

pythonその2

Javaで作ってあったサムネール作成ツール、FTPツール（SVGのInkscape情報削除、HTML、JS、CSSのminify、HTMLのサブ文書include込み）、家系図用画像のクリッピングツールもpythonに移植しました。 クリッピングツールはGUI操作のため調べ物はそれなりにありましたが、解ってしまえば割と簡単にできました。 しかもpython特有の記述によって、シンプルに書けて行数も減る（もちろん、共通部品化も一緒に考えています）。

Javaのもう一つの問題に、IDEを起動してしまうと時折自動処理によって.classファイルを消してしまうというものがあります。下手にIDEを起動・終了してしまうと、batファイルから呼び出している.classがいなくなっていて、エラーになってしまうのです。そうすると再度IDEを起動してビルドする必要があります。 その点、スクリプト言語であるpythonはソースコード＝実行コードのため、この問題は発生しません。これもとてもありがたいです。

家系図ツールについては、さすがにSwingでかなり作り込んであるものなので、そう簡単にはいきません。それでも、そのうち…と思わせるほど、pythonは魅力的です。

[rilmiah]

python

以前から興味はあったのですが、ちょこちょことサンプルコードをいじる程度でした。 BottleというWebフレームワークも、自宅LAN内のLinux環境（ファイル、DB等のサーバ）に入れたは良いもののとくに何かを作るわけではなく。

今回、Javaで作ってあったエルヴァートDB（Webサイトの一部ページの元データ…一部ページはJSONPでこれを表示しています）のメンテナンス画面を移植してみました。 と言っても、HTML、JS、CSSが1つずつで、サーバ側とはAjax（JSON）でやりとりするだけのアプリです。DB情報もなるべく単純化して定数持ちにしていたので、ほとんどロジックを移植するだけで済みました。

Javaはもう20年以上使ってきて、何かを作るに際して書き方や使うライブラリに悩むことはほとんどなくなりました。自分専用のライブラリも構築しています。BASICから始めて、CやC++、アセンブラ、FORTRAN、COBOL、VB、APL、Ruby、perl、PHP…いろいろ使ってきましたが、一番つっかえることなく使えるようになったのはJavaでしょう。 ただその一方、Webアプリの「重さ」が気になるようになってきました。サーブレットを用意し、処理ロジックをクラスで用意し、ビルドし、warを作る。 これだけでも結構面倒ですが、なにより面倒なのはTomcat（場合によってはApacheも）のセットアップと管理です。いまだに「誰か代わりにやってくれないかな」と思ってしまいます。ロジックを書くのはどれだけやっても苦ではないのですが、ミドルは…キャッシュが効いてうまく動かなかったり、反映に時間が掛かったりしてイラっとすることが結構あります。

始めたばかりのpythonは不明点が多く調べ物ばかりで、文法面で手間取ったり（ブロックの : をどうも書き忘れる）、Noneオブジェクトの扱いで手間取ったり、色々あったものの、正味1日くらいで完成にこぎ着けました。 やはり完成図が見えていると速いです。

統合環境（Intelli-J IDEA、以前はEclipse）で書けるJavaと異なり、例えばimportは自分でやる必要がありますし、文法エラーは走らせない限り判らない。うまくない面もあるにはあります。 ただ、昔は1つの画面でコマンドを叩いてエディタで編集、コマンドラインに戻ってコンパイル、続けて実行していたわけです。今はターミナルを2枚開いて片方で python hoge.py、もう片方はエディタを開きっぱなしにして、保存すれば即反映される。とてもラクです。

Java版で面倒くさくなってやっていなかった最適化・リファクタリングを一気に進めましたし、後々使いやすいように共通的な関数を別モジュールに分けたりもしました。 最初のアプリとして、規模の面でも良かったと思います。

加えてpython特有の記述が可能な箇所（三項演算や、forループ内包のlistなど）を見つけたりするのも楽しいです。 プロならもっと色々と見つけられるのでしょう。今後も折に触れて見直していこうと思います。