Недавно у меня возникла интересная задача по хранению некоторых данных в рамках сессии работы с БД PostgreSQL (TTL = время жизни единичного коннекта к базе). Изначальный вопрос был таков…
А можно ли вместо вот такой конструкции:

some_procedure1(user_id, param1, ... , paramN);
...
some_procedureX(user_id, param1, ... , paramN);

использовать такую:

set_user(id);
some_procedure1(param1, ... , paramN);
....
some_procedureX(param1, ... , paramN);

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

Пару недель назад в Переславле-Залесском прошла юбилейная, десятая конференция «Свободное программное обеспечение в высшей школе», кратко OSEDUCONF-2015.

Как следует из названия конференции, доклады все крутятся вокруг опенсорса-линукса и образования, иногда с уклоном в чисто научно-технические штуки, иногда в чистый cофт, иногда — в политику. Бывают и зажигательные доклады, и откровенно скучные, глубоко-философские и приземленно-реалистические, доклады конкретно-практические и академические с названием в три абзаца, из которых все равно ничего не понятно, жалобы на жизнь и истории успеха. Open-source разработчики и мейнтейнеры, ректоры и преподаватели ВУЗов, практики из индустрии, чиновники из министерств, ученые разной степени безумности, студенты, набирающие очки для диплома.

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


А под катом краткий обзор и классификация докладов как с последней конференции, так и ретроспектива-классификация за три последних года — не бойтесь кликать, там только компактный текст, а все видео — ссылками.

В настоящее время существует не так уж и много open-source САПР. Тем не менее, среди САПР для электроники (EDA) есть весьма достойные продукты. Этот пост будет посвящён моделировщику электронных схем с открытым исходным кодом Qucs. Qucs написан на С++ с использованием фреймворка Qt4. Qucs является кроссплатформенным и выпущен для ОС Linux, Windows и MacOS.

Разработку данной САПР начали в 2004 году немцы Michael Margraf и Stefan Jahn (в настоящее время не активны). Сейчас Qucs разрабатывается интернациональной командой, в которую вхожу и я. Руководителями проекта являются Frans Schreuder и Guilherme Torri. Под катом будет рассказано о ключевых возможностях нашего моделировщика схем, его преимуществах и недостатках по сравнению с аналогами.

На StackOverflow часто задают вопросы, подробно освещённые в документации. Ценность их в том, что на некоторые из них кто-нибудь даёт ответ, обладающий гораздо большей степенью ясности и наглядности, чем может себе позволить документация. Этот — один из них.

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

Всем, доброго времени суток.

По сути, к реализации этой маленькой автоматизации меня сподвигла лень.

Собственно, с чего все началось.

У меня есть ноутбук с установленной gentoo, и i3wm оконным менеджером. Так же есть несколько мониторов(дома, на работе и т д). Разрешения на всех мониторах разные, способы подключения тоже (VGA, HDMI, DVI) разные. Активно, использую первые два.

Раньше, при подключении второго монитора, приходилось вызывать команды, которые инициализировали этот самый монитор. Запуск команды с автоматическим ключом, не всегда давал, желаемого результата(не угадывал разрешение).

xrandr --auto

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

--mode

И хотя, в xrandr для каждого монитора у меня есть несколько вариантов разрешений, есть одно (максимальное для данного монитора, которое удовлетворяет), но на каждом мониторе оно разное(так как сами мониторы разные).

Потому пришлось искать решение…

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

UPD: схема заменена на вариант с контейнерами из С++11, соавторы — в комментариях ниже

Здравствуй, Хабр!

Осталось несколько дней до дня программиста и, конечно, в эту 13-ю пятницу, многие из пользователей хабра буду отмечать этот праздник. Буду отмечать и я.

По случаю профессионального праздника, мне бы хотелось поделиться с хабравчанами рассказом о своём небольшом кулинарном проекте, который удалось реализовать буквально накануне. Думаю из названия поста уже стало понятно, что это — коктейли для программиста. Кажется, до этого момента IT и миксологию еще никто не пытался объединить, а потому у меня есть некоторая надежда на успех моего начинания.

