コーヒーとWebについて、またはPHPが自転車である理由

いやいや この記事は、PHPでバイクを書く態度、つまりPHP自体がバイクであるということではありません。 そして、いや、著者はPHPをキックしたい怠け者に参加しようとはしていません。 むしろ、PHPだけが作者を追い払うとは言えません。 注意：この記事は非常に冗長です。

PHPは私たちの時代の非常にユニークな現象です。 PHPのエントリのしきい値は低く、tra-la-la、tra-la-laであるためPHPは優れています。 あなたは私よりもこのすべてをよく知っています。 膨大な数のサイトやブログが回転しているのはPHPであり、その作成者はプログラミングについてまったくまったく知らないことがあります。 JoomlaとWordpressは、これの鮮明な証拠です。 そして、私は特にこれらのエンジンの作者についてではなく、そのようなサイトの作者について話しています。 ただし、皮肉がなければ、PHPは多くの点で本当に優れていることに注意してください。個人的には、PHPをバイトコードの絶対的な悪と見なすことはできません。 PHPが単なるテンプレートエンジンであることを、何らかの理由で非常に多くの人が忘れています。



ええ、はい。 これは、非常に高度なテンプレートエンジンです。 高度なため、OOP、名前空間、さまざまな便利で便利なものがたくさんあります。 そして、彼らはすでに組み込みのウ​​ェブサーバーさえ持っている、と彼らは言います。 わからない、個人的にチェックしなかった、もうフォローしていないから。

判断が誰かに不快感を与える、または無礼だと思われる場合は、全員と全員に謝罪するのが適切だと思います。 考えもありませんでした。 むしろその逆：私は、非常に良いコードを書いている無私無欲な人々に心からお辞儀をし、そのような仕事や人々を非常に尊敬しています。 寛大に許し、厳密に判断しないでください。 今日、IT、特にWEBで起こっていることすべてを見ると、沈黙を保つのがますます難しくなります。 したがって、この記事は半哲学的な考察と考慮事項であり、実際的な推奨事項はまったく含まれていません。 しかし、それにもかかわらず、私は私に実際的な感覚を伝えることに成功することを本当に望んでいます。 この作品は、ウェブとその夕日、HTML5 / CSS / JSだけでなく、テンプレートエンジン、フレームワーク、デザインについてだけでなく、Habréの多数の出版物に触発されています。 このすべてに関するコメントと同様に。

まあ、いつものように、著者について少し。 著者は、チームリーダーでも、CEOでも、ジュニアでもシニアでもありません。 一般に、プログラマーとしての著者の経歴は、さまざまな理由で何らかの形でまだ発展していませんが、これには前提条件がありました。 特に、大人になる前に、著者は壮大なおもちゃの逆コンパイルとZ80ニーモニックのプログラミングからかなりの喜びを受けました。 しかし、将来的には、個人的な変化とその場所での見込みの欠如、そしてそのすべてが趣味のカテゴリーに追い込まれました。アセンブラーの後、なじみのない、完全に理解できない、不慣れなプラットフォームでFoxPro 2.6をマスターしようとする失敗した試みは、これに大きく貢献しました。 しかし、彼らが将来ITの頭字語と呼ぶようになったものは手放しませんでした。その結果、システム管理者として小さな州のオフィスで何年も費やされました。 しかし、プログラミングについての考えから、著者はVB / VBA / VBS、Delphi、MS VC ++、ひどく誤解されたMFCにさまざまな程度で没頭し、その後、著者はBorland C ++と彼のVCLでしばらく平和を見出しました。 その後、プログラミングの方法とシステムとインターフェースの設計に関する文献が発表されました。 その後、PHP、ActionScript（3.0）、Python、そしてもちろん、三位一体のHTML / CSS / JSがありました。 Javaは長い間、イデオロギーの理由から考慮されていませんでしたが、これは結局のところ変わりません。 繰り返しますが（これは重要です）、上記の略語と名前はすべて研究され、趣味としてのみ試されました。 実用的なアプリケーション（商業ベースを含む）は頻繁には発生しませんでしたが、依然として発生しました。 結局のところ、チュクチは作家というよりは読者です。 現時点では、ウェブベースを含む（deja vu！）プログラミングの分野で著者が自給自足に移行しているため、州事務所は過去のままです。 そして、はい、より早くダンプする必要がありました。
また、著者は、 JFDIの原則（「静かな乗り心地」と「7回測定」のカテゴリーから民俗の知恵を尊重する ）と極端な冗長性を無視したことで、友人にしばしばscられます。
そして最後の1つ：著者は、上記のすべてを非常に面白いと見ているので、自己皮肉の文脈で独占的に第三者へのアピールを使用します（また、いくらか悲しいこともあります）。 しかし、それについては十分です。

だから、テンプレートエンジン。 ちょっと考えてみてください。しかし、テンプレートエンジンと見なされるものは何をしますか？ ほとんどの場合、テンプレートエンジンは、大まかに言って、入力（または、多くの場合、テンプレートファイルへのリンク）と変数のセットを入力で受け取り、変数の値で満たされたテンプレートの形で既製のテキストを生成します。 また、多くの場合、デフォルトのテンプレートを使用できます。 原則として、多くの場合変数を渡すことができないため、出力はクリーンなテンプレートになります。 また、一部のテンプレートエンジンはデータベースからデータを要求してテンプレートに挿入できますが、MVCの概念との矛盾により、この自由は受け入れられないと多くの人が考えています。 多くの人が私が何を得ようとしているのかすでに推測していると思います。
実際、PHPはテンプレートエンジンとして考案されたため、新しいことは何も言いませんでした。 テンプレートエンジンのように機能します。リクエストを受信-処理-応答を返しました-スリープ（または作業終了）。 私は絶対にその使用に反対していません。 しかし、テンプレートエンジンを作成するためのツールキットとしてPHPを使用することに完全に反対です。 また、特にOOPを使用して、PHPフレームワークとCMSを作成することにも反対します（クラス階層が数千個に拡大した場合でも）。

ただし、これは単なる紹介です。 ここでの問題はもっと広くて深いので、物語は始まったばかりです。 しかし、少し脱線して、バイクを見てみましょう。 文字通りの意味で。 ハンドル、ペダル、一対の車輪。 サイクリング速度の世界記録は何だと思いますか？ 最近まで、私は全く知りませんでした。 ただし、単純な検索では268 km / hと表示されます。 考えてみてください。すべての車が対応できるわけではない速度で自転車に乗ることができます。 もちろん、どの道路でもそうではありませんが、このような速度を開発することができ、さまざまなトリックが必要になります。

