「春を学ぶことはナンセンスなレッスンです」-プロジェクトのインテリアキッチンの春の主な伝道者、ジョシュロング

今日、私たちの仮想スタジオで、世界で最も有名なSpringスピーカーはJosh Longです。


彼の報告は世界中でJava会議を開いています。 コミュニティの質問に答えるのは彼で、YouTubeでSpring Tipsをやっています。毎週読んでいるのは彼の「今週の春」です。


ところで、ジョシュは私たち自身の「今週のJava」ですべての素材を使用することを許可しましたが、彼はこのデータを「15分ダイジェスト」形式に圧縮することができなかったほどのボリュームと深さでそれを行います。


時々、彼はすべての都市に同時にいて、レポートを読んだり、記事を書いたりしているようです。 今日は、彼がそれをどのように行うかを理解します。 「コードの順化」、Springの驚くべき生存性の理由、そして彼がゼロからのグローバルな書き換えやその他の興味深いトリックなしで何年も生きてきた方法について学びます。




会員


Josh Long、Pivo​​talのSpring Developer Advocate


Evgeny Trifonov、Oleg Chirukhin-JUG.ruグループの編集者



多くの人が旅行することを誰もが知っていますが、昨年訪問した会議の数、フライトの数など、統計情報を提供できれば興味深いでしょう。



いい質問です。 私はその年に出席したすべての会議を記録するテーブルを持っています。 アシスタントのTashaが、スケジュールとこのテーブルの整理を手伝ってくれます。 それでは、電話でこのプレートを開いてみましょう...二百四十。 2018年、現時点では、240の異なるイベントに参加しました。 これらの会議のいくつかはオンラインで行われますが(私たちの会議のように)、私はほとんどに飛ばなければなりません。 今年、私は50万マイル以上飛行しました。 地球から月までの距離を確認してみましょう...それは23万9千マイルなので、月に行ったり戻ったりすることができます。



「月へと春から帰ります。」 トールキンの本の良いタイトル。



あなたはそんなに飛ぶので、航空会社はあなたに特別なオファーを提供しますか?



まあ、私はサービスについて文句を言いません。 私はよくユナイテッド航空で飛んでいますが、彼らにはグローバルサービスプログラムがあります。 あなたは招待状を受け取ることによってのみそこに着くことができます-あなた自身がそれを自分で求めることはできません、そしてそれがどんな基準を持っているかは不明です。 毎年、最も頻繁に飛ぶ人を招待します。 昨年、誰かが世界中の最も頻繁な顧客の1%を選択すると言いました。 または、コストの量でフィルタリングすることもできます。 いずれにせよ、彼らは私をとてもよく扱ってくれます。 いいね しかし、この場合でも、ほとんどの人にとって、フライトは負担になると思います。 それは間違いなく私に関係しています。 私はフライト自体のために飛ぶのではなく、Springを使う人々に会うために。 そのような機会があればテレポートします。 人生はもっとシンプルで面白いものになるでしょう。



Hyperloopを待つ正当な理由。



はい、しかしこれは長い時間待たなければなりません。



Springに近いトピックについて話しましょう。 あなたはそれについて世界中の人々と話します-その有病率に地域的な違いはありますか?



私は言いません。 Springは常に100%オープンソースであり、インターネットで動作するソフトウェアを作成している限り、Springは世界中で成功し続けます。 確かに、地域の特異性が顕著である他のオープンソースプロジェクトがあります。 現在統計を確認することはできませんが、ロシアではGridGainが非常に一般的であるように思われます。



はい、そうです。



中国では、MyBatisは非常に人気があります。 アメリカとヨーロッパでは10年も見ていませんが、中国では春と同じくらい一般的です。 そして実際、MyBatisには何の問題もありません。それは高速で強力です。



MyBatisがGridGainと連携するプロジェクトを行いました。



(笑)だから、あなたはそれらの両方を使用します-素晴らしい! 私はこれらのテクノロジーの両方が好きです。 MyBatisに対する通常のサポートはありませんでした。私は中国のさまざまな大企業に素晴らしいことを常に依頼していました。なぜ彼らはSpringでMyBatisを必要としたのですか。 他にも多くのオプションがありますが、Hibernateは非常にうまく機能し、MyBatisは実際には西洋では使用されていません。 結局、プログラムを使用したら、その正常な動作を確保する必要があると判断しました。 MyBatisのSpring Boot Starterのソースを見ると、そこに私の名前が表示されます。 東でこのプログラムを必要とする人々がそれで正常に動作できるようにしたかった。 一般的に、私の仕事のかなりの部分は、旅行中にさまざまな国で発見した種類に由来しています。



