Это понятно, но куда они все едут и почему не на работе (грузовики-автобусы-спецтехника, естественно, не в счёт)? Если бы в час пик было 9 баллов пробок, а в 14 часов, например, — 1-2, то было бы понятно. А так даже днём свободных дорог почти никогда не бывает.
А в последнее время ещё один вопрос добавился с к выше перечисленным: куда они едут, где они будут парковаться (при повсеместной ограниченной по количеству машиномест и платной парковке на улицах)?
По поводу Модели-Фасада: понятно, что любой более-менее нетривиальный UI-компонент имеет достаточно сложный «бэкэнд», что бы его можно было реализовать одним пассивным объектом.
Тут ещё другой момент, который я имел в виду:
Методы Модели-Фасада для того или иного компонента могут возвращать сложные объекты. Так вот, архитектурная проблема: имеют ли право методы Фасада возвращать ссылки на объекты, доступные из других фасадов, который этот Фасад скрывает (и в конце концов, ссылки на конкретные пассивные объекты, которые содержат данные)? Или Фасад должен возвращать только объекты-Прокси для доступа к реальным объектам? Или ещё как-то?
А например в случае JSON, для того же ls -R, как выводить: в виде единого массива с именами файлов, содержащих частичные пути, или в виде древовидной структуре, где массивы файлов подкаталогов доступны как значение объекта соответствующего записи родительского каталога. А если делаем ls -R tmp/…, то в JSON-
аналоге выдачи «tmp/..» разбивать элементы пути на компоненты? И давать ли JSON инфу про каталог, которому соответствует ".."? Уже получается 3 дополнительных опции.
Куда как проще использовать скриптовой язык, как и предлагает Пайк. :-D
Не увидел в статье, а есть ли поправки на ситуацию: «разработчик занимается чем-то, что зарегал в системе управления задачами, тут приходят и отвлекают его по теме задачи, сданной N месяцев назад, — по срочному вопросу (не работает/сломалось/не понятно и т.п.)». В результате разработчик отвлекается от текущей задачи на N минут, потом погружается обратно в контекст. По идее, такие расходы времени должны идти не в текущий проект, а в проект, по которому был задан срочный вопрос.
Спасибо за отличный анализ, жду вторую часть про контроллеры. :)
Сам не вытерпел и решил посмотреть, «как же было в оригинале». Нашёл статью некоего S. Burbeck: http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf 1992 года.
По результату прочтения несколько моментов.
В вашей статье есть какой-то акцент на применении Facade для реализации Модели. Burbeck же пишет, что Моделью может быть любой объект Smalltalk, просто при использовании «тупых объектов» — т.н. «пассивной Модели» мы не получаем функционал оповещения Вида при изменениях.
То есть по факту, разделение объектов на Модель-Вид-Контроллер в Smalltalk довольно тонко заточено именно под тамошнюю оконно-графическую модель. И Модель в отрыве от виджета (который состоит из пары Вид-Контроллер) не несёт никакого особого смысла — это просто объект Smalltalk (возможно, составной).
Соответственно, получается, что разделение UI на Вид и Контроллер в отрыве от соответствующей графической (точнее, UI-) библиотеки бессмысленно. А в рамках конкретной библиотеки может существовать другое деление, в т.ч. на бОльшее количество компонентов. Насколько я понял из вышеприведённой, в контексте Smalltalk это разделение позволяло повторно использовать одинаковые Контроллеры разными Видами, причём основной функционал Контроллера, кроме примитивной маршрутизации событий в стандартизованные сообщения, заключался в трансляции экранных координат мыши в локальные оконные — путём опроса соответствующих Видов. Этот функционал похож у многих виджетов, поэтому логично было выделить его из кода, описывающего конкретный UI.
Ещё интересная тема — иерархический MVC (HMVC — он же PAC), где контроллер выделяется как маршрутизатор всех событий компонента, а не только UI`шных.
Само определение в статье, которую вы предложили, уже содержит как минимум одно «и/или» (размер регистров и/или размер шины данных). И потом, можно перебирать разные регистры. Итак, на самой популярной десктопной архитектуре, каков размер слова? 8? 16? 32? 64? 80? 128? 256? Или 512 бит?
Ну и, например, в контекте языка unix shell, word — совсем другое. :)
Либо я не читал статью нормально, либо не понял. Кто разобрался, подскажите, плз.
Как исследователи исключили гипотезу: «те, у кого изначально высокая самооценка, даже несмотря на то, что они стали большой рыбой, избегают переходить в более крупные пруды»?
Я думаю, вполне можно применять этот термин. В демократии в реальном мире мы также не несём материальных затрат, например, на биологическое разнообразие, на состояние пастбищ, на наличие полезных ископаемых и т.п. Да и просто законы физики нам не поменять. Нам происхождение этих ресурсов неподвластно также, как и пространства сайтов с репутацией. И тем не менее нам даются какие-то возможности контролировать то, что происходит на этих пространствах. Просто если в реальном мире эти возможности даны предыдущими поколениями политиков, то в случае сайтов — их владельцами.
Не забывайте, что демократия — это власть демократов джентльменов с мушкетами и кольтами. По хорошему, любую грядку нужно не только засевать, но и полоть, что бы из неё получилось что-то дельное.
Проблема репутационных систем в том, что, как и системы с другим каким-то неравенством (деньги, происхождение и т.п.), они дают власть людям, которые могут оказаться не настолько чисты в помыслах, как задумывалось.
Даже, если бы пользователям с репутацией 1 дали проголосовать и забанить супертроллей, это вряд ли помогло бы, т.к. простому человеку (во всяком случае, не разбирающемуся в политике и дипломатии) проще уйти (проголосовать ногами), чем сагитировать десяток других.
Возможно, что описанную в статье проблему SO исправило бы, если бы эта база знаний была распределённой, по принципу P2P. Тогда человек — член сети, уходя ногами от тролля, также переставал бы поддерживать не только его карму, но и саму информацию о его былых заслугах, так что уход даже 10 человек мог бы эффективно забанить тролля. Проблема тут только в том, что бизнес-модель сайтов вроде SO не предусматривает распределённости. Кроме того, можно вспомнить имевшее место быть борцунство сисопов в Фидонете при тамошней демократии.
А с Angular2 удалось добиться выполнения требований «менее связная архитектура», «чёткое разделение зон ответственности», «не являющийся всё-в-одном», а также удалось ли сохранить пункт в стратегии перехода «старый код не трогаем, новый встраиваем независимыми блоками»?
Может, есть какой-то «тестовый набросок» того, в каком виде у вас Angular2 применяется?
Также присоединяюсь к ораторам, просящим статью на эту тему.
> Во-вторых, мы с вами заинтересованы в рождении как можно большего числа детей сейчас хотя бы с точки зрения нашей будущей пенсии. По крайней мере с ними шанс получить её у нас выше.
Непонятно, из каких наблюдений вы эту взаимосвязь («дети — повышенная вероятность нормальной пенсии») выдумали. Посмотрите на наклон графика на страничке https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%A1%D0%A1%D0%A1%D0%A0 и объясните, почему же тогда в 90х такой «швах» с пенсиями был?
> люди преодолевали такие сложности ради собственной мечты, а я вот уже больше года живу с пустой головой и без мечты.
На самом деле, если приглядеться, то все успешные достижения сделаны не только ради абстрактной мечты, но и ради вполне конкретных и теоретически-достижимых результатов (и топикстартер тому пример).
Так что, как сам практически «с пустой головой и без мечты», желаю побыстрее определиться, ради чего живёте и достигать, достигать! (сам-то я в процессе..) :)
Инвестиционные монеты — тоже фантики, даже в таких странах как США (после New Deal). Захочет государство типа США у вас их отжать — выпустит указ, что завтра ты их под страхом тюрьмы должен обменять на свои бумажные (или электронные) фантики по определённой цене и «привет» :)
А какая цель тогда у текущих соревнований? Мы видим картинку с каким-нибудь ликующим Лэнсом Армстронгом пересекающим финишную черту и не догадываемся что победитель — грустный чувак на велике позади. Вопрос: для чего мы смотрели — для сопричастности к ликованию победителя, обхитрившего всех лузеров позади него, или для того, что бы через N лет узнать: о, так вот, кто победил-то тогда.
Я уж не говорю про лицемерие олимпийских игр: мол, у нас игры любителей. Которые при этом «любительстве» в большинстве видов спорта ничем кроме спорта в жизни не зарабатывают — иначе невозможно конкурировать.
А в последнее время ещё один вопрос добавился с к выше перечисленным: куда они едут, где они будут парковаться (при повсеместной ограниченной по количеству машиномест и платной парковке на улицах)?
По поводу Модели-Фасада: понятно, что любой более-менее нетривиальный UI-компонент имеет достаточно сложный «бэкэнд», что бы его можно было реализовать одним пассивным объектом.
Тут ещё другой момент, который я имел в виду:
Методы Модели-Фасада для того или иного компонента могут возвращать сложные объекты. Так вот, архитектурная проблема: имеют ли право методы Фасада возвращать ссылки на объекты, доступные из других фасадов, который этот Фасад скрывает (и в конце концов, ссылки на конкретные пассивные объекты, которые содержат данные)? Или Фасад должен возвращать только объекты-Прокси для доступа к реальным объектам? Или ещё как-то?
аналоге выдачи «tmp/..» разбивать элементы пути на компоненты? И давать ли JSON инфу про каталог, которому соответствует ".."? Уже получается 3 дополнительных опции.
Куда как проще использовать скриптовой язык, как и предлагает Пайк. :-D
> У них, видимо, был только ассемблер и текстовый редактор.
Ассемблер с редактором Томпсон тоже сам написал, на GECOS системе.
Сам не вытерпел и решил посмотреть, «как же было в оригинале». Нашёл статью некоего S. Burbeck: http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf 1992 года.
По результату прочтения несколько моментов.
В вашей статье есть какой-то акцент на применении Facade для реализации Модели. Burbeck же пишет, что Моделью может быть любой объект Smalltalk, просто при использовании «тупых объектов» — т.н. «пассивной Модели» мы не получаем функционал оповещения Вида при изменениях.
То есть по факту, разделение объектов на Модель-Вид-Контроллер в Smalltalk довольно тонко заточено именно под тамошнюю оконно-графическую модель. И Модель в отрыве от виджета (который состоит из пары Вид-Контроллер) не несёт никакого особого смысла — это просто объект Smalltalk (возможно, составной).
Соответственно, получается, что разделение UI на Вид и Контроллер в отрыве от соответствующей графической (точнее, UI-) библиотеки бессмысленно. А в рамках конкретной библиотеки может существовать другое деление, в т.ч. на бОльшее количество компонентов. Насколько я понял из вышеприведённой, в контексте Smalltalk это разделение позволяло повторно использовать одинаковые Контроллеры разными Видами, причём основной функционал Контроллера, кроме примитивной маршрутизации событий в стандартизованные сообщения, заключался в трансляции экранных координат мыши в локальные оконные — путём опроса соответствующих Видов. Этот функционал похож у многих виджетов, поэтому логично было выделить его из кода, описывающего конкретный UI.
Ещё интересная тема — иерархический MVC (HMVC — он же PAC), где контроллер выделяется как маршрутизатор всех событий компонента, а не только UI`шных.
Ну и, например, в контекте языка unix shell, word — совсем другое. :)
http://static.existentialcomics.com/comics/philosophyFriends1.png
http://static.existentialcomics.com/comics/philosophyFriends2.png
Как исследователи исключили гипотезу: «те, у кого изначально высокая самооценка, даже несмотря на то, что они стали большой рыбой, избегают переходить в более крупные пруды»?
демократовджентльменов с мушкетами и кольтами. По хорошему, любую грядку нужно не только засевать, но и полоть, что бы из неё получилось что-то дельное.Проблема репутационных систем в том, что, как и системы с другим каким-то неравенством (деньги, происхождение и т.п.), они дают власть людям, которые могут оказаться не настолько чисты в помыслах, как задумывалось.
Даже, если бы пользователям с репутацией 1 дали проголосовать и забанить супертроллей, это вряд ли помогло бы, т.к. простому человеку (во всяком случае, не разбирающемуся в политике и дипломатии) проще уйти (проголосовать ногами), чем сагитировать десяток других.
Возможно, что описанную в статье проблему SO исправило бы, если бы эта база знаний была распределённой, по принципу P2P. Тогда человек — член сети, уходя ногами от тролля, также переставал бы поддерживать не только его карму, но и саму информацию о его былых заслугах, так что уход даже 10 человек мог бы эффективно забанить тролля. Проблема тут только в том, что бизнес-модель сайтов вроде SO не предусматривает распределённости. Кроме того, можно вспомнить имевшее место быть борцунство сисопов в Фидонете при тамошней демократии.
Может, есть какой-то «тестовый набросок» того, в каком виде у вас Angular2 применяется?
Также присоединяюсь к ораторам, просящим статью на эту тему.
Непонятно, из каких наблюдений вы эту взаимосвязь («дети — повышенная вероятность нормальной пенсии») выдумали. Посмотрите на наклон графика на страничке https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%A1%D0%A1%D0%A1%D0%A0 и объясните, почему же тогда в 90х такой «швах» с пенсиями был?
На самом деле, если приглядеться, то все успешные достижения сделаны не только ради абстрактной мечты, но и ради вполне конкретных и теоретически-достижимых результатов (и топикстартер тому пример).
Так что, как сам практически «с пустой головой и без мечты», желаю побыстрее определиться, ради чего живёте и достигать, достигать! (сам-то я в процессе..) :)
Я уж не говорю про лицемерие олимпийских игр: мол, у нас игры любителей. Которые при этом «любительстве» в большинстве видов спорта ничем кроме спорта в жизни не зарабатывают — иначе невозможно конкурировать.
Кстати, в фантастике есть популярный сюжет, что люди получают гражданство не по рождению, а, например, отслужив в армии или сдав экзамен.