Pull to refresh
0
0
Станислав @stanislav-belichenko

Программист (senior full-stack php developer)

Send message

Наверняка глупый вопрос новичка, но в обоих частях не нашел ответа на него: а как можно даже для внутреннего использования начать использовать модель, которая ошибается даже хотя бы в 5% случаев? Особенно, если речь о юридических тематиках. Другими словами, что происходит такого, чтобы качество работы использующих эти ошибочные ответы не падало?

Очень часто это встречается, если ты пользователь русской Windows. Просто выглядит это так, как будто неправильно что-то настроено, и в итоге не идешь в багтрекер.
Я скорее просто подвел итог вашим комментариям выше :-) Примеры научного метода в разработке я сходу не могу даже придумать — наука может быть прикладной областью в разработке, то есть областью, куда (где) применяется (прикладывается) в итоге программный продукт. Но сама его разработка — не знаю.
Крайне поучительная статья, спасибо!
Использование научных достижений и их, скажем так, созидание — суть разные вещи. Вы пользуетесь булевой логикой, что есть результат науки, но вы не создаете эту булеву логику с нуля. Вы пользуетесь ML-алгоритмами, но вы не используете математический аппарат для обоснования этих алгоритмов как рабочих. Ну и так далее. Ниже (выше) верно отметили, программирование ближе всего к инженерной (т.е. практической) деятельности.

Это ну примерно как быть Стивеном Хокингом, который придумал некую теорию, которую надо проверить на каком-нибудь ускорителе, и быть оператором этого ускорителя. Где-то посередине — те, кто построил ускоритель (создали вашу ОС, средства разработки в ней, тп).
Было бы здорово, если показали то место, где это будет происходить. Так как сказано, что мест будет довольно ограниченное количество, наверняка всем интересно. Особенно в том свете, что многим может быть не комфортно от реально кучи людей в небольшом пространстве. Мы же все-таки программисты, со своими тараканами в головах :-)
Более того, каждый бекендщик должен уметь читать всевозможные конфиги деплоя и сам их писать, при необходимости. Понимать, где будет использоваться локально созданный .env в качестве источника переменных окружения, а где какой-нибудь Consul, и так далее.
То есть данная библиотека помогает внутри DTO разбирать массив на части и раскладывать его по свойствам DTO, или же она подготавливает массив для передачи его в DTO?
Вопрос в том, какие спецификации вы имеете ввиду.
Что и побудило собрать все воедино.

И за это вам большое спасибо.
Логично, как и для любой другой технологии.

Не совсем понял, про что конкретно вы пишете. Есть масса технологий, которая востребована большинством, ну или по крайней мере чувствительной частью сообщества разработчиков.
Не заметил, чтобы это уже писали выше, поэтому напишу сам: использование RPC может быть обусловлено тем, что нужно делать вызов неких бизнес-методов, а не неких действий с ресурсами (давайте отложим в сторону холивар про то, есть или нет вообще ресурсы в REST). И это просто более прозрачно воспринимается, если у нас есть некий микросервис «договоры», который должен позволять сделать операцию «аннулирование договора».

Мы сразу отвязываемся от протоколов, кодов ответов и всего прочего, мы просто на самом верхнем уровне абстракции воспринимаем запрос через RPC так, что служба договоров должна выполнить некое бизнес-действие, возможно с неким ID запроса (про него я тут тоже не услышал), и потом вернуть ответ. Никакой завязки на любой уровень, кроме самого верхнего — тут мы все передадим в некоем достаточно абстрагированном от технологий, обеспечивающих передачу, запросе, тут мы все и получим в виде достаточно такого же ответа.

А все то, что описано в статье и обсуждается в комментариях, на самом деле может быть решено так или иначе в обоих подходах.
Про опережение — согласен, может так и есть. Но в целом вы в итоге написали то, что пишу и я — ниша какая-то уж слишком призрачная. То есть я понимаю написанное вами в посте и согласен, что данный сервис имеет свой круг решаемых им задач, но задумавшись а когда мне это может пригодиться на практике, я понимаю, что скорее всего — никогда, как и большинству.
Я пишу про экспертизу пользователя как разработчика, а не как администратора, DevOps'а и тп. Сложно в общем представить, насколько вообще востребован такой инструмент, он прям какую-то совсем узенькую нишу прикрывает, практически перекрываемую другими вариантами решений.
Критики в адрес вашего способа решения проблемы и так много, так что просто хочу вам посоветовать посмотреть в сторону таких шаблонов проектирования, как Value Object Data Transfer Object. Это не разной степени универсальности библиотека, а подход, который нужно будет реализовывать раз за разом, но в итоге у вас всегда будут именно те объекты именно с теми умениями, которые вам нужны. Еще можете посмотреть в сторону Enum.

При этом это не замена ORM и чего угодно еще, а просто способ работы с данными, который позволяет почти на 100% решить проблемы с документацией к данным в коде, и конечно собственно их использованием.
Интересная штука, но всегда в подобного рода сервисах удивляет, что достаточно высокий уровень экспертизы для их использования пересекается с предложением сэкономить на карандашах.
Этой краткой заметкой хочу пригласить к обсуждению: пробовали ли вы уже PHP 7.4? Если да, то каким был ваш опыт? Собираетесь ли переходить?

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

А вообще, учитывая, что мы живем со строгим режимом типизации, очень ожидаемой фичей будет типизация свойств классов. Давно пора. Ну и еще поддержка вариантов типизации вроде ?false. Раньше такое можно было только в аннотациях указать, теперь будет поддерживать сам язык.
Достаточно познавательно, но все же собственно про само развитие явно можно было написать гораздо более развернуто. А в итоге вышла промо-статья про то, что вы ищете таланты. Но все равно спасибо, было интересно!
тесты, конечно, здорово и полезно, но не увидел в статье упоминания TDD, тесты же не ради тестов

Спустя год, но все же отвечу:
В масштабах всей индустрии, мы по-прежнему привязаны к методологиям тестирования, изобретенным в далекую от нас эпоху, которая разительно отличалась от той реальности, в которой мы находимся сегодня. Люди по-прежнему увлечены идеями вроде полного покрытия тестами (настолько сильно, что в некоторых компаниях merge будет заблокирован, если патч или бранч с новой фичей приводит к понижению степени покрытия кодовой базы тестами более, чем на определенную долю процента), разработкой через тестирование и полным end-to-end тестированием на системном уровне.
Не слишком понятно, что именно вызывало проблемы у пользователей при работе с nfs, у меня все решилось без проблем вот такой добавкой в Vagrantfile:

  if Vagrant.has_plugin? 'vagrant-winnfsd'
    config.vm.synced_folder ".", "/var/www",
      nfs: true,
      mount_options: [
      'nfsvers=3',
      'vers=3',
      'actimeo=1',
      'rsize=8192',
      'wsize=8192',
      'timeo=14'
      ]
  else
    config.vm.synced_folder ".", "/var/www", :mount_options => ["dmode=777", "fmode=666"]
  end


Нашел ее в одном из проектов для разворачивания WordPress на Vagrant. При желании наверняка можно поиграться с параметрами в данном коде, у меня лично прирост обнаружился, не критичный, но при этом ощутимый. Еще, кстати, лично мне помогло выделение двух ядер виртуальной машине. В итоге Vagrantfile получился таким (11 ревизия, если что).
Недостаточное количество света именно что и влияет на качество изображения. Естественно, речь о качестве идет в контексте шумности изображения, а не в контексте удачности кадра, к примеру.

диафрагма не влияет на фокус

Серьезно? По-моему, вы опять не поняли контекст, в котором шла речь.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity