Первое видео курса

Массачусетский технологический институт выложил в свободный доступ курс лекций по теме «Теория и аналитика игры в покер» (на английском языке). Доступны видеолекции, конспекты и специальные заметки по курсу. Это событие – часть программы OpenCourseWare, которая посвящена организации бесплатного доступа к избранным лекциям института для всех желающих – даже для тех, кто не учится в нём.

Помните, как в школе многие говорят: «Ну зачем мы это учим, нам это не пригодится!»?



Так вот, лекции по покеру – пожалуй, могут оказаться не просто интересными, но и весьма полезными с практической точки зрения.

Лекции ведёт магистрант института Кевин Дезмонд, который получил степень бакалавра по финансам. И, что логично, его лекции как раз рассказывают о технологиях анализа и планирования, предназначенных для максимизации выгоды от игры на деньги.

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

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

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

AngularJS директивы – это клево

AngularJS является каркасом (фреймворком) для построения web приложений, который позволяет создавать сложные приложения достаточно просто. Одна из его лучших возможностей, это создание директив, которые являются повторно используемыми web компонентами. Это дает возможность создавать новые HTML теги и атрибуты, которые могут динамично отображать контент в ответ на изменение данных, и обновлять сами данные, в случае необходимости.
Это очень высокопроизводительный подход, поскольку он позволяет вам оборачивать сложное взаимодействие с DOM в повторно используемые пакеты кода.

По мотивам этой трансляции.

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

Введение

Разрабатывая и отлаживая проект в Visual Studio, вы, как правило, делаете это, компилируя код в Debug-конфигурации. На боевой же сервер проект выкладывается, откомпилированный в Release-конфигурации. И каждый проект рано или поздно разрастается настолько, что в нём появляется некий «отладочный» или «релизный» код — то есть, тот код, который должен работать только в одной из конфигураций. И если бы дело ограничивалось только кодом, то директива условной компиляции #if решала бы все проблемы. Но обычно за кодом ещё тянутся настройки, специфичные для каждой из конфигураций, а зачастую и разметка веб-страниц. В самом начале, когда такие проблемы только начинают появляться, и ещё не являются сильной головной болью, обычно используется банальное комментирование ненужных в конкретный момент строк с кодом/разметкой/настройками. Но это — Road To Hell в самом чистом виде. А вот о Stairway To Heaven я и хотел бы рассказать.



Когда я впервые столкнулся с такой проблемой и уже погряз в костылях из комментариев и наборов различных конфигурационных файлов, то в какой-то момент решил поинтересоваться чужим опытом, а также получше изучить возможности среды разработки и используемых инструментов. И внезапно выяснил, что все мои искусственные костыли являются абсолютно избыточными — проблема может быть решена стандартными средствами и без ухудшения читаемости кода. Итоги моего исследования я опишу в небольшом цикле статей, где рассмотрю и примеры проблем с окружением, и механизмы, с помощью которых весь код, настройки и html-разметку автоматически можно привести в нужный вид при публикации проекта. Речь при этом пойдёт о разработке ASP.NET MVC-приложений, как области, в которой я, в основном, и работаю. Однако, всё написанное будет применимо к любой .NET-разработке в Visual Studio.

На Хабре уже было немало материалов о том, как проводить качество вёрстки веб-проектов (вот отличная статья на эту тему) — как правило, речь в таких топиках идёт о коммерческих сайтах. В ходе развития образовательного проекта HTML Academy мы также столкнулись с необходимостью выработки критериев для оценки работ учеников.

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

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Предпринимая попытки постичь DDD вы наверняка натолкнетесь на этот паттерн, который часто тесно используется вместе с другим, не менее интересным, паттерном «Репозиторий». Этот паттерн предоставляет возможность описывать требования к бизнес-объектам, и затем использовать их (и их композиции) для фильтрации не дублируя запросы.

Пример

Давайте для примера спроектируем домен для простого группового чата: у нас будут три сущности: Группа и Пользователь, между которыми связь многие-ко-многим (один пользователь может находиться в разных группах, в группе может быть несколько пользователей) и Message представляющий собой сообщение, которое пользователь может написать в какой-либо группе:

Всем добрый день!

Бывало ли у вас такое, что вы долго думали над какой-то рабочей (или личной ситуацией), а потом вдруг раз! и все как будто раскладывалось по полочкам? У нас такое бывало неоднократно.

Вместо пролога. Более того, это в некотором смысле наша профессия — раскладывать по полочкам сложные ситуации. Потому что последние 7 лет мы с коллегами занимаемся обучением IT-специалистов и руководителей навыкам управления людьми и тому, что называется soft skills.

За время работы у нас накопилось какое-то количество инструментов, которыми мы решаем разные управленческие кейсы. И этими инструментами мы и задумали поделиться.

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

Все инструменты, о которых мы будем писать, очень простые. Либо это матрицы 2 на 2, либо 4 вопроса, либо что-то в таком же духе. Поскольку мы много работаем с менеджерами, то обнаружили, что матрицы 3 на 3 некоторым менеджерам уже сложновато воспринимать (хей, мы сами были менеджерами, знаем о чем говорим :)), а 2 на 2 — в самый раз, отлично заходят.

