vadimpanin

Оно тупо не умеет писать и читать тем же сокетом одновременно. Поочередно может, одновременно - нет.
Как только вызываешь асинхронную запись, пока идет асинхронное чтение - бумц! 10054 An existing connection was forcibly closed by the remote host. Учитывая что UDP оно как бы connectionless - выглядит весьма забавно. Дуплексный режим.
Народ в интернетах предлагает эту ересь игнорировать и просто еще раз запускать чтение, но это ж странно как-то.
В принципе, это может быть и неплохо, например можно чтение перенести на другой порт и дать ему приоритет в QoS повыше, получать на него ARQ (Automatic Repeat-reQuest), и отдавать сами ретрансмиты. Oh, wait, тогда опять фуллдуплекс получается же. На линуксе при этом ошибок нет.

Тут делал скриптик для AutoHotkey, чтобы автоматом мышку перемещать за активным окном по Alt-Tab (удобно при использовании двух мониторов) и встретил неожиданную проблему. В винде есть такое понятие как DPI awareness у приложения, т.е. способность его реагировать не нестандартные DPI экрана, настроенные пользователем. Если приложение не умеет нестандартные DPI - происходит DWM Scaling его окна (растягивание контента, при этом шрифты начинают выглядеть размазанно). Так вот, выяснилось что положение и размеры активного окна (которое берет AutoHotkey) зависят от способности приложения работать с DPI. Если приложение этого делать не умеет, то его координаты и размер считаются исходя из стандартных 96 DPI (то есть, соответственно, цифры меньше), поэтому попытки передвинуть курсор в середину этого окна заканчиваются странно.

UPD: А самое странное в этой истории то, что майкрософт до сих пор не научило Skype нормально работать с нестандартными DPI, в результате чего или контакт лист выглядит так, что его с лупой рассматривать приходится, или все приложение отвратительно размазывается DWM scaling'ом. На макоси (на той же ретине) при этом все хорошо.

Тут есть необходимость протестить работу софта в условиях непредсказуемых сетевых затупов. Т.е. буквально, есть источник, есть приемник. Приемник с источника получает бесконечный поток по HTTP. Нужно в середину поставить софтину-регулятор, которая позволит руками управлять скоростью отдачи потока приемнику. Скажем, от полного останова потока секунд на 20, до последующей отдачи с пятикратной скоростью.
Нет ли чего уже готового? Понятно что написать за день можно, но вдруг.
Можно конечно nginx попробовать с ratelimit, скриптиком менять циферку в конфиге и делать nginx reload :)

Официальный туториал по JSF + Hibernate с сайта спонсируемого ораклом нетбинза. Обратите внимание на удобнейший современный ORM.

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

http://lists.cairographics.org/archives/cairo/2013-December/024858.html

Я не знаю что ему принес Санта (или он просто в Колорадо живет), но тащить в C++ стандарт API для отрисовки 2D графики - идея более чем странная. Особенно если брать за основу существующую реализацию Cairo на сишечке.
Причем, отрисовка 2D графики сама по себе нужна редко (ну, там, школьникам кружочки порисовать), обычно графика нужна для отрисовки гуя. А гуй -- это получается другая библиотека. Если сейчас в каком-нибудь Qt одновременно пилят и контролы и их отображение, то если это API проползет в стандарт - будут библиотеки чисто для контролов, с рендерингом на а-ля Cairo, и глючить будут по-разному, в зависимости от реализации API на конкретной платформе/конкретном компиляторе. Получаем уже две проблемы.

Меня коллеги не засмеют за такие идентификаторы функций? :)
"serializeFieldArrayOfObjects"
"serializeFieldMapOfScalarsOptional"
Написал тут сериализацию, которая одинаково хорошо и удобно упаковывает объекты как в json, так и в бинарное представление. Попутно пришлось избавиться от перегрузки функций, потому что интуитивно понятным образом serialize(anything) сделать не получается. Потому что те же вектора uint8_t можно засериализовать как массив, а можно как данные. Причем первое в json будет массивом, а второе - текстом (в base64, например).

параллелизации и резервированию систем программного обеспечения. В частности, с реляционными СУБД и дисковыми массивами. С целью сохранения консистентности данных и обеспечения непрерывной работоспособности. А то создается ощущение, что приходится заниматься каким-то велосипедостроением.

"Ага, нормальные люди пишут на сях, и у них все течет да сегфолтится, зато очень быстро.
А если поменять порядок копирования байтиков в memcpy(3) на обратный, то у них КРОВЬ КИШКИ РАСП-ДОРАСИЛО...

А вот нормальные люди, которые пишут на PHP. У них всегда все как-то работает, но никто не знает, что будет в пограничных случаях: возможно, сообщение будет отправлено случайному пользователю, возможно, на сервере закончится место. Что стрясется — не знает никто, но все делают вид, что все в порядке.

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

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

