Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

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

Это пятый вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 5 мин.):

Темы и детали видеозаписи под катом

ВВЕДЕНИЕ

В 1991 году я проходил студенческую практику на одном из предприятий в области энергетики. Задача, которую мне предстояло решить – разработать программу для контроля поручений, выдаваемых руководителями. Программа называлась «КИП – контроль исполнения предписаний». Как мне тогда казалось, задачу я решил. Трудно было предположить, что к этой теме мне предстоит вернуться через 12 лет и превратить ее в основной предмет своей деятельности – разработку и внедрение систем электронного документооборота. 20 лет спустя оказалось, что тема эта столь же актуальна, а попытки ее решить, далеко не всегда приводят к ожидаемым результатам. Почему это происходит?
Причин, наверное, много. Ограничения по срокам и бюджету, квалификация и мотивация персонала, проектная методология, политическая конъюнктура – эти и другие факторы содержат предпосылки проектных неудач. Хочу предложить еще одно объяснение проблемам, возникающих в ходе внедрения и эксплуатации систем электронного документооборота.

---

UPD. Вторая версия бенчмарка тут: eric.themoritzfamily.com/websocket-demo-results-v2.html

---

Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.

Подробнее о проблеме 10000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений

Как с проблемой 10000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Python (ws4py)?

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

К моменту, когда у нас возникло желание попробовать новую систему организации процесса, мы были сработанной командой, ведущей успешную Scrum разработку.

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

Это третий вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 12 мин.):

Темы и детали видеозаписи под катом

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Недавно я публиковал здесь свой слайдкаст с рассказом о 6-сигмах, контрольных картах Шухарта и людях снежинках, где достаточно простым языком, местами злоупотребляя сквернословием, под 20-ти минутный хохот слушателей рассказывал о том, как отделить системные вариации от вариаций, вызванных особыми причинами.

Теперь хочу подробно разобрать пример построения контрольной карты Шухарта на основе реальных данных. В качестве реальных данных я взял историческую информацию о завершенных личных задачах. Эта информация у меня есть благодаря адаптации под себя модели личной эффективности Дэвида Аллена Getting Things (про это у меня тоже есть старый слайдкаст в трех частях: Часть 1, Часть 2, Часть 3 + Excel-табличка с макросами для анализа задач из Outlook ).

Постановка задачи выглядит так. У меня имеется распределение среднего числа завершенных задач в зависимости от дня недели (ниже на графике) и нужно ответить на вопрос: «есть ли что-то особенное в понедельниках или это всего лишь погрешность системы?»



Ответим на этот вопрос при помощи контрольной карты Шухарта – основного инструмента статистического управления процессами.

Введение

В процессе разработки, создавая новый функционал, всё чаще широкими мазками стал задевать старый код чем разрушал логику его работы. Это заставило всё-таки написать юнит и интеграционные тесты для старого кода и автоматизировать их запуск, т.к. гонять руками все тесты как-то грустно. Как раз вспомнилось недавнее руководство по CI Django в Jenkins и довольно старое по Webtest в Django. В итоге была совершена попытка поднять Дженкинса, но он как-то на моей убунте не взлетел и я грешным делом вспомнил про TeamCity. «Раз уж пишу в PyCharm и нашёл к нему подход, то, наверно, и TeamCity осилю, ведь конторка-то одна!» — подумалось мне… В общем-то я оказался прав, и, пока мне позволяет карма, решил подарить вам ультраполезный (и мегаподробный), в отличие от моего предыдущего, мануал :)

Итого: кому требуется руководство по поднятию интеграционного сервера TeamCity, и тестирование в нём Django проектов c тестами nose и webtest в виртуальном окружении python с автоматическим его (окружения) обновлением — добро пожаловать под кат.

Осторожно! Для работы TeamCity требуется (согласно документации) sun/oracle версия JVM…

Это шпаргалка раскрывающая раздел «Интеграция Selenium тестов» статьи Настройка Jenkins для django проекта с нуля. А именно как запускать Selenium тесты на удалённом сервере Jenkins у которого нет монитора и форточек.

Перевод статьи Джейсона Фрида (Jason Fried) "Why I Run a Flat Company". Джейсон — один из основателей компании 37signals и соавтор книг "Getting Real" и "Rework".

Несколько месяцев назад в компании 37signals, которую я возглавляю, случилось необыкновенное событие: мы расстались с одним из наших сотрудников. Казалось бы, что в этом необычного? Но дело в том, что в нашей компании подобное происходит крайне редко. За 11 лет работы мы потеряли всего лишь пять человек, причем один из них вернулся к нам семь лет спустя.

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

Вы в Интернет кафе и вам срочно надо нарисовать что-то в MS Visio? Не волнуйтесь, зайдите на Diagram.ly.

Доброго времени суток, уважаемые читатели! Не так давно мной была опубликована первая часть статьи на данную тему. Я хочу еще раз поблагодарить всех пользователей, высказавших конструктивную критику, благодаря которой примеры в статье удалось привести к почти идеальному виду. В то же время я понял, что данный формат подачи материала является неэффективным: мы рассмотрели всего пару методов, реализованных в Class Based View (далее по тексту CBV). Во второй части я решил переработать подачу и далее постараюсь описать максимально возможное количество методов, представленных в API. Постараюсь, также, охватить те методы, которые были упущены в первой части. Очень надеюсь на конструктивную поддержку читателей и надеюсь, что и в дальнейшем у нас получится продуктивный диалог, в результате которого статья станет еще более информативной.

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

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

Коротко:

• Покрытие кода unit-tests
• Selenium
• Автоматическое тестирование
• Подробное декларирование каждой ошибки
• Еженедельный анализ и оценка обнаруженных багов
• Синхронизация с Acunote

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

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

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

Прочитал пост "Проблемы при внедрении Agile" хабрапользователя adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.