Let's discuss joint projects in the editor - why and where they are going - page 6

 
Alexey Volchanskiy:

I trained someone in MQL5 today and he created a project from scratch without my help. It's really very simple, what are people worried about... They must have never dealt with projects before.

I have had some bugs with the Warehouse until it started working properly and I have never understood where my errors were.

Now, say, I'm trying to figure out whether to divide my whole library into separate projects, or to make everything into one. If I divide it into separate - then, in theory, the access to the individual sections of the library is streamlined, but at the same time some files fall into several projects simultaneously - can I do this ?

 
Ilnur Khasanov:
Can't really relate to the editor, now that there are team projects, will there be a task tracker? What will be in terms of team organisation, task setting, code review?
No, we are not planning to.
 
George Merts:

No, I'm just "blowing on water" - I was always having some problems with the Warehouse, until it started to work properly, and I never understood what my mistakes were.

Now, say, I'm trying to figure out whether to divide my whole library into separate projects, or to make everything into one. If you break it up into separate - then, in theory, the access to individual sections of the library is ordered, but it ends up with some files in several projects at the same time - can I do this?

If you are doing it only for yourself, the library should be moved to a separate project inside the MQL5 directory and work.

If you want joint projects, make a separate library project and separate working projects. From the working projects, refer to the neighboring library project by relative paths.

 
Renat Fatkhullin:

Could you create a similar thread on the Tester?

 
What are the advantages of the individual developer's service under discussion compared to the classics?
 
Alexey Volchanskiy:

)))))))))))))) was that a joke of humour? Let's make a bugzilla in the meta-editor.)

Well not bugzilla - there are many solutions. The same visual studio has tools, tfs is specifically integrated into the editor.
Well imagine you are the project commander, you have several participants sending you code on the project. How would you look at their code, make comments, etc.? How will you set specific tasks for each team member? How will you keep track of who added what and when?
This is not really a problem - there are many external services.
 
fxsaber:
What are the advantages of the individual developer's service under discussion compared to the classics?

double advantage = 0.00; // for face-to-face progger ))))
 
fxsaber:
What are the advantages of the discussed Service for the individual developer compared to the classics?

1) Will create complex programmes and manage them conveniently. No more hassle with one file.

2) They will learn how to use version control systems. Most of them have never used them before.

3) They will learn to work on joint projects.

4) It will be easier to prepare and publish products in an appstore and code for a kodobase.

5) It will be easier to work as a freelancer, when the customer can not only monitor the progress, but also participate in the development process

6) Public projects are another place to showcase their skills as an author and contributor/contributor to other projects

7) Increase their programming skills: +1 on version control, +1 on group work


This is what lies on the surface.

 
Ilnur Khasanov:
Well not bugzilla - there are plenty of solutions. The same visual studio has tools, tfs is specifically integrated into the editor.
Well imagine you're the project commander, you're being sent code by several contributors on a project. How would you look at their code, make comments, etc.? How will you set specific tasks for each team member? How will you keep track of who added what and when?
This is not really a problem - there are many external services.

I'm just kidding.

MQ will not waste resources on bullshit that 0.1% of users need

 
Renat Fatkhullin:

1) Will be able to create complex programs and manage them conveniently. No more hassle with one file.

2) They will learn how to use version control systems. Most people have never used them.

3) They will learn to work on joint projects.

4) It will be easier to prepare and publish products in the appstore and codes for codobase

5) It will be easier to work as a freelancer, when the customer can not only track progress, but also participate in the development

6) Public projects are one more place to demonstrate your skills as an author and contributor/contributor to other projects

7) Improve their programming skills: +1 on version control, +1 group work


This is what lies on the surface.


4-6 can you elaborate? Will I be able to throw in the KB without the current red tape?

Reason: