英語のルーツを持つJava会議。 継続的なメガレビュー

私とCleverDATAの同僚であるmpryakhinは、Javaカンファレンス-Jax London 2017のために英国の首都に行くことができました。先週、すでにChaos Engineering、ラムダ式、壊滅的なバグ、Container Delivery Javaアプリケーションについて読みました 。



そして、レビューの第2部では、自分の計画ではなく、自分の計画に従ってキャリアを構築する方法についてのストーリーを見つけます。 メトリックを使用して新機能の作業を最適化する方法。 また、高負荷のイベント処理システムを構築する複雑さについて学び、Java APIを使用してイーサリアムスマートコントラクトを操作するための便利なリンクを見つけます。

三日目 メトリックを使用した開発プロセスの正しい方向と制御の専門家の成長

多くの技術会議では、私たちの職業生活の技術的な側面を明らかにすることなく、日常生活で注意をそらしているものを理解するのに役立つ報告書で一日を開くのが慣例です。



多くの人はこれらのレポートを面白くないか、会議のトピックに関係がないと考えていますが、私の意見では、誰もが焦点を変え、長い間言語で紡がれているものに反映することができますが、実現されていないので、それらは最も貴重なものの1つです 新しい考え、アイデア、アプローチ-これはまさに多くの人々が外国の会議に参加するためのものです。

Sandro Mancusoによる「The Long Road」

このレポートは、私たちの職業生活の最も重要な側面の1つ、つまりキャリアパスの構築に取り組んでいます。 この問題へのアプローチ方法、実​​行するアクション 原則として、この分野のアドバイスの大部分はかなり曖昧であり、人生でそれらをどのように適用できるか想像するのが難しい場合があります。



このテーマに関する本、マニュアル、方法論、報告書、その他の資料がたくさんあると確信していますが、その多くはすでに知っていますが、この特定の報告書は特に記憶され、私の心に残っています。



著者は、あなたのプロとしての道を、各ステップが私たちの現在または以前の仕事である梯子として見ることを提案します。 キャリアを構築することは、この階段がどのように見えるか、そして新しい階段がそこに現れる理由に直接関係しています。





出所



大企業は、従業員に多くのキャリアオプションを提供し、何百万もの異なるKPIに興味を持たせることができます。 しかし、キャリアのはしごに沿っていくつかのポジションを進めた従業員は失望することがあります。 彼は自分の計画ではなく、会社の目標であるKPIに従ってキャリアを築いたからです。 そして、彼は数歩下がらなければなりません。



したがって、結論：定期的に、長期的な目標の観点から活動を遅くして評価し、現在の行動がどのように目標を達成するのに役立つか、目標が達成されたときに得た経験に基づいて調整が必要かどうかを理解する必要があります



次の仕事の選択は、会社の成功、社会的利益、チームの規模、平均年齢など、多くの側面に影響されます。 これはすべて非常に重要ですが、常にこの会社で何らかの開発が行われるという保証ではありません。



戦略的なポイントを検討する価値があります：市場での会社の地位（現地および国際）、その目標と野望、会社が事業を展開する事業領域、そして最も重要な側面は、あなたが参加するスペシャリストのチームです。



残念ながら、多くの技術専門家は、会社が彼らにもたらす社会的地位の短期的な改善のみに基づいて特定の職場の方向を選択しますが、同時にそのグローバルな目標について完全にまたは部分的に無知のままであり、チームに精通していません。



多くの場合、選択はリクルーターのチームの助けを借りて行われます。リクルーターの主なタスクは、空席を閉じることであり、開発には一切関与しません。 リクルーターの助けは間違いなく必要ですが、イニシアチブは私たちから最初に来るべきです-特定のビジネスドメインへの関心と、長期目標に従って開発するために最高の人々と協力したいという願望に基づいて。



Sandro Mancusoによる他の考えは彼の講演のビデオにあります。

「DevOpsの測定：重要な主要指標」Anders Wallgren著

ソフトウェアを開発するとき、私たちは他のすべてが存在しなくなるという考えに非常に熱心です。 アイデアは燃えるようなトーチと見なされ、私たちはそれに向かって手を引きます。 成功はすでに非常に近いように見えますが、突然地球が足元を下ってしまい、燃えているトーチは到達不可能な星であることが判明し、私たちは製品と「何がうまくいかなかったのか？」