あなたは、SpringプロジェクトのPivotal Developer Advocateです。 これは実際にはどういう意味ですか? 正確に何をしていますか?



難しい質問です。 Developer Advocateの概念は、Apple、特にMicrosoftのおかげで広まりました。 約30年前、Microsoftが本当の強さを持っているのは開発者だと気づいたときに始まりました。 プラットフォームを成功させて便利にしたい場合、開発者はこのプラットフォームで新しい価値あるものを作成する必要があります。 したがって、プラットフォームの利点を彼らに納得させる必要があります。 マイクロソフトは、さまざまな方法で開発者を動機付けようとし始めました。 彼らはVisual Studioを非常に安くしました。つまり、手頃な価格のツールを提供しました。 彼らは、Windowsで作業できる多くの非常に興味深いAPIを作成しました。 一般に、Microsoftはコミュニティとの共同作業が必要であることに気付きました。 人はソフトウェアを信用しませんが、他の人は信用します。 人々はソフトウェアに対する感情的な愛着を持っていません。 ホテルの部屋で孤独にプログラムを書くだけで有名になり、それを必要とする人なら誰でもドキュメントを見つけることができるのは好きなだけ想像できます。 しかし、実際にはこれは通常起こりません。 私の責任の重要な部分は、コミュニティの人々とのコミュニケーションです。 私は人々の言うことを聞いて開発者に伝え、開発者の言うことをコミュニティに伝えます。 言い換えれば、私は一種の乗り物です。

Springチームは奇妙で美しいです。 彼女はすでに10年半以上です。 最初は、彼女は非常に小さく、開発者自身がコンサルティングに従事していました。 彼らは常に他のチームと協力し、独自のソフトウェアの作成を支援しました。つまり、実際の問題を解決し、象牙の塔に閉じ​​込められませんでした。 彼らは、どのソフトウェアが必要であるかを前もって知るふりをしませんでしたが、他の人が本当に必要とするものを書き、彼らの利益は常に彼らの主要な基準でした。 彼らはクライアントと問題解決の苦しみを共有しました。 役に立たないものを作成しません。 そしてこれは、ご存知のように、ソフトウェアを作成する際にしばしば問題になります。 実際、最初のSpringチームは既に開発者支持者で構成されていました。 それらはプログラマが通常表すものとは似ていませんでした。 はい、彼らは才能のある開発者でしたが、同時に彼らは自分のアイデアを他の人々と熱心に話し合い、プレゼンテーションに出席し、人々に会い、知り合いを作り、対話を行いました。 これにより、Springはすぐに大きな人気を得ました。

問題は、このアプローチがうまくスケールしないことです。 すべての開発者が、旅行、チャット、および会議の時間の半分を費やすことは不可能です。 私がチームに参加した時点で、Springはオープンソースプロジェクトであるため、すでにSpringのコードを書いていました。 さらに、私はすでに本を出版し、記事を書き、プレゼンテーションを行いました。 ですから、私はすでにSpringをできる限りコミュニティに紹介し、できるだけ多くの人々にSpringを知ってもらう機会を与えようとしました。 そのため、Springチームは私にすべて同じことをするように招待しましたが、継続的かつ金銭的です。 私は80%が開発者擁護者であり、20%がプログラマーであると思いますが、残りの開発者擁護者チームは20%および80%がプログラマーです。

