А какой инструмент для этого самый простой? Я никогда ничего из автоматизации тестирования интерфейсов не использовал. Что бы мне такое взять чтобы просто и быстро?
Собственно в этом и была суть вопроса :)
Лилия, подскажите, можно ли написать автоматические тесты для веб-интерфейса при условии что загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд.
Если да, то какой инструмент для этого наиболее прост?
Про способы логирования могу добавить своё мнение, что очень полезно писать в системный журнал название файла и строчку кода, где был вызов логера. Делается это примерно так:
_, file, line, _ := runtime.Caller(1)
Параметр в функции означает глубину вызова по стеку.
А как строите развёртывание и масштабируете разработку без контейнеров? Какие потребности и какие решения?
От вопроса веет какой-то безысходностью :)
Контейнеры — лишь один из способов виртуализации со своими плюсами и минусами. Ну да, я тоже использую виртуализацию, но, как правило, не контейнерную.
Но суть не в этом. Скомпилированный Go-бинарник — это и есть контейнер со всеми необходимыми зависимостями, вполне себе самодостаточный. В этом ключе смысла засовывать его в ещё один контейнер я не вижу.
Как масштабировать? Да точно так же — либо вы увеличиваете мощности виртуальной машины или железного сервера и масштабируетесь вертикально, либо запускаете несколько экземпляров в разных машинах или серверах и масштабируетесь горизонтально. Тут ничего нового.
Вы ещё запускаете СУБД в контейнере — это, видимо, единственная причина использования контейнера как среды (реальная). Тут дело, конечно, хозяйское, но я против баз данных в контейнерах. Контейнеры — они больше про удалил/развернул/добавил.
Развёртывание у меня при помощи TeamCity. Всё просто: скачали репо, скомпилировали, подменили бинарник, перезапустили. Вы, полагаю, примерно то же самое делаете с контейнером. У меня на одну сущность меньше.
От именования пакетов способность кода «кричать» о своём назначении не страдает
Вот тут позволю себе не согласиться. Тем более что про именование (пакетов, переменных и пр.) написано очень многое и членами команды разработки Go и известными в сообществе людьми. И их рекомендации не ложатся на вашу схему, что, впрочем не отменяет возможности того, что вы правы в вашем конкретном случае.
А Дядя Боб вообще писал хоть и абстрактно, но из его примеров явно торчали уши Java и RoR. Так что его рекомендации нужно применительно к Go здорово фильтровать, в отличие от рекомендаций того же Роба Пайка. Это моё мнение.
Про контейнеры ответ прочитал. Есть мнение, что несмотря на описанные здравые аргументы, у вас тоже присутствует элемент моды и ажиотажа на них. Я как, человек много и плотно поработавший с различной виртуализацией самой разной инфраструктуры, откровенно рад что для проектов на Go можно без всего этого обойтись.
Сергей, у меня к вам пара вопросов:
1. Для чего вы запускаете программы, разработанные на Go, в контейнерах?
2. Разве о таком именовании пакетов (классов, модулей) говорил Роберт Мартин? Я имею в виду «Домен», «Приложение», «Транспорт». У него, насколько я помню, каждый класс или пакет должен своим названием говорить что именно он делает. Типа «Логирование», «Ошибки», «Отчётность».
Мне со стороны кажется, что да, примерно так оно и есть.
Вам, как я понимаю, так не кажется. Можете указать основные различия, которые на ваш взгляд именно делают разницу?
ОК, я вас понял. В вашей деятельности, судя по всему, возможно посчитать текущие и примерные будущие потребности, сравнить предложения на рынке и выбрать оптимальный вариант. При этом обосновав выбор с экономической точки зрения и увязав его с ИТ-стратегией, которая основана на бизнес-стратегии.
Мне же не так повезло. Мне приходилось прикидывать «на глаз» что есть сейчас и что будет. Выбирать из одного вендора (потому что другие не подходят). Экономические обоснования всегда должны быть в рамках бюджета. Да и вообще — заказчик как правило был из госсектора (хотя и не всегда), где понятие стоимости простоя в рублях вызовет тяжёлое недоумение (представьте, к примеру, Ген. прокуратуру). Ну и ТЗ и прочее писалось со стороны — пообщаться с бизнес-пользователями, поинтересоваться планами развития ИТ и будущими потребностями было просто не у кого или нельзя.
Вот мне почему-то кажется, что мой случай несколько чаще встречается на практике чем ваш. А может и нет, может просто так сложилось.
Вот эти-то сложновысчитываемые характеристики меня и смущают (RPO, RTO и пр.)
Давайте рассмотрим конкретный пример. Когда-то я участвовал в модернизации (читай создании) ЦОД для одной из крупнейших и авторитетнейших госструктур. Вы, конечно, знаете, но для тех кто не в курсе, скажу, что именно государство в России является основным покупателем СХД. Некоторые крупнейшие вендоры первые годы жили только! за счёт госзаказов от какого-нибудь РЖД. Тоже факт из первых рук, если что.
Так вот, большая госструктура. Каков у неё стоимость простоя в час? Да кто же знает? Это же не коммерческая компания. Но не это главное, суть в следующем.
Поставили мы им СХД за сумму порядка миллиона долларов, подключили к корзинкам с серверами по 10GB FCoE (или iSCSI — не помню). На серверах VMware vSphere. Всё работает, всё хорошо.
Проходит время и диски начинают сыпаться, они же там обычные, что бы и кто не говорил про «доработку прошивок», «дополнительное тестирование» и пр. И в какой-то момент вендор говорит: «Ребята, вы под санкциями, менять диски не можем!». А купить при наличии гарантии не так просто.
Так чего же делала эта СХД за бешеные деньги — то же что и 99% СХД — обслуживала кластер виртуализации. Всё, что её отличало от самосбора в этом смысле — два независимых контроллера. Хотя и самосбор может иметь сколько угодно путей просто добавив сетевые интерфейсы.
Так что я не к тому, что СХД надо срочно заменить на SuperMicro + CentOS + tgtd. Я про то, что представление о корпоративном ИТ всё же меняется и зачастую такая замена уже уместна. Также как и использование публичных облаков, что в первые годы их продвижения казалось скорее экзотикой.
Я в последнее время не занимаюсь корпоративной информационной инфраструктурой и СХД в частности, но вот складывается ощущение, что вся эта сакральность СХД как невероятно отказоустойчивой, сложной и высокоэффективной штуковины осталась в прошлом.
Большинству контор, даже крупных, нахрен не сдался весь этот набор возможностей СХД EMC на пять листов (также как и большинству гос. покупателей коммутаторов и маршрутизаторов Cisco не нужно 98% их возможностей). При этом весь этот маркетинг о покупке крутого устройства, которое решит проблемы на десять лет вперёд (т.е. проблемы, которых ещё нет) уже тоже приелся.
На мой взгляд, программные решения уже вполне зрелые и надёжные, и перейти от простого iSCSI СХД на встроенном функционале Windows или Linux на одном сервере к Windows Storage Spaces на куче серверов и JBOD или чему-то ещё более сложному вообще не проблема. И такой переход будет решать реальные проблемы. Ну и дешевле будет, само собой.
Что авторы статьи думают на этот счёт?
Количественная оценка средних временных затрат на написание юнит-тестов (около 30%) также как и оценка положительного эффекта, который они дают в дальнейшем (в виде снижения затрат на последующую модернизацию и развитие проекта) была у Роберта Мартина в Clean Architecture. Не уверен, но вроде бы он там ссылался на исследования.
На мой взгляд, это главная задача юнит-тестов — поиск регрессии. И этот эффект проявляется в будущем, а, значит, также должен быть учтён, дисконтирован и приведён к настоящему моменту. По аналогии с NPV.
У Вас в начале статьи ссылка на сайт Slack. Это, как я понимаю, типа социальной сети что-то. Я там зарегистрировался, но всё равно пройти по ссылкам не могу. Это какой-то закрытый сайт? Зачем тогда ссылки в статье?
Декоратор полностью повторяет интерфейс декорируемого объекта.
Я не очень понял, что есть интерфейс в таком вот контексте, поясните, пожалуйста.
Да и весь пример с интерфейсом MyDatabase не понятен, честно сказать, в отличие от декоратора HTTP-обработчика. Как именно происходит логирование в этом случае?
Не мог бы преподаватель «курса Golang» пояснить мне и некоторым другим прочитавшим статью как сделать UI на Go. Может я чего пропустил, или это просто опечатка?
Вообще как для Mail статья слабовата, для меня была бы ОК, но не для Mail.
Именно так: просто взять и бросить. Сигареты, алкоголь, еду по вечерам — не важно что. Секрет в том, что к этому моменту должно быть не просто желание, а, если хотите, цель в жизни — отказаться. Такое стремление не появляется на пустом месте, и время попыток бросить, следуя разным книжкам и советам, у такого человека уже позади.
Поэтому только так — отказаться от привычки и глупой мысли, что без этого будет невыносимо тяжело.
С перееданием всё сложнее — тут генетика против нас. Изначальной тяги к сигарете или алкоголю в нас нет, а к перееданию у толстяков тяга врождённая.
Тут только психологическая компенсация от результатов похудания может помочь. Однако опять же пишу всё это не просто так.
Именно так, сначала чёткое желание избавиться от {подставить нужное}. Многие не хотят бросать вредных привычек. А те, кто хотят даже от героина отказываются сравнительно легко (тут уже не по себе сужу, но в своё время, в наркотический бум 90-х, было немало примеров в обе стороны).
Собственно в этом и была суть вопроса :)
Если да, то какой инструмент для этого наиболее прост?
Параметр в функции означает глубину вызова по стеку.
От вопроса веет какой-то безысходностью :)
Контейнеры — лишь один из способов виртуализации со своими плюсами и минусами. Ну да, я тоже использую виртуализацию, но, как правило, не контейнерную.
Но суть не в этом. Скомпилированный Go-бинарник — это и есть контейнер со всеми необходимыми зависимостями, вполне себе самодостаточный. В этом ключе смысла засовывать его в ещё один контейнер я не вижу.
Как масштабировать? Да точно так же — либо вы увеличиваете мощности виртуальной машины или железного сервера и масштабируетесь вертикально, либо запускаете несколько экземпляров в разных машинах или серверах и масштабируетесь горизонтально. Тут ничего нового.
Вы ещё запускаете СУБД в контейнере — это, видимо, единственная причина использования контейнера как среды (реальная). Тут дело, конечно, хозяйское, но я против баз данных в контейнерах. Контейнеры — они больше про удалил/развернул/добавил.
Развёртывание у меня при помощи TeamCity. Всё просто: скачали репо, скомпилировали, подменили бинарник, перезапустили. Вы, полагаю, примерно то же самое делаете с контейнером. У меня на одну сущность меньше.
Вот тут позволю себе не согласиться. Тем более что про именование (пакетов, переменных и пр.) написано очень многое и членами команды разработки Go и известными в сообществе людьми. И их рекомендации не ложатся на вашу схему, что, впрочем не отменяет возможности того, что вы правы в вашем конкретном случае.
А Дядя Боб вообще писал хоть и абстрактно, но из его примеров явно торчали уши Java и RoR. Так что его рекомендации нужно применительно к Go здорово фильтровать, в отличие от рекомендаций того же Роба Пайка. Это моё мнение.
Про контейнеры ответ прочитал. Есть мнение, что несмотря на описанные здравые аргументы, у вас тоже присутствует элемент моды и ажиотажа на них. Я как, человек много и плотно поработавший с различной виртуализацией самой разной инфраструктуры, откровенно рад что для проектов на Go можно без всего этого обойтись.
1. Для чего вы запускаете программы, разработанные на Go, в контейнерах?
2. Разве о таком именовании пакетов (классов, модулей) говорил Роберт Мартин? Я имею в виду «Домен», «Приложение», «Транспорт». У него, насколько я помню, каждый класс или пакет должен своим названием говорить что именно он делает. Типа «Логирование», «Ошибки», «Отчётность».
Вам, как я понимаю, так не кажется. Можете указать основные различия, которые на ваш взгляд именно делают разницу?
Мне же не так повезло. Мне приходилось прикидывать «на глаз» что есть сейчас и что будет. Выбирать из одного вендора (потому что другие не подходят). Экономические обоснования всегда должны быть в рамках бюджета. Да и вообще — заказчик как правило был из госсектора (хотя и не всегда), где понятие стоимости простоя в рублях вызовет тяжёлое недоумение (представьте, к примеру, Ген. прокуратуру). Ну и ТЗ и прочее писалось со стороны — пообщаться с бизнес-пользователями, поинтересоваться планами развития ИТ и будущими потребностями было просто не у кого или нельзя.
Вот мне почему-то кажется, что мой случай несколько чаще встречается на практике чем ваш. А может и нет, может просто так сложилось.
Давайте рассмотрим конкретный пример. Когда-то я участвовал в модернизации (читай создании) ЦОД для одной из крупнейших и авторитетнейших госструктур. Вы, конечно, знаете, но для тех кто не в курсе, скажу, что именно государство в России является основным покупателем СХД. Некоторые крупнейшие вендоры первые годы жили только! за счёт госзаказов от какого-нибудь РЖД. Тоже факт из первых рук, если что.
Так вот, большая госструктура. Каков у неё стоимость простоя в час? Да кто же знает? Это же не коммерческая компания. Но не это главное, суть в следующем.
Поставили мы им СХД за сумму порядка миллиона долларов, подключили к корзинкам с серверами по 10GB FCoE (или iSCSI — не помню). На серверах VMware vSphere. Всё работает, всё хорошо.
Проходит время и диски начинают сыпаться, они же там обычные, что бы и кто не говорил про «доработку прошивок», «дополнительное тестирование» и пр. И в какой-то момент вендор говорит: «Ребята, вы под санкциями, менять диски не можем!». А купить при наличии гарантии не так просто.
Так чего же делала эта СХД за бешеные деньги — то же что и 99% СХД — обслуживала кластер виртуализации. Всё, что её отличало от самосбора в этом смысле — два независимых контроллера. Хотя и самосбор может иметь сколько угодно путей просто добавив сетевые интерфейсы.
Так что я не к тому, что СХД надо срочно заменить на SuperMicro + CentOS + tgtd. Я про то, что представление о корпоративном ИТ всё же меняется и зачастую такая замена уже уместна. Также как и использование публичных облаков, что в первые годы их продвижения казалось скорее экзотикой.
Большинству контор, даже крупных, нахрен не сдался весь этот набор возможностей СХД EMC на пять листов (также как и большинству гос. покупателей коммутаторов и маршрутизаторов Cisco не нужно 98% их возможностей). При этом весь этот маркетинг о покупке крутого устройства, которое решит проблемы на десять лет вперёд (т.е. проблемы, которых ещё нет) уже тоже приелся.
На мой взгляд, программные решения уже вполне зрелые и надёжные, и перейти от простого iSCSI СХД на встроенном функционале Windows или Linux на одном сервере к Windows Storage Spaces на куче серверов и JBOD или чему-то ещё более сложному вообще не проблема. И такой переход будет решать реальные проблемы. Ну и дешевле будет, само собой.
Что авторы статьи думают на этот счёт?
На мой взгляд, это главная задача юнит-тестов — поиск регрессии. И этот эффект проявляется в будущем, а, значит, также должен быть учтён, дисконтирован и приведён к настоящему моменту. По аналогии с NPV.
Да и весь пример с интерфейсом MyDatabase не понятен, честно сказать, в отличие от декоратора HTTP-обработчика. Как именно происходит логирование в этом случае?
Вообще как для Mail статья слабовата, для меня была бы ОК, но не для Mail.
Поэтому только так — отказаться от привычки и глупой мысли, что без этого будет невыносимо тяжело.
Тут только психологическая компенсация от результатов похудания может помочь. Однако опять же пишу всё это не просто так.