DollyPapper

Ничего нового не выдумали

* шареная память
* пайпы
* сокеты
* надстройки над сокетами (TCP)
* файлы

Ужасный pfsense на самом деле ок. С прокладкой обычно проблема бывает.

К сожалению, чтобы Вам что-то посоветовать - необходимо узнать Ваш личный "фундамент". Хоть указанная Вами книга и будет полезной (даже с учетом того, что она писалась для MySQL версии 4.х, фундаментально как в СУБД, так и в SQL и в конкретном синтаксисе MySQL последнее, наверно, десятилетие, ничего не менялось), я бы посоветовал следующий алгоритм обучения:

1) Знакомство с основами реляционной алгебры, нормальными формами и реляционной моделью. Без фанатизма, прочтение и осознание статей даже на Википедии хватит за глаза.

2) Знакомство с спецификацией SQL2008. Опять же, без фанатизма. В любом случае, работать Вы будете впоследствии с определенным диалектом языка.

3) Выбор диалекта языка. Подбор литературы (практически любой, за исключением книг из серии "{0} для чайников" и "100 и одно решение для {0}"). На этом этапе важно определиться также с инструментарием, который Вы будете использовать в дальнейшем. Для начала подойдет любой онлайн интерпретатор SQL кода, к примеру sqlfiddle. Но по мере изучения Вам понадобятся более сложные инструменты.

4) Знакомство с UML. Точнее, если по минимуму, с той частью, которая затрагивает прототипирование БД. SQL и СУБД - это инструменты, которые позволяют автоматизировать процессы бизнес логики. UML позволяет эти процессы описать и на основе этих процессов создать прототип схемы БД, от которого уже можно идти к конкретной реализации.

Итак. Четыре базовых шага выполнены. Дальше все просто, перевариваете информацию и занимаетесь практикой от простого к сложному (в комментариях уже указывали вполне годные наборы задачек). Попутно узнаете особенности программной реализации выбранной Вами СУБД. И внимательно читаете документацию от разработчика. На примере SQLite, у них подробно разобрана семантика запросов: SQLite CREATE. Под MySQL найдете сами.

Теперь поясню, почему все четыре шага важны.
1) Без базовых фундаментальных знаний вы просто не поймете, почему, к примеру, в ячейке столбца номера нельзя указывать два номера телефона, или как работают ограничения на целостность данных.
2) Хоть диалекты SQL и отличаются от стандарта SQL:2008, следует понимать, что знание стандарта позволит Вам в случае необходимости переключиться с одной СУБД на другую. Также, хорошая реляционная SQL СУБД должна быть совместима с этим стандартом априори.
3) Тут на Ваш вкус. Посмотрите изложение автора перед покупкой, посмотрите списки того или иного программного обеспечения. Но факт остается фактом, что прочтение только стандартов, мануалов и официальной документации - путь явно не для всех. Кому-то просто необходимо "художественное" изложение, да и просто из книг можно почерпнуть реальные примеры из опыта автора.
4) Надо понимать, что реляционные СУБД всего лишь инструмент для хранения и обработки данных, обеспечивающий определенные бизнес-процессы определенной предметной области. И под бизнес-процессами следует понимать не как какую-то эфемерную для простого человека вещь, а то, что закладывается под этим словом в оригинальном языке, т.е. совокупность процессов\действий, направленных на создание продукта\предоставление услуги. А средства UML позволяют все это описать в стандартизированной графической форме. Чтобы знать SQL не надо знать UML, не надо знать, что такое и, к примеру, ЖЦ программного продукта. Но со временем, если Вы захотите расти дальше, Вам нужен будет инструмент прототипирования. Также, как если вы дорастете до архитектора БД, вам нужно будет представление о том, как эти БД проектировать, начиная с описания предметной области и заканчивая организационной точкой зрения. Стандарты ГОСТ 34.601-90 и ISO/IEC 12207:2008.

Я, как и многие, начинал с какого-то полу прочитанного учебника и примеров из сети. Сейчас я понимаю, что просто потратил время практически впустую. Как ни странно, хоть и принято ругать наше образование, но список курсов для специальностей "ПИ" подобран не просто так. Помимо самого языка следует знать математический "бэкенд" и как его использовать для реализации задач предметной области. Я отношусь к SQL потребительски, это не мой основной язык, но сейчас я понимаю, что если бы уделил ему больше внимания не как языку, а, в первую очередь, как к одному из инструментов СУБД, работающих на основе реляционной алгебры для обеспечения бизнес-процессов, я бы избежал кучу потерянного времени, костылей и ошибок. Надеюсь, мой ответ будет Вам полезен.

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

Пример для Spring:

package com.example.springbark;

import com.example.springbark.pet.Dog;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class SpringBarkApplication implements CommandLineRunner {

    @Autowired
    private Dog dog; // зависимость от интерфейса

    public static void main(String[] args)  {
        SpringApplication.run(SpringBarkApplication.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        dog.bark();
        System.exit(0);
    }
}

package com.example.springbark.pet;

public interface Dog {

    void bark();
}

package com.example.springbark.pet;

import org.springframework.stereotype.Component;

@Component
public class Spike implements Dog {

    @Override
    public void bark() {
        System.out.println("Bark-bark");
    }
}

Тут есть импорт интерфейса Dog и в главном классе неизвестно, какой конкретно объект будет внедрен.

Не учите меня программировать.
Комментарии лишними не бывают.

// Когда я начинал это писать, только Бог и я понимали, что я делаю
// Сейчас остался только Бог

// иногда мне кажется, что компилятор игнорирует все мои комментарии

// пьян, исправить позже

// Магия. Не трогать.

/**
 * Всегда возвращает true.
 */
public boolean isAvailable() {
    return false;
}

Конкретные фреймворки - нет. Как работает веб - желательно знать.

Дополню - фрейморки знать не надо.
Но понимать и знать, как вебсервер работает с бекенд апликацией, как строить апликацию и деплоить - да.

Там и питон не обязательно знать... базового вполне может хватить.
Девопс должен уметь админить и автоматизировать администрацию и оркестрацию.

Если ты можешь написать на питоне скрипт, который получит по веб какой-то json, распарсит его и конвертнет в нужный формат, например в sql query или хотя бы cvs - уже полдела сделано

Никакая. "ОС" в opencomputers - это просто скрипт на lua, который имитирует своим поведением работу операционной системы.