Ищем двух крутых рубистов в команду: http://www.rubyjobs.ru/vacancies/5212 Есть задачи на 40 часов в неделю, удалёнка, один проект, а не разработка на заказ.

Быстрый слепой набор на кириллице и латинице Самый Ваш большой недостаток и самое большое достоинство. Кем себя видите через 5 лет?

словно взято из книги "как испортить вакансию" )

> Уже два года вижу эту вакансию :) Первую работу искал натыкался. Ага, мы выросли с двух человек до 8 за несколько лет.

(отдел разработки)

кем себя видите через 5 лет? - всегда ставит в тупик

Задумываться о жизненных целях полезно :)

кем себя видите через 5 лет? - всегда ставит в тупик

я всегда говорю, что вижу себя рептилоидом, поработившим жалких теплокровных

каков вопрос - таков ответ )

спасибо) запомню

кем себя видите через 5 лет? - всегда ставит в тупик

через 5 лет я вижу себя человеком, который сделал вас мультимиллионером

потому что мои знания позволят вашей компании стать более competitive на рынке

ну и т.д.

это типа ожидаемый ответ - типа ждут от тебя, что ты будешь про контору задвигать

i know exactly what needs to be done to make your business 10 times more successful from a technical standpoint

не стесняйтесь в выражениях))

Ага, но вам скажу что я имел ввиду только после испытательного

кем себя видите через 5 лет? - всегда ставит в тупик

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

для поиска что используете? sphinx elastic? никогда не делал

Ищем двух крутых рубистов в команду: http://www.rubyjobs.ru/vacancies/5212 Есть задачи на 40 часов в неделю, удалёнка, один проект, а не разработка на заказ.

Делал я этим ребятам тестовое - тратил свое время. Они увидели, что ни одного теста нет и даже смотреть не стали. Меня это изрядно подбесило тогда. В вакансии они этого не пишут специально.

Виталий, в описании вакансии вторым пунктом указано «TDD и документирование кода. Обязательно.» То, что у Вас в решении не было ни одного теста — ошибка.

Прошу заменить, что это в требованиях к сотруднику - в тестовом задании такого требования указано не было.

Лан. Я больше писать на эту тему не буду. Но дам два совета - подсакротите описание вакансии. Зачем там отзывы? Это же не лендинг. Чтобы люди не тратили своё время на описание прелестей вашей компании. И наконец, сформулируйте четкие требования в самом тестовом.

Виталий, в описании вакансии вторым пунктом указано «TDD и документирование кода. Обязательно.» То, что у Вас в решении не было ни одного теста — ошибка.

Обязательно TDD? Любопытно. Вообще DHH как-то сказал, что TDD умерло. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html - ну и в самом деле, пишут тест вначале только какие-нибудь начинающие кодеры, далекие от реальности. В жизни ты сначала делаешь функционал, а потом накидываешь тест. Но не наоборот - сначала тест, а потом уже функционал - так _на практике_ очень редко кто делает, и вообще я считаю что на практике это никогда не работает. также: In practice, according to my experience while working with more than 250 developers over the last four years, it means writing tests when we're in a good mood and have nothing else to do. http://www.yegor256.com/2017/03/24/tdd-that-works.html

по последней ссылке чел вообще деплоит сначала в продакшн, а потом накидывает тест если что сломалось. Но он делает это на джаве, на рубях и js я так не делаю - гемора много. Но и пришел к выводу, что 100% на рубях и js покрывать не надо. Только критические части.

> Прошу заменить, что это в требованиях к сотруднику - в тестовом задании такого требования указано не было. > И наконец, сформулируйте четкие требования в самом тестовом.

Виталий, хватит уже спорить. Не написали тесты — не взяли Вас на работу.

Вывод: пишите тесты.

Ro, Вы правы, надо будет заменить «TDD» на просто тестирование. Лишь бы это не ручное тестирование было :)

> 100% на рубях и js покрывать не надо согласен

> деплоит сначала в продакшн, а потом накидывает тест если что сломалось а вот с этим не согласен :)

а я согласен, я вот в 2012 году сделал без единого гвоздя geekjob.ru

задеплоил, работает

правда дело было на C#

(сайт я потом продал, поэтому он такой тухлый)

Ключевые слова ведь «я сделал и потом продал». А если в команде несколько человек и проект длится годами?

