「フロントエンドから抜け出す時です」：アンドレイ・シトニックは、コミュニティの停滞、オープンソース、そして

Evil Martiansの Andrey Sitnikは、フロントエンドで最も有名なロシアの名前の1つです。彼のプロジェクトPostCSSおよびAutoprefixerでは、何万ものGitHubスターが占めています。 しかし、アンドレイはニューヨークに住んでいて、世界中を旅しているので、ロシアで彼を見つけることはめったにありません。



5月には、HolyJS会議でサンクトペテルブルクに滞在し、HolyJSプログラム委員会のメンバーであるDmitry Dmitry Makhnev MakhnevとMaxim Yuzvaがこれについて詳しく尋ねました。 Andreiがフロントエンドが停滞していると考え、なぜ私たちのプロジェクトのコードが膨張しすぎていると思いますか？ 各国のITコミュニティの違いは何ですか？ 英語を学ぶ方法と、なぜそれが見かけよりも重要でないのですか？ 2016年にHolyJSで発表されたLoguxプロジェクトはどこに戻りましたか？

現在のプロジェクトについて

ドミトリー：最初に、あなた自身について簡単に教えてください。あなたはどこにいて何をしているのですか。



Andrei：私の名前はAndrei Sitnikです。私はニューヨークに住んでいますが、旅行をたくさんしています。 ほとんどの場合、彼らはオープンソースとパフォーマンスで私を知っています。今では「IT分野のメディアブランド」と言うのが一般的です。 本当にふさわしいとは言えませんが、運は私に貢献しました。



オープンソースに加えて、Twitter @ LinguoPunk 、 @ LostInWikiのウィキペディア、性的実証主義の戦いで言語の多様性を促進しています。



ドミトリー：現在取り組んでいるプロジェクトは何ですか？



Andrew：オープンソースにはいくつかのサポートプロジェクトがあり、最も有名なのはPostCSSとAutoprefixerです。 おそらく、PostCSSがわずかにアクティブになっている可能性があります。AlexeyBondarenkoはAPIに対して非常に大きな更新を行ったため、まもなく大きなリリースが行われる可能性があります。



Autoprefixerはリリースをサポートしています。 私たちが現在積極的に見ているのはIE 10-11のグリッドサポートだけですが、グリッドを積極的に推進していたレイチェル・アンドリューの抵抗のためにうまくいきません。 彼女は非常に有名な人物であり、CSSで自動的に何かを行うツールが好きではありません。このような宗教的な闘争です。 反対に、残念ながらこの機能は特に普及しませんでした。



ドミトリー：レイチェルは楽器を作るのをどのように止めることができますか？



Andrew：このツールは何も邪魔せず、動作します。 しかし、オープンソースはプログラミングに関するものではなく、オープンソースは社会と社会化に関するものです。 誰もあなたの製品を使用したり、メディアについて語ったりしない場合、それをする動機はありません。 その結果、それをやった開発者のモチベーションにぶつかり、それを続けています。 彼らのヒロイズムについて話す人はほとんどいませんが、彼らはまだ偉大な仲間であり、本当のヒーローです。



実際、私たちは私たちが望み、そしてできるすべてを実装しました。この仕様では一般的に不可能な自動グリッドのサポートでクレイジーなアイデアさえありますが、セレクターの魔法の巧妙な組み合わせの助けを借りてこれを行う方法を見つけました。



一般に、PostCSSとAutoprefixerはサポートされており、追加される機能はほとんどなく、ほとんどが小さな機能ですが、Loguxは積極的に開発しています。 そして今年は、特定のオープンソースプロジェクトよりも記事に専念したいと思います。



ドミトリー：解雇をたくさんしましたが、2016年のHolyJSでのプレゼンテーション後のLoguxについては、彼に何が起こったのか、本当に聞いていませんか？



アンドリュー：これは非常に興味深いトピックを提起するので、良い質問です。 実際には、ソフトウェアを配布するさまざまな方法があります。



オープンソースの使用は、何らかの合理的な意思決定ではありません。 ソフトウェア開発は、ファッション業界によって最もよく説明されています。 技術的な選択は、まずファッション、誇大広告などです。



