Уже в момент запуска Яндекс.Диск дал многим разработчиками возможность использовать его в своих приложениях и программах. И обеспечивает это то, что протоколом для десктопных клиентов Диска мы выбрали WebDAV.

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



Сегодня мы хотим рассказать о причинах, которые остановили наш выбор именно на WebDAV и сделали его протоколом для клиентов Яндекс.Диска.

На прошлой неделе Яндекс.Диску исполнился год, и за этот год сервисом успели воспользоваться уже больше 8 000 000 пользователей.

А сейчас мы продолжаем рассказывать о том, сколько усилий понадобилось, чтобы всё это стало возможным. Недавно мы писали о том, как и почему команда Яндекс.Диска выбрала WebDAV для синхронизации десктоп-клиентов с сервером и начала работу над прототипом клиента Яндекс.Диска. Сегодня, как и обещали, — о том, как всё работает с серверной стороны.



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

Написано, т.к. возник очередной холивар в комментариях на тему SQL vs ORM в High-Load Project (HL)

Преамбула

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

• Никогда нельзя реализовать HL-проект на основе только одной манипуляции с ORM
• Никогда не складывайте сложные вещи на плечи БД. Она нужна Вам чтобы хранить инфу, а не считать факториалы!
• Если вы не можете реализовать интересующую Вас идею простыми средствами ORM — не используйте ORM для прямого решения задачи. И тем более не лезте в более низкий уровень, костыли сломаете. Найдите более элегантное решение.
• Извините за издевательски-юмористический тон статьи. По другому скучно :)
• Вся информация взята по мотивам Django версии 1.3.4
• Будьте проще!

И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.

Перевод этой статьи уже есть на хабре, но он ужасен и содержит ложную информацию.

Приветствую, искатели приключений! Путешествуя по территории индексации MongoDB хотя бы некоторое время, вы, возможно, познакомились с таким правилом: если ваш запрос содержит сортировку/порядок (orderby) – добавьте сортируемое поле в конец индекса который используется для запроса.

Во многих случаях когда запрос содержит равенство (то есть поиск конкретного значения, например, {“name”: “Charlie”}) данная мантра бывает весьма полезной.

Запрос

db.drivers.find({"country": {"$in": ["A", "G"]}}).sort({"carsOwned": 1})

Индекс

{"country": 1, "carsOwned": 1}

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

_{Не в совокупности ищи единства, но более – в единообразии разделения.
Козьма Прутков}

Немного воды вначале

Нельзя не заметить, что аспектно-ориентированное программирование с каждым годом берет новые рубежи популярности. На хабре было уже несколько статей посвященных этому вопросу, от Java до PHP. Пришло время обратить свой взор на С/C++. Теперь я в первом же абзаце признаюсь, что речь пойдет не об «настоящих аспектах», но о чем-то, близко с ними связанном. Также рассуждение будет вестись в контексте embedded-проектов, хотя описываемые методы могут применяться где угодно, но именно embedded, это та область, где эффект будет максимально ощутимым. Еще я буду использовать слова «хидер» и «дефайн» для обозначения, соответственно, «заголовочного файла» и «макроопределения». Сухой и академичный язык это хорошо, но в данном случае, мне кажется, все будет проще понять, если пользоваться устоявшимися англицизмами.

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Не секрет, что Python не оптимизирует хвостовую рекурсию. Более того сам Гвидо является противником этого. Но если кому нужно, есть небольшое изящное решение. Под катом…

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

В этой главе сказа про дружбу C++ и Python будет на удивление мало использования Boost.Python. Передача исключений туда и обратно является по сути слабым местом данной библиотеки. Будем обходиться родным API языка Python, а где это возможно использовать Boost.Python.
Тем не менее Boost.Python создаёт окружение, в котором исключения из C++ попадают в Python в виде стандартного RuntimeError, а обратно из Python генерируется исключение C++ типа error_already_set, что означает «тебе что-то прилетело, сходи сам почитай что там». И вот здесь нам как раз будет не лишним использовать C-API языка Python, чтобы вычитать необходимую информацию об исключении и преобразовать в соответствующий класс сообразно логике приложения.
К чему такие сложности? — Дело в том, что в Python, в отличие от C++, кроме текста исключения и его типа приходит ещё и traceback — стек до места возникновения исключения. Давайте немного расширим стандартный std::exception дополнительным параметром для этого stacktrace, а заодно напишем конвертер исключений туда и обратно из классов C++ в классы исключений Python.

