В игре Go очень простые правила, но стать мастером в ней непросто, нужно научиться думать паттернами, территориями и прочими стратегическими концепциями. Язык Go не совсем случайно назван аналогично названию этой игры. В своем выступлении на недавнем митапе в Сан-Франциско, Роб Пайк упомянул книгу «Постулаты Go» (Go Proverbs), которые описывают сложные стратегии простыми поэтичными фразами. Эти постулаты несут глубинный смысл для тех, кто знаком с игрой Go, и могут казаться пустыми фразами тем, кто не знаком. И в этом нетехническом докладе он предложил придумать аналогичным способом «постулаты» и для языка Go.

Вот некоторые из них:

• Don't communicate by sharing memory, share memory by communicating.
• Concurrency is not parallelism.
• Channels orchestrate; mutexes serialize.
• The bigger the interface, the weaker the abstraction.
• interface{} says nothing.
• Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
• A little copying is better than a little dependency.
• Cgo is not Go.
• Clear is better than clever.
• Reflection is never clear.
• Errors are values.

Это чем-то похоже на Zen of Python. Вы можете не соглашаться с ними, но эти постулаты отражают идиоматичность и подход в Go. Давайте разберем подробнее каждый из них по мотивам доклада (видео в конце поста).

От переводчика: сегодня мы предлагаем вам перевод статьи, размещенной на Hackernoon компанией SteelKiwi. Она занимается разработкой программных решений b2b и b2c, а опытом, накопленным в процессе работы, делится с читателями своего блога.

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

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).