したがって、新しいソリューションを促進するための戦略がいくつかあります。 たとえば、何かが表示されても正常に機能しませんが、巨大なものを見逃す恐れがあるため、人々はすぐに誇大広告の列車に乗って、のこぎりを切って作業状態にします。



良い意味で、人気のあるオープンソースプロジェクトの半分以上はうんざりするように書かれています。 むしろ、それらの周りの誇大広告は、コードの品質と主催者からのサポートのレベルと完全に矛盾しています。 しかし、多くの人がすぐに誇大宣伝の列車に座ったので、プロジェクトは生き残り、存在し続けました。



たとえば、Babelプラグインには非同期性はありません。 プラグイン内で非同期関数を作成することはできません。これはひどい問題です。巨大なBabelアプリケーション市場をひどく制限しているため、どのように本番環境に入ったのかわかりません。 しかし、彼が書かれたのは、彼の建築です。 バベルにはたくさんの楽しみがあります。



これは広まる1つの方法です。「明日までに学ばなければ、すべてがなくなってしまいます。すべてには、市場にはこの技術で3年の経験を持つ人が必要です。」 しかし、別の方法があります。 例えば、Reactでは、彼らはそれを異なって行いました：最初に彼らは彼らの環境で「調理」し、それから多かれ少なかれ本番の準備ができたプロジェクトを提示しました。 もちろん、未解決の問題は、彼がどの程度正確に本番の準備ができていたかですが、フレームワークの100％準備が整っていないことは明らかです。



Loguxは、クライアント/サーバー通信システムです。 GraphQLであろうとAjaxであろうと、クエリのアイデアは不安定なインターネット向けではなく、うんざりするような状況で機能します-これはほとんどのサイトの既知の問題です。 Loguxは別のアプローチであり、その結果、技術的には非常に大きなソリューションです。 アイデアは新しいものではなく、そのような解決策はたくさんありますが、それらは失敗し、心配しました。 GraphQLでさえ、ひどいきしみで作られていました。



私の意見では、この種のタスクには誇大広告トレインは機能しません。 誰もがそれにぶつかってすべてがうまくいくように決定することはできません。 フロントエンドとバックエンドにソリューションをすぐに提供するとき、誇大広告の列車ですべてを解こうとすると、コミュニティ間の対立につながります。



そのため、Loguxではこれを行わないことにしましたが、プロジェクト内で慎重にゆっくりと準備します。 今年か2年、私たちはAmplifer内でLoguxを調理し、さまざまなプロジェクトで使用し、back-dersがどのように反応するかを見ました。 私は説明し、見せようとしましたが、Dima SalakhutdinovはRuby-confuに行ってLoguxについて話し、それらがどのように反応し、バックエンドにどのようにそれを与えるかを確認します。 「これは誇大広告だ」という精神でフロントエンドベンダーに私たちの言うことを伝えるのは間違っているので、そこではうまくいきません。



ドミトリー：なぜ機能しないのですか？



Andrew：バックエンドは停滞またはサポートのいずれかのシステムに切り替えました。近年、開発はほとんど行われていません。 その結果、優先順位が異なります。6か月ごとに新しいフレームワークがないと、影響を受けます。 Rust or Goのどこかにありますが、Ruby-何が新しいのでしょうか？ その結果、人々は他のことに集中します。 もちろん、私は大幅に簡素化し、バックエンドバックエンドは異なります。



これをバックエンドとクライアントに正しく配布したいので、実際に動作する既製のソリューションを提供したいと思います。 2017-2018年には、既に0.2の作業バージョンがありましたが、スケーラビリティはありませんでした。 スケーリングの方法は考えていましたが、PRには十分でしたが、実際は間違っています。



代わりに、理論上ではなく実際のスケーラビリティの問題に対処します。これは、それがあなたにとって理解できず、どの時点でわからないかです。 また、Loguxでは、システムを真剣に活用しました。たとえば、一度に複数のサーバーでサーバーを簡単に上げることができ、1つのコマンドでその数を増やすことができます。



実際の分析ができるまでこれを行うのは無意味です。 それがないと、プラグの入手場所がわからないからです。 好きなだけ拡大縮小できますが、拡大縮小しない場所が1つあることがわかります。 そのため、スケーリングの準備が本当に整ったコードと膨大な数の分析があります。どのように、どのくらいの時間を費やし、リクエストが何件入ってくるか、プラグの開始位置を確認できます。 たとえば、1秒あたりの操作の数またはユーザーの数によって、サーバー上のこのすべてが異なる方法で解決されます。



