Все потоки

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

Для решения задач я использовал несколько библиотек Python, предназначенных для работы с пространственными данными и их визуализации – GeoPandas, PyProj, Shapely, Folium, Branca, H3-Pandas, OSMnx.

Подробное описание кода, примеры картографических изображений и ссылка на полный git-проект внутри.

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

Насколько можно доверять средствам шифрования, призванным защищать вашу приватность и коммерческую тайну? Нет ли в популярных криптографических продуктах скрытых лазеек, оставленных разработчиками в корыстных целях или под давлением спецслужб?

На эти вопросы отвечают профессиональные криптографы, специалисты российской технологической компании «Криптонит».

CBDC (цифровая валюта) станет реальностью и станет важной и, возможно, доминирующей формой цифровой валюты в будущем. Суть цифровых валют — это определенность, поскольку глобальное развитие финансов требует инноваций от центральных банков. Преимущества для центральных банков очевидны: более жесткий контроль, выдающиеся возможности отслеживания и мониторинга, способность быстро реализовывать меры денежно-кредитной политики и способность противостоять растущему влиянию финтеха и финансовых институтов.  Тем не менее, у этих новых инноваций есть и темная сторона.

1. Полуавтоматические свойства и ключевое словоfield.
2. Модификатор уровня доступа file.
3. Первичные конструкторы для классов и структур.
4. Паттерн-матчинг для списков.
5. Атрибуты для Main в программах с top level statement.
6. Сырые строки без экранирования внутри строки для удобства работы с json, xml, html и регулярными выражениями.
7. Строковые литералы для UTF-8.
8. Паттерн-матчинг для Span<char>.
9. Перенос строк в выражениях интерполяции.
10. Возможность перегрузки операторов с проверкой на переполнение
11. Оператор побитового сдвига вправо без знака >>>.
12. Доступ к параметрам методов nameof.
13.nameof для членов экземпляров.
14. Ключевое слово required для обязательно инициализируемых свойств и полей.
15. Автоматическая инициализация свойств структур значением по-умолчанию.
16. generic-атрибуты.
17. локальные переменные и параметры только для чтения.
18. Кэширование делегатов при использовании method group для статических методов.
19. Поля с значением хранящимся по ссылке.
20.params Span<T>/params ReadOnlySpan<T>/params IEnumerable<T> в объявлении методов чтобы избежать лишних неявных созданий массива в куче и копирований коллекций.
21. Удаление оператора проверки параметров на null !!.
22. Предупреждения для имен типов полностью в нижнем регистре.

Внутри — разбор каждой фичи и сценарии применения.

Для тех, кто не читал предыдущую статью, расскажу о сути проекта. В 2020-2021 году я участвовал в роли руководителя команды разработчиков Внедренческого центра "Раздолье" в проекте Управление продажами в международной компании на базе "1С:ERP" (ссылка на сайт 1c.ru). Проект был выбран победителем международного конкурса «1С:Проекта года» в номинации «Лучший проект с использованием технологии "Дистанционное внедрение"».

Суть проекта заключалась в переводе Заказчика с 1С:УПП на 1С:ERP. На его примере кратко опишу, какой была организационная структура и какие программы мы использовали при взаимодействии в команде и с пользователями.

Практически весь проект выполнялся удалённо. Многие сотрудники Заказчика, участвующие в проекте, в условиях карантинов и локдаунов были переведены на удалённую работу. Многие сотрудники нашей компании тоже работали удалённо, с командировками в этот период были большие проблемы. Сам Заказчик работает в режиме 24х7 и является одним из крупнейших предприятий в России по производству кофе. На начало проекта в качестве основы корпоративной системы у Заказчика была программа 1С:УПП редакции 1.2 (даже не 1.3). По завершению проекта в 2021-м перешли на ERP 2.5. К слову, когда начинали работу, в 2020-м году, когда 2.5. была ещё в бета-версии, но мы решили прислушаться к рекомендациям "Фирмы 1С" запускать новые проекты на ней, а не на 1С:ERP 2.4.

Пол Грэм — американский предприниматель, известный русскому человеку, в первую очередь, благодаря своими эссе о бизнесе и жизни. В своем эссе «После эпохи дипломов» (After Credentials) Пол Грэм рассуждает о дипломах: откуда появились, для чего нужны, почему до сих пор не изжили себя, а также почему они не панацея.

