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

В этой небольшой статье, я последовательно буду создавать подключения к БД, а затем показывать на примере, что может пойти не так. На мой взгляд, понимание, почему нужно делать именно так, а не иначе, лучше, чем простое заучивание и использование паттернов.

Статья рассчитана на начинающих и всех, кто интересуется этой темой.

Вы когда-нибудь задумывались о том, какие вопросы задают DevOps инженеру на собеседовании? Да, есть вполне обоснованное мнение, что таких инженеров в принципе быть не может (или все инженеры команды являются проводниками методологии DevOps), но все же на рынке хватает вакансий «DevOps Engiineer» разных уровней. Сегодня мы рассмотрим вопросы DevOps инженерам высшего (без пипл менеджмента) уровня – Senior.

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

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

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

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

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

Я постарался копнуть в каждый вопрос чуть глубже чем, возможно, надо бы — что бы у читателя был не только короткий ответ на вопрос, но и некоторое понимание "а почему именно так устроена та или иная штука". Более того, крайне рекомендую ознакомиться и с ссылками на источники, что будут под ответами — там вы найдете более развернутые ответы.

Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.