Running with obstacles or creating one project

What are you talking about

Chefonline.ru is a culinary portal, no matter how trite it may sound. We have personal and general books of recipes, it is possible to create shopping lists, plan menus, store favorites, write to a collective blog or just read it, there are other interesting and useful services for amateurs and sympathizers.



The portal is quite young, though a lot has been done, but much is still in development or in the form of ideas, so I would like to tell you not about the project itself, but about the process of its creation. I hope, our experience will be useful to people.

Initial data

Apparently, you should not go into details of exactly how I sat and thought, and how exactly the idea came up to create a service for chefs and sympathizers. I’ll just say that the service was made on the basis of my needs and my desire, as I myself like to cook.



At the time of the start of development there were the following resources:

• The programmer, he maker-up (s)
• Designer
• Its own under-framework, on which a dozen projects have already been implemented
• Shared hosting
• Some experience in web development and project management.
• Quite a bit of free time

What was used in the development:

• PHP5 fast-cgi + nginx
• MySQL5
• Smarty
• Jquery

I invented a domain name and registered it without much anguish in an hour of searching for possible options, judging that there is no particular reason to think much and come up with something clever “start-up”. So, one might say, was born chefonline.ru

')

At the time of the start, I had (and still have) the main work with a busy schedule, plus the 2008 autumn crisis did not gain much momentum. So I had about an hour on the project on weekdays, plus a few hours on weekends - to sit on the project at night and all weekend there was neither strength nor desire. In general, we can call what we did a start-up, only with a stretch and terminological reservations.

Start of development and architecture

Before starting the development, I did not sit at night and did not design the architecture, did not suffer from the choice of technical solutions, and did not kill myself about the ideal database structure. Since the site was born from goals and needs that are quite clear and understandable to me, everything in my head was built quite clearly, at least at a high level and not going into much detail - experience suggested that, if you do not design, you still have to then finish and redo the course of the project. I just painted in a couple of hours the data interaction scheme, put up the database structure and figured out large-scale brushstrokes of yuzkeys. Many solutions have already been tested for a long time and were not in doubt, the framework of almost all modules was pulled from past projects. So I began to write the code on the second day after the emergence of the project idea.



The main difficulty was to think over the system of the book of recipes and the interaction of users within its framework - it could be both general, with one section structure, and personalized - with the ability to edit the structure, including creating it from scratch. Categories should have a tree structure. Until that moment, in my “framework” I used “NestedSets” and did not know grief, but the algorithm was not suitable for this particular task — constant inserts and updates could occur in the tree, and the nested sets are not suitable for this.



Breaking a bunch of material and having tried almost everything that exists in tree structures, I ended up with the commonplace “id-parentId”, but did not select recursion, but through JOIN (the methods are described on the forum dklab.ru ).



This method has some limitations and nuances (in particular, the nesting level), but in general, after a synthetic test on a large base with a nesting level of 10 (and I can hardly imagine a recipe book with more nesting), this algorithm satisfied me and as a result was written class work with him. It was also decided to spread the general catalog and personalized catalogs according to different tables in order to optimize the reading speed, in particular from the general recipe book - its categories are also used for the general recipe book displayed in the public part of the site.



In addition to the structure of the recipe catalog, I was concerned about the use of Jquery, which I never used and actually combined the pleasant with the useful — the development and simultaneous study of the framework. Reading docks in jQuery and finding solutions took most of the development time, writing code in PHP went pretty quickly and without any problems.



All ideas for the project were collected into a list (aka the backlog, if to speak in terms of scrum), sorted by priority and divided into sprints, two months long. Thus, it was clear what the portal would turn through 4-6-10 sprints, it simplified the adoption of some architectural decisions.

Design and usability

With the design were the biggest problems. The designer worked on the project, but rather slowly, the design concept was obtained only 4 months after the start of work on the project, after that there were another two months of painful edits and study of the internal pages. Usability was thought out together to the best of our ability and knowledge, and we devoted the maximum amount of time to this issue and tried to maintain a balance between beauty and functionality - whether it turned out or not, to judge users.



