Облачные архитектуры
Прочитал тут очередную техническую книжку... И вам я её не рекомендую.
Это просто обзор облачных технологий на момент издания, то есть на 2021 год. Там буквально написано "Облака это хорошо, микросервисы это хорошо, амазон так делает и вы делайте тоже" плюс "вот что есть в амазоне, гугле и ms azure в плане облаков". Всё.
Ноль практики, какие-то минимальные базовые примеры и рассуждения о том, как же хороши облака.
Кому эта книга может подойти? Возможно, людям не с технической стороны, которые хотят получить некоторую насмотренность на тему того, а что вообще есть в облаках. И то проще будет зайти в популрные облака (Yandex Cloud, Selectel, sber cloud) и посмотреть что там есть.
А ещё есть опечатки в переводе, ну это классика )
Прочитал тут очередную техническую книжку... И вам я её не рекомендую.
Это просто обзор облачных технологий на момент издания, то есть на 2021 год. Там буквально написано "Облака это хорошо, микросервисы это хорошо, амазон так делает и вы делайте тоже" плюс "вот что есть в амазоне, гугле и ms azure в плане облаков". Всё.
Ноль практики, какие-то минимальные базовые примеры и рассуждения о том, как же хороши облака.
Кому эта книга может подойти? Возможно, людям не с технической стороны, которые хотят получить некоторую насмотренность на тему того, а что вообще есть в облаках. И то проще будет зайти в популрные облака (Yandex Cloud, Selectel, sber cloud) и посмотреть что там есть.
А ещё есть опечатки в переводе, ну это классика )
Давно хотел провести эксперимент: написать такое приложение, чтобы и инфраструктурная часть была написана на .NET, и само приложение. И вот, наконец, дошли руки
https://vaiti.io/pishem-prilozhenie-na-c-steke/
https://vaiti.io/pishem-prilozhenie-na-c-steke/
вАЙТИ
Пишем приложение на C#-стеке
DIY-медиа для ИТ-специалистов. Практические истории про решение самых разных задач из ИТ и смежных областей.
6-го октября буду выступать с докладом про опыт наладки процессов в команде! Приходите, кто будет в Вологде!
https://ojti.ru/
А вот немного спойлеров к докладу)
https://ojti.ru/
А вот немного спойлеров к докладу)
Оверинжиниринг на Stack Overflow?
Недавно в рамках своей работы наткнулся на забавную штуку...
Итак, задача: у нас есть подсеть в формате CIDR (ip-адрес/маска) и массив ip-адресов. Нужно выбрать те адреса, которые принадлежат текущей подсети. (Подробнее про IP-адреса можно почитать тут)
Как мы знаем, подсеть - это диапазон ip-адресов, который рассчитывается определённым образом на основе маски, например:
- /24 - 254 хоста
- /25 - 126 хостов
- /26 - 62 хоста
- …
Ну и я конечно же просто пошёл гуглить - кто-то явно уже придумал решение. И ответы на разных источников предлагали написать свой алгоритм с побитовыми операциями и прочими рассчётами принадлежности адреса к подсети. Уверен, это отличный код, надёжный, как швейцарские часы...
ДА ЛАДНО, В ДОТНЕТЕ НЕТ ГОТОВОГО КЛАССА ДЛЯ ТАКИХ ШТУК?
Не верю.
Немного более глубокого исследования, и я обнаружил отличную структуру System.Net.IPNetwork, которая как раз описывает подсеть и содержит прекрасный метод Contains.
Итак, чтобы проверить принадлежность адреса к подсети, нужно всего лишь…
И помните: Cамое лучшее решение - самое простое
Flexible Coding
Недавно в рамках своей работы наткнулся на забавную штуку...
Итак, задача: у нас есть подсеть в формате CIDR (ip-адрес/маска) и массив ip-адресов. Нужно выбрать те адреса, которые принадлежат текущей подсети. (Подробнее про IP-адреса можно почитать тут)
Как мы знаем, подсеть - это диапазон ip-адресов, который рассчитывается определённым образом на основе маски, например:
- /24 - 254 хоста
- /25 - 126 хостов
- /26 - 62 хоста
- …
Ну и я конечно же просто пошёл гуглить - кто-то явно уже придумал решение. И ответы на разных источников предлагали написать свой алгоритм с побитовыми операциями и прочими рассчётами принадлежности адреса к подсети. Уверен, это отличный код, надёжный, как швейцарские часы...
ДА ЛАДНО, В ДОТНЕТЕ НЕТ ГОТОВОГО КЛАССА ДЛЯ ТАКИХ ШТУК?
Не верю.
Немного более глубокого исследования, и я обнаружил отличную структуру System.Net.IPNetwork, которая как раз описывает подсеть и содержит прекрасный метод Contains.
Итак, чтобы проверить принадлежность адреса к подсети, нужно всего лишь…
var network = IPNetwork.Parse("10.10.10.0/24");
network.Contains(IPAddress.Parse("10.10.10.2")); // TrueИ помните: Cамое лучшее решение - самое простое
Flexible Coding
Доклад о процессах на IT-форум.pptx
3.9 MB
Как и обещал, презентация с доклада
Спасибо всем кто пришёл, кто задавал вопросы, и отдельное спасибо Skillaz за то, что организовали и позвали! Было круто!
Спасибо всем кто пришёл, кто задавал вопросы, и отдельное спасибо Skillaz за то, что организовали и позвали! Было круто!
10-11 октября проходил Positive Security Day, где я был стендистом. Это новый для меня опыт - я почувствовал себя настоящим сейлом.
В задачи стендиста входило рассказывать заинтересованным людям (потенциальным заказчикам) про продукт - желательно так чтобы:
1. Люди поняли, что это и зачем
2. Люди захотели это купить
И сначала я был просто в ступоре... у нас не было заготовленных речей, надо было вывозить на импровизации. Но к счастью мои коллеги это дело подхватили и у них всё получилось! Тогда я послушал ребят, дообучил свою нейронку в голове, набрался смелости и присоединился к общению с людьми, которые интересовались продуктом. Было прикольно! Реально новый опыт, интересные вопросы, интересные люди из интересных компаний - всё это драйвило меня, и с каждым новым человеком я общался всё увереннее и увереннее.
Конечно же были и сложности, но по более сложным вопросам всегда можно попросить помощи у коллег - поэтому всё прошло хорошо.
А что такое мы разработали???
А это настоящий автопентестер! Я пришёл в команду чуть больше месяца назад и принял участие в разработке "мозгов" программы - непосредственной реализации техник и тактик, которые используют хакеры в рамках своих атак. За этот месяц я очень сильно погрузился в продукт, в ИБ и пентест - ведь чтобы его автоматизировать, надо понимать как это всё делается вручную. Супер интересная область, супер сложная задача эмулировать действия хакера - фактически нелинейное мышление человека перекладывать в программный код.
Но к счастью, у нас драйвовая команда, готовая принять этот вызов!
Кстати, запись мероприятия доступна тут (Зал Молекула, есть таймкоды, PT Dephaze на 05:23:00): https://psd.ptsecurity.com/#live
Flexible Coding
В задачи стендиста входило рассказывать заинтересованным людям (потенциальным заказчикам) про продукт - желательно так чтобы:
1. Люди поняли, что это и зачем
2. Люди захотели это купить
И сначала я был просто в ступоре... у нас не было заготовленных речей, надо было вывозить на импровизации. Но к счастью мои коллеги это дело подхватили и у них всё получилось! Тогда я послушал ребят, дообучил свою нейронку в голове, набрался смелости и присоединился к общению с людьми, которые интересовались продуктом. Было прикольно! Реально новый опыт, интересные вопросы, интересные люди из интересных компаний - всё это драйвило меня, и с каждым новым человеком я общался всё увереннее и увереннее.
Конечно же были и сложности, но по более сложным вопросам всегда можно попросить помощи у коллег - поэтому всё прошло хорошо.
А что такое мы разработали???
А это настоящий автопентестер! Я пришёл в команду чуть больше месяца назад и принял участие в разработке "мозгов" программы - непосредственной реализации техник и тактик, которые используют хакеры в рамках своих атак. За этот месяц я очень сильно погрузился в продукт, в ИБ и пентест - ведь чтобы его автоматизировать, надо понимать как это всё делается вручную. Супер интересная область, супер сложная задача эмулировать действия хакера - фактически нелинейное мышление человека перекладывать в программный код.
Но к счастью, у нас драйвовая команда, готовая принять этот вызов!
Кстати, запись мероприятия доступна тут (Зал Молекула, есть таймкоды, PT Dephaze на 05:23:00): https://psd.ptsecurity.com/#live
Flexible Coding
Итак, коллеги, важный опрос - я в смятении.
Чем отличается Acceptance Test Driven Development от Behaviour Driven Development c точки зрения технической реализации (написания тестов на основе бизнес-требований)?
Судя по тому, что читал в интернете - на практике это буквально одно и то же под разными названиями. Конечно есть уверждения, что одно это процесс взаимодействия с заказчиком, а другое это написание тестов... А с технической точки зрения это те же тесты на Gherkin Language... или нет?
Короче, го в комменты!
Чем отличается Acceptance Test Driven Development от Behaviour Driven Development c точки зрения технической реализации (написания тестов на основе бизнес-требований)?
Судя по тому, что читал в интернете - на практике это буквально одно и то же под разными названиями. Конечно есть уверждения, что одно это процесс взаимодействия с заказчиком, а другое это написание тестов... А с технической точки зрения это те же тесты на Gherkin Language... или нет?
Короче, го в комменты!
Akka .NET
По производственной необходимости я сейчас изучаю фреймворк Akka. Это реализация акторной модели - архитектура приложения строится на некоторых единицах исполнения заданий, которые общаются друг с другом посредством сообщений. Реактивная модель, получается (кстати, можете почитать про неё в Reactive Manifesto).
Сами акторы появились в Erlang и часто используются в телекоммуникационной индустрии. И так получилось, что они отлично ложатся на задачи в рамках моей текущей предметной области.
Как изучать?
По материалам именно по дотнету - всё плохо, поэтому тут я советую почитать оригинальные доки с примерами на Scala и Java.
(Но если что - вот документация и по Akka.NET)
Послушать можно доклады от автора порта акки на .NET - https://www.youtube.com/watch?v=MY1iPY78_fs. Ну или поискать другие.
Но самое главное
Я наткнулся на отличный курс от Petabridge - Akka Bootcamp. Он доступен на гитхабе - https://github.com/petabridge/akka-bootcamp. Тут гораздо более понятные и реальные примеры использования акторной модели - и есть практика, которую можно выполнять, а затем сравнивать свой результат с эталоном. Русификации нет, но я всё равно рекомендую изучать акку именно по этому курсу.
Flexible Coding
По производственной необходимости я сейчас изучаю фреймворк Akka. Это реализация акторной модели - архитектура приложения строится на некоторых единицах исполнения заданий, которые общаются друг с другом посредством сообщений. Реактивная модель, получается (кстати, можете почитать про неё в Reactive Manifesto).
Сами акторы появились в Erlang и часто используются в телекоммуникационной индустрии. И так получилось, что они отлично ложатся на задачи в рамках моей текущей предметной области.
Как изучать?
По материалам именно по дотнету - всё плохо, поэтому тут я советую почитать оригинальные доки с примерами на Scala и Java.
(Но если что - вот документация и по Akka.NET)
Послушать можно доклады от автора порта акки на .NET - https://www.youtube.com/watch?v=MY1iPY78_fs. Ну или поискать другие.
Но самое главное
Я наткнулся на отличный курс от Petabridge - Akka Bootcamp. Он доступен на гитхабе - https://github.com/petabridge/akka-bootcamp. Тут гораздо более понятные и реальные примеры использования акторной модели - и есть практика, которую можно выполнять, а затем сравнивать свой результат с эталоном. Русификации нет, но я всё равно рекомендую изучать акку именно по этому курсу.
Flexible Coding
Ради эксперимента поставил заметочник affine.pro. Однако у него довольно плохая мобильная версия, поэтому для быстрых записей я захотел написать телеграм-бота. А уже об этом - моя новая статья :)
вАЙТИ
Автоматизируем сервис без API
DIY-медиа для ИТ-специалистов. Практические истории про решение самых разных задач из ИТ и смежных областей.
Behaviour Driven Development && Dotnet
Так получилось, что в рамках своего опыта работы я не встречал проектов с хорошими юнит-тестами и большим покрытием ими проектов.
Зато на всех проектах использовался подход Behaviour Driven Development, в рамках которого писались интеграционные тесты.
Behaviour Driven Development - это подход к разработке, при котором вы пишете интеграционные тесты на основе User Story, используя язык Gherkin как со стороны бизнеса, так и со стороны разработки. Чем-то похоже на ATDD
Каждый тест состоит из трех этапов:
- Given (дано) - подготовка окружения (может быть несколько)
- When (когда) - выполнение действия, которое как-то это окружение меняет (желательно, чтобы этот шаг был только один)
- Then (тогда) - проверка того, что окружение изменилось так как надо (тоже может быть несколько)
Например
- Дано: созданный аккаунт пользователя с ролью администратор
- Когда пользователь авторизуется в системе
- Тогда пользователь видит страницу администратора
Такие тесты более сложны в сопровождении, дольше пишутся и дольше прогоняются, однако имеют очень важное преимущество - они не просто тестируют изолированный кусок логики, как юнит-тесты, а фактически подтверждают выполнение бизнес-требований.
В дотнете есть много популярных фреймворков для написания таких тестов - LightBDD, SpecFlow, MSpec. Однако наиболее популярны первые два - о них и поговорим в следующих постах
Flexible Coding
Так получилось, что в рамках своего опыта работы я не встречал проектов с хорошими юнит-тестами и большим покрытием ими проектов.
Зато на всех проектах использовался подход Behaviour Driven Development, в рамках которого писались интеграционные тесты.
Behaviour Driven Development - это подход к разработке, при котором вы пишете интеграционные тесты на основе User Story, используя язык Gherkin как со стороны бизнеса, так и со стороны разработки. Чем-то похоже на ATDD
Каждый тест состоит из трех этапов:
- Given (дано) - подготовка окружения (может быть несколько)
- When (когда) - выполнение действия, которое как-то это окружение меняет (желательно, чтобы этот шаг был только один)
- Then (тогда) - проверка того, что окружение изменилось так как надо (тоже может быть несколько)
Например
- Дано: созданный аккаунт пользователя с ролью администратор
- Когда пользователь авторизуется в системе
- Тогда пользователь видит страницу администратора
Такие тесты более сложны в сопровождении, дольше пишутся и дольше прогоняются, однако имеют очень важное преимущество - они не просто тестируют изолированный кусок логики, как юнит-тесты, а фактически подтверждают выполнение бизнес-требований.
В дотнете есть много популярных фреймворков для написания таких тестов - LightBDD, SpecFlow, MSpec. Однако наиболее популярны первые два - о них и поговорим в следующих постах
Flexible Coding
SLNX-формат или как Microsoft меня расстроили
Всем привет! Сегодня поговорим про "решения" проектов на .NET.
Как мы знаем, приложение на дотнете - это некоторое решение (Solution) с набором проектов. В одном из проектов может быть слой бизнес-логики, в другом - инфраструктурный, ну и так далее. Всё это может быть и в одном проекте, но это редкость.
Так вот, проекты объединяются в решение через sln-файлы - файлы решений. Внутри этого файла находится страшный сплошной текст с информацией о проектах, их расположением в Solution Folders и прочими метаданными. И его довольно трудно читать - там довольно странные GUID-ы, куча каких-то маппингов, повторов...
А проблемы начинаются, когда разработчики параллельно в разных ветках добавляют много проектов, а потом надо решать merge-конфликты. И после очередного разбора конфликтов на работе, итогом которого стала отвязка части проектов и ручная их перепривязка к решению, стало понятно, что так дальше продолжаться не может.
В .NET8 был представлен новый формат файлов решений - slnx. Данные в нём уже структурированы и довольно удобно читаются - xml-формат, там нет GUID-ов и прочего мусора, который мешает пониманию содержимого файла - то, что надо!
И вот мы уже перешли на новый формат решений, счастливы - конфликты в этом файле решаются просто, коллизий нет... и тут выясняется, что dotnet cli этот формат полностью не поддерживает. То есть dotnet restore, dotnet build в нашем dockerfile тупо не отрабатывает и мы не можем задеплоиться!
Собственно, благодаря тому, что xml удобно парсить, не составило труда написать скрипт, который парсит список проектов в решении и выполняет dotnet restore для них по отдельности, но это не так удобно. Вместо
> Да, я написал F#-скрипт для парсинга slnx-файла
А ещё забавно, что даже последняя версия Visual Studio 2022 отказалась открывать этот файл :)
Какой же статус работы по slnx?
- Для dotnet cli - выйдет в .net9.0.2
- Для vs code - есть открытый issue
- Для Visual Studio - да вроде уже работает, но у меня не работает :(
- И только JetBrains Rider стабильно открывает и понимает новый формат солюшнов
Морали не будет, просто будьте внимательнее при переходе на что-то новое и крутое :)
Flexible Coding
Всем привет! Сегодня поговорим про "решения" проектов на .NET.
Как мы знаем, приложение на дотнете - это некоторое решение (Solution) с набором проектов. В одном из проектов может быть слой бизнес-логики, в другом - инфраструктурный, ну и так далее. Всё это может быть и в одном проекте, но это редкость.
Так вот, проекты объединяются в решение через sln-файлы - файлы решений. Внутри этого файла находится страшный сплошной текст с информацией о проектах, их расположением в Solution Folders и прочими метаданными. И его довольно трудно читать - там довольно странные GUID-ы, куча каких-то маппингов, повторов...
А проблемы начинаются, когда разработчики параллельно в разных ветках добавляют много проектов, а потом надо решать merge-конфликты. И после очередного разбора конфликтов на работе, итогом которого стала отвязка части проектов и ручная их перепривязка к решению, стало понятно, что так дальше продолжаться не может.
В .NET8 был представлен новый формат файлов решений - slnx. Данные в нём уже структурированы и довольно удобно читаются - xml-формат, там нет GUID-ов и прочего мусора, который мешает пониманию содержимого файла - то, что надо!
И вот мы уже перешли на новый формат решений, счастливы - конфликты в этом файле решаются просто, коллизий нет... и тут выясняется, что dotnet cli этот формат полностью не поддерживает. То есть dotnet restore, dotnet build в нашем dockerfile тупо не отрабатывает и мы не можем задеплоиться!
Собственно, благодаря тому, что xml удобно парсить, не составило труда написать скрипт, который парсит список проектов в решении и выполняет dotnet restore для них по отдельности, но это не так удобно. Вместо
dotnet restore мы выполнеяем команду
dotnet fsi list-projects.fsx | sed 's|\\|/|g' | xargs -I {} sh -c 'if [ -f "{}" ]; then dotnet restore "{}"; fi'
> Да, я написал F#-скрипт для парсинга slnx-файла
А ещё забавно, что даже последняя версия Visual Studio 2022 отказалась открывать этот файл :)
Какой же статус работы по slnx?
- Для dotnet cli - выйдет в .net9.0.2
- Для vs code - есть открытый issue
- Для Visual Studio - да вроде уже работает, но у меня не работает :(
- И только JetBrains Rider стабильно открывает и понимает новый формат солюшнов
Морали не будет, просто будьте внимательнее при переходе на что-то новое и крутое :)
Flexible Coding
Итак, 2025 год (с наступившим!), автор вышел из цепочки событий разной степени безумия и готов с вами познакомиться!
Меня зовут Дмитрий Бахтенков, уже несколько лет я занимаюсь коммерческой разработкой на .NET, а также увлекаюсь различными аспектами саморазвития - очень много времени уделяю тому, как быть продуктивным, организованным, эффективным и т.д.
Этот канал я создал, чтобы делиться с вами своими мыслями, идеями и личным опытом, непосредственно связанным с программированием и IT в целом.
Что здесь есть?
- Статьи. Последнее время я публикую их на портале вАЙТИ
- Обзоры книг. Я много читаю, в том числе техническую литературу. Об интересных книгах я пишу отзывы, и думаю о том, чтобы делать более развёрнутые конспекты
- Интересные технические кейсы. Что-то непонятное, занятное и странное
- Обучающие посты
- Личный опыт, публичные выступления, советы по организации и многое другое
А ещё я завёл бусти. Он пока пустой, но в ближайшее время я буду его наполнять по чуть чуть. Подписывайтесь, если хотите меня поддержать, я буду рад!
Меня зовут Дмитрий Бахтенков, уже несколько лет я занимаюсь коммерческой разработкой на .NET, а также увлекаюсь различными аспектами саморазвития - очень много времени уделяю тому, как быть продуктивным, организованным, эффективным и т.д.
Этот канал я создал, чтобы делиться с вами своими мыслями, идеями и личным опытом, непосредственно связанным с программированием и IT в целом.
Что здесь есть?
- Статьи. Последнее время я публикую их на портале вАЙТИ
- Обзоры книг. Я много читаю, в том числе техническую литературу. Об интересных книгах я пишу отзывы, и думаю о том, чтобы делать более развёрнутые конспекты
- Интересные технические кейсы. Что-то непонятное, занятное и странное
- Обучающие посты
- Личный опыт, публичные выступления, советы по организации и многое другое
А ещё я завёл бусти. Он пока пустой, но в ближайшее время я буду его наполнять по чуть чуть. Подписывайтесь, если хотите меня поддержать, я буду рад!
Всем привет!
Начал писать цикл статей про многопоточность на разных уровнях абстракции. И представляю вам первую статью из этой серии - про процессор!
Начал писать цикл статей про многопоточность на разных уровнях абстракции. И представляю вам первую статью из этой серии - про процессор!
вАЙТИ
Многопоточность. Снизу вверх. Процессор
DIY-медиа для ИТ-специалистов. Практические истории про решение самых разных задач из ИТ и смежных областей.