ASP.NET MVC Lesson F. Work as it is

The purpose of the lesson: the final lesson on creating an application. Writing technical specifications. Creating a database. Rename webTemplate. The use of scaffolding. Admin panel 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, it is a profession, it is creativity. When I was studying at university and walking with someone on the way home, we often argued that it was better than Windows or Linux, Delphi or C ++. Then we could not sleep at night to rewrite beautifully the construction of a semantic tree for the compiler. We studied prolog, lisp, finite automata, data structures. We learned to see the beauty of the quick sorting of Hoare realized in the 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)))))) 

But now I see programming as a service. Like something for which I get paid money. I have been freelancing 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 asp.net mvc direction and began to develop in it. The global strategic task was the following: “Increase development speed”. Development speed is the most important parameter. First of all, we save our time and also adhere better to the deadlines. At the same time, I didn’t want to roll into conveyor development, where the programmer does the same trite things over and over again. I singled out for myself the method of accumulating and creating the tools that are almost always needed.



This is how the webTemplate came about. In essence, this is a template for all my projects. He himself is 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 the technical specifications, then about the mode of operation. And at the very end about the webTemplate.

About principles

Customer-employee relationships always cause a lot of controversy. That the customer has offended, the employee is wrong. Freelance is still a swamp, and often the customer is already “experienced” and during the first conversation informs that “there are no prepayments, for you have seen it!”. Here are my principles:

