Является ли Go объектно-ориентированным языком?

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

Хотелось бы поделиться "граблями", на которые успел наступить при работе с docker, интересными фишками и вообще рассказать про эту замечательную технологию.

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

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

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

Если вы хоть раз были сбиты с толку, что означает символ "амперсанд" (&) или "звёздочка" ("знак умножения", *) или запутывались, когда что использовать, то это статья для вас. Авторы Go старались сделать язык знакомым большинству программистов, и многие элементы синтаксиса заимствовали из языка С. Но в 2017м уже сложно понять, большинство программистов владеют С или нет, и смею полагать, что уже нет. Поэтому концепции хорошо знакомые прошлому поколению разработчиков, могут выглядеть совершенной абракадаброй для для нового поколения. Давайте немного копнём историю и расставим все точки над ї в вопросах указателей в Go и использования символов & и *.

Как сейчас проходят собеседования на golang разработчика? Что спрашивают?

Сегодня я хотел бы поделиться особенностью разработки сервисов на Golang вместе с протоколом gRPC. В этой статья я не буду рассказывать, что такое gRPC, protobuf и для чего они нужны, вместо этого я сосредоточусь на технической части.

Мы напишем простое приложение на Golang, который в качестве транспортного протокола будет использовать gRPC, а так же с помощью gRPC Gateway мы подключим поддержку RESTful API.

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

Git, как технология, прост в изучении — вменяемому разработчику требуется несколько часов и доступ к документации, чтобы понять базовые принципы его работы. Но в реальной жизни, особенно в командной разработке — теории недостаточно. Поэтому IT-компании создают простые пошаговые инструкции, чтобы стажеры/джуны быстро и безболезненно вливались в работу, опытные разработчики работали единообразно и предсказуемо, а тимлиды могли легко управлять этим процессом.

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

И вот в один прекрасный момент, попробовав Blade и Twig, я задумался о том, как бы какой-нибудь шаблонизатор к битре прикрутить.

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

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

Это было небольшое вступление, теперь непосредственно к сути.

Сегодня рассуждаем над задачей построения максимально отказоустойчивой сетевой инфраструктуры предприятия, с минимальной привязкой к конкретному вендору, преимущественно на открытых протоколах и стандартах.

Рассмотрим такие вопросы:

1. Вендор-независимость (долой проприетарное рабство)

2. Отказоустойчивость (больше линков, больше железа, меньше технологий)

3. Модульность (занудно, но важно)

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

1. Рекомендации по применению базовых протоколов и стандартов

2. Общие настройки сетевого оборудования

3. Коротко и таблично уделим внимание безопасности