HighLoad ++ 2017での最高のレポートの概要

次のいくつかの記事では、HighLoad ++ 2017の最高の（ 参加者による ）レポートについて説明します。主催者は、ここで視聴できるビデオへのアクセスを親切に開放しました。

Goth2Boss：エンジニアからチームリーダーへの移行中の破損と無駄/ Artyom Kalichkin

私にとって、これは今年の始まりです-強力な技術会議で、最初の場所は技術者からですが、管理についてのレポートで占められています。 もちろん、人文科学はより多くの評価を与え、デフォルトではより忠実な視聴者を与えると主張することができますが、事実は残っています。



エンジニアからリーダーへの移行における機能と問題に関するストーリー。 レポートは2つの部分に分けることができます。 レポートのトピックを明らかにする最初のレポートは、エンジニアリングスタッフからトップのスタッフに移る際の問題に関するものであり、2つ目は、新しいリーダーの育成とケアの方法に関するリーダーへのアドバイスです。 実際、検討中の問題は、階層ラダーのすべてのレベルを対象としています。 「ただれ」は、次のレベルの制御に移行するための特徴です。





成功した場合も失敗した場合も、自分の経験を正直かつ率直に共有している専門家の話を聞くのは常に興味深いことです。



最初の非常にクールなヒントは、「自分が上手くできることとできることについて正直であること」です。 確かに、これは基本的に、新しいレベルに移行するときに持つ唯一のサポートです。 本質的に、Artyomはイントロスペクションセッションを実施し、弱点がどこにあるかを正直に（これは非常に重要です）理解することをお勧めします。 あなたが良い記憶を持っているなら、あなたは良いコミュニケーターです-これらの資質を使用してください。



それでもリーダーになることができた場合は、次の不快な瞬間があなたの方法で確実に満たされるという事実に備える必要があります。

1. 外部の脅威から従業員を保護したいという強い欲求（Good Corporationには、この行動パターンを非常に明確に示す特別な用語Shit Umbrellaがあります）。 Artyomの観点から、これはチームとリーダーにとって最大の悪の1つです。 ユニットは外の世界のブラックボックスになり、問題は隠され、自分自身に対する批判のレベルと自分の間違いが減ります。 これはすべて、仕事の質と関心の低下につながります。 人を快適ゾーンから外すどんな状況でも、追加のリソースを接続し、可能な限り効率的かつ生産的に仕事をすることを奨励します。 あなたがそれを取得したい場合-すぐではありませんが、傘を閉じます。 ところで、傘を正しく閉じる方法については、メインレポートの後に質問と回答があります。 例として、Artyomは同僚の人生のエピソードを引用します。同僚は、fakapの場合にチームに来て、「私たちは失敗しました」と言いました。 ここで重要なことは、罪を犯した人は誰もいないということです。 その結果、チームはこの到着の原因を結集し、動員し、修正します。
2. 遅れた結果を知覚するのが難しい。 ここで、エンジニアがかなり具体的な仕事の結果を持っているという事実について話しています。それは、近い将来に達成され実現することができます。 リーダーについては、すべてがより複雑です。 リーダーシップの本質は、リーダーの行動を評価する際の客観性を意味するものではありません。 誰もが明確に言うことができるとは考えにくい-「はい、プロセスを正常に実装しました」。 多くの場合、「一般に」、「十分に」、「ほぼ」などの略語を聞くことができます。 すなわち 最終結果は達成可能であり、達成されますが、すぐにではなく、そして最も重要なことには、常に結果がありませんが、頭は何も起こっていないという感覚と、行われていることが目標に向かって行われているという不確実性に悩まされています。
3. 完璧なソリューションの追求。 「善の最高の敵」であることを覚えておくことは重要です。 残念ながら、現在の現実では、マネージャーはほぼ100％の場合、情報の不足、分析の時間、または非常に理想的なソリューションを開発するためのリソースの不足という条件で決定を下さなければなりません。 少し奇妙に聞こえますが、Artyomは、あなたが完全な決定を下せば、どこかを見逃したに違いないと主張します。 そして、少なくともその開発に多くの時間を費やしました。 このような決定は非常に頻繁に行われることを自分から付け加えますが、それはむしろ幸運と多くの経験です。
4. 関連するスライド
   
   
   
   
   
   
   
   すべての新しく造成されたリーダーの惨劇は、自分ですべてを行い、一般的にあなたの手で何かをしたいという願望です。 非常に重要な点-委任の問題と、手で仕事をしたいという欲求を区別することが重要です。 常に手を使って仕事をしたいという願望が、委任する能力の欠如に関連しているとは限りません。 たいていの場合、エンジニアリング作業を行い、非常に「プロフェッショナルな破壊」をわずかに減らします。 非常に有用なアドバイス-手で作業しますが、活動の方向を戦術的なタスクから戦略的なタスクにシフトします。 引用：「元エンジニアはいません。」

