restofwaterimpのぎじゅつMemo

SIerに所属。企画から運用まで幅広くやってます。C#中心に書いてます。

【C#】pythonのitertools.permutationsをC#で書いてみた。

python なら 簡単に順列の表現ができる・・・が、C#ではどうやってやるんだ?と 考えてもよくわからなかったので、python のitertools.permutationsの内容をC#で置き換えてみた。

pythonのコードはこちらに記載されている。 https://docs.python.org/3/library/itertools.html#itertools.permutations

def permutations(iterable, r=None):
    # permutations('ABCD', 2) → AB AC AD BA BC BD CA CB CD DA DB DC
    # permutations(range(3)) → 012 021 102 120 201 210
    pool = tuple(iterable)
    n = len(pool)
    r = n if r is None else r
    if r > n:
        return
    indices = list(range(n))
    cycles = list(range(n, n-r, -1))
    yield tuple(pool[i] for i in indices[:r])
    while n:
        for i in reversed(range(r)):
            cycles[i] -= 1
            if cycles[i] == 0:
                indices[i:] = indices[i+1:] + indices[i:i+1]
                cycles[i] = n - i
            else:
                j = cycles[i]
                indices[i], indices[-j] = indices[-j], indices[i]
                yield tuple(pool[i] for i in indices[:r])
                break
        else:
            return

このpermutationsに引数を与えると、順列の結果が返ってくる。 これをC#で書くとどうなるのか・・・を書いてみました。

internal class Program
{
    public static void Main(string[] args)
    {
        var a = Permutation("ABCDE", 4);
        List<string> result = new List<string>();
        foreach (var b in a)
        {
            string str = "";
            foreach (var c in b)
            {
                str += c.ToString();
            }
            result.Add(str);
        }

        
        Console.WriteLine(result.Count);
    }

    /// <summary>
    /// Permutation 順列(重複あり)
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="iterable">葉入れ悦</param>
    /// <param name="r">nPr の rの部分</param>
    /// <returns></returns>
    static IEnumerable<IEnumerable<T>> Permutation<T>(IEnumerable<T> iterable, int r = -1)
    {
        //入力を配列に変更
        var pool = iterable.ToList();
        //配列の長さ
        int n = pool.Count;

        r = r < 0 ? n : r;
        //総数より、抽出が大きい場合は終了
        if (r > n) yield break;
        /*全長*/
        var indices = Enumerable.Range(0, n).ToList();
        /*後ろから*/
        var cycles = Enumerable.Range(n - r + 1, r).ToList();
        cycles.Reverse();
        //変化なし版
        yield return indices.Take(r).Select(i => pool[i]);

        int indicesLength = indices.Count;
        int cyclesLength = cycles.Count;

        while (true)
        {
            bool breakCheck = false;
            for (int i = r - 1; i >= 0; i--)
            {
                cycles[i] -= 1;
                if (cycles[i] == 0)
                {
                    /*iの値を最後尾に持っていき、i以降をひとつ前に寄せる*/
                    var tmp = indices[i];
                    for (int k = i; k < indicesLength - 1; k++)
                    {
                        indices[k] = indices[k + 1];
                    }
                    indices[indicesLength - 1] = tmp;
                    cycles[i] = n - i; // 順列でとる値を復活(元に戻す)
                    /*
                     * 確認のための出力
                    foreach (var c in indices)
                    {
                        Console.Write(c);
                    }
                    Console.Write("  ");

                    foreach (var p in cycles)
                    {
                        Console.Write(p);
                    }
                    Console.WriteLine(" ★");
                    */

                }
                else
                {
                    /*指定の番号との入れ変え*/
                    int j = cycles[i];
                    var tmp = indices[i];
                    // C# 8.0 空しか ^を利用したindexの表現はできないらしい。
                    //indices[i] = indices[indicesLength - j];
                    indices[i] = indices[^j];
                    indices[^j] = tmp;
                    /* 確認用
                    foreach(var c in indices)
                    {
                        Console.Write(c);
                    }
                    Console.Write("  ");

                    foreach(var p in cycles)
                    {
                        Console.Write(p);
                    }

                    Console.WriteLine();
                    */
                    yield return indices.Take(r).Select(i => pool[i]);
                    breakCheck = true;
                    break;
                }
            }
            if (!breakCheck) yield break;
           //yield break;
        }
    }

}

