Pull to refresh
81
0
Vladimir Chernyshev @VolCh

Software Engineer, Technical Lead

Send message

Автоматизатор тестирования — это, по сути, разработчик, специализируйщийся на, как ни странно, автоматизации тестирования.

Ну так чего тогда возмущаться, что некоторые сотрудники режимных объектов нарушают режим? Не покемоны в этом виноваты же.


Это ли не стратегия любой страны? Даже максимально изолированные, рассчитывают что-то получать извне.

Semver это именно средство решения проблемы "когда из-за обновлений ломалась куча кода".

Всё же это средство уменьшить количество проблем "когда из-за обновлений ломалась куча кода". Гарантий, что даже при патчевом обновлении не сломается BC — нет. Стараются ломать только в мажорных обновлениях, но не всегда получается.

Лучше, да, часть кейсов для разработки закрывает.

Не имеет значение есть какая-то стратегия или "все совпадения случайны".


Есть политики безопасности на предприятиях и в учреждениях, если человек их нарушает, например, что-то фотографируя, то не важно лично завербованный Обамой агент он, или ловит покемонов. Реакция соотвествующих служб одинаковая должна, профилактика одинаковая.

Разве в рамках OGP нужно использовать конкретный софт или железо? Хоть на Эльбрусе реализуйте, нет?

А вообще в информационных воздействиях одних государств на население других государств для проведения ими «правильной» политики ничего нового. Помнится даже в истории Древней Греции подобное было. Собственно вся традиционная дипломатия таким инструментом информационного воздействия является. Только ЦА её обычно элиты, а не массы.

Домашний комп тоже нередко в локалке: или роутер с NAT на входе в квартиру, или провайдер белых адресов не даёт, равзе что за отдельную плату, а по дефолту пуская через NAT, или и то, и другое, разве что админские права могут быть на роутер дома у разработчика. А могут и не быть, например сын — разработчик, а папа — админ :)


Если речь идёт не о локальной разработке, а о, например, QA-сервере в корпоративной сети, то там хорошим вариантом может быть поднятие своего CA полноценного, особенно если активно используются локальные домены, которые в принципе не резолвятся публичными DNS. И с точки зрения безопасности вариант отличный — сертификат корпоративного CA добавляется на все сервера и рабочие станции, подписывать им можно сертификаты для любых целей, а не только для сайтов, вносить в проверенную любую информацию, например, отдел.

Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.

Безопасности скорее убавит в теории — меньше людей проводят аудит. Насчёт маневренности спорно: в теории может и увеличить, но на практике у самописного кода гибкости меньше, чем у популярных фреймворков, меньше готовых точек для изменения поведения.

Вот для ubuntu рецепт:


sudo cp my.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

А вот так называемые "доступные методы" не очень хорошо подходят для условий локальной разработки без прямого доступа из интернета к защищаемому хосту (NAT, прокси). В общем случае с 4 сторонними лицами надо взаимодействовать:


  • администратор локальной сети, который пробросит порт с внешнего адреса на внутренний, а потом уберёт проброс, если он вообще согласится. "Локальной сетью" вполне может оказаться сеть оператора, например мобильного, который даже временно, динамические публичные адреса не даёт
  • регистратор доменов
  • DNS-сервис, адреса которого нужно дать регистратору домена
Разве в скраме есть обещания? Вроде все тренеры или как их называют, при внедрении триста раз повторяют «спринт — не обещание, а план, никто вас наказывать не будет, лжецом называть не будет».

А вообще характерно, что не упомянуто о пользе стендапов для разработчиков, тестировщиков и прочих исполнителей :)
Вполне настраивается всё. Главное, что один раз настроить доверие к корневому, а потом плоди сколько хочешь. И всё на localhost, никому не нужно давать доступ к нему.

Хм… Оказывается не так давно, только в 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 не нужна.

При прочих равных не получится, потому что человек, который 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 скорее всего будут намного более эффективны.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity