Сегодня, 29 сентября 2016 года, вышел новый релиз PostgreSQL, получивший номер 9.6. В нём содержится много весьма полезных фич, и нельзя не рассказать о них, тем более что вклад нашей компании в этот релиз существенен. Поэтому в этой статье мы расскажем о тех разработках Postgres Pro, которые вошли в сегодняшний релиз.

В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.

Обычно это расширение используется администраторами баз данных в качестве источника данных для отчетов (эти данные на самом деле являются суммой показателей с момента сброса счетчиков). Но на основе этой статистики можно сделать мониторинг запросов — посмотреть на статистику во времени. Это оказывается крайне полезно для поиска причин различных проблем и в целом для понимания, что происходит на сервере БД.

Я расскажу, какие метрики по запросам собирает наш агент, как мы их группируем, визуализируем, так же расскажу о некоторых граблях, по которым мы прошли.

В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Solomon Golomb (1932–2016)".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

— Наиболее часто используемый математический алгоритм в истории
— Как я встретил Сола Голомба
— История Соломона Голомба
— Регистры сдвига
— Предыстория регистров сдвига
— Для чего нужны последовательности, генерируемые регистрами сдвига?
— Ну и где же эти регистры?
— Клеточные автоматы и регистры сдвига с нелинейной обратной связью
— Полиомино
— Остальная часть истории

---

Наиболее часто используемый математический алгоритм в истории

Октиллион. Миллиард миллиардов миллиардов. Это очень приблизительная оценка того, сколько раз мобильный телефон или другое устройство сгенерировало бит с помощью регистра сдвига с линейной обратной связью максимальной длины. Думаю, это самый используемый математический алгоритм в истории. Автор — Соломон Голомб, скончавшийся 1 мая, с которым мы были знакомы больше 35 лет.

Основой книги Соломона Голомба «Последовательности регистрового сдвига», опубликованной в 1967 году, были его работы 1950-х гг. А ее содержание живет в каждой из современных систем связи. Прочтите спецификации для 3G, LTE, Wi-Fi, Bluetooth или даже для GPS, — и вы найдете упоминания о многочленах, определяющих последовательности, генерируемые регистрами сдвига, которые эти системы используют для кодирования отправляемых ими данных. Соломон Голомб — человек, который создал эти многочлены.

Доброго всем времени суток, уважаемые посетители сайта Хабрахабр. В данной статье я бы хотел рассказать вам о том, что такое диаграмма Вороного (изображена на картинке ниже), о различных алгоритмах её построения (за , — пересечение полуплоскостей, — алгоритм Форчуна) и некоторых тонкостях реализации (на языке C++).



Также будет рассмотрено много интересных применений диаграммы и несколько любопытных фактов о ней. Будет интересно!

Преамбула

Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.

В последнее время публикуется множество советов по оптимизации производительности сайтов. Фразы вроде «DOM работает слишком медленно» или «всегда используйте CSS-анимацию» годятся в виде броских заголовков, но истинное положение вещей содержит различные нюансы.

Представляем статью авторства Пола Айриша и Пола Льюиса из команды Google Chrome о разработанной ими модели оценки производительности сайта. Ее можно с уверенностью назвать User-Centered Performance.

Введение

Когда-то давно я написал для себя ежедневник для ведения дел, заметок и фиксации движения по разным задачам. Сделан он был изначально на связке PHP + Kohana 2 + PostgreSQL. Со временем я переписал все на Yii (первой и тогда единственной версии). Для полнотекстового поиска был задействован встроенный в PostgreSQL движок tsearch2. Много лет я пользовался системой, понемногу ее развивал и пришел к тому, что объем текстов в ней накопился приличный. Поиском приходится пользоваться весьма часто и для повышения его удобства я задумал прикрутить к нему autocomplete из состава пакета JQuery UI.

Изображения и текст принадлежат их авторам.

Анимация элементов в мобильных приложениях — это просто. Правильная анимация тоже может быть простой… если вы последуете представленным в статье советам.

