Статья с сайта безумного инженера-самодельщика Криса Фентона



Встречайте ZedRipper – 16-ядерного зверюгу, работающего на частоте 83 МГц на базе процессоров Z80 – настолько же портативного, насколько и непрактичного. Это моя самая свежая на сегодня попытка собрать компьютер ради прикола, причём удовлетворив сразу несколько желаний:

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

Эта заметка продолжает разбор улучшений производительности, которые могли бы стать явью, если бы не разные "но". Предыдущая часть о StringBuilder-е находится здесь.

Здесь мы рассмотрим несколько "улучшений", отклонённых из-за непонимания тонкостей спецификации языка, неочевидных угловых случаев и других причин. Поехали!

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

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

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

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

Мой коллега Рафаэль Григорян eegdude недавно написал статью о том, зачем человечеству потребовалась ЭЭГ и какие значимые явления могут быть зарегистрированы в ней. Сегодня в продолжение темы нейроинтерфейсов мы используем один из открытых датасетов, записанных на игре, использующей механику P300, чтобы визуализировать сигнал ЭЭГ, посмотреть структуру вызванных потеницалов, построить основные классификаторы, оценить качество, с которым мы можем предсказать наличие такого вызыванного потенциала.

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

Для того, чтобы заняться классификацией ЭЭГ, можно позвать друзей, написать игру про Енотов и Демонов в VR, записать собственные реакции и написать научную статью (об этом я расскажу как-нибудь в другой раз), но по счастью, учёные со всего мира уже провели некоторые эксперименты за нас и осталось только скачать данные.

Разбор способа построения нейроинтерфейса на P300 с пошаговым кодом и визуализациями, а также ссылку на репозиторий можно найти под катом.

Известный американский маркетолог Стюарт Бритт говорил: «Вести бизнес без рекламы – всё равно, что подмигивать девушке в темноте: вы-то знаете, что вы делаете, а остальные – нет». Сложно не согласиться, ведь недостаточно просто создать продукт — чтобы им пользовались, нужно еще и рассказать о нем. Поэтому пока команда разработчиков PVS-Studio каждый день трудится над улучшением и стабильной работой анализатора, отдел маркетинга берет на себя не менее важную задачу – его продвижение. В последнее время мы активно работаем с YouTube блогерами и фиксируем результаты. Если у вас есть свой канал на YouTube и вы считаете, что вашей аудитории будет полезно и интересно узнать о том, как улучшить свой код, напишите нам — мы будем рады посотрудничать! Нас интересуют такие направления, как C, C++, C#, Java, DevOps, разработка игр, тестирование, качество кода.

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



Как баг превратился в фичу, о научном прогрессе и всех приключениях в попытках опубликоваться в Nature. Спойлер: почти получилось.

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

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

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

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

Добро пожаловать под кат!

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

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

Компьютерные игры существуют почти столько же, сколько и сами компьютеры. Хотя в это трудно поверить, текстовая адвенчура Zork была Fortnite-ом своего времени. Но Zork был ещё и чем-то большим. Ради портируемости и экономии пространства сам Zork был написан на Zork Implementation Language (ZIL), в котором активно использовалась совершенно новая на тот момент концепция объектно-ориентированного программирования, и выполнялся в виртуальной машине. И всё это происходило в 1979 году. Разработчики использовали всевозможные хитрости, чтобы уместить как можно бОльшую часть Подземной империи в компьютеры, имевшие всего 32 КБ ОЗУ. Однако Zork стал не только технологическим прорывом, но и большой вехой в истории компьютерных игр. При этом возник он не на пустом месте.

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

Каждый язык, поддерживающий параллельные (конкурентные, асинхронные) вычисления, нуждается в способе запуска кода параллельно. Вот примеры из разных API:

go myfunc();                                // Golang

pthread_create(&thread_id, NULL, &myfunc);  /* C with POSIX threads */

spawn(modulename, myfuncname, [])           % Erlang

threading.Thread(target=myfunc).start()     # Python with threads

asyncio.create_task(myfunc())               # Python with asyncio

Есть много вариантов нотации и терминологии, но одна семантика — запустить myfunc параллельно основной программе и продолжить родительский поток выполнения (англ. "Control Flow")

Всем привет, меня зовут Сергей. Я занимаюсь тестированием фронтенда Яндекс.Маркета. Знаю, что среди читателей Хабра много IT-специалистов, которые как-то связаны с релизным процессом и тестированием. У меня к вам вопрос. Бывало ли в вашей практике так, что фичи долго не катятся в продакшн? Знакомы ли вам раздутые релизы и их объёмные проверки?

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

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

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

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

Все началось, казалось бы, с простого вопроса, который сначала ввел меня в ступор — "Зачем нужен make? Почему нельзя обойтись bash скриптами?". И я подумал — Действительно, зачем нужен make? (и самое важное) Какие проблемы он решает?

Чем React Native отличается от Flutter, за исключением того, что речь идёт о разных фреймворках, в основу которых положены разные технологии? На что ориентироваться тому, кто не знаком с этими инструментами для разработки кросс-платформенных приложений, но хочет выбрать один из них для своего очередного проекта?



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

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

Давным-давно…

Еще в 2010 году я сидел в своём офисе и занимался ерундой: развлекался код-гольфингом и накручивал рейтинг на Stack Overflow.

Моё внимание привлёк следующий вопрос: как вывести количество байт в удобочитаемом формате? То есть как преобразовать что-то вроде 123456789 байт в «123,5 МБ».


Старый добрый интерфейс 2010 года, спасибо The Wayback Machine

С момента выхода прошлой публикации в мире языка Julia произошло много интересного:

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

В то же время заметен рост интереса со стороны разработчиков, что выражается обильными бенчмаркингами:

• Международное энергетическое агенство проверяет пакеты реализующие многомерную оптимизацию
• Датасаянтисты тестят работу с GPU
• Ни капли не предвзятые ребята сравнивают интеграторы для дифуров
• А энтузиасты сравнивают языки на базовых задачах.

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

Привет, Хабр! Предлагаю вашему вниманию перевод замечательной статьи из цикла статей небезызвестного Джейка Вортона о том, как происходит поддержка Андроидом Java 8.



Оригинал статьи лежит тут