Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Треды, или цепочки писем в почте, — одна из фич, на которые у гиков и массовой аудитории полярные взгляды. Гики активно ими пользуются; обычные пользователи, как показывают наши опросы, относятся к ним скорее настороженно. Во-первых, непривычно, во-вторых, люди опасаются, что не смогут сориентироваться в цепочках. Когда мы реализовывали треды в веб-версии Почты Mail.Ru, мы помнили об этом челлендже — и нашли, как нам кажется, максимально удобный и интуитивно понятный алгоритм группировки, который будет удобен и гикам, и менее продвинутым юзерам. За основу в работе над мобильными тредами мы взяли систему, разработанную большой Почтой, так как мы не хотели запутать пользователей и делать разную логику. Наша задача с точки зрения продукта заключалась в том, чтобы и веб-треды, и мобильные треды работали для пользователя одинаково. Но многие вещи пришлось переделывать с учетом офлайн-работы. О том, как мы сделали в Android-приложении Почты Mail.Ru цепочки, где письма не теряются даже при сбоях в сети, я расскажу в этой статье (о том, как сделали то же самое в iOS-приложении, расскажем в одном из следующих постов).

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



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

Яндекс.Метрика работает с 2008 года — более семи лет. Каждый раз изменение подхода к хранению данных было обусловлено тем, что то или иное решение работало слишком плохо — с недостаточным запасом по производительности, недостаточно надёжно и с большим количеством проблем при эксплуатации, использовало слишком много вычислительных ресурсов, или же просто не позволяло нам реализовать то, что мы хотим.

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

Проекты, в которых возникала данная задача:

• складской учет
• учет объектов недвижимости
• документооборот

Первый мой опыт был с MS Office, но позже возникла необходимость в разработке кросс-платформенных решений, посему выбор пал на OpenOffice. Т.к. в большинстве случаев нужно было формировать таблицы, то был выбран OpenOffice Calc.

Понадобилось мне однажды у себя в проекте реализовать работу с файловым хранилищем с использованием HTTP REST API. Проект разрабатывается на python, к тому же уже был реализован http-клиент с использованием библиотеки httplib2, поэтому было решено расширить функциональность http-клиента и работать с файловым хранилищем через туже библиотеку. Проблема возникла при загрузке файлов на сервер. Первый PUT запрос выполняется, далее все последующие запросы отказываются выполняться — 500 Internal Server Error.

Смотрю Wireshark'ом выясняется что после первого запроса сервер посылает в заголовках ответа connection: keep-alive и следом через 5 секунд закрывает соединение. Всё просто — это таймаут keep-alive установлен на сервере.



А вот как это выглядит на клиенте:

Примечание переводчика: В нашем блоге на Geektimes мы рассказываем о работе на фондовом рынке, описываем то, как на него влияют различные технологии, а также разбираем ситуации, которые помогают лучше понять устройство индустрии финансов. Сегодня мы представляем вашему вниманию первую часть адаптированного перевода лонгрида Bloomberg об истории Тома Хейса, бывшего трейдера банка UBS, удачливого «Человека дождя» фондового рынка, который оказался в центре скандала и получил 14-летний тюремный срок за манипулирование ставкой LIBOR. Важно: материал достаточно объёмный, поэтому на его прочтение уйдет определенное время.



В безлюдном торговом зале в здании токийского отделения банка UBS Том Хейс сидел, уставившись в один из восьми мониторов напротив него. Мятый воротник, бледное уставшее лицо и волосы, взъерошенные от привычки теребить их во время размышлений – британский трейдер был растрепан сильнее обычного. На календаре было 15 сентября 2008 года, и, как он вспоминал позднее, все выглядело так, будто наступил конец света.

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

Добрый день.
Изначально я не планировал публиковать этот пост на GT, но обратил внимание, что книга пользователя ragequit «Проект “Око”» получила в целом положительные отзывы, и понял, что мое творчество тоже может быть кому-то интересно. Заранее прошу прощения у тех, кого фантастика не интересует, за то, что этот пост попал в вашу ленту. Что касается меня, то буду благодарен тем, кто прочтет и оставит свои отзывы. Надеюсь, что любителям фантастики эта повесть понравится, и я смогу опубликовать здесь продолжение.

Сам текст под катом.

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

Моя замечательная жена выводит в свет собственный стартап, Inby. Будучи непосредственным участником данной истории, хочу поделиться её опытом с сообществом. Для этого публикую Катину авторскую статью для Хабра (и да будет НЛО ко мне благосклонно):

Привет, меня зовут Катерина, 32 года, раньше занималась журналистикой, маркетингом и управлением проектами, и вот теперь уже 1 год в ИТ, в собственном стартапе. Именно про этот увлекательный год я и хочу рассказать несколько занимательных историй, которые, надеюсь, будут интересны сообществу.

Началось всё с того, что 2,5 года назад я познакомилась с мужем-айтишником, оставила яхтенный бизнес в Черногории, переехала в Харьков и в скором времени собралась в декрет.

Предыстория

Некоторое время назад я загорелся желанием “улучшить” танк из известного набора “Танковый бой”, добавив возможность играть, как «если бы я был водителем танка». Идея появилась после прочтения нескольких статей на Хабре (например здесь: geektimes.ru/post/257528), в них же я нашел, как это можно сделать имея маленький WiFi-роутер и USB-камеру. Решение выглядело подкупающе простым: роутер прошивается специальной прошивкой, к нему подключается камера, танк управляется родным пультом, а видео смотрится в браузере. Быстро собрав прототип, я обнаружил, что видео захватывается в отвратительном качестве. Это было либо 320х240х30, либо 640х480х30. При включении режима 1280х720 в лучшем случае было рваное видео с артефактами, в худшем — его не было вообще. Режим 1920х1080 не работал в принципе. Меня это сильно расстроило, так как на PC камера поддерживала режимы вплоть до 1920х1080х30 и имела аппаратное MJPG сжатие. Моя интуиция подсказывала, что реализация далека от совершенства.

