Таблицы Markdown — это ад кромешный:

1. В ячейках нельзя написать текст длиннее пары слов, а тем более список.
2. Если диалект и позволяет пункт 1, это неудобно форматировать.
3. Если ячейки не выровнены, таблицу невозможно читать.
4. Нет поддержки однотипных таблиц и автоматики, вроде нумерации строк.

Пришло время написать фильтр для Pandoc, рисующий таблицы из структурированного YAML, с нумерацией строк, горизонтальной ориентацией, шаблонами граф, и заодно разобраться, как писать Lua-фильтры.

Когда-то давным давно, когда я еще учился в школе, а на дворе был конец перестройки, мой дядя (заронивший в меня интерес к электронике) припер домой сумку вынесенного через проходную завода добра. Собственно, такие сумки он приносил домой вполне регулярно, пополняя запасы, хранившиеся в диване. Диван этот, как вы догадываетесь, манил, и иногда в отсутствии дяди я в него заглядывал с восторгом. Но кое-что из этой сумки в диван не попало, а попало в мои руки. Дядя мне вручил пачку — штук десять — макетных плат, и новенькую нераспечатанную коробку дефицитных, да и не дешевых в то время светодиодов. Причем светодиоды были не простые: вместо привычной маркировки АЛ-что-то там на коробке стоял код из четырех цифр, как я понял — они были экспериментальные. И они были яркие. По сравнению с привычными АЛ307 или АЛ310 — просто ослепительные. И их к тому же было много — штук 50.

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

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

Всем добрый вечер!

Вот и осталось всего ничего (то есть один день) до запуска потока курса «DevOps практики и инструменты», а значит нам надо успеть за это время довыложить оставшиеся части статьи «Почему важна SRE документация».

Продолжаем.

Документы для Онбординга Нового Сервиса

SRE проводят PRR (production readiness review, обзор готовности производства) для проверки соответствия сервиса стандартам операционной готовности, а также чтобы убедиться, что владельцы сервиса понимают, как пользоваться знаниями SRE для управления большими системами.

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

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

Обновлённая поддержка прокси-серверов в клиентах Telegram

• Новый MTProto-прокси. Работает с родным для Telegram протоколом MTProto
• Открытый исходный код сервера на GitHub
• Docker-образ на DockerHub
• В мобильных клиентах появилась возможность добавлять несколько прокси-серверов каждого типа. Пользователь может выбрать наиболее подходящий
  

Короче, настало время. Присаживайтесь поудобнее

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

Дисклеймер: это не пост хейта или срача на тему «компании — вон с Хабра!», а вполне обоснованный текст на тему того, что стоит делать, чего не стоит делать и как с этим дальше жить. Он зрел в моей голове не один месяц, учитывая, что я уже пятый год зарабатываю на хлеб с маслом написанием постов. Надеюсь, что текст найдет отклик у аудитории и ситуация на платформе немного улучшится.

Этим постом я хочу достучаться до многочисленных маркетологов, которые пасутся на моей родной «полянке» и тут же делают не самые приличные вещи, которые, в итоге, бьют и по мне в том числе. А еще я хочу поговорить с аудиторией.

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


Уже 25 мая угроза штрафа в 20 млн Евро или 4% от мирового оборота (что из этого больше) станет реальностью – впадать в панику или не впадать? Поскольку я уже ливанул ведро бензина в огонь, чувствую себя обязаным показать дорогу к пожарному выходу, не дожидаясь анонсированного в предыдущей статье события. Зарание прошу прощения за шероховатости – экспромт, очень fast и очень dirty, зато полезность зашкаливает (надеюсь).

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

Как выглядит трек обучения программированию на Python с нуля? С чего стоит начать? На чем сделать акцент? Как не потерять интерес?

Полгода я искал ответы на эти вопросы, тщательно исследуя предметную область. Я обнаружил много полезных советов. Особенно в заметке Василия Большакова и на Хекслете. Но мне не хватало структуры. Знания нарастали со всех сторон и превращались в кучу. Чтобы структурировать процесс обучения и оценить его масштаб, я собрал план.

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

Сегодня мы поговорим о внедрении микросервисной архитектуры в Центре Финансовых Технологий (ЦФТ) — группе компаний, работающих в области информационных технологий для финансового сектора с 1991 года. То есть это организация, где качество продукта чрезвычайно важно, от него зависят реальные деньги.

