Гифки в ScreenToGif
ScreenToGif умеет записывать видеоряд с экрана, редактировать его и сохранять в gif или видео. Без звука, только картинка. Написан на C#, опенсорс.
Как бы это не было странно, но инструмент по созданию gif-ок оказался полезен и в разработке.
С помощью ScreenToGif решаю такие задачи:
1. Визуализация воспроизведения бага для баг-трекера или отчета. У ScreenToGif записанный видеоряд представляется в виде последовательности скриншотов. Поверх скриншотов можно что-то нарисовать: стрелки, подписи, рамки и т.п. Очень подходит для вставки дополнительных пояснений при воспроизведении бага.
2. Запись происходящего на экране в целях отладки. Не все программы пишут свои логи в файлы. Некоторые выводят свои сообщения только на экран. Да ещё и так быстро, что невозможно успеть что-то разобрать. Иногда и проскроллить обратно нельзя. Поэтому покадровый просмотр записи экрана оказывается полезным. К тому же некоторые скриншоты потом тоже использую в отчетах.
ScreenToGif умеет записывать видеоряд с экрана, редактировать его и сохранять в gif или видео. Без звука, только картинка. Написан на C#, опенсорс.
Как бы это не было странно, но инструмент по созданию gif-ок оказался полезен и в разработке.
С помощью ScreenToGif решаю такие задачи:
1. Визуализация воспроизведения бага для баг-трекера или отчета. У ScreenToGif записанный видеоряд представляется в виде последовательности скриншотов. Поверх скриншотов можно что-то нарисовать: стрелки, подписи, рамки и т.п. Очень подходит для вставки дополнительных пояснений при воспроизведении бага.
2. Запись происходящего на экране в целях отладки. Не все программы пишут свои логи в файлы. Некоторые выводят свои сообщения только на экран. Да ещё и так быстро, что невозможно успеть что-то разобрать. Иногда и проскроллить обратно нельзя. Поэтому покадровый просмотр записи экрана оказывается полезным. К тому же некоторые скриншоты потом тоже использую в отчетах.
👍1
Поверхностный багфикс
Есть такое понятие - “поверхностная медицина”. Это когда врач цепляется за первую попавшуюся болячку или нестыковку, которой объясняет проблему пациента. При этом другие возможные причины болячки не проверяет.
Был пациент с микроинсультом. Пациента обследовали, сняли КТ, и кардиолог обнаружил незакрытое овальное окошко в сердце. Доктор тут же обозначил это как причину инсульта и назначил операцию по закрытию окошка. Пациент же на всякий случай сходил к другому кардиологу, который решил проверить другие варианты возникновения инсультов и повесил на пациента холтер на 12 часов.
В итоге была обнаружена аритмия, проявляющаяся в течение дня и особенно во сне. А именно аритмии с гораздо большей вероятностью приводят к инсульту, чем дефекты анатомии сердца. Обычное медикаментозное лечение позволило устранить проблему без операционного вмешательства.
Аналогичные вещи происходят и в поиске источника бага в программе. Программист спешит устранить симптом, который лежит на поверхности, не доходя до истинного источника проблемы. Таким образом проблема продолжает неявно существовать до своего следующего проявления.
Про поверхностную медицину см. здесь: Эрик Тополь - Искусственный интеллект в медицине. Как умные технологии меняют подход к лечению.
Есть такое понятие - “поверхностная медицина”. Это когда врач цепляется за первую попавшуюся болячку или нестыковку, которой объясняет проблему пациента. При этом другие возможные причины болячки не проверяет.
Был пациент с микроинсультом. Пациента обследовали, сняли КТ, и кардиолог обнаружил незакрытое овальное окошко в сердце. Доктор тут же обозначил это как причину инсульта и назначил операцию по закрытию окошка. Пациент же на всякий случай сходил к другому кардиологу, который решил проверить другие варианты возникновения инсультов и повесил на пациента холтер на 12 часов.
В итоге была обнаружена аритмия, проявляющаяся в течение дня и особенно во сне. А именно аритмии с гораздо большей вероятностью приводят к инсульту, чем дефекты анатомии сердца. Обычное медикаментозное лечение позволило устранить проблему без операционного вмешательства.
Аналогичные вещи происходят и в поиске источника бага в программе. Программист спешит устранить симптом, который лежит на поверхности, не доходя до истинного источника проблемы. Таким образом проблема продолжает неявно существовать до своего следующего проявления.
Про поверхностную медицину см. здесь: Эрик Тополь - Искусственный интеллект в медицине. Как умные технологии меняют подход к лечению.
🔥5👍1
Донни Браско
Джозеф Пистоне, он же Донни Браско, - агент ФБР по внедрению. Известен тем, что шесть лет проработал под прикрытием, внедряясь в нью-йоркскую мафию. Никто до него не проводил такую длительную операцию и не внедрялся так глубоко.
Все невероятно интересно в его истории, рекомендую познакомиться. И книги есть, и кино. Я же выделю главный для себя момент…
Раньше я писал здесь об известных учёных: Дайан Фосси, Анатолий Сагалевич. Они в каком-то смысле пионеры в своей области, первопроходцы. И точно так же Донни пионер в своей.
Все трое сталкивались с новыми вызовами: никто такого раньше не делал, такого опыта нет и некого спросить. Донни писал: “Самые тяжёлые решения надо принимать самостоятельно и с ходу… Мне, например, не приходилось рассчитывать на руководителей ФБР из Вашингтона”. Один на один со своей проблемой, никто не поможет.
Такие истории вдохновляют. Мы, программисты, нередко оказываемся в похожей ситуации. Особенно в инновационных проектах, где степень повторяемости задач низкая. В этом бесконечном пространстве вопросов и ответов нам нужно найти правильные. Правильные вопросы и правильные ответы. Невозможно сказать: “Я не знаю”. В любом случае что-то мы должны сделать: пусть не точное или где-то ошибочное. Потом от этого мы сможем оттолкнуться. И если не мы сами, так новые умы.
#КнижнаяПолка
Джозеф Пистоне, он же Донни Браско, - агент ФБР по внедрению. Известен тем, что шесть лет проработал под прикрытием, внедряясь в нью-йоркскую мафию. Никто до него не проводил такую длительную операцию и не внедрялся так глубоко.
Все невероятно интересно в его истории, рекомендую познакомиться. И книги есть, и кино. Я же выделю главный для себя момент…
Раньше я писал здесь об известных учёных: Дайан Фосси, Анатолий Сагалевич. Они в каком-то смысле пионеры в своей области, первопроходцы. И точно так же Донни пионер в своей.
Все трое сталкивались с новыми вызовами: никто такого раньше не делал, такого опыта нет и некого спросить. Донни писал: “Самые тяжёлые решения надо принимать самостоятельно и с ходу… Мне, например, не приходилось рассчитывать на руководителей ФБР из Вашингтона”. Один на один со своей проблемой, никто не поможет.
Такие истории вдохновляют. Мы, программисты, нередко оказываемся в похожей ситуации. Особенно в инновационных проектах, где степень повторяемости задач низкая. В этом бесконечном пространстве вопросов и ответов нам нужно найти правильные. Правильные вопросы и правильные ответы. Невозможно сказать: “Я не знаю”. В любом случае что-то мы должны сделать: пусть не точное или где-то ошибочное. Потом от этого мы сможем оттолкнуться. И если не мы сами, так новые умы.
#КнижнаяПолка
👍3👌1
Запуск DrMemory из QtCreator
Продолжая тему анализатора утечек памяти DrMemory, сделал инструкцию по запуску DrMemory из QtCreator.
Полезно раскладывать нужные инструменты под рукой. Как минимум не так лениво будет ими воспользоваться.
Продолжая тему анализатора утечек памяти DrMemory, сделал инструкцию по запуску DrMemory из QtCreator.
Полезно раскладывать нужные инструменты под рукой. Как минимум не так лениво будет ими воспользоваться.
🙏1
Выбор вещественного типа C++
В C++ есть два типа вещественных чисел:
- Используем
- Используем
- Есть ещё
When do you use float and when do you use double
В C++ есть два типа вещественных чисел:
float и double. Отсюда часто задают вопрос, какой и когда использовать. Проще всего так:- Используем
double по умолчанию. Всегда.- Используем
float, если приходится работать с огромными массивами (порядка 10⁶ и более), где double займёт непозволительно много памяти. Но нужно учесть риски снижения точности float по отношению к double.- Есть ещё
long double, который нужно использовать, если не хватило точности double. В своей практике я с таким не сталкивался.When do you use float and when do you use double
👍2
Тайм-менеджмент и кандидатская диссертация
Нашел старый документ, где я пытался управлять своим временем, когда готовил кандидатскую. Я вел обычный учет трудозатрат с небольшой статистикой в LibreOffice Calc (бесплатный Excel).
Выглядит занятно и в какой-то степени маниакально. Но такая своего рода геймификация процесса помогла тогда организоваться. Подробности в статье.
Нашел старый документ, где я пытался управлять своим временем, когда готовил кандидатскую. Я вел обычный учет трудозатрат с небольшой статистикой в LibreOffice Calc (бесплатный Excel).
Выглядит занятно и в какой-то степени маниакально. Но такая своего рода геймификация процесса помогла тогда организоваться. Подробности в статье.
🔥4👍2
Образование
Спрашивает у меня школьник: “Как ты разрабатываешь медицинские программы без медицинского образования?”
Действительно… Я даже не сразу нашелся, что ответить. Но ответ получился простой. Оставлю здесь на случай важных переговоров.
Программу редко создает один человек. Обычно это все таки команда. Команда разных специалистов. В медицине, грубо говоря, над программой работают 3 типа специалистов: врачи, биоинженеры и разработчики. И эти три группы имеют точки соприкосновения. Что это за точки?
Врач хорошо разбирается в медицине. Биоинженер в свою очередь что-то знает в медицине и хорошо разбирается в математике. Разработчик что-то знает в математике и хорошо разбирается в разработке программ. Получается, врач с биоинженером соприкасается в области медицины: биоинженер хорошо понимает врача и может построить вычислительных процесс на языке математики. Язык математики - это точка соприкосновения биоинженера и разработчика. Разработчик переводит математические выражения в программы. Все просто.
Тем не менее в нашем не идеальном мире не всегда найдётся условный биоинженер. Тогда разработчик вынужден напрямую работать с врачом. И здесь поможет образование, кругозор и широта восприятия. Врач со своей стороны упрощает подачу мысли, а разработчик вспоминает школьный курс биологии. И наоборот. Два специалиста смогут договориться при должной подготовке и заинтересованности обоих.
Спрашивает у меня школьник: “Как ты разрабатываешь медицинские программы без медицинского образования?”
Действительно… Я даже не сразу нашелся, что ответить. Но ответ получился простой. Оставлю здесь на случай важных переговоров.
Программу редко создает один человек. Обычно это все таки команда. Команда разных специалистов. В медицине, грубо говоря, над программой работают 3 типа специалистов: врачи, биоинженеры и разработчики. И эти три группы имеют точки соприкосновения. Что это за точки?
Врач хорошо разбирается в медицине. Биоинженер в свою очередь что-то знает в медицине и хорошо разбирается в математике. Разработчик что-то знает в математике и хорошо разбирается в разработке программ. Получается, врач с биоинженером соприкасается в области медицины: биоинженер хорошо понимает врача и может построить вычислительных процесс на языке математики. Язык математики - это точка соприкосновения биоинженера и разработчика. Разработчик переводит математические выражения в программы. Все просто.
Тем не менее в нашем не идеальном мире не всегда найдётся условный биоинженер. Тогда разработчик вынужден напрямую работать с врачом. И здесь поможет образование, кругозор и широта восприятия. Врач со своей стороны упрощает подачу мысли, а разработчик вспоминает школьный курс биологии. И наоборот. Два специалиста смогут договориться при должной подготовке и заинтересованности обоих.
👍5🔥4
Предварительная обработка
Оптимизация алгоритмов по производительности зачастую решаются применением какой-либо предварительной обработки. Это чуть ли не первый вопрос, который нужно задать в начале работы.
Примеров предварительной обработки масса. Те же индексы в базах данных: использование специальной структуры значительно ускоряет выборку данных из таблицы.
Или построение модели кода средами разработки (IDE). Среда какое-то время после запуска тупит и строит модель, но после этого навигация по проекту и рефакторинг выполняются мгновенно.
Из более конкретных примеров можно рассмотреть эту задачу с собеседования. Тут, считай, все собеседование построено на проверке навыков предварительной обработки. Продемонстрированы разные варианты решений. Один из них - метод двух указателей, основанный на предварительной сортировке данных. Вообще сортировку часто можно увидеть в таких задачах.
Резюмируя,
Оптимизация алгоритмов по производительности зачастую решаются применением какой-либо предварительной обработки. Это чуть ли не первый вопрос, который нужно задать в начале работы.
Примеров предварительной обработки масса. Те же индексы в базах данных: использование специальной структуры значительно ускоряет выборку данных из таблицы.
Или построение модели кода средами разработки (IDE). Среда какое-то время после запуска тупит и строит модель, но после этого навигация по проекту и рефакторинг выполняются мгновенно.
Из более конкретных примеров можно рассмотреть эту задачу с собеседования. Тут, считай, все собеседование построено на проверке навыков предварительной обработки. Продемонстрированы разные варианты решений. Один из них - метод двух указателей, основанный на предварительной сортировке данных. Вообще сортировку часто можно увидеть в таких задачах.
Резюмируя,
Предварительная обработка – это мощный приём в арсенале программиста, особенно если вы собираетесь выполнять операцию многократно.
👍1🔥1
Сердце и механика
Опыт разработки диагностического ПО для лечения болезней сердца не позволил мне обойти стороной статью в "Юном технике" за 1985 год по биопротезированию сердечных клапанов. Наткнулся на нее случайно и сделал короткий обзор. Занятная история исследования сердца, перетекающая в осознание необходимости развития вычислительных систем.
Кстати, исследованиями руководил Валерий Сагалевич. Оказывается, это старший брат Анатолия Сагалевича, подводного исследователя, о котором я уже писал. Неожиданное совпадение.
Опыт разработки диагностического ПО для лечения болезней сердца не позволил мне обойти стороной статью в "Юном технике" за 1985 год по биопротезированию сердечных клапанов. Наткнулся на нее случайно и сделал короткий обзор. Занятная история исследования сердца, перетекающая в осознание необходимости развития вычислительных систем.
Кстати, исследованиями руководил Валерий Сагалевич. Оказывается, это старший брат Анатолия Сагалевича, подводного исследователя, о котором я уже писал. Неожиданное совпадение.
🔥5🤯1
Психологическая безопасность
Google как-то провел исследование среди 180 своих команд на тему их эффективности. Стало им интересно, почему одни команды работают лучше других. Назвали все это дело “Project Aristotle”.
Данных собрали много. Ожидалось, что лучшими окажутся команды с чёткой иерархией, строгой регламентацией процессов и явно выраженным спикером. Честно говоря, я тоже так думал. Но оказалось немного наоборот.
Лучшими показали себя творческие команды с открытым, дружеским взаимодействием. Непринуждённая обстановка и свобода выбора позволяла людям легче принимать риски и ответственность. Стало понятно, что психологическая безопасность - важный фактор для успешной работы.
Выделяют 4 уровня психологической безопасности:
- Инклюзивная безопасность: уверенность в своей вовлеченности и ценности для команды и проекта.
- Образовательная безопасность: поиск новой информации и обращение к коллегам с вопросами без боязни осуждения.
- Безопасность соучастия: возможность внесения значимого вклада в проект и признание приложенных усилий.
- Соревновательная безопасность: вовлеченность в здоровый конфликт и возможность высказать свое мнение.
Получается, что ничего нового и не открыли. Только ещё раз доказали, что любое общество строится на общении. А здоровое общение превращается в успешное взаимодействие.
Google как-то провел исследование среди 180 своих команд на тему их эффективности. Стало им интересно, почему одни команды работают лучше других. Назвали все это дело “Project Aristotle”.
Данных собрали много. Ожидалось, что лучшими окажутся команды с чёткой иерархией, строгой регламентацией процессов и явно выраженным спикером. Честно говоря, я тоже так думал. Но оказалось немного наоборот.
Лучшими показали себя творческие команды с открытым, дружеским взаимодействием. Непринуждённая обстановка и свобода выбора позволяла людям легче принимать риски и ответственность. Стало понятно, что психологическая безопасность - важный фактор для успешной работы.
Выделяют 4 уровня психологической безопасности:
- Инклюзивная безопасность: уверенность в своей вовлеченности и ценности для команды и проекта.
- Образовательная безопасность: поиск новой информации и обращение к коллегам с вопросами без боязни осуждения.
- Безопасность соучастия: возможность внесения значимого вклада в проект и признание приложенных усилий.
- Соревновательная безопасность: вовлеченность в здоровый конфликт и возможность высказать свое мнение.
Получается, что ничего нового и не открыли. Только ещё раз доказали, что любое общество строится на общении. А здоровое общение превращается в успешное взаимодействие.
🔥3👍1
Первый шаг к инженерному анализу
По роду деятельности мне приходилось исследовать и, отчасти, разрабатывать системы инженерного анализа. В основном на базе метода конечных элементов (МКЭ). Для лучшего понимания математических и алгоритмических принципов систем, реализовал пару задач на python. А чтобы труды не пропали, оставил все на GitHub.
TrussFem - реализация МКЭ для вычисления напряжённо-деформированных состояний двумерных ферменных структур. На вход программе продаётся задача в JSON-формате, а на выходе печатаются VTK-файлы с результатом. В readme есть демо и ссылки на использованную литературу.
MinFem2d - минимальная реализация МКЭ для двумерных сеток. Идею любезно позаимствовал отсюда и переписал код с C++ на python. Убил двух зайцев сразу: и с реализацией разобрался, и python подтянул. В readme тоже есть демо-картинка.
Изучайте и созидайте.
По роду деятельности мне приходилось исследовать и, отчасти, разрабатывать системы инженерного анализа. В основном на базе метода конечных элементов (МКЭ). Для лучшего понимания математических и алгоритмических принципов систем, реализовал пару задач на python. А чтобы труды не пропали, оставил все на GitHub.
TrussFem - реализация МКЭ для вычисления напряжённо-деформированных состояний двумерных ферменных структур. На вход программе продаётся задача в JSON-формате, а на выходе печатаются VTK-файлы с результатом. В readme есть демо и ссылки на использованную литературу.
MinFem2d - минимальная реализация МКЭ для двумерных сеток. Идею любезно позаимствовал отсюда и переписал код с C++ на python. Убил двух зайцев сразу: и с реализацией разобрался, и python подтянул. В readme тоже есть демо-картинка.
Изучайте и созидайте.
❤2👍1
Чем собирать python-приложения для поставки
На python удобно писать небольшие приложения. Путь "от идеи до модели" очень короткий. Но просто скрипт пользователю не поставишь, надо поставлять и дистрибутив python. Много мороки.
Для создания standalone-приложений на python широко используется pyinstaller. В одну команду можно получить exe-файл заданного скрипта. И все бы хорошо, если бы не антивирус. Файл, сгенерированный через pyinstaller, часто определяется как Троян. У меня, например, в VirusTotal приложение определялось как вредоносное в 20 из 72 анализаторов. Жесть. Windows Defender прибивает exe-файл сразу после генерации. А причина в том, что pyinstaller-ом часто собирают вредоносное ПО. Поэтому базы антивирусов содержат его генеративные шаблоны.
Но есть альтернатива - nuitka. Это аналогичный инструмент, но с немного другим принципом работы. Nuitka генерирует C-код и потом компилирует из него бинари. Вероятность определения как вредоносное ПО значительно снижается. В моем случае сгенерированный exe-шник пометили нежелательным всего 4 из 72 анализаторов. Приемлемый результат.
Сгенерированные дистрибутивы в nuitka и pyinstaller практически не отличаются по размеру. В то же время nuitka работает значительно дольше и требует наличия в системе C-компилятора. Но пусть уж так, чем: "У вас тут троян!"
На python удобно писать небольшие приложения. Путь "от идеи до модели" очень короткий. Но просто скрипт пользователю не поставишь, надо поставлять и дистрибутив python. Много мороки.
Для создания standalone-приложений на python широко используется pyinstaller. В одну команду можно получить exe-файл заданного скрипта. И все бы хорошо, если бы не антивирус. Файл, сгенерированный через pyinstaller, часто определяется как Троян. У меня, например, в VirusTotal приложение определялось как вредоносное в 20 из 72 анализаторов. Жесть. Windows Defender прибивает exe-файл сразу после генерации. А причина в том, что pyinstaller-ом часто собирают вредоносное ПО. Поэтому базы антивирусов содержат его генеративные шаблоны.
Но есть альтернатива - nuitka. Это аналогичный инструмент, но с немного другим принципом работы. Nuitka генерирует C-код и потом компилирует из него бинари. Вероятность определения как вредоносное ПО значительно снижается. В моем случае сгенерированный exe-шник пометили нежелательным всего 4 из 72 анализаторов. Приемлемый результат.
Сгенерированные дистрибутивы в nuitka и pyinstaller практически не отличаются по размеру. В то же время nuitka работает значительно дольше и требует наличия в системе C-компилятора. Но пусть уж так, чем: "У вас тут троян!"
🔥3👍2
Навигация развязок
В Санкт-Петербурге на объездной дороге проезжал сложную развязку. 2 раза проезжал и оба раза промахнулся съездом. А на таких развязках это чревато лишним десятком километров. Неприятно. Вроде бы и навигатор, и дорога перед глазами, но… мимо.
Развязка непростая: прямого направления перед глазами нет. Все направления многополосные и все поворачивают на разных уровнях. И съезда налево нет: есть движение прямо и 3 съезда направо. Мне нужен был 3-й съезд, но я благополучно уезжал на второй. Добавляла неудобства скорость. Это автомагистраль на 110 км/ч. Реагировать надо быстро.
На фоне этой проблемы появилась мысль. А почему бы навигатору не проговаривать номер съезда с развязки, как он это делает для кольца? Ну например: “Поверните на развязке направо. Третий съезд” или “Держитесь на развязке правее в третий съезд”. Съезды то я успел посчитать, я не успел понять какой из них мой. Если бы навигатор проговорил номер съезда, было бы легче.
Хотя для простых развязок, где съезда всего два (направо и налево), это скорее лишнее.
А пока самый простой вариант в таких случаях - это ориентироваться на знаки. Над съездами висят обозначения направлений. Но для этого надо хорошо запомнить маршрут и окрестности. Потому что указатель на "Дачный пр-т" мне ни о чем не говорит.
В Санкт-Петербурге на объездной дороге проезжал сложную развязку. 2 раза проезжал и оба раза промахнулся съездом. А на таких развязках это чревато лишним десятком километров. Неприятно. Вроде бы и навигатор, и дорога перед глазами, но… мимо.
Развязка непростая: прямого направления перед глазами нет. Все направления многополосные и все поворачивают на разных уровнях. И съезда налево нет: есть движение прямо и 3 съезда направо. Мне нужен был 3-й съезд, но я благополучно уезжал на второй. Добавляла неудобства скорость. Это автомагистраль на 110 км/ч. Реагировать надо быстро.
На фоне этой проблемы появилась мысль. А почему бы навигатору не проговаривать номер съезда с развязки, как он это делает для кольца? Ну например: “Поверните на развязке направо. Третий съезд” или “Держитесь на развязке правее в третий съезд”. Съезды то я успел посчитать, я не успел понять какой из них мой. Если бы навигатор проговорил номер съезда, было бы легче.
Хотя для простых развязок, где съезда всего два (направо и налево), это скорее лишнее.
А пока самый простой вариант в таких случаях - это ориентироваться на знаки. Над съездами висят обозначения направлений. Но для этого надо хорошо запомнить маршрут и окрестности. Потому что указатель на "Дачный пр-т" мне ни о чем не говорит.
👍2🔥2
vtour - виртуальный тур на минималках
vtour - это JavaScript-библиотека для создания виртуальных туров на базе цилиндрических панорам.
Идея сделать библиотеку появилась после этой статьи на Хабре, где автор с обычным фотоаппаратом делал красивые панорамы. Просто и быстро. Но на основе Flash’а. А нам он, мягко говоря, не нужен. Надо JS.
Я взял телефон, встал в центре комнаты и сделал с рук десятка два фотографий вокруг себя. В микрософтовском ICE склеил фотографии в одну круговую панораму. В Gimp немного поправил “ступеньки” в местах склейки. Итоговую панораму натянул на цилиндр на сцене three.js и разместил в центре камеру. Буквально за пару вечеров у меня на руках был тур по квартире.
На волне успеха (ну вот такие мы) предложил районному музею сделать виртуальный тур. Безвозмездно, чтобы обкатать технологию. Там охотно согласились. В процессе работы над туром музея и сформировалась библиотека vtour.
Возможности vtour:
- отображение цилиндрических панорам (вращение, масштабирование),
- переходы между цилиндрическими панорамами (тур),
- точки интереса в виде фото-спотов.
В проекте есть синтетическое демо для оценки функциональности, а музейный тур можно посмотреть здесь.
vtour - это JavaScript-библиотека для создания виртуальных туров на базе цилиндрических панорам.
Идея сделать библиотеку появилась после этой статьи на Хабре, где автор с обычным фотоаппаратом делал красивые панорамы. Просто и быстро. Но на основе Flash’а. А нам он, мягко говоря, не нужен. Надо JS.
Я взял телефон, встал в центре комнаты и сделал с рук десятка два фотографий вокруг себя. В микрософтовском ICE склеил фотографии в одну круговую панораму. В Gimp немного поправил “ступеньки” в местах склейки. Итоговую панораму натянул на цилиндр на сцене three.js и разместил в центре камеру. Буквально за пару вечеров у меня на руках был тур по квартире.
На волне успеха (ну вот такие мы) предложил районному музею сделать виртуальный тур. Безвозмездно, чтобы обкатать технологию. Там охотно согласились. В процессе работы над туром музея и сформировалась библиотека vtour.
Возможности vtour:
- отображение цилиндрических панорам (вращение, масштабирование),
- переходы между цилиндрическими панорамами (тур),
- точки интереса в виде фото-спотов.
В проекте есть синтетическое демо для оценки функциональности, а музейный тур можно посмотреть здесь.
🔥4👍1
YouTube Analyzer 2.0
Релизнул новую версию YouTube Analyzer - анализатора поисковой выдачи YouTube. Главное изменение - возможность использовать YouTube API. Поиск через YouTube API включается автоматически при вводе ключа API в настройках приложения.
По умолчанию поиск выполняется все тем же “грепом” html, так как внедрять ключ API в приложение я не стал. Дело в квотах. Бесплатно YouTube API выделяет 10 000 единиц в сутки. Один поисковый запрос в анализаторе стоит 102 единицы. То есть в сутки доступно 98 запросов. Не знаю, много это или мало. Пока понаблюдаю статистику. Возможно в будущем зашью публичный ключик в приложение.
Помимо YouTube API добавил русский язык интерфейса, темную тему и сохранение состояния приложения в настройках. Реализация на Python/PySide6 (Qt). Так что сохраняйте репу, может пригодиться.
Релизнул новую версию YouTube Analyzer - анализатора поисковой выдачи YouTube. Главное изменение - возможность использовать YouTube API. Поиск через YouTube API включается автоматически при вводе ключа API в настройках приложения.
По умолчанию поиск выполняется все тем же “грепом” html, так как внедрять ключ API в приложение я не стал. Дело в квотах. Бесплатно YouTube API выделяет 10 000 единиц в сутки. Один поисковый запрос в анализаторе стоит 102 единицы. То есть в сутки доступно 98 запросов. Не знаю, много это или мало. Пока понаблюдаю статистику. Возможно в будущем зашью публичный ключик в приложение.
Помимо YouTube API добавил русский язык интерфейса, темную тему и сохранение состояния приложения в настройках. Реализация на Python/PySide6 (Qt). Так что сохраняйте репу, может пригодиться.
🔥4👍1🤯1
Конечные автоматы
Конечный автомат - это абстрактная модель с конечным числом состояний и переходов между ними. В разработке на конечных автоматах может строиться бизнес-логика.
Но интересно, что на практике мне этот подход практически не попадался. Да, слышал, что автоматы применяют на терминалах. Также сталкивался с ними в геймдеве. Например, phaser их использует.
При этом теория автоматов звучит заманчиво. Явное описание состояний и переходов может оказаться крепким архитектурным решением. Во-первых, это известный паттерн (проще войти). Во-вторых, задаётся тенденция на расширение кодовой базы, а не ее изменение.
Но какие границы применимости? Сколько можно поддержать состояний в пределах одного компонента и не сломать себе голову? Удобно ли масштабировать?
Сразу и не ответишь. Но уже предварительно можно сказать, что даже у небольшого приложения наберётся много состояний. Логика автоматов этому способствует.
Тем не менее на новом проекте я решил пощупать эту концепцию средствами Qt State Machine. Как минимум, хочу ответить на вопросы выше. Как максимум - выработать практический пример использования и потом им поделиться.
Конечный автомат - это абстрактная модель с конечным числом состояний и переходов между ними. В разработке на конечных автоматах может строиться бизнес-логика.
Но интересно, что на практике мне этот подход практически не попадался. Да, слышал, что автоматы применяют на терминалах. Также сталкивался с ними в геймдеве. Например, phaser их использует.
При этом теория автоматов звучит заманчиво. Явное описание состояний и переходов может оказаться крепким архитектурным решением. Во-первых, это известный паттерн (проще войти). Во-вторых, задаётся тенденция на расширение кодовой базы, а не ее изменение.
Но какие границы применимости? Сколько можно поддержать состояний в пределах одного компонента и не сломать себе голову? Удобно ли масштабировать?
Сразу и не ответишь. Но уже предварительно можно сказать, что даже у небольшого приложения наберётся много состояний. Логика автоматов этому способствует.
Тем не менее на новом проекте я решил пощупать эту концепцию средствами Qt State Machine. Как минимум, хочу ответить на вопросы выше. Как максимум - выработать практический пример использования и потом им поделиться.
👍7
Как работать с легаси-кодом
Легаси-код - это историческая часть кода, с которой сложно работать. Почему? Потому что документации нет, авто-тестов нет, эксперта нет. Часто такое происходит? Да в общем-то да. В долгоживущих коммерческих проектах прям обязательно. Что делать?
Как только почувствовал, что твоя зона интереса уходит в легаси, нужно …не паниковать. Ну да, не всегда будет легко. Иногда своими руками приходится делать ведомым что-то неведомое.
Следующим шагом пытаемся понять, стоит ли овчинка выделки. То есть важна ли эта часть для бизнеса, будут ли там правки в будущем. Возможно стоить оставить все как есть и не тратить ресурсы. Либо взять и переписать все заново. Но это крайности.
Если работа с легаси неизбежна, то лучше работать инкрементально - серией самостоятельных шагов. Выгоды весомые: меньше шансов ошибиться или заблокировать разработку других фич. И чем меньше шаги, тем проще их выполнять и контролировать.
Наконец, было бы неплохо перед правками попытаться написать тесты. Сначала покрываем код тестами, потом к нему прикасаемся. Опыт такой есть и это спасало. Хотя провернешь такое далеко не всегда.
Jack Franklin - Five steps for managing legacy code
Легаси-код - это историческая часть кода, с которой сложно работать. Почему? Потому что документации нет, авто-тестов нет, эксперта нет. Часто такое происходит? Да в общем-то да. В долгоживущих коммерческих проектах прям обязательно. Что делать?
Как только почувствовал, что твоя зона интереса уходит в легаси, нужно …не паниковать. Ну да, не всегда будет легко. Иногда своими руками приходится делать ведомым что-то неведомое.
Следующим шагом пытаемся понять, стоит ли овчинка выделки. То есть важна ли эта часть для бизнеса, будут ли там правки в будущем. Возможно стоить оставить все как есть и не тратить ресурсы. Либо взять и переписать все заново. Но это крайности.
Если работа с легаси неизбежна, то лучше работать инкрементально - серией самостоятельных шагов. Выгоды весомые: меньше шансов ошибиться или заблокировать разработку других фич. И чем меньше шаги, тем проще их выполнять и контролировать.
Наконец, было бы неплохо перед правками попытаться написать тесты. Сначала покрываем код тестами, потом к нему прикасаемся. Опыт такой есть и это спасало. Хотя провернешь такое далеко не всегда.
Jack Franklin - Five steps for managing legacy code
👍3
Управление памятью в C++
C++ позволяет явно управлять выделенной памятью. Мощный инструмент.
И с этой мощью проще простого выстрелить себе в ногу.
Поэтому сообщество рекомендует:
1. Максимально использовать стек, а не кучу. И уж точно не выделять память динамически только “потому что я могу”.
2. Если динамическое выделение памяти необходимо, используем автоматическое управление ресурсами (RAII). То есть умные казатели, контейнеры и прочее, что позволяет нам не вызывать явно new/delete или хотя бы delete.
Кстати, про delete. Известно, что ОС при завершении программы сама удалит все, что мы забыли. Даже допустимо не подчищать память самому - так проще, да и программа будет завершаться быстрее. Наверное так. Но в С++ чистить за собой - хорошая привычка. Лучше ее придерживаться. Ведь в деструкторе может быть что-то большее, чем пустые скобки.
What is the philosophy of managing memory in C++?
C++ позволяет явно управлять выделенной памятью. Мощный инструмент.
И с этой мощью проще простого выстрелить себе в ногу.
Поэтому сообщество рекомендует:
1. Максимально использовать стек, а не кучу. И уж точно не выделять память динамически только “потому что я могу”.
2. Если динамическое выделение памяти необходимо, используем автоматическое управление ресурсами (RAII). То есть умные казатели, контейнеры и прочее, что позволяет нам не вызывать явно new/delete или хотя бы delete.
Кстати, про delete. Известно, что ОС при завершении программы сама удалит все, что мы забыли. Даже допустимо не подчищать память самому - так проще, да и программа будет завершаться быстрее. Наверное так. Но в С++ чистить за собой - хорошая привычка. Лучше ее придерживаться. Ведь в деструкторе может быть что-то большее, чем пустые скобки.
What is the philosophy of managing memory in C++?
👍3
Национальная безопасность
В феврале 2024 года Белый дом США выпустил отчет, в котором призвал программистов переходить на языки программирования с безопасным доступом к памяти. А если легаси и все такое, то необходимо максимально использовать memory-safe практики. На кону национальная безопасность.
Почему все так серьёзно? Потому что самые мощные эксплойты последнего времени появились на почве небезопасного управления памятью.
По версии АНБ США языки программирования Python, C#, Go, Java, Ruby, Swift и Rust считаются безопасными. Небезопасные ожидаемо C и C++, которые позволяют программисту “распускать руки” по отношению к памяти.
Но сишникам и плюсовикам расстраивается не стоит. Существуют правила безопасного поведения. Например:
- Присваивать удалённому указателю NULL.
- Всегда проверять выход за границы допустимых значений.
- Контролировать глубину рекурсий или вообще их не использовать.
- Всегда инициализировать переменные и указатели.
- Всегда проверять указатели на NULL, если они такими могут хоть на мгновение оказаться.
Ну и так далее. На самом деле таких практик вагон и маленькая тележка. Некоторые входят в привычку. Знать их надо.
В дополнение ко всему не надо забывать про предупреждения компилятора, юнит-тесты и статические анализаторы. Тот же cppcheck умеет находить уязвимости по разным классификаторам.
…
Не думаю, что C и C++ скоро канут в Лету. Хоронят их давно и регулярно. И тем не менее проблемы языков надо принимать и работать соответствующе.
In Rust we trust? White House Office urges memory safety
В феврале 2024 года Белый дом США выпустил отчет, в котором призвал программистов переходить на языки программирования с безопасным доступом к памяти. А если легаси и все такое, то необходимо максимально использовать memory-safe практики. На кону национальная безопасность.
Почему все так серьёзно? Потому что самые мощные эксплойты последнего времени появились на почве небезопасного управления памятью.
По версии АНБ США языки программирования Python, C#, Go, Java, Ruby, Swift и Rust считаются безопасными. Небезопасные ожидаемо C и C++, которые позволяют программисту “распускать руки” по отношению к памяти.
Но сишникам и плюсовикам расстраивается не стоит. Существуют правила безопасного поведения. Например:
- Присваивать удалённому указателю NULL.
- Всегда проверять выход за границы допустимых значений.
- Контролировать глубину рекурсий или вообще их не использовать.
- Всегда инициализировать переменные и указатели.
- Всегда проверять указатели на NULL, если они такими могут хоть на мгновение оказаться.
Ну и так далее. На самом деле таких практик вагон и маленькая тележка. Некоторые входят в привычку. Знать их надо.
В дополнение ко всему не надо забывать про предупреждения компилятора, юнит-тесты и статические анализаторы. Тот же cppcheck умеет находить уязвимости по разным классификаторам.
…
Не думаю, что C и C++ скоро канут в Лету. Хоронят их давно и регулярно. И тем не менее проблемы языков надо принимать и работать соответствующе.
In Rust we trust? White House Office urges memory safety
👍2
Гололед
Эта зима выдалась особенно интересной на дорожные условия. Чего только не было. Но сегодня вспомним про гололед. Какие системы автомобиля тут могут помочь? Шипы - шипами, а знать о попадании на лед хотелось бы до начала проблем. Ведь лед может быть невидимым, его еще называют "черный лед".
Вольным гуглом нашёл такие штуки:
- Самые простые системы предупреждают водителя о скользкой дороге, ориентируясь на температуру за бортом. Сомнительно, но окей.
- Оптические системы, определяющие лед по яркости свечения дорожного полотна. Утверждается, что алгоритм хорошо отличает лед и воду.
- Еще интереснее выглядят системы вроде лидара, где лед выявляется по степени разброса отраженного от дороги сигнала.
- Наконец, системы на основе анализа вращения агрегатов автомобиля на предмет проскальзывания. Система может оповещать как водителя, так и других участников движения по специальному протоколу.
В общем тема исследована, решения есть. Но их широкого применения нет. Поэтому стоит помнить кое-какие практики, которые помогут понять, что под колесами лед:
1. Смотреть на дорогу. Лёд все таки блестит.
2. Проверять покрытие тормозами. Нужно очень плавно отпустить газ и слегка поджать тормоз. Если под колесами лед, то они практически сразу заблокируются.
3. Слушать дорогу. На льду колеса шумят немного тише, чем на асфальте.
4. Наблюдать за машиной. Если на прямой дороге вдруг приходится подруливать, “ловить” машину, то скорее всего мы на льду. Ощущение чем-то похоже на движение со спущенным задним колесом.
5. Быть внимательным на мостах, на теневых участках, в крайней правой полосе на трассе и во время осадков в мороз. Дождь и мороз - суровый тандем, а правая полоса здорово полируется грузовиками.
Есть что добавить?
#Авто
Эта зима выдалась особенно интересной на дорожные условия. Чего только не было. Но сегодня вспомним про гололед. Какие системы автомобиля тут могут помочь? Шипы - шипами, а знать о попадании на лед хотелось бы до начала проблем. Ведь лед может быть невидимым, его еще называют "черный лед".
Вольным гуглом нашёл такие штуки:
- Самые простые системы предупреждают водителя о скользкой дороге, ориентируясь на температуру за бортом. Сомнительно, но окей.
- Оптические системы, определяющие лед по яркости свечения дорожного полотна. Утверждается, что алгоритм хорошо отличает лед и воду.
- Еще интереснее выглядят системы вроде лидара, где лед выявляется по степени разброса отраженного от дороги сигнала.
- Наконец, системы на основе анализа вращения агрегатов автомобиля на предмет проскальзывания. Система может оповещать как водителя, так и других участников движения по специальному протоколу.
В общем тема исследована, решения есть. Но их широкого применения нет. Поэтому стоит помнить кое-какие практики, которые помогут понять, что под колесами лед:
1. Смотреть на дорогу. Лёд все таки блестит.
2. Проверять покрытие тормозами. Нужно очень плавно отпустить газ и слегка поджать тормоз. Если под колесами лед, то они практически сразу заблокируются.
3. Слушать дорогу. На льду колеса шумят немного тише, чем на асфальте.
4. Наблюдать за машиной. Если на прямой дороге вдруг приходится подруливать, “ловить” машину, то скорее всего мы на льду. Ощущение чем-то похоже на движение со спущенным задним колесом.
5. Быть внимательным на мостах, на теневых участках, в крайней правой полосе на трассе и во время осадков в мороз. Дождь и мороз - суровый тандем, а правая полоса здорово полируется грузовиками.
Есть что добавить?
#Авто
👍4
Поиск информации по проекту
Согласно опросу на Stack Overflow, четверть разработчиков тратят более часа в день на поиск информации, необходимой для работы. Много? Ну, it depends, как говорится. В исследовательских проектах поиск информации вообще является непосредственной работой. Но сейчас немного не об этом.
Где разработчики ищут информацию о проекте? Гугл тут бесполезен - он поможет только в общих вопросах по открытым технологиям. Поэтому в первую очередь разработчик идет в базу знаний проекта: вики, данные репозитория, трекер задач, пользовательская документация и т.п.
Во вторую очередь обращаются к экспертам. Это спецы, которые досконально знают если не весь проект, то какую-то его часть. Все вместе эти ресурсы отвечают на все вопросы проекта.
Но что искать, где искать и у кого спрашивать? Для ответа тут тоже нужен эксперт. Тимлид например. Но эти вопросы сами по себе типовые и ответы на них могут быть в базе знаний. Поэтому надо ее правильно организовать.
В Compass от Atlassian для решения проблемы предлагают вести каталог компонентов проекта. Кто работает над компонентом, как с ними связаться, где лежит репозиторий, какие у проекта зависимости, где техническая документация и ссылки на дополнительную информацию. В общем все, что хотелось бы знать о конкретной части проекта содержится в каталоге. Причем за разработчиками остается право на расширение информации. Что логично в свете развития проекта.
Также в Compass предлагают наполнять каталог шаблонов, которые автоматизируют некоторые операции. Например, создание нового репозитория. Одной кнопкой можно создать репозиторий, отвечающий требованиям проекта, с уже настроенной непрерывной интеграцией.
Конечно, я не призываю использовать Compass, а говорю о его структурной идее, которая на мой взгляд действительно поможет ориентироваться в проекте и без привлечения эксперта. Каталог компонентов и каталог шаблонов до определенного уровня можно реализовать и в рамках вики. Главное - структура и содержание. А каталог шаблонов не обязательно автоматизировать. Достаточно зафиксировать шаблонные конструкции кода, которые легко переиспользовать в проекте.
Who owns this tool? A software component catalog to help devs find answers
Согласно опросу на Stack Overflow, четверть разработчиков тратят более часа в день на поиск информации, необходимой для работы. Много? Ну, it depends, как говорится. В исследовательских проектах поиск информации вообще является непосредственной работой. Но сейчас немного не об этом.
Где разработчики ищут информацию о проекте? Гугл тут бесполезен - он поможет только в общих вопросах по открытым технологиям. Поэтому в первую очередь разработчик идет в базу знаний проекта: вики, данные репозитория, трекер задач, пользовательская документация и т.п.
Во вторую очередь обращаются к экспертам. Это спецы, которые досконально знают если не весь проект, то какую-то его часть. Все вместе эти ресурсы отвечают на все вопросы проекта.
Но что искать, где искать и у кого спрашивать? Для ответа тут тоже нужен эксперт. Тимлид например. Но эти вопросы сами по себе типовые и ответы на них могут быть в базе знаний. Поэтому надо ее правильно организовать.
В Compass от Atlassian для решения проблемы предлагают вести каталог компонентов проекта. Кто работает над компонентом, как с ними связаться, где лежит репозиторий, какие у проекта зависимости, где техническая документация и ссылки на дополнительную информацию. В общем все, что хотелось бы знать о конкретной части проекта содержится в каталоге. Причем за разработчиками остается право на расширение информации. Что логично в свете развития проекта.
Также в Compass предлагают наполнять каталог шаблонов, которые автоматизируют некоторые операции. Например, создание нового репозитория. Одной кнопкой можно создать репозиторий, отвечающий требованиям проекта, с уже настроенной непрерывной интеграцией.
Конечно, я не призываю использовать Compass, а говорю о его структурной идее, которая на мой взгляд действительно поможет ориентироваться в проекте и без привлечения эксперта. Каталог компонентов и каталог шаблонов до определенного уровня можно реализовать и в рамках вики. Главное - структура и содержание. А каталог шаблонов не обязательно автоматизировать. Достаточно зафиксировать шаблонные конструкции кода, которые легко переиспользовать в проекте.
Who owns this tool? A software component catalog to help devs find answers
👍3🔥1