Сегодня кто только не использует CSS 3 анимацию в своих проектах, тем не менее не только лишь все, но мало кто может делать это правильно. Даже описаны так называемые «лучшие практики», но люди продолжают делать всё по-своему. Скорее всего потому, что просто не понимают, почему всё устроено именно так, а не иначе.

Многим известно, что в мобильной версии Safari можно отсканировать свою банковскую карту. Но многие ли разработчики умеют создавать формы, поддерживающие эту возможность?

Готов поспорить, что немногие.

Дело осложняет полное отсутствие документации от Apple по работе этой функции. Но тут есть один момент. Функция сканирования банковских карт является подмножеством автозаполнения — браузерного функционала, давно игнорируемого веб-разработчиками. Понятно, почему они не уделяли ему должного внимания: когда регулярно заполняешь форму тестовыми данными, автозаполнение обычно мешает. Но для наших пользователей это важная функция. В Google выяснили, что при использовании автозаполнения пользователи на 30% быстрее заполняют формы. Так что давайте изучим работу автозаполнения, разберёмся, как создавать формы, поддерживающие кросс-браузерное автозаполнение, и воспользуемся преимуществами новых возможностей наподобие сканирования банковских карт.

Привет, Хабр! Меня зовут Илья Кудинов, и я работаю QA-инженером в компании Badoo. Три года назад я начал посещать различные IT-конференции и рассказывать о процессах и технологиях, применяемых нами при контроле качества. И конечно же, после каждого доклада я общался со слушателями, интересовался, как работают они. В этом деле меня всегда мотивировали отзывы вида «Раньше мы работали вот так, но, послушав твой доклад, мы увидели, как можно сделать лучше», а еще лучше — когда люди не копируют наши приемы, а придумывают что-то сами, иногда даже более интересные варианты. Таких историй у меня накопилось много, и я хочу поделиться с вами некоторыми из них (все имена и названия вымышлены, любые совпадения с реальными лицами являются случайностью). Может быть, что-то из этого поможет вам увидеть направление развития вашего собственного проекта — и это будет самой большой наградой для меня! Разумеется, буду рад после этого выслушать и ваши истории — в комментариях или личных сообщениях.

Расширение pg_variables

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

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

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

Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

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

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

Рис. 0. КДПВ

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

Без анимации сложнее воспринимать резкие и внезапные изменения. Вместе с тем анимация должна быть короткой и ненавязчивой, чтобы не мешать пользователю.

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

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

Здесь я расскажу, как кооперативная многозадачность превращается во враждебную преемптивную.

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

Но, как обычно, есть нюансы. См. код для интела.

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

Всем привет!

Иногда начинающие разработчики не очень хорошо представляют, какую литературу надо читать для серьезного изучения того или иного языка.

Разработка под FPGA (ПЛИС) — это не просто какой-то язык. Это очень объемная область, с огромным количеством подводных камней и нюансов.

В этой статье вы найдете:

• список тем, которые должен освоить начинающий разработчик под FPGA
• рекомендуемую литературу по каждой из тем
• набор тестовых вопросов и лабораторных работ
• классические ошибки новичков (и советы по исправлению)

Добро пожаловать под кат!

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

Что хорошего?

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

Что плохого?

Любой, даже самый сопливый и занюханный выпускник специалитета отдела кадров считает себя настоящим ловцом людских душ и помыслов. Вооружившись медалью за пять лет безупречной отсидки в аудиториях ВУЗов, «навыками» НЛПерцев и «большой красной папкой», такой специалист по подбору персонала будет днями и ночами терроризировать порталы вакансий, препарировать гигабайты резюме и уничтожать остатки нервных клеток соискателей.

В этом топике я попробую вывести некоторые типичные признаки бестолкового «охотника за головами», при первых намеках на которые ваши ушки должны быть на макушке, а ноги на низком старте в направлении выхода. Зачем впустую тратить время и нервы? Работодателям и рекрутерам — на заметку.

Привет хабр!

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

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!