カテゴリー: Final Fantasy XIV

Home / カテゴリー: Final Fantasy XIV

ニームの書で使った道具

2018-12-12 | Final Fantasy XIV, Flask, halipe.co, JavaScript, Python, Responder | コメントはまだありません

そのうち使ってるツールを差し替えたりもするだろうから、いったん今のとこの技術スタック(っていうの?)をメモしておく。
基本的にはPython(Flask)以外はほぼぜんぶ初めて使うもので占められている。ふつうは知らないことを追加するのは+1にしなさいっていうんだけど、完全に無視した。のたうち回ったし、のたうち回っている。

ニームの書(halipe.co)

Backend

スクリプトはすべてPython。Flaskつかってて、Responderにリプレイスできるか試している。最初はElixirいくか!!とか息巻いてたが、API作るくらいのことで死にそうなのでやめた。
いまはGAEのFlexible環境にDockerコンテナ投げてAPIサーバが立ち上がっていて、ほかにはCloud Functionsで関数(これもPython)がいくつか。

そもそもはKubernetesに習熟したいという野望があってしこしこyaml書いてた。超楽しい。が、SSL証明書の取得と設定らへんで盛大にすっ転んだうえ、誤ったコンフィグを投げてはLet’s encryptにロックされて作業が止まるため、急遽GAEに逃げ込んだという次第。証明書やらドメインまわりやらが便利すぎてヨダレ出た。一方でデプロイ10分以上かかるのはちょっと辛い。
なんかStandard環境でもPython3使えるみたいなのを見かけたのでそっちに移す予定。jsonやyaml読んでjson吐くくらいしかしてないしょぼいAPIの為に毎月5000円払っている。しょぼいわ。
むろんそんだけの機能を、Kubernetesでクラスタあげようとしてたわけです。立ち上がってたら5000円どこじゃ済まないが、それはいいんだ。インフラ屋でもない人がこういうのの構築やるにはホビーくらいしかチャンスがない。
コマンド一個でPodが増えたり減ったりするのは、なんとも言えない愉しみがあった。あのPodやらService、むかしは物理サーバ一個一個でやってたんだぜまじかよってかんじ。

CI

リポジトリはBitbucket使っているので、マスタへのマージの際にBitbucket Pipelinesを起こし、Slackに通知するようにだけしている。
Python側だけテストが少し書いてあって、フックでテスト通すとこまでできた。これももちろん初めてだったので、動いたときはそれはもう大変に嬉しくて、ムダにPushした(程なく無料ビルド時間を使い切り動かなくなった)。
JS側がテスト書くまで至っておらず、まだ完成してない。Jestというのを見つけたので使ってみようと思っている。

DB

DBはCloud Firestoreをつかっている。ゼロの状態からNoSQLのDBつくんの初めてだった。リレーションとかあんま気にしないでいい単純なアプリなので、あんまり深い困りごとには遭遇してない。タグ検索とかの実装用にインデックスのテーブルこさえたりしたけど、テーブルそのものに張ってるindexつかうのとどっちがいいんだろうみたいな感じ。活用してる感はない。
更新情報とかはSpreadSheetに書き付けていて、反映用のスクリプト叩くとFirestoreにデータを放るという運用をやっている。一番最初はvueファイルにまるまる書き込んでたので、更新情報のっける程度の用事でデプロイが発生していた。

Frontend

TypeScript + Nuxt.js。どっちも使ったことないので採用。ホビーとはいえ無茶な挑戦だった。困ったときにTypeScript/Vue.js/Nuxt.jsいづれの問題なのかの切り分けすらできないような三下が、まるっきり全部わかんない状態で挑んだ。
作業の大半は調べ物の時間で、文字通りヨレヨレになっていた。
いっぽう尋常でない学びはあった。イベントハンドラって何?みたいな基礎部分への理解も危ういくらいの人だったんだが、なんとかなりつつある(まだ危うい)。
CSSまわりはBulmaを入れた。じつはCSSフレームワークの導入からやったのも初めて。
ほんと今まで何やって食ってたんですかねという感じなんだが、すでに動いてるプロジェクトに参加することが多いと下地はあらかた出来上がっていたりで、構築にはあんまり関与しないで済んじゃってたという背景がある。

ほか

手元でバッチやらを書く下地はJupyterNotebookを使うことがある。ド頭から動かさずに気になるとこだけ叩けるというのがことのほか便利で感動している。
表の操作はPandasとか使ってるけど、必要でというよりは使う理由になるので入れてるといった感じ。慣れておきたい。

地図をはじめ、さまざまな画像は基本的にFireworksでやっている。今となっては太古のアプリなんだろうか。あたしの用途ではこいつを超えるアプリケーションが地上にない。Vectorスイスイ書いてビットマップを切り取る切り抜くとかを、こやつだけが軽快にやってくれる。問題は古いのででかい画像に超弱い。もともとメモリの危ういソフトなんだがすぐ吹っ飛びそうになるのでおそるおそるやっている。横1900のPNGを9枚も食わすともう挙動不審になる。

