Видео

Просто оставлю это здесь: habr.com/ru/articles/204580/ :-)

Джаваскрипт - хорош для изучения тем что про него очень много информации. И результаты видны сразу. Раст - это уже специфический язык если кратко - "реинкарнация" C++. Какой язык изучать - сильно зависит от того, какие результаты хочется получить. Из того что очень долго остается востребованным и скорее всего еще долго будет - SQL. (А учитывая что всякие GPT очень хорошо умеют его анализировать, то изучать просто). Итого, без деталей очень сложно что-то посоветовать.

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

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

Согласен. А с другой стороны то, что нужно знать для системного программирования конечно. Модели памяти уже устоялись и описаны многократно и т.п. Тут уж кому как нравится. Кто-то любит оптимизировать одну функцию по году выжимая доли процентов ускорения и байты памяти экономии а кто-то требует новых задач, как только старые заработали хотя бы в виде прототипа.

Готовлю онлайн демо. :-) будет тут: dimonsmart.github.io/Demo/

Online demo: dimonsmart.github.io/Demo/mazegeneratordemo

Спасибо что заметили :-) Работаем над этим.

Дмитрий крут!

Мы рады что вам нравятся наши ролики. Будем стараться делать ещё. Кстати, интересно услышать мнение о использовании мигратора. Что понравилось, что нет. Чем пользовались раньше.

@@itchatter так случилось, что на текущем проекте, куда я попал используется данный мигратор, мне нужно было с ним ознакомиться. В целом, оказалось достаточно удобно. До этого работал с Entity Framework, если говорить про .net стек. Когда работал с Java то использовал Liquibase.

SpecFlow - это отличный пример как довольно привлекательная идея полностью портится реализацией...

Я пользовался down миграцией при отладке когда в котором миграция не только менялся таблички но и перекладывала данные. Для отладки было удобно. В реальности код который делает миграцию вниз обычно не тестируется вообще и присутствует для вида. Поэтому полностью согласен что лучше вообще отказаться от метода down чем узнать что он не работает в тот единственный момент когда он реально понадобится.

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

C++ - был отличный язык ... для своего времени. Не останавливайся на нём.

@@itchatter, а что посоветуете такое же хардкорное и интересное, в то же время актуальное?🙃😉

Любопытная постановка вопроса. Всё зависит от того что понимается под хардкорностью и зачем она нужна. Если мы говорим о близости языка к машинному коду и о возможностях низкоуровневых оптимизаций то Assemler и C. Но тут надо понимать что возможность написать что-то очень быстрое это не тоже самое что написать что-то быстро. Чем выше абстракции, тем больше накладные расходы. Но что лучше, программа которая работает неоптимально но сегодня или супер оптимизированная и очень быстрая но очень сильно не сегодня. Про абстракции рекомендую: ruclips.net/video/Fu67U2px2Jo/видео.html Если же мы говорим о возможностях кратко выражать сложные мысли то тут надо смотреть в сторону dsl и далее. Про DSL сильно рекомендую сайт tomassetti.me/ и пару видео на нашем канале ruclips.net/video/YSh6q5XWGy0/видео.html и ruclips.net/video/YSh6q5XWGy0/видео.html

​@@itchatterC++ был отличный язык? Серьезно? Айфон был хорошим телефоном, а бананы вкусным фруктом... 😅

Разверни мысль, пожалуйста. Про C++ да. Для того времени, когда все только прекратили массово пользоваться ассемблерами и когда вообще было не совсем понятно что такое программирование С++ был лучиком света. Сейчас его значение сильно уменьшилось., появились стройные и более структурированные альтернативы.

Хорошее наблюдение. И, кстати, очень похоже что да, но! Чтобы найти это самое большое число все равно надо будет перебрать все элементы, а это опять n.

О(1) не зависит от набора данных. Если "константа зависит от содержимого массива", то это уже не константа.

Так когда мы считаем O от чего-то, то мы выкидываем все константы и все, что очень быстро отрабатывает. В данном случае скорость перебора массива явно быстрее, чем sleер с минимальным значением. Значит, самое длинное время - при самом большом элементе. Или я вообще ничего не понял и написал херню)))

