あけましておめでとうございます。
さらに久しぶりの更新になります。長らく放置していましたこのブログですが、ドメインの更新を機に止めようかどうか悩んでおりましたところドメインが自動更新してしまったのでしばらく続けます。
改めてこのブログをみると足掛け17年ということで、ざっと見返しますと
ADP（プログラミング）関連、サーバー（書籍）関連 → 英語（通訳案内士、留学、勉強）関連 → 迷走
とまぁ見ようによっては私自身の歴史を感じるものでございます。
昨年はサービスを思いついたのでそれのブログにしようとしましたが、インバウンドの復活を受けて忙しくなりサービスの開発が進んでいない状況です。ただ、サービス自体の意義を感じますので表向きは進んでいませんが、資料集め等はしています。
コロナ禍中に、会社の方で動画をやろうということで Youtubeを始めたり、Facebookを始めたりしまして、こちらも試行錯誤をしていたのですが、ここ１年程、更新のペースをつかみつつありまして、こちらの方は整理をしようと思った次第のですが、個人のYoutubeの方の宣伝に使おうかと思い直しました。
どうも文章を書くより、好き勝手にしゃべった方が続くようでYoutubeの方はここ２年半平均すると、月に１本のペースでやっています。
ということで、こちらの方は、Youtubeのアップに使おうかと思います。
先月末の更新になりますが、下記２本の動画を上げています。
第82回 デジタル人材育成のための「実践の場」開拓モデル事業に与太話的に物申す
こちらは、本音として「国が派遣を応援するようなことをするなよ」という思いもあったのですが（誤解のないように書きますと私個人としては派遣での就労は好きな方です）、こういう話もあるのである意味仕方ない面はあるのかなと思います。
第83回 Intel vs AMD 2024 - 2025 Arrow lake vs Zen5
こちらは、半分趣味の話になります。インテル、ＡＭＤ共に昨年新製品がでましたが、お楽しみは今年に持ち越しになりそうです。
正月もすっかり明けてしまい、確定申告の時期を迎えてバタバタしています。
何気に、サーバーを昨年の年末にWindows 2019に移行し2012は実稼働2年と短命で終わりました。
使っている機能は大きく変わることもなく新機能についてもあまり興味がないので、移行自体もレポートを書くほどではなかったので記事にするのを忘れてしまいました。
ちなみにWindows 11ですが、出だしでRYZENに不具合が出ていて様子見していましてどうしようか悩んでいる今日この頃です。
コロナが長期化していますが、最近PCパーツの断捨離をはじめました、ここで紹介しましたネットブックも出品しています。
で、すっかり綺麗になりつつあり、奥さんも喜んでいるところで終わらせればよいのですが、なんとCPUを”落札”してしまいました。
Haswell-EのCPU、Core i7-5960X
になります。
なぜこのCPUを落札したかですが、昨年あたりにV-Tune（インテル プロファイラ）を無料で使えるようになっていること知り、さっそく試してみたのですが、
Core i7-980XではCPUが古すぎて対応していなく、ノートPC(Haswell）だと動作したので、思わず手を出した次第です。
Core i7-5960Xですが、発売当時は10万円程度だったので、それが数千円程度で手に入るのは時代の流れを感じさせます。
マザーボードについては価格差があるのでトータルでは1万円程高くなるようですが、Core i7 980Xもオークションで8000円程度で売れるので、CPUについては、ほぼ価格差なしで980Xから5960Xに交換できます。
1円からのジャンクということで『ダメもとで』ということで1300円で落札しました。
『CPUの次はマザーボード』ということでX99のマザーボードを落札し、『i7-5960xが動かなかったら』ということで予備のCPU(5930K)を落札し・・・
等々、結局、
マザーボード：3枚
CPU：7個
CPUクーラー：2個
を約5万円で落札しました。で、テストを行い、結局動くのが
マザーボード：2枚
CPU：3個（Core i7-5960X 2個、Core i7-5930K)
CPUクーラー：2個
で、Core i7-5960Xが動く環境、2セット＋αを5万円で仕入れたことになります。
高いのか安いのか微妙ですが、外れのCPUとマザーボードはジャンクとして出品しますのでいくらか（多分、CPUは100円、マザーボードは1000円ぐらいか？）回収できそうです（追記：なんやかんやでCPUが1500円、マザーボードは5000円で売れた。稼働品のCore i7-5960Xを5000円で売ったので11000円程回収した）。
Core i7-5960Xですが発売が2014年で8コアのCPUになります。ベースクロックは3GHzでターボブーストで3.5GHzまで回ります。
タスクマネージャでも時折、3.5GHzとレポートしており、このあたりのCPUはターボブーストがきちんと動くようです。
Core i7-980Xは、一応ターボブーストが搭載されているが、上り幅が低いこともあり、ターボブーストを意識していなかった。
もっともRYZEN9 5950xもターボブーストが効いていおり、ベース3.4GHzですが、ちょっと負荷をかけると4GHzまで行きます（コア数によるが）。
CPUウォッチャーの私としては発表当時のニュースやベンチマークも記憶に残っており、プラットホームがSocket 2011-V3で『そろそろ買おうか』と考えていたCPUになります。
その後、様子見をしている間にRYZENの噂を聞きつけてそちらに移ったのですが、そのCPUを手に入れることになるとは感慨深くなります。
Socket 2011-V3ですが、Haswell-EとBroadwell-Eに対応しており、コンシューマー向けCPUでは初の10コアCPUである、Core i7-6950Xが動作します。
こちらはオークションで落札してもよかったのですが、あまり値段が変わらなかったので中古でPCショップで買いました。税込み3万円程になりますが、発売当時が20万円したことを考えるとこちらも時代の流れを感じさせるものがあります。
というわけで5950Xの次は、5960Xと6950Xになり型番はあがりましたが時代に逆行しています。
ちょうどいいタイミングでこんな記事を読みました。6950xを購入してテンションが上がっているところで若干興ざめしてしまいました・・・。
古きプロセッサを温ねて新しきプロセッサを知る
今年は本当に色々ありました。
仕事面ですが、ここ数年ガイドの仕事をしていたのですが、コロナ禍でガイドの仕事がなくなりました。
一方で、とある団体の理事になり、その関係でヒマも手伝い久しぶりにシステム開発を請け負いました。
もっとも理事になったことはまったくの黒歴史になり、年明け早々に辞めるので、ここに厄落としに書いて終わりにします。
コロナ禍でZoom会議をやるようになったのと、仕事を請け負った関係もあり、PC環境はかなり変化がありました。
ざっと書きますと今年のＰＣ環境の変化は下記のとおりです。
1月 RYZEN9 3950XでPCを組む
このマシンですが、Zoom会議に大活躍しました。メモリ128GByte、フルSSDで充分なリソースでタフな使い方でも平気でした。
Zoom会議自体はプアなマシンでも参加できますが、画面共有したり、出欠を取る為にExcelを立ち上げたり、仮想マシンも上げている中でレスポンスも悪くなることはなく活躍してくれました。
さらに会議の動画UP用に、エンコードを行うようになると16コアが生きてきました。そういうことに縁遠かったので、まさか動画のエンコードをやるとは思いませんでしたが良かったです。
8月 4Kディスプレイ（27インチ）を購入
今までUXGAを２台で使っていたのですが、Zoom会議用に4K＋UXGAの２台にした。
今までは横長のディスプレイが無かったのですが、その場合、他の方と画面共有したときに微妙にサイズが合わないので、1台を横長のディスプレイにした。
8月 Androidタブレット購入
買ったのは、NEC PC-TE708KAS LAVIE Tab E TE708/KASなのですが、今までiPhoneで頑張ってきましたがやはり大きい画面の方がよいです。
11月 Tiger Lake のノートPCを購入
今までHaswellのノートPCを使っていたのですが、6年ぶりに更新で、MSI Prestige 14 EVOを購入。
CPUは、Core i7 1185G7(4コア ベース3.0GHz ブースト4.8GHz)で、あくまでも体感＆ADPのプログラムの実行の範囲内ですが、シングルスレッド性能はRYZEN9 3950X(16コア ベース3.5GHz ブースと4.7GHz)よりも速い気がします。ベンチマークテストで、3950Xが7秒台だったものがTiger Lakeは6秒台でした。
改めて感じたのは、めったにエンコードをしないしゲームもしない、仮想マシン何それな方なら16コアもいらなく4コアで十分で、Tiger LakeならデスクトップCPUとしても良い気がするのですが、なぜかモバイル利用になっているところが『どうしたIntel』と言わずにはいられないです。まぁ2年前にこのCPUが出ていたら断トツの性能を誇れたかと思うのですが10nmプロセスの躓きが尾を引いたようです。
12月 CPU切替機を変える
地味なところの変化ですが、CPU切り替え機を変えました。今まではVGA,PS/2だったものが、HDMI,USB TYPE-Cになりました。どちらも4台まで接続でしたが、新しいものは小さくなりディスプレイの下に置けるようになりました。前の切り替え機は18年使っていたものでこちらを退役させたのはさみしいものがあります。まぁ掃除がしやすくなったので良しとします。
12月 RYZEN9 5950XでPCを組む
とまぁ、Tiger Lakeでいいじゃんと言いながらしっかりとZEN3のRYZENも購入したわけですが、たまたまPCショップを覗いたときに売っていたのを衝動買いしました。
3950Xの方はWindows Server 2019のマシンとしてテスト環境とし、5950X（16コア ベース3.4GHz ブースト4.9GHz）をWindows 10のクライアントとしました。
パフォーマンスですが下馬評どおりあくまでも体感＋ADPの整数演算上ですが、RYZEN9 3950Xよりも2割増し程度の性能を見せました。実際にはベンチマークテストで、3950Xが7秒台だったものが、5950Xで5秒台になりました。さらにWindowsの動作も早くなったような気がしています。
変えたのはCPUとマザーボードだけですが、BIOSのアップデートもあり、どうもX570のシステム自体がこなれてきたようです。3950Xは買ったときは10万円しましたが今では6万円を切るところまで値崩れしました。残念ではありますがある意味納得です。
ちなみにAMD uProfが12月31日現在もRYZEN9 5950Xに対応していないです。このツールあまり使っている人がいないのでしょうか？やっぱり使うなら古いCPUの方がよいか？
その他、Webカメラを買ったり、マイクをかったりGoProを買ったりと会議関係のものは大分買いました。
そんなこんなで来年は良い年になるといいですね。
前回の記事ですが、読者の方から洗脳を解くには弱いという指摘を受けたのでちょっと補足を考えてみました。実際にオブジェクト指向に洗脳されている方には何をいっても聞かないのですが、そもそも論として、なんでこんな記事を書くのか？ということを説明しましょう。
一般的な話になりますが、エンジニアの中には原理主義者よろしく自身の考えを曲げない人が確かにいます。その人の世界で頑張ってもらえればよいのですが原理主義者の中には妥協という言葉をしらないのか、他人のコードや考え方に口出しをする方もいらっしゃいます。たとえば『手続型はダメ。オブジェクト指向はよい』とかですね。彼・彼女が完成されたエンジニアなら口出しも立派なアドバイスとして成立するでしょうが、ある意味究極のセオリーだと私が考えるのは『コードに正解はない』ということです。あるとすれば『こちらの方がより適切かもしれない』ということと『動くコードはやっぱり最強』ということです。あるエンジニアに、その昔私が書いたコードをありがたく手術と称してリファクタリングしてもらいましたがテストをすると重要なエラーチェックが抜けていることに気づきました。質問すると「まだ書いていない」という返事をもらいました。つまりこういうことです。エラーチェックのコードは時として見栄えが悪くなります。まぁ通常処理に加えて異常系の処理を加える関係上仕方がないでしょう。そういうコードから異常系の処理を取り払えば確かに見栄えはよくなります。さて、見栄えは良いが重要な処理が抜けているコードと見栄えは悪いがきちんと処理が入っているコード、あなたはどちらを評価するでしょうか？見栄えを取るという人は将来失業しないように気を付けましょう。
オブジェクト指向に心酔するのは構わないのですが、結論から言いますと残念ながらオブジェクト指向技術は思ったほど役には立ちません。詳しくは連載を通して理解してもらえればよいのですが、非常に残念なことにオブジェクト指向に過剰に心酔する人がいるのも事実です。例えば、この記事です。
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて
経験のあるエンジニアならこの記事が眉唾だと理解できるのですが経験の浅いエンジニアなら真に受けてしまうでしょう。少し技術的な点を突っ込んでおきます。記事中
アセンブリやCOBOLのような言語では、オブジェクト指向言語で一般的なカプセル化という考え方がきわめて弱いということがあります。変数は静的なグローバル変数が中心であり、
とありますが、アセンブリ言語でもローカル変数はあります。またいわゆるメンバ変数もシミュレートできます。もし仮にアセンブリでローカル変数がなかったりメンバ変数をシミュレートできないとすればJavaやC++のコードはどうやって実行されると考えているのでしょうか？OSはどんなふうに記述されていると考えているのでしょうか？JavaやC++はコンパイラを通して一旦機械語に変換されます。アセンブリとはその機械語に一対一に対応します。また、そもそも論としてアセンブリとCOBOLを同じテーブルに並べるところにもの凄い違和感を感じます。もしあなたが違和感を感じられないのならオブジェクト指向を勉強する前に他に勉強することがあるということになります。
さてこの方の約3年後の他の記事を見てみましょう。
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例
引用しますと、
最後に、最近になって気づいた自分の間違えについて書いておかなくてはなりませんね。以前であればこうした設計上の問題は日本のSI業界の構造が問題なのであるという話をしていたかもしれません(^_^;)が、ここで書いたような話は多少フィクションが入っているとはいえ、実際私がSI業界以外の今の会社で体験したことに基づいていると告白しなくてはなりません。言語の特性から、Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますが、こういった話はSIer以外でも、どこの国の開発チームでもあるのだなということですね。
この中にある
Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もあります
この感覚は実はオブジェクト指向症候群から脱する第一歩になります。多くの生き残っているエンジニアは大なり小なりこういう感覚を端緒とし、次に”Javaはダメだ○○は良い”となり、最後には”オブジェクト指向がダメなんだ”となります。もちろんですが私も20年程前にこういう感覚に襲われたことがあります。
まとめますと、オブジェクト指向症候群にかかると間違った知識をまき散らします。さらに病気から抜け出すと後でそれを修正しなければならないという二度手間が発生するわけです。できれば早く抜け出した方が本人の為でもありますし業界のためでもあります。
と長くなったのと月末でいろいろ忙しいので、今週はこれにて終了です。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。
私の盟友（？）こと
みながわさんの日記が更新されたので覗いてみた。2016年1月29日の記事によると、とあるWEBの記事
「staticおじさん」はなぜ自信満々なのかというのが目につく。
この手の記事に対しての警鐘は以前にも行ったのだが、未だにこういう煽り記事が出てくるということは出版業界はよっぽど不景気なのか？と邪推したくなる。
アメリカに留学して習った単語にobjectiveというのがあり日本語訳は客観的で、反対語はsubjective（主観的）になります。論文を書くときは客観的であれといわれます。といっても何が主観で何が客観か分からないでしょう。本当かウソか分かりませんがアメリカではこのobjectiveということを子供の頃から教わるらしいです。もっとも子供の頃にそんなことを習ったことのない日本人は文章を読むときに、何が主観的か客観的かが判断がつかないこともあるでしょう。ちなみに何の説明もなしに『普通はこうだ』とか、他にも記事を読んで『俺の意見を代弁していてくれる』と思ったら、その記事は主観的である可能性があります（主観的の定義に従えば自明ですよね）。
さて、元の記事にあるこの部分
Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。
これは、
インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり
と読み取れます。思わず普通ってなんやねん？と突っ込みたくなるのですが、
そろそろこのインスタンスメソッドを使うのが普通という誤謬を解きたいのですが、staticメソッドは場合によっては推奨されています。
期待するコードを期待するように書こうという本から引用させていただくと
クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ
このReadable codeという本は私は英語版を購入したのですがそこでも同様のことが書かれています。
また、英語が読める人は、static methodで検索をかければいろいろ議論を見ることができます。たとえば以下のQAたち
https://www.quora.com/Why-is-using-statics-Static-method-block-variable-in-Java-programming-bad-programming
http://programmers.stackexchange.com/questions/98083/cant-i-just-use-all-static-methods
ここでは、インスタンスメソッドを使うのが普通とか訳のわからん理由ではなくきちんと事実に則って議論がされています。
事実（fact)に則って議論するということは客観的(objective)な議論ができているということになるでしょう。
ざっくりとまとめますと、staticメソッドを使うと
欠点：継承ができなくなる。ポリモーフィズムも使えなくなる。
利点：メンバー変数へのアクセスを制限できる。パフォーマンスが上がる。
ということです。他のものは自明として、利点のところで『パフォーマンスが上がる』かは検証の必要があるのですが、ポリモーフィズムはオーバヘッドを発生させるのでそれを使わなければパフォーマンスがあがる可能性はあります。
また欠点の中で、『ややこしくなる』という意見もあったのですが、これは主観的な意見でしょう。たとえばstaticメソッドを使いなれた人はむしろすっきりとすると考るかもしれません。
さて、継承もポリモーフィズムも使わないということであれば、staticメソッドを使ってもよいということになるのですが、この反論として、『オブジェクト指向でなくなる』というのがあります。もはや手段と目的が混同されているとしか言いようがない意見でいやはや疲れます。
まぁ一介の無名なエンジニアが何をいっても仕方がないのでもっと説得力のある例を出しましょう。
επιστημη さんという著名なライターさんがいらっしゃいますが、彼は思い切りstatic メソッドを使っておられます。
http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx
のコードのrefereeクラスがそれに当たります。refereeクラスには3つのメソッドがありますが、すべてstaticメソッドになっています。
つまり、事実としてstaticメソッドは使うときは使うのです。ちなみにもちろんですが、επιστημη さんがオブジェクト指向を理解していないということはないでしょう。
という訳で、
ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。
というヒマがあったら自身が思わぬ誤謬をしていないか記事の検証を行うことを勧めます。
2/4追記
コメント欄で文意を汲み取っていないという指摘を受けましたが、まぁ充分文意を汲み取って反論をしているのですがどうも分かりづらいかもしれないので、補足します。
ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。
こういう教示的な文章は一見ごもっとなことのように受け取れますが、冷静に読めば分かりますとおり、ど素人でも同様のアドバイスができるでしょう（例を出すとサッカーや野球観戦をしているおっさんが野次っているさまと同じと言えば納得できるでしょうか？）。
社会人としては自分を律したり反省することは歳をとろうが若かろうが、技術者であろうがなかろうが、常に必要でいちいちアマチュアに指摘されることではないです。
そうはいっても100歩譲って、プログラミングに携わるプロが
『（引用先の記事に書かれてるニュアンスでの）自分はstaticおじさんではないか？』
と自問するということはどういうことでしょうか？
つまり、『staticは使えるのか？使えないのか？』という正に私がここで行っている議論をすることです。
そしてまさに
インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり
こういう意見が20年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。