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


— Меня зовут Сева Миньков. Я работаю в отделе облачной инфраструктуры поискового департамента. Занимаюсь в основном бэкендом. Пишу на разных языках, но чаще всего это Java и языки, запускаемые на Java Virtual Machine (JVM).

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

Чаще прочих встречается вот такая алгоритмическая идея.

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

Одним из самых ярких событий в мире Фронтенда в этому году стала публикация репозитория Vue next — части функционала третьей версии VueJS. В этой статье представлен обзор новых killer features VueJS. На момент публикации статьи репозиторий находился в статусе Pre-Alpha. Планы на релиз можно посмотреть в Roadmap

Новый хабрапост в серии разборов недавно прошедшего чемпионата. Участникам квалификации, которые выбрали секцию фронтенда, нужно было решить несколько задач очень разной сложности: первая (по нашим ожиданиям) занимала 20 минут, последняя — около часа. Мы проверяли широкий спектр навыков разработчика интерфейсов, включая способность разобраться в необычной предметной области.

A. Аннигилируй это

^{Авторы: Максим Сысоев, Константин Петряев}

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

Условие

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

Язык предметной области. Не перегружен конструкциями языка общего назначения. При этом позволяет всего несколькими строчками реализовать весьма сложную логику. Все это — DSL.

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

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


Общий объем показанной телеметрии таков, что в целом позволял оценить многие нюансы, связанные как с конструкцией станции, так и с особенностями ее посадки. Это действительно интересно. Дело в том, что посадка на Луну — очень непростой процесс, нюансы которого публикуются редко. В частности, реальная телеметрия обычно не публикуется вообще.

Очень хочу поделиться с вами переводом статьи про эксперимент с моб-программированием от одного из его создателей, Вуди Зила. Это когда вся команда сразу работает за одним компьютером. Как парное программирование, только групповое. Я бывший Java-разработчик и тимлид с 11-летним стажем, и раньше меня бы удивил такой подход. Оказалось, работает очень интересно. Внутри — как взаимодействуют участники, какие преимущества им это даёт, и с какими сложностями они столкнулись. Это отчёт об эксперименте, который уже три года успешно продолжается в команде Вуди. Полезно, если вы хотите настроить такое у себя.

1. Введение

Моб-программирование или моббинг — это подход к разработке программного обеспечения, при котором вся команда целиком работает над одним и тем же, в одно и то же время и в одном и том же месте за одним компьютером. Это похоже на парное программирование [PAIR], где двое человек сидят за одним компьютером и совместно работают над одним и тем же кодом в одно и то же время. При моб-программировании эта совместная работа распространяется на всех в команде, при этом всё ещё используется только один компьютер для написания кода.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи «Pragmatic Functional Programming» автора Robert C. Martin (Uncle Bob).

Переход к функциональному программированию всерьез развился только около десяти лет назад. Мы видим, что такие языки, как Scala, Clojure и F# привлекают внимание. На самом деле это был большой шаг в программировании: “О, круто, новый язык!” — энтузиазм… Видимо там было что-то особенное — ну или это мы так думали.  

Закон Мура гласит нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Данный закон действовал с 1960-х до 2000 годов. Затем он прекратился. Частота достигла 3 ГГц, а затем и вовсе поднялась на плато. Мы достигли скорости света! Сигналы не могут распространяться по поверхности чипа достаточно быстро, чтобы обеспечить более высокие скорости. 

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

Это перевод статьи An introduction to context-oriented programming in Kotlin

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

Несколько слов о разрешении функций

Как хорошо известно, существует три основных парадигмы программирования (примечание Педанта: есть и другие парадигмы):

• Процедурное программирование
• Объектно-ориентированное программирование
• Функциональное программирование

В этой статье я хочу рассказать об архитектуре советских программируемых микрокалькуляторов на примере калькулятора «Электроника МК-52» и как можно внедриться в его архитектуру.

