Angular как раз с прицелом на серверных разработчиков и пишется во многом. Они привыкли, что должен быть DI — вот им DI. Они привыкли, что внешние источники данных в тестах заменяются на Мокки — вот им мокки. И т.д. Все сдобрено словами Google и Enterprise — и все: орда джавистов, дотнетчиков и питонистов записывается в ваши поклонники!
Они и хорошо — гораздо лучше, когда люди из фронтенда лучше понимают бекенд, а люди из бекенда — фронтенд. Так и общий язык найти проще, и задачи быстрее выполнять.
Вопрос не в том, что инструмент умеет все, а в том, сколько у вас накапливается в проекте кастомного и glue-кода, который ничего не делает кроме как соединять отдельные «идеальные» микро-библиотеки.
Многие считают:
1. о, я возьму вот эту микробиблиотеку, соединю вон с той, буду брать все самое лучшее, все то и только то, что подходит для моей задачи, — и получу идеальный проект.
2. потом в коде для склейки частей у них возникает какое-то дублирование кода, вырисовываются какие-то шаблоны, они их начинают вычленять, радуются, как у них все идеально и идиоматично, и т.д.
3. так из идеальных кусочков у них получается свой недофреймворк, на котором они пишут свое приложение.
4. а потом этот фреймворк начинает трещать по швам из-за «особых частных случаев», обхода багов в выбранных библиотеках, несостыковываемостью выбранных компонентов между собой, проблем с производительностью и т.д.
5. а времени фиксить недофрейсворк нет — проект, сроки, заказчик, менеджер. Взяли человека в команду — ему с ним теперь неделями разбираться. А если «автор» фреймворка уже ушел из команды, и вы — как раз тот человек, кому придется разбираться в костылях вокруг идеальных библиотек образца 2013 года?
Иногда проще взять готовое большое решение и быстро решить задачу. Плюсы Эмбера:
— это такой же фреймворк, как и ваш самописный, но его в том или ином виде дорабатывают с учетом требований различных разработчиков несколько лет. Получается, что у вас фора — несколько десятков человеколет на вашем проекте. Багов в нем мало, шансов столкнуться с ними — не один раз в день, а один раз в месяц, например. Если у вас возникает «особый случай», очень высока вероятность, что где-то в Эмбере предусмотрены лазейки и хуки, чтобы его вписать во фреймворк.
— архитектура решена за вас, не нужно ничего придумывать, не нужно спорить о том, как сделать лучше.
— вопрос инструментов сборки или подключения аддонов для вас тоже не стоит: все уже решено, вы делаете как все.
— в отличие от Angular подводных камней гораздо меньше, мест где нужно изобретать велосипед — тоже, инструменты лучше, диагностировать и решать проблемы производительности проще.
— полно больших open-source проектов — всегда можно посмотреть, а как люди решают ту или иную задачу.
— все пишется в открытую: нет такого «ой, мы тут версию 2.0 готовим — все теперь будет не так, как раньше»
Он не делает для вас все, но 90% того, что он делает, вам наверняка подойдет.
По 4му пункту я сейчас обхожусь тем, что пишу без контроллеров. Все контроллеры — автогенеренные Эмбером везде, где можно. По факту пишу свои только если нужны queryParams. Решает кучу проблем.
Пишу и на Ember, и на Angular. На Ember у меня всегда меньше кода получается. И самое главное: я могу пересесть с одного Эмберовского проекта на другой без особых разбирательств, а Angular в каждой команде почему-то готовят по-своему и приходится время тратить, чтобы разобраться, какие тут приняты правила и конвенции.
Этой шутке лет 20-30 уже, не обольщайтесь. Во всяком случае, в 96 про Java такие письма рекрутеров точно ходили, и возможно, в начале 90х про Perl. Может и раньше тоже про что-то было такое.
Эти страны как раз пользуются мировыми валютами — Доллар, Евро, Йена. Если вы — американец, то смысл вам доллары на доллары менять, правда?
А так мы видим в списке Википедии более-менее крупные экономики, где есть национальна валюта, не распространенная на внешнем рынке. Если бы в России основной валютой был доллар, швейцарский франк, фунт, йена или евро, у нас бы не было валютного контроля.
Так это и стандартный Firefox умеет. По их инструментам, к сожалению, нет хорошего курса, чтобы в одном месте все-все было. А так в Firefox Dev Tools много чего хорошего есть.
Знать бы, как намертво удалить мозильские developer tools из «релизного» (массового) бруазера — уже был бы хлеб. И сделать плагином их установку, для тех, кому надо. А то я не пойму: релизный, массовый браузер суть несет в себе отладчик, что, как бы, несколько увеличивает и вес, и объем, и сложность кода.
А то, что другие браузеры — Chrome, IE, Opera, Safari — тоже так делают, вас не удивляет? Вы считаете, что они тоже должны ставиться дополнительно?
Вообще-то, доступность инструментов разработки и тот факт, что весь код передается пользователю в открытом виде — как раз и есть то, что сделало веб таким популярным, открытым и свободным. Низкий порг входа как раз и объясняет, почему на мобильных устройствах есть только 1.5-2 миллиона приложений, а сайтов в мире больше миллиарда.
А можете пояснить, пож-та, как работает Azure RemoteApp?
В Azure подняты виртуалки с Windows. Вы ставите себе клиент, который открывает с вашего компьютера RDP на свободный сервер, в котором для вас открывается IE. У сервера разрешен доступ в интернет, поэтому вы можете открыть в этом IE ваш сайт и протестировать. Физически браузер на вашем компьютере не запущен.
До недавнего времени альтернативой этому был только запуск Windows на вашем компьютере (в виртуалке или dual-boot).
Поскольку в данном случае это RDP-соединение, то часть вещей, конечно, работает не так, как если бы браузер был запущен непосредственно у вас. Например, нет графического ускорения, анимации неплавные и т.д. Плюс, он не находится внутри вашей сети, поэтому для тестирования внутренних систем или локальных копий вашего приложения придется настраивать туннелирование. Но для проверки на уровне «а не разъехался ли мой дизайн в IE» сервиса хватит с лихвой.
Скажите, а при обновлении на 10.10 обязательно нужны программы «с поддержкой»? Что будет, если я попробую старый Скайп на 10.10 поставить? Сам пользуюсь Скайпом той версии, где еще нет этой голубизны в чате, и как-то пересаживаться на новую версию не хочется.
По хорошему должно быть так: AppStore детектит архитектуру устройства и закачивает только соответствующие компоненты. Это же должно касаться и картинок: не неретиновом устройстве @2x не нужны и наоборот. Также неплохо было бы качать только ту часть локализационных данных, которая используется устройством (с докачкой, если переключается локаль).
1. Релизы выходят с завидной регулярностью, последний — Upstart 1.13.2 — был 4 сентября. Всего за этот год выпущено 5 релизов. SysV Init такой же «мертвый» или даже мертвее, но товарищи из протестующих как раз и ратуют за то, чтобы отказаться от SystemD в пользу «мертвого» проверенного решения.
2. Ubuntu пока только планирует перейти, а по факту там еще довольно много нерешенных задач wiki.ubuntu.com/systemd#Implementation_issues Можно заметить, что по ряду пунктов ребята из Ubuntu ждут, пока изменения попадут в Debian.
3. Upstart — init-система текущей LTS, и будет поддерживаться минимум до третьего квартала 2019 года. Очень вероятно, что она будет доступна как альтернативная еще один-два LTS-цикла (вначале задепрекейтят, потом отключат). Возможно, она останется альтернативной насовсем.
4. и SystemD, и Upstart поддерживают обратную совместимость с Sys V Init, поэтому если писать привычные rc-скрипты, то проблем с переходом не будет. Справедливости ради стоит сказать, что и там, и там есть определенные моменты.
5. В целом, если вам интересен новый init-демон только как замена традиционному, но быстрее, то вам будет все равно, что использовать, что upstart, что systemd.
Для Firefox уже сегодня есть расширение от Mozilla SSL Version Control. Позволяет указать минимально поддерживаемую браузером версию TLS/SSL, по умолчанию как раз ставится TLS 1.0. Расширение не требует перезапуска браузера, не добавляет ничего в UI, и обезопасит вас уже сегодня.
Конечно, можно флаги менять, но гораздо проще сказать друзьям и родственникам «пройди по ссылке и нажми на кнопку».
А я пеку блины. Хлеб — тоже хорошо, но чего-то мне больше удовольствия именно выпекание блинов доставляет. Времени уходит больше, но зато здорово удается отвлечься от работы, пока тесто разливаешь по сковороде и следишь, чтоб успел пропузриться нормально, но не начать гореть.
Они и хорошо — гораздо лучше, когда люди из фронтенда лучше понимают бекенд, а люди из бекенда — фронтенд. Так и общий язык найти проще, и задачи быстрее выполнять.
Многие считают:
1. о, я возьму вот эту микробиблиотеку, соединю вон с той, буду брать все самое лучшее, все то и только то, что подходит для моей задачи, — и получу идеальный проект.
2. потом в коде для склейки частей у них возникает какое-то дублирование кода, вырисовываются какие-то шаблоны, они их начинают вычленять, радуются, как у них все идеально и идиоматично, и т.д.
3. так из идеальных кусочков у них получается свой недофреймворк, на котором они пишут свое приложение.
4. а потом этот фреймворк начинает трещать по швам из-за «особых частных случаев», обхода багов в выбранных библиотеках, несостыковываемостью выбранных компонентов между собой, проблем с производительностью и т.д.
5. а времени фиксить недофрейсворк нет — проект, сроки, заказчик, менеджер. Взяли человека в команду — ему с ним теперь неделями разбираться. А если «автор» фреймворка уже ушел из команды, и вы — как раз тот человек, кому придется разбираться в костылях вокруг идеальных библиотек образца 2013 года?
Иногда проще взять готовое большое решение и быстро решить задачу. Плюсы Эмбера:
— это такой же фреймворк, как и ваш самописный, но его в том или ином виде дорабатывают с учетом требований различных разработчиков несколько лет. Получается, что у вас фора — несколько десятков человеколет на вашем проекте. Багов в нем мало, шансов столкнуться с ними — не один раз в день, а один раз в месяц, например. Если у вас возникает «особый случай», очень высока вероятность, что где-то в Эмбере предусмотрены лазейки и хуки, чтобы его вписать во фреймворк.
— архитектура решена за вас, не нужно ничего придумывать, не нужно спорить о том, как сделать лучше.
— вопрос инструментов сборки или подключения аддонов для вас тоже не стоит: все уже решено, вы делаете как все.
— в отличие от Angular подводных камней гораздо меньше, мест где нужно изобретать велосипед — тоже, инструменты лучше, диагностировать и решать проблемы производительности проще.
— полно больших open-source проектов — всегда можно посмотреть, а как люди решают ту или иную задачу.
— все пишется в открытую: нет такого «ой, мы тут версию 2.0 готовим — все теперь будет не так, как раньше»
Он не делает для вас все, но 90% того, что он делает, вам наверняка подойдет.
А так мы видим в списке Википедии более-менее крупные экономики, где есть национальна валюта, не распространенная на внешнем рынке. Если бы в России основной валютой был доллар, швейцарский франк, фунт, йена или евро, у нас бы не было валютного контроля.
А то, что другие браузеры — Chrome, IE, Opera, Safari — тоже так делают, вас не удивляет? Вы считаете, что они тоже должны ставиться дополнительно?
Вообще-то, доступность инструментов разработки и тот факт, что весь код передается пользователю в открытом виде — как раз и есть то, что сделало веб таким популярным, открытым и свободным. Низкий порг входа как раз и объясняет, почему на мобильных устройствах есть только 1.5-2 миллиона приложений, а сайтов в мире больше миллиарда.
В Azure подняты виртуалки с Windows. Вы ставите себе клиент, который открывает с вашего компьютера RDP на свободный сервер, в котором для вас открывается IE. У сервера разрешен доступ в интернет, поэтому вы можете открыть в этом IE ваш сайт и протестировать. Физически браузер на вашем компьютере не запущен.
До недавнего времени альтернативой этому был только запуск Windows на вашем компьютере (в виртуалке или dual-boot).
Поскольку в данном случае это RDP-соединение, то часть вещей, конечно, работает не так, как если бы браузер был запущен непосредственно у вас. Например, нет графического ускорения, анимации неплавные и т.д. Плюс, он не находится внутри вашей сети, поэтому для тестирования внутренних систем или локальных копий вашего приложения придется настраивать туннелирование. Но для проверки на уровне «а не разъехался ли мой дизайн в IE» сервиса хватит с лихвой.
По хорошему должно быть так: AppStore детектит архитектуру устройства и закачивает только соответствующие компоненты. Это же должно касаться и картинок: не неретиновом устройстве @2x не нужны и наоборот. Также неплохо было бы качать только ту часть локализационных данных, которая используется устройством (с докачкой, если переключается локаль).
1. Релизы выходят с завидной регулярностью, последний — Upstart 1.13.2 — был 4 сентября. Всего за этот год выпущено 5 релизов. SysV Init такой же «мертвый» или даже мертвее, но товарищи из протестующих как раз и ратуют за то, чтобы отказаться от SystemD в пользу «мертвого» проверенного решения.
2. Ubuntu пока только планирует перейти, а по факту там еще довольно много нерешенных задач wiki.ubuntu.com/systemd#Implementation_issues Можно заметить, что по ряду пунктов ребята из Ubuntu ждут, пока изменения попадут в Debian.
3. Upstart — init-система текущей LTS, и будет поддерживаться минимум до третьего квартала 2019 года. Очень вероятно, что она будет доступна как альтернативная еще один-два LTS-цикла (вначале задепрекейтят, потом отключат). Возможно, она останется альтернативной насовсем.
4. и SystemD, и Upstart поддерживают обратную совместимость с Sys V Init, поэтому если писать привычные rc-скрипты, то проблем с переходом не будет. Справедливости ради стоит сказать, что и там, и там есть определенные моменты.
5. В целом, если вам интересен новый init-демон только как замена традиционному, но быстрее, то вам будет все равно, что использовать, что upstart, что systemd.
Для Firefox уже сегодня есть расширение от Mozilla SSL Version Control. Позволяет указать минимально поддерживаемую браузером версию TLS/SSL, по умолчанию как раз ставится TLS 1.0. Расширение не требует перезапуска браузера, не добавляет ничего в UI, и обезопасит вас уже сегодня.
Конечно, можно флаги менять, но гораздо проще сказать друзьям и родственникам «пройди по ссылке и нажми на кнопку».