mayton2019

Вопрос состоит из двух частей.

1) Можно ли на java сделать микросервис? Ответ - да. Есть много готовых шаблонов типа Spring-REST
которые являют собой почти готовые микро-сервисы.

Например https://start.spring.io/;

2) Генерировать XLS со сложной структурой. Тут не знаю. Насколько сложной? Что там? Вся база знаний о планете Земля со времен Шумеров? Ну для работы с XLS есть библитечка apache poi

https://poi.apache.org/

Это задача выходит за рамки баз данных. Здесь идет речь уже о языке программирования и БД.

Вот у меня где-то есть код, который загружает BLOBS в таблицу используя Java JDBC.
И есть код, который выгружает.

Ну сигнатурки - это-же только часть вирусов.
Как быть с новыми заражениями на которых еще нет сигнатур?

По хорошему нужно очень глубоко анализировать контент бинарных выполнимых файлов.

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

Фактически когда мы говорим Linux - мы подразумеваем не саму ОС а ядро. Ядро физически лежит в каталоге

/boot

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

Существует много техник взаимодействия между процессами. Основное ключевое слово для поиска - IPC (Inter process communications). Там дальше надо выйти за границы Питона потому что эти техники немного разные для Windows/Linux. Некоторые похожие (Network Sockets).

Если надо просто вести учет строк в PIPE между процессами то можно так

bzip2 -d -k -c very_long_file.txt.bz2 | pv -l > /dev/null

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

Вот тут примеры и синтаксис пишут

https://wiki.postgresql.org/wiki/UPSERT

Маленькая ремарка.

В наше время такая метрика как количество процессоров (vCPU) - это маркетинговый обман.
Скорее всего продаются виртуалки. И когда мы спорим и обсуждаем на них цены - надо обсудить
каким образом облако их выделяет и вам предоставляет. Я думаю что режимов виртуализации
может быть много. Ядра. Треды. Процессы в докерах-кубернетисах - это тоже
в некотором роде виртуализация.

Обычно мозговые игры с шифрованием-дешифрованием выглядят так.

1) Вы пытаетесь представить открытый текст. Например он может начинаться со строки "Привет".
Или мы можем заведомо знать о том что в открытом тексте есть русский или болгарский или польский
язык и исходя из его свойств (гистограмма или биграмма) проверять гипотезы.

2) Вы начинаете перебирать все известные методы доисторической криптографии
- Шифр Цезаря (Виженнера)
- Квадрат Полибия
- Пасьянс Шнайера (колода карт)
- Палочки-веревочки и прочее
и последовательно применять их до тех пор пока не получим ответ.
Разумеется все это надо делать автоматизированно иначе это похоже на брейн-фак. А кому нужно
факать себе мозг да еще и безплатно?

В блоге Романа Душкина есть много науч-попа на эту тематику. Практически по всем темам.

3) Если к открытому тексту пременен современный метод криптографии типа AES/Blowfish
то пишите - пропало. Нет надежды на нахождение открытого текста. Можете обещать любую
денежную премию. Эти шифры слишком серъезны чтобы их пытаться угадать в хабре.

Да и ключом в таких шифрах обычно идет не парольная фраза а вполне себе длинный вектор
ключа и инициализации (256 бит например).

Это не будет работать. Base64 использует специальные символы padding в конце файла чтоб указать
какой из символов терминирует поток байтов.

Поэтому если ты просто текст base64 тупо разрежешь на 2 части то эти две части станут невалидные
с точки зрения кодировки base64. Надо примерно так

input string => base64decoder => bytearray => split_3500 => encode_each_array_base64 => save_to_files

вот на таком выдуманном всевдо-коде.

Надо ли учить PHP и MySQL?