きれいなコードではないと思うが、これでいける。 これで何をしているのか…なのだが、 元の指定した配列を並び替え、前から数分だけ、出力するということをしている。 数学で nPr ように習ったあれである。

ここで利用しているindices と cyclesの遷移例です。 n = 5 , r = 3 とした場合の移り変わりになります。 https://drive.google.com/file/d/1PYs53PWsHqpG0NQSjsvJy2GQ_zFxFK4h/view?usp=drive_link

cyclesの後ろから、値が、3,2,1,0 と0になったら、一つ前のインデックスに移り、インデックスの値を3に戻し、再度処理を実施する。

また、インデックスの値が 0 以外の場合は、指定の場所を基準に値の入れ替え。インデックスの値が0 の場合は 指定の値をindicesの最後尾に配置し、指定の値以降の配列を一つずつ前に寄せる。

すると、すべてのパターンの並びの計算が可能というわけである。

書いてみたもののpythonより、若干読みにくいのかな。 というのと、rangeに関する仕様の違いやyield、Enumerableの扱いを普段やったことがなかったので、置き換えるのに時間がかかった。

ビジネスアプリ内のドメイン知識に対する処置とは違って、純粋に数式の計算のロジックは難しい・・・。

【メモ】LINQを用いた計算について

C#以外の言語でMapやReduceなどを利用することが多いが、C#だとLINQでできてしまうので、便利なことが多い。

普段、仕事で使っている場合はLINQ to EntityかObjectを利用することが多く、ほとんどが 「Select」「Where」で利用することが多い。

Aggregateを使うと、よりいい感じにできるみたいなので、自分の整理のためにメモしておく。

learn.microsoft.com

まあ、MSのサイトにこう書いてあるのだが、例えが自分にはわかりにくかったので・・・

例えば 配列で[ 2, 3, 4, 5, 6]というものと、初期値として10というものがあった場合、 それぞれの配列に10をかけたものの合計を求めるとする。 forとLINQそれぞれ利用したものは以下の通り。

    int[] arr = new int[] { 2, 3, 4, 5, 6 };
    int initial = 10;
    int result = 0;
/*For文*/
    for (int i = 0; i < arr.Length; i++)
    {
        result += initial * arr[i];
    }

    Console.WriteLine($"合計 : {result}");


/*LINQ*/
    var linqResult = initial * arr.Sum(x => x);
    Console.WriteLine($"合計 : {linqResult}");

これを、配列に記載の値をかけるとした場合、LINQには掛け算はないが、Aggregateを利用することで、計算結果を次の配列に使うことができる。

int[] arr = new int[] { 2, 3, 4, 5, 6 };
int initial = 10;
int result = 0;

/*For文*/
int multi = 1;
for (int i = 0; i < arr.Length; i++)
{
/*multi変数を使いまわしとなるが・・・*/
    multi *= arr[i];
}

result = initial * multi;
Console.WriteLine($"合計 : {result}");

/*LINQ*/
var linqMultiResult = arr.Aggregate(initial, (sum, next) => sum * next);
Console.WriteLine($"合計 : {linqMultiResult}");

Aggregateを活用すると、初期値、(設定する値、配列の値) => 計算式 とすることで、初期値の値から、次の添え字の結果、その結果をまたその次の添え字の結果として、計算ができる。 パット見ると慣れない記述となるが、for文であれこれ考えるより、1行でスパッとできるので、いい感じ。

欠点ではないが、極力、指定する数値の型は合わせる方がよさそう。intとdoubleとか異なる型だとコンパイルエラーになります。

ただ、自分が日ごろ管理しているビジネスアプリだとあんまり使わないかな?(会計処理だと使えるかもです)

【メモ】安全確保支援士の学習

2022年秋の安全確保支援士の受験をしました。

結果は・・まだわかりませんが、今回試した方法を記載します。

