pi314

Более-менее распространённых реляционных баз данных сейчас не так много:
Oracle DB и Microsoft SQL Server - точно не подходят под "простые". Это большие enterprise решения, на обучение которым люди тратят уйму времени.

SQLite - Вы просили не писать (хотя под определение "простая, логичная и понятная" подходит как нельзя лучше: нету пользователей и ещё части усложняющей функциональности, при этом достаточно неплохо выдерживает SQL стандарт)

MySQL - самая популярная бд, согромным количетвом примеров, советов и т. п. Причём на всех языках мира.
Сама по себе эта бд не является образцом логичности и простоты, но если ты сталкиваешься с ней каждый день в течении нескольких лет, то она "вдруг" становится понятнее остальных.

PostgreSQL - сама по себе логичная и приятная, но далеко не простая. Функциональности очень много, причём много сложной.

Тут есть неплохое "сравнение" (скорее описание общих отличий) SQLite MySQL и PostgreSQL.

Про менее распространённые:
Не очень понятно, что вообще надо. Вопрос очень абстрактный. Если надо не только простую, понятную и логичную, а ещё, чтобы разобраться можно было, то надо, чтобы было хоть сколько-то материала (ответов на вопросы, примеров, туториалов).
Вот страница русской вики (в списке не только реляционные, их пропускал)
Посмотрим на те, у которых есть хотя бы страничка в русской wiki. (Если нет даже страницы, то вряд ли на русско-язычном ресурсе эту бд кому-нибудь посоветуют). Заранее прошу прощения за пробегание по верхам (с большинством бд не работал, мог допустить неточности):
* Caché - "позиционирующаяся производителем как «объектно-реляционная» или «постреляционная»" - вряд ли "простая и понятная"
* DB2 и Informix - базы данных, о которых я даже не смог понять, простые они, или нет. Обе - продукты IBM. Может быть она из них - то, что нужно (я правда не разобрался).
* Ingres - предшественник PostgreSQL (не вижу смысла иметь дела с ней, когда есть Postgre)
* mSQL - уже не разрабатывается, была вытеснена MySQL
* Btrieve - уже не разрабатывается
* ЛИНТЕР - уже не разрабатывается
* Adaptive Server Enterprise - не является бесплатной (дальше лень смотреть, если честно)
* Microsoft Access - комментарии излишни
* OpenOffice Base - думаю, что так же, как и Access - годится для офис-менеджеров
* Rdb - предшественник Interbase, хрен поставишь на ПК
* Interbase - предшественник Firebird
* Firebird - кстати, достаточно известная база данных, вполне может по соперничать с MySQL и пр. После изучения дополнительной информации о ней, может быть даже посоветовал бы её, как не такую сложную, как Postgre, но и не отход от стандартов и кашу MySQL (хотя сам с Firebird не работал, может оно там ещё сложней и замороченей)
* HSQLDB - выглядит как маленькая, лёгкая бд, которая хорошо поддерживает стандарты SQL и всё. То есть вполне подходит под определение простая, но достаточно близка к почему-то заранее отклонённой SQLite

Как итог напишу сложившееся общее субъективное мнение:
Лёгкие и (поэтому) простые - SQLite (проще работать с базой, больше информации), HSQLDB (работает согласно стандартам SQL).
Много информации, много возможностей, логичная - PostgreSQL.
ОЧЕНЬ много информации, достаточно простая, не логичная во многом - MySQL.
Достаточно простая, сравнительно мало информации, достаточно логичная (вообщем везде средняя) - Firebird.

P.S. Пока исследовал интернет совсем забыл про то, что в вопросе было про наличие удобных инструментов. По этому пункту
MySQL получает 5
PostgreSQL - 4
SQLLite - 4
Firebird - 4
HSQLDB - 3

Искусство схемотехники - отличная книга для начинающих.
Для понимания работы схем неплохо бы их моделировать и смотреть, что в схеме происходит.
Я учился по Micro-Cap. Сейчас почему-то набрал популярность пакет LTspice.

Ставим точку:
- может, если ФБ и ВК предоставляют возможность размещать свои кнопки и отдают с них статистику владельцу сайта, причём не анонимную, а с именами пользователей
- моежт, если пользователь оставить на сайте комментарий пользуясь авторизацией через ФБ или ВК(оба предоставляют какой-то аналог OAuth)
- может, используя значение referer из HTTP-запроса. Это если пользователь перешёл на сайт из ВК или ФБ. Но имя пользователя он при этом не узнает.