Чистые си [мне иногда кажется] надо отменить. Вообще отменить языки, где нельзя сделать нормальное автоматическое управление памятью (в C++, есличо - можно). C, Objective-C (в том обгрызенном виде в каком он в gcc представлен).
Я на выходных потратил три часа чтобы найти утечку где-то внутри ffmpeg'а, так и не нашел. Дотрейсил ее до bitstream filter'а aac_adtstoasc, и как бы все, где они там умудряются память выделять я не понял. При выгонке 250GB видеофайла в софте утекает примерно гигабайт памяти. Надо делать изолированный кейс и брейки ставить на маллоки всякие (чего я жутко не люблю).

На хабре какой-то крендель начал цикл статей о lock-free структурах данных, за обедом как-то подняли эту тему.
Вообще, сихронизация многопоточных программ - достаточно обширная и сложная тема. Даже опытные разработчики сталкиваясь со сложным софтом нередко натыкаются на дедлоки. Я не говорю про примитивы типа клиент-серверного веб-софта, где синхронизация заключается в простом разделении доступа к ресурсам. Я говорю про софт, который одновременно работает с десятком-другим достаточно разнородных объектов-тредов, параллельно работая с написанными левой ногой драйверами к какому-нибудь телевизионному железу (где внезапно приходят колбеки, когда объект уже давно удален, например). Ситуация усложняется если в проект приходят новые люди. Так как С++ поощряет выстрелы себе в ногу, дедлоки становятся реальной проблемой.
Я как-то потратил некоторое время пытаясь сформулировать правила, по которым можно писать "бездедлочные" приложения на плюсах. Свелось к тривиальному (потом про это). Думал про статический анализатор, который бы проверял код на потенциальные дедлоки, но сложность (в том виде в котором к ней заставляют подходить синхронизационные примитивы предоставляемые тем же posix) проблемы оказалась велика. В Microsoft DDK есть забавный софт, использующий движок SLAM, по которому написана куча whitepapers, где умные люди пытаются строить математическую модель безглючного софта (точнее, позволяющую детектить глюки в софте с всего порядка 10% ложных срабатываний). Но SLAM используется только для анализа кода драйверов на достаточно небольшом объеме кода.
Короче говоря, я на текущий момент не придумал ничего умнее примерно следующего
1) (очевидное) не делать мьютексов там, где можно обойтись незамороченным lock-free
2) объекты на стадии многопоточной работы (инициализация вполне может быть, и в идеале должна быть однопоточной) обращаются друг к другу только в одном, заранее известном направлении (получается граф, который нигде не замкнут)
3) любые обратные связи (ошибка в рабочем треде объекта, например) должны строиться через очередь сообщений, обрабатываемую асинхронно в основном рабочем потоке принимающего объекта
Потому что достаточно проблематично сделать дедлок в типичном кейсе, где один пишет, другой - читает. Таким образом, исключается возможность стандартной ошибки, когда, например, объект-менеджер дает команду объекту-исполнителю, в то время как объект-исполнитель репортит ошибку объекту-менеджеру (я неоднократно за годы натыкался на различные производные этого кейса).
Есть другой достаточно забавный подход, который в принципе похож, я его наблюдаю достаточно давно в соседнем отделе. Там просто не пишут многопоточный софт, эти ребята пишут на Objective-C и специально выпилили многопоточку, заменив главный loop программы на libev. Если им что-то нужно делать одновременно - они запускают другой или еще один процесс и общаются с ним через ZMQ. Тоже, в принципе, решение. Не без минусов, но принцип тот же. И гораздо более утойчиво к текучке на проекте, by design заставляет людей писать без дедлоков. Но на С++ писать таким образом я бы не хотел.
Параллельно меня забавляет ситуация с опытом по созданию многопоточных приложений среди С++ программистов, я неоднократно объяснял и видимо буду это на собеседованиях спрашивать. Но практически никто без подсказки не пользуется средствами языка для минимизации количества мьютексов.
Взять тот же пример объектом-менеджером и объектом-исполнителем. Объекту-менеджеру нужно знать статус объекта исполнителя, какую-нибудь статистику, которую удобно выводить в статус приложения. Статистика стоит из POD'ов каких-нибудь. Чтоб усложнить задачу - пусть там будет парочка string'ов. Что делает разработчик? Разработчик делает мьютекс, который лочится в момент изменения переменных статуса (в рабочем потоке) и в момент чтения из них (по запросу менеджера). Собственно вопрос - как избавиться от этого мьютекса (не жертвуя consistency данных и не заменяя все на POD'ы) используя средства STL или BOOST? (кстати, что характерно, человек на хабре, вещающий про lock-free для C++, говорит что не имел еще опыта с boost).

(gdb) thread apply all bt

выводит колстеки для всех тредов в gdb
удобно сразу в тикеты закидывать