「開発の進化」// Mail.Ru Technology Forum 2011のレポート：レポートのテキスト、ビデオ、プレゼンテーション

レポート「Development Evolution」で、Mail.Ru Technology Forum 2011から一連の復号化を開きます。 このトランスクリプトは、イベント当日、2011年11月16日に受信されました。 レポートを復号化するシステムの動作の詳細については、Mail.Ru Technology Forum：High-tech in event-managementの記事「Inside Out」を参照してください。

（モバイルデバイス用のビデオバージョンをダウンロードする -iOS / Android H.264 480x368、サイズ204 Mb、ビデオビットレート500 kbps、オーディオ-64 kbps）

（高解像度ビデオバージョンH.264 624x480、サイズ610 Mb、ビデオビットレート1500 kbps、オーディオ128 kbpsをダウンロードします）

（プレゼンテーションスライドのダウンロード 、2Mb）



Mail.Ru Group副社長、技術ディレクターVladimir Gabrielyanによる紹介

「同僚、ランチを楽しんだことを願っています。」 十分な栄養、親切、満足。 ツイート。 実際、次のスピーカーを紹介したいと思います。 すべての会社には、「ミスター・アイ・ノウ・ハウ」と呼ばれる人、すべての技術を知っている人、非常に正しい先見の明がある人がいます。グループ」。 これは、副テクニカルディレクターのイゴール・エルマコフ 、つまり私です。 本日、イゴールは、13年間にわたって当社のテクノロジーをどのように進化させてきたかについて説明します。このレポートを注意深くお読みいただければ、実際にお客様が既に通過した開発の段階をスキップして、それらのテクノロジーに直接進むことができますMail.Ruで使用します。 イゴール！

エルマコフイゴール：

-こんにちは、またここでお会いできてとても嬉しいです。来てくれてありがとう。 今日は、私たちの進化、開発についてお話します。 Volodyaの紹介にも関わらず、どうもありがとうございました。どうすればいいのか、それがどうだったのか、なぜだったのか、今どこにいるのかをお話します 進化とは何ですか？ ウィキペディアの古典的な定義は開発プロセスであり、突然の飛躍を伴わない開発プロセスであることが重要です。







これは革命ではなく、スムーズな変化です。 データストレージの側面における進化、ツールについてお話したいと思います。 ツールについて話すとき、私はエディターやあらゆる種類のユーティリティを意味するのではなく、言語とテクノロジーについて話します。 クライアント開発およびモバイル開発へのアプローチの変更についてお話したいと思います。







歴史への遠足。 98年目、古典的なLAMPプロジェクトであるMail.Ruの始まり、 Perl 、C、Apache 1.3。、それなし、classic、およびmod_perl 。 データをMySQL 、スマートワード： Nginx 、 NoSQLに格納します -その後はありませんでした。 ほとんどのWebプロジェクトは、これらの技術に基づいて構築されました。



スクリーンショットは、最初のデザインを示しています。 たぶん誰かが覚えている？ これもタコのデザインです。 はい、タコの最初のデザイン。

データ保存

MySQL 、なぜMySQLなのか？ 古典的なWebプロジェクトはその後MySQLで構築されたため、他のリポジトリについては話していません。 もちろん、メールには手紙を保存するための独自のサービスがあり、最初のバージョンはその時に作成されました。 データベース内の文字のデータは非常に非効率的です。 そのようなメールサービスの1つを知っていましたが、非常に不十分に終了しました。 彼らはすべての手紙をデータベースに保管しました。 誰もがその利点を覚えています-安価、シンプル、そしてもちろん、通常のWeb開発者向けの大規模な企業ソリューションと比較して-無料で、非常に多くのドキュメントがありました。 それにもかかわらず、MySQLの一部で構築されているため、よく知られています。 誰もが、フラットタブレットでのMySQLが非常に高いパフォーマンスを示したことを覚えています。ありがとうございました。 それにもかかわらず、マイナスのセットがありました。 マイナスのいくつかについてお話したいと思います。これは管理されていないキャッシュです。これは、テーブルを更新する際のクエリキャッシュのリセットです。







