Эта самая компания не знает, что кром "О большого" существует еще и "о малое", а также Ω, ω и Θ и θ. И они любят оценивать в т.ч. "О большое снизу". Гуманитарии, которые начитались про матан на хабре и довольные собой дрючат выпускников технических вузов.
Подскажите пожалуйста начал изучать Джаваскрипт учу уже где то пол года ) Думаю может я не то направление выбрал и Думаю может лучше перейти на изучение Раста . Мне 35 лет как думаете что будет лучше для меня в будущей перспективе??) Спасибо за ответ
Джаваскрипт - хорош для изучения тем что про него очень много информации. И результаты видны сразу. Раст - это уже специфический язык если кратко - "реинкарнация" C++. Какой язык изучать - сильно зависит от того, какие результаты хочется получить. Из того что очень долго остается востребованным и скорее всего еще долго будет - SQL. (А учитывая что всякие GPT очень хорошо умеют его анализировать, то изучать просто). Итого, без деталей очень сложно что-то посоветовать.
Отработает ли ConcurencyDbException если запустить конкурентное обновление не в рамках одного процесса, а в рамках двух? Например одновременно запустить 2 инстанса приложения?
Я бы рассматривал Intern как очень системную функцию для оптимизации затрат на память чего то "статического". Чего-то, что не будет меняться во время жизни приложения. А, например, для загрузки каких-нибудь однородных огромных таблиц действительно лучше реализовать свой кэш. Особенно в случае, когда когда набор строк которые хочется "закэшировать" меняется в зависимости от данных.
По настоящему проблемно слушать таких людей. Проблема не в том, что они плохо рассказывают что-то правильно или не неправильно. НЕТ! Они слишком умны и прогоняют всё через то, что они знают, как они думают. Исконно верно с их точки зрения. Но проблема не в языке как языке. Язык это инструмент и тот с которым ты лучше управляешься с всеми шероховатостями и есть Профессионализм(ОПЫТ :). Я прекрасно понимаю опыт этих дедов программирования, кто обязан был копаться в системах зараждающимися и допиливаемых ими же. Где сегодня мы просто используем то, что есть. Нельзя отрицать тот факт, что мы не готовы отказаться от того в чем заинтересованны были раньше наши деды. И чем заинтересованны мы. Поэтому, когда интерес будет сконцентрирован на стороне большинства. Будь то правые или левые. Значит Тем путём мы и пойдём. Поэтому я не согласен с тем, что бери обязательно вот этот язык или другой. Не! делай чё по кайфу - остальное призма. Всем piece ) Да и вообще вибирать инстумент не зная для чего он это глупо. Нужно понять чё ты хочешь делать, а потом уже брать набор инструментов. Все равно ты будешь брать готовый каркас приложения то есть(фреймворк). Чтобы собрать в итоге приложение. Чтобы это не было будь-то: игра сайт приложение или OC хз, что тебе интересно. А может ты чувак увлекающийся VR/Ar и (n)G сетями.
Это практически философская дилемма - использовать что-то сложное но круто подходящее или же что-то более просто, что сможет понять большее количество людей. Например, кто-то, не очень разбирающийся в хитросплетениях языка программирования может хорошо чувствовать связь приложения и бизнеса. И в этом случае сможет предложить не прогибать программу под требования и поменять требования так чтобы и бизнесу хорошо и можно было легко реализовать. Я придерживаюсь такого подхода в котором важны коммуникации. А для улучшения коммуникаций надо использовать в команде язык понятный в команде. И находить баланс между языком команды и языком "принятым" для конкретной задачи.
На самом деле системное программирование точно не для всех. Если не понимаешь модель памяти, не понимаешь многопоточность и асинхронность, или уже прости Высший Разум, руки кривые - то Rust даст только еще одного потенциального вредителя.
Согласен. А с другой стороны то, что нужно знать для системного программирования конечно. Модели памяти уже устоялись и описаны многократно и т.п. Тут уж кому как нравится. Кто-то любит оптимизировать одну функцию по году выжимая доли процентов ускорения и байты памяти экономии а кто-то требует новых задач, как только старые заработали хотя бы в виде прототипа.
Мы рады что вам нравятся наши ролики. Будем стараться делать ещё. Кстати, интересно услышать мнение о использовании мигратора. Что понравилось, что нет. Чем пользовались раньше.
@@itchatter так случилось, что на текущем проекте, куда я попал используется данный мигратор, мне нужно было с ним ознакомиться. В целом, оказалось достаточно удобно. До этого работал с Entity Framework, если говорить про .net стек. Когда работал с Java то использовал Liquibase.
Мне довелось поработать со SpecFlow и походить по граблям... Все те проблемы, о которых ты говоришь, я встречал. Гигантских размеров байндинги, несоответствие названий функций тексту, который ей соответствует, гигантские файлы с тестами. В основном это связано с тем, что за все части отвечали программисты, в том числе за сами шаги, которые в итоге превращались в названия функций. 13:40 -- обычно в таком сценарии у нас начиналось с того, что у программиста спрашивали, какие шаги есть и как писать, то есть уже нарушена ответственность. Идея с тем, что оригинальный текст преобразуется в вызовы функций -- огонь. У OpenAI есть возможность вместе с контекстом передать список функций с параметрами чтобы тот преобразовал текст в набор вызовов функций.
Я думал что сортировка временем это шутка пока не прочитал этот твит::» I just solved a modal stacking z-index issue by setting the z-index to the amount of time a user has spent on the page using the JS performance interface... thus every new modal opened has a higher z-index.« оригинал: x.com/alexjgarrett/status/1711855242290077701?s=46&t=pSUUZwB1G2U9ZdLF7-sH7Q
ты посмотри как что этот айтишник говорит. оказывается люди не идеальны и склонны совершать ошибки, так он договорится до первородного греха и ада для грешников
На практике фича Down у миграций мне ни разу не пригодилась. Лучше от её поддержки совсем отказаться, и никогда не тратить время на написание метода Down. В противном случае наступит момент, когда очередная миграция меняет данные необратимым образом, написать её откат будет физически невозможно.
Я пользовался down миграцией при отладке когда в котором миграция не только менялся таблички но и перекладывала данные. Для отладки было удобно. В реальности код который делает миграцию вниз обычно не тестируется вообще и присутствует для вида. Поэтому полностью согласен что лучше вообще отказаться от метода down чем узнать что он не работает в тот единственный момент когда он реально понадобится.
Что мне нравится в IT, так это возможность почувствовать себя джуном в новой технологии даже будучи сеньором в любой другой. Очень классно наблюдать как круто могут общаться люди студенты и "глубокие старики" и как они реально могут многому друг у друга научится.
Отлично видео! У меня тоже начинает появляться ощущение, что чем больше я погружаюсь в C++, тем меньше я знаю о нём и понимаю его.🙂🙂🙂 Хотя я ещё в самом начале на пути к коммерческой разработке.
Любопытная постановка вопроса. Всё зависит от того что понимается под хардкорностью и зачем она нужна. Если мы говорим о близости языка к машинному коду и о возможностях низкоуровневых оптимизаций то Assemler и C. Но тут надо понимать что возможность написать что-то очень быстрое это не тоже самое что написать что-то быстро. Чем выше абстракции, тем больше накладные расходы. Но что лучше, программа которая работает неоптимально но сегодня или супер оптимизированная и очень быстрая но очень сильно не сегодня. Про абстракции рекомендую: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Fu67U2px2Jo.html Если же мы говорим о возможностях кратко выражать сложные мысли то тут надо смотреть в сторону dsl и далее. Про DSL сильно рекомендую сайт tomassetti.me/ и пару видео на нашем канале ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-YSh6q5XWGy0.html и ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-YSh6q5XWGy0.html
Разверни мысль, пожалуйста. Про C++ да. Для того времени, когда все только прекратили массово пользоваться ассемблерами и когда вообще было не совсем понятно что такое программирование С++ был лучиком света. Сейчас его значение сильно уменьшилось., появились стройные и более структурированные альтернативы.
Хорошее наблюдение. И, кстати, очень похоже что да, но! Чтобы найти это самое большое число все равно надо будет перебрать все элементы, а это опять n.
Так когда мы считаем O от чего-то, то мы выкидываем все константы и все, что очень быстро отрабатывает. В данном случае скорость перебора массива явно быстрее, чем sleер с минимальным значением. Значит, самое длинное время - при самом большом элементе. Или я вообще ничего не понял и написал херню)))
Сортировка за линейное время существует, это сортировка подсчётом. Кроме того, хоть в этом алгоритме на первый взгляд и O(n) шагов, не у всех из этих шагов одинаковое время выполнения, и, вообще говоря, правильная оценка работы алгоритма это должна учитывать. Далее, какая-то часть библиотеки языка или даже операционная система должна эти таймеры в правильном порядке выполнить, а для этого значения нужно ... отсортировать, ба-думтс. Троллинг был бы удачнее, если бы вы рассказали про т.н. галактические алгоритмы.
Спасибо за содержательный комментарий. Кстати, если присмотреться то сортировка таймером и сортировка подсчетом идейно очень близки. Но с таймером гораздо веселее :-).
Примером сортировки таймером может быть, например, сортировка вагонов по номерам на горке. Спускаем вагон с горки через время равное номеру вагона в минутах. В результате получаем упорядоченный состав за n минут.
Тоже отличный видос! Я на днях сделал бегалку в консоли, ну с помощью рэйкастинга и как раз хотел сделать генератор лабиринтов. И вот щас сделал его уже по прошлому вашему видосу, работает отлично. Но часто бывает что закрывает там игрока от карты стенами или всякое такое, так что как раз попробую сделать чтоб проверяло, можно ли там такую карту пройти, и если нет, то заново ее генерировать. Правда пока не знаю как это всё реализовать, но подумаю😁
Здравствуйте. Очень интересно что имеется ввиду под "закрывает игрока", т.к. алгоритм из предыдущего примера всегда генерирует проходимый лабиринт. И было бы интересно посмотреть на то что у вас получается. Кидайте ссылки на ваши эксперименты сюда. Думаю это многим будет интересно.
@@itchatter всё, я понял в чем проблема, то ли вы не сказали в прошлом видео, то ли я прослушал. Ну в общем проблема в том, что когда у нас строится стена, полосочкой так бежит в какую - то сторону, то при столкновении с другой стеной, эта стена должна закончиться. Вот, я этого не сделал в начале, ну и простой пример закрытия игрока в таком случае, это допустим с клетки 2,2 стенка идет влево, а с клетки 4,2 стенка идет вверх. Таким образом получится, что клетка 1,1 будет изолированной.
Учу язык Rust в течении полу месяца, но столкнулся с проблемой что вакансий в моей стране мало и нету компаний которые взяли бы Джуна, требуются в основном опытные Senior программисты, и не знаю что буду делать позже когда обучусь базовыми знаниями и как искать первую работу с маленьким опытом на данном языке.Бывали моменты когда была мысль учить другой язык, но мне понравился именно Rust.В будущих перспективах собирался пойти работать где-то за границей но уже с хорошим опытом. Дайте пожалуйста пару советов.
Джунам сейчас вообще большая проблема найти работу. Раст в России почти не используют, и не будут. Идет уплощение структуры рынка, и продвинутые технологии там не нужны. Учите более популярный язык, шанс будет выше
Спасибо, отличное объяснение. Не хватает только демонстрации того как отработали решения с повторами и хинтами. Я имею в виду не бенчмарк, а суммы товаров при параллельном запуске.
// Политика повторов через 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 ! В Новосибирск не вернёшься?)