事前スペック

  • 仕事ではあまりネットワークやセキュリティに関することはしていない(クラサバがメイン)
  • 2022年春にネスペを受験したので、少しは知識が残っている(ネスペは午後1が2点足りず)
  • 仕事でクラウドを使うことになっていきそうなため、ネットワーク・セキュリティの最低知識を知らねば・・・という状態でした。

最初に取った作戦

翔泳社の本  → ざっと一通り読んだけど、かすかにしか覚えられず(鈍器ですね)

インプット系が多く、アウトプット(問題演習)がないため、私は知識定着しにくいなと感じていました。特に、基礎的な部分が身についているのかを計りづらく、「覚えれているかな?」と不安になるばかりでした。

また、仕事がバタバタしていたのと、情報処理試験一週前にビジネスキャリア検定試験も受験予定に入れおり、そちらに集中していました。 そのため、余計、情報処理の学習ができていない状況で、状況にあっていない本でしたね。

中身は良い本なんですけどね。

まとめると・・・。

  • 広く浅く書かれているのですが、テーマごとの関連性がつけにくかった(前をやると、後ろのが分かるというのではなく、網の目のように入り組んでいるように感じた)
  • アウトプットがしづらい。過去問を解けばいいのですが、テーマごとに絞る時間がない。章や節ごとに書いてあるチェック一覧が分かればいいのだが、限られた時間内では難しかった

と、なんだかんだしていたら、試験まで残り2週間。さて、どのようにやろうかとネットサーフィン、twitterを眺めていたら、いいのあるじゃんということで、この二つに絞って学習し始めました。。

方向転換

とにかく、要素技術が私の中で整理できていない。情報の関連性がなく、ストーリーになっておらず、頭に定着しにくい状態でした。 また、午前Ⅱ対策のための過去問演習の準備を楽してできないかなと。

  • 過去問対策

www.sc-siken.com

安全確保支援士の過去問道場という便利なサイトがあるじゃないですか。 過去回と分野別、また解説もしっかり書かれていると。お得ですね。 専門分野のみ絞って、過去問をやりまくりました。データベースやソフトウェア開発全般はある程度、自信があり、セキュリティに絞って問題解けるのは良かったですね。 また、解きながら、現時点の平均点や学習記録も残せ、定量的に自身の変化を知ることができるのもGoodでした。

  • 専門知識のストーリー化

www.youtube.com

この中の「一緒に支援士の勉強をしませんか?」というプレイリストを聞きました。(2倍速で)

ほかにもあったのですが、会話のテンポ、声質、使っているイラストが私にとってはすっと入ったからです。

このプレイリストは毎回、以下のようにテーマごとに10分から15分くらいの動画になっていました。


www.youtube.com

まさるさんのyoutubeは多くテーマありますが、上記のプレイリストがとても良いつくりでした。話が連続しており、前で学んだことを生かして、新たなテーマを知る。順番にテーマ、要素技術を抑えられるというのが私にはあっていました。

  • 暗号の種類→暗号化の方法→認証(エンティティ、メッセージ)→デジタル署名→CA局→アクセス制御

と、まずは防御側のことを知り、攻撃側のやり口を知る。

  • ログの改ざん→ポートスキャン→マルウェアマルウェア検出→パスワードクラック→DoS→中間者攻撃→ネットワーク知識

50以上の動画がありますが、文字で閲覧するより、イラスト動画で、ネットワークのやり取りを説明しており、イメージをつかむのに最適でした。 (私は聞きながら、ノートに同じような図を模写して覚えていました)

実際、本番でも、映像で見たことを思い出して解ける問題もありました。

動画なので、わからなくても何度も見返せますし、視覚と聴覚で覚えられるので、読書だけよりは刺激はあります。

イメージつきやすいものから取り組んだ方がいい

アナログの書籍で覚えるというのもよいですが、せっかく、先人の知恵を拝借でき、かつ分かりやすく解説している動画が数多く出ております。 玉石混合ではありますが、自分のスタイルに合ったものを見つけて、一気に広く浅く理解を深めるのがよいかと。

そこから、時間があればハンズオン(サンドボックスなどが提供されているものは実験してみる)で触ることで理解が深まります。

いろいろつまみ食いは良くないですが、選択肢の幅を広げて、自身に最適な学習ツールを見つけて、学習していっていただければ幸いです。