• Always take a 30% advance payment. Vindictive customers who summarize all the freelancers in one pile, in general, not quite adequate people. But (!) If it is necessary to break this rule, then you need to agree on the following: “I show a prototype, and you immediately transfer money to me”. Well, it is 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 your own TZ. At least tezisno. If the customer provides the 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 the TK, the customer said that "everything is completely wrong." So write TK yourself. About him still talk.
• Pay attention to communication. Phoned on Skype and talk as much as you can in more detail. Do not undertake to create 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 may be large, and the customer will immediately be excited about this moment, and, most likely, he will find time to save this money. If he did not notice this penny, all the better, the task was paid in full in advance.
• Never, under any circumstances, be lost for long without warning. This sin all. Destroy deadline. The project had to start, and the old one was still unfinished, a banal error knocked out of the rut for 2 days. The terms are burning. All this garbage, never be lost. If asked what is happening - answer honestly. If you put pressure on the earlier agreement that you let down, that “they said it would be Monday, and it was already Friday!” - feel that you are a big, fat and melancholic elephant. The worst thing you can do is give in to this provocation, be rude in response, do not do the work and fall down.
• Have a stock of money. Have a cash "pillow" for 2-3 months of the same quality of life. how you lead at the moment is very important. First of all, you do not work in a park, so here are the debts growing. Secondly, do not fall into the bondage of the current project. Thirdly, if you are thrown, then you will calmly settle down on the next project.
• Do not give the project to another server until full payment. Even if you have been paid in advance and you donate a project, the customer has the opportunity to drop you. Let's test on your server.
• Be loyal to the modifications and corrections. Some things are hard to foresee, but they can be key to a project. If this happened and the customer insists that it was originally spoken, then there are two options. All that you write in the TZ, has more weight. But, if the improvements are minor (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 also do not let it sit on your head.
• Do not go to "you" until the customer himself wants it. It is always better to communicate on “you”, even if you are of the same age. Thus, it creates a more restrained and polite atmosphere. Although in the future it will be easier to switch to “you”. This already applies to older customers.
• Do not take up the support of other 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 there was often a collapse out of the blue, the code stopped working, and it was necessary to look for a cause that was not completely clear.
• Catch as much information as possible about the objectives of the project. More often, the customer may not know enough about the technologies, and in the TOR describes the solution, which, in his opinion, should work. If you know a more elegant and optimal solution, do not hesitate to propose.
• Argue about the project, but remember that he pays the money. Yes, it is possible that some of his ideas and thoughts are not true, and you can offer a better solution. Offer, convince, even if this decision will cost more. Try to get rid of stupid decisions, but if the customer strongly insists, take his side. He pays, even for his mistakes.
• Love the job. Look at the project as if it were your own project. Make a better implementation, even if it goes beyond budget and time.
• Show progress. Notify the customer about the movement of the project. Nothing calms down like the Progress Bar. Even if you are late with the deadlines, show that the deal is on, do not leave in the dark.
• If you have nothing to show, ask. Even if you have nothing to show, show that the problem is in your head. Hover 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 for the night / weekend. You will fall for a long time and will recover. But if the work goes and already three in the morning - work, you will remember about these moments with pleasure.
• Look at the problem from afar. Examine the TK completely before writing something. Create an image, imagine how blogs will be implemented, but put the question “how can this be done three times faster in 2 hours?”, “How can you enter a lot of complex data without a single error?”, “Will the parser be faster or no? "," Is it possible to develop a template or a scaffolder for this case? "
• Do not announce the time and cost until you write the TK. Here do not even try to count something in your mind; you will always be 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:

• Purpose. 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 purpose of the project 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 may be:
    
    
    • User
    • Fast
    • News
    • Video
    • Photo album
    • Photo Cards
    • A machine
    • Friends
    • Music
    • Game, etc.
    
    
    
  • Site features. This includes:
    
    
    • check in
    • Personal Area
    • My photos
    • Status
    
    
    
  • Admin site.
    
    
    • Users
      
      
      • With the ability to activate
      • Banned
      
      
      
    • Video
      
      
      • To add
      • Change
      • Delete
      
      
      
    • News
      
      
      • To add
      • Change
      • Delete
      
      
      
    • Work with SMS
    • Registration through social networks
    • Work with Webmoney or other online billing systems
    
    
    
  
  
  
• Timing and budget. After describing all the parts of the project, we make a table
  
  
  • Job. For example, “creating a project database” or “Registration”
  • Dates (in hours). Try to keep the deadlines in each cell for more than 20 hours. And certainly not 40+ hours. Otherwise, try to break the task into smaller parts.
  • Money. Just multiply by the current bet.
  • Total. Then you add up the result, without looking or rounding. $ 1695, for example? Yes, and write. Timing and budget is an important part, it gives us a definition of how long it will take to develop (count on 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 will it take
• How much is it

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



Yes, and more importantly: 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 will clarify once again: TK uses one of the most important principles of interaction - the Declaration Principle. It is written “we work from 10:00 to 20:00”, the client came at 20:10, and you should not explain why you cannot serve them. But at 19:50, closing the door in front of the client’s face is a violation of his own rules, his own declaration.



TK approved. You can get to work.

Base structure, webTemplate and Scaffolding

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



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



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



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



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



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

Own rhythm

Have you ever had such a thing that on Monday you come still broken, and on Friday you leave already “dead”, and the goal of Monday is to live until Friday. And the goal of the month is to live up to salary. Or, after working at night, you then go "killed" for a week.

After watching myself, I noticed that my weekend was in the middle of Friday, and if I worked seven days a week, the fuse ended much faster. And all sorts of chores (for example, you need to go to the city) killed the whole working spirit and the whole day.

In addition, customers of projects that I support, almost constantly turn to me with edits. And they need to be done. And sometimes there is no time for that.

And I made a weekly rhythm that allows me to keep up with time and plan more accurately. It starts from Sunday:

• Sunday is the planning day (working day). On this day, you need to plan and start the work that will be done in the next two days.
• Monday is a normal working day. On this day, I start doing what I planned on Sunday.
• Tuesday - shock 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 would take two or three ordinary days. The goal of Sunday is to plan precisely this large amount of work.
• Wednesday is a half-day. On Wednesday, I am distracted by the edits of old projects, and decide matters in the city. Maybe even completely a 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 completed on the current project.
• Saturday - no programming. Relaxation.

The bottom line is that on Monday I know that it will be hellish Tuesday and tune in to it, but I am amused that I have a day off on Wednesday.

Further strength in the declaration, everyone knows that on Tuesday I can not answer the call. That their edits will be made on Wednesday or Thursday. That, most likely, the next large volume of the project will be loaded on Tuesday evening, but errors will be fixed on Thursday and Friday. Even relatives try to adjust to this schedule.



Search your rhythm, realize your ideas.



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