ドミトリー：それは十分に興味深いですね。 そして、私が理解しているように、計画は近い将来に十分な大きさですか？



Andrei：はい、すでに実用的なアプリケーションの計画を完了しています。0.3をリリースし、大量のアプリケーションには不十分なドックを作成します。 そして、コードは良いです。

Nano IDと高速インターネットについて

ドミトリー：あなたはインターネット接続の話題に触れました：誰もが私たちのインターネットが安定していて良いという事実に慣れていますが、実際にはすべてが完全に間違っています。 そして、ここではバンドルのサイズなどに注意を払わないことは不可能です。プロジェクトNano IDを覚えておいてください。 どうしてそんなに気にするの？ サイズから始めましょう。



アンドリュー：誰もが通常のインターネットを持っているとき、それは「マッチを節約する」ように思えませんか？ いい質問です。



Nano IDは、IDを生成する141バイトのライブラリです。 200バイトから減らしたとき、これは実用的な意味をなしませんでしたが、それを考える時が来たという「政治的マニフェスト」でした。



JSサイズは興味深い問題です。 第一に、コンパイラはそれを解決しませんが、逆も同様です。ほとんどのバンドラーは、誤って結合したり、サイズを大幅に増やしたり、非効率的に使用したりします。



そして、インターネット接続の速度が向上しているという事実は真実であり、同時にそうではありません。 インターネットが加速するとすぐに、各国は、たとえば中央アフリカなど、すべてが非常に悪い場所であると宣言します。 また、モバイルなどの新しい市場も登場します。 また、注意が必要な問題があります。ダウンロード速度は向上していますが、サイトの読み込みは速くありません。 サイトのページサイズをネットワーク速度で除算すると、すべてをすばやく開くLTEを確認できます。



問題は、実際のサイトの読み込み速度が他のパラメーターに依存することです。 たとえば、ラウンドトリップの数 。 事実は、信号が到着して戻ったときに、要求と最初のバイトの間で必然的に時間が経過することです。 この時間は非常に長く、最大500 msです。 第一に、光の速度のために、第二に、機器が遅いです。 また、ファイルが相互にロードされると、サイトの速度が低下します。



幸いなことに、私たちはずっと前にこの問題を発見し、その解決方法を学びました。 しかし、彼女だけではありません。 最近、別の問題に遭遇しました。問題はインターネット上ではなく、コンパイルの速度にあることが判明しました。 実際のところ、1メガバイトの写真はダウンロードして表示するのが簡単であり、1メガバイトのJavaScriptはコンパイルする必要があるため、ブラウザにとって2〜3倍重いです。 そして、JSの数は増え続けています。 そして、これは低速サイトの客観的な問題です。



エントロピー法を使用して、サイトを調査する問題に巧妙にアプローチできます。 重量が1 MBのWebサイトがあります。 「情報量」という概念があります。 メガバイトは単なる行数ではなく、このコードに含まれる意味の大きさです。 また、1 MBを必要とするサイトの複雑さはどの程度でしょうか？ サイトには本当に多くのユーザーケースがあり、それらをカバーするために膨大な量のコードが必要ですか？



実際、そのようなケースはほとんどありません。 Linuxカーネルには非常に多くのものが必要ですが、サイトには必要ありません。 したがって、冗長コードがたくさんあります。



Nano IDの動きの意味は、すべてのバイトを節約することではなく、「バンドルに何が含まれているのか」と考えることです。 そこに1 MBあるのは何ですか？ そのようなボリュームが必要になるタスクはありません。」 ほとんどのサイトでは、コードの75％が使用されていません。 Nano IDは、ユーザーにこのコードを送信することに反対する動きです。



なぜそれほど多くのコードが使用されないのかを考え始めると、それが巨大なチームでなければ、1メガバイトのコードを手動で書くことができないことがわかります。 これは、長年にわたって記述できる従来の「戦争と平和」よりも多く、同時に相互依存関係のためにコードの記述ははるかに困難です。



ほとんどの場合、このボリュームはライブラリです。 Moment.jsの有名なストーリー：あなたはそれをつなぎ、webpack操作の特性のために、それはあなたのウェブサイトにすべての言語をロードします 。 そして、多くの同様のケースがあります。



かつて、Loguxで一意のIDを生成する必要がありました。ライブラリを取得すると、その重量が100 KBであることがわかりました。 ランダムIDを生成するのになぜそんなに必要なのですか？



このようなサイズは、ほとんどの場合、ライブラリ開発者がそれらのスペルを間違えているという事実によるものです。 したがって、主なアイデアは、ライブラリ開発者がプロ​​ジェクトのサイズを制御できるように、 サイズ制限を使用することです。 ESLintのように、ちょうどライブラリサイズのため。 そして、膨大な数のライブラリが半分になることがすぐにわかります。



ドミトリー：質問はコードのサイズだけでなく、開発ツールのアプローチに関するものでもないように思われませんか？ ライブラリを個別の関数の代わりにオブジェクトとしてエクスポートし、Googleクロージャーコンパイラを自分のリスクで接続しない場合、誰も私をカットしません。 問題は、単にコードを書くことよりも深いのでしょうか？



Andrew：ツリーシェーキングの問題は、JavaScriptでは機能しないため、本当に関連があるとは言いません。 誰もがトライシャッシングが問題を解決すると考えていますが、違います。 最も一般的な問題は異なります：パッケージが何をしているか。 Rollupを使用して、プロジェクト全体を1つのファイルにパックします。たとえば、依存関係がそこにパックされていることがわかります。 これは大きな問題であり、Size Limitの助けを借りて、各プロジェクトで繰り返される可能性のある依存関係を削除したため、1つのライブラリを大幅に削減しました。



2番目の問題は、Node.jsのAPIを誤って使用することです。 たとえば、 choo.jsライブラリ（「コンパクトJSフレームワーク」）があり、Node.jsアサートモジュールを使用して着信引数がチェックされました。 そして、ほぼ4 KBをロードします。 そして、小さなライブラリのために、追加の4 KBを出荷しています。



そして、そのような問題は、ツリーシェイキングが使用されるものよりもはるかに一般的です。



トライシェークの最善の推奨事項は、アセンブリ内のファイルを分割し、別々のファイルに別々の関数を置くことです。 しかし、ほとんどの場合、問題は異なります。 --whyオプションを指定してSize Limitを実行するだけで、モジュールを使用するときにwebpackが埋め込む大量のゴミを確認できます。



マキシム：それから、アセンブリにwebpackを使用するのは悪いマナーですか？



アンドリュー：何を話すか見てる。 ライブラリを作成する場合、ほとんどの場合webpackは必要ありません。 別のファイルが必要なユーザーは1％未満であり、同時に別のファイルへのリンクとしてライブラリを挿入すると、サイトの速度が低下するため、webpackを使用するように強制することをお勧めします。



しかし、どのユーザーがあなたのライブラリを収集するか、どのユーザーがサイトを収集するかは、実際には違いはありません。 フロントエンドでは、ライブラリを誤って使用するとすべてが悪くなり、今日webpackからParcelに切り替えなければすべてが別れ、貧しい開発者であることに慣れています。 いいえ、正直に言うと、ツールについては気にしません。



webpackには多くの問題がありますが、これは悪いバンドラーですが、それがあなたのために機能するのであれば、作業を続けてください。 これは最も放棄されたプロジェクトの1つであるにもかかわらず、彼が問題の解決に役立つプロジェクトを見ました。 たとえば、そこにあるcss-loaderはロシアの1人によってサポートされています。 これは本当のヒーローですが、彼が忙しい場合-それだけで、誰もあなたの問題を解決しませんが、多くの問題があります。



webpackの使用をやめるべきだと言っても、それはコレクターが優れているからです。 しかし、再び、新しいプロジェクトを試してみて、古いプロジェクトを変更しないでください。 私たちはフレームワークとツールに多くの自慰行為をしますが、実際にはコードの作成方法にはまったく影響しません。

なぜ誇大広告と貴族が悪いのか

マキシム：あなたは、より急なバンドラーを支持してwebpackを避けることについて話しました。 あなたのレベルの人々からのそのような推薦が誇大広告を作成するという事実に問題があるのでしょうか？ 何か新しいものを使用することを推奨する代わりに、「押し上げてwebpackを再びすばらしいものにしましょう」と言うだけでしょうか？