エリック・エヴァンスのドメイン駆動設計 輪読会 #2 に参加した(自分のメモ)

前回ひ引き続き、DDD輪読会に参加しました。

ddd-community-jp.connpass.com

今回は、聴きながら家のことでバタバタしており所々でしか聞けませんでした。 Discordeの参加者のみなさんのコメントを後追いして、ピックアップします。

前回の勉強会のメモ restofwaterimp.hatenablog.com

今回も前回同様、事前にhackMDに気づきや疑問を記載し、それを拾い上げるスタイル。 前回と違うのは、気づきの数が・・・倍以上に膨らんでいる。

今回、一番刺激になったのは本編ではなく、本編終了後の廊下でのミノ駆動さんの話。 そこに至るまでの前振りなどは背景がわからないので、私の中では???なのですが、 evans本の本質、というかエリック・エヴァンスが伝えたいこと。というのに立ち返れた気がします。 内容は後ほど。

また、本勉強会で前回も感じたのですが、みなさん「言葉の定義」に敏感。 自分が気にしてなかったことも、取り上げられて議論されるので、それを聴ける、見れるだけでも勉強になります。

学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)

 今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。  この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。  これから、参加していき、何のことか自分なりで語れれば、更新していきます。  深く学びたい場合は、勉強会へ参加するのが近道ですww

 参加されている方の属性(しばてぃさんがPower BIで作成したもの。こういうことがすぐできるのが、 Power BIの凄さですね) オンラインということもあり、全国から参加されてます。  

2章のHackMD

hackmd.io

「用語と概念間の関係性」

この意味と、表記の揺れや意味の揺れについて議論が進む。 開発者とユーザ側。また、ユーザの間でも意味が違う。 コンテキストが異なれば、意味が違うのはそうなのだろうが、同じコンテキストないで、同じ意味を違う言葉で使っていたり、同じ言葉を違う意味で使っているなら統一する必要がある。

「よく言われる「DDDは重厚・重たい」という評価の発祥はどこか」

私は重たいと思っていた。書籍の厚さもあるが、覚えなければいけないことがたくさんあるイメージがあった。 実際、最初に一人で読み始めたときは話が抽象的で、読むために必要なバックグラウンドが掴めていなかった感じ。

実装の本かと思えば、設計の本とも思ったが、どうも単純な設計の話だけに終わらない本というのが今のところイメージです。 読み進めたら変わるかも。

ユビキタス言語」

little_hands こと松岡さんの

「ubiquitous = in every where」で、ただ言葉を合わせましょう、以上に「会話でも、コードでも、ドキュメントでも」っていう意味が込められてるので、「共通言語」以上の意味を持つのだと思います

で、ユビキタス言語って、文字に起こした時の言葉だけじゃないのねと理解した。てっきり、用語だけ統一と思っていたので。

「OOUI」

オブジェクト指向UIは読んだことがないからどういうことかわからなかったが、フロントエンジニアとバックエンドのエンジニア間で共通の言語を用いた方が良いかという質問かなと。

同じ方が良い意見もあるし、違うこともあるという意見もあった。 私自身の経験だと同じ方が良いという認識であった。が・・あくまで、「開発者の中」という意味で。 これが、ユーザ(扱う部門が違う)とかだと同じデータでも違う言葉を使うこともあるなと思っていたので、何が良いかはわからず。 もし違っていても、違った意味で使っていると関係者が認識できているのならそれはそれでいいのではと思ったり。(ただ、誰かが確認を取らなければいけないので後々面倒になりそう)

「表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること」

イテレーティブにすることというのもあるが、社内のコンサルタントによく言われることがあったなと思い出した。簡潔にかつ具体的にわかるかつストンと腹に落ちる言葉を考えるってこと。それを図とコードに再び反映させるってのはドメインのモデルを見直すということ(と自分は認識)

「çになってしまうと、ドキュメントはプロジェクトの進捗とのつながりを失ってしまうことが多い」

