Baruch Sadogursky、JFrog：Developer Advocate、Java 9 and Kotlin's World Dominance（ただし、Groovyの方が良いでしょう）

11月初旬に、 JavaDayカンファレンスがキエフで7回開催されます。 JFrogのDeveloper Advocateである彼女のレギュラースピーカーBaruch jbaruch Sadogurskyとチャットしました。 会話中に、私たちは次のことを話し合うことができました。



-Developer Advocateの機能：雇用主向け製品を宣伝しない理由

-ミニバスとトレインの例でのJava 9とJavaリリースの頻度

-コトリンと世界支配への道

「重要なのは、開発者の問題を解決するのにどれだけの支援ができるかであり、開発者の関心を、あなたが推進している製品の関心よりも高くすることです」

あなたの投稿はDeveloper Advocateのように聞こえますか？ 私の知る限り、これは伝道者の類似物ですよね？

はい、伝道者の類似物ですが、完全ではありません。 「伝道」の概念そのものが、単一の正しい決定についての真実を人々に伝えるという文脈で、宗教的な意味合いを持っています。 これは私がやっていることではありません。 少なくとも私はそれを信じたいです。 伝道者とは、正しいやり方を伝える人です。 英語の擁護者。最初はロシア語のように法的意味はありませんが、利益の保護、表現を意味します。 それが違いです。



開発者を擁護します。 これは、開発者、コミュニティの希望を理解し、社内でそれらを提供することを意味しますか？

これは、方向の1つです。 2番目に重要なのは、給料を支払っている会社の製品を使用しなくても（もちろん、より良い方法で）開発者が特定の問題を解決できるようにすることです。 「みんな、あなたの問題を解決するのに役立つので、Artifactoryを使ってください」と言うことができます。また、「それを使わない方がいい-ここでは役に立たない」と言うこともできます。最初のものを使用できます。



それでは、製品プロモーションとDeveloper Advocateのプロフェッショナルな仕事の間の境界線はどこにありますか？

ポイントは、一緒に働く人々のニーズをどれだけ理解するかです。 あなたが彼らの問題を解決するのをどのくらい助けることができますか、あなたの宣伝している製品の興味の上に彼らの興味を置きます。 大まかに言えば、あなたが言うことができるなら： 私たちの製品を服用しないでください-それは今あなたを助けません 、あなたはプロの開発者リレーションです。 とにかく開発者の声に耳を傾けず、理解もできなかったために製品を宣伝しているのであれば、これは非専門的です。



Developer Advocateは同時に開発者でもありますか？ 例えば、健康を維持し、コミュニティのニーズを理解するため。

必須です。 そして、問題は形式にありません。 コードを書くことなく、人々のニーズを理解することはできません-そして、あなたは自分の義務を果たせません。 必ずコードを書き、テクノロジーを理解し、それらを「プレイ」してください。 そしてそれはただ面白くて楽しいです。



マーケティングコンポーネントと開発コンポーネントのバランスはどうあるべきですか？ どのくらいの頻度でコーディングしますか？

収益に戻ると、マーケティングは開発者関係の一部ではありません。 ほとんどの場合、会社の開発者支持者は非常に小さいです。 現在、JFrogは250人を雇用しており、1人だけを擁護しています。 すぐに私たちの3つがありますが。 しかし、250人の会社にとっては、これでも十分ではありません。 したがって、通常、部門はこの機能に割り当てられず、別のユニットに接続されます。



Developer Advocateはどこでも機能しますが、営業部門では機能しません。 私たちの場合、私はマーケティング担当者です。 私はその最も純粋な形でマーケティングを行うのではなく、むしろその道を切り開きます。 JFrog製品が彼にとってどのように役立つかについての私の報告を聞いた後、彼はマーケティングのリーダーとなることができます。



関係と開発の関係については、理想的な比率は50/50です。 残念ながら、人々は少数です-多くの仕事があるので、技術的な部分は時間後に「ピックアップ」されなければなりません。 たとえば、最新のニュースを聞き、新しいテクノロジーを試すために、JavaDayに行きます。 デブリーフィングポッドキャストには、私にとって同じ目標があります。 私はそこで仕事で何かを宣伝しようとはしませんが、逆に、情報を得るために勉強して聞くことを試みます。 チームをタイプするときに、最終的に勤務時間中にこれを行う時間があることを本当に望みます。



つまり、あなたは乗って演奏するのが好きです。 しかし、コードを書くのも好きですか？

私は本当にコードを運転して書くのが好きです。 50/50の比率で両方を行うことができれば...私はすでに理想的な仕事をしていますが、もう少し理想的です。







プロフェッショナリズムデベロッパーリレーションズ-自分に正直になりましょう。 しかし、雇用主はおそらくいくつかのKPIを置くのでしょうか？ パフォーマンスはどのように測定されますか？

