blogger.com обнулена статистика просмотров ?

Сегодня с удивлением обнаружил обнуление статистики просмотра страниц блога у blogger.com.
Проблема , видимо, касается если не всех blogger.com-пользователей, то многих (первая реакция blogger.com).
Не смертельно, конечно, но неприятно.
Надеюсь, починят.

еще на тему лени :)

Знакомо ?)

Когда теория расходится с практикой

Многим из нас , наверняка, приходилось переживать волну энтузиазма, вызванного очередной прочитанной ИТ-книгой, очередной изученной методологией, которая после осмысления удивительно удачно разрешила бы текущие производственные проблемы, вопросы, недопонимание.
Воображение строит план, перспективы применения новых знаний заманчивы.. В теории красиво и ладно. Сплошной позитив. И вот ты весь такой позитивный и вооруженный погружаешься опять в производственную текучку. А ее участникам порой нет дела то книг, которые ты прочел, навыков , которые ты прокачал, обдуманных лучших практик, которые действительно оказали бы полезны в данном конкретном процессе... Инцерция. Твоя теория сталкивается с твоей же практикой. И очень важно , столкнувшись с ней, не сбиться в критиканство, не конфликтовать с людьми и беречь свой энтузиазм, стараясь конструктивно влиять на процесс. Стоит понимать, что люди годами работают по накатанным рельсам и даже , порой понимая, что рельсы эти устарели , не могут или не хотят (а иногда и не имеют права) что-либо менять.
Ну и всегда остается шанс того, что ты , впадая в эйфорию от новых знаний и жажды их применения, чего-то такого не учел, что делает в данном конкретном случае старые ржавые рельсы гораздо привлекательнее , чем все такие раскрасивые новые...

yandex.browser - первое впечателение о новом игроке

Кто не слышал и не в курсе - вчера вышла в массы первая версия браузера от Yandex. Все логично. Поисковик развивается динамично. Под рукой куча открытых технологий, из которых при желании и наличии средств можно попытаться сделать успешный продукт. По первому впечатлению - броузер мало чем отличается от Chromium, на основе которого он, собственно , и был собран. Изменения чисто косметические и затронули в основном верхнюю панель и строку адреса - так называемую "умную строку". "НАстройки", "Инструменты разработчика" - это все 1 в 1 как в Chromium. Что, вообще-то , не плохо) "Умную строку" я пока назвал бы "раздражающей строкой" - при клике на нее выскакивает здоровенная панель с кнопками , ведущими на различные Я-сервисы... Это дело , правда, отключается в "Настройках". В целом от браузера жтать чего-то сверхнового пока рано: как в хорошем смысле (новая функциональность) так и в плохом (новые баги). Новые фишки , надеюсь, скоро появятся. Новые баги, надеюсь, тоже =) А пока в помощь исследователям Яндекс честно приводит список стороннего софта, использованного в разработке. Из основного: js-движок "V8", парсер XML - expat, утечки искали Valgrind-ом и еще много другого... Жаль вот только версии стороннего софта не указываются :) Посмотреть на все это можно , набрав "chrome://Credits" в "умной строке". Пожелаю удачи новому броузеру - я за разнообразие !) p.s. отдельное спасибо за любезную landing-страницу для linux-пользователей. Будем ждать первых версий и для этой ОС.

Логи и безопасность - практика показывает

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

Игры со временем продолжаются

Только-только утихли споры по поводу перехода на постоянное летнее время, даже самые ленивые админы уже обновили tz-либы на своих серверах . И вот-те на. Опять , по-видимому, грядет переход - теперь на "постоянное зимнее". Понятно, что кому-то хочется удовлетворить свой законотворческий зуд, кому-то хочется набрать очков в глазах избирателей, которым пришелся не по нраву прошлый перевод, а кому-то хочется опять хоть как-то войти в историю (на худой конец вляпаться). Ну а нам опять, судя по всему, пере-привыкать, пере-проверять и пере-накладывать патчи. А принимая во внимание хоть и туманную но перспективу Медведа вернуться в Кремль через ННое количество лет, старые патчи предлагаю далеко не убирать - вдруг опять на летнее ? :)

mercurial: +100 к гибкости