では、誰が自転車を使っているのか見てみましょう。

• アスリート-すべてが彼らと明確であり、スポーツはスポーツです。 それは歴史的に起こったからです。
• 子どもたち-これらは、車を運転する生理学的能力または合法のいずれかにまだ成熟していません。 一般に、まだ小さい。 自転車のみが残ります。
• 車を購入する経済的能力を持たない人々。
• 人々は、さまざまな理由（生態学、健康、再び、お金、しかしすでに「原則外」）でこのタイプの輸送にイデオロギー的にコミットしました。

そしてどのような状況で：

• 自転車トラック/オリンピックトラック。
• ただ「ドライブ」/乗る。
• 近くのどこかで「高速運転」。
• 代替手段がない場合は、さらに離れることができますが、簡単ではありません。
• また、手で運ぶには重すぎるものを持ち込んだり、転がしたりすることもできます。

上記はさまざまなバリエーションで組み合わせることができます。 ご覧のように、実用的な用語での自転車の使用は大衆の間ではめったに使用されません（ヨーロッパとアジアのほとんどはこれに同意しませんが、これには理由があります）。 それは理解できる-なぜ、より快適で高速なのか？ さらに、誰もが、たとえばビジネスミーティングに自転車に乗ることができるわけではありません。 これには十分な勇気が必要であり、快適さをいくらか無視するためです（ペダルをこぐときの発汗）。 はい、ケースとネクタイをした厳格なスーツを着た男性、そして同時に自転車で、想像するのは難しいです。 しかし、もう一度-それはそのようなどこでもない、どこかで正常です。

したがって、異なる世界からの2つのエンティティを比較するために何がありますか？

• 手に入れて行く-シンプルで手頃な価格
• しかし、遠くて速く行きません
• あなたは遠くに行くことができますが、それは完全に迅速で疲れるでしょう
• あなたはすぐに行くことができますが、長くは続きませんし、すでに一般的には安くはなく、さらに疲れます。 そして、おそらく、そう遠くない。 そして、この焦点がどこにでも通るわけではありません。

最後のポイントは最も明白です。 PHPについては、おそらく、「短命」を除外することができますが、それ以外の場合は、ほぼ完全なイデオロギーの比較です。 「キャップ」/「空気回廊」が必要です。これは、この機会のために特別に編成する必要があり、ほとんどの場合、二度と役に立ちません。 どこにでもない滑らかな道が必要です。 ただし、陸上輸送には滑らかな道路が望ましいです。 そして、「上り坂ではない」ことが非常に望ましい。 でも、おそらく「短時間」で私は急いでいた。 安定性を確保するための特別な手段を講じないPHPの大規模または非常に大規模なプロジェクトは、遅かれ早かれ失敗します。 ハードウェアまたはプログラマーの能力が十分ではありません。 次に、自分でそれがどのように見えるかを決めますが、私はこのアナロジーが好きです：

• DBは道路のようなものです。 平坦であるほど良い。
• WEBサーバー-空気抵抗として。 ヒットからヒットする回数が少ないほど良い。
• さまざまな種類のキャッシュ-これは「キャップ」であり、それに付随する技術です。もちろん、これがなくても可能ですが、それを使った方が良いです。

原則として、ここでは作者を偏見で非難することができます-結局のところ、あらゆる言語で書かれたサイトにはウェブサーバーが必要です！ Etaa、onooo、kaneshno、ええと...はい...-著者はheしています。 しかし。 結局のところ、著者はPHPだけでなくキックすることを約束しました。 反対側からプロセスを見てみましょう。 エンドユーザー（たとえば、サイト訪問者）と彼のブラウザーの一部。 また、HTTPの生活のある時点で。 顧客サイトで詳細を確認できますが、それについては説明しません。 なぜなら、顧客は、もし彼が選ぶなら、何からであるかだけから。 それまでの間、サイトの開発者も彼のマスターであるとしましょう。 これも起こります。

一般的な意味で、エンドユーザーの主なタスクは、必要な（場合によっては必要な）情報を取得することです。 具体的には、「リンクをクリックして」（ドライブをコピー/アドレスを行に貼り付けます）して、必要なものを確認します。 そして彼にとって、ほとんどの場合、どのようなハードウェアが存在し、どのようなソフトウェアが存在するかは気にしません。 彼は、サーバーへのルート、すべてのHTTP、およびそのすべての応答と状態も気にしません。 彼は何が、なぜ、なぜあるのか見当がつかない。 このことから、彼は筋肉、パフ、nginxを必要としないことは明らかです（そのように発音されていないことは知っています）。 彼はINFAが必要です。 そしてポイント。 そして、ユーザーに見えるのは、写真/テキスト/ビデオ/音声だけです。 他の誰かがデザイン/利便性に注意を払っていますが、すべてではありません。 他の誰かがサイトの読み込み/反応の速度を見ていますが、すべてではありません。

そして、サイト開発者は何を見ていますか？ 最大限の意味で-すべてのために。 ただし、このためには、システム管理、プログラマビリティ、およびWebデザイン（多くの場合そうではないが、単純化のためにデザインに含めることを提案する「使いやすさ」）についてのアイデアが必要です。 それらの多くはありません、私たちはファッションの分業を持っています。 その結果、政府のこれら3つの支部が互いに非常に独立している場合があります。 リクエストからページへの地理的/時間的パスを、現在存在する形式でリストします。 主題にいる人のほとんどは私よりもこのことをよく知っていて、もし嘘をついたらそれを修正するでしょう。 しかし、私は、一般的な意味で、いわばその栄光の中で私の目の前にそれを出現させます。 だから：

• ユーザーがリンクをクリックする
• ブラウザーはサーバーアドレスを見つけます（または、初めてでない場合はキャッシュから取得します。ただし、最初はまだ実行する必要があります）。
• ブラウザはWebサーバーに対してGET | POST（あまり一般的ではないが他のHTTP）要求を形成し、それを実装します。
• Webサーバー：
  • 要求を分析し（たとえば、「静的/動的」の件名について）、静的な場合はファイルを生成します
  • 単にスクリプトを呼び出すか
• スクリプトは、静的か動的かを理解します。 通常、その場でファイルを生成できます。 そして、彼は答えのテキストを収集し始めます。 PHPに関する標準的なケースでは、この手順は次のように進みます。
  • スクリプトがディスクから読み取られる（またはファイルシステムキャッシュから取得される）、解析、実行される
  • スクリプト、構成、テンプレートの内容に応じて、通常は読み取り（キャッシュから取得）が開始され、すべての解析、コンパイル（PHPキャッシュからの取得）、実行が開始されます。 クエリはデータベースに対してデータに対して行われ、時にはテンプレートに対しても行われます（可能であれば、ここにもキャッシュされます）
  • 読み取られ実行されたすべてに基づいて、準備ができた応答テキストが形成されます