そして、データベースに問題があり、ハードドライブをキャンセルしてすべてをHEAPに入れるのが良いと思われます。 しかし、 HEAPテーブルの実装はMySQLでひどく、非常に遅いままです。 したがって、誰もが頭の中で持っていたソリューション-すべてをメモリに入れるために、 memcachedが表示されます。 彼は私たちに何を与えますか？ 非常に効率的なキャッシュ、非常に高速なストレージ、およびメモリ内のデータへのアクセスを提供します。 非常にシンプルで、1つの機能のみを実行します。 memcachedはまだハッシュであり、データを保存する必要がないにもかかわらず、memcachedは何らかのデータストレージとして使用されるようになります。 memcachedはデータストアではないため、これは悪いことです。 彼はあなたが何を入れたのかを覚える必要はありません;彼はキーがキャッシュされていなくてもいつでも削除できます。 最も重要なことは、メモリ内のすべてです。 データ、マシン、すべてで何かが起こった場合-データを失い、どこで入手できるか-不明であるため、ロールバックする場所がありません。 もちろん、MySQLレベルのデータとmemcachedレベルのレートの少なくともある種の信頼性を単純に取得して取得することは良い解決策です。 MemcacheDBのようなプロジェクトがひどく遅く、すべてが遅くなり、プルしなかったことを覚えています。 その結果、 NoSQLと呼ばれるソリューションがいくつかあります。







NoSQL それらは、生産性、実装データベースに負担をかける不必要な機能の欠如をもたらしました。 そのうちのいくつかは、スケーラビリティ、自動スケーラビリティ、および豊富な選択肢のための既成のソリューションをすでに提供しています。 Kostyaはタランチュラについて話し、おそらくRedisと比較しました。多くの人がApache Cassandra 、 MongoDBを知っています。これらはすべて特定の問題をカバーするNoSQLソリューションです。



したがって、私たちはメールではなく主に開発を使用しますが、ポータル、 Tarantool / BOXでは、Kostyaはそれについて多くのことを話しました。

開発言語：サーバー側

開発言語について話しましょう。 過去に戻ります-C ++ 、 Perl 、 C＃ 、 Java 、 PHP 、 ASP.NETを使用する環境のどこかに、すべてのテクノロジーが美しく、優れており、新しいPythonおよびRuby言語が徐々に登場します。







私の意見では、 Pythonが私の記憶に役立つなら1990年であり、 Rubyは1995年だからです。 しかし、ロシアについて話すと、彼らは人気を得ています。おそらくロシアで書かれたフレームワークのおかげで、Pythonを素早く効率的に開発できます.PythonはDjango 、RubyはRuby-on-Railsです。







フレームワークで最も興味深いのは、開発者がこれらのフレームワークに取り組むことに関与し、それによって開発者が改善、改善、つまり雪だるま式を開始することです。



その結果、Mail.Ruで今何をしているのでしょうか？ 今、Mail.Ruはコンパイルされた言語です。C++、もちろんPerlです。多くのPerlコードがあり、それをサポートし続けています。Javaです。 C＃を記述し、Pythonで記述し、Rubyで記述し、 Objective Cも使用します。誰かがKostyaに傍観した場合、多分、TarantoolでObjective Cを使用する理由を語ったでしょう。







一方では、これは技術動物園であり、多くの解決策があり、単一の戦略はないようです。 しかし、一方で、これらの技術のそれぞれが正当化されることを伝えたいと思います。 それぞれが特定の問題を解決し、アプリケーションに非常に理想的です。 そして、当社の開発において、新しい人員の採用にいくらかの変更があり、プログラマーに対する要件があります...開発者が来て言うとき、特定の「ホリバー」は本当に好きではありません。また、Pythonはファッショナブルだからクールです。」 そしてこの瞬間、私たちのインタビューで、そのような特定の光が点灯し、おそらくこの人に問題があることを示しています。適切なタイミングで適切なタイミングで使用する必要があるツールのセットがあり、プログラミング言語に関連しているからですツールと同じように、必要な場所に正確に使用してみましょう。

「クライアント」での開発