Советские калькуляторы семейства "Электроника Б3-34" («Электроника МК-56», «Электроника МК-61» и «Электроника МК-52») были особенно популярны в СССР. Причиной этому была не только доступная цена в 65 рублей за МК-54, 85 рублей за МК-61 или 115 рублей за МК-52, но и развитой язык программирования. Это семейство калькуляторов стало де-факто стандартным для многочисленных пользователей. Огромное количество книг было посвящено программированию на этих машинках и публикацией готовых алгоритмов. Электроника МК-52 даже летала в космос на корабле Союз ТМ-7, где предполагалось его использование в качестве резервного на случай неисправности спускаемого навигационного оборудования. Даже в военно-морском флоте СССР калькулятор «Электроника МК-52» с блоком расширения памяти БРП «Астро» какое-то время был стандартным средством для навигационных расчетов.

Привет, Хабр. Недавно прошло соревнование от Тинькофф и McKinsey. Конкурс проходил в два этапа: первый — отборочный, в kaggle формате, т.е. отсылаешь предсказания — получаешь оценку качества предсказания; побеждает тот, у кого лучше оценка. Второй — онсайт хакатон в Москве, на который проходит топ 20 команд первого этапа. В этой статье я расскажу об отборочном этапе, где мне удалось занять первое место и выиграть макбук. Команда на лидерборде называлась "дети Лёши".

Соревнование проходило с 19 сентября до 12 октября. Я начал решать ровно за неделю до конца и решал почти фулл-тайм.

Краткое описание соревнования:

Летом в банковском приложении Тинькофф появились stories (как в Instagram). На story можно отреагировать лайком, дизлайком, скипнуть или просмотреть до конца. Задача предсказать реакцию пользователя на story.

Соревнование по большей части табличное, но в самих историях есть текст и картинки.

Всем привет, меня зовут Геворг. Я Head of Mobile в Profi.ru. Хочу поделиться с вами историей нашего эксперимента с React Native. Расскажу, как мы оценивали плюсы и минусы разработки на React Native — в теории и на практике. Статья будет полезна тем, кто интересуется кросс-платформенной мобильной разработкой, но пока не решил, идти в эту сторону или нет.

Максимальное ускорение

Всё началось с того, что мы решили ускорить разработку в 10 раз на уровне компании. Поставили невыполнимую цель, чтобы выйти за привычный горизонт событий и попробовать новое. Все команды разработки Profi.ru взялись за эксперименты. На тот момент в компании было 13 нативных мобильных разработчиков, включая меня и двух тимлидов. Моя команда работала над двумя мобильными приложениями. В первом клиенты ищут специалистов, во втором — специалисты клиентов. Для меня этот период был непонятным и эмоционально напряжённым. По моим ощущениям, мы и так много делали, чтобы всё работало быстро.

Использовали общую архитектуру на всём проекте и следили за чистотой кода. Использовали генераторы, которые создают все файлы модулей. Всю бизнес-логику старались выносить на backend. Настроили CI/CD, а приложения покрыли E2E-тестами. За счёт всего этого стабильно релизили некоторые приложения раз в неделю. Я понятия не имел, как ускорить разработку даже в два раза. Куда уж в 10. Поэтому мы определили, что для нас важно.

Примечание от переводчика: это первая часть монументальной (на самом деле монументальной) статьи о Vim и его возможностях от разработчика из Миннеаполиса и автора проекта PostgREST Джо begriffs Нельсона.

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

---

Эта статья основана на исследовании истории Vim и прочтении его руководства пользователя от корки до корки. Надеюсь, эти заметки помогут вам открыть (или переоткрыть?) для себя основные функциональные возможности этого редактора, а также позволят отказаться от использования предупакованных файлов vimrc и более вдумчиво использовать плагины.

Список литературы

Чтобы выйти за границы привычных тем, я бы порекомендовал обзавестись бумажной копией этого руководства и емким карманным справочником. Я не смог найти печатную копию руководства пользователя для Vim, так что в итоге просто распечатал идущий вместе с редактором PDF-файл с помощью printme1.com. Он идет вместе с софтом в $VIMRUNTIME/doc/usr_??. В качестве удобного списка команд могу посоветовать справочник «Vi and Vim Editors Pocket».