Смягчение уязвимости Trojan Source, оптимизация функций приведения типов, многомерный оператор [], подавление предупреждений о вендорных атрибутах — вот лишь некоторые возможности GCC 12. Подробностями делимся к старту курса по разработке на C++.

Список заблокированных РКН ресурсов для использования с VPN стремительно теряет актуальность, поскольку, во-первых, многие ресурсы блокируются или замедляются на ТСПУ и записи для этих ресурсов в выгрузку не вносятся, во-вторых, после известных событий конца февраля многие ресурсы начали изображать РКН из себя и блокировать доступ с российских IP, в-третьих, избыточная отправка трафика в VPN приводит к недоступности уже российских ресурсов, которые отгородились от иностранных IP.

Поэтому на уже известном сервисе antifilter.download создан отдельный дополнительный сервис community.antifilter.download, предназначенный для ведения списка при помощи сообщества.

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

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

В предыдущем посте я, немного сумбурно, рассказал про библиотечку OMGlib, которая позволяет создавать полностью динамические веб-приложения. Вкратце, идея состоит в следующем: приложение использует браузер для взаимодействия с пользователем, для этого браузер открывает WebSocket-соединение с сервером, после чего просто выполняет получаемый от него javascript-код, отправляя результаты обратно через это же соединение. Все DOM-элементы при этом создаются динамически, через соответствующие функции javascript, без использования HTML вообще. Также, сервер может создавать функции в браузере и вызывать их, сгружая, таким образом, всю логику и механику, связанную с интерфейсом, прямо в браузер. Библиотечка реализована на языке Common Lisp, развитая система макросов которого позволяет писать код единообразно, просто помечая часть функций как browser-side, а компиляция их в JS происходит при помощи JSCL прозрачно для программиста.

В прошлый раз я подробно рассказывал об особенностях компании-вендора. Теперь настало время поговорить о мифах и правде в работе компании-вендора. Если тема вам интересна, то давайте начнём.

Миф 1. Особые продуктовые специалисты

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

Попробуем разобраться с качествами технического специалиста, которыми мы чаще всего оперируем для оценки в жизни:

Хороший vs Плохой

Соблазн применить эту категорию очень велик. «Хорошесть» или «плохость» не зависит от места работы, опыта работы, роста или цвета глаз. Это интегральная экспертная оценка ;-). Хорошего программиста видно по его коду, который компактен, понятен, легко поддерживается. Хорошего QA видно по въедливости, упорядоченности и понятности его кейсов. Видно его по вопросам, которые он задет до/при реализации/тестировании.

Это видно по скорости и уровню погружения в решаемую задачу и, в конце концов, по тому, к кому ходят задавать вопросы. И я не знаю, как это измерить в попугаях. Так вот, плотность хороших спецов в продуктах, аутсорсе, финтехе, abap, 1с, фронте и бэке одинаковая. И это качество точно не является специфичным для какой-то одной отрасли или направления.

Считаные недели остаются до Positive Hack Days 11. Международный форум по практической безопасности пройдет 18–19 мая в Москве. Команды атакующих и защитников для The Standoff уже сформированы, а мы завершаем подготовку инфраструктуры киберполигона и программы конференции.

Так вышло, что испытания релейной защиты обязательно проводят на специальных комплексах в режиме реального времени. Внутри этих комплексов находятся цифровые двойники электроэнергетических объектов. Чтобы разобраться как и зачем их туда загружают, мы прольем свет на всеми любимый и ненавистный стандарт МЭК 61850 и поделимся своим опытом моделирования энергосистем на КПМ РИТМ.

Статический анализатор PVS-Studio постоянно развивается: улучшаются различные механизмы, происходит интеграция с игровыми движками, IDE, CI/CD и другими системами и сервисами. Благодаря этому несколько лет назад появилась возможность использования PVS-Studio для анализа Unreal Engine проектов. Однако один из важных механизмов PVS-Studio – подавление сообщений анализатора (baselining, отключение выдачи предупреждений на существующий код) — не работал с UE-проектами. Почему он не был реализован сразу, и как в итоге была решена эта задача – читайте далее.