91年目、 HTTPの出現、テキストページ、最初のブラウザー、最初のHTTP要求。 画面上-Web開発者とのインタビューでの私のお気に入りの質問：最も簡単なHTTPリクエストを書いてください。 開発者は、多くの場合、HTTP 1.1から、HTTP 1.0から、たくさんのヘッダーを使って何かを書き始めます。 5文字と改行を1つだけ要求します。 一般に、私が知っているすべての最新のWebサーバーはすべて、0.9プロトコルを完全にサポートしています。 92年目、テキストブラウザーLynxの 1つが登場し、少し遅れてNetscape Navigator 3とInternet Explorer 3が登場しました 。 たぶん誰かは、これらがすでに強力なグラフィカルブラウザであり、まさにHTML 3.0を表示できることを覚えています。







90年代の終わりはMail.Ruの登場です。これはHTML、 Dynamic HTML 、 JavaScript 、 IFrameであり、クライアント側でクライアントと非同期で作業する最初の機会をもたらします。







つまり、ページをオーバーロードせずに、ページをオーバーロードせずにデータを更新できるようにするテクノロジーを手に入れることができます。 ちなみに、Microsoftは、私が正しく覚えていれば、最初にそれを使用して、そのサービスの1つの株価を更新しました。 少し後、 XMLHTTPコントロールがIE5に表示されます。 マイクロソフトに深く感謝し、 AJAXへの道を開きました。 繰り返しになりますが 、 Flashの人気は高まっています。 Flashは、クライアントのディスプレイにシンプルさと豊かさをもたらします。 ターニングポイントはカスケードスタイルシートの出現であり、新しいWebサイトの開発方法に何らかの秩序をもたらします。







Appleのおかげで、2000年代半ばは最新の物語であり、 WebKitの到来です。 彼らはHTML5に満足しています 。 WebKitはCanvas要素を提供します。これは基本的にHTML5の始まりです。 これは、すべての長所とユーティリティを備えたすべてのAJAXにすでに含まれています。 最後に、 Geckoエンジンで生まれたMozilla Firefoxの登場により、現在人気のあるブラウザープラグインテクノロジーであるFireBugが登場し 、Web開発を大幅に加速することができました。 多くの人がFirebugだけでなく、あらゆる種類の開発者ツールを使用していることを知っています。 JSフレームワークが表示されます。 ここでは、JSフレームワークとjavaスクリプトについて個別に説明します。 最初は、クライアントプログラマはどのように働いていますか？ 彼はレイアウトをPSDまたはJPGファイルの形式で取得し、それを切り取り、HTMLバインディングでラップします。テーブルがあれば、運がよければ、いくつかの歌姫がいます。すべてがうまくいきます。 最初にJavaScriptを起動します-これらはいくつかのフォームです。これはフォームの処理であり、これはそれらの検証です。 そして徐々に、ある時点でJavaScriptが非常に複雑になり、クライアント側のアプリケーションがサーバー側よりもはるかに多いことが明らかになります。







個々のJavaScript開発者が登場したとき、クライアント側のアプリケーションのみで作業する人々の空席とは別に、その転換点をよく覚えています。 繰り返しますが、このアプリケーションは多くの場合、サーバー側よりもはるかに複雑であり、サーバー上にデータを保存するだけの場合もあります。 今何があるの？ 現在、一般的に、すべてが私たちが望むほど良いとは限りません。ウェブ開発者ほど多くのブラウザ、5つのブラウザがあります。 もちろん、これはユーザーにとって素晴らしいことです。各ユーザーが最適なブラウザーを選択します。 現在、HTML 5とFlashの戦いを経験しています。何らかの形で、誰が勝つかわかりません。







