Yandex.Maps APIの作成者からの悪いアドバイス。 すべてを悪くする方法

あなたを追いかけるなら

人が多すぎる

詳細に尋ねる

彼らはどのように動揺していますか？

皆を慰めるようにしてください。

みんなにアドバイスを

しかし同時に減速する

絶対に何もない。

G.オスター

今日は素晴らしい春の日です。 それは春だけでなく、すぐに誰かがジャガイモを掘るために国に行かなければならないからです。 そして今日、Yandex.Maps APIのバージョン2.1はベータ版ではなくなり、メインバージョンになりました 。



このイベントのために、ドキュメントを完全に更新し、サンドボックスに新しい例を追加して、この記事を執筆しました。 今回は、ベータ版のリリース時に既にバージョン2.1について十分に話し合っていたため、バージョン2.1だけについては話さないことにしました。 一般的なYandex.Maps APIの使用について話しましょう。



API開発は非常に特殊なプログラミング領域です。 APIユーザーのニーズとスキルは、デザイナーと開発者のアイデアに重なっています。 私たちが受け取る主なフィードバックは、クラブのユーザーメッセージです。 Yandex.Mapsを使用したサイトの例、バグレポート、および製品改善のための推奨事項を送信します。 戦闘状態でAPIがどのように見えるかを確認し、口ひげをいています。



いくつかのことが間違っていることがよくあります。 今日はそれらについてお話したいと思います。 あなたが読むすべてのヒントは有害です。 この記事の推奨事項のいくつかを順守していることに気づいたら、大丈夫です。プロジェクトを少しでも良くするのに遅すぎることはありません。 したがって、アイロニーモードがオンになります。

いかなる場合でもユーザー同意書を読まないでください

何世紀にもわたってWindowsを使用してきた経験が、私たちに何かを教えてくれました。 私たちはユーザー同意書を読もうとさえしていません。 私たちは大胆に言う：「私はすべてに同意します」-そして、カルマの報復は私たちを追い越すことは決してないと思います-「彼らは馬鹿ですか？ 「私のシリコンウィンドウからGus Khrustalnyに移動して、海賊版Windowsの使用を禁止するのですか？」

Yandex.Maps APIを使用する場合、同じ戦略に従う必要があります。



ユーザー同意書を読んだ場合、APIにクールなアイデアを実装することは違法であることが理解できるためです。 たとえば、車両監視を行ったり、管理パネルのAPIを使用して1Cにしたりすることはできません。 または何か悪い。



したがって、作業を開始する直前に設定を行います。契約を読んでいない場合、基本的に制限に気付かないため、地図作成の世界は無限です。 もちろん、マイナス面もあります。違反が検出された場合、サイトでAPIを禁止できます。 しかし、ご存じのように、問題が利用可能になったら解決する必要があるため、静かに進んでいます。



一般に、理想的なオプションは、Webサイトを作成し、顧客に提供し、正直に稼いだ給与を得て、それを永遠に忘れることです。 手数料の額が多かった場合は、居住地を変更することをお勧めします。 それでも、お金は人々をだめにします。

あらゆる種類のドキュメントを読むことは避けてください。

ご存知のように、優れたコードにはコメントは必要ありません。 同様に、優れたAPIにはドキュメントは必要ありません。 一般に、ライブラリまたはモジュールは直感的である必要があり、理想的なAPIはプログラミングスキルを必要としません。 したがって、サンドボックスの例を参照したり、マニュアルのAPI機能について何か読んだり、さらにディレクトリ（！）を調べたりする場合は、衝動的に戦ってください。 適切な戦略-ランダムに1つの例を選択し（できれば最も詳細ではない）、心の呼び声を聞く-それはあなたに書く方法を教えてくれます。



したがって、アプリケーション開発を開始する前に見てはいけない場所：

• 開発者ガイド
• サンドボックスの例
• プログラムインターフェイスリファレンス

JavaScriptのことを心配する必要はありません。

ご存知のように、JavaScriptプログラマーはプログラマーではありませんが、タイプセッターです。 使用したいAPIはJavaScriptで記述されているという考えと混同しないでください。 この言語の構築を研究すると（もしそう言うことができれば）、他の言語から重要なものを忘れてしまい、混乱し、すべてが無駄になります。



理想的なオプションは、PHPを使用してJavaScriptコンストラクトを印刷することです。 例を挙げます。

<?php foreach($maps as $map): ?> myPlacemark = new ymaps.Placemark(["<?php echo $map['lantitude']; ?>" ,"<?php echo $map['longitude']; ?>" ]); myMap.geoObjects.add(myPlacemark); <?php endforeach;?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JavaScriptがどれだけ優雅に使われたかをご覧ください！



このアプローチにより、多くの不快な結果を避けることができます。

• アプリケーションは、ユーザーに人生の意味を考える時間を与えるのに十分な速度で実行されます。
• コードは最初から非常に混乱しやすいため、難読化は必要ありません。
• ページコードはブラウザによってキャッシュされませんが、サーバー上で毎回生成されます。

