Lazy
簡単な実装例は次のようになります。
private Lazy<string> lazyValue = new Lazy<string>(() => { Debug.Log("Lazy value is being calculated"); return "Hello, World!"; }); void Start() { Debug.Log("first"); Debug.Log(lazyValue.Value); Debug.Log("second"); Debug.Log(lazyValue.Value); Debug.Log("third"); Debug.Log(lazyValue.Value); } // 出力結果 first Lazy value is being calculated Hello, World! second Hello, World! third Hello, World!
このコードは、lazyValueというLazy
先ほどの例のように、Lazy
特定のComponentを持つGameObjectを視覚的にわかりやすくしたいという要望があり、少しやり方を調べてみました。
UnityエディタのHierarchyウィンドウで表示されるゲームオブジェクトの色を変更するクラスです。 特定のコンポーネントが存在する場合、そのゲームオブジェクトの色を変更します。 例として、Imageコンポーネントが存在する場合には色を変える場合のコードが次になります。
#if UNITY_EDITOR using UnityEditor; using UnityEngine; using UnityEngine.UI; [InitializeOnLoad] public class HierarchyColor { static HierarchyColor() { EditorApplication.hierarchyWindowItemOnGUI += HierarchyWindowItemOnGUI; } private static void HierarchyWindowItemOnGUI(int instanceID, Rect selectionRect) { var gameObject = EditorUtility.InstanceIDToObject(instanceID) as GameObject; if (gameObject != null && gameObject.GetComponent<Image>() != null) { EditorGUI.DrawRect(selectionRect, Color.red); GUI.color = Color.black; EditorGUI.LabelField(selectionRect, gameObject.name,new GUIStyle() { fontStyle = FontStyle.Bold }); GUI.color = Color.white; } } } #endif
エディタがロードされたときに一度だけ呼び出されます docs.unity3d.com
Hierarchyウィンドウで各ゲームオブジェクトが描画されるたびに、特定のイベントが発生します。 このイベントのハンドラは、ゲームオブジェクトのインスタンスIDと描画領域のRectを引数として受け取ります。これらの情報を利用してハンドラ内でゲームオブジェクトの描画方法をカスタマイズすることが可能です。
引数として与えられたインスタンスIDを使用して、そのIDに関連付けられたオブジェクトを取得します。
最近は殆ど本を読まなくなっていて、長期休暇があったときに1冊読むかどうかになっています。 お正月に読んだ本は「世界一流エンジニアの思考法」です。 自分がエンジニアをしていることもあり、発売当初から本屋を見て気になっていました。
筆者が米国のマイクロソフトに働いているということで、自分とはエンジニアとしてのジャンルも環境も違うのですが、 何か参考になればと思い読んでみました。
Kindleで読んで、メモをした部分を中心に書いていきたいと思います。
つまり、誰もが知っている「基礎」が身についていなかった。そして、「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」 ものなのだ。
自分のエンジニアとしての能力は低いと自覚していることもあるので、このあたりの項目には興味持って読むことができました。 内容としてはエンジニア以外にも通じると思うのですが、どんなに凄い人でも基礎の取得は大変ということで、ただ基礎ができていれば、いちいちAIに聞いたりググったりする必要がないのでコードを書く効率は良くなるというものです。
ポイントとしては、自分が新人だろうがベテランだろうが、うまくいってないものは「わかっていない」。基礎的なことがうまくできない段階で、下手に試行錯誤して自分流に考えてアレンジすると、かえってめちゃくちゃになって成功しない。王道を愚直に実行し、ゆっくりと基礎を理解しよう。
自分も基礎できていない部分多分にありそうなので、C#をもう少し見直してみようと思いました。
とくに 既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」というのはベストプラクティス だと思う。
これは私も意識していますが、プロジェクトが大きくなるにつれて、各機能の把握が難しくなります。 実際に操作している人に直接尋ねる方が効率が良い場合が多いでしょう。 大切なのは、こうしたやり取りをしやすくする環境を作ることです。
総じてイケてる技術者の人ほど、知らないことは知らないと素直に明かして気軽に質問する。これはアメリカのカルチャーによるところも大きいと思う。
相手の時間を取ることへの罪悪感や、基本的すぎる質問を恥ずかしく感じるなどの阻害要因をなくすことが求められます。 私自身も、自分の能力が低いと感じられるのを避けたいと思うことがあります。 しかし、プロジェクト全体の進捗と比較して考えれば、これらは些細なことです。プロジェクトの進捗のためならば、質問を恐れずに進むべきだと思います。
アメリカでは納期が近くなっても、「無理して機能を完成させなくていいから、品質の良いものをつくるようにしようよ」とマネージャから言われる。
マネジャーの主な仕事は、モチベーションを高めることだとされています。 スケジュール管理や具体的な作業指示は行わず、エンジニアが効率良く働けるような環境を考え、整える役割を担っています。
私は、スケジュール管理を含む裏方作業をしてくれることを非常にありがたいと感じています。 重要なのは、エンジニアが集中しやすい環境を共に創り上げることだと思っています。
プログラマたちがきちんと理解して実装できるようになれば、次からは開発が速くなる。 だからマネージャとしては急かさないことによって「未来への投資」をしているようにも見える。
スケジュールに関しては決まってはいるが、そこまで重視していないのがマネージャー（プロジェクト）のあり方が違いそう。 近視眼的な見方ではなく、遠い目で物事を見ているのではないかと思いました。
会議の時間なんてたかが知れている。その間に内職したってやれることは限られているし、ほかの人からチャットが来ても、 30 分、１時間後にまとめて対応する時間をとれば十分早いレスポンスじゃないか？ 「マルチタスク」はしないほうが絶対に脳の生産性が高まる。
これは私の反省点の一つですが、自分に直接関係が少ない会議が設定されていることがあります。そうした場合、ただ出席するのではなく、意見を積極的に発言したり、議論に参加することに集中した方が良いと感じました。
「後で人に説明する」ことを意識するだけでも、相当集中力や記憶力が向上する。準備もしなくていいので、これはとても楽だ。
ブログに書くことなど、記憶の定着方法については昔から色々な本に書かれているので、それをちゃんとやろうと言う話。 人に説明するレベルまでの理解は簡単ではないですが。
だが、PullRequestのレビューを減らすには、「読んだ人がどう感じるか？」を意識しながらコードを書く必要があった のだ。
自分もコメントたくさんいただくことが多いのですが、このあたり意識して書こうと思いました。 とりあえず機能として動くだけではなく、命名は正しいか、この変更でデグレの可能性ないかなど。
が、「In my opinion」。日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」 みたいなニュアンスだ。 このノリで話すと、たとえ相手のアイデアと正反対の意見でも、言われたほうが「心にぐさっとこない」感じになる。心が痛まないのだ。
海外で人々が率直に物を言うというイメージは、実際には皆が気を使い合っているということだそうです。 私も時には言いにくさを感じ、どのように伝えれば良いかといった余計な気遣いをすることがありますが、これはおそらく世界共通の状況なのでしょう。 意見を言う側も言われる側も、それをどう受け止めるかが難しいと感じます。
「生産性を上げるためには学習だよ。だから、僕は仕事を定時ぐらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。ずっと仕事していると疲れるし、たとえ同じプログラミングでも、仕事と切り離したものはリラックスしてできるよね」
生産について、効率化など色々言われているが、このあたりの考え方は結構良いのではと思いました。
だから、アメリカではみんな「専門性を高める」という蓄積に価値が置かれ、スピードは思ったより重視されない。 結局は時間をかけて小さな努力を積み重ねるほうが圧倒的に良いものがつくれるのだから。
引用する文章ないのですが、 私は新しい取り組みを始める際、とりあえず様々な方法を試してみることが多いのですが、これは実際には非効率で、優秀なエンジニアは、実際に手を動かす前に、推論を立てて十分な検討を行う時間を費やしているという点を知り、大変参考になりました。
ParticleSystemの色設定なのですが、単純な固定色の設定ではなく、グラデーションが設定されている場合が多いです。
これを動的に変更したい場合のコードは次のようになります。
var mainModule = _starParticle.main;
var gradient = new Gradient
{
// 色設定
colorKeys = new GradientColorKey[]
{
new GradientColorKey(color1, 0.5f),
new GradientColorKey(color2, 1.0f),
},
// アルファ設定
alphaKeys = new GradientAlphaKey[]
{
new GradientAlphaKey(0.2f, 0.25f),
new GradientAlphaKey(0.8f, 0.75f),
}
};
mainModule.startColor = new ParticleSystem.MinMaxGradient(gradient);
色とアルファ値をLocationごとに設定ができます。 長短なコードになりやすいので、余り書きたくないのですが、必要な場合は頑張ります。
お正月開催2日目に京都競馬場へ行ってきました。 京都競馬場へは2023年にリニューアルして３回目です。 お正月開催に関しては、コロナや京都競馬場が工事中もあり2020年以来4年ぶりになりました。
競馬場へ行く回数自体少ないのですが、久しぶりに武豊騎手が勝つところに立ち会うことができました。 今年は運がよいのかも。
先程のレースに続いての連勝。
サインもらえるチャンスがあり、年甲斐もなく色紙持って行きましたが、無理でした。
初来日のルメートル騎手。
今日一番注目していた3歳500万以下、アドマイヤテラ号楽勝でしたので、ここからクラシックに乗ることできるか？
芝レースに関しては、昨日はほぼ前に行った馬同士の決着が多かった気がするのですが、今日は結構指し追い込みが決まってました。
メイン競争のすばるステークス。
武騎手は惜しくも2着。
次に京都競馬場に行けるのはGWかもしれませんが、今年は少し予定も難しい気がするので、行けるときに行きたいですね。
