Что угодно может произойти! Поэтому в проекте должен быть СТО/техлид, одной из онсовных задач которого будет выработка и enforcement общих подходов. А отдельно взятому разработчику нужно стараться обращать внимание на то, какие привычки и подходы доминируют в кодовой базе вокруг него, и либо принимать их, либо убеждать всех вокруг, что нужно делать по-другому.
Много кода пишется на автомате и это ок, так что мест, где реально принимается какое-то решение, чаще всего не так много. Так что это не буквально 100% рабочего времени ?
При реализации фичей меньше думать о глобальной картине – это мне не нравится. Как только мы принимаем какое-то решение о том, как фича будет реализована, мы невольно начинаем мыслить в этой принятой парадигме. Менять получившийся код может оказаться не просто затруднительно по времени — сама идея более удачного решения может потеряться или перестать выглядеть логично.
А чищу код я чисто на автомате, конечно, исключительно на языке инвариантов. Но это возможно только если он изначально написан неплохо ?
А почему бы не давать поле с вводом названия на родном, на английском, и альтернативные переводы, с указанием языка для каждого перевода?
Потому что у продавцов, которых подключали на старте, не было в распоряжении таких данных для сотен тысяч своих товаров, и заводить их ради нас они бы не стали.
имя в нормальной(стандартной) форме, имя для сайта, имя на английском языке, и галочки для выбора отображения
Указанием всего этого стал бы запариваться примерно 1% пользователей.
Я сейчас отхвачу минусов, конечно, но в моём представлении активизм Александры в долгосрочной перспективе скорее даже вреден, чем полезен. Sci-hub — это костыль, решающий финансовую проблему доступа учёных к статьям, и этим фактически заметающий концептуальные проблемы науки под ковёр. Исследователи скачивают статьи бесплатно, а на следующий день отправляют свои исследования в тот же самый Elsevier. Status quo воспроизводит сам себя.
Спасибо, очень понравилось ваше мнемоническое правило, что NaN — это на самом деле число, просто неизвестное. Могу добавить, что, поскольку log(-1) = NaN, это число ещё и необязательно вещественное (в данном случае комплексное).
Это очень, очень неуниверсальное решение. Limit и offset, в отличие от него, работают с любыми сортировками.
Для запросов в очень большие данные с очень большим сдвигом стоит пользоваться хранилищами, предоставляющими для этого специальные возможности. Например, у Elasticsearch для этого есть даже дваразных API.
С точным ТЗ в продуктовой разработке сложновато, потому что никто не умеет глядеть в будущее, увы)
Неплохая курсовая!
Что угодно может произойти! Поэтому в проекте должен быть СТО/техлид, одной из онсовных задач которого будет выработка и enforcement общих подходов. А отдельно взятому разработчику нужно стараться обращать внимание на то, какие привычки и подходы доминируют в кодовой базе вокруг него, и либо принимать их, либо убеждать всех вокруг, что нужно делать по-другому.
Я работаю над проектом > 1M LOC на Go)
Много кода пишется на автомате и это ок, так что мест, где реально принимается какое-то решение, чаще всего не так много. Так что это не буквально 100% рабочего времени ?
При реализации фичей меньше думать о глобальной картине – это мне не нравится. Как только мы принимаем какое-то решение о том, как фича будет реализована, мы невольно начинаем мыслить в этой принятой парадигме. Менять получившийся код может оказаться не просто затруднительно по времени — сама идея более удачного решения может потеряться или перестать выглядеть логично.
А чищу код я чисто на автомате, конечно, исключительно на языке инвариантов. Но это возможно только если он изначально написан неплохо ?
Справедливости ради, конкретно в вашей ситуации проблема в отсутствии строгой валидации схемы, а не в питоне.
Применение машинного обучения как жанр комедии)
Иногда я делаю вещи просто чтобы мне было весело.
Указанием всего этого стал бы запариваться примерно 1% пользователей.
(Нет.)
log(-1) = NaN, это число ещё и необязательно вещественное (в данном случае комплексное).Для запросов в очень большие данные с очень большим сдвигом стоит пользоваться хранилищами, предоставляющими для этого специальные возможности. Например, у Elasticsearch для этого есть даже два разных API.