Раз уж тут опять появилась жизнь, то расскажу как я не смог поставиить скайп. До причин копать неохота, так как найден воркэраунд.

А началось все с того, что я вычищал реестр ХР от вредоносной программы MсAfee — но чего-то перестрался и у меня напрочь исчезла поддержка Ipv4 из сетевых интерфейсов. Вернуть нормальными путями не получилось, что-то подобное вбивать и сверять руками не хотелось. Кстати, на самом деле в реестре не было нужных записей и я было начал вбивать их, но стало лень и было решено просто поставить ту же систему на диск D. Что и было сделано.

Далее после установки пары апдейтов (следует отметить, что оригинальный диск с XP SP2) я решил поставить скайп. Был старый инсталятор версии 4. Скайп не встал. Ну подумал я, что версия старая, не может на сервер сходить и скачал свеженькую, буквально накануне поставленную на Win7.


Читать дальше

Обычно я пользуюсь браузером Google Chrome. Но когда я писал вчера заметку про баг в Gmail и проверял, воспроизводится ли он в других браузерах, я заметил одну интересную штуку – в браузере Firefox шрифт в месте, где проявлялся дефект, выглядел более жирным, чем в Chrome. Это показалось мне любопытным, я посмотрел код страницы, и увидел там вложенные друг в друга теги <b>, примерно вот так:

простой, <b>жирный, <b> ещё жирнее, <b>а можеть быть ещё?</b></b></b>

Разумеется меня сразу заинтересовало, что будет, если сделать не два уровня вложенности, а больше – три, четыре, пять – будет ли шрифт становиться всё жирнее и жирнее?

Увы, Firefox меня разочаровал – третий уровень вложенности выглядел так же, как второй.

Но и это ещё не вся правда – когда я поменял шрифт с “arial;sans-serif” на “times;serif” этот эффект двойной жирности исчез!

В итоге, я запомнил для себя, что для большинства браузеров есть лишь два понятия – обычный шрифт и жирный, а вот Firefox для некоторых стилей шрифтов поддерживает две градации жирности. Поэтому если вы увидели где-то незакрытый тег <b> – обязательно нужно проверить, как это будет выглядеть в браузере Firefox.

Уже второй день Google радует нововведениями в интерфейсе почты:

 

Похоже, сломался преобразователь «псевдотега» END_BOLD в настоящий закрывающий тег </b>.

Даже не знаю, есть ли специальные методы проектирования тестов, нацеленные на поиск такого рода дефектов. Ясно, что хорошо бы иметь автотесты для шаблонизатора, которые проверяют правильность преобразования отдельных конструкций. Кроме того, если бы разработчики сказали мне, что поменяли что-то в шаблонизаторе, я бы 1) спросил, где это может проявиться (в данном случае — при выводе сообщений жирным шрифтом), 2) при выполнении тестов (любых) смотрел во все глаза, выискивая такие сообщения, то есть включил бы режим фокусировки.

Но ведь не может быть, что гуглеры совсем не проверяли ничего. Почему и как этот баг остался незамеченным? Ведь для этого даже никаких специальных тестов делать не нужно, достаточно зайти в почтовый ящик. Может быть он проявляется только для некоторых пользователей? Если это так — задачка становится более интересной. Как это предугадать? У кого есть такой опыт?

Что-то давно я ничего не писал в Панбагон, пора возобновить эту добрую традицию. Тем более день только что закончился особый — День программиста, профессиональный праздник наших горячо любимых соратников.

По случаю этого торжества я получил поздравительное письмо от проекта askdev.ru, которое начиналось такими словами:

%D0%A1%20%D0%94%D0%BD%D0%B5%D0%BC%20%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82%D0%B0!
-------------------------
Вот и подходит наш праздник к концу а для некоторых уже закончился.

Господи, подумал я, до чего верно подмечено! Вот именно после этого письма тот самый программист, который ЭТО сделал, должен добровольно прекратить веселье и скромно удалиться править баг с кодировкой. Праздник для него закончился.

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

P.S. Не надо мне сообщать про то, что в заголовке ошибка, там одни сплошные фичи. Смотрите сами, если не верите.

Где-то в 20-х числах мая у нас пропал интернет. «Домашние» методы не спасли (типа тех, что с первых шагов советуют в техподдержке: «Бутните машину», «Бутните роутер»). Начались звонки провайдеру.

Радовало то, что валить все на нас не стали и сразу признались честно: «Проблемы на нашей стороне». После чего началась серия звонков под общим лозунгом: «А вот теперь попробуйте!» Не помогло… И не помогало еще два дня.
На третий день мастер не выдержал (или просто закончились деньги на звонки другому мобильному оператору) и решил посетить нас лично. В отместку за уже третий день без сети (для семьи айтишников как без хлеба!) на основной машине запустили Убунту. :) Мелочная такая мстя. :) Но приятная ))

Мастер просидел у нас почти 4 часа. Он еще раз прояснил для себя, что на нашей стороне все хорошо, подучился работать в консоли линукса, вдоволь нанюхался запахов готовящегося пирога из кухни (я постаралась, да) и ждал пока человек «из офиса» выяснит что же не так.

