В последние годы REST (REpresentational State Transfer) стала стандартной архитектурой при дизайне веб-сервисов и веб-API.

В этой статье я покажу вам как просто создавать RESTful веб-сервисы используя Python и микрофреймворк Flask.

Что такое REST?

Характеристика системы REST определяется шестью правилами дизайна:

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

Вступление

Это III часть цикла статей, посвященных написанию плагинов для XBMC с собственным интерфейсом. В предыдущих частях (часть I и часть II) я рассказал об основных принципах создания интерфейса плагинов XBMC и дал несколько простых примеров. В этой части я хочу совсем кратко рассказать о различных API для взаимодействия с XBMC, продемонстрировать написанный мною микро-фреймворк, упрощающий компоновку интерфейса.

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

А вот как правильно настроить систему для работы с HDD и SSD знают далеко не все.

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

Жизнь мальчиков с математическими способностями в атомных городах была предопределена — школа с пятерками по алгебре и геометрии, мех-мат столичного университета, возвращение в систему, квартира через год, кандидатская степень в 40 лет, ВАЗ 2103 к пятидесяти годам, звание доктора, гараж, шесть соток, четыре квадратных метра.

Бесконечные размышления о математическом моделировании ядерных взрывов разрывали мальчикам мозг. Мозг можно было отвлечь тремя способами — алкоголем, азартными играми и спортом. Секс и музыка помогали не всегда.



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

Приветствую, уважаемые хабражители.

Мой опыт, которым я хочу с вами поделиться, должен оказаться полезным для всех пользователей ноутбуков, хотя мой частный пример — MacBook Pro.

После покупки сего агрегата, с порядковым номером в линейке: 6.1, я ожидал невиданных ранее скоростей, но, увы, предательская каруселька перегрузки, на месте курсора > появлялась достаточно часто, заставляла себя ждать, мучила вопросом «как так?!» при этом скорость загрузки тотально укомплектованной операционной системы составляла примерно 2+ минуты, с загрузкой 5-и приложений (различной тяжести) на автозапуске.

Такие показатели + периодические подвисания оказались досадным и обидным заключением, ведь под капотом процессор i7 / 4Gb DDR3 / 5 Series Chipset с возможной скоростью обмена данными в 3 гигабита.

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

Проблема

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

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

Представляем вашему вниманию доклад Владимира Климонтовича, сделанный им на конференции Application Developer Days, в котором он поделился своим опытом обработки ОЧЕНЬ БОЛЬШИХ объемов данных, и использование для этого NOSQL-подходов, в частности Apache Hadoop.



Ниже представлены текстовая версия доклада + видео + аудио и слайды презентации. Спасибо belonesox за работу над подготовкой материалов доклада.

Объем данных, генерируемый и собираемый современными научно-исследовательским центрами, финансовыми институтами, социальными сетями, уже привычно измеряется петабайтами. Так в дата-центрах Facebook хранится уже более 15 млрд. изображений, нью-йоркская фондовая биржа NYSE создает и реплицирует ежедневно около 1 Тб данных, Большой адронный коллайдер получает около 1 Пб данных в секунду.

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

Платформа Hadoop, которая, в принципе, успешно решает проблему Big Data для полу- и неструктурированных данных, в своем «чистом» виде предъявляет значительные требования как к квалификации администраторов Hadoop-кластера, так и к первоначальным финансовым затратам на аппаратное обеспечение такого кластера.

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

Непрерывный рост данных и увеличение скорости их генерации порождают проблему их обработки и хранения. Неудивительно, что тема «больших данных» (Big Data) является одной из самых обсуждаемых в современном ИТ-сообществе.

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

Одним из самых известных и обсуждаемых проектов в области распределенных вычислений является Hadoop — разрабатываемый фондом Apache Software Foundation свободно распространяемый набор из утилит, библиотек и фреймворк для разработки и выполнения программ распределенных вычислений.

Мы уже давно используем Hadoop для решения собственных практических задач. Результаты нашей работы в этой области стоят того, чтобы рассказать о них широкой публике. Эта статья — первая в цикле о Hadoop. Сегодня мы расскажем об истории и структуре проекта Hadoop, а также покажем на примере дистрибутива Hadoop Cloudera, как осуществляется развертывание и настройка кластера.

Осторожно, под катом много трафика.

В данной статье будет по шагам разобран процесс создания небольшого кластера Hadoop для опытов.

Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X), либо описывают только настройку в режиме single mode/pseudo distributed mode и лишь частично fully distributed mode. На русском языке материала практически нет вовсе.

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

Всем кому интересно, прошу пожаловать по кат.

Здравствуйте!

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

О том, что спрашивают на собеседовании у C++ программистов, а также об ответах на эти вопросы и пойдет речь в данном посте.

Ничего не предвещало беды, как вдруг в 2 часа ночи раздался телефонный звонок.

— Алло, милый! У меня youtube не работает!
— Прекрасно, иди спать!
— Нууу! Там новая серия вышла!
— Завтра всё сделаю!
— Ну Заяя, нуууу!
— Ладно! Ладно! Сейчас.
…

