суббота, 3 декабря 2011 г.

[life.photo] Несколько фотографий, которые меня зацепили

Зацепили в плане композиции и исполнения.

Все из разных выпусков WSJ’s Photos of the Day. Первая вот (взята отсюда, автор Navesh Chitrakar):

Прямо иллюстрация к главе о цветовых акцентах учебника по фотографии. Как и вторая (взята отсюда, автор Rod Sanford):

Ну и третья (взята отсюда, автор Damir Sagolj):

Удивительно: бОльшую часть снимка занимает дверь лимузина, да и у героя снимка видна лишь половина лица. Но снимок производит на меня сильное впечатление – подчеркивается мимолетность и отстраненность, показушность приветливости властьимущих. Интересно, фотограф выцеливал такой момент, или же это оказался единственный стоящий кадр из серии снимков отъезжающего кортежа?

[prog] Диагностика vs Скорость

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

Однако жертвой погони за скоростью может стать не только код. На неделе разгоняя обработку ответов от удаленной системы столкнулся с тем, что изменив схему обработки, переместив большее количество действий на уровень БД, значительно потерял в диагностике происходящего. Ответы приходят в асинхронном режиме, какой-то запоздает, какой-то придет повторно, может даже совсем левый ответ поступить. Раньше обработка была медленнее, я делал больше запросов к БД и точно знал, почему ответ должен быть проигнорирован. А сейчас запросов к БД меньше, выполняются они быстрее, но я вижу только списки актуальных и неактуальных ответов. Причина неактуальности уже недоступна. Чтобы ее сохранить, нужно делать лишние манипуляции с данными, а это потеря скорости, что недопустимо.

Раньше было “ответ такой-то проигнорирован потому-то”, а стало “ответ такой-то проигнорирован”. И все. Такие дела.

PS. Усвоенная мной за последние десять лет мудрость: логов мало не бывает ;)

[life] 10 мифов об интровертах

Здесь. Интересно. Особенно понравилось вот это (курсив мой):

Миф 9. Интроверты не умеют расслабляться и получать удовольствие.
Интроверты обычно расслабляются дома или на лоне природы, а не в шумных общественных местах. Интроверты не охотятся за острыми ощущениями и не являются адреналиновыми наркоманами. Если вокруг них слишком много разговоров и шума, они просто “выключаются”. Их мозг очень чувствителен к нейротрансмиттеру допамину. У интровертов и экстравертов различаются ведущие нейронные пути. Просто учитывайте это.

Курсивом я выделил еще одну хорошо сформулированную причину того, почему я не хочу быть начальником. Просто “выключаюсь” :)

PS. Ссылка найдена здесь.

пятница, 2 декабря 2011 г.

[prog] Слоистость, мать ее!

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

Этот афоризм вспомнился в попытках понять, почему select из временной таблички с сотней записей и двумя столбцами занимает десятки миллисекунд. Хотя более тяжелые запросы из больших таблиц, как правило, отрабатывают в три-четыре раза быстрее.

Есть MS SQL Server (не важно, 2005 или 2008), есть ODBC, над ODBC еще есть OTL. И простой select длится 50 миллисекунд (при том, что insert-ы – всего 7 миллисекунд). Какой слой здесь выступает тормозом? На кого вешать собак?… Тайна сия велика есть.

Павбывавбы, короче.

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

четверг, 1 декабря 2011 г.

[life.photo] Ёлочка, лети!

Здорово фотограф (Pascal Lauener) скомпоновал все! Это рождественскую ёлку доставляют в Берн на вертолете.

Снимок найден в очередном выпуске WSJ’s Photos of the Day.

[life.science.wow] The Scale of the Universe

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

The Scale of the Universe.

Хотя, подозреваю, что это баян.

[life.wow] Фокус с картами и аквариумом

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

среда, 30 ноября 2011 г.

[life.cinema] Очередной кинообзор (2011/11)

Подошло время очередного кинообзора. Как обычно в последнее время, фильмы в списке расположены в порядке убывания моей субъективной оценки. Сразу хочу сказать, что ничего особенно выдающегося за прошедший месяц посмотреть не удалось (за исключением, конечно, “Крестного отца”, но об этом отдельно).

Липучка. Малобюджетненько и, местами, туповато. Но забавно.

Бабло. Забавно.

Всегда говори "ДА". Смешной. Правда видно, что Джим Керри не очень вписывается в роль намного более молодого героя.

Профессионал (который Killer Elite). Очередной фильм с участием Джейсона Стэтхэма в очередной роли "круче меня только яйца". Впрочем сделано добротно, крепкий боевичок. Но в "основан на реальных событиях" не верится.

Ларри Краун. Совершенно нулевой фильм в плане сюжета и идеи. Но актерского мастерства у Тома Хэнкса с годами меньше не становится.

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

Опасный квартал. Посмотрел этот весьма качественно снятый фильм, с хорошими актерами, но не понял, о чем он. И зачем его вообще снимали.

Аполлон 18. Не могу сказать, что мне понравилось. Слишком часто пытаешься отогнать от себя мысль "а это какая камера снимала и откуда она там взялась?" Не говоря уже о том, как все эти записи попали на Землю :)

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

11-11-11. Дешевенькая галиматься. Дешевизна проявляется как в сюжете, так и в спецэффектов. В общем, смело можно не смотреть.


Пересмотрел три серии “Крестного отца”. Точнее, посмотрел сначала первую часть. Впечатление пострясающее. Я смотрел его давным-давно, кода мне было лет семнадцать. Тогда было понятно, что это фильм очень сильный. Теперь еще раз удостоверился в этом. Что любопытно, первой части уже почти 40 лет. Но приставка “ретро” не нему до сих пор не применима.