• スクリプトはWebサーバーへの応答のプレーンテキストを返します
• Webサーバー（一般）は、ヘッダーとスクリプトの応答をブラウザーに送信します
• ブラウザはサーバーの応答を解析し、それをどう処理するかを決定します。
  • HTML仲間の場合-解析および表示/実行
  • メディアshnyagaが、再び、表示または紛失した場合、それ自体またはプラグインを使用して
• 利益！ （404やその他の汚いトリックではないが、それについては話さないでください。すべて順調です）

ご覧のとおり、非常に標準的な手順です。 異常なものも、致命的なものもありません。すべてが標準フレームワーク内にあります。 入浴しませんが 「ここで何かがおかしい」という感覚を常に感じています。 それを理解してみましょう。 大ざっぱな検査でさえ、「キャッシュから取得された」という一般的に使用される表現を明らかにします。 また、PHPのサイトパフォーマンスの改善に専念しているフォーラムを実行しようとすると、このキャッシュにつまずき、キャッシュする他の何かを探していることになります。 「なぜキャッシュするのか」という質問に対して、これがどれほど便利かを非常によく説明します。 私は私の好きな処方を与えます：
-そして、キャッシュなしではどうですか？
-すべてのサイトのボトルネックはデータベースです！ できる限りすべてキャッシュしてください
-ママッシュドステア！
そして、深いため息をつく最も思いやりのある人だけが、PHPが通訳であるという100回または1000回の簡単な講義を行います。プロキシを使用し、Apacheにスクリプトをねじらせます。 また、HTTP、...

別の、一見して目立たないリストを提供します。 ウェブサイトを簡単かつ簡単に作成するために必要な技術の小さなリスト（ここではウサギの穴がすでに始まっているため、ここではまだPHPに遅れをとっています）：
サーバー側：

• Webサーバー、または複数の
• スクリプト（通常、必須ではありません）言語
• データベースサーバー

クライアント側：

• HTML
• CSS
• Js
• 多くの場合、AS（フラッシュ）だけでなく

これはすべて、何らかの方法でHTTP over TCP over IP over Ethernetに関連付けられています（ただし、プロセス間通信ソケットは1つのサーバー内で使用できます）。 1つのサイトに7つの（!!!）テクノロジー！ いいえ、まあ、それは本当に普通ですか？ そうでもない。 1回の要求と応答のサイクルでは、それらは依然として必要であり、引き続き機能します。 これが「I and my dog」などのページへのリクエストであり、6か月ごとに変更される場合でも、常に自分自身を解析してキャッシュする7つの異なるテクノロジーは正常ですか？ もちろん！ -専門家が答えます。 そして、彼らは政治家や共有ホスティングの詳細などで答えを正当化します。 など ところで、彼らは正しいでしょう。 今日に適用されます。 なぜなら、今日では、このようなスキームが最も柔軟で粘り強いことが証明されているからです。 さらに、コメントでは、彼らはさらに、またはさらに多くをスローします。 何らかの理由で何かを忘れたり、さらに悪いことに、私は知りませんでした。
しかし、私には個人的には普通ではないようです。 そして今、私の立場を説明しようと思います。

1桁目。 約6年前、著者はPHP / MySQLで構築されたサイトの追跡と追加の形でWebテクノロジーに精通しました。 もちろん、最初は非常に奇妙で新しいものでしたが、HTMLとJSが混ざり合い、エコー、印刷、または単に<？Php？>の外に表示されるという認識がすぐに現れました-そうではありません楽しんでください。 これと並行して、ブラウザーベースのオンラインゲームを書くことはクールで収益性があるだけでなく、非常に簡単であることが突然判明しました。 おなじみですか？ :)その結果、PHPで書かれた（もちろん、著者ではなく、未知のサードパーティによって）オープンソースのエンジンを使用して、特定のブラウザーベースのオンラインゲームが起動しました。髪の毛が動いているコードを調べた後、約180の量のデータベースを操作する練習を行いましたクリックごとのこれらのリクエストは単に恐ろしいものでした。 そして、リクエストの大部分は、PHP over HTTPが類似のプロジェクト（プレーヤーとゲームプロセスの現在の状態）に関連して欠けているものを実装しました。 ここで、著者を無用に選択するテクノロジーをもっと痛く、そして当然のように蹴ることは適切でしょう。 もちろん、コードは対応しており、ゲームの仕組みで多くのことが変更されましたが、エンジンの主な欠点を克服できませんでした-最初から完全に書き換える必要がありました。 それは考え出されて始まりました。 そして当時の私たちの最大の欲求は、データベースとそのコンテンツを管理する何らかの「悪魔」を編成して、エンジンの仕組みを統一および簡素化することでした。 ほぼ同時に、ストアドプロシージャとスケジューラがマッスルに登場し、これですべての問題が最終的に解決されるように思われました。 当時はCやPythonを使用する勇気がありませんでした。しばらくすると、計画された作成がその特異性のために望ましい収入をもたらさないことが明らかになり、すべての最高の考えは魔法の「後」に延期されました。 これは、これまでのところ、まだ到着していません。 上記の重要なポイント： それは、エンジンの必然的な崩壊を加速した、現在の状態と独自の松葉杖の実装で動作する組み込みメカニズムの欠如です。

余談2。 著者は、ある程度まで、理想主義者、完璧主義者、夢想家です。 著者は、朝にトルコでfreshれたてのコーヒーを飲み、少し夢を見るのが好きです。 そのコーヒーを含めて、どういうわけか自分でbrewれた。 しかし、この夢の特定の例にはまったく適用されるキャラクターがないため、著者はせん妄の順序でこのトピックに次のナンセンスを空想するのが好きです。 おそらく私たちの脳を伸ばすために、または単にゴミに苦しむために-私は確かに知りません。 それで、その朝、私はこのように横たわり、推論しました。
さて、夕方にトルコ人に水を注いでコーヒーを注ぐことができるとしましょう。 圧電点火式ガスストーブ-彼らはリレーでタイマーをクリックすることができます、それは難しくありません。 バーナーの蛇口のノブを回してガスを開閉する簡単な方法を思い付くことが残っています...そして、それは私に夜明けをもたらしました。 私たちはこの馴染みのあるプロセスに非常に慣れているため、プロセスの詳細に気付くことを完全にやめ、ずっと前に取り組んできたステップを飛躍的に考え始めました。 コーヒーを作るには何が必要ですか？ トルコ人、水、コーヒー、オープンガス、火をガスに設定...停止！ 一般的なガスはどうですか？ 水を温めるために。 だから-私たちはチェックするか、行く必要がありますか？ オープンガスが必要ですか、それともお湯が必要ですか？..

