Hello, world!
В этой небольшой заметке я хочу поделиться с вами двумя сниппетами, которые показались мне очень интересными. Первый сниппет представляет собой пример реализации простой реактивности (signal), второй — способ предотвращения несогласованности данных в результате состояния гонки (race condition). Первая конструкция используется в SolidJS (с некоторыми дополнительными оптимизациями), вторая — заимствована из одного рабочего проекта.
Интересно? Тогда прошу под кат.
В последнее время много копий сломано вокруг технических собеседований. Очевидно, что инвертирование двоичного дерева на доске практически никак не связано с практическими навыками реального программиста. Примитивный Fizzbuzz по-прежнему остаётся самым эффективным тестом. Как следствие, выросло внимание к опенсорсным проектам, но оказалось, что это тоже не очень хороший показатель, потому что у большинства профессионалов нет на них времени.
У нас в компании самое эффективное собеседование по программированию на сегодняшний день — это обычно какое-то домашнее задание на несколько дней, в котором кандидата просят исправить баг или реализовать небольшую функцию. Это не очень хорошо, потому что занимает много времени, и человек может получить внешнюю помощь (или погуглить, если функция достаточно распространённая). С другой стороны, некоторые крупные компании вместо этого удвоили количество собеседований с доской (и алгоритмами), подвергая будущих инженеров многочасовым сессиям онлайн-программирования с различным уровнем инвазивного наблюдения.
Все эти методы интервью не сравнятся с очень простой метрикой: совместная игра в Factorio. Прохождение всего цикла Factorio — практически идеальный показатель, насколько хорошо человек решает общие технические проблемы. Можно даже настроить прохождение игры на основе будущей должности, чтобы лучше понять, как кандидат справится со своей ролью.
Читать полностью »
Это вторая часть цикла статей «Бесстрашная защита». В первой мы рассказывали про безопасность памяти
Современные приложения многопоточны: вместо последовательного выполнения задач программа использует потоки для одновременного выполнения нескольких задач. Все мы ежедневно наблюдаем одновременную работу и параллелизм:
Параллельные потоки ускоряют работу, но привносят набор проблем синхронизации, а именно взаимные блокировки и состояние гонки. С точки зрения безопасности, почему мы заботимся о безопасности потоков? Потому что у безопасности памяти и потоков одна и та же основная проблема: недопустимое использование ресурсов. Здесь атаки приводят к таким же последствиям, как атаки на память, включая повышение привилегий, выполнение произвольного кода (ACE) и обход проверок безопасности.
Читать полностью »
10 октября 2018 года наша команда выпустила новую версию приложения React Native. Мы рады и гордимся этим.
Но ужас-то какой: через несколько часов внезапно увеличивается количество сбоев под Android.
10 000 сбоев под Android
Наш инструмент мониторинга сбоев Sentry сходит с ума.
Читать полностью »
Как компьютерный инженер, который пять лет занимался проблемами кэша в Intel и Sun, я немного разбираюсь в когерентности кэша. Это одна из самых трудных концепций, которые пришлось изучить ещё в колледже. Но как только вы действительно её освоили, то приходит гораздо лучшее понимание принципов проектирования систем.
Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.
С другой стороны, неправильные представления о кэшах часто приводят к ложным утверждениям, особенно когда речь идёт о параллелизме и состоянии гонки. Например, часто говорят о трудности параллельного программирования, потому что «у разных ядер в кэшах могут быть разные/устаревшие значения». Или что квалификатор volatile в языках вроде Java нужен, чтобы «предотвратить локальное кэширование общих данных» и принудительно «читать/записывать только в основную память».
Читать полностью »
Об авторе: Тэмми Бутов — технический руководитель инфраструктуры для разработчиков в Dropbox. Это управление потоками кода — полный цикл использования Go в Dropbox, от программирования до выпуска. Она выступала на конференции GopherCon 2017 на тему того, как разработчики Dropbox создают и поддерживают работу крупномасштабных сервисов на Go.
Тэмми цитирует статью Роба Пайка «Go в компании Google: языковой дизайн в службе разработки ПО» от 2012 года, поскольку она в целом хорошо передаёт, почему Go хорошо работает и в Dropbox:
«Go — эффективный, масштабируемый и производительный язык. Некоторые программисты получают удовольствие от работы с ним; другие находят его прозаическим, даже скучным. В этой статье мы расскажем, почему все эти позиции не противоречат друг другу. Go спроектирован для решения проблем, возникающих в софтверной разработке в Google, что привело к созданию языка, который не является прорывным с исследовательской точки зрения, тем не менее это прекрасный инструмент для разработки крупных софтверных проектов». — Роб Пайк, 2012
Масштаб Dropbox впечатляет:
Экспериментальный движок Mozilla Servo близок к выпуску альфа-версии. На днях разработчики сообщили, что планируют первый релиз Servo+Browser.html на июнь 2016 года.
Servo – движок, написанный с нуля на языке программирования Rust. Он отличается лучшей безопасностью, модульностью, а также исключительно высокой производительностью за счёт алгоритма параллельной компоновки страниц и новых парсеров CSS3 и HTML5 на Rust. Два важных компонента используют существующие модули на C++ от Mozilla: это движок SpiderMonkey для обработки JavaScript и библиотека 2D-графики Azure для OpenGL и Direct3D.
Читать полностью »