繰り返しますが、JSライブラリーの全盛期： Prototype 、 jQuery 。 あなたが欲しいものを取り、使用します。 おそらく、2番目のサイトごとに、人気のあるライブラリの1つが見つかるでしょう。 こっち JavaScript開発者についての議論を続けると、かなり興味深い現象が現れます。サーバー側でJavaScriptを操作しようとする試みです。 NodeJSと呼ばれる特定のテクノロジーがあります。これについてすべてを聞いたことがあるので、サーバーを構築し、JavaScriptで記述できます。 これにより何が得られますか？ クロスプラットフォームコードでは、クライアントとライブラリのサーバー側の両方で同じ言語で記述できます。これらはクライアント用であり、それらの一部をサーバーで使用できます。 シンプルな構文を備えた優れたオブジェクト言語、非常に簡単です。 NodeJS Webサイトから取得したJavaScriptコードの例。いくつかの7行のWebサーバー実装を返します。







技術は非常に興味深い、有望であり、テストによると、パフォーマンスを引き出せず、エンジンには多くの問題があり、これまでのところ負荷では機能しません。 たぶん、私たちのものの上にもう少し小さいものが生きている-生きていない。 過去10年間でかなり興味深い結果が得られました。LAMPプロジェクトから始めて、10年以上で技術の層全体が変化していることがわかりました。







現在、私たちは新しいプロジェクトを行っています。その上で、古いテクノロジーはまったく使用していません。 そこでイベントエンジンを使用します。 私たちはMySQLを使用しませんでした。MySQLは存在せず、すべてがNoSQLデータベースに基づいています。 私たちのテストによると、実行によると、それが生きて機能していることがわかり、予想以上にサービスを構築するのが速くなっています。

モバイル開発

モバイルクライアントについて覚えて、モバイル開発について話しましょう。 ご存知のように、それはかなり前のことで、チャンネルの帯域幅が低く、かなり奇妙なマークアップ言語がありました。







何をサポートしていたこの電話のセットを推測することは決して不可能だったことは奇妙でした。 誰が写真を見ることができ、誰ができない。 どのタイプの写真を表示できますか、どのタイプ-できません。 フォーム送信がサポートされているかどうか。 いくつかのマイナーバージョンでサポートされているのに、次のバージョンではサポートされないのはなぜですか。 貧弱な電話機能により、ブラウザは完全に存在せず、プロセッサはありませんでした。すべてが非常に遅く悲しかったです。 時間が経つにつれて、 XHTMLが表示されます-組み込みのブラウザーでサポートされるようになります。 Windows MobileにおけるMicrosoftの大きな一歩です。 これはInternet Explorerであり、何らかの方法でページを解析し、HTMLを解析し、少なくとも一部のJavaScriptサポートを提供します。 60プラットフォームのNokia。 Operaはこの市場で多くのことを行ってきました。 彼らはすべてのモバイルデバイスに侵入し続けています。 おそらく、誰もが小さなクライアントのためにサーバー側に大きなサイトを表示するサービスを覚えていて知っているでしょう。



私の意見では、ある時点で、ターニングポイントがあります。有名な会社Appleのおかげで、iPhoneにSafariが搭載されています。 JavaScriptは、かなり興味深いアイデアをもたらします。 ページをスケーリングするための優れた使いやすさのソリューションを提供し、スケーリング、この大きなページの巻き戻し、小さなページ、大きなページ、そして再び小さなページの表示方法に問題はありません。







最も近い競合他社とフォロワーはすぐにそれを手に入れます。Androidの WebViewは、APIからのアクセス、優れたJavaSciptエンジン、Flashのサポートを備えています。



Androidについて個別に言いたいことはありますか？ それらのおかげで、APIからのサポートは優れており、ブラウザの作成、座ってすぐに書くことができます。 これにより、興味深い決定を下すことができます。ネイティブ提案がWebViewのスナップインのようなものであり、サーバー側からこのWebViewのコンテンツを既に制御している場合、Webベースのアプリケーションを作成できます。 つまり、何らかのレンダリングを記述する必要はありません。 繰り返しになりますが、iPadは次のモバイルブラウザを搭載し、SamsungはBadaを搭載し、Windows PhoneはInternet Explorerを搭載しています。これはIEに基づいています。



