Приветствую!
Думаю, большинство разработчиков Django слышали о Celery — системе асинхронного выполнения заданий, а многие даже активно её используют.

Около года назад на хабре была довольная хорошая статья, рассказывающая о том, как использовать Celery. Однако, как было упомянуто в заключении, уже вышла Сelery 2.0 (на данный момент стабильной версией является 2.2.7), где интеграция с django была вынесена в отдельный пакет, а также произошли другие изменения.

Данная статья будет полезна прежде всего новичкам, которые начинают работать с Django, и им требутся что-то, способное выполнять асинхронные и/или периодические задания в системе (например очистку устаревших сессий). Я покажу как установить и настроить Сelery для работы с Django от начала до конца, а также расскажу про некоторые другие полезные настройки и подводные камни.

По адресу http://regulation.gov.ru/projects# доступен очередной проект закона о внесении очередных изменений в закона «Об информации, информационных технологиях и о защите информации». Точнее на данном портале сейчас выложено два таких проекта, но нас интересует проект закона от ФСТЭК РФ:



Что же предполагается изменить в методах защиты и кого касаются изменения?

Пришла мне недавно вот такая рассылка от уважаемой компании. Я прочитал, сел и прямо заплакал от того, как гладко. Прямо в дёсны целуют.

У них, может, и так, а у меня немного накипело, простите. Я постарался собрать примеры по последним случаям, когда что-то пошло не так. Естественно, никаких пруфов не будет, и всё дальше — не более чем слухи.



Для начала возьмём отличную связку из полосатого оператора и компании, где прямо в названии указано качество поставляемого железа. Раньше поставка была через российских посредников-интеграторов, потом подписались напрямую, устранили «лишнее звено». Дальше — ярчайший пример экономии средств. Производитель не может согласовать российскому заказчику рублевый контракт. Контракт валютный, а значит все валютные риски, все издержки на операторе. Что было с курсом доллара, вы знаете.

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

И это не всё.

Если вы работаете или только собираетесь поработать с бюджетным учреждением, эта статья (как и весь цикл) может оказаться для вас небесполезной. К вам обратился заказчик с предложением разработать для него некое программное обеспечение (продать/собрать компьютеры, взять на обслуживание офисную технику). И этот заказчик — бюджетное учреждение. На что следует обратить внимание? Чего следует опасаться? Возможно ли как-то минимизировать риски такого сотрудничества? Что такое обещание денег и почему его недостаточно? И причем здесь открытые данные? Если это вас заинтересовало — прошу под кат.

Я хорошо понимаю тех, кому трудно говорить на публике, и довольно долго работал в политике, даже не пытаясь выступать

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

Итак, что же умеет Celery:

