Компания SpaceX, основанная небезызвестным Илоном Маском, выпустила симулятор ручной стыковки корабля Crew Dragon с МКС. Если все пойдет по плану, стыковку проведут 27 мая 2020 года. Она будет проходить в полностью автоматическом режиме, но экипаж корабля сможет переключиться на ручное управление. Собственно, именно ручной режим и воспроизведен в симуляторе.

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

Космический челнок так и норовит улететь не туда… А точность с которой нужно попасть в шлюз составляет 20 см… по трем осям, а также по угловой скорости, скорости смещения и т.д.

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

Как тебе такое, Илон Маск?


Курение вредит вашему здоровью

Чуть меньше полугода назад сделал сыну на день рождения подарок — конструктор Xiaomi MITU. Неожиданно для меня ребенок на неделю завис в этом конструкторе. Когда были испробованы первые модели и их управление с планшета, возник закономерный вопрос — «А как для него писать программы?»

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

Наверное, тогда маркетологи и придумали такое название как Flash Accelerator (флеш-акселератор или флеш-ускоритель).

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

Мотивация

• Хотелось ли вам за разумные деньги купить SSD размером в несколько терабайт?
• Чтобы ресурс был на десятки петабайт?
• Такой, что что бы вы ни делали, вы бы не смогли его исчерпать?
• При этом с защитой по питанию и сделанный из самых качественных деталей и самой стойкой памяти?

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

Текст объемный и рассчитан на:

• начинающих разработчиков, которые только знакомятся с платформой .NET Core;
• опытных разработчиков, выполняющих роль DevOps-инженеров в produсtion-окружении.

В статье не упоминается процесс создания приложений при помощи SDK (dotnet CLI), однако эта информация будет полезной для понимания, как работает SDK, а именно её основной компонент (ядро) — «драйвер» dotnet.dll, поскольку эта библиотека является управляемой сборкой и выполняется на .NET Core.

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

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

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

Окружение JupyterLab

Проект Jupyter уже несколько лет прилагает усилия к тому, чтобы закрыть разрыв между блокнотами и обычными IDE. Эти усилия, в значительной мере, представлены платформой JupyterLab, которая даёт разработчику более совершенный и удобный интерфейс, в который входят менеджер файлов, текстовые редакторы, консоли, блокноты.

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

Оптимизирующий AOT-компилятор обычно структурирован так:

1. фронтенд, преобразующий исходный код в промежуточное представление
2. конвейер машинно-независимой оптимизации (IR): последовательность проходов, которые переписывают IR для устранения неэффективных участков и структур, которые не могут быть непосредственно преобразованы в машинный код. Иногда эту часть называют middle-end.
3. Машинно-зависимый бэкенд для генерации ассемблерного кода или машинного кода.

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

Кроме огромных репозиториев с источниками для подготовки к интервью, здесь много чего интересного

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

А я его перевел, т.к. показалось, что пост многим будет интересен. Перевод очень вольный: я опустил нерелевантные промо-ссылки и гипер эмоциональные похвалы автора оригинала, чтобы оставить только суть. Еще, обновил цифры, чтобы информация была более актуальной к моменту публикации этого перевода. Итак, перейдем к списку.

Введение

В статье рассматривается «Y-метод» сборки кубика Рубика — его легко понять и запомнить. Он основан всего на одной последовательности, которая называется «Y-движение». Поняв этот алгоритм, вы навряд ли забудете как собрать кубик самостоятельно.

Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была "Go быстрее Rust, Mail.Ru Group сделала замеры".

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

В 2019 году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.

Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.

25 апреля в рамках «Дня тренинга МГУ 2020» Алексей Каптерев выступил с докладом про критическое мышление. Представляем вам часть 2 расшифровки лекции.

Часть 1 доступна по ссылке.

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.

К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.

Затем было очень трудно прохождение теста BigCrush.

Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.

Привет! Хочу познакомить вас с проектом Rust Embedded. Он позволяет нам использовать язык программирования Rust для разработки под встроенные платформы (Embedded Linux / RTOS / Bare Metal).


В этой статье, мы рассмотрим компоненты, которые необходимы для начала разработки под микропроцессоры Cortex-M3. После этого напишем простой пример — моргание встроенным светодиодом.

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Перевод репозитория github.com/dwmkerr/hacker-laws

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

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

Законы

Закон Амдала

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

Появление async/await в C# привело к пересмотру того, как писать простой и корректный параллельный код. Зачастую, используя асинхронное программирование, программисты не только не решают проблемы, которые были с потоками, но и привносят новые. Дедлоки и рейсы никуда не пропадают — их просто становится труднее диагностировать.



Дмитрий Иванов — Software Analysis TeamLead в Huawei, в прошлом техлид JetBrains Rider и разработчик ядра ReSharper: структур данных, кэшей, многопоточности, регулярный спикер конференции DotNext.

