Интро: почему я написал эту статью

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

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

Разрабатывая проект на JavaScript (TypeScript, ClojureScript или каком-то другом языке, транслируемом в JavaScript), мы привыкли создавать объекты, массивы, строки и вообще писать код, как будто память бесконечна. Это не так. Я расскажу о видах проблем с памятью, о том, какие ограничения мы часто забываем и как их можно преодолеть. В ответ браузеры и пользователи скажут вам спасибо.

• Категории проблем с памятью
• Ограничения по памяти для разных типов данных
  　Heap
  　Buffer, TypedArray
  　String
  　Map, Set
  　Call stack
  　Типичные задачи, в которых можно наткнуться на ограничения по памяти
• Soft-утечки
  　Пример из продакшена
  　Как получаются soft-утечки
  　Как их обнаружить
  　Как найти причину
  　　1. Memory Allocation Timeline
  　　2. Техника трёх снапшотов
  　　3. queryObjects
  　　Тренируемся находить утечки
• Hard-утечки
  　Пример из продакшена
  　Как бороться
• Нестандартные оптимизации памяти в Node.js
  　Исходный код
  　Module._pathCache
  　Несколько версий пакета в node_modules
  　require('./data.json')
• Заключение

Одним из самых компьютеризированных разделов медицины является радиодиагностика. Медицинские исследования генерируют большое количество данных, которые затем обрабатываются передовыми методами визуализации, 3D-реконструкции по срезам и даже машинного обучения. Этот топик призван помочь системным администраторам погрузиться в тематику передачи и хранения медицинских изображений.


Фото автора

До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

Системы глубокого анализа трафика (Deep Packet Inspection, DPI) — программно-аппаратные комплексы для классификации проходящего интернет-трафика по типу данных (веб-страница, документ, аудио, видео), протоколу (HTTP, BitTorrent, VoIP/SIP) и конкретным программам (Skype, WhatsApp), зачастую обладающие дополнительной функциональностью. Системы DPI распространены и используются по всему миру продвайдерами проводного и беспроводного доступа.

Мобильные операторы используют системы глубокого анализа трафика, прежде всего, для приоритизации разного контента в интернете (QoS), чтобы можно было одновременно скачивать большой файл и смотреть видео на YouTube, и чтобы один пользователь сотовой сети, активно использующий интернет, не создавал проблем другим пользователям. Операторы используют DPI примерно с начала двухтысячных, с приходом UMTS (3G), чтобы более-менее честно разделять беспроводной канал ограниченной пропускной способности.

Мобильные операторы используют и другие возможности DPI, например, ускорение TCP и HTTP-трафика (TCP PEP, Performance-enhancing Proxy), для ускорения интернета в мобильных сетях и идентификации пользователей веб-сайтами. Если попытаться зайти в личный кабинет оператора с телефона, на многих операторах он откроется сразу, без необходимости ввода логина и пароля. Или, что можно было встретить лет 5 назад, простой заход на подозрительный веб-сайт или клик по рекламному баннеру из Android-игры оборачивался автоматической подпиской на платную услугу, о чем можно было узнать из СМС-сообщения.

Как-то так сложилось, что тег DLNA сервер чаще встречается в постах-вопросах, чем в ответах. И если в вопросах установки на домашний Windows-ПК какой-то пользовательский опыт накоплен, то определиться с выбором ПО для домашнего сервера/NAS-а/медиацентра — оказалось непросто. Распределившись по песочницам народ обособленно решает проблемы каждой программы в отдельности. А понять что из них чего стоит и нужно ли оно вообще — лично мне не удалось.

И вот, я вооружившись ссылкой с Википедии Как выбрать DLNA-сервер под Windows, Mac OS X или Linux — опробовал почти всё, что есть под Linux.

Вступление

Тернист и извилист путь Java-платформы к правильному способу записи строчек в лог-файлы. История logging в Java довольно познавательна в плане изучения особенностей Open Source, в том числе его взаимодействия с корпорациями и единичными программистами. Я собираюсь рассказать столько, сколько возможно, об истории развития Java logging, а также о том, к чему все пришло и как жить дальше.

Доброго времени суток уважаемые хабравчане. Уже 3 года я работаю на проекте в котором мы используем Spring. Мне всегда было интересно разобраться с тем, как он устроен внутри. Я поискал статьи про внутреннее устройство Spring, но, к сожалению, ничего не нашел.

Всех, кого интересует внутреннее устройство Spring, прошу под кат.

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

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

Да, под Node.js можно написать сервер, но для бэковой разработки, все же, .net бесспорный лидер. На js, на мой взгляд, очень сложно написать гибкий и легко поддерживаемый бэкенд, хотя возможно многие со мной и не согласятся.

Давайте ударим автопробегом по бездорожью попытаемся вопреки всему этому написать SPA приложение с бэком на .net core и клиентом на js, из инструментов разработки будем использовать горячо любимую Visual Studio.

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

Liquibase — это система управления миграциями базы данных. Это вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).

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

Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.

1. Версионность приложения должна быть отражена в структуре папок миграций

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

