Наверняка вы знаете, что часто причиной тормозов некоторых коммерческих программ являются закладки в коде типа:

for(i = 0; i < 100000000; i++);

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

Итак, нужно было сделать курсовую, иллюстрирующую, как несколько потоков разделяют общей ресурс – очередь. Одновременно потоки добавляют в очередь данные, а затем считывают из нее то, что добавили. Реализовал на C в Knoppix с использование pthread. Но веселье началось, когда я понял, судя по выводу проги, что потоки выполняются не одновременно, а поочередно.

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

После 5-часовой медитации и курения исходников до меня дошло – ведение логов и заставляло прогу работать правильно! При операциях ввода-вывода между добавлением данных в очередь теряется часть времени достаточная, чтобы хоть немного потоки поработали вместе.

После добавления аналога: for(i = 0; i < 100000000; i++) в поток, я заплакал над убитыми впустую выходными...

Работал над одним проектом, который до меня делали другие. Проект достаточно большой, и одна из его частей считывает некоторые данные с базы. Есть возможность регулировать дату от и до при считывании. Возникла проблема, из-за которой клиент очень ругался. Если промежуток от и до очень большой, к примеру кто-то захочет считать данные за несколько лет, то скрипт работает нереально медленно, а иногда даже выдаёт таймаут.

Бились над проблемой 3 дня, перелопатили кучу кода, даже нашли некоторые другие баги, которые не имели отношения к проблеме. В итоге наткнулся на кусок кода в том месте, где искать никто просто не додумался:

$res = $DB->getData($query); //считывает данные с ДБ и загоняет в пронумерованный массив

$data = new array();

foreach ($res as $key=>$value)

{

if (!$data[$key])

$data[$key] = $value;

};

Все это вместо простого $data = $res;

Что имел ввиду кодер, родивший это чудо, так и осталось загадкой.

Делали мы как-то в институте модель какого-то мирка, по которому бродят дикие звери и удовлетворяют свои потребности: едят, пьют, спят, размножаются. В общем, кривенькая такая моделька, но зачем-то она нам понравилась.

И вот по мере наполнения нашего мира существами перед нами встала проблема коллизий. Проявилась она совершенно архетипично - в узком перешейке, соединявшем какой-то полуостровок с каким-то континентиком, встретились два барана (точнее, как мы их тогда называли, "экземпляры класса ТБаран"), каждый из которых шел к какой-то своей, одной ему понятной цели, уперлись друг в друга и мало-помалу померли с голода.

До нас дошло, что надо делать механизм обхода динамического препятствия, поскольку наша модель данных была построена так, что на одной клетке два существа поместиться не могли. Ходы они делали тоже поочередно, поэтому взаимный телепорт друг на друга тоже был невозможен. Решили пойти "индийским способом" - один из встречных превращался в случайный элемент ландшафта, через который можно было пройти, а после перехода деревце или пенек превращались обратно в кролика или льва и шли по своим делам.

В таком виде мы и представили программу преподавателю.

Кто ж знал, что программа подкинет нам такой сюрприз!

На узкой горной тропе встретились неудовлетворенный желудочно ТБаран и неудовлетворенный сексуально ТСлон. Как объекты для удовлетворения своих потребностей они друг друга совершенно не интересовали, поэтому представляли друг для друга просто препятствие. Всемогущий Рандом решил, что в этот раз слону придется полежать немного в качестве элемента интерьера, а баран пойдет дальше. Скрипт бодро превратил ТСлона в квадратный метр свежей зеленой травы, радостный ТБаран сожрал ее, навалил кучу и там же рухнул спать. Несчастного слона поминали всей бригадой, включая преподавателя.

История про кабель навеяла. Прямо дежавю.

Мой коллега по одной конторе ваял софт к какой-то измерительной штуке. Ну не работает и все. Методом тыка понял, что в соединительном кабеле командную шину и шину данных поменяли местами а биты в шине данных перекрутили в обратном порядке. Ну да ладно - месяц убит не напрасно, ПЗУ в железке перепрописано новым микрокодом и все работает.

