Видео

ппц как буду ждать второй доклад

понравилось. всё по делу. кратко и четко. и главное ПОЛЕЗНО

У Рустама отличные лекции

Ужасно Ужасно Ужасно... 23мин. "...и вот, удивительная вещь, измерительный прибор, странным образом, влияет на волновую функцию...." Тоесть, совокупность материальных тел, собранных в некоторой последовательности, и обладающая вследствии этого и замысла создателя, набором свойств, ВЫЗЫВАЕТ КОЛЛАПС НЕ МАТЕРИАЛЬНОГО ТЕЛА, А НАБОРА СИМВОЛОВ на доске или в тетради. Это" клиника", ребята

Вообще ничего не понятно, но так убедительно!... Не пускайте его в политику, иначе будете голосовать за всё, что он предложит то:)

Спикер реально хорош! Читаю его на Хабре.

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

Рустам, спасибо!! Было бы здорово увидеть материал, не вошедший в доклад)

Такая себе критика, особенно про статические классы. Код нужно организовывать, если понятие Class использовать как некий namespace то че париться, надо просто правильно обозначать сам класс. Чтобы компилятор не ломал себе голову созданием конструктора/деструктора.

Не помнимаю хейта систем дизайна на интервью - это на порядки проще по трудозатратам чем алгосы, т.к. как минимум там нельзя ничего проверить, а значит, можно лить много воды 😊. Прочитай пару книг по теме по диагонали как художественную литературу. Потом на собесе просто вываливай всю инфу по ключевым словам из головы, рисуй квадратики, стрелочки. Кароче представь себя ChatGPT ...или студентом-экономистом, пишущим диплом 😅.

Смотрите следующую часть доклада Александра - ruclips.net/video/092UL69hQd0/видео.html

Смотрите предыдущую часть доклада Александра - ruclips.net/video/UZbPOtEgcoY/видео.html

Мне кажется, темную энергию надо искать где-то рядом с Алексеем :))) Спасибо за лекцию!

Такой долбоёбнынуй комментатор, что проще на хер послать.

По сути он предлагает процедурное программирование на манер ООП. То, что раньше было статическими функциями, теперь оборачиваем классами и гордо называем ООП.

Аймэдж, как айфон что ли? А ю сириес? Образ (имадж) уже не подходят?

Какой доктор)) не знающие основных законов в физике доктора уже?)) Болтун это)

Хехе, но теперь же надо переписать еще и без synchronized который плохо дружит с виртуальными тредами )

Спасибо! В том числе и за доказательство, что волновая функция не линейна. Мечта Шрёдингера работала бы, если бы конусы из его уравнения все время были симметричными,т е их срезы давали бы строго равнобедренные треугольники

Господь Бог создал абсолютно пустое трехмерное пространство и материю в виде фундаментально элементарных неделимых частиц-неоатомов с определенными свойствами. Все остальное- процесс самоорганизации,в т.ч. и образование физического вакуума,структурными частицами которого также являются неоатомы. Это основа и релятивистской квантовой гравитации.

Квантов не существует иди... Ы! Как и времени

❤❤❤

Что за чушь про AT&T-синтаксис на 16:30, что на армах дефолтный синтаксис аналогичен интеловскому, что у RISC-V даже, Алексей под другими архитектурами что ли PDP-11 понимает

ничего не понятно, но очень интересно

Ну теперь я знаю ответ на вопрос, а есть ли гопники программисты или программисты гопники, в смысле быдло инженеры 😂 вообще конечно ужасно...

Очень полезный доклад, отлично!

8:33 жена Шредингера, то ли с тобой то ли не с тобой, квантовая на всю голову.

Насчёт знаков зодиака вот не понял, нужно смотреть знаки зодиака - разрабов и девопсов ? Апликухи ? Тимлида ? )))

config server - это хорошо, но далеко не всегда все микросервисы нуждаются в одной настройке, которую можно вынести на root level, и из-за этого код либо все равно дублируется либо в каком-то сервисе появятся не используемые проперти. Мы тоже используем эту фичу, но пошли немного дальше и добавили profiles. К примеру, при добавлении профиля kafka подключается application-kafka.yml, а для БД application-db.yml, итд.

Программный комитет удаляет комментарии с конструктивной критикой, как же это низко

