• UI тесты: Cucumber + Selenide
    0
    Так что это только вопрос времени, когда до всех [your language]-кукумберов дойдет, что эти степы не нужны в BDD-фреймворке.
  • UI тесты: Cucumber + Selenide
    0
    А, вот, нашел планы по удалению их в php-кукумбере тоже: https://twitter.com/BehatPHP/status/700679895316373504?lang=en
  • UI тесты: Cucumber + Selenide
    0
    Прошу прощения, обманул насчет всех. Нашел только в оригинальном cucumber:
  • UI тесты: Cucumber + Selenide
    0
    В целом BDD это не совсем про тесты — это про документацию и коммуникацию, скорее. Из всех фреймворков поэтому давно поудаляли встроенные степы «я нажимаю на кнопку».
  • UI тесты: Cucumber + Selenide
    +1
    And type to input with name "userName" text: "riskmarket.testoviy2016@yandex.ru"
    And type to input with name "password" text: "l0dcfJMB”
    When type to input with name "lastName" text: "TESTOVIY"
    And type to input with name "firstName" text: "TEST"


    То, что вы делаете, считается антипаттерном в BDD. Сценарии должны быть на языке домена:
    Given there is user Alice
  • Число прописью в Laravel 5
    +4
    Уберите nbproject. Разделите на 2 проекта: фреймворконезависимая библиотека и драйвер к ларавелу.
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    0
    Ну смотреть надо конкретно в каждом случае. Алгоритм на всё не придумаешь.
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    +4
    О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    +1
    Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    +2
    Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    0
    Если цель фичи — проверить приветствие, то можно написать
    Given Я пользователь Вася Пупкин
    When Я логинюсь
    Then Я должен увидеть приветствие

    Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
    Я пользователь Вася Пупкин
    У меня баланс $100
    Я покупаю подписку
    У меня баланс должен стать $50

    вместо
    Я нажимаю «логин»

    Я нажимаю «оплатить»

    Я должен увидеть $50
  • Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
    +1
    У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
    я нажимаю на ссылку «войти»
    я ввожу «васяпупкин» в поле мыла
    я ввожу «васяпупкин1111» в поле пароля
    я нажимаю на кнопку «войти»
    я должен увидеть «здравствуйте, Вася Пупкин!»

    что-то вроде этого:
    Я пользователь Вася Пупкин
  • Про роль техлида
    +8
    А можно поинтересоваться источником этой элементарной терминологии?
  • Composer — the right way
    0
    Это устаревшая инфа. Вот новая: docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git
  • Обучаем сотрудников английскому: опыт Edison
    0
    Для меня первый сериал был Футурама, совершенно все понятно было еще тогда, когда я инглиш знал очень и очень плохо (если смотреть с субтитрами). Возможно, кому-то не понравится. А так да, советуют все друзей. Но футурама проще намного. Подозреваю Family Guy и симпсоны такой же уровень будут.
  • Подключение к Git по SSH в Windows без PuttyGen на примере BitBucket
    +6
    Почему он не подцепляет ключ, сгенерированный ssh-keygen я не знаю.

    Не самая лучшая фраза, которую может сказать software developer. Лучше бы разобраться с проблемой, а не плодить костыли.
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    –1
    Пункты 2-3 самые прикольные у вас. Получается, программисту надо доплачивать за то, что он будет думать во время работы? И не каждый программист хочет думать во время работы? WAT??? Я всегда думал, что программист должен делать все, что в его силах в свое рабочее время, чтобы сделать работу лучше. Оказывается, нет?
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    +1
    Я вообще сторонник подхода, чтобы не разделять прототип и продукт. Я убежден, что прототип постепенно должен становиться продуктом по мере работы над ним. Самые кривые вещи должны постепенно рефакториться, когда они начинают доставлять неудобства. И таким образом, кривой тяп-ляп прототип постепенно должен превращаться в нормальный продукт. Мне кажется, такая эвристика в большинстве случаев подходит, если надо что-то побыструхе вывести на рынок и протестировать идею. Потому что будем честны, много ли прототипов удается переписать с нуля? Обычно этот шаг откладывается до одного большого «рефакторинга», который никогда не наступает.
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    0
    Вы так недалекоглядны

    Ну офигеть, пошел переход на личности и ярлыки.
    Не всегда в бизнесе преследуют только краткосрочные цели

    Эммм. А я где говорил про краткосрочные vs долгосрочные? Я говорил — дешевле. Решить, дешевле на каком промежутке это должно быть — задача бизнеса, а не программиста.
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    0
    Ниже отличный коммент про менеджмент vs программисты.

    Вы про мой коммент ниже или про какой? =)
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    0
    Бизнес нанимает программиста, чтобы заработать денег. Ему не то чтобы сильно важно, что там под капотом. Поэтому когда вы придете к нему и скажете «вы хотели качества», он вас не поймет, и вы поругаетесь. Единственная причина рефакторить — сделать то же самое дешевле, чем это было бы без рефакторинга. Иначе рефакторинг бесполезен.
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    0
    Я думаю, что в этом вся и проблема, что многие думают «оптимизация бизнеса — вообще не его головная боль».

    Я считаю, что подход «девелоперы беспокоятся про оптимизацию бизнеса» может применяться на абсолютно любого размера проектах, начиная от ситуации, где проект делает 1 девелопер, и для этого не должно быть никаких требований по наличию или отсутствию каких-либо ролей. У нас только так не принято пока что, к сожалению. Вот и страдаем.
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    +1
    Немного оффтоп.

    Я абслютно согласен: рефакторинг — не дело менеджеров или бизнеса. Команда сама должна решать, когда и сколько делать рефакторинг. Единственный критерий тут, и единственная причина делать рефакторинг: как быстрее и дешевле (при заданном бизнесом уровне надежности) сделать для бизнеса то, что ему надо. И тут уже это могут знать только технические специалисты.

    Другое дело, что часто менеджемент не доверяет техническим специалистам в этом вопросе. И, кстати, правильно делает =). Потому что очень часто программисты подменяют «быстрее и дешевле» на «нам интереснее». И это часто можно видеть не только от новичков, но и от очень серьезных девелоперов. Когда за счет бизнеса идет обучение новым технологиям или просто развлечение со всякими крутыми штуками.

    Отсюда у меня такой вывод: в извечной войне «менеджеры против рефакторинга» программисты должны для начала учиться работать с менеджементом и с бизнесом по одну сторону баррикад. Постепенно работать над этим доверием, когда если программист говорит «нам надо делать А», это значит, что программист совершенно уверен, что для бизнеса «А» будет полезно, а не это просто его прихоть изучить технологию «А».
  • Как переписать большой проект или безболезненный для бизнеса рефакторинг
    +5
    Вы описали очень хороший способ перехода с одного фреймворка на другой. Но по моему опыту (я писал раньше на Kohana, и пишу теперь на Symfony), степень говнокода — это особенность системы, а не фреймворка, на которой все написано. Если у вас были тяжелые и непонятные контроллеры в Kohana, вас будут ждать такие же в Symfony, и поддерживать это дело на Symfony будет не обязательно проще (а чаще — сложнее, т.к. вы начнете тратить уйму времени на борьбу с фреймворком там, где раньше вы просто делали class Kohana extends Kohana_Core и вворачивали любой костыль). Я бы посоветовал вам бросить ресурсы не на переход от одного фреймворка на другой, а на рефакторинг кода в рамках одного фреймворка. Возможно, имеет смысл начать юзать высококачественные компоненты (Doctrine, symfony/form) в вашем проекте на Kohana. Или начать выносить бизнес-логику из контроллеров в отдельный слой. И это может дать намного больше профита с меньшими затратами, чем переписывать все на другом фреймворке.
  • Нюансы коммерческой разработки на WordPress
    0
    И сильно, бывает, отличается конверсия? Как это замерялось? Вы брали смотрели конверсию на старом сайте и сравнивали ее с конверсией после редизайна?
  • Нюансы коммерческой разработки на WordPress
    0
    А часто бывает так, что приходит клиент и хочет ну совершенно не то что ему надо, и никак не переубедить? Скажем, хочет, чтобы нарисовали дизайн, хотя можно сделать в 100 раз красивее и в 10 раз дешевле на готовом бесплатном или купленном за 15$.

    Я недавно делал проект достаточно большой и сложный, там прикидывали на дизайн надо было тыщ 50-100, наверное, если делать дизайнером и потом верстать это все. В итоге мы купили за 15$ на wrapbootstrap тему и еще за 20$ сделали логотипчик. И даже без помощи верстальщика все сделали. И получилось очень норм в итоге. Есть похожие примеры у вас из вашей практики?
  • Нюансы коммерческой разработки на WordPress
    +4
    Возможно, вопрос не совсем в тему статьи, но все же очень связан с ней. И вы наверняка имеете все знания и данные, чтобы прокомментировать его. Когда я был школьником и фрилансил, я делал огромное кол-во недорогих сайтов на собственном велосипеде. Пусть это были не сайты на вордпрессе, но они были достаточно дешевы для клиента и делались достаточно быстро. Так вот, вспоминая то время, я начинаю понимать вот что: пользы от этих сайтов в большинстве своем было ровно 0. Как это происходило: приходит клиент в «студию» с такой мыслью: «мне нужен сайт». Как этот сайт поможет бизнесу — хз, но он должен быть. Менеджер тоже не заинтересован помочь бизнесу, его задача — продать сайт. Потом они утверждают дизайн и неделю играются со шрифтами. Потом я программирую это все. В итоге на свет рождается очередной никому не нужный сайт, пусть и не очень дорого. И мне теперь очень печально от такого, потому что все (и мы в том числе в то время) из-за конфликта интересов (бизнесу не нужен сайт, но нам нужно его продать) продавали сайты, а не помогали бизнесу.

    В связи с этим такой вопрос. Есть ли у вас реальные примеры того, как дешевые быстро делающиеся сайты на вордпресс помогают бизнесу экономить деньги на разработке действительно нужных им вещей (а не очередного никому не нужного сайта-визитки)? Задумываетесь ли вы над этими вопросами, когда продаете очередному клиенту очередной сайт?
  • Как узнать местоположение пользователя, зная только его email-адрес
    +5
    Мне логика подсказывает, что CSS не будут подгружаться как и картинки, иначе смысла не подгружать картинки нету.
  • Как узнать местоположение пользователя, зная только его email-адрес
    +10
    Поэтому gmail не подгружает автоматически картинки в письмах.
  • Паттерн «Репозиторий». Основы и разъяснения
    0
    Мы, видимо, говорим о разных вещах. Вы говорите о том, как готовить данные для тестов. А я говорю о том, как хранить данные внутри тестов. Так вот если весь сценарий проходит внутри одного процесса, то можно юзать InMemoryRepository. Если нет (UI тесты, например, где надо хранить состояние между запросами), то InMemoryRepository уже не подойдет, и надо юзать что-то, что кладет коллекции энтитей в файлы. Например что-то на основе репозитория по ссылке в статье.

    Как готовить данные для теста это отдельный вопрос.
  • Паттерн «Репозиторий». Основы и разъяснения
    0
    Не понял, при чем тут дата-фэктори? Мы заменяем доктрин репозиторий на репозиторий, который кладет сериализованный массив энтити в файл вместо БД. Базовый класс для такого репозитория можно взять на гитхабе по ссылке в статье, кстати — оно для этого и задумывалось. Про поддержку тестов, смотря с чем сравнивать. Если сравнивать с подходом того же everzt-а Modelling By Example, то использование data-factory на его фоне выглядит так себе.

    Хорошо оно ли для функциональных тестов, вопрос, конечно, спорный. Я считаю, что можно написать кучу интеграционных тестов чисто на доктрин-репозитории, а UI тесты уже с моками делать. Сам пока не пробовал такой подход.
  • Паттерн «Репозиторий». Основы и разъяснения
    +1
    Захотел откомментить, что интерфейс должен быть на уровне домена, а реализация на уровне приложения, через минуту об этом прочитал. Захотел добавить ссылку на либу пользователя everzet, увидел через минуту. =) Прям согласен с каждым словом в статье!

    Добавлю от себя: кто-то (возможно everzet, но я не уверен) предложил очень интересный способ ускорения даже UI тестов. Нужно заменить Doctrine репозитории на репозитории на обычных файлах на время выполнения UI тестов. Т.о. у нас сохраняется persistence, но убирается лишняя нагрузка на парсинг DQL, гидрацию и пр, а так же убирается необходимость чистить БД перед каждым сценарием.
  • Производительность shared-папок в Vagrant
    0
    Утянул ваш конфиг себе. Надеюсь мои проблемы с NFS решатся вашими mount_options =).
  • Web-разработка с комфортом: Parallels Desktop 10 + Vagrant
    0
    спасибо! =)
  • Производительность shared-папок в Vagrant
    0
    Мы работали на одном проекте по samba с гостя, очень успешно. Только надо помнить, что гит должен работать на той же системе, на которой лежат файлы. Т.е. в данном случае — на госте через ssh. Все девелоперы (и верстальщики) юзали консольный гит по ssh и не парились. Но у такого сетапа есть два минуса: 1) vagrant up надо делать не в рабочей копии проекта, а в другом месте, а потом уже рабочую копию вручную маунтить на хост, что не очень удобно, 2) IDE не то чтобы сильно быстро индексирует файлы, которые доступны через шару (не очень критично на самом деле для нас оказалось, приходилось подождать изредка 30 сек, нуок).
    Теперь я юзаю везде NFS (файлы на хосте), на OSX без вопросов завелся, даже на винде. Но тоже есть проблемы вечно какие-то, то файл не сразу увидит, то время изменения неверное видно, хз. Надо будет попробовать ваш способ.
  • Несколько интересных особенностей MySQL
    +8
    Приводить такую настройку как типовой конфиг для человека, которому не хочется самому разбираться в тонкостях, жестого =)
  • Несколько интересных особенностей MySQL
    0
    synchronous_commit = off

    разве не отключит гарантию сохранности данных?
  • Несколько интересных особенностей MySQL
    0
    Предположим у нас миллион записей в таблице, a = num / 1000, b = num % 1000. Тогда запрос WHERE a = X AND b = Y в случае составного индекса просто найдет одно число в индексе и вернет запись. Тот же запрос в случае двух индексов выберет тысячу записей для первого индекса, отсортирует их по адресу хранения, выберет тысячу записей из второго индекса, отсортирует их…
  • Несколько интересных особенностей MySQL
    0
    Моя логика подсказывает, что найти записи в дереве в случае составного индекса как ни крути должно быть намного проще и быстрее, чем пройтись по двум индексам, отсортировать в обоих (добавлено: найденные) данные по физическом расположению, сделать битовые операции. Другое дело, в каком кол-ве случаев разница действительно важна.
  • Несколько интересных особенностей MySQL
    +1
    Разницы не может не быть принципиально. Для выборки используются разные алгоритмы, а значит сложность у них все-равно разная будет. Другое дело, что на очень большом кол-ве случаев в Postgres не нужен составной ключ, а вполне можно юзать два раздельных (по крайней мере у них так написано в книжке high performance Postgres). Но поиск по двум раздельным индексам в любом случае, насколько я понимаю, будет хуже поиска по составному индексу.