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

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

Начнём мы с первого метода – фильтра Хэмплея. В этой статье речь пойдёт именно о нём. Я постараюсь как можно проще рассказать о его особенностях и показать всё на наглядных примерах. Приступим.

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

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

Откуда столько названий стандартов USB? Какие допустимые потери сигнала в кабеле по спецификации, и почему почти никто ей не следует? Как измерить потери в дифференциальной линии и не продать почку?

Статья будет наиболее полезна для hardware-инженеров, разрабатывающих системы с высокоскоростными интерфейсами, но рассчитана на базовый уровень знаний в электронике. Узнаем о истории стандарта, понятии потерь, способах оценки и измерений.

• У них есть срок службы. Обычно он составляет 20–25 лет, после чего нужно будет сделать «капремонт». Собственно, поэтому в цену хорошего импланта входит поддержка производителем 25 лет, иначе есть шансы не обнаружить комплектующие и вырывать его, а потом ставить новый. Так себе удовольствие.
• Искусственные зубы нужно чистить. Да, они искусственные, но вот бактерии на них прилетают вполне себе живые.
• Не стоит пропускать ТО: это та же самая полугодовая гигиена, что для живых зубов, но другими инструментами (без металла).
• Требования к домашней чистке у имплантированных зубов выше, чем у «родных»: нужны ирригатор, ёршики и нить.

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

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

Если ситуация вдруг кажется вам знакомой - добро пожаловать под кат.

Ноутбук — главный девайс в моей жизни, я провожу за ним бо́льшую часть суток. Он должен быть лёгким, компактным и мощным. Долгое время лидером по этим параметрам был Dell XPS 13, но всё поменялось с выходом MacBook Air на процессоре M1.

Air всего на 100 граммов тяжелее XPS 13, но примерно в три раза мощнее, автономнее и не нуждается в активном охлаждении. Никогда не думал, что скажу подобное про технику Apple, но MacBook Air — самое крутое устройство в своей весовой категории на рынке, оставившее конкурентов далеко позади.

Я фанат Линукса, эта операционная система для меня больше, чем просто окружение. Это философия, новостная повестка и постоянный предмет обсуждения. Поэтому сама идея отказа от Linux в пользу другой ОС меня всегда отталкивала. Да и тот эпизодический опыт, когда приходилось что-то делать в macOS, был эмоционально неприятным.

Но появление M1 посеяло во мне зерно сомнений: мой ноутбук больше не был самым крутым и навязчивой мыслью было то, что я отказываю себе в чём-то большем. Это зерно прорастало и проросло: я купил MacBook Air с 16GB ОЗУ и 512GB SSD, с удивлением обнаружив, что он ещё и стоит дешевле моего XPS. Впереди меня ожидали настройка окружения, борьба с Docker, грусть от отсутствия привычного автодополнения в консоли и много чего ещё.

Мы живем в удивительное время: компьютеры окружают нас со всех сторон. Любимый смартфон, ноутбук на работе, медицинские приборы, браслеты и часы. Умные рекламные табло, самокаты и автомобили. 

В основе каждого такого устройства лежит тот или иной микропроцессор. А простой микрокомпьютер размером со спичечный коробок (на базе Atmega или STM32) можно положить в карман или установить в качестве дверного звонка. Мы живем в будущем, не особенно-то его замечая. Но до начала 1980-х ни один советский радиолюбитель даже мечтать не мог о домашнем персональном компьютере.

Сегодня мы попробуем взглянуть на первые микропроцессоры, применявшиеся на территории нашей страны. Первая статья нашего небольшого цикла будет целиком посвящена 8-битным CPU, которые так или иначе выпускались на территории Советского союза и СНГ.

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.

50 лет назад, 15 ноября 1971 года компания Intel представила процессор 4004. Трудно переоценить значимость этого события, именно с этой даты началась эра архитектуры x86, которую мы знаем и сегодня.

Поздравляю компанию Intel с этой знаменательной датой!

Далее будет немного истории, много теории, ещё больше практики и оригинальных фот.

Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.

Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.

В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть На самом деле, суть не в этом, мог быть любой другой язык, где еще нет готовой библиотеки, и соответственно автор должен пройти весь путь с нуля. Тем более, криптография дело такое — доверяй, но проверяй. С продуктом, нацеленным на безопасность, вы не можете просто взять и положиться на готовую библиотеку от производителя, слепо ему поверив (впрочем, это тема более для второй части). На данный момент библиотека вполне работает на "среднем" уровне (позволяет делать любые API-запросы).

Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?