В Ангуляре, дочерняя область видимости обычно прототипически наследуется от родительской. Единственным исключением является директива, в которой используется scope: { ... }, создающая «изолированную» область видимости, не наследуемую прототипически. Такая конструкция часто используется при создании директив для компонентов «многоразового использования»
Вместо предисловия скажу, что есть такой сайт yeoman.io, где собраны наиболее популярные технологии, автоматизирующие разработку фронтенда (сборку, параметризацию CSS и проч.). Обратите на него внимание в начале работы над проектом.
Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.
Самые непристойные и отвратительные наши поступки, выходящие за всякие нормы морали и принципов, обычно начианаются со слов «А почему бы и нет?».
В данном посте я затрону вопросы проектирования приложения на AngularJS, философии, его архитектуры, сборки, пройдусь по разным полезным библиотекам и готовым архитектурным шаблонам. В довершение устрою небольшую Angular+Require.js+Grunt+Yeoman оргию, которую я назвал Angular-Super-Seed или чуть более скромно ASS-генератор.
Так что, если вы планируете писать приложение на Angular, то почему бы и нет?
Мотивация
«Поступай с людьми так, как хотел бы, чтобы поступили с тобой». Вдруг кому-то пригодится
Узнать что-нибудь новенькое как о себе, так и о разработке в комментариях.
У многих .NET разработчиков, использовавших в своей практике WPF, Silverlight или Metro UI, так или иначе возникал вопрос «а как можно упростить себе реализацию интерфейса INotifyPropertyChanged и свойств, об изменениях которых нужно сигнализировать?».
Самый простой «классический» вариант описания свойства, поддерживающего оповещение о своем изменении, выглядит так:
И самое интересное, как всегда, в комментариях — чистой воды холивар. Но из-за чего? Почему одни свято верят в методологию БЭМ'а, другие презирают её как узурпатора семантичности? Я попробую изложить свою точку зрения на суть всего холивара и прояснить в первую очередь для себя положение БЭМ'а в собственном мироздании.
Некоторое время назад на просторах сети столкнулся с интересной библиотекой Breeze.js. Первая мысль, которая пришла на ум при взгляде на неё: «Да это же как Entity Framework для браузера». В поисках информации и отзывов других пользователей, конечно, первым делом поискал статью на Хабре, но не нашёл, поэтому и решил написать, в надежде, что кому-нибудь это тоже будет полезным. Статья написана в виде tutorial по созданию проекта на основе Breeze.js, Angular.js, ASP.NET Web API и Entity Framework.
Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 2008го, и опыта хорошего и плохого у меня накопилось достаточно много. Цель данной публикации — показать разницу между простыми сотрудниками и фрилансерами, а также — показать основные организационные проблемы, которые возникают при разработке и проектировании программного обеспечения. Я надеюсь, что этот пост поможет прояснить некоторые производственные моменты, которые могли бы быть не совсем очевидны для разработчиков и их руководства.
Суждения в данной статье субъективны — сплошная концентрированная «отсебятинка».
Они основаны на моём личном опыте и опыте людей с которыми я общаюсь.
«Как защитить код своего .net приложение?» – один из тех вопросов, который можно часто услышать на различных форумах.
Самый распространённый вариант – обфускация. С одной стороны — прост в использовании, а с другой — не достаточно надёжно прячет исходники. Предложу свой вариант, хорошо подходящий для утилит, использование которых предполагается самим автором (либо доверенным лицам), код которых показывать нежелательно.
Защита будет строиться на шифровании сборок симметричным ключом и динамическом их дешифровании в процессе работы приложения. Ключ шифрования будет определяться пользователем на этапе развёртывания и вводиться как пароль при запуске.
Самые непристойные и отвратительные наши поступки, выходящие за всякие нормы морали и принципов, обычно начианаются со слов «А почему бы и нет?». 