全体として、私の仕事はコミュニティと連絡を取り合うことであり、これを行うにはさまざまな方法があります。 私は私の6番目の本を書いています、それはリアクティブスプリングブックと呼ばれています。 私の以前のものは、クラウドネイティブJavaと呼ばれるO'Reillyによって公開されました。 Safari Books Onlineで見ることができるビデオチュートリアルを多数作成しましたが、それぞれ4〜5時間かかります。 さらに、毎週水曜日に、YouTubeにSpring Tipsビデオを投稿します 。各ビデオは、エコシステムの特定の狭い側面に特化しています。 それらは通常45分から1時間続き、毎年少なくとも2シーズン、時には3シーズンを行います。 したがって、毎年、2週間ごとに、会議での完全なレポートに十分な資料を準備しています。 2011年1月から毎週火曜日に、例外なく、 「今週の春」という新しいブログエントリを作成します。このブログエントリでは、エコシステムで最も興味深いものすべてを確認します。 私は他のブログも運営しています。最後の2晩はちょうどそれをやっています。 さらに、私はコードを書き、会議で講演します。 したがって、私の仕事にはさまざまな活動が最大限に含まれていますが、自分の活動を1つに制限することもできます。 ブログを書いたり、動画を作ったりする人がいますが、彼らはとてもうまくやっています。 一部の人は旅行すらしませんが、オンラインでセミナーを実施しています。 私のアプローチは他のアプローチとは異なりますが、最終的には、この活動はすべて同じ目標を追求します。



ところで、私の責任には、チュートリアルの作成、ブログ作成なども含まれます。 私にとってそれは非常に難しく、任意の時間がかかる可能性があります。 あなたにとってどれほど難しいですか? 1つのSpring Tipsビデオを準備するのにどれくらい時間がかかりますか?



言うのを忘れていました-新しいポッドキャストを入手しましたが、まだ何も出ていませんが、7つのインタビューがすでに準備されています:-)準備の時間に関しては、さまざまな方法で起こります。 取り上げようと決めたトピックにすでに精通している場合は、座ってすべてを2、3回記録する必要があります。常に多くの間違いを犯します。 1週間に1回、つまりわずか4時間かかります。 しかし、他のケースではこれでは十分ではありません。 時々私は問題を研究し、それを何ヶ月もメモし、それからこの仕事はすでに終わっているので、なぜこれらのメモのビデオを作らないかを決めます。 あなたがそうであるように、私は常に学んでいます。 しかし、ビデオのために特別に何かを学ぶ必要がある状況はまれです。 ここで最も難しいのは、学習プロセス自体ではなく、座り込んでトピックを掘り下げるために必要なものを決定することです。

私たちのチームのプログラマーは、これまで誰も作成したことがないものをリリースすることがあります。 この状況では、当然、人々は質問を持ち、これらの質問はデフォルトでプログラマーに投げかけられます。 そして、すべてを説明するビデオを作成し、それをネットワークに事前アップロードして、人々がお互いを知る時間があるようにします。 明らかに、この状況では、私も学ぶ必要があります-私たちはまったく新しい何かについて話しているからです。



現在、Springにはいくつのプロジェクトがありますか?



いい質問です。 数十個だと思います。 非常に専門的なモジュールがあり、その一部はコミュニティによって開発され、一部はPivotalのSpringチーム、または他の大企業によって開発されています。 Google GCPのすべてのサポートはGoogleで行われ、Microsoft AzureのサポートはMicrosoftで行われました。 しかし、たとえばMyBatisのように、コミュニティによって多くが開発されています。 さらに、Neo4jグラフデータベース用のモジュールであるSpring Data Neo4jなど、個別のモジュールがあります。 これはSpring Dataプロジェクトの一部ですが、Neo4jとのコラボレーションで行われ、彼らはこのプロジェクトの主な仕事をしました。彼はちょうどgitリポジトリに住んでいました。 そのような例はたくさんあります。

Spring Bootに関しては、自動構成と呼ばれる素晴らしいメカニズムがあります。 それは人々が彼らが取り組むものをグループ化する便利な方法を提供します。 ユーザーはJARファイルをクラスパスにダウンロードするだけで、実行中のSpring Boot Appに自動的に追加されます。 エコシステムにはこのような自動構成がたくさんありますが、重要な部分については知りません。 プラグインのように機能します。



そして、このようなさまざまなプロジェクトすべてでユーザーを理解する方法は? 一般的な構造やアイデアはありますか?



ほとんどの場合、すべてのプロジェクトが必要になるわけではありません。 目標を指定し、それに基づいて目的のプロジェクトを選択します。 人々が「春を学ぶ」ことを試みるとき、私はそれが好きではありません-これは無意味な運動です。 質問は次のようになります。たとえば、REST APIを書く必要があります。 私の最初のステップはspring.io/guidesに行くことです。そこで 10〜15分かかるシンプルで手頃な価格のガイドを見つけることができます。 知っておく必要のあるすべてのものがあります。どのコードを書くか、どのフォルダーに入れるか、IntelliJやEclipseなどでそれを行う方法です。 これらのガイドをすべての人がアクセスできるようにするため、すべてを詳細に説明し、何も省略しないようにします。 JMS、Neo4j、セキュリティ、サーキットブレーカー、Kafkaなど、あなたが何をするにしても、トピックごとに個別のガイドがあります。 タスクを決定し、適切なガイドを選択します。 Springについてではなく、システムと統合するものについて考える必要があります。Springは、この統合を可能にする単なるツールです。 したがって、「Springを学習する」という意味はありません。特定のタスクを簡素化できる場合は、それを使用する必要があります。