この話、リアルで聴けていないのでコメント見て。 いろいろ参考にしてよいというリンクが貼っていたので、転記 前回の知識を噛み砕くでもドキュメントの話は上がっていた。前回はリバースで作れるものはあえて書かない。「なんでそういうモデルにしたのか」というのは残した方がいいよねと。今回の話はドキュメント更新されないよね・・・ということかな?

domainlanguage.com

www.slideshare.net

以下の言葉の定義について議論されていた。

  • モデル
  • コード
  • ユビキタス言語 自分なりの説明ができると良さげ。
「P41 の図2.4と図2.5 のモデルについて」

違う図が書いてあるのはみなさん許容されている。違う視点で書かれているから。 その事象をどう捉えるかということと、「誰に伝える図」なのかがポイントかなと感じた。

何か調査をするときなども、「自分の分析のための図や表」と「誰かに説明するための図や表」は違うことがある。 また、切り口も変えることがある。

松岡さんが書いていたエリックの地球儀の話はこのyoutubeなのかな?あとでみよっと。 www.youtube.com


ここで22時ちょっと過ぎくらい。ここから廊下が始まった・・(終わったのは翌日2時少し前くらいだったそうです)

上段に記載しましたが、本編外でご講演(?)がミノ駆動さんよりあったので、そこがとてもためになった。 RailsとDDDの話の前提として以下のことが語られました(自分の理解なので間違っていたらごめんなさい)

「DDDで達成したいこと」は何か?という問いかけ

日本語版への序文にEvans自身が書いていて

  • コアドメインに集中すること。

  • ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探求すること。

  • 明示的に境界づけられたコンテキストの内部で、ユビキタス言語を語ること。

主人公はコアドメイン。コアドメインの価値を最大化すること。 → メイン業務のウリや価値って何かを語れるか。

ビジネスの足を引っ張るのは何か

  • コアドメインのビジネス価値が上がらない → 競争優位性を失っている

  • コアドメインの開発生産性 → 技術的負債、UIやDBとの密結合

コアドメインに集中するために、他の層との結合を疎にする → 例えば、オニオンアーキテクチャ

ドメインの変化 → 実装のモデルも変化

設計時にはコアドメインの変化が実装にどう影響するかはわからない(というか、ユーザとかはしらない) そのため、できそうと設計時に判断してもシステム側が足を引っ張ってしまい、開発生産性が下がり、市場競争に負けてしまう可能性もある。 それを防ぐため、実装もコアドメインに集中させるため、依存を取り除くようにすべきだろうということ。

自社サービス(対外向けのサービス)を作る人はモチベは上がるが、内向きの仕事やSIなどの他企業の仕事の場合は モチベが上がらないという意見もあったが、それは違うということ。 より良い設計を作ることで、自分の価値をあげ給与に反映や、自社の売り上げに貢献する。 自分自身の価値をあげる活動にする。

DDDの特性として、

  • 保守性

  • 変更容易性

  • 機能性

私の周り(SIer)では自分の書いたコードの設計で、自分の価値をあげようとか、売り上げ貢献に反映する動機でDDDなど より良いコードを書くという人がいないのでエンジニアの方からこういう言葉が出るのが衝撃であった。

設計やコードを洗練するということが自発的になされないことが多く、なかなかつらしのこともある(ただの実力不足?)。

わからないなりにDDDを取り入れようとしているのだが、自分の中のモチベは「保守性」と「変更容易性」 提供している機能にコアな部分の変更を容易にし、ビジネスへの変更をなるべく早く対応できるように変えたいなと。

話を聞いていて、実装をする人も経営のことを知るべきと感じた。 (多分、DDDやろうとしている人はビジネスエキスパートと話をする必要があるので、自然に対象のドメイン業務および 経営は学ぶ必要があるとは思っている) 自分たちが作るものの価値、インパクト、投資対効果などなどを見極めつつ何に注力するかというのを 他人任せにせず、自分で決めれるようになるのいい。

参考で貼られていたリンク

qiita.com

qiita.com

脈略のない文章になってしまいましたが、これで終わり。 今回も、開催していただいた@jnuank_さんありがとうございます。

次回もまた参加しよう!

読む敷居を下げてもらえる本(かなりお世話になってます)

booth.pm

エリック・エヴァンスのドメイン駆動設計 輪読会 #1 に参加した(自分のメモ)