Для параноиков рекомендую Ghostery, есть под лису и под хром.

Программы на C/C++ работают быстрее за счёт отказа от контроля всего и вся (расхода памяти, переполнения стека, корректности указателей), за счёт явной и жёсткой типизации переменных, за счёт меньшего количества обёрток вокруг типов данных. Но это позволяет программисту выстрелить себе в ногу таким количеством способов, которые в Java и не снились.

Фича называется Lazy Load: friendlybit.com/js/lazy-loading-asyncronous-javascript

Знания без практического применения
То есть всё, что вы знаете это "Базовые знания"?

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

уровень зарплаты
15к - неполный день
30к - полный день

студент 3 курса
Без пояснений, значит считаем, что закончили 2й.
могу тратить 30 часов в неделю
Час на езду, полдня на зачеты, сессии, доздавать, не знаю вернусь ли сегодня, не знаю буду ли завтра, звонки в 8 утра что не приду, звонки в 2 дня что не приду, задержался. Итого 15-20 часов.

Мне кажется, что речь человека, если только это не речь узкого специалиста на рабочем месте или на лекции, на самом деле почти всегда - об одних и тех же вещах. Специфика конкретного человека заключается в выборе синонимов, вводных слов, наиболее частым схемам построения предложений. Превратить эти отличия в картинки - невозможно. Они (отличия) сотрутся : как Вы нарисуете по-разному "классный", "клевый" и "прикольный" ?

Если же оставить в отчете именно слова, а не их изображения, то тогда это довольно известная задача сравнения изучаемого текста с корпусами наиболее употребительных слов. Средствами мат.статистики считаются отклонения, наблюдаемые в речи этого человека, относительно общеупотребительной лексики, и из них строится какой-нибудь отчет или визуализация :
habrahabr.ru/post/204104

На компьютере.

Мне кажется, это Неуловимый Джо.
Если вам необходима компактная платформа общего назначения для прикладного решения на питоне, к примеру, возьмите малину, кубик или любую подобную плату. Валом их.
Ембеддед это несколько другие задачи и соответственно инструменты. Это работа на уровне железа, таймингов, прерываний. Зачастую сложно понять, почему что-то не работает, хотя должно. Хотя код на си или асме, и вроде как все прозрачно и понятно и на одном экране умещается.
А вы представьте в какой ад превратится отладка, если туда впихнуть рантайм или виртуальную машину?

В двух словах это набор базовых принципов (мат. модели, например), на которой работает язык программирования. Сейчас наиболее широко используются три парадигмы: императивная, функциональная и логическая.

Императивная основана на мат. модели машин Тьюринга. Особенность данной парадигмы в том, что программист чётко, шаг за шагом описывает изменения состояния программы (алгоритм), который компьютер в точности выполняет. Внутри данной парадигмы широко используются процедурный стиль (язык C) и объектно-ориентированный стиль (язык Smalltalk как яркий представитель).

Функциональная парадигма основана на мат. модели лямбда-исчисления Чёртча. В ней программы представляют из себя вычисление функций именно в их математическом понятии. Здесь (в идеале) нет глобального состояния программы и от него ничего не должно зависеть. Функции не должны иметь побочных эффектов (pure), а данные стараются делать неизменяемыми (immutable). Наиболее яркий представитель - Haskell.

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

А вообще по теме парадигм есть неплохая глава в книге Сошникова Д.В. "Парадигма логического программирования"

Я думаю, эта задача очень близка к задачам теории оптимального управления. А именно — задача поиска оптимального программного управления. Если рассмотреть эту задачу в непрерывном времени, а также исключить для простоты займы в банке, то ее можно выразить следующим образом. Пусть состояние системы выражается вектором x[i] = {x1, x2, x3}, где:
x1 — количество фабрик кредитов
x2 — количество танков (юнитов)
x3 — количество кредитов в кассе

Тогда имеем следующие уравнения:

