人々はどのようにして優秀なエンジニアになるのですか？ 例のすべての前提条件を思い出してみましょう。
祖母の村では、夏の間ずっと「追放」されていたため、退屈でした。 だから私はレゴから宇宙船を作るのを楽しんでいた。 自身のコンピューターは、専門の「バンキング」のBSUの力学および数学部門への入学に対するボーナスとして19歳でのみ登場しました。 これに先立ち、原則として両親は機器を購入しませんでした。
大学で、彼はC ++およびJavaでのプログラミングの基礎を学びました-しかし、ループとディスプレイを書くレベルでのみ。 そのようなタスクは私にあまり興味を引かなかったので、最初はプログラミングのために全然離れるつもりはなかった。 しかし、プロファイルに取り組んで財務上の誤算に関与する見通しは、着想を刺激するものでもありませんでした。ドレスコード、締め付けられたナット-これらはすべて鈍いように見えました。 ある日、誤ってWindowsの代替としてオープンソースプロジェクトとLinuxシステムについて耳にしました。 このコンセプトは私に非常に興味を持ち、私はこの分野を独自に研究し始めました。
私はギャンブルに巻き込まれました-私はPythonにGoogleを導く方法を教え始めました。 彼は次のように推論しました：PythonはLinux向けのソフトウェアをたくさん書いており、そのようなクールな企業で使用されています。つまり、独自のプログラムを作成できる言語に関する資料があります。
ある日、誤ってWindowsの代替としてオープンソースプロジェクトとLinuxシステムについて耳にしました。 このコンセプトは私に非常に興味を持ち、私はこの分野を独自に研究し始めました。
どうしてEPAMに行きましたか？
メインサイトに直接あるメールアドレスで、採用担当者に素朴な手紙を書きました。 それはカテゴリーからのものでした：「みなさん、こんにちは！ あなたをPythonプログラマーとして見たいです。 私は言語から何かを知っていますが、経験はありません。無料で、いつでも経験のために働く準備ができています。」 私はインタビューに招待され、「Pythonはありませんが、Rubyがあります-気に入るはずです。」 それ以前は、他の会社では.Net開発者のポジションをすでに提供されていましたが、フレームワークも職場の雰囲気も同意するほど納得しませんでした。
インターンシップで、彼らはRubyについての500ページの本をくれ、タスクを設定し、進捗状況を定期的にチェックしました。 数ヶ月後、独学の研修生である私はこのプロジェクトに参加することが許可されました。彼らは私に単純なバグを扱うことを許可しました。 すぐに顧客からインタビューを受け、本格的な開発者になりました。 数学的基礎と忍耐力が助けになりました。
プログラミング言語を幅広く選択しているのに、なぜRubyに最も興味があったのですか？
この言語を使用すると、構文ではなくタスクに集中できます。 RoRのオープンソースソースプロジェクトは、それを所有するすべての人にとって読みやすく理解しやすいものです。 私が会議やハッカソンでいつも会うベラルーシのコミュニティのルービストから判断すると、これらはただの宇宙の人々です。 彼らの方が多少簡単です：Rubyの構文、簡潔さ、ダイナミクスは、遺伝子レベルでエンジニア自身に伝えられるのでしょうか？
私が会議やハッカソンでいつも会うベラルーシのコミュニティのルービストから判断すると、これらはただの宇宙の人々です。
インターンから6年間、会社で一流のエンジニアになりました。 どのプロジェクトで経験を得ましたか？
最初のプロジェクトでは、3年半働きました。 それは、Ruby、Java、Perl、およびJavascriptに基づく大規模なシステムでした。 すべてのプロセスは体系化され、大規模システムは「鉄の塊」で提供されました。創造性で特に加速することはありません。 その後、約6か月後、NodeJSで、EPAMが「共催」したNetwork File Systemを操作するときにトラフィックを分析するためのコンソールツールのフロントエンドを作成しました。 主にPython、Django、およびデータベースを扱っていたときに、スタンフォードのオープンラーニングプラットフォームに基づく内部EPAM大学プロジェクトもありました。 その後、主要なPythonプロジェクトが続きました。
来年半はPythonとNodeでしか書いていませんでしたが、自宅やハッカソン中にプロジェクトでRubyを積極的に使用しました。 チームがPowerPointで美しいプレゼンテーションを行うだけでなく、24時間で製品を作成するときの本当のブレーンストーミングが好きです。 例えば、 ハッカソンのベラルーシの段階で、 LG Smart TVはスポーツ用のインタラクティブなアプリケーションを開発しました。 ちなみに、そのようなイベントに参加するために、ルビーの小さなチーム、「ハカトナー」 クレイジーキツネザルをまとめることさえできました。
チームがPowerPointで美しいプレゼンテーションを行うだけでなく、24時間で製品を作成するときの本当のブレーンストーミングが好きです。
そのような活動に参加したおかげで、私は言語をまったく忘れませんでした。そして今、最高の時間を過ごしました。EPAMは最近、フレームワークの深い知識を必要とする2つの興味深い大規模プロジェクトを開きました。
これらは、今では経験豊富なRoR開発者を必要としているプロジェクトですか？
はい 私は今、そのうちの1人で忙しく、おそらくこれは会社での6年間の仕事すべてにとってRoRで最も興味深い取り組みです。 このプロジェクトには、アメリカの顧客向けの内部セキュリティシステムの開発が含まれます。 この製品のエンドユーザーは、米国最大のソフトウェア企業です。 クライアントが非常に深刻であるという事実にもかかわらず、プロジェクトの雰囲気はスタートアップです。 強力なチームは興味深い問題を解決しますが、同時に明確に開発されたプロセスは存在せず、これは作業にダイナミクスを追加するだけです。 図形を貼り付けたり、典型的なパターンを作成したりするだけではありません。 誰も解決したことのないタスクを受け取ります。考えられるすべての結果を考慮し、アーキテクチャを操作して、自分で解決策を見つける必要があります。 多くの点で、Solution Architectの作業に似ています。 したがって、レベルD2以上の専門家を探しています。 このプロジェクトでは現在、Ruby、RoR、Lua、Go、Java（Spark、Spring）、Docker、AWSなどを使用しているため、どんなに素晴らしいサウンドであっても、これらすべてのテクノロジーを知っておくことをお勧めします。 または、天から地に降りる場合、少なくともそれらの大まかな画像を持っています。
クライアントが非常に深刻であるという事実にもかかわらず、プロジェクトの雰囲気はスタートアップです。
プロジェクトには、マイクロサービスを含む大規模で複雑な構造があります。 一般的なステレオタイプとは異なり、多くはRubyで記述されています。 私に加えて、ベラルーシ側には数人の主要なRoR開発者がおり、私たちは全部で5人です。アメリカ側では、8人のRoRチームはさらに強力です。 毎日あなたはそのような「宇宙飛行士」とコミュニケーションを取り、彼らもあなたのアドバイスに耳を傾けます！ これは素晴らしいです。
私たちのシステムには、異なるバージョン、地域、サーバーの種類、および展開があります。そのため、展開に携わるのではなく、顧客側の大規模なDevOpsチームです。 このプロジェクトでは、私たちが取り組んでいる基本的なものから始めて、マルチレベルのテストシステムを使用します。 これはすべて、製品開発時の予期しない状況のリスクを減らすのに役立ちます。 また、勤務中に顧客サポートの慣行があり、顧客自身から報告されたバグを修正します。
EPAMのもう1つの新しいRoRプロジェクトは、ドイツの顧客向けの組み込み銀行システムであり、この銀行システムは世界中の銀行にこの製品を提供しています。 私の知る限り、すでにアラビアおよびドイツの銀行と統合されています。 ダッシュボードシステムなど、このプロジェクトの主要コンポーネントはRoRで記述されています。 これはモノリシックプロジェクトであり、いくつかの部分に分割されてから、作業を同期します。 銀行システムが安定して機能するように銀行システムを削減するのは毎日ではないことを認めなければなりません。 そして、それはまったくRubyではありません。 単一の言語ではありません。 プログラマーとして開発したい人は、さまざまな方法で非標準の問題を解決できなければなりません。
銀行システムが安定して機能するように銀行システムを削減するのは毎日ではないことを認めなければなりません。
仕事でいつも従うルールはありますか？
普遍的な解決策を信じないで、「クランチ」と戦ってください。 例を挙げましょう。 Windowsマシンの脆弱性のスキャンに関するプロジェクトがありました。 Windows用のシステムは、Linuxとの類推によって作成されたもので、不安定でゆっくりと動作し、すべてのメモリを「消去」しました。 人々が同様のソリューションを見て、そのようなものを作成しようとするとき、それは古典的な間違いでした。 Linux、Windowsでうまくいったことが、ホイールの研削を始めました。
普遍的な解決策を信じないで、「クランチ」と戦ってください。
彼は、デモ版として「ひざまずいて」週末にシステムを取り上げて書き直しました。 その後、チームはそれを改善し始め、徐々に運用に移しました。 私たちは専門知識を得て、顧客は感謝していました。
数年後、あなたは誰を見ますか？
ツールを組み合わせて、さまざまな方法を使用して、新しいプロジェクト、アーキテクチャの概念、問題解決に情熱を傾けています。 したがって、将来は自分を建築家と見なします。