Недавно потребовалось мне сделать небольшую прогу под Windows. Раньше мне не доводилось разрабатывать под нее.
Сама программа несложная, написалась относительно быстро. Намного больше времени отъела сборка ее под винду. Понятно, что выбранные инструменты (Python3 + Qt5) не родные, а универстальные, но что потребуется столько времени затратить на сборку, я не предполагал.
Соответственно, хочется поделиться практикой, может кому еще придется стучаться лбом в эту стену.
Под катом выстраданная инструкция как легко собирать PyQt5 приложения в single-file.exe не требующий инсталлятора.

Я давно интересуюсь вебом в реальном времени. На сегодня уже есть ряд библиотек для этого. В этом топике я хочу рассказать про недавно опробованный нами самый простой способ — использование внешнего сервиса Pusher.com.

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

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Билайн достаточно давно купил Корбину, но как-то неспешно интегрировал ее в себя. Видимо, растягивал удовольствие. Поэтому примерно раз в месяц на Хабре появляются статьи про различные проблемы с домашним интернетом Корбины Билайна. То одно сломают, то личный кабинет заглючит. Про один глюк я уже писал - «Живи на яркой стороне 404 ошибки». Когда на само предложение оплатить по карточке система показывала ошибку.

Сегодня возник еще менее приятный баг.

Думаю, многие хабражители видели новую игру в города от Яндекса. Играть можно как с соперником, так и с роботом – Городовым. Нам стало интересно, можно ли победить Городового — то есть загнать его в угол, так чтобы он не смог сделать ход и сдался.
После тщательной подготовки выяснилось, что это не простой Городовой, а самый настоящий Японский Городовой! В его жилах течет кровь самурая: он скорее сделает себе харакири, чем сдастся и позволит вам насладиться победой :)

Этим летом в полку легких веб-серверов на Эрланге прибыло. Roberto Ostinelli опубликовал свою разработку — misultin. Это библиотека для создания легких быстродействующих HTTP-серверов. В этом плане проект напоминает mochiweb, но акцент еще больше сделан на скорость. По тестам автора misultin обгоняет mochiweb примерно на 50-60% при одновременной работе с 100-200 клиентами.
Функциональность пока беднее, но присутствуют базовые вещи для создания сервисов: отправка простых ответов, файлов, поддержка RESTful, удобная отправка ответов по частям (стриминг). Автор планирует далее развивать проект добавлять новые возможности.

Коллеги, возмножно, кто имел дело с данной библиотекой? Какие отзывы?

>-|-|-(°>

Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

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

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

На Хабре достаточно много разработчиков работают с файлами на удаленных хостах. На локальной машине запускается IDE, отладчик, все необходимое, а сами файлы находятся на сервере, где они регулярно бакапятся, автобилдятся, тестируются и так далее. Очень удобный рабочий вариант. Да я сам его использую.
Единственная проблема, доставляющая неудобство — файлы все же находятся на другом компе, и доступ к ним не такой простой и прозрачный как к «своим».
Под катом — как сделать такой доступ максимально удобным. Чтобы он запускался автоматом когда надо, а самое главное — чтобы не запускался, когда не надо!

Если вам поднадоел внешний вид Гнома, то его можно легко разнообразить, например, добавив панель задач в маковском стиле:


(по клику можно увидеть полный скриншот)

Если вы разрабатываете программы на Питоне, то, уверен, вы хорошо знакомы с работой с ним в интерактивном режиме. Это самый простой и удобный способ проверить пришедшую в голову идею, запустить библиотечную функцию, пошагово прогнать какой-то алгоритм и т.п. без создания лишних мусорных файлов. Вобщем питоновская консоль — очень мощная и удобная вещь. У меня постоянно напрашивается сравнение с юникс-шеллом в языке. Если бы не две ложки дегтя в этой бочке меда: команду каждый раз приходится набирать заново, вместо того, чтобы просто нажать стрелку вверх и подправить команду, а также приходится писать много лишнего, что только добавляет опечаток и необходимости повторного набора. Вобщем я хочу как в баше: история + автодополнение.
Я удивлен почему это еще не сделано по умолчанию. Кстати, очень может быть, что это уже реализовано в вашей системе, и вам это совершенно неактуально — тогда можете совершенно смело пропустить эту статью. Возможно это пригодится кому-то другому. На попавшихся мне Macos, Freebsd, Debian и Fedora этого не было.

Замечательная вещь — ассоциативный массив. Самые разные задачи решаются с его помощью легко, приятно и быстро. А как быть когда значение должно принадлежать не одному ключу, а быть «размазанным» на некоторый интервал?
Представьте, что вам нужно сделать программу для составления расписания дежурства менеджеров интернет-магазина. Работа с ним должна была максимально простой, примерно так:

# легко назначить
>>> timetable['08:00' : '12:00'] = 'Иванов'
>>> timetable['12:00' : '16:00'] = 'Петров'

# как узнать кто дежурил в 13:51 ?
>>> print timetable['13:51']
Петров

# легко просмотреть поэлементо полный список
>>> for interval, person in timetable.items(): print interval, person
('08:00', '12:00') Иванов
('12:00', '16:00') Петров

# ...или одной строкой
>>> print timetable
{['08:00', '12:00'] => 'Иванов', ['12:00', '16:00'] => 'Петров'}


Понятно, что собственно сложения ассоциативных массивов (они же хеши, dict-ы и т.п. в разных языках) не существует, т.к. совершенно неочевидно, что оно должно давать. Но иногда удобно иметь простую легкочитаемую операцию, которая бы легко и просто объединяла хеши. Особенно это удобно когда есть ряд хешей и вам нужно оттуда взять несколько ключей с разным приоритетом. Если нет значения в первом, то проверяем второй, если нет и там, то третий, и т.п.
У вас есть 4 хеша global_config, local_config, db_row, user_info
Чуть ниже хабраката я покажу как жуткую конструкцию из 4 строк

values = global_config.copy()
values.update(local_config)
values.update(db_row)
values.update(user_info)

Записать в одну

values = global_config + local_config + db_row + user_info

Когда пишешь многопроцессное приложение на питоне хочется иметь какой-то максимально простой способ мониторинга за работой отдельных процессов. Я сейчас не говорю про детальные аналитические отчеты на 10 страницах, а про получение минимальной информации о здоровьи и работе каждого процесса: чем он сейчас занят, насколько грузит систему, сколько памяти отожрал и т.п. Примерно как nginx или postgres сообщают о себе: одного взгляда в top либо ps достаточно, чтобы понять что и как делает каждый процесс.
Осталось разобраться как это можно сделать в питоне на ОС Linux (на примере Debian и FC).

В питоновском блоге разгорелась дискуссия об оформлении бесконечных циклов, что эстетичнее: while True или while 1<5 :-) Этот топик — мой опыт и рассуждения на тему бесконечных циклов и их реализации в питоне. Звиняйте, что не могу опубликовать в питоновском блоге — поэтому пишу здесь.

На мой взгляд работа с такими циклами зиждется на двух китах: