Кстати, столкнулся с неожиданной проблемой, 🙈 на собеседовании в жёлтый банк и голубой маркетплейс: зазубривание ответов на вопросы. При чём ты можешь быть супер крутым специалистом 👩🎓 с большим опытом, но тебя завалят просто потому, что ты работал в финтехе на dotnet 3.1 и совершенно не встречал в работе кейсы, когда нужно было бы проектировать модуль с использованием рекордов и структур, для миллиона запросов в секунду 🤯 . И дядя собеседующий, которому до лампочки 🧐 пройдешь ты собес или нет — просто поставит галочку ☑️ в свой табличке и перейдет "к следующему вопросу", чтобы успеть за день прособесить побольше и получить зарплатную стимуляцию 🪙 .
Очень актуально попался следующий пост где мужика с 25-летним опытом👨💻 бомбит на ту же тему:
https://habr.com/ru/articles/841224/
Очень актуально попался следующий пост где мужика с 25-летним опытом
https://habr.com/ru/articles/841224/
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Удавка на собесе
Хабр-хабр, дорогие друзья. Сегодня поговорим про ИТ собесы, от которых меня в последнее время тошнит. Я занимаюсь коммерческой разработкой с 2000-х, поменял более 10 ИТ-компаний и прошел достаточно...
This media is not supported in your browser
VIEW IN TELEGRAM
Нашел Regex hack для навигации через Powershell/Windows terminal.
Пишешь звездочку ( * ) везде, где лень писать полный путь, и нажимаешь Tab, чтобы тебе автокомплитнули всё. С подпапками так-же работает.
Например:
🔵 Перейти в папку, которая оканчивается на Dir5:
🔵 Перейти в папку, которая начинается на project и в серидине есть dir
🔵 Перейти в подпапку, которая начинается на module
Пишешь звездочку ( * ) везде, где лень писать полный путь, и нажимаешь Tab, чтобы тебе автокомплитнули всё. С подпапками так-же работает.
Например:
$ cd *dir5
// Tab
$ cd ./Company2.D̲i̲r̲5
$ cd project*dir*
// Tab
$ cd ./P̲r̲o̲j̲e̲c̲t̲2.D̲i̲r̲1.Module2.Dir3
// Tab
$ cd ./P̲r̲o̲j̲e̲c̲t̲4.D̲i̲r̲1.Module5
$ cd */module*
// Tab
$ cd ./Company3.Module3/M̲o̲d̲u̲l̲e̲3
// Tab
$ cd ./Project2.Dir1.Module2.Dir3/M̲o̲d̲u̲l̲e̲2.Dir1.Dir3
Please open Telegram to view this post
VIEW IN TELEGRAM
С тех пор, когда я в последний раз интересовался синхронизацией многопоточности, примерно 5 лет назад, прочел Metanit, на котором были локи, мьютекс и семафор[слим].
И на собесах и в работе всегда этого хватало.
И либо dotnet так сильно разросся, начиная с 3.1, либо это уже продвинутая магия.
Или возможно это прерогатива хайлоада, где доп запрос в брокер слишком долго и дорого.
Да, лишние 15мс, когда у тебя требование на 10к запросов в секунду с максимальным временем отклика 200мс — суперважно, учитывая что этих запросов может быть около 10, а это уже +150мс, не считая даже запросы в БД.
Небольшой списочек того, что нашел:
🔴 Блокирующие
🔵 Mutex
🔵 Semaphore
🔵 SemaphoreSlim
🔵 EventWaitHandle
🔵 AutoResetEvent
🔵 ManualResetEvent
🔴 Синхронизаторы
🔵 Monitor
🔵 SpinLock
🔵 ReaderWriterLockSlim
🔴 Общение между потоками
🔵 Barrier
🔵 Interlocked
🔵 SpinWait
⭐️ Бонус:
🌟 System.MarshalByRefObject
🌟 WaitHandle
🌟 Thread.Join
🌟 EventWaitHandle
🌟 CountdownEvent
И на собесах и в работе всегда этого хватало.
И либо dotnet так сильно разросся, начиная с 3.1, либо это уже продвинутая магия.
Или возможно это прерогатива хайлоада, где доп запрос в брокер слишком долго и дорого.
Да, лишние 15мс, когда у тебя требование на 10к запросов в секунду с максимальным временем отклика 200мс — суперважно, учитывая что этих запросов может быть около 10, а это уже +150мс, не считая даже запросы в БД.
Небольшой списочек того, что нашел:
Please open Telegram to view this post
VIEW IN TELEGRAM
Docs
Mutex Класс (System.Threading)
Примитив синхронизации, который также может использоваться в межпроцессной синхронизации.
Интересный опыт разницы разработки с тестами и без.
🔵 Скрин №1: до имплементации интеграционных тестов. Среднее число измененных строк в день ~500.
🔵 Скрин №2: после имплементации интеграционных тестов. Среднее число измененных строк в день ~3 000.
Субъективный вывод, также основанный на опыте: тесты хоть и забирают на себя часть времени, но позволяют гораздо быстрее менять код, так как снимают нагрузку на оперативку разработчика — сильно реже перепроверяешь и сильно меньше беспокоишься, об остальных участках кода и структуре проекта в целом, когда спину прикрывают тесты.
Субъективный вывод, также основанный на опыте: тесты хоть и забирают на себя часть времени, но позволяют гораздо быстрее менять код, так как снимают нагрузку на оперативку разработчика — сильно реже перепроверяешь и сильно меньше беспокоишься, об остальных участках кода и структуре проекта в целом, когда спину прикрывают тесты.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Он следит. Если не 🟢 озеленить тесты, то он достанет свой серебряный меч против скуфов нечисти. Мотивация.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤩1
Неправда! Это чтобы народу хуже сделать! Чтобы все на рутуб переходили, и пропаганду смотрели! Чтобы чебурнет свой сделать! Чтобы за народом следить!
🌟 Выгодоприобретатели блокировки Youtube / Habr
🌟 Выгодоприобретатели блокировки Youtube / Habr
Хабр
Выгодоприобретатели блокировки Youtube
Недавно возникшая тема с блокировкой (замедлением) Youtube коснулась практически каждого жителя РФ. При этом до сих пор нет ни одного прямого официального заявления о причастности к этой блокировке....
👍1😁1
Короче, есть такая штука — BFG. Это типа как git-filter-branch, только круче. С ней можно легко и быстро удалить ненужные данные из истории репозитория.
Как это работает:
- Клонируешь репозиторий с флагом --mirror, чтобы сделать копию.
- Запускаешь BFG, чтобы обновить коммиты и ветки.
- Удаляешь ненужные данные с помощью git gc.
- Снова запускаешь BFG, чтобы обновить ссылки на git сервере.
BFG может удалять файлы с именами id_rsa или id_dsa, большие двоичные файлы больше 50 мегабайт, пароли, папки или файлы с именем .git.
BFG работает в 10–720 раз быстрее, чем git-filter-branch и не трогает последний коммит.
https://rtyley.github.io/bfg-repo-cleaner/
Как это работает:
- Клонируешь репозиторий с флагом --mirror, чтобы сделать копию.
- Запускаешь BFG, чтобы обновить коммиты и ветки.
- Удаляешь ненужные данные с помощью git gc.
- Снова запускаешь BFG, чтобы обновить ссылки на git сервере.
BFG может удалять файлы с именами id_rsa или id_dsa, большие двоичные файлы больше 50 мегабайт, пароли, папки или файлы с именем .git.
BFG работает в 10–720 раз быстрее, чем git-filter-branch и не трогает последний коммит.
https://rtyley.github.io/bfg-repo-cleaner/
rtyley.github.io
BFG Repo-Cleaner by rtyley
A simpler, faster alternative to git-filter-branch for deleting big files and removing passwords from Git history.
NET_Microservices_Architecture_for_Containerized_NET_Applications.pdf
11.7 MB
А, ну и небольшая книжка (всего 350 стр.) от майков, про архитектуру микросервисов.
Сразу в PDF да.
Сразу в PDF да.
👍2
Один из способов отличить дипфейк видео от реального:
Стандарт аутентификации C2PA.
C2PA — это организация, которая придумала стандарт Content Credentials.
С его помощью издатели, создатели и потребители могут отслеживать путь разных медиа от производства до потребления. Например, можно узнать, какая камера сделала фото, изменяли его или нет и когда.
C2PA использует шифрование, чтобы зашифровать информацию о происхождении контента. Это значит, что можно узнать, кто, как и когда создал контент.
Было бы классно, если бы не проблемы по оптимизации соцсетей. Практически любой медиаконтент, который мы заливаем на платформы — подвергается изменению. Компрессия, для оптимизации хранения, изменение размера и качества, для выбора качества показываемого медиа, создание дополнительных файлов для превью и прочее.
Во всем этом конвеере, метаданные исходного файла спокойно могут потеряться, а для внедрения полноценной системы проброса метаданных внутри платформы — нужно очень много финансовых затрат. Это не отдельный функционал, а модификация всей вертикали обработки медиа.
Стандарт аутентификации C2PA.
C2PA — это организация, которая придумала стандарт Content Credentials.
С его помощью издатели, создатели и потребители могут отслеживать путь разных медиа от производства до потребления. Например, можно узнать, какая камера сделала фото, изменяли его или нет и когда.
C2PA использует шифрование, чтобы зашифровать информацию о происхождении контента. Это значит, что можно узнать, кто, как и когда создал контент.
Было бы классно, если бы не проблемы по оптимизации соцсетей. Практически любой медиаконтент, который мы заливаем на платформы — подвергается изменению. Компрессия, для оптимизации хранения, изменение размера и качества, для выбора качества показываемого медиа, создание дополнительных файлов для превью и прочее.
Во всем этом конвеере, метаданные исходного файла спокойно могут потеряться, а для внедрения полноценной системы проброса метаданных внутри платформы — нужно очень много финансовых затрат. Это не отдельный функционал, а модификация всей вертикали обработки медиа.
Forwarded from Стой под стрелой (Nikita Prokopov)
Раздражает, как в айтишечке используют слово «требования» (requirements). Типа, звучит как «кровь из носу надо», «без этого не заработает/не полетит» и вообще несдвигаемая какая-то стена и что-то осмысленное и глубоко проанализированное.
А на деле это обычно с потолка взятая цифра, которую за три секунды кто-то придумал. Типа, «нам надо обрабатывать 5000 запросов/секунду». Почему именно 5000? А если 10000 обработаем? А если 1000? Не то чтобы решения будут сильно разными, и не то чтобы кто-то специально будет программу замедлять. Команда напишет код to the best of its abilities, купят сервачок какой-нибудь, а там херакс — и 100,000 вместо 5000 получится. И чего? Обратно отдавать куда-то?
В обратную сторону тоже верно. Написали, получилось тысяча — что теперь, не запускаться? Запустятся все равно, один фиг столько пользователей на старте не будет. А потом посмотрят, сколько придет.
То же самое с reliability, и с дедлайнами, с временем отклика. Все будут стараться, но получится как получится, и запуск будет все равно.
А еще иногда кто-нибудь выходит и говорит гордо: we’ve met our requirements. Типа, выполнили требования. А ты смотришь и видишь — фигню какую-то сделали. Типа, сайт три секунды открывается. А он такой — так у нас и были требования чтобы три секунды.
Ну и нафига тогда требования?
А на деле это обычно с потолка взятая цифра, которую за три секунды кто-то придумал. Типа, «нам надо обрабатывать 5000 запросов/секунду». Почему именно 5000? А если 10000 обработаем? А если 1000? Не то чтобы решения будут сильно разными, и не то чтобы кто-то специально будет программу замедлять. Команда напишет код to the best of its abilities, купят сервачок какой-нибудь, а там херакс — и 100,000 вместо 5000 получится. И чего? Обратно отдавать куда-то?
В обратную сторону тоже верно. Написали, получилось тысяча — что теперь, не запускаться? Запустятся все равно, один фиг столько пользователей на старте не будет. А потом посмотрят, сколько придет.
То же самое с reliability, и с дедлайнами, с временем отклика. Все будут стараться, но получится как получится, и запуск будет все равно.
А еще иногда кто-нибудь выходит и говорит гордо: we’ve met our requirements. Типа, выполнили требования. А ты смотришь и видишь — фигню какую-то сделали. Типа, сайт три секунды открывается. А он такой — так у нас и были требования чтобы три секунды.
Ну и нафига тогда требования?
Testcontainers для .NET — одно из давно искомых, но почему-то ускользавших от меня решений, по созданию окружения при прогоне тестов. Помогает создавать и запускать контейнеры Docker.
С ним можно запускать контейнеры прямо из кода, например, в слое test prepare, в
Оно работает с .NET Docker remote API. Контейнеры очень гибко конфигурируются, можно использовать любые докер образы, настраивать порты и healthcheck'и прямо как в docker compose. Так-же можно использовать свои контейнеры, собранные из Dockerfiles.
Например запуск экземпляра PostgeSQL, с ожиданием полного запуска:
Official page: https://dotnet.testcontainers.org/
Nuget: https://www.nuget.org/packages/DotNet.Testcontainers
С ним можно запускать контейнеры прямо из кода, например, в слое test prepare, в
[OneTimeSetup] (NUnit).Оно работает с .NET Docker remote API. Контейнеры очень гибко конфигурируются, можно использовать любые докер образы, настраивать порты и healthcheck'и прямо как в docker compose. Так-же можно использовать свои контейнеры, собранные из Dockerfiles.
Например запуск экземпляра PostgeSQL, с ожиданием полного запуска:
new ContainerBuilder()
.WithName(containerName)
.WithImage("postgres:17")
.WithHostname(containerHostName)
.WithExposedPort(5432)
.WithPortBinding(5432, true)
.WithEnvironment("POSTGRES_PASSWORD", postgresPassword)
.WithEnvironment("PGDATA", "/pgdata")
.WithTmpfsMount("/pgdata")
.WithWaitStrategy(Wait.ForUnixContainer().UntilCommandIsCompleted("psql -U postgres -c \"select 1\""))
.Build();
Official page: https://dotnet.testcontainers.org/
Nuget: https://www.nuget.org/packages/DotNet.Testcontainers
www.nuget.org
DotNet.Testcontainers 1.6.0
A lightweight library to run tests with throwaway instances of Docker containers.
🔥1
STOMP - это простой протокол взаимодействия, предназначенный для асинхронной передачи сообщений между клиентами через серверы-посредники. Он определяет текстовый формат сообщений, передаваемых между этими клиентами и серверами.
STOMP активно используется в течение нескольких лет и поддерживается многими брокерами сообщений и клиентскими библиотеками. Эта спецификация определяет протокол STOMP 1.2 и является обновлением STOMP 1.1.
https://stomp.github.io/stomp-specification-1.2.html#Overview
STOMP активно используется в течение нескольких лет и поддерживается многими брокерами сообщений и клиентскими библиотеками. Эта спецификация определяет протокол STOMP 1.2 и является обновлением STOMP 1.1.
https://stomp.github.io/stomp-specification-1.2.html#Overview
stomp.github.io
The Simple Text Oriented Messaging Protocol
MQTT - это протокол обмена сообщениями, разработанный OASIS (Организация по продвижению стандартов структурированной информации ), который служит стандартом для связи в Интернете вещей (IoT). Этот протокол разработан как чрезвычайно легкий и эффективный транспортный механизм публикации/подписки, что делает его идеальным для подключения удаленных устройств с минимальной сложностью кода и требованиями к пропускной способности сети.
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf
🔥1
.SLNX
Новый формат файла решения (солюшена) .Net. Пока что не входит в шаблон по умолчанию RTM (но уже по умолчанию с версии Visual Studio 2022 v17.12-preview).
Если коротко, то просто все устали читать километры GUID'ов в стандартном .sln файле (скрин №1), и майки перешли в формат XML (скрин №2). В целом стало сильно лучше читаться, и меньше проблем в параллельной разработке, при решении конфликтов (да-да, кто не резолвил это практически наугад, того не существует. скрин №3).
PS. В Rider уже завезли поддержку, с версии v2024.2 (кроме того, что он стал бесплатный⭐️ )
Новый формат файла решения (солюшена) .Net. Пока что не входит в шаблон по умолчанию RTM (но уже по умолчанию с версии Visual Studio 2022 v17.12-preview).
Если коротко, то просто все устали читать километры GUID'ов в стандартном .sln файле (скрин №1), и майки перешли в формат XML (скрин №2). В целом стало сильно лучше читаться, и меньше проблем в параллельной разработке, при решении конфликтов (да-да, кто не резолвил это практически наугад, того не существует. скрин №3).
PS. В Rider уже завезли поддержку, с версии v2024.2 (кроме того, что он стал бесплатный
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
JSON — BSON
JSON (JavaScript Object Notation) — текстовый формат для хранения и передачи структурированных данных, в формате ключ-значение. Поддерживает
BSON (Binary JSON) — бинарный формат для хранения данных (используется в MongoDB), поддерживающий все типы JSON, плюс дополнительные типы. Например
JSON — для передачи данных, BSON — для хранения данных.
Использование BSON в ASP.NET Core:
Для десериализации данных в ASP.NET Core нужно добавить
JSON (JavaScript Object Notation) — текстовый формат для хранения и передачи структурированных данных, в формате ключ-значение. Поддерживает
string, bool, int, float, object, [ ].BSON (Binary JSON) — бинарный формат для хранения данных (используется в MongoDB), поддерживающий все типы JSON, плюс дополнительные типы. Например
date (без пояса), byte[ ], regex, string(len)JSON — для передачи данных, BSON — для хранения данных.
Использование BSON в ASP.NET Core:
Для десериализации данных в ASP.NET Core нужно добавить
BsonMediaTypeFormatter в коллекцию formatters и он будет включаться для обработки запроса «application/bson».