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

Однако речь сегодня пойдет вовсе не об организациях как таковых, а о пластике. Менеджмент, как известно, не очень-то любит материальные методы мотивации сотрудников (и правильно делает), зато очень любит различного рода пластиковые награды, статуэтки и плашки, призванные оценить успехи. Между тем, главное правило при проведении подобных мероприятий – «Не навреди!».

На удивление, в русскоязычном сегменте интернета (и на Хабре в том числе) до сих пор крайне мало информации о PubNub. Между тем, основанный в 2010-м году калифорнийский стартап успел за последние семь лет вырасти в то, что сама компания называет Global Data Stream Network (DSN), а по факту – IaaS-решение, направленное на удовлетворение нужд в области передачи сообщений в реальном времени. Наша компания – Distillery – является одним из на данный момент четырех development-партнеров PubNub, но сказано это не пустого бахвальства ради, а чтобы поделиться с сообществом вариантом использования PubNub на примере demo-проекта, который требовалось создать для получение оного статуса.

Те, кому не терпится посмотреть на код (C# + JavaScript), могут сразу пройти в репозиторий на GitHub. Тех же, кому интересно, что умеет PubNub, и как это работает, прошу под кат.

Вступление

Наверняка первый вопрос, который возник у вас при взгляде на заголовок, был "Шта?". На самом деле я просто перевел фразу "Инверсия управления, внедрение зависимости" в Google Translate на китайский, а затем обратно. Зачем? Затем, что на мой взгляд, это хорошая иллюстрация того, что происходит на самом деле. Люди вокруг путают, коверкают и извращают эти понятия. По долгу службы я провожу много интервью, и 90% того, что я слышу, когда задаю вопрос про DI — честно говоря, откровенный бред. Я сделал поиск по Хабру и нашел несколько статей, которые пытаются раскрыть эту тему, но не могу сказать, что они мне сильно понравились (ладно, ладно, я проглядел только три первых страницы, каюсь). Здесь же на Хабре я встречал в комментариях такую расшифровку IoC, как Injection of Container. Кто-то всерьез предполагает, что есть некий механизм инъекции контейнеров, который сосуществует где-то рядом с DI, и, видимо, даже делает нечто похожее. Только с контейнерами. Мда. На самом деле понять внедрение зависимости очень просто, надо всего лишь…

Отодвиньте на несколько минут клавиатуру, возьмите в руку горячую парящую кружку кофе, представьте, что на вас надеты теплые шерстяные носки с оленями, откиньтесь в кресле и наконец-то расслабьтесь. Конец года, можете себе позволить, в конце концов. Даже если на носу дедлайн, а работать сверхурочно 31-го декабря ой как не хочется. Какой же нормальный заказчик заставит своего программиста спешно деплоить непротестированный код на продакшен в самый канун праздника? Вы прищуриваетесь и слегка ухмыляетесь уголком рта, ведь вас не провести. И не таких видали! И откуда только они берутся? Кто-то советует им плохое, не иначе. А они люди наивные, верят всему. Вот бы хоть глазком взглянуть на эти вредные советы, из-за которых клиенты ну никак не могут найти общий язык с нами, простыми и добросовестными разработчиками в носках с оленями!


P.S. Все примеры взяты из реальной жизни и усердно выковыряны из недр одной известной онлайн-биржи труда, название которой я вам, конечно, не скажу, но вы и так, конечно, догадаетесь.

-Я хочу устроить панику, понятно?
-Ты там бойню устроишь, а не панику.
«Большой куш»

В течение уже достаточно долгого времени мне попадаются на глаза посты, статьи и даже целые книги, задача которых — донести до читателя советы о том, как правильно делать Скрам. Все они, в общем-то, однотипны и построены на предположении, что большинство людей некорректно понимают предлагаемые практики, их назначение и важность. В этих источниках активно доказывается, что Скрам все-таки работает, говорится о принятии ценностей, о перестроении мышления на уровне компании, о тонкостях организации митингов и прочих нюансах, которых по итогам каждый раз набирается вагон и маленькая тележка. Судя по всему, проблема действительно существует, ведь даже Кен Швабер и Джеф Сазерленд описывают Скрам как “легковесный, простой в понимании и сложный в овладении” [1]. Но только ли дело в практиках? Может быть, люди не понимают саму суть Скрама? Когда что-то начинает приносить серьезные деньги, то не секрет, что именно прибыль становится путеводной звездой этого корабля. Может быть все эти тренинги, сертификации и спешно переучивающиеся в скрам-мастеров менеджеры проектов затмили собой изначальный посыл? Вполне вероятно. Но так ли это? Данный опус — это попытка взглянуть на проблему под немного другим углом, с точки зрения больше технической, чем какой-либо еще.

Здравствуйте.

Многим наверняка приходилось в своей жизни проектировать и разрабатывать RESTful API. С релизом технологии Web API делать это стало гораздо проще, а с выходом Web API 2 еще и куда приятней. Система раутинга, перекочевавшая из ASP.NET MVC, отлично справляется со своей задачей, и позволяет нам не только свободно конструировать пути, но и приправлять их различными параметрами, указывая оные в фигурных скобках. Вряд ли шаблон вида «api/{controller}/{id}» вызывает нынче у кого-то благоговейный ужас. Однако что произойдет, если какой-то из методов нашего API в качестве этого самого {id} будет принимать не число в строковом представлении, не Guid, а, скажем, адрес электронной почты? Ну, например, чтобы проверить наличие этого адреса в базе данных. Работать тогда ничего не будет, а виной всему маленькая и, казалось бы, совсем безобидная точка. Как с этим жить дальше и рассказывается под катом.

Без лишних проволочек, предположим, что вы попали в следующую ситуацию:

• у вас есть некоторый .NET проект;
• для этого проекта вы написали NUnit-тесты (либо они уже написаны);
• вам торжественно вручили Visual Studio 2008 Team System (или выше) или Visual Studio 2010 Premium (или выше) и поручили провести анализ покрытия кода тестами (aka code coverage).

Путь вам преграждает только одно маленькое «но»: Test Runner, интегрированный в Visual Studio, видит только собственные MSTest'ы, а вашему любимому NUnit'у уделяет ноль внимания и преподносит фунт презрения. Что делать?

Не так давно в рамках разработки крупного ASP.NET проекта возникла следующая подзадача: реализовать визуальное отображение табличных данных, обновляющихся в режиме real-time. Схема обновления довольно проста, а именно: на сервер посредством QueryString присылаются данные, которые должны как можно быстрее заменить собой устаревшие данные на странице, причем без необходимости страницу эту рефрешить. Первым решением, которое сразу же пришло мне в голову, было использовать ставшую уже общепринятой технику AJAX-запросов по таймеру, скажем, каждые 5 секунд. Однако сразу же выявились очевидные недостатки применения такого подхода: во-первых, довольно внушительное число потенциальных клиентов, дергающих сервер каждые 5 секунд с созданием каждый раз нового соединения, а во-вторых, это все-таки довольно грубая эмуляция real-time'а, ведь данные на сервер гипотетически могут приходить даже по несоколько раз в секунду (а могут не приходить и по несколько минут, и это уже больше относится к «во-первых»).

Идея решения пришла довольно неожиданно от коллеги по работе, поделившегося линком на статью на Хабре, описывающую реализацию технологии Comet на Perl в целях создания веб-чата. "Comet — это то что нужно!", — подумали мы, и я начал разбираться, как же эту штуку можно прикрутить к ASP.NET. О чем, собственно, и пойдет речь под катом.