/db-migrations
    /v-1.0
        /2013-03-02--01-initial-schema-import.xml
        /2013-03-02--02-core-data.xml
        /2013-03-04--01-notifications.xml
        /changelog-v.1.0-cumulative.xml
    /v-2.0
        ...
        /changelog-v.2.0-cumulative.xml
    /changelog.xml

Подробнее:

Вступление

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

На дворе 2017ый год и для каждого нового продукта/проекта встает вопрос выбора фреймворка для разработки. Долгое время я был уверен, что новый Angular 2/4 (далее просто Angular) станет главным трендом enterprise разработки еще на несколько лет вперед и даже не сомневался что буду работать только с ним.

Сегодня я сам отказываюсь использовать его в своем следующем проекте.

Дисклеймер: данная статья строго субъективна, но таков мой личный взгляд на происходящее и касается разработки enterprise-level приложений.

На ныне покойном Geektimes есть (или был) блог Gearbest и он был (или есть) уныл. Их маркетологи зачем-то раз за разом втюхивают одни и те же телефоны и планшеты, тогда как на сайте (впрочем, как и на Ali) есть куча других отличных товаров для гиков. Поэтому, можно я поделюсь своими маленькими китайскими открытиями?



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

Благодаря Алексею Надежину мы уже знаем, что лучшими по соотношению цена/емкость являются либо батарейки Ikea и Ашан, либо GP Super. Тем, собственно и жили.
UPD: в комментариях указали, что Алексей провел новое исследование. С учетом обновления цен до текущих, получается, что лучше выглядят батарейки Pairdeer и Lexman из Леруа Мерлен. Ну и опять же Ашан.
Однако, вывалив в специальный контейнер очередную порцию дохлых батареек и испытав на себе полуночный плач ярославны о том, что любимая кукла не работает, пришел к простому выводу — пора переходить на аккумуляторы. Причем, если будут аккумуляторы, неплохо бы их как-то еще и заряжать. Полез гуглить простые зарядки и тут мне открылся “о дивный новый мир”.

Одним из преимуществ веб-сервисов является относительная простота тестирования. Действительно, в простейшем случае все, что нам нужно для проверки работы веб-сервиса – это отправить правильно сформированный HTTP-запрос любым удобным способом и проверить, что вернулось в ответ. С помощью SoapUI – инструмента для всевозможных видов тестирования веб-сервисов (более подробно о возможностях можно почитать на официальном сайте) – этот процесс можно сделать еще удобнее, автоматизировав его: мы можем создать набор тестов, указав в нем, какие запросы следует отправлять, и задав набор правил, которым должны удовлетворять ответы от сервиса. Но, тем не менее, эти тесты мы по прежнему должны будем запускать руками, а душа жаждет полной автоматизации. Действительно, почему бы не запускать эти тесты автоматически при сборке приложения (на CI-сервере или прямо на машине разработчика)?

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

Компилировать проект ручками — занятие весьма утомительное, особенно когда исходных файлов становится больше одного, и для каждого из них надо каждый раз набивать команды компиляции и линковки. Но не все так плохо. Сейчас мы будем учиться создавать и использовать Мейкфайлы. Makefile — это набор инструкций для программы make, которая помогает собирать программный проект буквально в одно касание.

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

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

Тема радиации заинтересовала меня после прочтения статьи про брелок Гейгера. Как справедливо заметил в комментариях KbRadar, брелок является сигнализатором опасности, а не поисковым прибором для сравнения мощности фона излучения в разных местах. Поэтому мне захотелось обзавестись простейшим дозиметром-радиометром с экраном. Я написал в Даджет и заказал для обзора дозиметр Defender СОЭКС. Оказалось, что прибор уже снят с производства, и мне достался последний имевшийся в наличии экземпляр. Поэтому далее в статье не буду подробно описывать данный конкретный гаджет, а лишь приведу результаты проведенных с его помощью исследований.

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

Почему я это решил написать? Всё просто: я убил 3 недели времени на то, чтобы разобраться с чего начинать и как это работает. Кроме того, попробую собрать небольшой каталог ссылок по работе с ESP8266. Надеюсь, что эта информация поможет сэкономить вам хоть толику времени.



Итак, приступим!

Некоторое время назад я опубликовал тут свою статью, посвященную проблеме благоустройства дворов: habrahabr.ru/post/257563
В статье рассматривался алгоритм, позволяющий по плану местности предсказать, где пешеходы будут сходить с дорожек и топать по газонам, разнося грязь и портя всю красоту. Алгоритм представлял собой симуляцию движения пешеходов на заданной местности с помощью доработанного A* и модифицируемого во время движения навигационного графа.

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

Продемонстрирую процесс применения сервиса на примере вот этого участка проспекта Стачек в Санкт-Петербурге:



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

Про измерение CO2 и его важность на Geektimes было уже немало публикаций (ссылки в конце статьи). Здесь же хочу описать проект компактного монитора уровня CO2, а также температуры, влажности и давления с Wi-Fi, обновлением прошивки по воздуху и интерфейсом в мобильном приложении. Сердца системы модуль на базе esp8266, сенсор CO2 MH-Z19 и фреймворк esp8266-arduino. И так, включим устройство в USB-розетку: