Станислав Макаров

Вы имеете ввиду разбить проект на несколько файлов?
Вам понадобится создать по два файла для каждого модуля: заголовочный (с объявлениями) и собственно файл с реализацией (определением). Файлы с объявлениями имеют расширение .h .H .hpp и так далее.

main.cpp: определение функции main.

// Следующая строка при компиляции будет заменена на содержимое файла helloworld.h
#include "helloworld.h"

int main(int argc, char** argv)
{
    helloworld(); // Вызываем функцию определённую в другом файле.
    return 0;
}

helloworld.h: объявление функции helloworld

// Следующая конструкция называется include guard.
// Благодаря ней вы не сможете вставить содержимое этого файла дважды,
// что поможет вам избежать ошибок переопределения.
#ifndef HELLOWORLD_H 
#define HELLOWORLD_H

// Объявление функции.
// Если функция объявлена но не определена в данном файле,
// компилятор будет искать её реализацию в других файлах.
void helloworld();

#endif

helloworld.cpp

// Снова вставляем содержимое файла helloworld.h
#include "helloworld.h"

#include <iostream>

// Определяем функцию.
void helloworld()
{
    std::cout << "Hello, world!";
}

Зависит от ТЗ. Если статья может быть в нескольких категориях - Many-Many. Если гарантировано в одной - One-Many.

php_flag magic_quotes_gpc off

Может, он имел ввиду LLVM?

Из какой книжки накопипастили куски? Сообщение в гугл вводили? Переводить пытались?
Английским по белому написано - вы пытаетесь использовать фичи из C++11, а компилятору об этом не сказали.
И даже решение написано - опцию нужно добавить.

никак не хранить, предоставьте эквайринг банкам.
исходя из того что вы задаёте такой вопрос - эти данные у вас гарантированно украдут.

конфликты мерджей очень сильно тормозят

1) Дробите задачи, делайте ветки короткоживущими
2) Хорошая идея делать ребейз принятых веток
3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches

Да и бд экспорт/импорт постоянно приходится делать.

1) Миграции
2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.

Если второй пункт соблюдается то вакатка новых релизов будет происходить по такому алгоритму:

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

При таком сценарии даунтайм будет минимальным.

вопрос с выкатыванием новых релизов

Вот вам варианты в порядке сложности и мощности (от простого к сложному).
- capistrano/capifony
- ansible/puppet/chief/etc
- docker + docker-machines + docker-compose

Ну и да, тесты тесты тесты. Все самое критичное должно быть покрыто хотя бы интеграционными/функциональными тестами. В идеале же вся бизнес логика должна быть покрыта быстрыми юнит тестами и UI/инфраструктура функциональными (читать про пирамиду тестирования).

А ты настойчивый. Предыдущий вопрос удалили? Так и быть, отвечу, если это предотвратит еще сотню таких же вопросов:

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

P.S. Неплохо бы перечитывать свой вопрос, чтобы в нем был смысл. В этом вопросе смысл "Как изучать Spring, и есть ли ресурсы с более простым объяснением, чем...".

1. на Битбакете должны быть dev ветка, master ветка и теги релиз версий. feature/hotfix ветки по необходимости. Т.е. если фича/фикс растягивается на больше чем один день, то вечером перед уходом домой вы пушите ее в репозиторий. На следующий день если вы работаете из дома, то выкачиваете ее из репозитория. Так же если вы не придете на работу, то другой разработчик сможет продолжить вашу работу выкачав ветку из репозитория.Чтение про ветки.
2. В вашей схеме не хватает CI-сервера, и потому появляются разные костыли и вопросы по поводу веток. CI-сервер автоматически при коммите в dev ветку(закоммитчена фича/хотфикс) собирает проект, прогоняет тесты и деплоит ваш проект на dev сервер. При коммите в master ветку(закомитчен хотфикс или релиз ветки из dev) он прогоняет тесты и деплоит ваш проект на продакшн.

При чтении использовать order by.
Пока нет order by, по самому стандарту SQL порядок строк не определён.

Не верно. В одной ячейки один id должен храниться. Вам нужно создать еще одну связующую таблицу соотношением один ко многим.

Для начала объясню почему индексы в вашем случае не работают и не могут работать.

> OR links.domain LIKE CONCAT(sites.domain, '.%')

CONCAT - это функция, и вы работаете с результатом функции.
Т.е. получается что в вашем запросу нужно:
1. выбрать все строки из links
2. подсодеденить к каждой строке по sites.domain или sites.domain результат фунции.
=> нужно посчитать каждую строку каждый раз.
Это очень много.

что я бы сделал:
1. создал таблицу доменов
в ней:

id | main_id |domain
1 | 1 | com.youtube
2. | 1 |com.youtube.www
3. | 1 |com.youtube.subdomain

Во всех таблицах - перешёл бы на этот ключ.
2. тогда ваша выборка сокращается до:

SELECT links.id, links.url, sites.id AS site_id, sites.description 
FROM links
LEFT JOIN domains ON links.domainId = domains.id
LEFT JOIN sites ON sites.id = domains.main_id

(смутно понимаю что вы хотели в этом запросе, поэтому уж не обессудьте :) )

Т.е. основной посыл:
переходите на int- ключи

PS: Так же это называется нормализация базы данных. Хранить много одинаковых строк - это плохо.

У вас же в логе написано, что не может найти либу OpenSSL