あなたの意見では、春のどのプロジェクトが最も有望ですか? または最も過小評価されていますか?



Spring Retryライブラリは非常に人気があります。 もともとはSpring Batchで開発されました。 Spring Batchを使用したことがあるかどうかはわかりません。たとえば、ファイルシステム、XML、CSPファイルなどのドキュメントなど、大量に順次送信されるデータを処理できます。 このツールを使用するためのオプションの1つでは、レコードを読み取ってから書き込みます(たとえば、Webサービスからメッセージキューへ)。 このデータの処理には数時間かかる場合があり、最後の1つのエラーのためにシステムが夜間に行われたすべての作業をロールバックした場合、非常に望ましくありません。 できません Spring Batchはデータパケットを処理し、1つではなく10または1000のレコードを処理します。 数千のレコードの処理が失われた場合でも、残りはすべて保存されます。 さらに、パッケージシステムを作成するときは、失敗する可能性のある他のサービスにアクセスする必要があることに留意する必要があります。 これにはSpring Retryがあります。 このライブラリを使用すると、サービスを繰り返し呼び出すことができます。 さらに、指数関数的なシャッタースピードを使用できます。 Spring Batchに加えて、Spring RetryはSpring Integration、Spring Cloud Stream、Spring Cloud Data Flowでも使用されます。 最後の2つでは、Spring Retryが他の何かと関連しているため、サポートしています。 したがって、このライブラリは多くのSpringプロジェクトで使用されており、誰もがそれを知っているかどうかはわかりません。 Spring Retryは非常に頻繁に使用されるライブラリであり、見落とされることもあります。 一般に、多くの異なる事後対応​​があります。 彼らは通常、最も興味深いです。



なぜ正確に反応主義なのか?



どこにでも反応性があります。 Springの利点は、Springを使用してプロジェクトを開始および終了できることです。 今週、Facebook RSocketプロジェクトをサポートすることを発表しました。 これはgRPCの完全に反応する類似物ですが、非常に柔軟です。 パブ/サブ、ストリーミングデータ、クライアント要求/応答に使用できます。一般的に、さまざまなメッセージングパターンを実装できます。 そして、それはFacebookで使用されています。 2つのバンドルがあり、1つはC ++に、もう1つはJavaにあります。 Javaのものは、リアクティブライブラリであるReactorを使用して記述されています。 彼女はSalesforceを使用しています。 もちろん、他のオプションもあります。 GoogleからgRPCについて聞いたことがありますか? これは非常に高品質で興味深いものですが、リアクティブではありません。デフォルトでは、リアクティブ型ではうまく機能しません。 Salesforce gRPCにはこの欠点はありません。 彼はSpring Reactorに基づいてサービスを作成するコンパイラを持っています。 そのため、FacebookとSalesforceの両方は、Reactorをニーズに合わせて拡張できました。

Reactor自体は、私たちの最も興味深いプロジェクトの1つです。 RxJavaは以前に登場しましたが、Reactorはリアクティブスレッドサポートを提供した最初の製品です。 これは主に、素晴らしいプログラマーであるRxJavaプロジェクトマネージャーのDavid KarnockがReactorで私たちと協力していたために起こりました。 そのため、私たちのエコシステムで起こったすべての新しくて興味深いことのかなりの部分が何らかの形でReactorに触れました。 このおかげで、このプロジェクトは大規模なシステムを作成する企業にとって非常に魅力的なものになりました。 Reactorは、Spring WebFluxフレームワークの基礎にもなっています。 また、Reactorに基づいて、リアクティブメッセージング、リアクティブWebソケット、Spring Cloud Stream、リアクティブサーキットブレーカーなどをサポートしました。これらのコンポーネントはすべてリアクティブアプリケーションに統合できます。 もちろん、Springを使用することもできますが、これらのリアクティブタイプでエコシステム全体を使用することを好みます。

