Меня он тоже интересует! :)
Но я не большой спец по таким тестам. Если подскажете, относительно простой вараинт теста. Желательно, заскриптованный, то сделаю.
КВМ, кстати, есть. Доступен прямо из панели управления. Пока Вы не спросили, я на него даже внимания не обратил. :)
Реальную скорость канала не мерил. Заявлено у них 200 мегабит. Успел только посмотреть пинги до пары нужных мне мест. Например, от ДЦ AWS в Дублине до них менее 20мс.
Да именно так! Вы очень хорошо сформулировали. :))
В связи с этим, думаю, следует разделить тестирования создания объектов, так как это может быть специфично для каждого класса и, собственно, тестирование методов интерфейса, которое, на самом деле, должно быть единым для всех классов, реализующих этот интерфейс.
> Старайся использовать «широкие» строки как для строковых констант
Сомнительное утверждение. Особенно, если предполагается, что
> придется локализовывать ее в другие страны, механизмы интернационализации
Я бы предпочел все строковые константы сразу выносить во внешние файлы. Ресурсы, наборы строк или что там предполагается для использования в этих механизмах интернационализации.
Соглашусь с автором. Из моего личного опыта (2 года работал в компании, разработывающей промышленную автоматику и телемеханику), в промышленности львиная доля программ пишется на LD (графический). На втором месте FBD (графический) и ST (текстовый).
Хотя лично для меня язык LD это что-то чудовищное, я его толком так и не осилил :)) Поэтому жаль, что здесь поддерживаются не все языки стандарта IEC 61131-3
Вот именно, что надо самому испытывать. Или искать, что кто-то испытал. А тут сразу вопросы пояыляются. А точно ли испытали устройство из той же партии, что Ваша? А точно ли соблюдена методика испытания?
Примерно то же самое с корпусом.
Здесь же производитель гарантирует и промышленный температурный режим и IP65.
Вообщем, я согласен с Вашим комментарием ниже. Ace — это законченное устройство, которое можно взять и использовать. Ардуино это конструктор для гиков.
Пока я не заню чего я хочу, я возьму, скорее всего, Ардуино. Когда я точно знаю что я хочу получить и в каких условиях я буду эксплуатировать, я буду смотреть на готовые устройства типа Ace.
Я знаю, что во многих российских компаниях роль тестировщиков сильно недооценена. А на самом деле, они такие же участники разработки продукта, что и программисты. Нормальные QA также пишут код. Им часто приходится решать нетривиальные задачи. Имхо разница только в том, что они находятся по другую сторону от работающего кода.
Сложившаяся недооценка работы QA приводит к тому, что люди, умеющие программировать и решать нетривиальные задачи, не хотят идти на эту работу. Это приводит, например, к таким печальным последствиям: когда заходит речь, про автоматизацию тестирования, выясняется, что одни (разработчики) не хотят этим заниматься, другие (QA) не умеют, так и остаются проекты без автоматического тестирования.
Автору: а за статью спасибо! У меня самого были примерно такие же расчеты. Но они обычно оставались на салфетках/досках, которые терялись или стирались.
То, что Вам нужно будет построено либо на LaTeX либо на XML.
Из XML стандартов есть два, подходящих для технической документации (как для софта так и для железа): DocBook и DITA. Лично мне больше импонирует DITA, но DocBook имхо проще на старте.
XML (опять же, имхо) проще для технических писателей. Особенно, если пользоваться хорошими CSS-based XML редакторами. К списку таких редакторов, которые приводит автор я бы еще добавил Arbortext. Но мой выбор здесь — oXygen XML Author, так же как и у автора статьи. Минус один — они все очень недешевы.
В планах есть. Но пока отдаленных. Так как, если писать с какими-то реальными примерами, а не высосанными из пальца, надо какой-то не совсем тривиальный, но, тем не менее, свободный от кода заказчика проект.
Присоединяюсь насчет конечного автомата.
Прямо сейчас реализую небольшой проект (15-20 тысяч строк кода) который строю сразу на КА. Логика каждой истории описывается при помощи КА. И это не только пользовательские истории. Это, например, истории взаимодействия клиента с серверами (серверов больше одного).
И есть КА верхнего уровня для «межавтоматного» взаимодействия. Причем эти КА работают параллельно. То есть, попадания в некоторые состояния автомата нижнего уровня являются событиями (символами) для КА верхнего уровня, которые могут приводить к возникновению событий для другого КА нижнего уровня.
> 9 дней работы браузера без выключения, да еще и заплатить придется за каждую операцию (DELETE хоть и бесплатный, но LIST стоит денег).
Зачем браузер держать открытым? зачем LIST делать часто?
Но я не большой спец по таким тестам. Если подскажете, относительно простой вараинт теста. Желательно, заскриптованный, то сделаю.
КВМ, кстати, есть. Доступен прямо из панели управления. Пока Вы не спросили, я на него даже внимания не обратил. :)
Реальную скорость канала не мерил. Заявлено у них 200 мегабит. Успел только посмотреть пинги до пары нужных мне мест. Например, от ДЦ AWS в Дублине до них менее 20мс.
www.prokaizen.ru/2010/07/toyota-toyota_10.html
Это что имеется в виду? Или это какая-то опечатка?
Было бы интересно посмотреть на эту кривую. Не могли бы Вы описать план курса по основам программирования на go?
В связи с этим, думаю, следует разделить тестирования создания объектов, так как это может быть специфично для каждого класса и, собственно, тестирование методов интерфейса, которое, на самом деле, должно быть единым для всех классов, реализующих этот интерфейс.
Сомнительное утверждение. Особенно, если предполагается, что
> придется локализовывать ее в другие страны, механизмы интернационализации
Я бы предпочел все строковые константы сразу выносить во внешние файлы. Ресурсы, наборы строк или что там предполагается для использования в этих механизмах интернационализации.
Хотя лично для меня язык LD это что-то чудовищное, я его толком так и не осилил :)) Поэтому жаль, что здесь поддерживаются не все языки стандарта IEC 61131-3
Примерно то же самое с корпусом.
Здесь же производитель гарантирует и промышленный температурный режим и IP65.
Вообщем, я согласен с Вашим комментарием ниже. Ace — это законченное устройство, которое можно взять и использовать. Ардуино это конструктор для гиков.
Пока я не заню чего я хочу, я возьму, скорее всего, Ардуино. Когда я точно знаю что я хочу получить и в каких условиях я буду эксплуатировать, я буду смотреть на готовые устройства типа Ace.
> -40… 85°С
> IP65
это однозначные плюсы по сравнению с Ардуино.
www.indeed.com/salary/Quality-Assurance-Engineer.html $84,000/year
www.indeed.com/salary?q1=Software+Engineer&l1= $94,000/year
Я знаю, что во многих российских компаниях роль тестировщиков сильно недооценена. А на самом деле, они такие же участники разработки продукта, что и программисты. Нормальные QA также пишут код. Им часто приходится решать нетривиальные задачи. Имхо разница только в том, что они находятся по другую сторону от работающего кода.
Сложившаяся недооценка работы QA приводит к тому, что люди, умеющие программировать и решать нетривиальные задачи, не хотят идти на эту работу. Это приводит, например, к таким печальным последствиям: когда заходит речь, про автоматизацию тестирования, выясняется, что одни (разработчики) не хотят этим заниматься, другие (QA) не умеют, так и остаются проекты без автоматического тестирования.
Автору: а за статью спасибо! У меня самого были примерно такие же расчеты. Но они обычно оставались на салфетках/досках, которые терялись или стирались.
не цените вы тестировщиков…
Из XML стандартов есть два, подходящих для технической документации (как для софта так и для железа): DocBook и DITA. Лично мне больше импонирует DITA, но DocBook имхо проще на старте.
XML (опять же, имхо) проще для технических писателей. Особенно, если пользоваться хорошими CSS-based XML редакторами. К списку таких редакторов, которые приводит автор я бы еще добавил Arbortext. Но мой выбор здесь — oXygen XML Author, так же как и у автора статьи. Минус один — они все очень недешевы.
Кстати, рекомендую посмотреть:
habrahabr.ru/post/212881/
habrahabr.ru/company/mirantis_openstack/blog/190624/
А помимо хранения в репозитарии еще потребуется CI: сборка, публикации и тестирование. Разработка документации это вам не просто так :)
Прямо сейчас реализую небольшой проект (15-20 тысяч строк кода) который строю сразу на КА. Логика каждой истории описывается при помощи КА. И это не только пользовательские истории. Это, например, истории взаимодействия клиента с серверами (серверов больше одного).
И есть КА верхнего уровня для «межавтоматного» взаимодействия. Причем эти КА работают параллельно. То есть, попадания в некоторые состояния автомата нижнего уровня являются событиями (символами) для КА верхнего уровня, которые могут приводить к возникновению событий для другого КА нижнего уровня.
> 9 дней работы браузера без выключения, да еще и заплатить придется за каждую операцию (DELETE хоть и бесплатный, но LIST стоит денег).
Зачем браузер держать открытым? зачем LIST делать часто?
docs.aws.amazon.com/cli/latest/reference/s3/rm.html
А это не быстрее будет?