効果を測定することはできますが、非常に困難で高価です。 初期段階では、企業はコミュニティに対する開発者関係の専門家の影響を測定することに投資する準備ができていません。 多くの企業では、影響はまったく測定されていないか、Twitterのフォロワー数やレポートを訪れた人のような非常に単純で素朴な指標に依存しています。 しかし、スピーチに何人の人が来たかは、レポートにスキャンダラスな名前が付いていることと、誰が並行して話しているかという2つのことによって決まります。 JavaDayのWebサイトにすでにハングアップしている星のように、私と並ぶ星が並ぶとしたら、驚くべき報告をしても誰も私のところに来ないでしょう。 これは意味のないKPIの例です。



どのKPIが本当に重要ですか？ 私のレポートはどれくらい人々を引きつけましたか？ Yegor Bugaenkoの例を見てみましょう。 彼の報告は非常に「キャッチー」な人々です。 それは良いですか悪いですか？ これにより、彼の開発者関係は改善または悪化しますか？ エゴールは雇用のために行動します。 この場合、すべてが単純です。彼のレポートの後、3人が彼の仕事に来たら、レポートは良かったです。 別の100人がこのレポートに不満を感じる可能性があることは問題ではありません。



そして、それが雇用ではなく、製品、プラットフォーム、APIなら？ 報告後に何人が登録しましたか？ しかし、その日のブログ記事が公開されたからではなく、会議後に彼らが来たことをどうやって知っていますか？ それにもかかわらず、私はそれが測定することが可能であると信じていますが、これは重要な作業です。



JavaOneのスピーカーとして再び承認されます。 何で演奏しますか？

私のレポートのほとんどはまだDevOpsに関係しているため、すべてのレポートについてまだ回答がありません。 Dockerについてなど、多くの技術レポートがそこで受け入れられることを期待しています。 これまでのところ、音声ユーザーインターフェイスに関する1つのレポートがメインのJavaスレッドで受け入れられました。 AlexaとGoogle Homeの 2つのお気に入りの形式のいずれかを作成します。 それらの拡張機能を作成し、その過程で、サードパーティ拡張機能の設計と統合のコンテキストでAmazonとGoogleが下した決定を比較します。



7月に、2017年のトップ20 Javaインフルエンサーリストに参加しました。 Developer Advocateのこのような評価のヒットはどれほど重要ですか？ なぜあなたはそれに夢中になったのですか？

昨年、主催者が最初にこの評価を行い、私たち-そこに着かなかった人たち-はそこにいた人たちをひどくトロールしました。 事実は、評価が以前に話したそれらの無意味な測定基準のみに基づいているということです。 ユーザーはKloutを採用しました。これは、ユーザーインタラクションに基づいてソーシャルネットワークの影響評価を構築するプラットフォームです。 しかし、実際には、プラットフォームは非常に単純であり、先ほど述べたように、影響を測定するのは依然として困難です。 しかし、今年私はそこに着いた！ そして、すべて、Kloutは一度に心への影響を測定するための最も深刻で真実なツールです！ （もちろん冗談です。些細なことですが、素晴らしいことです。）



オラクルは最近、すべての伝道者を縮小しました。 彼はおそらくそれらの有効性を測定するのに十分なお金を持っていましたか？

それらが無駄に減少したかどうかの優れた指標は、その名前を知っていますか。 伝道者が解雇されたというニュースを読んで、聞いたことがないなら、彼らの専門家はまあまあでした。 Oracleの場合、Simon Ritterのような有名人がいましたが、そうではありませんでした。 それらを削減しても、Javaや会社に害はありませんでした。

「今、Java 9の非常に多くの肯定的な側面について話すことができます。」

まだあまり人気がないJava 9を宣伝する人はいないと思いませんか？

答えは2つあります。 開発者リレーションは、悪い製品を宣伝できません。 「9」にあるものが気に入らないことを人々が理解するなら、誰も彼らを納得させることはできません。 1年前、リリースは問題以上でした。 Oracleで開発者の擁護者として働いた場合、少なくとも内部的にはこれらのソリューションを批判します。

状況は少し変わりました。 オラクルはコンセプトの変更を余儀なくされ、9つの「ボンネット内」にあるモジュールの積極的なプロモーションを放棄し、コミュニティ全体をJava 10に移行しました。これにより、「9」はかなり無害な更新になります。 したがって、「ああ、いや、それはすべてを壊すので更新しません」という状況から、「あなたもアップグレードできます-おそらくいくつかのニシュタクがあります」という状況になりました。 そして、この状況では、OracleにDeveloper RelationsがないことはJavaにとって悪いことです。 モジュール性を守る必要はもうありませんが、新しいリリースにある利点を明らかにする必要があります。これは誰にも明らかではありません。



