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

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

^{Ушенина (на фото слева, играет белыми) — Гиря (на фото справа, играет чёрными). Ничья.
Гран-При среди женщин, 4-й тур
6 мая 2013 года, Женева}

В 2013 ходу российский гроссмейстер Ольга Гиря в безнадёжной позиции, вместо того, чтобы сдаться, применила нестандартное читерство.

Имея на две фигуры меньше, она нашла остроумный способ добиться ничьей с чемпионкой мира (на тот момент) Анной Ушениной. Ольга просто разменяла всё, что только можно и свела партию к эндшпилю «король + слон + конь VS король». Украинская шахматистка полсотни ходов безуспешно пыталась заматовать вражеского короля, после чего результат партии был признан ничейным.

Обидная ничья существенно повлияла на результат Ушениной в турнире. Она заняла 5-6 место, а выигрыш позволил бы разделить бронзу (3-5 место).

Современный веб состоит из множества разных технологий, которые предоставляют самые разные возможности… но ещё и создают немалое количество угроз. Современные браузеры давно стали самыми сложными приложениями на компе, обогнав по сложности даже ядро ОС (в Firefox в несколько раз больше строк кода, чем в ядре Linux или офисных пакетах). Мы проводим в браузере большую часть своего времени, так что не удивительно, что браузер находится под прицелом: его постоянно пытаются взломать, использовать в ботнете, пытаются украсть из него наши данные, прослушать его трафик, отслеживать посещаемые нами сайты и наши действия на этих сайтах.

Сейчас самое время сказать, что всё не так уж плохо, и со всеми этими проблемами можно справиться… но это не так. Из коробки браузеры уже делают немало: регулярно обновляются, стараются затыкать дыры в безопасности, внедряют новые технологии для защиты, предоставляют возможность расширять их функционал сторонними расширениями. Но серьёзной защиты из коробки нет, и вряд ли она когда-нибудь появится: она идёт в комплекте с усложнением интерфейса браузера и частичным отключением его функционала, что "ломает" сайты и вряд ли понравится обычным пользователям. Но самое печальное, что даже такой ценой невозможно полноценно защитить браузер — слишком уж он стал сложным.

Тем не менее, для усиления защиты браузера можно много чего сделать.

От переводчика: перевели для вас статью Илада Леева о переходе с Python на Go. Статья будет полезна не только начинающим программистам, но и всем, кто так либо иначе интересуется Go.

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

Постепенное «созревание» Go, обширное комьюнити и тот факт, что все больше компаний принимают этот язык на вооружение после успешных тестов, заставили меня обратить на него внимание и углубиться в литературу. Но этот пост не о том, что лучше — Python или Go: сравнений в сети огромное количество. По моему мнению, все зависит от области применения. Я собираюсь рассказать о том, почему выбрал Go, дав несколько советов и ссылок на полезные ресурсы для всех интересующихся темой.

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

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

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

От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.

---

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

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.

Содержание

• 1. Антипаттерны: плохое обоснование
  
  • 1.1. Очевидно же
  • 1.2. Мамой клянусь!
  • 1.3. Зайчики обиделись
• 2. Хорошие паттерны обоснования
  
  • 2.1. Пруфлинк
    
    • Ссылка на требования
    • Сами требования
    • Ссылка в интернет
    • Письмо заказчика
    • ROI
    • Статистика
  • 2.2. Единообразие
  • 2.3. Проблема, или #жизньболь
• 3. Когда обоснование не нужно
• 4. Итоги

Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:

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

А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:

— Почему это баг??

Например, там написано: «Загружаем отчет, получаем 57,6. А должно быть — 57.9».



Если записать обоснование, это решит проблемы:

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

См также:
Зачем нужно обоснование в баге — более подробно о том, зачем вообще обоснование.

Через меня прошли сотни начинающих тестировщиков (студентов). Вот как раз на их задачах я и начала задаваться вопросом «А почему это баг?»… Спрашиваешь ребят, а в ответ получаешь «Да это же очевидно!». Ну как-то не очень =))

Через кучу задач и вопросов «А почему?» стали вырисовываться паттерны ответов. Я выделила хорошие и плохие паттерны. О них и хочу рассказать.

Эта статья для:

• начинающих тестировщиков — узнайте, как грамотно объяснять свою точку зрения;
• тест-менеджеров — чтобы дать ссылку своим падаванам и потом ссылаться на антипаттерны без дополнительных объяснений.

1. Антипаттерны: плохое обоснование

Любая интернет-компания обязана тайно изменить программный код по требованию властей

6 декабря 2018 года парламент Австралии принял Assistance and Access Bill 2018 — поправки к Telecommunications Act 1997 о правилах оказания услуг электросвязи.

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

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

Современная DDR3 SDRAM. Источник: BY-SA/4.0 by Kjerish

Во время недавнего посещения Музея компьютерной истории в Маунтин-Вью моё внимание привлёк древний образец ферритовой памяти.


Источник: BY-SA/3.0 by Konstantin Lanzet

