← All posts tagged dev

alex0b
dev

Я у мамы сегодня плюсовик-затейник: вышивал крестами по WinAPI, чтобы проверить взаимодействие с моим идеальным кодом на dotNet. Смешно получилось — баг совсем не там. И да, больше ничего идеального нет.

alex0b

Удивился без музыкальных инструментов: мои хранимочки написанные на C перестали собираться спустя пару лет. Точнее линковаться. Медитация над выхлопом gcc утомила и заставила найти простое и правильное решение в документации самого pg. А еще я понял, что ни фига не понимаю в этих gcc\Makefile и прочей прилежащей лабуде. Не то чтобы я планирую отряхнуть пыль с бороды на свитер и снова взяться за суровые, настоящие яп, но только теперь под правильной ОС. Нет, как раз предпочту держаться интерпретируемых, а понять принцип хочется из любопытства. Так вот, граждане, подскажите — кто что сможет: что-нибудь почитать кратенькое, поверхностное, но идейно верное про gcc, вот это всё?

alex0b

Пускай будут полноценны и счастливы те обезьяны, которые научили меня скачивать и руками править wsdl-файлик, искать на фтпешках апача древний axis. Да выпрямятся передние лапы и просветлится разум тех макак, что в спецификации пишут универсальный формат дат, а на практике используют пиндосский. Чтоб им до пенсии на php писать. Дорогой энторпрайз, я твой soap в дверной глазок видел в светлых кросовках adidas.

alex0b

Надо больше спать. Схема описанная в #2700053 не работает, как в общем случае так и конкретно для InnoDB. Рандомная вставка в таблицу со строковым PK — это не "медленно", а невозможно медленно.

alex0b

Жуйк, подскажи почему весь мир (и я в том числе) для налепливания меток к контенту делает схему типа:
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

uint32 cur_time = rtdbcon::CurrentUnixTime() / 60 * 60 + 60 ;Даже не знаю, что меня больше всёго тут смущает: толи / 60 * 60, толи ложь насчет настоящего значения текущего времени.

alex0b

Все таки задачи в TFS, и главное их интеграция с SCM сделаны неплохо. Можно лучше, но и это прекрасно работает. CMMI из коробки годится для больших проектов. Мы тут думали что мы особенные и перетащили свою "методологию", выращенную в ClearCase (которая далжна была называться "мы не понимимаем и не хотим использовать этот ваш RUP, а перепилим это все в типа Bugzilla Light"). А теперь медленно но верно отламываем все наши нововведения. Уже практически классический CMMI и остался. Правда тут не последнюю роль играет желание довести таки интеграцию ms project server с tfs до логического конца (Project, он занете ли не такой гибкий, у него не бывает двух смыслов в поле записи).
А теперь и облачный TFS — 5 юзеров бесплатно: habrahabr.ru и работает с Express студией, и Team Explorer Everywhere под эклипс. Это серьезный повод задуматься — не перетащить свое домашнее не-вижуал-студийное барахло под крылышко старику Стивену.

alex0b

Генерировал-генерировал docx с помощью OpenXML Format SDK только радости не много — офис2007 падает при попытке распарсить закрывающую скобочку в теге TableWidth: <w:tblW w:w="100%" w:type="pct" /> . Ну не сука?

alex0b

Хе-хе, вот оно правильное таргетирование рекламы. Решил позырить что да как слеплено на deeep.me
— тыкаю в него файербагом, а в голове заметка:

Интересуетесь реализацией? :)
Нам нужны любознательные PHP-разработчики! [ООП, MVC, Javascript, frameworks]
Пишите: sergey@deeep.me / Звоните: +7 (921) 927-09-61
P.S. Работа в офисе в Питере.

alex0b

Это все. Это надо уже в наркологию сдаваться, чтобы кофе откачивали из организма. Оставлю себе на память, что я тут понаписал и понадебужил:
try{
...
}finally{
throw Notification.the().Exception(Notification.Level.System, new Message(0, "DHCPv6: failed at #%d"), null, currentId);
}

alex0b

Определенно, такая реализация generic-типов не нужна. Вроде бы все просто: не нужна — не пользуй. Ан нет, буду колоться, но продолжать жрать этот кактус. Что бы приходить на работу, тыкать палкой цэ-шарпъ и улыбыться.

alex0b

Всем хорош pgsql, поддерживает ipv6 из коробки (хотя наверно уже все умеют давно), функции годные есть. Только вот если вот захочется выполнить какие-то операции с подсетями, например хотябы сформировать адрес следующей подсети (+1) — хрен что выйдет. Ойпивэ6 зело больших размеров, привести его к чему-нибудь не случится, выкусить кусок тоже. А я на сишечке не быдлокодил с институтика. Вроде осилил: pastebin.com . С удовольствием почитаю всех, кто захочет рассказать откуда у меня руки растут.