← All posts tagged dev

alex0b
Java dev рукожопие Драный jasper reports. Что руководило людьми, проектировавшим генератор отчетов, где у документа есть обязательный корневой data source? Они никогда не встречали сводных отчетов в одну страничку с совсем разносторонними графиками, наверно. Нет, конечно можно дополнительные data source допилить и даже подотчеты встроить. Можно и пропеллер прикрутить — не летает, зато крутится. Ок, корневой data source есть, но его нельзя использовать в качестве источника для дополнительного. Если надо запилить график и сводную таблицу, то это будут два ds и два запроса. Я уже раз прошерстил n млн строк, получил пару сотен. Теперь надо просто разные свертки сделать. Но зачем так просто? Лучше сделаем еще проще и тупее. Железо не потеет. Отдельное удовольствие заставить отчет отображаться одинаково в jasper studio и на полигоне. Да фиг с ним — одинаково — за неделю не получилось заставить его работать вне среды разработки, если используются местные встроенные функции. Просто падает, говорит функции не нашел. Даже если взять все либы из самой студии. Ок, я просто тупой. Но отчет, у которого дата отформатирована нечеловеколюбиво, не радует, даже если таблица не разлезется. Даже кособокие ms report builder / report server не вызывали такого глубокого неудовлетворения.
alex0b
dev рукожопие Когда люди выставляют холодильник зимой на улицу — это нормально. Когда они выставляют API в виде JSON­ RPC — это нормально. Но когда они заявляют, что "Функционально протокол реализует команды манипуляции данными DML языка SQL, точнее PostgreSQL диалекта ( postgresql.org )", начинаешь опасаться. Черви безумия.
alex0b
dev Свежеслепленный экзешник занимает ровно 320000 байт. Все торчащие палочки были аккуратно обрезаны.
alex0b
dev Несколько раз перечитал "никаких проблем с разными браузерами", пока не понял что слова "сраными" в этой фразе нет.
alex0b
dev Я у мамы сегодня плюсовик-затейник: вышивал крестами по WinAPI, чтобы проверить взаимодействие с моим идеальным кодом на dotNet. Смешно получилось — баг совсем не там. И да, больше ничего идеального нет.
alex0b
Linux ? PostgreSQL dev C Удивился без музыкальных инструментов: мои хранимочки написанные на C перестали собираться спустя пару лет. Точнее линковаться. Медитация над выхлопом gcc утомила и заставила найти простое и правильное решение в документации самого pg. А еще я понял, что ни фига не понимаю в этих gcc\Makefile и прочей прилежащей лабуде. Не то чтобы я планирую отряхнуть пыль с бороды на свитер и снова взяться за суровые, настоящие яп, но только теперь под правильной ОС. Нет, как раз предпочту держаться интерпретируемых, а понять принцип хочется из любопытства. Так вот, граждане, подскажите — кто что сможет: что-нибудь почитать кратенькое, поверхностное, но идейно верное про gcc, вот это всё?
alex0b
Java dev рукожопие Пускай будут полноценны и счастливы те обезьяны, которые научили меня скачивать и руками править wsdl-файлик, искать на фтпешках апача древний axis. Да выпрямятся передние лапы и просветлится разум тех макак, что в спецификации пишут универсальный формат дат, а на практике используют пиндосский. Чтоб им до пенсии на php писать. Дорогой энторпрайз, я твой soap в дверной глазок видел в светлых кросовках adidas.
alex0b
SQL dev Надо больше спать. Схема описанная в #2700053 не работает, как в общем случае так и конкретно для InnoDB. Рандомная вставка в таблицу со строковым PK — это не "медленно", а невозможно медленно.
alex0b
? SQL dev Жуйк, подскажи почему весь мир (и я в том числе) для налепливания меток к контенту делает схему типа:
posts (pk id, text content)
tags (pk id, varchar tag : unique_idx)
tags_posts (pk tag_id + post_id, fk(tags), fk(posts))

Чтобы найти все посты по метке X, надо выполнить что-то типа:
select p.* from posts p inner join tags_posts tp on p.id=tp.post_id inner join tags t on t.id=tp.tag_id where t.tag = X;
Как я понимаю, тут
— 1 скан по tag : unique_idx
— 2 inner join по индексам
+ что бы вывести список всех меток к посту надо выполнить еще один запрос с джоином.

Причем мир использует эту схему универсально, всегда и везде. А если скажем для случаев расчитанных на быструю выборку и допускающих медленную вставку/обновление сделать:

posts (pk id, text content, text post_tags) // post_tags — разбиваются по разделителю при формировании страницы
tags_posts (pk varchar tag + post_id, fk(posts))

select p.* from posts p inner join tags_posts tp on p.id=tp.post_id where tp.tag = X;
Так должно занимать больший объем за счет дублирования строк, но казалось бы должно быстрее выполняться и все данные достаются одним запросом. Что я упускаю?
В случае, если метками помечаются разные виды контента в выборке поста/картинки/бульбы по тегу — ничего не меняется — структуры запросов сохраняются. Для построения единного облака придется делать все таки общий словарь с счетчиком использования, что так же увеличит объем хранения, и приведет схему подобию первой, только pk в 2-х таблицах будут строчные. Неужели рост объема снижает весь профит от быстрой выборки?
alex0b
dev рукожопие ЯДибил Этож надо так профакапить: три ночи ядерной отладки, сотни логов, косоглазие из-за диффов. А всё потому, что при форматировании даты случайно нарисовал 12-часовой формат.
alex0b
dev uint32 cur_time = rtdbcon::CurrentUnixTime() / 60 * 60 + 60 ;Даже не знаю, что меня больше всёго тут смущает: толи / 60 * 60, толи ложь насчет настоящего значения текущего времени.
alex0b
dev happiness Запилил дедлок. Обнаружил дедлок. Подумал про грачей. Пофиксил дедлок. Пофиксил фикс дедлока. Работает. День прожит не зря.