Как часто вы поражаетесь, читая чужой код, и думаете «господи, ну и каша...». Скорее всего, достаточно часто. И можете ли вы быть уверенным, что никто не думал также когда читал ваш код? Другими словами, насколько вы уверены в чистоте своего кода? Можно быть уверенным только если полностью понимаешь, что значит чистый код.

Сложно дать точное определение чистому коду, и, скорее всего, сколько программистов — столько определений. Однако, некоторые принципы достаточно универсальны. Я собрал девять самых релевантных и описал ниже.

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

У функционального программирования много преимуществ, и его популярность постоянно растет. Но, как и у любой парадигмы программирования, у ФП есть свой жаргон. Мы решили сделать небольшой словарь для всех, кто знакомится с ФП.

В примерах используется JavaScript ES2015). (Почему JavaScript?)

Работа над материалом продолжается; присылайте свои пулл-реквесты в оригинальный репозиторий на английском языке.

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

Если вы — программист, то вам приходится учиться очень много. Вспомните свой первый "Hello, World!". У меня это было в четвертом классе. Мы изучали С++, и наш учитель написал программу от руки на доске. Мы использовали Turbo C++, копировали ее на дискету, чтобы экспериментировать дома.

В том время я не думал, что Turbo C++ это редактор. Я не думал о нем как об IDE. Для меня Turbo C++ был языком C++. Это был единственный известный мне способ программировать. Я не знал, что значит "компиляция", не знал, зачем нужен #include  в начале файла. Я не понимал, что делает main и что printf может принимать любое количество аргументов. Я просто скопировал программу с доски, нажал Run и увидел вывод на экране.

Это круто. Так и нужно учить программированию. Нужно делать что-то до того когда еще не понимаешь, как это работает. Некоторое время нужно умышленно быть в неведении о деталях. Детали отвлекают.

Когда я узнал, что появился новый язык программирования системного уровня, с производительностью как у С++ и без сборщика мусора, я сразу заинтересовался. Мне нравится решать задачи с помощью языков со сборщиками мусора, вроде C# или JavaScript, но меня постоянно терзала мысль о сырой и грубой мощи С++. Но в С++ так много способов выстрелить себе в ногу и других хорошо известных проблем, что я обычно не решался.

Так что я влез в Rust. И, блин, влез глубоко.

Язык Rust все еще довольно молод, поэтому его экосистема пока находится в стадии начального развития. В некоторых случаях, например, в случае с вебсокетами или сериализацией есть хорошие и популярных решения. В других областях у Rust не все так хорошо. Одна из таких областей это OpenGL GUI, вроде CEGUI или nanogui. Я хотел помочь сообществу и языку, поэтому взялся за портирования nanogui на Rust, с кодом на чистом Rust, без связок с С/C++. Проект можно найти тут.

Обычно, знакомство с Rust начинается с борьбы с идеей borrow-checker. Как и у других программистов, у меня тоже был период, когда я не мог понять, как решить ту или иную проблему. К счастью, есть классное сообщество в #rust-beginners. Его обитатели помогали мне и отвечали на мои дурацкие вопросы. Мне понадобилось несколько недель на то, чтобы почувствовать себя более-менее комфортно в Rust.

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

Я и мои коллеги всегда склоняем своих клиентов полностью автоматизировать процесс деплоя. Автоматизация помогает сократить количество конфликтов и задержек, которые возникают в процессе между "завершением" работы над программой и введением в эксплуатацию. Дэйв Фарли (Dave Farley) и Джез Хамбл (Jez Humble) заканчивают книгу "Непрерывная доставка" (Continuous Delivery) на эту тему. Она основывается на множестве идей, которые в целом связаны с непрерывной интеграцией и подталкивают к возможности быстро пустить софт в работу. Глава о сине-зеленом деплое привлекла мое внимание, потому что это один из малоиспользуемых методов, и я решил кратко его осветить.

Введение

