вложить десятки тысяч долларов собственных средств
я не знаю всей истории создания проекта, но в той же статье вы пишете
На сам проект у меня ушло два года работы. Примерно 3800 часов. Каждый час я примерно оцениваю в 30$
тут корректно было бы сказать что вложили 3800 часов, а это куда более ценный ресурс — его вы назад уже не отобьете
И уникальность опыта вы переоцениваете, готов поспорить что здесь найдется довольно большой процент людей кто участвовал в провальных проектах. Даже если это не свой проект всегда можно проанализировать и понять в чем была проблема
Почему вы называете pet-project стартапом? Глянул предыдущие статьи и судя по всему вы кучу времени пилили проект один, изредка привлекая фрилансеров и увольняя их когда результаты их деятельности вас не удовлетворяли. Опять же, в предыдущих ваших статьях на тему этого портала, например здесь, вам указывали в комментариях на структурные ошибки и косяки в использовании. И неглубокие знания предметной области проекта, вероятно, куда больше повлияли на провал
почему не приделали все это в виде обычного расширения/плагина/модуля или как там это называется в modx? В проекте на чем-то современном использовать это нет смысла т.к. уже существуют http://phpdebugbar.com/ https://github.com/symfony/var-dumper
По самому коду — очень неряшливо написано, постоянные смешивания конструкций
namespace Alpa\PhpDump;
// the file for the autoloader will load when accessing the class.
include_once __DIR__.'/../include_file_in_index.php';
видать задачи где подойдет именно «строитель запросов чуть-чуть лучше чем тупая конкатенация строк» простые и сводятся к обычным выборкам максимум с парой условий. Или же людям, которые занимаются в основном такими задачами, лень потыкать существующие отлаженные инструменты и проще сделать очередной костыль тупо под задачу и использовать его
а я думал что будет информация которую можно вытащить из данных пробежки как-то отображаться в веб-морде, что-то типа красивых графиков скорости, пульса, восстановления пульса после окончания пробежки, чтоб за какое-то время можно было наблюдать динамику повышения тренированности, типа за месяц стал пульс быстрее в норму приходить, при определенном пульсе средняя скорость стала выше и т.п.
https://cloud.mail.ru/ — вполне ниче так, рекламы нет, работает норм
Внезапно аццки полезная фишка в их почте — халявные смс-оповещения — юзаю для сообщений от заббикса
В таком случае надо перескочить через голову с намеком что прямой руководитель не хочет прислушиваться к голосу разума и фишка будет зафейлена за 2 недели без вариантов вообще. Если же никто так и не прислушается то или со спокойной совестью делать без переработок что возможно и потом говорить «я же говорил» либо сваливать из такого места. Быть слишком исполнительным в таком случае себе вреднее, потом все сроки так и будут ставиться с учетом того что чувак в экстренном случае пропустит свои выходные и будет перерабатывать потому что ему сказали что надо
В этом и косяк — должна быть цель сделать крутой продукт. Разработчику надо было держаться до конца и говорить что если срок 2 недели то фишка не будет полностью готова и получится недоделанная и кривая. Или в процессе сказать руководителю отдела что как бы он ни хотел чуда не случится и нужно отодвигать сроки или обрезать функционал. В общем куча вариантов как обойти то что руководитель отдела захотел повыеживаться несмотря на предупреждения
Подобный случай отлично описан в книге Роберта Мартина — Идеальный программист. Там достаточно много уделено внимания как раз таким случаям как жестко отказать или когда следует браться за реализацию фишки. В приведенном вами примере разработчику следовало четко сказать что за 2 недели — не сделать, а за 3-4 — да, реализуемо. И никаких «если постараться то за 2 успеем»
На втором шаге можно обойтись и без Ивана — когда сертификат самоподписаный. Только ему наверно приходится говорить «Верь мне, я Боб, все будет хорошо». Тут уже Алиса может и не поверить, сказав что без контроля Ивана ничего не получится
Не все так просто — у вас все равно все будет в 1 процессе. В текущей реализации если задача, которую запустит этот демон, вылетит с ошибкой, то все выполение застопорится т.к. запускается не в отдельных процессах. Так же придется самому дописывать контроль над тем что нужная ресурсоемкая задача не запущена, перезапуск демона чтоб он не прибил то что в процессе ну и кучу чего еще
в последнем примере дело не в UI, а в идее единого интерфейса для комманд и запуска одной команды для разруливания задач, чтоб она уже сама если время наступило запускала все остальное.
В итоге получилось бы или как в последнем примере или как здесь.
Ну или можно было бы вообще отвязаться от крона и использовать https://github.com/amphp/amp, ориентироваться на этот кусок, но это привнесет кучу других проблем с проверкой состояния демона, разруливания по отдельным процессам и т.п.
вы хоть определитесь, десятки или сотни тысяч ушли. Если сотни тысяч — странно что не наняли нормального дизайнера
я не знаю всей истории создания проекта, но в той же статье вы пишете
тут корректно было бы сказать что вложили 3800 часов, а это куда более ценный ресурс — его вы назад уже не отобьете
И уникальность опыта вы переоцениваете, готов поспорить что здесь найдется довольно большой процент людей кто участвовал в провальных проектах. Даже если это не свой проект всегда можно проанализировать и понять в чем была проблема
http://phpdebugbar.com/
https://github.com/symfony/var-dumper
По самому коду — очень неряшливо написано, постоянные смешивания конструкций
и кучи закомментированных кусков кода
а также куски с дебаг-информацией
Ну и завязка на апач тоже не в плюс
Внезапно аццки полезная фишка в их почте — халявные смс-оповещения — юзаю для сообщений от заббикса
В итоге получилось бы или как в последнем примере или как здесь.
Ну или можно было бы вообще отвязаться от крона и использовать https://github.com/amphp/amp, ориентироваться на этот кусок, но это привнесет кучу других проблем с проверкой состояния демона, разруливания по отдельным процессам и т.п.