ASP.NET MVCレッスンF.そのままの作業

レッスンの目的：アプリケーション作成の最後のレッスン。 技術仕様の作成。 データベースの作成。 webTemplateの名前を変更します。 足場の使用。 管理者。 メインサイト。 テスト。

メインについて

これが最後のレッスンです。ここでは、特定のプログラミングから少し離れて、作業について振り返ります。
プログラミングは仕事であり、これは職業であり、これは創造性です。 私が大学にいて、家に帰る途中で誰かと歩いていたとき、私たちはしばしばWindowsまたはLinux、DelphiまたはC ++の方が良いと主張しました。 そして、コンパイラのセマンティックツリーの構造を美しく書き直すために、夜眠ることができませんでした。 プロローグ、Lisp、有限状態マシン、データ構造を研究しました。 私たちは、HoarがLispで素早くソートされることの美しさを理解することを学びました。 IN！：

(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< ax)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r)))))) 

しかし今、私はプログラミングをサービスとして見ています。 私が報酬を得るもののように。 私は3年間フリーランスをやっています。 フリーランサーとしての仕事の始めに、ウェブだけでなくasp.net mvcでもプログラムしました。 ZendFrameworkにはphpがあり、QuirkのRTSでの取引戦略を計算するためのモジュールを作成しました。



しかしその後、彼はasp.net mvcの方向を選び出し、その中で開発を開始しました。 グローバルで戦略的な目標は次のとおりでした：「開発のスピードを上げる」。 開発速度は最も重要なパラメーターです。 まず第一に、私たちは時間を節約し、納期を厳守します。 同時に、プログラマが何度も同じ平凡なことをするパイプライン開発に滑り込みたくありませんでした。 私は、ほとんど常に必要なツールを蓄積して作成する方法を自分で特定しました。

これがwebTemplateの由来です。 実際、これは私のすべてのプロジェクトのテンプレートです。 彼自身はすでに4番目のバージョンです。 これが私のメイン製品です。 しかし、最初に、顧客との関係の原則、次に技術仕様のドラフトのルール、次に動作モードについて説明します。 そして、最後にwebTemplateについて。

原則について

顧客と従業員の関係は常に多くの論争を引き起こします。 顧客が気分を害したか、従業員が間違っていました。 フリーランスは未だに沼地であり、多くの場合、顧客はすでに「経験」しており、最初の会話で「前払いはありません、見たことがある！」と通知します。 私の原則は次のとおりです。