ここで、実際には、このスキームによれば、私たちは皆通常推論します。 私たちは、人生の問題をうまく解決するためのモデルとして、十分に確立された、確立された、良い、または単に便利な実践とアルゴリズムを保持し、同様の場合、これらの実証済みの技術を正確に適用しようとしています。 これは私たちの思考の基盤の主要な基盤の1つであり、これは良いことです。多くの場合、このアプローチはタスクの適切な解決策になります。 しかし、常にではありません。 以下に抽象的な例を示します。より具体的なバリエーションでは、私自身の行動を含め、通常の生活で何百回も観察する幸運がありました。 友人に水を飲む必要があるとします。 量、範囲、持ち運びのしやすさなど、心の状態をすばやく把握し、非常に正常な解決策を見つけます。 私たちはマグカップを取り、水を注ぎ、それを友人に運びます。 バディは幸せです-私たちもそうです。 問題は解決され、誰もが幸せです。 サンプルソリューションが作成されました。 数時間後、友人が繰り返すように頼みます-私たちは同じマグを取り、手順を繰り返すことをheしません。 すべてが順調です。 サンプルは、統合の第一段階である真実の確認を通過しました。 1週間後、友人が再び光を見ます-同じシナリオによると。 サンプルは工業用に使用できます。 そして、1か月後に数人の友人が水を求めるとき-私たちは大胆に2つのマグカップを取りますが、問題はありません！ 動作中の産業用アプリケーション、実装、テスト、およびテスト済みのスケーリング。 これからは、「水を飲む」は「円から」に関連する鉄筋コンクリートになります。 トラップの準備ができました。 むかしむかし、騒々しい15人ほどの会社が、7月に路上で摂氏+30で、私たちの囲炉裏に落ちたからです。 要するに、habraeffect。 サークル付きの7〜10回のフライトに加えて、いくつかのフライトを中断する可能性があります。 空のマグカップを数個用意する代わりに、片方の手の指でハンドル（単に水平に持ち運ぶ必要はありません、空です）ともう一方の手にボトル/デカンタ/水差しを置きます。 実際、このようなものは真に独創的なアイデアを生み出します-いくつかの考えを一歩下がって、側から状況を見てください。 それ以外の場合は、15個のマグカップを一度に休ませる作業を何らかの形で単純化し始めます。 たとえば、すべてを1つのトレイに置くことができます。 そして、あなたは粘着テープでそれを巻き戻すことができます...そして、神はこの問題をうまく解決することを禁じます。 しばらくすると井戸から10リットルの水を運び出すタスクがあり、近づいてくる隣人は私たちを観察し、井戸から水を集め、マグカップでマグカップを作り、これらのマグカップを構成する組成とカプセル化を注意深く観察するので、長い間笑うでしょうhorizo​​ntal_movement円用に特別に研がれたゴールバッグ。 そして、井戸の隣に立っているバケツの横に彼の悪意のあるうなずきに応えて、私たちは重いもの、例えばこのバケツで彼を非常に強く叩きたいと思うでしょう。 彼が私たちを馬鹿と呼ぶのが正しいことを理解するのは非常に不快で苦痛だからです...

かつて私は壮大なAS3行列に非常に熱心でしたが、Ay氏が来てすべてを台無しにしました 。 もちろん、3年前の古代の技術を抑制して扱いにくくするために呪いましょう。数十の鉄とソフトウェアの最終メーカーと技術的な問題に同意して解決することで最適化しようとはせず、代わりに、効果のない着色とすでにほとんど問題のない超高速のインタプリタ言語は、もちろんあなたが使用している場合、すでに壮大なページにインタラクティブなタッチを追加します この優れたフレームワークを使用して、動的に変化するすべてのプリミティブをバイパスする方法で、すぐにこのすべてからキャンディを作成します、残りわずか数年です！..私は本当に多くのことについてスティーブおじさんをとても尊敬していますが、私はこの点で具体的に彼と一緒にいます私は同意しません。 しかし、私は彼が本当に最高のものを望んでいたことを除外しません。 しかし、adobesは誤解されるか、単に誘惑され、その結果、実際にウェブをプロファイリングしました...

余談3。 組み込みのブラウザとキーボード/マウスサポートを備えた比較的新しいスマートテレビが壁にぶら下がっています。 ただし、90％のケースでビデオホスティングサービスにアクセスしようとしても失敗します。 手始めに、キーボードの矢印がマウスカーソルを制御するため（!!!）、アドレスが封印されている場合はアドレスを入力するのは困難です。 ただし、サイトに正常にアクセスできたとしても、映画を見ることができるという事実ではありません。 狂ったスクロールのためにカーソルがムービーに入らないか、サイト所有者が慎重に考えたJSスクリプトの重みでブラウザが停止したため、最初からやり直す必要があります。 自慢のスマートアプリケーションを開発している人は、キーボードを見たことがないようです。なぜなら、スクリーンキーボードの記号的なレイアウトは、何らかの理由で、ほとんどの場合、アルファベット順だからです。 入力言語を切り替えるためのボタンがある場合もありますが、これに通常使用されるキーボードショートカットキーは機能していません。 どの言語がありますか？これらのアプリケーションのキーボード自体は常に機能するとは限りません。 そして、実際には、まったく同じフラッシュが使用されているという事実は何の意味もありません。 どこかで機能するはずなのに、どこかで機能しないからです。 そして進歩とは何ですか？

私が同じAS3をオンにしたとき、再び、私は彼らがそれに書いたことに恐怖を覚えました。 最も有名なカジュアルなおもちゃは教育書の例に基づいて作成されており、グラフィックは30年前の「壮観な」ものよりもはるかに悪い（!!!）ため、アニメーションについては沈黙しています。 しかし、これは幸いなことに、言語の問題ではなく、曲がった手です。 さまざまなエンジンが比較的広く流通する頃には、いくつかの場所で品質が向上しているためです。 当時、同胞を含むかなりの数の才能のある人たちがAS3で賢明なことをしました。これには、ほぼ完全な3Dと物理学の実装が含まれていました。 10番目のバージョンでは、すべてが雲一つないわけではありませんが、Z座標をねじ込みましたが、これは重要ではありません。 重要なことは、アドビが非常に明白ですでにほぼ致命的な欠陥があることを認識し、それを排除するための対策を講じたことです。 ちなみに、サイズが4825バイトのシンプルな2年前のバージョンを次に示します。 ソースコードには約250行のコードが含まれています。 組み込みクラスのみが使用され、サードパーティのエンジンは使用されません。 軌道は楕円形であり、惑星の位置は平均異常（ケプラーによる加速運動）に従って計算されます。 実行速度またはサイズに関して最適化は行われませんでした。 そのため、少なくともCanvasであっても、同じ裸のJSでクライアントコードと実行速度に近いサイズを与えてください。 またはCSS、gee-gee。 たぶん、私はHTML5と仲間の勝利を認めます...

