Дочь занимается изготовлением украшений из полимерной глины и как-то пришла ко мне с просьбой. Хочу, говорит, снимать рекламные ролики своих изделий на видео, и публиковать их в Инстаграме.

После уточнения всех её хотелок и нескольких экспериментов были сформированы примерные требования к проекту «видеосъемка для интернета»:

1. Съемка видео должна выполняться с использованием штатива (в противном случае на видео заметны движения оператора)
2. Требуется поворотный стол для экспозиции небольших предметов (так как камера располагается на штативе, а необходимо показать изделия со всех сторон).
3. Съемка должна вестись на камеру мобильного телефона, т.к. одно из мест для публикации, это Instagram, в котором опубликовать видео можно только с мобильника

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

Внимание, дальше картинки и видео!

В очередной раз увидел на Хабре статью про сложное дело под названием «программирование». И то, что программирование действительно является делом не простым воспринимается как факт и обычно не требует какого либо подтверждения.

Но понятие «сложность» сродни термину «куча». Для кого-то и пять кокосов это не куча, а кого-то съел один и «больше не хочется» — значит для него и единственного кокоса будет много.

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

Обычно разговоры о «сложности» включают в себя только оценочные суждения без какой либо численной оценки. А так как лично меня интересует вопрос сложности языков программирования, то я решил посчитать сложность реализации компилятора gcc в каких нибудь условных попугаях. Вдруг можно будет увидеть какие нибудь закономерности?

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

И это очень сильно напоминает развитие технологий, как и в любой другой области техники. Когда с очередным этапом совершенствуются создаваемые творения. Быстрее, выше, сильнее … и одновременно значительно сложнее.

Об этой проблеме меня заставила задуматься первоапрельская статья «Доказательное программирование»

Понятно, что дата публикации статьи говорит сама за себя. Тем не менее, новые стандарты С++, постоянно выходящие спецификации Java или новый синтаксис у PHP 8, невольно заставляют задуматься, а в нужную ли сторону идет развитие языков программирования? Ведь большинство нововведений добавляют сложность в основной рабочий инструмент и решая одни проблемы, неявно добавляя множество других.

А что должно быть в конце прогресса у развития такой дисциплины как программирование? Или хотя бы у одного конкретного языка? Ради достижения какой конечной «идеальной» цели разрабатываются новые стандарты языков программирования?

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

Например, при работе в STM32 CubeIDE, вся настройка параметров работы периферии сводится к вводу правильной частоты кварца и условного «кликанья мышкой», вместо того, чтобы программировать параметры работы железа вручную.

В продолжение серии статей про различные полезности для STM32 (1, 2 и 3), хочу рассказать, как в некоторых случаях, такое упрощение работы может стать источником совершенно не очевидных ошибок.

Почему «очередной»? Потому что первую мою статью о найденном способе обхода правил Хабра, прилетевшее НЛО принудительно скрыло в черновики, где она остается и по сей день.

Но тот способ можно было применять деструктивно, поэтому с таким решением НЛО я полностью согласен. Да и сама статья предназначалась в первую очередь для привлечения его внимания (практически ловил на живца), т.к. мое обращение в поддержку сайта насчет потенциальной уязвимости было проигнорировано.

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

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