И тут приходит электрик.

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

Потом этим железом испытывали ракетные двигатели...

Институт. Пятый курс. Лабораторная по параллельному программированию. Студент защищает работу:

- Таким образом, полным перебором вариантов мы находим все возможные ответы.

Преподаватель:

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

- Путем организации параллельного вычисления.

Препод довольно кивает - студент закончил лить воду и сейчас начнет рассказывать, как он распараллеливал потоки, искал узловые точки алгоритма и т.д.

- Так как же вы организовали это параллельное вычисление?

В ответ студент показывает на четыре компа в аудитории:

- Компьютер №4 проверяет значения от нуля до миллиарда, компьютер №5 - от миллиарда до двух...

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

А потом в преддверии отмечания дня рождения я решила проконсультироваться с подругой-вебмастером о содержимом праздничного стола.

Разговор получился таким:

я: Привет! Ты сильно занята? Вопрос есть.

она: Нормально, давай.

я: Вот думаю, что с меню делать...

она: На javascript? Высылай код, посмотрю!

я: Нет, я о другом - горячее там, салатики...

В процессе работы над проектом на С# нарвался на следующее:

DateSelect.Value = (DateTime.Now.Month.ToString().Length > 1 ? DateTime.Now.Month.ToString() : "0" + DateTime.Now.Month) + "/" + (DateTime.Now.Day.ToString().Length > 1 ? DateTime.Now.Day.ToString() : "0" + DateTime.Now.Day) + "/" + DateTime.Now.Year.ToString().Remove(0, 2);

До сих пор не понял, чем этому человеку не понравилось

DateSelect.Value = DateTime.Now.ToString("MM/dd/yy");

Я как-то написал программку для проверки таблицы умножения.

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

И вот, сделал я так, что компьютер, пока не прорешаешь ему всю таблицу умножения, вообще ничего запустить не дает.

Дописал прогу и выложил на работе в общую папку с названием "Запусти меня".

Через полчаса все менеджеры повторяли таблицу умножения.

Копаясь в глубинах скрипта, написанного неизвестными кодерами

для имитации нажатий с клавиатуры, наткнулся на гениальный код:

integer i

while (i!=1)

Desktop.Typekeys("")

i--

if i==12

Desktop.TypeKeys("<#Plus>")

Так сказать, перестраховался человек... А вдруг когда-нибудь да станет i равно 12?

Работаю программистом по автоматизации производства. Есть большой проект, который уже несколько лет хорошо и стабильно работает, но в него регулярно нужно вносить небольшие изменения в связи с модернизацией оборудования. И был в свое время у меня помошник, в образовании которого есть ряд существенных пробелов.

Итак, одно из таких изменений было внесено и шел процесс финального тестирования на экспериментальном стенде - все отлично, все работает и радует глаз. И тут понадобилось мне отлучиться. Прихожу - оборудование стоит, никаких аварийных сообщений нет. Ненормально и совершенно непригодно для реальной эксплуатации. Пробую еще несколько раз: оборудование останавливается в произвольные моменты времени без всяких на то причин! А надо сказать, что проект сделан в среде UltraLogik, у которой с возможностями отладки большие проблемы. Поэтому самый верный способ поиска ошибок - это медленное и вдумчивое курение исходников. И вот при очередной итерации этого увлекательного процесса я обнаруживаю следующую процедуру, написанную моим горе-помошником.

procedure FBD_BLOCK(var Input : integer;

var FromValue : integer;

var ToValue : integer;

var Output : boolean);

var

prev_value : integer;

begin

Output:=false;

if (Input=ToValue) and (prev_value=FromValue) then Output:=true;

prev_value:=Input;

end;

Фанфары, мат и желание дать в репу! У него оборудование выключается, когда на систему снизойдёт вселенская благодать и случайное значение неинициализированной переменной совпадёт с нужным!

Хорошо, что это был первый раз, когда эта процедура реально использовалась.