Свёрточные нейронные сети (СНС). Звучит как странное сочетание биологии и математики с примесью информатики, но как бы оно не звучало, эти сети — одни из самых влиятельных инноваций в области компьютерного зрения. Впервые нейронные сети привлекли всеобщее внимание в 2012 году, когда Алекс Крижевски благодаря им выиграл конкурс ImageNet (грубо говоря, это ежегодная олимпиада по машинному зрению), снизив рекорд ошибок классификации с 26% до 15%, что тогда стало прорывом. Сегодня глубинное обучения лежит в основе услуг многих компаний: Facebook использует нейронные сети для алгоритмов автоматического проставления тегов, Google — для поиска среди фотографий пользователя, Amazon — для генерации рекомендаций товаров, Pinterest — для персонализации домашней страницы пользователя, а Instagram — для поисковой инфраструктуры.

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

Задача

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

Городская библиотека Стокгольма. Фото minotauria.

В этой статье я хочу рассказать о том, что оценивать время обращения к памяти как O(1) — это очень плохая идея, и вместо этого мы должны использовать O(√N). Вначале мы рассмотрим практическую сторону вопроса, потом математическую, на основе теоретической физики, а потом рассмотрим последствия и выводы.

Введение

Если вы изучали информатику и анализ алгоритмической сложности, то знаете, что проход по связному списку это O(N), двоичный поиск это O(log(N)), а поиск элемента в хеш-таблице это O(1). Что, если я скажу вам, что все это неправда? Что, если проход по связному списку на самом деле O(N√N), а поиск в хеш-таблице это O(√N)?

Не верите? Я вас сейчас буду убеждать. Я покажу, что доступ к памяти это не O(1), а O(√N). Этот результат справедлив и в теории, и на практике. Давайте начнем с практики.

Измеряем

Давайте сначала определимся с определениями. Нотация “О” большое применима ко многим вещам, от использования памяти до запущенных инструкций. В рамках этой статьи мы O(f(N)) будет означать, что f(N) — это верхняя граница (худший случай) по времени, которое необходимо для получения доступа к N байтов памяти (или, соответственно, N одинаковых по размеру элементов). Я использую Big O для анализа времени, но не операций, и это важно. Мы увидим, что центральный процессор подолгу ждет медленную память. Лично меня не волнует, что делает процессор пока ждет. Меня волнует лишь время, как долго выполняется та или иная задача, поэтому я ограничиваюсь определением выше.

Давайте сначала разберемся, зачем нужен вебпак (webpack), и какие проблемы он пытается решить, а потом научимся работать с ним. Webpack позволяет избавиться от bower и gulp/grunt в приложении, и заменить их одним инструментом. Вместо bower'а для установки и управления клиентскими зависимостями, можно использовать стандартный Node Package Manager (npm) для установки и управления всеми фронтэнд-зависимостями. Вебпак также может выполнять большинство задач grunt/gulp'а.

Bower это пакетный менеджер для клиентской части. Его можно использовать для поиска, установки, удаления компонентов на JavaScript, HTML и CSS. GruntJS это JavaScript-утилита командной строки, помогающая разработчикам автоматизировать повторяющиеся задачи. Можно считать его JavaScript-альтернативой Make или Ant. Он занимается задачами вроде минификации, компиляции, юнит-тестирования, линтинга и пр.

Допустим, мы пишем простую страницу профиля пользователя в веб-приложении. Там используется jQuery и библиотеки underscore. Один из способов — включить оба файла в HTML:

Привет, Хабр!

Последние несколько месяцев мы в Хекслете работали над новыми курсами и обновлениями платформы. Сейчас на сайте доступно четыре "профессии", так мы называем последовательные программы обучения по разным направлениям, от новичка до джуниора. Одна из профессий окончена, а в остальных продолжают выходить новые курсы. Сегодня хочу рассказать про самое важное для нас сегодня направление — JavaScript, в частности профессию "Фронтэнд JS-программист".

Мы пошли не стандартным путем "hello world, сделаем форму, добавим анимацию, изучим ООП", а взяли за основу подход к изучению программирования в целом, а не конкретно языка JavaScript. Язык же используется как инструмент решения задач и применения изученных концепций и идей. При это мы изучаем свежий стандарт ES6 и с самого начала знакомим учащихся с правильным окружениям и техниками: модули, пакетный менеджер, отладка, модульное тестирование.