Считается что PHP/MySQL относятся к "морально устаревшему" стеку технологий (LAMP (lin+apache+mysql+php).
(Я думаю что знания MySQL полезны. Это лучше чем "никакой" SQL.)

На смену ему должен был выйти лет 7 назад MEAN (mongo+nodejs+....e.t.c.).
Мне уже поздно переходить в MEAN. Слишком стар. Но я-бы перешел просто потому что это
более новый взгляд на старое. Новое - всегда лучше чем старое.

Учу веб-разработку для фриланса - делать сайты на заказ (знаю, что рынок супер конкурентный). По книжкам выучил JS, HTML, CSS, базовый jquery (*тут могла быть ваша шутка*), к фреймворкам и библиотекам пока не приступал.

По поводу "размещать сайт". Это вообще не твоя основная цель. Цель - набить руку в системе.
Для этого тебе не нужно иметь свои хостинги. А нужно просто влиться в систему которая уже
их делает в режиме конвейера.

По поводу "выучил по книжкам". Ты не выучил еще ничего. И дело даже
не в техниках верстки. А ты пока не понял как работает процесс коллективной разработки софта.
Это сложно. Это интересно и эффективно. И ты будешь эффективнее в команде а не во фрилансе.
Работа в команде - это не только код. Это согласование ТЗ. Документирование.
Скрам-процессы. Корпоративная этика и кодекс поведения. Это как лак для дерева.
Ты - пригож для всех корпораций после этого. А во фрилансе хоть 40 лет просиди.
Никто характеристики не даст и не впишеться.

Поэтому лучше пойди в корпорацию. Покрутись несколько лет. Получи своё видение. И потом
уже во фриланс если будет желание.

Хочу понять, насколько глубоко надо лезть в бэкэнд

На этот вопрос сложно ответить. Ты скорее сам почувствуешь. Опять-же после опыта в корпорации.
Кстати и развиваться можно внутри корпораций вполне себе хорошо. И курсы и тренинги и сертификация.
ИЧСХ тебе корпорация их и оплатит.

Очень много. Практически все современные NoSQL-in-memory-dbms используют хеш-таблицы в каком-то варианте.

Хеш-таблицы являются частью механизма буферного кеша (страничного кеша) в дисковых БД. В Oracle, Postgres e.t.c.

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

Дисковые файловые системы могут использовать хеш-таблицы (в зависимости от настроек). Как хранить списки файлов в директориях. Там кажется выбор есть. Дерево или хеш-табличка.

В простейшем случае ты можешь сделать такую табличку

b'\x01' => '01'
b'\xff' => 'ff'

Где одному байту будет соотвествовать 2 символа.

Или можно разбирать 1 байт на 2 части по 4 бита и для каждого из них ставить в соотвествие одну
шестнадцатеричную цифру.

Ну и API-ев богатое множество должно быть.

По поводу твоих экспериментов с utf-8. Там есть запрещенные комбинации байтов. Потому
не любой рандомный массив байтов обязан преобразовываться в символы.

В SQL - много таких особенностей. Тоже самое с group by и оконными фунециями. Надо много повторяющихся expressions написать.

Попробуй еще так написать.

WITH HT AS (
 SELECT `product_id`, MD5(`value`) AS myhash
  FROM modx_ms2_product_options
  LIMIT 10
)
SELECT * FROM HT WHERE `myhash` = 'e59253548ffcb090ecc0cd0944afd27f'

Да может. Мобильные телефоны используют уже обученные модели для коррекции лиц.

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

Такое связывание специфично для Java-фреймворков а не для языка С.

Я-бы предложил обсудить вопросы безопасности. Что будет если пользователь вызовет функцию которую ему нельзя вызывать? Как мы вообще ограничиваем пользователя? Стоит-ли такая гибкость получаемого удобства? Может лучше пойти классическим путем? Перечислить все возможные варианты действий явно и в switch-case обработать?

Сравнительно недавно в Кафку завезли новый стандарт кворума на основе Raft-протокола. Это означает что Смотритель зоопарка будет скоро не нужен и его можно будет выкинуть нафик. А все ноды Кафки будут решать кворумные вопросы самостоятельно.

Тут надо сезон "разлохматить" на 4 входа. Обычно НС не работают с текстовым вводом. Поэтому
будет во входном слое 6 входов типа:
- area
- AC
- isSummer
- isWinter
- isSpring
- isAutumn

Всем сезонным факторам присваивается нолик на входе кроме текущего сезона.
Там можно дать единичку. Для признака кондиционера тоже можно брать 1.0 если он есть.

Дальше можно искать решение в виде например однослойной сети. Я-бы пошел от простого.

И данных нужно побольше. Чтоб хотя-бы была выборка учебная и контрольная.

Нормальный Б/У десктоп будет лучше чем все эти Распберри и ардуинки. Я не понимаю чем там автор хочет
заниматься но эти все просто несерьезно. Любая верстка - предполагает хорошую клавиатуру а работа
человека за столом - предполагает нормальный монитор. Все эти телевизоры и джойстики и блютус-игровые клавиатуры - дадут вам билет в хронические заболевания глаз, шеи и поясницы.

Работать нужно засучив рукава а не дурачится.