ロゴのVectorを作るとかはIllustlatorをつかっている。これも昔々のやつだけど、あたしは線が書けてaiが書き出せたらいいので、それ以外のことでは全く用途がない(せいぜいトレースくらい)ので、たぶんもうこの先新しいIllustlatorを買う機会もあるまい。いまはそっち側で食べてるわけでもないし。
あ、名刺作るときは活躍してるんだった。赤作るときはYMを100にするだけじゃなくて黒10%入れろとか、ああいう細かい話がたまーに活きることがある。
オンデマンド機だと関係ないけれども。

相変わらずにーむのしょをいじっています

2018-12-08 | Final Fantasy XIV, halipe.co | コメントはまだありません

WP5.0に上げたら編集画面がWordみたいになった。なんでこういう余計なことをするんだ。まあいい。
昨日今日あたりは、スマホでタグ付けらんなかったのを修理(というか回避というか)して、認証コケるやつの背景を調べて(まだ糸口つかめない)、あと運用周りの準備してた。
いままで500エラー出てもなんも気づかないとかだったので、とりあえず500とtracebackひっかけたらSlackに飛ぶようにして、少なくとも検知はできますよと。あと、ユーザ登録時に認証状態が半端になるようなところがあるので、そっちもイベントで引っ掛けて検知だけでもできるように。

仕事でやってるとテストだの運用だの監視だのってダルいんですけど、さすがに自分のサービスなんでモチベーションが違うよね。それでも昔ツール書いてたときって障害とかには無頓着だったんだけども。たぶんGCPとかにあらかたツール揃っていて、アクセス解析や障害検知のセットアップしなくて済んだのが大きい。
そう考えると昔の人は偉かったんだなあ。すっごい他人事なのは、当時はまるっぽ知らんぷりで人任せにしてたからです。

火曜はリセット日なので

2018-12-05 | Final Fantasy XIV, halipe.co | コメントはまだありません

なにかといそがしい。
明日から奥様がバイト行くっていうので、今日は夕ご飯のあとにレクリエーションをしました。いつも気の利いたこと思いつけないので、こういうのは我が家ではけっこう珍しい。

たまたまGoogleがクリスマスのアドベントカレンダー的にアレコレ詰め込んだサービスの塊を出していて、そんなかにScratch(教育用コンピュータ言語。ブロックつなげて動作を作る)をつかったパズルがあったので、一緒にやったりしてました。

奥様もかつては、あちこちのホームページを見てはScriptを目で追い読み込み手で試し、自作のCGIやらも含めていろいろやってたらしい。そのまま続いてたらそれなりに高給取りだったのにもったいない。
今じゃロジカルな部分など毛ほど見せない人ですけど、一緒にパズルを解くくらいは付き合ってくれるかなということで遊んでました。
上下左右に進むのとループのブロックだけのシンプルなパズルだったのだけれど、大変に楽しかったみたいで、よかった。

リセ日です。リセ日なのですが、明日以降は慣れない仕事でヨレヨレということを考えると、のんびり一緒にパズルで遊んでくれるのは今日くらいということでそんなんやってました。

ほんでそのあとFF14にログインし、地図のスクリーンショットを撮り、にーむのしょのイケてないスクリプトを修理し、アルファ編やらエキルレやらを積んできょうはおしまい。

今のとこ大して人も来ないしまるで使われてる気配のないしょぼいWebサービスですが、このまま更新続けていきます。この次に作るやつも粗々まとまっているので、そろそろ設計開始であります。

画像の変換が辛い

2018-11-29 | Final Fantasy XIV, halipe.co, Python | コメントはまだありません