Данная статья не является продолжением повествования об обёртках C++ API. Никаких обёрток сегодня не будет. Хотя по логике это третья часть данного повествования.
Сегодня будет море крови, расчленение существующих типов и магическое превращение их в привычные аналоги в другом языке.
Речь не пойдёт о существующей конвертации между строками, нет, мы напишем свои конвертеры.
Мы превратим привычный datetime.datetime питона в boost::posix_time::ptime библиотеки Boost и обратно, да чёрт с ним, мы вообще всю библиотеку datetime превратим в бустовые типы! А чтобы не было скучно, принесём в жертву встроенный класс массива байт Python 3.x, для него как раз ещё нет конвертера в Boost.Python, а потом зверски используем конвертацию массива байт в новом конвертере питоновского uuid.UUID в boost::uuids::uuid. Да, конвертер можно использовать в конвертере!
Жаждешь крови, Колизей?!..

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

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

Данная статья является продолжением первой части.
Продолжаем мучить Boost.Python. В этот раз настала очередь класса, который нельзя ни создать, ни скопировать.
Обернём почти обычную сишную структуру с необычным конструктором.
И поработаем с возвращением ссылки на поле объекта C++, так чтобы сборщик мусора Python его не удалил ненароком. Ну и наоборот, сделаем альтернативный вариант, чтобы Python прибрал мусор после удаления того, что ему отдали на хранение.
Поехали…

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



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

Как известно, в основной реализации Питона CPython (python.org) используется Global Interpreter Lock (GIL). Эта штука позволяет одновременно запускать только один питоновский поток — остальные обязаны ждать переключения GIL на них.

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

Идея свежая, но имеет один существенный недостаток — она не работает…

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

Исторически в Почте Mail.Ru использовался механизм от «большого» Поиска (go.mail.ru); однако для задач поиска по почтовым ящикам такой вариант не был оптимальным ввиду большого потребления ресурсов и относительной сложности в обслуживании. Поиском по почте пользуются около 3% владельцев почтовых ящиков; однако, хотя эта цифра кажется относительно небольшой, ящики этих людей обычно достаточно объемны, и поиск им действительно необходим. Поэтому мы приняли решение написать специализированный поисковый демон, который будет заниматься именно поиском по почте. Основными требованиями к нему стали ограничения по потребляемым ресурсам (размер индекса — не более 3% от размера почтового ящика, среднее потребление оперативной памяти — не более 100 Мб, средняя утилизация CPU — не более 3%) и скорости исполнения запросов (среднее время — не более 200 мс). О том, как он был организован, я расскажу ниже.

Введение.

Python замечательный язык. Связка Python + NumPy + Matplotlib, на мой взгляд, сейчас одна из лучших для научных расчётов и быстрого прототипирования алгоритмов. Но у каждого инструмента есть свои светлые и тёмные стороны. Одной из самых дискутируемых особенностей Python является GIL – Global Interpreter Lock. Я бы отнёс эту особенность к тёмной стороне инструмента. Хотя многие со мной не согласятся.

Если кратко, то GIL не позволяет в одном интерпретаторе Python эффективно использовать больше одного потока. Защитники GIL утверждают, что однопоточные программы при наличии GIL работают намного эффективнее. Но наличие GIL означает, что параллельные вычисления с использованием множества потоков и общей памяти невозможны. А это достаточно сильное ограничения в современном многоядерном мире.

Один из способов преодоления GIL при помощи потоков на C++ был недавно рассмотрен в статье: Использование Python в многопоточном приложении на C++. Я же хочу рассмотреть другой способ преодоления ограничений GIL, основанный на multiprocessing и shared array. На мой взгляд, этот способ позволяет достаточно просто и эффективно использовать процессы и разделяемую память для прозрачного параллельного программирования в стиле множества потоков и общей памяти.

Все более или менее знающие Python разработчики знают про такую жуткую вещь как GIL. Глобальный блокировщик всего процесса до тех пор пока Python выполняется в одном из потоков. Он даёт потоко-защищённость методами сравнимыми с садизмом, поскольку любая неявная блокировка в многопоточном приложении смерти подобна, всё что опиралось на параллельное выполнение, умирает в мучениях, раз за разом натыкаясь на блокировку GIL.
Известно что по сей день из-за этого скорбного факта программисты на C++ используют Python-обёртки по большей части лишь в однопоточных приложениях, а программисты на Python пытаются всех убедить, что им и так неплохо живётся.
Казалось бы, если поток порождён в C++, он не знает ни о каком GIL, используй Python без блокировок и радуйся. Радость разработчика однако закончится уже на втором потоке запросившем область глобальных переменных без блокировки.
Однако есть путь ведущий к светлому будущему!
Этот путь был изначально в таком языке как Perl, он же поддерживается в Си-API языка Python и я ума не приложу почему подобный механизм не включен в один из стандартных модулей Python! Способ по сути сводит использование различных под-интерпретаторов Python в разных потоках, причём используя свой GIL для каждого(!!!) без всякого шаманства и магии, просто последовательно вызвав несколько функций и стандартного набора Си-API языка Python!

