А что за боязнь ООП? Это же не черт в табакерке, и не сложнее, чем функциональное программирование, например. Хотя сложность во многом зависит от инструмента (конкретного API, языка), в чистом виде научиться мыслить объектами, имеющими действия-методы и данные-свойства не составит труда
Как показывает практика составит. Если бы было так легко, то не было бы столько ужасного кода. И я не говорю о плохом коде с ООП, и при процедурном его много. Я говорю, о коде который пишется в синтаксисе ООП, но не является ООП, например классо-ориентированный код, где повсеместно используется статика.
Но в php без ООП сейчас никуда, поэтому боязнь надо перебороть.
На выполнение ваш скрипт запускаете как обычно: вызываете по адресу в браузере или как-то так. Но перед этим в PHPStorm должен быть включен дебаггер - кнопка, справа вверху "Start Listening for PHP Debug Connections". В браузере (если через него запускаете) должно быть также запущено расширение для XDebug. И, конечно, Xdebug должен быть установлен и настроен, как в php, так и в PHPStorm.
Ориентируйтесь на поле времени, этого вполне достаточно. Если аккаунт может быть отключенным не по времени, сделайте 2 поле, и ориентируйтесь на 2. Тут дело не в логике, а в технической реализации, не нужно внедрять внешние планировщики без особой нужды.
Если пользуетесь Oracle или PostgreSQL Pro, то триггер можно создавать в базе, для этого есть специальные джобы, но и в этом случае я бы выбрал 1 вариант.
Sergey Svetlov, я не специалист, не могу оценить трудозатраты, поэтому отметил что трудозатраты и сроки разные вещи. Но тут специалист нужен только для оценки трудозатрат. Поэтому в вашем случае - мой 2 абзац.
Кол-во стейджингов не связано с кол-вом задач и гитом. Если у вас 1 тестировщик, он может использовать 1 стейджинг, последовательно переходя от одной задачи к другой, собирая для каждой нужный код. И не важно сколько задач ожидают тестирования. Не вижу проблемы.
Если речь про CI и регрессионное автоматизированное тестирование, то их можно прогонять ночью из dev на том же 1 стейдже.
Проблема может быть только в том случае, если тестировщик не управляет процессом сборки.
Lamoda, насколько знаю, отдельные сервисы, связанные со сложными вычислениями в погоне за скоростью перевела с php на python, последний их также не устроил, стали переводить на go. Хотя мне кажется, это больше архитектурные просчеты, обычно уже при проработке архитектуры понятно, где достаточно php, а где нужен go.
dollar, ну да, вы ничего такого не писали, вероятно комментарии адресованные мне, с замечаниями для меня, с цитатами моего текста и сделанными выводами относятся не ко мне... Но согласитесь в самом первом комментарии вы сильно лопухнулись, ведь далее вы старательно контролируете то, что пишите, чтобы потом написать "я такого не писал! я не это имел ввиду", ну и все остальное, а там слишком явно.
В любом случае, раз утверждаете что-то, распространяйте и на себя. Почему вы так многострочно переживаете мои фразы? По вашей логике: с чего вы взяли, что они относятся к вам?
В остальном, по-прежнему скучно, "я не писал", а если "писал, то не то имел ввиду", и даже после этого никаких пояснений как действительно думаете. Теперь уже "переход на личности" только устоявшийся оборот, к чему же вы тогда писали про "несуществование личности"? Ведь речь была только об этом обороте. Если подгоняете факты к вашим суждениям делайте это более изящно, попробуйте выписывать ваши суждения, чтобы не путаться в них.
А на счёт сомнения, вы зря, хоть при научном подходе, хоть в повседневной жизни, человек анализирует ситуацию и принимает решение, затем действует, следующий анализ будет только, если появятся новые вводные. А если, человек сомневается постоянно, не может принять решение, а приняв, все равно терзается сомнениями, это называется неуверенностью. И дело не в процентах правоты, а в том, что если бы каждый учёный, вместо действий, только постоянно сомневался, никакого научного развития не было.
Коли вы призвали как авторитет научный подход, то в нем доказывать должен утверждающий (это к слову о верблюдах). Тогда потрудитесь доказать ваш первый комментарий, равно как и вообще переход на личности, а не обсуждение вопроса.
dollar, давайте будем честны, хотели бы завершить разговор, давно бы уже сделали, а делать вид что выше этого и в то же время активно спорить не слишком честно, а ваше снисходительное "чтобы пресечь демагогический аспект, я и сказал, что вы правы, а я - нет, что бы это ни значило"? Кого это может обмануть? Не нужно лицемерия, ведь вы же никак не можете допустить, чтобы последнее слово было не за вами.
Вы не переходили на личности? Ну да, с обсуждения кода перепрыгнуть на обвинения в отсутствии логики с аргументацией из своих якобы психологических изысканий?
Пишите, что не переходили на личности, а в следующем абзаце уже не уверены в существовании личности. Уверены что не затрагивали того, в существовании чего не уверены? Как то вы слишком уверены, когда вам надо, и не уверены, когда опять же вам надо. Да, и научный мир вы упомянули не к месту. Научный подход не приемлит принятие без доказательств, и готов к пересмотру утверждений при новых данных, а уж никак не постоянные сомнения в своих словах и мыслях, это как раз и зовется неуверенностью.
И опять уверенно пишите чего нет, но вдруг начинаете сомневаться и оправдываться, когда вас уличили. Я уже предупреждал, что уловки "я этого не говорил, т.к. перед утверждением написал "мне кажется", "почти", "на грани"" можете использовать где-то ещё, здесь не прокатит. Фразы "ты дебил, поэтому не буду с тобой разговаривать" и "мне кажется, ты дебил, не буду с тобой разговаривать" по-сути одно и тоже. И там, и там, выражено мнение, выехать на сомнениях не получится, т.к. вытекающее действие озвучено уверено, а значит и в первом нет сомнений.
Опасались флуда? К чему тогда с обсуждения вопроса бросились флудить про связь слов и логическое мышление? Не хватает логики? Ещё бы, "спагетти код понятен гению программирования Васе, поэтому это отличный код, подтверждение тому то, что Vitsliputsli слишком часто употребляет слова подобные "все"", что-то с вашей логикой явно не так...
Любите сомневаться - сомневайтесь до того, как что-либо написать.
dollar, в моих словах оскорблений не больше, чем в вашем "замечании", перечитайте его. Прав в чем? Мы могли бы подискутировать по вопросу, но вы решили иное (может из-за внутренней неуверенности, о которой пишите), перешли на личности. К чему теперь обижаться, что кто-то прошёлся и по вашей личности тоже?
dollar, а я давно заметил, что когда кто-то не может сказать по существу он меняет тему. А если этот кто-то ещё и понял, что был неправ, но его незрелая психика не позволяет признавать свои ошибки, то он переходит на менторский тон, делает вид что его положение не допускает сомнения в словах, и начинает делать глупые утверждения без какой-либо аргументации в надежде сбить с толку собеседника.
Вы ошиблись в собеседнике, мне плевать на вашу демагогию, есть что сказать - говорите, нет - лучше промолчать.
продолжая демагогию
Когда кто-то использует вместо кванторов всеобщности высказывания вида: "почти однозначно", "практически не способен", "я уже давно заметил" это свидетельствует о том, что он сам не уверен в том, что говорит. Демагог, зная что пишет чушь, таким образом страхует себя на случай, если прижмут, типа он же не имел ввиду что для всех работает.
Сожалею, но ваша попытка спрятаться за слова выглядит очень жалко.
Mylistryx, если забыть про uuid, а зачем морока с разрядами, не проще ли было использовать составной ключ? Или уже неизвестно, просто так "исторически" сложилось?
Однако если взглянуть на его код, то там хрен разберешь, что к чему. Так называемый, спагетти-код. Ему этот код понятен. А нам, сторонним наблюдателям, - нет.
Не бывает понятного спагетти кода. Да, Вася может постоянно вариться в этом коде и потому помнить, что где и как делается. Также, и другой программист, после долгого изучения выучит, что, где и как работает. Но если оба месяц-два поработают с другим проектом, то уже с трудом будут помнить что и где находится, а код им в этом не поможет. Очень часто заказчики попадают в рабство таких Вась, просто по причине своей скупости, но яхты им никто не будет покупать.
Так же и с оптимизацией, управление сложностью гораздо более важная задача, потому что от нее зависит все, а оптимизация нужна только на отдельных участках, и эти участки зачастую не определимы сразу. А "кривой, но круто оптимизированный" код возможен только для каких-то очень простых задач. В противном случае, вы очень быстро потеряете контроль над проектом.
В сортировке пузырьком нет никакой архитектурной ошибки, иначе бы ее не использовали в обучении. Хотя есть и более эффективные варианты. А если говорить про архитектуру, то наиболее эффективен монолитный кусок, без шин обмена, API, модулей, сервисов, автолоадинга, ООП, да и вообще классов, конфигураций, обработки исключений, портируемости и т.п. Но такая не расширяемая, не поддерживаемая, не тестируемая и от того нестабильная, какашка, никому не нужна.
altair86, используйте явное указание индексов только в крайнем случае. Т.к. вы получите более эффективный план в данный момент, но в будущем при изменении статистики план может стать крайне неэффективным.
Проверьте когда собиралась статистика и соберите ее по нужным таблицам. Теоретически это должно происходить автоматически, но всякое бывает. Не указывайте ничего вручную, если нет полной уверенности, что оптимизатор действительно ошибается.
Для явного указания индекса используйте хинт IndexOnlyScan с указанием нужного индекса, это модуль pg_hint_plan. Доступно только в Enterprise версии.
Как показывает практика составит. Если бы было так легко, то не было бы столько ужасного кода. И я не говорю о плохом коде с ООП, и при процедурном его много. Я говорю, о коде который пишется в синтаксисе ООП, но не является ООП, например классо-ориентированный код, где повсеместно используется статика.
Но в php без ООП сейчас никуда, поэтому боязнь надо перебороть.