Она не для людей. Она необходима для среды разработки, чтобы корректно отрабатывали такие функции как «перейти к определению», «контекстные подсказки», «найти символ по имени». К сожалению в вебшторме нет поддержки апи для добавления js-фреймворков (которая, есть, например, для java). Так что приходится довольствоваться либо 10 предопределенными, либо генерировать jsodc-и. Я бы лучше на тайпскрипт перешёл, чем заниматься этой ерундой. Но, к сожалению, архитектурные вопросы решаю не я.
Кроме того, по ним же с помощью jsduck генерируется документация. При этом приходится дублировать определения в разных нотациях, чтобы это понимала и IDEA и jsduck.
Насчет автосохранения — это не очень хорошо, когда исходник постпроцессится по мере сохранения. Например, я сейчас сделал, чтобы автоматом генерировались jsdoc/jsduck аннотации. При сохранении при потере фокуса и обновлении при его приобритении получается все пучком: уходим, возвращаемся, а там уже доки появились. При постоянном сохранении же постоянно происходят конфликты между версией в памяти и версией на диске.
Что лишний раз подтверждает, что исключения не справляются со своей основной задачей — обработкой исключительных ситуаций. А хорошем приложении ничего кроме библиотек быть и не должно.
И мне не надо, чтобы функция возвращала ошибку, мне надо, чтобы я мог ей сказать, что в случае определенных ситуаций нужно использовать такую-то стратегию восстановления. На выбор:
1. остановить загрузку всех картинок, написать в консоль ошибку
2. написать в консоль, продолжить грузить остальное
3. попробовать загрузить то же самое с другого домена
4. отложить загрузку на 5 минут
и 100500 других стратегий, про которые библиотека не должна знать превращаясь в кухонный комбайн.
вообще без исключений в календарике я не могу обойтись банально потому, что они сами чуть что возникают в самых интересных местах.
Никак не адекватно, если их нужно руками ловить в одном месте, а потом перекидывать в другое. Это ничем не лучше пресловутых «кодов возврата» Представь себе 5 параллельно запущенных воркеров, каждый качает по сотне файлов. Что делать при ошибке загрузки одного из них? Библиотека не знает и кидает исключение, останавливая все файлы. Занимайтесь ерундой с перезапуском воркеров. Для этих целей кто во что горазд пишет костыли. Например, можно кидать событие «ошибка загрузки файла», на которое можно подписаться и реализовать свою стратегию. Но это все вручную и зачастую переопределить стратегию на 2 уровня ниже уже не получится ибо автор либы поленился реализовать соответствующее прокидывание событий и стратегий. Как это должно реализовываться: мы создаем домен и описываем в нем стратегии реагирования на различные исключительные ситуации и далее все запускаемые, создаваемые и любые другие сущности имеют связь с этим доменом. В случае ахтунга — исполняется обработчик домена, который реализует альтернативные стратегии, либо инициирует освобождение всех привязанных к нему ресурсов — откручивается стек, останавливаются потоки, освобождаются файлы и тп.
более наглядный пример — есть календарик, он ловит события клика, нажатия на клавиатуру, скролл мышью, прикосновения пальцами и кучу других событий из разных мест. С исключениями приходится в каждый обработчик вставлять try-catch чтобы в случае ошибки календарик не умирал благородной смертью японского самурая. А с доменами можно было бы сделать так: объявяляем домен в котором указываем обработчик ошибок, в этом домене создаем календарик — все обработчики автоматом наследуют домен и в случае любых ошибок раскручиваться будет стек доменов, а не стек исполнения. в ноде как раз долгое время была проблема из-за отсутствия доменов — если разработчик библиотеки, в которой используются асинхронные операции, забыл где-то поставить try-catch, то ронялась вся нода и никак из внешнего кода на это было не повлиять, потому что стек честно раскручивался до конца.
У исключений есть еще одна беда — они замечательно раскручивают стек в случае синхронного кода, но совершенно бесполезны в случае использования колбэков или многопоточности.
Например, нам нужно собрать проект, для этого мы запускаем параллельно 3 задачи. Если хотябы одна из них упадет, то нужно остановить и другие 2, после чего завершиться с ошибкой. Исключения тут идут лесом. А если нам нужно при указании специального параметра не завершать приложение, а вывести сообщение в консоль, продолжая параллельные задачи, после чего ожидая изменения файлов, после чего запускать только те задачи, которые зависят от измененных файлов?
Исключения — это и правда зло, потому что полагаются на стек. Вместо этого хорошо иметь отдельный стек «доменов» (что-то типа nodejs.org/api/domain.html) и при создании колбэка привязывать к нему текущий домен. А в домене уже при его создании устанавливать стратегию реагирования на исключительные ситуации.
Все тут принялись советовать всякие поисковые движки, которые являются не более чем костылями сверху неполноценных субд, не способных делать хитрые фильтрации за приемлемое время и без монструозных запросов. В итоге у вас получится не одна субд с шардингом, репликацией, транзакциями и прочими плюшками, а две с дополнительными проблемами синхронизации и прочим геморроем.
Аж даже превышала 90%?) То есть более чем в 9 случаях из 10 исследование «крупной фирмы с огромным количеством заказчиков» дает ложноположительный результат?
Как я обожаю эти дилетантские исследования с громкими выводами)
Как происходила рандомизация и сколько было параллельных А/В тестов?
Как отсекались новые пользователи? Старые пользователи подвержены эфекту новизны, а куки имеют свойство протухать.
Какова статистическая значимость ваших гипотез?
Без всего этого вам не сюда, а в хаб «астрология и эзотерика».
А как связаны «информирование разработчика об исключительной ситуации» с «восстановлением после сбоя»? Это перпендикулярные понятия. Ничто не мешает показывать разработчику ошибку большими красными буквами, отсылать ему отчеты и тп, при этом сохраняя потребительские свойства насколько возможно. В примере с фонтаном в случае с быстрым падением предупреждающего сообщения вообще выведено не будет. Это сильно лучше, чем очевидно некорректное «Осторожно! Пожалуйста, пейте воду из фонтана»? Предупреждение с непонятным текстом как минимум насторожит. Отсутствие предупреждения — нет.
Вот за что я не люблю эти «постулаты» так это за то, что они решают одни проблемы за счет других. В результате оказывается, что все приложение оказывается неработоспособным из-за маленькой никому не нужной кнопочки в углу экрана. И самое печальное, что я так и не смог убедить «ведущего разработчика», что это не правильно, ибо «fail fast — best practice».
Очень попахивает экстом и его ужасными фичами вида «перегрузка свойств в конструкторе» и «автосоздание вьюшек по конфигам». Тем не менее есть и много свежих идей.
Смутило, что вы удаляете элелементы, а потом добавляете в нужном порядке. Это конечно очень просто, но ресурсоёмко и теряет фокус. Я у себя пробегаюсь по спискам и трогаю элементы только если их действительно надо переместить.
Также я не разделяю эту любовь к requireJS. Какая разница будет у вас глобальная переменная или же зарегистрированный модуль, который доступен по глобальному имени? Те же глобальные переменные, но зачем-то спрятанные в недра глобальной функиции require. Относительные пути — это тоже зло, потому что при переносе модуля нужно фигурно исправлять относительные ссылки в него и из него. Лучше ссылаться ко всем модулям по глобальному имени и при переносе просто пробегаться реплейсом по всем файлам. Просто и надёжно. И если не плодить иерархию сверх меры, то вполне юзабельно.
Наоборот. При некорректных значениях программа работает непредсказуемо. И если в более иных случая программа завершится, то яваскрипт продолжит жить «своей жизнью» и например может уничтожить друды последних десяти минут пользователя, что мы часто наблюдаем на многочисленных кривых веб-страницах.
Зачем же бросаться из крайности в крайность? Разрабатывайте микромодули. Подключайтесь) github.com/nin-jin/pms-jin
Каждый модуль имеет максимум 10кб исходного кода. Можно сбилдить любой набор модулей со всеми их зависимостями. Например, библиотека $jin.atom (http://hyoo.ru/?article=%D0%90%D1%82%D0%BE%D0%BC%D1%8B+%D0%BD%D0%B0+JS;author=Jin) собирается в 20кб ни от чего не зависящих исходников.
Какого уровня? баги то детские. Просто Егор задавался вопросом «а что будет если», а те кто делал авторизацию в гитхабе нет.
Мне вот однажды надо было внедрить санитайзер, который уже использовался много где в яндексе. тоже дырок много понаходил, но заводил сразу баги в джире. Надо ли говорить, что никакого вознаграждения я не получил?) да, Егор, я тебе завидую. Почему то вечно узнаю об этих баунтях лишь когда все уже все нашли(
Кроме того, по ним же с помощью jsduck генерируется документация. При этом приходится дублировать определения в разных нотациях, чтобы это понимала и IDEA и jsduck.
И мне не надо, чтобы функция возвращала ошибку, мне надо, чтобы я мог ей сказать, что в случае определенных ситуаций нужно использовать такую-то стратегию восстановления. На выбор:
1. остановить загрузку всех картинок, написать в консоль ошибку
2. написать в консоль, продолжить грузить остальное
3. попробовать загрузить то же самое с другого домена
4. отложить загрузку на 5 минут
и 100500 других стратегий, про которые библиотека не должна знать превращаясь в кухонный комбайн.
вообще без исключений в календарике я не могу обойтись банально потому, что они сами чуть что возникают в самых интересных местах.
более наглядный пример — есть календарик, он ловит события клика, нажатия на клавиатуру, скролл мышью, прикосновения пальцами и кучу других событий из разных мест. С исключениями приходится в каждый обработчик вставлять try-catch чтобы в случае ошибки календарик не умирал благородной смертью японского самурая. А с доменами можно было бы сделать так: объявяляем домен в котором указываем обработчик ошибок, в этом домене создаем календарик — все обработчики автоматом наследуют домен и в случае любых ошибок раскручиваться будет стек доменов, а не стек исполнения. в ноде как раз долгое время была проблема из-за отсутствия доменов — если разработчик библиотеки, в которой используются асинхронные операции, забыл где-то поставить try-catch, то ронялась вся нода и никак из внешнего кода на это было не повлиять, потому что стек честно раскручивался до конца.
Например, нам нужно собрать проект, для этого мы запускаем параллельно 3 задачи. Если хотябы одна из них упадет, то нужно остановить и другие 2, после чего завершиться с ошибкой. Исключения тут идут лесом. А если нам нужно при указании специального параметра не завершать приложение, а вывести сообщение в консоль, продолжая параллельные задачи, после чего ожидая изменения файлов, после чего запускать только те задачи, которые зависят от измененных файлов?
Исключения — это и правда зло, потому что полагаются на стек. Вместо этого хорошо иметь отдельный стек «доменов» (что-то типа nodejs.org/api/domain.html) и при создании колбэка привязывать к нему текущий домен. А в домене уже при его создании устанавливать стратегию реагирования на исключительные ситуации.
Я бы рекомендовал посмотреть на OrientDB db-engines.com/en/system/Neo4j%3BOrientDB
Как происходила рандомизация и сколько было параллельных А/В тестов?
Как отсекались новые пользователи? Старые пользователи подвержены эфекту новизны, а куки имеют свойство протухать.
Какова статистическая значимость ваших гипотез?
Без всего этого вам не сюда, а в хаб «астрология и эзотерика».
Вот за что я не люблю эти «постулаты» так это за то, что они решают одни проблемы за счет других. В результате оказывается, что все приложение оказывается неработоспособным из-за маленькой никому не нужной кнопочки в углу экрана. И самое печальное, что я так и не смог убедить «ведущего разработчика», что это не правильно, ибо «fail fast — best practice».
Смутило, что вы удаляете элелементы, а потом добавляете в нужном порядке. Это конечно очень просто, но ресурсоёмко и теряет фокус. Я у себя пробегаюсь по спискам и трогаю элементы только если их действительно надо переместить.
Также я не разделяю эту любовь к requireJS. Какая разница будет у вас глобальная переменная или же зарегистрированный модуль, который доступен по глобальному имени? Те же глобальные переменные, но зачем-то спрятанные в недра глобальной функиции require. Относительные пути — это тоже зло, потому что при переносе модуля нужно фигурно исправлять относительные ссылки в него и из него. Лучше ссылаться ко всем модулям по глобальному имени и при переносе просто пробегаться реплейсом по всем файлам. Просто и надёжно. И если не плодить иерархию сверх меры, то вполне юзабельно.
Почитай про мою реализацию: hyoo.ru/?article=%D0%90%D1%82%D0%BE%D0%BC%D1%8B+%D0%BD%D0%B0+JS;author=Jin
Наоборот. При некорректных значениях программа работает непредсказуемо. И если в более иных случая программа завершится, то яваскрипт продолжит жить «своей жизнью» и например может уничтожить друды последних десяти минут пользователя, что мы часто наблюдаем на многочисленных кривых веб-страницах.
Каждый модуль имеет максимум 10кб исходного кода. Можно сбилдить любой набор модулей со всеми их зависимостями. Например, библиотека $jin.atom (http://hyoo.ru/?article=%D0%90%D1%82%D0%BE%D0%BC%D1%8B+%D0%BD%D0%B0+JS;author=Jin) собирается в 20кб ни от чего не зависящих исходников.
Мне вот однажды надо было внедрить санитайзер, который уже использовался много где в яндексе. тоже дырок много понаходил, но заводил сразу баги в джире. Надо ли говорить, что никакого вознаграждения я не получил?) да, Егор, я тебе завидую. Почему то вечно узнаю об этих баунтях лишь когда все уже все нашли(