mayton2019

Не указал предыдущий опыт работы. Вот - главная причина.

В настоящее время модем уже не нужен. Это морально-устаревшие технологии 2000х годов когда интернет пускали по сетям телефона или по коаксиальному кабелю телевидения. Вот для таких стеков и ставился модем. Более того. Такие квази-телевизорные сети работали очень хреново (у меня был максимум 25 мегабит) и еще и асимметрично. Тоесть скорость в upload была раз в 10 медленнее чем в download.

Сейчас вне нормальные провайдеры домашнего инета тянут ethernet (витая пара) до каждой квартиры. А модемы остались только у ваших бабушек.

Если обсуждать конкретно приложение ACDSee то чорт его знает. Вообще JPEG кодек управляется большим набором параметров (progressive, chroma subsampling) и это всё идет вне самого параметра сжатия.

Я думаю что после десятка пережатий картинка должна достигнуть некого стационарного состояния (аттрактор типа) и после этого уже не изменятся. Но достигать этого состояния явно не стоит.

А к автору возникает здравый вопрос. Для чего собственно надо что-то пережимать? В мире и так много электроэнергии тратится впустую. Майнинг крипты и прочее. Зачем еще добавлять безсмысленного нагревания атмосферы?

Я-бы сказал что пен-тестер - это должность весьма экзотическая. Кто тут в топике сидит? Готов спорить что все кто ни попадя и девопсы и PM-ы и тестировщики.

Вот пускай сюда пентестер зайдет и расскажет о себе. Только с пруфами.

Не совсем понятно о каких гарантиях тут идет речь. Когда база создается с нуля (таблицы еще пустые) то после создания таблиц (или во время создания) делаются contstraints которые описывают связи между таблицами и реакцию на delete/update. Типа

.... CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE
  RESTRICT...;

И после этого из базы нельзя удалять родительские ключи пока на них есть дочерние связи.