さらに、最近、反応型ドライバーのSQLベースのデータにアクセスするためのAPIであるR2DBCについて発表しました。 リアクティブJDBCはまだ存在しません。 問題は、リアクティブコードを使用する場合、ロックを使用できないことです。 ロックを使用する場合、この相互作用を拡大して、スレッド数を増やす必要があります。 スレッドの数を増やすことでスケーリングを回避したいだけなので、これは元の目標と矛盾します-これは高すぎます。 したがって、R2DBCは、リアクティブなデータアクセスを提供する抽象化を提供します。 最初に反応するデータベースドライバーがあります-たとえば、Postgres。 したがって、スレッドがないため、特にPostgresでR2DBCを使用し、ロックを使用せずにリアクティブSQLで作業できます。 このトピック全体は私にとって非常に興味深いようです。



おそらく、よくある技術的な質問に答えられるでしょうか? 問題の1つは、複数のSpringプロジェクトを使用すると、多くの注釈が同時に発生することです。 それぞれの機能を理解するのは難しくなります。Ctrlキーを押しながらクリックして定義に移動することはできません。 そのような状況でどのように行動するのですか?



`--debug`オプションで実行する必要があります。 現在、Springエコシステムの大部分は自動構成として存在しています。 一部はインポートされた設定のようなものです。この場合、注釈をクリックすると、「@ Import」という碑文が表示され、そのクラスにそのクラスが示されます。 それをクリックすると、作成されたオブジェクトが表示されます。 ただし、Springは自動構成メカニズムを介して動作する場合があります。この場合、注釈は作成されません。 ライブラリとクラスパスのみがあります。 それから、何が起こっているのか、なぜ起こっているのかを把握するのは本当に難しいです。 しかし、人々がこれを理解できるように、できる限り簡単にしたいと考えています。 このために、アプリケーションの起動時に入力する必要がある「--debug」パラメーターがあります。 次に、起動時にアプリケーションによって実行されるすべてのステップが記述されたレポートが表示されます。 アプリケーションは、特定のフィールドまたはクラスが存在するかどうかを確認し、これに応じて、オブジェクトを作成するかどうかを決定します。 レポートには、どの条件が満たされたか、満たされていないか、どの構成がチェックに依存しなかったかが示されます。 たとえば、Kafkaへの接続が機能しない理由を理解できない場合、対応する条件を確認できます。クラスパスに必要なクラスがない可能性があります。



さて、トローリングの質問が少しあります。 Springの反対者は、 @Autowiredどこでもどこでも簡単に使用できるため、低品質のアーキテクチャの原因であるとしばしば主張します。 この意見に同意しますか? 10年前、アーキテクチャは3つの層で作成され、値がコンストラクターからコンストラクターに転送され、DTOが作成されました。 Springを使用すると、これをすべて取り除くことができます。 それは良いですか悪いですか?



Springはツールです。 これにより、より多くの人が本番環境に来て正常に動作するソフトウェアを作成できるようになるため、有害ではないと思います。 近年、何百万人もの人々がそれを使用してアプリケーションを作成し、すべてがうまく機能しています。 春全体が有害であると考えるのはばかげていると考えると、そのような意見は無知とは言えません。

Springでは、まったく明示的なワイヤリングを作成できます。 特定のオブジェクトがどこから来たのかわからないことが心配な場合は、自分でバインドできます。 あるメソッドが別のメソッドを呼び出し、呼び出されたメソッドの出力値がビンになるJava構成を作成できます。Springが処理します。 同じビンを繰り返しまたは千回呼び出しても、このオブジェクトがシングルトンである場合、複数のリンクはありません。 あなたはすべてを明示的にしたい-それを行うことができます。 必要に応じて、さらに退屈なオプションであるXMLを使用できます。 要するに、「@ Autowired」を使用したくない場合は、これを完全に回避できるということです。

