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

Демонстрация Hadoop пользователям

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

Знаете, чем я сейчас занимаюсь? Пишу стартовые скрипты для systemd, и это меня бесит.

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

С другой стороны, «было» — это условность. Все мы часто находимся в относительном неведении относительно того, как устроена наша операционная система. А однажды увидев код /usr/sbin/service ты уже не можешь развидеть его. Так же как и пользоваться этим инструментом.

Наверное, нужно вернуться обратно. Чтобы понять, как мы оказались в такой заднице со смесью SysV и systemd, приправленной Upstart.

TL; DR: автор ноет по поводу зоопарка из SysV, Upstart и systemd в современных дистрибутивах Debian/Ubuntu.

Вы не любите кошек? Да вы просто не умеете их готовить! (с) Альф

При проектировании достаточно объёмных реляционных баз данных часто принимается решение об отступлении от нормальной формы — «денормализации».
Причины могут быть разными. От попытки ускорения доступа к определённым данным, ограничений используемой платформы/фреймворка/средств разработки и до недостатка квалификации разработчика/проектировщика БД.
Впрочем, строго говоря, ссылка на ограничения фреймфорка и т.п. — по сути попытка оправдать недостаток квалификации.

Денормализованные данные — слабое звено, через которое легко можно привести нашу базу в неконсистентное (нецелостное) состояние.

Что с этим делать?

В этой заметке речь пойдет о HTTP-кэшировании (перевод) и его использовании совместно с фреймворком Django. Мало кто будет спорить с утверждением о том, что применение HTTP-кэширования — очень правильная и разумная практика разработки веб-приложений. Однако именно в этом функционале Django содержит ряд ошибок и неточностей, которые очень сильно ограничивают практическую пользу от такого подхода. Например, до сих пор актуален баг #15855, заведенный в апреле 2011 года, который может приводить к очень неприятным ошибкам в работе веб-приложения.

Middleware vs. explicit decorator

В Django есть два стандартных способа включения HTTP-кэширования: через активацию UpdateCacheMiddleware/FetchFromCacheMiddleware, либо через декорирование функции представления при помощи декоратора cache_page. У первого способа имеется один существенный недостаток — он включает HTTP-кэширование для всех без исключения представлений (view) проекта, зато второй содержит тот самый баг #15855. Если бы не этот баг, то вариант с использованием cache_page являлся бы более предпочтительным. Плюс, такой вариант хорошо согласуется с важнейшим из постулатов The Zen of Python, что «явное лучше неявного».

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

Каскару, которая кофе, не следует путать с каскарой, которая Rhámnus purshiána — североамериканская крушина. Крушина является весьма жестким слабительным и эффекты употребления могут оказаться весьма неожиданными. Кофейная же каскара довольно редкий напиток, который готовят из сушеной мякоти кофейных ягод. Путаница возникла из-за общего в названии испанского слова "cascara" – «скорлупа», «кора». У крушины как раз используется именно кора. Другие названия каскары — sultana, qishr и buno.
Короче говоря, добыл я упаковку для тестирования и с удивлением понял, что нашел почти идеальный напиток для занятий спортом. Причем кофеина в нем будет очень умеренное количество: исследования показали, что даже при самой крепкой заварке каскары содержание кофеина составило 111,4 мг/л., в то время как на литр сваренного кофе приходится 400-800 мг. Давайте потыкаем палочкой и попробуем приготовить спортивный компот из кофейных сухофруктов.