В свою очередь, Владимир Плизга последние 6 лет погружен в разработку бэкенда интернет-банков и сопутствующих сервисов в ЦФТ, где активно топит за микросервисы и прочие модные штуки. Чтобы пообщаться с ним, я приехал прямо в офис ЦФТ, сделал сэлфи и обязательную фотку красного слона :-)

Обсуждаемые темы:

• Зачем нужны микросервисы;
• Как с ними жить (судьба REST и SOAP, statefull vs. stateless, переход от монолита к микросервисам, совместимость с legacy и многое другое);
• Микросервисные технологии (Spring Cloud Netflix, Zuul, ...), какие с ними проблемы, что нужно допиливать;
• Документация: на русском или английском? Написание и генерация документации (Swagger, SpringMVC, SpringFox). Архитектурные диаграммы — нужны ли, в чем рисовать, как хранить;
• Мониторинг, восстановление от сбоев;
• Ну и самое главное: стоит ли игра свеч?

(слева — Владимир, справа — olegchir)

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

Это Иван Бакаидов — программист, автор на Хабре, панк, девятнадцатилетний гражданин Российской Федерации, инвалид первой группы по причине Церебрального паралича.

В прошлом году я прочитал статью «Как узнать какие цветы дарить девушке, если у нее двигается только голова и она не может говорить?», она поразила меня похлеще чем «Смотря на код с закрытыми глазами».

Интервью с Иваном ibakaidov. Есть над чем подумать.

Расскажи, как впервые увидел компьютер? Как заинтересовался программированием и как учился?

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

А вот посадить меня за него предложили в институте раннего вмешательства. Это питерская организация, активная в 1990х, 2000х годах. Они собрали прогрессивных специалистов в сфере реабилитации и много сотрудничали с западом.

Основной идеологией было: «Не надо делать из человека здорового, надо научить его удобно жить», что до сих пор противоположно политике Минздрава и большинства больниц, а на самом деле задай себе вопрос: «Что надо человеку: ходить или перемещаться?» или же «говорить или общаться?»

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

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

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

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

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

Что существенно?

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

Аудитория: Java Junior, любители холиворов, профессиональные написатели синглтонов

Любые замечания и предложения — очень приветствуются. Это мое первое видео, и не совсем понятно, нужен ли тут вообще такой контент. Считайте это закрытым альфа-тестом, только для посетителей хаба Java :)

Ниже дана полная текстовая расшифровка, кому не хочется тратить время на просмотр.

Καλημέρα! (Доброе утро!) В этот раз мы приветствуем вас из греческого города Гераклиона.

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

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

Целью статьи является описание процедуры установки современного движка XenForo для разворачивания форумов c использованием кэширования на базе memcached и мощнейшего поискового движка ElasticSearch. Эти сервисы будут работать внутри Docker контейнеров и разворачиваться и управляться через интерфейс Plesk.

Кроме того, в статье затронуты вопросы более широкого использования Elastic Stack (ElasticSearch+Logstash+Kibana) в контексте Plesk для анализа данных. Например, анализа поисковых запросов на форуме и анализа логов сервера.

Вышел GitLab 10.0 с Авто-DevOps, групповыми досками задач, новой навигацией и множеством других фич.

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

Вышел GitLab 9.4: Связанные задачи и веб-мониторинг приложений

В GitLab 9.4 мы представляем связанные задачи, веб-мониторинг приложений, обновленную навигацию, групповые майлстоуны и многое другое!

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

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

Эта статья продолжает первую часть, содержащую подробное описание нашего пайплайна:



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

Итак, я остановился на том, что созданный .gitlab-ci.yml не позволяет реализовать пайплайн в полной мере, поскольку GitLab CI не предоставляет директив для разделения задач по пользователям и для описания зависимостей выполнения задач от статуса выполнения других задач, а также не позволяет разрешить модификацию .gitlab-ci.yml только для отдельных пользователей.

Обновление: у этой статьи появилось продолжение, переведённое @achekalin. В каком порядке читать — на ваше усмотрение: в этой статье можно получить удовольствие от обширной попоболи автора, а в продолжении — от сделанных им выводов.

Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.

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

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

У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).

Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.