いいですね 人生では、すべてがそれほど哀れではありません。 しかし、新しい、待望の、複雑で興味深いタスクを解決するとき、私たちが中に入って、数時間後（そして、あなたはそれを信じないでしょう、私はその週さえ見ました-それはすべてあなたの組織のサイズとあなたの罪悪感に依存します）スクラムマスターは、あなたが何をしているか、いつ結果を期待するかを正確に説明する時が来たことを思い出します。



この段階では、熟考する時間がもうないことを理解しており、大きな目標と考えは次回まで延期され、私たちは一生懸命働き始めます。



このようなケースは、どのレベルおよびプロファイルのチームや企業でも珍しいことではありません。 それは、彼らで働いている技術専門家の経験やプロ意識に常に依存しているわけではありません。 多くの場合、欠点は、あなたが今いる場所、行かなければならない道、そしてより詳細に見るとそれほど明白ではない最終目標の理解不足です。



そのため、時間の一部を費やして、当初の期待どおりではないタスクの完了に専念していますが、正確にどこに行くのかは必ずしも明確ではありません。 そして、私たちが何かを誤解したとき、最も簡単な方法は、私たちの活動についての情報を集め始めることです。 ここでメトリックが役立ちます。 これについての詳細は、Electric Cloudの専門家から言われました。







この図は、特定の観察結果を扱う科学的アプローチを示しています。 実際、革新的なものは何もないため、多くの人に親しまれ、頻繁に使用されています。 これは、観察しているものの理解に私たちを導くことが保証されている論理的なアクションのシーケンスです。



ここでの主な注意は、各手順が問題をよりよく、より完全に理解し、より意識的に最終目標に到達するのに役立つので、手順をスキップしようとしないで、操作の順序に注意を払う必要があります。



しかし、メトリック、またはそのタイプに戻ります。

• 機能の開発と実装の有効性。
  
  
• 顧客満足度に対する機能の影響。
  
  
• 製品および当社のビジネスに対する機能の影響。
  
  
• 従業員の満足度。
  
  

私たちのほとんどは、開発/テストプロセスの最適化と新しい機能の導入に直面することになります。ここでは、最初のグループのメトリックの種類を活用します。



原則として、新しい機能を開発するプロセスは、開発段階の次のセット（パイプライン）に減らすことができます。



写真はクリック可能です：







したがって、典型的なプロジェクトの開発には5つの段階があります。

• 開発;
  
  
• テスト;
  
  
• 展開;
  
  
• 実装;
  
  
• 護衛。
  
  

プロセスがまだ類似した部分に分割されていない場合、おそらくこれは機能の開発および実装時間をより意識的に制御するための最初のステップになります。



プロセスが個別の部分に分割された後、それぞれの時間を測定し、最も時間がかかっている段階を見つけることができます。 さらに、特定の一連の観察と上記の図を使用して、多くの改善を実行し、パイプラインを使用して、開発プロセス全体に対する変更の影響の品質を評価できます。



したがって、最適な作業条件下で、スポーツカーのエンジンなどの新機能を開発および提供するプロセスを繰り返しカスタマイズする機会が得られます。 将来的には、これは最高の製品を求める競争に勝つ助けになります。



各機能の実装が会社の特定の目標を追求することを忘れないでください。 次のメトリックはメトリックとして機能します。

• 新規顧客を引き付けるコスト。 市場、環境に関連する新機能がタイムリーに更新され、バグの数が非常に少ない場合、顧客の忠誠度が高まり、市場での人気が高まり、その結果、新しいクライアントを引き付けるコストが減少します。
  
  
• 利益。 ここでは、すべてが非常に簡単です。顧客数を増やし、メンテナンスのコストを削減します。
  
  
• 市場シェア。 環境を冷静に評価することは常に役立ちます。
  
  

製品は、顧客/ユーザーの目標を満たさなければなりません。 ここで、メトリックは次のとおりです。