ドメイン駆動・・・。書籍持っているけど、一人で読み続けられず、挫折し、積読状態になっていたところ、 「オンライン」で開催しているじゃん、と見つけ、参加。

ddd-community-jp.connpass.com

昔に統計の書籍で輪読会には参加したことはあったが、「初学者入りにくい・・・」と思っておりましたが、本輪読会。。最高の学びの場でした。 文殊の知恵最高って感じの内容で、あっという間に3時間聞いてました。

勉強会のスタイルは hackMDで書籍の気づき・感想と疑問を事前に参加者で書き書き。 勉強会中は、hackMDの内容をファシリテーターの方が、まるでラジオを聞いているかのような感じで、題目に対してアテンド。 並行で、Discordにチャットでその時の気づきやアドバイスなどなどが経験者や有識者からひっきりなしに書き込まれるという。 音声はきかなあかんは、チャットは追わなければ・・・とてんやわんやでした。

聞いているだけ、チャットを眺めているだけで、学習できるという素晴らしい場の時間でした。

でもって、あとで、チャットを追ってみよう・・・と取り組み始めているのですが、コメントが多く、追うのだけで大変。 ただ、テキストで追っていくだけで、「そういう話していたな〜」と思い出しやすいです。

学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)

 今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。  この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。  これから、参加していき、何のことか自分なりで語れれば、更新していきます。  深く学びたい場合は、勉強会へ参加するのが近道ですww

ドメイン

エヴァンスの用語解説では「知識、影響、または活動の領域」 開発するのって、このドメインにある問題を解決したいことを作るのかなと。 why必要として、whatどういう姿になっていたいのか。 howに走らない。何となく、BABOKとかREBOKの話かな?

モデルをシンプルにする

 幹と枝葉と思っていた。幹だけを見つけるのがとても難しい。それも、「誰も見ても、それ!」と言える部分を見つけるのが。

コメントで参考となっていたサイト martinfowler.com シンプルなデザインのルール

  • テストに合格する

  • 意図を明らかにする

  • 重複なし

  • 最小限の要素

優先順位は上の方が高い。 実装する時や設計する時は「意図を明らかにし」「最小限の要素」でドメインのことを示すことができるのか。 不要な部分は削るのだが、削った結果、「ビジネスに価値があるモデル」になっているかかな?検証するには例示とかかかな。

ja.wikipedia.org

アジャイル開発(大規模)

「チームを複数に分割したアジャイル 開発」→危うい

何となく、モデル分析して、「このモデルはこのチーム」「このモデルはこのチーム」、「かぶるところあるけど、これはあのチーム」って分けるとあとで崩壊ってことかな? もしくは、全体のモデルを考えずにモデル考えて、全体でつなげたらつながらん・・・ってことかな。SIerだとよくある・・・ってなっていたけど、よくあるかと。 アジャイル でなくても、ウォーターフォールでもあると。関連するシステムの境界を跨いで全体を俯瞰できるように(一人でも複数人でも)しなければ、 ドメインの境界はつながらないだろう。(業務もシステムもどちらも考える必要あると個人的な経験ではかある)SIerだと、先に機能ごとにチーム分けて、 つながらなくなることありますから・・・。

cynefin framework ← 初めて聞いた

iandco.jp

知識の噛み砕き

CleanArchitectureから考えるのか?? モデリング と言ってもデータベースモデリングではない。業務分析/ドメイン分析のこと。 ここは納得。データモデリングからするのではなく、業務を知ること。用語、一番主となるフロー、登場人物などを知ることが先。 また、その業務が「何のために、何を実現させるために」やっているかを整理するのも。(これしないと、データの世界だけで追っていても何作っているのか訳わからなくなる)

blog.j5ik2o.me

「最初からドメインオブジェクトだけをテストコード上で会話させる設計」   → どういうことかわからず。。。。本読めばわかるのかな?

勉強会の参加の皆さんは「設計、分析は一回こっきりではなく、ずっとやる」というtwadaさんのコメントに納得されていますが、 私の周りの現実ではそうならないこと多いなと・・・(業務は常に改善、進化するがね。システム変わらないのかい?というのと、システム作っても「もっと良い感じにならないかな?」 と考えるのが価値を高める気がするのだが・・・)