次に、HTML以外のプラットフォーム用のPHP以外の言語でのプログラマーとプログラミングの進化を簡単に見てみましょう（これらについては後で説明します）。 通常、プログラマーの開発パスはいくつかの重要な段階を通過します。

ステップ00。「hello world」を作成します。 やった！ 私はプログラマーです！
ステップ10. Cool Window Applicationを作成します。
ステップ20。多くの変数、関数および変数の束のようなものがコピー＆ペーストによって傾けられます。 10箇所で修正するのはすでに疲れているので、それについて何かする必要があります。
ステップ30。 クラスを使用する必要があります！
ステップ40.何かのクラスがますます私にコピーされ、10か所で1つのイチジクを編集する必要があります。
ステップ50。 設計パターンは私のすべての問題を解決します！
ステップ99.くそー、なんてばかだった...まあ、それはまだ簡単です...
ステップ100。禅。

ステップの数とメソッドの名前はほぼ任意に選択されます。 それらはそれ自体では重要ではありませんが、プログラマーが思考のパラダイムを変えるという事実です。 少なくともそれは私と、私がよく知っていて、そのコードを見た人々の場合でした。 確かに、私の批判的な見方では、それらのどれも私自身と同様に99番目のステップに到達していません。 はい、私が知っているプログラマーはそれほど多くありません。 しかし、いくつかのフレームワーク/ライブラリ/プログラムの作者のコードを見ると、あなたはそれから地獄を抜け出し、人々は約500番目のステップに長い間行ってきたという感覚を得る...

気になる点が1つあります。 さまざまな教科書には、コンピューターテクノロジーのハードウェア機能に関するプログラムの設計プロセスを振り返らないように推奨するものがあり、これがなぜそのように機能するのかを考えずにそのまま使用するよう求めています。 私には、質の高いプログラマーを訓練することは根本的に間違っているようです。 そして、私はこれについて多くの確認に会いました-ほとんどの本当に良いプログラマーは、「一般にこれがすべて」が、アセンブラーとTCPレベルに至るまで、どのように機能するかについて良い考えを持っています。 しかし、注目に値するのは、このような推奨事項は、モンキーパッチャーを育てる上で本当に価値があることです。 理解できます。 動物の訓練は通常、同様の方法で行われます。理由と理由は関係ありません。それを行うことが重要であり、それはおいしいでしょう。 そして、この不快な注意事項については、切望されているPHP / HTMLのカップルに移ります。

私は個人的に、PHPを条件付きで2つの大まかなカテゴリーに分類する傾向があります：他のプログラミング言語を知っている人（原則として、PHPは最初の言語ではありませんが、逆のことも起こります）と、PHP以外は何も知らない人。 最初のカテゴリは、前のシナリオに従って開発されることがよくありますが、質問はありません。通常、PHPで適切なコードを記述し、正しく合理的に使用します。 しかし、ここに2番目のカテゴリーがあります-すべてがそこで異なっています。 それだけです。 なぜなら、最初のシナリオに従って開発している間、人々は最初は特定の言語（たとえば、コンソールまたはWinAPI / X11）に関連付けられていない1つまたは2つの技術のみを直接使用することが多く、原因と関係が壊れていないためです：ここにあるのは、コマンドライン引数ですそれらはコード内にあり、それを使用します。 2番目のカテゴリーについて言えないこと。

PHPの前にまったくプログラミングをしなかった人は、既製の、大規模で、すでに機能し、非常に理解できないシステムに直面することに気づくからです。 一方で、ここにエコー「ハローワールド」-ブラウザ-F5-がありますが、それがどのようにそこに到達し、なぜそれ自体を更新しなかったのかは明確ではありません。 いいえ、「Webサーバーのルートにファイルを配置する」などの基本的な概念はもちろん習得されますが、「Webサーバーはどこから来たのですか？」および「どのように見えますか？」という質問は、しばしばこのギャップを埋めるという漠然とした希望を持って答えられません。 時間が経つにつれて、そのような不明瞭な場所の数は増え、すべての種類のCEES / JES / Hateaccess / OOPE /テンプレート/フォント/ jipegiがそこに追加され、その内部はあまり明確ではありませんが、（そしてこれは非常に重要です）-あなたは間違いなくそれを使用できることがわかります何、なぜ、どのように考えるか。 時間が経つにつれて、「考えない」というパラダイムが普及していることが判明し、それが完全に悲しいものになります。 かつてどこかで、ある心理学者は、人が新しいテキストを知覚することは、彼が理解できない言葉に出会った場所で終わることを発見しました。 この場合、この単語に戻ってその意味を明確にし、続行することが最も正しいでしょう。 Webテクノロジーの場合（そしてほとんどの場合、PHPで始まるWeb上）-多くのあいまいな言葉があります。 信じられないほどたくさん、いくつかのために-ほとんどすべて。 ただし、TCPタイプでWebサーバーを介してブラウザーに要求からチェーン全体の説明を開始すると、すぐに実際のプログラミングに到達しません。 そして、ここから嘘が始まります。 教師（広義では、上級の仲間、友人やフォーラムのユーザー、ビデオレッスンの講師など）が研修生に嘘をつき、すべてが後で明らかになるか、学生自身が自分自身と教師に嘘をつき始めます（誤解を認めるのは残念だからです） ）：「はい、それから私はすべてを理解しました。」 「はい、わかりません」先生は手を振って、次のトレーニングの部分を教えます。 時間が経つにつれて、研修生は「少し誤解されているが、そうなる」という状態に非常に慣れてしまい、概念、方法、フォーマット、および可能なすべての完全なダンプが心に蓄積されます。

出力では、PHPで数年間プログラミングを行っている「スペシャリスト」を見つけることができますが、あるサーバーにアップロードされたファイルが別のサーバーに要求されたときにブラウザーにどのように表示されるかを明確に説明することはできません。 いいえ、全体として、もちろん、彼はパニックに陥っていますが、説明を求めると、出力は「そのようなもの」と「はい、違いは何ですか」の間になります。

