mayton2019

Можно сделать базовый класс сущности без пароля. И от него унаследовать все+пароль.
Дальше - дело техники.

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

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

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

Мне удивительно что хакер не умеет сортировать данные. Как же он до этого работал?

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

К сожалению комметарии всегда не формализованы. И разработчик не являясь техно-писателем не может их написать настолько грамотно чтобы они представляли интерес для заказчика. Поэтому для заказчика пишутся отдельно сопроводительные документы по софту. А комментарии в коде разрабы пишут для самих себя типа "todo: оптимизировать".

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

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

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

И процедуру хипифай проверь отдельным тестом. Для всех i должен работать инвариант:

heap[i] >= heap[i*2 + 1]
heap[i] >= heap[i*2 + 2]

А зачем во всю таблицу прописывать магическую дату которая к тому-же равна какому-то NOW?
Уж лучше оставить null. Так хотя-бы места в индексах не будет занимать. Да и вообще.. null в базах несет особый смысл.

Вобщем создатели диалекта MySQL были по своему мудры и не дали возможности ленивому разработчику просто так мусорить в таблицах.

При разработке docker не ставились задачи - догнать bare-metal. Главная задача - виртуализация и оркестрация.
Если у вас нет таких задач то возможно и docker вам просто не нужен. Ставьте софт на железо и
не будет таких вопросов.

Если разрешать качать back-скрипты - то это был-бы взлом всех веб-ресурсов.

Мне кажется что если не решать эту задачу только регулярками а сделать такое.
- проверить что строка состоит из 4х чисел разделенным точками
- проверить что каждое число в диапазоне [2..255] (проверять уже как Integer)
то тогда функция проверки будет простая и наглядная. Это для кейса 10.80.212.195.

Для масок подсети и IPBlocks единая функция проверки все равно безсмысленна - ведь на следующем уровне API
нам надо различать классы { IP, IP+Mask, IPBLock } и нам выгодно сделать 3 функции-предиката. Тем более что классы результата различны.

Обычно на Go пишут микросервисы. А они не должны умирать. Как раз совсем наоборот должны работать очень долго.

1. Без кода - непонятно. Без стектрейса непонятна ошибка. С чем вообще воюем.
2. Загляни внутрь jar-ника. Там должны быть в полном составе все зависимости (в том числе и транзитивные).
3. Начинай читать книгу Hibernate In Action.

Зачем все фолдеры удалять? Там-же вроде как есть каталог Администратор. Будете логонится десктопом - он вам пригодися. Что там еще... Default User. Это формочка для печенья. Чтоб новых создавать.

Вот как тут пишут https://www.w3schools.com/SQL/func_mysql_case.asp через SWITCH CASE...

Есть публичный API для английской википедии. В виде семантической сети (RDF/SparkQL).
Можно начать с него искать. И там уже сделать свой API.

Тут - совокупность проверок
1) strings.Contains - даст положительный результат
2) по бокам от найденного Contains должны стоять не-алфавитные символы.

P.S. Это можно делать регулярками но я-бы предложил мой метод. Он кажется легче в понимании.

Разделение на локальный Git и Github здесь вообще не в тему т.к. оно не добавляет никакой информации.
Такая-же схема будет у любого разработчика который работает в команде.

По поводу разделения на DEV/QA/Stage/PROD.... e.t.c.

Эта схема уже создана. Она называется GitLab или GitFlow я уже не помню. Вобщем каждый env имеет свою ось разработки (бранч) и в процессе CI/CD теги или бранчи просто двигаются слева направо по этим осям. Всё остальное делается триггерами на CI/CD.

Насчет data anlytics не скажу. Но вот на https://databricks.com/ я находил бесплатные курсы по инжерении bigdata. Если повезет - там еще акции всякие прилетают.

Я думаю что главное отличие - это способность осуществлять соединения (JOINS) по любому полю.

Попробуйте сджойнить две таблицы Cassandra по любому полю. Хрен вам. Это считается неверным дизайном. С точки зрения идеологии Cassandra вы должны были дизайнить модель так чтобы таких джойнов (или таких мыслей) у вас никогда не возникало. Грубо говоря - хотите какую-то выборку - подготовьте ее заранее на уровне архитектуры. Типа мат-вью.

Да что там джойн. Там даже выбрать по предложению WHERE не всегда можно. Тоже считается антипаттерн. В базовом SQL синтаксисе это не сработает. Надо добавлять опцию allow filtering что как-бы говорит нам - что мы вышли за рамки обычного запроса. Захотели птичьего молока...

А вот для Oracle/PG/Mysql/MSSQL - получить джойн по любому полю с любым - сущий пустяк. Хотя дать смысл этому джойну будет сложнее. Джойнить величины с величинами.

Хотя в последнее время различия между реляционными и прочими - стираются. Это как парадигмы в ЯП. Лет 20 назад все говорили о парадигмах. Сейчас - многие языки считаются мультипарадигменными. Тоесть спор сам по себе закрыт на уровне определения.