Из всех пунктов интересен, пожалуй, только первый. Остальное не впечатлило, но эта мысль хорошая — в игре развитие либо строго линейное, либо псевдо-нелинейное в рамках ограниченного набора линейных алгоритмов, заложенных туда разработчиком. В жизни же бескрайнее поле любых возможностей. Каждая секунда потраченного в игре времени лишь двигает игрока из точки А в точку Б по заданной траектории, которой идут все; а в жизни эту секунду можно потратить на возможность изменить что-то в себе или в мире так, как оно никем другим никогда не было бы изменено, если бы не усилие этого конкретного человека.
Выбор геймера не в том, в каком мире жить, а в том, жить ли в запрограммированном мире или же программировать мир.
Не соглашусь, что ваш пример демонстрирует эти же штуки. Одно дело — просто распределить файлы по подкаталогам, и совсем другое — моделировать с помощью дерева файлов иерархию связей между компонентами. Ваш пример — это такая же одноуровневая плоская структура, просто с подкаталогами внутри.
tamtakoe наверное имеет в виду, что вам придется выдирать этот модуль из дерева несколько раз, так как у вас несколько точек входа в один и тот же модуль (controllers, services, directives, и т.д.). Это повышает риск чего-то где-то забыть или сделать не так, по сравнению с тем, как если бы точка входа была одна, а структура делилась бы по функциональности, а не по типу.
А еще в рекурсивной структуре удобно делать вот такие штуки:
В вашей же структуре это все будет на одном плоском уровне. Про себя скажу, что я где-то года полтора назад ушел с подобного вашему подхода, когда понял, что он не дает масштабировать большое приложение, и очень рад, что ребята из AngularJS наконец-то сами подтвердили, что структура Angular Seed неэффективна для больших SPA-приложений.
Забыл упомянуть, что речь идет, естественно, о SPA-приложениях — то есть о том, для чего в первую очередь создавался AngularJS и на что он заточен. Просто последние 2 года я пишу только их и поэтому уже подзабыл, что нынче кто-то еще делает иначе.
Смысл в том, что в рекурсивной многоуровневой модульной структуре отдельным юнитом считается не программная сущность, а кусок функциональности проекта. Все html и css/less/sass (и иногда даже картинки и прочие файлы) хранятся вместе с соответствующими js и их тестами, чего нет смысла делать, когда у вас в структуру проекта введены чисто программные понятия вроде controllers и services. Это невероятно повышает читаемость проекта и эффективность разработки, не надо постоянно лазить по дереву файлов, большинство юнитов получаются хорошо инкапсулированными. Попробуйте, вам понравится.
Чтобы судить о недостатках, нужно попробовать разные подходы. Вы сначала попробуйте структуру, которую официально советуют разработчики AngularJS по приведенной мной ссылке выше, и тогда уже можно будет сравнивать.
Angular Seed структурирует код, разделяя файлы по назначению.
Хотя такой подход может быть неплохим начальным пособием для наглядности, никогда не делайте так в реальных проектах средних и больших размеров. Больше информации по теме в блоге AngularJS:
Судя по вашему профилю, вы не связаны с веб-разработкой, отсюда и.
Статья предназначена для тех, кто все-таки как-то крутится именно в этой части ИТ-индустрии, а среди них количество незнающих, что такое Landing Page, близко к нулю.
По поводу третьего пункта: если каждый разработчик будет иметь свой форк проекта на гитхабе, и делать пул-реквест не из одной ветки origin repo в другую, а из своей ветки в своем репозитории в мастер основного репозитория, то тогда проблемы с доступами легко решаются средствами гитхаба. Плюс это дает больше понимания, над чем трудится каждый человек. Давать всем разработчикам полный доступ на создание веток в основном репозитории не всегда полезно и может привести к бардаку.
Программиста нет, все программы появились из случайного шума в машинном коде. У программ нет никакой функции и смысла, и глюков в них тоже вообще нет, так как не описаны правила их работы. Постепенная деградация производительности программы есть нормальный процесс ее замедленной деинсталляции. После деинсталляции программа уничтожается без возможности восстановления.
Google+ никогда и не претендовала на то, чтобы стать «нормальной социальной сетью». И это очень хорошо, потому что G+ замечательно подходит тем, кому «нормальные социальные сети» не особо и нужны, как Брину.
Раз уж упомянули про квесты, то в пост призывается хабраюзер Antorix, который придумал и написал большинство игровых и движковых текстовых квестов (указанные в посте — вроде бы его), почти все названия внутриигровых предметов и локаций, легенду, историю и дух каждой расы, и много где еще по сюжету и атмосфере участвовал.
В стабах может использоваться как верификация поведения (например, ожидание вызова методов), так и верификация состояния (вызвали, посмотрели на изменившуюся переменную), причем второе используется чаще. В моках — только верификация поведения. Предназначение у них одинаковое.
Для господ заминусовавших, видимо разделяющих незнание автора статьи — никто не пишет определение провайдера с именем CarProvider, у него должно быть имя Car, так как он определяет инжектируемую сущность, а не класс провайдера. Автор сам пошел неправильным путем, написав CarProvider, после чего должен пенять на собственную глупость, а не на странную получившуюся в итоге инжектируемую сущность CarProviderProvider.
Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer)
Ангуляр действительно хорошо подходит под SPA, только SPA — это совсем не то, что вы описали, а приложение вида «толстый клиент», где страницы рендерятся браузером, и где переходы по урлам (а они там, разумеется, есть) обрабатываются клиентом, а не сервером. И Google Docs Writer, и GitHub, и Gmail, и Twitter, и любое другое приложение с "#!" (или HTML5 History API, как на гитхабе) замечательно пишется на ангуляре.
Реальное различие между ангуляром и эмбером в другом. Эмбер — это чистый фреймворк «из коробки», а ангуляр — это скорее метафреймворк, то есть такой фреймворк для написания своего фреймворка. Это подходы с разных уровней, у ангуляра он более широкий и в конечном счете включает в себя всё, что может дать Эмбер. А конечные юзкейсы приложений у них совершенно одинаковые.
Выбор геймера не в том, в каком мире жить, а в том, жить ли в запрограммированном мире или же программировать мир.
А еще в рекурсивной структуре удобно делать вот такие штуки:
В вашей же структуре это все будет на одном плоском уровне. Про себя скажу, что я где-то года полтора назад ушел с подобного вашему подхода, когда понял, что он не дает масштабировать большое приложение, и очень рад, что ребята из AngularJS наконец-то сами подтвердили, что структура Angular Seed неэффективна для больших SPA-приложений.
en.wikipedia.org/wiki/Single-page_application
Забыл упомянуть, что речь идет, естественно, о SPA-приложениях — то есть о том, для чего в первую очередь создавался AngularJS и на что он заточен. Просто последние 2 года я пишу только их и поэтому уже подзабыл, что нынче кто-то еще делает иначе.
Хотя такой подход может быть неплохим начальным пособием для наглядности, никогда не делайте так в реальных проектах средних и больших размеров. Больше информации по теме в блоге AngularJS:
docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
Плохо программы не пиши. Плохие программы работают хуже, чем хорошие.
Статья предназначена для тех, кто все-таки как-то крутится именно в этой части ИТ-индустрии, а среди них количество незнающих, что такое Landing Page, близко к нулю.
Ангуляр действительно хорошо подходит под SPA, только SPA — это совсем не то, что вы описали, а приложение вида «толстый клиент», где страницы рендерятся браузером, и где переходы по урлам (а они там, разумеется, есть) обрабатываются клиентом, а не сервером. И Google Docs Writer, и GitHub, и Gmail, и Twitter, и любое другое приложение с "#!" (или HTML5 History API, как на гитхабе) замечательно пишется на ангуляре.
Реальное различие между ангуляром и эмбером в другом. Эмбер — это чистый фреймворк «из коробки», а ангуляр — это скорее метафреймворк, то есть такой фреймворк для написания своего фреймворка. Это подходы с разных уровней, у ангуляра он более широкий и в конечном счете включает в себя всё, что может дать Эмбер. А конечные юзкейсы приложений у них совершенно одинаковые.