• Выполнять задания асинхронно или синхронно
• Выполнять периодические задания(умная замена crond)
• Выполнять отложенные задания
• Распределенное выполнение (может быть запущен на N серверах)
• В пределах одного worker'а возможно конкурентное выполнение нескольких задач(одновременно)
• Выполнять задание повторно, если вылез exception
• Ограничивать количество заданий в единицу времени (rate limit, для задания или глобально)
• Routing заданий (какому worker'у что делать)
• Несложно мониторить выполнение заданий
• Выполнять подзадания
• Присылать отчеты об exception'ах на email
• Проверять выполнилось ли задание (удобно для построения Ajax приложений, где юзер ждет факта завершения)

Заинтересовало? Просим под кат.

Думаю, что сама по себе концепция свободной информации – лучшее, что случалось с нашей цивилизацией после изобретения термоса. Да и до, пожалуй, тоже. Разве что молочное животноводство может поспорить.

Опенсорс – это феномен, который стал возможен буквально несколько лет назад. Сейчас видно, как ПО с открытым кодом эффективно вытесняет с рынка некоторую проприетарщину, и люди вокруг не считают это чем-то особенным. И на том, и на другом рынке есть компании, которые недетски зарабатывают со своих «детищ». В проприетарном сегменте – потому что написали и продают, а в опенсорсном – потому что написали и поддерживают.

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

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

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

Мы много пишем о создании торговых систем и создаем инструменты для их разработки (от API брокерской системы до конструктора роботов внутри торгового терминала). Сегодня речь пойдет о проектировании архитектуры алагоритмической торговой системы — именно этой теме посвящен материал из блога Turing Finance, написанный количественным аналитиком хедж-фонда NMRQL Стюартом Ридом.

В своей статье автор описывает принципы создания архитектуры для трейдинговой системы, которая бы отвечала требованиям ISO/IEC/IEEE 42010 и стандартам описания софта инжиниринговых архитектурных систем. Согласно этим стандартам описание архитектуры должно содержать различные стандартизированные архитектурные подходы и поддерживать связи между конструкторскими решениями и требованиями системы. Мы представляем вашему вниманию адаптированный перевод этой статьи.

Периодически при разработке какого либо проекта требуется сгенерировать данные в таблицах, чтобы потом прогнать по тестам для оценки производительности работы (используются или нет индексы, как долго исполняется запрос при большой выборке и т.д.). Для этого обычно берется реализованная функциональность API (функции) (php, node.js и т.д.) проекта и прогоняются через CLI для заполнения данными таблиц (insert). Неудобство заключается в том, что нельзя это сделать по быстрому.

Для быстрой обработки пакетов требуется обнаруживать битовые шаблоны и быстро (со скоростью работы канала) принимать решения о нужных действиях на основе наличных битовых шаблонов. Эти битовые шаблоны могут принадлежать одному из нескольких заголовков, присутствующих в пакете, которые, в свою очередь, могут находиться на одном из нескольких уровней, например Ethernet, VLAN, IP, MPLS или TCP/UDP. Действия, определяемые по битовым шаблонам, могут различаться — от простого перенаправления пакетов в другой порт до сложных операций перезаписи, для которых требуется сопоставление заголовка пакета из одного набора протоколов с другими. К этому следует добавить функции управления трафика и политик трафика, брандмауэры, виртуальные частные сети и т. п., вследствие чего сложность операций, которые необходимо выполнять с каждым пакетом, многократно возрастает.

Чтобы добиться работы на ожидаемом уровне производительности при скорости канала 10 Гбит/с и размере пакета в 84 байта, процессор должен обрабатывать 14,88 миллиона пакетов в секунду. Оборудование общего назначения было недостаточно мощным для обработки пакетов с такой скоростью. Поэтому в большинстве рабочих сетевых систем обработкой пакетов в каналах данных занимаются контроллеры ASIC и сетевые процессоры NPU. К очевидным недостаткам такого подхода относятся: недостаточная гибкость, высокая стоимость, длительные циклы разработки, зависимость от определенного поставщика. Тем не менее, благодаря доступности более быстрых и дешевых ЦП и программных ускорителей, таких как Data Plane Development Kit (DPDK), можно переложить эту нагрузку на оборудование общего назначения.

Привет, Хабр!

В 2014 году мы совместно с несколькими министерствами и ведомствами дали старт мониторингу трудоустройства российских вузов, результаты которого были опубликованы в 2015 году на портале http://graduate.edu.ru/.

Мониторинг проводился среди выпускников 2013 года (у них было достаточно времени, чтобы найти работу). Сейчас идет работа над мониторингом выпускников 2014 года и мы решили рассказать вам о целях и результатах прошлогоднего проекта. Если вам интересно узнать, как размер зарплаты и успех трудоустройства зависит от вуза, специальности и региона, добро пожаловать под кат.

Как чуден и глубок русский курлык
— Генератор постов

Обработка естественного языка (natural language processing, NLP) — тема, на мой взгляд, очень интересная. Во-первых, задачи тут чисто алгоритмические: на вход принимаем совершенно примитивный объект, строчку, а извлечь пытаемся вложенный в него смысл (ну или хотя бы частичку смысла). Во-вторых, необязательно быть профессиональным лингвистом, чтобы решать эти задачи: достаточно знать родной язык на более-менее приличном уровне и любить его.

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

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

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

Я знаю людей, которые искренне недоумевают по поводу того, что функциональное программирование не очень популярно. К примеру, сейчас я читаю книжку «Из смоляной ямы» (Out of the Tar Pit), в которой авторы после аргументов в пользу функционального программирования говорят:

Продолжаем серию интервью с докладчиками PyCon Russia о Python, их работе и увлечениях. Готовы мини-интервью с разработчиком языка Python Андреем Светловым и программистом из Scrapinghub Александром Сибиряковым.

Под катом — короткое интервью c Армином Ронахером (Armin Ronacher), автором фреймворка Flask, проекта Pallets, одним из основателей Pocoo Team, автором известного шаблонизатора для языка Python Jinja2 и нескольких библиотек с открытым исходным кодом. Сейчас Армин живет в Австрии и работает партнером Sentry и консультантом для Fireteam.

Видео выступления Армина на PyConRu-2014

На самом деле, еще меньше. Основной инструмент для написания такого приложения — Node-RED в Bluemix



Несколько лет назад наша компания разработала инструмент Node-RED. Это open-source сервис, который помогает создавать приложения на модульной основе — нужно просто соединять готовые блоки. В качестве блоков выступают не только программные модули, но и различные устройства, веб-API и онлайн-службы. Для работы с Node-RED нужны базовые знания HTML, CSS и JavaScript. Конечно, чем глубже ваши знания, тем более совершенное приложение можно будет создать.

Сегодня в качестве примера мы покажем, как на основе Node-RED можно создать приложения для анализа твитов заданной тематики в режиме реального времени (первоисточник — англоязычная статья). Тематика (ключевое слово) — не единственный критерий, искать можно и по автору или хэштегу. Но в примере используется именно поиск по ключевым словам. Кроме темы, приложение, которое мы напишем, будет способно оценивать эмоциональную окраску сообщения. Искать будем только негативные твиты определенной тематики. Нужные сообщения будут показываться в течение пары секунд после того, как их кто-то напишет.

Почему корпорации сотрудничают со стартапами? И почему стартапы сотрудничают с крупными корпорациями?

1. Сила перемен
a) «Быстрая рыба поглощает медленную»
«В современном мире не большая рыба поглощает мелкую, а быстрая поглощает медленную», — говорит Клаус Шваб, основатель и председатель совета директоров Всемирного Экономического Форума.

Как показывает опыт последних лет, для создания крупной компании теперь требуется гораздо меньше времени. Если судить по оценке рыночной стоимости, то за пять лет с момента запуска рыночная стоимость компании Facebook увеличилась до 15 миллиардов долларов США (2004-2009гг). За тот же период рыночная стоимость компании Uber выросла до 40 миллиардов долларов США (2009-2014). Вторым показателем скорости роста является время, необходимое для достижения дохода в 1 миллиард долларов США. Для того чтобы достичь этого показателя компании Dell потребовалось 9 лет (1984-1993), Office Depot — 5 лет (1986-1991), а Groupontook только 2 (2008-2010). Если говорить кратко, то маленькая рыбка может довольно быстро вырасти в огромную акулу и поглотить вас.

б) «Если вы сами не придумаете нечто, что разрушит вашу компанию, это сделает кто-нибудь еще»

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!