アンドリュー：いい質問です。 一方で、そのようなコメントが文脈を理解せずに知覚される場合、本当に問題があります。 しかし、別の問題があります。私は停滞を恐れています。



実際、フロントエンドは停滞しています。 私たちの人生の終わりまで、私たちはReactの後援の下で生きます-クリティカルマスが獲得されるため、単一の新しいフレームワークがそれを置き換えることはできません。 それはバックエンド言語のようなものです。古い言語は新しい言語に負けません。なぜなら、いくつかの狭いタスクを除いて、移行のための臨界質量、条件がないからです。 これでフロントエンドが始まりました。



フレームワークとビルドシステムの停滞は非常に大きな問題を意味します。つまり、生き方を教えてくれる人々の停滞です。 フロントエンドの星はまだ同じであり、その結果、新しい星は来ないので、私たちは今これを見る。 そして、人々の停滞は、アイデアの停滞も意味します。 これまで間接的なパラメーターでこれを見てきましたが、新しいアイデアをもたらすには十分な慣性があります。 しかし、あなたは会議に来て、すべて同じです、そしてそれは本当に私を落ち込ませます。 私の意見では、フロントエンドの世界を倒す時です。



それはJavaのようなものです-すべてがうまくいく巨大な市場ですが、新しいものは何もありません。 この問題に対処する方法-私は知りません。 しかし、これは私が小さなプロジェクトにdrれ、常にアドバイスをする理由の1つです。



正直なところ、webpackは書き換えが非常に難しく、作成者はDXの品質を気にせず、自分で作成してユーザーとはほとんどやり取りしません。 さらに、書き換えが非常に困難になるアーキテクチャ上の問題があります。 webpackチームには正直なところうまくやろうとする人がいますが、私たちがこれをするのを妨げる困難があります。



コミュニティがあり、それをどこに移動するか（古いツールを安定化して追加するか、新しいツールを使用するか）-私には答えがありません。



理想的な世界では、古いツールを使用するのが悪いという感覚を生み出すことはありませんが、新しいプロジェクトでは新しいツールを使用します。 そして、私はそれを作成する方法がわかりません。 確かに、間違った勧告がなされ、人々は「間違った」ものを使用するために他人を毒し始めます。



マキシム：あなたの意見では、MicrosoftやFacebookのような大企業がwebpackやBabelのような主要なオープンソースプロジェクトの購入を開始する可能性はありますか？



アンドリュー：購入-いいえ。 コミュニティが新しいアイデアをもたらす限り、これは彼らにとって有益ではなく、これは本当のビジネス上の利点です。 それらはそれらを制御します;それは異なって働きます。



残念ながら、この問題はフロントエンドで既に発生していますが、それは会社が何かを購入したという事実には表れていませんが、変化しないスターがいくつかあるという事実では、彼らは常に2階になり、私たちがどうするかを言いますコードを書きます。 彼らはお互いを知っており、お互いに近づき、何かをするように依頼する方が簡単です。 したがって、彼らの意見は他の人々の意見よりも重要です。 これは社会でエリートを作成する古典的なシステムです。



社会的なエレベーターのシステムがなければ、これはエリートが保護され、アイデアが古くなるという事実につながります。 問題は、企業がそれらを管理していることではなく、どのフロントエンドを使用するかを決定する非常に少数の人々のグループがあることです。 ブラウザの動作は、Chromeを使用しているごく少数の人々によって完全に決定されます。 Chromeの人気が高まり続けると、大きな問題が発生します。



主な問題は、企業支配ではなく貴族の創造です。 これは、フロントエンドを停止する時だと思う理由の1つです。貴族はすでに形成されており、私たちは何もできません。 たとえば、欧米市場では、あなたがどれだけクールで、どのクールなアイデアを宣伝しているのかは重要ではありません。おそらく、突破することはないでしょう。 昔のスターは、チャンネル登録者数が1桁以上多く、メディアの影響が大きく、彼らのアイデアはあなたのものよりもはるかに重要です。



Dmitry：大企業で働くことではなく、オープンソースとグローバルなアイデアを提供するという点で「突破しないでください」。



