より良いエンジニアを目指して

1日1つ。良くなる！上手くなる！

読書感想「オブジェクト指向UIデザイン」

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

オブジェクト指向UIとタスク指向UI

オブジェクト指向UI

  • 名詞 -> 動詞
  • まずオブジェクト選び、次にオブジェクトに対するアクションを選ぶ
  • ナビゲーションはオブジェクト（名詞系）を手がかりにするう
  • あらゆる情報システム、特に作業者による探索や創意工夫が期待されるものに通いて有効

タスク指向UI

  • 動詞 -> 名詞
  • まずタスク選び、次に引数としてオブジェクトやパラメーターを指定する
  • ナビゲーションはタスク（動詞系）を手がかりにする
  • オブジェクトを選択する必要がない場合や、定例の入力手続きだけを提供する場合

例として、お金を入れてから買いたい飲み物を選ぶ旧式の自販機をタスク思考UIとして挙げています。

オブジェクト指向UIの設計ステップ

  1. タスクの洗い出し
  2. <モデル>オブジェクトの抽出
  3. <インタラクション>ビューとナビゲーションの検討
  4. <プレゼンテーション>レイアウトパターンの適用

オブジェクトの抽出では、エンジニアの本で見るようなクラス図が登場します。

実際に本書では演習としてそのオブジェクトの抽出作業や、アプリケーションとして必要なタスクを考えるワークアウトが用意されています。

読書感想「転職2.0」

転職2.0　日本人のキャリアの新・ルール

これまでの転職（転職1.0)は1回の転職を成功させて給与を上げれば、終身雇用に乗っかれば儲けもの。

そうではなく、これからの転職（転職2.0)は3,4年のスパンで転職して働き続ける。これまでの転職の概念を改めて、新しい転職をしようというのが本書です。

前提として筆者はLinkedInの日本法人代表なので、転職推進派ということは念頭に置いた方がいいです。とはいえ、それでも良心的な転職の考え方だとは思います。

転職するつもりはなくても職務経歴書を書いてみるというのは僕も常々思っていたことです。外での市場価値を知ることは内での価値を高めることにもつながりますから。

ただ、書いてあることはふわっとしている。というか、なんかキャッチーなようなキャッチーでないような単語を作って説明しており、逆に曖昧に聞こえるので、それを整理してみます。

  • ポジション、スキル、業種、経験、コンピテンシーの観点で自分をタグ付けしてSNSで発信する
    • タグは転職だけではなく、現業や仕事外（育児など）でも得ることが出来る。
    • スキルは長持ちしない5年持てばいい方。
    • このタグの掛け合わせの希少さが市場価値を高める。
      • 筆者の場合はエンジニアx企業買収（エンジニア観点でイケてる技術を使っている企業をピックアップできる）
  • 目指すポジションがあってそれに向かってスキルを得たり転職したりする。これがポジション思考
    • 熱いポジションを知るには企業に所属しているキャリアコンサルタントに話を聞くのも手。
  • 仕事を会社で選ぶのではなく、自分の持っている能力との相乗効果を生み出せる仕事を選ぶ
  • やりたいことがない人は、今の仕事の中でワクワクすること、楽しく感じることは何かを見つける
  • 転職の際に最も有用なのは有価証券報告書（求人情報には都合の良いことのみ掲載されている、四季報では漠然としている）
  • 面接では会社が設定した目標と自分が達成したい目標の2軸で説明する
  • 転職してからは3ヶ月で慣れることが勝負。上司に仕事をする上で、誰と調整すべきかを聞いておく

転職2.0の目指すところは一生生き残り続けられること、そして我慢することがなくなっていく転職です。

UnityでNuGetをUnityNuGetで扱う

UPM経由でNuGetパッケージを扱えるUnityNuGetについて

上記の記事を参考にさせていただきました。

UnityでNuGetを扱いたいなーと考えた結果、UnityNuGetを使うことにしました。

github.com

UnityNuGetの良いところはPackageManagerで扱うことができる点です。

ただ、注意点としては、以下のファイルで宣言されているライブラリしか扱えません。なので、NuGetForUnityの方が扱えるライブラリは幅広いのではないかと思います。

UnityNuGet/registry.json at master · xoofx/UnityNuGet · GitHub

私が扱いたい Prism.CoreとMicrosoft.Extensions.DependencyInjectionを扱えれば良いのでこれでOKでした。

DIライブラリをUnityContainerからMicrosoft.Extensions.DependencyInjectionへ乗り換え

C#

発端は既存コードをUnityで使いたいからでした。

しかし、UnityContainerは名前空間は同じUnityで衝突してしまうのです。

気づくと、とっくにサポートは終わっていたのです。

github.com

世の中は常に変化してるものなんですね……。

そこで何を使うか考えたところ、Microsoft.Extensions.DependencyInjectionにしました。

www.nuget.org

Microsoftがサポートしてますし、UnityNugetでも取得可能なライブラリということもあり、すんなり決まりました。

DIライブラリに要求することなんて、登録と取得しかありません。

単純な置換でほぼほぼ解決しました。

仕様の違いとして、

  • 登録はServiceCollectionに対して行う。取得はServiceProvider経由。
  • 登録後にServiceProviderを生成しないとダメ。（これが面倒）

なので、途中まで登録して、後から追加がしづらいのです。

staticクラスに集約していたので、以下のようにしました。

    public static class ContainerSource
    {
        static ContainerSource()
        {
            RebuildServiceProvider();
        }

        public static ServiceProvider Container { get; set; }

        private static readonly ServiceCollection ServiceCollection = new ServiceCollection();

        private static void RebuildServiceProvider()
        {
            Container?.Dispose();
            Container = ServiceCollection.BuildServiceProvider();
        }

        public static void AddSingleton<TService>(TService instance) where TService : class
        {
            ServiceCollection.AddSingleton<TService>(instance);
            RebuildServiceProvider();
        }
}

呼び出し方としては

                ContainerSource.AddSingleton<IScriptService>(new ScriptService());

みたいな感じで呼びます。

読書感想「ビジネスマンのための新教養 UXライティング」

ビジネスマンのための新教養 UXライティング

ユーザーの体験に合わせた言葉を選ぶ。これがUXライティングです。

本書の冒頭でサービスの画面のボタン名が「登録」とか「新規会員登録」ではなく、「２週間無料お試し」とか「一緒に始めよう」となっています。

何気無く、触っていたサービスの画面ですが、あっ、これがそうなのかと気付かされました。

そういう考え方をするにはどうすればいいのか。ユーザー目線といったら、そうなのですが

ユーザーの言葉でUIを作っていく

という言葉はなるほどなと思いました。

どうしても開発者はシステム寄りの言葉を使ってしまいがちですから。

  • ペルソナ法
  • ジャーニーマップ

という手法も紹介されてます。

ボリュームとしては物足りない気もしましたが、UXライティングについて軽く知りたいという入り口としては適切な本です。