murlogen

А технические вопросы - как именно деньги будут сниматься платиться на какие именно счета карты платежные системы Вы уже решили???

Скрипт на фоне этого гемороя - ерунда. Если у вас есть финансовый ресурс и опыт работы с платежными системами - то уж нанять студента сделать это на заказ не составит вам никаких проблем.

Проблема КАК ИМЕННО деньги будут попадать В РУКИ конечных пользователей.
И КАК ИМЕННО они будут их отдавать.

ФИЗИЧЕСКИ как будут перемещаться деньги в этой системе.
Не виртуально на сайте, а физически.

Если в конечном итоге это все будет проходить через существующие платежные системы (а как иначе? вы же не откроете в каждом городе по своему представительству):

1) Вы ничего не заработаете, даже напротив
2) Чем вы будете в глазах этих людей ценнее других прочих платежных систем

Для начала нужно иметь такое приложение в котором куча параметров, которые ты можешь изменять и куча метрик, по которым ты будешь проводить обучение.

Мне представляется маловероятным само наличие приложения, пригодного для обучения нейронной сети.

Ну то есть в Гугле или Фейсбуки такие приложения есть.
Есть и у облачных провайдеров.

Но где ты возьмешь в обычной жизни такие вещи для того, чтобы обучить нейронную сеть?
Как только найдешь - все остальные вопросы отпадут сами собой.

Не мудрите.
Вы уже почти все описали.

Пригласите грамотного 1С ника.
Пригласите грамотного веб-мастера.

Они вас послушают час-другой, зададут вопросы.
Сами себе составят ТЗ.

и все вам сделают.

Если нет заинтересованного облеченного властью лица в компании - бесполезняк.

Если есть - он пнет кого нужно и вам все расскажут.
Ваше дело будет только целыми днями беседовать с людьми.

На фриланс - не стоит.
Деньги, да, быстро да, больше, да.
Но рост твой очень медленный.

Поработай на студии года 3 хотя бы.
Потом ты обгонишь такого же фриленсера без опыта студийной работы - и обгонишь в разы по зарплате.

1. Решать все головные боли должно руководство.

Или точнее - заинтересованный в проекте человек с достаточными полномочиями должен раздавать всем пинка, как только что-то начинает буксовать.

Если такого человека нет (он не достаточно имеет полномочий или заинтересованности) - закрывайте проект.

2. Достаточно сделать boilerplate (шаблон или несколько) - который будут все использовать. В приказном порядке.
Читать все эти длинные регламенты и пр. - никто не будет.
Описания как работать - должны быть 3-4 экрана высотой, не более.

Не мешайте людям работать.
Помогите им - сделайте ваш корпоративный boilerplate

Человек просто берет его.
И модернизирует под свой участок проекта.

Заведите удобный wiki-подобный комментарий к boilerplate.
Документация появится сама.

Вопрос смысла не имеет без конкретизации.

Зависит от возможностей компании и сложности продукта и важности документации.

• Иногда - разработчик.
  
• Иногда - специальный технический писатель.
  
• Иногда - никто (или одна страничка в хелпе приложения).
  
  

1. Писать должен тот кто разбирается и в ИТ и в бизнес процессах - это идеальный вариант. Но подходит для мелких компаний с технически продвинутым персоналом.

2. На практике - это тандем ИТ-шника и того, кто разбирается в конкретном бизнес-процессе (иногда таковых несколько человек - по каждому процессу - свой). Фактически ИТ-шник допрашивает с пристрастием разных людей, имеющих отношение к бизнес-процессу. И записывает с их слов, интерпретировав в технический язык.

Тут крайне важно, чтобы интервьюироваемые не перекладывали на ИТ-шника. Типа "ты же специалист, должен все знать". Я обычно отвечаю: "Вы хотите чтобы я ваши проблемы решил или свои".

Дело ИТ-шника понять и перевести на технический язык. Но ни в коем случае не самому описывать бизнес-процессы. Бизнес процесс должен описать тот, кто этим занимается.

Причем, важно!!!
Иногда начальники не очень хорошо представляют мелочи, которые будут важны для тех. задания.
Поэтому нужно общаться и с руководством и с простым сотрудником, которого затрагивает то, что описывается в тех. задании.

На самом деле ТЗ не всегда нужно.

Если заказчик согласен вечно платить почасовку - можно без ТЗ.
Это позволяет сэкономить кучу времени и быстро подстраиваться под изменения бизнеса.

Но это возможно только если заказчик может и согласен платить без ограничений.
Такое возможно, если сумма денег которые тратят на исполнителя - для заказчика копейки.
Или заказчик безоговорочно доверяет исполнителю (и исполнитель по карману заказчику)

Есть еще вариант -
делается примитивный прототип MVP
https://en.wikipedia.org/wiki/Minimum_viable_product
По нему оценивают и тех. задание составляют/уточняют.
Но делать такие вещи обычные заказчики отказываются,
только те, кто работает с большими и дорогими вещами - согласны.
Это серьезно уменьшает их риски.

Не совершайте ошибку - не пишите замороченными словами.
Нужно писать обычным человеческим языком.
ТЗ - это намного более простая вещь, чем обычно представляют.
Это просто описание человеческим языком всех нюансов.

Ищите по doxygen, к примеру.

1. Химия в организм (алкоголь и тп.)
   
2. Новые физические ощущения. В сексе, в занятиях спортом, танцы, скачки на лошади - что угодно. Любое физическое воздействие
   
3. Новые места (путешествия, как глобальные, так и локальные - новые места в своем городе)
   
