Конференция DEFCON 17. Мои неудачи. Часть 1

Вопрос: можете сказать нам о легенде, которую никогда не станете развенчивать?

Адам Сэвидж: думаю, существует несколько таких легенд. Если вы видели наши передачи, то заметили, что мы стараемся не делать скучных вещей типа сравнения вешалки с высококлассным аудиокабелем. Не думаю, что этот эпизод стоит показывать. Я просто хочу сказать, что в свое время мы исследовали миф, связанный с большим количеством жидкого кислорода. Разрушители легенд работают с разными взрывчатыми веществами, но ничего не пугает меня больше, чем горючие газы. Но эти газы сущая ерунда по сравнению с жидким кислородом. Это действительно страшная штука, и когда мы начинали изучать связанные с ним материалы, то прочитали о том, что эксперименты с этим веществом абсолютно не предсказуемы.



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

Вопрос: вы можете рассказать про самый грандиозный провал «Разрушителей легенд»?

Данная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6.
С шифрованием TLS. С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.

Если вы не хотите изучать эти все технологии, но хотите настроить такой сервер — тогда эта статья для вас.

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

29 марта инженер по имени Жерард Вильямс Третий ушел из компании Apple. Это известие сразу опубликовал CNET и еще три десятка изданий во всем мире, не только технических, но и финансовых. Что же такого делал этот инженер, что его уход вызвал волнение среди биржевых спекулянтов? Он 9 лет проектировал процессоры в Apple iPhone, до этого 12 лет работал в ARM, до этого проектировал DSP в Texas Instruments, а до этого разрабатывал в Интеле схемы на ПЛИС. Во всех местах он использовал технологию проектирования на уровне регистровых передач, с использованием языков описания аппаратуры Verilog и VHDL.

Примеры поближе к России? На фото справа: 25-летний москвич Илья Неганов взял в 2011 году книжку Харрис & Харрис (последнюю версию которой можно скачать здесь или здесь), спроектировал простой процессор, сейчас работает в Apple, проектирует на верилоге GPU, по выходным летает на самолетике. Ниже пара молодоженов из Санкт-Петербурга, которые проектировали на верилоге и ПЛИС обработку изображений из камеры и получили приз на конкурсе Innovate FPGA. Они провели медовый месяц в штаб-квартире Интела в Санта-Кларе. Далее товарищи из Киева, двое из которые выиграли бронзу на европейском финале Innovate FPGA. И наконец два школьника, из 5 и 9 классов, которые делают свои первые упражнения с микросхемами малой степени интеграции на макетной плате, после чего приступают к упражнениям на верилоге и ПЛИС.

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

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

Проблемы исключений

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

Исключения трудно заметить

Существует два типа исключений: «явные» создаются при помощи вызова raise прямо в коде, который вы читаете; «скрытые» запрятаны в используемых функциях, классах, методах.

Проблема в том, что «скрытые» исключения и правда трудно заметить. Покажу на примере чистой функции:

def divide(first: float, second: float) -> float:
    return first / second

Функция просто делит одно число на другое, возвращая float. Типы проверены и можно запустить что-то такое:  

result = divide(1, 0)
print('x / y = ', result)

Заметили? На самом деле до print исполнение программы никогда не дойдет, потому что деление 1 на 0 – невозможная операция, она вызовет ZeroDivisionError. Да, такой код безопасен с точки зрения типов, но его все равно нельзя использовать.

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

С какими проблемами сталкивались мы и наши клиенты при организации удаленной разработки ПО для устройств, как их решали, и откуда «растут ноги» у Redd, программно-аппаратного комплекса удаленной разработки ПО для встроенных систем. Почему появилась эта «коробка», и как изменится жизнь (опять же, мнение автора) миллионов разработчиков embedded-систем, устройств интернета вещей, оборудования для авто, самолётов, связи.

Проект-менеджерам (и тем, кто мечтает стать начальником) посвящается.

Писать тонны кода сложно, а управлять людьми — еще сложнее! Так что вам просто необходима эта книга, чтобы научиться делать и то и другое.

Можно ли объединить прикольные истории и серьезные уроки? Майклу Лоппу (также известному в узких кругах как Рэндс) это удалось. Вас ждут выдуманные истории о выдуманных людях, обладающих невероятно полезным (хотя и выдуманным) опытом. Именно так Рэндс делится своим разнообразным, порой странным опытом, полученным за годы работы в крупных IT-корпорациях: Apple, Pinterest, Palantir, Netscape, Symantec и др.

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

Эта книга не похожа ни на один манускрипт по менеджменту или лидерству. Майкл Лопп ничего не скрывает, он просто рассказывает всё как есть (возможно, не все истории стоило бы предавать огласке: Р). Но только так вы поймете, как вам выжить с таким боссом, как руководить гиками и нердами и как уже довести до хеппи-энда «тот гребаный проект»!

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

