いい感じに小汚いおっさんが美味しそうに食べてるものは本当に美味しい
でも汚いから広告効果はほとんどない
でも僕はそういう人を見るのが好きである．
悦びを得るためにものを食べることができる人間は，とても魅力的に見える．
就活を始めてから，僕は食欲が減退した．
白米の摂取量が6割ほど現象したし，ラーメンも1杯食べるのに苦労するようになった．
それでも身体は生きようと，僕に何かを摂取させるために腹を空かせて音を鳴らしてくる．
だから僕はお腹が減ってると考えて，何かを食べようとする．
でも食事があまり喉を通らない．
バターと醤油と出汁で味付けした焼きうどんは，僕の好みの料理だった．
沢山の野菜と豚肉に彩られたその皿は，最後は鰹節をまぶして完成する．
肉と醤油が少し焦げて，いい香りが僕の食欲をそそる．
でも，僕はその皿を平らげることができなかった．
美味しいのに，本当に美味しいのに，半分を食べた段階で残してしまった．
今の僕は自虐的な体質で，悦びを得ることに対して強い忌避感を持っているのだと思う．
楽しむこと，喜ぶことを恐れ，感情の起伏を抑え込もうとしているのだ．
だから悦びを得るために食べることができない．
だから僕は食べるために生きることもできなければ，生きるために食べることもできないのだ．
それはとても悲しくて，つらいことだ．
僕はそんな自分が嫌いだ．
美味しいものは美味しいと感じて，悦びとともに糧としたい．
コンビニのホットスナックを素手で持ってうまそうに食っていたあのおっさんのように，僕も食事で悦びたい．
今朝食べたツナマヨおにぎりは，本当に美味しかった．
今朝の僕は今日という一日に希望を持っていた．
だから逆説的に考えるなら，不安な気持ちに押しつぶされながら食べていると，食事というものは不味くなるのだろう．
以前に友人と食べたケーキは，とても美味しかった．
今日の夕飯だって，美味しかった．
一回食欲が減退して食事量が減ったからと言って，僕が食事を楽しめなくなったわけではないはずなのだ．
きっと夕飯の量を減らしたから，朝お腹が減るようになっただけなのだ．
良いことではないか．
何も不安に思うことなんてないじゃないか．
僕は以前と同じ量が食べられないことに違和感を覚えているだけなのだ．
そんな小事に気を取られて，食事の質を下げてはダメなのだ．
睡眠の質だって，意識を変えたら良くなったではないか．
食事の質も，きっと本質は同じなのだ．
明日はもっと，食事を楽しもうと思う．
生きるために食べるならば，それは生きることへの悦びを見出すことと同じなはずだ．
まずは明日，ツナマヨおにぎりを美味しく食べることから始めよう．
そうすればきっと，昼食も夕飯も美味しく食べられるはずなのだ．
自作ゲームサイトを作るためにとりあえず勉強した
たんしおレモンさんってすごいなって思う．
自分の作った作品を自分のHPにおいて無料で遊んでもらうというのは，相当に技術力や経験を積んでいないとできないのではないか．
今日はブラウザゲームをおいて遊んでもらうためのサイトを作るにあたって必要な技術はどういったものなのかについて調査していた．
結果，そういったサイトを作る方法は全くわからなかった．
WEBサービスを作るための触りやアーキテクチャについては，最低限の理解はできたと思う．
だが僕のやりたいことを実現するための方針は，具体化されていないのが現状だ．
それもそのはずであり，HTML5製ブラウザゲームをWEBサイトで提供するというのは僕が想像してたよりも遥かに技術的なハードルが高いようなのだ．
肥大化したアセットによる膨大な通信量と，それを制御するための完璧なデータキャッシュだけに対応する技術力を磨くだけで，おそらく1年以上の学びを必要とする程には．
だが壁の高さに物怖じしていては始まらない．
とりあえず今日は，今日学んだことについて軽くブログにまとめようと思う．
WEB開発のトレンドってなんか横文字だらけで気持ち悪い
ITビジネスの何割がそうなのかは知らないけど，現在のソフトウェア開発の主流はWEB開発にあるのは疑いようのない現実である．
まぁ今のところ便利だと思うようなサービスはだいたい全部WEBサービスなのだから，当然といえば当然である．
そんなビジネス真っ盛りなWEB開発を調べていると，どこもかしこも「エンジニアはトレンドを追え」みたいな記事が大量に出てくる．
なんかよくわからないけど栄枯盛衰な界隈らしいので，遅れた技術に触ることに対して危機感を持つべきらしい．
さて，WEB開発をするためにはまず，アーキテクチャについて知らなければならない．
大体のWEBサイトは，WEBサーバ，データベースサーバ，アプリケーションサーバの3層構造になっている．
昔はstaticなページを表示させるだけのWEBサーバしかない構成もあったらしいが，なんかちょっとずつ増えて今の形になったらしい．
とりあえずWEBページを作るために知らなければならない技術は，大まかに分けて次のような感じらしい
クライアントサイド
WEBページのGUIを作る部分．
ITエンジニアの仕事だとフロントエンドだとかWEBデザイナーだとか言われるやつである．
使用技術としてはHTML+css+jsが一般的である．
クライアントからのリクエストに対してWEBサーバがこの情報を返せば，最低限はWEBページが表示されてくれる．
この部分をもっと楽にいい感じに作るために使われるのがWordPressなどのCMSである．
WEBサーバ上にこれらのファイルを設置し，リクエストに応じて返せばWEBページが表示される．
ただしこれだけではWEBページの見かけ上の動作しか実現することができないため，後述するアプリケーションサーバを用いて動的なWEBページを作ることになる．
サーバとのインタラクションが必要ない場合は，HTMLとjsだけで動くプログラムを作り，クライアント側で全部動かしてしまうことも可能．
これはネイティブ開発に多く見られる，ダウンロードして後はオフラインでも動作するタイプのアプリケーションと仕組みが酷似している．
わざわざサーバに対して逐一通信をせずとも，クライアント側のプロセスでその機能を動かすために必要なリソースをWEBページとしてキャッシュすれば，後はオフラインでも動作するという仕組みである．
Flashゲームも同様の方法で動いており，WEBサーバに設置されたゲームや動画のデータをキャッシュしてクライアント側のプロセスとして動作させるという技術である．
クライアントのプロセスとして動くという点がセキュリティ面で大きな問題を孕んでおり，それが原因でAdobe Flashは終焉を迎えた．
HTML5製のゲームはFlashゲームと同様にクライアント側のプロセスでゲームを動かすものである．
すなわちWEBページとしてゲームを実装することができれば，極論を言うとアプリケーションサーバを導入する必要はない．
WEBサーバ
クライアントが直接通信を送る部分．
物理的に設置されたサーバというハードウェアと密接な関係のある部分であり，ここについて専門的なことをする人間を特にインフラエンジニアだとかネットワークエンジニアだとか言う．
物理的に構築したサーバにLinuxなどのOSを導入し，ApacheやNginxなどのミドルウェアを入れることでWEBサーバとして機能する．
最近はDockerというコンテナ技術を使い，Linuxカーネル上にコンテナを設置して仮想マシンを動かすことで設計や管理を楽にする手法が取られている．
さらにDockerを便利に使うためにKubernetesとかいうやつまで出てきていてこいつを使うとさらに便利になる．
自宅にサーバを設置する変態が，この世界には少数ながら存在しているとまことしやかに囁かれている．
ハードウェア自体にとんでもなく金がかかる上に電気代と回線使用料金でアホみたいにコスパは悪いらしい．
多くの場合，レンタルサーバ，もしくはIaaS(Infrastructure as a Service)を利用してサーバを設置する．
レンタルサーバの場合，共有サーバ，仮想化専用サーバ，専用サーバなどの種類がある．
仮想化専用サーバはVPSと呼ばれ，共有サーバ上に割り当てられた仮想マシンを専用サーバとして使用する形となる．
IaaSはいわゆるクラウドと呼ばれるサービスであり，基本的にはVPSと変わらないが，従量課金制による柔軟なマシンリソースの割り当てにより，1台から複数台までの仮想マシンを流動的に使用することができる．
共有サーバ以外のレンタルサーバは，基本的に1からOSやミドルウェアをインストールする必要がある．
こうしたケースにおいて，Dockerなどのコンテナ技術が使われる．
IaaSを本格的に利用する場合，同じ環境で複数のサーバを立てるため，コンテナ技術の理解と利活用が特に重要となる．
アプリケーションサーバ
そのWEBサービスがサービスとして提供する機能を動かしている部分．
例えば電卓をWEBアプリ化した場合，クライアントからの入力をWEBサーバを介して受け取り，実際に数字の計算をしてWEBサーバに返すのがアプリケーションサーバの役割．
この部分を開発している人間を特にサーバーサイドエンジニアだとかバックエンドエンジニアだとか言う．
StaticなWEBページには必要ないが，DynamicなWEBページを作る際には必要となる．
UI的な意味でStaticというわけではなく，ユーザーとのやり取りに応じてWEBページの振る舞いが変わるという意味でのDynamicである．
WEBサービスが実際にサービスを提供する上で必要不可欠な部分であり，サービスとしての個性が出てくる箇所．
ECサイトで商品を買うために注文を作って送るためにも必要だし，ゲームとかの攻略wikiで攻略情報を書いてもらってページ更新してもらうためにも必要だし，就活先の企業にES書いてエントリーするためにも必要．
Perl，PHP，Python，Ruby，Go，Java，Kotlinなどとにかく大量に言語があって，更にはDjango，Laravel，Ruby on Rails，Node.jsなど大量のフレームワークがありもう何がなんだかわからん状態と化している．
こうした言語やフレームワークが沢山あるということはそれぞれに得手不得手があるということでもあり，開発シーンやサービス内容と照らし合わせて使用言語やフレームワークを選定するのが重要となる．
例えば機械学習系のサービスをするなら，機械学習に強い(=よく使われている)とされるPythonやそのフレームワークを選択する必要がある．
WEBサーバからの入力に対して逐一処理を行うため，瞬間的にアクセスが増大すると処理が追いつかなくなる場合がある．
その場合はサーバを増設する，プロセスをチューニングするなど，ネイティブ開発にはない知識と対応力が求められる．
WEBアプリ開発において最も花形となる部分であるため，プログラミングスクールとかがこぞってこの部分の勉強をさせたがる．
チュートリアルも豊富であり，ここだけしかやってなくてもHerokuなどのクラウドにアプリケーションをデプロイするのはそれほどハードルが高くない．
データベースサーバ
アプリケーションサーバで駆動しているアプリケーションを動かすために必要なデータベース(DB)を管理する部分．
多くの場合はユーザー情報の管理を主目的としており，ここを専門的に扱う人間をデータベースエンジニアという．
サービスがスケールしていき，顧客情報が大規模になればなるほど仕事の量が増える．
こいつのセキュリティに問題があると世間の風当たりが強くなる．
使用技術はSQL(Structured Query Language)であり，こいつを使うと対話型で大量のデータを操作することができる．
つまりアプリケーションサーバがSQL文を生成してデータベースサーバに送るだけで，ほしいデータや弄くりたいデータに簡単にアクセスすることができるということである．
多くの場合はDBをRelational DB(RDB)として扱い，レコード(行)xフィールド(列)の表形式でデータを管理している．
世にいうビッグデータ解析とか呼ばれるお仕事は，データベースサーバに集積されたデータを数理モデルなどで処理して新しい知見を得ようとする業務である．
ビッグデータ解析はデータベースサーバを管理するエンジニアにとって直接影響するものではないが，そうして解析から得られた知見を元に新たなサービス形態が提案され，サーバーサイドエンジニアたちがその機能を実装するという仕事が発生する．
ユーザー情報を管理する場合，利用者数が増えるにつれて扱うレコード数が増えていくため，サービスの規模によっては維持コストがとんでもないことになる場合がある．
開発しているサービスがログイン情報を取り扱わなかったり，クライアント側のキャッシュで十分にアプリケーションが動作可能な場合，DBサーバは使われないこともある．
例えば企業のカンパニーサイトなどはCookieの受け入れを求めたりするときもあるが，ログインまでは求められない．
一方で採用活動などでエントリーを受け入れている場合，ユーザー情報をDBとして管理する必要がある．
こういう時に，リクルーティング用の別のサイトにリンクを貼っているケースがある．
これはカンパニーサイトとリクルーティングサイトを別個にして開発しており，後者だけにDBサーバを割り当てて運用しているケースであると言える．
(番外編) ゲームサーバ
ゲームサーバとは，主にオンラインゲームにおいてゲームを行うために接続されるサーバである．
基本的には上記サーバのアーキテクチャを用いて作られている．
ユーザーが動かしているゲームのクライアントと通信し，ゲームのログインであったり，ガチャの結果であったりをやり取りする．
リアルタイム性が求められるゲームにおいては，しばしば独自の通信プロトコルが用いられる．
特にFPSとか格闘ゲームとか，そういったカテゴリのゲームがこれに該当する．
ソーシャルゲームなどの場合は常時接続しなければならないほど高頻度でトラフィックが発生するわけではないため，WEBページを作る際のアーキテクチャと同様の手法でサーバを設計し，設置することが多い．
WEB開発怖すぎだろ……
調査を進めてて，正直チビりそうになった．
ゲームサイトが作りたいと言うだけでも，これだけの知識を学ぶ必要があるのだ．
ただ，調べていて希望も見えてきた．
まずHTML5でゲームを作って公開する場合，サーバーサイドの知識はそれほど要求されるわけではないということ．
WEBページとしてゲームを実装すれば良いため，極端な話を言うと「ゲームとして動くWEBページ」さえ作ってしまえば，それ以外はいらないのである．
つまりはフロントエンドエンジニアの仕事を極限まで煮詰めてしまえば，HTML5のゲームを作って公開するところまで十分に可能であるということである．
実際にはログイン機能であったりランキング機能であったりを導入するためにもサーバーサイドの知識が必要となるが，そちらが主目的とならないのはありがたい．
WEBページを作ってデプロイすれば，極論を言うならそれがゲームになってくれるということである．
それ以上にブラウザ側の仕様を理解した上で描画処理やサウンド再生を行う方が大変らしい．
ブラウザというプラットフォーム内では，ウィンドウサイズの変更やスクロール，ブラウザの機能によるズームイン・ズームアウトなどで描画領域がコロコロと変動する．
サウンドについてもブラウザの機能として鳴らすことになるなど，「ブラウザをゲームエンジンと見立てる」という考え方が必要になりそうだ．
またHTML5ゲームは，ゲーム内で扱うすべてのリソース取得にWEB通信を行う必要がある．
すなわち，ブラウザに効率よくリソースをキャッシュさせないと無限のトラフィックが発生し，サーバが破壊される．
とまぁ色々調べた結果，案外なんとかなるかもという気持ちが湧いてきた．
情報量の多さに戸惑うが，今からビビっていても仕方がないので，やりたいことに必要な技術の大枠がわかっただけでも今日の学びには意義があると思う．
必要なのはWEBページを作って公開するという部分なので，クライアントサイドとWEBサーバについての勉強が最も必要となると思われる．
つまりは，まずはVPSかIaaS上にサーバを立ててWEBページを表示するということから始めれば良いのだ．
アプリケーション層をリッチに実装する必要性は，早急にはない．
データベースサーバについても，今後必要になってから学び始めても遅くないだろう．
そうと決まれば，明日はHP制作とデプロイまでの流れを学習しよう．
どうせ教材はこのインターネットの海に腐るほど漂流しているはずなのだから．
いつもの儀式
よし，今日の俺はよく頑張った！！技術調査して文章にまとめて理解が深まった！！
しかもついでに1社エントリーを進めた！！アルバイトの採用担当の方から選考書類の受理メールも来た！！！
すごい！すごいぞ俺！！！明日もきっと頑張れる！！自信持って！！！いけるいける！！！うおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお
