Достаточным для чего?

ну в какой то ситуации норм, но это не гарантирует доставку

Тест может проверять или не проверять контент письма. Система может подставлять или не подставлять переменные в письмо. Скажем так, если Цель теста - проверить что что-то кому-то отправилось - то достаточно. Если цель - проверить, что отправилось то, что нужно - то недостаточно. Если цель - проверить e2e , что юзер какого-то конкретного почтового сервиса увидит письмо - совсем недостаточно.

грамотно, спасибо

В продолжение вопроса - а Robotium или Selendroid кто-нибудь использует?

Если хотите что-то спросить - сначала задайте вопрос. Тот, кто в теме - сам вам ответит. Не пытайтесь сначала завладеть вниманием всех, а потом спрашивать. Это не работает и только тратит ваше и наше время.

Шапка

вероятно что из 1.8к людей кто-то использует/использовал

Поэтому и спрашиваю, используют ли сейчас. Мне будет достаточно самого факта: да, есть люди, которые это используют.

lol

никто не использует, это дипломная работа ПТУшника, никому нафиг ненужная

никто не использует, это дипломная работа ПТУшника, никому нафиг ненужная

Он ее не сдал кстати

Андрей, вы про Robotium?

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

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

потому что это выглядит ОЧЕНЬ странно )

Поэтому и спрашиваю, используют ли сейчас. Мне будет достаточно самого факта: да, есть люди, которые это используют.

Поэтому и спрашиваю, используют ли сейчас. Мне будет достаточно самого факта: да, есть люди, которые это используют.

используем, мигрируем в Espresso

Всем привет. Мне нужно сделать SOAP-овую заглушку, способную выдержать двести-триста запросов в секунду. Пока что использовал для создания заглушек SoapUI, но не уверен что оно выдержит такую нагрузку. Заглушка должна быть именно заглушкой (stub) - отдавать простой и тупой ответ на post-запрос, никакой параметризации. Там где собираюсь развернуть заглушку стоит серверная убунта. В какую сторону смотреть?

В сторону кэширования запросов. :D

Если из палок и говна, то 2-3-n компов/серверов с балансировкой по DNS

В сторону кэширования запросов. :D

А Вас не затруднит дать ссылку на более развёрнутый материал? Пока не представляю себе с чего начать.

Если из палок и говна, то 2-3-n компов/серверов с балансировкой по DNS

Нету ни первого, ни палок, ни серверов, ни балансировщика.

https://www.nginx.com/blog/nginx-caching-guide/

https://www.nginx.com/blog/nginx-caching-guide/

Спасибо большое

В каких случаях делать нагрузочное тестирование уместно? Если в ТЗ например есть несколько требований касательно скорости работы системы, но сказано что, скажем, в секунду работает не больше 50 юзеров, а вообще не больше тысячи, то есть смысл включать в тест план нагрузочное тестирование? Или это зависит ещё от бюджета проекта?

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

а вы предложите в формате on demand

Так и указать в тест плане?

Ну прикол в том что ещё нужно разработать стратегию тестирования производительности

Если не нужно оно вообще, то и над стратегией думать не придется

Так и указать в тест плане?

это больше оценка + подходы?

для прояснения на каком вы этапе

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

Я пишу свой первый тест план, мне дали ТЗ и сказали "Сделайте тест план"

окей

вы сами нагрузочным тест-ем занимаетесь?

Нет

тогда вы не можете дать оценку и подходы на него

верно?

чаще всего хватает 5-10 запросов в постмане ДО и ПОСЛЕ чтобы уже понимать аномально другое время выполнения метода

Об этом думал, верно. В таком случае тест лид должен советоваться с тестировщиком, который знает нагрузочное?

Я не тест лид, просто спрашиваю

для всего остального: иметь выборку по пользователям \сущностям API метода, на них гонять в jmeter 1000-10000 запросов при холодном кеше в Redis, и при закешенном, например.

Об этом думал, верно. В таком случае тест лид должен советоваться с тестировщиком, который знает нагрузочное?

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

в 9\10 случаев такое делать не нужно без совета от разработчика + ревью глазами кода того, что он поменял в методе

как бы я делал в вашем случае - просто предложил эти тесты, а подходы/оценка на работы - on demand

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

Просто оставлю это здесь. Согласен по всем пунктам “задачей софтверного проекта категорически не является обучение программистов; каждый программист либо контрибьютит, либо учится это делать в свободное время; проект должен платить только за конечный результат нужно качества” http://www.yegor256.com/2015/02/16/it-is-not-a-school.html

Спасибо, ваше мнение очень важно для нас. (с)

Просто оставлю это здесь. Согласен по всем пунктам “задачей софтверного проекта категорически не является обучение программистов; каждый программист либо контрибьютит, либо учится это делать в свободное время; проект должен платить только за конечный результат нужно качества” http://www.yegor256.com/2015/02/16/it-is-not-a-school.html

Идеально для владельца бизнеса. А для программистов не очень

Это вообще ни для кого не работает.

Это может работать для команды распределенных аутсорсеров, которые контрибьютят а их продают по оверпрайсу.

Это вообще ни для кого не работает.

Спасибо, ваше мнение очень важно для нас. (с)

Очень просто считать, что легко уволить чувака и заменить его каким-нибудь другим. Проблемес в том, что часто бизнес в силу "недодумок" или вполне конкретных job-saving практик не избавляется от бас фактора. И хочет какой-нибудь Вася развиваться - и ты не дропнешь его только потому, что прочитал статью yegor256 , для бизнеса издержки развития специалиста дадут а) лоялти б) ресурс для решения комплексных проблем в будущем. Поэтому "учитесь в другом месте, а не у нас" - работает для малого процента рынка, для компаний, которые являются топом из топов , т.е. исключают для себя кадровое голодание за счет космического реноме

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

Да и вообще зачем давать отпуски рабочим. Их работа это и есть отпуск от бедности, правда? :)

В прочем, автор уже и сам всё сказал: > If your team is engaged in continuous development or maintenance of software, this concept may not be relevant. Да, если вам надо сделать херню уровня хакатона, сдать её заказчику и укатить на свежекупленной ламборджини в закат - то всё хорошо.

Проблема в том, что жизненный цикл ПО основан на поддержке и развитии. В долгосрочной перспективе.

Очень просто считать, что легко уволить чувака и заменить его каким-нибудь другим. Проблемес в том, что часто бизнес в силу "недодумок" или вполне конкретных job-saving практик не избавляется от бас фактора. И хочет какой-нибудь Вася развиваться - и ты не дропнешь его только потому, что прочитал статью yegor256 , для бизнеса издержки развития специалиста дадут а) лоялти б) ресурс для решения комплексных проблем в будущем. Поэтому "учитесь в другом месте, а не у нас" - работает для малого процента рынка, для компаний, которые являются топом из топов , т.е. исключают для себя кадровое голодание за счет космического реноме

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

ну тем более

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

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

Но вот как раз люди, которые "всему научились и готовы контрибьютить" им не нужны, AFAIK, потому что все понимают, что IT сейчас - это непрекращающееся обучение.

@azshoo мб уже что-то то знают и умеют работать головой, нэ?

ERROR: S client not available

@azshoo мб уже что-то то знают и умеют работать головой, нэ?

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

Но они всё равно учат сотрудников внутри компании. Они выделяют время на обучение. Они выделяют время на ресерчи по задачам и инструментам.

Когда искали у нас, не смогли найти на наш бюджет человека с нужным уровнем. Просто взяли самого адекватного.

все очень просто: есть бизнесы, которые работают над повторением существующего, например, Ламода - клон Zolando. Или русские Твичи (Лучи). Создавая что-то принциипиально новое, перед инженером будет ставиться рисерч задача. Тут нужно еще у Александра уточнить, в сервисном бизнесе он работает, или продуктовом. Есть маза, что в сервисном бизнесе рисерчей и обучения нет, потому что это не from 0 to 1. это 1 to N - повторение того, что уже работает

сам yegor256 работает в таком бизнесе, логично, что он так думает. типовые задачи, типовых клиентов, типового стэка

Сам бизнес хочет найти человека, который придёт и сделает все отлично, при этом уместится в выделенный бюджет

в а чем собственно суть полемики?

Александр Хот прочитал твиттер Backendsecret, там его на этой неделе ведет yegor256. Он открыл для себя статьи этого очень принципиального, но часто наивного человека и решил поделиться с нами этой новостью

Александр Хот прочитал твиттер Backendsecret, там его на этой неделе ведет yegor256. Он открыл для себя статьи этого очень принципиального, но часто наивного человека и решил поделиться с нами этой новостью

"Часто наивного" - но тем не менее у него куча реализованых проектов и огромный опыт и разработки и менеджмента

а_чего_добился_ты.jpg

именно поэтому ему нужно смотреть в рот? субъективные впечатления определённой человеческой особи != реальность

О, понеслись аргументы за 300.

Вы, не постесняюсь спросить, видели код сего господина? обладаете достаточной экспертностью для его оценки? или, может быть, имеете опыт работы в его проектах? Нет? тогда "а_чего_добился_ты.jpg" не по адресу)

именно поэтому ему нужно смотреть в рот? субъективные впечатления определённой человеческой особи != реальность

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

Вы, не постесняюсь спросить, видели код сего господина? обладаете достаточной экспертностью для его оценки? или, может быть, имеете опыт работы в его проектах? Нет? тогда "а_чего_добился_ты.jpg" не по адресу)

Вот откуда столько самоуверенности? Вы меня даже не знаете но уже сомневаетесь что я могу читать java код

вся суть русскоязычных комьюнити - "не выебывайся, и будь как все"

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

Хороший, чистый, производительный и вообще мякотка.

?

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

Иногда даже всё вместе.

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

Егор вообщето организовал несколько своих компаний, и вполне себе успешен как менеджер

Это как-то противоречит тому, что я сказал?

Это как-то противоречит тому, что я сказал?

нет, но намек что типа - да он кодер, че он там в менеджерстве шарит

Нет, это было прямое утверждение: качество кода никак не коррелирует со способностью давать советы по управлению компаниями.

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

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

Егор аутсорсит разработку, в которой вкладываться в разработчика нет смысла - зачем? они свободны, очень распределены, работают по 3-4 часа в день.

но думать, что это будет работать на 100% компаний - это наивно, это булшит