Вот как выглядит программа обучения:

1. Жизнь программиста. Про профессию, виды компаний и виды разработки.
2. Основы программирования. Фундамент: кодинг, ошибки, отладка, функции, побочные эффекты, типы данных. И, конечно, базовые штуки вроде чисел, строк, условий и т.д.
3. JS: подготовка к работе. Установка и настройка окружения — node, npm, atom.
4. JS: Составные данные. Как из простых типов данных составлять более сложные. Абстракция от чисел до объектов.
5. Bash: Основы командной строки.
6. JS: Последовательности. Пишем свой генератор HTML и изучаем filter, map, reduce.
7. JS: Программирование, управляемое данными. Типы, сообщения, ООП и TDD.

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

Память, медленная-медленная память

В начале 1980-х время, необходимое для получения данных из ОЗУ и время, необходимое для произведения вычислений с этими данными, были примерно одинаковым. Можно было использовать алгоритм, который случайно двигался по динамической памяти, собирая и обрабатывая данные. С тех пор процессоры стали производить вычисления в разы быстрее, от 100 до 1000 раз, чем получать данные из ОЗУ. Это значит, что пока процессор ждет данных из памяти, он простаивает сотни циклов, ничего не делая. Конечно, это было бы совсем глупо, поэтому современные процессоры содержат несколько уровней встроенного кэша. Каждый раз когда вы запрашиваете один фрагмент данных из памяти, дополнительные прилегающие фрагменты памяти будут записаны в кэш процессора. В итоге, при последовательном проходе по памяти можно получать к ней доступ почти настолько же быстро, насколько процессор может обрабатывать информацию, потому что куски памяти будут постоянно записываться в кэш L1. Если же двигаться по случайным адресам памяти, то зачастую кэш использовать не получится, и производительность может сильно пострадать. Если хотите узнать больше, то доклад Майка Актона на CppCon — это отличная отправная точка (и отлично проведенное время).

В первой части этой серии статей вы узнали о данных и о том, как можно использовать компьютеры чтобы добывать смысловое значение из крупных блоков таких данных. Вы даже видели что-то похожее на большие данные у Amazon.com середины девяностых, когда компания запустила технологию для наблюдения и записи в реальном времени всего, что многотысячная аудитория клиентов одновременно делала на их сайте. Довольно впечатляюще, но назвать это большими данными можно с натяжкой, пухлые данные — больше подойдёт. Организации вроде Агентства национальной безопасности США (NSA) и Центра правительственной связи Великобритании (GCHQ) уже собирали большие данные в то время в рамках шпионских операций, записывая цифровые сообщения, хотя у них и не было простого способа расшифровать их и найти в них смысл. Библиотеки правительственных записей были переполнены наборами бессвязных данных.

То, что сделал Amazon.com, было проще. Уровень удовлетворённости их клиентов мог быть легко определен, даже если он охватывал все десятки тысяч продуктов и миллионы потребителей. Действий, которые клиент может совершить в магазине, реальный он или виртуальный, не так уж много. Клиент может посмотреть что в доступе, запросить дополнительную информацию, сравнить продукты, положить что-то в корзину, купить или уйти. Всё это было в пределах возможностей реляционных баз данных, где отношения между всеми видами действий возможно задать заранее. И они должны быть заданы заранее, с чем у реляционных баз данных проблема — они не так легко расширяемы.

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

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

Тип — это коллекция возможных значений. Целое число может обладать значениями 0, 1, 2, 3 и так далее. Булево может быть истиной или ложью. Можно придумать свой тип, например, тип "ДайПять", в котором возможны значения "дай" и "5", и больше ничего. Это не строка и не число, это новый, отдельный тип.

Статически типизированные языки ограничивают типы переменных: язык программирования может знать, например, что x — это Integer. В этом случае программисту запрещается делать x = true, это будет некорректный код. Компилятор откажется компилировать его, так что мы не сможем даже запустить такой код. Другой статически типизированный язык может обладать другими выразительными возможностями, и никакая из популярных систем типов не способна выразить наш тип ДайПять (но многие могут выразить другие, более изощренные идеи).

