Skip to main content

Дмитрий Мурзинов

Одной строкой

Днём я инженер, а по вечерам — подающий надежды баскетболист. В юности получил радиотехническое образование с уклоном в цифровую обработку сигналов. Пишу на Verilog, рисую в PCAD, для мелких задач использую Assembler/Embedded C.

 

Чем интересно заниматься

Основной используемоей ОС является линукс (RHEL|CentOS 6|7). Из последних профессиональных интересов: увлечение криптографией и железной реализацией криптоалгоритмов. Также сильно затягивает исследование недокументированных возможностей автоэлектроники.  

Принципы..

..которым стараюсь следовать в разработке:

  • простота: если решение задачи оказывается слишком сложным, то с вероятностью 100% способ решения неверен
  • велосипедостроение: прежде чем изобретать свой способ решения, неплохо было бы оглядеться: может быть, кто-то уже решил проблему и сделал это лучше, чем мы можем себе представить. не забываем про отраслевые стандарты консорциумов ISO, IEEE, IEC, SAE и такие ресурсы как GitHub.com, OpenCores.org, etc…
  • время-деньги: низкоквалифицированную и рутинную работу делегировать как можно чаще, постоянно повышать планку делегируемых работ
  • unix-way: по возможности, устройство/модуль/программа должны реализовывать одну законченную функцию, но зато делать это хорошо
  • автоматизация: если действие повторяется больше трёх раз, то пора это действие тем или иным способом автоматизировать. варианты: написать макрос, создать Makefile, засунуть скрипты под cron, в pre/post-commit хуки, чтобы делать всю грязную работу
  • бритва Оккама: помимо того, что не нужно умножать сущности, всегда помнить о тезисе «это нам никогда не понадобится»… и, скорее всего, оно не понадобится на самом деле
  • декомпозиция: не пытаться решить ВСЮ задачу СРАЗУ: просто поверить, что это невозможно. Если разбить задачу на части, то решение подзадач становится вполне осязаемым
  • opensource: возвращать наработки в сообщество
  • документация:
    • черновик документации, заметки «на полях» сегодня — лучше чем обещание выпустить «идеальную документацию» через месяц (через месяц часто уже и не вспомнить деталей, почему выбрал то или иное решение)
    • визуальное документирование творческо-мыслительного процесса на ментальных картах (только рукотворные MindMap)
    • отсутствие документации на открытые исходники (минимальное объяснение назначения и как пользоваться) == закрытые исходники

 

Консалтинг

Могу помочь по таким направлениям как Радиотехника, Автоэлектроника, ЦОС, [СБ|ПЛ]ИС; неполный перечень услуг:

  • Анализ практической осуществимости проекта
  • Технический аудит проектов
  • Архитектурная спецификация СФ-блоков
  • Анализ протоколов методом обратной разработки
  • Ускорение вычисления функций цифровой обработки сигналов
  • Помощь в подборе элементной базы
  • Миграция проектов на другие платформы|производителей

 

Связь с автором

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

Соглашение о конфиденциальности: В соответствии с ФЗ, данные, отправляемые через эту форму хранятся как персональные данные; Вы, нажимая кнопку «отправить сообщение», даёте своё согласие на обработку персональных данных (или что-то вроде того).  

 

Контакты

iDoka
13 repositories, 4 followers.

PS: если заметка помогла Вам, поделитесь ей с друзьями или коллегами: