Абармотовы заметки

Обедер.ру

2009-11-06T14:10:41Z

Сделал сервис по учету совместных расходов — обедер.ру.

Городской квест или как мы хотели сыграть в Street Challenge и что из этого получилось.

2009-08-12T17:40:10Z

За обедом Дима М. развлекал нас рассказами о ночных играх в Москве. Суть такая — несколько команд (водитель, штурман, «мозги» и машина) собираются на старте, получают легенду и отправляются в путь. По подсказкам нужно искать контрольные точки города и выполнять там различные задания. Кто раньше всех все закончит тот и молодец. Такая ночная «зарница» для жителей мегаполиса. Рассказывал убедительно, с вдохновением и мы решили попробовать. К сожалению почти все такие игры занимают целую ночь (как правило в выходные), т.е. придется уговорить семью что папа будет пропадать неизвестно где всю ночь и потом еще пол-выходного дня будет отсыпаться )) Слабо представляю как это можно сделать...

Но! Головы продолжали работать, пытаясь найти выход. И родилась очень интересная идея — «Городской Квест».

Квест проводится в течение недели или месяца. Игроки получают на сайте несколько заданий, выполняют их в любое удобное время и присылают отчет, за что получают очки. У кого к окончанию квеста больше всего очков тот и Буратина.

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

Примеры заданий:
- посчитать сколько ног на картине висящей справа от «трех богатырей» в третьяковке.
- сфоткаться в обнимку со страусом в «парке птиц» (эт скорей всего на выходные задание)
- сфоткаться орущим и несущимся на роликах по ул. Косыгина (культовая горка у роллеров)

Т.е. в задании главное, что при его выполнении игрок лично куда-то шел, что-то делал и параллельно «окультуривался».

Фактически человеку дается план развлечений на неделю да еще и с призами за активность.

Офигенная идея! И аналогов нет.

Аквариум

2009-08-04T13:06:29Z

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

Идея онлайн семинаров

2009-07-22T15:30:10Z

Сделать систему для проведения онлайн семинаров, тренингов и любых выступлений требующих общения с аудиторией.

Ведущий объявляет о проведении тренинга. При этом указывает дату-время начала и окончания, тему, тэги и т.п.

Собственно сам семинар:
Аудитория (посетители) смотрят онлайн-трансляцию семинара. И могут отправлять свои вопросы (комментарии). Тут же обновляемая лента с комментариями. Рядом с каждым вопросом в ленте кнопки голосования [+] и [-].

Т.е. зритель может спросить сам либо поставить плюсик у вопроса, если его задал кто-нить другой. Чем больше голосов у вопроса тем крупнее его шрифт.

Ведущий видит только ленту вопросов и по ходу дела отвечает на них (сразу или в конце семинара)

Похожие сервисы уже есть, тут идея именно в механизме комментирования.

Life

2009-01-21T07:39:03Z

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

Можно сделать мультиюзерную игру. Поле размером N x N, 2 (или больше) игрока, у каждого фишки своего цвета и каждому выделен участок поля (база), в которую он (и только он) может «кидать» фиругы. В зависимости от уровня юзера ему доступно различное число фигур — от «кирпича» и «планера» на первом уровне, до «панерного ружъя» и возможности создавать свои фигуры на высоких уровнях. Так же игрок может кинуть «бомбу», чтоб расчистить место в базе для кидания очередной фигуры. (и бомб и фигур конечное число, которое растет в зависимости от уровня)

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

Фишки взаимодействуют по обычным правилам. Цвет учитывается только при рождении — чьих родителей больше, такая фишка и рождается (фишка рождается ровно от трех родителей).

Самое короткое руководство по проектированию БД

2008-04-13T09:53:24Z

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

1. создаю свою систему, удовлетворяющую требованиям
2. импортирую данные из исходной базы

Эта заметка о пункте номер два.

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

Самое краткое руководство по проектированию Баз Данных.

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

1. Объекты

Первое что надо сделать — выделить виды объектов предметной области. В нашем случае это «товар», «раздел каталога» и «производитель». Для каждого вида создается своя таблица. Каждая запись (строка) таблицы содержит данные об одном объекте. Порядок следования записей не определен. Если данные добавляются в алфавитном порядке — при запросе на получение записей этот порядок будет нарушен.

Необходимо избегать дублирования данных. Например недопустимо хранить в каждой записи таблицы «товар» полную информацию о производителе. Т.к. при изменении каких-то данных производителя, придется искать все упоминания о нем в таблице «товары». Назовем нашим таблицы item, node и company.

2. Первичный ключ

Что бы «обращаться» к конкретному объекту необходимо дать ему уникальный номер. Вообще говоря это может быть любое уникальное поле или группа полей (например, в случае учета сотрудников — номер паспорта или фамилия, имя, отчество), однако по многим причинам гораздо удобней сделать отдельное поле с уникальным значением. Это поле и есть первичный ключ. Обычно это поле называют «id» (идентификатор).

3. Связи, внешние ключи

Все объекты каким-то образом связаны друг с другом — производители производят товары, товары размещаются в каталоге и т.п. Отношения бывают трех видов:

один-ко-многим

один производитель может создавать много разных товаров. Реализуется просто — в таблице объектов, которых «много» создается поле с id объекта, который «один». В случае товаров и производителей нужно в таблицу item добавить поле company_id, которое будет содержать id производителя данного товара. Такое поле называют внешним ключем.

многие-ко-многим

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

один-к-одному

допустим наш товар это книги и диски. Их общая информация хранится в таблице item, а данные специфичные для книг и для дисков будем хранить в таблицах book и disk соответственно. Т.е. для каждой записи в таблице book есть ровно одна запись в item. По сути это один объект хранится в двух таблицах.