アンドリュー：はい。 聞いてください、あなたは大企業で働くのは良いことだと言います。 もちろんそうではありませんが、これらは[わいせつな]ギャレーです。 私たちは何について話しているのですか？



ドミトリー：さまざまな感覚があるかもしれません。 誰かが、これがこのように世界を変えるかもしれないと感じています。なぜなら、ビジネスと一緒に、開発から少し離れると何らかのサポートがあるからです。



Andrew：実際のところ、ビジネスは異なっています。 本当に良い会社は、たとえば37signalsとDHHだと思います。



面白いのは、間違った決定をしたために多くを失ったという非常に不愉快な気持ちでフロントエンドを見ていることです。 最初はとてもクールで、たくさんのアイデアがあったとき、私たちは常にそれらを受け入れ、どこかに行きました。 しかし、最終的には、大企業の投資ですぐに成長するスタートアップの全体像はひどいものでした。



これらの企業は独占企業になり、データを販売し、ひどい決定を下します。 ValleyがITで行っていることはあまり好きではありません。



DHHは、大金を投入せずにスタートアップが自然に成長するべきだと考えています。大金が投入されるとすぐに、まったく異なる条件が発生し、社会だけでなく、私たちの運動全体の発展にも悪影響を及ぼします。 私は大企業に何が起こるかを完全に嫌います。



ドミトリー：ソーシャルエレベーターに戻る場合。 あなたの意見では、あなたがまだ集まって何かクールなものを思いついた場合、エリートのサポートなしでオープンソースに真剣に取り組むことは可能ですか、それとも完全にブロックされた道ですか？



Andrew： Vue.jsには良い例があります。 これは素晴らしいプロジェクトですが、Reactを批判する対象はすべて決定していますが、Reactを破ることはありません。 どのプロジェクトを作成するかは問題ではありません。独占権がある限り、ユーザーは単に切り替える理由がありません。



「誰もが書いているように書かなければなりません。主流から離れるべきではありません」というマントラを信じており、20〜30％優れた製品を提供しても、このマントラはあなたを抑制します。 例外は、空いている市場です。 たとえば、ロシアではGoogleがなかったためYandexが勝ちました。



検索エンジンがどれほど優れていても、Googleを変えることは不可能です。 InstagramやFacebookなどの新しい市場、またはロシアのYandexなどの新しい言語市場でのみ敗北することができます。 フレームワークでも同じです。 Vueが通常存在する唯一の理由は、Reactがまだ到着していない中国市場などで勝利したことです。



一方、Vueは独自のプロジェクトとして開始され、その後、企業が参加して参加しました。 会社にお金を要求するのは恥ずべきことではないと思います。正しく尋ねれば、企業は喜んで彼らに寄付します。 したがって、企業からのサポートを見つけることは正常であり、実際に機能します。これは、Win / Winの状況です。 企業が介入して、何らかのオープンソースの問題を引き起こすことはめったにありません。



ここでの問題は、マーケティングの問題です。ウェブ開発の実施方法を決定するエリートの非常に小さなグループが存在し、そこに新しいものを提供することは非常に困難です。完全に新しい市場に参入します。

オープンソースに行く価値はありますか

ドミトリー：疑問が生じます、それは価値がありますか？



Andrew：これはいい質問です。 すぐに言います。いいえ、やらないで、新しいオープンソースプロジェクトを作成しないでください。



それらが作成される主な理由は、広告です。オープンソースを作成すると、スターと同じくらい有名になります。 しかし、実際にはこれは「生存者の間違い」です。 私はロシアにいるダン・アブラモフです。実際、氷山の一角には何百人もの人々がプロジェクトを悪化させましたが、誰にも知られていません。



良い方法では、完璧なプロジェクトを作成しても、失敗する可能性は99％あります。 例えば、私はやがてサイズ制限を作成しましたが、 最初に良い記事を書き、それをPRし、その間に別の男がプロジェクトを作成し、誰もがそれについて話し、サイズ制限が失われました。



おそらく、あなたも終了するでしょう：誰かがプロジェクトを書くかもしれません。おそらく後で、もっと悪いかもしれませんが、彼は有名人と友達であり、有名人はすぐにそれについて書くでしょう。それだけです。 これはオープンソースの外観です。実際、クールなプロジェクトを作成し、メディアの影響を受けていない人々のための墓地です。 すべてのメディアの影響は、非常に小さな人々のグループに統合されます。



