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

Начнем, пожалуй, с истории появления ZooKeeper. Сначала, как известно, в Google написали сервис Chubby для управления своими серверами и их конфигурацией. Заодно решили задачу с распределенными блокировками. Но у Chubby была одна особенность: для захвата локов необходимо открывать объект, потом закрывать. От этого страдала производительность. В Yahoo посчитали, что им нужен инструмент, при помощи которого они могли бы строить различные системы для конфигураций своих кластеров. Именно в этом основная цель ZooKeeper — хранение и управление конфигурациями определенных систем, а локи получились как побочный продукт. В итоге вся эта система была создана для построения различных примитивных синхронизаций клиентским кодом. В самом ZooKeeper явных понятий подобных очередям нет, все это реализуется на стороне клиентских библиотек.

Стоит отметить, что протокол, используемый Zookeeper называется ZAB, ссылки на описания протокола приведены в конце статьи.

Я разобрал всю почту и отправил последнее письмо. Написал родным, передал свои проекты друзьям. Отправив последний твит, я выключил свой ноутбук, телефон и планшет. Через 10 минут начнётся мой «цифровой шаббат», и я в течение месяца не смогу управлять ни одним цифровым устройством.

Со времён Батлерианского Джихада, когда «мыслящие машины» были стёрты с лица большей части вселенной, компьютеры внушали недоверие.
— Мессия Дюны

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

Предлагаю к ознакомлению вольный перевод статьи Джейсона Хатчерса «TDD⁽¹⁾ is ‘canard. Tell it to the Duck» или дословно: «TDD — Утка. Скажи это утке». ⁽²⁾

Автор критикует «ортодоксальный» TDD подход к разработке и предлагает альтернативный.

И, да, в заголовке статьи нет опечатки ⁽³⁾.

Вводная

В СУБД PostgreSQL есть такое интересное техническое решение — перед тем как собственно начать что то менять в файлах самой базы данных СУБД пишет уже переведенные во внутренний формат команды в специальный журнал — Write-Ahead Log, а после успешного завершения транзакции делает в этом журнале пометку. Сделано это было для восстановления после сбоев, но в итоге пытливый ум разработчиков дошел до идеи использовать этот журнал для резервирования и репликации. В принципе логично, все ходы в нём записаны, более того можно не просто восстановить данные из бэкапа, но и восстановить состояние базы на определенный момент времени, прервав проигрывание записей WAL-лога в нужный момент.

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

Возникает логичный вопрос, а нельзя ли сделать проигрывание WAL-логов с понедельника по пятницу, при этом исключив наш «ошибочный» запрос?

В обычной ситуации я ограничился бы вопросом на форум, но у меня было 2 дистрибутива FreeBSD, 10 тарболлов с исходниками PostgreSQL разных версий, 10Гб места на винте, gcc, две относительно незагруженных недели, а также текила, ром, ящик пива и обрывочные воспоминания о синтаксисе языка C. Не то чтобы это был необходимый запас для решения, но раз уж заглянул в исходные коды, то сложно остановиться…

Уже достаточно давно существует всем известная связка Nginx + Lua, в том числе здесь был ряд статей. Но время не стоит на месте. Примерно год назад появилась первая версия модуля, интегрирующего Ruby в Nginx.

Возможно, многие из читателей задавались вопросом, как людям удаётся собирать кубик Рубика 3×3 за 7 секунд. Если даже предположить, что рекордсмену сильно повезло, то таблица мирового рейтинга по среднему из пяти результатов уже не оставляет сомнений: если больше 80 человек в среднем укладываются в 12 секунд, очевидно они что-то знают. В этом кратком обзоре я постараюсь приоткрыть секреты скоростной сборки. Сразу оговорюсь, что после прочтения этой статьи вы не станете чемпионами: здесь приведены только основные моменты и ссылки на более подробную информацию. Кроме того, даже после изучения метода полностью вам потребуются долгие тренировки для достижения хороших результатов. Зато вы получите неплохое представление о том, как это делается, и при желании будете знать, куда двигаться дальше. Я думаю, при достаточной усидчивости после нескольких месяцев тренировок многие смогут достичь среднего результата в районе 30 секунд.

В своем прошлом посте, с анонсом Google Chrome расширения для Likeastore, я упомянул тот факт, что в качестве поискового индекса мы начали использовать ElasticSeach. Именно ElasticSeach дал достаточно хорошую производительность и качество поиска, после которого было принято решение, выпустить расширение к хрому.

В этом посте, я расскажу о том, что использование связки MongoDB + ElasticSeach, есть крайне эффективное NoSQL решение, и о том, как перейти на ElasticSearch, если у вас уже есть MongoDB.