В этом году DevOps & TechLead Conf 2022 пройдут на одной площадке. Участников ждут погружение в инженерные процессы в IT (от XP до devOps & beyond), musthave-инструменты и практики изменений в командах для быстрых и качественных релизов.

Мы встретились с экспертами из Программного комитета конференций — Дмитрием Зайцевым и Анастасией Асеевой-Нгуен. Поговорили о болях DevOps-инженеров и техлидов, о новых форматах и о самых актуальных темах в индустрии. О том, что получилось — читайте под катом.

Я подустал от мрачных текстов и вспомнил о своей давней мечте. За 20 с хвостиком лет работы в Интел у меня развеселых историй накопилось на целую книгу. Хотелось в ретроспективе посмотреть на некоторые события, участником которых мне довелось быть. И еще хотелось отдать дань уважения компании и людям, с которыми мне посчастливилось работать. Я уже даже название придумал – Made at Intel. Понятно, что пока я был внутри конторы, речь о публикации этих баек идти не могла. Я сам подшучивал, что для публикации нужно правильно выбрать время. В смысле сначала уволиться, а потом публиковать, а не быть уволенным вследствие публикации. :) Однако примерно 2 года назад я Интел покинул, и казалось бы меня уже ничего не сдерживало. Но тут, как всегда – то перо поломается, то струна порвется, то еще какая бяда приключится. К тому же на то чтобы писать книжку – это же рeшимости набраться надо... И вот – вчера я решил, что большое надо начинать с малого. Буду писать по главке и выкладывать сюда - собирать фидбек. Так мало –помалу и наберется.

Итак, сегодня вашему вниманию представляется первая глава, в которой эволюция архитектур Intel рассматривается с точки зрения ... истории религиозных течений. Да –да, не удивляйтесь, архитектура вычислительных устройств –это одна из самых религиозных вещей. Не думайте, что все решения по Instruction Set Architecture принимаются исключительно на основе анализа данных – это совсем не так. Скорее похоже на средневековое государство – тут есть немного бизнеса, побольше политики и очень много религии. Все просто – почти любой эксперимент в этой области растягивается на годы и обходится в миллиарды долларов. Хуже всего, что в процессе дизайна можно давать лишь приблизительные оценки ключевых характеристик – частоты, производительности, энергопотребления, температурной карты. То, как все оно будет на самом деле становится понятным уже только тогда, когда чип выходит из печки. Да сейчас в этой области уже накоплен определенный опыт и наши оценки становятся несколько точнее, но и только. А 20 лет назад этих знаний было куда меньше. И пионеры, подобные Интел двигались в темноте на собственный страх и риск. Разумеется, в таких условиях на первый план выходит кто во что ВЕРИТ. Ну да – еще кто лучше говорить умеет. Поэтому лучшие архитекторы приходят из школ с углубленным изучением богословия. :)

Самый больной вопрос для любого разработчика, которому приходится вычитывать данные из базы: "Как сделать мой запрос быстрее?". Классический ответ - необходимо создать подходящий индекс. Но куда именно его стоит "накатывать", да и как вообще он должен выглядеть?..

Мы научили наш сервис визуализации планов PostgreSQL отвечать на эти вопросы, и под катом расскажем, чем именно он руководствуется в своих рекомендациях.

Как вы могли заметить, я давно работаю с процессором STM32 ARM при помощи Mbed. Были времена, когда Mbed был весьма прост, но многое изменилось с тех пор, как он превратился в Mbed OS. К сожалению, это означает, что многие примеры и библиотеки, которые вы могли бы найти, с относительно новой системой работать не будут.

Мне нужен был поворотный энкодер — и я вытянул дешевый экземпляр из одного набора «49 плат для Arduino», какие продаются повсюду. Уверен, это не самый филигранный поворотный шифратор из имеющихся в природе, но для поставленной задачи его должно было хватить. К сожалению, в Mbed OS нет драйвера для такого датчика, а первые несколько сторонних библиотек, которые я нашел, либо работали по принципу опроса, либо не компилировались под последнюю версию Mbed. Разумеется, для чтения поворотного энкодера никакой магии не требуется. Но насколько сложно самостоятельно написать для него код? В самом деле, довольно сложно. Подумал, поделюсь моим кодом и расскажу, как к этому коду пришел.