ヒーローになる方法（ADD-2010のJacob Sirotkin）

有名なブロガーであり経験豊富な開発者であるジェイコブ・シロトキンは、若いプログラマーの目を雇用主の不快な側に向けることを好み、これらの事実の性質を説明しています。



面接で話すのが好きではないが、直面しなければならない問題。

• 困難にもかかわらず、どのようにソフトウェアをうまく​​開発するのですか？
• ボスはこのようになりますか？
• それは何でしょうか？
• 生き方

読みたくないシックチャンネルの所有者向けに、ビデオレポートを提供できます。







車の中でオーディオを聴くのが大好き- ダウンロードして聞いてください。

ここでレポートのプレゼンテーションを参照してダウンロードします 。



Stas Fominが作成

はじめに

ここで短いレポートを作成しますが、最初に自分自身についていくつか説明します。 特別なインテリジェンスと機知に長けているというわけではありませんが、10年以上ソフトウェアを開発してきましたが、その結果は非常に心配でした。



私はjug.ruを 10年間やっており、 LiveJournalを持っています。会議で話すのが好きです。

地雷原にはヒーローはいません

次に、業界全体がどのように思えるかについて説明します。 非常に多くの異なる機能を備えた多くのプログラムがあります。 そして、実装が開始されると、顧客は地雷原にいるかのように実行されます-何かが導入されたらどうなりますか？ 同様の地雷原スキームは、多くのアウトソーシング業者に適用されます。 つまり 最初に、できるだけ多くのクライアントが採用され、できるだけ多くのスタッフがこれらのクライアントに採用され、この大きなスタッフに少量のお金が滴ります。お金がなくなると、すべてのプログラマーが辞めて「弱体化」します。

あなたの頭脳なしでは役に立たない

IPhone向けに開発したとしても、理論的には億万長者になることができます。 しかし、統計的には、あなたは自分自身を深く赤字にしています。 AppStoreの販売統計に特化した小さなレビュー記事がありました。そうです、そうです、収入が非常に多い非常に成功したプログラムがありますが、ほとんどはまったくばかげた金額を受け取ります。



そして、私のレポートで成功するソフトウェアを作成する方法をお話しするふりはしません。 ふりをしてみませんか？ 自分の頭脳がなければ成功したソフトウェアを作れないと私は深く確信しています 。 そして、私はあなたにあなた自身の脳を与えません。 これは技術的に不可能です。 しかし、私は何を望んでいますか？ あなたが考えるのに役立つと思われるいくつかの問題に触れたいと思います。 たぶん、あなたはそれを好きになるでしょう。

ヒーローになる方法

聴衆の期待を聞きたいです。 潜在的なロールモデルとして考えたいヒーローは何ですか？ バージョンはありますか？



ホールのノイズ... Linus Torvalds、Sergey Brin、...



実は、がっかりするはずです（スライドを参照）。 そして、私が何に出会ったかによって、あなたは私から学ぶことができます。 私のロールモデルはドン・キホーテです。彼は頑固に真実の光を上司に伝えようとしています。 まあ、他の皆のために。







正しいことを伝え、正しいことをしようと、まあ、なんとかして一般的に前進します。 それは非常に痛みを伴い、in辱的です。 私はアドバイスしません。







キャプテンエビデンスは少し簡単です。 これはおもしろくないと思う人もいますが、実践することで、議論したい人が常にいることがわかります。

危険な質問

なんで？

そして今、私たちは主な質問に目を向けます-なぜヒーローになるのですか？ ほら、ロシアの給料は非常に少ない。 プログラマーは通常、全国平均の2倍になります。 プログラマーがいくつかの追加の資質を持っている場合、彼は平均的なプログラマーよりも2つ多く得ます。 そして、品質は異なる場合があります-Javaの知識、インタビューで上手に振る舞う能力、良い英語...文字通り何でも。







そして、それがどうなるか見てみましょう-ここであなたは仕事をしている、合理的な良い永遠を開発したい。 そして、あなたの上司はサッカーを見たいと思っています。 誰が勝ちますか？



ホールの騒音と興奮...



病気の質問...

Bobruiskブランチにどのタスクを割り当てますか？

別の問題は、当社の領土分布、多くのお客様からの遠隔性に関連しています。 あなたの会社がボブルイスクに支店を持っていると想像してください。 このブランチにメダルを授与するタスクを任せますか？