По началу я думал что это будет просто перевод одного весьма забавного текста. Но оказалось, что он из рук вон плох, поэтому от него остались только тезисы.

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

1. Никогда не ищите глазами, пользуйтесь функциями поиска. Всегда, всегда используйте поиск, если вы печатаете быстро. Хороший пример — открытие файла в редакторе. Используйте поиск или комплишн (в зависимости от редактора) и вы увидите насколько это быстрее. То же относится к выбору таба/буфера, если редактор не позволяет перейти в нужный буфер — выкиньте его, иначе смотрите в пункт 4. Идеальный редактор работает так — нажимаем кнопочку (в моем случае Ctrl-X + b) и в строке ввода вписываем первые несколько букв открытого в другом табе файла. Завершаем всё нажатием tab и enter. Таким методом я переключаю открытый буфер за 0.2 секунды. Мышью и глазами я переключаю его за 1.4 секунды. Что приводит нас к следующему пункту.

2. Не повторяйте что-либо более 10 раз. Это критическое число для всех разное, для меня оно именно десять. Автоматизируйте. Больше. Чаще, но не увлекаясь глобализмом. Причем не только в коде, в редакторе, в среде, но и в жизни. Нужно разбить 20 куриных яиц? Сделайте коробочку с дырочками и отсекайте острую часть яйца. 11 раз написать триграмматон на заборе? Сделайте шаблон и купите балон с краской. Не забывайте, что клавиатурные шорткаты есть почти во всем софте. Каждый раз когда вы снимате руки с клавиатуры — теряете время.

3. Учитесь скриптовым языкам. Python, Ruby, Perl, Bash, Javascript, CMD, VBasic. Просто хватайте тот, который ближе к вам и пишите-пишите-пишите. Понятно, что выбрать просто, если вы работаете в windows — для вас только CMD и VBasic. Юниксоидам доступно чуть больше, думаю это одна из причин почему гики так активно пересаживаются на Linux. Я знаю, что учиться не легко — но надо. Есть один странный рецепт — попробуйте в течение 2-3 недель работать из консоли. Нет, не надо отказываться от окон и тп — просто откройте окно терминала или cmd и работайте из него, запустив нужный вам скриптовый интерпретатор. И ради бога, никаких far/mc/nc и тп. — ваша цель научиться писать скрипты. После этих 2х недель вы вернетесь к привычной среде с довольно большим знанием о том, как же устроен скриптовый язык. Напомню, для python и ruby есть ipython и iruby. Для perl есть mshell, остальные интерпретируемы сами по себе.

4. Изучите свой IDE настолько, насколько это возможно. В идеале — откажитесь от IDE в пользу хорошего текстового редактора. Я имею ввиду редактора. Например ViM или Emacs. Пользователи MacOS могут использовать и TextMate, однако мне он кажется жалким подобием левой руки (слабой пародией на MicroEmacs). Да, и уверяю вас — оба редактора, и ViM, и Emacs имеют столько возможностей, сколько не снилось любому другому. В то же время оба они прекрасно работают без донастройки, хотя я предпочитаю Emacs. Конечно многие еще помнят что Emacs раcшифровывается как Eight Megs And Constantly Swaping, но 8 метров памяти уже давно перестали быть чем-то из ряда вон выходящим. Окей, вернемся. Выберите редактор. И теперь используйте его везде, где только можно. Вбейте себе в голову — вы используете ТОЛЬКО этот редактор. Потому что достаточно хорошо знать два редактора невозможно. Знатоки утверждают что работая со своим редактором на полную катушку вы получаете буст к производительности в 200-500%. И глядя на Бацека, например, я в это верю. И единственный минус от этого знания только в одном — вы не сможете от этого отвыкнуть.

5. Изучайте технологии и пишите маленькие программки. Выделяйте себе 20-30 процентов времени на ковыряние в новых движках или базах данных. Да, двадцать-тридцать процентов времени. Я знаю что обычно на это выделятся куда меньше — но меня-то не надо обманывать, я ж сам такой был, и хорошо знаю сколько процентов времени программист пишет код. Подвиньте чуть-чуть время, выделяемое вами на чтение LiveJournal и закопайтесь по локоть в Django. Или сядьте и напишите скрипт для накручивания голосов на Хабре. В общем проводите время весело и с пользой. Это сильно помогает отдохнуть на работе не теряя темпа. А главное — это очень неплохо сказывается на структуре вашего кода — теперь вы знаете как и что делают другие.

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