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

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

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

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

Мы рассмотрим такие аспекты как:

1. Понимание различных подходов к моральным рассуждениям людей в различных (или одинаковых) ситуациях
2. То, как закон, общество и страховка относятся к рискованному вождению, авариям и несчастным случаям.
3. Риски и потери при вождении (или обучении вождению), которые мы, похоже, охотно принимаем для получения небольших преимуществ.
4. Как меняется наш взгляд на то, что «цель оправдывает средства» в зависимости от того, о чем идет речь: преднамеренные злодеяния или небольшие осознанные риски.
5. Большие преимущества, которые мы получим, когда небольшой автопарк автономных автомобилей научится водить более безопасно, после чего их программное обеспечение будет скопировано в миллионы других машин – ситуация, которая невозможна в случае с водителями-людьми.
6. Риски и принципы современных подходов к тестированию и разработке автономных автомобилей, и то, как Uber их нарушил.
7. Огромная выгода, если мы сможем найти правильный подход.

Привет, Хабр!

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Signs You Will Suck at Programming» автора Jonathan Bluks.



Очень часто на Reddit или Quora я вижу вопросы вида «Как понять, смогу ли я стать успешным программистом?» (На самом деле, эта статья является расширенным продолжением моего недавнего ответа на Quora.) Когда кто-то задумывается о смене карьеры или интересуется разработкой и хочет знать, что для этого требуется, неизбежно возникает этот самый вопрос.

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

Будучи преподавателем на курсе «Full-stack Web-development», я работал со многими программистами-новичками. Хорошая новость в том, что мне редко встречались студенты, которые вообще не могли научиться программировать. Я считаю, что умение программировать — такой же базовый навык, как умение читать, писать и считать. Это под силу любому, так как это одна из способностей человека, но этому действительно надо учиться.

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

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

А разве у них есть поверхность? Ведь все привыкли к представлению о черной дыре как о сингулярности скрытой от нашего взора горизонтом события. Впрочем, исследуя термодинамику черных дыр, физики давно пришли к выводу, что они ведут себя не как трехмерные, а как двухмерные объекты. Например, количество составных частей черной дыры как термодинамической системы, пропорционально квадрату радиуса горизонта события, а не его кубу. Но данный «прозрачный намёк» принято относить скорее к проблемам, таким как: Куда девается информация провалившаяся за горизонт события? Если из двух квантово запутанных частиц одна пересекла горизонт события, то с чем запутана оставшаяся?

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

EricGrig

Предисловие

Я хотел бы начать предисловие со слов благодарности двум замечательным программистам из Одессы: Андрею Киперу (Lohica) и Тимуру Гиоргадзе (Luxoft), за независимую проверку полученных мною результатов, на начальном этапе исследования.

1. Статья «Linear algorithm for solution n-Queens Completion Problem» была опубликована в (arXiv.org) в начале первого дня 2020 года. Изначально статья была написана на русском, поэтому здесь представлено базовое изложение, а там — перевод.
2. Данная задача, и некоторые другие из множества NP-Complete (задача выполнимости булевых формул (3-SAT), задача о поиске максимальной клики, или клики заданного размера …) в разное время, входили в сферу моих интересов. Я искал алгоритмическое решение на основе различных вычислительных экспериментов, но конкретного успеха не было. Это было похоже на то, как человек пытается научиться подтянутся на турнике на одной руке. Результата нет, но каждый раз появляется надежда, что скоро все получится. Последний раз я решил, что следует подольше остановиться на задаче n-Queens Completion (как одной из представителей семейства) и попытаться что-то сделать. Здесь уместно вспомнить замечательный Одесский анекдот: «В переполненном автобусе, который вечером по ухабистой дороге возвращается в пригород, раздается голос женщины – Мужчина, если уж полностью на меня легли, так сделайте хоть что-нибудь».
3. Исследование длилось достаточно долго – почти полтора года. С одной стороны, это связано с тем, что в процессе исследования, рассматривались и другие задачи, с другой – по ходу решения были сложные вопросы, без ответа на которые не удалось бы идти вперед. Перечислю некоторые из них:
   
   
   • В матрице решения n строк, в какой последовательности следует выбирать индекс строки, если число возможностей для такого выбора составляет n!
   
   

Как и обещали, мы начинаем праздничный квест:



О его старте зарегистрированные участники (таковых оказалось более 200) были уведомлены в 11:00 MSK по почте.

Победителем станет тот, кто первым разместит правильную финальную картинку (с подарками Санты) в комментариях к этой публикации. Просим не давать подсказки в комментариях до этого момента.

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

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

Церемонность

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

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

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

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



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