идея ясна но 90% советов полная дичь( удачи в разработке по таким советам, ничего больше чем пет проджект с классами типа File не напишешь. интересно, а автор пробовал в энтерпрайз разработку по таким правилам?

Какой же плохой звук, Ну вот серьёзно, можно купить за 5к нормальный микрофон, нормальные наушники, это же ваш рабочий инструмент. Прошу, это такие копейки на фоне тем которые вы обсуждаете.

1. Если конфиг действительно может быть мало связан с релизом, то зачем нам новая верстя DB, без новой версии кода, эти изменения использующих? (за редким исключением). 2. Более сложная проблема - откат изменений в DB при откате релиза совсем не поднята. 3. Продакшин-Конфиг и общем репозитории/общем сервисе?! Далеко не всегда это возможно!

Ведущий очень слабый! Алексей -мега крут!

Докладчик немного газлайтит насчет «нового релиза». Мы просто поправили конфиг, мы просто накатили патч на базу. Разве это новые релизы, вопрошает он? 🤣

Вижу Семихатова - ставлю лайк! Как всегда - офгигенно!

Спасибо за доклад!

По поводу потенциальных проблем при обновлении пропертей через Spring Cloud Data: В зависимости от того как определён @ConfigurationProperties класс, спринг может использовать один из двух подходов: - Если в @ConfigurationProperties классе нет ни одного final поля, то Spring будет обновлять значения в инстансе напрямую через рефлекшен и сеттеры. Никакого пересоздания бинов в таком случае не будет, запросы продолжат обрабатываться как прежде - Если в @ConfigurationProperties классе есть хотя бы одно final поле, то будет использоваться Constructor Binding. В таком случае единственный способ обновить значения полей - это пересоздать бин с пропертями с нуля. Это в свою очередь триггерит пересоздание всех бинов которые автовайрят эти проперти, и бинов которые автовайрят бины которые были пересозданные на предыдущем шаге и т.д. Насколько мне известно, в таком случае спринг просто прекращает принимать новые запросы пока все затронутые бины не пересоздадутся Но есть потенциальные проблемы когда используется смесь этих подходов. Например, вложенные проперти классы где родительский класс использует Constructor binding, а вложенное проперти - нет. Или когда часть полей в классе устанавливаются через Constructor Binding, а часть - через рефлекшен и сеттеры. В некоторых случаях спринг говорит что проперти обновились, но по факту продолжает использовать старые значения. Приходится долго и муторно отлаживать и искать какой из вложенных проперти классов виноват. С другой стороны, если ситуация обратна (родительский класс НЕ использует Constructor binding, а вложенное проперти - использует), то тогда вложенное проперти будет пересоздано, но родительское проперти - нет. Спринг просто вызовет сеттер у родительского проперти с новым значением. Это можно использовать для атомарного обновления связанных пропертей. Для примера, адрес и порт прокси сервера - эти два значения всегда должны быть консистентны. Мы хотим избежать ситуаций когда мы прочитали адрес старого прокси сервера и порт нового прокси сервера. Если вынести эти два проперти в @NestedProperty и использовать Constructor Binding для них, а при чтении сначала скопировать объект в отдельную переменную (var proxySettings = someProperty.getProxy(); var address = proxySettings.getAddress(); var port = proxySettings.getPort();), то эти два значения всегда будут консистентны друг с другом Потенциальные проблемы вызванные самим фактом изменения пропертей наживую: - Если проперти копируется при создании бина, то его практически не возможно обновить наживую. Например - проперти используется как параметр конструктора бина, или когда мы создаём бин, а потом через сеттер прокидываем значение из проперти. При попытке обновить такое проперти через клауд конфиг Спринг обновит это значение в @ConfigurationProperties классе, но в бине останется старое значение. Нужно как-то вручную пересоздавать этот бин - Неконсистентность данных когда одно и то же проперти читается много раз во время обработки запроса. Например, какой-нибудь коэффициент для расчёта/размер налога/т.д. В таком случае есть вероятность что при первом чтении проперти вернёт одно значение, а при втором чтении при обработке того же самого запроса - другое значение - Насколько мне известно, значения автовайренные через Spring Expression Language (@Value, @Scheduled, etc) обновить таким способом нельзя - Выставление невалидных значений. Например, если над классом стоит аннотация @Validated, и одно из полей проаннотировано как @Min(1). Если мы случайно выставим в проперти "0", то Спринг пересоздаст бин, проавтовайрит его куда нужно, а потом выкинет ошибку что новое значение не прошло валидацию и перестанет обрабатывать запросы В общем, с одной стороны это полезный инструмент, особенно для всяких экстренных операций. Но с другой стороны с ним очень много подводных камней. Если решите использовать его, то советую обмазаться как можно бОльшим количеством проверок, и тщательно следить какие проперти можно обновлять, а какие нет. Возможно даже стоит разделить эти проперти по разным application.yaml файлам

Спасибо за доклад. Побуду бабой-ягой: 1. Изменение настроек в проде - это, по сути, релиз. Если вы не фиксируете изменение в репозитории, то вы забудете о том, что меняли руками, и следующим деплоем затрете эти изменения. Не говоря уже о том, что каждый релиз должен быть протестирован. 2. Насчет 12 factors: там пропагандируется конфигурация через переменные окружения, как не завязанный на стек способ конфигурации. И спринг это поддерживает из коробки. 3. Запускать миграции как шаг запуска спринг-бута безопаснее: каждая версия вашего сервиса знает о том, какие миграции ей нужны, и она никогда не запустится, пока миграции не накатились. Мы используем flyway таким образом успешно много лет. Вынося миграции отдельным шагом вы не только усложняете пайплайн, но и рискуете однажды запустить образ, для которого миграции не накачены. 4. стоило сказать про обратную совместимость миграций как обязательное правило. После накатывания миграций новой версии, старая должна продолжать работать корректно с обновленной БД. Иначе у вас поломается RollingUpdate

32:00 Про liquibase не убедительные примеры вначале. Всё-таки это версионирование БД, а не инструмент запустить какой-то в моменте нужный sql. Если это справочник, то он должен стоять за api для того, кто этим справочником распоряжается.

null - нАл

Разум - ошибка природы. Человек тому подтверждение.

Супер информативно, спасибо большое!!!

От примеров с казино ловлю флешбэки)

Спасибо за крутой материал! Взял на заметку идею оптимизации образа с помощью слоев, которые предоставляет спринг.

Квантовая Механика, как и другие разделы Физики это один из способов описания происходящих процессов. Физика и Квантовая механика ни чего не объясняет и не должна объяснять. Она просто предлагает адекватную описательную модель с помощью математики.

Фундаментальная ошибка докладчика. Он выделяет измерения в некое особенное явление, а измерение это тоже обычное взаимодействие объектов.

Нет ни чего странного и необычного в квантовой модели. Обычная теория вероятностей и дискретная математика.

Нужен огород для выращивания волновых функций. Почем за десяток.

Квантовую механику никто не понимает, поэтому трактует так, чтобы было интересно слушать.