Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Глава 25. Креативность

«Есть запахи, которые вы не можете ощущать, длины волн света, которые вы не видите, звуки, которые вы не можете услышать,… есть мысли, о которых вы не можете думать.»

Глава 24. Квантовая механика

1. это фундаментальная физика,
2. она имеет много неожиданных интеллектуальных следствий и
3. дает ряд моделей для работы.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

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

Мой инструментарий социального архитектора состоит из 20 инструментов, каждый из которых соответствует какому-либо аспекту сообщества или группы. Их можно использовать двумя способами.

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

Во-вторых, вы можете использовать их для создания сообщества, при этом прилагая усилия там, где они наиболее необходимы.

• Четкая миссия – заявленная причина существования группы.
• Свободное участие – насколько легко люди могут присоединиться к группе.
• Прозрачность – насколько открыто и публично принимаются решения.
• Бесплатные участники – как много можно платить людям за участие.
• Свобода работы с материалами (ремиксабельность) – насколько свободно участники могут использовать работу друг друга.
• Четкость протокола – насколько хорошо прописаны правила.
• Компетентность власти – насколько хорошо следят за соблюдением правил.
• Нон-трайбализм – насколько далеко распространяются права группы над своими участниками.
• Самоорганизация – насколько свободно могут участники определять свои задачи.
• Толерантность – как группа разбирается с конфликтами.
• Измеримый успех – как хорошо группа может отслеживать свой прогресс.
• Высокое награждение – как группа вознаграждает своих участников.
• Децентрализация – насколько широко распределены участники группы.
• Свободная рабочая среда – насколько легко создавать новые проекты.
• Стандартная структура – насколько общая структура стабильна и предсказуема.
• Плавность обучения – насколько легко начать и продолжить учиться.
• Позитивность – насколько группа движима позитивными целями.
• Чувство юмора – насколько серьезно группа себя воспринимает.
• Минимализм – сколько лишней работы делает группа.
• Разумное финансирование – как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.

Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.

1. Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.
2. Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.
3. Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.
4. Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT.
5. Iptables. Настраиваем security zones. Изучаем tcp сессии.

Как создать АПИ для умных? Такое апи, чтобы создание клиента для него было не скучным механическим процессом, а настоящим приключением с элементами детектива, хоррора и мистики? Такое апи, о котором пользователи будут взахлёб рассказываете коллегам? Апи взрывающее мозг, заставляющее смеяться, кричать и плакать? Я постарался отобрать лучшие практики, с которыми пришлось столкнуться.

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