oleg_ods

Все очень сильно зависит от ТЗ, разработка которого стоит отдельных денег и времени.

Нужно провести аналитическое исследование, изучить потребности клиентов зала и владельцев заведения. Например, достаточно ли просто фиксировать факт входа выхода, или еще нужно использовать пропуск в зал в качестве ключика от шкафчика? А может, стоит привязать к пропуску еще и пульсометр и ввод антропометрических данных клиента в тренажеры?

Если вы хотите продать свое поделие владельцам фитнесов (которые как правило, люди не очень дружащие с ойти, им как-то штанга роднее будет), походите сами в разные фитнесы, посмотрите, где вам больно, а где удобно, авось, родите интересную бизнес-идею.

Слишком много вариаций существует, отсюда и огромный разброс цен. И стоимость непосредственно разработки составляет в данном случае около 1/5 всей стоимости, больше нервов и средств уйдет на аналитику и поддержку, потому что если ваше самописное чудо бахнет под утро, когда час пик и толпы разгневанных качков недожгли свои калории - у владельцев заведения будет неплохой соблазн отдать им вас в качестве тренажера.

для

большего понимания языка

нужна практика. про книги - тот кто хочет узнать нечто, читает все что под руку попадется*. тот кто не хочет ни читать, ни кодить, (upd даже гуглить сам не хочет ;) тот и задает вопросы "а как мне ни чего не делая, сразу в сеньеры попасть"?

ps * - если какую то книгу хвалят, это хорошо. в данном случае, вы упоминаете книги, у которых заведомо разная цель (по крайней мере по названиям). даже при возможном сходстве оглавления, "CLR via C#" больше ориентирована на раскрытие подкапотного устройства дотнет (CLR же). "Справочник по С# 7.0 полное описание" - вы не сообщаете автора, а мне тоже в лом гуглить.. в общем случае справочник, все таки не обучающее пособие для новичков, а подручная книга для того кто уже начал кодить самостоятельно, и постоянно этим занимается
но как я попытался намекнуть выше, если вы хотите изучать (а если еще и смекалкой не обделены) - читайте все что под руку попадется, и тут же пробуйте. и сравнивайте. сравнение очень крутой опыт. в этом случае не важно, лучшая ли у вас книга. да и вообще - книги катастрофически отстают от реальности. возмитете любую доступную книгу, но добавтьте просмотр хабра по тематическим тегам, и не ленитесь нажимать кнопку F1 в визуал студии (будете знакомиться с МСДН**). так и формируется собственный опыт

** частенько МСДН, это истина в конечной инстанции. хотя не всегда легокопереваримая

pps только на ютуб не ведитесь. там конечно есть и записи с конференций профи (чумовые) но до них дорасти надо. а по запросам вылезает море пены от школоты. имхо

Нет, не стоит.
Вы тупо будете слушать, как картавый мычащий Васян пересказывает какой-нибудь learnjavascript, пропуская половину тем, которые сам не понимает.
И таких видео - 90%.

Читайте Эндрю Троелсена, автор не заморачивается какаими-то поблажками для новичков.

В конструкторе x, y, z перепутаны с width, height, length

Есть такая штука - авторизация, и есть такое понятие как овнершип (владение) и ACL/RBAC. Во всех скриптах проверяется кто владелец файла, или кто может его изменять/удалять. Если у пользователя есть права на изменение/удаление объекта - скрипт отрабатывает, если нет - выдает ексепшн или иначе оповещает о неудачном завершении.

конструктор – метод, который вызывается автоматически при создании объекта.
Конструктор_(объектно-ориентированное_программирование)

Создайте в таблице пользователей еще 1 поле (например password_hash_version).
Всем старым пользователям проставьте метод md5 в это поле, а новым пользователям или тем кто сбрасывает пароль bcrypt.
И при авторизации просто смотрите какой алгоритм использовать, старый или новый.
Когда переведете всех пользователей на новый алгоритм хеширования, старый можно удалить.

1. примерно так