• 常に30％の前払いをご利用ください。 一般に、フリーランサーを1つの山にまとめた誠実な顧客は、十分な人材ではありません。 しかし（！）この規則を破る必要がある場合は、次のことに同意する必要があります。「プロトタイプを見せて、すぐにお金を送ってください」。 ここで、ブートストラップ+足場、そして2〜3日間、すでに何かを示していることは明らかです。顧客は忠誠心を持ち、お金を送ります。
• TKは常に自分で書いてください。 少なくとも理論的に。 顧客がTKを提供し、ほとんどの部分に何らかのドキュメントがある場合、それはあなたが正しく理解するという事実ではありません。 そして、私がTKを書き直したときに、顧客は「すべてが完全に間違っている」と言ったようなケースがありました。 TKを自分で書いてください。 彼についてもう一度話しましょう。
• コミュニケーションに注意してください。 Skypeに電話して、可能な限り詳細を記入してください。 すべての不正確さを閉じるまで、プロジェクトの作成に取り組むことはしないでください。 これが不可能な場合、この不可解なタスクを解決するために必要な金額をプロジェクト予算に書き留めてください。 もちろん、金額は大きくなる可能性があり、顧客はこの瞬間にすぐに興奮し、おそらく、このお金を節約する時間を見つけるでしょう。 彼がこの金額に気付かなかった場合、さらに良いことに、タスクは前もって全額支払われました。
• いかなる状況でも、警告なしに長時間消えることはありません。 誰もがこれを罪にします。 締め切りを台無しにしました。 プロジェクトは開始されるはずでしたが、古いプロジェクトはまだ未完成であり、2日間のあいまいなミスが解決されませんでした。 タイミングはオンです。 これはすべてゴミです。消えることはありません。 何が起こるか尋ねられたら、正直に答えてください。 あなたが「月曜日に何が起こるか、それは金曜日だと言った」とあなたが言っていないという早期合意を彼らが押し付けるなら、あなたは大きく太った、憂鬱な象だと感じてください。 あなたができる最悪のことは、この挑発に屈し、見返りに失礼になることであり、仕事をして倒すことではありません。
• お金の供給があります。 同じ生活の質の2〜3か月の「枕」を持ちます。 現時点での運転方法は非常に重要です。 まず、あなたは公園で働いていません。借金が増えているということです。 第二に、現在のプロジェクトの束縛に陥ることはありません。 第三に、投げられた場合、あなたは静かに次のプロジェクトに出るでしょう。
• 全額を支払うまで、プロジェクトを他の人のサーバーに渡さないでください。 前払いされていてプロジェクトを配っている場合でも、顧客はあなたを捨てる機会があります。 サーバーでテストしましょう。
• 改善と修正に忠実であること。 想像するのが難しいものもありますが、それらはプロジェクトの鍵となります。 これが発生し、顧客が最初に話されたと主張する場合、2つのオプションがあります。 TKで書くものはすべて、より重要です。 しかし、改善が重要でない場合（ほとんどの場合それが起こります）、それはより簡単です。 あらゆる些細なことを議論の主題に変える必要はありませんが、それを頭の上に座らせないでください。
• 顧客自身が望むまで「あなた」に切り替えないでください。 たとえあなたが仲間であっても、「あなた」とコミュニケーションをとることは常に良いことです。 したがって、より控えめで丁寧な雰囲気を作り出します。 将来的には「あなた」に切り替えるのが簡単になるでしょう。 これは、古い顧客にもっと当てはまります。
• 他の人のプロジェクトのサポートを引き受けないでください。 滑りたいものを過小評価しないでください。 サポートが必要なプロジェクトがいくつかあり、それらは私の前に書かれていました。 私は他の誰かのコードに対処する必要があり、時間がかかり、多くの場合、顧客はそれがもたらすメリットを説明できませんでした。 2番目のポイントは、崩壊がしばしば突然発生し、コードが機能しなくなり、完全に明確ではない理由を探す必要があることでした。
• プロジェクトの目標について可能な限り多くの情報を入手します。 多くの場合、顧客はテクノロジーについて十分に知らない可能性があり、作業声明では、彼の意見では、動作するはずのソリューションを説明しています。 よりエレガントで最適なソリューションをご存知の場合は、お気軽に見積もりをお送りください。
• プロジェクトについて議論しますが、お金を払うことを忘れないでください。 はい、彼のアイデアや考えの一部が間違っている可能性があり、最良のソリューションを提供できます。 このソリューションのコストが高くなるとしても、納得してください。 愚かな決定を取り除くようにしてください、しかし、顧客が強く主張するならば、彼の側をしてください。 彼は自分の間違いに対しても支払います。
• 仕事が大好きです。 自分のプロジェクトとしてプロジェクトを見てください。 予算と時間を超えても、より良い実装を行います。
• 進行状況を表示します。 プロジェクトの動きを顧客に通知します。 プログレスバーほど心強いものはありません。 締め切りが遅れたとしても、物事が進んでいることを示し、無知のままにしないでください。
• 表示するものがない場合は、お問い合わせください。 表示するものがない場合でも、タスクが頭の中にあることを示します。 多くの明確な質問を配置し、ディスカッションプロセスに参加します。
• 夜は働かないでください。 仕事の奴隷にならないでください。一晩中/週末に仕事をしようとしないでください。 あなたは引き裂かれ、長い間回復されます。 しかし、仕事が進行中であり、午前3時にすでに仕事がある場合、これらの瞬間を喜んで思い出すでしょう。
• 遠くから問題を見てください。 何かを書く前にTKを完全に学んでください。 画像を作成し、ブログの実装方法を想像しますが、「これを2時間で3倍高速に実行するにはどうすればよいですか？」、「1回のミスなしで大量の複雑なデータを作成するにはどうすればよいですか？」、「いいえ？」、「この場合、独自のテンプレートまたは足場を開発するのは適切ですか？」
• TKを作成するまで、条件と費用を宣言しないでください。 それからあなたの心の中で何かを計算しようとしないでください、あなたはいつも間違えられます。

参照条件

技術的なタスクはあなたのすべてであり、成功の70％です。 参照条件は、次の質問に答える必要があり、次の部分で構成されます。

• 目的。 ここでは、プロジェクトの目的を簡単に説明します。 何してるの？ このプロジェクトの目的は何ですか？
• プロジェクトの一部。 それらはプロジェクトの目標から論理的に派生したものでなければならず、データベースにテーブルを作成するためのプロトタイプになります。 あるはずです：
  
  • サイトの言語（多言語の場合、どの言語）
  • プロジェクトの本質。 可能性があります：
    
    • ユーザー
    • 投稿
    • ニュース
    • 映像
    • フォトアルバム
    • 写真カード
    • 車
    • 友だち
    • ミュージック
    • ゲームなど
    
    
  • サイトの機能。 これには以下が含まれます：
    
    • 登録
    • 個人アカウント
    • 私の写真
    • ステータス
    
    
  • サイト管理者。
    
    • ユーザー
      
      • アクティブ化する機能を使用して
      • 禁止する
      
      
    • 映像
      
      • 追加する
      • 編集
      • 削除する
      
      
    • ニュース
      
      • 追加する
      • 編集
      • 削除する
      
      
    • SMSを使用する
    • ソーシャルネットワークを介した登録
    • Webmoneyまたはその他のオンライン支払いシステムを使用する
    
    
  
  