自分でやるとメダルをもらえるのなら、ボブルイスクにタスクを与えるべき理由を自分で考えてみてください。 あなたは彼女を渡しません。 1つの場合を除き、このタスクは実行できません。



ホールの騒音→ボブルイスクでは、彼らはより少ないお金でそれをします！



Bobruiskは小額のお金を受け取ります。 彼はメダルを獲得しません。 メダルは少しのお金以上です。



観客の騒音→メダルを獲得します！ そして彼はお金が少ない。 そして、ボブルイスクを請求した人は多くのお金を受け取ります。



一般的に-Bobruiskはメダルを受け取りません。



サンフランシスコから見るとすみません、ボブルイスクでもサンクトペテルブルクでも同じです。

最初のユーザーは誰ですか？

グローバルなそのような古いロシアの憂鬱に加えて、何が起こっているのか、一般的にあなたのプロジェクトにどれだけの損害があるのか​​を見つけるのに役立つ質問がまだあります。



すぐに警告したいのですが、これらの質問は非常に慎重に行う必要があります。頻繁に質問すると、非コミュニケーション的な人々、社会的なタイプとして知られるようになるからです。



最初のユーザーは誰ですか？



ユースケースは簡単です。大臣のプロトタイプを作成します。 秘密をお伝えします。大臣は、まるで彼がここにいるかのように座っており、ここ（彼は5メートル先のテーブルを指しています）はコンピューターです。 そして、大臣は3メートルからそのように見えます。 コードがそこで機能しているのか、PowerPointでプレゼンテーションをしているのかは、彼にとっては重要ではありません。



したがって、あなたの目標が大臣のプロトタイプを開発することである場合、特にプログラミングが必要であり、何も必要ありません。

誰が責任があるのか

もう1つの質問は、誰が責任を負うべきかということです。 あなたがシステムをやっていると想像してください。 そして彼らは何も解放しなかった。 彼らは1年間働いたが、リリースはしなかった。 何も起こりませんでした。 しっかりしたバグ。 誰が処罰されますか？



非常に頻繁に、分析は彼らがだれも罰しないことを示します。 なぜなら、理論的には、このプロジェクトの主要な人物であり、彼は会社の非常勤の所有者でもあり、彼にはさらに10の興味深い興味深いプロジェクトがあります。 つまり 彼らは彼を罰しませんが、彼らはあなたを解雇します。 以上です。 まあ、それに応じて、責任はあなたに簡単に非難されます、それは簡単です。



だからパフォーマーは罰せられます...



さて、どうすれば罰せられますか？ -発砲できます-発砲します。 彼らはまだscることができます-彼らはscり、これを冷静に受け止めます。



プロジェクトの成功に関心があるだけで、プロジェクトにリソースを割り当てる人ではない場合、プロジェクトを作成することは非常に難しいことを理解しています。



誰かが本当に責任があると判明した場合、この人からサポートを受けることができるので、この質問は良いです。 解任されるマネージャーがあなたと協力している場合、プロジェクトが失敗した場合、「脅威がある」ことを彼に説明できます。彼はあなたを助けます。



つまり 質問はむしろ「私以外の人のせいだ」と聞こえますか？



この質問はやや将来のものです。「崩壊の責任は誰にあるのでしょうか？」

締め切りはいつですか？

質問はそれほど重要ではありません。 あなたがブリザードなら、おそらく気にしない、あなたはすでに市場で何年も先を行っています。



しかし、商用ソフトウェアを作成し、それを実行するタイミングが重要ではないことが判明した場合、それは誰かがあなたのビジネスがどれだけ経済的に利益があるかを計算するのを忘れたことを意味します。



締め切りがarbitrarily意的に遠い場合、プロジェクトは好きなだけお金を食べることができます。 これは、経済的にarbitrarily意的に無意味であることが判明することを意味します。



締め切りがない場合は、考える理由もあります。

製品定義ステートメントを作成する

さて、プロジェクトを成功させる方法について話しましょう。 iPhone開発者ガイドからタイトルを引用させてください。 「あなたが何をしていて、誰のために、何をしているのかを正確に定式化してください。」







人生がずっと楽になります。 ちなみに、私はオリジナルのマニュアルを読むことをお勧めします、それは愚かな人々がそれを書いたのではなく、かなりうまくいきました。

どうする