PHPのもう1つの頭痛の種は、あらゆる意味でのOOPと、他のあらゆる種類のランタイムパンです。 そして、PHPプログラマーの進化は、最終的にZenへの上記の100のステップとわずかに異なります。 なぜなら、すべてのPCは、スクリプトが機能し、すべてをつぶして忘れてしまうことを知っているからです。また、一方で、何年も何世紀にもわたって継続的に実行されているソフトウェアのようにコードを書きます。 クラスの構造、静的メソッド、インターフェイスの実装、さらには（!!!）信号まで徹底的に考え、何キロメートルものコードを生成します。神格化は「遅延読み込み」の実装から始まります-結局のところ、彼らはこのコードが実行されない可能性があることを理解しているので、何のためにも使用しないのはなぜですか？まだキャッチされていませんか？このコードは決して実行されないかもしれませんが、書かれています！そして、それを書くには時間、労力、しばしばお金がかかりました...

そして、実行時間が長い言語のプログラマーにとって、一度初期化された変数は、プログラムの1年後でもかなりの場合に使用できる場合、PHPではすべて初期化され、インスタンス化され、構成されます文字通り、ユーザーのブラウザーからの各くしゃみに応じて、多くの場合ajaxリクエストに応じて、その後すべてが即座にクラッシュして忘れられます。著者は時々少しブレーキをかけ、彼にとってこの事実の実現はかつて精神への強い打撃になりました。

もちろん、私はアメリカを再び発見したことはありませんが、なぜこれについて話しているのか、なぜアメリカを重要と考えるのか。多くのプログラマーの頭の中にある共通の混乱は、彼らがプロセス全体から抽象化するのを防ぎ、存在の本質を反映するからです。このすべてのために積み上げられている。そして、これを念頭に置いての試みに応じて、彼らは「これを変更することはまだ不可能です」という事実に慣れており、何も理解することを拒否します。時々、ブラウザ以外の方法がないため-ブラウザ-Webサーバー-PHP-データベース-PHP-Webサーバー-ブラウザは単に表されません。まあ、いずれにしても出力はまだパンのあるHTMLなので、これは公理では証明できない不変で不変の真理のカテゴリに入ります。そして、今日のPHPが大半を占めており、separate_webサーバーが必要なのはまさにそのためです。他の言語のプログラマーは、まだインストールおよび構成されているため、individual_webサーバーにバインドし始めます。そして本当に、なぜですか？それでも、それは思われ、それでうまく動作しますか？

それにもかかわらず、この質問にすでに答えるために、別のトピックに触れます。つまり、別個のWebサーバー。彼は通常何をし、どのようにすべてが始まりましたか？言い換えれば、なぜそれがそのように行われるのですか？実際、最初のWebサーバーはかなり前に作成されました。 RAMは小さく、高価でした。ファイルも小さく、デザイン用のグラフィック要素は実際には使用されませんでした。 PHP、JS、CSSはありませんでした。裸のHTMLのみがありました。当時のブラウザは、情報への飢えを満たす手段ではなく、実行することで情報を取得できる新しいプログラムです（インターネット接続があり、非常に小さくて時間がかかっていた場合）。そして、ウェブサイトは誇示する方法ではありませんでした（少なくとも... :)）が、いくつかの情報を共有する方法でした。ディスクアレイも大容量で違いはありませんでしたが、それでも、RAMよりも安価でした。ファイルが頻繁に使用される場合でも、RAMにファイルを保存することは単に不可能であると考えられていました（実際、不可能でした）。さらに、接続速度は単位および数十キロビットで測定されました。そのため、最初のWebサーバーは、ユーザーの要求に応じて、サーバーのハードディスクから1秒あたり数十バイトのファイルを読み取り、ネットワークを介して少しずつクライアントに転送し始めました。また、1つのファイルを転送するのに常に1秒もかかりませんでした。はいそれから20年余りが過ぎました。すべてが変わりました。その当時の平均的なサーバーは、おそらく、RAM容量、CPU周波数、ROM容量など、どのようなパラメーターでも現代の平均的なスマートフォンにうらやましいでしょう。そして、画面解像度も。

しかし、私たちはまだファイルをディスクに保存し、Webサーバーでそれらを読み取り、バンドルをブラウザーにフィードします。あらゆる種類のアメニティと、スクリプト言語を備えたリッチインターネットアプリケーションのようなアメニティを数多く発明しました。そして、これらすべては20年前のテクノロジーの上にあります。彼らは貧しいパフに静的ファイルを与えず、Webサーバーによって個別に配布することにしました。 CSSの欠陥にうんざりしている賢い人たちは、LESSとSASSを思いついたかもしれません。そして今、ジレンマはそれをいつどこでコンパイルするのですか？サーバーまたはクライアントのいずれか。キャッシュ、または各変更後に再コンパイルして静的に追加しますか？しかし、何らかの理由で、本質的にどのキャッシュがどのようなものであり、Webサーバーがどのように静的を配布するのかを見たいとは思わないでしょう。誰もが「ファイルはシステムによってキャッシュされ、毎回ディスクから再読み込みされることはありません」のような言語を使用しますが。さて、すでにこの最後のステップを踏んでください！結局のところ、キャッシュされているファイルは、実際にはディスクではなくRAMに保存されていることを誰もが既に確認できます。別のタイプのキャッシュを発明する理由-これらのファイルをメモリにロードし、それらを直接提供するだけです。コンパイルが必要な場合は、最終フォームにコンパイルし、再度RAMから渡します。そしてすでに真に可変なもの-データベースからロードするか、そこに保存する場所...コンパイルが必要な場合は、最終フォームにコンパイルし、再度RAMから渡します。そしてすでに真に可変なもの-データベースからロードするか、そこに保存する場所...コンパイルが必要な場合は、最終フォームにコンパイルし、再度RAMから渡します。そしてすでに真に可変なもの-データベースからロードするか、そこに保存する場所...

