大変遅くなりましたが、言語の由来Part2です。

・Java
断定はされていないようなのですが、
言語ロゴがコーヒーカップであるようにコーヒーが由来のようです。
ジャワコーヒー（Java Cofee）のJavaではないかということのようですね。

・Python
イギリスのコメディ番組「空飛ぶモンティ・パイソン」から取られたようです。
わかりやすく特徴的なだけにこの由来は有名かもしれませんね。
開発者は短くて個性的で少し不思議な名前を付けたいと思っていたようなので、
印象に残りやすいのも納得です。

・Rust
植物に寄生するさび菌に由来するようで、堅牢（Robust）の部分文字列でもあるそうです。
開発者チームに自転車好きが多かったためロゴは歯車になった、とどこかで見かけていたため、
てっきり金属の錆のことだと思っていました。

・Dart
最近名前を見聞きする、クロスプラットフォームフレームワークのFlatterで使用される
Dartの名称の由来はググり力が足りず調べても見つかりませんでした。
どなたか知っておられる方がおりましたら教えていただけますと幸いです。

他にもいくつか調べたのですが、書くのにあまり時間をかけ過ぎてもアレなのでこの辺で。
こうやって言語の由来を調べてみると、開発者のことが垣間見える感じがして良いですね。
皆さんも息抜きに自身の好きな言語の由来を調べてみるのはいかがでしょうか。

[1] Java – Wikipedia: https://ja.wikipedia.org/wiki/Java
[2] General Python FAQ — Python 3.10.0 documentation:
https://docs.python.org/3/faq/general.html#why-is-it-called-python
[3] Internet archaeology: the definitive, end-all source for why Rust is named “Rust”:
https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

今まであまり考えたことがなかったのですが、
ふとC言語の”C”とは何ぞやと思い、
C言語及び関連言語の名称の由来を調べてみることにしました。

・C言語
B言語の改良した言語、でC言語だそうです。
流石にA, B, C…のCではないだろう、と思ったら似たようなもので驚きました。
そのC言語の由来となったB言語自体の由来は、
BCPL（Basic Combined Programming Language）を元に開発されたため
その短縮形である、という説が一般的なようです。
こちらはA言語が由来ではないのですね。
（BCPLやその元のCPLも同様にA言語由来ではないようです。）
因みにA言語の由来はa programming languageの略だそうです。。。

・C++
Cを一歩進めたものということで、CをインクリメントしてC++, 納得です。

・C#
インフォテックでもメインで使用しているC#ですがその由来は、
C++を更にインクリメント（改善）して C++++
↓
4つ並んだ+が#に見えるので C#
だそうです。
#そのものの意味を含んでいないとは思わず、調べた中で一番驚きました。

その他の言語の由来もいくつか調べてみたのですが、
長くなりそうなので、また別記事に分けて紹介しようと思います。

参考：
[1] C言語（C language）とは – IT用語辞典 e-Words（https://e-words.jp/w/C%E8%A8%80%E8%AA%9E.html）
[2] B言語（https://ja.wikipedia.org/wiki/B%E8%A8%80%E8%AA%9E）
[3] A言語（https://ja.wikipedia.org/wiki/APL）
[4] C++言語とは – IT用語辞典 e-Words
（https://e-words.jp/w/C-_-_%E8%A8%80%E8%AA%9E.html）
[5] C#（C Sharp）とは – IT用語辞典 e-Words（https://e-words.jp/w/C-.html）

先日、Visual Studioでコードエディタ上を右クリックした際のメニュー*に、
上部メニュー内の項目（ビルドなど）があると良いな～と思うことがありました。
* コンテキストメニューと言うそうですね

少し調べてみたら方法がわかったので、備忘録も兼ねて以下に記載します。

1. 上部メニューのツールからカスタマイズを開く

2. カスタマイズのコマンドタブで
2-1. コンテキストメニュー：エディタコンテキストメニュー|コードウィンドウを選択

2-2. コマンドの追加を開き、目的のコマンドを追加

以上の手順により、コードエディタ上で右クリックした際のメニューに目的の項目（コマンド）を追加できました。

頻繁に使うわけではないけれども上部メニューから一々実行するのは手間な場合に、
ショートカットキーと違って覚えておく必要のない、
今回のコンテキストメニューへの追加が便利なのかな、と思います。

参考にさせていただいたのは以下のサイトになります。
ありがとうございました。
Sunday Programmer’s Report: Visual Studio のコンテキストメニューに「Blend で開く」を追加する

たまの休日に一部の復習も兼ねて、”Java言語で学ぶデザインパターン入門”を亀のようなペースで読み進めています。
個人的に一番好きなパターンはStrategyパターンです。
このパターンは、インタフェースを定義してアルゴリズムを交換可能にするもので、
典型的な使いどころには、ゲームにおけるプレイヤーAI（CPUなどとも呼ばれますね）の思考ルーチンが挙げられます。
例えば、囲碁や将棋などの対戦ゲームにおいて、戦略の異なるAIをこのパターンで実装します。
以下のような形ですね。

public interface IPlayerStrategy {
    // 入力されたゲーム状態を元に行動を決定
    PlayerAction DetermineAction(GameState state);
}

public class AggressiveStrategy : IPlayerStrategy {
    public PlayerAction DetermineAction(GameState state){
        // 攻撃的な戦略に基づいて行動決定
    }
}

public class DefensiveStrategy : IPlayerStrategy {
    public PlayerAction DetermineAction(GameState state){
        // 防御的な戦略に基づいて行動決定
    }
}

public Player {
    private readonly IPlayerStrategy _strategy;

    public Player(IPlayerStrategy strategy){
        _strategy = strategy;
    }

    public PlayerAction GetNextAction(GameState state){
        return _strategy.DetermineAction(state)
    }
}

名が体を表す良いパターンだと思います。
個人の趣味ですが、典型例がゲームなのも良いですね。

実務経験はほぼないので、憶測になってしまうのですが、
実務であれば例えば、あるクラスにおいて、インスタンス生成時に決定される同一のフラグによって挙動を切り替える処理が何度も登場するような場合に、
Strategyパターンを適用できるのではないかと思っています。
インタフェースを切り、フラグのオンオフの挙動をそれぞれその具象クラスに切り出すことで、
外部のクラスには影響を及ぼさずに、フラグ毎の処理の見通しを良くできるような気がしています。

経験を積んで、パターンの使いどころを見極められるようになりたいです。

先月研修でC#の勉強をしていたのですが、C#8.0からusingステートメントが、
以下のようにローカル変数宣言の先頭に追加する形で行えるようになっていたことを知りました。
(using declarationと呼ぶそうです)

// after 8.0
using var sw = new StreamWriter("hoge.txt");

// before 8.0
using (var sw = new StreamWriter("hoge.txt"))
{
}


8.0以前はその後の処理を記述する際に中括弧やインデントが必要だったのですが、
この形式だとネストを減らすことができてありがたいです。

ただ、Disposeの呼び出しがスコープの末尾なため、
記述の長いメソッドで利用するとリソースの解放が遅くなり、
場合によっては支障が出るのではないかと思ったのですが、
そもそもメソッドの長さが適切であれば問題ないことに気付きました。

メソッドの長さは適切に、ネストは浅く、シンプルなコードを書くよう心掛けたいです。