最も一般的な方法でSpring Bootを使用する場合、Beanは1つのみになります。 `ConnectionFactory`型のBeanが必要であることはご存知です-この場合、型ごとにインジェクションを行うのに問題はありません。 まだオブジェクトは1つしかありません。1つのConnectionに対して2つの `ConnectionFactory`はありません。 2つのHibernateセッションはありませんので、 `HibernateSession`の挿入を妨げるものはありません-単一のインスタンスに存在します。 すべてを明示的にしたい場合は、 `@ Qualifier`アノテーションを使用できます。 それを使用して、タイプ別に注入するものをマークします。 これにより、異なるビンの実装を互いに区別することが可能になります。 ある場所のアプリケーションがiTunesと、別の場所(Amazonと3番目)でAndroid Playストアと通信できるサービスがあるとします。 異なるタイプの3つの異なるBeanになりますが、それぞれに `@ Qualifier`アノテーションがあります。 さらに、この注釈は別の注釈に重ね合わせることができるため、型の安全性が確保されます。 この型をバインドし、その上に注釈を付けます。Beanが作成されると、消費者のサイトを含め、 `@ Qualifier`注釈が付けられます。 したがって、これらの注釈はリンクを提供し、プログラムの実行中に3つの実装が存在する場合でも、必要なものを見つけることができます。



つまり、一般に、あなたの意見では、柔軟性はプラスの機能です。 あなたとSpringチームは、Zen Zenのような基本原則を順守していますか?



はい、固執します。 ちなみに、私は90年代後半からPythonでプログラミングをしており、Python Zenの大きな支持者であり、非常に正しい一般的な考え方を持っています。 質問に関しては、Springの共同設立者であり、プロジェクトに携わった2人目の開発者であるJürgenHöllerについてお話しする必要があります。 これはとても優しい人で、とても静かで、私がコミュニケーションを取らなければならない最高の人の一人です。 たとえば、会議で彼に会った場合、彼と話すのは非常に簡単です。 同時に、彼には強力な知性があり、春への彼の貢献を過大評価することは困難です。 JAXカンファレンスは、非常に重要ですが、もちろんジョーカーには届きませんでした:)-彼に、これまで誰も受け取ったことのない仕事に対して特別な賞を授与しました。 通常、賞は特別なカテゴリーで与えられますが、これはカテゴリーがなく、ユルゲンにのみ属します。 SpringはJavaエコシステムで唯一、15年も書き直されていないプロジェクトです。必要がないためです。 ユルゲンには、モジュールの記述方法、型の表現方法、一般的には何十年もの間必要に応じて簡単に変更できる高品質のコードのベースを作成する方法について非常に明確な考えがあります。 Javaエコシステムには、このようなプロジェクトは他にありません。 プロジェクトの大部分はもはや存在せず、ゼロから書き直されたプロジェクトの中でも、15年生きている人はほとんどいません。

最初から非常にきれいに書かれていたため、書き直されずに15年だけ続いたのはSpringだけです。 ユルゲンは、私たちが従ういくつかの基本原則を教えました:モジュールの作成方法、実装パッケージの作成方法(公開部分とは対照的に)、APIの表面レベルの記述方法、APIの設計タイプ、使用するパターン。 Springを使用すると、必然的にデザインパターンに精通することになり、常にそうでした。 パターンパターンの例がすぐに思い浮かびます。 Spring Integrationはエンタープライズ統合パターンを紹介し、Spring MVCはMVCを紹介します。 これらのパターンはすべてフレームワークの一部であり、実証済みのプラクティスに基づいて使用します。 私たちの禅は、ユルゲンが教えてくれた原則です。 この点で、私たちはすべて彼の学生です。 ユルゲンは、コードの記述方法に対する少し奇妙なアプローチで知られています-彼のマナーのために、特別な用語「jurgenize」が生じました。 私たちのチームには、優秀な経験を持つ非常に優秀な人が多く、すでに学位とはげたパッチを持っている人もいます。 それにもかかわらず、ユルゲンはコードに独自の変更を加えます。 スペースの追加やクリーニングなどの小さなこともありますが、コードを最初から1,000倍以上書き直したり、コードの作成者を変更したりすることはありません。つまり、元の作成者の名前でコミットします。 これらの場合、コードは「合法化された」、つまり修正されたと言われています。 Jürgenのおかげで、私たちのコードはとてもきれいです。 コード分​​析ツールの場合、非常にクリーンなコードがあるため、Springで少なくとも何らかの誤動作を見つけることは高品質マークと見なされます。 一般に、原則を詳細に説明することはできませんが、それらはそこにあり、ユルゲンによって定められており、すべてのSpringプロジェクトがそれらに従っています。 Spring Bootに関しては、モジュールを作成するための非常に正確なルールがあり、これをスターターと呼びます。



