Модульных тестов и статической типизации недостаточно. Нужен опыт и знание языка!
Кроме того, мы говорим про «какие-то» модульные тесты, которые «что-то» не находят. Так может быть модульных тестов действительно недостаточно, и нужны интеграционные?
А может быть модульные тесты не находили ошибки потому, что их автору было реально лень писать «все комбинации»?
В таком случае, можно попробовать инструменты, которые бы автоматически сгенерировали тесты.
Для C#/VB/F# есть, например, Pex – отличный инструмент, который пытается зайти в каждый участок метода и генерирует тесты в итоге.
Ну, и пример, почему нужен опыт и знание языка.
Бывалые C#-перы, конечно же, быстро разгадают пример только с одного пронзительного взгляда. (Но, наверное, еще и потому, что на той строчке акцентируется большое внимание)
А вот для людей, которые знают язык не настолько хорошо – это может показаться загадкой.
Зайдите по ссылке и нажмите Ask Pex www.pexforfun.com/default.aspx?language=CSharp&sample=EnumSwitch
using System;
public enum Color { R, G, B }
public class Program
{
public static string Puzzle(Color color)
{
switch (color)
{
case Color.R: return "Red";
case Color.G: return "Green";
case Color.B: return "Blue";
default: throw new Exception("impossible"); // Is it really impossible to get here?
// Ask Pex to find out!
}
}
}
Вышел из ступора. Да, сейчас у меня версия 12.16 на Linux Mint 15. Так как и система свежая, и ядро обновленное, возможно это так повлияло на общею производительность, что я тормозов сейчас не ощущаю
Я бы был очень рад найти чет похожее на Smarty или Template Toolkit. По сути, они предоставляют свой упрощенный язык, которого бы вполне хватило. Но, пока в поисках.
Да, согласен, было бы круто добавить такой оптимизатор, чтобы на вход получал HTML страницы и XPath локатор, который бы внутри оптимизировался и на выходе производил более оптимизированный локатор.
Но, тут работы много. Это нужно делать отдельным модулем. Может за это время выйдут байндинги для IBM Watson, может его заюзаю.
Если серьезно, то постараюсь что-то такое прикрутить в следующей версии (0.2). По крайней мере были планы, и есть библиотеки, которые, возможно, могут помочь в этом деле
хотел бы заметить, что у меня дома не самая производительная машина. Ноут 2010-го года с двумя ядрами и 3-мя гигами RAM. В таких условиях производительность – имеет значение. И у Хрома она была больше.
Нестабильную работу Оперы 12 я наблюдал лишь тогда, когда включался глючный Flash-плагин. Это на виндах.
Еще пытался поставить 12-ю Оперу на Убунту на той же машине. Это было нечто ужасное по стабильности работы.
Сейчас поставил 15-ю под Linux Mint. Работает отлично, как на ноуте так и на нетбуке.
Надеюсь, что этот переход на новый движок будет поводом как улучшить старые фичи, так и избавится от ненужных. Так что поддерживаю такое развитие браузера
Я был реально фанатом Оперы, еще с 7-й версии. В то время, Опера была реально крутым браузером. Еще во время своей dial-up жизни, я полюбил, например такую фичу по умолчанию, как восстановление сессии браузера. Позвонил провайдеру – накликал кучу вкладок за 2 минуты – а потом целый день и завтра еще читаешь.
Я использовал почтовый клиент, потому что… ну удобно было просто с тем же dial-up соединением. Зашел вкладки по открывать, за одно нажал на кнопку синхронизации почты – и опять же в оффлайне потом все читаешь.
Но… потом Опера начала тормозить… не потому что она сама стала медленней, а потому что вышел Хром, к которому я быстро привык. В итоге – имея на рабочем столе ярлык оперы и Хрома – я выбирал последний.
После выхода Оперы 15 – я уже не помню когда в последний раз открывал Хром. Многих старых фич Оперы мне, конечно же, не хватает: закладки и синхронизация (в прочем, там ведь появился какой-то Stash), вынос ссылки на панель навигации браузера, отделение окна браузера и перенос его на другой монитор… но в целом, я доволен тем, что Опера 15 стала намного производительней.
В одной компании, где я работал проблема со слишком часто сломанным билдом была решена правилом: сломал билд – принеси тортик. Сначала торты ели каждый день, потом перестали.
SparkleShare задумывался как доступ к гиту «для дизайнеров», т.е. менее технических людей. Как я понял, git-annex – это оптимизация для больших файлов, но, к сожалению, не всем под силу работать с командной строкой.
вместо того, чтобы начать думать как решить проблему они часто начинают думать почему проблему решить нельзя.
Я вот иногда ищу некоторые экзотические решения для своих экзотических, но простых, проблем.
Часто попадаю на форумы MSDN. Там люди со значком MVP (признание от Microsoft), говорят что это не поддерживается, сделать невозможно и нереально.
Захожу на Стэковерфлоу – там говорят, что прямым путем сделать нельзя. Но, есть работающий хак…
Ну да, это всего лишь повод задать вопрос, например, какие технологии посмотрел в ближайшее время или дать возможность изучить новый инструмент за пол часа или прочитать и попросить рассказать про неизвестный до этого исходный код.
А вообще, за быстро обучаемостью стоит систематизация знаний и поиск сути и принципов, которые стоят за той или иной технологией или инструментом.
Вот, например, тестировщикам я даю задачу протестировать некоторое приложение – демо пример на AngularJS + Ruby, а задача состоит в том, чтобы ответить можно ли релизить приложение сегодня вечером. При этом есть приложение… а больше ничего нет и нет у кого спросить как оно должно работать. Т.е. спросить можно у меня, но я «не знаю» ответа на некоторые вопросы.
Один из вариантов – это найти много-много багов (там их действительно много). Но, этот вариант менее ценный, потому что потом я задаю вопрос: ну хорошо, вот вы нашли 100 багов, так мы можем релизить приложение? Почему нет? Почему да?
Второй вариант – это систематизированное исследование приложения. Во-первых, следует выяснить ЧТО должно делать приложение, т.е. какую задачу решать. Потом выяснить насколько хорошо оно решает проблему. Потом разделить ошибки по приоритетам. Например, есть такие ошибки, как возможность заказа минус десяти товаров или отсутствие валидации номера телефона, но эти ошибки кажутся несерьёзными по сравнению с тем, что приложение не работает в IE. А в справке описан пункт, который вообще не имплементирован.
Фраза «быстро обучаюсь» – почти ничего не значит. Что такое «быстро» – это две недели или два года? «Быстро обучился» создавать искусственные интеллекты, потратив всего 50 лет.
Это скорее возможность спросить человека, как он систематизирует знания.
Если я название своему ящику выбрал в 14 лет, и оно отражает склад ума 14-летнего подростка — мне теперь выбирать между привычным ящиком, и карьерой?
Ни в коем случае. Я против того чтобы выбирать между привычным ящиком, и карьерой. Просто карьеру вы будете делать в другом месте.
Вы бы ещё соискателей раздевали, и татуировки психоанализировали: если октокот — значит кандидат достойный, а если какие-нибудь пони — значит ну его нафиг.
Я считаю, что кандидат имеет право носить любую татуировку, если ее не видно под одеждой. Да, под одежду лезть на собеседовании … ну это как-то не этично.
Я очень много всего насмотрелся, когда проводил собеседование на старшего тестировщика-автоматизатора (C#, .NET), но и человек со знанием Java тоже подходил. Что я заметил:
>> Таблицы скилов
Очень хорошо, чтобы если хоть какая-то таблица есть. Чтобы в ней были хоть какие-то скилы и примерный опыт использования. Большенство пишут C/C++, C#, Pascal
Потом оказывается, что это был опыт еще в институте, а за последние 4 года человек даже для себя ничего не писал, даже на языке Windows Batch-файлов.
>> Перечень проектов
Очень интересная тенденция, что у тестировщиков и программистов описание технологий проекта – одинаковы. Т.е. тестировщик пишет: .NET, ASP.NET MVC, JavaScript, Entity Framework, а в итоге оказывается, что это он описал те технологии, которые использовали программисты, а он там рядом просто сидел.
>> Список личных качеств
А для меня этот раздел очень ценен, если можно некоторые качества проверить на месте.
Ну, например, энергичность и уверенность в себе сложно проверить на собеседовании, а вот про умение планировать свое время и быструю обучаемость можно несколько отличных вопросов позадавать
>> И еще, никогда не отправляйте резюме с адреса mail.ru. Это плохой знак.
Это не так. Домен Gmail ничем не лучше и не хуже мейлру. Точно такая-же бесплатная система. И нет ничего страшного если у кандидата, например, нет своего почтового домена.
Самое интересное – это название ящика:
farcry@gimail.com
andrushka1983@gimail.com
alyonusha_k@gimail.com
Авот это:
Vasilii_Pipishko@mail.ru – вполне нормально
Кроме того, мы говорим про «какие-то» модульные тесты, которые «что-то» не находят. Так может быть модульных тестов действительно недостаточно, и нужны интеграционные?
А может быть модульные тесты не находили ошибки потому, что их автору было реально лень писать «все комбинации»?
В таком случае, можно попробовать инструменты, которые бы автоматически сгенерировали тесты.
Для C#/VB/F# есть, например, Pex – отличный инструмент, который пытается зайти в каждый участок метода и генерирует тесты в итоге.
Ну, и пример, почему нужен опыт и знание языка.
Бывалые C#-перы, конечно же, быстро разгадают пример только с одного пронзительного взгляда. (Но, наверное, еще и потому, что на той строчке акцентируется большое внимание)
А вот для людей, которые знают язык не настолько хорошо – это может показаться загадкой.
Зайдите по ссылке и нажмите Ask Pex
www.pexforfun.com/default.aspx?language=CSharp&sample=EnumSwitch
Smarty или Template Toolkit. По сути, они предоставляют свой упрощенный язык, которого бы вполне хватило. Но, пока в поисках.
Но, тут работы много. Это нужно делать отдельным модулем. Может за это время выйдут байндинги для IBM Watson, может его заюзаю.
Если серьезно, то постараюсь что-то такое прикрутить в следующей версии (0.2). По крайней мере были планы, и есть библиотеки, которые, возможно, могут помочь в этом деле
Вот отсюда брал, но там вроде бы 12-я…
community.linuxmint.com/software/view/opera
Нестабильную работу Оперы 12 я наблюдал лишь тогда, когда включался глючный Flash-плагин. Это на виндах.
Еще пытался поставить 12-ю Оперу на Убунту на той же машине. Это было нечто ужасное по стабильности работы.
Сейчас поставил 15-ю под Linux Mint. Работает отлично, как на ноуте так и на нетбуке.
Надеюсь, что этот переход на новый движок будет поводом как улучшить старые фичи, так и избавится от ненужных. Так что поддерживаю такое развитие браузера
Я использовал почтовый клиент, потому что… ну удобно было просто с тем же dial-up соединением. Зашел вкладки по открывать, за одно нажал на кнопку синхронизации почты – и опять же в оффлайне потом все читаешь.
Но… потом Опера начала тормозить… не потому что она сама стала медленней, а потому что вышел Хром, к которому я быстро привык. В итоге – имея на рабочем столе ярлык оперы и Хрома – я выбирал последний.
После выхода Оперы 15 – я уже не помню когда в последний раз открывал Хром. Многих старых фич Оперы мне, конечно же, не хватает: закладки и синхронизация (в прочем, там ведь появился какой-то Stash), вынос ссылки на панель навигации браузера, отделение окна браузера и перенос его на другой монитор… но в целом, я доволен тем, что Опера 15 стала намного производительней.
Как-то так…
Что для этого нужно от тестировщика/разработчика для реализации подхода?
Я вот иногда ищу некоторые экзотические решения для своих экзотических, но простых, проблем.
Часто попадаю на форумы MSDN. Там люди со значком MVP (признание от Microsoft), говорят что это не поддерживается, сделать невозможно и нереально.
Захожу на Стэковерфлоу – там говорят, что прямым путем сделать нельзя. Но, есть работающий хак…
Так что не только у наших разработчиков такое
А детей заберешь (му-га-га-га)
А вообще, за быстро обучаемостью стоит систематизация знаний и поиск сути и принципов, которые стоят за той или иной технологией или инструментом.
Вот, например, тестировщикам я даю задачу протестировать некоторое приложение – демо пример на AngularJS + Ruby, а задача состоит в том, чтобы ответить можно ли релизить приложение сегодня вечером. При этом есть приложение… а больше ничего нет и нет у кого спросить как оно должно работать. Т.е. спросить можно у меня, но я «не знаю» ответа на некоторые вопросы.
Один из вариантов – это найти много-много багов (там их действительно много). Но, этот вариант менее ценный, потому что потом я задаю вопрос: ну хорошо, вот вы нашли 100 багов, так мы можем релизить приложение? Почему нет? Почему да?
Второй вариант – это систематизированное исследование приложения. Во-первых, следует выяснить ЧТО должно делать приложение, т.е. какую задачу решать. Потом выяснить насколько хорошо оно решает проблему. Потом разделить ошибки по приоритетам. Например, есть такие ошибки, как возможность заказа минус десяти товаров или отсутствие валидации номера телефона, но эти ошибки кажутся несерьёзными по сравнению с тем, что приложение не работает в IE. А в справке описан пункт, который вообще не имплементирован.
Фраза «быстро обучаюсь» – почти ничего не значит. Что такое «быстро» – это две недели или два года? «Быстро обучился» создавать искусственные интеллекты, потратив всего 50 лет.
Это скорее возможность спросить человека, как он систематизирует знания.
Программистам на языке Ада вполне простительно иметь в номере и 666.
Ни в коем случае. Я против того чтобы выбирать между привычным ящиком, и карьерой. Просто карьеру вы будете делать в другом месте.
Я считаю, что кандидат имеет право носить любую татуировку, если ее не видно под одеждой. Да, под одежду лезть на собеседовании … ну это как-то не этично.
>> Таблицы скилов
Очень хорошо, чтобы если хоть какая-то таблица есть. Чтобы в ней были хоть какие-то скилы и примерный опыт использования. Большенство пишут C/C++, C#, Pascal
Потом оказывается, что это был опыт еще в институте, а за последние 4 года человек даже для себя ничего не писал, даже на языке Windows Batch-файлов.
>> Перечень проектов
Очень интересная тенденция, что у тестировщиков и программистов описание технологий проекта – одинаковы. Т.е. тестировщик пишет: .NET, ASP.NET MVC, JavaScript, Entity Framework, а в итоге оказывается, что это он описал те технологии, которые использовали программисты, а он там рядом просто сидел.
>> Список личных качеств
А для меня этот раздел очень ценен, если можно некоторые качества проверить на месте.
Ну, например, энергичность и уверенность в себе сложно проверить на собеседовании, а вот про умение планировать свое время и быструю обучаемость можно несколько отличных вопросов позадавать
>> И еще, никогда не отправляйте резюме с адреса mail.ru. Это плохой знак.
Это не так. Домен Gmail ничем не лучше и не хуже мейлру. Точно такая-же бесплатная система. И нет ничего страшного если у кандидата, например, нет своего почтового домена.
Самое интересное – это название ящика:
farcry@gimail.com
andrushka1983@gimail.com
alyonusha_k@gimail.com
Авот это:
Vasilii_Pipishko@mail.ru – вполне нормально
Спасибо