Семёну и нам приятно! Спасибо!

Спасибо за содержательный комментарий. Кстати, если присмотреться то сортировка таймером и сортировка подсчетом идейно очень близки. Но с таймером гораздо веселее :-).

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

@@itchatter за какое время вы выбираете нужный вагон? Мне кажется, вы получили сортировку пузырьком.

@@itchatter да, я тоже сначала хотел написать, что это сортировка подсчётом, пока не подумал про сложность работы шедулера...

мне больше нравится таймер ))0)0)

Спасибо!

Здравствуйте. Очень интересно что имеется ввиду под "закрывает игрока", т.к. алгоритм из предыдущего примера всегда генерирует проходимый лабиринт. И было бы интересно посмотреть на то что у вас получается. Кидайте ссылки на ваши эксперименты сюда. Думаю это многим будет интересно.

@@itchatter всё, я понял в чем проблема, то ли вы не сказали в прошлом видео, то ли я прослушал. Ну в общем проблема в том, что когда у нас строится стена, полосочкой так бежит в какую - то сторону, то при столкновении с другой стеной, эта стена должна закончиться. Вот, я этого не сделал в начале, ну и простой пример закрытия игрока в таком случае, это допустим с клетки 2,2 стенка идет влево, а с клетки 4,2 стенка идет вверх. Таким образом получится, что клетка 1,1 будет изолированной.

@@user-be9rc4yz8r ​ Отлично что получилось разобраться. Возможно этот комментарий поможет тем кто будет строить лабиринты позднее.

Спасибо! Очень приятно получать такие отзывы!

github.com/DimonSmart/MazeGenerator/ Тут и генератор лабиринта и поиск пути в лабиринте. Можно использовать для своих разработок

@@itchatter Огромное спасибо, изучу )

@@Larni_Frey +OnlineDemo: dimonsmart.github.io/Demo/mazegeneratordemo

Спасибо. Продолжение следует. В следующей задаче будем искать путь в лабиринте.

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

Крути опыт

В примере мы увеличивали число ста разных товаров на единичку. А проверяли сумму позже, чтобы убедиться что всё обновилось корректно.

// Политика повторов через Polly readonly RetryPolicy _concurrencyExceptionRetryPolicy = Policy .Handle<DbUpdateConcurrencyException>() .Retry( retryCount: 100, onRetry: (exceptiona, b) => { Interlocked.Increment(ref RetryCounter); }); // Обновление с использованием политики _concurrencyExceptionRetryPolicy.Execute(() => { using var db = GetDbContext(); var company = GetRandomSKU(); var value = db.WarehousesWithConcurrencyCheck .First(i => i.SKU == company); value.Amount++; db.SaveChanges(); }); // И проверка сумм примерно так public void ShowResultWithoutConcurrencyCheck() { var db = GetDbContext(); var value = db.Warehouses.Select(i => i.Amount).Sum(); Console.WriteLine($"A:{value}"); if (value != 100) Console.WriteLine("Error!!!!"); } P.S. Код не выкладывал - он не красивый и мне за него чуток стыдно :-)

Спасибо за комментарий. Мы стараемся.

Мог бы, конечно. И даже проще, чем в С++. Только сейчас как-то не до того... Но вообще было бы неплохо, конечно

@@AlexanderGranin есть класная книга Функциональное программирование на JavaScript(Луис Атенсио). Там про монады, реактивность.. но почти нету про архитектуру. Поэтому было бы круто почитать про функциональную архитектуру на JS/TS ! В Новосибирск не вернёшься?)

@@avikbox Ну в JS свои авторы, наверное, есть... В Новосибирск не вернусь в ближайшие годы, угу

😆 У Димы я в гостях, у Димы! Я когда уехал из Новосибирска, он стал единоличным владельцем подкаста. Правда, он не соглашается с этим 😄

Да, Дмитрий молодец!

Да, Екатерина прекрасна!

Отвечает Александр Гранин: а я не помню вообще... Может, у ребят спросить.

@@itchatter Когда новые ролики будут? И в тиктоке тоже ждём. Очень не хватает СТРИМОВ с автором.