четверг, 30 октября 2008 г.
В Казахстане и Кыргызстане заблокирован доступ к LiveJournal
В Казахстане и Кыргызстане заблокирован доступ к LiveJournal вот причина того, что не постился в блоге. Подробнее можно почитать на mignews.com . Ситуация честно говоря просто обескураживающая. Я как житель Кыргызстана отрезан от блога, потому что некто в Казахстане закрыл доступ. Где собственно логика??? Просто почти все кыргызстанские интернет провайдеры выходят в глобальную сеть через оптику лежащую именно в Казахстане. Интернет доступ работающий у нас в стране это просто отдельный разговор, впрочем я уже скидывал ссылку об этом. Сейчас пишу в блог через http://mylj.ru. Очень хороший ресурс все таки :) Рекомендую всем кто лишился своего ЖЖ по вине злобных админов, ну или по каким то политическим соображениям :). Думаю скоро поделюсь своими новостями, их уже много и есть чем поделиться...
среда, 10 сентября 2008 г.
С днем тестировщика
9-сентября не официальный праздник в принципе, но от этого не менее знаминательный День тестировщика или День QA. Поздравляю коллеги с праздником хоть и с опозданием в 1 день:). Почему 9-сентября можно узнать здесь . Первому найденному багу 63 года:) P.S. Че то я совсем забыл про блог, впредь буду отчаянно пытаться писать хотя бы 1 раз в неделю
понедельник, 26 мая 2008 г.
Ну наконец то в Wiki
Начну наверно из далека. Такое направление как software testing или qa хоть и появилось относительно давно, но все community такого рода специалистов не консолидированы.
Что я имею в виду? Есть конечно какие то базовые понятия для любого QA но вот их взгляды на одни и те же понятия расходятся колоссально. Для примера открываем самые большие форумы и наблюдаем в обсуждениях просто кошмар. К примеру из 30 последних тем, около 25 будет с вопросом типа: А что такое тесткейс?, Что такое сценарий тестирования?. Причем это наблюдается как на англоязычных, так и на российских форумах.
Эта проблема известна многим и было много попыток сделать единую базу знаний для всех QA, примером такого может быть http://www.softwareqatest.com/ . Да я признаю что база знаний у нее неплохая, но вот 1 незадача, туда мало кто заходит просвещаться. А теперь главная фишка: Ни для кого не секрет, что большинство IT-товарищей первым делом пытаются просветиться либо в Гугле, либо в Википедии . Ну и вот наконец то к конкретно самой новости: в Wikipedia открылся отдельный портал для QA по адресу http://en.wikipedia.org/wiki/Portal:Software_Testing . Для себя открыл несколько интересных понятий, да и мне кажется, что любой QA найдет там массу интересного и база знаний будет дополняться.
P.S. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.
Что я имею в виду? Есть конечно какие то базовые понятия для любого QA но вот их взгляды на одни и те же понятия расходятся колоссально. Для примера открываем самые большие форумы и наблюдаем в обсуждениях просто кошмар. К примеру из 30 последних тем, около 25 будет с вопросом типа: А что такое тесткейс?, Что такое сценарий тестирования?. Причем это наблюдается как на англоязычных, так и на российских форумах.
Эта проблема известна многим и было много попыток сделать единую базу знаний для всех QA, примером такого может быть http://www.softwareqatest.com/ . Да я признаю что база знаний у нее неплохая, но вот 1 незадача, туда мало кто заходит просвещаться. А теперь главная фишка: Ни для кого не секрет, что большинство IT-товарищей первым делом пытаются просветиться либо в Гугле, либо в Википедии . Ну и вот наконец то к конкретно самой новости: в Wikipedia открылся отдельный портал для QA по адресу http://en.wikipedia.org/wiki/Portal:Software_Testing . Для себя открыл несколько интересных понятий, да и мне кажется, что любой QA найдет там массу интересного и база знаний будет дополняться.
P.S. Больше всего радует то, что можно будет пнуть долбанных индусов в Вики на форумах и не париться.
вторник, 13 мая 2008 г.
Меня одного вот это бесит?
Я конечно понимаю, что самому ЖЖ выгодно чтобы я писал каждый день и можно было продать каждый показ баннера(которых итак много ИМХО!) при просмотре, но всему есть предел. Тут еще и подгонять юзера это уже ни в какие ворота не лезет.
четверг, 8 мая 2008 г.
Стыдно но все же
Недавно улучшили процесс деплоя как на сторону заказчика, так и себе. Честно говоря очень обидно, что не доперли до этого сразу но все же. Принцип следующий:
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.
пятница, 11 апреля 2008 г.
О Continuous Integration (ci)
Вытаил время для очередного топика. На этот раз захотел написать о таком понятии как Continuous Integration, ну или просто CI. Для тех кто не знает что это такое, то читаем в Wiki . Прочитав можно сразу понять, что понятие ci было впервые озвучено многоуважаемыми Фаулером и Беком в качестве набора базовых практик которые позволяют команде наиболее быстро получать фидбек по работе софта.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...
Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.
Ну в общем то для начала думаю хватит.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...
Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.
Ну в общем то для начала думаю хватит.
четверг, 20 марта 2008 г.
О читабельности кода
Недавно стал задумываться о том, какого хрена молодые разработчики (особенно студенты) сильно не гадуют почему нужно переменные, методы, классы, интерфейсы и т.д. и т.п. называть нормальными именами( как их принято называть жаваподобными именами). Каждый раз называют любимыми x, y, i и т.д. В чем заключается собственно барьер?
Школа. Проблема на мой взгляд кроется даже не в увиневере, а в школе. Итак вспоминаем школу урок математики. Приводится какая то задача и там же как было принято какие то неизвестные величины, тобишь переменные всегда называются x и y. Далее идет огромное дерево решений с использованием этих имен. При этом это является нормальным для всех, читабельным решением.
Универ. Такая же фигня после этого наблюдается и в универе когда препод говорит мол называем прибыль x, себестоимость a, цена b. И давайте мол решение автоматизируем и напишем x = b - a; и все счастливы. А на первый вопрос как во всем этом разобраться советует писать комментарии. Вот и настает полная фигня и бардак в коде. А это извините меня 10 лет в школе(грубо говоря) и 5 лет(в универе) впихивание таковой культуры.
Естественно на первые грабли такие товарищи наступают очень быстро, при первом же коммите ну или чуть позже, если конечно человек устроился на работу в команде)). По правде я когда то видел целые группы разработчиков у которых x и y-ки забиты в проекте и сопровождаются не менее большими комментариями. Это уже полный ахтунг.
Помню случай когда студенты спорили друг с другом на то, кто пишет труднее и в чьем коде трудней разобраться и это на самом деле для них являлось просто офигительным решением. Смешно конечно, но это было на самом деле.
Лекарство. Самый лучший пример по извлечению таких вредных привычек у такого товарища наверное просто заставить переписать его собственный код под новую логику. Там и выходят все отрицательные стороны его подхода и человек начинает понимать собственные ошибки. Если не понимает, то писец... Лучше сменить порфессию, либо работать одному.
P.S. Мысль возникла после того, как увидел автоматически сгенеренный скрипт от TestComplete(кто видел, тот наверное поймет). Такое впечатление что его писали именно такие товарищи о которых
писалось выше...
Хотелось бы подчеркнуть что тоном хорошего кода является не только название переменных конечно, но как то это зацепило так что не судите строго:)
Школа. Проблема на мой взгляд кроется даже не в увиневере, а в школе. Итак вспоминаем школу урок математики. Приводится какая то задача и там же как было принято какие то неизвестные величины, тобишь переменные всегда называются x и y. Далее идет огромное дерево решений с использованием этих имен. При этом это является нормальным для всех, читабельным решением.
Универ. Такая же фигня после этого наблюдается и в универе когда препод говорит мол называем прибыль x, себестоимость a, цена b. И давайте мол решение автоматизируем и напишем x = b - a; и все счастливы. А на первый вопрос как во всем этом разобраться советует писать комментарии. Вот и настает полная фигня и бардак в коде. А это извините меня 10 лет в школе(грубо говоря) и 5 лет(в универе) впихивание таковой культуры.
Естественно на первые грабли такие товарищи наступают очень быстро, при первом же коммите ну или чуть позже, если конечно человек устроился на работу в команде)). По правде я когда то видел целые группы разработчиков у которых x и y-ки забиты в проекте и сопровождаются не менее большими комментариями. Это уже полный ахтунг.
Помню случай когда студенты спорили друг с другом на то, кто пишет труднее и в чьем коде трудней разобраться и это на самом деле для них являлось просто офигительным решением. Смешно конечно, но это было на самом деле.
Лекарство. Самый лучший пример по извлечению таких вредных привычек у такого товарища наверное просто заставить переписать его собственный код под новую логику. Там и выходят все отрицательные стороны его подхода и человек начинает понимать собственные ошибки. Если не понимает, то писец... Лучше сменить порфессию, либо работать одному.
P.S. Мысль возникла после того, как увидел автоматически сгенеренный скрипт от TestComplete(кто видел, тот наверное поймет). Такое впечатление что его писали именно такие товарищи о которых
писалось выше...
Хотелось бы подчеркнуть что тоном хорошего кода является не только название переменных конечно, но как то это зацепило так что не судите строго:)
Подписаться на:
Сообщения (Atom)