ちゃっかりサイトを HTTPS 化してたり、記事の一番下に GitHub の当該ファイルに飛べるリンクを追加したりと、どうでもいい手入れを細々としてましたが、本題のほうは書けるようなネタも無いかな…という感じで程よく放置してました…が、特に死んでたというわけではなく、ぼちぼちとコードを書いたり書かなかったりしてました。
]]>成果が積み重なるのは喜ばしいことですが、同時に複雑さも折り重なり、問題も山積、問題に気付けないことにも同時に気付く、そういう未来も同じくらい存在します。長期的に育ってゆくコードベースの健康を維持したり、問題の芽を摘むための方策のひとつとして、静的解析が挙げられます。
.NET 環境向けにも様々なツールが存在するわけですが、今回、その中のひとつである NDepend のライセンスを開発元より頂戴しまして、実際に使ってみる機会を得ました。(ありがとうございます!)
日頃この手の解析ツールをしっかりと使ってきた方ではないのですが、せっかくの機会ですし、自分なりに遊んでみて、長短織り交ぜてレビューしてみようと思います。
]]>本稿の投稿日時が実際のものと盛大に食い違っているわけですが、既にスライド中に URI が仮置きされていて、今更変えるのも…というのが要因です。すっかり遅くなってしまいましたが、まあ、書かないよりは…という奴です。
]]>Rx においては時間軸と実行処理の抽象化のためにスケジューラと呼ばれる概念が用意されており、これを選択したり、あるいは独自に実装することで Rx の処理に介入することができます。つまり、これを実装すればオペレータの挙動が綺麗に出力できるかも?…と思ったら、既にそういう用途に使えそうなものがありました。
]]>2014 年 8 月に入社して以来 Unity と格闘する日々を送りつつ、社内での自動ビルドおよび実機配布システムの構築・管理なども行い、おおよそ 1 年半の間、多くの学びを得ることができました。
一方で、今までの歩みも踏まえつつ、より自分の力を活かし、また、今後様々な経験を積む機会について熟慮した結果、今回の決断に至りました。
4 月 1 日より株式会社ライフベアのエンジニアとして働いております。
メイン フィールドは Unity から Xamarin へと移りますが、C# プログラマとして活動してゆくことは変わりありませんので、今後ともよろしくお願いいたします。
]]>…とはいっても、世の中には非標準な Rx もあったりします。UniRx は Unity 環境における Rx 移植ですが、そのままでは LINQPad で便利に使えません。そこで、UniRx でも本家と同じように便利に Dump
したりするためのひと工夫を紹介します。
それはさておき、LINQPad はどんなオブジェクトも .Dump()
すれば見やすく表示してくれるというのが最高に魅力的です。これだけでも LINQPad は十分に便利で使う価値があります。ですが、LINQPad の便利さはそれに留まるものではありません。
…ということ等々を以前書いたりもしましたが、文章ばかりの記事でして面白みにも少し欠けていました。先の記事は割と総論的な内容だったので、趣向を変えて、面白く膨らませそうな LINQPad の便利な使い方について、折にふれて書いていこうと思います。
さて、LINQPad はその名の通り LINQ の学習に非常に有用ですが、Reactive Extensions (Rx) の学習でも活躍します。本稿では、更にひと手間加える事で、LINQPad 上で Rx を interactive に利用する方法を紹介します。
]]>実際、お手軽なのは素晴らしいことですし、安定してる (最近はかなり改善されたとはいえ、Unity で VS のデバッガにアタッチしたりすると稀によく死にますし…) というのも重要なわけで、皆の頼れる味方、UnityEngine.Debug
クラスのロギング系メソッドは最高に便利ですね。しかも、Rich Text 機能を用いることで、
|
|
こんな感じで色とか指定できたり超便利 です。最高ですね。ただ、ちょっとこれは書きづらい…なんとかしたい…
]]>Windows においてグラフィカルにコンフリクトを解決するためのツールは数多く…と言いたいところですが、決して多くありません。どれが使いやすいかというと、うーん…一長一短ということにしておきたい感じです (私見)。そんな中、Visual Studio をマージ ツールとして使うことができ、触り心地も悪くない感じです。Windows 環境のマージ ツールでお悩みの方は、一度試してみては如何でしょうか。
]]>Visual Studio の醍醐味のひとつといえばカスタマイズ、そしてその一角を占めるのが拡張 (extension) の導入ですよね。Visual Studio Community の登場により、拡張がサポートされていない Express Edition に遠慮する必要性が相当減ったのは 2015 年の大きな変化といえるのではないでしょうか。
そこで本稿では、私が個人的におすすめしたい「入れてすぐ納得できる」拡張をいくつか紹介したいと思います。(全部知ってたらごめんなさい!)
]]>bool
でなく Boolean
、string
ではなく String
、そして int
ではなく Int32
と書いてきた (いわゆる) CLR 型名派の私。世間の声にもめげず、自分を曲げずにここまでやってきました。Visual Studio や ReSharper のコード スタイル設定での公認機能拡充等々で遂に我々 (?) の時代が来た!と思っていた…のですが…
この機能、ReSharper 9 までは拡張 (extension) として提供されていたのですが、10 になって本体に統合されました。これを機に是非ひとつ試してみては如何でしょうか?
]]>1 年以上前からあるサービスみたいなので、少し乗り遅れた感はあるのですが、折角このタイミングで使えるようになったんだから仕方ない。
]]>lock
構文を用いるとき、
|
|
と、特別に用意した static readonly
な Object
型のインスタンスを同期オブジェクトに用いるのがお約束となっています。何気なくスルーしてしまうこのイディオムですが、きちんと向き合ってみると意外と便利に活用できるみたいです。
本稿では、いわゆるシンボル型の実装を題材にして、Object
型のインスタンスの活用について記していきます。記事は C# コードを取り上げていますが、比較的言語中立な話なはず。
周りの人に感動を与える芸術的な光のコードを書くときもあれば、目を背けざるを得ない、絶望を振りまく闇のコードを書かざるを得ないときもある。そして、そんな深い絶望を超絶技巧でねじ伏せる魔術的なコードは、両方の要素を具えているといえます。
プログラミングとは、そう、光と闇との大いなる戦い…今回提唱するエレメンタル プログラミングで、皆さんもこの大いなる戦いに身を投じましょう。
(注: 本稿は有用と思われる内容も含んでいますが、本質的にはネタ記事です)
]]>設定がんばったので、個別記事の URI は今までのものがそのまま維持されてます。それ以外は…たぶん大丈夫なはず?
]]>例によって一筋縄ではいかなかったので、やり方について簡単にまとめました。
]]>