行ったことの定義があれば、空の議論に時間を浪費することを回避できます。 たとえば、ロシア連邦経済開発省のプロジェクトを行いました。 そして、17のパラメーターに従って地域の経済発展のモデルを構築する必要がありました。 パラメーターは完全にブルドーザーからのものであり、その中の何も理解していませんでした。 何をすべきかは完全に不明でした。 私は単純なモデルを提案しました-「これらのパラメーターを任意の係数で要約します」。 これは、SuperSumatorと呼ばれる完全に理解可能なモデルです。



それらは、ユーザーが係数を変更することを可能にし、同時に、どの領域で、どの係数が一番上にあるかを見ることができました。 私たちは私たちが何をしているかについて少し議論しませんでした。 これはすぐにわかりました。 完璧な品質の製品をリリースしました。



機能に関する小さなコメントがありましたが、誰も気にしませんでした。

抵抗は役に立たない

目標を設定するのに役立つものは他にありますか？ あなたは抵抗を克服することができます！



私の練習からの別のケース-私は、原則として、働きたくないマネージャーを獲得しました。 彼は他にも人生に興味がありました。 彼は開発中のタスクを起動したくありませんでした。それだけで、実際にはそれらを起動しませんでした。 しかし、彼はかつて休暇に出かけ、2階でちょっとしたキャスティングがあり、非常に明確なタスクを設定してくれるトップの非常に高いレベルのマネージャーを獲得しました。 マネージャーがまだこれを行うことに反対していたという事実にもかかわらず、私は仕様の調和から始まり、ユーザーサポートで終わるこのタスクを行いました。



彼は要件に同意しなければならないことに反対し、開発を開始することに反対し、導入に反対しました。 しかし、明確な目標があったので、とにかくすべてうまくいきました。

Joelテスト：より良いコードへの12のステップ

プロセスについて話しましょう。 そんな人がいました、あるいは、私たちのためにstackoverflow.comを作ったジョエル・スポルスキーという人がいます。







そして10年前、彼は「The Joel Test：12 Steps to Better Code」という記事を書き、そこで通常の開発プロセスの基準を概説しました。



ジョエル・スポルスキーの記事に業界はどのように反応しましたか？



業界はJoelの記事に大きなボルトを付けました。



あなたは新しいプロジェクトに来て、バグトラッカーはありません。



「バグトラッカーはありませんが、どうですか？ 「いいえ、いいえ、私たちは気にしません、私たちはそのようです。」



すべて、完全な自律性。 私は今、ジョエルのアイデアを少し創造的に語ることができますが、現実の観点からです。

プロセス

はっきりと見えないかもしれませんが、これはスイングに関する古典的な漫画本です。 さまざまな関係者がプロジェクトをどのように理解しているか、どのように見ているかについて。 誰もが異なるビジョンを持っていることは明らかです。 このビジョンは同期する必要があり、これに対処するには、努力、時間、議論、有能な手紙の執筆、会議の収集、出張のノックアウトなどが必要になります。 このために、どうにかして戦わなければなりません。

ウィキが勝たなければならない

この問題を解決する良い方法があります。 wikiを使用する必要があります。



ウィキは個人的な例で使用され、テキストが書き込まれ、同僚に書くように依頼します。ウィキが正常に開始され、正常に開発されると成功する例があります。



そして最終的に、仕様は実際にはフォームで、Joelが書いた形式で取得されます。彼は仕様の書き方に関するいくつかの記事を持っています。



「ウィキは勝たなければならない」-彼は誰を倒すべきか？ 通常、彼はSharepointを倒すべきです。 これはドキュメントの非常に大きなリポジトリであり、管理者はワードドキュメントを入れることがあります。 彼らは単語文書を入れて、それを読んでみます。 彼らは「何かがまったく理解できない、ある種のナンセンスだ」と言う。 マネージャーは言います-「わかりました、わかりました、本当に何も明確ではありません、多くの質問、私は書き直します。」



1週間後、新しいバージョンをコミットします-さて、何かが2つの場所で、ささいなことで修正されました。 簡単にはなりません。 コラボレーションのシェアポイント-私はそれが機能するのを見たことがない。 Wikiは基本的に機能します。 難しいこともありますが、うまくいきます。



Stas Fomin ：ウィキを使用した成功例に興味があるかもしれません：

• ナレッジマネジメント：倉庫からフローへ
• MediaWiki-特効薬またはスイス製ナイフ？

