DotNetRu - группа независимых сообществ .NET разработчиков со всей России. Мы объединяем людей вокруг .NET платформы, чтобы способствовать обмену опытом и знаниями. Проводим регулярные встречи, чтобы делиться новостями и лучшими практиками в разработке программных продуктов.
Наши группы:
ВКонтакте: vk.com/dotnetru
Telegram Channel: t.me/DotNetRu
Telegram Chat: t.me/DotNetRuChat
Пікірлер
1:00:48 опять какое то "понимание", что за понимание, откуда оно? зачем оно? зачем? друзи, интерфейс - это родительская абстракция ограниченного функционала, ни больше ни меньше ну смотрите, у вас есть классические абстракции, ну есть и есть) есть типичное Figure2D, вы от него можете наследовать Triangle и так далее, ну и что? у вас есть родительский тип, и есть производный тип, или вы что-то карячили у вас есть тип, и вы решили сообразить абстракцию от этого типа - у вас появился родительский тип - какая разница, суть одна - у вас абстракции [две штуки] и между ними операция "абстрагирования" у интерфейсов всё ровно так же, у вас есть типы, вы можете сообразить типы, пусть это интерфейсные типы - и что? это родительские абстракции и есть, только с той лишь разницей, что это абстракции ограниченного функционала, т.е. это часть изначальной абстракции, которую "абстрагировали" до интерфейса, и теперь интерфейс как [частичный] родитель отвечает [может отвечать] за эту абстрагированную часть абстракции есть родитель - это понятно а интерфейс - это полу-родитель, треть-родитель, четверть-родитель - называйте как хотите Figure2D [родитель] | \ Triangle, Circle ISquare [родитель ограниченного функционала] | \ Triangle.Square(), Circle.Square()
1:03:29 вот обсуждается размер файлов и чтение файлов - а это вообще несовместимые сущности, и какой одичалый всё это совместил - это вообще непонятно, потому что размер файла хранится в базе данных дескрипторов - и обращение идёт __втуда__ , а чтение файлов - это обращение в бд дескрипторов и чтение набора байт, в дескрипторе указано начало и так далее где этот файл лежит например по версии нтфс-а, или же оно лежит в оперативке, если оно уже зачитано и оно лежит [уже] в оперативке т.е. __на__ __самом__ __деле__ никакого чтения файла - нет, никакого получения размера файла - нет, какой ска паразит это придумал - его расстрелять нужно три раза и всё, потому что в этом всём __реальности__ - нету а реальность здесь - это дескриптор, и получать нужно дескриптор из бд дескрипторов, и вот там указан и размер файла и начало этого файла - вот это __реальность__ , и вменяемое получение колбеков должно быть, всё это кучерявое апи должно быть вменяемое, а оно вкрай невменяемое т.о. вменяемое [ещё раз - вменяемое] по - это отражение реальности, а не розовые влажные ёжики в вакууме, и если бы базовые библиотеки были вменяемые [а когда то они были вменяемыми], то и проблем бы сейчас и не было, и никто не обсуждал бы как приколотить какой то ссатый интерфейс, и чего он значит - а ничего он значит, он не нужен, а вменяемый файловый дескриптор завален килотонной бесполезных прокладок над прокладками поверх слоя прокладок, и уже "где то там" закопана реальная реальность - и где она закопана это вообще не известно
для тех кто не понял - в данном случае вменяемое по - это апи поверх нтфс-а, если это нужно, или же это апи поверх виртуальной памяти - если это нужно, но это разные сущности, они __не__ __объединимы__ , у них разные задачи, это галимая бд что бы надёргать из неё например какие то имена/структуры, или же это уже виртуальная память где уже лежит какой то файл [набор байт] и к нему требуется обращение, но по какой то невообразимой причине это всё намешано в аццкую кучу - как компот, суп, кота шерстяного туда же, катлета и ананас - всё в блендер скидали перемешали получилась бливотина
00:53 Проблемы с типиклайтом 06:33 Умные клиенты 08:26 Обработка ошибок и тайм-ауты 11:11 Пример конфигурации типиклайта 12:41 Обзор библиотек для работы с API 20:13 Примеры использования библиотек 25:47 Обзор библиотек для создания клиентов 32:36 Рефит и Рест-Из 34:45 Киото и Ред Шарп 39:07 Сравнение производительности 40:30 Выбор генератора клиентов 42:57 Дебаг и оптимизация 45:48 Версионирование и использование интерфейсов
На практике SOLID - SID (без OL)
ребяты, а давайте прощще) покажите хотя бы один код, где реализован солид по фен-шую, ну хотя бы разик сие чюююдо увидеть ну хоть один разик - покажите! пс: я вам могу показать много кода, но оно не то что далеко от фен-шуя, оно предельно [запредельно] далеко от фен-шуя, типичный пример моего [например] синглтона, привожу __полный__ код: // ибанько - это синглтон, ровно один[!] раз создай экземпляр этого типа, больше не нужно, нельзя[!] public class SomeObject_Single { // бла бла дальше какой то код } это синглтон и есть, а вы что подумали? а со своим фен-шуем идите казе втрещщину, никому не нужен ваш [или не ваш] фен-шуй, потому что фен-шуй полностью бесполезен
ребяты я ни одного так называемого сабеса не прошёл, впрочем когда то пытался но это было так давно [10-15 лет взад], что про это можно даже не вспоминать, потому что всё заканчивалось предельной банальностью - некий интервьюер посылался мною найух, а как это происходило? ну вот спрашивало меня это бесполезное тело - а что такое ооп? а я ему в ответ - а что такое объект? вот зная что такое объект __в__ __рантайме__ - вот из этого и следует ооп, но тогда уже я спрашивал - а как работает рантайм? и кто кого собеседовал - становилось вообще непонятно, а в итоге некое моё резюме сразу же свелось к банальности - моё резюме начинается со следующего: не знаешь как работает рантайм? тогда закрой резюме, ты мне не нужен, найухиди не мешай
41:58 так это давно понятно, что дот-нет - это если притянуть заушы - это рантайм и би-си-ель [bcl - base classs library], и как раз таки рантайм напейсали великие гении [ну почти], а би-си-ель напейсали студенты полуподвальные так извините у всех вменяемых базовые типы - свои, ну вот так вот - рантайм общий, стринг/инт/лонг - общие, а всё остальное карячут сами, вы не знали об этом? ну полностью своя базовая библиотека типов - что тут непонятного? свои словари, свои аллокаторы, свои массивы, всё что есть - всё своё, свой би-си-ель, потому что вся та чюшьня от майкрософта - она вкрай невменяемая, кривая-касая-глючная-забагованная-тормозная, и ничего на этом вменяемого не сделать
как пользовать би-си-ель от майкрасофтины, например банальный ulong.TryParse(string), если он ничего не может? а он ничего не может, не может парсить из массива, из любого массива, из указателя, не может парсить так, как мне нужно, и на это напейсался свой TryParse(), и это большой набор методов, все они работает на порядок быстрее, на некоторых данных на пару порядков[!] быстрее, за счёт этого конечные парсеры работают сильно быстрее и так далее, пейсать всё сильно проще, потому что мой TryParse() - это грандиозная часть моего би-си-еля, эта часть может всё, и делает это самое всё - быстро, вот так вот весь би-си-ель полностью свой, банальный пример - у меня существуют статические классы, вот же они: Bytes_ToUInt32 Bytes_ToUInt64 String_ToUInt32 String_ToUInt64 и так далее, а теперь посмотрим на методы в каком нибудь классе, пусть это будет класс Bytes_ToUInt64, вот его методы: ulong = Bytes_ToUInt64.OptimizedForMinValues(byte[] bytes) ulong = Bytes_ToUInt64.OptimizedForMinValues(byte[] bytes, int start) bool = Bytes_ToUInt64.OptimizedForMinValues(byte[] bytes, out ulong result) bool = Bytes_ToUInt64.OptimizedForMinValues(byte[] bytes, out ulong result, int start) ulong = Bytes_ToUInt64.OptimizedForMaxValues(byte[] bytes) ulong = Bytes_ToUInt64.OptimizedForMaxValues(byte[] bytes, int start) bool = Bytes_ToUInt64.OptimizedForMaxValues(byte[] bytes, out ulong result) bool = Bytes_ToUInt64.OptimizedForMaxValues(byte[] bytes, out ulong result, int start) ulong = Bytes_ToUInt64.OptimizedForMinValues(byte* bytes) bool = Bytes_ToUInt64.OptimizedForMinValues(byte* bytes, out ulong result) ulong = Bytes_ToUInt64.OptimizedForMaxValues(byte* bytes) bool = Bytes_ToUInt64.OptimizedForMaxValues(byte* bytes, out ulong result) ulong = Use1Digit(byte[] bytes) ulong = Use1Digit(byte[] bytes, int start) ulong = Use1Digit(byte* bytes) ulong = Use2Digits(byte[] bytes) ulong = Use2Digits(byte[] bytes, int start) ulong = Use2Digits(byte* bytes) ulong = Use3Digits(byte[] bytes) ulong = Use3Digits(byte[] bytes, int start) ulong = Use3Digits(byte* bytes) и так далее там 200+ методов и это на один класс, а классов дофига, ну потому что парсить в цыферки можно много чего, и много из чего, так вот я всего лишь про то, а как жить без вменяемых базовых парсеров? ну я фиг знает как, вы же как то "живёте"
Чья песня в конце? Кто поёт?
Наше собственное производство :)
@@DotNetRu круто! Когда и где будет концерт?
32:38 оно делается не так, всё то что описал николай - давно придумано в 70-ых, оно называется - дескриптором, и для этого интерфейсы не нужны
все эти ваши архитектуры принципы какие то - это всё фигня, причём это не то что фигня - это __вредительство__ ну смотрите, допустим есть базовая высокопроизводительная библиотека типов, её накарячили вменяемые люди из вменяемого прошлого из вменяемой страны из вменяемой канторы, и тут значит вы? слушайте, вы когда пальцами касаетесь чего либо - вы можете только разрушить, потому что вменяемые из прошлого делали весьма обдуманно, и на это обдуманное все эти ваши принципы - не накарячиваются, а если вы эти принципы прикарячиваете - вы тут же разрушаете всю ту логику, на которой написана вменяемая библиотека типов пример на пальцах: вот как можно прикарячить какой то ссатый солид на например вин-мсг? это как? как можно запросто совмещать в принципе несовместимое? и у вас всё именно так, вы исключительно и только ломаете вменяемое, а больше вы ни на что не способны, у вас всё всегда черизсраку
Я вижу смысл в принципах и паттернах только один - "общий знаменатель" для программистов. Чтобы новый человек мог зайти в проект и чувствовать как дома
странные у вас смыслы, ну потому что нигде таких смыслов - нет, тем более что это не смыслы вовсе, и такие пвевдо-смыслы есть конечно, это например у дошкольников - там где объясняют числа на памидорках или каких нибудь белочках, и никакого общего знаменателя тут нет и быть не может, потому что общий знаменатель в случае с числами - это теория чисел, а не теория белочек на памидорках
и ага, тут же очевидная проблема есть - это переход от белочек к реальности, и это ещё хуже, чем учить, потому что это называется "переучивать" - а это сильно хуже, чем "учить"
и да, тут есть ещё железобетонная проблема - это когда общего смысла - нет изначально, ну потому что к нему __изначально__ никто не стремился, ну смотрите есть группа программистов нтфс-а, есть группа программистов джава-рантайма, есть группа программистов ядра квейка-первого, и так далее список бесконечен вот вы не мне, а себе объясните - они эти самые разнообразные группы имели/имеют общие смыслы? рилииии?? у них всё реализовано принципиально по-разному, потому что у них принципиально разные задачи, разные подходы, разные цели, разные __смыслы__ , и совершенно разная логика на вот это всё разнообразное - солид не накарячить, и вообще ничего не накарячить поверх, такого что бы оно заимело общий смысл, потому что этого общего смысла - __нет__
@@AEF23C20 Из этого опуса я понял только одно, что ты понятия не имеешь что такое SOLID.A
посоны вы не понимаете, сколько заплачено - такая и архитектура ахаха!
Александр прочитал одну статью про SRP, и теперь упорно стоит на том, что этот принцип именно такой, какой он описан в статье. Но Николай сказал правильно, этот принцип изначально звучал по другому. Еще в книге Agile, principles, patterns and practices in C# дядя Боб еще 15 лет назад описал примеры па каждоному принципу. И вот там, SRP как раз таки был описан без людей. Пример в том, что класс саязанный с модемом, имеющий методы установления соединения, закрытия соединения, и методы для отправки и приема данных, то этот класс нарушает SRP. Всё... Никаких тебе стейкхолдеров. Изучайте первоисточники тщательнее, иначе дискуссия выглядит очень странно. Николай не придумал свой SRP, он его описал как раз таким, каким его изначально описал Мартин.
15 лет назад Дядюшка Боб просто не мог его описать конкретно, а в 2014 смог
@@DotNetRu Если понимать статью 2014 года как более "конкретную" формулировку, то пример с модемом из его книги, а также пример из англоязычной википедии не имеет ничего общего с SRP. Проектируя класс модема (или reporter из вики), мы можем разделить его с соответствии с ответственностями даже не задумываясь об акторах. Говоря об этом подходе, который соответствует принципу Separation of concerns, мы не можем говорить, что это принцип Николая, например. Это вполне себе Martin's SRP в его изначальной формулировке. Формулировка 2014 года, если понимать ее как переосмысление, а не как дополнение, напрочь переворачивает смысл всего принципа, делающая его несовместимым с SOLID. Так как солид изначально был про низкоуровневое проектирование. Там нет ничего про бизнес и про людей. Вы можете проектировать системную утилиту, торгового бота или что-нибудь еще, и успешно применять SOLID. А для бизнес-ответственностей и для людей у нас есть DDD и прочие подходы. Возвращаясь к моему изначальному посылу: Николай не придумал свой принцип, он о нем говорил как об SRP придуманный Мартином вполне законно. То, что Мартин окончательно всех запутал и перевернул все с ног на голову в 2014, не делает из этого "принцип Николая", а делает его скорее как "SRP в оригинальной интерпретации, более подходящей к SOLID".
В Чистой архитектуре 2017 года он формулирует принцип как "у класса должна быть только одна причина для изменения", упоминая стейкхолдеров, как одну из важных причин для изменения кода, но не зацикливаясь на них. Он различает разные задачи, которые могут ставить одни и те же люди и допускает ситуативный подход к определению "одной ответственности". Там же он говорит, что S применим к проектированию классов, но так же легко масштабируется для больших программных модулей. Для отмасштабированного принципа он предлагает отдельное название, но я его сейчас не вспомню.
@@xaknickполучается что сам автор SRP запутал программистов: еще один повод не трогать SRP
Александр слишком фанатично продвигает религиозное происхождение Солида )) Текущее применение S - по-моему это просто экстраполяция рекомендация того что описал Мартин, по-моему не плохо. Про чувака, который писал на ревью что "этот код не подходит по SOLID" - это проблема в чуваке а не принципа. Замени претензию к SOLID на "Что за хрень ты написал? Переделать!" и получишь ревьювера той же квалификации(её нет).
Проблема экстраполяции в нечеткости - Вася и Петя по-разному экстраполируют и один и тот же принцип понимают по-разному. В итога получаем путаницу. Уж лучше бы каждый из них придумал собственный термин.
Спасибо, интересно было
в блоге автора книги про EF, которую вы переводили, есть хорошая статья про миграции. thereformedprogrammer статья handling-entity-framework-core-database-migrations-in-production-part-2
А признавайтесь, у кого блейзор васм в продакшене есть? Есть вообще будущее там? Я попробовал года три назад. Вроде норм было, кроме размера билда. Вроде было всё что нужно базово, даже флаксор мне в принципе норм. Жс интероп страшненький, но жить можно. Телерики всякие компоненты пилят. Но с тех пор ни кейсов не встречаю, ни вакансий.
44:36 я даже не знаю как на "это" "реагировать" /// Converts an object to null. Returns null. public static object ToNull(this object value) { return null; } комментарий к методу "Converts an object to null. Returns null." сразу показывает тотальное непонимание __всего__ ну потому что никаких объектов нет, это ссылки а не объекты, объектам неоткуда взяться, но почему то написано, что некие объекты "конвертируются" [чёёёё??] в null. причём это даже не ссылки а копии ссылок, в методе именно копии ссылок бггг, а сами ссылки где то там "выше", в вызывающем метод коде этот метод "зануляет" ссылки, и не более, никаких "объектов" метод не касается вовсе /* можно так */ obj = null; /* ну или так */ obj = obj.ToNull(); ил-код метода: // Code size 2 (0x2) IL_0000: ldnull IL_0001: ret никакого выигрыша тут нет, проигрыша впрочем тоже нет, а безумия много на самом деле нужно передать настоящую ref-ссылку в метод, в методе её же занулить, если так шыбко хочется [ну или это действительно нужно], и естественно всё обвешать AggressiveInlining и ещё много чем тем не менее у любого безумия есть выгода, и тогда некое безумие может быть не так уж и безумно ну смотрите, допустим вы обычным способом зануляете ссылки [зачем почему - это не суть, вопрос в другом], и понятное дело вы будете занулять классическим способом, но действительно лучше использовать "метод-занулятор", а потому что всегда можно взять и переписать/дописать этот метод, т.е. например пусть он считает "зануление" ссылок, или смотрит откуда они, и так далее, или вообще перестанет возвращать null, а что-то другое это же типичная [впрочем, не такая уж и типичная] тестовая ситуация, когда надо что-то, а через 5 секунд надо что-то другое, вот этот "метод-занулятор" наверное и был накарячен, впрочем накарячен почти отвратительно, но тем не менее смысл есть а на самом деле нужно взять класс object, там накарячить виртуальный метод ToNull() принимающий и зануляющий настоящие ссылки, что бы затем можно было как раз таки перекарячивать у всего производного это самое стандартное поведение
9:55 говорят, что все нормально кроме ловли исключения. Название метода не соответствует правилам именования, пример GetDateTimeOrNow. Если ловит исключение, то конкретное, а не все как тут. В данной ситуации исключение ловить не нужно, нужно только проверить на null и вернуть Now, если от этой идеи (возврат Now) нельзя отказаться.
Про неопределенность требований в курсе, ребят? Какие тест ферст и тдд
OMG, this is Russia 😳😨Very dangerous
Russia 😨 very dangerous :(
Такая боль слушать про конструкторы и не видеть о чем речь 🎉
Можно ссылку со статьёй открыть. На видео оператора или спец. эффекты мы пока не накопили :)
Интересно - спасибо!
Ну вы что...рантше были выступления на уровне,та скйчас вск слабее и слабее... видать вск мозги уехали (
просто витрачений час, нічого нового і цікавого все абстрактно , нової інформації 0, все сказане знають навіть люди не зв`язані із fpv
Півтори години води
Чтобы не ставить приватный анализатор, к параметрам primary constructor можно добавить ключевое слово `in`, тогда их разрешено будет использовать только при инициализации класса.
Пошла магия 30 уровня. Спасибо, попробую.
@@tt0nixпро магию точно сказано 😊
Бесполезно
По поводу уникальности. Если мы не можем отличить в таблице два ресторана в спб шаверма и шаверма, то какой смысл в этом? Ну допустим их можно будет добавить с гуидами, но пользователь то не будет знать, что это за шаверма. С фио тоже самое. Натуральная уникальность необходима для таких вещей.
Для ресторанов это например координаты, или какое-то кадастровый номер. Для фио, день рождения, пол и тд
@@GirlAteDeath Насколько я понял, тут освещалась статья не против уникальности, а против использования таких полей в первичных ключах. Например, из ваших примеров: координаты или кадастровый номер были введены неверно, потом их поправили, и всё, ключ поехал.
@@zachemny ну я с последними аргументами согласен и сам за обычные искусственные ключи. Но примеры в начале были плохим аргументом
@@GirlAteDeath Примеры были максимально понятные большенству. Если две одинаковые шавермы на улице, то у пользователя есть миллион способов их отличать: по расположению, цвету прилавка, причёске продавца. Это может как иметь отражения в БД (например поле со свободным комментрием) так и не иметь. Но всё это слишком непредсказуемые и переменчевые критерии чтобы на их основе строить именно первичный ключ. В общем случае: первичный ключ - это не то поле по которому пользователь будет семантически отличать записи. Например вы не отличаете друзей только по имени (если имена совпадают), у вас есть много дополнительных критериев. И у каждого человека такие критерии будут разные. А ключ должен быть однозначно один для всех.
Дочерним спаном может не хотеться делать, если там огромное количество операций. Потом просто трейс будет невозможно, ни смотреть, ни изучать
Интересный вариант, спасибо.
В файле проекта сделают "use primary constructor parameters as readonly" тру фэлс и не будет брэйка)) keylookup дополнительно получаешь будучи джуном. Т.к. праймери ключ, чаще всего и кластерный индекс...) А не помню, обсуждалось про ЕФ8, что они вместо In начали OpenJson делать?
Про OpenJson не было. Есть какие-то ссылки про почитать?
Вот, кстати, мне непонятна эта политика релизиов. Если команда EF Core рождает фичу, которая стабильна и не имеет ломающих совместимость изменений, то почему бы не выпускать её как апдейт минорной версии? Но они почему-то предпочитают ждать год и выкатывать одним большим пакетом.
Может быть замешан маркетинг? На минорной фиче инфоповодов не выстроешь и конференцию Build не соберёшь. А так смотри какой праздник каждый год, анонсы, статьи, доклады, хайп.
Flight Per View - fpv (Если коптеры)
а не First Person часом?
@@m057d0p3 вони вигадали нову розшифровку))
Спасибо ребят
Хех, как только я увидел primary constructors - сразу запретил их в проекте через рослин аналайзер. Кому интересно, гитхаб - magicxor/MagicxorAnalyzer.CSharp
Думаю, такая практика будет пользоваться спросом :)
Им куча народу писала, не несите в язык полуготовую фичу. Не послушали. =(
очень круто, спасибо!
Спасибо за очередные новости!
Эмм... 38:09 Предлагается сделать Dictionary<int, int> для хранения входящих и исходящих узлов... Очевидно, что ключи в таком случае будут повторяться, а это недопустимо в Dictionary. Или, я ошибаюсь?
Да, там в зале сразу поправили, что как вариант, надо Dictionary<int, int[]> по ключу находим узел, а в массиве список переходов.
автор ведосика объясняет [и не может объяснить] опять и снова банальность, её [банальность] придумали в 70-ых прошлого века, и вот эта банальность: программы - это данные и алгоритмы над этими данными, только это полуправда, а вот истина: программы - это __подготовленные__ данные и узкозаточенные алгоритмы над этими __подготовленными__ данными для этих алгоритмов данные - как розовая абстракция в вакууме никому не нужны, а равно и алгоритмы как абстракция в вакууме - тоже никому не нужны
Зачем .NET Channels когда есть ConcurrentQueue и SynchronizedCollection
Верхнеуровневый смысл похож. Низкоуровневые принципы разные. Channels более производительный и гибкий. А коллекции более удобные и понятные в использовании.
абстрактные алгоритмы - это не сложно, 95% алгоритмов кнут описал в своих великолепных книшках, а вот сложное - это железные алгоритмы, потому что они завязаны собственно на железо, и самое сложное - алгоритмы завязанные на исполняющую среду, и вот это и есть главная проблема, которую вообще никто не рассматривает на пальцах: абстрактные алгоритмы - это не сложно, сложнее - железные алгоритмы, ещё сложнее - алгоритмы настроенные [заточенные] на исполняющую среду, потому что описывается всё, кроме работы исполняющей среды, исполняющую среду никто никогда не описывает а теперь реальная задачЬка: 1. сгенерируйте 10 мультов рандомных строк, замерьте время генерации этих строк 2. замерьте время __последовательного__ доступа к строкам 3. сгенерируйте 10 мультов рандомных строк, но __многопоточно__ , замерьте время многопоточной генерации этих строк 4. докажите, что строки нагенерированные многопоточно - рандомны 5. замерьте время __последовательного__ доступа к строкам, нагенерированным многопоточно 6. вы потеряете быстрый доступ к строкам, нагенерированным многопоточно 7. объясните что происходит, __на__ __самом__ __деле__ 8. вы никогда не сможете объяснить, потому что вы не знаете как работает рантайм, и это самое сложное и есть, всё остальное - не сложно а теперь реальная реальность: все эти абстрактные алгоритмы, всякое разное от кнута - всё это работает, но оно автоматически устарело, потому что мирок ойтишечки принципиально изменился, потому что теперь всё работает многопоточно, и всё ранее работающее, все абстрактные алгоритмы, все железные алгоритмы - становятся не нужны, потому что они отвратительно работают в многопотоке, а для многопотока нужно перекарячивать всё __по__ __новой__ , абсолютно всё что было - нужно перепиливать на многопоток - и это нереально сложная задача и есть задача выше - приведена, задача кажется тривиальной, и ранее на однопотоке она и решалась тривиально, но мирок изменился, и теперь эта казалось бы тривиальная задача по генерации строк - стала предельно __не__ __тривиальной__ а теперь главная суть - тотальный вменяемый переезд на многопоток, на многопоточные алгоритмы - это нереальной сложности задача, это самое сложное и есть, это и есть задачи массового ближайшего будущего в ойтишечке, а кто этого не понимает - отвалится, потому что никакой алгоритм, никакая программка на однопотоке никому не нужны, а соответственно и древние одичалые юзающие древние бесполезные алгоритмы - не нужны добро пожаловать в реальный мирок ближайшего будущего
и ага, для тех кто ничего не понял, на пальцах: если вы не способны карячить банальные массивы многопоточно, если вы не способны изменять массивы многопоточно, если вы не способны играть в многопоток - вы уже отстали от жизни лет на десять как минимум, вам дали проц например на 12 ядер - а вы даже банальный массив не в состоянии накарячить на этих двенадцати ядрах пс: массив это банальный пример, но вы и с банальностями не справляетесь, задумайтесь над этим ппс: выводы
Смотришь на симпотичную девушку и параллельно готовишься к собесу по алгосам
1:41:20 "Зачем вам асинк в вебе?" "Почему бы просто не юзать треды?" Я бы скорее задался вопросом а зачем вам мультитред в вебе? Ведь чтобы обрабатывать запросы достаточно одного треда, который будет асинхронно всё обрабатывать. Если нагрузка это позволяет, то почему бы нет? Взамен не нужно заниматься синхронизацией тредов, в расте это выражается чем что не обязательно работать с Send типами и можно использовать более простые и легковесные типы. Многопоток куда менее гибок, чем асинк. В асинке есть select, можно просто взять две и более любые фьючи и скомпозировать их. Есть таймеры, которые опять же могут работать с любой фьючей. Есть удобная отмена и много других полезных вещей
Какая разница что внутри pin_mut! unsafe? Сам макрос так сделан чтобы безопасно его вызывать и самому никакой unsafe не писать. К слову в std есть более удобный макрос для пина на стеке std::pin::pin! Лучше его использовать, тем более что он возвращает значение, а не просто пересоздает переменную как pin_mut!
Асинк трейты с натягом в 2023 стабилизировали всё же
А возможно ли добавить к трансляции формул из excel интерфейс на основе JavaScript и его фреймворком?
самый крутой "краулер" реализован в церне, ну потому что там валит __в__ __секунду__ 40 __терабайт__ данных с детекторов, однако же оптимизация позволяет отфильтровывать [и отбрасывать] большинство поступающих данных, при этом остаётся всё равно нереально много, и уже этот "остаток" размещается в дата-центрах, и набор дата-центров церна - самый большой продвинутый и самый быстрый в мире, и ни одной канторке до дата-центров церна - никогда не дотянуться
нужно добавить, зачем сие церну? дата-центры церна обслуживают естественно большой адронный коллайдер, события бак-а, т.е. всё то что называется столкновениями частиц, и результаты этих самых столкновений частиц как раз и хранятся в дата-центрах церна, и это самая манструозная айтишечка из имеющихся в мире в принципе, ничего более крутого чем в церне пока не существует
базовые урлы берутся не из интырнетов, для базовых урлов достаточно локального дампа чего бы то ни было, например достаточно локального дампа википедии, и весьма многие подобного рода "агрегаторы" имеют готовый дамп, который можно скачать большими кусками и перемусолить локально вообще не лазя в интырнеты, плюс ко всему подобного рода дампы - __инкрементальные__ , т.е. скачивать и перепарсивать по-новой дамп не нужно, нужно подкачивать дамп изменений например за последний месяц, и этот инкрементальный дамп за месяц перемусоливать итд итп
думаю что то типа dig определяем IP адреса для A записей. Затем прогоняем их через какую либо открытую базу гео определения например maxmind
ребята, у вас с требованиями сразу беда, потому что требования изначально не верны суть краулера вовсе не в сборе каких то данных, это никому не нужно, суть краулера - это __динамический__ сбор данных ["динамический" - изменяемый по времени], и нужен именно такой краулер, который следит за __динамикой__ __изменения__ данных, а не сборщик данных как таковых
Как я понял из видео, postgres можно запускать в памяти для тестов? Если да, то как?
Ребят, у вас уши не потеют в наушниках? ) Спасибо за инфо по тестам.
В Sony XM4 не потеют :)