mayton2019

Первая линка возвращает

$ curl --head https://vm.tiktok.com/ZMNv1gmUj/
HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html; charset=utf-8

Во всех языках программирования есть библиотека поддержки дат. И во всех этих библиотеках есть функция расчета количества дней между двумя датами. Например

days(currentDate() - date('0001-01-01'))

Далее - четность-нечетность.

Тоесть от Рождества Христова до текущего дня. Вот такая вот декомпозиция задачи на простые функции.
А автору - жирный минус за то что он не может нормально постановку сделать. Какая-то гумнанитращина.
Нельзя-же так! Инженер должен уметь владеть языком функций.

И еще забыл указать какую футболку он одевает в условно первый день.

Словами решать эту задачу - категорически не интересно. Смотрите фунции работы с датами. Там есть свои нюансы. Есть разные календари и прочее.

Лет 10 назад мне попала в руки база абонентов мобильного оператора. Как раз в формате Cronos. Но открыть я ее не смог приложением. Дело в том что этот формат использует симметричное шифрование данных. Как архиватор RAR. Без знания пароля - безнадёжное дело.

Поэтому Python здесь не поможет. Надо первым делом понять с чем мы имеем дело. Открыть файл приложением клиентом и убедится что он хотя-бы не шифрован.

Возникла проблема - требуется писать программы быстрыми, чем быстрее - тем лучше.

Ты решаешь какую-то искусственную проблему. Стандартные компоненты пишет целая корпорация и анализируют тыщи тестировщиков. Сомнительно что ты сможешь написать нечто даже близко подходящее по возможностям.

Кстати я тебе предлагаю как всегда пойти от формализма - просто перечислить фичи которые ты собираешся реализовать в виде документа. И я думаю где-то на 500-й фиче ты забросишь это дело.

Спецификация - сильная вещь. И многие юные амбициозные кодеры беруться писать нечто неспецифицированное и в результате создают гоммункула который никому не нужен или создают что-то ограниченное.

Яркий пример - создатели своих DBMS. Тыщи их. Но никто не в состоянии довести разработку даже до альфа-версии. А уж о том чтобы ее показать на презентации - вообще и речи нет.

Такие задачи обычно делают на языке Си и на микро-контроллерах или на хитрых операционках типа RTOS.

C# с его уборкой мусора может внести в поток большие погрешности. Ну вобщем зависит сильно от задачи. Для игр должно хватать шарпов. Для чего-то серъезного скорее всего нет.

А так?

<p>${message}</p>

Для особо важных архивов - создавай parity check file https://manpages.debian.org/testing/par2/par2creat...

Если какой-то нейтрино повредит 1 битик то это тебя спасет.

Вот тут рабочий пример дают

https://developers.google.com/drive/api/guides/man...

Во первых хочу заметить что отладка и оптимизация это разные вещи. Отладка - debugging это когда мы step-by-step исполняем императивный код и наблюдаем состояние переменных. Режим отлалки был в PL/SQL но им пользоваться было настолько неудобно что никто из моих коллег никогда его не включал.

Оптимизация производительности - это целая сложная тема. По ней написаны толстые книги. Для каждой БД своя. И вобщем Дмитрий верно сказал. Команда explain - это просто первый шаг к оптимизации. И дальше 100 дорог в 100 направлений. Сис-парамтеры. Индексы. Партишенинг. Хинты. И много много прочего.

Насколько я помню - это использовалось в Hadoop/BigData. Это когда вам надо посчитать допустим среднее значение поля по тера-байтному файлу - вы не скачиваете все данные к себе а вы транслируете логику туда, ближе к нодам-воркерам и они уже расчитывают среднее значение локально в своей сверх-быстрой сети и уже вам отдают результат.

Во фреймворке Spark это скрипт spark-submit. И он как раз это и делает. Передает jar файл с логикой (или python-файл) на узел-координатор.

Промышленный дизайн. Там не надо уметь рисовать. Надо просто понимать на каком уровне окна или двери установит ручку. Или какой высоты должен быть мусорный ящик.

По поводу пикселей и прочее. Их ценность определяется просто зрительской симпатией. Их должно это радовать. Покажите ваши пиксельские работы аудитории.

В современных БД практически нет ограничения на длину строк varchar. А для блобов (BLOB) там специально созданы условия чтоб аттачить толстые файлы произвольного размера.

Когда-то давно реляционные БД ограничивали длину строки varchar. Это было связано с блочной организацией дисковой памяти. Например в Oracle varchar2 был максимум 4000 байт. Потом где-то с 12 релиза его можно растянуть до 32к. Ну а для XML/JSON типов там создается специальное поле которое является просто подтипом BLOB но имеет в виду что лежит например JSON. Констрейнт короче.

Есть специальные dbms такие как Mongo, CouchDb, Tarantool. Они специально создавались под JSON. Обратите на них внимание.

Эта неадекватная транзакция называется "выбросом".

Есть много методик фильтрации выбросов. Но я помню только ящик с усами. Это что-то вроде биржевой свечки. Только вместо цены открытия и закрытия в ящике отмечают 1-3 квартили. И на диаграмме этого ящика строится межквартильный размах, как функция этих квартилей. Обычно с линейным коэфициентом. И далее четко видно что выбросы выходят за границы этого размаха.

Но это не точная методика. Она может случайно убить и нужные транзакции. Поэтому надо внимательно смотреть на данные и проверять.