Відео

просто витрачений час, нічого нового і цікавого все абстрактно , нової інформації 0, все сказане знають навіть люди не зв`язані із fpv

Півтори години води

Чтобы не ставить приватный анализатор, к параметрам primary constructor можно добавить ключевое слово `in`, тогда их разрешено будет использовать только при инициализации класса.

Бесполезно

По поводу уникальности. Если мы не можем отличить в таблице два ресторана в спб шаверма и шаверма, то какой смысл в этом? Ну допустим их можно будет добавить с гуидами, но пользователь то не будет знать, что это за шаверма. С фио тоже самое. Натуральная уникальность необходима для таких вещей.

Дочерним спаном может не хотеться делать, если там огромное количество операций. Потом просто трейс будет невозможно, ни смотреть, ни изучать

В файле проекта сделают "use primary constructor parameters as readonly" тру фэлс и не будет брэйка)) keylookup дополнительно получаешь будучи джуном. Т.к. праймери ключ, чаще всего и кластерный индекс...) А не помню, обсуждалось про ЕФ8, что они вместо In начали OpenJson делать?

Вот, кстати, мне непонятна эта политика релизиов. Если команда EF Core рождает фичу, которая стабильна и не имеет ломающих совместимость изменений, то почему бы не выпускать её как апдейт минорной версии? Но они почему-то предпочитают ждать год и выкатывать одним большим пакетом.

Flight Per View - fpv (Если коптеры)

Спасибо ребят

Хех, как только я увидел primary constructors - сразу запретил их в проекте через рослин аналайзер. Кому интересно, гитхаб - magicxor/MagicxorAnalyzer.CSharp

очень круто, спасибо!

Спасибо за очередные новости!

Эмм... 38:09 Предлагается сделать Dictionary<int, int> для хранения входящих и исходящих узлов... Очевидно, что ключи в таком случае будут повторяться, а это недопустимо в Dictionary. Или, я ошибаюсь?

автор ведосика объясняет [и не может объяснить] опять и снова банальность, её [банальность] придумали в 70-ых прошлого века, и вот эта банальность: программы - это данные и алгоритмы над этими данными, только это полуправда, а вот истина: программы - это __подготовленные__ данные и узкозаточенные алгоритмы над этими __подготовленными__ данными для этих алгоритмов данные - как розовая абстракция в вакууме никому не нужны, а равно и алгоритмы как абстракция в вакууме - тоже никому не нужны

Зачем .NET Channels когда есть ConcurrentQueue и SynchronizedCollection

абстрактные алгоритмы - это не сложно, 95% алгоритмов кнут описал в своих великолепных книшках, а вот сложное - это железные алгоритмы, потому что они завязаны собственно на железо, и самое сложное - алгоритмы завязанные на исполняющую среду, и вот это и есть главная проблема, которую вообще никто не рассматривает на пальцах: абстрактные алгоритмы - это не сложно, сложнее - железные алгоритмы, ещё сложнее - алгоритмы настроенные [заточенные] на исполняющую среду, потому что описывается всё, кроме работы исполняющей среды, исполняющую среду никто никогда не описывает а теперь реальная задачЬка: 1. сгенерируйте 10 мультов рандомных строк, замерьте время генерации этих строк 2. замерьте время __последовательного__ доступа к строкам 3. сгенерируйте 10 мультов рандомных строк, но __многопоточно__ , замерьте время многопоточной генерации этих строк 4. докажите, что строки нагенерированные многопоточно - рандомны 5. замерьте время __последовательного__ доступа к строкам, нагенерированным многопоточно 6. вы потеряете быстрый доступ к строкам, нагенерированным многопоточно 7. объясните что происходит, __на__ __самом__ __деле__ 8. вы никогда не сможете объяснить, потому что вы не знаете как работает рантайм, и это самое сложное и есть, всё остальное - не сложно а теперь реальная реальность: все эти абстрактные алгоритмы, всякое разное от кнута - всё это работает, но оно автоматически устарело, потому что мирок ойтишечки принципиально изменился, потому что теперь всё работает многопоточно, и всё ранее работающее, все абстрактные алгоритмы, все железные алгоритмы - становятся не нужны, потому что они отвратительно работают в многопотоке, а для многопотока нужно перекарячивать всё __по__ __новой__ , абсолютно всё что было - нужно перепиливать на многопоток - и это нереально сложная задача и есть задача выше - приведена, задача кажется тривиальной, и ранее на однопотоке она и решалась тривиально, но мирок изменился, и теперь эта казалось бы тривиальная задача по генерации строк - стала предельно __не__ __тривиальной__ а теперь главная суть - тотальный вменяемый переезд на многопоток, на многопоточные алгоритмы - это нереальной сложности задача, это самое сложное и есть, это и есть задачи массового ближайшего будущего в ойтишечке, а кто этого не понимает - отвалится, потому что никакой алгоритм, никакая программка на однопотоке никому не нужны, а соответственно и древние одичалые юзающие древние бесполезные алгоритмы - не нужны добро пожаловать в реальный мирок ближайшего будущего

1:41:20 "Зачем вам асинк в вебе?" "Почему бы просто не юзать треды?" Я бы скорее задался вопросом а зачем вам мультитред в вебе? Ведь чтобы обрабатывать запросы достаточно одного треда, который будет асинхронно всё обрабатывать. Если нагрузка это позволяет, то почему бы нет? Взамен не нужно заниматься синхронизацией тредов, в расте это выражается чем что не обязательно работать с Send типами и можно использовать более простые и легковесные типы. Многопоток куда менее гибок, чем асинк. В асинке есть select, можно просто взять две и более любые фьючи и скомпозировать их. Есть таймеры, которые опять же могут работать с любой фьючей. Есть удобная отмена и много других полезных вещей

Какая разница что внутри pin_mut! unsafe? Сам макрос так сделан чтобы безопасно его вызывать и самому никакой unsafe не писать. К слову в std есть более удобный макрос для пина на стеке std::pin::pin! Лучше его использовать, тем более что он возвращает значение, а не просто пересоздает переменную как pin_mut!

Асинк трейты с натягом в 2023 стабилизировали всё же

А возможно ли добавить к трансляции формул из excel интерфейс на основе JavaScript и его фреймворком?

самый крутой "краулер" реализован в церне, ну потому что там валит __в__ __секунду__ 40 __терабайт__ данных с детекторов, однако же оптимизация позволяет отфильтровывать [и отбрасывать] большинство поступающих данных, при этом остаётся всё равно нереально много, и уже этот "остаток" размещается в дата-центрах, и набор дата-центров церна - самый большой продвинутый и самый быстрый в мире, и ни одной канторке до дата-центров церна - никогда не дотянуться

базовые урлы берутся не из интырнетов, для базовых урлов достаточно локального дампа чего бы то ни было, например достаточно локального дампа википедии, и весьма многие подобного рода "агрегаторы" имеют готовый дамп, который можно скачать большими кусками и перемусолить локально вообще не лазя в интырнеты, плюс ко всему подобного рода дампы - __инкрементальные__ , т.е. скачивать и перепарсивать по-новой дамп не нужно, нужно подкачивать дамп изменений например за последний месяц, и этот инкрементальный дамп за месяц перемусоливать итд итп

думаю что то типа dig определяем IP адреса для A записей. Затем прогоняем их через какую либо открытую базу гео определения например maxmind

ребята, у вас с требованиями сразу беда, потому что требования изначально не верны суть краулера вовсе не в сборе каких то данных, это никому не нужно, суть краулера - это __динамический__ сбор данных ["динамический" - изменяемый по времени], и нужен именно такой краулер, который следит за __динамикой__ __изменения__ данных, а не сборщик данных как таковых

Как я понял из видео, postgres можно запускать в памяти для тестов? Если да, то как?

Ребят, у вас уши не потеют в наушниках? ) Спасибо за инфо по тестам.

Сегодня прямо очень хорошо, молодцы! И тема актуальная.

чувачку с бородой надо дать погоняло - "копи паст" :D

Спасибо за обзор !

Чел запарил со своими аналогиями. Особенно, когда при объяснения аналогии придумывает ещё одну. Да скажи как есть

Да, мы любим короткие выпуски

За ссылки на обсуждаемый контент и тайм-коды в описание - моё уважение и поклон.

implicit/explicit - эти ключевые слова уже есть. for - тоже. Итого только 1 новое ключевое слово

к вопросу о for вместо : вроде в c# после 13 реализация интерфейсов через экстеншены (может завезут в c# 13, но маловероятно) поэтому : заменили на for

Про extension types: - Я думаю, все уже знают, но implicit и explicit есть в языке - Согласен что : вместо for лучше и слово extension должно помочь парсеру однозначно распознать конструкцию... Мне кажется, они просто на коленке до билда эту фичу подлатали. Много вопросов, потому что ее имплементация годами лежала в форках, и была не одна (еще были concepts and roles). - Жду расширения UnsafeAccessAttribute для работы поверх экстеншена, чтобы доступаться к non public типам.

поменяйте тему видео на темную

Невозможно это слушать. Это мы там рассматривали, это мы тут рассматривали, это в книге подробно написано. Делайте самодостаточные видосы без миллиона отсылок.

Общая архитектура в итоге замылилась, не имея под рукой книжку вообще невозможно понять конечное решение. Хорошо бы в конце резюмировать

Все указывает на то, что MS при покупке mono просто пообещали, что не будут убивать xamarin/maui какое-то время. И сейчас выделяют минимум ресурсов на поддержку. Как будто там всего 5 человек и то, на парт-тайме. Ну и в МС, зная, что xamarin/maui скоро сами же убьют, нигде не используют сами.

После многообещающего начала "бугаенко-долбоящер" ожидал увидеть феерию технической экспертизы. Однако дальше проганья с похмелья не поехало... Спасибо, что час, а не три с половиной. Обнял - приподнял!

Тема тестов не раскрыта ) Почему ничего не сказали про архитектуру? Когда пишешь через тесты, классы/модули получаются слабосвязанными и хорошо тестируемыми (автоматически), а не прибитыми гвоздями друг к другу. Архитектура как бы выкристаллизовывается под давлением тестов - и она получается как ни странно красивой. Лучше прорабатываются различные конеркейсы. Падение скорости разработки - это иллюзия. Поддерживать потом такой код - это одно удовольствие: - новая фича имплементиться написанием теста/тестов быстро и просто - код легко читается - тесты заменяют документацию - не нужен раздутый штат тестировщиков. экономия по деньгам 2x/3x для компании. Я уж молчу про стабильность работы - на порядки возрастает.

Ребята, у вас сильно идеализированное рассуждение про работу с легаси для доработок: "Сломал систему тестом, разобрался, почему не работает; сделал доработку - починился тест". По факту бывает так, что ты нифига не понимаешь, что там за значения бегают на входе и на выходе, и не можешь их соотнести с бизнес-требованиями по доработке... пока не продебажишь *систему целиком* на самой бизнес-задаче.

TDD не дает возможности писать код, выключив голову - что бы там Саша не говорил. Потому что правильный тест на код написать бывает в 2 раза сложнее, чем сам код. Более того, сосредоточение на тестах переносит умственные усилия не в ту сторону, поскольку часто одну и ту же задачу можно решить разными способами уровня выше, чем тестируемый модуль. А иногда некоторые изначально придуманные и тщательно протестированные по TDD способы в реале оказываются нерабочими, и крупноблочную архитектуру приходится переделывать. Поэтому эффективнее сначала реализовать MVP-версию своего решения, а потом допиливать, паралельно покрывая тестами.

по поводу нсвага: всю кастомизацию можно делать за счет .liquid шаблонов. мы у себя так делаем больше 2-3 лет)

с tdd тебе не нужно знать полный путь до метода, ты сразу его запускаешь из теста

Nikolay шарит

лучше tdd пока не придумано

Почитал статью про каналы, ну такое, шина сообщений чаще всего синхронная (просто как способ развязать классы, избавится от прямых зависимостей, сделать код расширяемым) и тут смысла в каналах нет, для асинхронного режима все же лучше через базу прокидывать, это надежный способ. В сухом остатке задач под каналы практически нет, ну может какой-то не очень важный паблишинг в signalr.

Согласованное хэширование используется при клиентском шардировании БД для определения в какой шард идти за данными