とあるソフトウェアエンジニアのブログ

今年は本当に色々ありました。

仕事面ですが、ここ数年ガイドの仕事をしていたのですが、コロナ禍でガイドの仕事がなくなりました。
一方で、とある団体の理事になり、その関係でヒマも手伝い久しぶりにシステム開発を請け負いました。
もっとも理事になったことはまったくの黒歴史になり、年明け早々に辞めるので、ここに厄落としに書いて終わりにします。

コロナ禍で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年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。

去年あたりから忙しくなり、我が人生で4回目の炎上プロジェクトを絶賛体験中のところですっかり更新がご無沙汰になりましたが、少し余裕が出てきたところへ考えさせられるニュースが入ってきたので書いてみます。ちなみに、こういうニュースを聞くたびに、日本は衰退に向かっている、と感じてしまします。がそれは私だけでしょうか？

STAP細胞のニュースについて、経緯をざっくり説明しますと、iPS細胞に似た性質を持つSTAP細胞（STAP幹細胞）を理化学研究所の小保方氏らが作成に成功したと科学雑誌ネーチャーに１月３０日に発表したのですが、その後、相次いで論文に対して疑義が出され理研が調査を行うことになりましたが、その後も色々な疑惑が出てきて、共同研究者の若山教授が撤回を呼びかけ、昨日（３月１４日）に理化学研究所が中間報告を行いました。

同時に会見もありまして、その内容の一部が以下から見られます。

ＳＴＡＰ細胞:会見（１）「論文の作成の過程に重大な過誤」野依理事長
ＳＴＡＰ細胞:会見（２）「論文としてもはや存在すべきではない」竹市センター長

『論文の取り下げを視野に入れて検討する』というらしいですが、どこかのブログとは違って、論文の取り下げというのは研究を白紙にするということで大変不名誉なことで、それだけのことが論文の執筆過程で行われたということのようです。
まだ中間発表なので『STAP細胞は存在するのか？』とか『論文は捏造なのか？』といったことは今後の調査を待つことになりますが、インタビューで気になったのは責任者が他人事と受け取れるような発言をしたことにあります。

ＳＴＡＰ論文:「切り張りダメとは…」小保方さん謝罪によりますと、事件に対して

『似たようなことが起こっているのであれば、時代のなせる業、カルチャーが変わったなと非常に心配している』

と発言されたのですが、仮にもマネジメント側の人間の発言としては、疑問を持たざるを得ないです。
世の中、信じられないことをする人は昔からいます。私の半径３メール以内の経験では、約１５年ほど前になりますが当時の上司が顧客とのミーティング中に居眠りをしてました。
当時プロジェクトリーダーであった私はそれが理解不能で上司の足を蹴って起こし、ミーティングが終わってから叱責し、その後、続けて居眠りしたので、上の上司に話してプロジェクトから追い出しました。
もちろん、ここまでする必要はないかもしれませんが、人の上に立つ者としてはカルチャーのせいにしないで、きちんと対応をとるべきでしょう。というかこのような事態になった時点で『教育を徹底する』とかではなくまずはご自身の監督不行き届きを反省すべきだと思ってしまいます。そんなことだから、こういった声に耳を貸せないのか？と疑問に思ってしまいます。
実は、STAP細胞は存在しないと主張されている人が理研内部にいらっしゃるようです。ブログによるときちんと報告したにも関わらず政治的な力によりもみ消されたようです。もちろん私は専門家ではないので真偽を判断することはできませんが、理研にはこのブログの真偽に対してコメントしてほしいものです。

とかなり息巻いてコメントしましたが、まぁ歳をとると人は丸くなっていくもので、私の半径３メールの経験では、私自身が今となっては客先で居眠りしている人をみたとしても何とも思わなくなり、せいぜい飲み会のネタにするぐらいとなってしまったので、あまり人のことは言えないかもしれません。もっとも『居眠りできて天国です。』とか言われるとプロジェクトから追い出すかもしれません。

いずれにしても人の上に立つ人はきちんと人を見る目を養わないとダメということを思い知らされた事件です。

さらにネタがなくなってきたのですが、以前撮った写真から

みみですが、餌をねだる時の目力が半端ないです。


食べ過ぎなのでダイエットをしないとダメなのですが、粘ること１０分、結局おかわりにありつけました。


ちなみに、間違えてフラッシュをたいてこんなんがとれました。目力強し！