При разработке программного обеспечения любого класса и назначения, зачастую приходится заниматься поиском ошибок, которые привели к краху всего приложения. И если в случае обычного компьютера, анализ логов и core dump`ов как правило не вызывает сложностей, то для устройств на основе микроконтроллеров бывает сложно получить «посмертную» информацию, необходимую для изучения проблемы.

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

В продолжение серии статей про различные полезности для STM32 (1 и 2), предлагаю вашему вниманию решение для сохранения посмертной информации микроконтроллера при возникновении различных критических ситуаций с целью последующего анализа ошибки.

Ну и в соответствии с собственным наблюдением Хабр — ума палата, буду рад любым комментариям и предложениям, которые помогут протестировать или улучшить предлагаемое решение.

Успел прочитал переводную статью «5 фактов о том, как Microsoft приватизировала открытый исходный код, убивая JavaScript в процессе». «Успел прочитать», потому что статью сразу безбожно заминусовали (через 30 минут уже было -12), а сейчас статья вообще скрыта в черновиках.

Её основная мысль была «Миссия Microsoft – так или иначе превратить каждого JavaScript-разработчика в дрон Microsoft TypeScript, приносящий деньги» за счет того, что «Microsoft внедрила использование TypeScript в React, Angular и Node, одновременно приватизировав Github и npm».

По мнению автора, именно для этого Microsoft купила Github, пакетный менеджер Npm (который является менеджером пакетов для NodeJS), а так же всячески продвигает свой VSCode как единственный редактор кода для TypeScript. И хотя все приведенные факты в статье имею место быть, но сам стиль подачи материала выглядит классической страшилкой из области теории заговоров, причем написанной человеком, который всей душой искренне любит JavaScript и ненавидит Microsoft.

Наверно я так и прошел бы мимо, если бы сам немого не кодил на JavaScript, и не по наслышке знаю ту боль, которую может причинить разработчику отладка на не типизированном языке. А ведь это одна из многих проблем, которую по задумке и предназначен решать TypeScript. Если бы не одно но…

В процессе работы у каждого программиста иногда встречаются неожиданные проблемы, которые возникли как будто на ровном месте. Практически по Черномырдину «никогда такого не было, и вот опять!». После этого начинаешь искать решение в интернете или закапываешься в чтение мануалов и документации, чтобы разобраться в пустячном, на первый взгляд вопросе.

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

Продолжая серию статей про маленькие хитрости разработки под STM32, хочу поделиться двумя очень простыми, но полезными функциями. Они никак не тянут на полноценный проект на github.com, но способны облегчить жизнь (или наоборот, выпить немало крови), при определенном стечении обстоятельств.

1. Буферизированный вывод отладочной информации в последовательный порт
2. Автоматическое включение защиты от чтения и модификации прошивки

При разработке одного девайса на базе STM32F407 столкнулся с проблемой нехватки оперативной памяти. Назначение самого девайса не принципиально, но важно, что изначальный код писался для десктопной системы и его нужно было просто портировать на микроконтроллер под управлением FreeRTOS. А так как исходный код был написан на С++ и вопрос об экономии ОЗУ даже не стоял, то и вылезла соответствующая проблема.

Заниматься оптимизацией кода, одновременно добавляя себе проблем с поиском новых ошибок, очень не хотелось. Поэтому своевременно вспомнилось, что данная версия микроконтроллера имеет на борту дополнительный сегмент ОЗУ размером 64К (CCM SRAM), который сейчас никак не был задействован. Эврика — вот оно, решение!

Но к сожалению, все оказалось не так просто.

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

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

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

А что делать, если разработчиков в компании раз-два и обчелся, либо их опыта недостаточно для экспертной оценки предлагаемого решения? Или у них просто отсутствует время или желание вникать в чужие трудности?

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

Но в результате оказалось, что это не нужно в принципе, т.к. «не программистам» просто не требуется учиться писать программы. А если иногда такое желание и возникает, то вполне хватает обычных формализованных языков программирования, которых уже сейчас насчитывается наверно более десяти тысяч.

И пользователи, как программисты, так и не программисты, просто хотят решать возникающие перед ними задачи. И хотя задачи бывают совершенно разные, но если способ (алгоритм) её решения известен, то выбрать язык для её решения не составит никакого труда.

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

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

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

Эта проблема называется «Комбинаторный взрыв» — экспоненциальная (или более) зависимость времени работы алгоритма от количества входных данных. И есть как минимум два решения этой проблемы.

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

Если вкратце, то мне была нужна миниатюрная библиотека для микроконтроллеров с сериализатором двоичных данных и последующей передачей этих сообщений по низко скоростным линиям связи, тогда как обычные форматы xml, json, bson, yaml, protobuf, Thrift, ASN.1 и др. мне по разным причинам не подходили.

Как и ожидалось, решение оказалось более чем велосипедом, и тем не менее, сама публикация статьи на Хабре мне очень сильно помогла. Дело в том, что при первоначальном анализе возможных библиотек, я почему то упустил из вида сериализаторы MessagePack, CBOR и UBJSON.

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

После этого я прикрутил к библиотеке CBOR свой интерфейс (чтобы не перелопачивать исходники), и … решил от этого формата отказаться в пользу MessagePack :-)

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

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

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

Micro Property — библиотека для сериализации данных с минимальными накладными расходами. Она разработана для использования в микроконтроллерах и различных встраиваемых устройствах с ограничениями по размеру памяти, которым приходится работать по низкоскоростным линиям связи.

Конечно, я знаю про такие форматы как xml, json, bson, yaml, protobuf, Thrift, ASN.1. Даже нашел экзотический Tree, который сам является убийцей JSON, XML, YAML и иже с ними.

Так почему же они все не подошли? Зачем я был вынужден написать еще один сериализатор?

Уже после публикации статьи в комментариях дали несколько ссылок на пропущенные мной форматы CBOR, UBJSON и MessagePack. А они с большой долей вероятности решают мою задачу без написания велосипеда.
Жаль, что я не смог найти эти спецификации ранее, поэтому добавлю этот абзац для читателей и для собственного напоминания, что не следует торопиться писать код ;-).
Обзоры форматов на Хабре: CBOR, UBJSON

Навеяло обсуждениями к посту Как «активный гражданин» приучает людей к фишингу.

Потом, когда пришло не только жене, но и мне — полез смотреть откуда… и неожиданно узнал что рекламу теперь может слать и mos.ru
Совсем потеряли совесть…

Давно уже реализуемая практика. Стоит зарегистрироваться на портале. или оформить обращение… Не важно на mos.ru, или прокуратуру с полицией, вам тут же начнутся звонки и сомнительные смс.)
Не хочется об этих всех службах думать плохо. Но повторные обращения и снова звонки и смс. Так что борьба с мошенничеством стоит под контролем. Мошенники сами себя не ловят.)

Точно. Сходил пару раз в МФЦ и просто шквал звонков с разной рекламой. Причем сплошняком роботы текст зачитывают.

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

Эту фразу на заре своей трудовой деятельности я услышал от начальника отдела АСУ одного из Советских заводов, когда он предлагал идти работать к нему в отдел.

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

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

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

На просторах Хабра встретилась статья: Zero-click выдача и On SERP SEO: как попасть на нулевую позицию в Яндексе и Google, в которой говорится о попадания не просто в ТОП, а прямо на самую нулевую позицию поисковой выдачи. А так же приводится внушительный список рекомендаций SEO активностей, чтобы достичь желаемого результата.

Поборов некоторые сомнения, я все же решил поделиться случайно найденным простым лайфхаком для попадания в ТОП или даже в Zero-click поисковой выдачи по отдельным запросам без сложного и самое главное долгого тюнинга сайта.

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

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

Чуть больше месяца назад стал замечать, что почти каждая попытка посмотреть видео с YouTube на десктопном компьютере начинается с сообщения об ошибке.

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

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

Под катом — причина возникновения ошибки (для тех, кому лень читать, это AdBlock), и что с этим можно сделать. Конечно, кроме отключения самого блокировщика рекламы.

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

Но потом понял, что ситуация с Redis (Redis вновь меняет лицензию) в качестве примера не очень подходит. И не только из-за адской смеси различных используемых в проекте лицензий, но и дополнительной путаницы, возникающей из-за толкования терминов Open Source и Свободное ПО.

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

Ведь цифры говорят сами за себя. Суммарная выручка облачных провайдеров за последний квартал 2019 года превысила $30 миллиардов долларов. Среди них лидер — Amazon (32.4% рынка), Microsoft Azure почти в два раза меньше (17.6%), далее идут Google Cloud (6%) и Alibaba Cloud (5.4%).

Тем не менее, для компаний меньшего размера, подобный бизнес как правило не достижим. Поэтому для них вопрос коммерциализации доработок свободного программного обеспечения под Copyleft лицензиями (такими, как GPL), может оказаться вполне актуальным.

Предлагаю вашему вниманию практический способ коммерциализация доработок свободного программного обеспечения под Copyleft лицензиями, в том числе применительно к законодательству РФ.

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

• Персональные данные миллиона клиентов российских МФО выставлены на продажу в сети
• Очередная утечка базы данных клиентов, на этот раз от гипермаркета «Лента»
• Очередная утечка базы данных, на этот раз любителей алкоголя

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

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