6-7 декабря в Москве состоялась пятая по счёту конференция «Гейзенбаг».
Её слоган — «Тестирование. Не только для тестировщиков!», и за два года регулярного посещения «Гейзенбагов» мне (прежде Java-разработчику, ныне — техническому лиду в маленькой компании, никогда не работавшему в QA) удалось многому научиться в области тестирования и многое внедрить в нашей команде. Я хочу поделиться субъективным обзором запомнившихся мне на этот раз докладов.
Меня зовут Роб Стакл, я консультант по безопасности из Феникса, штат Аризона, и в основном работаю пентестером. Я участвую в конференциях DefCon с 1996 года, увлекаюсь высотной фотографией, а в эти выходные была одиннадцатая годовщина нашей свадьбы. Я хочу поблагодарить мою удивительную и понимающую жену Линду, которая не ожидала, что моё участие в DefCon означает, что каждый год я буду вынужден проводить годовщину нашей свадьбы в Вегасе, о чём я очень сожалею.
Я собираюсь поговорить с вами о нескольких вещах, связанных с исследованиями, над которыми я работал несколько последних лет. Их объединяет общая тема — если вы не мониторите свой DNS трафик и не понимаете, что там происходит, когда всё в порядке, то вы наверняка не обратите внимания, когда с ним начнут происходить плохие вещи. Я «насиловал» DNS в течение нескольких лет и это всегда было одним из моих любимых векторов атаки. Вы можете потратить целое состояние на упрочнение периметра сети, но если я могу получить контроль над одним из ваших устройств, поверьте мне, ваша игра закончена.
Чему армия могла бы научить тестировщика? Как выглядят две крайности в подходах к тестированию? Как объяснить, что технический долг платежом красен? Что есть общего у предыдущих вопросов?
Общее то, что при всей их разнице, они все близки одному человеку. У Джима Холмса за спиной несколько десятилетий IT-опыта, начавшегося в 80-х в ВВС США — неудивительно, что он готов рассказать о многом. Для него важно понятие «testing culture», и мы задали ему вопросы, которые могут очень сильно различаться, но в конечном счёте так или иначе связаны с культурой тестирования.
Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год
Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.
Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона: а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?
И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.
Господа! На фотографии Ирина, девушка из Новосибирска, рассматривает музейную экспозицию про персональные компьютеры 1980-х годов. Именно тогда, в 1980-х, окончательно произошел весьма неприятный разрыв между западной электроникой и советской. Если в 1970-х советская электроника просто отставала лет на 7 (если судить по датам выхода DEC PDP-11 и СМ-4), то в районе 386-го она просто померла.
Одновременно в конце 1980-х на Западе появилась технология логического синтеза из языков описания аппаратуры Verilog и VHDL. Эта технология стала мейнстримом в 1990-х и в конечном итоге в 21 веке привела к айфонам и нейроускорителям. Логический синтез ввели во всяких MIT и Стенфордах вместе с лабами на ПЛИС-ах еще в 1990-е, но в России и Украине того времени пораженческие настроения и неверие в отечественную электронику привели к тому, что исправлять ситуацию предстоит нам сейчас.
Для того, чтобы построить в России экосистему разработки электроники, с сотнями компаний, а не дюжиной, как сейчас, нужно делать то, что делали в США в 1990-х и делают сейчас в Китае: выучить кучу молодых инженеров принципам логического проектирования цифровых схем на уровне регистровых передач. Даже если не все из них будут проектировать микропроцессоры и сетевые чипы, а половина пойдет в чистое программирование, эти знания не пропадут зря: время повышения быстродействия компьютеров за счет уменьшения транзисторов подходит к концу, и везде наступают гибридные софтверно-хардверные решения, со специализированными аппаратными вычислительными блоками — об этом недавно даже произнес речь Джон Хеннесси, председатель совета директоров компании Alphabet / Google.
Я это все говорю к тому, что она днях в Новосибирске пройдет одно из мероприятий по вытаскиванию России из неразвитого состояния в данной области.
Как можно научиться тому, чему тебя никто не может научить?
Все успехи своей карьеры я отношу на счёт моей способности к неструктурированному обучению. Такого рода обучение требуется при погружении в область знаний, находящуюся на переднем крае исследований, при попытках разобраться в новой работе или создать что-то совершенно новое. Это полная противоположность тому, чему нас учат в школах, и что большинство людей зовёт «образованием».
Во время структурированного обучения (такого, как в школе) существуют упражнения, учителя, способные вами руководить, и проторённая дорожка из точки А в точку Я. Самое тяжёлое здесь – ежедневно заниматься работой.
Такой процесс должен быть знаком всем. Большая часть людей проводит первые два десятилетия их жизней, выполняя небольшие, дискретные задачи структурного обучения, соревнуясь со своими одноклассниками по легко определяемой шкале. Подобное структурное обучение вне классов или телевизионных викторин практически бесполезно.
В реальном мире нет никаких учебников или учебных планов. Нет возможности практиковаться. Нет источника постоянной обратной связи. Нет учителей – есть только вы, и те люди, которых вы можете убедить помогать вам.
Делимся с вами очередным открытым уроком, который прошёл у нас в рамках курса «Разработчик Java». На нём преподаватель курса, Владимир Сонькин, рассказывал про асинхронное программирование почему оно позволяет делать код быстрым и эффективным, не используя сложные технологии распараллеливания. Также показывал примеры применения асинхронности для построения процессов обработки данных в бизнес-приложениях.
Как всегда ждём комментарии, вопрос, которые можно оставить тут или зайти на день открытых дверей.
Добрый день, уважаемые хабровчане!
После длительного перерыва, связанного с защитой дипломного проекта в Бауманке, я снова вернулся к написанию статей. Так как с недавнего времени я занялся 32-битными микроконтроллерами серии STM32F на ядре ARM Cortex-M3, об этом и пойдет мой рассказ. Мне статья поможет систематизировать знания об этих замечательных микроконтроллерах, а вам, я надеюсь, послужит одной из ступеней на пути к их использованию и развеет страхи и сомнения, которые всегда возникают после уютных 8-битных AVRок при упоминании страшных 32-битных монстров.
Итак, почему Cortex, чем же плохи АVR?
В Java для введения порядка среди определённых объектов можно написать компаратор — класс, содержащий функцию compare, которая сравнивает два объекта. Альтернативой компаратору является естественный порядок объектов: объект реализует интерфейс Comparable, который содержит метод compareTo, позволяющий сравнить этот объект с другим. Сравнивающая функция должна вернуть 0, если объекты равны, отрицательное число (обычно -1), если первый объект меньше второго, и положительное число (обычно 1), если первый больше. Обычно реализация такой функции не представляет сложностей, но имеется один случай, о котором многие забывают.
Сравнение используется различными алгоритмами от сортировки и двоичного поиска до поддержания порядка в сортированных коллекциях вроде TreeMap. Эти алгоритмы завязаны на три важных свойства сравнивающей функции: рефлексивность (сравнение элемента с самим собой всегда даёт 0), антисимметричность (сравнение A с B и B с A должны дать разный знак) и транзитивность (если сравнение A с B и B с C выдаёт одинаковый знак, то и сравнение A с C должно выдать такой же). Если сравнивающая функция не удовлетворяет этим свойствам, алгоритм может выдать совершенно непредсказуемый результат. Причём скорее всего вы не получите никакого исключения, просто результат будет неверный.
Как обнаружилось, несоблюдение этих свойств — не такая уж редкая ситуация. Проблема возникает при сравнении вещественных чисел — float или double.
В статье об онлайн-курсе «Введение в Linux» на образовательной платформе Stepic мы обещали рассказать о технической реализации нового типа интерактивных задач, который был впервые применен в этом курсе. Этот тип задач позволяет создавать на лету виртуальные серверы с Linux для работы через веб-терминал прямо в окне браузера. Автоматическая проверяющая система следит за корректностью выполнения заданий.
Пример задания из курса:
В этой статье я хочу рассказать о проекте, который лег в основу нового типа заданий на Stepic. Я также расскажу о том, из каких компонентов состоит система, и как они взаимодействуют между собой, как и где создаются удаленные сервера, как работает веб-терминал и автоматическая проверяющая система.
Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.
В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.
Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.
Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.