Только что натолкнулся на возможность Postgresql, показавшуюся мне забавной. Для кого "баян" — респект вам, я несколько лет работаю с Postgres и до сих пор не натыкался на такую штуку.

select; без указания полей, таблицы и условий возвращает одну строку. Но у этой строки нет полей:

=> select;
--
(1 row)

Для сравнения:

=> select null;
 ?column? 
----------

(1 row)
=> select null where 0=1;
 ?column? 
----------
(0 rows)

А сможем ли мы создать таблицу из такого "пустого" запроса? Таблицу без полей.

Если вы будете во Владивостоке 3 декабря — приходите на конференцию для разработчиков DevFest!

У нас будут доклады и мастер-классы по Android, машинному обучению, web разработке, Kubernetes и Go; Интересные железяки — Google Home, Android TV, Cardboard, Tango.

Конференция проводится GDG Владивосток при поддержке Google.

Участие бесплатное. Почитать подробней и зарегистрироваться можно на сайте.

Те кто сталкивался с задачами автоматизированного анализа резюме, представляют современное состояние дел в этой области — существующие парсеры в основном ограничиваются выделением контактных данных и ещё нескольких полей, таких как «должность» и «город».

Для сколько-нибудь осмысленного анализа этого мало. Важно не только выделить некие строки и пометить их тегами, но и определить, что за объекты кроются за ними.

Живой пример (кусок XML результата анализа резюме от одного из лидеров области Sovren):

    <EmployerOrg>
        <EmployerOrgName>ООО Звезда-DSME</EmployerOrgName>
        <PositionHistory positionType="directHire">
            <Title>Ведущий специалист отдела развития информационных систем</Title>
            <OrgName>
                <OrganizationName>ООО Звезда-DSME</OrganizationName>
             </OrgName>

Парсер Sovren прекрасно справился с выделением полей. Ребята не зря занимаются этим делом без малого 20 лет!

Но что дальше делать с «Ведущий специалист отдела развития информационных систем»? Как понять, что же это за должность, насколько опыт работы этого человека релевантен для той или иной вакансии?

Неделю назад наш инвестор сообщил, что по ряду причин его доходы сократились и он больше не может финансировать нас в полном объеме. C Августа команду придётся сократить. Для продолжения разработки и продвижения мы ищем дополнительные инвестиции.

За время работы мы сделали два самостоятельных онлайн-проекта, каждый из которых не имеет аналогов на нашем рынке:

• Поисковик вакансий emply.ru
• Сервис скоринга резюме emply.ru

Как часто вам хотелось дописать в запросе к Google параметры похитрей: "… с видом на море", или "… мощностью более 500 л/c", или "… цена не больше 100 рублей"?

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

На подобные запросы могут ответить “вертикальные” поисковики. Хитрость в том, что они работают в чётко очерченной предметной области. Например, ищут только фокстерьеров или только калоши. Зато про эти самые калоши они знают всё и позволяют задать много всяких специфичных параметров.

Мы затеяли разработку как раз вот такой штуки — поисковика по вакансиям. Да не простого поиска по тексту, а поиска с фильтрацией не хуже чем на специализированных сайтах вакансий.

Сегодня мы запустили альфа версию emply.ru — поисковую систему по вакансиям, которая собирает вакансии по всем русскоязычным (пока) сайтам, включая как сайты работодателей, так и доски объявлений.

Использование хранимых функций СУБД для реализации бизнес-логики или её части, всегда было камнем преткновения. С одной стороны баррикад DBA и программисты БД, с другой — разработчики backend.
Рискну навлечь на себя гнев из обоих лагерей, но всё же просуммирую плюсы и минусы и изложу свои соображения о том, когда стоит писать код в хранимых функциях, а когда следует выносить наружу.

Недавно я выложил статью со «скелетом» схемы данных, который можно использовать для создания своих схем PostgreSQL.
Помимо собственно скриптов разворачивания схемы, создания объектов, там были примеры хранимых функций и Unit-тесты на них.



В этой статье я хочу на примере pg_skeleton подробней остановиться на том, как писать тесты для хранимых функций PostgreSQL при помощи pgTAP.

Реляционная базы данных — зверь сравнительно непознанный, и имеет репутацию генератора проблем. Не то, чтобы проблем не существовало, но как и с другими инструментами, чаще всего сложности возникают от неумения их (РСУБД) готовить.
Готовить с одной статьи не выучиться, но одно блюдо сдюжим.

Я постарался выделить скелет, набор скриптов, на базе которого можно делать свои схемы данных PostgreSQL и тестировать их при помощи pgTAP: github.com/C-Pro/pg_skeleton
И в качестве приятного бонуса я прикрутил это дело к Travis, чтобы у вас ещё и CI было уже на старте :)

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

Всем нам иногда хочется попробовать новую идею, запилить какой-нибудь сайтик про манулов, но чтоб обязательно на node.js, хайлоад реди, с мемкешем, монго, фейловером и с претензией на мировое господство. У меня для Вас хорошие новости: благодаря щедрости проклятых западных капиталистов всё это можно получить совершенно бесплатно.

Сравнение с точки зрения разработчика

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