  |
はてなキーワード: アーキテクチャとは
楽しいのは描画系とか、操作とか、シューティングだと色んな装備実装したりとか、そういうのは楽しい
敵の行動あたりから雲行きが怪しくなる
要はパックマンとかスーパーマリオの延長線がなんだかんだ多いのではないか
シューティングなんか、同じ動作パターンの繰り返しであり、それが幾重にも積み重なる、
例えば、同じ画面内に様々な敵が登場するが、それぞれの敵の行動パターンは非常に単純であるが、
それがミックスされたり、自機に向かってどんな感じで弾を撃つとか、自機と無関係にレーザーを放つとか、
結局は凝ったイライラ棒みたいなもんで、意外性がないというか面白くない
敵が、生きてるのではないか？と思うぐらいちゃんと考えてるように見せるというのは難しい
例えば監視の兵士がいるとして、兵士は巡回ルートを回りつつ、ときどき他の監視員とだべって、
しかし、プレイヤーが誰かに見つかると半数がプレイヤーの位置に急行する、
みたいなことをいちいち裏で計算してしまうと破綻してしまうし、
といっても、近接戦闘になって、目の前の敵が2Dシューティングのような動作をされても非常に機械的というか、
まあ、それでも初代doomみたいなのでも面白いっちゃあ面白いんだけど、
敵が単純動作するという前提があって、それで敵を利用したり、ロードランナーみたいなところがある
でも、今の時代にちょっとしたニューラルネットとか使わないとつまらん気もするんだよなぁ
その落とし所というか、どうやったら面白くなるのか、が未だに分からない
そう、ゲームみたいなものを作るのは誰でもできるんだけど、どうやったら面白くなるのか、を実現するのは非常に難しい
レトロゲーでも、最初考えたルールを実装したが面白くないのでルールを足した、
ルールを足したが矛盾が生じたので、最初のルールの一部を削った、みたいな試行錯誤が見えることがある
その結果としてできたゲームは面白い、ちゃんと新しいルールが成立している
特にレトロゲーは、ゲーム＝新しいルールの発明、みたいなところがあった
最近はそういう感じではなく、FPSならFPSを突き詰めていく方向になっている気がする
面白ければなんでもいいということでもある
ゲームを作るのは楽しいが、完成させるまでは非常に苦痛だ、困難な茨の道だ
一方でプロゲーマーとかゲーム実況というのは、他人の作った手の上で踊るだけではあるが、
昨今の世の中は、そういういかに楽な立場でカネを得るかという方向に向かってるので、
何が言いたいのか分からなくなってきたが、
まあ、プログラムなんて書かない方がいいと思うんだよね
それよりもプロゲーマー教育とかYouTuber教育の方が、特にDQNヤンキー系の親の子供とかは喜ぶと思うし、
やっぱり人生は勝ち負けだし競争だし、端的に一言で言うならカネだと思うので、
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。
石光直樹，リクルート（2021 年 06 月 04 日）
28 →目次に戻る
ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま
す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め
て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向
けて情報を発信していきました。
今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整
えていきたいと考えています。
マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ
て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC
管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。
「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従
来よりもセキュリティを強固にすることにして、この課題をクリアしました。
続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え
ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT
PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム
を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC
管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな
り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を
目指すために、優先度を下げた部分といえます。
そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で
きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い
ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは
VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社
外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、
ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて
いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま
した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい
たのです。
29 →目次に戻る
しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ
社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと
で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって
しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が
難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に
なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて
きています。おそらく、われわれの目指す「クラウド＆マルチデバイス環境」を支えるネットワークは「ゼロトラス
トネットワーク」になることでしょう。
では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に
して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。
コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。
いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来
的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。
変化に対応して、かつ自ら変化を引き起こす
さらに、FAT PC 導入においては大きな変化があります。それは「SAC」（Semi-Annual Channel、半期チャ
ネル）の導入です。
VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」（Long Term Servicing Branch※）
を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ
デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。
※現在の名称は、「LTSC」（Long Term Servicing Channel、長期サービスチャネル）
これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機
能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続
も制限されるような状況でした。
30 →目次に戻る
他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー
スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必
要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から
FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に
しました。
今後の「クラウド＆マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま
のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな
るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ
れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても
らえるようになればすてきだなと思いました。
そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB（LTSC）から SAC に変更すること
にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても
変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。
VDI 基盤の抜本的な刷新
ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と
特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。
VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず
検討したのはクラウドの導入です。将来「クラウド＆マルチデバイス環境」になれば、VDI 自体もクラウドのサー
ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。
しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて
コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます
発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には
クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。
当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような
ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。
31 →目次に戻る
議論、検討を重ね、さらに比較、検討した上で、われわれは HCI（Hyper Converged Infrastructure）構成
を選びました。HCI はサーバ中心のアーキテクチャで、SAN（Storage Area Network）スイッチやストレージ
を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する
だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。
いままでは「サーバ＋ネットワーク＋ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを
変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ
ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。
加えて、VDI 基盤のデータセンターのネットワークを SDN（Software Defined Network）に切り替える決断
もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また
(ゲームの話は一切知らん)
いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。
端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。
k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねーな、と思う。
wasm+エッジコンピューティングの進化でまたもっと全然新しいアーキテクチャが出てくるんだろうか。ぼくは今のところあんまりそんな気もしてなこないんですがどうでしょうか。結局そこでチマチマやって得られるユーザー体験の向上の果実って小さくねえか。とはいいつつ Cloudflare Workers でなんかできないかと遊ぶ日々なのだが。
目的によるんじゃないの？
壊れた自動車を直したり、新しい自動車を作ったりするには自動車の仕組みを理解しないといけないけれど、ただ乗るだけなら別に中の仕組みなんて知らないでも乗れるでしょ？
ツールを単に使うだけなら、別にツールの中身なんて知る必要はない。便利な使い方さえ知っておけばいい。
ツールを直したり、新しいツールを作ったりしたいと思ったら、どうやってツールが作られているか理解しないといけないから、コンピュータサイエンスが必要になってくる。
まあ、コンピュータサイエンスとざっくり言ってもいろいろ含まれるよね。
自分が学生時代に習ったもので記憶に残っているのだと、アルゴリズムとデータ構造、プログラミング言語処理系、オペレーティングシステム、コンピュータアーキテクチャ、ネットワーク、分散システム、符号理論...くらいかなぁ。
今時はマシンラーニングやソフトウェア開発手法なんかも学ぶのかもしれない。
嘘を書きすぎ。
ちなみに両方使ってるユーザーです。Pixel 5 もiPhone 13 Pro Max もXiaomiも。
コスト…iPhoneは9万でXiaomiは3万円。話にならない。
→ 自分自身の説明にも書いてますが、スペック同等だとAndroidも価格そこまで変わらない(厳密にCPUアーキテクチャ違うので評価しにくいが)
→ それは「カメラの性能」であって、「中のイメージセンサ」や「画像の変換技術」部分が違いすぎる。
→ と言いながら、別に私はiPhoneのカメラ性能は全然どっちでも良い。スペック良すぎとも思う
→ 個人的にこれは嘘。同じぐらいの作業をしてると明らかに13Pro Maxのほうが持ちがいい
(PCとWatch連携させて、動画見て、バックグラウンドで地図系の情報掴んだりさせてる・・・という普段利用状況に合わせると。特にちょっと頑張らせるとAndroidは減る速度が大きい)
ディスプレイ…発色はほぼ同等だけどXiaomiのほうが大きく見やすい。
→ 絶対これもない。iPhone 13 Pro Maxのほうが見やすい。
→ でもじゃあそれに価格差がありますか？と言われるとこれだけではなんとも
コネクタ…Lightningは不便すぎて捨てたい。USB-Cでパソコンもタブレットもスマホもイヤホンも充電できる便利さを知ってしまうと、アップルはアホかと思う。
→ よくこれ言う人居るんだけど、もうすでに家にいっぱいコードあるからもうどっちでもいい。
→ むしろUSB-CだとPCの充電に使えるレベルの給電できるコードだったりPD対応してるかだったり、チェック項目むしろ多いよ。Lightningだったら確実なんだけど。
→ iPad Proも持ってるのでUSB-Cで充電速度がまちまちやなと思う感はある。まぁ不便ではないどっちでも良い。
指紋認証…Xiaomiあり、iPhone12はなし。これも信じられない。この時代、指紋認証はあったほうがいいに決まってるじゃないか。アップルはドケチなのか、ユーザーを舐めてるのか、実装する技術がないのだろう。
→ 指紋認証に価値を覚えない。顔のほうが早いし、Androidも顔にしてる。反応が悪かったり、濡れてると使えないとかあるのでマジで指紋じゃなくていい。
→ ちなみに顔認証もApple WatchとiPhoneあれば連携してるのでマスクしてようが解除しますよ・
アプリ内購入…Xiaomi…というかAndroidはみんな電子書籍も動画もアプリ内で買える。アップルはわざわざSafari立ち上げて検索し直して買うというバカみたいな手間がかかる。アップルが頑なにアプリ内購入に3割のマージンを要求するからだ。
→ これは事実。Amazon Kindleの本を買えないのはマジでクソ。いちいちブラウザなのだけマジで苦痛。これだけでも価値はある。
デザイン…好みだがガスコンロみたいなiPhoneのカメラのデザインはクソだと思う。そしてiPhoneは画面サイズの割に重たい。軽くする技術がないのだろう。
→ これも事実。iPhone 13 Pro Maxのカメラ出っ張りすぎ。
画面分割…画面分割でYoutubeの動画を表示させ下でLINEでチャットするとかAndroidは普通に出来るが、iPhoneは無理。マルチタスクの技術がないのだろう。
→ できるよ？YouTube側の対応もあってまだできないけど技術的にはもうできる。でも正直つかわん。動画見ながらチャットとかしたかったらPCとかタブレット使えば？
ちなみに、「ウィジェット機能」「フォルダ機能」とか別にどうでもいい。Androidのほうでも使わんしiPhoneの方も殆ど使っとらん。
それのもとがAndroidだから〜って言われて、じゃあAndroidって決める理由にもならん。どっちでも使えるならどっちでも良いってことでしょ。
だってAppleの端末のほうが問題起きにくいもん。初心者も使えるし。Androidだとイレギュラーなことが起きたりカスタム前提なので。
あと明らかにゲームアプリをやっててもiPhoneのほうが動きが快適。マジでAndroidのほうがおかしくなること多い。
だから「カスタムしたい」「何でもできるようにして欲しい」「安く買いたい」ならAndroidでいい。
私も2〜3台目の適当用スマホはAndroid。数万なら無くなっても痛くないし。
いまもjQueryをWebアプリケーションの大事なライブラリとして使っている会社は少なくないと思う。
jQueryを会社で使っていると何が問題なのかを語っていこう。独断と偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。
採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。
また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人が可哀想なだけで、現役なわけではない。ラガード（遅滞者）の仲間入りをさせているだけだ。新人でもキャリアをデザインできる新人は「jQueryはオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。
そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードをメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。（jQueryでアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQueryに依存しておらず、jQueryに依存していないのであれば簡単にjQueryから脱却できるはずで、簡単にjQueryから脱却できるならもう脱却しているはずだからだ）
メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます！」とにこやかに言うようなものだ。
（ただし、さすがにjQueryだけでフロントをやっているという会社の求人をほとんど見かけることはない。無意識のスクリーニングで落としているのかもしれない）
jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているか、たまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。
「jQueryを使っていました」というエンジニアは、他社からはフロントエンドスキルが0とみなされる。つまり、フロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ（逆はできる）
jQueryを書ける人口自体は増えているだろうが、労働市場からは撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。
私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。
jQueryで入社するのは、昔からjQueryを使っている高齢のエンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。
そのため、需要と供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。
リプレイスはハッキリ言って難しい。モダンなフロントエンドを学習するだけでは足りなくて、それを使いこなせた上でしかもjQueryを使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。
時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。
jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。
何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。
jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合、既存の従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。（もちろん、「jQueryしかなかったサービスをモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある）
ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ？」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体は価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態でリプレイスしようとするのは、生活困窮世帯にリボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。
jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。
jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代で通用しにくいものになっていく。
bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンなインフラエンジニア（もしくはモダンなインフラ知識のあるエンジニア）がいないかもしれない。SREという概念がないかもしれない。
世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。
すべては憶測なので、実際は違うかもしれない。
さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体はメンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。
問題は、jQueryというライブラリを使ってきた時代からアーキテクチャが前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryのバージョンに反比例する。
jQueryを使っているアプリケーションには、jQueryが担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベント、SPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLにベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数、無視される変数のスコープ、サポートが終わったライブラリ、ドキュメントを見つけるのすら困難なよくわからないライブラリ、高齢者しか知らない伝説の機能・伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。
そのため、一定の基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。
そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。
そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。
（そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ）
jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか？」という部分が気になるところだと思う。
そこで、後編では「どうやってjQueryを全廃すればいいのか？」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。
お楽しみに！
GPGPUアプリケーション開発の環境およびAPIとしては、ハードウェア内部構造自体が汎用性を増したDirectX 10世代の統合型シェーダーアーキテクチャGPUの登場以降、NVIDIAによるGPGPU専用の統合開発環境「CUDA」や、AMDによるGPGPU基盤「AMD Stream」（旧称ATI Stream）、そしてクロノス・グループによる標準規格「OpenCL」が現われ、GPGPU活用の幅が広がりつつある。 https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%8E%E3%82%B9%E3%83%BB%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか？違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
RubyやRailsでどう書くかを知っているか知っていないかだけでそれがプログラミング能力だと勘違いしてる人が多い。全員というわけではないが……
「このライブラリでこう書ける」とか「こういう書き方がある」とか「こっちに書くとここがこうなる」とか、そういった規約覚えゲー的なところに目を取られて、どれだけRuby on Rails関連の規約をたくさん覚えているかでプログラミングスキルが高いか低いかを考えてる人が多い。もちろんそうした覚えゲーもある種プログラミング能力の一部なのだが、一方でライブラリを単に入れただけでは実現不可能なパフォーマンスを考えたコードを書くときやアーキテクチャ設計の段階では、何年も経験しているはずなのに役立たずになる。
ググるのが面倒なシンタックスシュガーや、ライブラリを導入した人しか辿り着けないconfigなど、規約（笑）とかいう発見非可逆なルールによって、それを導入した人だけが知っていて既得権益を得られるような構造になっている。そのために、ある機能を新しく利用したときに、それを知らない人にRails知識マウントを取れるようになっている。この気持ち悪さは、例えるなら、刑法を全部読んでからじゃないと街を歩くだけで逮捕されて、しかも何の罪で逮捕されているのか教えてもらえないようなものだ。
それで、全員というわけではないが、そういったRailsしか書けないおじさんは別言語で書くときに平気で今までプログラミングしたことないかのようなレベルの最悪のクソコードを生み出してくる。そもそも他言語が書けないおじさんも多い。
なぜなら、Rails知識こそがプログラミングスキルだと考えていて、Rails知識すごいワールドでしか生きてないからだ。覚えゲーをやっていただけで、スキルとしてはポケモンの名前を覚えただけにすぎない。社内スキルのようなものだ。
自分としてはRubyやRailsが直ちに滅びるとは思っていないが、Railsをメインで使ってる会社からしても、こうしたRailsしか書けないおじさんは今後不要になってくると思う。
情報の一次ソースに当たることは昨今の情報社会において当然のことのように思うが、情報が氾濫している以上そうしなくても満足してしまうこともしばしば。
アプリケーション開発においても全くその通りで、QiitaやGitHubで拾ってきたサンプルコードがベストプラクティスと思い込んでしまう人がいる。
DDDだ、クリーンアーキテクチャーだ言い始める前に、エリック・エヴァンスやアンクルボブの本を手に取ろう。
そして会社やプロジェクトは情報の入手へ投資を惜しまないようにしよう。本を買おう。
組織委員会の話ね
https://mainichi.jp/articles/20210719/k00/00m/050/325000c
呪われてるってからには、組織委員会を呪う人がいるはずなんだけど、だれ？
②周期…麻生さんの説 1940年東京五輪と1980年のモスクワ五輪ボイコットを「40年ごとに問題が起きた、呪われたオリンピック」と発言 当たり過ぎて怖い
40年周期を1年ずらした程度では呪いから逃げられなかった（2年ずらしが正解？）
③ザハ・ハディッド…競技場コンペ案でお馴染み 呪う資格がある
インポッシブル・アーキテクチャー展 https://bijutsutecho.com/exhibitions/5030 で展示された競技場実施設計図集には、設計チームの巨大な情熱（もしくは呪い）がたしかに込められていた
ある事柄について、「わからない」人と「とてもわからない」と言っている人がいるとする。
Aの人にとっての「わからない」はこうだ。
これらは、僕、ひいてはB側からすると十分わかっている側なのだ。
対して、Bの人にとっての「（とても）わからない」はこうだ。
ひどいものだ。
でも初めてやることや慣れてないことに対してだとこうなる場合も多いのではないだろうか。
そういうときに、Aの人が予防線的に使う「わからない」という言葉で、Bの人の本当にわからない人たち側の「わからない」が埋もれていく。
これらは、Bの人が向き合っている現場で出せる最後のアラートなのだ。これが埋もれたり、出しづらくなっていくと、ただでさえわからない問題を抱えているのによりストレスが溜まる。
だから、A側の人は気軽に「わからない」と言わないでほしい。もしくは、僕たちB側の人のための「わからない」の一個下の理解度を指す言葉がほしい。
