Python: вещи, которых вы могли не знать

Э, ребята, давайте понимать, переопределять __class__ это не более чем шутка.

Python: вещи, которых вы могли не знать

а вот как вам такое? :)

class Worm:
    def creep(self):
	print("i am creeping")


class Butterfly:
    def fly(self):
	print("i am flying")


creature = Worm()
creature.creep()
creature.__class__ = Butterfly
creature.fly()

Изящный вебсервер на Go (Graceful Restart)

Спасибо что поделились рецептом. По ходу чтения кода появился вопрос.
Что происходит в следующей строчке кода?
listener2 := listener1.(*net.TCPListener)
Не могу понять что мы имеем в listener1 на этот момент.
Спасибо.

Знакомство с Go — пишем граббер веб страниц с многопоточностью и блудницами

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

Обработка ошибок в стиле panic/defer на Python

Прям очень красиво получилось.

Релиз proxmox 3.1 и первый шаг к платному репозиторию

OpenStack?

Редактирование конфигов в Python

давно не видел такого хорошего Python кода. очень приятно.

Нагрузочный тест c помощью Go

Отличная статья!
Продолжение приветствуется категорически.

Простой сайт на D

Отсутствие daemon режима, по моему скромному мнению,
для подобных вещей является скорее современной тенденцией.
Создавать daemon-ов и управлять ими это работа,
например, для upstart script, с которой он прекрасно справляется.

Обязательно посмотрите в сторону upstart — несколько
строчек в конфиг файле который лежит в /etc/init
делают удивительные вещи.

Использование RESTful контроллеров для ресурсов AngularJS

Спасибо за понимание. Больше хороших API!

Использование RESTful контроллеров для ресурсов AngularJS

> Помогает чем?
Помогает поддерживать API в постоянно изменяющихся условиях.
Смотришь на решения которые принимал несколько лет назад и
видишь — такой подход хорош. С точки зрения клиенской библиотеки
и с точки зрения структуры исходного кода. Позольте объяснить подробней.

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

Ведь если нужно изменить одно поле — делаем PUT, не так ли?

> Речь о параметре в URI, или вообще в запросе?
В запросе. Хотя даже /item/id/do-something я тоже стараюсь избегать.
Наверное потому что потратив много времени в борьбе с чужими API
и на разработку своих, считаю Computation REST наиболее близким к идеалу.

Но нужно понимать что правило «don't do POST with action» это не догма, а способ
сделать жизнь простого разработчика проще. Который работает для меня.

PS. www.erenkrantz.com/CREST/

Использование RESTful контроллеров для ресурсов AngularJS

> POST /api.cfm/messages/8?action=archive
Я читал где то, что если Вы делаете POST и передаете
параметр action это почти всегда плохо. И в целом
уже несколько лет такое правило мне здорово помогает.

Лучше делать POST /api.cfm/archive и в теле запроса message=8
В ответ сервер возвращает ID транзакции по которому можно
опрашивать состояние операции.

Platform-as-a-Service: итоги 2012 года

openshift.redhat.com/community/get-started/ruby-on-rails

Установка и настройка KVM под управлением CentOS 6

Отличная статья.
Единственное что я бы добавил — работа с libvirt не из под root.
wiki.libvirt.org/page/SSHPolicyKitSetup

Рэй Курцвейл стал техническим директором Google

Вы наверное в институте не учились, поэтому не знаете следующего: ;))
C XX века известно, что некоторые навыки которые в течении жизни приобретает мужчина, могут быть переданы его сыну через Y хромосому.

PS. Лично я не дал бы ломаного цента, за этот и другие научные факты
связанные с эволюцией. Все так туманно.

Hyper-V 3.0 против… Или суицидальный холивор

На первой картинке в таблице есть строка Кластер. Где максимум узлов 64.
Где можно почитать что это значит — «кластер»?

Создание умного дома и разработка своего протокола

«не думаю, что по этой сети будет передаваться большой объём данных.» — сильное, и возможно не верное допущение.

free-lance.ru Девятый день

С правилом Паретто часто допускают одну ошибку. Говорят, давайте будем обслуживать 20% клиентов котороые приносят 80% прибыли. Остальных — в сад.
Однако через короткое время оказывается — чтобы были высокоприбыльные клиенты должны быть и те, другие 80%, низкоприбыльных. Жизнь не стоит на месте. Сегодня тебе клиент принес 10, а завтра 1000. Но обслуживать ты его должен хорошо в любом случае.

Хорошая клиент-серверная архитектура

Интересно. Хотя это ошибки валидации, количество которых предсказать трудно.
И, цитируя вашу цитату — 5xx Server Error The server failed to fulfill an apparently valid request —
ключевое слово apparently valid. А здесь есть сомнения что запрос валидный. То есть с точки зрения формы он валидный, но содержание подкачало.

Наверно ближе всего 400, что для меня значит — не нужно повторять этот запрос.
Но тоже есть сомнения.

Так что пока возвращаю статус 200,
имея в виду «у нас нет проблем с обменом данными, все в порядке с доступом»,
ну а содержание сообщения это уже другой вопрос.

Тем более, может я хочу одни и те же JSON сообщения отправлять через
HTTP, AMQP, ZeroMQ…

Хорошая клиент-серверная архитектура

Мне тоже нравится идея возвращать только статус.
Однако возвращаю {'ok': false, 'error': 'Some valuable parameter is not provided}
А иначе как? Status 400 и описание ошибки в теле ответа? в виде HTML?
Спасибо.