Под катом — видеозапись и текстовая расшифровка доклада Дмитрия с конференции DotNext 2019 Piter.

В HTTP/2 появилась компрессия стандартных заголовков, но тело URI, Cookie, значения User-Agent по-прежнему могут составлять десятки килобайт и требуют токенизации, поиска и сравнения подстрок. Задача становится критичной, если HTTP-парсер должен обрабатывать интенсивный злонамеренный трафик. Стандартные библиотеки предоставляют обширный инструментарий обработки строк, но у HTTP-строки есть своя специфика. Именно для этой специфики разработан HTTP-парсер Tempesta FW. Его производительность в несколько раз выше по сравнению с современными Open Source решениями и превосходит быстрейшие из них.


Александр Крижановский (krizhanovsky) основатель и системный архитектор Tempesta Technologies, эксперт в области высокопроизводительных вычислений в Linux/x86-64. Александр расскажет об особенностях структуры HTTP-строк, объяснит, почему стандартные библиотеки плохо подходят для их обработки, и представит решение Tempesta FW.

Под катом: как HTTP Flood превращает ваш HTTP-парсер в узкое место, проблемы x86-64 с branch mispredictions, кэшированием и не выровненной памятью на типичных задачах HTTP-парсера, сравнение FSM с прямыми переходами, оптимизация GCC, автовекторизация, strspn()- и strcasecmp()-like алгоритмы для HTTP-строк, SSE, AVX2 и фильтрация инъекционных атак с использованием AVX2.

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

А предыстория такая. Пока мы со школьными группами осенью ездили по Пскову, зарулили в театр. Он во Пскове неожиданно крутой. Ставили как раз Пушкина. Проблема в том, что дети не поняли сюжет и ещё минут 15 обсуждали после спектакля, что же это такое было и кто выиграл или проиграл. Вроде, очевидно, что Германна где-то прокатили, но вот где и как?

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

Мы поговорим о модели песчаной кучи. Песок (не настоящий, модельный), пересыпаясь, создаёт вот такие картинки:



Песчаные кучи можно складывать (это легко, если вы привыкли складывать всякие штуки) и вычитать (а вот это уже нетривиально).

А ещё можно использовать эту штуку в качестве Hello world вместо игры «Жизнь».

Изображение: shutterstock

Вот и настал момент, которого, возможно, больше всего боялись системные архитекторы, инженеры и специалисты по безопасности компании Intel: была найдена ошибка в неперезаписываемой области памяти (ROM) подсистемы Intel Converged Security and Management Engine, и эта ошибка ставит под сомнение все усилия компании по созданию корня доверия и фундамента безопасности на ее платформах.

И дело здесь даже не в том, что ошибки микропрограммного обеспечения (firmware), которое «зашито» в бортовой памяти Mask ROM микропроцессоров и чипсетов, уже невозможно исправить, а скорее в том, что найденная ошибка разрушает цепочку доверия всей платформы в целом, позволяя скомпрометировать ее аппаратную основу.

Посвящается памяти Джона Форбса Нэша-младшего

Вы ведь помните, что такое «простые числа»? Эти числа не делятся ни на какие другие, кроме самих себя и 1. А теперь я задам вопрос, которому уже 3000 лет:

• 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, p. Чему равно p? 31. Каким будет следующее p? 37. А следующее p ? 41. А следующее? 43. Да, но… как нам узнать, каким будет следующее значение?

Придумайте суждение или формулу, которые (хотя бы с грехом пополам) прогнозируют, каким будет следующее простое число, (в любом заданном ряду чисел), и ваше имя навечно будет связано с одним из величайших достижений человеческого мозга. Вы встанете в один ряд с Ньютоном, Эйнштейном и Гёделем. Разберитесь в поведении простых чисел, и можете потом всю жизнь почивать на лаврах.

Введение

Свойства простых чисел изучались многими великими людьми в истории математики. С первого доказательства бесконечности простых чисел Евклида до формулы произведения Эйлера, связавшей простые числа с дзета-функцией. От формулировки теоремы о простых числах Гаусса и Лежандра до её доказательства, придуманного Адамаром и Валле-Пуссеном. Тем не менее, Бернхард Риман до сих пор считается математиком, сделавшим единственное крупнейшее открытие в теории простых чисел. В его опубликованной в 1859 году статье, состоявшей всего из восьми страниц, были сделаны новые, ранее неизвестные открытия о распределении простых чисел. Эта статья по сей день считается одной из самых важных в теории чисел.

После публикации статья Римана оставалась главным трудом в теории простых чисел и на самом деле стала основной причиной доказательства в 1896 году теоремы о распределении простых чисел. С тех пор было найдено несколько новых доказательств, в том числе элементарные доказательства Сельберга и Эрдёша. Однако до сих пор остаётся загадкой гипотеза Римана о корнях дзета-функции.

С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?

Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.