それはスタートアップのようなものです。 スタートアップは本当に「人々がGoogleを作成するときの素晴らしい状況」ではなく、「Googleが登場するためには、99％の人々が自分の人生を台無しにする必要がある」という状況です。



したがって、あなたが幸せで有名になりたいなら、オープンソースにしないでください。 雇用されたい場合は、ソースをオープンにしないでください。 これらのものを得るためのはるかに良い方法があるので：会議で話す、すでに大規模なプロジェクトのドキュメントを修正する、記事を書く。



会社に来て、バベルで何らかのプルリクエストをした場合、10個の星を使った何らかのプロジェクトがある場合よりも格段にクールに見えます。 そして、これはほとんどの場合そうです-あなたがどれだけうまく書いても。



影響を与えたいだけの場合は、基本的な記事を書いて、通常とは異なる観点から基本的なことを噛むことがより重要です。 彼らは同じことを言うので、それは本当にうまくいきます、メディアスタッフはそれを再投稿します。 新しいアイデアは再投稿されません。なぜなら、彼らも理解していないからです。



オープンソースを開始する理由は1つしかありません。この世界で何かを変えたい場合です。 たとえば、PostCSSは、より多くのCSSツールが必要だったために開始されました。 Autoprefixerは、私がCompassを殺したかったからです。しかし、Compassを殺したとき、アメリカのプログラマーにOperaを無視してアメリカのブラウザ専用のサイトの書き込みを止めさせたいので、前進しました。



そのようなタスクがある場合、面白いのは、記事が機能しないということです。 これらの記事はすべて、アクセシビリティに関するものであり、リンクの代わりにボタンを使用すること、URLがない場合、覚えていないためまったく機能しません。 実際に機能するのは、これらすべてをチェックする自動ツールです。 プレフィックスの記述方法に関するレポートは100万件ありましたが、Autoprefixerが登場するまで機能しませんでした。



もしあなたがオープンソースを書きたいなら、この社会で変えたいという明確な目標を持ってください。そうすれば、あなたが失敗したとき、人々があなたのデザインを使わないとき、星があなたを無視するとき、この目標はあなたを浮かせるでしょう彼らはあなたを個人的に知りません。



ドミトリー：このスイングはどれくらい強いのですか？ たとえば、JavaScriptに型を追加することを神に許していただきたいのですが、これはすでに多すぎることは明らかです。 , ?



: , , — , . — .



: . , , , .



: , , , , , . , . , .



- , … PostCSS , , . , , . - -, , , , , .



: ?



: , , .



: , , , ?



: , , , , - , , , , , . : « Open Collective , , ».



, . . . , , , . « , , . Open Collective, , . , , , ».



, Babel webpack. : « , . issue, Open Collective , ». , . , — . , , . , .



, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .



: - , - ?



: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.



: , pet project . , , : , , -, , . , , ?



: - . , . , , .



« ». . , . , . — , , maintainer , , - .



, . , , . , , , issue, - , , , .



, ? まさか。 , , , . , , .



: , ?



: , . . . , .



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



, . , 10, , , , , .



: , , ? , - : « , ».



: , , , . , . , . «» — , , — . , , - PostCSS. .



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



— . , , , , , , . , . — , . , .

,

: , PostCSS . , ?



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



-, , YouTube. , . , . , , .



: , , , . . , , . , , , , . , , . .



: , , . ? ?



: ? . «». , — , , . , , .



, — , , . , . - QR-. , QR- , ? . , , .



, . , — , , . . , : - , . , , .



. , , , , . -, . — , , , ( , ).



— , .



, .



— .



, : . , , , - . Google - , , , .



, , , , , . — Twitter, , ( ), . , , . , , , , 150-300 .



, , , .



: - - , — ?



: , . — . , , . , -, , , , .



. , , : « , ». — , . , , XVIII-XIX . . , .



, , -. , , , , , , . , , . , , , . , — .



, , — , , . , . : - , .



, , , , , . , . .



, , , — , , .



: , .



: , . -, . , , , . , , . , , — , .



— , . , , . .



small talk — , , , , -.