Привет, Хаброжители! Эта книга Ноя Гифта предназначена для всех, кого интересуют ИИ, машинное обучение, облачные вычисления, а также любое сочетание данных тем. Как программисты, так и просто неравнодушные технари найдут тут для себя полезную информацию. Примеры кода даны на Python. Здесь рассматривается множество столь продвинутых тем, как использование облачных платформ (например, AWS, GCP и Azure), а также приемы машинного обучения и реализация ИИ. Джедаи, свободно ориентирующиеся в Python, облачных вычислениях и ML, также найдут для себя много полезных идей, которые смогут сразу применить в своей текущей работе.

Предлагаем ознакомиться с отрывком из книги «Создание интеллектуального бота Slack в AWS»

После многолетнего опыта работы с php и js, я привык иметь в ошибках стектрейс и смотреть на место, где произошла ошибка прямо из эррор-репорта. Пересев на Go пару лет назад, я был несколько удивлен, что в Go другие правила и нужно угадывать стектрейс по какой-нибудь строке типа `invalid character`. А если она произошла на проде и не известно, как ее воспроизвести, то это превращалось в целый аттракцион.

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



→ GitHub

Прим. перев.: Оригинальную статью написал Miłosz Smółka — один из основателей небольшой польской компании Three Dots Labs, специализирующейся на «продвинутых backend-решениях». Автор опирается на свой опыт активной эксплуатации GitLab CI и делится накопленными советами для других пользователей этого Open Source-продукта. Прочитав их, мы поняли, насколько нам близки описанные им проблемы, поэтому решили поделиться предлагаемыми решениями с более широкой аудиторией.



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

Небольшая предыстория

После лекции на HighLoad++ 2017. Я посмотрел этот доклад, “Как мы админа увольняли”, в записи. Докладчик сказал, что все web компании испытывает проблемы с паролями, и у меня появилась идея как это решить. Скорее всего кто-то уже сделал, но, если честно, я не знаю просто хочу описать, потом может, кто-то сделает или я как-нибудь сам сделаю. Надеюсь, если кто-то решит сделать, что-то подобное это будет opensource.

Собственно описание проблемы и способа её решения

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

Есть два варианта решения такой проблемы.

1. Выкладывать все изменения на сайт лично руководителю компании.
2. Что-то придумать и сделать.

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

Что делать определились, теперь нужно определиться как это сделать.

Вот сразу самая простая идея, а почему не сделать proxy? Ну скорее всего супер-прокси. Схема работы в принципе проста и я её нарисовал ниже.


Рисунок 1 – общая схема работы системы

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

Его задачи следующие:

• Соответственно принимать трафик, или даже стоит работать на уровне команд SSH и SFTP, для начала, и отправлять ответ от сервера клиента, специалисту.
• Аутентификация и авторизация специалиста
• Проверка легитимности команд, это можно сделать позже.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

Хранимые объекты без головной боли: простой пример работы с объектами Caché на языках ObjectScript и Python

Замок Нойшванштайн

В июне 2020 года ровно 50 лет табличным хранилищам данных или говоря формально — реляционной модели данных. Вот официальный документ – та самая знаменитая статья. За что говорим огромное спасибо доктору Эдгару Фрэнку Кодду. И, между прочим, реляционная модель данных входит в список важнейших мировых инноваций последних 100 лет по версии Форбса.

С другой стороны, как ни странно, Кодд считал реляционные базы данных и язык SQL искаженной реализацией своей теории. В качестве ориентира, он даже разработал 12 правил, которым должна удовлетворять каждая система управления реляционными базами данных (на самом деле это 13 правил). И, по правде говоря, на сегодня, в мире не найти СУБД удовлетворяющих хотя бы «Правилу 0» Кодда и, следовательно, никто не может называть свою СУБД на 100% реляционной :) Может есть исключения, подскажите?

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

Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

Data Science — наука о данных, возникшая на стыке нескольких обширных направлений: программирования, математики и машинного обучения. Этим обусловлен высокий порог вхождения в профессию и необходимость постоянно получать новые знания.

Ключевыми навыками для начинающих специалистов являются:

• умение писать код (Python);
• способность визуализировать свои результаты;
• понимание того, что происходит «под капотом».

На эти три категории разделены книги, которые специалисты Plarium Krasnodar подобрали для читателей с начальными знаниями в Data Science.

Привет.

Как я уже писал недавно (Первая краткая статья о MQTT/UDP), MQTT/UDP — протокол на базе MQTT, но:

• Ходит поверх UDP broadcast (не нужен брокер, почти не нужна конфигурация)
• До неприличия простой в реализации (10 строк на си + UDP/IP стек — и вы отправляете данные с сенсора)
• Все слышат всех

В некотором смысле это CAN, но поверх Ethernet-а.

Зачем.

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

Первый слой – кто хочет?

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

Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?

Если собрать всех – например, программистов – и спросить: кто хочет что-то изменить в отделе, компании или отрасли? – то руки поднимут больше половины. Почему до конца, до реальных изменений, полезных и заметных, доходят эти несчастные доли? Где, и почему теряются остальные?

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


Ой, не то. Вот так:


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

Итак, первый, самый широкий слой воронки – те, кто поднял руку.

Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.

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

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

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

Иногда молодые команды разработки охватывает неразбериха.

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

У нас тоже была похожая история, но мы нашли свой путь.

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

Как всё было