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

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

Чтобы разобраться, как вообще такая клюква возможна, давайте сначала разберёмся, что такое дирижабль.


^{Wikimedia Commons, Hindenburg disaster, 1937}

Сначала посмотрите на картинку. Это катастрофа Гинденбурга в 1937 году. Можно сказать, что именно из-за неё кончилась эра пассажирских дирижаблей. Она ужасна и прекрасна одновременно.

Перевод статьи молодого греческого программиста «Why I bill hourly»

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

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

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

Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?

Приветствую, товарищи!

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

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

Я решил не делить его на отдельные куски — так информацию искать будет проще. Надеюсь что не сильно нарушу тематику ресурса, пусть НЛО нас рассудит.


Flumserberg. Здесь и далее — обычно мои фотографии, которые мне показались более или менее приличными :)

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Потенциально возможное продолжение книги Паттерны проектирования (Элизабет Фримен и другие).

На дворе 2017 год. В компанию, где работает старший разработчик Джо, пришел на стажировку молодой студент Мартин. Он целый год скрупулезно изучал Java по современному учебнику с акцентом на функциональные интерфейсы, лямбда-выражения и прочие новшества.

Сколько памяти занимает 1 миллион целых чисел?

Меня часто донимали размышление о том, насколько эффективно Python использует память по сравнению с другими языками программирования. Например, сколько памяти нужно, чтобы работать с 1 миллионом целых чисел? А с тем же количеством строк произвольной длины?
Как оказалось, в Python есть возможность получить необходимую информацию прямо из интерактивной консоли, не обращаясь к исходному коду на C (хотя, для верности, мы туда все таки заглянем).
Удовлетворив любопытство, мы залезем внутрь типов данных и узнаем, на что именно расходуется память.

Рассмотрены примеры таких конструкций + некоторые очевидные, но не менее опасные конструкции, которых в коде желательно избегать. Статья рассчитана на python программистов с опытом 0 — 1,5 года. Опытные разработчики могут в коментах покритиковать или дополнить своими примерами.

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

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

В этой статье я расскажу, как и почему мы в 2ГИС выбрали второй вариант для построения новой системы, как решали возникающие задачи и какие выгоды от этого получили. Под катом — про Amazon S3, Apache Kafka, Reactive Extensions (Rx), eventual consistency и GitHub, сжатые сроки и невозможность собрать команду необходимого размера из инженеров, использующих один стек технологий.

Многие разработчики приходят в разработку ПО, потому что хотят создавать игры. Не все могут стать профессиональными разработчиками игр, но любой может создавать собственные игры из интереса (а может быть, и с выгодой). В этом туториале, состоящем из пяти частей, я расскажу вам, как создавать двухмерные однопользовательские игры с помощью Python 3 и замечательного фреймворка PyGame.

(Остальные части туториала: вторая, третья, четвёртая, пятая.)

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

Мы реализуем следующие функции и возможности:

• простые стандартные GameObject и TextObject
• простой стандартный Game object
• простая стандартная кнопка
• файл конфигурации
• обработка событий клавиатуры и мыши
• кирпичи, ракетка и мяч
• управление движением ракетки
• обработка коллизий мяча с объектами игры
• фоновое изображение
• звуковые эффекты
• расширяемая система спецэффектов

Не стоит ожидать, что игра будет очень красива графически. Я программист, а не художник, меня больше интересует эстетика кода. Созданный мной дизайн может неприятно удивить. С другой стороны, у вас будут почти неограниченные возможности по улучшению графики этой версии Breakout. Если вы отважитесь повторять за мной, посмотрите на скриншот:


Готовый исходный код выложен здесь.

Количество выходов в интернет с мобильных устройств ежегодно растёт на 2-4% в год. Качество связи не успевает за такими темпами. Как итог, даже самое лучшее веб-приложение обеспечит ужасный опыт, если пользователь не сможет его загрузить.

Проблема в том, что до сих пор нет хорошего механизма управления кэшем ресурсов и результатов сетевых запросов. В своей статье я хочу рассказать как Service Worker (SW) может помочь в решении этой задачи. Объясню в формате рецептов — какие элементы и в какой пропорции смешать, чтобы получить нужный результат, исходя из задачи и требований.

Сейчас в тематических интернетах модно слово «Node.js». В этой небольшой статье мы попробуем понять («на пальцах»), откуда всё это взялось, и чем такая архитектура отличается от привычной нам архитектуры с «синхронным» и «блокирующим» вводом/выводом в коде приложения (обычный сайт на PHP + MySQL), запущенного на сервере приложений, работающем по схеме «по потоку (или процессу) на запрос» (классический Apache Web Server).

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

Итак, задача:
Хочется, чтобы каптчу вводить не приходилось. Хоть если играешь сам, хоть если играет за тебя бот, если ты спишь.
Дополнительное условие: 40 часов времени (ибо паника на корабле).
Желательное условие: установочный файл под Windows.
Ещё одно желательное условие: результат должен занимать не более мегабайта.

Года полтора назад встал вопрос совместимости написанного кода с Python3. Поскольку уже стало более менее очевидно, что развивается только Python3 и, рано или поздно, все библиотеки будут портированы под него. И во всех дистрибутивах по умолчанию будет тройка. Но постепенно, по мере изучения, что нового появилось в последних версиях Python мне все больше стал нравится Asyncio и, скорее, даже не Acyncio а написанный для работы с ним aiohttp. И, спустя какое то время, появилась небольшая обертка вокруг aiohttp в стиле like django. Кому интересно что из этого получилось прошу под кат.

Вторая часть

Введение
Краткий обзор других фреймворков на базе aiohttp
1. Структура
2. aiohttp и jinja2
3. aiohttp и роуты
4. Статика и GET, POST параметры, редиректы
5. Websocket
6. asyncio и mongodb, aiohttp, session, middleware
7. aiohttp, supervisor, nginx, gunicorn
8. После установки, о примерах.
9.RoadMap

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

Сегодня я постараюсь объяснить простыми словами принципы работы 10 самых эффективных data mining-алгоритмов, которые описаны в этом докладе.

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

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

Знакомьтесь: Ceph

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



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

Вы наверняка слышали об OpenStack. Блин, да о нем говорят на каждом более-менее связанном мероприятии. Все кому не лень пропагандируют OpenStack. Модно, молодежно, все уже есть, Open Source, вливайся давай. И вот наслушавшись тонны маркетингового булшита, вы решаетесь: Будем ставить OpenStack!

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

Бытует мнение, что бесконечно можно смотреть на огонь, воду и то, как другие работают, но есть и ещё кое-что! Мы уверены, что можно бесконечно говорить с Сашей goldshtn Гольдштейном о перформансе. Мы уже брали у Саши интервью перед JPoint 2017, но тогда разговор касался конкретно BPF, которому был посвящен доклад Саши.

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

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

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

Сразу предупрежу, что какие-то вещи я мог понять неправильно, какие-то переврать. Если для вас это важно — не читайте этот пост, а приходите на следующую конференцию лично!