多くのプログラマーがまだシステムに逆らおうとしているのは残念です。 彼らは、純粋でよく構造化されたJavaScriptでコードを書きます。 同じURLにデータをバッチでロードし、ブラウザーのキャッシュを詰まらせます。 その結果、アプリケーションは高速であり、ユーザーはそれを当然のことと見なし、他のサイトを見ることさえしません。 若い世代について考えてみましょう-学童が青春を過ごすウェブサイトの作成をやめ、インターネット依存症のない人類を解放しましょう！



JavaScriptアプリケーションを開発することに決めた場合、読む価値のない本 ：

コードの構造化を避ける

ロケーションマップよりもやや複雑なことを行う予定がある場合は、サイトのアーキテクチャを検討することが思い浮かぶかもしれません。 コード内のコンポーネントを強調表示したり、クラスを作成したり、コードを関数に分割したりすることもできます。



これは、いくつかの理由で実行しないでください。

• モジュール化されたコードは、コマンドの順序が乱れているため読みにくいです。
• アーキテクチャの開発には多くの時間がかかります。
• カードを使用するアプリケーションは、単に時間と注意を払うだけの価値はありません。 ポイント。

マップを使用してアプリケーションを開発する際に避けるべきこと：

• コードをクラスまたは関数に分割する必要はありません。
• モジュラーシステムを使用しないでください。RequireJSは必要ありません。
• 異なるファイル間でコードとデータを分離する必要はありません-多くのファイルがある場合、それらは混乱しやすいです。

残念ながら、これらのアプローチを使用する例があります。 サンドボックスでその不条理を確認して評価できます。

 //   . ymaps.modules.define('CustomModule', function (provide) { var CustomModule = function (defValue) { this.field = defValue; }; provide(CustomModule); }); //  . ymaps.modules.require(['CustomModule']) .spread( function (CustomModule) { // ... }, this );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バージョン2.1では、API開発者はAPIで使用されるモジュラーシステムを開くことにより、文字通りトラップを設定しました。 今では、気の弱い開発者はそれを我慢できず、コードをモジュールに分割できません。 勇気を出しなさい。



完璧なコードを書くのを妨げる可能性のある本は、inな人々によって書かれています。 彼らの価値体系は逆さまになっています。 敵は本人に知られている必要があります。潜在的に危険な出版物の一部を以下に示します。

事前にすべてを準備する

マップ上に多数のオブジェクトを表示する予定がある場合は、サーバーからクライアントにデータをダウンロードするポイントを決定する必要があります。 唯一の正しい方法は、マップを表示するページのコンテンツを読み込む前に、できればすぐにデータをダウンロードすることです。 自分で考えてください-今ではない場合、いつですか？ 人がインターネットをオフにすると、タグが叫びました。 すべてのプログラマーがこの単純な真実を理解しているわけではなく、オンデマンドでデータをダウンロードしようとしています。



以下は、オンデマンドでデータをタグバルーンにロードする方法を示す悲しい例です。 これは 、オンデマンドでマップを作成する方法を示す別の悲しい例です。 そして、これらの開発者だけが当てはまらないもの...

在庫ありでダウンロード

APIは、モジュールとパッケージに分類される多くのコードです。 サイトを開発したら、別の重要な質問を解決する必要があります。どのAPIコードをサイトに接続するのですか？



ここで、コーラの缶のために友人を送ったときのケースを思い出すのは悪くありません、そして、彼は1をもたらしました。 まったく同じルールがコードのロードに機能します。 APIコード全体をダウンロードすることをお勧めします。何が役立つかわかりません。 バージョン2.0では、開発者は、ユーザーが迷わずにサンドボックスからサンプルをコピーした場合に誤って使用を開始する可能性のあるパッケージを作成しました。







このようなエラーを回避する方法は？ バージョン2.0を使用する場合、ロード可能なモジュールの任意の組み合わせをpackage.fullに変更する必要があります。 このアプローチでは、ユーザーはより多くのコードを取得できます。これは良いことです。



バージョン2.1では、開発者は残念ながら、人々が挑発に屈しなかったことを検出し、API全体をロードしました。 したがって、バージョン2.1では、パッケージは完全にキャンセルされ、package.fullは必要に応じて非同期にロードされる部分に分割されるようになりました。

パッケージの代わりに、使用する単一のモジュールを接続できるようになりました。 通常、何の準備もありません。







プログラミングは難しくなっています。

コントロールを追加する

マップ上にボタンがある場合、ユーザーは常に満足しています。 誰がボタンが嫌いですか？ ボタンはすべてが大好きです！ バージョン2.0のサンドボックスからサンプルをコピーして、使用可能なすべてのコントロールの動作を示し、サイトにコードをそのまま追加できます。







経験豊富なユーザーは、すべてのコントロールがこのマップに表示されるわけではないことに気付くかもしれません。 不注意なプログラマーは、2つ目のズームコントロールと検索コントロールをマップに追加するのを忘れていました。 ところで、以前のこの例には、一度に2つのスケールコントロールが含まれていました。 そのため、すべてが正常に機能するサイトを定期的に検索します。マップ上には、大小両方のコントロールなど、必要なものがすべてあります。 例を悪化させるのになぜかかったのかは、今日まで謎のままです。



