Выгоревшие статей на столько букв не пишут. Автор знает кучу технологий, рынок труда знает, предложения работы есть, от многого даже отказывается по честолюбивым причинам. Тут не должно быть страха и бессилия. Когда бессилие, сил нет ни на что..., а он тут общался во всю, с юмором и дискуссиями.
Боже мой! Как же человек собой любуется! Через строчку хвастает глубиной познания C++ и программирования, прикрыв всё это выгоранием. Вот не зря говорят, что многие программисты страдают нарциссизмом.
Повзволю себе не согласиться. С ReCaptcha все не так однозначно.
1. Когда мы ее поставили на свой сайт, к нам стало поступать много жалоб пользователей, им не хотелось делать бесплатной работы по распознаванию изображений, тем более, что иногда ReCaptcha требует по два-три шага для прохождения. Время прохождения большое.
2. При использовании ReCaptcha становится зависим от работы google. Это все равно какой-никакой runtime vendor lock in. Конечно, google надежен, кто спорит, но чего только в нашей жизни не случается.
В иготе отказались в пользу картиночной кириллической капчи. У пользователей стало меньше проблем, а значит и нам легче.
Порой читаешь такие планы, уже со стороны своего некоторого опыта владения пиццерии, и думаешь, что за ересь тут написана.
И так с большинством популярных запросов в поисковиках. А происходит так потому, что пишут эти статьи рерайтеры, нанятые за хлеб и воду на фриланс биржах, либо «профессиональные блогеры» которые более ничем кроме блоггинга не занимаются, соотвественно во всем кроме последнего являются дилетантами. Таков современный, коммерциализированный веб.
Вам удачи и успехов! Приятно читать о таких проектах.
Категорически несогласен. Человек только начинает, экспериментирует, проверяет идею. Делает это расходуя только собственное время. Если у него есть время и знания для этого, можно только приветсвовать. Выстрелит, появится перспектива окупаемости — найдет разрабов, перепишут если надо.
А вы предлагаете сразу во все тяжкие? Нанять студию на такую вот сугубо кастомную предметную область? Вы понимаете, какой они счет выставят? Сколько там миллионов будет?
А проект то нетиповой, вряд ли у них что то удовлетворительное получится с первого раза. Тем более, что у студий конвейер, отработали, деньги получили, пошли дальше. Сидеть на одном проекте они будут только за очень большие деньги.
Ну CQRS тут точно ни к селу, ни к городу. А код да, слабочитабельный. Legacy система, что тут скажешь. Автор крутится, как может, ищет выход из положения.
В условиях не дан тип данных поля DT. Это и есть главная неточность в этом примере. Может DT предполагает строку YYYY/MM/DD (мало ли чего разработчику системы взбрело в голову), тогда первый ответ SNAFU правильный. Какова задача, таково и решение.
По мне, единственное, что можно скзать на такую задачу:
Недостаточно данных для ответа на поставленные вопросы, так как неизвестен тип поля DT.
Так может так и стоило задачу сформулировать? А не накручивать? Конечно, дело ваше. Видимо много желающих на данную вакансию. Ее бы и джуниоры решили, если бы она была нормально сформулирована. Создаете сложность там, где ее нет. Это всего лишь SQL.
Да нормально с синглтонами всё тестируется, че все на них так накинулись? Всё и вся через конструкторы тоже не напрокидываешься, есть такие сервисы, которые нужны почти всем классам (пример EventDispatcher), и тут синглтоны неплохо подходят, чтоб конструкторы не засорять.
Статья про идеальный мир, где проекты в богатых команиях пишутся с самого начала по TDD и с архитектурой угадали.
В реальности часто бывает так: бюджет ограничен, заказчику надо вчера, написали на коленке проект, тестов нет, на архитектуру много где забили, лишь бы быстрее выпустить проект на рынок и проверить выстрелит ли (думали сдохнет, шансов было мало). Проект взял и разросся, увеличился штат, увеличилось требуемое количетво фич. Чтобы безопасно менять код такого проекта, надо его покрыть тестами, хоть какими. Вот тут и появляется тестирование сингтонов, гигантские фикстуры, вызовы тестируемых методов через рефлексию. По мне лучше когда есть хотя бы функциональные тесты, или хотя бы приемочные, пусть и некрасивые, так спокойнее, чем вообще без них.
PS: Если дело касается веб-приложений на PHP я за функциональные тесты, я думаю у них максимальный профит (повышение надежности проекта) при минимальном времени написания. Под них архитектуру чаще не надо менять, в отличие от unitов
Могут то могут, но что-то не видел я такого. Хорошо, допустим вам нужна страница 200, как до нее добраться по вашему примеру? А главное зачем? Что такого конкретного может быть на 200 странице, чтобы была необходимость прямого перехода туда?
А, то есть весь список никогда не показывать, а показывать всегда, допустим, MAX 500 элементов и выводить общее количество, чтоб пользователь понимал, что это не все и искал нужные ему элементы списка поиском?
P.S. так то почему нет, достойный способ, но не подойдет для краулеров, котороым нужно проиндексировать все данные.
Вот такое обычно плохо заканчивается.
В театр ему надо, на сцену, трагикоммедии играть.
1. Когда мы ее поставили на свой сайт, к нам стало поступать много жалоб пользователей, им не хотелось делать бесплатной работы по распознаванию изображений, тем более, что иногда ReCaptcha требует по два-три шага для прохождения. Время прохождения большое.
2. При использовании ReCaptcha становится зависим от работы google. Это все равно какой-никакой runtime vendor lock in. Конечно, google надежен, кто спорит, но чего только в нашей жизни не случается.
В иготе отказались в пользу картиночной кириллической капчи. У пользователей стало меньше проблем, а значит и нам легче.
И так с большинством популярных запросов в поисковиках. А происходит так потому, что пишут эти статьи рерайтеры, нанятые за хлеб и воду на фриланс биржах, либо «профессиональные блогеры» которые более ничем кроме блоггинга не занимаются, соотвественно во всем кроме последнего являются дилетантами. Таков современный, коммерциализированный веб.
Вам удачи и успехов! Приятно читать о таких проектах.
А вы предлагаете сразу во все тяжкие? Нанять студию на такую вот сугубо кастомную предметную область? Вы понимаете, какой они счет выставят? Сколько там миллионов будет?
А проект то нетиповой, вряд ли у них что то удовлетворительное получится с первого раза. Тем более, что у студий конвейер, отработали, деньги получили, пошли дальше. Сидеть на одном проекте они будут только за очень большие деньги.
По мне, единственное, что можно скзать на такую задачу:
Недостаточно данных для ответа на поставленные вопросы, так как неизвестен тип поля DT.
Так может так и стоило задачу сформулировать? А не накручивать? Конечно, дело ваше. Видимо много желающих на данную вакансию. Ее бы и джуниоры решили, если бы она была нормально сформулирована. Создаете сложность там, где ее нет. Это всего лишь SQL.
Статья про идеальный мир, где проекты в богатых команиях пишутся с самого начала по TDD и с архитектурой угадали.
В реальности часто бывает так: бюджет ограничен, заказчику надо вчера, написали на коленке проект, тестов нет, на архитектуру много где забили, лишь бы быстрее выпустить проект на рынок и проверить выстрелит ли (думали сдохнет, шансов было мало). Проект взял и разросся, увеличился штат, увеличилось требуемое количетво фич. Чтобы безопасно менять код такого проекта, надо его покрыть тестами, хоть какими. Вот тут и появляется тестирование сингтонов, гигантские фикстуры, вызовы тестируемых методов через рефлексию. По мне лучше когда есть хотя бы функциональные тесты, или хотя бы приемочные, пусть и некрасивые, так спокойнее, чем вообще без них.
PS: Если дело касается веб-приложений на PHP я за функциональные тесты, я думаю у них максимальный профит (повышение надежности проекта) при минимальном времени написания. Под них архитектуру чаще не надо менять, в отличие от unitов
P.S. так то почему нет, достойный способ, но не подойдет для краулеров, котороым нужно проиндексировать все данные.