Недавно обнаружил замечательное расширение для hg : crecord.
Оно позволяет делать построчные коммиты - то есть, выбирать конкретные строки, которые включить в очередной коммит.
Допустим у вас есть измененный файл и в стандартный diff попадают изменения , сделанные в рамках двух разных доработок. Изменения по одной из доработок вы хотите закоммитить,  а изменения по другой - пока не хотите. В этом случае как раз и поможет данное расширение..

Установка и подключение предельно просты:

1. выкачиваем расширение в локальную директорию из репозитория (расширение еще не включено в список стандартных)

$ hg clone https://bitbucket.org/edgimar/crecord

2. редактируем .hgrc файл  

[extensions] 



crecord = /путь/до/каталога/crecord/содержащего/__init__.py/ 

И теперь можем использовать как новую команду для hg:
$ hg crecord

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

p.s.

Без багов, конечно же , тоже не обошлось:

hg crecord требует указания имени пользователя.
Требует - указываем ... через стандартный для hg  параметр -u

$ hg crecord -u someuser
.. а он не понимает и продолжает требовать.

Приходится явно прописывать в .hgrc

[ui]
username = someuser
Приятного использования!

Тестировщики и тех.поддержка: взаимовыгодное сотрудничество

Вопросам взаимодействия тестировщиков и технической поддержки уделяется гораздо меньше внимания , чем, например отношениям тестировщиков и разработчиков. Хотя, на мой взгляд, тут также довольно много разных тонкостей, психологических моментов, проблем , стереотипов  и всяческих там особенностей.
Сотрудники технической поддержки находятся на самом "острие" , ежедневно общаясь с заказчиком, мотаются по командировкам , где зачастую в стрессовых ситуациях вынуждены оперативно решать технические проблемы, прикрывая порой промахи остального коллектива, оставшегося в уютном оффисе. Саппортеры - первые, кто узнает о проблемах заказчиков, фильтрует всяческие ошибки настройки от реальных багов. Благодаря близости к "реальной эксплуатации" техподдержка обладает особо ценными знаниями о конфигурациях софта, о типичных действиях реальных пользователей, об реальных объемах баз данных и еще о многом таком, о чем тестировщики могут только догадываться. В общем, "сильные стороны" тех.поддержки очевидны. Переворачивая известный афоризм , можно  сказать , что "недостатки техподдержки являются продолжением их достоинств". Сотрудник тех.поддержки зачастую не знает досконально всех особенностей системы и не настолько глубоко в нее "погружен" как разработчик или тестировщик. Поэтому порой ему недостаточно знаний о системе, чтобы точно поставить "диагноз" той или иной проблеме и, тем более , выявить точную причину произошедшего сбоя.
Тестировщики же, наоборот  , зачастую "оторваны от реальности" , не обладая полным пониманием всех тонкостей и особенностей того, как именно используется софт " в бою".
Исходя из вышесказанного должно быть понятно, почему вопрос взаимодействия тестирования и тех.поддержки - довольно важен. Для менеджмента и руководителей этих подразделений важно не только решать всяческие шероховатости, конфликты , возможные взаимные производственные споры сторон, но и налаживать и отлаживать процесс обмена знаниями. Тестировщики должны быть более осведомлены о "реалиях" использования софта для того, чтобы само тестирование стало более адекватным и направленным на реальные, а не вымышленные или высосанные из пальца  сценарии и конфигурации. Сотрудники тех.поддержки должны быть более информированы об особенностях этого самого софта  , чтобы давать более точные  и оперативные рекомендации заказчикам.
Процесс обмена знаниями можно построить по-разному.
Я бы хотел поделиться собственным положительным опытом организации и участия в одном из вариантов подобного обмена.
А именно в некоей ротации.
Время от времени сотрудникам технической поддержки передаются задачи на регрессионное тестирование тех или иных частей системы. Почему именно регрессионное?  Потому что в этом случае саппортеру не надо выдумывать тесты, погружаться в теорию и практику тест-дизайна - он проверяет работоспособность по методикам тестирования , которые , к слову, после работы с ними техподдержки , становятся намного богаче и адекватнее.
В то же самое время тестировщикам время от времени поручается разбор кейсов от заказчика, в ходе которого ребята по-новому начинают смотреть на вроде бы уже досконально знакомую систему и наборы своих тестов. А также, что немаловажно - переоценивают свою меру ответственности за общий результат.
Вот такое вот взаимовыгодное сотрудничество.