• 製品に対する満足度。 フィードバックを継続的に収集することにより、開発プロセスと顧客とのコミュニケーションプロセスの調整の両方に影響を与える可能性のある多くのニュアンスを特定できます。
  
  
• 機能の恩恵を受ける。 残念ながら、私たちのアイデアは、ソリューションを設計しているビジネスドメインのニーズと常に一致するわけではありません。製品の価値は、その品質だけでなく、市場のニーズに動的に適応して聞く能力にもあります。 したがって、機能の一部が期待される利点をもたらさない場合、これはそれらを修正するための良いマーカーです。
  
  
• ユーザビリティ機能。 多くの場合、ユーザーは私たちのアイデアに感謝できません。なぜなら、 それは新しいものであり、誰もまだ私たちの前にやったことのないものであり、ビジネスはそれをどこにも見たことがない。 多くの場合、人々は新しいものすべてに対してかなり保守的で懐疑的ですが、使いやすさに関する情報を収集する場合、そのような機能に関するセミナーをタイムリーに開催することができます。
  
  

Googleにはルールがあります。変更の影響をビジネス価値の観点から評価できない場合、そのような変更は不適切です。 このため、周りのすべてがメトリックでカバーされます。

私たちは、製品（1DMP）を開発するときに、説明したアプローチの一部を使用します。 最良の部分は、これらのメトリックのいくつかを手に入れて、製品の開発/実装および保守に対して行った変更またはその他の変更を定量的および定性的に評価できることです。 これにより、反復ごとにプロセスを微調整し、より速く目標に到達することができます。



このトピックの詳細については、ビデオスピーカーをご覧ください。

Lorenzo Nicoraによる「IoTおよびモバイル向けのイベントソースのスケーリング」

この日の最後のレポートでは、負荷の高いイベント処理システムの構築に使用される微妙さ、ニュアンス、アプローチについて説明することを約束しました。 レポートの説明は多くの用語で一杯でした。比較的最近登場し（リアクティブデザインパターン、アクターモデル）、より基本的で、多くの人が使用していますが、それほど興味深いものではありません（DDD、CQRS、イベントソーシング）。



多くの記事で、さまざまなタスクのコンテキストで1つまたは別のアプローチを適用すると、激しい議論が生じ、これらのトピックへの関心がさらに高まります。



レポートは「単純から複雑へ」の原則に基づいて作成され、主な目標はこれらすべての用語を理解し、使用する価値があるものとそうでない状況を理解することでした。



誰もが、負荷の増加に伴う典型的な情報システムのスケーリングの問題を知っています。 原則として、データベースサーバーはボトルネックであり、集中的な録音中はうまく拡張できません。







ストレージへの書き込みが遅いという問題の一般的な解決策の1つは、サービスと宛先ストレージの間に中間バッファーを追加することです。 したがって、アプリケーションを水平方向に拡張し続けることができますが、ストレージへのデータの追加速度に依存する度合いは低くなります。



このソリューションには1つの大きな欠点があります。 中間バッファを追加するとすぐに、クライアントの観点から実行された2つの操作が同じ順序でデータベースに順次到達するという保証が失われました。 システムの一貫性が損なわれる可能性があります。



したがって、シーケンスが重要なイベントの特定のソースがあります。 引き続き水平に拡張したいと考えていますが、データの一貫性とその変更のトランザクションの性質は重要です。 DDD （Domain-Driven Design）が役立ちます。



この原則の主な考え方は、データの一貫性を保証できるビジネスドメインを作成することです。 最も単純な形式では、これはユーザーとそのアカウントのステータスに関する情報になります。 さらに、各入力要求は常にこのユーザーデータのみを処理する1つのプロセス（アグリゲーター）のみを通過します。



ユーザーが要求したアクションがドメインモデルのビジネスロジックの観点から実行可能である場合、プロセスは状態を変更し、行われた変更を特徴付けるイベントを生成し、トランザクションログに記録されます。



したがって、プロセスに何かが発生した場合、その状態は常にこのログから復元できます。 ところで、このタイプのシステムを設計するとき、アクターモデルは非常に重要です。







したがって、着信要求は処理され、それに基づいてイベントが生成され、トランザクションログに記録されます。 しかし、着信イベントの結果をプロセスの状態とは異なる新しい形式で表示する必要がある場合はどうすればよいでしょうか？ （たとえば、レポートを作成します。）