観客から-そして反対の例があります。 ヴィッキーは亡くなり、シェアポイントが勝ちました。



これはすごい。



Vickiはそこで編集するのが非常に不便であることに不快感を覚えました。



あなたはそれをやった、あなたはうまくやったが、ここに本当のプログラマーがいる...しかし、Linuxoidはどうだろうか？ 彼は実際に接続すらしません。ドキュメントをダウンロードすることはできますが、編集することはできません。



Wikiはドキュメントの編集がはるかに簡単です！

バグ修正

このスライドは、深い個人的な経験によるものです。 バグを修正するとどうなりますか？







まず、同僚の尊敬を得る[1]！ 「Yashaはバグを修正します...考えてみてください...」-そう、あまり有用なアクティビティではありません。



第二に、あなたは簡単に解雇することができます！ ここで、コンポーネントを作成し、バグなしで作成します。 すべてが機能し、解雇されます。 それは起こります、私は知っています。



第三のポイント-あなたはインタビューに来て、彼らはあなたに尋ねます、「あなたは何をしましたか？ 「バグを修正しました...-そして何をしましたか？」 以上です。 さあ、バグなしで書く人が必要です。



バグを修正していないかもしれませんが、インタビューでは悲しいです。



とにかくそれを修正するのはなぜですか？ 事実、バグを修正しても、アプリケーションは改善されます。 そして、時にはその効果は予想外です。 予想以上の成果が得られます。



たとえば、30分かかったアセンブリプロセスがあり、同時に、ゼネラルディレクターの手による何らかのアクションが必要でした。 そして、あなたはそれを取って自動スクリプトを書きました。 そして、ソフトウェアをより速く開発でき、より良い生活の質になったことがわかりました。



別のポイント-時には本当にバグを修正する必要があります。 本当の例は、ボスが私のところに来て、「リリースの2週間後に、バグしかありません...それにもかかわらず、リリースする必要があります...」と言うことです。 まあ、何も、2週間で静かに書き直しました。



3番目のポイント-見て、iPhoneがあります。 原則として、ノキア、HTC、マイクロソフトは、あらゆる方法で競争力のあるデバイスを製造できます。 彼らは価格を過小評価し、ディスプレイを配置し、さらに悪いことに、少なくとも大きなプロセッサ、加速度計を配置することができますが、まったく問題はありません。 彼らは何ができませんか？ 失敗しないプラットフォームを作ることはできません。 つまり バグなしで行うには、非常に困難です。 それは本当に競争上の優位性になります。



2つの検索エンジンが勝ったとき、最も単純な質問ではまったく同じですが、一部のクエリでは、あるシステムが他のシステムよりも優れていることがわかりました。 そして徐々に、すべてのユーザーがその検索エンジンに切り替えますが、その検索エンジンではバグが少なくなります。 つまり 競争の激しい市場では、バグを修正することが非常に重要です。

どの学生もバグのあるアプリケーションを作成できますが、これはトリックではありません。

タイプミスをどのくらい早く修正しますか？

次のスライドでは、ソフトウェア開発プロセスについて説明します。 つまり リリースをリリースする方法を理解する必要があります。







この状況を想定してください-リリースは年に1回リリースします。 これはどういう意味ですか？ これは、最後のリリースをリリースした人々が退職したことを意味します。



そして、リリースを開始します。 これを行う方法がわかりません。 これを行うのは初めてです。 当然、あなたはうまくいかない。 したがって、リリースは年に1回ではなく、2回に1回リリースします。



Stas Fomin ：このような長いリリースサイクルを信じていない場合は、3年間の製品リリースサイクルに関するビデオストーリーを参照してください。



ある年、何かを開発し、それを何らかの形でリリースするために別の年に仕上げます。



時々、それは一番上で終わり、あなたは全くリリースしません。

理論

共通のインフラストラクチャについて説明しましたが、効率的に作業するには、理論的な知識が必要です。 数冊の本を読むことをお勧めします。最初の本はMartin Fowlerのリファクタリングであり、それが私の人生を変えました。それを読んだ後、コーディングに多くを追加しました。







しかし、今、私はその名前、またはむしろサブタイトル-「既存のコードの改善」について詳しく調べたいと思います。 リファクタリングの革新的なアイデアは何ですか？ 現在、コードを破棄せずに改善しています。



ここで、コードの2番目のバージョンを再度作成し、それがより正確になるという事実については話していません。既存のバージョンを取得して、改良を開始します。 そして次第に洗練され、より良い結果が得られます。