何を言いたいですか？ もちろん、それらはすべて自分自身であるという事実はクールですが、1つの非常に大きな問題をもたらします-それらの多くがあり、私たちはそれらをすべてサポートし、忘れないようにする必要があります。 さらに、モバイルデバイスの開発に加えて、このような興味深い効果が得られます。原則として、大型デバイス向けに設計されていないサービス、人気のあるサービスがあります。 私はリストしませんが、確かにあなたが知っているものはありますが、それらは原則として使用するのが面白くて便利で、モバイルデバイスでのみ人気があります。

結論

一般的に、悪い知らせがあります。 わずか10年で、すべてのテクノロジーが完全に変わりました。 今、あなたがウェブサービスを書くために座って、あなたがそれを書くなら、あなたは全く異なる技術を使います。 これは、常に新しいものが表示されるため、勉強を続け、会議に出席し、本を読み、フォーラムを読み、レポートを聞く必要があることを意味します。 高性能サービス、彼らは選択を非常に要求しており、出現する豊富な技術はしばしば問題を解決しないが、それを作成します。 選択肢が多すぎて、間違いを犯しやすく、問題を実際に解決できないものを選ぶのは簡単です。 今日の典型的なWebサービスの最小セットは成長しています。 以前の場合、Webサーバーの例について話します。Apacheを使用して、そこにあるすべてのものを処理した場合：写真、スクリプト、すべてすべて、Apacheの場合は、独自のApacheがあります。 、アプリケーションを提供する別個のApache（スクリプト言語で記述されます）、静的を提供する別個のWebサーバー、Apacheの前にある同じNGINXを確実に配置して、負荷を軽減します。 サービスを構築するためのレンガは、ますます専門的になっています。



良い例は、優れたキャッシュであるmemcachedです。これは完全に内部的にテキストに基づいていますが、すべてがテキスト表現で保存されます。 優れたキャッシング。使用する必要がなくなりました。 memcachedを使用してから、そのアプリケーションのいくつかを忘れました。



繰り返しますが、デバイス、アクセス許可、ブラウザー、エンジンのリストは壊滅的に拡大し、それぞれのレンダリングは異なって機能します。 解像度に関しては、一般的に興味深い話があります。覚えているなら、古いウェブは640 * 480で始まり、それから1024-1024の後のかなり長い間、800 * 600です。 そして最も興味深いのは、ページを完全にレンダリングする新しい携帯電話のおかげで、640 * 480および800 * 600に徐々に戻っていることです。 したがって、以前の許可に戻り、何らかの形でページを表示する方法について理解します。 最も重要な問題は、サービスを数年にわたって成功するように計画する場合、平均して3年に1回完全に書き換えることに留意してください。 同じメールを例にとると、クライアントを本質的に完全に3回書き直したと言えます。 そして、これは設計によるものではなく、新しいテクノロジーの出現によるものです。



新しいテクノロジーは速度の新しい要件を与え、ユーザーがチャネルを拡張すると、ユーザーがモデムを持っているという事実によって低速なサービスを正当化できなくなります。 サーバーで1秒以内にページを収集することは問題ではなく、5回ダウンロードします。 今、0.5秒はすでに敏感です。0.5秒は親切にしてください、しかしページを与えてください。 したがって、あなたは常にこのレースに参加し、絶えず加速し加速する必要があります。 さらに、新しい技術-非常に良いフィードバックです。 たとえば、同じAJAXなどの新しいテクノロジーは、新しいITソリューションを提供します。 しかし、基本的にクライアントサイトを変更するだけのこのAJAXを実装するために、ページはオーバーロードしませんが、それは悪いように見えますが、ページはオーバーロードせず、非常にクールで、最小限のデータがネットワーク上で追跡されます。 ただし、通常の書き込みを行うには、サーバー側で通常のAJAXサポートが必要です。 つまり、実際にサーバー側のコードを完全にリファクタリングします。 一般に、この速度が向上しない場合は、平均して3年ごとにサービスを書き換える準備をします。







どうもありがとうございました。ご質問をお聞かせください。

ホールからの質問

