German Jet

На ваш вопрос невозможно корректно ответить. Каждая СУБД обладает своими архитектурными особенностями и по сути является платформой, т.е. многие полезные вещи уже реализованы. Т.е. можно сравнивать две конкретные СУБД и рамках решения конкретной задачи. Как СУБД для ИС уровня предприятия, Oracle очень хороший выбор, т.к. обычно в таких системах нагрузка 50 на 50(50 запись\50 чтение). И в силу архитектурных особенностей Oracle(реализация транзакций и блокировок) справляется с такой эксплуатацией на ура. Плюс БД еще надо администрировать, заботиться о сохранности данных после сбоя(бэкапирование), туча функций и объектов для реализации бизнес-логики .... короче много всего что нужно делать, и это уже реализовано в Oracle. И как бонус, Oracle более лоялен к рукожопости разработчиков, которые считают, что все БД одинаково работают и устроены. Если данных много и надо быстро их обрабатывать, можно посмотреть в сторону Exadata. Более подробно об особенностях можно почитать в документации. А во всем остальном нужно смотреть под конкретную задачу. Самый большой минус- это стоимость.
З.Ы.: И от себя лично добавлю, на заре карьеры я работал с MS SQL и возненавидел эту СУБД, как раз из-за реализаций транзакций и блокировок, и помогли мне в этом прежние разработчики. В MS SQL блокировки на уровне строк, но реализованы в общем пуле- общий пулл блокировок- это минус скорость(общий пулл надо блокировать, для записи или чтения этих блокировок) и плюс память. И чтобы не загружать особо сервер, прежние разрабы реализовали логику так, что процесс проходил мелкими транзакциями, конечно с коммитами. И были такие прецеденты, что данные удалились, а в другую таблицу не встали из-за ошибки в приложении. Потом дедлоки, это вообще отдельная тема, и приходилось разруливать изменением структуры данных, чтобы пользователи работали, только со своими данными. Короче вспоминаю, как страшный сон. Зато при разработке другой ИС где было решение взять Oracle как СУБД, через призму прошлого опыта, для меня было большое открытие, что там не будет такого гемороя, как с MS SQL. Конечно, может быть MS SQL сейчас сильно изменился в лучшую сторону, но осадочек у меня остался.

Многие работодатели сейчас утверждают, что Савина уже недостаточно и требуют более специфичных знаний. Одна из хороших книг - Станислава Куликова «Тестирование программного обеспечения. Базовый курс.» (распространяется бесплатно).
Также один из работодателей мне советовал книгу Джеймса Уиттакера, Джейсона Арбона и Джеффа Каролло "Как тестируют в Google".
UPD.
Наткнулся на прекрасную статью о литературе для тестировщиков и не только. Там, в том числе, книгу "Как тестируют в Google" считают неоправданно рекомендуемой. Советую ознакомиться в первую очередь с этим списком.
okiseleva.blogspot.com/2014/02/blog-post_6.html

"window.title": "",

Предлагаю обобщить проблемы в одну и решить её.

Обобщенная проблема называется дисциплинированность. Придерживание дисциплины - сложная работа для силы воли, и поэтому её сводят к формированию привычек и жёсткому следованию и слежению за исполнением того, что составляет привычку.

Вам нужно привить себе привычку жёсткого ограничения времени на любую задачу.

Мытьё посуды, ремонт чего-то, чтение книги, кода, контрибуция в пет/опенсорс проект, семья - для всего нужно ввести правило, уделять не менее N времени в день/неделю/месяц.

Привычку нужно вводить мягко и плавно, начав со взятием под контроль и слежением за рабочим днём, потом расширив обзор на день, а через несколько недель можно уже брать под контроль неделю.

Может уйти и больше времени, потому что привычка, поддерживающая дисциплинированность требует называть вещи своими именами и не обманывать себя.

Производительность и занятость часто путают с продуктивостью и результативностью, и если вам очевидны симптомы того, что вы часто путаете первое со вторым, то значит пришло время остановится и:

1) вернуться к азам - перечитать основополагающие для вас книги, например, для меня это Совершенный код, Экстремальное программирование и Тайм-менеджмент для системных администраторов; если есть подозрения, что вместо паттерна вы используете антипаттерн, то пришло время для тотальной работы над ошибками;

2) начать записывать каждое решение задачи за день, самое важное - указывать время начала и время конца, если вы не ведёте ежедневник (в любом виде, достаточно весьма обобщенного лога деятельности за день);

