devopsからスタートアップまで:AppStoreに2年。 パート1.はじめに





この一連の記事では、従業員をスタートアップにした経験について説明します(Megalentaオフラインブラウザーは既にAppStoreで正常に作成および公開されています)。 一部の記事には技術的な詳細が含まれ、一部の記事(この記事のような)では、プログラミングとITの両方の一般的なトピックに関する議論の可能性が高くなります。



「devops」という用語はあまり好きではありませんが、現代の用語では、これは私の最後の職場で10年以上行ってきた作業範囲の最も近い(しかし網羅的ではない)記述です。 私はいくつかの分野を非常に深く、いくつかは表面的に研究しましたが、ITでの20年間のキャリアを通して、「不必要な知識のカルト」と呼ぶことにした奇妙な機能に常に出会っていました。 これは私の個人的な意見であり、誰にも押し付けるつもりはないことをすぐに警告しますが、これから記事シリーズを開始する必要があります。そうすれば、後で「技術的に」または他の観点から「間違っている」と思われるロジックを理解できます決定。



私のキャリアの最初の頃、​​私はITのあらゆる分野に特定のマイクロ宗教があり、せいぜい特定の考え方を広め、最悪の場合、特別な用語の束と「正しく」 さらに、多くの用語は、この分野に特化して作られているか、特定の意味を持ち、人間の言語およびITの他の分野の両方でこの用語の意味とは根本的に異なります。 私が話していることを明確にするために、ITのさまざまな分野における「ドメイン」と「ノード」という用語の意味の数を覚えておいてください。 場合によっては(たとえば、プログラミング言語や適切に設計されたフレームワークで)、これは論理的で有機的なように見えることに同意します。 しかし、多くの場合(たとえば、会計システム、Bitrix CMSなど)、人からの不慣れで、時には非論理的な用語や規則が大量にあると、脳が爆発し、しばしば不当な劣等感が生じます。



初めて、デンマーク王国で何かが汚れていたのではないかと疑っていました。各支店について、その規模に関係なく(この記事では、現在および将来、会社について言及するとき、従業員としての私の最後の勤務地を意味します)彼は、ハードウェア、OS、および通信に関してITインフラストラクチャを担当し、少なくとも3台のWindowsサーバーをインストールしました(これには信頼性のための冗長性はありません)。 技術的な詳細を説明できません 私はActive Directoryのスペシャリストではありませんが、フォレストを整理し、Active Directoryで複製するためのルールに何らかの関係がありました。 すべてがマイクロソフトのルールに準拠していることは間違いありません。 彼はシステム管理者向けのマイクロソフトコースを修了しました。 そして、マイクロソフトの開発者でのセミナーで、私たちがすべてを正しくしたかどうかを特定しました。 その結果、1台のワークステーションでも、Windows Serverを実行している少なくとも3台のコンピューターの存在が必要になりました。 今ではすべてがシンプルになっている可能性がありますが、2003年にはそうでした。



一般的にそのような「ルール」、特にMicrosoftについて洞察を得ました。数年後、Excelのアドオンを公開する要求に応えて、Microsoftの従業員から「loram@microsoft.com」のような返信先の手紙を受け取りました「。 私たちはIvanK@firma.comのような企業の住所と平和に暮らしていたことがわかり、Microsoftのコースで私たちはすべてが間違っていると語り、教えたとおりにすべてをやり直しました。 ルートドメインを「firma.com」とし、サブドメイン「city.firma.com」を作成し、「Firstname。Lastname@gorod.firma.com」という形式のアドレスを含めます。 このような長い住所で私たちがどれだけ口論して誓ったか、しかし、それが正しいなら、それは必要です。 マイクロソフトは、判明したとおり、独自のルールに従う必要はありません。 そして、以前に、スピード、最適化、または混乱することを嫌がり、愚かにも「松葉杖」を運転し、いくつかの教義やパラダイムに違反した場合、私は自分の劣等感を感じず、ある意味で私の良心を苦しめました現在、このような内部紛争ははるかに少ない頻度で発生し始めています。 将来、ルールを解釈する自由(社内および一部の言語または地域で一般的に受け入れられる)は、多くの場合、このような「不作法」について非常に否定的な同僚との論争の原因でした。 しかし、ビジネスはビジネスであり、私の松葉杖が彼を助けたなら、私を完全に間違っていると呼ぶことは不可能でした。 多くの場合、これらの紛争の結果として、動物園のラクダについてのジョークをもう一度言いたいと思います。



小さなラクダは父ラクダに尋ねます:

「お父さん、お父さん、どうしてこんなひどいひづめがあるの?」

-さて、砂漠に住んでいます、砂の上を歩いているので、足が最後に砂に落ちるのを防ぐために特別に広い蹄があります...

「ああ、はい...なぜそんなに厚いコートですか?」

-だから日中は砂漠で暑く、羊毛は太陽光線を体に通さず、体に涼しく、夜は寒く、それから私たちを暖めます...

-ああ、なるほど...でも、どうしてこんなに下唇が突き出ているの?

-さて、ラクダの棘があるように特別です。 彼女の唇と口をこじ開けて......

-お父さん、よく、なぜ背中にこぶがありますか?