В статье будет кратко описано, как собрать приложение консольными командами и запустить на реальном девайсе и симуляторе без какой-либо надобности открывать xcode для этого.

В общем, стоит начать с того, что в моей компании имеется отдел ios разработки в составе > 10 человек, которые работают над пачкой приложений. Для автоматизации рутинной работы нам пришлось развернуть CI сервер (пока самописный, ввиду особых исторических причин (ну как у всех), планируется миграция на jenkins). К рутинным вещам я отношу — сборку проектов, запуск тестов (если, конечно, вы их пишете), создание ипашек для тестеров и для выкладки в app store. В общем, хотелось чтобы по нажатию кнопочки или по хуку в гите всё это начинало работать. Пока у нас всё работает по нажатию кнопки разработчиком, про гит пока только в планах. В данной статье я только затрону тему компиляции проекта и упаковку его в ipa файла. Функционал запуска проектов на девайсах на стороне CI сервера еще находится в стадии разработки, а вот сам процесс упаковки уже давно в «бою», может кому пригодиться.

Что планируем:

• соберем приложение и запустим на симуляторе
• соберем ipa и запустим на реальном девайсе
• соберем ipa для выкладки на маркет
• немного подэбажим ошибки сборки

Новый тренд на HighLoad++ — множество докладов об использовании оперативной памяти. Слово Константину Осипову, разработчику платформы Tarantool, автору доклада «Что особенного в СУБД для данных в оперативной памяти».

Ты отвечал в MySQL за производительность, как так получилось, что ты решил разрабатывать свою СУБД?

В MySQL я руководил одной из команд разработки сервера, за производительность там отвечали все.

MySQL по многим параметрам был работой мечты, но, к сожалению после того, как мы стали частью Oracle, многое изменилось.

Несколько моих коллег ушли в MariaDB, кто-то основал свою компанию (SeveralNines, FromDual). Я никогда не чувствовал себя «недогруженным», а с уходом многих ключевых разработчиков работа вообще превратилась в марафон по передаче знаний. Сопротивление поглощению, желание начать всё с чистого листа, бунт против медленного принятия решений большой компанией, нежелание по разным причинам уезжать в США, в конце концов, хорошее предложение от Mail.Ru, которому к этому моменту уже было около года — и я ушёл.

Если бы знал, куда ухожу, ещё десять раз подумал бы. Иногда вообще не было веры, что удастся сделать что-то полезное, чем будут пользоваться за пределами Mail.Ru, да и сейчас Tarantool очень далёк пока от «идеальной СУБД».

Привет, Geektimes! Описывать преимущества SSD или твердотельного накопителя над HDD нет смысла – кто ценит быстрый запуск операционной системы, отсутствие шума и низкое энергопотребление, наверняка уже успел обзавестись таким диском. Но на этом приключения с SSD не заканчиваются: подобно автомобилю или даже смартфону данный накопитель требует бережного обращения и ухода. Поэтому периодически за ним нужно следить.

Если вы установите Vector или другой твердотельный накопитель от OCZ вместо HDD (или совместно с ним) на Mac, сделать это можно будет довольно просто – производитель предлагает собственную утилиту SSD Guru, которая позволяет поддерживать диски в надлежащем состоянии (о ней мы уже подробно писали в блоге). Однако и сторонние разработчики не спят – многие давно выпустили на рынок собственные решения, заслуживающие пристального внимания. О них мы и поговорим.

Под катом — перевод статьи опытного разработчика о его опыте практического применения Go. Важно — мнение переводчика может не совпадать с мнением автора статьи.

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

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

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

По долгу работы я примерно 3 года занимаюсь разработкой и поддержкой нескольких проектов, которые используют MongoDB в качестве основной БД, и в этой статье хочу рассказать, почему на мой взгляд с MongoDB далеко не все так просто, как написано в мануалах, и к чему вы должны быть готовы, если вдруг решите взять MongoDB в качестве основной БД в ваш новый модный стартап :-)

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

Фильтры — тема для оптимизаторов всегда актуальная и зачастую довольно болезненная. Львиная доля статей, рекомендаций и прочих разновидностей SEO-ликбеза в Сети посвящена именно искусству правильно выстраивать отношения с поисковиками. Те, кому повезло больше, пишут и читают материалы о том, как избежать санкций; те, кому меньше, — как из-под них выйти с минимальными потерями. Эта статья, как вы уже поняли, будет не из тех, которые рассказывают истории успеха или говорят о мерах предостережения. Мне хотелось бы поделиться личным неудачным опытом работы с поисковиками — описать, как выглядит ситуация изнутри, какие возникают вопросы и сомнения и, конечно, какие шаги имеет смысл предпринимать. Одним словом, приглашаю всех желающих поучиться на наших ошибках!

Привет, Geektimes! Хочу представить свои наработки в исследовании в области искусственного интеллекта.

Spotify — шведский сервис потокового воспроизведения музыки с которым сотрудничают такие компании как Sony, EMI, Warner, и Universal. Сервис Spotify был запущен в октябре 2008 года, сейчас он предоставляет более 30 млн композиций. Многие считают его попыткой повторить успех Napster и легализовать его модель. Шведам все это удалось едва ли не лучше всех в мире.

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


/ фото Sunil Soundarapandian CC