А потом надоело. Захотелось, знаете ли, что-нибудь полезное сделать, а не только вокруг циркулярки прыгать всё время. Да и годная пила внезапно подвернулась, за все $200. :) Вот приведя её в порядок и попробовав, я и понял, почему очень многие более опытные товарищи прямо говорят: не занимайтесь онанизмом, копите деньги на хороший инструмент.
В моем самодельном циркулярном столе есть пазы. И в предыдущем были. И в предыдущем предыдущего. Я их выточил сам. Уверяю вас, что точность этого сетапа как минимум не ниже, чем у любого станка до 100 тыр ценой — я пробовал многие. В том числе — безусловно лучше, чем упомянутый выше Корвет…
Мгм. Вы знаете, я никак не хочу оскорбить вас недоверием, но в данном случае вынужден. Потому как имея опыт работы и с ручным инструментом, и с хламчинским дешёвым электрическим, я таки представляю себе сложности, с этим связанные. Да что далеко ходить, даже фанеру отрезать ровно и перпендикулярно строительной циркуляркой нифига не так просто, как об этом в йутубе показывают. Так что, можно фото ваших самодельных станков в студию?
Ну а уж про шину и вовсе разговора нет никакого… Это первое, что делает любой, строящий стол. Это элементарно, вопрос в точности (хоть она особо большая там и не нужна). А уж имея одну, сделать другую получше — это вообще не вопрос.
Вот это меня настораживает ещё больше, как и дальнейшие упоминания йутубов и серьёзных людей с серьёзными проектами. Вы уверены, что на самом деле пробовали что-нибудь руками делать, а не просто видосики смотрели?
И вообще, помню книжку по столярному делу годов эдак 50х — в школе читал на трудах… На самой первой странице было написано что-то вроде: «Хочешь называться столяром? Сделай себе верстак!» по полной — с тисками, сборочной поверхностью, etc.
Угу. Вот похоже, что мсье как раз по книжкам только и мастер. Я уже три верстака построил и четвёртый собираюсь делать, теперь уже правильный наконец. С учётом опыта предыдущих и понимания, что мне нужно, а что нет.
в сети вагон видосов, как сделать из дешевой циркулярки (3-4 тыр) пильный стол, который, кстати, чудно заменяет как торцовку, так и любые фабричные девайсы за минимум 30 тыр.
Я этот квест проходил (сейчас на 4-м циркулярном станке). Дешёвая циркулярка ни разу не заменит стационарный циркулярный стол. Основных причины три:
а) В стационарном станке есть направляющие пазы (miter slots), выточенные в чугунии с высокой точностью. По этим пазам ездят все приспособы, и от этих пазов напрямую зависит, что у вас будет получаться на станке. Так вот, у дешёвых пластиковых циркулярок этих пазов либо вообще нет, либо использовать их толком не получится из-за формы и конструкции. Для грубого торцевания досок на стройке подходит, для чего-то более амбициозного никак. Я проверял.
б) Из пункта а) вытекает следущий: наличие пазов это одно, а точность их ориентировки относительно лезвия это совсем другое. Циркулярных станков бывает много разных типов, и регулируются они по-разному: лёгкие (jobsite saw) вообще толком не регулируются, у более тяжёлых портативных механизм привешен к чугуниевому столу снизу, у стационарных механизм крепится к шкафу (станине), а стол просто лежит сверху.
Так вот, нормально отрегулировать можно только последний тип. Я уже через все проходил, и на все потратил уйму времени, прыгая вокруг с микрометром. Только стационарный держит настройку и не съезжает со временем от вибрации. Все портативные (вкл. тяжёлые) разрегулируются очень быстро, и начинаются проблемы.
в) Кроме пазов, огромную роль играет также продольная направляющая (fence). От неё напрямую зависит не только, сможете ли вы получить на выходе деталь, отрезанную точно по размерам, но и качество распила, и безопасность операции. Например, хорошо отрегулированная Т-образная направляющая типа Biesemeyer позволяет обойтись без фуговки при склеивании массива. Нет, не шучу, проверял многократно: отфуговал с одной стороны, отрезал с противоположной, можно склеивать.
Так вот, все эти штуки просто так из говна и палок не сделаешь. Если направляющую ещё можно попробовать самому сделать (в теории), то вот сам станок не получится. Другие инструменты можно подумать, но циркулярный станок… Лучше это время и силы потратить на практику с ручными инструментами.
Перед тем, как проделывать операцию, остановитесь и подумайте, что и как куда идёт. Целее будете.
Распускать доски с помощью ручной циркулярки это, мягко скажем, не самое безопасное занятие. На стационарном станке тоже не 100%, но при наличии защитного кожуха и riving knife (не знаю, как по-русски называется) гораздо меньше шансов создать себе проблемы.
Фуговальные станки очень опасны, не надо их недооценивать. Особенно ваш, доставшийся от деда: я не вижу на нём защитной крышки над лезвиями. Очень надеюсь, что крышка есть и вы её просто временно сняли ради сделать фотографию, и никогда (никогда!) не используете станок без неё. И руками заготовку не держите, а используете прижимы типа таких:
Из практики: торцовочная пила это не must have, особенно для столярных дел. Это плотницкий инструмент, для грубого торцевания. Я тоже начал строительство мастерской с торцовочной пилы, а теперь она висит на стене гаража без дела. Сколько вокруг этой пилы ни прыгай, точность у неё никакая (если, конечно, это не Festool Kapex стоимостью в пол-самолёта) — особенно когда надо стыки под 45 градусов делать, для рамок, коробок и проч. Для торцевания и угловых отрезов гораздо лучше работают специализированные приспособы на базе стационарной циркулярки: погуглите cross-cut sled, miter sled и всё станет понятно.
Я вообще пришёл к выводу, что единственно нужный в мастерской хороший станок — это стационарная чугуниевая циркулярка. Один раз её настроить, отъюстировать с микрометром, сделать пару дополнений и дальше можно не задумываться о допусках, корректности углов и зазорах при сборке деталей.
Правда, хорошая чугуниевая циркулярка стоит некисло денег (новая), а б/у если и находятся, то обычно в печальном состоянии. Но! Если не бояться трудностей, то можно разобрать такой станок, восстановить, почистить от ржавчины, смазать и собрать обратно лучше, чем было. За относительно немного денег можно получить в своё пользование очень годный индустриальный станок.
Но тут есть ньюанс… (с) Если таких трудностей не бояться, то процесс имеет свойство затягивать хуже героина. Я так радовался, когда по дешёвке урвал сверлильный станок 40-х годов! Сейчас как восстановлю, как пользоваться начну!.. Восстановил… Начал… Теперь в работе 60-х годов циркулярка, 50-х годов большой стационарный фрезер, 40-х годов фуганок, 50-х годов токарный станок, ну, вы понимаете… Времени по дереву уже почти не остаётся, зато приходится осваивать работу по металлу, финиширование, покраску, полировку, электрику… Но когда закончу! :)
Именно. Вы примеряете этот диалог на себя в позиции собеседуемого в типичной ролевой игре, описанной в начале статьи. Это когда собеседующий — "строгий профессор", а вы "студент-раздолбай" на зачёте, потеете в ожидании каверзных вопросов с целью завалить.
Автор же ищет пути этой ситуации избежать и беседовать с кандидатом на равных, как человек с человеком. Может, не идеально ищет, но сам факт.
Отлично читается, по-моему, и существенно компактнее простыней if/elsif/else. Очень подходит для определённого рода ситуаций, когда switch не подходит (или отсутствует, хе-хе), а синтаксис if/elsif займёт больше места, чем собственно условия и присвоения. И если ещё условие нужно будет добавить, то не надо переформатировать, просто строку вставить.
Ну т.е. полная вкусовщина конечно, но мне нравится.
Вы какой код хотите посмотреть, вышеупомянутого фреймворка? Вот здесь можно подписаться на пробную версию, скачать архив и посмотреть код. Лучше подписываться с одноразового емаела, чтобы потом моск не выклевали на тему купить. Это не я придумал. :(
Если интересно, как вся эта кухня тестируется, то вот статейка с бла-бла по верхам, ну и там же ссылка на код оркестратора. Сами юнит-тесты идут в архиве с фреймворком.
Да мне в общем-то всё равно, как он выглядит. Более ёмкий синтаксис и type inference помогают сократить boilerplate, но развесистая клюква дерева типов никуда не денется, со всеми накладными расходами.
Для сторонников статической типизации вообще типично начинать проектирование системы с раскладывания по полочкам типов, их взаимосвязей, наследования, интерфейсов, и прочего из отдела "как должно выглядеть, чтоб красиво". Что вполне противоречит набитому кровавыми шишками принципу YAGNI...
В Idea это уже давно есть. Работает из рук вон плохо по сравнение с TS.
Возможно, я не пробовал. Мне такой механизм представляется мало ценным, на практике случаи, когда функция должна принимать на вход ограниченный набор строк, относительно редки. Ну т.е. когда у вас весь код уже закрыт тестами и вылизан, можно закрутить ещё одну гайку, отчего ж нет. Только вот на практике обычно получается, что вот эти вот малозначительные вещи выдвигаются на передний план под соусом "а так тесты писать не надо!"
Всё отлично поддерживается. Даже подсказки в IDE работают.
Речь не о подсказках, а о когнитивной нагрузке и расходах на проектирование/поддержку. Только не надо мне рассказывать о том, что всё это бесплатно и просто само по себе работает. Я слишком старый уже, чтобы в Деда Мороза верить.
Это дырявый инструмент. Проверяется проверяются несколько значений из бесчисленного множества.
У него покрытие этих видов дефектов по определению больше, чем возможно при тестировании. Так что он не может быть дополнением. Это тесты — жалкая замена.
Вот там внизу товарищ dimm_ddr уже по теории высказался, а я как человек практический скажу так: вы можете сколько угодно гоняться за своей красной селёдкой идеального кода без дефектов, а мне надо работу работать.
Ещё раз: спорить с тем, что строгая статическая типизация позволяет избежать целого класса дефектов в коде, бессмысленно. Речь вовсе не об этом, а о том, что всё в этом мире не бесплатно, и за устранение этого класса дефектов приходится платить строгостью и статической типизацией. В теории всё отлично: избегаем X дефектов, платим за это Y человеко-часами.
А теперь внимание, правильный ответ: на практике этот самый класс дефектов оказывается мелкой точкой на радаре, незаметной в фоновом шуме. А вот Y человеко-часов затрат никуда не деваются. И по прошествии времени в сколько-нибудь заметном проекте число Y увеличивается многократно. При стабильно минимальном возврате.
Идём дальше: насколько мне известно, единственный практически работающий способ обеспечить качество кода это автоматизированное тестирование, что, кстати, подтверждается наличием научных исследований на эту тему. А дальше возникает сакраментальный вопрос: если тесты писать по-любому надо качество кода статическая типизация не спасает, то нахрена козе баян зачем нужны танталовы муки с этой самой статической типизацией?
Ну вот как бы не сюрприз, что к похожим выводам некоторые крайне умные и очень опытные люди пришли ещё в конце 50-х. LISP наше всё, да.
Судя по вопросу вы никогда не программировали на языках со статической типизацией. Попробуйте, увидите мир с совершенно другой стороны.
Отчего же, программировал и довольно много. Правда, давно уже, поэтому деталей не упомню, а вот лютая, бешеная отрыжка на развесистые деревья типов и простыни UML-диаграмм осталась. Видеть всё это ещё раз совершенно не хочется, спасибо.
function(p) {
p.fooo; // ESLint тут бесполезен
p.foo = 'baaar'; // То же самое
}
Сегодняшний бесполезен против первого варианта, а в будущем возможно и добавят проверку на нечёткое совпадение имён переменных и полей. Теоретически это вполне возможно сделать. Второй вариант действительно не отловит.
Нда, типофашизм крепчал… О таком я не знал, спасибо за просвещение. Не завидую тому, кто будет что-то похожее поддерживать...
Тестирование закрывает те дефекты, которые не смог отловить статический анализ.
Ваша формулировка очень интересно отражает грань между разными подходами. Для меня как сторонника динамических языков, тестирование является основным инструментом верификации кода, а статический анализ всего лишь дополнение, позволяющее существенно сократить расходы на тестирование определённого вида дефектов. Для вас — ровно наоборот.
В динамических языках статический анализ отлавливает куда меньше, чем в статических. Соответственно и наблюдается дополнительная нагрузка или на тестирование, или на багрепорты.
Теоретически, да. На практике, при грамотно построенном тестировании эта нагрузка в пределах фонового шума.
А моей практике они встречаются по несколько раз на дню (на Java) и ни разу не встречались на JavaScript за 5 лет опыта. Угадаете почему? Нет, не потому что ненужны, а потом вместо пары секунд, требуют пары часов.
Я начну с другого: что такое ужасное у вас творится с архитектурой проекта, чтобы массовые переименования полей/переменных по всему проекту требовались по нескольку раз на дню?
Просто когда у человека не было топора всю жизнь, он может искрене верить, что ножом куда удобнее рубить дрова. Да и вообще зачем дрова рубить и так как-нибудь сгорят.
Вы читаете куда-то между строк. См. выше: многие мои коллеги по цеху JavaScript пользуются различными IDE, которые обеспечивают эту самую лёгкость переименования, бла бла. И усиленно пытаются (ну, пытались раньше) продать мне эту идею, хотя на практике пользуются ею крайне редко. Потому что обратная совместимость, когнитивная нагрузка, да и просто банальный вопрос "зачем?"
Вы просто видимо не понимете, что такая хорошая IDE на статически типизированым языке.
Отчего ж, вполне понимаю. Несколько лет разработки на Pascal и C++ даром не проходят, хоть и давно это было.
Переименование полей это ерунда, вот возможность полностью поменять всю архитектуру
Вот тут я аж поперхнулся. Если у вас лёгкость полной замены архитектуры проекта является весомым аргументом в пользу выбора языка программирования, то мне даже добавить нечего. Извините, но мы с вами, похоже, на разных планетах живём и общий язык найти вряд ли удастся.
А это реально так. Нельзя просто ткнуть в поле и переименовать его во всем проекте сразу… вроде name -> firstName
IDE не пользуюсь, но многие коллеги без них жить не могут. И лёгкость переименования переменных и полей является самым частым (и обычно, единственным) аргументом в пользу IDE в неизбежных холиварах на кухне.
Я только плечами могу пожать. В моей практике такие переименования по всему проекту встречаются крайне редко, поэтому особого внимания не заслуживают.
Учитывая, что это выглядит как Канонiчный Пiтонъ, я бы ожидал от линтера достаточной продвинутости для понимания и анализа таких вот общераспространённых конструкций.
Ну т.е. ESLint как-то умеет понимать 'use strict'?
А каким образом информация о типах поможет вам в борьбе с опечатками? Такое впечатление, что вы с этими типами носитесь, как с писаной торбой.
Что-нибудь типа такого, самый банальный вид опечаток:
function() {
var foo = 'bar';
...
fooo; // ESLint ловит на ура
foo = truue; // То же самое
}
И т.д. Где тут нужна информация о типах? И каким образом она поможет от наиболее распространённых случаев синдрома толстых пальцев, когда тип переменной остаётся таким же, но значение ошибочно? Вот как в примере с '_main__' внизу, или сделать опечатку в цифре, или ещё что-нибудь.
Применять юнит-тестирования для защиты от таких банальностей — это стрельба из пушки по воробьям. Статический анализ и тестирование это два разных инструмента, закрывающие разные виды дефектов, и использовать нужно оба.
Так в том-то и дело, что на каком-то TypeScript можно было потратить на тесты значительно меньше времени
Тестирование бизнес-логики займёт на каком-то TypeScript ровно столько же времени и усилий, что и на каком-то JavaScript. Тестировать же типы принимаемых аргументов и возвращаемых значений не имеет смысла, поэтому никакой экономии вы не увидите.
IDE в разы лучше делает рефакторинг у статических яхыков
Голословное утверждение. На чём оно базируется?
динамика в таком случае даст плюсы за счет упрощения синтекса языка
Не совсем понятно, какой язык вы имеете в виду. Основные преимущества динамической типизации обычно находятся далеко не в упрощении синтаксиса.
У меня тут вывод покрался… «если у вас проект на 10к+ строк кода, то лучше бы использовать язык со статической типизацией, потому что банально IDE очень сильно будет выручать». А для небольших проектов плюшки динамики очень сильно помогают, а минусы сильно не болят.
Мой 6-летний опыт поддержки, развития, и многократных глубоких рефакторингов JavaScript фреймворка на 1.5 млн строк утверждает: и на крупных проектах процент ошибок по типам так же мал, и минусы динамического/слабого типизирования так же не болят. Надо хорошо тестировать, вот и всё.
Ждём выступление Джавистов: Пфе, вот если бы по-настоящему крупный проект!.. :)
Ух, мы с вами, чувствую, погрузимся в такие дебри, от куда будет сложно выбраться. Я с Ext'ом со 2й версии, т.е. года, этак с 2008, если мой склероз мне не изменяет:)
Можем и забраться, если вам интересно будет. :) Я с Ext работаю не так давно, в Sencha меня пригласили как раз аккурат к релизу 4.2. С тех пор уже 6 лет прошло, время летит...
Но многие вещи о которых вы пишете довольно спорные, на мой взгляд.
Запросто, понимание у всех разное. Я вижу вещи изнутри, вы на них смотрите снаружи, может и не совпасть.
Все прекрасно понимают, что стоимость поддержки легаси-броузеров в проекте стоит очень дорого.
IE11 ещё очень много где используется, и будет использоваться долго. У нас были клиенты, которые в конце 2018 всё ещё использовали IE7 и приложения на базе Ext 4. Масштабы есть очень разные, и стоимость поддержки тоже отличается очень сильно.
Про сборку. Не cmd единым жив интернет) cmd такой же инструмент как оные другие.
Нет, не такой же. Гораздо сложнее, и с более глубоким пониманием именно Ext JS. В Cmd очень много всякой магии для отслеживания зависимостей, настолько много, что заменить Cmd просто нечем. И бОльшая часть этой магии работает на уровнях, вам совершенно не очевидных.
Это уже не говоря о преобразованиях кода. У вас, скорее всего, никогда не было повода заглянуть в код production build и сравнить его с исходниками. Разница будет весьма заметная, в основном в классовой системе. Ext.define преобразуются в более дешёвые вызовы Ext.derive и т.д. Много тонких нюансов.
Порядок, примерно такой: разделяет общие файлы, очищает от «чужих методов» -> запускает cmd для клиента -> пакует в контейнер. В зависимости от проекта, можно собрать отдельно сервер, отдельно клиент или 2-в-одном.
Именно об этом я и говорил: за кажущееся упрощение серверной части вы платите усложнением toolchain, усложнением кода, разного рода проблемами, несвойственными серверной стороне, и т.д. Конкретно в вашем случае и сейчас цена может быть незаметно низкой, но она есть, и если потребуется ваше решение масштабировать, то цена будет расти быстрее, чем выгода.
Да объясните, наконец, зачем на сервере что-то отрисовывать? На сервере это работает так: Ext.create -> <Трансляция имени класса в путь к файлу> -> requere(<файл>).
На сервере отрисовывать незачем, хотя и можно. Я говорил о своих исследованиях, которые проводил на браузерной стороне. Там критерием истины служит время от начала загрузки до первой отрисовки, в случае сервера скорее от начала загрузки до создания дерева объектов. Себестоимость создания этого дерева никуда не девается.
Еще немного времени возьмет всякого рода фокусы с наследованием, но это копейки.
Ошибочное мнение. Настолько не копейки, что специально для этого в Cmd есть целый кусок преобразования кода.
После этого класс у вас в памяти и все последующие Ext.create этого класса мгновенные. Кроме того, большинство классов на сервере живут пока жив текущий процесс.
Речь не о классах, а об экземплярах класса. Посмотрите внимательно в Ext.Config и Ext.Configurator, там много интересного. Если вкратце, то при создании каждого экземпляра класса создаётся прототипная цепочка конфигов, и на это тратится существенное время. За гибкость надо платить.
Серверный this.fireEvent сделает асинхронно ровно то, что написал я, а именно, отправит в клиентские сокеты сообщения «чувак, тебе событие».
Возможно, я не совсем внимательно смотрел в код. У вас же серверная логика базируется на Ext.app.Controller? Контроллеры умеют стрелять события по своему событийному домену и слушать их, всё это происходит синхронно. То, что события в WebSocket отправляются асихронно, не означает, что больше ничего не происходит.
Кроме того, речь даже не о ваших событиях в WebSocket. Речь о том, что вы используете штатный механизм, который никогда не был предназначен для такого варианта использования. И этот механизм очень легко может выстрелить вам в ногу, если вы не будете очень аккуратны. Вы-то может и будете, а вот другие люди, не так хорошо понимающие этот механизм?
Сочувствую) Я после 6лет с ПХП долго восстанавливал нервную систему. С Ext JS у меня более счастливый брак))
Я рад, что вам нравится наш фреймворк. Это всегда приятно слышать. :)
В броузере утечки неизбежны, слишком много всего там живет разношерстого. Сервер в этом плане на порядок проще, и отловить утечки там реально.
Дело не в разношёрстности. В Node отсутствует DOM, но течь через expandos на DOM нодах браузеры уже давно разучились, этих проблем не было уже с IE8. Дело в управлении памятью в JavaScript, а эта часть одинакова и там, и там.
Технически, бОльшая часть утечек в JavaScript попадает в категорию "псевдо-утечек". В этом случае память остаётся адресуемой и может быть освобождена, но по каким-то причинам сборщик мусора не может её освободить. Обычно это случается из-за того, что где-то есть ссылка на объект, и по цепочке ссылок можно дойти до глобального объекта.
Вот проблема как раз в том, что Ext JS по своей архитектуре способствует таким утечкам, и избавиться от них было очень сложно. В других решениях проблема может быть либо не настолько выраженной, либо отсутствовать вовсе, но в JavaScript всегда очень легко эти утечки создать вручную. Очень, очень легко. В браузере они не критичны, т.к. даже самое долгоживущее приложение рано или поздно закрывают. А вот на сервере это проблема.
Да, я директором пользуюсь если сервер не нодовский. Но нафига мне лишняя прослойка, когда у меня один язык на клиенте и сервере?
Это не прослойка, это транспорт. С разными вкусными плюшками, которые вы можете использовать практически бесплатно.
Еще раз: основная задача в этом проекте максимально стереть границу между клиентом и сервером при сохранении возможностей масштабирования.
Именно поэтому я и критикую ваше решение. Ещё раз: как разработчик этого фреймворка с многолетним стажем поиска и устранения разного рода проблем я считаю, что использование Ext JS на сервере нецелесообразно. Не будет это решение масштабироваться до сколько-нибудь заметных нагрузок.
В начале времен, когда трава была зеленее и столы выше, программы на клиенте и сервере были написаны одинаково, и могли поддерживаться программистами с одинаковыми компетенциями. Потом настали трудные времена и клиент ушел от сервера.
Вы преувеличивается и зелень травы, и трудность времён. :) Web приложения это не более, чем очередной заход в распределённые вычисления. Со своими специфическими заморочками, но в сущности по мелочам.
Я просто пытаюсь снова воссоединить клиент и сервер:)
Зачем? Мне было бы очень интересно услышать развёрнутый и убедительный ответ на этот вопрос. :)
Только, ради Бога, не пишите про всякие там соапы, терминалы и прочее, что было в те далекие времена
Ну вы смешали тоже. SOAP это просто транспортный протокол на базе XML, Ext JS его вполне умеет. И есть клиенты, которые его используют. Я даже пару багов в нём как-то фиксил...
Если понимать, что ExtJS все-таки больше приедназначен для интранета и всяких там админок
Ну вот если вы это понимаете, то также должны понимать, что для интранета и всяких там админок очень часто используется всякое старьё (конкретно, IE11). В котором не то, что ES8, а даже и ES6 едва присутствует.
Сборка сервера через Cmd занятие бессмысленное, классы подгружаются и остаются в памяти по мере необходимости стандартным нодовским require
Допускаю, хотя в исходниках ваших модулей я этого не увидел. Но в общем смотрел по диагонали, мог и пропустить.
А клиент, да, собирается через cmd и превращается в 1мб.
Вот тут будут возникать отдельные вопросы, и даже целая пачка. Емнип, Cmd совершенно не в курсе ваших тегов scope:server и если исходники используются там и сям, то перед сборкой клиентской части нужно выкусывать серверную. А это дополнительный инструментарий, шаг сборки, да и просто геморрой.
Вообще, вопрос сборки такого проекта интересен сам по себе, рамок одной статьи маловато для этого. Могу описать, если хотите)
Спасибо, с процессом сборки Cmd я, можно сказать, интимно знаком. :) Не настолько этот процесс интересен, как вам кажется, а вот сложен намного более, чем вам представляется.
Не совсем понятно как это может повлиять на производительность. Максимум, вы теряете немного в момент инициализации объекта, что для сервера не сильно критично (объекты долгоживущие), а для клиента не сильно заметно.
Я в своё время потратил много, много дней на профилирование Ext JS и выводы были очень интересные. В большей части приложений порядка 20-30% времени до первой отрисовки съедало именно создание объектов и в частности, создание конфигов для них. Вы в курсе, как эта штука внутри устроена? Посмотрите, механизм весьма интересный и гибкий, но и тормозной при этом — очень много накладных расходов на создание объекта с заданным прототипом.
Хм, никакой синхронности от сервера не требуется: сервер просто кидает в сокет нужного клиента сообщение «парень, тебе тут событие» и забывает про него.
От сервера требуется асинхронность, иначе масштабирование системы будет под очень большим вопросом. Поскольку всё происходит в одном event loop, каждый кусок кода должен быть очень быстрым и возвращать управление планировщику как можно быстрее. А в Ext на каждое событие можно повесить обработчик, который может тоже стрелять события, на которые могут быть повешены обработчики, и так далее ad nauseam. Всё это происходит синхронно, и пока весь код не отработает, управление к планировщику не вернётся и никакие другие куски кода работать не будут.
В браузере это не так критично, браузер по определению работает для одного пользователя. Пользователь подождёт и секунду, и две, а какие-нибудь 200 мс и не заметит. А вот на сервере такой подход недопустим, т.к. очень легко попасть на случай, когда залётный таймаут из базы данных или ещё откуда просто положит систему.
В вашем случае всё это не очевидно, потому что серверная сторона маленькая и простенькая, и на грабли вы ещё не наступали. Может и не наступите. Но подход не масштабируется в принципе.
Глобальные объекты вы имеете ввиду DOM?
Нет, при чём тут DOM. В браузере верхний объект это window, в Node это global, но суть не меняется: Ext JS создаёт иерархию классов в виде вложенных объектов со ссылкой на верхний объект. Когда вы пишете что-нибудь в стиле:
var foo = new Ext.bar.Foo();
То вот этот Ext, технически, это переменная в глобальном контексте, а по факту свойство window.Ext (или global.Ext). Всё, что находится в самом объекте Ext, живёт в памяти всегда.
Большая часть этих вложенных объектов — это классы Ext. Некоторые объекты это singletons, а ещё некоторые просто объекты JavaScript, безо всякой специальной магии. Проблема в том, что и singletons, и некоторые классы, и даже просто объекты, делают очень много всяких разных штук, очень не полезных для расхода памяти. Держат ссылки на экземпляры своего типа (StoreManager держит ссылки на все Store, ComponentManager на все компоненты, etc), размещают всякие кеши на прототипе, и протчая, и протчая. И всё это растёт и пенится, от чего Garbage Collector рано или поздно становится плохо. Для браузера это опять же не очень критично — стал тормозить, F5 и понеслось. А вот на сервере будет больно.
Вы видите ExtJS как сборник UI-компонент, но по факту там 2 части — Core (движок классов) и UI (компоненты и все с ними связанное).
Я вижу Ext JS как кусок говна софта, на который я потратил 6 лет жизни. ;) Частей там существенно больше двух.
Мы делали на этой штуке систему лояльности, при нагрузке в районе 150 запросов/сек в течении суток я не заметил каких-то утечек на сервере…
6.2 у вас? Это приятно слышать, потому что я потратил несколько месяцев на отлов всех утечек, до которых мог дотянуться. Похоже, что выпилил все крупные, раз вы проблем до сих пор не заметили. :)
Но вот до конца проблему решить не удалось и не удастся. Я могу много рассказать о том, как оно течёт, куда, и почему, но если вкратце: текло, течёт, и течь будет. Основная больная проблема это глобальные ссылки, и от них никуда не денешься. Архитектура такая.
Что бы у меня в каталоге users в папке view лежали формы и таблицы для списка пользователей, а в model все что касается данных…
Если вы немного копнёте в Direct, то увидите: это как раз средство свести серверную сторону к абсолютному минимуму. По факту к надстройке над базой данных, которая делает проверку прав доступа и может быть чуть-чуть ещё.
А всё, что вам нужно, можно сделать на клиентской стороне. Благо, Ext JS как раз для таких вещей и создан.
Проходил до уровня "сделать большой шкаф и стол к контракторской пиле". Вот такой: http://woodarchivist.com/1924-table-saw-cabinet-plans/
А потом надоело. Захотелось, знаете ли, что-нибудь полезное сделать, а не только вокруг циркулярки прыгать всё время. Да и годная пила внезапно подвернулась, за все $200. :) Вот приведя её в порядок и попробовав, я и понял, почему очень многие более опытные товарищи прямо говорят: не занимайтесь онанизмом, копите деньги на хороший инструмент.
Мгм. Вы знаете, я никак не хочу оскорбить вас недоверием, но в данном случае вынужден. Потому как имея опыт работы и с ручным инструментом, и с
хламчинскимдешёвым электрическим, я таки представляю себе сложности, с этим связанные. Да что далеко ходить, даже фанеру отрезать ровно и перпендикулярно строительной циркуляркой нифига не так просто, как об этом в йутубе показывают. Так что, можно фото ваших самодельных станков в студию?Вот это меня настораживает ещё больше, как и дальнейшие упоминания йутубов и серьёзных людей с серьёзными проектами. Вы уверены, что на самом деле пробовали что-нибудь руками делать, а не просто видосики смотрели?
Угу. Вот похоже, что мсье как раз по книжкам только и мастер. Я уже три верстака построил и четвёртый собираюсь делать, теперь уже правильный наконец. С учётом опыта предыдущих и понимания, что мне нужно, а что нет.
Я этот квест проходил (сейчас на 4-м циркулярном станке). Дешёвая циркулярка ни разу не заменит стационарный циркулярный стол. Основных причины три:
а) В стационарном станке есть направляющие пазы (miter slots), выточенные в чугунии с высокой точностью. По этим пазам ездят все приспособы, и от этих пазов напрямую зависит, что у вас будет получаться на станке. Так вот, у дешёвых пластиковых циркулярок этих пазов либо вообще нет, либо использовать их толком не получится из-за формы и конструкции. Для грубого торцевания досок на стройке подходит, для чего-то более амбициозного никак. Я проверял.
б) Из пункта а) вытекает следущий: наличие пазов это одно, а точность их ориентировки относительно лезвия это совсем другое. Циркулярных станков бывает много разных типов, и регулируются они по-разному: лёгкие (jobsite saw) вообще толком не регулируются, у более тяжёлых портативных механизм привешен к чугуниевому столу снизу, у стационарных механизм крепится к шкафу (станине), а стол просто лежит сверху.
Так вот, нормально отрегулировать можно только последний тип. Я уже через все проходил, и на все потратил уйму времени, прыгая вокруг с микрометром. Только стационарный держит настройку и не съезжает со временем от вибрации. Все портативные (вкл. тяжёлые) разрегулируются очень быстро, и начинаются проблемы.
в) Кроме пазов, огромную роль играет также продольная направляющая (fence). От неё напрямую зависит не только, сможете ли вы получить на выходе деталь, отрезанную точно по размерам, но и качество распила, и безопасность операции. Например, хорошо отрегулированная Т-образная направляющая типа Biesemeyer позволяет обойтись без фуговки при склеивании массива. Нет, не шучу, проверял многократно: отфуговал с одной стороны, отрезал с противоположной, можно склеивать.
Так вот, все эти штуки просто так из говна и палок не сделаешь. Если направляющую ещё можно попробовать самому сделать (в теории), то вот сам станок не получится. Другие инструменты можно подумать, но циркулярный станок… Лучше это время и силы потратить на практику с ручными инструментами.
Не критики ради, а безопасности для:
Перед тем, как проделывать операцию, остановитесь и подумайте, что и как куда идёт. Целее будете.
Распускать доски с помощью ручной циркулярки это, мягко скажем, не самое безопасное занятие. На стационарном станке тоже не 100%, но при наличии защитного кожуха и riving knife (не знаю, как по-русски называется) гораздо меньше шансов создать себе проблемы.
Фуговальные станки очень опасны, не надо их недооценивать. Особенно ваш, доставшийся от деда: я не вижу на нём защитной крышки над лезвиями. Очень надеюсь, что крышка есть и вы её просто временно сняли ради сделать фотографию, и никогда (никогда!) не используете станок без неё. И руками заготовку не держите, а используете прижимы типа таких:
Из практики: торцовочная пила это не must have, особенно для столярных дел. Это плотницкий инструмент, для грубого торцевания. Я тоже начал строительство мастерской с торцовочной пилы, а теперь она висит на стене гаража без дела. Сколько вокруг этой пилы ни прыгай, точность у неё никакая (если, конечно, это не Festool Kapex стоимостью в пол-самолёта) — особенно когда надо стыки под 45 градусов делать, для рамок, коробок и проч. Для торцевания и угловых отрезов гораздо лучше работают специализированные приспособы на базе стационарной циркулярки: погуглите cross-cut sled, miter sled и всё станет понятно.
Я вообще пришёл к выводу, что единственно нужный в мастерской хороший станок — это стационарная чугуниевая циркулярка. Один раз её настроить, отъюстировать с микрометром, сделать пару дополнений и дальше можно не задумываться о допусках, корректности углов и зазорах при сборке деталей.
Правда, хорошая чугуниевая циркулярка стоит некисло денег (новая), а б/у если и находятся, то обычно в печальном состоянии. Но! Если не бояться трудностей, то можно разобрать такой станок, восстановить, почистить от ржавчины, смазать и собрать обратно лучше, чем было. За относительно немного денег можно получить в своё пользование очень годный индустриальный станок.
Но тут есть ньюанс… (с) Если таких трудностей не бояться, то процесс имеет свойство затягивать хуже героина. Я так радовался, когда по дешёвке урвал сверлильный станок 40-х годов! Сейчас как восстановлю, как пользоваться начну!.. Восстановил… Начал… Теперь в работе 60-х годов циркулярка, 50-х годов большой стационарный фрезер, 40-х годов фуганок, 50-х годов токарный станок, ну, вы понимаете… Времени по дереву уже почти не остаётся, зато приходится осваивать работу по металлу, финиширование, покраску, полировку, электрику… Но когда закончу! :)
Именно. Вы примеряете этот диалог на себя в позиции собеседуемого в типичной ролевой игре, описанной в начале статьи. Это когда собеседующий — "строгий профессор", а вы "студент-раздолбай" на зачёте, потеете в ожидании каверзных вопросов с целью завалить.
Автор же ищет пути этой ситуации избежать и беседовать с кандидатом на равных, как человек с человеком. Может, не идеально ищет, но сам факт.
del, ошибся веткой.
Это история взросления, зарабатывания уверенности в себе и самоуважения. +100.
Огромное спасибо за статьи, очень интересно. За пасхалку про планету в форме чемодана особенное мерси. ;)
Не флейма ради, а просто мимо проходил. Ternaries можно форматировать не вот так:
А вот так:
Отлично читается, по-моему, и существенно компактнее простыней
if/elsif/else. Очень подходит для определённого рода ситуаций, когдаswitchне подходит (или отсутствует, хе-хе), а синтаксисif/elsifзаймёт больше места, чем собственно условия и присвоения. И если ещё условие нужно будет добавить, то не надо переформатировать, просто строку вставить.Ну т.е. полная вкусовщина конечно, но мне нравится.
Вы какой код хотите посмотреть, вышеупомянутого фреймворка? Вот здесь можно подписаться на пробную версию, скачать архив и посмотреть код. Лучше подписываться с одноразового емаела, чтобы потом моск не выклевали на тему купить. Это не я придумал. :(
Если интересно, как вся эта кухня тестируется, то вот статейка с бла-бла по верхам, ну и там же ссылка на код оркестратора. Сами юнит-тесты идут в архиве с фреймворком.
Лет 20 уже как
нашёл Исусаувидел свет динамики, и назад не оглядывался.Да мне в общем-то всё равно, как он выглядит. Более ёмкий синтаксис и type inference помогают сократить boilerplate, но развесистая клюква дерева типов никуда не денется, со всеми накладными расходами.
Для сторонников статической типизации вообще типично начинать проектирование системы с раскладывания по полочкам типов, их взаимосвязей, наследования, интерфейсов, и прочего из отдела "как должно выглядеть, чтоб красиво". Что вполне противоречит набитому кровавыми шишками принципу YAGNI...
Возможно, я не пробовал. Мне такой механизм представляется мало ценным, на практике случаи, когда функция должна принимать на вход ограниченный набор строк, относительно редки. Ну т.е. когда у вас весь код уже закрыт тестами и вылизан, можно закрутить ещё одну гайку, отчего ж нет. Только вот на практике обычно получается, что вот эти вот малозначительные вещи выдвигаются на передний план под соусом "а так тесты писать не надо!"
Речь не о подсказках, а о когнитивной нагрузке и расходах на проектирование/поддержку. Только не надо мне рассказывать о том, что всё это бесплатно и просто само по себе работает. Я слишком старый уже, чтобы в Деда Мороза верить.
Вот там внизу товарищ dimm_ddr уже по теории высказался, а я как человек практический скажу так: вы можете сколько угодно гоняться за своей красной селёдкой идеального кода без дефектов, а мне надо работу работать.
Ещё раз: спорить с тем, что строгая статическая типизация позволяет избежать целого класса дефектов в коде, бессмысленно. Речь вовсе не об этом, а о том, что всё в этом мире не бесплатно, и за устранение этого класса дефектов приходится платить строгостью и статической типизацией. В теории всё отлично: избегаем X дефектов, платим за это Y человеко-часами.
А теперь внимание, правильный ответ: на практике этот самый класс дефектов оказывается мелкой точкой на радаре, незаметной в фоновом шуме. А вот Y человеко-часов затрат никуда не деваются. И по прошествии времени в сколько-нибудь заметном проекте число Y увеличивается многократно. При стабильно минимальном возврате.
Идём дальше: насколько мне известно, единственный практически работающий способ обеспечить качество кода это автоматизированное тестирование, что, кстати, подтверждается наличием научных исследований на эту тему. А дальше возникает сакраментальный вопрос: если
тесты писать по-любому надокачество кода статическая типизация не спасает, тонахрена козе баянзачем нужны танталовы муки с этой самой статической типизацией?Ну вот как бы не сюрприз, что к похожим выводам некоторые крайне умные и очень опытные люди пришли ещё в конце 50-х. LISP наше всё, да.
Отчего же, программировал и довольно много. Правда, давно уже, поэтому деталей не упомню, а вот лютая, бешеная отрыжка на развесистые деревья типов и простыни UML-диаграмм осталась. Видеть всё это ещё раз совершенно не хочется, спасибо.
Сегодняшний бесполезен против первого варианта, а в будущем возможно и добавят проверку на нечёткое совпадение имён переменных и полей. Теоретически это вполне возможно сделать. Второй вариант действительно не отловит.
Нда, типофашизм крепчал… О таком я не знал, спасибо за просвещение. Не завидую тому, кто будет что-то похожее поддерживать...
Ваша формулировка очень интересно отражает грань между разными подходами. Для меня как сторонника динамических языков, тестирование является основным инструментом верификации кода, а статический анализ всего лишь дополнение, позволяющее существенно сократить расходы на тестирование определённого вида дефектов. Для вас — ровно наоборот.
Теоретически, да. На практике, при грамотно построенном тестировании эта нагрузка в пределах фонового шума.
Я начну с другого: что такое ужасное у вас творится с архитектурой проекта, чтобы массовые переименования полей/переменных по всему проекту требовались по нескольку раз на дню?
Вы читаете куда-то между строк. См. выше: многие мои коллеги по цеху JavaScript пользуются различными IDE, которые обеспечивают эту самую лёгкость переименования, бла бла. И усиленно пытаются (ну, пытались раньше) продать мне эту идею, хотя на практике пользуются ею крайне редко. Потому что обратная совместимость, когнитивная нагрузка, да и просто банальный вопрос "зачем?"
Отчего ж, вполне понимаю. Несколько лет разработки на Pascal и C++ даром не проходят, хоть и давно это было.
Вот тут я аж поперхнулся. Если у вас лёгкость полной замены архитектуры проекта является весомым аргументом в пользу выбора языка программирования, то мне даже добавить нечего. Извините, но мы с вами, похоже, на разных планетах живём и общий язык найти вряд ли удастся.
IDE не пользуюсь, но многие коллеги без них жить не могут. И лёгкость переименования переменных и полей является самым частым (и обычно, единственным) аргументом в пользу IDE в неизбежных холиварах на кухне.
Я только плечами могу пожать. В моей практике такие переименования по всему проекту встречаются крайне редко, поэтому особого внимания не заслуживают.
Учитывая, что это выглядит как Канонiчный Пiтонъ, я бы ожидал от линтера достаточной продвинутости для понимания и анализа таких вот общераспространённых конструкций.
Ну т.е. ESLint как-то умеет понимать
'use strict'?А каким образом информация о типах поможет вам в борьбе с опечатками? Такое впечатление, что вы с этими типами носитесь, как с писаной торбой.
Что-нибудь типа такого, самый банальный вид опечаток:
И т.д. Где тут нужна информация о типах? И каким образом она поможет от наиболее распространённых случаев синдрома толстых пальцев, когда тип переменной остаётся таким же, но значение ошибочно? Вот как в примере с '_main__' внизу, или сделать опечатку в цифре, или ещё что-нибудь.
Применять юнит-тестирования для защиты от таких банальностей — это стрельба из пушки по воробьям. Статический анализ и тестирование это два разных инструмента, закрывающие разные виды дефектов, и использовать нужно оба.
Тестирование бизнес-логики займёт на каком-то TypeScript ровно столько же времени и усилий, что и на каком-то JavaScript. Тестировать же типы принимаемых аргументов и возвращаемых значений не имеет смысла, поэтому никакой экономии вы не увидите.
Голословное утверждение. На чём оно базируется?
Не совсем понятно, какой язык вы имеете в виду. Основные преимущества динамической типизации обычно находятся далеко не в упрощении синтаксиса.
Нелепые опечатки должны отлавливаться линтером и не доходить даже до merge.
Мой 6-летний опыт поддержки, развития, и многократных глубоких рефакторингов JavaScript фреймворка на 1.5 млн строк утверждает: и на крупных проектах процент ошибок по типам так же мал, и минусы динамического/слабого типизирования так же не болят. Надо хорошо тестировать, вот и всё.
Ждём выступление Джавистов: Пфе, вот если бы по-настоящему крупный проект!.. :)
Можем и забраться, если вам интересно будет. :) Я с Ext работаю не так давно, в Sencha меня пригласили как раз аккурат к релизу 4.2. С тех пор уже 6 лет прошло, время летит...
Запросто, понимание у всех разное. Я вижу вещи изнутри, вы на них смотрите снаружи, может и не совпасть.
IE11 ещё очень много где используется, и будет использоваться долго. У нас были клиенты, которые в конце 2018 всё ещё использовали IE7 и приложения на базе Ext 4. Масштабы есть очень разные, и стоимость поддержки тоже отличается очень сильно.
Нет, не такой же. Гораздо сложнее, и с более глубоким пониманием именно Ext JS. В Cmd очень много всякой магии для отслеживания зависимостей, настолько много, что заменить Cmd просто нечем. И бОльшая часть этой магии работает на уровнях, вам совершенно не очевидных.
Это уже не говоря о преобразованиях кода. У вас, скорее всего, никогда не было повода заглянуть в код production build и сравнить его с исходниками. Разница будет весьма заметная, в основном в классовой системе.
Ext.defineпреобразуются в более дешёвые вызовыExt.deriveи т.д. Много тонких нюансов.Именно об этом я и говорил: за кажущееся упрощение серверной части вы платите усложнением toolchain, усложнением кода, разного рода проблемами, несвойственными серверной стороне, и т.д. Конкретно в вашем случае и сейчас цена может быть незаметно низкой, но она есть, и если потребуется ваше решение масштабировать, то цена будет расти быстрее, чем выгода.
На сервере отрисовывать незачем, хотя и можно. Я говорил о своих исследованиях, которые проводил на браузерной стороне. Там критерием истины служит время от начала загрузки до первой отрисовки, в случае сервера скорее от начала загрузки до создания дерева объектов. Себестоимость создания этого дерева никуда не девается.
Ошибочное мнение. Настолько не копейки, что специально для этого в Cmd есть целый кусок преобразования кода.
Речь не о классах, а об экземплярах класса. Посмотрите внимательно в
Ext.ConfigиExt.Configurator, там много интересного. Если вкратце, то при создании каждого экземпляра класса создаётся прототипная цепочка конфигов, и на это тратится существенное время. За гибкость надо платить.Возможно, я не совсем внимательно смотрел в код. У вас же серверная логика базируется на
Ext.app.Controller? Контроллеры умеют стрелять события по своему событийному домену и слушать их, всё это происходит синхронно. То, что события в WebSocket отправляются асихронно, не означает, что больше ничего не происходит.Кроме того, речь даже не о ваших событиях в WebSocket. Речь о том, что вы используете штатный механизм, который никогда не был предназначен для такого варианта использования. И этот механизм очень легко может выстрелить вам в ногу, если вы не будете очень аккуратны. Вы-то может и будете, а вот другие люди, не так хорошо понимающие этот механизм?
Я рад, что вам нравится наш фреймворк. Это всегда приятно слышать. :)
Дело не в разношёрстности. В Node отсутствует DOM, но течь через expandos на DOM нодах браузеры уже давно разучились, этих проблем не было уже с IE8. Дело в управлении памятью в JavaScript, а эта часть одинакова и там, и там.
Технически, бОльшая часть утечек в JavaScript попадает в категорию "псевдо-утечек". В этом случае память остаётся адресуемой и может быть освобождена, но по каким-то причинам сборщик мусора не может её освободить. Обычно это случается из-за того, что где-то есть ссылка на объект, и по цепочке ссылок можно дойти до глобального объекта.
Вот проблема как раз в том, что Ext JS по своей архитектуре способствует таким утечкам, и избавиться от них было очень сложно. В других решениях проблема может быть либо не настолько выраженной, либо отсутствовать вовсе, но в JavaScript всегда очень легко эти утечки создать вручную. Очень, очень легко. В браузере они не критичны, т.к. даже самое долгоживущее приложение рано или поздно закрывают. А вот на сервере это проблема.
Это не прослойка, это транспорт. С разными вкусными плюшками, которые вы можете использовать практически бесплатно.
Именно поэтому я и критикую ваше решение. Ещё раз: как разработчик этого фреймворка с многолетним стажем поиска и устранения разного рода проблем я считаю, что использование Ext JS на сервере нецелесообразно. Не будет это решение масштабироваться до сколько-нибудь заметных нагрузок.
Вы преувеличивается и зелень травы, и трудность времён. :) Web приложения это не более, чем очередной заход в распределённые вычисления. Со своими специфическими заморочками, но в сущности по мелочам.
Зачем? Мне было бы очень интересно услышать развёрнутый и убедительный ответ на этот вопрос. :)
Ну вы смешали тоже. SOAP это просто транспортный протокол на базе XML, Ext JS его вполне умеет. И есть клиенты, которые его используют. Я даже пару багов в нём как-то фиксил...
Ну вот если вы это понимаете, то также должны понимать, что для интранета и всяких там админок очень часто используется всякое старьё (конкретно, IE11). В котором не то, что ES8, а даже и ES6 едва присутствует.
Допускаю, хотя в исходниках ваших модулей я этого не увидел. Но в общем смотрел по диагонали, мог и пропустить.
Вот тут будут возникать отдельные вопросы, и даже целая пачка. Емнип, Cmd совершенно не в курсе ваших тегов
scope:serverи если исходники используются там и сям, то перед сборкой клиентской части нужно выкусывать серверную. А это дополнительный инструментарий, шаг сборки, да и просто геморрой.Спасибо, с процессом сборки Cmd я, можно сказать, интимно знаком. :) Не настолько этот процесс интересен, как вам кажется, а вот сложен намного более, чем вам представляется.
Я в своё время потратил много, много дней на профилирование Ext JS и выводы были очень интересные. В большей части приложений порядка 20-30% времени до первой отрисовки съедало именно создание объектов и в частности, создание конфигов для них. Вы в курсе, как эта штука внутри устроена? Посмотрите, механизм весьма интересный и гибкий, но и тормозной при этом — очень много накладных расходов на создание объекта с заданным прототипом.
От сервера требуется асинхронность, иначе масштабирование системы будет под очень большим вопросом. Поскольку всё происходит в одном event loop, каждый кусок кода должен быть очень быстрым и возвращать управление планировщику как можно быстрее. А в Ext на каждое событие можно повесить обработчик, который может тоже стрелять события, на которые могут быть повешены обработчики, и так далее ad nauseam. Всё это происходит синхронно, и пока весь код не отработает, управление к планировщику не вернётся и никакие другие куски кода работать не будут.
В браузере это не так критично, браузер по определению работает для одного пользователя. Пользователь подождёт и секунду, и две, а какие-нибудь 200 мс и не заметит. А вот на сервере такой подход недопустим, т.к. очень легко попасть на случай, когда залётный таймаут из базы данных или ещё откуда просто положит систему.
В вашем случае всё это не очевидно, потому что серверная сторона маленькая и простенькая, и на грабли вы ещё не наступали. Может и не наступите. Но подход не масштабируется в принципе.
Нет, при чём тут DOM. В браузере верхний объект это
window, в Node этоglobal, но суть не меняется: Ext JS создаёт иерархию классов в виде вложенных объектов со ссылкой на верхний объект. Когда вы пишете что-нибудь в стиле:То вот этот
Ext, технически, это переменная в глобальном контексте, а по факту свойствоwindow.Ext(илиglobal.Ext). Всё, что находится в самом объектеExt, живёт в памяти всегда.Большая часть этих вложенных объектов — это классы Ext. Некоторые объекты это singletons, а ещё некоторые просто объекты JavaScript, безо всякой специальной магии. Проблема в том, что и singletons, и некоторые классы, и даже просто объекты, делают очень много всяких разных штук, очень не полезных для расхода памяти. Держат ссылки на экземпляры своего типа (StoreManager держит ссылки на все Store, ComponentManager на все компоненты, etc), размещают всякие кеши на прототипе, и протчая, и протчая. И всё это растёт и пенится, от чего Garbage Collector рано или поздно становится плохо. Для браузера это опять же не очень критично — стал тормозить, F5 и понеслось. А вот на сервере будет больно.
Я вижу Ext JS как кусок
говнасофта, на который я потратил 6 лет жизни. ;) Частей там существенно больше двух.6.2 у вас? Это приятно слышать, потому что я потратил несколько месяцев на отлов всех утечек, до которых мог дотянуться. Похоже, что выпилил все крупные, раз вы проблем до сих пор не заметили. :)
Но вот до конца проблему решить не удалось и не удастся. Я могу много рассказать о том, как оно течёт, куда, и почему, но если вкратце: текло, течёт, и течь будет. Основная больная проблема это глобальные ссылки, и от них никуда не денешься. Архитектура такая.
Если вы немного копнёте в Direct, то увидите: это как раз средство свести серверную сторону к абсолютному минимуму. По факту к надстройке над базой данных, которая делает проверку прав доступа и может быть чуть-чуть ещё.
А всё, что вам нужно, можно сделать на клиентской стороне. Благо, Ext JS как раз для таких вещей и создан.