Реализуется так — первичный ключ таблицы book содержит id из таблицы item. Т.е. первичный ключ одновременно является внешним ключем.

дерево

по сути это тоже что и один-ко-многим. Один раздел каталога содержит много других. Реализация такая же — запись таблицы node содержит id родительского раздела (parent_id)

4. обеспечение целостности

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

То же самое на SQL

1. создаем таблицы


    -- раздел каталога
    create table node (
        id numeric not null,  -- первичный ключ
        parent_id numeric not null, -- внешний ключ. ссылается на родительский раздел
        name varchar(200) 
    );

    -- компания-производитель
    create table company (
        id numeric not null, -- первичный ключ
        name varchar(1000),
    );

    -- товар
    create table item (
        id numeric not null, -- первичный ключ
        company_id numeric not null, -- внешний ключ. ссылается на компанию-производителя
        name varchar(1000), -- наименование
        qty numeric,   -- кол-во товара
        price numeric  -- цена за единицу
    );

2-3-4. Создаем недостающие связи и указываем какие поля являются первичными и внешними ключами.


    -- товар - книга
    create table book (
        id numeric not null,   -- одновременно первичный и внешний ключ, ссылающийся на item
        author varchar(1000)
    );

    -- товар - диск
    create table disk (
        id numeric not null,  -- одновременно первичный и внешний ключ, ссылающийся на item
        play_time numeric
    );

    create table node_item (
        node_id numeric not null,
        item_id numeric not null
    );


    -- для каждой таблицы указываем ее первичный ключ
    alter table node add constraint "PK_NODE" primary key (id);
    alter table item add constraint "PK_ITEM" primary key (id);
    alter table company add constraint "PK_COMPANY" primary key (id);
    alter table book add constraint "PK_BOOK" primary key (id);
    alter table disk add constraint "PK_DISK" primary key (id);
    -- у таблицы, реализующей отношение многие-ко-многим, первичный ключ составной.
    alter table node_item add constraint "PK_NODE_ITEM" primary key (node_id, item_id); 

    -- указываем внешние ключи и на что они ссылаются
    alter table node add constraint "FK_NODE_PARENT" foreign key (parent_id) references node(id);
    alter table item add constraint "FK_ITEM_COMPANY" foreign key (company_id) references company(id);

    alter table node_item add constraint "FK_NODEITEM_NODE" foreign key (node_id) references node(id);
    alter table node_item add constraint "FK_NODEITEM_ITEM" foreign key (item_id) references item(id);

    alter table book add constraint "FK_BOOK_ITEM" foreign key (id) references item(id);
    alter table disk add constraint "FK_DISK_ITEM" foreign key (id) references item(id);

Postgres pg_dump: password authentication failed

2008-03-28T12:12:59Z

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

Так pg_dump, к примеру, вместо ожидаемого запроса пароля и последующего выполнения своих непосредственных обязанностей сразу обругал меня FATAL'ом и сказал, что password authentication failed. Даже не смотря на ключ --password, который в принудительном порядке производит запрос пароля. А т.к. эта же утилита используется pgAdmin'ом, похожее ругательство иногда возникает и там.

Ошибка возникает под виндой и только при наличии папки «dev», находящейся в корне текущего диска.
Это дают о себе знать юниксовые корни постгреса. Они (корни) пытаются работать с терминалом через /dev/tty, которого в винде разумеется нет. Но при наличии папки /dev, утилиты заботливо его создают после первого вызова.

Лечится просто — перед запуском утилиты сотрите файл /dev/tty

Как бороться с «просвечивающим» SELECT'ом в IE

2008-03-18T14:01:14Z

Проблема

Стандартный select, оказавшись под непрозрачным дивом остается полностью виден в IE. Из-за этой его особенности, выпадающие меню, всплывающие окошки и прочие элементы, связанные с позиционированием дивов могут выглядеть крайне неаккуратно.

Решения

Есть несколько способов решения этой проблемы. Перечислю их от простого к сложному:

1. прячем select
2. iframe поверх select'а
3. собственные select'ы

Подробнее

1. прячем select
Самое простое решение — поставить селектам (всем или пересекающимся с дивом) css свойство visibility: hidden;
Разумеется искать все селекты и ставить каждому из них свойство не нужно. Достаточно определить css класс:


    .noselect select { visibility: hidden; }

и добавить этот класс к области над которыми окажется див.
Стить display: none; в этом случае не подходит — может «поползти» верстка страницы.

2. iframe поверх select'а
Пожалуй самое интересное решение. По совершенно непонятной для меня причине селекты в ИЕ не «пробиваются» сквозь iframe.
Т.е. если сначала разместить iframe а поверх него div — селекты будут вести себя, как во всех порядочных браузерах.
~~К сожалению это решение не подходит для полупрозрачных дивов.~~ (UPD: спасибо beartamer и vithar)

3. собственные select'ы
Нет селектов — нет проблемы. Т.е. вместо селектов можно использовать их имитацию.
Есть готовые скрипты, которые «на лету» заменяют все селекты на их аналог основанный на всплывающих дивах. Разумеется при этом наша проблема будет решена.
Однако есть пара замечаний. Во-первых далеко не все скрипты обеспечивают полную функциональность при имитации селектов. Во-вторых селекты будут иметь нестандартный вид, а это не всегда идет на пользу.

--

И нафига он мне нужен...

2005-01-24T10:36:05Z

На знаю для чего и зачем завел этот ЖЖ... Все-равно ничего писать сюда не собираюсь. Или собираюсь. Вобщем пусть будет.