00:00:00 Когда нужна архитектура 00:06:07 Принятие решений 00:09:58 Типы связывания 00:20:00 Ошибки 00:27:15 Принятие решений 00:37:05 Эволюция архитектурных решений 00:58:13 Схема современной архитектуры 01:01:40 субд в браузере 01:05:20 Альтернативные варианты 01:12:20 Как на самом деле 01:13:45 Архитектура мечты 01:16:45 Современные возможности и требования 01:25:20 Топологии 01:30:45 Итог
43:40 - 45:48 *Следующий этап развития* Тут у вас какая то 100% каша без масла. Судите сами: с 2001 года момента появления ИЕ6, браузера который держал 98% рынка, никого не волновал клиент в браузере в том виде о котором рассказываете Вы, по причине того, что он делался благодаря ActiveX технологии полноценно работавшей в ИЕ6 которая доминировала вплоть до 2010 года. Никто даже не задумывался над фактом построения интерфейса в браузере в силу отсутствия КАКИХ ЛИБО средств с производительностью достаточной для этого. Именно потому в 96 году появляется ActiveX и именно потому в 2001 году, с выходом ИЕ6 эта технология становится стандартом дефакто в браузере на десятилетие вперед. Именно потому никто в всерьез не продвигал никаких средств развития веба в то время, потому что никто WEB браузер в этой плоскости - как вы ее описываете - и не думал рассматривать. Это было ненужно. Все задачи покрывались ActiveX компонентами. *Web 2.0* Далее, когда вы говорите о хайпе и пузыре WEB 2.0 то вероятно тут произошло наслоение двух разных событий. Никакого пузыря web 2.0 не было. По сути web 2.0 это просто набор слов, определяющий формирование контента в нем, благодаря деятельности пользователей. До этого момента, существовала монолитная позиция относительно того, что контент в ВЕБ могут делать только специалисты кокторые знают как это делать. Собственно говоря web 2.0 никуда не исчезал и то что мы наблюдаем сейчас я является примером его расцвета. Подчеркну еще раз - *ни о каких технологиях в рамках WEB 2.0 вообще речи не шло* Концепция веб 2.0 это изменение парадигмы формирования источников наполнения веба с работы специалиста, на массовую генерацию того же контента обычными пользователями. *Пузырь* Слово пузырь применялось исключительно в разрезе доткомов. Которые устроили в США истерию в промежутке между 90 и 99 годах. Истерию на базе перспектив развития маркетинга в веб, никто еще всерьез не понимал что это, мало кто видел, но поднятая истерия заставила вливать миллиарды долларов инвестиций. Именно благодаря им мы и получили Google и много чего другого. Когда в 99 году доткомы рухнули вместе с насдаком выжили сильнейшие вроде Google, которые сейчас определяют суть развития веба. *AJAX* AJAX сам по себе внезапно было доступен в 2001 году с выходом того самого ИЕ6. Только он был всем глубоко по барабану, по причине того, что не было средств построения интерфейса в браузере. И не могло быть, потому что в то время никаких ресурсов для осуществления работы интерпретируемого языка в рантайме браузера не было и быть не могло. От того ActiveX Flash SilverLight на много лет вперед разукрашивали WEB а не сам веб по себе. Тех кто знаком с этими технологиями очевидно что браузер для них это всего лишь пускалка среды. Ситуация слегка стала меняться в 2006 году, когда появились веб сокеты, и вычислительные мощности подросли до состояние когда подобие JS стало уже выполнять какую то полезную нагрузку. И кардинально меняется в 2008 году когда вдруг откуда не возьмись вылезает Google Chrome с V8 производящий революцию в WEB. Среда которую представили в Google на порядки оказалась быстрее всего что было до этого. А с 2010 года полноценную реализацию WS и XMLHTTP2. До этого момента, никто вообще не мог рассматривать браузер как некоторую платформу для построения интерфейса и тем более бизнес логики. Не было никаких оснований для этого. *Отдельно о AJAX и производительности* AJAX (а если быть корректным то XMLHTTP) с момента своего появления всегда было *как первое средство для снижения нагрузки* Каким образом в вашей интерпретации получилось наоборот я ума не приложу. Тут даже в программировании разбираться не нужно чтобы сделать вывод. От этого я допускаю, что аргументируя таким образом вы имели ввиду нечто иное, чем просто функционирование AJAX в браузере. И в догонку стоит добавить то, что вы упускаете. В 2010 году только 30% населения имело хоть какойто доступ к интернет. А в 2001 не более 10%. Это максимальный потенциальный рынок который мог бы дать средства на что-то в браузере. И именно эти средства и играют роль в развитии браузера как среды для решения всего на свете. Кроме этого, до 2017 года в языке отсутствовали в принципе какие либо средства для работы с внешними устройствами. Что автоматически ставило крест на использование платформы в любой серьезной системе где безопасность имеет значение.
@@TimurShemsedinov Не удаляйте пожалуйста ничего с канала - материал буду пересматривать еще много раз - а копировать такой большой объем ценной информации просто невозможно
Слайд "Принятие решений" (организация данных, ... надежность SLA) надо добавить: Конфигурирование (это примерно тоже самое, что "данные + связывание", но на уровне инфраструктуры, а не на уровне основных бизнес-процессов)
1:01:50 WebSQL нету уже. Mozilla загубила идею, выступая против и в FF так поддержку и не реализовав. Так что 3 локальных хранилища сейчас: Cookies, Local/Session Storage и IndexDB.
Вот есть три типа связываний через данные, вызов, cобытия. Топологии на 1:26:24 это примеры использования этих методов? Многослойная это вызов Шина - событие Брокер - вызов и тд Или что-то я не понял в чем смысл Можно ли совмещать эти топологии вместе?
Топологии не прибиты к типам связывания гвоздями, обычно многослойная система сделана через вызовы, но бывает и через события или данные. Конечно это все ещё имеет разницу в масштабе связывания, есть связывание внутри процесса (по сути на уровне кода и систем модульности), между процессами, и между подсистемами. Внутри процесса все три типа бывают, между процессами все, но вот через общие данные очень редко, для этого есть механизм memory mapped files, который позволяет шарить одну память между двумя процессами используя механизмы свопа операционной системы. На уровне подсистем они могут ходить в одну базу данных и быть связаны по данным, но в этом связывании на низком уровне будут вызовы и события. Так что, тут вопрос масштаба ещё важен.
В первом месте работы, где я работал программистом, вся бизнес логика находилась в постгрес, node служил лишь вызваетелем процедур в оной. Это была боль. Боль без нормального дебагинга.
Это потому, что системы реального времени - это очень специфический класс систем, они занимаются управлением технологическими процессами, например в производстве или транспорте, т.е. задержка между выработкой управляющего сигнала и его исполнением может привести к тому, что процесс пойдет не так, а иногда и опасно для жизни людей, например в медицине или бортовых системах самолетов или другого транспорта. Все же системы, у которых система управления разорвана через передачу данных по интернету не могут считаться системами реального времени, а только системами с масштабом времени, приближенным к реальному.
@@cockmasterd Хоть в некоторых языках со сборкой мусора и можно ее отключить, но такие языки не подходят для реального времен, потому, что при отключенной сборке будет утекать память
@@TimurShemsedinov Но память может утекать и с GC. Какое нибудь "тяжелое" замыкание, к примеру. Да и проблема определения того, что именно считать "мусором" с точки зрения сборщика мусора никуда не делась) По тексту видео мне показалось, что вы делает акцент именно на "отсутствии" GC. Но, повторюсь, проблемы утечки памяти также применимы и к языкам с GC.
@@cockmasterd Память может утекать везде, как в языках без gc, так и с gc или при отключенном gc, главное, что в языках с gc нет механизмов ручного освобождения памяти, т.е. gc отключать для того, чтобы решать задачи реального времени практически бесполезно, а с включенным могут быть внезапные остановки на сборку. Так что, писать управление контроллером на js можно в очень ограниченном классе задач, поиграться, лампочками помигать, для серьезных вещей не катит.
00:00:00 Когда нужна архитектура
00:06:07 Принятие решений
00:09:58 Типы связывания
00:20:00 Ошибки
00:27:15 Принятие решений
00:37:05 Эволюция архитектурных решений
00:58:13 Схема современной архитектуры
01:01:40 субд в браузере
01:05:20 Альтернативные варианты
01:12:20 Как на самом деле
01:13:45 Архитектура мечты
01:16:45 Современные возможности и требования
01:25:20 Топологии
01:30:45 Итог
43:40 - 45:48 *Следующий этап развития*
Тут у вас какая то 100% каша без масла. Судите сами:
с 2001 года момента появления ИЕ6, браузера который держал 98% рынка, никого
не волновал клиент в браузере в том виде о котором рассказываете Вы, по причине
того, что он делался благодаря ActiveX технологии полноценно работавшей в ИЕ6
которая доминировала вплоть до 2010 года.
Никто даже не задумывался над фактом построения интерфейса в браузере в силу
отсутствия КАКИХ ЛИБО средств с производительностью достаточной для этого.
Именно потому в 96 году появляется ActiveX и именно потому в 2001 году, с выходом ИЕ6 эта технология
становится стандартом дефакто в браузере на десятилетие вперед.
Именно потому никто в всерьез не продвигал никаких средств развития веба в то время,
потому что никто WEB браузер в этой плоскости - как вы ее описываете - и не думал рассматривать.
Это было ненужно. Все задачи покрывались ActiveX компонентами.
*Web 2.0*
Далее, когда вы говорите о хайпе и пузыре WEB 2.0 то вероятно тут произошло
наслоение двух разных событий. Никакого пузыря web 2.0 не было. По сути web
2.0 это просто набор слов, определяющий формирование контента в нем, благодаря
деятельности пользователей.
До этого момента, существовала монолитная позиция относительно того, что контент в ВЕБ
могут делать только специалисты кокторые знают как это делать.
Собственно говоря web 2.0 никуда не исчезал и то что мы наблюдаем сейчас я
является примером его расцвета. Подчеркну еще раз -
*ни о каких технологиях в рамках WEB 2.0 вообще речи не шло*
Концепция веб 2.0 это изменение парадигмы формирования источников наполнения веба
с работы специалиста, на массовую генерацию того же контента обычными пользователями.
*Пузырь*
Слово пузырь применялось исключительно в разрезе доткомов. Которые устроили в
США истерию в промежутке между 90 и 99 годах. Истерию на базе перспектив
развития маркетинга в веб, никто еще всерьез не понимал что это, мало кто
видел, но поднятая истерия заставила вливать миллиарды долларов инвестиций.
Именно благодаря им мы и получили Google и много чего другого. Когда в
99 году доткомы рухнули вместе с насдаком выжили сильнейшие вроде Google,
которые сейчас определяют суть развития веба.
*AJAX*
AJAX сам по себе внезапно было доступен в 2001 году с выходом того
самого ИЕ6. Только он был всем глубоко по барабану, по причине того, что не
было средств построения интерфейса в браузере. И не могло быть, потому что в то
время никаких ресурсов для осуществления работы интерпретируемого языка в
рантайме браузера не было и быть не могло.
От того ActiveX Flash SilverLight на много лет вперед разукрашивали WEB
а не сам веб по себе.
Тех кто знаком с этими технологиями очевидно что браузер для них
это всего лишь пускалка среды.
Ситуация слегка стала меняться в 2006 году, когда появились веб сокеты, и
вычислительные мощности подросли до состояние когда подобие JS стало уже
выполнять какую то полезную нагрузку. И кардинально меняется в 2008 году когда
вдруг откуда не возьмись вылезает Google Chrome с V8 производящий революцию в
WEB. Среда которую представили в Google на порядки оказалась быстрее всего что
было до этого. А с 2010 года полноценную реализацию WS и XMLHTTP2.
До этого момента, никто вообще не мог рассматривать браузер как некоторую
платформу для построения интерфейса и тем более бизнес логики. Не было никаких
оснований для этого.
*Отдельно о AJAX и производительности*
AJAX (а если быть корректным то XMLHTTP) с момента своего появления всегда было
*как первое средство для снижения нагрузки*
Каким образом в вашей интерпретации получилось наоборот я ума не приложу.
Тут даже в программировании разбираться не нужно чтобы сделать вывод.
От этого я допускаю, что аргументируя таким образом вы имели ввиду нечто иное, чем просто
функционирование AJAX в браузере.
И в догонку стоит добавить то, что вы упускаете.
В 2010 году только 30% населения имело хоть какойто доступ к интернет.
А в 2001 не более 10%. Это максимальный потенциальный рынок
который мог бы дать средства на что-то в браузере. И именно
эти средства и играют роль в развитии браузера как среды для решения всего на свете.
Кроме этого, до 2017 года в языке отсутствовали в принципе какие либо
средства для работы с внешними устройствами. Что автоматически ставило крест на
использование платформы в любой серьезной системе где безопасность имеет
значение.
Интересно
Спасибо, очень интересная лекция.
Очень полезные лекции. Только ценность их понимается, когда уже отработал 2 года
Я думаю, что со следующего года что-то попроще сделаю
@@TimurShemsedinov не надо. Давайте по хардкору.)
@@TimurShemsedinov Не удаляйте пожалуйста ничего с канала - материал буду пересматривать еще много раз - а копировать такой большой объем ценной информации просто невозможно
@@legioner9mix та вроде не удалял никогда, только пару раз перезаливал в лучшем качестве
минимум 2 года ))
Слайд "Принятие решений" (организация данных, ... надежность SLA) надо добавить: Конфигурирование (это примерно тоже самое, что "данные + связывание", но на уровне инфраструктуры, а не на уровне основных бизнес-процессов)
1:01:50 WebSQL нету уже. Mozilla загубила идею, выступая против и в FF так поддержку и не реализовав. Так что 3 локальных хранилища сейчас: Cookies, Local/Session Storage и IndexDB.
Pipeline -- конвейер
Вот есть три типа связываний через данные, вызов, cобытия.
Топологии на 1:26:24 это примеры использования этих методов?
Многослойная это вызов
Шина - событие
Брокер - вызов
и тд
Или что-то я не понял в чем смысл
Можно ли совмещать эти топологии вместе?
Топологии не прибиты к типам связывания гвоздями, обычно многослойная система сделана через вызовы, но бывает и через события или данные. Конечно это все ещё имеет разницу в масштабе связывания, есть связывание внутри процесса (по сути на уровне кода и систем модульности), между процессами, и между подсистемами. Внутри процесса все три типа бывают, между процессами все, но вот через общие данные очень редко, для этого есть механизм memory mapped files, который позволяет шарить одну память между двумя процессами используя механизмы свопа операционной системы. На уровне подсистем они могут ходить в одну базу данных и быть связаны по данным, но в этом связывании на низком уровне будут вызовы и события. Так что, тут вопрос масштаба ещё важен.
@@TimurShemsedinov, можете посоветовать посмотреть или почитать, что-то по топологиям.
@@Wra-ij8yk Особо нечего посоветовать (
В первом месте работы, где я работал программистом, вся бизнес логика находилась в постгрес, node служил лишь вызваетелем процедур в оной. Это была боль. Боль без нормального дебагинга.
Линукс Торвальдс сказал - «Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структуры данных и их отношения ».
Линус Линуксович
Были б такие лекции лет 10 назад, мне бы пришлось меньше страдать в свое время.
Pipeline вполне традиционно переводится как конвейер
Точно, спасибо
Трубопровод, система подачи. Конвейер это conveyor
@@oranjevoeN в контексте софта - конвеер
огромное спасибо за полезный материал, самый раз для вкатывания в тему архитектуры.
Очень интересная лекция, благодарю. Узнала для себя все новое.
С юмором у Вас все хорошо. Вставки супер!
Спасибо!
Может попросить студентов "вытянуть" звук на этих видео и перезалить потом?
На этих видео норм звук, есть пару видео с плохим, но не это
Тут первые пару секунд глюки
Спасибо за лекцию!
приятно слышать человека который знает о чём говорит
А вы чисто JavaScript программист?
За 25 лет программирования я уже столько языков и технологических стеков использовал, что боюсь, что даже не все могу быстро вспомнить...
Привет, хорошие лекции! Спасибо. А можно найти их в текстовом виде? Может что то в роде блога?
Нет, только сами лекции, которые можно посещать и видео, выкладываются в тот же день
@@TimurShemsedinov Здравствуйте, хотелось бы узнать график проведения лекций и семинаров, если они еще проводятся. Хочу посещать.
@@lionking4454 На следующий семестр расписание еще не готово, но оно будет скоро. Следите за каналами: t.me/HowProgrammingWorks и t.me/metarhia
@@TimurShemsedinov Понял, спасибо.
53
Such much?
Спасибо!
Полезная и интересная лекция.
Спасибо! Было полезно!
🔥🔥🔥
слишком подробно уходит автор в тематику несвязанной с видео, звук мешает воспринимать
не стал смотреть видео из-за ужасной записи голоса
На 1:14:50 вы говорите, что для систем реального времени подходят только языки без Garbage Collection. Почему? Расскажите подробнее.
Это потому, что системы реального времени - это очень специфический класс систем, они занимаются управлением технологическими процессами, например в производстве или транспорте, т.е. задержка между выработкой управляющего сигнала и его исполнением может привести к тому, что процесс пойдет не так, а иногда и опасно для жизни людей, например в медицине или бортовых системах самолетов или другого транспорта. Все же системы, у которых система управления разорвана через передачу данных по интернету не могут считаться системами реального времени, а только системами с масштабом времени, приближенным к реальному.
@@TimurShemsedinov но как такому классу систем может помешать ЯП со "сборкой мусора"?
@@cockmasterd Хоть в некоторых языках со сборкой мусора и можно ее отключить, но такие языки не подходят для реального времен, потому, что при отключенной сборке будет утекать память
@@TimurShemsedinov Но память может утекать и с GC. Какое нибудь "тяжелое" замыкание, к примеру. Да и проблема определения того, что именно считать "мусором" с точки зрения сборщика мусора никуда не делась) По тексту видео мне показалось, что вы делает акцент именно на "отсутствии" GC. Но, повторюсь, проблемы утечки памяти также применимы и к языкам с GC.
@@cockmasterd Память может утекать везде, как в языках без gc, так и с gc или при отключенном gc, главное, что в языках с gc нет механизмов ручного освобождения памяти, т.е. gc отключать для того, чтобы решать задачи реального времени практически бесполезно, а с включенным могут быть внезапные остановки на сборку. Так что, писать управление контроллером на js можно в очень ограниченном классе задач, поиграться, лампочками помигать, для серьезных вещей не катит.