  |
はてなキーワード: Visual Studioとは
・ おひとり様
・ Visual StudioこみゅにてぃやIntelliJ IDEAこみゅにてぃやAndroid Studioで、C#/UnityアプリやKotlinアプリやAndroidアプリを作ってあそびたい
・ Gitは入れて動かして出すくらいならできる
・ Gogs（https://gogs.io/）は使ってたんだけど、他にないかなーと思って
知り合いと飲んだら、過去の私と同じような状況であの日々を思い出して吐き出したくなった。
当時私が参加していたチーム・プロジェクトは美味しそうなFWを使っていた。
サーバサイドのエンジニアは片手ほどの人数で、採用時点でそのFWの経験があることを確認されていたし、別チームから転属してきたメンバーも何らかのMVCでWSGIなFW経験があり、わりとサクッと順応していた。
前職では業界未経験だったり、経歴を盛っていると思われるエンジニアもどきと仕事していたので、普通に公式ドキュメントを読み、FWのソースコードを確認することができる同僚との仕事はおもりがなくなったようで気楽だった。
3年前の夏、サーバサイドのチームに新人のN氏が加入した。新人と言っても別チームから来た年上の業界経験豊富なインフラエンジニアである。
別プロジェクトのクラウド化や縮小が当時の1年半ほど前から進んでいて、社内のインフラエンジニアはSREに名前を変えるような流れがあった。（実際にはインフラ、ミドルウェア、ネットワークに長けた彼らは相変わらずそれなりに仕事があったようだが）
その流れの中でN氏は、サーバサイドエンジニアをしてみようと決めたらしい。転向については1年前から部長に相談していたとのことだった。しかも、うちのチーム名指しで。これはちょっと嬉しかった。
さっそく、N氏には社内向けの新機能を担当してもらい、私がレビュー担当になった。
これがなんというか読むのが辛かった。確実に言えるのはチュートリアル絶対やってないということだった。
機能は満たすが、FWの書き方やお作法については部分的にググった結果がパッチワークされているような。
社内の各チームのアーキテクチャはエンジニアならだれでも知っていた、つまりN氏は知っていながら特に準備なしでやってきたわけである。
そこから始まる、レビューを通した実プロダクトを使ったチュートリアル。褒めるとこは褒めて、受け入れられないところは参考になる実装やドキュメントを提供する。
はじめからチュートリアルを一緒にこなした方が良かった。レビューで大幅に書き換えてもらうのは結構辛い。勿論プロダクトに使えるレベルのコードじゃないから仕方ないんだけど。
しかもN氏、臭いのである。脂汗を吸った服、毎日履いてくるジーパン、脱いだのが瞬時にわかるほど臭う靴。
当時は Visual Studio Live Share なんて無いし、ペアプロは5分で限界だった。
がっつり書き直しが入るようなコードの卒業には2ヶ月ほどかかった。(これは私が時間を十分にとれなかったのも悪かったし、N氏は前のチームの引継ぎ作業も並行していたので)
もう、色々思い出して悲しくなったから書いとくと
ちなみに知り合いのところは、最近の天気のせいなのか生乾き臭マックスの縁故入社の新人とのことで、当時彼にしてもらったように「ガンバ」と背中叩いておいた。
N氏は今も臭っているようだが今は別プロジェクトだ。スキルセットが増えている分、頼れるエンジニアに近づいたのかな。喉元過ぎればなんとやらで、忘れていた。
最近は私が別チームからの支援できた若手のフロントエンドエンジニアにレビューしてもらっている。
チュートリアルこなして、書籍や記事を読んで手を動かしたうえで相談をしながら実装を進めている。あんまりなものは見せられない。
人に教えておらうにも、ある程度は自分で勉強しないと適切な質問が出来ない。
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
なんか、Visual Studioが自動生成するコードじゃ
面白くないよね
PeekMsgじゃなくて
MsgWaitを使った タイマー有りのマルチパンプとキー入力
ぐらいまで やればいいよね？
横４ 縦 １０ぐらいのテトリスっぽいなにか？
を めざせばいいのか？
たぶん 途中で挫折するけど
クリスマスプレゼントの続き
とりあえず、Visual Studioが作ってくれるテンプレ
// // 関数: MyRegisterClass() // // 目的: ウィンドウ クラスを登録します。 // ATOM MyRegisterClass(HINSTANCE hInstance) { WNDCLASSEXW wcex; wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS_HREDRAW | CS_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbClsExtra = 0; wcex.cbWndExtra = 0; wcex.hInstance = hInstance; wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINDOWSPROJECT7)); wcex.hCursor = LoadCursor(nullptr, IDC_ARROW); wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); wcex.lpszMenuName = MAKEINTRESOURCEW(IDC_WINDOWSPROJECT7); wcex.lpszClassName = szWindowClass; wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL)); return RegisterClassExW(&wcex); }
https://visualstudio.microsoft.com/ja/
printf("Hello world\n");
よく知られているやつ
// ConsoleApplication2.cpp // int main() { for (int i = 0; i < 8; i++) { printf("Hello 47\n"); } getchar(); return 0; }
<は＜の半角
実行結果
Hello 47 Hello 47 Hello 47 Hello 47 Hello 47 Hello 47 Hello 47 Hello 47
１年と３ヶ月前の父の日に、高校生の娘とカービィオーケストラを観に行くという幸運（https://anond.hatelabo.jp/20170619135108）に一生の運気を使い切ってしまったように思われた私こと娘の親父の内緒日記である。
昨年、カービィ生誕25周年の特別企画で開催されるに至ったと思われるカービィオーケストラだが、それも過ぎてしまい次の節目は30周年だろう。30周年と言えば2022年4月27日であり、すっかり娘は成人してしまっているので、さすがに親父と出かけるなんてことにはならないに決まってる。
もはやここまでか、と物寂しい思いにふけっていた私に朗報が舞い込んだ。東京限定であるものの「カービィカフェ」なる飲食イベントが開催されるとのことだ。もちろんこの情報は娘が先に察知していたのだが、なるべく全種類を食べたいものの、メニューの種類が半端なく、一回でのコンプリートは望むべくもない、というのが娘の抱いた率直な印象のよう。
かつ、この手のイベントの料理は、それがサイゼリアだったら399円で供していたであろうパスタに対し、ちょっとしたピンクい小物を添えるだけで1500円に化けてしまうという、例えればプラレーラーがＮゲージに片足を突っ込んだときに抱く感情と同質のものとも言え、つまり端的に言えば胃袋の空き容量に比例して財力も必要なイベントなのである。
カービィオーケストラの争奪戦を経験しているので、事は理解した。連れて行ってやるから面倒な手続きをクリアしたうえで軍資金を手配せよって意味だ。
学校の友だちは、こぞって iPhone であるところ、同じものを欲しいとは言わないで、通話用の F801i に加えて 15000円弱の中華製のシムフリーな泥タブという二台持ち体制に満足してくれ、その泥タブに使う通信用シムだって、友だちらはキャリア謹製シムで「ギガが足りない」って声を揃えているところ、「メガが足りない」と愚痴をこぼしつつも殆ど 0sim の無料枠で賄ってくれているので、突発的なイベントに限って少々財布の紐を緩めるくらいは親として受忍すべきと認識している。
「分かった。。。」
9月21日は17時50分からパソコンの前に張り付き、18時と同時にひたすら F5 を連打しまくる任務に従事するのだが、予約サイト側は Cloudflare を導入してるぽい割には全く繋がらない。チケピの客の９割がボットという話を聞いたことあるが、きっとボット達が動いてるに違いない・・・娘の誕生月は10月なので、10月分の予約争奪戦には決して負けるわけにはいかないのだ。
とっさに Visual Studio を起動させ、新しいプロジェクト → Windows フォームプロジェクト（C#）を選択した。
デフォルトで用意された Form1.cs に WebBrowser コントロールを貼り付けて、DocumentCompleted をフックし、WebBrowser にエラーぽいメッセージ（門前払い）が出力された時に Navigate し直すコードを書いた。たぶん10分かからず書けたと思うが、アプリはエラーなく直ちに起動した。
突貫で作った割にはそのアプリは非常に効率よく、おおよそ2～3分で門前払いを突破したのだが、「上記の内容を確認しました」にチェックを打って「予約する」のボタンを押しても反応がないではないか。相手（サイト側）がきっと（少なくとも） UserAgent を見て WebBrowser コントロール であることを識別しているに違いない。
UserAgent を偽装するコードを書く暇もないので、FireFox で F5 を連打する作業に戻った次第だが、平均2秒に１回は押していたと思うので、1分間に30回、つまりは計500～600回は押したであろう暁にようやく「予約する」のボタンが出現する画面に遭遇できた。門前払いを突破できたら後はスムーズで、人数「2人」と娘が指定した平日の日付を指定した。スカイツリーから都心の”カタワレどき”を眺めて下りてきてちょうどいい時間帯をチョイスし、無事に予約成立。
9月21日午後6時50分、私は無事にカービィカフェ10月分の予約争奪戦を制したのだ。
※当初は嫁の予定も考慮したのだが、どうにも合わない上に「勝手に行ってきたら？」だったことを書き添えておく
カービィオーケストラ・大阪へは距離が近いこともあって日帰りで行ったのだけど今回は華の大東京である。前日が日曜日なので無理に日帰りに拘る必要もない。娘に聞けば、土曜日は部活があるが日曜日は用事がないとのことだったので「せっかくなので前泊して観光しようか」と打診してみる。
この際、嫁の許可なんてものはどうだっていい。娘が行きたいと言えば、それが総てなのだ。
みなとみらい、山下公園、中華街、そんなアーバンな地帯へは嫁と行ったことがあるが、それが結婚前だったのか結婚後だったのか、更にはどこを回ったのか、昔のことすぎて全く記憶にないので、横浜は娘のみならず私にとっても新鮮であるに違いない。
休前日はどこも予約で一杯だったが日曜の夜は空いていて、中華街に程近いロケーションでツインを取れた。
あとは、20年ぶりくらいに横浜のガイドマップを調べてコースを選定するのみ。当時はガイドブックだったが、今はインターネットがある。
媒体が変わって、ページを開くかわりにマウスをクリックするような時代にはなったけれど、ワクワク・ドキドキした感覚は20年前と何ら変わっていない。
藤子不二雄はあまり好きじゃないようだから、川崎のミュージアムは喜ばないよな
八景島までなら何とかなるかな。
夜は中華だよな、だけどボッタが多いって聞くし、よくよく調べないと
プログラミングってこれからの時代必要っぽいし、なんとなくイケてるスキルっぽい。
ゲームとかアプリとか作ってストアで公開とかしたら就職とか転職にめっちゃ有利じゃね？
俺はこういうのが出発点で良いと思う。
でもプログラミングを始めようとすると「何がやりたいの？」と聞かれてソッコー詰まる。
俺は「何をやればいいの？」って思って調べてるつもりなのに「何がやりたいの？」って突き放される。
ここで混乱して立ち止まってしまう。
でも一呼吸おいて、初心者とそれ以外の間に生じる認識の祖語について１つずつ解消しなければ先に進めない。
俺はプログラミングを覚えるということは、何でもできるようになることだと思っている。
でも先人たちはそのようなスキルをすぐに教えてくれない。それどころか「何をやりたいの？」と言って、他につぶしの利かない小さな範囲の知識を与えようとしているように見える。
「アプリ作りたい」と言えば、どんなアプリ？という問いが続くし、特定の具体的なアプリしか作れないような知識しかもらえないだろう。
どういうことか？
試しに「何でも作れるようになりたい」と言ってみると「じゃあC言語やろうぜ」とか言われる。
C？いまさらCで何作れるんだよ。AndoroidアプリはJavaじゃないの？C関係ないでしょ！？Cでスマホアプリもウェブサイトも作れないじゃん！何言ってんの！？
ち・が・う！何でも作れるようになりたいの！あんたみたいに！Visual Studioだろうとgccだろうと、cとかc++とかc#とかjavaとかpythonとかrubyとかphpとかテンサーフローとかhtmlとかjavascriptとかjqueryとかgoとか駆使してたくさんウェブサービスとかアプリとか作りまくってるあんたみたいに！
「じゃあ今挙げたやつ全部やれよ。ちなみに今の俺は１０年以上プログラミング勉強してるから。１０年後今の俺になったところで、俺はさらに１０年積んでるからな。一生追い付かんな」
「じゃあ今、あるいはこれから使えるものを重点的にやっていくしかないな。で、何がやりたいの？」
何がやりたいのってどういうこと？むしろ何ができるの？
「アプリ作るとか」
「どんなアプリ作るの？」
…………どんなアプリ作れるの？
「ストアにあるようなやつ」
じゃあFGOみたいな……
「お前には無理だからｗ」
はぁっ！？ストアにあるようなやつって言ったじゃん！
そこでまた数回やりとりが発生して、プログラムを書くコストとかスキルの問題について再確認することとなり、
現実的に俺個人が支払えるコストの範囲で、何を作れるようなスキルを取捨選択するかという問題になり、
結局は教科書のサンプルをちまちま作っていくしかないのではないかというつまらない結論が脳裏に浮かぶし、
その道筋でさえ結局何年も積む必要があり、そのころには別の言語とか開発環境が主流になってるかも……
「そこだよそこ」
えっ？
「まずさ、日本語の教科書を読むには日本語が必要じゃん？それでも国語辞典とかwikipedia調べながら知らない単語や概念は別途補てんする必要がある」
う、うん。
「プログラミングの教科書とか風潮を読むにはプログラミングの基礎が必要。それに加えて、作りたいものに合わせて新規に開発環境なり言語なりを学習することになる。だから何でも作れるようになりたけりゃ、この世の全てを体得する必要があるけど無理だろそんなの」
え、えー
「でもいくつもの開発環境、言語を使って、ソフトウェアをいくつも実際に作ってると、基礎的な引き出しは大きくなるし、追加で新しい環境とかを学習する要領もつかめてくる。何年も積み重ねがあるとなおさらね。するとより少ない労力で新しい技術に追従できるし、新しい開発環境やアプリの分野でもサクサク作ってるように見える。それが、お前の言うところの『何でも作れる』ように見えるものの正体さ」
なんか夢から覚めた気分。
「FGOを作りたいなら、FGOをかみ砕いて、自分ならどういうアレンジでそれっぽいものを作れるか考えて、その過程で自分の能力とか限界を見極めていく必要がある。でもそれは結果論であって、最初は作りたいものをひたすら作ってみるしかない」
ふーん
「何度も聞くけど、何が作りたいの？FGOならFGOでいいよ。やってみろよ」
どうしよっかな……（頭を抱える）
の増田です
2年以上かかりましたがなんとか完成しそうです
本当はAccessまたはVisual Studioで書けたらよかったのですが誰も経験者はいないし外注はできないので
フォームのファイルは共有サーバー上に上に起き全員が同一ファイルを使用
帳票及び得意先（1000件）商品（1万件）資材（1万件）DBは、フォームのあるファイルに格納する（別ファイル起動/終了時間削減のため同一ファイルに格納）
受注（8万件、1万件/年ペースで増加）
資材入出庫履歴（40万件）
完成間近だけどExcelは同時使用に弱いらしいのでファイルがぶっ壊れることを考えると胃が痛い
追記
