コメントはまだありません裏側のバッチ直してますとか、更新情報をシート管理にしましたとか、いわゆる運用タスク的な課題ばっかりをここ何日かはやっていた。先の未来の自分を助ける重要な必要な改修なのだが、ユーザの目にはなにも変化が見えない。そんな事を気にするほどの訪問数じゃないので別にいいのかもしれないのだが、しょぼい訪問数のうちから健全なイテレーションを回すのを習慣づけたいなという気持ちがある。みわかりやすいのは、地図の操作を直したとか、地図の画像増やしたとかそういうのだ。一方でわかりにくいのがここ数日やってたような、裏方作業。それぞれをいい塩梅に交互にやっていくようにしていくと、ユーザの側からは更新され続けていることがわかり、裏側に積み上がる課題も一定のペースで処理していける。いえ動かす手は二本、頭は鈍いやつ一個でしかないので、Nozbeに積み上げていくタスクがなかなか減ってくれない。チケットはいまのところ50件前後を行ったり来たりしている。Kubernetesやらの関連チケットを別のとこに分けてこの件数。なかには大きな玉(作業量の大きなチケット)もあって、いきなり抱えるとしんどくなって潰れるので、小分けにして乗り越える必要がある。改善タスク的な今やる必要のないものもあるけれども、それでもできたら20件くらいにしておきたい。やることだらけだよ―という気持ちがだんだんオリになって心に沈殿していくのはあんまりよいことでない。地図つなげる作業はひとことで言うとダルいのだが、頭を使わないで黙々とやれる。考え事の合間に消化するような進め方がいいかもしれない。こないだの週末みたいに地図60枚とかいう馬鹿げた作業をするから疲れるんだ。コメントはまだありませんそのうち使ってるツールを差し替えたりもするだろうから、いったん今のとこの技術スタック(っていうの?)をメモしておく。基本的にはPython(Flask)以外はほぼぜんぶ初めて使うもので占められている。ふつうは知らないことを追加するのは+1にしなさいっていうんだけど、完全に無視した。のたうち回ったし、のたうち回っている。ニームの書(halipe.co)BackendスクリプトはすべてPython。Flaskつかってて、Responderにリプレイスできるか試している。最初はElixirいくか!!とか息巻いてたが、API作るくらいのことで死にそうなのでやめた。Functionsで関数(これもPython)がいくつか。そもそもはKubernetesに習熟したいという野望があってしこしこyaml書いてた。encryptにロックされて作業が止まるため、急遽GAEに逃げ込んだという次第。証明書やらドメインまわりやらが便利すぎてヨダレ出た。一方でデプロイ10分以上かかるのはちょっと辛い。なんかStandard環境でもPython3使えるみたいなのを見かけたのでそっちに移す予定。jsonやyaml読んでjson吐くくらいしかしてないしょぼいAPIの為に毎月5000円払っている。そんだけの機能を、Kubernetesでクラスタあげようとしてたわけです。立ち上がってたら5000円どこじゃ済まないが、それはいいんだ。インフラ屋でもない人がこういうのの構築やるにはホビーくらいしかチャンスがない。コマンド一個でPodが増えたり減ったりするのは、なんとも言えない愉しみがあった。あのPodやらService、むかしは物理サーバ一個一個でやってたんだぜまじかよってかんじ。Pipelinesを起こし、Slackに通知するようにだけしている。Python側だけテストが少し書いてあって、フックでテスト通すとこまでできた。これももちろん初めてだったので、動いたときはそれはもう大変に嬉しくて、ムダにPushした(程なく無料ビルド時間を使い切り動かなくなった)。JS側がテスト書くまで至っておらず、まだ完成してない。Jestというのを見つけたので使ってみようと思っている。Firestoreをつかっている。ゼロの状態からNoSQLのDBつくんの初めてだった。リレーションとかあんま気にしないでいい単純なアプリなので、あんまり深い困りごとには遭遇してない。タグ検索とかの実装用にインデックスのテーブルこさえたりしたけど、テーブルそのものに張ってるindexつかうのとどっちがいいんだろうみたいな感じ。更新情報とかはSpreadSheetに書き付けていて、反映用のスクリプト叩くとFirestoreにデータを放るという運用をやっている。最初はvueファイルにまるまる書き込んでたので、更新情報のっける程度の用事でデプロイが発生していた。どっちも使ったことないので採用。ホビーとはいえ無茶な挑戦だった。困ったときにTypeScript/Vue.js/Nuxt.jsいづれの問題なのかの切り分けすらできないような三下が、まるっきり全部わかんない状態で挑んだ。作業の大半は調べ物の時間で、文字通りヨレヨレになっていた。尋常でない学びはあった。イベントハンドラって何?みたいな基礎部分への理解も危ういくらいの人だったんだが、なんとかなりつつある(まだ危うい)。CSSまわりはBulmaを入れた。じつはCSSフレームワークの導入からやったのも初めて。ほんと今まで何やって食ってたんですかねという感じなんだが、すでに動いてるプロジェクトに参加することが多いと下地はあらかた出来上がっていたりで、構築にはあんまり関与しないで済んじゃってたという背景がある。ほか手元でバッチやらを書く下地はJupyterNotebookを使うことがある。ド頭から動かさずに気になるとこだけ叩けるというのがことのほか便利で感動している。表の操作はPandasとか使ってるけど、必要でというよりは使う理由になるので入れてるといった感じ。地図をはじめ、さまざまな画像は基本的にFireworksでやっている。今となっては太古のアプリなんだろうか。あたしの用途ではこいつを超えるアプリケーションが地上にない。Vectorスイスイ書いてビットマップを切り取る切り抜くとかを、こやつだけが軽快にやってくれる。問題は古いのででかい画像に超弱い。メモリの危ういソフトなんだがすぐ吹っ飛びそうになるのでおそるおそるやっている。横1900のPNGを9枚も食わすともう挙動不審になる。ロゴのVectorを作るとかはIllustlatorをつかっている。これも昔々のやつだけど、あたしは線が書けてaiが書き出せたらいいので、それ以外のことでは全く用途がない(せいぜいトレースくらい)ので、たぶんもうこの先新しいIllustlatorを買う機会もあるまい。いまはそっち側で食べてるわけでもないし。あ、名刺作るときは活躍してるんだった。赤作るときはYMを100にするだけじゃなくて黒10%入れろとか、ああいう細かい話がたまーに活きることがある。オンデマンド機だと関係ないけれども。コメントはまだありませんサーバサイドはまだいいけど、ローカルでエラー出るじゃん。いうかフロントヘビーな時代だから不具合ってどっちかというとブラウザに出るわけで、そんなんこっち預かり知らんからリロードしてよみたいになるじゃん。仕事ならそんくらい適当でもいい(よくない)んだけど、ニームの書はそうはいかんので。尻ふく人あたししかいないんだもん。(うちとこの場合だとjson読んでjson吐くくらいのことしかしてないから、APIでエラー出るってケースがそもそもほぼない)ない頭捻ってうんうん考えた挙げ句、バックエンドと同じ文脈に持ってけばいいじゃねえかとなった。ためしにフロントでなんかエラー出るとするわ。FirebaseのAPIがあかんかったーとか、中身は何でもいい。出たらとりあえず可哀相ですねリロードしてねでいいんだけど、拾ったエラーはAPIでpostしとくと。起こった事象だけでもpostして、投げられたエラーコードやメッセージはFirestoreに保存していくと。js自体がエラーで止まっちゃったらどうしようもないんだけど、やらかしそうなとこにtry-catch張ってけばいいんじゃろ。例外上がったら問題点をまとめてAPIに投げると、すくなくともユーザの側でなんの問題が起きたのか、わかるんじゃないかなと。いう対応に詳しい人がいたらまた別のことやるのかもわからん。生きすぎていて、この辺のノウハウが全然ない。コメントはまだありませんニームの書(https://halipe.co/)まだ全然データ足りないんだけど、色んな人にボコボコにしてもらうほうがモチベーション保てると思って見切り発車しちゃった。地図足りてないんで日々追加してます。SS撮る(1600ピクセル四方くらい)→Firewirksでつなげてトリミング→色調補正バッチに食わせて出力→サーバに転送なんてダルいんだ。色調補正バッチがうまいこと稼働してるので、地図張り合わせるのがすごくダルいくらいで済んでる、それはいいんだ。今日の問題は色調補正バッチ。変換してくれるのはいいんだが、一枚あたり30秒かかる。ほっときゃいいとはいえ辛い。いうか、あきらかに遅い箇所があって、さすがにバカなことやってる箇所だから直したい。実験用にJupyterNotebook起動。--no-import-allいつものやつ。余計なのも入ってるが気にしない。np.array(img)サスタシャの地図を一枚読み込む。今回やろうとしとるのは、ゲーム内の画像そのまんまだと色調があまりにもくすんでいるので明るい感じに修正する、というもの。実際には前にやっていて(FF14の画像をバッチで画質処理+コピーライトの貼り付けしたい)、こんかいはそれのリファクタというかありえないコードになってるとこを直す話。元のコード30秒かかるのは流石にやばい。これ書いた当初は「画像の変換って時間かかるんだな~」とか牧歌的に思ってたが、PhotoShopがこんな速度でフィルタかけてたらAdobeは今頃地上から消えていたはずだ。なにが問題かというとまあさすがに明白で、ピクセル一個ずつをループで丁寧に変換して歩いてるところ。当時は書き方わかんなかったし、改善よりも歩を進める事を優先したので斯様な惨状を放置する運びに。なんでじゃあ改善するかというと、リリースしてガンガン地図増やすぞという頃合いになると、所要時間がだんだん冗談で済まされなくなってくるから。いま作り終わってる地図が33枚あるんだけど、こいつの処理完了に15分かかる。修正後あれこれすっ飛ばして結論。行列への関数適用をずばっとやってくれる関数を見つけたので、何となくこうですか的な具合で書いてみる。意味がわからん速度が出た。30秒が意味分かんないわ。いうことであっけなく変換バッチの改善作業が終わった。苦労してないので、今回もまたnumpyとからへんが身につくほどの作業量にならずじまい。画像の変換は触り始めると楽しいので、継続的にやってこうかなという気にはなってる。Reserved.日記書くの二年ぶりだって。開発してるやつあるんで作業メモ。やりたいこと:たくさん画像あるやつを一律で補正して、固定イメージはっつけて別名で保存したい素材の画像をバッチに食わせて、別名で新しい画像を得たい要はFF14の画像を大量に画質処理+コピーライトの貼り付けしたい年が変わるとコピーライトの年表示が変わるから、繰り返し生成しなおすことを視野に入れたいふだんFireworksつかう(Photoshopはもう完全に使い方忘れた。仕事道具だったのに)のだけど、こいつがバッチ処理みたいな機能ある。これつかって楽できんかと思ったけども、せいぜいサブネイル作るくらいのしょっぱい代物で話にならない。いい、画像ライブラリ振り回してなんかできるじゃろ、数学得意じゃないけどトーンカーブもなんとかなるじゃろということで。pltはりさんの画像を読み込んでみる。上のはりさんはスクリーンショットを切り取って小さくしただけのもので、補正やらは一切なし。暗い屋内だわくすんでるわ、ぱっとしない。ほんではどっかから拾ってきたサインカーブ作るやつをplotで描かせてみる。やっべグラフとか描いちゃってかっけえ。理数系ってこういうの鼻歌でやるんじゃろかっけえ。各ピクセルにこいつを食わせると暗い色をより暗く、明るい色をより明るくしてメリハリが付く。ほんとはカーブの具合を上みたいな感じのカーブにいじりたいが、式の書き方がわかんないのでいったんこれで。効率やらノウハウやらわかんないので、愚直に各ピクセルのRGB値を変換していく。後ろの照明がぱっと明るくなってたり、はりさんの顔にあたってる明かりが明るくなってたり。フィルタはちゃんとかかったということで進める。次、コピーライト画像を読み込む。これを読み込んで、画像(今回ははりさんの画像)の、所定の位置にコピーライトを貼り付けたい。困ってるのが、元の画像ったらわりと大きめのマージンがあること。このマージンがだいぶ邪魔なので、ほんとは空白部分をトリムしたい。cropでうまくいくとあったんだが、正確に0でないピクセルがありそうな気配でtrimかかんない。実際やるときはマージン分をいいぐあいに調整して貼り付けちゃおう。はりさん画像とコピーライト画像のサイズを取得して、はりさん画像のどの座標にコピーライト画像を貼り付けたらいいかを調べる。テキトウにpaste_pos関数作っておこう。2つの画像をあげると、どの座標に描いたらいいかを返すやつ。横0縦184ピクセルのとこに貼り付けたらいいとわかった。Image.pasteにコピーライト画像、貼り付け先の座標を渡す。引数のmaskにもコピーライト画像をわたしてるのは、これでアルファチャンネルをよしなにしてくれるとのことで。上のサンプルではコピーライト画像のほうが横幅が大きいけれども、溢れたぶんはなくなる。実際にこの仕掛けを利用するときはもっと大きな画像を使うことになるので、横幅あふれた―とかは実際には発生しないので、気にしないでよい。だいたい実験が完了したので、これをバッチスクリプトとしてまとめたら終わり。いままで画像処理やること少なかったわ、式わたして数値の変換するなんてこともやったことなかったわで、若干進歩。プログラミングのための線形代数買ってあるのに積んでるんだよなーそのうち読もう。いうのに役立つ何かが書いてあるかも。(1)記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。