そして今、ソフトウェアはまさにそれを行っています。 完璧な製品をすぐに作る人はいません。 誰もが最初に最初のバージョンを作成し、次にユーザーの反応を見て修正します。



つまり 現在、ソフトウェアは既存のものが改善されるほど開発されていません。 そして、最初の開発は、1年続くことができます。 また、製品の成功度にもよりますが、洗練は5、10年続きます。 製品が成功すればするほど、改良に時間がかかります。



別の本-「Effective Java」、第2版を読むことをお勧めします。Java5のみに関連するもので、私の意見では英語のみです。







ジョシュアブロッホはよく話します。プレゼンテーション、ビデオ、スライドを見ることができます。...Amazonで彼の本を買う必要はありません。



より関連性が高い-「パターン」、デザインパターンに関する「4人のギャング」の有名な本がありますが、翻訳が不十分であり、実際に適用すると、あまり望ましくない結果になることがよくありますが、ここではより理解しやすく、多くの頭脳がありますこの本に埋め込まれています。

レンガ

専門家はどのライブラリを使用するかを気にしません

もう1つのポイントは、現代のソフトウェアは既成のソフトウェアコンポーネント、つまり他の人がすでに開発したものに基づいているということです。 これにより、時間が大幅に短縮され、品質が向上します。原則として、傾向は明確かつ正確です。



マイナスが1つあります。 人がばかであるなら、どの図書館も彼を助けません。 だから、ある人はSOAPを使いたいと思っていますが、そのせいで反応時間が1分間長くなり、3倍のメモリを消費することを気にしません。 彼は気にしないで、やりたい、使っている、気にしない。 このプロジェクトを開始しなかった場合は、このビジネスに対処する必要があります。ここでは、インターネットを介して調査を実施するシステムがありました。 彼女はTamino XML Databaseを内部に持っていました。 すべてが非常に良かった、私は長い間XMLを扱ってきましたが、彼には1つの問題がありました-彼は1秒あたり10回を超える挿入を行うことができませんでした。 ご存知のように、1秒あたり10回の挿入は非常に少ないです。 これにはまったく対処できません。他のものを使用する必要がありますが、ORACLEは可能ですが、少なくとも1秒間に100回は実行できます。 問題ありません。ここではOracleにアクセスしますが、問題は発生しません。 しかし、当局は、「タミノは私たちの子供です。私たちは彼をここに連れて行きます。私たちは彼をそのようにただ渡すだけではありません」 そして、毎秒10回の挿入-これは膝です、まさか...まあ、私は解雇され、その後すべてがそこに置き換えられましたが、-部分的に...

XSLT



良い例がXSLTです。 ビューからデータを分離できます。 たとえば、SaaSサービスを実行している場合、つまり 1つの大きなサーバーと、サーバーでアプリケーションを実行する多くのクライアントがあります。 特定のクライアントごとにカスタマイズします。 XSLTはその機会を提供します。



例があり、SaaSサービスを作成した後、SaaSではなくアプリケーションサービスプロバイダーと呼ばれました。 そして、クライアント部分はXSLTを介して行われましたが、管理部分はそうではありませんでした。 そして、クライアントは定期的に私たちに尋ねました-「XSLTの管理部分はクライアントとして実行できますか？」 「まあ、XSLTで書き直す必要があります。」 「書き換えは少し高価です。」そして、しばらくして、彼は再び尋ねました...

はい、XSLTを使用したカスタマイズは非常に便利で非常に役立ちます。さまざまなクライアント向けにカスタマイズする必要がある場合に機能します。

ジョンソン

JSON 2台のサーバーがあるとします。 JSONは、それらの間で情報を交換するための非常に優れた形式です。 JSONはXMLよりも優れています。 よりコンパクトで、より標準化されており、作成またはタグ付けするジレンマ属性がありません。 そして同時に、それはまだ人間が読むことができ、プログラムによって非常に簡単に処理されます。 また、任意の新しいデータを追加できます。 少なくとも、それに注意を払い、それが何であるかを知っておくことを強くお勧めします。

非同期タスク処理



別のこのような大規模なエンタープライズパターンは、非同期タスク処理です。 いつ適用されますか？



サーバーがあるとしましょう。 そして、多くのタスクが彼に注がれています。 素朴なアプローチは、各タスクをすぐに処理しようとするときに同期的です。 実際には、次の2つの問題が発生する可能性があります。

