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 Не удаляйте пожалуйста ничего с канала - материал буду пересматривать еще много раз - а копировать такой большой объем ценной информации просто невозможно
1:01:50 WebSQL нету уже. Mozilla загубила идею, выступая против и в FF так поддержку и не реализовав. Так что 3 локальных хранилища сейчас: Cookies, Local/Session Storage и IndexDB.
В первом месте работы, где я работал программистом, вся бизнес логика находилась в постгрес, node служил лишь вызваетелем процедур в оной. Это была боль. Боль без нормального дебагинга.
Вот есть три типа связываний через данные, вызов, cобытия. Топологии на 1:26:24 это примеры использования этих методов? Многослойная это вызов Шина - событие Брокер - вызов и тд Или что-то я не понял в чем смысл Можно ли совмещать эти топологии вместе?
Топологии не прибиты к типам связывания гвоздями, обычно многослойная система сделана через вызовы, но бывает и через события или данные. Конечно это все ещё имеет разницу в масштабе связывания, есть связывание внутри процесса (по сути на уровне кода и систем модульности), между процессами, и между подсистемами. Внутри процесса все три типа бывают, между процессами все, но вот через общие данные очень редко, для этого есть механизм memory mapped files, который позволяет шарить одну память между двумя процессами используя механизмы свопа операционной системы. На уровне подсистем они могут ходить в одну базу данных и быть связаны по данным, но в этом связывании на низком уровне будут вызовы и события. Так что, тут вопрос масштаба ещё важен.
Слайд "Принятие решений" (организация данных, ... надежность SLA) надо добавить: Конфигурирование (это примерно тоже самое, что "данные + связывание", но на уровне инфраструктуры, а не на уровне основных бизнес-процессов)
Это потому, что системы реального времени - это очень специфический класс систем, они занимаются управлением технологическими процессами, например в производстве или транспорте, т.е. задержка между выработкой управляющего сигнала и его исполнением может привести к тому, что процесс пойдет не так, а иногда и опасно для жизни людей, например в медицине или бортовых системах самолетов или другого транспорта. Все же системы, у которых система управления разорвана через передачу данных по интернету не могут считаться системами реального времени, а только системами с масштабом времени, приближенным к реальному.
@@cockmasterd Хоть в некоторых языках со сборкой мусора и можно ее отключить, но такие языки не подходят для реального времен, потому, что при отключенной сборке будет утекать память
@@TimurShemsedinov Но память может утекать и с GC. Какое нибудь "тяжелое" замыкание, к примеру. Да и проблема определения того, что именно считать "мусором" с точки зрения сборщика мусора никуда не делась) По тексту видео мне показалось, что вы делает акцент именно на "отсутствии" GC. Но, повторюсь, проблемы утечки памяти также применимы и к языкам с GC.
@@cockmasterd Память может утекать везде, как в языках без gc, так и с gc или при отключенном gc, главное, что в языках с gc нет механизмов ручного освобождения памяти, т.е. gc отключать для того, чтобы решать задачи реального времени практически бесполезно, а с включенным могут быть внезапные остановки на сборку. Так что, писать управление контроллером на js можно в очень ограниченном классе задач, поиграться, лампочками помигать, для серьезных вещей не катит.