OK、答えてくれてありがとう。 最後の質問はパフォーマンスとJava 11についてです。私の知る限り、Springは常に実行時にコンテキストを生成します。 古い銀行プログラムでは、これに数分から数時間かかる場合があります。



おい? 信じられません



正直、自分の目で見た。



しかし、春になることはできません。 恐らく、Hibernateで恐ろしいことが行われます。 Beanは数百万単位で生成でき、空のBeanは非常に迅速にコンパイルおよび実行できます。 データベース、検証などから情報をロードするには時間がかかります。これにより、Springが遅延する可能性があります。 しかし、Spring自体は非常に高速です。



はい、Hibernateには何らかの恐怖があったと思います。 それにもかかわらず、Springは30秒、時には1、2分で開始します。それでもまだかなり長い時間ですよね。 たとえば、Dockerで実行する場合、コンテナをすぐに起動する必要があります。 Springの起動時間を短縮することは可能ですか?



Springを開始するのに2秒もかかりません。 また、Spring Cloud Functionを使用すると、この時間を0.5秒以下に短縮できます。 たとえば、Spring Cloud FunctionのSpring Bootなど、0.5秒で問題なく実行されるプロジェクトがあります。 だから、再び、問題は春ではありませんが、あなたが彼らに何をするか、バックグラウンドで何が起こっているのですか-インターネット上の別のデータソースにアクセスできますか、インターネットからファイルをダウンロードしますか、グリッドにデータをアップロードしますか。 小規模なマイクロサービスのみを行う場合、システムは非常に高速に動作するはずです。 アプリケーションの実行時間が非常に長い場合、何か問題があります。



なるほど。 ところで、GraalVMとAOTについて聞いたことがありますか?



はい もう少しお話しします。SpringFuプロジェクトがあります。 彼は実験的で、春のヒントシリーズから彼に関するビデオを撮影しました。 Kotlinで作成しましたが、現在はJava APIを備えています。 このプロジェクトは、GraalVMなどの環境用に作成されました。 Spring Fuは、動的に生成されたプロキシまたは「@ Configuration」を使用しません。 GraalVMのネイティブイメージジェネレーターは、ロードされるクラスを知る必要があります。 ただし、cglibまたはByte Buddyを使用して動的にロードする場合、これによりGraalVMの使用が困難になります。 Hibernate、Spring、および動的に生成されたプロキシを使用する他のすべてのライブラリは、ネイティブイメージの作成にはあまり適していません。 したがって、春風にはこのようなものはありません、これは直接述べられています。 まだSpringを使用していますが、アプリケーションを構築する方法は異なります。 また、Spring Fuの利点の1つは、GraalVMとうまく機能することです。 そして、今すぐアプリケーションが起動します。 つまり、通常は即座に:完全にメモリに格納されると! GraalVMのネイティブイメージジェネレーターは、開発の非常に初期の段階にあることに注意してください。 このため、GraalVMによって起動されたアプリケーションはすぐにロードをすぐに開始し、実行時には以前と同じ速度になると思われるため、困難が生じることがあります。 しかし、GraalVMランタイムではJVMを使用しなくなったため、システムの動作が異なるため、そのようにはなりません。 したがって、このプロジェクトの正常性をテストしてください。ただし、これは無料の起動加速ではないことに注意してください。 それでも、私はGraalVMを喜んでいます。彼らのチームは、フレームワークとの連携を改善するために多大な努力を注いでいます。



もちろん、最後の質問はJava 11についてです。



はい、彼女は美しいです。



その中でSpringにとって何が便利ですか?



Spring開発者にとって、このテクノロジーまたはそのテクノロジーを選択する主な基準は2つあります。1。ビジネスニーズに適しているかどうか、2。プログラマーとして適しているかどうか。 最初の基準として、この技術がより高速で安定性を提供するかどうか、長期的なサポートがあるかどうか。 これらはすべてJava 11にあります。 Java 8のサポートはまもなく終了するため、長期サポートのある次のリリースにアップグレードすることは理にかなっています。 ところで、私の友人、次のバージョンにアップグレードする場合は、OpenJDKアセンブリを使用してください。あらゆる点で優れています。 正しいバージョンを入手するのは非常に簡単です。すでにTwitterでそれについて書いています。 このリリースはSpringで非常にうまく機能します-安定しています。 少なくともhttps://start.spring.ioにアクセスして 、新しいプロジェクトを生成し、Java 11を選択すると動作します。 Java 11のサポートは、IntelliJとEclipseの両方で利用できます。