Из этого поста вы узнаете ответы на следующие вопросы:
Как спасти свою милую от стресса в 2 часа ночи? Как вернуть доступ к youtube.com, если ваш провайдер его заблокировал? Как быстро поднять VPN и настроить клиентские устройства (Android, Windows, Debian, dd-wrt) для работу с ним? Как безопасно серфить интернет на открытых точках доступа? Как заработать карму в глазах своей возлюбленной? Если вам это интересно, добро пожаловать под кат!

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

Введение.

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

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

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

Не так давно была опубликована статья про ICQ на Python, которая меня подтолкнула развить тему, правда в несколько другом направлении. Несколько лет назад у меня были трудности с домашним интернетом: доступ только в локальную сеть, из связи с внешним миром только ICQ и локальный Jabber сервер; никакой другой возможности попасть наружу не было. В результате чего родилась идея туннелировать HTTP трафик в XMPP.

Для краткости, введем обозначение «нестандартные» — под этим термином будем далее подразумевать такие модули, которые содержат в себе файлы, отличные от *.py. К примеру это могут быть библиотеки (*.pyd), картинки, иконки, и т.д.

Первая проблема состоит в том, что практически все сборщики бинарных «дистрибутивов» python-приложений, такие как py2exe, bbfreeze, cx_Freeze, и другие, забирают из таких модулей только *.py файлы. Вторая проблема возникает со сложными namespace-модулями, такими как ETS — часто сборщик не может правильно разобрать все их внутренние зависимости.

Конкретно в моем случае камнями преткновения оказались все модули ETS (mayavi, chaco, и т.д.), m2crypto, vtk, h5py, matplotlib и несколько других (вообще, как выяснилось, таких модулей очень много).

Я попробовал протестировать разные сборщики и поначалу остановился на cx_Freeze, т.к. он единственный умеет более-менее правильно импортировать ETS «из коробки». Однако, его оказалось недостаточно: он не смог справиться с другими нестандартными модулями, а также по ряду других причин (к примеру, мне так и не удалось скрыть окно консоли, поставить кастомную иконку, и пр.). Конечно, там есть механизм «рецептов» (совсем не документированный), который даже работает, к примеру, для matplotlib, но хотелось более универсального и простого решения, чем писать подобный рецепт под каждый модуль.

В итоге я остановился на py2exe, т.к. с ним удалось решить все вышеназванные проблемы. Поскольку на это ушло довольно-таки значительное время, то хочу с вами поделиться — может кому тоже понадобится.

Введение

Странно, но поискав на Хабре упоминания текстового редактора Sublime Text 2 я почти ничего не нашел. Спешу исправить положение и рассказать хабраюзерам об этом прекрасном инструменте. Вначале очень коротко расскажу о том чем же он так хорош, потом напишем простой но полезный плагин.

Цель статьи рассказать о своем поиске «идеального» редактора для python кода, о том почему выбрал emacs и кратко о том как я его (emacs) настроил для работы с python.

Небольшая предистория: Разработкой на python я занимаюсь уже более двух лет и все это время пытался подобрать оптимальный редактор. Что я только не использовал за это время — mcedit, nano, gedit, netbeans, eclipse, а также некоторые другие платные варианты (демо версии). Но всегда чего то нехватало, где то автокомплита, где то подсветки, где то банально неудобно. Какой то период (около 10 месяцев) использовал Eclipse, но его прожорливость в ресурсах, зависания доводили до белого каления. Когда ошибки eclipse мне окончательно надоели, я начал поиски такого редактора который стал бы отличным помошником в работе.
Вооружившись google начал искать «идеальный» редактор.

Небольшой видеоролик про редактирование кода в vim.
Краткое содержание.
1. Использование аббревиатур.
2. Плагин MRU
3- Плагин tagbar
Сделано с помощью свободного редактора OpenShot — для изготовления видеороликов в домашних условиях он оказался вполне пригоден.

http://youtu.be/eagC7PcGcCk



P.S. В комментариях советуют массу плагинов. Но их такое количество разных, что если у кого-то есть желание написать про них-я не против. Но моё время ограниченно и вынужден ограничиться самым, на мой взгляд, важным.

Наверное всем, кто хоть раз интересовался Python, известно про GIL — его одновременно и сильное и слабое место.
Не мешая однопоточным скриптам работать, он ставит изрядные палки в колеса при многопоточной работе на CPU-bound задачах (когда потоки выполняются, а не висят попеременно в ожидании I/O и т.п.).
Подробности хорошо описаны в переводе двухгодичной давности. Побороть GIL в официальной сборке Python для настоящего распараллеливания потоков мы не можем, но можно пойти другим путем — запретить системе перебрасывать потоки Python между ядрами. В общем пост из серии, «если не нужно, но очень хочется» :)
Если вы знаете про processor/cpu affinity, пользовались ctypes и pywin32, то ничего нового не будет.