От переводчика: перевели для вас статью Брета Кэмерона о хитростях в работе с CSS. Многие моменты пригодятся не только новичкам, но и опытным разработчикам.

Эта статья о приемах работы в CSS, узнав о которых, я восклицал: «Агаааа!». Надеюсь, вы тоже сделаете пару открытий.

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

Я покажу несколько приемов и расскажу о принципах их использования в CSS. Сама по себе статья не о сложностях. Наоборот, она призвана сделать вашу работу более комфортной.

Interface

In the first article, we've mentioned that an access method must provide information about itself. Let's look into the structure of the access method interface.

Properties

All properties of access methods are stored in the «pg_am» table («am» stands for access method). We can also get a list of available methods from this same table:

postgres=# select amname from pg_am;

 amname
--------
 btree
 hash
 gist
 gin
 spgist
 brin
(6 rows)

Although sequential scan can rightfully be referred to access methods, it is not on this list for historical reasons.

In PostgreSQL versions 9.5 and lower, each property was represented with a separate field of the «pg_am» table. Starting with version 9.6, properties are queried with special functions and are separated into several layers:

• Access method properties — «pg_indexam_has_property»
• Properties of a specific index — «pg_index_has_property»
• Properties of individual columns of the index — «pg_index_column_has_property»

The access method layer and index layer are separated with an eye towards the future: as of now, all indexes based on one access method will always have the same properties.

Wireshark Foundation выпустила финальную stable-версию популярного сетевого анализатора трафика — Wireshark 3.0.0. В новом релизе устранено несколько багов, реализована возможность анализа новых протоколов и заменен драйвер WinPcap на Npcap.

Wireshark — самый популярный в мире анализатор сетевых протоколов. Он используется для устранения неполадок, анализа, развития и обучения.

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

Посмотрите, например, на результат работы всего 251 байта JavaScript:


Ну, давайте разбираться, как это работает!

В сегодняшней части перевода серии материалов о Docker мы поговорим о работе с данными. В частности — о томах Docker. В этих материалах мы постоянно сравнивали программные механизмы Docker с разными съедобными аналогиями. Не будем отходить от этой традиции и здесь. Данные в Docker пусть будут специями. В мире существует множество видов специй, а в Docker — множество способов работы с данными.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

Что такое шум Перлина?

Шум Перлина придуман в 1983 году Кеном Перлином (получившим за это достижение премию Американской Академии кинематографических искусств и наук). Видите ли, в те времена все стремились к фотореализму, но его всегда не хватало. Кен Перлин придуман этот алгоритм шума, чтобы избавиться от жалкого «компьютерного» внешнего вида 3D-моделей. Шум — это генератор случайных чисел в компьютерной графике. Это случайный неструктурированный паттерн, он полезен в тех случаях, когда требуется источник подробных деталей, недостающих в очевидной структуре¹. Шум Перлина — это многомерный алгоритм, используемый в процедурной генерации, текстурах, генерации рельефа, генерации карт, генерации поверхностей, генерации вершин, и так далее, и тому подобное.

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

Привет, Хаброжители! Мы недавно издали книгу по Kubernetes версии 1.10. В посте рассмотрен отрывок «Сетевые решения для Kubernetes»

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

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

Для начала следует договориться, что значит лучшие практики для языка программирования. Здесь можно вспомнить слова Расса Кокса, технического руководителя Go:

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

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

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

У нас в небольшом банке были большие проблемы: 3 python монолита связанных чудовищным количеством синхронных RPC взаимодействий с большим объемом legacy. Что бы хотя бы отчасти решить все возникающие при этом проблемы было принято решение перейти на микросервисную архитектуру. Но прежде чем решиться на такой шаг нужно ответить на 3 основных вопроса:

• Как разбить монолит на микросервисы и какими критериями следует при этом руководствоваться.
• Каким образом микросервисы будут взаимодействовать?
• Как осуществлять мониторинг?

Собственно кратким ответам на эти вопросы и будет посвящена данная статья.

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

Всем привет, я один из разработчиков сервиса SearchFace и готов поговорить о нём в комментариях.



Из-за шумихи с иском ВК на второй план отошло то важное, ради чего мы запустили сервис — чтобы протестировать возможности поиска. А раз уж теперь сервис доступен широкой публике, хочется продемонстрировать всем, на что способны наши алгоритмы распознавания.

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

Бублики — это инструкции в файле Dockerfile

Недавно познакомился со структурами C/C++ — struct. Господи, да «что же с ними знакомиться» скажете вы? Тем самым вы допустите сразу 2 ошибки: во-первых я не Господи, а во вторых я тоже думал что структуры — они и в Африке структуры. А вот как оказалось и — нет. Я расскажу о нескольких жизненно-важных подробностях, которые кого-нибудь из читателей избавят от часовой отладки…

Этот текст предназначен для тех, кто только осваивает программирование. Основная идея в том, чтобы показать этап за этапом, как можно самостоятельно сделать игру à la Wolfenstein 3D. Внимание, я совершенно не собираюсь соревноваться с Кармаком, он гений и его код прекрасен. Я же целюсь совсем в другое место: я использую огромную вычислительную мощность современных компьютеров для того, чтобы студенты могли создавать забавные проекты за несколько дней, не погрязая в дебрях оптимизации. Я специально пишу медленный код, так как он существенно короче и просто понятнее. Кармак пишет 0x5f3759df, я же пишу 1/sqrt(x). Мы преследуем разные цели.

Я убеждён, что хороший программист получается только из того, кто кодит дома в своё удовольствие, а не только просиживает штаны на парах в университете. В нашем университете программистов учат на бесконечной череде всяких библиотечных каталогов и прочей скукоте. Брр. Моя цель — показать примеры проектов, которые интересно программировать. Это замкнутый круг: если интересно делать проект, то человек проводит над ним немало времени, набирается опыта, и видит вокруг ещё больше интересного (оно же стало доступнее!), и снова погружается в новый проект. Это называется проектное обучение, вокруг сплошной профит.

Простыня получилась длинная, поэтому я разбил текст на две части:

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

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


Это не законченная игра, но только заготовка для студентов. Пример законченной игры, написанной двумя первокурсниками, смотрите во второй части.

По мере взросления и стабилизации экосистемы Docker связанные с безопасностью этого продукта темы привлекают все больше внимания. При проектировании инфраструктуры невозможно избежать вопроса обеспечения безопасности Docker.

В Docker уже встроено несколько замечательных средств обеспечения безопасности:

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

  
  

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

  
  

• Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).

  
  
• Docker-контейнеры воспроизводимы. Благодаря их декларативной системе сборки любой администратор может легко выяснить, из чего и как был сделан контейнер. Крайне маловероятно, что у вас в итоге окажется неизвестно кем настроенная legacy-система, которую никому не хочется конфигурировать заново. Знакомо, не правда ли? ;)

Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.

pudge — встраиваемая key/value база данных, написанная на стандартной библиотеке Go.


Остановлюсь на принципиальных отличиях от существующих решений.

Stateless

pudge.Set("../test/test", "Hello", "World")

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