Стиль монад конечно подкупает if err != nil, но в одном из проектов я его попробовал (правда не знал, что это называется монадой)) ). Выглядит красивше, но фактическая последовательность выполнения у вас реализуется в рантайме, а не в коде, как следствие дебажить подобный код — занятие не из приятных, особенно в случае, если вызываемых функций штук 30+.
Посему к предложенному способу рекомендую относиться с большой осторожностью.
Ранее, до go был поклонником node, да у этой технологии (node) есть своя красота и удобство для решения некоторых бизнес задач. Но то, что я вижу в ней сейчас, к большому сожалению, это упор на скорость разработки в ущерб пониманию и безопасности.
В случае сложных проектов это слишком дорого и долго, в отличии от golang.
Аргументом в таких спорах могут служить уже не нужные профессии.
Фонарщик, с приходом электричества остался не у дел, зато появилась целая куча областей, в частности решающих вопрос освещения.
Что на счет людей, которые до изобретения печатного станка копировали книги?
А как же человеки-будильники, бурлаки, авгуры, ткачи, водоносы, таперы, дагеротиписты, телефонисты и т.д?
Мое мнение таково: если железяка может делать твою работу — это конечно печально, но как работник ты никому не нужен, что вполне нормально и первой твоей задачей является получение новой специальности.
Если говорят: я старый, ничего больше не умею — ок, это твой выбор, старей и не моги дальше. И привожу пример: когда-то давно разносил квитанции, это примерно 23-24кг писем на 1 день, я там увидел несколько бабулек, которые брали на день 2 маршрута, редко — 3, как они справлялись я до сих пор не понимаю.
> Поскольку воздух наименее плотный, он хуже всего приглушает звук.
Как правило, чем плотнее материал — тем затухание звука слабее. Чем менее плотный газ — тем сильнее затухание звука. В вакууме звук не распространяется.
После этого вы создаете тестовый HTTP-сервер и легко тестируете этот код.
Зачем писать функциональный тест, если для вашего примера unit будет хватать?
но всё же, практика показывает, что намного лучше всё же не пытаться мокать базу, а разрешать коду работать с какой-нибудь временной базой
Если тестируется именно взаимодействие с БД — вполне резонно, репозитории например. Если тестируется что-то использующее репозитории — базу дергать в абсолютном большинсве случае будет плохой идеей.
Зря вы так считаете, у jira функционала мягко говоря много,. То, что вы привели как пример — это маленькая полезняшка.
меня чуть не сожгли когда я спросил с чего взяли, что gitlab абсолютно запрещает пуши в master…
Вообще говоря не запрещает, но это настраивается)) Видимо вы акцентировали внимание не на плюшках для собеседника, а на плюшках для себя, что ставит в случае переговоров вас в не выгодное положение
"Показать пример" — это работает для высоко мотивированых людей. В противном случае — это должна быть не маленькая работа с вашей стороны.
Проект — самопис на базе zend1, единственный dev, знавший, как работает это кодло в полной мере уволился через 2 недели после того как я пришел. Я конспектировал проблемы (в большинстве архитектурные) проекта около 2х месяцев, далее поговорил с руководством, было дано добро на рефакторинг, параллельно с поддержкой старого.
Проект на svn, команда его переросла и на поддержку уходило огромное количество времени. Я акцентировал внимание на том, что мердж на 150+ конфликтов — это источник ошибок, потраченное время и попросил руководство прикинуть, сколько это в деньгах. Не прошло и пары месяцев, как мы во всю пользовали gitlab.
Проект — что-то монструозное. Dev процесс построен на "песочных" серверах, где у каждого инженера поднято свое окружение. Все вроде хорошо, но очень мэээдленно. Кто-то из десятков пользователей запустит сложный процесс — остальные сразу почувствуют. Я попросил выделить мне 2 дня на поднятия окружения под вагрантом. Было запилено окружение, пусть и не самое лучшее, но более менее оно работало. В один прекрасный момент на песочницах сыпятся веники… Угадайте, как много народу себе вагрант подтянуло и даже поддерживать собралось?))
Проект на php, в соглашениях указано: все аргументы проверяются на тип, в случае обработки — на граничные условия, чуть что бросаем исключение. Фактически это значит, что добрая часть кода — это проверки. Меня задолбало их писать, был написан проект ko-ko-ko/assert, который очень жестко отревьюился. Но разрешение на его внедрение никто не давал… В общем, я прямым текстом за***бал, потому и внедрили. Потом куча народу еще спасибо сказала))
Резюмируя: любое ваше предложение будет по началу восприниматься "в штыки", иногда с конструктивной критикой, иногда — без. Менять что-то просто так — никому не хочется. Именно по этому, что бы внедрить что-то вам придется потратить значительные усилиля.
redmine — вообще говоря вполне норм таск трекер, бесплатный к тому же. Вы вот посчитайте на досуге на вашу компанию сколько обойдется jira + скорее всего другие их продукты, confluence, crucible, bamboo… Сумма может получиться далеко не маленькая.
и даже из него не выжимая ничего кроме списка задач как в Excel
Задайте вопрос PM-у, в чем проблема использования той, или иной нужной, годной и прекрасной фичи, с вашей точки зрения.
использовать Jenkins только для сборок и ни разу для тестирования — потому что так «истерически сложилось»
В чем проблема, договоритесь с админами, что бы вам выделили свой профиль и запускайте тесты там. Если это процесс (автотесты) длительный — люди к вам потянутся. Если же профита не будет никакого — щито поделать, вы хотите то, что никому не надо.
не фиксить тесты тоже сложилось
вот это уже зашквар)) Тесты в такой ситуации теряют смысл
всерьез ставить вопрос «а давайте уберем нексус. лишний компонент вносит риск в систему»
Если пользователи Nexus вам приносят 2,47$ в месяц — это отличная идея
Все эти абстракции и птичие языки нужны для делегирования работы между разными специалистами, экономии вменении разработки, упрощения поддержки и тестирования.
В один прекрасный момент ресурсы у любого железа кончаются и поднимается вопрос о распределении нагрузок. Так уж получается, что основное время ваша система, пусть даже на С будет тупо ждать ответ. С этого ракурса — написав web систему на C вы не особо выиграете. Если же взять во внимание время, которое вы потратите на разработку — это будет на много дороже.
Зачем эту ерунду писать?
Зачем рекурсивно бегать по ФС? :)
Но вот например мы хотим подключать js-скрипты. Наличие скрипта проверяется сначала в папке шаблона (если нужна специфичная версия), потом в шаблоне по умолчанию, потом в папке по умолчанию.
Действительно))
Зачем? ОС сама закеширует файлик на 2 строки и факт его наличия/отсутствия.
да-да, вы только подтверждаете мои слова, а не опровергаете.
С вами было весело общаться, но на этой веселой ноте давайте заканчивать. Вы как google-translate, что-то пишете, но без малейшего осознания.
То есть отдавать ему пути ко всем скриптам на сайте.
nope, клиент собирается и зависимостями рулит самостоятельно, без помощи php. Со стороны бэка грузятся только данные.
Но тогда этой логикой нужно будет снабдить приложение :) Приходим туда, откуда пришли :)
фронт должен знать из чего состоит фронт… и не поспоришь))
Отдавать только те скрипты, которые оно может использовать
Возвращайтесь в 2016-ый)) Фронт в случае SPA сам решает, что у него есть, что нужно догрузить и что нужно обновить.
Но для этого следует использовать $JS->jquery() или $JS->package('jquery'), который, ну признайте, ну вот ни чем не лучше __call() :)
Я понимаю, что ваше черезжопное решение самое прекрасное и восхитительное для вас, но в реальности эта же задача решается принципиально по другому. Почему же оно черезжопное? Да все просто:
вы на каждый запрос дергаете рекурсивно файловую систему, для HL — это самоубийственная практика. ramfs может спасти, но даст дикий оверхэд.
А можно отдавать какие скрипты нужно подключить по конкретному запросу, но тоже нужно это расчитать.
Вы понятие не имеете о чем говорите. В случае SPA бэк вообще не участвует в управлении его скриптами. С точки зрения бэка — это не более, чем просто статические файлы, которые отдаются nginx-ом. PHP в этом процессе вообще не участвует.
То есть вы придумываете разную ерунду и сложности, которые как бы даже не совсем для решения задачи в случае с SPA
Нет слов)) Ну вот серьезно, вы бы хоть чуть-чуть разобрались в том, о чем говорите))
Доверь таким программистам-фреймворщикам сайт писать. :)
Кхм, я себя сайтоделецем и не считаю)) Бэкенд инженер — уже ближе. Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.
Рекомендую ознакомиться: https://toster.ru/q/276441#answer_723827, там я описывал, на что стоит обращать внимание при проверке кода
Если вы ловите исключение и хотите его пробросить выше — его бросаете вручную. Разница есть только для языков с поддержкой множественных catch.
согласен
panic + defer + recover. Во многих ситуациях этот механизм гибче и удобнее, чем классический throw + catch
Стиль монад конечно подкупает if err != nil, но в одном из проектов я его попробовал (правда не знал, что это называется монадой)) ). Выглядит красивше, но фактическая последовательность выполнения у вас реализуется в рантайме, а не в коде, как следствие дебажить подобный код — занятие не из приятных, особенно в случае, если вызываемых функций штук 30+.
Посему к предложенному способу рекомендую относиться с большой осторожностью.
Ранее, до go был поклонником node, да у этой технологии (node) есть своя красота и удобство для решения некоторых бизнес задач. Но то, что я вижу в ней сейчас, к большому сожалению, это упор на скорость разработки в ущерб пониманию и безопасности.
В случае сложных проектов это слишком дорого и долго, в отличии от golang.
На счет npm — собственно, а чему удивляться то?))
С точки зрения вбивания в голову простой истины: "проверяй свои зависимости" — это отличное решение.
Аргументом в таких спорах могут служить уже не нужные профессии.
Фонарщик, с приходом электричества остался не у дел, зато появилась целая куча областей, в частности решающих вопрос освещения.
Что на счет людей, которые до изобретения печатного станка копировали книги?
А как же человеки-будильники, бурлаки, авгуры, ткачи, водоносы, таперы, дагеротиписты, телефонисты и т.д?
Мое мнение таково: если железяка может делать твою работу — это конечно печально, но как работник ты никому не нужен, что вполне нормально и первой твоей задачей является получение новой специальности.
Если говорят: я старый, ничего больше не умею — ок, это твой выбор, старей и не моги дальше. И привожу пример: когда-то давно разносил квитанции, это примерно 23-24кг писем на 1 день, я там увидел несколько бабулек, которые брали на день 2 маршрута, редко — 3, как они справлялись я до сих пор не понимаю.
Как правило, чем плотнее материал — тем затухание звука слабее. Чем менее плотный газ — тем сильнее затухание звука. В вакууме звук не распространяется.
Зачем писать функциональный тест, если для вашего примера unit будет хватать?
Если тестируется именно взаимодействие с БД — вполне резонно, репозитории например. Если тестируется что-то использующее репозитории — базу дергать в абсолютном большинсве случае будет плохой идеей.
Спасибо за статью, еще бы пункт "Из PHP" — цены бы не было))
Если в компании платят за время, а не за реализованные задачи — экономить время вполне может быть плохой идеей.
Зря вы так считаете, у jira функционала мягко говоря много,. То, что вы привели как пример — это маленькая полезняшка.
Вообще говоря не запрещает, но это настраивается)) Видимо вы акцентировали внимание не на плюшках для собеседника, а на плюшках для себя, что ставит в случае переговоров вас в не выгодное положение
Смею предположить, что не умеете его готовить
подтверждаете мои слова.
ну и пофиг)) вам больше всех надо?
это плохо, очень.
Если это чисто ваше "благо" — действительно. Если общее — странно.
тыкните носом на википедию, где черным по белому написано, что такое jenkins))
пересмотр приоритетов на внутренние наработки — это вполне норм. Если результат не используется — зачем его делать?
это домоклов меч над всей вашей компанией, рано, или поздно он упадет, будьте готовы))
"Показать пример" — это работает для высоко мотивированых людей. В противном случае — это должна быть не маленькая работа с вашей стороны.
Проект — самопис на базе zend1, единственный dev, знавший, как работает это кодло в полной мере уволился через 2 недели после того как я пришел. Я конспектировал проблемы (в большинстве архитектурные) проекта около 2х месяцев, далее поговорил с руководством, было дано добро на рефакторинг, параллельно с поддержкой старого.
Проект на svn, команда его переросла и на поддержку уходило огромное количество времени. Я акцентировал внимание на том, что мердж на 150+ конфликтов — это источник ошибок, потраченное время и попросил руководство прикинуть, сколько это в деньгах. Не прошло и пары месяцев, как мы во всю пользовали gitlab.
Проект — что-то монструозное. Dev процесс построен на "песочных" серверах, где у каждого инженера поднято свое окружение. Все вроде хорошо, но очень мэээдленно. Кто-то из десятков пользователей запустит сложный процесс — остальные сразу почувствуют. Я попросил выделить мне 2 дня на поднятия окружения под вагрантом. Было запилено окружение, пусть и не самое лучшее, но более менее оно работало. В один прекрасный момент на песочницах сыпятся веники… Угадайте, как много народу себе вагрант подтянуло и даже поддерживать собралось?))
Проект на php, в соглашениях указано: все аргументы проверяются на тип, в случае обработки — на граничные условия, чуть что бросаем исключение. Фактически это значит, что добрая часть кода — это проверки. Меня задолбало их писать, был написан проект ko-ko-ko/assert, который очень жестко отревьюился. Но разрешение на его внедрение никто не давал… В общем, я прямым текстом за***бал, потому и внедрили. Потом куча народу еще спасибо сказала))
Резюмируя: любое ваше предложение будет по началу восприниматься "в штыки", иногда с конструктивной критикой, иногда — без. Менять что-то просто так — никому не хочется. Именно по этому, что бы внедрить что-то вам придется потратить значительные усилиля.
redmine — вообще говоря вполне норм таск трекер, бесплатный к тому же. Вы вот посчитайте на досуге на вашу компанию сколько обойдется jira + скорее всего другие их продукты, confluence, crucible, bamboo… Сумма может получиться далеко не маленькая.
Задайте вопрос PM-у, в чем проблема использования той, или иной нужной, годной и прекрасной фичи, с вашей точки зрения.
В чем проблема, договоритесь с админами, что бы вам выделили свой профиль и запускайте тесты там. Если это процесс (автотесты) длительный — люди к вам потянутся. Если же профита не будет никакого — щито поделать, вы хотите то, что никому не надо.
вот это уже зашквар)) Тесты в такой ситуации теряют смысл
Если пользователи Nexus вам приносят 2,47$ в месяц — это отличная идея
Все эти абстракции и птичие языки нужны для делегирования работы между разными специалистами, экономии вменении разработки, упрощения поддержки и тестирования.
В один прекрасный момент ресурсы у любого железа кончаются и поднимается вопрос о распределении нагрузок. Так уж получается, что основное время ваша система, пусть даже на С будет тупо ждать ответ. С этого ракурса — написав web систему на C вы не особо выиграете. Если же взять во внимание время, которое вы потратите на разработку — это будет на много дороже.
Действительно))
да-да, вы только подтверждаете мои слова, а не опровергаете.
С вами было весело общаться, но на этой веселой ноте давайте заканчивать. Вы как google-translate, что-то пишете, но без малейшего осознания.
Месседж был в контексте SPA. Прочитайте пункт Goals.
что в воду преднул)). Трафик на оборот уменьшается.
В случае подходов, что он предлагает 100rps можно расценивать как довольно серьезную нагрузку (загрузку статики я не учитываю). Ну сами посудите:
nope, клиент собирается и зависимостями рулит самостоятельно, без помощи php. Со стороны бэка грузятся только данные.
фронт должен знать из чего состоит фронт… и не поспоришь))
Возвращайтесь в 2016-ый)) Фронт в случае SPA сам решает, что у него есть, что нужно догрузить и что нужно обновить.
Я понимаю, что ваше черезжопное решение самое прекрасное и восхитительное для вас, но в реальности эта же задача решается принципиально по другому. Почему же оно черезжопное? Да все просто:
вы на каждый запрос дергаете рекурсивно файловую систему, для HL — это самоубийственная практика. ramfs может спасти, но даст дикий оверхэд.
Вы понятие не имеете о чем говорите. В случае SPA бэк вообще не участвует в управлении его скриптами. С точки зрения бэка — это не более, чем просто статические файлы, которые отдаются nginx-ом. PHP в этом процессе вообще не участвует.
Нет слов)) Ну вот серьезно, вы бы хоть чуть-чуть разобрались в том, о чем говорите))
Кхм, я себя сайтоделецем и не считаю)) Бэкенд инженер — уже ближе. Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.