3) отдых и перерывы (кофе-брейк, перекур, переменка) отмечать тоже обязательно, и важно не путать отдых и паузы. Отдых сотредоточен на восстановлении организма после физического или интеллектуального стресса, в то время как брейки сотредоточены на недопущении вхождения в поток и на чередовании видов деятельности, что приводит к экономии ресурсов, выделенных на день.

Для интеллектуальной деятельности и инженерного дела, связанного конструированием, проектированием, согласованием поток вреден, и нужно следить за тем, чтобы не забывать выныривать. Чередование видов деятельности и задач, позволяет медленнее накапливать стресс, потому что смена деятельности даёт отдых разным отделам мозга и частям организма в целом в разное время.

Проблема зарывания в работу/задачу решается введением строгого ограничения на продолжительность работы. Поставьте на своем смартфоне беззвучные и без вибраций будильники с перерывами в час+8 минут со смещением 5 минут к последующему будильнику. Позже оптимизируете под себя, просто важно ввести привычку поставить все на паузу, выкинуть из головы все на бумагу или в текстовый файл и 5 минут подышать свежим воздухом, выпить чаю, etc.

Проблема с жадностью выделения времени на оптимизацию работы решается обычным счётчиком 1-2-3. Если вы столкнулись с проблемой третий раз, то вы отдаете себе отчёт, что налицо закономерность, и поскольку математически доказано, что оптимизация сейчас сэкономит время, то вы спокойно в ежедневнике выделяет время на сегодня на оптимизацию.

Когда вы начнёте прививать привычку, вас может поначалу демотивировать количество времени, которое вы тратите на тривиальные задачи, и количество свободных часов в будний день. Но вы должны понять, в этом и заключается мощь и сила дисциплинированности: время в сутках строго ограничено, физиологические и интеллектуальные ресурсы на день строго ограничены, каждый день вы в магазине, где вы и покупатель, и продавец, каждый день у вас торги, tradeoffs, что я сделаю сегодня, а что я откладываю, если я дело откладывал всю неделю, то почему не хватает времени будет очевидно, если вы ведёте лог, учёт трат времени а своем ежедневнике. Только так можно понять, то ли задача неадекватная, то ли просто месяц для этой задачи неподходящий.

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

Для того, чтобы не перерабатывать, нужно делать лишь самое необходимое именно сейчас, чтобы брать как можно меньше рисков в текущий момент, откладывать принятие решений на как можно поздний срок - но тут надо уметь называть вещи своими именами - одно дело, когда вы избегаете риска, другое дело, когда вы избегаете ответственности. Если у вас нет ограничения по времени, что ещё может заставить вас попросить помощи или начать работу над ошибками, валидировать свои знания, привычки самого себя?

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

У вас должна быть цель стать профессионалом в области. Потому что только профессионал может выбирать, с кем работать, где работать, над чем работать - над крупными проектами для правительств, над банковским софтом, над веб-проектами или над играми.

Вот это будет правильная установка. А что учить и в каком порядке вам никто не скажет, потому что требования меняются, возможности устроится на работу у всех разные, неизменно только одно - желательно знать все и вчера. Именно с этой установкой рисуются абстрактные Programming paths, но толку от них не будет никакого, если вы не сможете обобщать знания и не будете постоянно работать над строительством своего дерева знаний. Главное - пополнять свои знания концепциями, из которых потому выводятся базовые шаблоны, шаблоны проектирования, а из них, в свою очередь, архитектурные шаблоны, методология разработки, и непосредственно связь с рынком, экономикой, психологией и прочим, и так далее. И эти концепции не только в книгах по разработке ПО, их много в теор вере, дискретной математике, физике, которые дождаться в голову только в процессе получения высшего образования, системно.

Любовь к учению - единственное, что может поддерживать на пути, потому что путь очень долгий. Многое будет непонятно и с первого раза, и со второго. Иногда и с третьего, потому что вы на самом деле не поняли базовые вещи. Или выбрали неправильную книгу. Или начали читать правильную книгу слишком рано. А узнаете вы расхождение между объективным знанием и собственным все равно не раньше, чем столкнетесь с проблемой на практике. А по-другому никак.

Что вы можете сейчас сделать - взять прицел. Конкретно сформулируйте профессию и специализацию. Оптимизируйте процесс полученния знаний: как бы не ругали образование в ВУЗах СНГ, все же это нехилая экономия времени, если вы сразу будете получать профильное образование.

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

А на самом деле надо. Вы должны получать удовольствие от получения знаний, потому что иначе вы не сможете сделать игры, которые могли бы приносить новый опыт игрокам. Чтобы транслировать новый опыт через генераторы опыта - игры - нужно уметь и любить этот опыт (субъективный и эмоциональный) получать, и представлять, как его давать людям. Разработка игр - всего лишь автоматизация этого процесса.

Так что, запасайтесь попкорном и начните с языка Си. Освойте структурное программирование. Алгоритмы, структуры данных. Архитектуру компьютера, ОС. Не торопитесь как можно быстрее неправильно понять как можно больше вещей за кратчайший промежуток времени. Перечитывание и практикуете, пока не станет понятно так, что сможете научить кого-нибудь другого. Макконнелл, Роберт Мартин, Кент Бек, Эрик Эванс, Мартин Фаулер + 1 год дополнительного быдлокодинга на java и c# и c++ и у вас появится понимание ООП, ФП, типовые устройства моделей памяти и сборщиков мусора. Ещё за год научитесь писать настоящий ООП код, читать чужой код, даже если он написан в процедурно-макаронном стиле как книгу. Но надо ли вам эти три скучных года, потерянных полностью для личной жизни? Не проще ли получить solid knowledge и постепенно получать практику в среде опытных специалистов?

Подытожу: становитесь профессионалом, на это у вас уйдёт ~10 лет после введения привычки учится в свободное время. Периодически смотрите на требования вакансий и составляйте себе древо знаний, которое хотите получить.

У меня была подобная задача.
Нужно было «имя отчество фамилия» преобразовывать в «Имя Отчество Фамилия».
Решил через расширение стандартного класса `class String`.
Метод `#capitalize_words` разбивает строку на массив из слов и проходит по каждому слову и делает ему «капитализацию».
После этого собирает массив в исходную строчку.

class String
  # @see String#capitalize
  def capitalize_words(separator = ' ')
    words = split(separator).map(&:capitalize)
    words.join separator
  end
end

Ниже тест `RSpec` для метода, на всякий случай.

describe String do
  describe '#capitalize_words' do
    context 'with word' do
      let :one_word do
        'foo'
      end

      it 'return capitalized word' do
        expect(one_word.capitalize_words).to eq 'Foo'
      end
    end

    context 'with words' do
      let :words do
        'foo bar'
      end

      it 'return capitalized all words' do
        expect(words.capitalize_words).to eq 'Foo Bar'
      end
    end

    context 'with custom separator' do
      let :words do
        'foo$bar'
      end

      let :custom_separator do
        '$'
      end

      it 'return capitalized with custom separator' do
        expect(words.capitalize_words(custom_separator)).to eq 'Foo$Bar'
      end
    end

    context 'with empty' do
      let :empty do
        ''
      end

      it 'return empty' do
        expect(empty.capitalize_words).to eq empty
      end
    end
  end
end

Язык действительно интересный и легкий. Есть русская документация в elixir school и достаточное количество библиотек. Есть русское сообщество в телеграмме @proelixir Есть курсы elixir и большое количество книг тоже на русском. Язык развивается, пусть не так быстро, но от того возможно качественно.
Его активно используют за бугром, там найти работу не составит труда. У нас достаточно проблематично джуном. Но я бы сказал что джуном берут только в офис практически везде, поэтому вам должно либо повезти с местом жительства, либо вы должны будете продвинуть его на текущем месте работы.
Я на чистом эликсире писал парсеры, многопоточность выручает очень сильно.
Рассматривать elixir без phoenix не имеет смысла. Phoenix имеет смысл рассматривать только как очень быстрый микросервис. Как вариант для websockets. Вполне может выстрелить LiveView но до этого надо дожить. В большинстве компаний, на сегодняшний момент в России, предпочтут go вместо elixir.
В купе за 10 лет он только разовьется, просто в России его еще толком не заметили.
Как основной язык, возможно, но только там где уже работает erlang. Поэтому лучше потихоньку изучать как добавочный и прикручивать его там, куда go еще не прикрутили)
Мышление меняет очень сильно, после пары месяцев работы с ним будете смотреть на другие языки уже совсем иначе, но точно не хуже!

@Repository
class ShipRepository {
 
    @PersistenceContext
    private EntityManager entityManager;
 
    @Override
    public List<Ship> findLimitedTo(int limit) {
        return entityManager.createQuery("SELECT s FROM Ship s ORDER BY s.id",
          Ship.class).setMaxResults(limit).getResultList();
    }
}