2番目の基準に関しては、Java 11のSpring開発者にとって大きな変更はありません。 `var`とHTTPクライアントが登場したのはいいことですが、Springは既にリアクティブなWebクライアントを持っているので、HTTPクライアントの恩恵を受けるかどうかはわかりません。 Java 10とJava 9には便利なものがいくつか追加されました。さらに、Javaプログラムをスクリプトとして実行できるようになりました-これは悪くありません。 これがSpringで理にかなっているかどうかはわかりません-一方で、そうではありません。 それがどのように見えるか、私にはわかりません。



SpringがJava 11に切り替えるのは困難でしたか?



いや Springの中心には、非常に高品質のライブラリとエコシステムがあります。 Springフレームワーク自体はクラスパスとモジュールパスの両方をサポートしますが、個人的にはモジュールパスの使用はお勧めしません。 正しく使用するには、他のすべてのものもモジュールパスをサポートする必要があります。 そして、これはまだ不可能です。現在、ライブラリでモジュールパスのサポートを提供している人は少なすぎます。 クラスパスモードは非常にうまく機能します。 CGLib、AspectJ、およびJAXB XMLライブラリには、Java 9に切り替えたときに誰もが抱えていた非常に標準的な問題がありました。これらの問題はすべて、昨年に解決されたため、Java 11への移行が容易になりました。



ところで、私たちはJavaの将来のバージョンについて多くの興味深いことを計画しています。たとえば、LoomプロジェクトはJavaのファイバーです。



Java 12になりますか?



おそらくそうではないでしょうが、彼らはこれをかなり長い間行うでしょう。



Kotlinもコルーチンを使用しているため、このプロジェクトは非常に興味深いものです。 彼が出てくるときはいつでも、彼は大きな恩恵を受けるでしょう。 リアクティブコードを作成せずにリアクティブパイプラインを表現できることは非常に重要です。 個人的には、複数行の文字列の出現を楽しみにしています。 たぶんこれは私に証言するための最良の方法ではありません-例えば、SQLクエリなど、多数の行を必要とするコードがたくさんあります。



これは、スライドショー用に最適化されたコードの重要な部分があるためです。 レポート中のスライドでは、画面上に文字列全体を表示すると便利です。



はい、そうでないと読みにくくなります。 IDEでは、それらははるかに良くなります。 繰り返しになりますが、Python、Kotlin、Scala、Groovy-過去20年のどの言語でも複数行の文字列サポートを提供しています。 私の意見では、これは非常に自然なことです。



読者にアドバイスをお願いしますか? SpringやPivotalに関係している可能性があり、Java全体に関係している可能性があります。



他のテクノロジーと同様に、Springの最大の部分はコミュニティです。 技術的には、Springは非常に興味深いプロジェクトのセットですが、その長寿の秘theは素晴らしいコミュニティです。 あなたが耐えられない人々とそのために通信する必要がある場合、誰もあなたの素晴らしいソフトウェアを必要としません。 したがって、可能な限り友好的になるよう努めています。 プロジェクトマネージャーを含む開発者は、Stack Overflowで質問に答え、そこでさまざまなタグを追跡します。 Gitterにはチャットルームがあり、その中の各チャットルームはGitHubのリポジトリに対応しています。 たとえば、 https://gitter.im/spring-projects/spring-boot 。 そこで、Spring開発者を見つけて、興味のある質問をすることができます。


多くの場合、プロジェクトを支援する方法、Springのコードを書き始める方法を尋ねられます。 GitHubの「投稿に最適」などのタグには多くの問題があります。 私たちは皆に喜んでいますが、すべてのプロジェクトがすべての人に適しているわけではありません。一部のバグは他のバグよりも複雑です。 したがって、当社と協力したい場合は、これらのタグを探して問題を解決してください。 それは私たちのコミュニティの補充が発生する方法です。 私たちは、エコシステムの改善を支援するすべての人の仕事を大切にしています。



広告の分。 ジョシュロングは、 リアクティブスプリングトークでジョーカー2018カンファレンスに参加します。 チケットは会議の公式ウェブサイトで購入できます。

Source: https://habr.com/ru/post/J425961/


All Articles