Привет, меня зовут Иван Греков, я работаю во фронтенд-команде Badoo, занимаюсь вёрсткой пользовательских интерфейсов на проектах компании.

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

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

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


Серия будет состоять из следующих частей:

• Часть 1. Введение в процедурную анимацию
• Часть 2. Математика прямой кинематики
• Часть 3. Реализация прямой кинематики
• Часть 4. Введение в градиентный спуск
• Часть 5. Инверсная кинематика для робота-манипулятора
• Часть 6. Инверсная кинематика щупалец
• Часть 7. Инверсная кинематика лап паука

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

Как это было

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

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

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

Если вы недовольны своей работой, вам наверняка порой приходит в голову мысль: «Пора бросать это дело». Так почему же вы не бросаете?

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

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

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

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

В очередной статье нашего цикла публикаций, посвященного интернет-разведке, рассмотрим, как операторы продвинутого поиска Google (advanced search operators) позволяют быстро находить необходимую информацию о конкретном человеке.

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

Вводная часть: Дизайн российских городов, где он?
Первая часть статьи: Первый частный город в России, быть или не быть?

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

В прошлой своей статье "Дизайн российских городов, где он?" я затронул тему плохой архитектуры в наших с вами городах. Она получило широкий резонанс, набрав более 300 комментариев.

Сегодня поговорим о более практической части и попытаемся вместе ответить на вопрос «Что делать?».

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

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

Всем привет! В последнее время всё чаще сталкиваюсь с тем, что многие админы используют дешёвые СХД (SOHO) для продуктивных сред… При этом редко задумываясь о доступности данных и отказоустойчивости решения… Увы, но не многие также задумываются о резервных копиях и бекапах…

Вот и сегодня ко мне «на лечение» попал интересный экземпляр:


Чудестный экземпляр EMC (ещё даже не Lenovo) iomega storcenter px4 (который дальше 25% не грузится)

О подробностях восстановления читайте под катом.

Источник: 'Nova typis transacta navigatio' (Linz: s.n., 1621), p.12 (British Library, G.7237).

Часто во время разговоров о Docker я слышу мнения, с которыми не совсем согласен.

«Docker по своей сути предназначен для крупных компаний»

«под OSx у него экспериментальная поддержка, под Windows работает еле-еле»

«Я не уверен, что смогу быстро развернуть его локально»

… и еще много всякого.

В этих утверждениях есть доля истины (см. ниже мифы 3 и 5), но она мала, и по большей части реальная картина получается искаженной.

А есть еще и наполненные жаргоном статьи о том, как при использовании немалого количества фреймворков обрабатывать 10к миллионов запросов в секунду. И это с помощью всего лишь 30к контейнеров при автоматизации 5к микросервисов, размещенных на шести сотнях облачных виртуальных машин…

Что ж, нетрудно догадаться, почему Docker окружен таким количеством мифов.

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

Давайте поговорим о самых распространенных мифах – тех, с которыми я сталкивался и в которые верил, – и попробуем найти в них истину, а также решения, если таковые имеются.

Таких материалов пока практически нет в сети. Поэтому короткая заметка с рекомендациями в пределах допустимых условиями экзамена.


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

Я же представляю слой населения, который начал с нуля в феврале, а в середине марта сдал с результатом 92%.

Современные маршрутизаторы обрабатывают по несколько миллионов пакетов в секунду, работают с несколькими FV таблицами маршрутизации, позволяют реализовать огромное количество сервисов. Различные вендоры используют разный подход к построению оборудования. В данной статье не будет огромного количества выводов. Сегодня поговорим об архитектуре оборудования Juniper.

В статье о EVPN я упомянул о необходимости во включении composite-next-hop для работы EVPN, после чего как минимум 10 человек задали мне один и тот же вопрос — что же такое composite-next-hop. И я так полагаю, что composite-next-hop для многих является загадочной технологией, позволяющей резко уменьшить количетсво next-hop-ов. Очень хорошо эта тема раскрыта в книге “MPLS in SDN era”, я же на основании статьи из данной книги вкратце опишу как это работает.

— Здравствуйте. Скажите, сколько стоит сделать приложение типа Uber?

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

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

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

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

Разработанная инженерами Uber система хранения данных Schemaless используется в нескольких самых важных и крупных сервисах нашей компании (например, Mezzanine). Schemaless — это масштабируемое и отказоустойчивое хранилище данных, работающее поверх кластеров MySQL¹. Когда этих кластеров было 16, управление ими было несложным делом. Но в настоящий момент у нас их более 1 000, и в них развернуто не менее 4 000 серверов баз данных. Управление такой системой требует инструментов совсем другого класса.

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

В этой статье я описал создание в AWS состоящего из трех нод кластера Docker Swarm и подключение к нему общего для всех нод реплицируемого тома GlusterFS.

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

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.