#364: Fuck off, please?
16 декабря 2008, 12:45. рейтинг: 1280
Работаю в международной компании, поддерживаю RT (тикет-система). Пришёл запрос от руководства, улучшить безопасность – усилить фильтрацию входных e- mail'ов. Усилил. Пишу аккаунт-менеджеру (главный по работе с клиентами), мол, дай вежливый и правильный текст письма на английском. Через полминуты получаю требуемый текст:
%Manager%: Dear non-customer,
%Manager%: Fuck off, please.
%Manager%: regards,
%Manager%: %CompanyName% email bouncer
Видимо накипело.
#365: Какое страшное самоубийство!..
16 декабря 2008, 12:45. рейтинг: 6634
Делали мы как-то в институте модель какого-то мирка, по которому бродят дикие звери и удовлетворяют свои потребности: едят, пьют, спят, размножаются. В общем, кривенькая такая моделька, но зачем-то она нам понравилась.
И вот по мере наполнения нашего мира существами перед нами встала проблема коллизий. Проявилась она совершенно архетипично – в узком перешейке, соединявшем какой-то полуостровок с каким-то континентиком, встретились два барана (точнее, как мы их тогда называли, "экземпляры класса ТБаран"), каждый из которых шел к какой-то своей, одной ему понятной цели, уперлись друг в друга и мало-помалу померли с голода.
До нас дошло, что надо делать механизм обхода динамического препятствия, поскольку наша модель данных была построена так, что на одной клетке два существа поместиться не могли. Ходы они делали тоже поочередно, поэтому взаимный телепорт друг на друга тоже был невозможен. Решили пойти "индийским способом" – один из встречных превращался в случайный элемент ландшафта, через который можно было пройти, а после перехода деревце или пенек превращались обратно в кролика или льва и шли по своим делам.
В таком виде мы и представили программу преподавателю.
Кто ж знал, что программа подкинет нам такой сюрприз!
На узкой горной тропе встретились неудовлетворенный желудочно ТБаран и неудовлетворенный сексуально ТСлон. Как объекты для удовлетворения своих потреб ностей они друг друга совершенно не интересовали, поэтому представляли друг для друга просто препятствие. Всемогущий Рандом решил, что в этот раз слону придется полежать немного в качестве элемента интерьера, а баран пойдет дальше. Скрипт бодро превратил ТСлона в квадратный метр свежей зеленой травы, радостный ТБаран сожрал ее, навалил кучу и там же рухнул спать. Несчастного слона поминали всей бригадой, включая преподавателя.
#366: Дядя Вася
16 декабря 2008, 16:45. рейтинг: 2404
В свое время делали региональную сеть. По принципу – каналы (медь) предос тавляет одна госконтора, а мы оконцовываем. Запустили – все работает.
Через 3 дня вдруг один из участков начал сбоить. Причем, нестабильно. Данные проходят, но с потерями. Это один из худших видов ошибки. Две недели пытались выловить причину. Несколько раз меняли оконечное оборудование (а это поездка в 160 км). Клиент негодует. Использовали даже аппаратуру для проверки качества соединения, чтобы выявить всевозможные "наводки" на канал.
Сидим на оконечной точке. В очередной раз поставили новую аппаратуру, наст роили циски, все перепроверили – ничего не происходит. Грустим.
Тут заходит в гости дядя Вася – местный телефонист. Пьяный в доску.
– Привет ребята. Чё такие грустные?
– Да вот, опять связь нестабильная, пакетики теряем.
– Да не грустите, я вам тут в качестве подарка улучшение сделал.
Нас прямо приподняло над стульчиками.
– Мил человек, а что ты сделал?
– Дык я вам на линию усилок впаял. Чтобы сигнал посильнее был. Так что с вас бутылка.
– А покажи-ка?
– Дык вот же я прямо на кроссе в разрыв и вставил. Усилитель ТЧ (тональной частоты).
Опа, а у нас-то оборудование цифровое!
– Дядь Вась, а какую полосу частот он усиливает?
– ....
– Дядь Вась, вот тебе магарыч. За то, что уберешь свой "усилок".
Конечно же, все заработало. Дядь Васин усилок срезал самый верх несущей час тоты модема. И в результате порядка 10% пакетов терялось. Ни одному нашему спецу даже в буйных фантазиях не представлялось, что каким-то образом может вырезаться часть частоты.
#367: Собрать по кирпичику
16 декабря 2008, 16:45. рейтинг: 764
Работал над одним проектом, который до меня делали другие. Проект достаточно большой, и одна из его частей считывает некоторые данные с базы. Есть возмож ность регулировать дату от и до при считывании. Возникла проблема, из-за которой клиент очень ругался. Если промежуток от и до очень большой, к примеру кто-то захочет считать данные за несколько лет, то скрипт работает нереально медленно, а иногда даже выдаёт таймаут.
Бились над проблемой 3 дня, перелопатили кучу кода, даже нашли некоторые другие баги, которые не имели отношения к проблеме. В итоге наткнулся на кусок кода в том месте, где искать никто просто не додумался:
$res = $DB->getData($query); //считывает данные с ДБ и загоняет в пронумеро ванный массив
$data = new array();
foreach ($res as $key=>$value)
{
if (!$data[$key])
$data[$key] = $value;
};
Все это вместо простого $data = $res;