---

С чем можно столкнуться при синхронизации Web Audio и геймплейных часов внутри javascript-приложения; сколько вообще разных «часов» есть в javasctipt (три!) и зачем все они нужны, а также готовое приложение для node.js – под катом.

Нет времени объяснять! Новый год совсем скоро. Курьеры сбиваются с ног, такси дорожают с каждым часом — а надо еще докупить подарки… Если вы не любите готовые решения в коробках с ленточками — как насчет подарка, который потребует творческого подхода? Что-нибудь такое, что можно разложить на новогоднем столе, сдвинув в сторону салаты, — и начать самозабвенно собирать, монтировать, подключать?.. Мы нашли несколько таких в нашей коллекции.

Осторожно! Варианты могут серьезно увлечь. Дарите только после боя курантов, чтобы не пропустить час X. Под катом — новогодний стол превращается…

Привет, Хабр!

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

1. Для императивной реализации — выигрыш от Rust получился всего 20 %. Это означает, что JVM вплотную приблизилась к нативной производительности, и тут уже нечего улучшать.
2. Для функциональной реализации — Rust оказался быстрее в 4.5 раза, потребление памяти снизилось в 5.5 раза, а отсутствие сборщика мусора сделало программу более стабильной (меньше разброс показателей). Это интересно для тех, кто хочет писать быстрые функциональные программы.
3. Концепция единственного владельца данных (и единственной мутабельной ссылки), принятая в Rust, очень близка концепции иммутабельности, в результате чего функциональные алгоритмы, основанные на неизменяемости, рекурсии и копировании, легко ложатся на Rust практически без переписывания, тогда как императивные алгоритмы заставляют редизайнить код, учитывать мутабельность ссылок, времена жизни, и т.д.

Вывод — Rust как будто специально создан для ФП, хотя возможности его синтаксиса пока не дотягивают до Scala.

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


Металлическая(?) белая(?!) крыса(?) желает счастья всем хабраюзерам в Новом Году. Перешлите картинку десяти друзяшкам, не прерывайте цепочку! Источник: [1]

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

Как встречать Новый 2020, чтобы не обидеть покровительницу Белую Крысу? Конечно же, придать торжественный вид интерьеру, приготовить подарки для близких, устроить большой праздник. В меню должны быть самые вкусные, сытные блюда. Чего уж точно не терпит хозяйка Нового года – это голод. Значит, на столе должны быть разнообразные продукты, напитки, фрукты с овощами. Нужно от души накормить животное мясом разных сортов, рыбой, выпечкой, курицей, орехами, шоколадом, коктейлями и компотами. Она попробует все и, наверняка, останется довольна такому щедрому угощенью.[1]

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

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

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

Проблема хрупкого базового класса

Известное об известном: spark работает с “датафреймами” (dataframes), которые являются алгоритмами трансформации. Алгоритм запускается в самый последний момент для того, чтобы "дать больше места" оптимизации и за счет оптимизации максимально эффективно его выполнить.

Под катом мы разберем — как можно разложить многостраничный SQL запрос на атомы (без потери эффективности) и как можно за счет этого существенно уменьшить время выполнения ETL конвейера.

Привет! Меня зовут Максим, последние 17 лет я работаю в ИТ (аналитик, РП, 11 лет бекенда), а еще я получил второе образование психолога в жанре «гештальт-терапия». Хочу рассказать о том, что для меня психотерапия очень похожа на разработку ПО с помощью дебаггера и как эту схожесть можно применять на практике.



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

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

Многие, как и я, любят футбольные симуляторы и многие увлекаются программированием. Когда-то, в далёком 2004 году, наигравшись в ФИФУ я подумал, что было бы неплохо совместить два моих увлечения в одной игре, в которой игроки управлялись бы не вручную, а написанным для них скриптом. Этакая игра для программистов, а-ля «RoboCup Simulation Soccer», только на свой лад. Я тогда был начинающим программистом и написал уже несколько простеньких игр, но реализовать свою задумку в полной мере не смог, так как не придумал, как написать подходящий интерпретатор языка программирования игроков. Игр для программистов сейчас стало больше, но такую, как я хотел не нашёл, и спустя много лет и тонны написанного кода, я решил вернуться к своей давней задумке.

Игра получилась такой, как я и хотел — funcball.com.

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

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

Приветствую, Хабровчане!

В этой статье я хочу рассказать о своем опыте работы преподавателем программирования на C++ в колледже при техническом университете. Это был уникальный опыт в жизни, который многому меня научил. Когда речь заходит об интересных фактах из личного прошлого — этот отрывок из жизни приходит на ум одним из первых.
Поехали.