Baruchが給料にOracleを持っているふりをしましょう。 Java 9を宣伝しますか？ 開発者に正確に伝えたいことは何ですか？

はい、もちろん、Java 9の非常に多くの肯定的な側面について既に話をすることができます。最も議論と拒絶を引き起こした最大の機能はJigsawです。 彼の以前の生まれ変わりはすべてを壊すことを約束していましたが、今では議題から削除されました。 Java 8で機能するほとんどすべての機能は、「9」でほとんど変わらずに機能します。 したがって、他の機能について話すことができます。

たとえば、言語の構文には新規性があります-インキュベータープロジェクト-これにより、新しいHttpClientのように、10以上を対象としたいくつかのことを試すことができます。 はい、5や8のような巨大なリリースではなくなります。 Java 9は、7のような、よりマイナーな安定化リリースです。 しかし、その中には話すべきことがあります-そして更新を提供する理由があります。



そのような遅延と適応は、言語の開発にどれほどの害を与えますか？ しかし、オラクルは、5年の間に複数回、より頻繁に新しいバージョンをリリースするために、開発サイクルを短縮することを考えていました。

はい、Javaリリースを「ミニバス」にするか「トレイン」にするかについての議論があります。 「ミニバス」がいっぱいになると出てきます。 つまり、特定のリリースで計画されている特定の機能セットがあります。 すべての機能の準備ができたらリリースされます-ミニバスがいっぱいになります。 しかし、「列車」はスケジュール通りに出てきます。誰が管理しましたか？ これまで、Javaリリースは「シャトルバス」でした。 誰もがモジュールの準備ができるのを待っていたため、Java 9の「出荷」は常に遅れていました。

Oracleでは、リリース日が割り当てられた「トレーニング」に移行しています。 これにより、「1つを通じて」リリースが行われる可能性が高く、大きなリリースの後に、より「化粧品」のリリースが続く場合があります。 つまり、モジュールの次のフェーズ（すべてのユーザーに影響を与えるもの）が「トップ10」に入り、Java 11では根本的な変更はほとんどないでしょう。 書く時間がありません。



あなたは「ミニバス」ですか、それとも「電車」ですか？

「電車」の方が正しいように思えます。 このアプローチにより、プロジェクトオーナーのOracleのストレスが大幅に軽減されます。 ミニバスの場合、彼らは真っ向から急いで品質に妥協しなければなりませんが、リリースに間に合うか、またはそれを再び延期させることで有罪となります。

Java 8はこの問題に直面していたと思いますが、控えめに言っても、品質、バグ、ドキュメント、設計の決定の点で問題がありました。 Javaは他の多くの言語よりも安定しています（安定したJVMであっても）が、Javaは驚くほどJava標準によって未加工でした。 おそらく、「ミニバスを埋める」というプレッシャーが理由でした。 通常のリリースの場合（この時間がない場合は、次のリリースでリリースされます）、この問題はほとんど回避されます。



または、Javaは継続的な配信ベースで進化できますか？

どのプラットフォームを扱っているかを忘れてはならないので、私は非常に疑っています。 彼女は大人です。 多くの保守的な企業クライアントはこれに依存しています。 アップグレードは高速ではなく、新しいバージョンが絶えずリリースされているため、ある程度のプレッシャーがかかります。 「3つのバージョンがすでにリリースされていますが、まだ更新されていません！」これには対応していません。 したがって、開発者向けのビルドの継続的な配信が可能です。 しかし、1年に1回よりも頻繁に長期サポートバージョンをアップロードすることは理にかなっているとは思えません。



リリースの頻度について話しました。 今、品質について話しましょう。 Javaには何が欠けていますか？ 次のメジャーリリースで何を追加しますか？

もちろん、これについては際限なく語ることができます。 Javaには、歴史的またはそのように考えられていたため、Javaにはない多くの言語機能があります。 具体的に私を喜ばせる何かについて話すと、これらはプロパティ、消去のないジェネリック、そしておそらく型推論です。 組み込みの不変性もおそらく非常に良いオプションです。 つまり、Javaの外観を知りたい場合は、Groovyをご覧ください。

「Kotlinは世界を征服するための良い出発点です。 彼女はJetBrainsと呼ばれています。」

Kotlinはどうですか？ なぜ誰もが彼について今話しているのですか？

まず、人々がGoogle I / Oであなたについて話すとき、それは明らかにあなたの人気に貢献します。 さらに、Kotlinは優れた言語です。 他の言語から多くのものを取り、正しく実装されています。 もちろん、誰もが知っているように、言語の人気は著者のひげに依存しています（ひげをなでる）。 しかし、真剣に、それは昇進と普及の可能性にも依存しています。 誰もがOOPモデルと見なしているSmalltalkの中には、完全に偏った理由で離陸しなかったものもあります。