Есть европейский закон или право. Право быть забытым ( https://en.wikipedia.org/wiki/Right_to_be_forgotten ) или еще вариант GDPR.
На основании его гражданин может попросить google или другие поисковые системы удалить сведенья о нем при поиске и поисковик обязан эти данные добавить в такой-себе стоп-лист чтоб не гуглилось никогда. Как быстро они этот запрос отработают - я не знаю. И действует это кажется для Европы.

Для РФ вряд-ли кто-то будет рассматривать такое обращение. Но можно попробовать.

Машинное обучение это вообще не про Python. Это больше к мат-статистике и обработке больших данных.
Задачи - классификация, регрессия и кластеризация e.t.c.. Алгоритмов и названий очень много. Некоторые из них могут повторяться в вариациях или иметь неточные русские переводы.

Фреймворк Apache Spark имеет следующий классификатор алгоритмов: https://spark.apache.org/docs/latest/ml-guide.html
Ignite - вот такой : https://ignite.apache.org/docs/latest/machine-lear...

По поводу Python или Scala. Знающие маш-обучение таких вопросов вообще не задают. Для специалистов язык - вообще не имеет значения. Язык в данном контексте это как приложение калькулятор или spreadsheet. Это вспомогательный инструмент. Собственно эта наука вообще не про программирование. А про наблюдение глазами за процессом обучения и корректировку мета-параметров.

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

На собеседовании тоже будут спрашивать про опыт. Что делал. Какие методы знаешь. Язык - опционален. Могут спросить - но будут предполагать что 99% ты выучишь новый язык если надо.

Посмотри модель EAV. Может поможет.

Надо описать в документации все методы и endpoins. Лучше в открытом формате типа Swagger/OpenAPI. И показать их заинтересованным лицам. Тем кто будет этот API использовать. Вот если у них не будет вопросов - значит все понятно и хорошо. Если они будут говорить WTF - то надо все эти вотафаки аккуратно записать и исправить.

Посмотрел что такое ciscopacket tracer. Это рисовалка диаграмм наподобие Microsoft Visio.

Непотятно какой это язык? Go что-ли? Тут ошибка не про работу с AWS S3 bucket а просто про то что сериализация структуры params почему-то на выходе выдала НЕ-Xml строку. А ожидалась Xml.

Вот тут пишут как структуры сливать в XML

https://www.golangprograms.com/golang-write-struct...

Если это одно-пользователькая система то ее можно попробовать переписать на Access. Но в задачах с Excel обычно самое слабое звено - это пользователи. Они слишком любят Excel и никогда не хотят ничего другого. У меня был опыт работы с немецким банком. И я заметил что у них это прям национальная особенность. Любые записи. Расчеты. Они делают в Excel. Очень часто для них Excel является стандартом обмена. Мы грузили Excel в реляционные базы и выгружали потом обратно. Уже в другом виде. Вот такой был странный подход.

Сможете-ли вы убедить пользователй или переобучить их - вот в чем вопрос. А сама задача выглядит несложной.

Работы есть. Многие компании (Intellias, Epam) задекларировали больше дохода и сделали больше найма.
Есть риски связанные не с Украиной а с иностранными заказчиками. Они, зная о ситуации рассматривают
it-шников с Украины как рисковых. И стараются формировать команды где для каждого есть backup. Или есть
специалист который дублирует знания и способен заменить в случае релокаций.

Судя по тексту ошибки - это нарушение констрейнта первичного ключа "assignment_pk".

Когда ты вставляешь что-то в таблицу с primary key то должен всегда проверять что ID уникален.

В данном случае этот запрос неверен. Выдает неуникальный сет IDs.

SELECT $1, task_id, item_id, NULL, completed, result, 'QUEUE', NULL
FROM assignments
WHERE assignments.id = $2

Если докер является частью вашего облака AWS/Azure - то надо читать их документацию. Обычно постащик облака всегда продает какой-то сейф (vault) для хранения секретов. И есть API через который можно читать содержимое этого сейфа.

Был в десятке разных компаний. У всех - по разному.
Бэкап это по большей части организационный вопрос. Главное что в этом топике вам никто правильно не ответит.

Нужно спрашивать ваш бизнес о требованиях к базе. Например:

1) Как долго бизнес согласен ждать восстановления? Это влияет например на стратегию делания инкрементальных кумулятивных и полных бэкапов для БД. Разумеется все БД - в режиме arhivelog/wal.
2) От чего мы страхуемся? От физических повреждений. Или еще нужно предохранится от неверно поставленного обновления на базу. Тут - надо прикупить дополнительных дисков или магнитных накопителей.

Самое главное что у вас должны быть учебные тревоги. Тоесть вы должны реально откатать бэкап+восстановление хотя-бы несколько раз. Иначе то что вы делаете будет фейком. Часто видел такое. Бэкап делает какой-то сисадмин средствами Акрониса например. Но этот сисадмин и понятия не имеет как работает Oracle и что вообще нужно предварительно подготовить чтоб бэкапные файлы не стали ненужным балластом.

Для разработчика ты можешь поднять Postgres, Redis, Mongo в Docker. Это делается (почти) в 1 строку.
Или если тебе нужен ансамбль из нескольких сервисов тогда - kubernetes.

Облачные провайдеры дают бесплатный аккаунт только на 1-2 месяца а потом все равно надо платить. Кстати при глубоком изучении тех-же AWS/Azure/GCP я все таки советую оплатить акк. Я замечал что есть некоторая часть проблем которая принципиально не устраняется в бесплатных учетках.

Мне кажется надо собирать информацию там где она возникает. Если ошибки сыплет приложение то и оно должно генерить лог файл типа http-statuses.log:

200
403
500

и дальше графана его нормально проглотит и нарисует вам pie-chart или что там еще надо.

А бедный nginx тут вообще не при делах. И не его задача генерить 500-тки. Это ведь ошибка аппликейшена вобщем-то.