. — , , . , , , , .



— , 5-10 , . , .



: , ?



: , , — . , , — . , « », . , . , — . , , . , , .



— , , , . , , . , , , . «», .



. , , , , . , , , — : , . — , , , . , «-», . , , - . — , .



. , . .



- - , , , , : « ?». «» , . , : , . , , , .



: ( ), , , .

ドミトリー：会議について話している場合、スピーカーとして参加する決定的な要因は何ですか？



Andrew：私にとって、決定的な要因は会議の可用性です。 時々、私のパスがいくつかの国を通過する場合、私は人々にあまりアクセスできない会議に同意します、ただレポートをポンプでくみます。



会議の価格が非常に高いという大きな問題があると思います。 会議はお金を稼ぐ必要があることを理解していますが、これには問題はありませんが、素晴らしい500ドルを取り、率直に言って、節約できるものにそれを使うJSConfがいます。 たとえば、夕食の場合、最も強力なアフターパーティーは、率直に言って、不快なビールを飲む方が好きですが、それは興味深い人々です。



そして、巨大な価格は、スピーカーが聴衆と話すことに興味がないという事実につながります。会議では、CRDT Viktor Grishchenkoの最高のJS実装の同じ作成者である大企業の従業員のみが非常に高価なチケットのために来ることができなかったため、トピックをサポートするのが難しい場合があります。 保存する方法はたくさんあり、それらを適用する必要があり、高価なチケットは間違っています。 会議にアクセスできる必要があります。



誰もが通常のネットワークにアクセスできるように、私はしばしば小さな会議に参加することに同意します。 また、多くの会議では、チケット価格の高い会議よりも対話が優れています。 これが私のアプローチです。



ドミトリー：会議がうまくいかないことはありませんか？ ネットワーキング、アクセシビリティ、その他についてはすでに明確になっていますか？



アンドリュー：まあ、スピーカーとして、私はステージの前にタイマーがあるとき本当に感謝しています。 この点で、HolyJSではすべてが非常に専門的であり、パフォーマンスの組織が好きです。 一般に、ネットワーキングは重要なことです。人々は知識を得るために会議に行くのではなく、レポートよりも記事を読む方が簡単ですが、コミュニティに所属しているという感覚のためです。



コミュニティは、会議で起こる最も重要なことです。 あなたが話しているという感覚、そしてあなたの中で何かが変わった、あなたは何かを知っています。 私たちの社会には「なぜ」という理解がないという良い考えがあります。 私たちは会議に参加して、なぜこれをすべて行っているのかを理解します。 そして、良い会議はおそらくこの問題を解決するでしょう。



ドミトリー：あなたは「知識ではない」と言いましたが、これは非常に物議を醸す問題です。 非常に基本的なトピックを持ちながら、非常に異なるコミュニティの人々を集めた会議に参加しませんか？



アンドリュー：はい、もちろん、それはとても楽しいでしょう。



ドミトリー：それは、真面目で強力な報告がある会議よりも面白いでしょうか？



アンドレイ：どちらのアプローチも良いと思うし、ここでも問題はない。



ドミトリー：おそらく最後の質問です。 HolyJSに何を期待しますか？



アンドリュー：良いパーティー！ 2016年には、私の人生で最高の1つであり、すべてが非常にうまく整理されました。



ドミトリー：この時間をさらに改善するためにこの時間をお勧めしますか？ パーティーをしたいですか？



アンドレイ：私は地元の会議で組織しようとします。 私たちは多くの地元の会議を開いていますが、彼らが自分で何かをする機会があるとき、それはかなりクールであることがわかります-多くのイニシアチブの人々がいます。 そして、すべての地元集会の主催者または彼らの主要な講演者に無料チケットまたは何らかの援助が与えられたら、それは素晴らしいことです。

Andreiは、最寄りのHolyJS （サンクトペテルブルク、5月24〜25日）で、オープンソースプロジェクトの推進についてさらに話します。 そして彼の他に、JSオープンソースの他の多くの重要な人物がいるでしょう：Ryan Dahl（Node.js、Deno）からMichel Weststrate（MobX、Immer）まで。 レポートのトピックに関する詳細はすべてウェブサイトに掲載されており 、チケットはそこで購入することができ、徐々に高価になります。