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

1. 80 литров во варианте «карманы отстёгнуты/свёрнуты/ужаты», 120 в максимальной.
2. Нормальная спина (ну чтобы можно было пройти километров пять минимум).
3. Непромокаемый или со специальным непромокаемым чехлом.
4. Тёмного цвета.
5. Который прослужит достаточно долго.
6. Обязательно должен открывался либо как чемодан, либо иметь карман снизу.

В идеале:

1. Цвет — олива.
2. В наличии — посадочные места для MOLLE подсумков.

Времени на покупку будет часов 4-5, не больше.

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

1. played = 1, avgScore = 150;
2. played = 1, avgScore = 300.

Почему так — разбираться влом, но факт остаётся фактом, запросы в mySql получаются императивными, что меня не обрадовало. Кстати, формула для avgScore достаточно проста: avg(n+1) = (n * avg(n) + a(n+1)) / (n+1).

Из новых приколов: драйвер для mySql в PDO в виндовой версии PHP с приятным багом. Более двух инсертов за одну сессию засунуть нельзя. Даже, если они заныканы в хранимку. Надо рвать/поднимать соединение заново. Или юзать стороннюю дллку, где бага нет.

Баг присуствует в таких сборках как denwer и vs.php, как минимум.

Приятной работы.

Чего-то плагин подглюкивает, каменты не всегда открывает. Загадка про MySql в силе ещё сутки.

Дано: таблица T с полями id (pk, autoincrement, int(11)), played (int(11)), avgScore(int(11)). Для записи с заданным id played = avgScore = 0. Это важно.

Вопрос: чему будут равны played и avgScore для записи с этим id (пусть будет 123, неважно) после запросов:

1. update `T` set
`T`.`played` = `T`.`played` + 1,
`T`.`avgScore` = (`T`.`played` * `T`.`avgScore` + 300) / (`T`.`played` + 1)
where `T`.`id` = 123;
2. update `T` set
`T`.`avgScore` = (`T`.`played` * `T`.`avgScore` + 300) / (`T`.`played` + 1),
`T`.`played` = `T`.`played` + 1
where `T`.`id` = 123;

Чота, я туда не еду. Без защиты лица на игры по правилам СК ездить — опасно, а я не маньяк, пока.

Переделал дисклеймер в ЖЖ, добавил вишлист. Думаю наклепать резюме, а то, что-то непорядок.

Заголовок: Банановая республика
Место проведения: г. Тамбов, полигон «Лысые Горы»
Ссылка: форум ЦЧ страйкбола
Описание: Суточная игра.
Дата: 2009-07-18 — 2009-07-19

Заголовок: Поездка на волгу
Место проведения: Саратов
Описание: Отпуск
Дата начала: 2009-07-25
Дата завершения: 2009-08-01

Обещанное продолжение про профайлеры. Начало тут

В предыдущей статье мы сделали дамп с помощью WinDbg. Далее, что с ним можно сделать? Наверно много, но меня интересовало только одно, а именно — память. Поэтому, я загнал дамп в .Net Memory Profiler.

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

Пришлось гуглить и пытать по аське знакомых. Результаты:

“!eeheap -stat” — выдаст статистику по управляемым кучам. Предварительно надо загрузить расширение sos.dll. Посмотрев результаты, я понял, что управляемой памяти на самом деле всего полтора гига.

Дальнейшее было делом техники — зацепился из кода к GC Lua, стал выводить статистику по памяти в лог и убедился, что жрёт наш замечательный интерпретатор.

А вот пособие для нубов, как юзать WinDbg для отсечки утечек памяти.