Semver это именно средство решения проблемы "когда из-за обновлений ломалась куча кода".
Всё же это средство уменьшить количество проблем "когда из-за обновлений ломалась куча кода". Гарантий, что даже при патчевом обновлении не сломается BC — нет. Стараются ломать только в мажорных обновлениях, но не всегда получается.
Не имеет значение есть какая-то стратегия или "все совпадения случайны".
Есть политики безопасности на предприятиях и в учреждениях, если человек их нарушает, например, что-то фотографируя, то не важно лично завербованный Обамой агент он, или ловит покемонов. Реакция соотвествующих служб одинаковая должна, профилактика одинаковая.
Разве в рамках OGP нужно использовать конкретный софт или железо? Хоть на Эльбрусе реализуйте, нет?
А вообще в информационных воздействиях одних государств на население других государств для проведения ими «правильной» политики ничего нового. Помнится даже в истории Древней Греции подобное было. Собственно вся традиционная дипломатия таким инструментом информационного воздействия является. Только ЦА её обычно элиты, а не массы.
Домашний комп тоже нередко в локалке: или роутер с NAT на входе в квартиру, или провайдер белых адресов не даёт, равзе что за отдельную плату, а по дефолту пуская через NAT, или и то, и другое, разве что админские права могут быть на роутер дома у разработчика. А могут и не быть, например сын — разработчик, а папа — админ :)
Если речь идёт не о локальной разработке, а о, например, QA-сервере в корпоративной сети, то там хорошим вариантом может быть поднятие своего CA полноценного, особенно если активно используются локальные домены, которые в принципе не резолвятся публичными DNS. И с точки зрения безопасности вариант отличный — сертификат корпоративного CA добавляется на все сервера и рабочие станции, подписывать им можно сертификаты для любых целей, а не только для сайтов, вносить в проверенную любую информацию, например, отдел.
Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.
Безопасности скорее убавит в теории — меньше людей проводят аудит. Насчёт маневренности спорно: в теории может и увеличить, но на практике у самописного кода гибкости меньше, чем у популярных фреймворков, меньше готовых точек для изменения поведения.
А вот так называемые "доступные методы" не очень хорошо подходят для условий локальной разработки без прямого доступа из интернета к защищаемому хосту (NAT, прокси). В общем случае с 4 сторонними лицами надо взаимодействовать:
администратор локальной сети, который пробросит порт с внешнего адреса на внутренний, а потом уберёт проброс, если он вообще согласится. "Локальной сетью" вполне может оказаться сеть оператора, например мобильного, который даже временно, динамические публичные адреса не даёт
регистратор доменов
DNS-сервис, адреса которого нужно дать регистратору домена
Разве в скраме есть обещания? Вроде все тренеры или как их называют, при внедрении триста раз повторяют «спринт — не обещание, а план, никто вас наказывать не будет, лжецом называть не будет».
А вообще характерно, что не упомянуто о пользе стендапов для разработчиков, тестировщиков и прочих исполнителей :)
Вполне настраивается всё. Главное, что один раз настроить доверие к корневому, а потом плоди сколько хочешь. И всё на localhost, никому не нужно давать доступ к нему.
Не тащите в одну кучу jQuery и jQuery UI. Это очень разные продукты. И React c jQuery UI не пересекаются вообще по решаемым задачам. Для React есть библиотеки UI компонентов, включая тот же Bootstrap, но они не входят в React, как jQuery UI не входит в jQuery.
В целом же React делает ненужным jQuery, поскольку основная задача jQuery — удобное изменение DOM, а философия React исключает не то, что прямое изменение DOM, а даже изменение виртуального DOM, он просто создаётся заново на каждый чих. Просто нет нужды выбирать что-то из DOM по селекторам. Можно, но нет смысла, даже если решим хранить состояние приложения в DOM — у React есть свой механизм получения ссылок на элементы.
А по мелочам, если не ошибаюсь, jQuery есть даже в официальных туториалах по React, используется jQuery.ajax() для примеров получения данных компонентов с сервера. jQuery и React не исключают друг друга, просто в React приложении бОльшая часть функциональности jQuery не нужна.
При прочих равных не получится, потому что человек, который 8 часов работал, а не отдыхал с перерывами на работу, не будет в состоянии чего-то контрибьютить.
Спорно
Зато вот то, что человек, который после работы идет плодотворно коммитит гитхабы, на работе работает спустя рукава — это уже факт.
Нет. Задача программиста реализовывать бизнес-требования с устраивающими бизнес скоростью и качеством, а тестировщика — проверять что это качество приемлемо. Видение бизнеса и конкретного пользователя на приемлемое качество могут очень сильно различаться.
При прочих равных надо сравнивать. Или оба чешут яйца, а потом один идёт контрибьютить, а второй валяться на диване, или оба честно работают, а потом один идёт контрибьютить, а второй валяться на диване.
В целом предполагается, что первый более эффективен, хотя бы потому что объективно больше опыта разработки "в часах" при равном стаже "в годах". Кроме того, некоторые работодатели считают повышенную оплату известных в узких кругах опенсорса разработчиков имиджевыми инвестициями, дополнительной рекламой.
За моделью, конечно. Я же об этом и сказал. Смысл том, что в саму модель он не входит. Он где-то за ней.
Входит в рамках MVC. В них просто ничего нет кроме модели, вью и контроллера. Отдельного слоя может и не быть, модель прямо с базой сожет работать. Всё приложение, кроме UI абстрагируется за API модели.
Тогда архитектор ничего не знает про MVC. А решение о том, что: «мы будем использовать mvc» — это уже роль программиста, в чистом виде.
Это роль архитектора. MVC — архитектурный паттерн.
Любой assertInvoked гарантирует, что вы заменяете тест интеграции модульным.
Интеграционные тесты проверяют интеграцию модулей. В данно псевдокоде тестируется интеграция модели и вью. Проверяется взаимодействие модулей. В юнит-тестах я бы просто замокал один из модулей.
Дело даже не в знании. Дело в том, что модель ВСЕГДА проектируется с учетом нужд вида. Иначе будет кусок чего-то вонючего вместо модели, работать с которой потом будет невозможно.
С учётом, да. Если приложение в целом должно что-то показать, то это модель должна отдавать через свой API. Но если виду хочется, например, чтобы модель отдавала ФИО в нескольких форматах, то это попытка нарушить границы ответственности. Модель отдасть полное ФИО, а уж вид будет преобразовывать в отдних случаях в Иванов И. И., а в других в уважаемый Иван Иванович, ещё и пол из модели проанлизировав.
Проблема в том, что чем дальше вы идете в использовании этого принципа, тем сильнее гвоздями прибиваете вашу модель и вид друг к другу и, с-но, усложняете дальнейший процесс разработки.
Да как же прибиваю, если модель знает о виде только то, что он реализует интерфейс, который является частью API модели?
Ну вот в данном случае мы это и имеем. Модель предоставляет блоб с данными (знания), а вид — их преобразует к понимаемому пользователем формату. И никто от модели MVC не требует знать структуры этих данных.
Не путайте данные и знания. Знания это как раз понимание формата данных. Если у нас приложение корзины с товаром, то то знания о том, что такое корзина и товар должна находиться в модели. Разработчик, который хочет понять, например, чем в приложении товар отличается от товарной позиции должен лезть в модель. В вид разве что заглянуть посмотреть какой метод модели дергается для отображения рядом с меткой "товар", а какой "товарная позиция". Более того, в модели могут быть знания, которые в виде никак не отображаются. Например, что в каталоге не отображаются товарные позиции с нулевым остатком.
Но это все требования у УИ. Все требования к системе — это требования к поведению УИ.
Нет. UI — это механизм взаимодействия системы и пользователя, а не система. Банально в требованиях к UI не напишешь "при нажатии на кнопку должно отправляться письмо менеджеру". UI не оперирует понятием "отправка письма", это понятие совсем другого уровня по сравнению с экранами, окнами, мышами и т. п.
А такого требования не будет. Будет требование: «в случае попытки добавления в корзину отсутствующего на складе товара, пользователь должен получить отказ». Это требование к виду, не к модели.
Это требование к системе. Оно будет декомпозировано на требования к модели "должно бросить исключение ZeroResidue при попытке добавления товара с нулевым остатком" и на требование к UI вывести сообщение об ошибке "Нулевой остаток" при появлении исключения ZeroResidue. Кстати, именно в модели будут знания о том, что такое нулевой остаток, в каких условиях он может появиться. И вполне может оказаться, что эти условия будут меняться, если бизнес, например, решится на оверселл. К UI требование не остатки проверять, а показывать сообщения при исключении в модели, не более.
А требование к системе в целом — это всегда требование к слою взаимодействия с этой системой. О чем я вам и талдычу. Ну попробуйте сформулировать требование, которое было бы требованием к модели, а не уи.
Слой взаимодействия системы с внешним миром не только UI. Пример с письмом я уже приводил — это взаимодействие с SMTP сервером, а не пользователем. Ещё может быть требование "записать данные о продаже в базу данных учётной системы", "отправить чек в систему фискальной службы" и т. п. Сложные системы взаимодействуют не только с пользователем, но и с другими системами. Есть действия, которые в UI вообще не отображаются, типа сбор данных которые сейчас никак не обрабатываются, просто пишутся в базу на всякий случай, например по требованию закона или на перспективу внедрения анализа пользовательского поведения. У вас систему не примут, если приемщик сделает SQL запрос и не увидит там, например, IP с которогоо был заказа, хотя он нигде в системе не показывается.
Совершенно прямое. Нет никакой разницы является ли вам интерфейс интерфейсом между двумя сервисами или между человеком и компьютером. Это в обоих случаях одинаково MVC.
MVC — это про пользовательские интерфейсы, не про программные. Можно пробовать применять, но это использование не по назначению, другие методы организации API скорее всего будут намного более эффективны.
Автоматизатор тестирования — это, по сути, разработчик, специализируйщийся на, как ни странно, автоматизации тестирования.
Ну так чего тогда возмущаться, что некоторые сотрудники режимных объектов нарушают режим? Не покемоны в этом виноваты же.
Это ли не стратегия любой страны? Даже максимально изолированные, рассчитывают что-то получать извне.
Всё же это средство уменьшить количество проблем "когда из-за обновлений ломалась куча кода". Гарантий, что даже при патчевом обновлении не сломается BC — нет. Стараются ломать только в мажорных обновлениях, но не всегда получается.
Лучше, да, часть кейсов для разработки закрывает.
Не имеет значение есть какая-то стратегия или "все совпадения случайны".
Есть политики безопасности на предприятиях и в учреждениях, если человек их нарушает, например, что-то фотографируя, то не важно лично завербованный Обамой агент он, или ловит покемонов. Реакция соотвествующих служб одинаковая должна, профилактика одинаковая.
А вообще в информационных воздействиях одних государств на население других государств для проведения ими «правильной» политики ничего нового. Помнится даже в истории Древней Греции подобное было. Собственно вся традиционная дипломатия таким инструментом информационного воздействия является. Только ЦА её обычно элиты, а не массы.
Домашний комп тоже нередко в локалке: или роутер с NAT на входе в квартиру, или провайдер белых адресов не даёт, равзе что за отдельную плату, а по дефолту пуская через NAT, или и то, и другое, разве что админские права могут быть на роутер дома у разработчика. А могут и не быть, например сын — разработчик, а папа — админ :)
Если речь идёт не о локальной разработке, а о, например, QA-сервере в корпоративной сети, то там хорошим вариантом может быть поднятие своего CA полноценного, особенно если активно используются локальные домены, которые в принципе не резолвятся публичными DNS. И с точки зрения безопасности вариант отличный — сертификат корпоративного CA добавляется на все сервера и рабочие станции, подписывать им можно сертификаты для любых целей, а не только для сайтов, вносить в проверенную любую информацию, например, отдел.
Безопасности скорее убавит в теории — меньше людей проводят аудит. Насчёт маневренности спорно: в теории может и увеличить, но на практике у самописного кода гибкости меньше, чем у популярных фреймворков, меньше готовых точек для изменения поведения.
Вот для ubuntu рецепт:
А вот так называемые "доступные методы" не очень хорошо подходят для условий локальной разработки без прямого доступа из интернета к защищаемому хосту (NAT, прокси). В общем случае с 4 сторонними лицами надо взаимодействовать:
А вообще характерно, что не упомянуто о пользе стендапов для разработчиков, тестировщиков и прочих исполнителей :)
Хм… Оказывается не так давно, только в 2009, в es5. Почему-то думал, что это es3, прошлое тысячелетие. И даже по факту это JavaScript 1.6, 2005-й год.
Не тащите в одну кучу jQuery и jQuery UI. Это очень разные продукты. И React c jQuery UI не пересекаются вообще по решаемым задачам. Для React есть библиотеки UI компонентов, включая тот же Bootstrap, но они не входят в React, как jQuery UI не входит в jQuery.
В целом же React делает ненужным jQuery, поскольку основная задача jQuery — удобное изменение DOM, а философия React исключает не то, что прямое изменение DOM, а даже изменение виртуального DOM, он просто создаётся заново на каждый чих. Просто нет нужды выбирать что-то из DOM по селекторам. Можно, но нет смысла, даже если решим хранить состояние приложения в DOM — у React есть свой механизм получения ссылок на элементы.
А по мелочам, если не ошибаюсь, jQuery есть даже в официальных туториалах по React, используется jQuery.ajax() для примеров получения данных компонентов с сервера. jQuery и React не исключают друг друга, просто в React приложении бОльшая часть функциональности jQuery не нужна.
Спорно
Откуда этот факт? Есть ссылка на исследование?
Что значит "доказать"? Я своё отношение показал.
Если другим кандидатам неоткуда браться, то надо уменьшать входной барьер.
Нет. Задача программиста реализовывать бизнес-требования с устраивающими бизнес скоростью и качеством, а тестировщика — проверять что это качество приемлемо. Видение бизнеса и конкретного пользователя на приемлемое качество могут очень сильно различаться.
При прочих равных надо сравнивать. Или оба чешут яйца, а потом один идёт контрибьютить, а второй валяться на диване, или оба честно работают, а потом один идёт контрибьютить, а второй валяться на диване.
В целом предполагается, что первый более эффективен, хотя бы потому что объективно больше опыта разработки "в часах" при равном стаже "в годах". Кроме того, некоторые работодатели считают повышенную оплату известных в узких кругах опенсорса разработчиков имиджевыми инвестициями, дополнительной рекламой.
Входит в рамках MVC. В них просто ничего нет кроме модели, вью и контроллера. Отдельного слоя может и не быть, модель прямо с базой сожет работать. Всё приложение, кроме UI абстрагируется за API модели.
Это роль архитектора. MVC — архитектурный паттерн.
Интеграционные тесты проверяют интеграцию модулей. В данно псевдокоде тестируется интеграция модели и вью. Проверяется взаимодействие модулей. В юнит-тестах я бы просто замокал один из модулей.
С учётом, да. Если приложение в целом должно что-то показать, то это модель должна отдавать через свой API. Но если виду хочется, например, чтобы модель отдавала ФИО в нескольких форматах, то это попытка нарушить границы ответственности. Модель отдасть полное ФИО, а уж вид будет преобразовывать в отдних случаях в Иванов И. И., а в других в уважаемый Иван Иванович, ещё и пол из модели проанлизировав.
Да как же прибиваю, если модель знает о виде только то, что он реализует интерфейс, который является частью API модели?
Не путайте данные и знания. Знания это как раз понимание формата данных. Если у нас приложение корзины с товаром, то то знания о том, что такое корзина и товар должна находиться в модели. Разработчик, который хочет понять, например, чем в приложении товар отличается от товарной позиции должен лезть в модель. В вид разве что заглянуть посмотреть какой метод модели дергается для отображения рядом с меткой "товар", а какой "товарная позиция". Более того, в модели могут быть знания, которые в виде никак не отображаются. Например, что в каталоге не отображаются товарные позиции с нулевым остатком.
Нет. UI — это механизм взаимодействия системы и пользователя, а не система. Банально в требованиях к UI не напишешь "при нажатии на кнопку должно отправляться письмо менеджеру". UI не оперирует понятием "отправка письма", это понятие совсем другого уровня по сравнению с экранами, окнами, мышами и т. п.
Это требование к системе. Оно будет декомпозировано на требования к модели "должно бросить исключение ZeroResidue при попытке добавления товара с нулевым остатком" и на требование к UI вывести сообщение об ошибке "Нулевой остаток" при появлении исключения ZeroResidue. Кстати, именно в модели будут знания о том, что такое нулевой остаток, в каких условиях он может появиться. И вполне может оказаться, что эти условия будут меняться, если бизнес, например, решится на оверселл. К UI требование не остатки проверять, а показывать сообщения при исключении в модели, не более.
Слой взаимодействия системы с внешним миром не только UI. Пример с письмом я уже приводил — это взаимодействие с SMTP сервером, а не пользователем. Ещё может быть требование "записать данные о продаже в базу данных учётной системы", "отправить чек в систему фискальной службы" и т. п. Сложные системы взаимодействуют не только с пользователем, но и с другими системами. Есть действия, которые в UI вообще не отображаются, типа сбор данных которые сейчас никак не обрабатываются, просто пишутся в базу на всякий случай, например по требованию закона или на перспективу внедрения анализа пользовательского поведения. У вас систему не примут, если приемщик сделает SQL запрос и не увидит там, например, IP с которогоо был заказа, хотя он нигде в системе не показывается.
MVC — это про пользовательские интерфейсы, не про программные. Можно пробовать применять, но это использование не по назначению, другие методы организации API скорее всего будут намного более эффективны.