あなたはあなたがどのように開発したかについて話しました。 いくつかの技術を待っているかどうかを知りたいのですが、たとえばタッチスクリーンが突然表示されるなど、それらの準備はありましたか？ つまり、遠い年に発明されたのは明らかですが、デバイス上ではなく、何かに使用するために表示されるのを待っていた、または「ああ、かっこいい！ タッチスクリーン「または」がありました。 加速度計が登場し、どうにか使用できます。 つまり、テクノロジーの期待に関する計画の中に、何かがすでに発明されていたり、すべてが自発的だったりして、一部のメーカーがいくつかの新しいソリューションを「移動」する可能性が高いという計画がありましたか？

はい、答えようとします、あなたの質問を理解しました。 私たちが座ってクールなものを思い付くわけではありませんが、宇宙の例を挙げるためにがん細胞を数えますが、あなたのサービスでクールなバッテリーがあれば素晴らしいでしょう、それから私たちはがん細胞を一緒に数えます、CPUを完全にロードしますが、携帯電話に小さな原子炉が搭載されるまで待ちましょう。これで終わりです。 しません 私たちは、メーカー、ハードウェアのメーカー、ソフトウェアのメーカー、大手メーカー、同じサムスン、同じノキアと協力しています。 彼らは彼らのベストプラクティスのいくつかを私たちと共有しています。製品の次のバージョンがどのように機能するかを議論します。

こんにちは、Line MediaのIlya Pyatinです。 実際、インターネットテクノロジーの開発の特定の歴史を耳にしましたが、このレポートは「開発の進化」と呼ばれていますよね？ そして、開発、それは技術だけで構成されていないのですか？ これらは、開発者、あなたが持っているいくつかのチーム、はい、展開、バージョン管理などです。 それがどのように発展したか聞いていただけますか？ 多くの場合、これは使用されているテクノロジーよりもさらに重要であり、どういうわけかそれについて何も言われていません。 そして、少なくとも歴史の全期間ではなく、これらの技術のどれを好むのですか？しかし、今...あなたはリストされたものをすべて使いましたか、またはあなたは優先順位を与えましたか？ ありがとう

私たちが好むテクノロジーについてご覧ください。 ここでは、どうやら彼は自分の考えを不十分に表現した。 したがって、アプリケーションのツールが大好きです...そして、多くのサービスがあるため、メールの保存、ソーシャルネットワークの表示、2人のメッセンジャーサブスクライバー間のVoIP通信の提供に同じテクノロジーを使用することはできません。 したがって、技術はありません。 私たちは長い間進化し、最終的に成長し、今ではどこでも使用していません。私たちはあなたと一緒に、他の会社の同僚は進化しています、私たちは市場にあるすべての開発を見ています、どこかでそれらを適用しようとしています私たちは試みていますが、私たちにはチャンスがなく、彼らは私たちに全く適用できないことがわかります。 そして、唯一の技術はありません。 展開、監視、および運用に関する話をする場合、これは非常に長い議論です。 これについてはまったく説明したくありませんでした。これは、監視における展開方法、展開における展開方法、適用方法、適用しないルール、そこで使用するルール、コミットを適用するルール、パッチ。 これは非常に長い議論であり、個別に話し合うことができます。

こんにちは、こんにちは。 私の名前はアレクセイ・シシキンです。 次の質問があります。 あなたの意見では、拡張現実で完全に市場に参入するために欠けているもの。 かつて、iPhoneにはSafariが搭載され、モバイルデバイスでサイトを見ることが可能になりました。 あなたの意見では、拡張現実には何が欠けていますか？ ありがとう

この技術についてもう少し教えてください。

拡張現実とは、現実の世界には存在しないが、アプリケーション内のクライアントの位置で受信したデータから生成されたオブジェクトの、電話などの画面上の表示です。

あなたが知っている、私はあなたの意味を理解しています。 少々お待ちください。 鉄はまだ準備ができていません。

質問してもいいですか？ 5ポイントシステムの観点からレポートを評価するように依頼された場合、私はそれを評価しませんでしたが、見事に書きました。

ありがとう