「だから私たちは砂漠の船です。私たちは長い間、食物も水もなしに砂漠の広がりを歩きます。そして、こぶの中には食物と水があります...」

-ああ、そうだね...しかし、はっきりしないことが一つだけあります。サマラ動物園でこのチューニングをすべて行う必要があるのはなぜですか?!



その後、さまざまな理由で企業向け製品の開発に直接参加することをやめたとき、2つのすばらしい記事に出くわしました。ArchitectureAstronautsに 脅迫させないでください 。 彼らは、ドグマとパラダイムに対する現在の態度の形成に少し近づきました。



その後、IT以外の分野でも同様の状況に気付き始めました。 金融、香水、化粧品、会計システム、さらには教師向けの英語コースでも、さまざまな程度の発達と成熟度のマイクロ秒科学があり、これらの疑似科学を研究した人々による頬の膨らみ、そして有料のトレーニングと認定がありました。 場合によっては、状況はまだ明らかではなく、よりcなものでした。 たとえば、有名な香水メーカーは、コンペティションという名目で、その月/四半期/年のベストセラーのためにパリでトレーニングと認証を組織しています。 当然、売り手とコンサルタントは、競争の1か月前と2か月後の両方で他のブランドの存在を忘れています(結局、新しい知識を誇示したいです)。 そして、この状況はさらにevenい形をとることがあります。ある一般的な場所でのトレーニング証明書の利用可能性が必須または非常に望ましい場合。 思い出させてください、今はITだけではありません。 たとえば、英語の教師向けのある種の国際証明書があり、テストの質問の1つは次のように聞こえます。「ポートフォリオから定規を取得し、その名前を英語で発音するように生徒に求めます。 このアクションの名前は何ですか?」 つまり、彼らもそのために独自の用語を思いついたのです!



一般的に、私の理解における不必要な知識の崇拝の肥大化は次のように見えます:1人の才能のある、または単なる正気の人でも何かをうまくやった後、彼の技術/アイデアを開発する過程で、いくつかの企業はトピックを取り上げてお金を稼ぐことができると決定します残りの人もこれを学びたいと思っています。 用語を学んで暗記したバカでさえ同じことを繰り返すことができるように、彼らは多くの用語で疑似科学を作成し、その後、彼らはトレーニングを売り始め、「チーク詐欺師」のコミュニティを組織し始めます。 しかし、その後悲しいことが起こります。因果関係が失われ、常識があり、この常識に基づいてプロファイルの問題の解決策を簡単に生成できる場合でも、このコミュニティはあなたを拒否するか、あなたを認識しません真剣にこの擬似科学とその用語の無知による。



それでも、上記の状況を認識しても、製品を構築する際に「何が良くて何が悪い」という分野の最終的な理解に近づくことはできませんでした。 また、自分や他のプログラマーの作成時に参照用語を使用して作業を「正しく」整理する方法、最大の柔軟性/効率比のためにどのように理想的に詳細にする必要があるか、アーキテクチャを詳細に調べ、UMLを描画する必要があるのか​​、私はまったく理解していませんでした 結局、新しい製品を作成するとき、私は専門家ではないテクノロジーを選択します。また、アーキテクチャを事前に決定したり、用語を定性的に評価したりすることはできません。 別の皮肉なことに、私がこの技術の専門家になったとき、次のタスクは別の技術であるか、現在の技術が進化して再びアマチュアのように感じることです。



私はこれらすべてに論理的な説明があることを理解しましたが、それを形式化することはできませんでした。 そして、音楽が助けになり、すべてをその場所に置きました。 交響楽団によって演奏されるクラシック音楽があります。 アーキテクト(作曲家)、PM(指揮者)、詳細な技術課題(スコア)があります。 また、まったく異なる方法で音楽を作成および再生するロックグループがあります。 ブライアン・メイがフレディ・マーキュリーに「ボヘミアン・ラプソディ」を演奏するためのメモを要求していると想像できますか? ロックバンドでは、誰もがお互いを完全に理解し、スキルと才能によるパフォーマンスに貢献します。 その結果、私はオーケストラ、ロックバンド、ジャズマンという異なるルールの3つのアプローチがあるという結論に達しました。 数百人のプログラマーでフレームワークまたは複雑な製品を作成する場合、交響楽団の規則に従って作業する必要があります。 数人のスタートアップにとっては、ロックバンドで演奏するだけで十分ですが、非常に才能のあるミュージシャンがいます。 さて、サクソフォン奏者だけが完全な即興演奏を行い、個人的に、そして完成品を迅速にリリースするために、彼にとって都合の良いすべてを行うことを妨げるものはありません。 別の質問は、音楽の絶対的な耳なしで即興演奏することは不可能であるということです-それは完全にがらくたになるでしょうが、私はそれを持っています(長年の経験と松葉杖を運転することができ、体系的な解決策を作成する方が良いプロの「本能」の形で)。 私はこれに落ち着いて、柔軟性と意思決定のスピードのために「ジャズマン」オプションを選択し、製品の作業を開始しました。 どの製品とプラットフォームを使用するか、どのツールを使用するか、どのデッドロックを訪問したかについては、次の記事を読んでください。ただし、今のところ、結果を評価できます-itunes.apple.com/en/app/offlajn-brauzer-megalenta/id1013837150



All Articles