プラモデル制作 - MODEROID 斑鳩
スーパーロボット大戦30を遊んでいて、かつて第4次スーパーロボット大戦で圧倒的に強かったビルバインを再現したような機体が存在していて興味を覚えた。
それが「斑鳩」だ。
Knight's & Magicという小説の作品に登場する機体らしい。
私はスーパーロボット大戦30を遊んだ後に漫画版で作品の詳細を知ることになった。
中でも主人公の登場する斑鳩はゲーム同様、作中でも圧倒的な強さを誇っており、また、鎧武者と作中背景にある魔導に関連する情報を織り交ぜたデザインが格好良い。
これまではバンダイのプラモデルしか作ったことがなかったのだが（IMSの製品も買ってはいるのだが作れる気がせずに積んだままである…）、バンダイ製品のプラモデルが品薄ということもあってMODEROIDで販売されている斑鳩を制作してみた。
バンダイ製品と比較すると、パーツの先端が尖っていて持つと痛かったり、パーツとパーツが擦れた際に塗装が剥がれる心配があったりと扱いにはある程度注意が必要だった。
また、やはりバンダイ製品との比較なのだが、パーツの色分けがされていない箇所がそこそこあり塗装にかかる労力が大きい。
（これはあくまでもバンダイ製品と比較してという話である）
マスキングが嫌いな私はモチベーションが上がらず少しずつ作業していたため、全てを塗るのに2ヶ月ほどかかってしまった。
塗装は全体的にメタルカラーを利用し、機体の青い部分は下地に青を塗ったあと青／紫の変更塗料を利用した。
これによって見る角度によっては若干紫がかった表情を見せることが出来る。
塗装し終わった後に確認したところ、塗り分けが必要だった箇所がいくつか残っていたのだが、ここまでのマスキングと塗装作業でモチベーションを使い切ってしまったので見なかったことにしてそのままにした。
それにしたって完成品は十分すぎる出来栄えになったと思う。
コードレビューの考え方
以前以下のようなブログを投稿した。 daikichi.hatenadiary.com
今回、すこしばかりコードレビューに関する数値的な文書を読んだのでその内容を元に以前の投稿の答え合わせ的な意味をこめてコードレビューについての考えをいくつか記述することにする。
Code Reviews Do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down https://www.microsoft.com/en-us/research/publication/code-reviews-do-not-find-bugs-how-the-current-code-review-best-practice-slows-us-down/?from=http%3A%2F%2Fresearch.microsoft.com%2Fapps%2Fpubs%2F%3Fid%3D242201
考察に利用出来そうな情報は以下。
- コードレビューにおいて機能的欠陥に関する指摘が行われるのは全体の15%
- コードレビューにおいて長期的な品質に関する指摘が行われるのは全体の50%以上
- ある部分のレビューをする場合、レビュアーの経験がない開発者の有用性のあるレビューは33%、レビュアーの経験が３回以上になると、有用性のあるレビューは67%となる、レビュアーとなることで高速な学習を行える
- レビューの有用性はレビュー規模が大きくなるにつれて下がっていく
レビューの目的を考える
コードレビューに求める効果は以下のようなものがある。
- 実装・設計の共有
- 不具合の発見
- 保守性の確保
このうち、先に上げた情報を参考にすると機能的欠陥に関する指摘は15%となり、不具合の発見にはそれほど効果がないものと考えられる。
一方、保守性の確保については50%以上の指摘が行われており、コードレビューはプロジェクトの長期的な保守性の確保に大きな効果があると考えられる。
実装・設計の共有についてはどうだろうか？
ある部分のレビューをする場合、レビュアーの経験がない開発者の有用性のあるレビューは33%、レビュアーの経験が３回以上になると、有用性のあるレビューは67%となる、レビュアーとなることで高速な学習を行える
ある実装に対して、レビューを複数回行うと有用性のあるレビューを行う量が飛躍していくことが伺える。
コードレビューを行うことはレビュアーが該当箇所の実装・設計情報を学習する効率的な場であると考えられるだろう。
これらの情報をまとめると、コードレビューは保守性を確保し、実装の情報をコードレビュー参加者内で共有するために行うもの、また、不具合の発見にはそれほど高い効果は無いと考えられるだろう。
レビューの規模を保つ
レビューの規模が大きくなるにつれてレビューの有用性が下がっていくのならば、レビューはできる限り小さい単位にまとめなければならない。
以下のようなコードレビューリクエストはレビューを行う前に、分割して再提出することを要求することを検討したほうが良いだろう。
これに関しては機能の正しい分割・境界の理解の共有にも役立つことが考えられる。
コードレビューを通すことでチームとしてのスキルをフラットにすることに効果があるだろう。
このデータを元にした考え方はチームにコードレビューを行う文化が無い場合に、なぜコードレビューをするのか？というのを説得する材料として利用できそうだ。
すでに文化があるチームに関してはレビューの方法を検討する材料にもなるだろう。
プラモデル制作 - HG サイバスター
最近作成したガンプラはガンスタのほうにアップロードしているが、今回制作したサイバスターはガンダムではないためこちらのブログに記録を残すことにする。
ここしばらいく、ガンプラの入手は非常に困難だがこちらのキットは同じバンダイの製品でも比較的容易に入手出来る、勿論作りやすさや出来栄えはHGシリーズでラインナップされているだけあってガンプラにひけを取るものではない。
今回はメタル塗装で仕上げてみた。
シルバーの装甲は、ファレホのアルミニウム→シフターズのエレクトリックブルー／インテンスバイオレットで塗装した。
シフターズは偏光カラーなので、見る角度によって色が変わるのだがこれが丁度良い陰影を作ってくれるおかげでキットの立体感をいい感じに演出してくれる。
メタリックカラーに墨入れで影を作るのは少し浮いた印象を持っていたのだが、この陰影効果のおかげで墨入れを行わない決断が出来たのは良かった。
フレーム部分はパープル＋シルバーの混色で装甲箇所ほどではないがメタリック感を演出している。
作業中、塗料の乾燥を待たずにどんどん上塗りをしていったせいか塗膜が非常にもろくあまり動かしてポーズを取らせることが出来なくなってしまったのは反省点だ。
動かせないのだから当然サイバードへの変形は断念した。
サイバードで飾りたいならキットをもう一つ購入するべきなのだろう。
キットの表面に曲線が多く、メタルカラーをいい感じに反射してくれるので大変綺麗な出来栄えで仕上がったと思っている。
塗膜を弱くしてしまったことを除けば大変満足する出来で作成出来た、次につながるようにしたい。
2021年に作ったガンプラ
記憶が朧なのだが、確か誕生日プレゼントに貰って作ったはず。
以前RGのフリーダムを制作したことがあり、最近のガンプラはここまで進化したのか！と感動したのを熱心に語っていたら相方を頂けたということだ。
出来はとても良かったと思うが一部接着剤などが必要だったり（説明書では接着剤は必要ないのだが、無いとどうしても外れやすい部分があった）部分塗装が必要だったり作りやすいキットではなかったと記憶している。
子供の頃、兄がGジェネレーションで遊んでいるのを眺めていたがその中で衝撃を受けたMSがこれ。
大人になって分かったことだた「エアーズの攻防」というシーンのCGだったようで音楽、機体、MSどれも最高に格好よく胸が踊ったことを覚えている。
やはり大人になってからなのだが、キット化されない事情などがあることも知り、生きている間にキット化されればいいなと思いながら生きていたら思いの外早くキット化されてくれて大変喜んだ（おそらく今年スワローズが日本一になった次に嬉しかったことだ）。
キットの出来栄えも申し分なく、今となっては何故もう一つ注文しておかなかったと後悔している。
次に再販されるのを心待ちにしておこう。
Mk-Ⅴを制作してすっかりガンプラにハマってしまった。
追い打ちをかけるように登場したのがこのエントリーグレードのガンダムで、作りやすく、色分け、可動域も申し分なし、さらに低価格とガンプラの沼に完全に引き込まれてしまった原因はこの商品だろう。
気がついたら、ガンダムの各種カラー（プロトタイプ、ノーマル、G3）を作り上げており、また、オリジナルカラーで塗装したものを作ったりととにかく同じキットを作り続けていた。
鉄血のオルフェンズシリーズが放映されていた際、個人的なガンプラブームが訪れていたのだが、これはその際に投げ売りされていたのを購入して放置していたものだ。
先に書いたようにMk-Ⅴの制作をしてガンプラ制作の意欲を取り戻した際に押入れにしまってあったのを引っ張り出して作成したものだ。
キットの出来は想像以上に良く、2021年の棚にはつねにこのキットを飾っていた。
1年も経過すると関節部分が緩くなっており2022年は棚から引退させないとならないだろう、少し寂しくもある…
模型店を覗くとガンプラの品薄が目立つようになってきている時期だったが、これを制作しているときはまだ欲しいキットはなんとか購入出来ていた時期だ。
Ex-8は比較的購入するのが楽なキットであり、また、08小隊のキットは是非作ってみたいと以前から考えており、その機会が訪れたというわけだ。
部分塗装やウェザリングを試してみたがお手軽製作にしてはなかなかよく出来たのではないかと思う。
2021年、年末に改めて眺めてみたが全塗装したものと比べるともっと出来たのではないかという思いが強く湧いてくる….
再度キットを入手する機会が訪れるなら今度は全塗装やジオラマにもチャレンジしてみたいキットだった。
daikichi.hatenadiary.com daikichi.hatenadiary.com gumpla.jp
ビルドダイバーズRe:RIZEのキットの楽しさに目覚めていくつかのコアガンダムキットを制作した。
中でも可変型の機体をミキシングで作れたのは個人的には良い制作だったと思う。
改めて2021年年末に眺めてみるとまだまだ出来ただろうという思いがつよく、2022年に機会があるならもう少しより良くした改造したプラモデルを制作できると良いと思う。
鉄血のオルフェンズ放映時には1/100フルメカニクスのほうを制作していたが、店舗に飾られている1/144のキットもキレイな仕上がりになっておりいつかは作ってみたいと考えていた。
今回キットを入手することが出来たので制作してみたのだが、1/100のようにギミックをのせようとするとキットに少しばかり手を入れる必要がありその練習台となったのがこのキットだ。
完成時はよく出来たと思っていたが、やはり、改めて見てみるともっとよく出来ただろうという思いが強い。
HGAC 1/144 ウイングガンダムゼロ｜バンダイ ホビーサイト
塗装時はガンダムマーカーをメインに行っていたが、このキットからは塗料を新しくファレホに変えている。
このキットはファレホをどう使うかの練習台となったのだが失敗をとにかく塗り重ねたものとなってしまった…
キット自体は格好良いのだが、塗料を変える踏み台としてしまったことで完成の出来映えは不満の残るものとなってしまった。
ウイングガンダムゼロの失敗を生かして作成したのがこのハイゴックだ。
このキットの完成の出来映えは大変気に入っている、先の失敗が生きており大変良い結果になってくれた。
一番くじで運良く残り8回でラスト・ワンが手に入る状況に遭遇して入手出来た。
色々と改善点はあるものの、電飾してみたり飾る分には全く問題ない出来栄えで制作出来たと思う。
パールホワイトの塗料のテストのために購入して制作してみた。
テストとしてはイマイチだったものの、完成したものはなかなか気に入っている。
そもそも、キットの出来が良くガンダムAGEはこれを制作したことをきっかけに初めて視聴することになったほどだ。
こうして書いてみるとかなりの数のキットを制作した年となったようだ。
最近、ガンプラの入手が非常に困難になっており作る予定もないのに作りたいキットを購入しては押入れに積むという行為をやりがちになってしまっていた。
その甲斐あってか2022年、一年分制作に費やせる分は積むことが出来たと思うので2022年はこれらのキットを崩しながら、また、制作は細部までこだわれるように仕上げていければと思う。
来年には映画やら、新作のガンダムアニメやらとキットを購入したくなる衝動に駆られることは間違いないので積みがこれ以上増えないように心がけたいものだ。
ファレホをエアブラシで利用する際のメモ
希釈液
シンナー：プルーバー → ３：２
プライマー
希釈液：プライマー → １：１ ←エア圧の関係か薄まりすぎて垂れてしまう
希釈液：プライマー → １：２
モデルエアー
希釈液：モデルエアー → １：２
バーニッシュ
シンナー：バーニッシュ → １：１
Rustの宣言的マクロ
Rustのコードを書いていて、マクロが頻出するものの理解が不足しており少しばかり気味悪さを覚えていた。
内容を調べる気力が湧いたため、少しばかりRustのマクロについて調べることにする。
本稿はRustのマクロの種類のうち宣言的マクロについての内容を調べたことのメモ書きである。
さて、Rustには宣言的マクロと手続き的マクロという大きく２つの分類のマクロが存在している。
宣言的マクロはprintln!やvec!などといった、suffixに!のつくものがそれである。
宣言的マクロを使うメリット
このマクロを利用することのメリットは関数では扱えない可変長引数を扱うことが可能ということ。
以下でprintln!マクロを例に見てみる。
// 引数１つでも呼び出せる println!("hello"); // 引数２つでも呼び出せる let greet = "hello"; println!("{} world", greet);
Rustの関数ではこのような可変長引数を扱うことが出来ないため、可変長の引数をとって何かをするような処理を行いたい場合に宣言的マクロを定義するメリットがある。
宣言的マクロの定義方法
宣言的マクロを定義するにはmacro_rules!というキーワードを利用する。
以下に、与えた引数に対してprintln!マクロを実行するマクロを記す。
macro_rules! multi_println { ( $( $x:expr ), * ) => { $( println!($x); )* } }
これを呼び出すと以下のように出力される。
multi_println!("a", "b", "c"); // a // b // c
これはどのようにして、動作しているのだろうか？
宣言的マクロでは与えられたパラメタをmatch式のようなパターンマッチで評価し、評価されたブロック内のコードに置き換えるという動きをする。
詳しいmatchパターンはまだドキュメントを流し見しただけであり、理解が追いついていないのだが、先に記したコードでは、
( $($x:expr), * )がmatchパターンになり、
$xにはmatchした値が入り、exprはmatchする種別、*は正規表現のように先のmatchパターンに0個以上matchすること、という意味となる。
matchした後のブロック内のコードは実際に展開されるコードであり、$( ... )はマッチした回数呼び出される処理となる。
先に記したコードmulti_println!("a", "b", "c");は以下の実装と同等である。
println!("a"); println!("b"); println!("c");
宣言的マクロは先に記したコードのように定義するだけでは、定義したスコープ内でしか利用することが出来ない。
スコープ外でも利用可能にするには#[macro_export]という注釈をマクロ定義の前に付ける必要がある。
// #[macro_export]を付けておけば、そのクレートの利用を宣言することでマクロも利用可能になる。 #[macro_export] macro_rules! sample { ... }
宣言的マクロはいつ定義すればよいのか？
ドキュメントによれば、この宣言的マクロの定義方法はアップデートによってduplicateになるとされている。
macro_rules!には、いくつかの奇妙なコーナーケースがあります。 将来、Rustには別種の宣言的マクロが登場する予定です。これは、同じように働くけれども、それらのコーナーケースのうちいくらかを修正します。 そのアップデート以降、macro_rules!は事実上非推奨 (deprecated) となる予定です。
マクロ - The Rust Programming Language 日本語版 - https://doc.rust-jp.rs/book-ja/ch19-06-macros.html
ということで、新たに定義するというよりは既存実装を読む上での理解の助けにするぐらいに理解しておけばよく、自前で何か定義するということはあまり考えなくても良いのだろう。
ということで、宣言的マクロについてざっくりと理解を深めることが出来た。 また余裕が出た機会には手続き的マクロについても理解を深めることができればと思う。