Динамически типизированные языки помечают значения типами: язык знает, что 1 это integer, 2 это integer, но он не может знать, что переменная x всегда содержит integer.

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

Нам всем знакомо это чувство.

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

Я никогда не принимал тяжелые наркотики, но предполагаю, что у них похожее действие.

Такая жизнь с лёгкостью превращается в наркоманию. И наркомания эта — одна из самых коварных. Но она не воспринимается как физическое привыкание… скорее, как продуктивность.

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

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

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

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).

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

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

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

Начинающий программист Ewa Mitulska-Wójcik описала в недавней публикации на Медиуме свои мысли о необходимых разработчикам личных качествах. Публикуем перевод этой заметки и небольшой комментарий в самом конце.

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

Коммуникабельность

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

Вот некоторые повседневные коммуникативные задачи, с которыми вам придётся столкнуться, как разработчику.

1. Делиться возникшими проблемами с другими ребятами в команде.
2. Отчитываться о деталях прогресса в системе управления проектами, вроде Jira.
3. Выражаться ёмко и конкретно, насколько возможно, когда этого требует ситуация.
4. Уметь слушать и быстро реагировать
5. Чётко объяснять все потребности, сомнения, риски и прогресс проекта в понятной остальным членам команды, менеджеру или клиенту форме.
6. Объяснять технические проблемы так, чтобы вас понимали клиенты и члены команды, не связанные с технической частью.

Оригинал: Bruno Marnette: Coding is boring, unless…

Мне не удавалось, как разработчику, задерживаться на одной работе больше двух лет.

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

(Оговорка: мне везло, что я жил в местах, где работы для программистов было больше, чем программистов! Я понимаю, что возможность сменить работу доступна не всем).

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

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

В Enki нам повезло работать над трудной и интересной задачей. У нас есть много интересных штук для претворения их в код и множество занятных проблем, которые нужно решить. Поэтому, казалось бы, о какой скуке может идти речь? Но в начале её никогда и не бывает. Скука, как правило, нагнетается со временем, и поражает вас в самый неподходящий момент.

Вот почему мы заранее предлагаем решение, создавая культуру, которая спасет нас (постучим по дереву!) и сделает так, чтобы никогда не становилось скучно.

Рекрутеров редко спрашивают про то, как устроена их работа: обычно на собеседованиях кандидатам интереснее узнавать про проекты, куда они будут выходить. Оно и правильно. Но в одну пятницу CEO DigitalHR Катя Гаврилова в интервью с Hexlet отвечала на поток вопросов от разработчиков: почему эйчары не перезванивают, как становятся рекрутерами и как они вообще ищут кандидатов. На некоторые темы так и не хватило времени, поэтому постараемся дать ответ здесь:

ОБРАЗОВАНИЕ

Если у кандидата есть высшее образование, но непрофильное?

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

ПРЕДЫДУЩИЙ РАБОТОДАТЕЛЬ

Насколько важны рекомендации от других компаний?

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

Фото из Гугла, это не мама автора

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

Объясню немного

Мир банковского программного обеспечения — это другая вселенная. Она сильно отличается от той, к которой привыкло большинство из нас. Я публикую этот пост на HN и на Reddit. Публикую интервью не в виде вопросов-ответов, а в виде рассказа. Я добавил некоторые вопросы и ответы в нижнюю часть поста.

1991

Год, когда она начала внутреннее обучение в банке Nordea, который тогда назывался Nordbanken (Северный банк). В 2001 году его переименовали в Nordea. Во время обучения она должна была проходить различные тесты, в первую очередь тест IQ, чтобы показать, что она обладает интеллектом, достаточным для работы в этой области. Тест на психологическую устойчивость — что у неё достаточно нервов для этой специфической работы и тест на многозадачность, который она завалила с оценкой 22/100. Остальные тесты она прошла успешно и заняла одну из 16 доступных позиций.

Должность звучала «как программист мэйнфреймов IBM на языке COBOL», и до сих пор, уже 25 лет, моя мама работает на этой должности в том же банке.

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

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.

А потом начинаются джойны, агрегирование, подзапросы, и получается совсем белиберда. Вроде такой:

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

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