Представьте что вы делает компоненту на ангуларе, которую можно будет использовать на разных страницах. И тут возникает проблема, какое должно быть связывание разовое или нет. Как разработчик компоненты вы не можете этого решить потому, что это зависит от использования и будет или нет меняться модель. Это дополнительный параметр, причем чем сложнее модель, тем больше таких дополнительных параметров. Это очень плохо.
Поразительно, но как раз к 35 воля и подводит некоторых. Семья становится больше, работа ответственнее, первые проблемы со здоровьем появляются. Груз такой большой, что никакой воли не хватит, что-то изменить. Да и зачем? Ведь ты так долго к этому шел.
Я бы хотел добавить, что библиотеки на Clojure довольно компактные по размерам и доступные для понимания. В отличии от, например, Spring из Java код Ring и Compojure приятно читать и он, что удивительно, простой. Мне лично для работы с Clojure помог сайт http://www.4clojure.com/ всем начинающим я рекомендую порешать задачки оттуда.
Что-то мне подсказывает, что методы написания Windows и Doom были довольно продвинутыми. Иначе, почему они получили оглушительный успех? А если успех не зависит от методов работы, то может и идиотов не надо гнать из профессии.
Сильные разработчики имеют очень большое влияние на коллектив. Да они могут не заниматься административной рутиной, но разработкой они управляют, и в некотором смысле являются менеджерами. Много сильных разработчиков вместе могут порвать команду в клочья и надо искать баланс между лидерами сильными программистами и ведомым молодыми дарованиями. С опытом лидерские навыки редко развиваются, они либо есть, либо их нет, возможно, поэтому способность стать сильным разработчиком не зависит от лет опыта.
Есть куча характеристик, показатели которых можно измерять для Rust и Go. И в этом смысле определять соперничество.
То, что они предназначены для разных областей, не значит что они не являются соперниками. Просто один другому однозначно проигрывает в популярности, в зависимости от сферы применения.
И ничего нет, например, о атаках по времени при обработке токена. Что токен должен быть разделен на две части, по одной из которых идет поиск токена с защитой от таких атак, а по другой проверка на валидность.
Разве добавление хэша в идентификатор сессии не является тем самым делением его на 2 части, содержащую данные и проверяющую валидность.
Я ищу решения, но иногда проще поменять фреймворк, чем постоянно искать решения. Хорошо, что пока я не видел нерешаемых с помощью angular проблем, поэтому и использую.
Это хороший пример.
Но ломается, когда сначала задать дефолтовое изображение для которого не нужен кроппер, а потом поменять. В итоге я должен учитывать, когда выполняется директива и на что реагирует. Все это решаемо, но создает сложности.
У меня такая же ситуация с Angular. Полгод разрабатываю на Angular и до сих пор есть проблемы с service — factory — provider, со скопом директив, с банальным реюзом методов моделей. Да и с производительностью у него не ахти, я не нашел ни одного хорошего примера бесконечного списка, уже на 1000-1500 позиций большинство начинает безбожно тормозить. Тот же ng-repeat для больших таблиц с часто меняющимися данными не вариант. А когда приходится разбирать чужой код, там вообще финиш потому, что одни и те же вещи можно сделать очень разными способами и если не следить за псевдо глобальными переменным в rootscope получается страшная лапша.
Я не знаю, как Google, но Яндекс точно делает свои карты и у него есть собственный штат картографов. Я правда не в курсе какими чужими картами он пользуется. Так, что Яндекс не ограничивается фиолетовой частью.
Документацию повторять не хотелось, поэтому я привел пример только одного конструктора ST_Point. Из возможностей ограничился хранением OSM базы в postgres. Понятно, что за рамками осталось очень много, но всего сразу не охватить.
Еще совсем недавно качество OSM картографической базы было неудовлетворительным для промышленного использования. Возможно уже скоро рендеринг и поиск значительно улучшаться. И не последнюю роль в этом сыграет правильное позиционирование.
То, что они предназначены для разных областей, не значит что они не являются соперниками. Просто один другому однозначно проигрывает в популярности, в зависимости от сферы применения.
Разве добавление хэша в идентификатор сессии не является тем самым делением его на 2 части, содержащую данные и проверяющую валидность.
Но ломается, когда сначала задать дефолтовое изображение для которого не нужен кроппер, а потом поменять. В итоге я должен учитывать, когда выполняется директива и на что реагирует. Все это решаемо, но создает сложности.
Если изображения нет, то он неправильно инициализируется, поэтому удобно навешивать его после того, как ангулар загрузит данные об изображении.
В простом случае все понятно, но это не опровергает того, что ангуляр сложный, непонятный, запутанный фреймворк.
Что подразумевается под обработчиками? Если речь о бизнес логике, то это не очень хорошее решение.
Иногда jQuery плагин удобнее навешивать после загрузчки данных, когда уже произошла линковка директив и отработал контроллер. Тут надо исхитряться.
Использовать сервисы как конструкторы, довольно неудобно. Приходится изворачиваться, так как сервисы синглетоны.
Статья как раз о том, чтобы делать и поддерживать сложные SPA. С простыми проблем нет, и автор специально подчеркивает этот момент.