dx1/dt = u1 — скорость покупки новых фабрик кредитов. Эта величина задается регулятором, ее требуется найти по условию задачи
dx2/dt = u2 — скорость покупки новых танков. Аналогично, величина задается регулятором, ее требуется найти
dx3/dt = k1*x1 — k2*x2 — k3*u1 — k4*u2, где:
k1 — скорость производства кредитов фабриками
k2 — стоимость содержания танка за единицу времени
k3 — стоимость фабрик
k4 — стоимость танков

По условию задачи требуется минимизировать затраты, поэтому эффективность управления можно выразить с помощью интеграла. Для начала запишем затраты в каждый момент времени:
s = k2*x2 + k3*u1 + k4*u2

Общие затраты будут интегралом от этой функции:
I = integral from 0 to t1 of s * dt.

Далее, на управление и переменные состояния накладываются ограничения:
x3 >= 0 — баланс должен быть положительным;
u1 >= 0 — продажа фабрик запрещена;
u2 >= 0 — продажа танков запрещена.

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

Диф. уравнения, описывающие систему, являются, к счастью, линейными, поэтому ТОУ дает относительно легкие способы решения такой задачи. Разобравшись с решением задачи в непрерывном времени, можно будет перейти к решению в дискретном времени, хотя я думаю, оно будет сложнее.

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

С танками разобрались. Получается, что до самого конца функционирования системы необходимо работать только на кредиты. Количество кредитов в кассе к концу работы должно равняться стоимости всех приобретаемых танков. Запишем все это в виде уравнений:

x2(t) = 0 при t<T, x2(T)=N — количество танков к концу работы
где T — время конца работы.
u2(t) = 0 при t<T, u2(T) = N*delta(t-T) — дельта-функция Дирака.
lim(t->T) x3(t) = k4*N — после покупки танков нет смысла оставлять деньги в кассе, поэтому количество денег в кассе к концу работы должно быть равно стоимости всех приобретаемых танков.

Остается решить вопрос с покупкой фабрик кредитов. Очевидно, фабрики есть смысл строить только до тех пор, пока они окупаются. Поскольку стоимость фабрик равна k3, а их производительность равна k1, то приравняем и получим:
k1*to = k3, где to — время окупаемости фабрик. Отсюда:
to = k3/k1.

В каких количествах надо строить фабрики? Если мы хотим максимизировать количество танков N — то нам следует максимизировать количество кредитов к концу работы. Следовательно, фабрики нужно строить по максимуму до тех пор, пока они окупаются. По максимуму — это значит, что весь начальный капитал и всю текущую прибыль необходимо вкладывать в фабрики, и перестать это делать в момент T-to. Во время T-to идет чистое накопление, а до этого времени деньги равны нулю. Следовательно:

lim(x3->0) = 0 — весь начальный капитал полностью пускаем на фабрики
x3(t)=0 при 0<t<T-to
x3(t)=k1*x1o*t при to<=t<T
где x1o — количество фабрик к моменту начала фазы накопления.

В каждый момент прибыль, приносимая фабриками, будет равна k1*x1(t). Вся эта прибыль до начала фазы накопления будет инвестироваться в покупку новых фабрик. Следовательно, имеем уравнение:
k1*x1 = k3*dx1/dt
Это простейшее диф. уравнение первого порядка, его решением является экспонента. Следовательно, количество фабрик во время фазы постройки будет расти экспоненциально, и таким же образом будет расти скорость покупки новых фабрик.

Но это я рассмотрел случай максимизации N при заданном T. по исходному условию задачи у нас заданы как T, так и N. Хоть это и менее интересный случай, желание заказчика — закон! Рассмотрим и его.

Поскольку затраты на постройку танков при заданном N минимизировать уже некуда, то из других затрат остаются только затраты на постройку фабрик. Их можно минимизировать исходя из того, чтобы иметь минимально возможное количество фабрик для накопления необходимого количества кредитов. Когда лучше покупать фабрики? Очевидно, в начале игры, так как чем дольше существуют фабрики — тем больше они дают прибыли. Поэтому и здесь все функционирование системы разобьется на 3 этапа: фаза постройки, фаза накопления и финальный аккорд по покупке танков. Количество денег в кассе в конце также будет равно стоимости приобретаемых танков. В свою очередь, в фазе накопления сумма в кассе будет линейно расти начиная от нуля в момент начала фазы накопления. Несложно составить уравнения, аналогичные приведенным выше, и рассчитать моменты перехода между фазами.