ニームの書(https://halipe.co/

まだ全然データ足りないんだけど、色んな人にボコボコにしてもらうほうがモチベーション保てると思って見切り発車しちゃった。地図足りてないんで日々追加してます。

SS撮る(1600ピクセル四方くらい)→Firewirksでつなげてトリミング→色調補正バッチに食わせて出力→サーバに転送

なんてダルいんだ。色調補正バッチがうまいこと稼働してるので、地図張り合わせるのがすごくダルいくらいで済んでる、それはいいんだ。
今日の問題は色調補正バッチ。さくさく変換してくれるのはいいんだが、一枚あたり30秒かかる。ほっときゃいいとはいえ辛い。というか、あきらかに遅い箇所があって、さすがにバカなことやってる箇所だから直したい。

実験用にJupyterNotebook起動。

import os,sys,re
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from PIL import Image
import matplotlib.pyplot as plt
import itertools as it
import time
%pylab inline --no-import-all

いつものやつ。余計なのも入ってるが気にしない。

img = Image.open(r"la-noscea_サスタシャ浸食洞.png")
im = np.array(img)

サスタシャの地図を一枚読み込む。
今回やろうとしとるのは、ゲーム内の画像そのまんまだと色調があまりにもくすんでいるので明るい感じに修正する、というもの。実際には前にやっていて(FF14の画像をバッチで画質処理+コピーライトの貼り付けしたい)、こんかいはそれのリファクタというかありえないコードになってるとこを直す話。

元のコード

30秒かかるのは流石にやばい。これ書いた当初は「画像の変換って時間かかるんだな~」とか牧歌的に思ってたが、PhotoShopがこんな速度でフィルタかけてたらAdobeは今頃地上から消えていたはずだ。
なにが問題かというとまあさすがに明白で、ピクセル一個ずつをループで丁寧に変換して歩いてるところ。当時は書き方わかんなかったし、改善よりも歩を進める事を優先したので斯様な惨状を放置する運びに。

なんでじゃあ改善するかというと、リリースしてガンガン地図増やすぞという頃合いになると、所要時間がだんだん冗談で済まされなくなってくるから。
いま作り終わってる地図が33枚あるんだけど、こいつの処理完了に15分かかる。ちょっとこれは引く。

修正後

あれこれすっ飛ばして結論。行列への関数適用をずばっとやってくれる関数を見つけたので、何となくこうですか的な具合で書いてみる。
0.27秒。意味がわからん速度が出た。いやわかるわ。30秒が意味分かんないわ。
ということであっけなく変換バッチの改善作業が終わった。

まったく苦労してないので、今回もまたnumpyとからへんが身につくほどの作業量にならずじまい。
画像の変換は触り始めると楽しいので、継続的にやってこうかなという気にはなってる。

こんかいつかったnotebook(gist)
https://gist.github.com/mezquita/0d4d99e2d66c9397949966840853779e

文中の画像の権利表記:Copyright (C) 2010 – 2018 SQUARE ENIX CO., LTD. All Rights Reserved.

日記書くの二年ぶりだって。まじか。
ちょっと開発してるやつあるんで作業メモ。

やりたいこと:

  • たくさん画像あるやつを一律で補正して、固定イメージはっつけて別名で保存したい
  • 素材の画像をバッチに食わせて、別名で新しい画像を得たい
  • 要はFF14の画像を大量に画質処理+コピーライトの貼り付けしたい
  • 年が変わるとコピーライトの年表示が変わるから、繰り返し生成しなおすことを視野に入れたい

ふだんFireworksつかう(Photoshopはもう完全に使い方忘れた。かつては仕事道具だったのに)のだけど、こいつがバッチ処理みたいな機能ある。これつかって楽できんかと思ったけども、せいぜいサブネイル作るくらいのしょっぱい代物で話にならない。
もういい、画像ライブラリ振り回してなんかできるじゃろ、数学得意じゃないけどトーンカーブもなんとかなるじゃろということで。

Jupyter notebookで実験

とりあえずJupyterNotebook起動して、Pillowとかいろいろ読み込んどく

import os
from PIL import Image
import numpy as np
import matplotlib.pyplot as plt

はりさんの画像を読み込んでみる。

いいんじゃないすか。上のはりさんはスクリーンショットを切り取って小さくしただけのもので、補正やらは一切なし。暗い屋内だわくすんでるわ、ぱっとしない。

ほんではどっかから拾ってきたサインカーブ作るやつをplotで描かせてみる。
やっべグラフとか描いちゃってかっけえ。理数系ってこういうの鼻歌でやるんじゃろかっけえ。

ともかく、各ピクセルにこいつを食わせると暗い色をより暗く、明るい色をより明るくしてメリハリが付く。

ほんとはカーブの具合を上みたいな感じのカーブにいじりたいが、式の書き方がわかんないのでいったんこれで。拙速がだいじ。
さしあたり効率やらノウハウやらわかんないので、愚直に各ピクセルのRGB値を変換していく。

後ろの照明がぱっと明るくなってたり、はりさんの顔にあたってる明かりが明るくなってたり。フィルタはちゃんとかかったということで進める。

次、コピーライト画像を読み込む。
これを読み込んで、画像(今回ははりさんの画像)の、所定の位置にコピーライトを貼り付けたい。
ちょっと困ってるのが、元の画像ったらわりと大きめのマージンがあること。このマージンがだいぶ邪魔なので、ほんとは空白部分をトリムしたい。
cropでうまくいくとあったんだが、正確に0でないピクセルがありそうな気配でtrimかかんない。
一旦いいや。実際やるときはマージン分をいいぐあいに調整して貼り付けちゃおう。

はりさん画像とコピーライト画像のサイズを取得して、はりさん画像のどの座標にコピーライト画像を貼り付けたらいいかを調べる。テキトウにpaste_pos関数作っておこう。2つの画像をあげると、どの座標に描いたらいいかを返すやつ。横0縦184ピクセルのとこに貼り付けたらいいとわかった。

Image.pasteにコピーライト画像、貼り付け先の座標を渡す。引数のmaskにもコピーライト画像をわたしてるのは、これでアルファチャンネルをよしなにしてくれるとのことで。
上のサンプルではコピーライト画像のほうが横幅が大きいけれども、溢れたぶんはなくなる。
実際にこの仕掛けを利用するときはもっと大きな画像を使うことになるので、横幅あふれた―とかは実際には発生しないので、気にしないでよい。

だいたい実験が完了したので、これをバッチスクリプトとしてまとめたら終わり。
いままで画像処理やること少なかったわ、式わたして数値の変換するなんてこともやったことなかったわで、若干進歩。プログラミングのための線形代数買ってあるのに積んでるんだよなー

そのうち読もう。こういうのに役立つ何かが書いてあるかも。