Содержание

• История
• Иерархия конфигурации
• Сторонние плагины
• Бекапы и откаты
• Include и path
• Редактирование и компиляция цикла
• Диффы и патчи
• Буфер ввода / вывода
• Типы файлов
• Не забывайте про мышь
• Разное

История

Рождение vi

Команды и функции Vi существуют уже более пятидесяти лет, начиная с редактора QED. Вот его таймлайн:

«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется», — Бьёрн Страуструп, создатель C++

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

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

Но действительно ли это так?

Как мы оказались в такой ситуации?

Не стоит ждать, что я назову JavaScript идеальным языком. У него есть странные причуды. Он был спроектирован за десять дней, а затем его изменили так, чтобы он напоминал Java. К сожалению, это наследие, с которым мы вынуждены жить.

Но ни один язык не идеален, а JavaScript значительно улучшился после ES6 и продолжает своё развитие. Он эволюционировал из «игрушечного языка», используемого только для анимирования элементов веб-страниц, в серьёзный язык программирования, применяемый сегодня для выполнения больших и сложных веб-приложений.

Фред Еарьян перед PDP-7 с серийным номером 129

Недавно я встречался с Фредом Еарьяном, бывшим инженером Boeing, и Джеффом Кейлином, инженером из Living Computers, для обсуждения их работы по реставрации PDP-7 в лаборатории музея Living Computers: Museum + Labs. PDP-7 (от Programmed Data Processor, «программируемый обработчик данных») был представлен компанией The Digital Equipment Corporation (DEC) в 1964.

В начале 1960-х термин «компьютер» был синонимом огромных и дорогих машин, в которых часто было сложно разобраться. DEC выбрала для своей машины название PDP, чтобы избежать подобных негативных коннотаций.

Покупателей для PDP-7 DEC находила по всей стране, в частности, в лабораториях Белла, национальной лаборатории тихоокеанского северо-западного побережья и Лаборатории реактивного движения. PDP-7 также пользовался популярностью в университетах – его, в частности, отправляли в Оксфордский университет, MIT, Хельсинкский технологический университет и Токийский университет.

Здравствуйте, меня зовут Дмитрий Карловский и я… хочу поведать вам о фундаментальной особенности систем типов, которую зачастую или вообще не понимают или понимают не правильно через призму реализации конкретного языка, который ввиду эволюционного развития имеет много атавизмов. Поэтому, даже если вы думаете, что знаете, что такое "вариантность", постарайтесь взглянуть на проблематику свежим взглядом. Начнём мы с самых основ, так что даже новичок всё поймёт. А продолжим без воды, чтобы даже профи было полезно для структурирования своих знаний. Примеры кода будут на псевдоязыке похожем на TypeScript. Потом будут разобраны подходы уже нескольких реальных языков. А если же вы разрабатываете свой язык, то данная статья поможет вам не наступить на чужие грабли.

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

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

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

Желая унизить главного героя Ричарда Хендрикса, его бывший начальник показывает на совещании фрагмент его старого кода. Там к уже отсортированным данным применён линейный поиск — так что задача будет выполнена, но выглядит это очень неэффективно.

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

Прошло примерно 18 месяцев с внутреннего релиза Deno, вышел preview release, появилось несколько статей на Хабре, и Райан ездит по конференциям и рассказывает о нём. Однако я нигде так и не видел сколько-нибудь вдумчивого разбора этого проекта — почему-то все ограничиваются переводом документации...

Что же, давайте попробуем это сделать сейчас. Последние 5 лет я пишу на Node.JS, а компания OneTwoTrip, где я сейчас работаю, пишет проекты на ноде около 9 лет (да, это я писал историю про 9 лет в монолите на ноде). Так что анализ должен выйти неплохой. Тем более что я его уже рассказал на Moscow Node.JS Meetup 10, и было интересно. Кстати, если вам удобнее слушать, а не читать, то послушать и посмотреть можно вот тут. Моё выступление второе, я чувак в розовой рубашке.

Перевод статьи подготовлен специально для студентов курса «Machine learning».

---

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