それが理由です。 物語を知る必要があるからです。 そして、インタビューについてあなたが言ったことは、私が時々学生から試験を受け、同じアプローチで答えに近づいたので、それは私を少し道徳的に支えました。 いくつかのオプションを議論する必要がある場合。 しかし、実際には、用語は絶えず変化しており、時にはすべてを調べる時間がない場合があります。 しかし、データベースに戻ります。 そのすべてがほとんど回転しています。 実は、コンスタンチンもあなたに話し、実装データベースにはまだ独自のニッチがあり、誰もそれらをキャンセルしないと言っていますが、まだ新しいSQLがあります。 ここで、何らかの形で定義を決定するようにお願いします。多分、すでに変更できます。 思い出してください、リレーショナルデータベース、リレーショナルデータモデルがやがて勝ち、何らかの理由で勝ち、階層ネットワークの前に進化したためです。 しかし、次の2つの定義があります。進化データベースがフラットテーブルと対話することを意図した場合の単純な定義と、リレーションという単語からのより数学的な定義です。 これは、相互作用する現実世界のオブジェクトをモデル化するためです。 まず、この関係について、2番目のSQL言語には独自の豊富な開発の歴史があり、いつ... SQL言語は、データベースの主な作業を決定するいくつかのサブ言語で構成されることが知られています。 ここで決めてください。

適用可能性の判定などについては、おそらく各ツールを繰り返します。 ありがとう、あなたは私の報告書を非常に注意深く聞いてくれた。私はC言語から始めて、それについて書き続け、そして書くと言った。 , , , , , . , . , . 13 , , , . , .

. : - ? , . ?

, . - , . . , , : , . , , , . . ?

?

, , , , , .

, . . «-». , , , WinBse-, noSQL, , ? ?

, Python

-?

いや

, .

, , 10- . , -, mail.ru Perl-.

. ....

, mail.ru, -Perl.

, . - Perl. : « - , Perl». , , , Perl, , . , .

, . . , , : « ( ), ?»

. , ...

, , . - ?

. , , Tarantool. Tarantool . , Tarantool. . memcached, memcachedb, Tarantool, memcached, memcachedb , , , , . Redis, , . : , , … Tarantool , Tarantool!, , Tarantool.



Tarantool, , , , , , Tarantool , . . : , , , , . MySQL. . - ? いや , MySQL . . , . , , . , , , , , , , , , , , … , . , 9 . MySQL - - . . - , «» , , . . , , .

, . . . , , . , ? WML, - .

. , WML- , . . WML-, , WML, XHTML .

! . . , , , . , , - . , , . , , , - . , . , ? , , 20%. , - , . . - ?

. , , .

, , , ? - ?

, «-», , Tarantool — open-source , , - , «» , . , open-source , , , .

, , - ?

?

, , , , .

, , .

, «». . ?

, ? ?

? NodeJS, . , -, «» NGINX, «». , API, , .

, - , « », «API », « NGINX», , , , API , , , Nginx, - , … ,

Mail.Ru , NodeJS ? ?

- , -, . , , . ?

, PHP, enterprise-, , , .

, ? , - , - , , , , API, - . deprecated . PHP.

JS . , , , -.

, . , - , . , , ! , , , , , . , - .



, NodeJS, Java 1.0. 1.0 , Java 1.0 6- , , ! , Java? ? , ? , ? : « », ? , - . : «, ». , , .



, .

, . .



, , , . , . «» ? : «-, NodeJS , ». , ? , , 20% , «» - , «» ?

-, , . . , , , «» , , . core dump, «» , , .

, .

, . . - , . - , - , - , - .

, .

, , .

ありがとう

, . . , . , . , , . , , , .

, .

---

このテキストは、Infospace Centerで11月16日に開催されたMail.Ru Technology Forum 2011でのIgor Ermakovのレポートの転写です。ビデオレポートテキストを作成するための技術の詳細については、こちらをご覧ください：Mail.Ruテクノロジーフォーラムの裏側：ハイテクイベント管理。他のレポートのビデオバージョン（モバイルデバイス用のバージョンを含む）は、フォーラムWebサイトtechforum.mail.ruで入手できます。レポートのテキスト版は、ここおよびフォーラムのWebサイトで毎週またはほとんど同じ頻度で発行されます。テキストのタイプミスについてPMでお知らせください。