Недавно я познакомился с интересным языком — clojure. Мне сразу понравились ленивые и иммутабельные коллекции, stm, макросы, обилие скобочек и dsl на все случаи жизни.
И я решил попробовать сделать web-приложение, используя только clojure.

Приложение

Было задумано создать простую искалку субтитров, которая:

• каждые 5 минут индексирует новые субтитры на addicted, notabenoid и других сервисах;
• имеет одностраничный web-интерфейс с поиском без перезагрузки страницы;
• показывает в web-интерфейсе количество проиндексированных субтитров и меняет его при появлении новых;
• имеет простое api для взаимодействия с десктопным клиентом.

Радует, что все больше дизайнеров посматривают в сторону от Адоби в поисках инструментов поудобнее, полегче, попроще и подешевле. И выбирать есть что. Сегодня я расскажу про свой процесс создания дизайна сайта в Sketch.app. Надеюсь, какие-то мысли вы позаимствуете у меня, что-то никогда не станете делать так же, а до чего-то придете своим путем. Оставайтесь с нами.

Последняя часть по работе с сайтом в Скетче.

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

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

• оборот в завершившемся году (фактические цифры);
• установленные ранее планы на завершившийся год (для анализа выполнения);
• оборот годом ранее (для понимания динамики);
• прибыльность.

Стандартная столбчатая диаграмма, которую можно на скорую руку построить в Excel, даёт, мягко говоря, не совсем наглядный результат. К примеру, если у бизнеса четыре направления, то на диаграмме появятся 16 рядом стоящих столбцов, и кто-то может с непривычки спутать передовиков и отстающих.
Специалисты, знакомые с R, могут использовать ggplot2 для программного построения нужной диаграммы, например, такой как здесь. Для примера взяты цифры за 2012 год из годового отчета компании Unilever. Плановые показатели не относятся к публичным данным, поэтому пришлось их выдумать из головы, установив, для определенности, на уровне «прошлый год + 5%».
Исходные цифры находятся в Excel и выглядят так (данные в миллионах евро):

Построенная в RStudio диаграмма выглядит следующим образом:

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

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

Конечно, мечта о полноценной коммуникации с компьютером на естественном языке пока еще далека от полноценной реализации примерно настолько же, как и мечта об искусственном интеллекте. Однако некоторые результаты есть уже сейчас: машину можно научить находить нужные объекты в тексте на естественном языке, находить между ними связи и представлять необходимые данные в формализованном виде для дальнейшей обработки. В Яндексе уже достаточно давно применяется такая технология. Например, если вам придет письмо с предложением о встрече в определенном месте и в определенное время, специальный алгоритм самостоятельно извлечет нужные данные и предложит внести ее в календарь.



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

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

Первая часть про прототипы.



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

Один славный малый Matt West c туманного альбиона, промышляющий фрилансом и предпринимательством, предложил нашему вниманию пост: «Как использовать секционные элементы HTML5».
Ниже приводится его перевод.

---

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


Год назад мы отказались от всех публичных счетчиков в пользу закрытых сервисов и собственной инфраструктуры обработки данных. Собирая на Олимпиаде по 10 млн. хитов в сутки, мы нащупали предел доброты Google Analytics, за которым бесплатное обслуживание уже не возможно. Но теперь у нас есть свой лунапарк со сверткой и графиками, поэтому мы можем легко снизить интенсивность использования GA, сохранив за ним только аудиторские функции. О том, как мы собираем данные и как используем их в своей работе – в простыне с веселыми картинками внутри.

Спустя какое время стало ясно, что основная идея Prototype вошла в противоречие с миром. Создатели браузеров ответили на возрождение Javascript добавлением новых API, многие из которых конфликтовали с реализацией Prototype.

— Sam Stephenson, создатель Prototype.js, You Are Not Your Code

Создатели браузеров поступают гармонично. Решение о новых API принимают с учётом текущих трендов в opensource сообществах. Так prototype.js способствовал появлению Array.prototype.forEach(), map() и т.д., jquery вдохновил разработчиков на HTMLElement.prototype.querySelector() и querySelectorAll().

Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаос под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.

Предыдущие части:

Часть 1
Часть 2

Здравствуйте, хабрачеловеки! Не так уж давно вышел релиз PostgreSQL 9.3 и я хотел бы ознакомить Вас с наиболее важными новшествами, касающимися клиентской части, которые, возможно, пригодятся Вам. В этой статье рассмотрено следующее:

• материализированные представления
• обновляемые представления
• триггеры к событиям
• рекурсивные представления
• латеральное присоединение
• изменяемые внешние таблицы
• функции и операторы для работы с типом JSON