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

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

Я провел в изучении JMM много часов и теперь делюсь с вами знаниями в простой и понятной форме.

В этой статье мы подробно разберем Java Memory Model (JMM) и применим полученные знания на практике. Да, в интернете накопилось достаточно много информации про JMM/happens-before, и, кажется, что очередную статью про такую заезженную тему можно пропускать мимо. Однако я постараюсь дать вам намного большее и глубокое понимание JMM, чем большинство информации в интернете. После прочтения этой статьи вы будете уверенно рассуждать о таких вещах как memory ordering, data race и happens-before. JMM — сложная тема и не стоит верить мне на слово, поэтому большинство моих утверждений подтверждается цитатами из спеки, дизассемблером и jcstress тестами.

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

Я много раз читал, как кто-то попробовал MobX, у него код получился запутанным с не контролируемыми изменениями, после чего он продолжил писать на Redux. Для MobX нет рекомендованной архитектуры. Но при использовании и соблюдении в MobX строгой и однообразной (имеется ввиду одинаковой в различных участках проекта) архитектуры, можно получить понятный код с контролируемыми изменениями в сколь угодно большом проекте. Я опишу один из вариантов, как этого добиться.

Больше года назад, когда я работал антиспамщиком в Mail.Ru Group, на меня накатило, и я написал про эксперименты с malloc. В то время я в свое удовольствие помогал проводить семинары по АКОСу на ФИВТе МФТИ, и шла тема про аллокацию памяти. Тема большая и очень интересная, при этом охватывает как низкий уровень ядра, так и вполне себе алгоритмоемкие структуры. Во всех учебниках написано, что одна из основных проблем динамического распределения памяти — это ее непредсказуемость. Как говорится, знал бы прикуп — жил бы в Сочи. Если бы оракул заранее рассказал весь план по которому будет выделяться и освобождаться память, то можно было составить оптимальную стратегию, минимизирующую фрагментацию кучи, пиковое потребление памяти и т.д. Отсюда пошла возня с ручными аллокаторами. В процессе раздумий я натолкнулся на отсутствие инструментов логирования malloc() и free(). Пришлось их написать! Как раз про это была статья (а ещe я изучал macOS). Были запланированы две части, однако жизнь круто повернулась и стало не до malloc(). Итак, пора восстановить справедливость и реализовать обещанное: ударить глубоким обучением по предсказанию работы с кучей.

Внутри:

• Совершенствуем libtracemalloc, перехватчик malloc().
• Строим LSTM на Keras — глубокую рекуррентную сеть.
• Обучаем модель на примере работы реального приложения (vcmi/vcmi — а вы думали, причем здесь Heroes III?).
• Удивляемся неожиданно хорошим результатам.
• Фантазируем про практическое применение технологии.
• Исходники.

Интересно? Добро пожаловать под кат.

Вам больше не помогут no-cache или max-age заголовки, вы просто не знали и не могли узнать о механизме обновления SW. Потому что про него вам не говорили.

Здравствуйте! Меня зовут Игорь, я главный инженер по разработке в команде SmartData. Занимаюсь fullstack-разработкой внутренней аналитической BI-системы. В нашей компании React принят в качестве основного стандарта для построения пользовательских интерфейсов. Как и большая часть сообщества React, мы активно используем хуки в нашей повседневной работе.

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

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

It's 2019! Everybody thinks they know code splitting. So - let's double check!

What does code splitting stand for?

In short – code splitting is just about not loading a whole thing. Then you are reading this page you don't have to load a whole site. When you are selecting a single row from a database – you don't have to take all.
Obvious? Code splitting is also quite obvious, just not about your data, but your code.

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

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

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

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

Their main claim to fame comes from being featured in many introductory machine learning classes available online. As a result, a lot of newcomers to the field absolutely love autoencoders and can't get enough of them. This is the reason why this tutorial exists!

Тем не менее, одна из практических задач, для которых их вполне себе можно применять — поиск аномалий, и лично мне в рамках вечернего проекта потребовался именно он.

На просторах интернетов есть очень много туториалов по автоэнкодерам, нафига писать еще один? Ну, если честно, тому было несколько причин:

• Сложилось ощущение, что на самом деле туториалов примерно 3 или 4, все остальные их переписывали своими словами;
• Практически все — на многострадальном MNIST'е с картинками 28х28;
• На мой скромный взгляд — они не вырабатывают интуицию о том, как это все должно работать, а просто предлагают повторить;
• И самый главный фактор — лично у меня при замене MNIST'а на свой датасет — оно все тупо переставало работать.

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

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

Развитие глубоких нейронных сетей для распознавания изображений вдыхает новую жизнь в уже известные области исследования в машинном обучении. Одной из таких областей является доменная адаптация (domain adaptation). Суть этой адаптации заключается в обучении модели на данных из домена-источника (source domain) так, чтобы она показывала сравнимое качество на целевом домене (target domain). Например, source domain может представлять собой синтетические данные, которые можно «дёшево» сгенерировать, а target domain — фотографии пользователей. Тогда задача domain adaptation заключается в тренировке модели на синтетических данных, которая будет хорошо работать с «реальными» объектами.

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

Мой опыт подсказывает, что любой более или менее сложный проект по машинному обучению рано или поздно превращается в набор сложных неподдерживаемых внутренних инструментов. Эти инструменты, как правило, мешанина из скриптов Jupyter Notebooks и Flask, которые сложно развёртывать и интегрировать с решениями типа GPU сессий Tensorflow.

Впервые я столкнулся с этим в университете Карнеги, затем в Беркли, в Google X, и, наконец, при создании автономных роботов в Zoox. Зарождались инструменты в виде небольших Jupyter notebooks: утилита калибровки сенсора, сервис моделирования, приложение LIDAR, утилита для сценариев и т.д.

С ростом важности инструментов появлялись менеджеры. Бюрократия росла. Требования повышались. Маленькие проекты превращались в огромные неуклюжие кошмары.