ASP.NET MVC Lesson F. Work As It Is

Lesson Objective: The final lesson on creating an application. Writing technical specifications. Creating a database. Rename webTemplate. Scaffold application. Admin The main site. Tests.

The main thing

This is the final lesson, and here I am a bit away from specific programming and reflect on the work.
Programming is work, this is a profession, this is creativity. When I was at university and walking with someone on my way home, we often argued that Windows or Linux, Delphi or C ++ were better. Then we could not sleep at night to beautifully rewrite the construction of the semantic tree for the compiler. We studied prolog, lisp, finite state machines, data structures. We learned to see the beauty of quick sorting Hoar realized on the Lisp. IN!:

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

But now I see programming as a service. Like something I get paid for. I have been doing freelance for three years now. At the beginning of my work as a freelancer, I programmed not only the web and not only on asp.net mvc. There was php on ZendFramework, and writing modules for calculating strategies for trading on RTS on Quirk.



But then he singled out the direction of asp.net mvc and began to develop in it. The global, strategic objective was as follows: "Increase the speed of development." Development speed is the most important parameter. First of all, we save our time, and also adhere to deadlines better. At the same time, I did not want to slide into the pipeline development, where the programmer, over and over again, does the same banal things. I have identified for myself a method of accumulating and creating those tools that are almost always needed.

This is how webTemplate came about. In fact, this is a template for all my projects. He himself is already the fourth version. This is my main product. But first, I will talk about the principles of relationships with customers, then about the rules for drafting technical specifications, then about the mode of operation. And at the very end about webTemplate.

About the principles

Customer-employee relationships always cause a lot of controversy. Either the customer offended or the employee was wrong. Freelance is still a swamp, and often the customer is already “experienced” and at the first conversation notifies that “no advance payments, for they have seen!”. Here are my principles:

• Always take a 30% prepayment. Vindictive customers who summarize all freelancers in one pile, in general, are not quite adequate people. But (!) If you need to break this rule, then you need to agree on the following: "I show the prototype, and you immediately transfer money to me." Well, it’s clear that here bootstrap + scaffolding and 2-3 days, we already have something to show, the customer goes into loyalty and sends money.
• Always write TK yourself. At least thesisally. If the customer provides TK, and for the most part there is some kind of document, then it is not a fact that you will understand correctly. And I had such cases that when I rewrote TK, the customer said that "everything is completely wrong." So write TK yourself. We’ll talk about him again.
• Pay attention to communication. Call on Skype and give the details as detailed as possible. Do not tackle the creation of a project until you close all inaccuracies. If this is not possible, then write down the amount that is needed to solve this incomprehensible task in the project budget. Of course, the amount can be large, and the customer will immediately be thrilled by this moment, and most likely he will find time to save this money. If he didn’t notice this penny, all the better, the task was paid in advance in full.
• Never, under any circumstances, disappear for a long time without warning. Everyone sins this. Ruined the deadline. The project should have started, and the old one is still unfinished, a banal mistake unsettled for 2 days. Timing is on. All this bullshit, never disappear. If asked what happens, answer honestly. If they press on an early agreement, what do you fail that “they said what will happen on Monday, but already Friday!” - Feel that you are a big, fat and melancholy elephant. The worst thing you can do is to succumb to this provocation, to be rude in return, not to do work and topple.
• Have a supply of money. Have a “pillow” for 2-3 months of the same quality of life. how you drive at the moment is very important. Firstly, you do not work in the park, that debts are growing. Secondly, you will not fall into the bondage of the current project. Thirdly, if you are thrown, then you will quietly get out on the next project.
• Do not give the project to someone else's server until full payment. Even if you have been paid in advance and you are giving away the project, then the customer has the opportunity to throw you. Let's test on our server.
• Be loyal to improvements and corrections. Some things are hard to envision, but they can be key to the project. If this happened and the customer insists that it was originally spoken, then there are two options. Everything that you write in TK has more weight. But, if the improvements are insignificant (most often it happens), then it is easier to do. It is not necessary to turn every little thing into a subject for discussion, but do not let it sit on your head.
• Do not switch to “you” until the customer himself wants it. It is always better to communicate with “you,” even if you are peers. Thus, it creates a more restrained and polite atmosphere. Although in the future it will be easier to switch to “you”. This applies more to old customers.
• Do not take on the support of other people's projects. Do not underestimate what you want to slip. I had several projects that needed to be supported, and they were written before me. I had to deal with someone else's code, it took time, and often the customer could not explain what benefit it brings. The second point was that the collapse often happened out of the blue, the code stopped working, and you had to look for a reason that was not completely clear.
• Get as much information as possible about the goals of the project. More often the customer may not know enough about the technologies, and in the statement of work describes a solution that, in his opinion, should work. If you know a more elegant and optimal solution, then feel free to submit a quote.
• Argue about the project, but remember that it pays money. Yes, it is possible that some of his ideas and thoughts are incorrect, and you can offer the best solution. Offer, persuade, even if this solution will cost more. Try to get rid of stupid decisions, but if the customer insists strongly, take his side. He pays, even for his mistakes.
• Love the work. Look at the project as your own project. Make a better implementation, even if it goes beyond budget and time.
• Show the progress. Notify the customer of project movement. Nothing is more reassuring than the Progress Bar. Even if you are late with deadlines, show that things are going, do not leave them in ignorance.
• If there is nothing to show, ask. Even if you have nothing to show, show that the task is in your head. Place a lot of clarifying questions, get involved in the discussion process.
• Do not work at night. Do not be a slave to work, do not try to do work overnight / over the weekend. You will be torn, and will be restored for a long time. But if work is underway and it is already three in the morning, work, you will remember these moments with pleasure.
• Look at the problem from afar. Learn TK completely before writing anything. Form an image, imagine how blogs will be implemented, but ask “how can this be done three times faster, in 2 hours?”, “How can I make a lot of complex data without a single mistake?”, “Will it be faster to write a parser or no? ”,“ Is it appropriate to develop your own template or scaffolder for this case? ”
• Do not declare the terms and cost until you write TK. Then do not even try to calculate something in your mind, you are always mistaken.