Жаль, что Коппола не ограничился только первой частью. Вторую уже можно было бы и не снимать. Хотя впечатления она и не портит. А вот от съемок третьей части вполне можно было бы отказаться. Впрочем, это мое личное мнение.

воскресенье, 27 ноября 2011 г.

[prog] Немного о двух недавно найденных багах, их причинах, способах выявления и вообще

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

Найти проблему помогли, в основном, два фактора:

  • во-первых, это своевременное привлечение разработчиков к выяснению причин странной работы ПО. У нас работает комплекс из программных компонентов, который в совокупности стал показывать меньшую, чем обычно, производительность. А причин этого видно не было. Коллеги из техподдержки попросили меня посмотреть на происходящее. Я же, зная принципы работы частей комплекса увидел, что операция, которая должна отрабатывать за доли секунды, почему-то занимает десятки секунд. Если бы не это, то проблема могла бы остаться незамеченной и дальше;
  • во-вторых, везение. Медленное выполнение одной операции на боевой БД – это хорошая диагностика, но явно недостаточная для выяснения причин. Нужно было как-то повторить такую ситуацию на тестовых стендах. И тут невероятное везение. Первый же запуск приложения на старом тестовом стенде выявил ту же самую проблему. Оказалось, что стенд использовался для проверки разных компонентов и нагрузку на него давали самую разнородную. В результате чего в тестовой БД так же образовалась нужная смесь из старых и новых данных, которая и приводила к увеличению времени на их обработку. Ну а дальше оставалось только спокойно разобраться в ситуации.

Что особенно хотелось бы подчеркнуть говоря об этой проблеме – самые серьезные ошибки в приложениях вызваны вовсе не особенностями языков программирования (чем Java/C#-программисты так любят пугать C++ников, а Haskell-исты вообще гнобят всех нефункциональщиков). А, например, просчетом разработчика при выборе алгоритма. В результате чего есть правильно написанный код, без багов, который делает все, что хотел программист. Только вот не то, что следовало бы делать.

Вторая ошибка вообще вспоминается как страшный сон. Пытаясь ускорить обработку данных в одном из приложений я вместо while(!stream.eof()) написал if(!stream.eof()). Т.е. вместо цикла по содержимому потока сообщений выполнялась обработка только первого сообщения в потоке. Приложение действительно ускорилось – ведь оно стало выполнять в сотни раз меньше действий.

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

Причина сей ошибки банальна – модификация делалась в спешке и, поэтому, не была должным образом протестирована. Я прогнал только одиночные тесты. Затем выполнил тесты для пачек сообщений большего размера, но анализ результатов толком не провел. Тем не менее, излишняя самоуверенность и желание быстрее все закончить привели к тому, что обновленная версия ПО с ошибкой была поставлена в бой (хорошо хоть хватило здравого смысла установить ее лишь на одном из многих каналов обработки сообщений).

Обнаружить проблему удалось на следующий день. Благодаря хорошему стечению обстоятельств:

  • во-первых, я таки не поленился создать для новой версии отдельное тестовое окружение чтобы продолжить начатые накануне оптимизации. И именно на новом тестовом стенде стали проявляться странности, природу которых я сразу не понял;
  • во-вторых, приблизительно в это же время стали приходить жалобы из техподдержки о том, что в одном из приложений растут очереди не доставленных ответов. Что было странно, поскольку по логам было видно, что ответы до нужных получателей доходят.

Сложив всю симптоматику я понял, что дело в тех самых внесенных накануне изменениях. Версию, понятное дело, откатили, очереди стали уменьшаться. А я, как идиот, по 20 раз пересматривал куски кода с if-ами вместо while-ов и не мог понять, почему же программа работает не правильно.

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

  • тестирование, тестирование и еще раз тестирование. Даже если ты уверен, что изменения незначительные и все работает – проверь еще раз. Особенно, если ты уверен;
  • писать нужно просто. Очень просто. Чуть ли не до дебилизма просто. Поскольку в условиях сильного напряжения, внешнего давления и жестокого цейтнота разобраться в простом коде (пусть даже объемном) еще можно. А вот в сложном, в котором каждая строчка содержит по несколько нетривиальных действий – уже навряд ли.

Ну и в завершение, чтобы не забыть, еще пару тезисов:

  • что-то я стал сомневаться, что посредством каких-то абстрактных слоев (вроде ORM-библиотек) можно создавать нагруженные приложения, способные работать с СУБД от разных производителей. Скажем, которые могут работать и с MS SQL, Oracle и PostgreSQL. Под конкретную СУБД и даже под конкретную инсталляцию БД нужно делать какую-то специфическую заточку напильником. Например, по результатам трассировки активности MS SQL пришлось добавить в один из SQL-запросов опцию MAXDOP. Можно ли делать такие низкоуровневые оптимизации текстов запросов в случае ORM – я не знаю;
  • online-мониторинг происходящего в приложении – это must have. Хорошо, что на заре своей карьеры мне довелось принять участие в разработке SCADA-пакета, где мне и была привита привычка к online-мониторингу. Вообще, чем больше работаю, тем более занимает меня идея о том, что для контроля над приложениями (режима 24x7 в частности) нужно применять те же самые подходы, которые уже давно используются в АСУТП. В частности, приспосабливать системы SCADA для мониторинга внутренностей приложения. Впрочем, это уже тема отдельного разговора.