В параллелях генерируются GUIDы, что дает уникальность.
Вообще говоря, реализация метода Guid.NewGuid() зависит от операционной системы:
в Windows Guid создаётся силами native-библиотеки ole32.dll (метод CoCreateGuid) (исходный код .NET 9). На rsdn есть древняя статья, в которой препарировали реализацию CoCreateGuid того времени. И обнаружили там достаточно предсказуемые данные.
в Linux же Guid может создаться как через вызов криптографического генератора случайных чисел, так и обычного (снова исходный код .NET 9).
Вывод 1: считать сгенерированные данным кодом Guid-ы случайными можно только в определённом окружении.
Далее этот массив байт подвергается криптохэшированию, что дает полную непохожесть наборов байт (а исходные GUIDы похожи друг на друга, хоть и отличаются).
Любая функция хэширования обладает свойством детерминированности. То есть при передаче ей одного и того же значения она будет возвращать один и тот же результат. Посчитайте хоть один раз, хоть миллион любую функцию хэша от Guid.Parse("be6296a3-fc24-4f58-a450-a874a333f8cd") - результат всегда будет одним и тем же.
То есть если взять периодическую последовательность и прохэшировать её блоками фиксированного размера (в вашем случае по 12 байт), в результате вы также получите периодическую последовательность.
Вывод 2: реализованное хэширование не увеличит "случайность" в ваших исходных данных - поэтому его можно вообще удалить из кода.
UPD: увидел комментарий
SHA512 дает нужную максимальную длину итоговых строк.
Для выравнивания длины строки использование хэша идея не самая хорошая, уж проще случайными байтами дозаполнять.
Или сразу генерировать нужное количество байт через упомянутый выше System.Security.Cryptography.RandomNumberGenerator
Кладу код в копилочку примеров на собеседования, на котором после показа кода первый вопрос к кандидату будет: что бы кандидат предложил переписать для уменьшения времени работы кода.
PS. А вообще выглядит как план: сначала выложить код в виде статьи на хабр, а далее собрать из комментариев идеи по его улучшению и реализовать самые лучшие.
Случайно заметим, что _context там создаётся не в начале метода - а в конструкторе контроллера.
И тут можно было бы попытаться начать искать информацию в чём разница, может быть вообще стоит один контекст на всё время работы программы сделать? Ищем информацию о времени жизни контекста - находим DbContext Lifetime, Configuration, and Initialization. Перепишем вывод из этой статьи - один контекст на один UnitOfWork...
Вот так, постепенно, и можно собрать информацию на статью - максимально полное описание.
Давайте всё же сделаем скидку на то, что это первая статья.
А я буду держать кулачки за то, чтобы автор продолжил свою работу по изучению интересных ему тем - и с каждым новым разом разборы получались чуть глубже ;)
у руководителя что-то щелкнуло, меня "оградили" от этого
Кажется, ваше начальство на практике столкнулось с ситуацией "не каждый senior хочет вырасти в лида/менеджера". И вдвойне хорошо, что "щелчок" произошёл до вашего выгорания и/или смены места работы.
При наличии JavaScript - разумеется есть. Поищите: в интернете есть несколько проектов конвертеров md -> html.
Лично мне чисто по описанию понравился https://github.com/showdownjs/showdown. Его можно использовать как в бэкенде (node.js), так и прямо в браузере. Примеры есть в самом репозитории.
Увидев в статье, что автор разбирал камеру на чипе ANYKA AK3918EN080 я аж встрепенулся =)
Дело в том, что у меня самого всё никак руки не доходят разобраться с прошивкой почти что такой же камеры:
чип ANYKA AK3918EN080,
WiFi Realtek RTL8188US,
флеш BH1634 25Q64CS16.
А вот так эта камера выглядит в неразобранном виде:
И это не шутка: коллекционка Mass Effect Andromeda сделана на базе поворотной камеры на чипе ANYKA - просто поворотный механизм заменили на приличной такой мощности двигатели.
API управления простой как три копейки (он по их приложению для Android реверс-инжинирится вообще без проблем). Но вот "влезть" в прошивку чтобы поменять поведение у меня пока руки пока не дошли (да и боюсь немного - дампа исходной прошивки пока нет).
Поэтому расскажите: не пробовали ли вы к текущему моменту собрать модифицированную прошивку? Если пробовали, не поделитесь ли инструкцией?
Или это просто был шаг обучения и продолжать работать именно с подобным устройством вы не будете?
UPDATE. Более подробное изучение темы показало, что venv будет менее удобен при наличии зависимостей от не python библиотек.
Например, использование того же плагина with-pdf требует наличия в системе пакетов pango, для русского языка ttf-ubuntu-font-family, а также некоторых других (полный список есть в статье) - и вот это всё придётся всё равно ставить в основную систему.
А в случае докера это всё-таки можно "спрятать" в образ.
Вы абсолютно правы: картинки можно как hfcgjkfufnрасполагать рядом с файлом markdown, так и определять в отдельные папки, прописывая при этом в самом markdown относительные пути.
Я предпочитаю класть картинки в подпапку ./images.
В файле index.md есть, к примеру, ссылка на картинку shortcut_internet_mode.png, расположенную в подпапке images. И вот как выглядит добавление картинки в самом файле:
Наверное, можно предложить и разработчикам mkdocs добавить такой вариант прямо на страницу getting started - а не только сослаться на подобный метод в одном из абзацев раздела troubleshooting-а.
Замечу, что мы — команда разработки десктопных приложений для Windows, поэтому сборка и выкладка docker-образов пока что не про нас (вот ASP.NET Core команда — это другое дело, может скоро и их затащим).
В общем:
Кое-где закидываем через SSH (job-а запускается под linux и scp-шкой закидывает нужные файлы).
Кое-где кидаем через WebDAV (job-а запускается также под Linux и у нас кто-то, примонтировав через davfs2 закидывает rsync-ом, а кто-то типа меня через кастомный скрипт на powershell core).
А непосредственно доставкой до клиента после выкладки на публичный сервер занимается самописный обновлятор (сделанный примерно во времена .NET 4). Так исторически сложилось + пока функционала более, чем хватает.
Обновлятор при запуске ПО и/или раз в некоторый интервал времени лезет на сервер, смотрит нет ли новой версии и, если есть, скачивает её инсталлер и даёт пользователю выбор: запустить сразу или запустить после закрытия программы (эта же идея, к примеру, в Paint.NET реализована).
И да: там важно переключить окружение в Developer Powershell не только из-за msbuild, но и чтобы другие утилиты Visual Studio стали доступны. Например, signtool для подписи файлов.
И насчёт того, что у Nuke есть интеграция с semver.
Это реализовано через GitVersion. Мы пробовали его внедрить, но столкнулись с рядом неудобств. К сожалению, сейчас я уже помню каких (толи не смогли его подружить с Wix-инсталлером, толи ЭЦП у файлов слетала так как она происходила в нашем процессе раньше, чем срабатывал патч GitVersion).
Про портянки: здесь сложилось отсутствие в markdown оформления без переноса строк, а также моё желание "схлопнуть" весь код в с подробными комментариями в один файл (для удобства понимания).
Если открыть файл .gitlab-ci.yml в репозитории, можно убедиться, что файл без комментариев о структуре со сборкой, вызовом unit-тестов, git describe а также отправкой результатов в Telegram (упс, спойлер) занимает всего 84 строки.
Согласен, некоторые строки длинные. Тот же SonarQube требует передачи ему семи параметров с длинными мнемоническими именами (например, /d:sonar.cs.opencover.reportsPaths="$env:OPENCOVER_REPORT_FILE_PATH").
Но всё равно код достаточно простой, читаемый. И главное: его можно нарезать кусочками и добавить в любой уже рабочий Gitlab CI без подтягивания лишних зависимостей.
Теперь о Nuke: полностью с вами согласен, это отличная и динамично развивающаяся система с множеством приятных бонусов. И написана она на языке по сути нашей разработки — C#.
Почему мы её не использовали сразу? Дело в том, что для нашего проекта CI/CD создавался по моим шаблонам ещё в 2018 году, а о Nuke и его презентации на dotNext в 2017м, мы, к сожалению, услышали чуть позже.
Почему мы не переписали сборку как только узнали о Nuke? На самом деле мы не увидели явных преимуществ такого переписывания по сравнению с текущей реализацией:
нашим специалистам DevOps удобнее поддерживать код Powershell, чем C#,
существует PowerShell Gallery, в которой модно выкачать модули с очень полезными командлетами. И добавление этих модулей проще.
Например, для того, чтобы отправлять сообщения в слак, надо:
один раз установить модуль командой Install-Module PSSlack
дописать в код проверку наличия модуля и отправку сообщений (код примерный):
Если вы пользуетесь браузером с синхронизацией вкладок между устройствами (Opera, Safari) — вы передаёте информацию о посещениях нанятым разработчиками браузера людям, которые могут и проанализировать эти данные.
Если вы пользуетесь браузером со встроенным блокировщиком рекламы или устанавливаете его самостоятельно — вы передаёте информацию о посещениях нанятым разработчиками блокировщика людям, которые могут и проанализировать эти данные.
Если вы заходите на сайт, на котором есть авторизация через сервисы гугла, яндекса или иные — вы передаёте информацию о посещении нанятым разработчиками механизма авторизации людям, которые могут и проанализировать эти данные.
Забыли деавторизоваться в соц. сети? — через кнопочку "поделиться" (просто потому, что она там есть, а не когда вы её нажимаете) вы передаёте информацию о посещении нанятым разработчиками соц.сети людям, которые могут и проанализировать эти данные.
Не стоит забывать о том, что сама ОС может собирать анонимную статистику.
Ну и вишенка на торте — поверхностный анализ (иди даже модификация) трафика вашим провайдером.
Лично я уже давно смирился с тем, что список посещаемых мною сайтов могут видеть все. Считаю это ещё одной статьёй оплаты за доступ к интернету.
Но если вы:
поставили себе Linux с отключенной аналитикой,
сидите через шифрованный VPN-туннель со всех устройств (включая мобилки),
везде поставили браузер, не отправляющий никуда лишней статистики,
везде поставили плагин, который обрезает "следящие" кнопки, а также рекламу (при этом не делая запросы вообще куда-либо кроме сервиса для обновления списка рекламных ссылок),
Или нашли иной способ заблокировать вышеперечисленное, а также возможные неизвестные методы.
Ну да, тогда вопрос зачем включили статистику вполне имеет место быть. Хотя в таком случае вы были бы в полной безопасности: один из предыдущих пунктов защиты полюбому бы отсёк такую статистику.
Ещё пару предложений из моего опыта (напишу тезисно):
Проверять DPI скринов. Все скриншоты должны быть сняты с мониторов одним и тем же DPI.
Подписи к картинкам (alt) — это крайне важная штука для понимания.
Ссылки внутри документации. По умолчанию следует добавить/сгенерировать на каждый заголовок уровней H1-H2.
Термины и определения. Если подобное требуется, либо выносим в отдельный раздел + добавлять ссылку на каждое использование термина. Либо выделите первое/каждое вхождение в статье термина — и пусть по нажатию/наведению появляется всплывающее окно с текстом определения.
Ну и стараемся корректно писать символы: тире, дефис; не забываем про апострофы и кавычки.
NWOcs, посмотрев на исходный код проверок запусков процесса, кажется, может быть ещё один достаточно простой способ обхода: переименовать исполняемый файл блокируемого ПО (так как проверки завязаны на него, а не на заголовки окон ClassName-ы). Например, переименовать Skype.exe в Explorer.exe (проверил: скайпу всё равно как называется его исполняемый файл).
PS. К сожалению, с данным софтом не знаком от слова совсем — потому не могу оперативно проверить сам.
И пара моментов по тексту статьи:
Вообще говоря, реализация метода Guid.NewGuid() зависит от операционной системы:
в Windows Guid создаётся силами native-библиотеки ole32.dll (метод CoCreateGuid) (исходный код .NET 9). На rsdn есть древняя статья, в которой препарировали реализацию CoCreateGuid того времени. И обнаружили там достаточно предсказуемые данные.
в Linux же Guid может создаться как через вызов криптографического генератора случайных чисел, так и обычного (снова исходный код .NET 9).
Вывод 1: считать сгенерированные данным кодом Guid-ы случайными можно только в определённом окружении.
Любая функция хэширования обладает свойством детерминированности. То есть при передаче ей одного и того же значения она будет возвращать один и тот же результат. Посчитайте хоть один раз, хоть миллион любую функцию хэша от Guid.Parse("be6296a3-fc24-4f58-a450-a874a333f8cd") - результат всегда будет одним и тем же.
То есть если взять периодическую последовательность и прохэшировать её блоками фиксированного размера (в вашем случае по 12 байт), в результате вы также получите периодическую последовательность.
Вывод 2: реализованное хэширование не увеличит "случайность" в ваших исходных данных - поэтому его можно вообще удалить из кода.
UPD: увидел комментарий
Для выравнивания длины строки использование хэша идея не самая хорошая, уж проще случайными байтами дозаполнять.
Или сразу генерировать нужное количество байт через упомянутый выше System.Security.Cryptography.RandomNumberGenerator
Спасибо за статью!
Кладу код в копилочку примеров на собеседования, на котором после показа кода первый вопрос к кандидату будет: что бы кандидат предложил переписать для уменьшения времени работы кода.
PS. А вообще выглядит как план: сначала выложить код в виде статьи на хабр, а далее собрать из комментариев идеи по его улучшению и реализовать самые лучшие.
Ой зря вы реальный токен бота оставили и в картинках, и в текстах...
Один из вариантов пути, которым автор мог прийти к текущему коду при изучении EF Core
Загуглить как пользоваться EF Core - вылез бы overview
Увидеть там ТОЧНО ТАКИЕ ЖЕ примеры с using-ом контекста. Использовать их и на их основе писать статью.
А теперь давайте сравним этот код - и код из примера в другом разделе Get started with ASP.NET Core MVC
Случайно заметим, что _context там создаётся не в начале метода - а в конструкторе контроллера.
И тут можно было бы попытаться начать искать информацию в чём разница, может быть вообще стоит один контекст на всё время работы программы сделать? Ищем информацию о времени жизни контекста - находим DbContext Lifetime, Configuration, and Initialization. Перепишем вывод из этой статьи - один контекст на один UnitOfWork...
Вот так, постепенно, и можно собрать информацию на статью - максимально полное описание.
Давайте всё же сделаем скидку на то, что это первая статья.
А я буду держать кулачки за то, чтобы автор продолжил свою работу по изучению интересных ему тем - и с каждым новым разом разборы получались чуть глубже ;)
Приветствую!
В целом пока что не сталкивались. Но как резервное средство всегда есть разметка HTML, которую можно встраивать в markdown-документы.
Кажется, ваше начальство на практике столкнулось с ситуацией "не каждый senior хочет вырасти в лида/менеджера". И вдвойне хорошо, что "щелчок" произошёл до вашего выгорания и/или смены места работы.
При наличии JavaScript - разумеется есть. Поищите: в интернете есть несколько проектов конвертеров md -> html.
Лично мне чисто по описанию понравился https://github.com/showdownjs/showdown. Его можно использовать как в бэкенде (node.js), так и прямо в браузере. Примеры есть в самом репозитории.
Увидев в статье, что автор разбирал камеру на чипе ANYKA AK3918EN080 я аж встрепенулся =)
Дело в том, что у меня самого всё никак руки не доходят разобраться с прошивкой почти что такой же камеры:
чип ANYKA AK3918EN080,
WiFi Realtek RTL8188US,
флеш BH1634 25Q64CS16.
А вот так эта камера выглядит в неразобранном виде:
И это не шутка: коллекционка Mass Effect Andromeda сделана на базе поворотной камеры на чипе ANYKA - просто поворотный механизм заменили на приличной такой мощности двигатели.
API управления простой как три копейки (он по их приложению для Android реверс-инжинирится вообще без проблем). Но вот "влезть" в прошивку чтобы поменять поведение у меня пока руки пока не дошли (да и боюсь немного - дампа исходной прошивки пока нет).
Поэтому расскажите: не пробовали ли вы к текущему моменту собрать модифицированную прошивку? Если пробовали, не поделитесь ли инструкцией?
Или это просто был шаг обучения и продолжать работать именно с подобным устройством вы не будете?
UPDATE. Более подробное изучение темы показало, что venv будет менее удобен при наличии зависимостей от не python библиотек.
Например, использование того же плагина with-pdf требует наличия в системе пакетов pango, для русского языка ttf-ubuntu-font-family, а также некоторых других (полный список есть в статье) - и вот это всё придётся всё равно ставить в основную систему.
А в случае докера это всё-таки можно "спрятать" в образ.
не в тот тред добавил сообщение
Спасибо за вопрос!
Вы абсолютно правы: картинки можно как hfcgjkfufnрасполагать рядом с файлом markdown, так и определять в отдельные папки, прописывая при этом в самом markdown относительные пути.
Я предпочитаю класть картинки в подпапку
./images.Посмотрите пример в нашем репозитории https://gitlab.com/Rostelecom-IT/help-camera-rt/-/tree/master/desktop-app/docs/application_modes:
В файле
index.mdесть, к примеру, ссылка на картинкуshortcut_internet_mode.png, расположенную в подпапке images. И вот как выглядит добавление картинки в самом файле:Поверьте, автор не хотел ничем блеснуть =)
Просто, не являясь практикующим питонистом, я всего лишь воспользовался наиболее подходящим вариантом из предложенного разработчиками material for mkdocs в их документации.
Поэтому благодарю за интересное предложение!
Наверное, можно предложить и разработчикам mkdocs добавить такой вариант прямо на страницу getting started - а не только сослаться на подобный метод в одном из абзацев раздела troubleshooting-а.
Где как на самом деле.
Замечу, что мы — команда разработки десктопных приложений для Windows, поэтому сборка и выкладка docker-образов пока что не про нас (вот ASP.NET Core команда — это другое дело, может скоро и их затащим).
В общем:
А непосредственно доставкой до клиента после выкладки на публичный сервер занимается самописный обновлятор (сделанный примерно во времена .NET 4). Так исторически сложилось + пока функционала более, чем хватает.
Обновлятор при запуске ПО и/или раз в некоторый интервал времени лезет на сервер, смотрит нет ли новой версии и, если есть, скачивает её инсталлер и даёт пользователю выбор: запустить сразу или запустить после закрытия программы (эта же идея, к примеру, в Paint.NET реализована).
К сожалению нет(
И да: там важно переключить окружение в Developer Powershell не только из-за msbuild, но и чтобы другие утилиты Visual Studio стали доступны. Например, signtool для подписи файлов.
И насчёт того, что у Nuke есть интеграция с semver.
Это реализовано через GitVersion. Мы пробовали его внедрить, но столкнулись с рядом неудобств. К сожалению, сейчас я уже помню каких (толи не смогли его подружить с Wix-инсталлером, толи ЭЦП у файлов слетала так как она происходила в нашем процессе раньше, чем срабатывал патч GitVersion).
Поэтому и решили остаться на текущем варианте.
Большое спасибо за отличный вопрос!
Про портянки: здесь сложилось отсутствие в markdown оформления без переноса строк, а также моё желание "схлопнуть" весь код в с подробными комментариями в один файл (для удобства понимания).
Если открыть файл .gitlab-ci.yml в репозитории, можно убедиться, что файл без комментариев о структуре со сборкой, вызовом unit-тестов, git describe а также отправкой результатов в Telegram (упс, спойлер) занимает всего 84 строки.
Согласен, некоторые строки длинные. Тот же SonarQube требует передачи ему семи параметров с длинными мнемоническими именами (например,
/d:sonar.cs.opencover.reportsPaths="$env:OPENCOVER_REPORT_FILE_PATH").Но всё равно код достаточно простой, читаемый. И главное: его можно нарезать кусочками и добавить в любой уже рабочий Gitlab CI без подтягивания лишних зависимостей.
Теперь о Nuke: полностью с вами согласен, это отличная и динамично развивающаяся система с множеством приятных бонусов. И написана она на языке по сути нашей разработки — C#.
Почему мы её не использовали сразу? Дело в том, что для нашего проекта CI/CD создавался по моим шаблонам ещё в 2018 году, а о Nuke и его презентации на dotNext в 2017м, мы, к сожалению, услышали чуть позже.
Почему мы не переписали сборку как только узнали о Nuke? На самом деле мы не увидели явных преимуществ такого переписывания по сравнению с текущей реализацией:
Например, для того, чтобы отправлять сообщения в слак, надо:
Install-Module PSSlackВ Nuke при помощи написания своего Addon-а это также можно сделать. Но это займёт чуточку больше времени.
В этот момент мы можем свалиться в холивар "на чём удобнее писать скрипты — на C# или Powershell", поэтому я не буду продолжать эту тему)
Как говорится: разработчики выбирают инструмент, который реализует максимум требуемых возможностей за минимальное количество телодвижений.
Про ужас с поиском исполняемого файла VS отвечу: так Nuke точно также ищет msbuild если ему это требуется =)
Лично я уже давно смирился с тем, что список посещаемых мною сайтов могут видеть все. Считаю это ещё одной статьёй оплаты за доступ к интернету.
Но если вы:
Или нашли иной способ заблокировать вышеперечисленное, а также возможные неизвестные методы.
Ну да, тогда вопрос зачем включили статистику вполне имеет место быть. Хотя в таком случае вы были бы в полной безопасности: один из предыдущих пунктов защиты полюбому бы отсёк такую статистику.
Ещё пару предложений из моего опыта (напишу тезисно):
Ну и стараемся корректно писать символы: тире, дефис; не забываем про апострофы и кавычки.
Также много интересных фишек можно подсмотреть в руководстве по написанию документации на docs.microsoft.com (https://docs.microsoft.com/ru-ru/contribute/markdown-reference)
NWOcs, посмотрев на исходный код проверок запусков процесса, кажется, может быть ещё один достаточно простой способ обхода: переименовать исполняемый файл блокируемого ПО (так как проверки завязаны на него, а не на заголовки окон ClassName-ы). Например, переименовать Skype.exe в Explorer.exe (проверил: скайпу всё равно как называется его исполняемый файл).
PS. К сожалению, с данным софтом не знаком от слова совсем — потому не могу оперативно проверить сам.