Прежде всего события самодостаточны. Когда компонент вызывает событие, он не подозревает, получил ли кто-то его или нет. Это свойство позволяет разработчику рассматривать каждый компонент в отдельности, вместо того, чтобы помнить обо всех связях и рассуждать о растущей сложности приложения, как единого целого.
События — не панацея против растущей сложности. Когда нужно смоделировать более-менее сложное взаимодействие 2-х и более компонентов, общение через события может стать той ещё головной болью, и захочется старых-добрых вызовов методов объектов. С событиями код становится чище, а вот разработчику нужно помнить больше, чем если бы в коде было написано «classA.methodB», потому как под записью «this.trigger('someEvent', args)» все равно может предполагаться общение с конкретным компонентом, только теперь про это в коде не написано.
Наконец-то!
Было очень неудобно пользоваться поиском картинок того же гугла, который по клику на картинку из результатов под картинкой подгружал сайт-источник. Во-первых, из-за этого интерфейс тормозил — редкий сайт оптимизируется для быстрой загрузки. Когда нужно просмотреть десяток картинок, чтобы выбрать что-нибудь, нужно загрузить десяток сайтов — то ещё удовольствие. К тому же, я не ищу сайты по картинкам. А если контент все-таки заинтересовал, в новом интерфейсе предусмотрели удобную кнопку для перехода на сайт-источник.
Как? Это такие добрые компании… а вы вебмастера все злые, жадные и вообще SEOшники — скажет типичный пользователь интернета.
Давайте немного подумаем. Реклама, показанная под затемненным фоном, под картинкой, имеет конверсию около 0. Т.е. ни пользователь, ни владелец баннера пользы от этого действия не получают. Зато «щедрые сеошники» получают свои деньги за воздух.
По-моему, сейчас задачи пользователей решаются эффективнее. Если при этом поисковики получают прибыль, а сеошники зарабатывают меньше — так это только потому, что сеошники в действительности решают совсем другие задачи.
Цифры интересные, но несколько не понятно, какой будет результат на разных проектах. Уж точно не те же проценты от объема бинарников. Думаю, будет полезно показать код, который оптимизировался в ходе работа на статьей.
Про то, о чём все знают:
• 80% информации человек воспринимает через зрение.
• Лучше один раз увидеть, чем сто раз услышать.
С этими постулатами никто не спорит.
Все 4 утверждения (80%, увидеть > услышать, все знают, никто не спорит) ничем не обоснованы и крайне спорны. Вы бы хоть ссылку на авторитетный источник поставили, раз считаете, что это очевидно без доказательств.
Второй блок кода (начинается с "(defun start-program ()") совершенно нечитаем. Наверное, его надо по-другому отформатировать, — сейчас создается ощущение, что кто-то в перловом однострочнике наставил переводов строк. :)
2800 постов с 2006 года. Каждый день по посту-другому. :) Надеюсь, это как-то сгенерированно, иначе не ясно, когда товарищь писатель работает над софтом для поездов. :)
P.S. Ну, и гугл в придачу. Очень скрытный человек. :))
Как говорил мой преподаватель, «программу без ошибок можно написать за бесконечно большее время и бесконечно большой бюджет.» :)
По сути: в статье упущено важное разделение на программы, требовательные к высокому уровню надежности, и программы, падение которых не критично. Также забыл автор и про стоимость увеличения надежности, о которой уже столько понаписано и в отечественной и в зарубежной литературе, что голословно утверждать «надо просто делать программы/станки/техпроцессы» без ошибок — непозволительно. :)
Подход к проектированию и реализации критических к надежности систем и систем обычных отличается кардинально, и совершенно не ясно, где автор собрался брать квалифицированных работников, чтобы всегда работать по самым надежным схемам. На чем автор написал примеры кода в статье? Не на PHP ли?;)
2 цвета — это от бедности соот. утилит. Консоль может красивой и удобной, если её хорошо приготовить, что и пытается сделать автор. Правда, я так и не смог приготовить виндоcmd, чтобы в нем было действительно удобно работать. :(
Зато в линуксе — красота:
Хабр читают много где. В таком случае, стоило бы написать суммы и в зайчиках, и в гривнах, юанях и т.п. Правда, это обзор российского рынка российской компанией. ;) Оцените 100000 руб в $, и оценить порядок цен станет значительно проще относительно этой цифры.
Очень сложно сейчас оценить последствия создания такой колонии. А вот в средне-ближайшем времени — это проект, который может объединить многих людей на Земле.
Сама идея перехода космической отрасли в руки гражданских организаций — плодотворна. Такой проект может быть хорошим началом для массового изменения отрасли. В конце-концов, значительная часть вещей и сервисов, которыми мы сейчас пользуемся, были сделаны в военных целях военными людьми, а после ушли в гражданский сектор, где и развились до технологий, к которым мы так привыкли и не замечаем крайней сложности решений (самолеты, интернет, gps и т.п.)
Такой проект стоит рассматривать как процесс, а не как конечный результат — «80 тыс. человек на Марсе к 20xx году».
События — не панацея против растущей сложности. Когда нужно смоделировать более-менее сложное взаимодействие 2-х и более компонентов, общение через события может стать той ещё головной болью, и захочется старых-добрых вызовов методов объектов. С событиями код становится чище, а вот разработчику нужно помнить больше, чем если бы в коде было написано «classA.methodB», потому как под записью «this.trigger('someEvent', args)» все равно может предполагаться общение с конкретным компонентом, только теперь про это в коде не написано.
Было очень неудобно пользоваться поиском картинок того же гугла, который по клику на картинку из результатов под картинкой подгружал сайт-источник. Во-первых, из-за этого интерфейс тормозил — редкий сайт оптимизируется для быстрой загрузки. Когда нужно просмотреть десяток картинок, чтобы выбрать что-нибудь, нужно загрузить десяток сайтов — то ещё удовольствие. К тому же, я не ищу сайты по картинкам. А если контент все-таки заинтересовал, в новом интерфейсе предусмотрели удобную кнопку для перехода на сайт-источник.
Давайте немного подумаем. Реклама, показанная под затемненным фоном, под картинкой, имеет конверсию около 0. Т.е. ни пользователь, ни владелец баннера пользы от этого действия не получают. Зато «щедрые сеошники» получают свои деньги за воздух.
По-моему, сейчас задачи пользователей решаются эффективнее. Если при этом поисковики получают прибыль, а сеошники зарабатывают меньше — так это только потому, что сеошники в действительности решают совсем другие задачи.
Все 4 утверждения (80%, увидеть > услышать, все знают, никто не спорит) ничем не обоснованы и крайне спорны. Вы бы хоть ссылку на авторитетный источник поставили, раз считаете, что это очевидно без доказательств.
P.S. Ну, и гугл в придачу. Очень скрытный человек. :))
По сути: в статье упущено важное разделение на программы, требовательные к высокому уровню надежности, и программы, падение которых не критично. Также забыл автор и про стоимость увеличения надежности, о которой уже столько понаписано и в отечественной и в зарубежной литературе, что голословно утверждать «надо просто делать программы/станки/техпроцессы» без ошибок — непозволительно. :)
Подход к проектированию и реализации критических к надежности систем и систем обычных отличается кардинально, и совершенно не ясно, где автор собрался брать квалифицированных работников, чтобы всегда работать по самым надежным схемам. На чем автор написал примеры кода в статье? Не на PHP ли?;)
Зато в линуксе — красота:
На тему: tema.livejournal.com/1197434.html
Сама идея перехода космической отрасли в руки гражданских организаций — плодотворна. Такой проект может быть хорошим началом для массового изменения отрасли. В конце-концов, значительная часть вещей и сервисов, которыми мы сейчас пользуемся, были сделаны в военных целях военными людьми, а после ушли в гражданский сектор, где и развились до технологий, к которым мы так привыкли и не замечаем крайней сложности решений (самолеты, интернет, gps и т.п.)
Такой проект стоит рассматривать как процесс, а не как конечный результат — «80 тыс. человек на Марсе к 20xx году».