4. Новые знакомства с интересными/необычными людьми (да, да, да, это помогает и для веб-сайтов, даже если человек не имеет к этому никакого отношения)
   
5. Просмотр сайтов куда не заходил никогда. Например, я увлекаюсь фото. Наши фотографы хоть и разные, но не настолько разные, как заграничные - те на наших похожи бывает куда меньше, чем наши между собой. Аналогично и для просмотра дизайнов сайтов рекомендую - ходить туда куда обычно не ходишь.
   
6. Сон. Настраиваться на эту тематику и видеть дичайшие образы. Аналогично первому варианту с химией, но зато естественно. Просыпаться в определенное время, когда помнишь сон. Будешь помнить ты или нет - зависит только от времени просыпания. То есть в какой фазе сна тебя разбудило.
   
7. Не замыкаться только на просмотре сайтов/фотографий/знакомствах по единоборствам. Смотреть близкую тематику (да хоть йога). Или вообще не близкую - да хоть автомобили.
   
8. Не замыкаться на кунг-фу и единоборствах. Ассоциативное мышление в нашей голове штука сложная. Ты можешь придумать хорошую идею просто наблюдая за пьяной девчонкой в клубе или глядя на здание или на зверя в зоопарке или рассматривая штабеля с товарами на складе.
   

Общая идея - новые впечатления во всем. В том что связано с тематикой сайта и в том что не связано с тематикой сайта.

Дело не в языках.
А в стандарте HTTP, который stateless.
То есть хранить приходится состояние в явном виде.

От языка сие не зависит.

Можешь хранить в cookie в браузере,
можешь хранить в http header или в http url,
можешь хранить в браузерном local storage,
можешь в базе данных или в оперативной памяти на сервере, во вспомогательном сервисе на сервере (не в вашем движке, а например в Tarantool), связывая эти записи с браузером через cookie, header или url).

Дело не в языке PHP или другом языке.
Во всех языка - те же варианты.

Это стандарт http, Карл.
Это стандарт http.

Разделить на мелкие независимые части (типа микросервисов). Изолировано-самодостаточные.

ПС:
Навык декомпозиции - это самый важный навык для программиста, разрабатывающего сложные системы.

Все очень просто. Даже примитивно. И вполне очевидно.
Чем дороже - тем лучше. Чем дороже - тем меньше конкуренция.

Есть только такой недостаток человеческой психики -
когда у тебя есть миллион исполнителей готовых сделать за еду,
но ты даже головой понимаешь, что это нереально,
то, все равно, жаба говорит - давай попробуем за 3 копейки.

Самая большая проблема - если заказчик не специалиста вообще.
Тогда выбрать адекватного исполнителя сложно.

Я вот специалист, заказывал работы по своей сфере.
Я точно знаю что работа занимает довольно много времени
и человек, квалификация которого позволяет сделать эту работу,
не будет работать даже в провинции дешевле Х денег,
но я все равно получал множество предложений
с обещаниями сделать круто в 10 раз быстрее, чем это физически возможно.
Ну и разумеется, за деньги в 10 раз меньше.

На самом деле эту работу невозможно выполнить на таких условиях было.
Тем не менее жаба моя очень сильно мешала подумать.
Даже не смотря на то, что я являюсь специалистом в этой сфере и прекрасно понимаю,
что все эти оценки - мягко говоря, до идиотского оптимистичны.

Вывод:
Да, конкуренции полно.
Да, предложений много.
Реальных квалифицированных исполнителей - крайне мало.
То, что там что-то тебе предлагают,
в 99% означает, что тебе или не выполнят вообще
Или выполнят на крайне некачественном уровене.

Ответ очевиден - только деньги.
Квалифицированные специалисты несмотря на "типа конкуренции" имеют очереди из работ.
И цен не снижают
;)
Вся эта конкуренция - эффемерная.
Это больше - просто информационный шум.
Да, неудобно пробиваться до заказчика или искать адекватного исполнителя.

То есть эта "типа конкуренция" - просто мешает сосредоточиться, встретиться заказчику и исполнителя.
Фактически - конкуренции нет.

Есть еще одна ошибка заказчика.
Её вы можете почитать на форумах где заказчики жалуются, что невозможно найти специалиста.
Фактически это выглядит так: "выбрал первого попавшегося за 3 копейки, тот ничего не сделал,
выбрал второго попавшегося за 3 копейки, тот ничего путного не сделал,
выучился на своих ошибках, выбрать третьего попавшегося за 10 копеек, тот ничего не сделал,
выучился на своих ошибках, взял по рекомендации специлиста, тот захотел 100000 рублей, совсем оборзел, отказался,
выбрал первого попавшегося за 100 рублей, тот сделал вид что делает работу, не более того"

Ну вот такая вот конкуренция.
Да, жаба заказчика очень мешает понять, что фактически нет работников за 3 копейки.
Они не реальные.

Не гоните на Windows.
Дело не в файловой системе.

Дело в том, что nix-овый софт традиционно использует запуск процессов на каждый чих.
В nix это дешевая операция.
Вот весь софт и заточен чтобы делать элементарные вещи через запуск скриптов, а в Винде следовало бы делать через вызовы АПИ.

Неужели до сих пор ни кто не придумал платформу для разработки на Windows, что-то типа интегрированной системы Linux + Ext4 с чтением/записью в Windows.

Microsoft и Ubuntu - придумали уже несколько месяцев как.
С лета 2016 в Windows 10 встроена подсистема Linux на базе Ubuntu
Попробуйте, может, решит вашу проблему.

Там правда не файловая система (думается не в ней и проблема).
А утилиты, API - имхо, в них и был затык.