萌えツイを考えてみたが、現在頓挫中(桜織ツイート

Twitter のボットを作ろうかな、とちょっと思っている。
理由はボクのやりたいことができるボットがないからだ。やりたいことは以下の通り。

  1. 季節を認識する
  2. 祝日を認識する
  3. ボットにするキャラの生活パターンに合わせたツイートができる
  4. 画像も含めてツイートする
  5. テキスト ファイルを読み込ませて、それをツイートするモードが欲しい

他のことはいろいろできるボットは多い。特定の単語に反応したり、Reply に反応したり。⑤は BOT サービスだと GUI を使ってツイート内容を一つ一つ登録するタイプが多い。そんなのめんどくさい。テキスト ファイルを放り込むだけで済ませたい。
とりあえずツイートする部分を PHP で組んでみようと思い、組んでみた。

わりとあっさりできる。あとは季節・月・曜日や祝日をチェックして、それに応じたセリフをツイートするように組むだけ……なのだが、もう一つ問題がある。それは画像だ。上のツイートではもちろん画像のツイートに成功している。しかしそれが毎回新しい画像なら問題ないのだが、キャラのセリフにあわせた表情の画像をツイートするとなると、同じ画像を何度も使用することになる。
同じ画像がすでに Twitter 上にあるのにまたアップロードするのはよろしくない、とボクは思う。Twitter のサーバがそんなことで圧迫を受けるなんて事はまったくないだろうけど、やっぱり他人のサービスだし、できるだけ避けたい。

そこで考えたのが、予め必要な画像をツイートしておくと言うものだ。Twitter は画像の引用ができる。サービス開始前にツイートに必要な画像を全部ツイートしておいて、ボットがツイートするときには、アップロードした画像の URL と一緒にツイートすれば良いのだ。
しかしここでも問題がある。アップしたい画像は何千枚にもなるのだ(汗)。表情・ポーズ・服装を全部用意すると膨大な数になってしまうのである。はたして画像をアップロードするためだけにツイートしてよいものか? BAN されるのではないか……。

ところがこの「予め画像をアップロードしておく」というのには欠点があることが判明する。確かにツイートにすでにアップロードしておいた画像を含ませることはできるんだけど、その画像をクリックするとアップロードしたときのツイートが表示されてしまうのだ……orz(下のツイート)

というわけで毎回画像をアップロードするしかないのか……???
というところでこの Twitter ボット計画は現在頓挫中……。

下の写真はお昼に食べた日乃屋カレーのスペシャルカレー(三種盛り)。
ボクの中でウィンナーと鶏南蛮は定番となりつつある。残り一つを気分によって変える感じだ。

復帰後最初のまぜはる

萌え時計に黒翼とテトメトを追加した。脇役もちょっとずつ追加できればなぁと思いつつ。
追加したあと、黒翼はすぐに出たがテトメトがなかなか出ない。レアキャラになってしまった。
萌え時計のキャラ表示決定部分は、今のところ完全に立ち絵ファイルのランダムである。そのため、表情やポーズが多いキャラほどヒットする確率は高くなる。テトメトはポーズも表情も少ないので、なかなかヒットしないのだ。
もう一つ、着物姿の黒翼(表記ではクロハ)もヒットしづら。こちらは夜 Only になってしまっているためだ。ゴスロリの黒翼は F5 連打で割とすぐ出てくると思う。

と言うわけでお昼はまぜはるに行ってきた。台湾まぜそばで有名なお店である。
渋谷から浅草橋に戻ってきてからのリハビリ飯(ぁ
辛くて濃くてうまい、と思う。コレを置かずにご飯がいけてしまう(笑

リバースプロキシの秘密は preserveHostHeader にあり

ボクは aipo というグループウェアを一人で使っているのだが(笑)、一人で使うので、割と URL がテキトーだった。例に挙げれば、https://amatsukam.jp:3333/ って感じ。なんだよこの 3333 って数字は! みたいなw
https は本来 443 で動くのだが(なので何も指定しないと 443 番で通信しようとする)、そちらは色んな人がアクセスするための別のサービスが動いているため、ボクしか使わないグループウェアの方はテキトーなポート番号を割り当てていたのだ。

が、先日リバース プロキシというものを知ったボクはこの aipo も https://amatsukami.jp/aipo/ にできるのではないかといろいろ悪戦苦闘していた。

それがついに解決して、3333 を付けなくてもアクセスできるようになった。
Microsoft 製リバースプロキシである Application Request Routing の preserveHostHeader という設定を True にすることにより、インターネット網からアクセスしてきたホスト名でリバースプロキシ下にあるサーバ群にアクセスするようになった。
というわけでホスト名に関しては、まずは解決。

しかし問題はこれだけではない。aipo はルートディレクトリに配されている。どういうことかというと、https://amatsukami.jp:3333/ が aipo のホームページ(ホームディレクトリ)である。しかしこれを、https://amatsukam.jp/aipo/ にしたい。リバースプロキシだけでは、コレを解決できない(たぶん)。aipo 本体も https://amatsukami.jp:3333/aipo/ にしなければならないわけである。

んでなんとなーく aipo のドキュメントを眺めていると、昔 aipo ディレクトリで運用されていた名残があるような感じで、んじゃー、aipo フォルダってのを作ったら動くんじゃないかと思ってやってみたら動いたwwww
具体的には、aipo のインストール先である「dpl8110\tomcat\webapps」っていうディレクトリに、ROOT というディレクトリがあるので、それをそっくりそのまま aipo というディレクトリ名に変えるだけである(万全を期すなら、ROOT は残しておき、ROOT ディレクトリを aipo というディレクトリ名でコピーする)。こうすることによって、aipo は https://amatsukami.jp:3333/aipo/ で動くようになった。
次に aipo のプラグインなどを提供している container ディレクトリだが、こいつは単純にリバースプロキシで、https://amatsukami.jp/container/ ってアクセスが来たら、aipo のサーバにそのまま飛ばすようにすればよい。ただコレの欠点は、amatsukam.jp では container というディレクトリが使えなくなることだが、別に問題はないだろう(理想を言えば、aipo/container/ にするべき)。

また、3333 という数字をつけなくてすむようになったので、iPhone のカレンダーに aipo のカレンダーが取り込めるようになった。aipo に入力した予定表がそのまま iPhone でも見られる。イイ感じ!

下の写真はお昼に食べに行った「アカス」のランチ。タンドリーチキン付き。真ん中のはタンドリーチキンだよ! 見間違えないでよ!(何

日乃屋の野菜カレーは根菜だった

日乃屋カレーへスペシャルカレーを食べに行った。最近、日乃屋カレー率高いなw
まぁ好きなんだからしようがない。
そして今回は、野菜とウインナーと鶏南蛮をトッピングに選んだんだけど、野菜がサツマイモにズッキーニ、パプリカ、レンコンというラインナップで驚いた(笑)。いやまぁ、全然いいんだけど、ただサツマイモはやっぱりモサモサしちゃうねー。ルーが甘いから余計甘くなっちゃうし。
レンコンはイイ感じ。パプリカとズッキーニも水分少なめでベチャッとならないようになってた。

そして今日も 9/25 だというのに 30 ℃越えである。

萌え時計をレスポンシブデザインに対応させた。サイズ指定がいっさい必要なくなり、萌え時計が配置された要素に従うようになった。だいたいは iframe を使って貼ると思うのだが、その iframe の大きさに勝手に合わせるようになる。
上のツイートでもブラウザいっぱいに表示された萌え時計の文字が、画像の大きさに合わせてちゃんと拡大されて、位置も概ね合っていることが解る。

詳しい記事はこちらに。

ただ今回の対応では縦横比が 1:1 じゃないと正常には表示されない。
萌え時計はそもそも 1:1 なので、まぁ別にいいかって感じではあるのだが……これが長方形だと今の組み方では文字の大きさを幅に対してしか見てないので、横幅に関しては正しく認識するけど、縦幅に関しては正しい大きさにならない。縦横比が 1:1 だと横の%=縦の%でもあるので正常に表示されるのだ。
縦に対して考慮してないのは、Microsoft Edge が対応してないから(汗
なのでそのうち、対応する予定。

SMB3.0 とか金融とか kobo とか

ボクはウェブサービス以外で自宅のサーバとやりとりするときは VPN をつないでやっているのだけれど、PC はともかく(起動時に VPN を勝手につなげるようにできるので)、モバイル端末ではイチイチ VPN 接続してからサーバにアクセスしなければならない。それに、VPN 分のオーバーヘッドも発生する。

VPN 経由で主に使うサービスはなんと言ってもファイル サーバだ。サーバ上にある様々なファイルにアクセスしたいわけだ。なので、Windows の共有フォルダがそのままインターネットで使えれば、VPN を経由しなくてもすぐに使える。

SMB3.0 から、それが可能になった。いや、今までも可能っちゃぁ可能だったんだけど、セキュリティ的にお粗末な実装だったため、とてもじゃないがインターネット網に出すわけには行かなかった。

と言うわけで、ちょっと自宅サーバの SMB をインターネット網に出して見た。

接続速い! ファイル転送も速い! いいじゃんコレ!!

でもねぇ、色々懸念点はある。この SMB は過去何度も攻撃対象にされてきた。SMB の穴を攻撃するマルウェアもたくさんある。そのため、市販のルータは SMB で使うポートを塞いでいることが多い。今回もボクの自宅のルータが SMB のポートを塞いでるせいで最初アクセス出来なかった。

もう一つ、SMB に対する世間の印象も悪いことが挙げられる。過去、そうやって漕ぐ駅対象にされたおかげで、とにかく SMB が使うポートは必ず塞ぐのが基本という習慣がすっかり定着してしまっているのだ。なのでボク自身は、ボクのルータの設定だけで住むが、他人に「ここにアクセスしてー」って手軽に渡せる代物ではないのよねぇ……。

まぁでもとにかくできることは解ったので、今後、使用する方向で検討していきたいと思っている。

金融の記事、時々見るけど、そもそも言葉がサッパリわからないんだよね。
みんな解ってて読んでるのかなぁ? ボクはサッパリ解らないや。上記の意味も、もー、何が何だかサッパリだ。で色々調べた結果、とある企業の株価が急激に下がったりしたときのための保険みたいなのがあって(ヘッジとクレジット デフォルト スワップ)、その保険料がすげー値上がりしてる(つまりその企業はいよいよヤバいって事)、っていう意味らしい。レーバーデー開けってのはアメリカの休日明けで、要するに休み明けにクレジットデフォルトスワップの値上がりがすげーカーブを描いてて、倒産は誰しもが解ってたんじゃないの? っていうような記事だった。

秋葉で画面解像度が 1920×1200 の Android 端末2999 円で売ってたので買ってきた。何に使うかというと、これで Windows でデュアル ディスプレイをやるのだ。会社の開発機は、1920×1200 のパネルが二枚あるんだけど(NEC と EIZO)、自宅は 1920×1200 が一枚しかないのだ。

そして反応速度に難はあるが、動画をずっと再生して奥分には問題なし。
ただ、7 インチに 1920×1200 は業務では文字が細かすぎて使えなかったww

気温とか 4K とかカレーのシミとかミルクとか

またまた Twitter から拾った、いろいろくだらない&どうでもいいネタ。

暑い! ってただそれだけである。残暑は長し。

まぁメモ程度に。1080p と較べるとファイルサイズはほぼ倍。電池は 10 ポイント多く使用した。さすがに 4K クラスとなると HEVC で録画したいんだけど、Premiere で読み込めないので未だに互換フォーマット。というか、PhotoshopHEIF に対応してくれないと移行でできない……orz
すぐ対応すると思ったのになかなか対応しないなぁ……。

そう!こういうのないの? ボクは白が好きなので、割と白を着るんだけど……時々食事の時失敗しちゃうんだよねぇ。そしたらもうそれは選択肢なくちゃいけなくなる。上のようなウェットティッシュがあれば、ちょいちょいってその部分に薬品(?)を浸透させて、そのあとウェットティッシュ側に吸い取るみたいな……そういうのないのかなぁ。

先日 TAMA Networks の旧コンテンツを別サーバに移した。そしたら、訪問者カウンタがおかしくなった。理由は簡単で、リバースプロキシ(Application Request Routing)経由でアクセスするため、旧コンテンツから見たらリバースプロキシしかアクセスしてこないためだ(笑)。
旧コンテンツに何千人、何万人来ようが、全部リバースプロキシが間に入るので、旧コンテンツからしたら一人がすげー勢いでアクセスしてくるな、って事にしかならないのだw

と言うわけで、リバースプロキシ側で HTTP ヘッダに HTTP_X_FORWARDED_FOR という名前で、アクセスしてきた人の IP アドレスを入れて、それを旧コンテンツに渡し、また旧コンテンツでは REMOTE_ADDR でカウントするのではなく、先ほどの HTTP_X_FORWARDED_FOR でカウントするように書き換えた。これで解決。

シティハンターだったっけなぁ? キャッツアイだったかなぁ。女子高生とかを「ミルク臭い」と呼んでいたのを思い出した。確かに 10 代の女の子って代謝が早いせいなのか、ミルクのような臭いがしてた。でも最近、JC も JK も大人びちゃって化粧やら香水やらするから、あの臭いはしなくなったよなぁなんてことをふと思う(ぁ
脱いだら解るけど。

そしてエロゲを作ってるからかもしれないけど、アレだよね、すっかりミルク臭いなんて表現は使わなくなったって言うか、もう女子高校生や女子中学生くらいが恋愛のターゲットになっても驚かれなくなったよなぁ……。エロゲだと容姿的にそれくらいが普通だもんなぁ。

リバースプロキシの基本がわかってない(ぁ

さて、昨日は古い PHP で動く旧コンテンツを、リバースプロキシApplication Request Routing)を使って別のサーバに追い出すことに成功した。ということはだ、今別サーバで色々動いているものが、少なくとも見た目上は一つに集約できるのではないかということに気づく。

今、Redmine(プロジェクト管理)やグループウェア(Aipo)なんかが動いてはいるんだけど、それらは全部 HTTP でやりとりするのね。しかも Windows で動かすと全部独立したサービスで動くため、これらを一つの HTTP で動かすわけにはいかないという状況だ。

そこでどうしているかというと、不特定多数の人がアクセスするサービスはデフォルトに割り当て、ボク一人で使っている Redmine やグループウェアは TCP ポート番号を分けることによって使い分けていた。
たとえば、http://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、http://amatsukami.jp/redmine/ ってやると http://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て http://amatsukami.jp/ で完結できる。

というわけでさっそく一番使用頻度が高いグループウェアで設定してみようとするんだが、これがうまくいかない。ホスト名が一致しないのだ。
どういうことかというと、リバースプロキシ経由になるということは、グループウェアにアクセスしに来るのはリバースプロキシと言うことになる(アクセス経路は以下の通り)。

ユーザ → リバースプロキシ → グループウェア

リバースプロキシとグループウェアは LAN 内で結ばれていて、お互い LAN 内の名前(ホスト名という)で呼び合っている。この LAN 内のホスト名はインターネットの世界では通用しない。でもグループウェアは呼ばれたホスト名で応答するように作られており、リバースプロキシは LAN 内でしか有効でないホスト名をそのままユーザに返してしまうため、インターネット網にいるユーザは結局アクセス出来ないのだ。

じゃぁ旧コンテンツはどうしているのかというと、旧コンテンツのエンジンである Pukiwiki Plus ! は返すホスト名を固定できるのだ。このホスト名をインターネットで通じる名前にしておけば問題ないというわけである。
ところがボクが使っているグループウェアにはこの機能が無い。
ただこの時、ボクはグループウェアの方に着目してしまったのよね……これが遠回りの原因になってしまった。グループウェアはオープンソースなもんだから、ソースとかを見始めちゃったのよね……orz
結局、この日は解決することができなかった
(正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった)

下の写真は浅草橋で一番美味しい(とボクが思い込んでいる)、ろく月の豚白湯麺とチャーシュー丼。うまいー!