バージョン2.1は再び私たちを時流に乗せました。 コントロールが少なく（悪役がミニマップをソーティング）、デフォルトでマップにインストールされ、小さなマップでは小さなサイズに折りたたまれます。







自分で見てください-ボタンはほとんどなく、ボタン自体は小さいです。 通常、マップは裸です！ 一般に、2.1は一般に使用しない方が良いです。

ユーザーにブラウザの弱さを見せます。

マップ上に数百または数千ものオブジェクトを表示する必要がある場合は、気軽に戦闘に参加してください。 タグを作成し、勇気を持ってカードに完全に適用します。 十分な数のタグを使用すると、世界のボスであるユーザー、つまり人またはブラウザーをすぐに表示できます。 多数のタグ（IEの場合は100、他のすべての場合は500）を使用すると、ブラウザはうなり声を上げて無期限にフリーズするためです。 だから彼はそれが必要です。



ブラウザの欠陥を隠そうとする開発者は、非常に洗練された方法で欠陥を隠します。

• オブジェクトのクラスタリングを使用します。 この独創的なテクニックの多くの例 、さらには記事全体を捧げてきました。
• アクティブエリアの技術を使用します。 開発は複雑ですが、表示されるオブジェクトの数に関する制限はなくなります。 開発者のガイドを読むか、サンドボックスの例を見て、計画の陰湿さを評価できます。

ジオコーダーのリクエストを保存しようとしないでください

多くの場合、ユーザーはこの問題に直面しています。 店舗、薬局、アトラクションなどの住所のリストがあります。 これらの住所はすべて地図上に表示する必要があります。 タスクは簡単に解決されます。すべての住所を取得してクライアント側に送信し、住所をクライアント上のラベルの座標にジオコーディングするだけです。



準備のできていない読者は、「ラベルのセットが同じであり、アプリケーションの各アプリケーションが各ユーザーによって再度呼び出されるたびにジオコーディングされることは正しいですか？」と尋ねることがあります。 この質問に直接答えます：「心配しないでください。」 Yandexサーバーは非常にフォールトトレラントであり、すべてに耐えることができます。 唯一の問題は、サイトからのリクエストが多数ある場合、ジオコーディングのリクエストの上限である25,000を超えると、サイトが禁止されることです。 しかし、私たちはすでにこの問題を上記でカバーしているので、ささいなことで頭を散らしません。



この記事を読んでおらず、Yandexサーバーの能力を信じていない開発者は、サーバー上のジオコーディングデータを思いついています。 また、従業員の1人が、node.jsでサーバージオコーディング用のモジュールを作成しました。 これは、開発者ガイドのトピックです。







そしてそれは怠ではなかった...

テクニカルサポートからパンを取らないでください

ある時点で、Yandex.Maps APIテクニカルサポートサービスとチャットしたいという奇妙な欲求を感じるかもしれません。 このイベントは、とにかくではなく、真剣に受け止める必要があります。



不要な詳細を含むテクニカルサポートサービスを読み込まないようにしてください。 理想的なバグレポートは5つの単語で構成されています-「すべてが壊れていますが、何も機能しません」。 一般に、当社のテクニカルサポートサービスでは、これら5つのキーワードを「1つすべてが常に機能している」という1つに長い間短縮してきました。 そして今、サポートと開発者の両方が物事の本質を即座に理解するための用語があります。



クラブに連絡する良い例は次のとおりです。







このメッセージを見た開発者は、彼のすべての仕事が腐敗しやすいことを即座に認識します。 宇宙はビッグバンから現れ、膨張し、崩壊しようとしています。 すべてなくなりました。 何も動作しません。



技術サポートまたはクラブに連絡する際に避けるべきこと：

• 問題の詳細な説明。
• バグを再現できるコードを提供します。
• バグが再生されるページへのリンク。

開発クラブに問題について書きたい場合は、検索を使用しないでください。FAQの回答を読んで、他の方法で問題の解決策を見つけてください。 考えてみてください-誰もが質問に対する答えを自分で見つけたら、テクニカルサポートワーカーは何をするでしょうか？

おわりに

それが私たちが話したかった悪いアドバイスです。 一般的に、あなたの典型的な間違いは私たちの仕事です。 開発者がAPIを使用するときに同じレーキを踏む場合、これはある程度私たちのせいです。 おそらく、ケースを提供しなかった、いくつかの例を書いた、不十分に作成されたドキュメントなど、など。 特に、バージョン2.1では、人がバージョン2.0よりも間違いを犯しにくくするようにしました。 そして、この方向の作業は屋根よりもさらに高くなります。



私たちの記事を心に留めて、あなたのプロジェクトを改善し、私たちに良い怒りの願いを送らないでください。 すべてが壊れていて何も機能しない場合でも、すべてを説明して教えます=）