ストーリーの2番目の部分は、ユニット内のリーダーの育成と検索の問題に専念します。検索、コンピテンシーテスト、募集、そして最も重要なのは、新しいリーダーの形成の最初の段階です。 どんなにかっこいい人であっても、その人を離れることはできません。



結論として、このストーリーのエピソードのヒットパレードをお届けします。

1位。

Artyomは、彼と彼の病棟がリーダーをどのように作成しようとしたかの例を示していますが、最終的に、彼らはこれがすべて間違っていることを認識し、エンジニアはエンジニアのままでした。 同時に、彼は、失敗した場合に伝説があるべきだと強調します。チームが人が前のポジションに戻った理由を説明しなければならないときです（私の個人的な経験は、これがこのような状況で最も難しいタスクであることを示唆しています）

2位。

2番目は、観客の一部が驚いたことに、フレーズが突然聞こえるエピソードです。実際、エンジニアであることは非常に面白く、マネージャーに切り替えることはピンクのポニーの国への移行ではありません。

3位。

さて、物語は10の後にそれを閉じます！ 何年も、人間は何もエイリアンではありません。 証明。







レポート終了後の25分間の質疑応答では、ITの管理とキャリア成長のトピックの関連性が再び実証されたことに留意してください。

すべてを絞りたい/アンドレイ・アクショノフ

2番目に、おそらく、今日のITで最もカリスマ的な人の1人です。 人気のスフィンクス検索エンジン「ヴォロネジ牛」の著者である超専門家（これは以前の会議のレポートからの引用だと思わないでください:)） 彼の報告を少なくとも一度は聞いたことがない人は、激しくそれを勧めます。





Andrewは最近、一般的な技術トピックについて話し始めましたが、このレポートでは、圧縮に焦点を当てて、さまざまな種類のデータの圧縮方法とアプローチの概要を説明します。 私たちは、C ++で記述した言語、またはPHPで記述した言語に関係なく、プログラミングのほぼすべての分野に適用できる一般的なアプローチとアルゴリズムについて話します。



一般に、特定の問題を解決するために圧縮は必要ではないかもしれませんが、それでも、いつでも圧縮があなたを救う状況が生じるかもしれません。 何も保存しなくても（はい、大きな変数配列を圧縮することも時々非常に便利です）。 私は自分で簡単な家庭用の例を挙げたいと思います-ディスクスペースで災害が発生したとき、低ビットレートでのビデオのトランスコードが助けになりました。これは本質的に、圧縮の1つの例ですが、品質と画像圧縮はわずかに低下しますが、これは良い結果を与えませんが、多数のファイルで-排気は非常に顕著です。



ストーリー全体が優れた例で満たされています。実際、すべては特定の問題を解決する例の分析に基づいて正確に構築されています。 私見は、情報を提示するのに最適な形式の1つです。



ストーリーには2つの部分があります。

1. コード例のコーディングと、さまざまなアルゴリズムの長所と短所の視覚的なデモンストレーション。
2. 変換、概要、変動性が高すぎるため-画像を1つの方法で変換し、ビデオを別の方法で変換します。 しかし、例もあり、それらは多くに近いものです。

したがって、コーディングについて（コーディングと混同しないでください）。

ヒント1。

「頻繁なパッキング、まれな膨張。」それだけです。 分岐します。 圧縮中のインフレーションは冷静に聞こえますが、実際はそうではありません。

ヒント2。

「大量の情報に関しては、直感は信頼すべきではありません。 確認する必要があります。 頻度テーブルを作成します。 テストでは、ほとんどの場合、最も一般的な文字はスペースとキャリッジリターンです。 そして、常にそれについて覚えているから。



しかし、すべてが常に素晴らしいとは限りません。 圧縮に失敗した場合に、どのようにして脚を撃つことができるかについての優れた例が示されています。 頻繁（スペース）は1ビットでエンコードされ、まれなものは9ビットに拡張されました。 その結果、3％の節約になりましたが、同時に、テキスト配列の要素にすばやくアクセスできる可能性を奪いました。 どのくらいの長さの要素が不明確になりました。 原則として全体が真実であることが判明しましたが、どういうわけかそれはあまり適用されませんでした。



会話は、コーディングアルゴリズムがステップごとにどのように進化するかについて続きます。「バランスを探しています」、どこでそれが本当に頻繁に行われ、どこではまれです。 その結果、圧縮率がやや低下するアルゴリズムが得られましたが、ビット読み取りの作業が不要になります。これは、他のすべての条件が同じであれば、ゲインになる可能性が高いからです。

