ガンプラ制作 - ガンダムアスタロトオリジン
数年前にセール品で購入したまま眠らせておいたものを作成した。
最近ガンダムマーカーをエアブラシとして利用出来るノズルを購入したため、エアブラシによる塗装を試みた。
掃除をしないで済むエアブラシは掃除に利用する有機溶剤が苦手な人間にとっては大変ありがたい。
今回は以下のように作成してみた。
エアブラシによる塗装は筆で塗るのと違い、塗料が均等に吹き付けられるので仕上がりが格段に良い、今後の制作でも大いに活躍してくれそうだ。
今回は更にリアルタッチマーカーを利用してウェザリングにも挑戦してみた。
出来栄えはまだまだ改善の余地はあるものの、スミ入れにかける作業が不要になり制作時間に大きく貢献したことは大変良い体験だった。
もう少しリアルな表現もしてみたいため、スポンジによるチッピングやタミヤのウェザリングマスターの利用も次回は検討してみたい。
鉄血のオルフェンズのキットはフレームに装甲をのせる作りになっているせいか、可動域が非常に広く様々なポーズを楽しめるのが良い。
正直、いつ作ろうか悩んでいたキットだがいざ作成してみるとなかなか格好良い出来になったため大変満足している。
抜刀アクションが再現出来る
ショットガンを構えたポーズ、広範囲の可動域のおかげで膝立ちも簡単
スラスターを展開
コードレビューガイドライン
考えていたのだが、いまいち信憑性が低い話ばかりでどうしたものかと悩んでいる。 このブログは匿名性ではないので怪文書ではないのだが、怪文書に近い出来だ。 もっと納得出来る理由を添えたいのだが、さあ、どうしようか…
コードレビューの基本的方針
コードレビューの目的は下記の通り。
- 設計や実装をレビュワーと共有すること
- バグの温床を見つけること
コードを綺麗にすることではないので注意が必要です。
綺麗の捉え方は主観なので、時として不毛なコミュニケーションに発展します… 「コードが綺麗！」という価値観はコードレビュー時は捨てましょう。 （褒めるための「コードが綺麗！」はどんどん言いましょう、言っているとどういうコードが綺麗なのかという認識が周囲に認知され始めます）
コードレビューでやらないこと
- Linterが指摘出来るような指摘
- 機械が出来ることを人間がやるのは時間の無駄です、Linterがなければすぐに導入しましょう。
- ショートハンドコーディングを勧める
- 些細なパフォーマンスの話
- 結果に特に影響を与えない些細なパフォーマンスの話は無駄です（結果が同じなので）。
- コストが
O(n)になる実装などで、実装当初は0<n<10とかだったけれど未来はどうなるの？という話はしっかりしましょう、これは些細なパフォーマンスの話ではありません。
コードレビューを円滑に進めるためにやっておきたいこと
コミュニケーションが同期的であると、当事者間の共有は万全ですがコミュニケーションに参加しない人に対する共有が不完全になりがちです。 非同期コミュニケーションであるドキュメントを書くことを強く推奨します。 （同期コミュニケーションは常に１：Nの関係（数字は人数）になりますが、ドキュメントによる非同期コミュニケーションは０：Nで説明が成立するケースがありコスト的なメリットがあります。）
設計の共有
機能の規模によっては設計の共有はレビュー前には不可欠です。 これを共有することで、コードが設計とリンクするのでレビューの負担が大きく減少します。
設計の共有方法は機能の大きさによって異なります。
そもそもプロジェクトに設計方針が無いのだけど！？
過去の遺産を引き継ぐ場合、よくあります。 以下の行動を取りましょう。
- 前任者がいるならとにかくしつこく聞く
- 読み取れる範囲で設計方針をドキュメントにする
- 改善したほうが良さそうな方針があれば改善した方針でドキュメントにする
プロジェクトに対する人のアサインが流動することを前提とすると、基本方針の説明をドキュメントに任せられることは大きなコスト削減となります。 （そして基本方針は時間に対してそこまで大きく変更されることがありません。） 可能な限りやっておきましょう。
大きな機能
- レビュー依頼画面に書く情報としては大きくなりすぎるので、専用のドキュメントツールを利用します。
- 実装に入る前にDraftとして設計情報のレビューを行うのが良いです。
- UMLやワイヤフレームをドキュメントに添えて情報を伝えやすくします。
中ぐらいの機能／修正
- 実装する機能は専用のドキュメントツールに記載された機能の一部なら、それへのリンクを記します。
- 修正である場合、専用のドキュメントツールに記載された機能の一部ならドキュメントを修正します。
- 何故その変更や追加が必要だったのかを記載します。
小さい機能／修正
- 何故その変更や追加が必要だったのかを記載します。
2020年に飲んだ日本酒
２０２０年は引っ越しをしたために周辺環境が変わった。
生活圏内に色々な酒を扱っている店舗（主にワインと日本酒）があったため、様々な種類の日本酒を飲むことが出来た。
２０２０年に出会った日本酒について、感想などを忘れぬよう雑記を残すことにする。
花浴陽 純米大吟醸無濾過原酒山 山田錦
２０２０年に飲んだ酒ではダントツに美味しい。
香り良し、口に含んだときの味がほぼジュース、喉越しで日本酒らしさが顔を出す。
何でも埼玉県で一番美味しい酒なんだとか…
通販サイトなどを見るとプレミアム価格がつくことがあるようだが、運良く定価で購入することが出来た。
おそらくもう一度飲む機会はないのではないだろうかと思う。
頻繁に手に入ってしまうとあまりにも美味しいので、酒浸りになりそうだし入手難度は高くて丁度良いのかもしれない。
大雪渓 純米吟醸
無性にわさびが食べたくなり、わさびのお供に購入した。
口に含んだときの味が安酒か？と警戒させるのだがそれは大きな間違いであることが分かる。
口に含んだ後口の中で転がしても、喉越しの時も特別な主張を一切しない不思議な味であり安酒のような不快感は一切ない。
この主張のなさからスイスイ飲むことが出来る面白い酒だった。
肝心のわさびとの相性は正直良くわからないが、また飲んでみたいと思える一品だ。
冬まで待てない冬の月
ラベルのうさぎとお酒の名前が面白く購入した一品。
白桃酵母を利用しているらしく、味に桃の皮特有の苦味があるように感じた。
家族にはこの苦味が苦手で敬遠されてしまったが、個人的には幼少時から桃を食べ慣れていた影響もあるのかこの苦味に好感を持つことが出来た。
冬の月
上記で書いた「冬まで待てない冬の月」が気に入ったため、予約購入した一品。
非常に美味しかった記憶があるものの購入時期、仕事が多忙だったこともありじっくり飲むことが出来なかった。
２０２１年も再度購入したい。
飛良泉 純米大吟醸 限定生酒
どうも限定という言葉に弱く、瓶に限定などと書いてあろうものならその商品を手にとってしまう。
この飛良泉という酒も購入はそのような動機だ。
香りがよく、飲み口はスッと入る。
口の中で転がすと日本酒らしさが顔を出し始め、喉を越すころにはしっかりとした日本酒らしさで通り過ぎる。
難しく書くと良さが伝わらないだろうから簡単に書くが、美味しい酒だった。
Sasanami 春
花見がしたく、ラベルのオシャレさも手伝い購入した一品。
味は忘れましたが「爽やかだなー」という感想をもった記憶がある。
素敵 Japan
購入難度が低く、それでいて圧倒的に美味しい！２０２０年で何度もリピート購入した。
ぶどうを思わせる香り、ワインのような飲み口、強すぎない日本酒さ、とにかく飲みやすく、飲みやすいだけでなく味もしっかり美味しいお酒。
開栓からしばらく時間をおくとフルーツのような味わい・香りは姿を消すが、今度は味が丸くなるというのだろうか？そう表現する他ないのだが、そのような味に姿を変え、これがまた飲みやすい。
トータルのバランスで考えるとこの酒は２０２０年に出会った酒の中でもNo1だろう。
SwiftPackageManagerを使うための覚書
以前SwiftPackageManagerを利用してライブラリを作成したことがあったが、使い方をすっかり忘れてしまったため覚書として使い方のメモを残しておくことにする。
プロジェクトディレクトリの作成
SwiftPackageMamagerにはプロジェクトディレクトリを作成してくれる機能は無いため自前でプロジェクトディレクトリを作成しておく必要がある。
ディレクトリを作成したら、そのディレクトリに移動してSwiftPackageManagerの初期化を行っていくことになる。
mkdir /path/to/Project cd /path/to/Project
初期化
swift package init --type [empty|library|executable|system-module]というコマンドを実行することでプロジェクトのスケルトンを生成することができる。
--typeに指定したオプションによって生成されるスケルトンが異なってくる。
生成内容はそれぞれ下記の通り。
| オプション | 生成物 |
|---|---|
| empty | 空のプロジェクトスケルトンが生成される、用途的に使うことはほぼ無いのではないか？ |
| library | 他のSwiftプロジェクトから利用可能なライブラリを生成するためのスケルトンが生成される。 |
| executable | 実行可能なコマンドのためのスケルトンが生成される。 |
| system-module | システムモジュールを生成するためのスケルトンが生成される。 |
SwiftPackageManagerでビルドを行うには特定のプロジェクト内構造を持つ必要がある。
この構造を自分で考えるコストが必要になるemptyオプションは基本的に利用するケースが無いように思われる。
Xcodeプロジェクトの生成
swift package initでプロジェクトの初期化を行うと開発が行えるようになる。
通常、Swiftの開発にはXcodeを利用するため*1Xcodeのプロジェクトファイルを生成する必要がある。
Xcodeプロジェクトの生成は下記のコマンドを実行すれば良い。
swift package generate-xcodeproj
コマンドを実行すると、[ProjectDirName].xcodeprojという設定が生成されるので、これをXcodeから開けばXcodeを利用して開発を行うことができる。
以前使ったときはテストコマンドやビルドコマンドもあったような記憶があるのだが、どうも無くなってしまっているようだ*2
ブログに書いたことで次に利用する時はすんなり使えるようになっているとよい。
オクトパストラベラー感想
ちょっと前に話題になっていたオクトパストラベラーというゲームをクリアした。
以下感想です。
シナリオ
- 各キャラクター４章構成だが、４章の間にキャラクターの心情が変化していく様を描くのには無理があるキャラクターがちらほら（特にテリオン）
- ゲーム上仕方がないのかもしれないがただの商人の娘であるトレサが強い謎
- サイラス編がキャラクターの天然ぶりと相反してシナリオが怖い（４章を夜に暗い部屋でやると特に怖い）
- ハンイット編はシナリオ的にはわりとよく出来ている、隠しボスへの布石みたいなものもあって気が付く人にとってはいいシナリオだと思う
戦闘
- ブースト、ステータスアップ・ダウンを駆使して戦うことを覚えるとボス戦が楽になる
- 上記を除くとごくごく普通のRPGな戦闘スタイル
フィールド
- グラフィックが綺麗なのだが画面の輝度や周囲の明るさによってフィールドが見にくくなることがあった
- ダンジョンの作りが単調なので、RPGとは入り組んだダンジョン！という人には物足りないかも（私は難しく考える必要がなかったので特に気にならなかった）
- 宝箱に入っているものが多くの場合重要ではないので後半は宝箱を見つけてもスルーするようになっていた
フィールドコマンド
- 盗むや買い取るはゲームが難しい人用の救済手段みたいなもののように感じた
- 巷で噂されるほど感心はしなかったものの、新しい街に移動したあと盗むコマンドでレア装備を見つけるのが一つの楽しみになったのは間違いない
- プリムロゼの誘惑で男性NPCキャラが「げへへ」という言葉を発するあたりに人間の業を感じずにはいられない
隠しボス
- 最後の最後で８人全員必要とか辞めて！
感想はこんなところ。
正統派RPGを名乗るには*1ダンジョンの構造が少し残念だったように思うが、それを除けばなかなか良い出来のRPGだと思う。
気がついたら総プレイ時間が70時間程度になっていたので私としては楽しめたゲームだった。
*1:ソースは？
読書感想 - 異文化理解力
異文化理解力という本を読んだ。
グローバルな人を相手にして働くビジネスパーソンが各国の文化的背景等から生まれるコミュニケーションの差異を明らかにし、どのように対処していくかという内容の本だ。
なお、「日本人の性質とプログラマー文化」と題しているがこのエントリはただの読書感想文であり、壮大な考察が述べられるものではない。
さて、ITエンジニアとして仕事をしていると他の職種と比べてITエンジニア特有の文化のようなものが形成されていおり、また、この文化が日本人の性質とされているものから外れている節があるように感じる。
例えば、無駄なミーティングを好まないだとか、情報をオープンにするだとか、ひどいコードを目の前にしたときに「なんだ、このクソコードは！」など堂々と暴言を吐く、などなど…
これらは仕事を効率よく進めることい対して非常に有用だが日本人の性質と照らし合わせると、ズレが生じておりITエンジニアの精神的な観点をすり減らしてしまうという問題はなかろうか？
特に、ITエンジニアはプログラムのソースコードを指して暴言を吐きがちだが、このオープンなフィードバックは明らかにITエンジニア諸氏の精神をすり減らしている場面をよくよく目にする。
これは一例に過ぎないが、私達はもう少し、ITエンジニアとしてではなく、日本人という文化に所属する人間を相手にして仕事をしているということに意識を向けたほうが良いのかもしれないと考えさせられた。
実はITエンジニアに留まらずIT企業というのが特殊な文化を構築しており、このあたりがまた従業員のモチベーションに関するミスマッチを起こしているというケースも目にすることがある。
エンジニアリングにせよ、IT企業にせよまだまだ若い産業であるので、これまでの文化とは異なる形態をとるのはおかしな話ではないが、その文化の所属する前に私達の考え方は自分の国の文化的背景がベースとして存在している。
これらを上手く迎合できるような振る舞いというのを考えていければと思った。
退職しました
これはITエンジニアの界隈で非常に流行している退職エントリというものだ。
ITエンジニアの界隈では人材の流動性が高いらしく*1、また、自身の情報を発信することが人材的価値の向上に繋がるケースモデルが一定数観測されることから、このような退職エントリが上がることは珍しいことではない。
私はITエンジニアとして業界に身をおいているのだが、この流行というものに倣って退職エントリというものを書いてみるに至った次第だ。*2
さて、先日8月末日をもって約3年と半年ほど所属した会社を退職した。
会社への不満、未来への成長の展望、これまでの感謝等、感情としては諸々が混じり合っているためどれがどうっだったという明確な理由を上げてもそれは違うことのように思われる。
故に、退職理由は簡単に書き記せるような明確なものではなく、様々な要素が重なった中である日「退職しよう」という判断が自分の中で下されたのだ。
いざ書いてみたが書きたいことが殆どないことに若干の寂しさを憶える。
なお、次に所属する会社はすでに決まっているためこのエントリに転職活動を示唆するものは含まれていない。