Technical task

The technical task is your everything, it is 70% of success. The terms of reference should answer the following questions and consist of the following parts:

• Goal. Here we briefly describe the purpose of the project. What are we doing? What is this project for?
• Parts of the project. They should logically come from the project goal and will be the prototype for creating tables in the database. There should be:
  
  • Site language (if multilingual, which languages)
  • The essence of the project. It could be:
    
    • User
    • Fast
    • News
    • Video
    • Photo album
    • Photo cards
    • The car
    • Friends
    • Music
    • Game etc.
    
    
  • Site features. This includes:
    
    • registration
    • Personal Area
    • My photos
    • Status
    
    
  • Site admin.
    
    • Users
      
      • With the ability to activate
      • To ban
      
      
    • Video
      
      • Add
      • Edit
      • Delete
      
      
    • News
      
      • Add
      • Edit
      • Delete
      
      
    • Work with sms
    • Registration through social networks
    • Work with Webmoney or other online payment systems
    
    
  
  
• Timing and budget. After describing all the parts of the project, we make a tablet
  
  • Work. For example, “creating a project database” or “Registration”
  • Dates (in hours). Try not to have more than 20 hours in each cell. And certainly not 40+ hours. Otherwise, try to break the task into smaller parts.
  • Money. Just multiply by your current bet.
  • Total. Next, knock out the result without looking or rounding. $ 1695, for example? Yes, and write. Timing and budgeting is an important part, it gives us a definition of how long development takes (expect 6 hours a day, not 8 or even worse 10) and how much it will cost.
  
  

Thus, TK declares three things, the most important:

• What need to do
• How long does it take
• How much is it

Skipping this link, you initially ruin the project. You are mistaken for all three points, in terms of work, in time, in cost. Try to avoid this.

And even more important: TK should not be large, ideally - up to 20 pages. Do not detail too much, otherwise the customer will not read it, and will insist on using his document. Your document should be better. It will be better, because there will be a line with the price of the project. But do not overdo it with him.

I’ll clarify again: TK uses one of the most important principles of interaction - the principle of declaration. It is written “we work from 10:00 to 20:00”, the client arrived at 20:10, and it’s not worth explaining why you cannot serve them. But at 19:50 to close the door in front of the client’s nose is a violation of their own rules, their own declaration.

TK approved. You can get to work.

Base structure, webTemplate and Scaffolding

Running through the technical task, I write out all the entities separately in a file, evaluate the connection. And then I describe them in the database. It takes a lot of time, up to 8 hours. After TK - this is the most important part of the project.

After that, I copy the webTemplate project and rename webTemplate -> [new project name]. It takes about 30 minutes.

After that, in a new project, I run Scaffolding for the required ProviderRepository and Model tables. You can immediately compose all the commands and copy to the Package Manager Console to start the process and go to drink tea.

Next, in ViewModels, I add the necessary SelectReference, remove the unnecessary fields and add the necessary attributes from the ManagedAttribute and start the Scaffolding Controller.

After that, I correct the project so that it compiles, and I work with the admin panel.

Further, starting from the main page, I do all other modules day after day.

Own rhythm

Has it ever happened to you that on Monday you come still broken, and on Friday you leave already “dead”, and the goal of Monday is to survive until Friday. And the goal of the month is to live up to the salary. Or, having worked at night, you then go “killed” for a week.
After observing myself, I noticed that my days off came in the middle of Friday, and if I worked without days off, the fuse ended much faster. And all sorts of household chores (for example, you need to go to the city) killed the whole working spirit and the whole day.
In addition, customers of the projects that I support almost constantly contact me with edits. And they must be done. And sometimes there is no time for this.
And I made a weekly rhythm that allows me to keep up with more time and plan more accurately. It starts on Sunday:

• Sunday is the day of planning (work). On this day, it is necessary to plan and start the things that will be done in the next two days.
• Monday is a normal business day. On this day, I begin to do what I planned on Sunday.
• Tuesday is a busy working day. On this day, I usually turn off Skype and do a very large part of the work. The working day lasts about 10-12 hours. Usually this is enough to make a piece that takes two or three ordinary days. Sunday's goal is to plan precisely this large amount of work.
• Wednesday is half-day. On Wednesday, I get distracted by editing the old projects, and decide things in the city. Maybe even a full day off.
• Thursday is either a return after Tuesday to the current project, or a continuation of edits if they still remain.
• Friday is a normal working day, usually something routine is being completed on the current project.
• Saturday - no programming. Relaxation.

The bottom line is that on Monday I know that there will be a hell of a Tuesday and tune in to it, but the good news is that on Wednesday I have a day off.
Further, the force is in the declaration, everyone knows that on Tuesday I can not answer the call. That their edits will be made on Wednesday or Thursday. Which, most likely, the next large volume of the project will be downloaded on Tuesday evening, but errors will be fixed on Thursday and Friday. Even relatives try to adapt to this schedule.

Look for your rhythm, realize your ideas.

All sources are located at https://bitbucket.org/chernikov/lessons