Все началось вот с чего: моя супруга увлекается кулинарией и ведет небольшой кулинарный блог. В прошлом году на мой день рождения она пригласила к нам в гости на кухню настоящего бармена из барного startup-проекта БАРаДОМа.нет. С момента знакомства с Артёмом (барменом который превратил мой день рождения в домашнюю барную вечеринку), у меня появилась идея: найти рецепты (или придумать самим) коктейлей, которые бы вписались в IT-тематику.

Итогом нескольких дней активной переписки с Артёмом стала вот такая небольшая коктейльная карта:

• Ruby
• Python
• Суровый Perl
• JMP (aka Assembler)
• Profit!
• Epic fail
• Memory leak

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

В продолжение темы Контроллер «Virt2real», или просто — Виртурилка

Итак, первый серьёзный (по нашим меркам) тираж железок успешно прошёл приёмку нами на заводе и официальную растаможку в России. Процент брака основных плат зашкалил за нуль и составил 0.5%. Очень неплохо, мы рассчитывали в худшем на 5-6 процентов брака. К слову, есть мысль отдать одну бракованую железку BarsMonster на вскрытие проца (если он заинтересуется, само собой).

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

В общем, железки уже у нас на руках, теперь начинается самое интресное

Задача:

Собирать информацию о действиях пользователя (аудита) в консоли Linux, а именно вводимых им командах и выводимой на экран информации.

Предлагаемое решение:

screen по умолчанию для всех пользователей в Linux с логированием

Необходимые условия:

1. Полное логирование всех пользователей в консоли, включая вывод информации процессами, чтобы можно было оценить почему пользователь принял то или иное решение
2. Без возможности отключения логирования
3. Раз уж выбрали screen — максимально используем его возможности (открытие новых окон, отключение по ^a + d, оставляя рабочие процессы запущенными и другие удобства)
4. Максимальное удобство — не должно быть каких-либо несовместимостей с приложениями
5. В случае использования пользователями, не знакомыми с screen — сделать работу максимально знакомой и близкой к обычной командной оболочке (shell)

My God, it's full of stars!

Arthur C. Clarke

Кто из нас в детстве не мечтал «бороздить просторы вселенной», как капитан Пикард, прогуливаться по неизведанным планетам далёких миров, встречать рассветы двойных или тройных звёзд, погружаться в атмосферы газовых гигантов, ронять корабли в чёрные дыры? И я тоже не исключение. Конечно, частично эту мечту воплощали книги, фильмы и «Элит»-ные игры. Но вся романтика в них разрушалась банальными купи-продай и «пиу-пиу» в «жидком» космосе на скоростях самолётов времён первой мировой войны. Да и тем немногим виртуальным миркам не хватало свободы, детальности и масштабов реальной вселенной.

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

Но вот, чуть больше года назад, я совершенно случайно наткнулся на вселенную Space Engine, и она просто взорвала мне мозг и размазала его по полу своим масштабом и невероятной детализацией.

David Drysdale, Beginner's guide to linkers (http://www.lurklurk.org/linkers/linkers.html).

Цель данной статьи — помочь C и C++ программистам понять сущность того, чем занимается компоновщик. За последние несколько лет я объяснил это большому количеству коллег и наконец решил, что настало время перенести этот материал на бумагу, чтоб он стал более доступным (и чтоб мне не пришлось объяснять его снова). [Обновление в марте 2009: добавлена дополнительная информация об особенностях компоновки в Windows, а также более подробно расписано правило одного определения (one-definition rule).

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

g++ -o test1 test1a.o test1b.o
test1a.o(.text+0x18): In function `main':
: undefined reference to `findmax(int, int)'
collect2: ld returned 1 exit status

Если Ваша реакция — 'наверняка забыл extern «C»', то Вы скорее всего знаете всё, что приведено в этой статье.