В итоге прояснилось.
«У вас очень сильно перебран трафик и система автоматически отключила вас от интернета!»
«КАК?! У нас же безлимитный тариф?!»
И тут выяснилось, что даже на безлимитные тарифы у провайдера есть лимит. Но установлен он таким образом, что при нашей скорости эту границу мы физически преодолеть не можем. А мы за примерно 3 недели месяца не только ее преодолели, но и накачали сверх положенного столько, что система решила: «пора прикрывать эту лавочку».

Еще нам было сказано, что такая ошибка у них возникает чрезвычайно редко (учитывая скорость фикса я даже предполагаю, что мы — первопроходцы в этом вопросе). Так что собой можно гордиться :)))
Оставшуюся неделю до конца месяца вспоминаю с ужасом. Система автоматически пыталась не дать нам волю, мы звонили провадеру, там опять «шикали» на систему и заветные два мониторчика снова весело мигали. Несколько часов...
У нас есть одна догадка о том каким же именно образом нам удалось преодолеть эту границу. Но, опять же, причина этой возможности преодоления кроется в провайдере. :)

Boundary Testing Forever!

Всем привет!

Не так давно была написана вводная статья, которая кратко объясняла базовый функционал проекта FIXber — рынка услуг по тестированию программного обеспечения.




С тех пор мы доработали новый функционал и значительно переработали старый.
И вот сейчас, как и обещали, мы готовы предоставить вам проект на «пощупать».



Читать дальше

Собрался я вчера обновить VirtualBox до недавно вышедшей новой четвёртой версии. Скачал, начал устанавливать, по привычке жму быстро Next в визарде, и вдруг в какой-то момент осознаю, что на предыдущем шаге было написано что-то важное, судя по всему какое-то предупреждение, потому что всё такое ярко-красное, крупным шрифтом и мне почудилось там слово “warning”. Тут я останавливаюсь и решаю вернуться на предыдущий шаг, чтобы почитать, о чём меня хотели предупредить создатели продукта. На экране чёрным по белому написано «If you want to review or change any of your installation settings, click Back». Однако не тут-то было – кнопка Back есть, она активна, но при нажатии ничего не происходит, вернуться на предыдущий шаг визарда нельзя!

К счастью кнопка Cancel всё таки работала, поэтому я отменил инсталляцию и начал всё заново. И когда я дошёл до шага с предупредительной записью, я увидел, что экран визарда несколько отличается от привычного – вместо обычных кнопок Next и Back на этом экране имеются кнопки Yes и No:

В результате этот экран делит визард на две части – если вы дошли до него, вы уже не можете вернуться на предыдущий шаг и изменить директорию, в которую собираетесь инсталлировать приложение. Ну а если нажали Yes и прошли дальше – то теперь обратного пути совсем не будет, даже кнопка Back не позволит вам вернуться назад.

Для того ли была придумана концепция визарда, чтобы вот так походя сломать её ради дурацкого вопроса? Почему нельзя было сделать это обычным способом, с кнопкой Next в качестве согласия с предупреждением? И ведь наверняка какой-то дизайнер интерфейсов специально ЭТО придумал, хотел сделать “как лучше”.

Блуждая по просторам своего винчестера, наткнулся на книгу: «TCP-IP. Экзамен 70-059».
Книга представляет собой источник практических советов.
Это прекрасно!
Авторы книги — мэтры ИТ-индустрии — передают читателю свой бесценный опыт решения актуальных проблем. 
Школьник, изучив «Экзамен», получает знания и опыт сравнимые с опытом высококвалифицированного сетевика.
Метод проб и ошибок — не единственный путь к Гуру ИТ.

N-ая компания – наш заказчик – специализируется  на сервисе Online Backup.
В стратегических планах развития, компания заключила контракт с производителем антивируса  на интеграцию Online Backup в антивирусное ПО. 
Антивирусники, тестируя сервис Online Backup – в первый же день – находят критический баг. 
В URL отражались цифры – ID пользователей. 
Меняя цифры в ID  и нажимая Refresh, пользователь получал возможность зайти на страницу-аккаунт другого пользователя.
Свежий взгляд сторонних тестеров на привычные вещи, однако…

Я не тестировщик, но так как единственный электронный адрес на сайте https://ticket.rzd.ru/ оказался нерабочим, а выплеснуть свой пар нужно, напишу сюда.

Итак, ведь классно же, что можно не выходя из дома купить билет на поезд и пройти электронную регистрацию. Я трачу 5 минут времени на поиск, заказ, оплату и электронную регистрацию, а потом подхожу к поезду с паспортом и все, Я ЕДУ. Ни очередей, ни выкупа билета – правда, круто?

Нельзя сказать, что сайт интуитивно понятен, даже скажу больше – будь я гуманитарием, не в жизнь бы не разобралась, но заказать билеты можно и это очень здорово.

Но!!!!

Сегодня я очень долго не могла заказать билеты. И вот почему:

Читать дальше