この場所では、誰かが作者をOccamのかみそりで突くべきであり、オブジェクトは、すべてがこのように機能する場合、なぜ追加のエンティティが必要なのでしょうか？そして、なぜあなたは車が必要なのですか、もし百年以上前に、大多数が馬と二頭を欠いていたなら？なぜパーソナルコンピューターとブラウザーとタイロンネットを備えたグラフィカルインターフェイスが必要なのですか？結局のところ、これは非常に権威ある承認されたほど昔ではありませんでした...だから、紳士、オカミスト。設計のあらゆるレベルで浸透しているユビキタスキャッシュは、実際、非常に不必要な存在です！結局のところ、すべてが彼なしで機能しますよね？もしそうなら、なぜそれが必要なのでしょうか？判断に一貫性を持たせましょう。しかし、いや、誰もキャッシュを拒否することを急いでいない、余分なキャッシュは決して不要ではありません。なんで？キャッシュは、アプリケーションを高速化すると言われています。しかし紳士、これはナンセンスだから許可してくれ！加速せずに何かを加速するにはどうすればよいですか？ CPUは引き続き同じ周波数で動作し、RAMの周波数は同じです。ディスクアレイとの交換レートも増加しません。ただし、キャッシュを使用すると本当に速く動作します。偉大な神聖な真実は、キャッシュが速度を上げることは決してないということです-ブレーキを取り除くだけです。つまり、繰り返し作業中にゆっくりと作業領域をバイパスし、その状態を簡単に覚えることができます。まあ、彼らはまだ回避する必要がある場合は、そうです。しかし、彼らはどこから来たのですか？そこで私たちは実際にそこにそれらを積み上げました...

だから問題は-なぜ、私たちはこのゆっくりと動作するコードをフレーミングするのかという名の下に？なぜ高速にしないのですか？原則として、無知か無力のどちらかです。時々誤解によって。しかし、見てみましょう。平均的な現代的な、それほど複雑ではないサイトには、数百キロバイトからメガバイト単位のグラフィックやその他のスタイルが含まれています。現代の価格では、RAMは何もありません。一方、どのレベルでもキャッシュにある場合は、とにかくこのRAMを占有します。さらに、システムのさまざまな部分のさまざまなレベルのキャッシュに表示され、このRAMを数回消費する可能性があります。そして、常に最適な方法ではありません。それでは、なぜ追加のレイヤーが必要なのでしょうか？私たちはシュレックでも弓でもありませんか？システムを起動した直後に、それらをメモリにロードして使用します。そして、キャッシュが取得され、まったく必要ありません。しかし、PHPの弱点が現れるのはこの場所です...それはできません。シリアライズして保存しても何も取得できません。とにかく、次のリクエストでは、最初にオブジェクト階層を初期化してからデシリアライズする必要があります。何も加速しない過度の無駄な仕事。

余談4。 VAZ2101を改造せずに200 km / hの速度まで加速できない理由を知っていますか？エンジンのせいでもありません。しかし、すでに130 km / hで、貧しい「ペニー」が左右に投げられ始め、運転するのが怖くなる。時速20 kmでの15度のステアリングバックラッシはほとんど目立たないため、時速200 kmでは、文字通り道から簡単に飛び出すことができます。それは単にそのような速度のために設計されていません。ところで、自転車に乗ることも危険です。減価償却なし、ダイレクトステアリング... 1つの不正確な動きは、かなりの身体的損失を招く可能性があります。また、高速用に設計されていません。しかし、高速では、現代の自動車産業の結果の突破口が計算されます。そして、あなたは現代の車が15年前の平均的な自転車とどう違うのか知っていますか？はい、そうです。みんなに。しかし、その中で最も重要なことは、その中のすべてのノードが、プロのデザイナーによって相互に最大限に適合されているため、それについて考える必要さえないということです。車に乗って運転するだけです。そして、突然あなたの組織に車が必要になったとき、特別な訓練を受けた自動車整備士を雇って、あなたが必要な車にするために、ブレーキ、シャシー設計などの取り付けられるシリンダーの数について互いに議論します、そして誰もこれを再び持つことはありませんか？はい、誰かが自分で車を収集しますが、これは趣味または産業の注文であり、常に安くはありません。しかし、この場合でも、実際には誰もエンジンのパラメーターを計算して設計することはなく、適切なパラメーターを取得するだけです。もしもちろん、エンジンパラメータの計算プロセスではなく、完成車に興味があります。このall意では、重要な点は、ほとんどの場合、専門家によって計算されるものが膝アセンブリよりも優れており、信頼性が高く、時には安いことです。もちろん、例外がないわけではありません。

同じ著者がCMSまたはフレームワークについて語っています！はい、いいえ。はい。どちらもプログラマーを不必要なルーチン作業から救うように設計されているためです。いいえ、彼らの作業はアプリケーションレベルで実行されるためです。言い換えると、フレームワークまたはCMSである車両に対して逆の主張を行う場合、それらはさまざまな程度の抽象化の詳細のコンストラクターから組み立てられた車に意味的に似ています。また、もちろん、生命に対する権利がありますが、どういうわけか...おそらく大量に使用されていません。しかし、プログラミングでは、何らかの理由で、これは依然として事実です。

たとえば、同じpythonの多くのフレームワーク、および最近ではPHPには、開発用の組み込みWebサーバーがありますが、専用のソリューションがより高速で信頼性が高いため、実稼働環境で使用することはお勧めしません。 Webサーバーを操作するための拡張機能とプロトコルの両方が開発されました。さらに。データストレージ。ほとんどの言語には、ファイルシステムやさまざまなデータ保存方法を操作するための機能が組み込まれています。しかし、産業規模では、再び、特殊なDBMSを使用することをお勧めします。これもまた、信頼性が高いためです。それは常に簡単ではありませんが。多くのプロジェクトでは、RAMにあるSQLiteデータベースが非常に高速で信頼性の高いソリューションであると認めています。言い換えれば、専門のソリューションが再び勝ちます。次に、今日のサイトの大部分を見て、すべてに共通するいくつかのセマンティック機能を強調してみましょう。オフハンド：

• まず、設計原則。HTML / CSS / JS c withパン。すべて同じです。本質的に、ブロックデザイン要素の書体/サイズ/フォントの色とサイズ/スタイル/レイアウトのみが異なります。
• -, . , , , (, , ). , . — — - , - .
• -, . - , . , , - . , , , — , , - HTML+CSS+JS. , , , .