2. Нет, многопоточность с асинхронностью не имеет ничего общего. При многопоточности обычно планировщик ядра (если потоки ядерные) переключает контекст между твоими потоками. Работает это так: ты в своем приложении сообщаешь планировщику что хочешь создать поток (например через pthread_create, если ты программируешь в linux или freebsd), указывая ему функцию, которая должна выполняться в отдельном потоке и аргументы для нее. Ядро создает у себя в таблицах запись для него и ставит этот поток в очередь на выполнение так же как основной поток. Адресное пространство у них будет общее.

3. К примеру ты хочешь обслуживать TCP клиентов, ты создаешь сокет (или несколько), ставишь им неблокирующий режим, затем тебе их в цикле нужно опрашивать. Для этого есть несколько способов: select и poll есть во всех ОС, но они хороши когда у тебя сокетов мало. В linux есть еще epoll, который намного более эффективен, во FreeBSD и MacOS есть kqueue - очень эффективный метод. Когда к тебе, к примеру, придет TCP клиент твой select/poll/epoll/kqueue вернет информацию о сокете, который готов для чтения (твой listen сокет), ты делаешь ему accept, и добавляешь сокет клиента в select/poll/epoll/kqueue. Если происходит событие на клиентском сокете, к примеру на нем сработал read - значит там есть данные, ты их читаешь и обрабатываешь, если сработал write - сокет освободился для записи и можно в него писать. Еще в kqueue и epoll есть таймеры. Главное не использовать при такой архитектуре какие-нибудь sleep, не использовать блокирующие библиотеки с базам данных, нужно обраратывать все быстро и возращать управление в select/poll/epoll/kqueue. Если, к примеру, нужно сделать задержку, выполнение коллбэка нужно прервать, создав какой-нибудь таймер (есть много способов).
В целом - разработка асинхронных приложений требует совершенно иного подхода, это обычно немного сложнее, особенно если тебе нужно будет ходить, например, в базу данных. К примеру, системный резолвер (gethostbyname) является блокирующим - его в такое архитектуре исползовать нельзя, придется взять библиотеку, например, c-ares, которая реализует асинхронный резолвер.

4. то же что и 3, но select/poll/epoll/kqueue запускаем в нескольких потоках, это рационально делать для утилизации нескольких процессоров.

В точке входа в проект (index.php), в самом начале выставить все по нулям

ini_set('display_errors', 0);
ini_set('display_startup_errors', 0);
error_reporting(E_ALL);

1.

Мне нужно записать в базу данные id, ware->id, ware->title, income если найдено соответствие по email адресу.

- добавьте в таблицу dle_users колонки под эти данные (с префиксом, чтобы отличать их от остальных колонок, например paym_id, paym_ware_id, paym_title, paym_income) или создайте новую таблицу payment_info с такими же колонками плюс user_id как foreign key на id из таблицы dle_users.
2.

На сайте может быть зарегистрировано несколько тысяч пользователей.

- несколько тысяч - это сколько?) До 10 тысяч? До 100 тысяч? Это имеет значение, это влияет на решения, принимаемые в п.1. Для большой таблицы с активными данными и частой записью лучше не делать alter table.
3.

Обращаться к Json хочу как можно чаще по cron

- наименьшая единица времени в кроне - 1 минута. Насколько часто Вам нужно? Иногда раз в полчаса вполне достаточно - не будет лишней нагрузки, но тут вопрос к бизнес требованиям - на что влияет актуальность этих данных.
4. По какому критерию Вы инициируете запрос к стороннему сервису? Как я вижу, что вы дергаете данные по одному платежу/пользователю, неизвестно, как сторонний сервис отреагирует на много запросов за один раз.
Скрипты по крону не имеют ограничения по времени исполнения, но могут зафейлится по потреблению ресурсов или по стабильности ответов от стороннего сервиса. В целом идея такая:
1. Дергаете стороннее апи, получаете json ответ. По какому критерию не делать лишние запросы - я не понимаю из Вашего задания, но предположительно по paym_id, которые еще не обработаны.
2. Парсите ответ через json_decode в массив.
3. Находим в массиве имейл, проверяем есть ли в dle_users. Если есть - добавляем paym_id, paym_ware_id, paym_title, paym_income в базу.

В этой статье есть решение моей проблемы
https://web-answers.ru/c/kak-prochitat-okno-pamjat...