ヒント3。

「レアを非常に膨らませることを恥ずかしがらないでください。」 確かに、同じニュアンスが再び現れます-それは常に動作するとは限りません。 それはすべてデータセットに依存します。 一般に、一般的に、圧縮とはデータセットの分析、アルゴリズムと方法の選択に関することです。 適切な選択をすると、圧縮品質と速度の両方で、すべての古典的なアルゴリズムを超えることができる結果になります。



ビートは結局何をしましたか？ 実際、何もありません-読み取り操作を実装することは単純に難しく、スペースを節約できますが、速度が低下します。 それからバイト？ しかし、Andreiが正しく観察しているように、バイトをバイトに圧縮すると、圧縮率が1であることに驚くかもしれません。 言い換えれば、声明はすべてが時間と場所を持っていることをもう一度確認します。



ところで、Andreyが引用するほとんどすべての例は、最新のプログラミング言語のほとんどで、最小限の修正で簡単に再現できることに注意する価値があります。最も重要なのは、理解しやすいことです。

変換について説明します。

ここではすべてがはるかに広い 各タイプのコンテンツには独自の特性があります。 長年にわたって一貫して、アルゴリズムの進化と誕生に注目しています。

1. 70年代-Lempel-Ziv（同じLZW、 https：//ru.wikipedia.org/wiki/Lempel__Ziva_—_Welcomeアルゴリズム。これは、PDFやGIFなどの仕様でまだ使用されています）
2. 80年代-PPM https://en.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D1% 81％D0％B6％D0％B0％D1％82％D0％B8％D1％8F_PPM （7zip、RAR、WinZipなど）
3. 90年代と2000年代は、生産性の向上と、以前に発明されたものの追加のチューニングをモットーに開催されました。
4. 2010s-Brotli- https: //ru.wikipedia.org/wiki/Brotli（主にブラウザーで使用）

悲しいかな、それ以来、彼らは根本的に新しいものを思いついていません。 すべての変換の中で、目立ったものは何もありません。最も重要なことは、ほとんどすべてが同じLZを使用していますが、より最新の実装ではLZ77です。 証明。







しかし、テキストではない場合はどうでしょうか？ たとえば、検索エンジンの場合、ほとんどすべてのデータが膨大な数の配列です。 そして、ここで人類は解決策を思いつきました-デルタコーディングとそのテーマのさまざまなバリエーション。 しかし、ここでは、アンドレイは思い出します-すべてがそれほどクールではない、これがうまくいかない状況が常にあります。 そして再び、データとタスクのアルゴリズムを選択するという考えに戻ります。 視野を広げたい人のために、レポートに掲載されたキーワード（すべてではない）のリストを以下に示します。







一般に、レポートを要約すると、次の結論を導き出すことができます。

1. アプローチはすべて非常に単純で、主なことは、どの最適な圧縮および変換技術が意味をなすかを考えることです。
2. 彼らは熱心に努力しましたが、50年間、彼らは新しいものを思いつきませんでした。 新しいものはすべて、古いものをテーマにしたバリエーションです。 そのため、特にアドバイスに注意深く従っている場合は、上記のいずれかがタスクに適している可能性があります。 そして、あなたが私を信じないなら、クールな検索エンジンとデータベースがどのように機能するかを見て聞いてください。 ボンネットの下では、すべてがレポートが言ったことです。
3. 恥ずかしがらずにベンチマークを実行し、結果を比較してください。 結果によると、zstdを優先してgzipを簡単に破棄できます。
4. Aksyonovは非常にクールです。ただし、多くの人にとって、彼は話しすぎているように見えますが、彼はそのようです。 彼の話はすべて注目に値します。

次に何が起こりますか？

3.モバイルアプリケーションの不正行為： Vadim Antonyukを定義および検出する方法。



4. IPカメラのファームウェアをRust / Max Lapshinで作成します。



5. BigMail：ロシアポストでのDataLakeの作成方法/ Alexey Vovchenko。



6.安く、信頼性が高く、簡単です。 OKのペタバイトのビデオと写真の保存/ Alexander Khristoforov;



9. JavaおよびLinux-操作機能/ Alexey Ragozin;



10.因果整合性がMongoDB / ミハイルチュレネフ（ミシャチュレネフ）でどのように実装されているかの詳細。

それまでの間、 TeamLead Confカンファレンスでチームリーダーのトピックについて議論を続け、 Backend Confサーバープログラミングカンファレンスで適切に成長している手を借りて、圧縮と一般的なプログラミングを続けてください。