継続的学習

ここの質問、自分の取り上げてもらえてよかった。ドメイン知識が人に残る(それが成長)というのは理解できていたのだが、一度解散したプロジェクトがまた戻った時、 どうやってドメイン知識を引き継がせるのか・・・がわからなかったので。コードの設計はドメインの切り方などで残すけど、設計意図とかどうやっているのだろうと。

意図や歴史を(口頭でも)伝承できる人を増やす、絶やさないという方向もあったりしますよね は私もなるほどと思った。一人じゃなく、増やせばいいのだと。

why   なして、そういう設計(モデル)にしたのかを他でわかるようにしておく what ←

how Resharperjig(私もC# 使いなので、ReShaper使いたいけど、買ってもらえない・・・) 

RDRA ADR(Architectural Decision Records) Design Doc  → 聞いたことなかったので、見てみる。 www.sparxsystems.jp

qiita.com

ドメインエキスパートへコードを見せるか

自分は見せたことない。間に入る方(大体情報システム部門)へはありますが・・・。 コードではなく、業務モデリングを見せて説明かなと。そっから、正常系なのか例外系なのかを嗅ぎ分けるのが難しいですけど。 (往々にして、話し手のバイアスが入るので)

ソフトウェアを再構築するようなモデルの見直し

私もこれは気になっていた。放っておきたいけど、メスを入れたいのだけど・・・

t_wadaさんより t-wada.hatenablog.jp

で、タイムラインに流れてきたこれをポチりとした。 きたら読み込む

リファクタリング、リアーキティング、リライト について書いてあるそうなので、そこをまずはみる。

輪読会で扱っている書籍

【メモ】MS Learn のsandboxの利用(Visual Studio2019を利用する場合)

勝手に自分がはまったのでメモ。

f:id:restofwaterimp:20200606075824p:plain

サーバレスアプリケーションのMS Learnの途中でVisual Studio で作成した function を azure functionにデプロイする という演習があり、途中でsandobxに接続するというのがあるのですが、 なかなかうまくいかず、てこずったので記録として残します。

何にてこずったのか? ここで、Concierge Subscriptionがでず・・・ f:id:restofwaterimp:20200606081040p:plain

Azureで関数を作っていたし、VSも最初からログインしていたのに出てこない・・。 なぜ?と思っていて、関数を作り直したり、 sandboxを一回expireさせてから再度やったりと。

結果として、これが解決なのかわからないですが、 こうしたらできた、ということで。

VSのアカウントのプロファイル管理で再度ログインする

これで見えるようになりました。

VS右上にある、アカウントのアイコンをクリックし「アカウントの設定」をクリック

f:id:restofwaterimp:20200606081833p:plain

プロファイルの管理画面に遷移する

f:id:restofwaterimp:20200606082034p:plain

そこで、アカウントのタイプでsandboxがあるので、一度切り替えて保存。

そうすると、Conciergeのサブスクリプションが表示された

選択できれば、そのまま継続できます。

MS Learnに記載されている内容やdocsの内容もVS 2017がベースで書かれているものなので、 2019でやるときには少し違う部分があるみたいです。

これで、先に進める・・・。

【C#とpython】 リストとタプルと辞書と集合

リストとタプルと集合がよくごっちゃになるので整理

pythonではなくC#でいうと・・・

タイプ 使い方 C#だと pythonだと 特徴
リスト 添字 new List<T,T> をつける。t=["A","B","C"] add,removeで追加削除可能 pythonならappendなど
辞書 key-valueとして利用する new Dicitionary<T,T>() Dictionary = {"USA":1, "JAPAN":2, "Germany":3} RDBのような構造。
タプル C#だと戻り値。pythonだとimurableな変数 return (0,1)など。C#7.0より利用かのいう ()をつける。t = "A","B","C" 追加、削除など要素の書き換えはできない
集合 数学的な集合と同じ。文字列や文字を一意に作成する HashSet() Sorted Hash()など set() 文字 やset 配列の値 set Dictionary キーの値のみ一意に 追加削除はできない