Если бы вы разрабатывали обычный монолит или сервис со своим хранилищем, то вы просто переименовали бы колонку в telegram_id, а также поправили код, который с ней взаимодействует.
Врядли кто-то станет так делать, это очень регрессионно и трудозатратно. Для описанной вами задачи проще было бы добавить новую таблицу в которой для userId хранить список его каналов.
Так вот про это и вопрос: что считать активным кодингом и какие интервалы отдыха нужны между периодами активного кодинга, чтобы восстановила эффективность? А так нет единой точки отсчёта и результат этой статьи невозможно перенести на реальную жизнь.
Странно, но не указано какой должен быть интервал между фазами активного кодинга. Может с 9 до 12 активно покодил, потом пару часов других занятий и час на обед и затем ещё 3 часа кодинга. И так уже 6 часов в день из 8 часов обязательных. Три часа как-то мало выходит.
А еще есть вариант того ,что выбранный фреймворк как и "самописный" перестанет попадать в видение проекта и получим те же сложности, но уже в плоскости смены фреймворка.
Тут наверное основой вывод - это то, что перед тем как сесть писать код нужно все хорошо спроектировать, но это требует много времени, поэтому так мало кто делает. Выбирают эволюционный подход, но в ходе эволюции не все решения выживают.
Ну я имел ввиду, что приложение просто ищет QR код в кадре, что проще, чем распознает образ экспоната. А для пользователя ничего не меняется, он просто направляет камеру на объект.
Очень экстравагантно выглядид. В мгновение, посреди пустого пространства возникает чёрная дыра ну или что-то еще, чем мог бы быть туннель между вселенными. Это наверно должно было бы породить мощную гравитационную волну. Ну и если описанная теория имеет хоть что-то общее с реальностью, то такие волны рано или поздно могли бы зафиксировать, нужные технологии уже имеются.
Если верить Хоукингу чёрные дыры испаряются, т.е. выходить что получившиеся из них новые вселенные тоже испаряются. А раз так-то бесконечной инфляции не выйдет.
В вашем варианте можно попробовать в левом отсортированном подмассиве применить бинарный поиск, чтобы найти место вставки нового элемента не перебирая все элементы, а затем просто сдвинуть все элементы от этого места вправо и на освободившееся место поставить новый элемент. Таким образом водно уменьшить число сравнений элементов.
Если идти по строке слева на право и искать паттерн AXA или AA, где А - это любой символ, то можно находить центры палиндромов и уже от центров идти в обе стороны к краям определят максимальную длинну. Так по идее должно иметь сложность от O(N) до O(N*N) в худшем случае.
Врядли кто-то станет так делать, это очень регрессионно и трудозатратно. Для описанной вами задачи проще было бы добавить новую таблицу в которой для userId хранить список его каналов.
Так вот про это и вопрос: что считать активным кодингом и какие интервалы отдыха нужны между периодами активного кодинга, чтобы восстановила эффективность? А так нет единой точки отсчёта и результат этой статьи невозможно перенести на реальную жизнь.
Странно, но не указано какой должен быть интервал между фазами активного кодинга. Может с 9 до 12 активно покодил, потом пару часов других занятий и час на обед и затем ещё 3 часа кодинга. И так уже 6 часов в день из 8 часов обязательных. Три часа как-то мало выходит.
Вот интересно, в машине есть куча доп оборудования, которое я не заказывал и при этом оно наверняка добавляет заметный вес, а с ним и расход топлива.
Это законно? :)
А еще есть вариант того ,что выбранный фреймворк как и "самописный" перестанет попадать в видение проекта и получим те же сложности, но уже в плоскости смены фреймворка.
Тут наверное основой вывод - это то, что перед тем как сесть писать код нужно все хорошо спроектировать, но это требует много времени, поэтому так мало кто делает. Выбирают эволюционный подход, но в ходе эволюции не все решения выживают.
Ну я имел ввиду, что приложение просто ищет QR код в кадре, что проще, чем распознает образ экспоната. А для пользователя ничего не меняется, он просто направляет камеру на объект.
А можно было бы рядом с экспонатов разместить небольшой QR код и искать и распознавать его. Это же сильно проще чем экспонаты распознавать.
Смотрю на все это переплетение трубок и сосудов и такое ощущение что времена стимпанка возвращаются:)
Т.е. наличие чёрной дыры никак не аффектит на окружающее пространство? Это странно звучит.
Очень экстравагантно выглядид. В мгновение, посреди пустого пространства возникает чёрная дыра ну или что-то еще, чем мог бы быть туннель между вселенными. Это наверно должно было бы породить мощную гравитационную волну. Ну и если описанная теория имеет хоть что-то общее с реальностью, то такие волны рано или поздно могли бы зафиксировать, нужные технологии уже имеются.
А что случается при слиянии чёрных дыр? Порождённые ими вселеные тоже должны сливаться?
Если верить Хоукингу чёрные дыры испаряются, т.е. выходить что получившиеся из них новые вселенные тоже испаряются. А раз так-то бесконечной инфляции не выйдет.
В вашем варианте можно попробовать в левом отсортированном подмассиве применить бинарный поиск, чтобы найти место вставки нового элемента не перебирая все элементы, а затем просто сдвинуть все элементы от этого места вправо и на освободившееся место поставить новый элемент. Таким образом водно уменьшить число сравнений элементов.
Если идти по строке слева на право и искать паттерн AXA или AA, где А - это любой символ, то можно находить центры палиндромов и уже от центров идти в обе стороны к краям определят максимальную длинну. Так по идее должно иметь сложность от O(N) до O(N*N) в худшем случае.
Размер кода не всегда показывает чистоту. Есть ещё требование что
бы код можно было легко расширять и поддерживать. И обычно это все через «пресловутые» паттерны реализуется, которые не добавляют краткости коду.
Как вариант можно данные выгружать не как есть, а по-xor-ит с чем то. И тогда в выгрузке не будет осмысленных данных.
Для, этого хватит просто возможностей sql, если данные слили из БД.
Сможет ли анализатор содержимого файлов такое детектировать.?
Можно ещё самолётов докупить :).
Тогда будет не ясно в каком он летит.
С рекурсивными запросами есть нюанс - ограничение на глубину рекурсии.
Для mssql глубина по-умолчанию 100, те можно так построить интервал размером не больше квартала.
А если нужно погонять что-то, что требует использования gui погонять.
Ну например игру на pygame запилить. Как тут с докером обойтись?
Шутка конечно, но:
4 пробела - это больше одного таба на 3 байта. В итоге примерно четверть кода исходников - это пробелы