Какие-то инструменты придумали мы, какие-то позаимствовали у других умных людей, какие-то не знаем, откуда появились в нашей голове. Но они все полезные, да.

Являются ли эти инструменты серебряными пулями? Ясен пясен, нет. Но они совершенно точно помогают прояснить ситуацию, навести дистинкции и понять, в какую сторону думать. А решения все равно придется придумывать вам. До тех пор, пока не появится, наконец, справочник юных сурков по менеджменту.

Итак, довольно лишних слов, давайте перейдем к первому инструменту (всего мы планируем разобрать около 15 разных полезных концептов):

Современные SSD-накопители достаточно надежные, а с учетом того, что цена за 1 ГБ (в долларах) постепенно падает, то использовать SSD во многих случаях даже более рационально, чем работа с HDD. Но какой SSD выбрать?

Полтора года назад журналист Tech Report решил провести эксперимент по выявлению наиболее надежных SSD. Он взял шесть моделей накопителей: Corsair Neutron GTX, Intel 335 Series, Kingston HyperX 3K, Samsung 840, Samsung 840 Pro, и поставил все шесть на цикличный процесс чтения/записи. Объем памяти каждого накопителя составлял 240-256 ГБ, в зависимости от модели.

В этом году я успел уже рассказать о том, как выбирал мини-квадрокоптер за 20$ и о том, как нашёл для себя мини-квадрокоптер с камерой за 40$ и даже рассказал о том, как устроил мини-соревнования на коптерах в парке-музее «Коломенское». Но после каждой публикации ко мне поступало много вопросов именно о выборе бюджетного квадрокоптера, который умеет транслировать видео на пульт. Понятно, что многих людей интересует именно бюджетный вариант первого квадрокоптера, так как после моей статьи «Купить квадрокоптер и попрощаться с ним» многие стали свидетелями того, как за несколько минут я попрощался квадрокоптером за 500$, подвесом за 300$ и камерой за 600$, что в современной России очень не бюджетно.

Сегодня я решил объединить все мои знания о бюджетных FPV квадрокоптерах, сравнив лучшие из них.

Мой первый пост.
Центрирование блока относительно другого блока относительно часто-попадающаяся задача, это очередное ее решение. Для меня оно стало самым универсальным и покрывающим все кейсы, с которыми я когда-либо сталкивался.

Этот релиз знаменует собой начало нового этапа, в котором заложена основа чтобы сделать базу данных мощной, гибкой и легкой в управлении.
Изначально версия данного релиза была 2.8, но из-за важности изменений было принято решение переименовать его в 3.0

Основные нововведения и улучшения:

• Произвольные механизмы хранения, в том числе WiredTiger. Теперь api монго отделено от того как база хранит данные. Это позволяет создавать новые способы хранения данных, например InMemory.
• Высокая производительность и эффективность. Новый механизм хранения WiredTiger использует блокировку на уровне документа, что позволяет значительно улучшить производительность. Так же он использует алгоритмы сжатия данных и индексов, что значительно уменьшает размеры хранимых данных.
• Упрощенные операции через Ops Manager. Он позволяет проводить такие операции, как развертывание, масштабирование, модернизацию и резервное копирование в несколько кликов или вызов API. Улучшена система логирования.
• Улучшен аудит безопасности.
• Улучшен язык запросов и инструменты. mongoimport, mongoexport, mongodump, mongorestore и mongooplog теперь работают быстрее. Возможность смотреть план выполнения до запроса с помощью explain.

С более подробной информацией вы можете познакомиться здесь:
Официальный анонс 3.0
Анонс основных нововведений в Mongodb 3.0
Вебинар «Что нового в Mongodb 3.0»
pdf Что нового в Mongodb 3.0

Ratchet — так называется HTML5-фреймворк для быстрого прототипирования мобильных приложений, который 1,5 года назад создали те же парни, которые когда-то выпустили Bootstrap.

Инструмент позволяет быстро создать красивый интерфейс мобильного приложения — и дает вам красивые стили и замечательные иконки, согласованные с гайдлайном в зависимости от платформы. Можно сделать прототип, а можно завернуть в PhoneGap и без особых усилий получить сравнимый с нативным интерфейс приложения в продакшене.
Фреймворк очень прост в использовании и прекрасно документирован.

Я являюсь поклонником Ratchet с момента выхода первой версии. Тогда он был доступен только под iOS.
Не так давно вышла вторая версия, которая наряду с iOS поддерживает Android. Ура-ура!
(правда, обратной совместимости с первой версией нет)

Кому интересно про новые возможности Ratchet 2.0 — прошу под кат!

К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».

Как мы избавились от JavaScript-библиотек социальных сетей, ускорили скорость загрузки страниц и использовали RESTful API для “шаринга” и “лайков”.

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

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

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

Хабрахабр, привет!

Возникала ли у вас когда-нибудь потребность отслеживать появление какой-нибудь информации на сайте, особенно если там нет рассылки новостей и RSS-канала!? Приходилось ли ожидать, когда опубликуют результаты экзамена, новые вакансии, тендеры, обновят прайс.

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

Результатом разработки стал сервис Websvodka.ru, о котором здесь кратко расскажу. Возможно, вам он тоже сможет пригодиться.