CQRS （コマンドクエリの責任分離）アプローチが助けになります。その名前から、書き込みプロセスと読み取りプロセスが異なる角度で分離されていることが明らかです。 システムには、ユーザーの影響の間に生成されたイベントの完全なログがあるため、読み取りタスクに最適化された形式でこのログを再読み取りすることは難しくありません。







ただし、システムは異なるアプリケーションインスタンス間で分散され、異なるサーバーに配置できることを忘れないでください。 これにより、要求をアプリケーションの目的のインスタンスにルーティングするオーバーヘッドが追加されます。このインスタンスでは、このドメインオブジェクトへの要求を処理するプロセスを利用できます。 これにより、システムの再パーティション化の感度が向上します。



このアプローチの適用は、受信の順序がリクエストの処理に重要であり、リクエストのソースがそれらの一貫性を保証する場合にのみ正当化されることに注意すべきです。 注文が重要なリクエストの良い例は、銀行口座の引き出し/補充です。



場合によっては、リクエストの送信元は、リクエストの順序と順序、たとえばデバイスのIoTセンサーや送信する信号を保証できない場合があります。 時々、これらのデバイスはオフラインまたは省電力モードになります（情報をバッファリングし、定期的にサーバーに送信します）。



また、良い例としては、デバイスがオフラインの場合に主要な機能を提供するさまざまなモバイルゲームがあります。 表示されると、彼らはプレイヤーに関する統計をサーバーに送信し、その後のゲームメカニズムでのアカウンティングを行います。 この場合、着信リクエストの処理は、基本的な検証と、さらなる分析のために大規模な分析リポジトリに記録することになります。 これにより、サービスに状態を保存する必要がなくなり、要求処理サービスを標準的な方法で水平方向にスケーリングできます。 このアプローチは、弱い書き込みの一貫性として知られています。







さらに、受信したイベントは、これらのイベントを目的の順序で構築するさまざまなタスクによって分析され、これに基づいて特定の決定が行われます。



このトピックの詳細は、 ビデオレポートに記載されています。



そのため、会議の3日目はまったく気付かれずに飛びました。 ほとんどのレポートは取り残されました。 頭は考えでいっぱいであり、発行されたノートはメモで走り書きされました。 私たちは夜の残りを、良いマグカップとおいしいステーキを片手にロンドンのパブで過ごしました。

4日目。 Javaを使用したブロックチェーン

Conor Swenssonによる「web3jを使用したブロックチェーン上のJavaアプリケーションの開発」

セミナーで、コナーはブロックチェーン技術の開発における主要なマイルストーンについて話しました。 レポートは非​​常に詳細であることが判明し、多くの企業がすでに取り組んでいるブロックチェーンの世界の傾向の1つが分散プライベートブロックチェーンの構築であることがわかるのは興味深いことでした。 さらに、いくつかの技術的ソリューションは既にライブラリーおよびフレームワークで具体化されており、2015年のLinux Foundationの参加により設立されたHyperledger Foundationの傘下に集まりました。



セミナーでは、Etheriumネットワークの例を使用して、ブロックチェーン操作の基本原則について学びました。 セミナーのコードベースは、 Solidityで記述されたスマートコントラクトとJavaマシンの間のブリッジであるオープンweb3jライブラリに基づいて構築されました。



セミナー参加者は次のタスクを完了しました。

• 自分にテスト財布を手に入れました。
  
  
• テストネットワークに接続。
  
  
• 最もシンプルなスマートコントラクトを作成し、Ethereum Blockchainで公開しました。
  
  
• 公開されたスマートコントラクトと対話する小さなサービスを作成しました。
  
  

セミナーのすべての資料はgithubで公開されているため、誰もが私たちと同様にこのセミナーを受講し、Java APIを使用してイーサリアムスマートコントラクトのすべてのニュアンスを理解できます。



セミナーに似た内容のビデオがパブリックドメインに登場しました。

結論として

ムプリャヒンと私は今でもこの旅行を非常に喜んで覚えています。 レビューの準備では、資料とレポートを何度も改訂しましたが、驚くことはありませんでした。毎回、聴衆に座っている間に気付かなかった何か新しいことに注意を払いました。 会議への旅行は、特に長い間、開発者の生活の中で常に大きなイベントです。 私たちのレビューがあなたに役立つことを願っています。 会議のスライドはこちらから入手できます 。