так что на C#, Java, и даже TypeScript возможно писать без тестов до деплоя)

Ключевые слова ведь «я сделал и потом продал». А если в команде несколько человек и проект длится годами?

если проект длится годами, то это означает, что программисты хорошо работали - не просаживали бюджет на что попало

в этом случае можно добавить несколько тестов (интеграционных) - чтобы покрыть самые чувствительные части

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

т.е. когда речь о том, чтобы написать проект с минимальным бюджетом (как это сделал я), то такой подход самое то

Смотря насколько большой проект и сколько людей над ним работает.

ну если он большой, то и бабки значит есть)

можно писать тесты сколько влезет)

Если разработка на заказ и проекты потоком идут — вот тогда тяжело в бюджете найти деньги на дополнительное время на тесты. А если проект свой, внутренний, то в итоге оказывается дешевле писать с тестами.

а что значит "в итоге"?) до "в итоге" надо еще дотянуть. Т.е. "в итоге" это когда бабки уже есть. А вот когда их нет, то чтобы дотянуть до этих "в итоге", то надо затратить как можно меньшее кол-во ресурсов

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

вот такая аналогия с этими тестами

> А вот когда их нет, то чтобы дотянуть до этих "в итоге", то надо затратить как можно меньшее кол-во ресурсов Такое тоже имеет место быть

Я тут вставлю свои пять копеек, можно?) в большом проекте, который тянется годами, и над которым работает много народа, обычно есть QA отдел, который и пишет тесты и занимается тестированием. Имхо, конечно же.

я тут был на проекте

да чего греха таить, вот он:

http://www.atp.com/

работал в этой конторке

там было полтора теста, один из которых был красный

а QA отдел тестировал ручками

контора цветет и пахнет, в итоге владелец ее продал очень хорошо потом

контора - софт для документации по самолетам

ага, по самолетам и без тестов))

ага, по самолетам и без тестов))

Что ещё раз подтверждает реалии бизнеса. :) Главное, чтобы работало.

видимо для написании доков хватает шаблонов

ну там не совсем дока. Там был дополнительный продукт - по обслуживанию самолетов

ну короче довольно ссыкотная тема конечно без тестов

но как показала практика, владелец бизнеса разбогател в итоге все равно)

ERROR: S client not available

можно ли было сделать лучше? да. Принесло бы это больше денег? ну... сложный вопрос)

можно ли было сделать лучше? да. Принесло бы это больше денег? ну... сложный вопрос)

О чём и речь. Зачастую это никому не нужно.

а вот без тестов были там еще рабочие места благодаря этому - люди тестированием занимались)

вот сегодня какой-нибудь адепт программирования последует моим советам, тестами не покроет, а завтра окажется, что из-за этого нужен еще один программер. И из этого чата какого-нибудь джуна на работу возьмут)

хах))

Так это же хорошо! Рабочие места!

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

Зато потом с ними на порядок легче расширяться и рефакторить

А вот что касается скорости слепого набора, то он гораздо полезнее в чатиках сидеть, чем при разработке )))

может быть, но я вот тока что рефакторил 1 небольшой класс. Кода там на 20 строк, а тестов на 100

в итоге отрефакторил так, что все тесты надо было переписывать

ну и забил, удалил файл с тестами просто

жду теперь когда все сломается))

Потому что надо не классы покрывать тестами а функционал

Это не tdd а bdd

да я в итоге накачу 1 интеграционный тест, он покроет кучу кода сразу. И даже то, что нельзя было покрыть юнит-тестами

такая вот моя мысль

Тоесть есть у тебя сервис объект, который что-то печатает, ты его отрефакторил, а метод perform по прежнему делает то же самое

Вот тесты и не надо переписывать, и ты уверен, что он делает, что должен

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

когда дизайн не стабилизировался, это довольно часто требуется

Интеграционные очень долгие в выполнении и потом тяжело искать, где в этой куче кода что сдомалось

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

Тогда это не рефакторить, а переписывать нафиг целиком )

ну по сути интеграционный тест - это happy path по которому юзер идет, хорошо это иметь в любом случае

Ну это да

ну вот в итоге я и отрефакторил так, что почти переписал)

ну и тесты было влом переписывать и я подумал - а зачем я их вообще писал

их даже никто не видел)

написал и удалил

Ci видел, и перед деплоем тебе показывал

По крайней мере должен был