A serious danger lurked after receiving the first results on the concept - thoughts arose to accept what is, because there is nowhere else to pull - maybe not the way you want, but at least something. It is good that the excerpts were enough both for disputes, and for abandoning the primary concept, and for further revisions and improvements. There were quite a lot of improvements - the concept was reworked three times, the main page was completely reworked two, well, and the little things were well.



The involvement in the project had a huge impact on the development of the interface and its results - I myself as a service user could give as much feedback as possible - what and why do I need, what place to put and what effect will this have on the overall interface of the site. It was quite difficult to disregard the fact that I, as a developer, walk in the same ways and many things that seemed obvious to me turned out to be completely unobvious for users. The first beta testers helped me with this, to whom I express my great appreciation - many annoying bugs and interface problems were fixed with their help. It was difficult and a little disappointing to accept the fact that the personalized recipe book, which we were so proud of, which we liked and seemed comfortable with, was not completely obvious to the users according to the results of the first usability tests. Humbled, of course, and remade. It was a good experience of admitting one’s mistakes, and it doesn’t happen much.



As for the long rendering of models, the practice has shown that no matter what personal relationships are there, working relationships should always be worked out, negotiated and coordinated, work methods and interactions should be developed in advance, as they say - on the coast. Hoping for consciousness or telepathy is pointless and harmful. After half a year of unproductive work, we still came to an agreement on how and how we will work, after which things went much faster. In particular, every Sunday we gathered at my home and almost the whole day worked in a calm atmosphere on the project, and in the evening we tested new dishes, combining the pleasant with the useful :)



Actually, the result of work on the visual component can already be assessed.

Performance optimization

Initially, it was obvious that a large number of javascript and weak hosting would become bottlenecks, closer to the summer, this was confirmed by performance tests and stress tests of an almost finished project. It was decided to hold the following events:

• Rent a dedicated server or at least VPS, where you can also configure and optimize
• Cache most statics and database queries in memcache
• Combine and compress javascripts and css

As a result, I transferred the project to VPS, and I had to set everything up myself (having no administration of * nix systems at all) - this is a separate fascinating story, from which I learned a lot of experience and useful skills, as well as the false feeling that I am now the king of the world. The result of my weekly efforts was the following: nginx + php5-fastcgi + mysql5 + xcache + memcached. With this, I met my needs for server optimization (the bottleneck was still the kernel settings that cannot be changed on the VPS, as well as the rather weak provider channel) and went to the client side.



Unfortunately, in terms of client optimization, not so much was done as planned. It still remains to make the union of javascripts and css, optimize the DOM, minimize the number of http requests, the caching mechanisms are not fully implemented.

Total

A year has passed since the start of the project, during this time not so much was done as we would like, more mistakes were made than we would like, but a lot of experience was learned. This experience can be presented in several theses, which, in essence, are nothing more than once again confirmed common truths.

1. The involvement of project participants in the subject area is a big plus for the project.
2. It is not always worthwhile to postpone the implementation of the project and dive too deep into planning and design. Iterative development, frequent demonstrations, getting maximum feedback - this should be sought.
3. Using your services (as an end user) from the very first prototype, you can avoid many problems in the future.
4. If team members have different levels of motivation - communicate, develop common approaches, solve problems that arise immediately after they are identified, do not delay and do not try to “hush up” them - it will not resolve itself.
5. It is important to find a middle ground between perfectionism and pragmatism, in some cases, painful refactoring will save a lot of time in the future, in some excessive pedantry can lead to a linkage of the project in the swamp improvements.
6. Less bicycles - everything has already been invented before us and it’s good that I personally already realized this for myself, if I had started the project a couple of years earlier and I would have spent much more time inventing my bicycles, rather than using the existing material and other people's work.
7. Do not hesitate to show the project, do not be afraid of negative feedback - this is a very important feedback and the more you get it in the early stages, the better the final product will be.
8. Development alone or in a small team of friends does not mean that the development process can be neglected. We use many scrum techniques and do not at all consider this a waste of time or overkill, on the contrary, we constantly observe positive moments.
9. You should not rely on the primary UGC, when developing a project there should be a plan for its filling.

Update: I thank everyone who wrote about the errors found in the comments or in the feedback on the site. Of course, it’s a shame for mistakes, but it’s better to fix them sooner rather than later. I also thank all those who made useful and reasonable comments on the design, usability and technical part of the site.