DMM.makeで自作3Dモデルをフィギュア化した
Blenderで初めて3Dモデルを作ってみてふと思った。
これは3Dプリントってやつをすればフィギュアとして手に取れるのでは・・・？
ということで、DMM.makeの3Dプリンターサービスを使ってみた
このサービスは3Dデータをアップロードして、どの素材で作りたいかを選んで注文するだけでOK。しばらくすると3Dプリントされたものが届く。
アップロードした時点でまず自動データチェックが行われ、OKだった場合は素材選びに移れる。この時点でもう素材ごとにお値段がいくらになるかが決まる。
素材を選んだら注文をするのだが、注文した後もデータのチェックが行われ、その素材で本当に造形できるのかチェックされる。ここでダメだと注文がキャンセルされる。
自分の場合、厚さが薄すぎる箇所が複数個所あり、何度も注文キャンセルされてしまった。勝手がわからず、直したつもりでも直ってなくてを繰り返してプチパニック。
きっとDMMの担当者に愛想をつかされたことだろう。その節はすみませんでした。
紆余曲折ありながらも、完成品はこちら。素材はフルカラープラスチック。（実はコレの前にゴムライクで試しに出力してはいるが、そっちはかぼちゃ氏の下絵を描いてくれたむつばさんにプレゼントした）
控えめに言って最高。
自分の作ったものが物理的に形になる感動。
レガシー企業を変えようとしている
タイトルは大げさになってしまったが、ようは特定の案件にアサインしないから、がんばって社内改善してちょ と言われているわけだ。
テストコードという概念も無ければバグ管理もコードレビューも無く、SVNへのコミットはなるべくまとめて最後に一括でドン！
ソースの修正はかならずコメントアウトして直接は書き換えず、修正履歴コメントを残す必要があったりとか、そういうよくあるレガシー企業。
主に使うJavaフレームワークはStruts2。JDKは6。世間ではフロントをSPAにして、サーバー側はRest APIで構築みたいなことが当たり前のように行われている中、弊社ではそういったワードを知っている人すらいない。
まだRestで消耗しているの？どころの話ではない。サーバーとはHTMLを返すものなのだ。JavaScriptはブラウザでアラートダイアログを出すための言語なのだ。
単体テストというのはエクセルにこのボタンを押したらDBのどのテーブルにコレが登録されるとか、この値がセッションに保存されるとか言うのを書いて、Eclipseのデバッガで処理を止めて変数の値を表示してスクショを撮ることなのだ。
とまあ現状はそんな感じである。つらい。
もう何から手を付けていいのやらわからない状態ではあるが、とりあえずテストコードを書くようにするのがいいんじゃないか？と思い、デモ環境の構築にとりかかった。
社内の空きPC（去年まで自分が使っていたWindows 32bit メモリ4G）をCentOSに入れ替え、私物の16GBメモリを搭載しサーバーとして利用。Dockerで JenkinsやらGitBucketを導入してみた。
Struts2,Spring,MyBatisという、社内でよく使われている構成の適当なプロジェクトをサンプルとして、テストコードのデモを作成。まあ1000行くらいある適当なメソッドをクラスに切り出してこれまた適当にテストを書いてみただけだが・・・
それをGitBucketにあげてJenkinsと連携。GitBucketにPushしたらJenkinsでテストが走ってカバレッジも取得されて結果をSlackに通知するというだけのシンプルなものだ。
とりあえず、テストってこういう感じのものだよ〜というのは見せられる準備はできたのだが、これをどうやって社内に展開していけばいいのだろうか。やっぱりどこか実際のプロジェクトで導入実績を作らないと広まらないよなぁ。手頃な小規模プロジェクトがあればいいのだけれど・・・
そして弊社ではWindows FormsとVBの組み合わせの案件が未だに多いみたい（自分はやったことない）なので、その環境でテストを書いていくには？というところに今は取り掛かっている。
いやもうWindows FormsもVBも勘弁してくれという話なのだが、それしかできない人が多いから仕方がないようだ。つらい。
ちょっと調べたところ、Windows Formsでいい感じの開発をするためには、もはや自分でフレームワーク作るみたいなイキオイになりそう？WPFであればPrismという定番フレームワークがあるみたいだけど、Windows Formsにはないのかな？
ああもう進めて行き方がわからない。いっそ転職してしまいたいが、こんなレガシー開発しか経験のない26歳をどこが雇ってくれるというのか。もう第二新卒ですらないのだぞ。
やはり趣味で何か実績をひっさげるべきなのだろう。しかし趣味ではゲーム作っていたいからなあ。今年は技術書展でGodot本も出したいしな。むむむむ・・・
つらみ。
勉強会 Unity ライブゲーム制作 〜ブラックジャック編〜に行ってきた
先日行われたコレに行ってきた。
講師の方はDMM Gamesの人らしい。アイギスやってます！って言えばよかった。
自分はUnityではなくGodot使いなので、今回はさながら敵情視察！
使うツールがなんであれ、他人がゲームを作る様子が見られる（しかもプロ）のは貴重なので、勢いで参加！
内容としては、講師が90分使ってブラックジャック（トランプのアレ）を制作する様子を見守るというもの。
講師が所々解説したり独り言を言ったりしながら、ブラックジャックの最低限の実装を終える様子を見てきた。
他の参加者の中には、ゲーム業界を目指す学生が二人いた。がんばれ〜応援してます〜。
そして感想ですが、いや〜これが中々に面白かった。
プロはとにかく速い！なにかにつけてイチイチ速い！すごいな〜。
あと処理効率を結構気にしてたな。別にそんなとこまで気にしなくてよくない？って自分なら思ってしまうような細かい部分でも、内部的にはこうなってるから、ここはこうした方がパフォーマンスが良くなるというのを解説してた。そういうところもプロっぽいなーと思った。
ゲームの作り方としては、普段自分がゲームジャムでやっているやり方と、そう違いはなかった。コレにはちょっと安心した。
また次の機会があれば、ライブゲーム制作参加したいなー。
あと、もうちょっと規模の大きいゲームの作り方を見たいな。もうちょっと設計をしっかりする感じの。
なにもかもがレガシーな開発現場は何から変えていけばいいのだろう
社内でちょっと特殊なポジションに就いた。かんたんに言うと、レガシーな現場をカイゼンしていくチーム。特定の案件にはアサインされない。
チームと言っても自分と直属の上司の二人だけだ。で、実質自由に動けるのは自分だけ。なんかカイゼンジャーニーの主人公になった気分だ。
これまで散々社内で文句は言ってきた。しかしいざカイゼンを始めるとなると、一体何から手を付ければいいのだろうか。
一切テストコードを書かない文化を改める？
CI環境も作ってテスタビリティの高いコードはこう書くんですよ〜みたいなのを広める？
タスク管理はExcelでテキトーにやってるのを、Redmineか何かでチケット管理するようにする？
ソースをSVNで最後の最後に1回のコミットで済ませていたのを、きちんとブランチ戦略を考えてコードレビューも挟んだりとかする？（Gitに移行する？）
アジャイル状態を目指してスクラム開発をやってみる？
細かいところでは、ファイル名（クラス名）を、A0001.javaみたいな記号と連番にしてるのをやめる？
ソースを修正するときは必ずコメントアウトして修正履歴を残すようにしてるのをやめる？
基本設計書や詳細設計書も粒度がバラバラだし意図が全然わからないけど中途半端に日本語混じりのSQLが書いてたりしててよくわからないことになってるけど、これを標準化？する？
いったい何から手を付ければいいんだ。
とりあえず、業務システム開発モダナイゼーションガイドとカイゼン・ジャーニーをもう一度読もう・・・
それと外部のコンサル頼んだりしたほうがいいのかしら。
あーわからんーーーーーーーー
【Godot】move_and_slideで動かしているKinematicBody2Dの向きを反転させようとscaleを直接操作したらバグった
はい。長くてわかりづらいタイトルになってしまった気がする。
Godotでゲームを作っていると、キャラクターのスプライトやらなんやらを反転させたいことがよくある。
矢印キーの右を押せば右に向いて、左を押せば左を向くみたいな。
こういうとき、反転させたいノードのscaleにマイナスを掛けると反転させることができる。
scaleが(1,1)だとしたら(-1,1)にすると左右反転、(1,-1)にすると上下反転するというテクニック。
しかし表題にあるとおり、move_and_slideで動かしてるオブジェクトのscaleをいじったところ、反転したりしなかったりと不可解な動きになってしまった。
詳しいことはよくわからないが、オブジェクトを物理演算で動かしているときはscaleを直接いじるんじゃないということみたいだ。これはRigidBodyも同様だろうねきっと。
ということで、スプライトを反転させたいときはKinematicBody2Dではなく、スプライトのscaleをいじればいい。
反転させたい対象がいくつもある場合は、Positon2Dとかにまとめてぶら下げてしまい、Position2DのscaleをいじればOK。
ちなみに似たような問題として、RigidBody2Dのpositionを直接書き換えるようなことをすると、これまた不可解な動きをしてしまう。 物理エンジンが計算しているところを邪魔するなってことですね。
この場合、_integrate_forces()を使うことで上手く制御することができる。↓のような感じ。
func _integrate_forces(state):
var xform = state.get_transform()
xform.origin = hoge # ここで位置を好きに書き換える
state.set_transform(xform)
なんかとっ散らかった文章になったが、書かないよりはマシだろう。以上。
