Linux используют — потому что Маки дорогие, а так же те, кто ни смог переучить горячие клавиши. OS X Лучшая среда разработки для популярных ЯП в настоящее время.
Вот если бы Инстаграмм написал и опубликовал свою систему непрерывного развертывания или хотя бы мануал составил как ее собрать из готовых компонентов, был бы повод заинтересоваться, а так, банальщина и пустозвонство. Ни статистики, ни выводов.
По мнению инженеров Instagram, реализовать подобный проект под силам ИТ-департаментам многих компаний
А по мнению Киосаки, Гандапаса и менеджера из Форекс клуба, стать миллионером может каждый.
В Питере давным давно поезда ездили автоматически, правда оказалось что машинисты, сидящие для подстраховки, часто спали, поэтому систему ликвидировали
Писал как-то в поддержку MAPS.ME, что не находит «Большой пр. П.С.», на что мне ответили, что правильно набирать «Большой пр п с». С тех пор не пользуюсь приложением.
Понимаю, что сделать нормальный поиск по базе сложно, но то, что компания и не думает этим заниматься, а надеется, что пользователи будут искать по их шаблонам — клиника. MAPS.ME ожидает судьба ссылочных каталогизаторов после прихода на рынок поисковиков.
Это то же самое, что процессоры A8, A9..., топологию которых разрабатывает Apple (уверен, там тоже используются сторонние блоки), а сборка осуществляется в Китае. Но у нее хоть продукт хороший получился, а у нас, как понял, не лучше аналогов и цена не меньше будет. И сборка не на собственных линиях. В чём тогда смысл такой отечественной разработки?
Тут проще мобильное приложение написать, которое будут моментально работать, чем содержать команду, которая будет поддерживать всё это js-ное говно без фреймворков
Но до той поры я бы предпочёл использовать обходиться без фреймворков, по крайней мере в мобильном сегменте.
Если кому-то так важна производительность в мобильном сегменте, то нужно не js-фреймворк выбирать, а писать мобильное приложение на соответствующем языке. В противном случае, пофиг на чем писать. 200—500 мс, даже 1 с это не те цифры над которыми нужно задумываться. Тем более js развивается, а производительность мобильных устройств неуклонно растет.
Какой-то мрачный вывод у статьи. В общем, используйте, что хотите и не думайте над производительностью. Лучше над качеством своего кода подумайте.
«repeat password» или «view password»… В моем случае директива поля ввода пароля с глазиком лежит в common/components/form/password как элемент абстрактной формы. Ничего бредового.
Инкрементные билды в плане...
В Вебпаке легко разбить билд на файлы и добавить хеш к имени, но при ограничении количества бандлов будет склеивать друг с другом наиболее мелкие, что негативно скажется на кешировании (редко меняющиеся зависимости могут оказаться в одном файле с часто меняющимися). Описывать структуру бандлов в конфиге, даже для среднего проекта с парой сотен зависимостей, чересчур. От ленивой загрузки так же придется отказаться. Во-первых, она не поддерживается Ангуляром (без костылей), во-вторых, на практике, даже в огромном проекте из нескольких разделов больше половины кода грузится сразу и остается 10-20 кусков-разделов, подгружаемые лениво, общий вес которых таков, что проще сразу загрузить и не морочить голову. Возможно, плохо читал документацию, но простого решения этой задачи Вебпаком не нашел.
Я же например планирую переделать все это так:
Пометил вещи, которых не должно быть в объявлении компонента:
import angular from 'angular';
import uiRouter from 'angular-ui-router'; //Зачем глобальные зависимости в каждом компоненте?
export default angular
.module('about', [ //В крайнем случае включить uiRouter, ngResource и проч. в lib
uiRouter //и подключать везде его,
]) //но и это попахивает костылем
.config(($stateProvider) => {
"ngInject"; //Лишнее
$stateProvider
.state('about', {
url: '/about',
template: '<about></about>'
});
}).name; //Зачем разработчику помнить, что нужно всегда экспортировать name?
на днях нашел время добавить ng-annotate
Обязательно сделайте пример с одновременным использованием angular-bootstrap и angular-strap. У них пересекается сервис $tooltip и их совместное подключение разруливается исключительно ng-annotate.
Интересный проект. Буду следить, как развиваете компонентный подход и используете технологии типа webpack, systemjs, jspm, на которые пока серьезно не смотрел.
За NG6-starter огромное спасибо! Есть с чем сравнивать. Напишу о своих впечатлениях. Первое естественно негативное. Даже если опустить, что пару часов пытался его запустить github.com/AngularClass/NG6-starter/issues/65, то код, который увидел поверг в ужас. Тут и gulp и webpack и lodash'евский шаблонизатор и ES6 c Babel'лом и страшные конфиги. Чтобы весь этот стек поддерживать нужно знать уйму технологий. И, вообще, зачем весь этот сборочный хлам держать в каталоге приложения, а не в node-modules?
Из-за Babel livereload работает дольше. Как делать билд для продакшена (по модулям с md5 именами) так и не понял. Документация молчит.
Чем ES6-модули принципиально лучше AMD-модулей? На пару скобок меньше писать в каждом файле? Это из разряда, что плохому танцору всегда что-то мешает. Можно сравнить:
Библиотечные зависимости типа uiRouter зачем-то тянутся в каждый компонент. В статье даже графиком проиллюстрировал, что все библиотеки лучше собирать в один файл и подключать ко всему проекту разом. Создавать для каждого компонента отдельный модуль излишне в Angular 1.x, потому что все сервисы в глобальной области видимости. Объявлять в конструкторе каждого контроллера его имя, вообще, суровый костыль. Из-за всех этих условий пришлось генератор компонентов написать, потому что создавать вручную — много мороки. Лучший генератор всех времен и народов — копи-паст. Надеюсь, они к этому придут.
Разбивать структуру на common и components — плохое решение (уже проходили). Сначала в common'е navbar, потом footer, потом news в footer, потом раздел news в components и всё — пересечение — половина компонентов в common перетечет. Лучше делать однородную структуру (+ с ней легче работать), разбитую по бизнес-логике, а не синтетически. А уже в каждом из ее компонентов делать вложенные, если нужно. Таким образом в user могут быть login и register, которые могут использоваться в том же navbar для отображения формы входа/регистрации.
Из хорошего могу отметить направленность на компонентный подход (тоже приду к этому). Но ребята явно бегут впереди лошади. Ангуляровцы всего неделю назад выкатили module.component. С этого момента можно только начать подумывать над подобной архитектурой. В противном случае всё выливается в кучу никому не нужных костылей. Проект явно исследовательский, продакшеном тут и не пахнет.
Еще страничка Browsersync ничего такая. Можно развивать это направление.
По поводу «архитектура без проекта — теория». Уверен что большинство темплейтов появились не из пустого место, а выросли из нескольких проектов, так что не просто теория :-)
Так я его и выложил в этой статье! Специально заморочился с примером github.com/tamtakoe/node-arjs-builder-seed
Основные вещи настроены, конфиги написаны, общая структура ясна, даже роутинг с ресурсами прикручены, хотя это уже углубление в архитектуру. Конечно, там есть код за который мне стыдно, но его не много и он не столь важен для понимания сути. Скачиваете, запускаете, всё сразу работает и готово к использованию.
Что такое NDA? Его используют аутсорсеры, или стартаперы (тот случай, когда все гонят и на развитие не хватает времени, так что сомневаюсь на счет крутых штук). При этом подобные ограничения накладываются на бизнес-логику и узкоспециализированные вещи. Архитектура — слишком обширное понятие — это опыт, который кочует из одной компании в другую, который содержит в себе наработки других людей, в т. ч. открыто опубликованных. Чтобы к тебе прикопались нужно доказать, что написание структуры, сборки и проч. было утверждено в плане разработки, что всё это написано сотрудниками с нуля в соответствии с этим планом (в т. ч. все исследования, переделки и проч.), написано в компании в рабочее время, а не дома, что большинство фишек не позаимствовано из открытых источников, что в этом есть исключительно интеллектуальная собственность компании и она понесла какой-то урон (компаниям важно чтобы с их ноу-хау все было в порядке, а все эти архитектуры им до лампочки). На деле, прицепиться не реально, поэтому писать статьи на общие темы и публиковать компоненты общего назначения можно совершенно безболезненно.
А по мнению Киосаки, Гандапаса и менеджера из Форекс клуба, стать миллионером может каждый.
Понимаю, что сделать нормальный поиск по базе сложно, но то, что компания и не думает этим заниматься, а надеется, что пользователи будут искать по их шаблонам — клиника. MAPS.ME ожидает судьба ссылочных каталогизаторов после прихода на рынок поисковиков.
Если кому-то так важна производительность в мобильном сегменте, то нужно не js-фреймворк выбирать, а писать мобильное приложение на соответствующем языке. В противном случае, пофиг на чем писать. 200—500 мс, даже 1 с это не те цифры над которыми нужно задумываться. Тем более js развивается, а производительность мобильных устройств неуклонно растет.
Какой-то мрачный вывод у статьи. В общем, используйте, что хотите и не думайте над производительностью. Лучше над качеством своего кода подумайте.
В Вебпаке легко разбить билд на файлы и добавить хеш к имени, но при ограничении количества бандлов будет склеивать друг с другом наиболее мелкие, что негативно скажется на кешировании (редко меняющиеся зависимости могут оказаться в одном файле с часто меняющимися). Описывать структуру бандлов в конфиге, даже для среднего проекта с парой сотен зависимостей, чересчур. От ленивой загрузки так же придется отказаться. Во-первых, она не поддерживается Ангуляром (без костылей), во-вторых, на практике, даже в огромном проекте из нескольких разделов больше половины кода грузится сразу и остается 10-20 кусков-разделов, подгружаемые лениво, общий вес которых таков, что проще сразу загрузить и не морочить голову. Возможно, плохо читал документацию, но простого решения этой задачи Вебпаком не нашел.
Пометил вещи, которых не должно быть в объявлении компонента:
Обязательно сделайте пример с одновременным использованием angular-bootstrap и angular-strap. У них пересекается сервис $tooltip и их совместное подключение разруливается исключительно ng-annotate.
Интересный проект. Буду следить, как развиваете компонентный подход и используете технологии типа webpack, systemjs, jspm, на которые пока серьезно не смотрел.
Из-за Babel livereload работает дольше. Как делать билд для продакшена (по модулям с md5 именами) так и не понял. Документация молчит.
Чем ES6-модули принципиально лучше AMD-модулей? На пару скобок меньше писать в каждом файле? Это из разряда, что плохому танцору всегда что-то мешает. Можно сравнить:
Библиотечные зависимости типа uiRouter зачем-то тянутся в каждый компонент. В статье даже графиком проиллюстрировал, что все библиотеки лучше собирать в один файл и подключать ко всему проекту разом. Создавать для каждого компонента отдельный модуль излишне в Angular 1.x, потому что все сервисы в глобальной области видимости. Объявлять в конструкторе каждого контроллера его имя, вообще, суровый костыль. Из-за всех этих условий пришлось генератор компонентов написать, потому что создавать вручную — много мороки. Лучший генератор всех времен и народов — копи-паст. Надеюсь, они к этому придут.
Разбивать структуру на common и components — плохое решение (уже проходили). Сначала в common'е navbar, потом footer, потом news в footer, потом раздел news в components и всё — пересечение — половина компонентов в common перетечет. Лучше делать однородную структуру (+ с ней легче работать), разбитую по бизнес-логике, а не синтетически. А уже в каждом из ее компонентов делать вложенные, если нужно. Таким образом в user могут быть login и register, которые могут использоваться в том же navbar для отображения формы входа/регистрации.
Из хорошего могу отметить направленность на компонентный подход (тоже приду к этому). Но ребята явно бегут впереди лошади. Ангуляровцы всего неделю назад выкатили module.component. С этого момента можно только начать подумывать над подобной архитектурой. В противном случае всё выливается в кучу никому не нужных костылей. Проект явно исследовательский, продакшеном тут и не пахнет.
Еще страничка Browsersync ничего такая. Можно развивать это направление.
По поводу «архитектура без проекта — теория». Уверен что большинство темплейтов появились не из пустого место, а выросли из нескольких проектов, так что не просто теория :-)
Основные вещи настроены, конфиги написаны, общая структура ясна, даже роутинг с ресурсами прикручены, хотя это уже углубление в архитектуру. Конечно, там есть код за который мне стыдно, но его не много и он не столь важен для понимания сути. Скачиваете, запускаете, всё сразу работает и готово к использованию.
Что такое NDA? Его используют аутсорсеры, или стартаперы (тот случай, когда все гонят и на развитие не хватает времени, так что сомневаюсь на счет крутых штук). При этом подобные ограничения накладываются на бизнес-логику и узкоспециализированные вещи. Архитектура — слишком обширное понятие — это опыт, который кочует из одной компании в другую, который содержит в себе наработки других людей, в т. ч. открыто опубликованных. Чтобы к тебе прикопались нужно доказать, что написание структуры, сборки и проч. было утверждено в плане разработки, что всё это написано сотрудниками с нуля в соответствии с этим планом (в т. ч. все исследования, переделки и проч.), написано в компании в рабочее время, а не дома, что большинство фишек не позаимствовано из открытых источников, что в этом есть исключительно интеллектуальная собственность компании и она понесла какой-то урон (компаниям важно чтобы с их ноу-хау все было в порядке, а все эти архитектуры им до лампочки). На деле, прицепиться не реально, поэтому писать статьи на общие темы и публиковать компоненты общего назначения можно совершенно безболезненно.