そして、ウェブはどうですか？これがHTML5-フラッシュキラーです。これがJS-AS3キラーです。直接人々のある種の前線。誰かと戦っているのは誰ですか？ネアンデルタール人のクロマニョンとの戦争は、何らかの理由で敗北しましたが、クロマニョンです。そして、これは奇妙であり、誰かにとって有益であるという悪い考えにつながります。技術としてフラッシュが喜ばなかったことは何ですか？ glyい迷惑なバナー？したがって、質問は実際には技術者ではなく、製造業者と販売業者向けです。なに、2000年代初期の vyviglaznyhウインクデザインのHTMLサイト-よかった？測定を超えて輝くすべてのものは遅かれ早かれ消え去り、それは消え去ります。なぜフラッシュが必要なのですか、今はキャンバスがありますか？ヌードヌード。Adobeの代わりに、新しく導入された要素を操作するためのすべてのメソッドを、ActionScriptの次のバージョンとビジネスにねじ込みます。私は長い間彼らをフォローしていません、私は知りません、多分彼らはすでにそれをしたでしょう。最近では、フラッシュプレーヤーがペストリーのように膨らんでいます。だから、HTMLの代わりにフラッシュの背後にある著者？いや 著者は合理的なアプローチのためです。

脱線番号5、最後。少し前に、著者は自由な生活を始めました。とりわけ、コアでないビジネスプロファイルとして「tsmskでクイックスタートを1ペンスでも大丈夫」という原則に基づいてサイトの開発に戻ることが決定されました。しかし、ここでPHPでCMSを選択するという質問に私は殺されました。多くの時間が費やされましたが、私の夢の銀の弾丸は発見されていません。禅を得るための無駄な試みで、Yiiさえ考慮されました。彼らが言うように、素晴らしいコード、素晴らしい機能、豊富な、しかし英語のドキュメント、良いコミュニティ。しかし、ナイアシリル。まあ、配列の配列の配列を引数として関数に渡すことはできません。クールなフレームワーク、クールな記述コード、なぜ???そして、フォーラムの定数「どうする？ 「ドックに行く！」でもいまいましい同じ質問が異なる時間に異なる人々から何度も発生する場合、この場所で何かが間違っています！すべてのプログラミング言語のすべてのフォーラムには、常に同じ質問があります。ユーザーを作成する方法、それらを保存する方法、ハッシュする方法、リクエストを記述する方法、そしてなぜこれが可能なのか、そしてなぜそうなのか？..パスワード、データベースへの同じクエリは、同じ場所で同じキャッシュを接続するため、まったく同じブレーキがかかります...しかし、賞賛されたコードの再利用はどうでしょうか？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたこの場所に何か問題があります！すべてのプログラミング言語のすべてのフォーラムには、常に同じ質問があります。ユーザーを作成する方法、それらを保存する方法、ハッシュする方法、リクエストを記述する方法、そしてなぜこれが可能なのか、そしてなぜそうなのか？..パスワード、データベースへの同じクエリは、同じ場所で同じキャッシュを接続するため、まったく同じブレーキがかかります...しかし、賞賛されたコードの再利用はどうでしょうか？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたこの場所に何か問題があります！すべてのプログラミング言語のすべてのフォーラムには、常に同じ質問があります。ユーザーを作成する方法、それらを保存する方法、ハッシュする方法、リクエストを記述する方法、そしてなぜこれが可能なのか、そしてなぜそうなのか？..パスワード、データベースへの同じクエリは、同じ場所で同じキャッシュを接続するため、まったく同じブレーキがかかります...しかし、賞賛されたコードの再利用はどうでしょうか？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたそしてなぜそうなのでしょうか？..そして今、1000万人のプログラマーは、おそらく同じユーザーの同じストレージ、同じパスワード暗号化、同じデータベース要求、同じキャッシュが同じ方法で接続することを実現するために、すでに世界で何千億もの労働時間を費やしています...コード？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたそしてなぜそうなのでしょうか？..そして今、1000万人のプログラマーは、おそらく同じユーザーの同じストレージ、同じパスワード暗号化、同じデータベース要求、同じキャッシュが同じ方法で接続することを実現するために、すでに世界で何千億もの労働時間を費やしています...コード？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたexact_so_zhe_ne__normal ...しかし、賞賛されているコードの再利用はどうですか？その頃、上記のコーヒーの状況が発生し、その後、私は最終的に取り返しのつかない決定をしましたexact_so_zhe_ne__normal ...しかし、賞賛されているコードの再利用はどうですか？その頃、上記のコーヒーの状況が発生し、その後、最終的に取消不能の決断を下しました。 PHP , , .

, ?

: « / ?» — « ?». - , - , , , , . , , , :

• , , , ?
• , - , ?
• -, --- FAQ' , , ?
• CRUD, ( IT-, ) ?
• User/Password Post/Comments - — , , ?
• , , ( __JS_, ) — , 20 , , ? , . , MVC , , , , ?
• , , , ?
• , , , , MVC, -, ? , ?
• - ? - RichWebDataServer, web-, , , , , , ? , . - HTTP_2.0 . MVC, , . , ActionScript, - , plain_text GET|POST. , - X.Org RDP, , , .

長く忠実なサービスにブラウザに感謝し、ステンシルやタイプライターの隣にある歴史博物館に引き渡し、ポケットから新しいデバイスを取り出して、断片ではなく現代のテクノロジーの勝利に基づいて構築された本格的なインタラクティブをお楽しみください30年前のテクノロジー。冗談です。 :)しかし、真剣に、そして既存のウェブの技術スタック全体を批判的にレビューします、私の主観的な意見では、それは本当に時間です。 PHPに関しては、どこにも行きません。彼が新しいウェブで場所を見つけることを除外しません。特に愛好家が「より速い馬」を作ろうとするのをやめた場合。そして、古き良き複雑でないサイトは、非常に長い間それで動作します。

そしてもう一つ。提起された質問で、私は故意に場所でスティックを曲げて、かなり意識的に正当な批判を期待します。実践が示すように、十分に合理的な批判は弱点を明らかにし、そこに、もし良ければ、本当に有用な何かが生まれる可能性があります。私が控えたいのは、「機器の既存のブレークスルーと訓練を受けた専門家の軍隊をどこに置くか」という精神のコメントだけです。私は、即座の革命で爆発的な効果を期待するほど素朴ではありません。実のところ、私は世界で何かが変わるとはまったく確信していませんが、理性の勝利への希望を持っています少なくともそこにいる誰かをかき混ぜます。また、「作者がプログラマーではないことはすぐに明らかです」などの自己肯定に警告したいと思います。これは、既存のテクノロジーのフレームワーク内のコードではなく、テクノロジー自体の利便性と利便性に関するものです。正確にこの状況に慣れている経験豊富な視線の失明について。そして、世界をより良く、よりきれいにすることができるかどうか、そしてこれに必要なものについて。

この作品を読んでいる間、皆さんの注意と忍耐に感謝します。そして、このような長いプレゼンテーションをおaび申し上げます。いいえ、著者は統合失調症ではありません。私たちは両方ともこれを絶対に確信しています-私と著者の両方。 :)