コトリンは今、世界を征服するための良い出発点を持っています。 これはJetBrainsと呼ばれ、IntelliJ IDEAのおかげで開発者の間で非常に人気があり、尊敬されています。 JetBrainsについて考えるとき、優れた技術レベルで作られたクールな製品を想像します。 さらに、彼らのチームは、利益を追求する代わりに、適切と思われることを行います（少なくとも彼らはそう考えてほしい）。 これは夢の会社です。



このような信頼の限界は、言語自体に表示されます。 「ああ、KotlinはJetBrainsでやった-それは何か良いことを意味する！」 見てみると、これは本当に良いことであることがわかりました。 これは、誇大広告の波を生み出したGoogle I / Oの後、開発者に気づかれました。 さらに、KotlinでAndroid向けに作成していない場合は、何らかのJava 6向けにコーディングしていることになります。痛みと苦痛。



なぜKotlinはそんなに良いのですか？ Javaに対する利点は何ですか？

Kotlinには、他の言語の多くの優れた機能があります。 定型文の数を減らすより便利で正しい構文。 たとえば、POJOはより少ないコードで作成できます。 ゲッター、セッターは必要ありません。 ある種の正しいGroovy！

最も深刻な機能の1つは、ヌルの安全性です。 これは、たとえばGroovyを上回る利点です。 一般に、ヌル値可能性に関連するすべてのことを自分で実行する方法ははるかに少ないです。 賢い人による6年間の設計は無駄ではありません。



リアクティブプログラミングのようなファッショナブルなものはそこにありますか？

デブリーフィングの第138号では、Kotlinのジェットライブラリを作成しているRoma Elizarovと話をしました。 この言語は、RXのようなライブラリがネイティブに接続するのに非常に簡単で便利になるように作成されています。 接続するとすぐに構文に非常に調和して適合し、あたかもその言語で定義されているかのように作業できます。



今彼に教えるべきですか？

新しい言語を学ぶことは常に価値があります。これは、すでにコーディングしているものに関係なく、視野を広げ、より良いプログラマーになるための素晴らしい機会です。 今後数十年で何も変わらない伝統的な銀行で働いていたとしても、Kotlinの学習は専門能力開発のためだけです。 これは開発者としてのあなたの仕事です。

しかし、また、キャリアの機会を探しているとき、コトリンは面白い賭けです。 これは、彼女が「撮影」し、あなたの次の仕事がコトリンであるという100％のチャンスを意味しません。 一方、タレブが教えてくれたように、その試みは拷問ではありません！ -彼が「シュート」した場合はどうなりますか？



KotlinはAndroidで良好なスタートを切りましたが、エンタープライズセグメントでJavaとどれだけ競争できますか？

これまで、Java間のギャップは巨大です。 近い将来、ブロックされなくなります。 対象読者は少し違うようです。 Javaの安定性とJavaの背後にある巨大な企業を愛する銀行や政府機関について話しました。 一部のプログラマーがコードの作成に慣れているという理由だけで、Javaを今日Kotlinに変更しません。 これは、Javaに15年かかった非常に長いプロセスです。 このセグメントのJavaを変更するには、別の言語に5倍以上必要です。 安定性よりもリリースの品質と量がはるかに重要であり、変更を行いやすい、よりダイナミックな企業、スタートアップは、Kotlinのような言語をはるかに速く認識します。

銀行は、Javaがどこにも行かないこと、長い間サポートされていること、Java開発者がいつでも見つかること、そして次のバージョンは後方互換性があることを確信しています。 彼らは彼らのニーズを理解しているサプライヤーと協力しています。



ある男が母親にインタビューした投稿を思い出しました。 彼女は過去20年間、銀行でCOBOL開発者として働いてきました。 現在、このような開発者は非常に高価であり、銀行は24時間年中無休で稼働する必要があるため、他のものに切り替える余裕はありません。

実際、サーバーを変更する時間がないためではなく、再構築する余裕はありません。 これは真実ではありません。 何百万行ものコードがCOBOLで記述されているため、彼らはそれを買う余裕がありません。 これらすべてのシステムを他の言語で書き直すよりも、平均的な開発者が受け取るよりも多くのCOBOL開発者に支払う方がはるかに安価です。

そしてまだ彼らは書き直します。 2017年の銀行システムには、COBOLよりもはるかに多くのJavaがあると思います。 はい、これらはCOBOLコードの並行サポートを行う長期プロジェクトですが、最終的には変更が発生します。 そして50年後、Javaは新しいCOBOLになります。 これは明らかであり、避けられず、おそらく自然なことです。