эти хрупкие автотесты

Ни для кого не секрет, что одним из обстоятельств, удерживающих некоторых от создания gui-шных автотестов по типу Selenium-овских , является большая вероятность написания хрупких (fragile) тестов. И действительно , для подобного вида тестов вероятность получить хрупкий тест более высока, чем для других видов.

Посмотрим, что же делает подобные тесты хрупкими:

1. Несогласованность с разработчиками. Зачастую тестировщику-автоматизатору достается интерфейс и функционал мало пригодный для "нехрупкой" автоматизации. Например (Если говорить о web), беспорядочное отношение к именованию контролов, присовению идентификаторов важным контейнерам, таблицам и т.д. В данной ситуации необходима совместная выработка общих правил и дальнейшее соблюдение соглашений. Разработчики любят хорошие ТЗ для того, чтобы было "комфортно" программировать, а тестировщики любят предсказуемый код и интерфейсы, которые "комфортно" автоматизировать.
2. Бездумное использование "записанных" тестов. Тут лучше привести пример. Есть таблица со списком объектов из БД. Гипотетический тест проверяет то, что она содержит запись об определенном объекте. Записывалка тестов генерирует код, который ищет нужную ячейку с текстом по xpath локатору с явным индексами tr и td. Тестировщик использует сгенерированный код без изменений и через некоторое время получает провал теста. В чем дело? А просто список объектов пополнен новым и старый сдвинут. Или разработчик выводит список без сортировки и СУБД вдруг "сфетчила" записи в новом порядке. Тут, конечно, можно запросить "поддержку тестирования" в виде добавления сортировки. Но правильнее сначала отредактировать локатор , убрав индексы (если, конечно, соблюдение порядока следования записей не критично), ну а потом можно и сортировку попросить.. для предсказуемости )
3. Часто меняющиеся требования к продукту. Тут уж никуда не деться от переделывания тестов. Рынок диктует свои условия. Поменялись требования, поменялся функционал / внешний вид , меняются тесты. Если подобные правки слишком часты и накладны, то стоит подумать о том, чтобы отказаться от автоматизации данного участка.
4. Плохой дизайн тестов. Тестируемая система не менялась,  а тест то и дело проваливается. Причиной может послужить недостаточно вдумчивое проектирование теста, не учитывающее возможное изменение тех или иных внешних по отношению к тесту условий при неизменности тестируемого функционала. Грубо говоря, тестировщик создал код , похожий на тот, что создают "записывалки". Рекордеры ничего не "знают" об особенностях, которые обязан знать и учитывать автоматизатор.

Наверняка, можно еще добавить несколько пунктов. Но навскидку - приведенные кажутся мне основными.

Платежные системы: непридуманный случай использования

Спешка.
Не вовремя заканчиваются средства на счету мобильного телефона.
Первый аппарат привычной системы оплаты.
Абонент закидывает в "кошелек" последнюю на данный момент наличность, например  500р, чтобы из "кошелька" уже совершить беспроцентное пополнение баланса мобильника.
Тут же в терминале заходит в кошелек и видит несколько предложений, как оплатить - но нужной возможности оплаты прямо из кошелька в терминале уже нет (закрыли в целях безопасности?).
Есть возможность отправки кодовой смс на кодовый номер - оператор берет плату - не подходит, так как баланс отрицательный.
Есть возможность оплаты из соответствующего android-приложения - не подходит, так как надо его качать ,  а 3g-сессии тоже не бесплатны.
Есть возможность через оплатить через сайт системы оплаты, что тоже неподоходит, так как халявного мобильного инета ОПСОСы еще не предоставляют.
В итоге: терминал деньги принял,  а потратить их не дает. Результат: у абонента наличных нет, связи все еще нет, абонент бегает ищет халявный вайфай (макдональдс, например) или банкомат (если есть карточка с нужным количеством средств)....

Вопрос авторам этой очередной версии ПО для терминала оплаты - вы о людях вообще думаете, когда патчи накладываете? ))