Есть такой Тверской вагоностроительный завод. Завтра у него день рождения. Поэтому тут я расскажу кое-что интересное про сам завод.

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

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

Давайте начнём экскурсию.

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

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

Статья опубликована 21 мая 2018 года

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

Разобравшись с самыми распространёнными заблуждениями о GDPR, давайте посмотрим на реальное влияние GDPR. Затем рассмотрим наиболее важные полезные советы для владельцев сайтов.

В любом законе кроме его буквального текста есть ещё дух закона, его предназначение. В данном случае предназначение GDPR состоит в том, чтобы обуздать корпорации, которые проявляют худшие практики ведения бизнеса в интернете с нарушением конфиденциальности пользователей. Законодатели стремятся вернуть контроль над данными обратно владельцам этих данных — частным лицам, которые здесь являются субъектами (отсюда термин «субъекты данных»). Есть бесчисленное множество примеров таких нарушений. Не собираюсь их здесь перечислять — на это просто не хватит времени. Но будьте уверены: положение дел таково, что регулирование не начнёт действовать быстро. Постоянные читатели моего блога знают, что тема конфиденциальности мне дорога, поэтому я приветствую GDPR и надеюсь, что закон приведёт к желаемому эффекту. Судя по количеству писем от компаний, которые почти умоляют меня разрешить им присылать спам и дальше — вероятно, это единственный закон, который явно положительно повлиял на мою жизнь ещё до того, как вступил в силу. (По иронии судьбы, эти компании нарушают закон, рассылая такие сообщения…).

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология

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


Если не видели пирамиду тестов, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Большое спасибо за то, что пришли меня послушать! То, о чём я буду говорить, отличается от выступлений предыдущих спикеров. Сначала я хочу поблагодарить людей, которые помогали мне в подготовке этого выступления. Некоторые из них смогли тут присутствовать, некоторые нет. Это Алан Митчел, Рон МакГайер, Крис Тейлор и Кэти Херитадж и ещё несколько человек, которые захотели сохранить анонимность, поэтому их имена напечатаны на этой картинке чёрным цветом.



Мой сосед меня реально достал, а его ребёнок достал меня вдвойне! Меня раздражают его… сопли, можете заменить «сопли» более подходящим словом из четырёх букв! Но самая большая проблема возникла, когда у соседского парня появилось вот это – квадрокоптер с видеокамерой.



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



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

Я стал искать варианты адекватного ответа. Может быть, это?

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

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

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

В этой статье — истории реальных программистов и их профессиональных фобий, которые мешали им жить и работать в свое удовольствие. Люди реальные, имена вымышленные.

Некоторые песни навсегда связаны в нашем сознании с определенными фильмами или даже ключевыми сценами. Песня Селин Дион My Heart Will Go On — это любовная история Джека и Розы на Титанике. Её же песня All by Myself обязательно напомнит о предрождественской тоске Бриджит Джонс. Но есть песни, которые звучат настолько часто, что они не просто не закрепляются в зрительском сознании за определенным фильмом, сериалом или сюжетом, но могут вызвать и обратную реакцию: «О, нет, опять».

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

Консервная банка без экипажа, которая после взлета падала в океан (по мнению А.И. Попова)

«Против глупости сами Боги бороться бессильны!»
Фридрих Шиллер

Неутомимый борец с историей программы «Аполлон», доктор физ-мат наук А.И. Попов в 2012 написал статью «Краткая история американской лунной ракеты», в которой попытался доказать, что ракета Сатурн-5 не отправляла к Луне ни один из Аполлонов 8, 10, 11, 12, 13, 14, 15, 16, 17. По его мнению, Лунной Одиссеи 1968 не было вообще! Некоторые домыслы из статьи Попова выглядят довольно убедительно, а его докторская степень по физике вдохновляет сторонников лунной конспирологии (в дальнейшем «луноборцев»), которые в России составляют уже подавляющее большинство, а в мире их число растет эпидемически. При этом луноборцы, как правило, не сомневаются в программе Аполлон… поскольку они «точно знают», что США сняли ее в Голливуде и навязали человечеству при соучастии СССР.

Статья «Краткая история американской лунной ракеты» состоит из 5-ти независимых разделов и заключения о том, что Сатурн-5 не только никогда не отправлял людей к Луне, но даже на околоземную орбиту был не способен вывести ни грамма груза. Все заявления А.И. Попова разделены на основные тезисы, которые тщательно рассмотрены по одному. Скучно не будет.

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

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

---

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

Ещё один любопытный эксперимент, в котором участвовало 45 тыс. человек. Заходишь на сайт, тебе показывают статью Дэвида Дойча, британского физика. В статье автор пишет, что сегодня очень трудно внезапно умереть. Например, от инфекционного заболевания или в уличной драке. Лет сто назад это случалось намного чаще. Главный вывод статьи — сейчас мир безопасен как никогда. В среднем, конечно, ведь где-то постоянно идут локальные военные конфликты.