mayton2019

Машинное обучение это вообще не про 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-тки. Это ведь ошибка аппликейшена вобщем-то.

В этой задаче всё нормально и никаких видимых проблем нету. Обычно индекс работает синхронно с обновлением основной таблицы (кроме редких типов индексов основанных на текстовом поиске).

Единственное что здесь избыточно так это сам ключ.
'328382164-audi-a4-2012-blue-WВA2UAF48H38K007347'
его копия будет лежать и в таблице и в индексе. Я-бы поискал какие-то закономерности.
Если вся таблица созавалась под audi - то стоит-ли держать еще признак рядом?

Если бы база была класса Oracle и ключ - композитный то я-бы разбил его на два-три подключа
и использовал-бы compressed index. Тогда марки машин можно было сжать и уменьшить объем индекса.

Практически эта задача звучит так. Создать копию файла с изменённой строкой. Такой подход к изменению текстовых файлов во всех языках и системах программирования.

Я думаю всё равно. С учетом облачных технологий - все больше задач уходят в облаки и локально что-то компилировать скоро не надо будет.

А слабый комп даже полезен чтобы оценить как слабый пользователь будет видеть к примеру landing page.

Топик тегирован "Базами Данных". Какими - чорт его знает.

Поэтому есть следующие коробочные решения. Cassandra, Redis, Amazon DynamoDb. Все они поддерживают дополнительное поле TTL и удаляют записи автоматически без участия разработчика.

По поводу подводных камней о которых пишет автор. Это всё очень плохо и почти не работает в боевых условиях. Пока бэкап данных делается в обычном плановом режиме - никто не знает о существовании всяких там левых файлов на сервере приложений. Грубо говоря все думают что состояние системы (state) лежит в базе и только в базе. Поэтому попытка размазать состояние системы по нескольким нодам вычислительной сети приводит к сложным и трудноуловимым последствиям.

Какой бизнес-смысл этих ограничений? Если поле массива должно хранить возраст человека (условно от 0 до 120 лет) то тогда надо создать свой тип (класс) и создавать типизированный массив.