• 同期的に処理できない非常に多くのタスクがあります。
• エラーのあるタスクを受け取り始めました。 そして、あなたは、屋根が行きます。

非同期タスク処理は、最初にタスクを作成し、後で処理する場合です。 そして、それを一度処理してから、もう一度、エラーがある場合は徐々に処理し、エラーが多すぎる場合はほぼ完全に制御することができます。



Phil Delgyadoの指導のもと、Yandex.Moneyからこのソリューションを適用しました。他のほとんどすべてのプロジェクトでは、これが非常に簡単になります。非常に詳細な記事があります。



www.telamon.ru/articles/async.html

ナンセンスをしないでください

Joelには、ソフトウェアが10年間にわたってどのように開発されてきたかに関する別の記事があります。 いいね JoelはExcelを例として使用していますが、私には独自の例があります。



スフィンクスについてお話したいと思います。ここのホールにはアンドレイ・アクセノフがいます。私はオープニングアクトにいます。彼は私のことを話します。 私もこの言葉で多くの個人を持っています。 私は10年前にロシアの博物館で検索エンジンを実行しました。 私は自転車を発明しました。 SQLに基づいてすべてを行って、逆索引を作成しました。 しかし、彼は本格的な全文検索を行っていませんでした。「予算内ではなく、まったく必要ありません」。



Luceneはこの時に始まり、Sphinxはこの時に始まりました。 つまり カスタム検索エンジンにはニッチがあることに気づきませんでした。 私はLuceneが存在することに気づかず、職場でナンセンスに苦しむかのように続けました。 または、Luceneに参加することもできます。おそらく、私が彼に参加した場合、Sphinxと競合する方が良いでしょう。 しかし、運命ではありません。



別の例は昨日、OS Phantomでした。 ドミトリー・ザヴァリシンはそれを始めたばかりで、正確に10年以上にわたってそれを行う方法を考えていました。 そのため、アイデアがあれば、それを理解してください...彼らが一晩で書いたJUnitは些細なことです...人々が使用する深刻なソフトウェアを作りたいなら、準備してください長期間開発すること。 10年ではないかもしれませんが、最初のバージョンの1年は簡単に残すことができます。



難なく良いソフトウェアを開発することはできません。

ナンセンスをしないでください

今、そのようなより一般的な質問、推奨事項。 プログラマーとして働くとき、そのような矛盾があります。



優れたソフトウェアを開発して、人気があり、問題なく機能するようにしたいとします。 これには6か月から1年必要です。まあ、かなりの期間にしましょう。



しかし、同時に、あなたには顧客ではなく上司がいて、彼はあなたのために短期的な目標を設定します。 そして、非常に頻繁に、これらの短期的な目標が衝突し、最終的な長期的な結果がもたらされます。



顧客は、私たちが何をしていたかを正確に1時間ごとに見たいと思っています。 または、彼はいくつかの一時的なウィッシュリストを持っていますが、今では確実にこのようにすばやく実行しています。 または、彼はただあなたと話をしたいので、彼が話していることについて何も理解していない意味のない会議を招集します。



あなたへの私のアドバイス-あまりナンセンスをしないようにしてください。 これは意気消沈し、結果は悪い結果です。



私の練習からの新鮮な例。 顧客は、多かれ少なかれ突然、すべてのリクエストで自動コミットが不要になり、すべてのトランザクションが必要になります。 私は少し考えて、もし彼が自動コミットを主張するなら、今は契約を破ろうと言った。 顧客は考えて言った：「はい、ヤシャ、あなたは私にオートコミットを売った」。



つまり 理解：ナンセンスをしないことは危険な立場です。



経営陣と議論し始めるとすぐに、解雇のリスクがすぐに浮かび上がります。 しかし、時には、何かを説明できれば、リーダーシップの部分が同意することが判明します。 彼らは命令を下した後、彼らはあなたが不幸であるのを見ました-「まあ、私たちは主張しません」。

つまり 原則として-話す-時々助けます。 時々ない。

間違いは販売よりも重要です

ここにもう一つの悲しい瞬間があります。 , , , .



, . . — , , — , . , , . « ! !…»



— . , , .



, , , , . .



, - . — « , ». … , . .



, - - , - , — « ». , !



- , . , , . ! つまり , , . .



— , . , , . — , . .