• タイミングと予算。 プロジェクトのすべての部分を説明した後、タブレットを作成します
  
  • 仕事。 たとえば、「プロジェクトデータベースの作成」または「登録」
  • 日付（時間単位）。 各セルに20時間を超えないようにしてください。 そして、確かに40時間以上ではありません。 それ以外の場合は、タスクを小さな部分に分割してみてください。
  • お金。 現在のベットを掛けるだけです。
  • 結果。 次に、見たり丸めたりせずに結果をノックアウトします。 たとえば、1695ドルですか？ はい、書いてください。 タイミングと予算は重要な部分であり、開発にかかる時間（1日6時間、8時間またはさらに悪い10時間と予想されます）および費用の定義を提供します。
  
  

したがって、TKは次の3つのことを宣言します。最も重要なことです。

• どうする
• どれくらい時間がかかりますか
• いくらですか

このリンクをスキップすると、最初はプロジェクトが台無しになります。 仕事の面、時間の面、コストの面で3つの点すべてに間違えられます。 これを避けるようにしてください。

さらに重要なことは、TKが大きくないこと、理想的には20ページまでです。 あまり詳細にしないでください。そうしないと、顧客はそれを読まず、ドキュメントの使用を主張します。 あなたの文書はもっと良いはずです。 プロジェクトの価格に一線があるので、より良いでしょう。 しかし、彼と一緒に無理をしないでください。

再度明確にします：TKは相互作用の最も重要な原則の1つ-宣言の原則を使用します。 「私たちは10:00から20:00まで働いています」と書かれており、クライアントは20:10に到着しました。なぜ彼らにサービスを提供できないのかを説明する価値はありません。 しかし、19時50分にクライアントの鼻の前でドアを閉めることは、彼ら自身の規則、彼ら自身の宣言に違反しています。

TKが承認しました。 仕事に取り掛かることができます。

基本構造、webTemplate、および足場

技術的なタスクを実行して、すべてのエンティティを個別にファイルに書き出し、接続を評価します。 そして、それらをデータベースに記述します。 最大8時間かかります。 TKの後-これはプロジェクトの最も重要な部分です。

その後、webTemplateプロジェクトをコピーし、webTemplate-> [new project name]の名前を変更します。 約30分かかります。

その後、新しいプロジェクトで、必要なProviderRepositoryテーブルとModelテーブルに対してScaffoldingを実行します。 すべてのコマンドをすぐに作成し、パッケージマネージャーコンソールにコピーしてプロセスを開始し、お茶を飲むことができます。

次に、ViewModelsで、必要なSelectReferenceを追加し、不要なフィールドを削除し、ManagedAttributeから必要な属性を追加して、Scaffolding Controllerを起動します。

その後、プロジェクトを修正してコンパイルし、管理パネルで作業します。

さらに、メインページから始めて、他のすべてのモジュールを毎日実行しています。

自分のリズム

月曜日にはまだ壊れてしまい、金曜日にはすでに「死んだ」ままになり、月曜日の目標は金曜日まで生き残ることです。 そして今月の目標は、給料を守ることです。 または、夜働いてから1週間「殺され」ます。
自分を観察した後、私は休日が金曜日の真ん中に来たことに気づきました。休日なしで働いた場合、ヒューズははるかに速く終了しました。 そして、あらゆる種類の家事（例えば、街に行く必要がある）は、仕事の精神全体と一日を殺しました。
さらに、私がサポートするプロジェクトの顧客は、ほとんど絶えず編集について連絡をくれます。 そして、彼らはやらなければなりません。 そして、時にはこの時間がありません。
そして、私はより多くの時間に追いつき、より正確に計画できるように週ごとのリズムを作りました。 日曜日に始まります：

• 日曜日は計画（仕事）の日です。 この日には、今後2日間で行われる作業を計画して開始する必要があります。
• 月曜日は通常の営業日です。 この日、私は日曜日に計画したことを始めます。
• 火曜日は忙しい一日です。 この日は、通常、Skypeをオフにして、作業の大部分を行います。 作業日は約10〜12時間続きます。 通常、これで通常の2〜3日かかる作品を作成できます。 日曜日の目標は、この大量の作業を正確に計画することです。
• 水曜日は半日です。 水曜日に、私は古いプロジェクトを編集することに気を取られ、街で物事を決定します。 たぶん丸一日も休みです。
• 木曜日は、火曜日以降に現在のプロジェクトに戻るか、まだ残っている場合は編集の継続です。
• 金曜日は通常の就業日であり、通常、現在のプロジェクトで何かルーチンが完了しています。
• 土曜日-プログラミングなし。 休みます。

結論としては、月曜日に火曜日の地獄があり、それに同調することを知っていますが、良いニュースは水曜日に休みがあるということです。
さらに、力は宣言にあり、誰もが火曜日に電話に出られないことを知っています。 編集が水曜日または木曜日に行われること。 おそらく、プロジェクトの次の大容量は火曜日の夜にダウンロードされますが、エラーは木曜日と金曜日に修正されます。 親relativeでさえ、このスケジュールに適応しようとします。

あなたのリズムを探し、あなたのアイデアを実現します。

すべてのソースはhttps://bitbucket.org/chernikov/lessonsにあります