Издательство Питер решило представить недавно выведшую книгу от автора бестселлера «Карьера программиста», которая поможет вам наилучшим образом подготовиться к собеседованию при приеме на работу менеджером проекта в крупную IT-организацию или перспективный стартап. Основную часть книги составляют ответы на технические вопросы и задания, которые обычно получают соискатели на собеседовании в таких компаниях, как Google, Microsoft, Apple, Amazon и других. Рассмотрены типичные ошибки, которые допускают кандидаты, а также эффективные методики поlготовки к собеседованию.

Введение

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

В этой статье я расскажу о следующем:

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

Впервые слышите о tornado? Слышали, но боялись асинхронности? Смотрели на него более полугода назад? Тогда я посвящаю эту статью вам.

Введение

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

• Создание более простой, чем целый документ, единицы управления проектом (требование). Прочитать и подтвердить одно требование намного проще, чем согласовывать целое Техническое задание.
• Указание связей между требованиями. Такая возможность позволяет отслеживать изменения в связанных требованиях. Т.е. если что-то изменилось, то далее система может выделять все элементы, связанные с измененным, как подозреваемые на изменение.
• Выбор представления набора взаимосвязанных требований. При большом количестве требований иногда необходимо представить всю картину их взаимосвязи. Кому-то удобнее просмотреть эту информацию в виде таблицы (матрицы трассировки), кому-то в виде иерархического дерева, кому-то в виде сетевых графиков (статья Системы управления требованиями: что и зачем?).

Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS, Borland Caliber, Polarion Requirements и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.

     Доброго времени суток, уважаемые читатели. В этом посте я хотел бы описать несколько примеров развертки mongoDB, отличия между ними, принципы их работы. Однако больше всего хотелось бы поделиться с вами практическом опытом шардирования mongoDB. Если бы этот пост имел план, он бы выглядел скорее всего так:

1. Вступление. Кратко о масштабировании
2. Некоторые примеры развертки mongoDB и их описание
3. Шардинг mongoDB

    Пункты 1 и 2 — теоретические, а номер 3 претендует на практическое руководство по поднятию кластера mongoDB и больше всего подойдет тем, кто столкнулся с этим в первый раз.

Поддержка SOAP (как сервера) в Rails ухудшалась от версии к версии. В версии 1.x рельсы комплектовались AWS. В версии 2.x AWS распался на несколько форков, которые поддерживали энтузиасты. До версии 3.х, в стабильно работающем исполнении, AWS не дожил. Идеологически подобное отношение к SOAP может нравиться или не нравиться, но в реальной жизни мы окружены великим и ужасным Enterpris'ом. И поддержка двустороннего SOAP'а может понадобиться в любой интеграции: от 1С, до автоматизированных банковских систем.

Вместо поддержки еще большего количества (мертворожденных?) форков AWS для 3-ей версии, мы написали WashOut.

В данном посте речь пойдет о способе аутентификации человека по динамике написания рукописного пароля (подписи). В последнее время к этому направлению проявляется огромный интерес, и связано это в первую очередь с распространением мобильных устройств с сенсорными экранами. Согласитесь, было бы здорово получить по почте документ, открыть его, пальцем нарисовать свою подпись и отправить адресату. При этом документ будет иметь юридическую силу. За рубежом – это уже давно реальность. В России пока доверяют подписанному бумажному документу, либо электронному документу с официально зарегистрированной ЭЦП.

Существенным недостатком ЭЦП является то, что она может быть передана другому лицу, т.е. в отличие от традиционной подписи она является отчуждаемой от своего владельца. При этом будет сохраняться юридическая значимость документов подписанных ЭЦП посторонним лицом, что в некоторых случаях может оказаться недопустимым. Если же объединить ЭЦП и биометрическую подпись в электронном документообороте, то можно решить проблему неотчуждаемости юридически значимой ЭЦП от её владельца!

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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

Одна из главных проблем руководителя — это получение актуальной информации о ходе проектов, за результаты которых он отвечает. По моей практике, до внедрения PPM руководители тратят очень много времени просто на то, чтобы проверить, что всё везде идёт по плану. Грубо говоря, 60% рабочего времени может уходить просто на то, чтобы понять, что все справляются, и вмешиваться не надо. С другой стороны, после внедрения PPM всю эту работу делать уже не надо – она делается автоматически системой. А вам только приходят алерты для ситуаций, в которых требуется внимание. Получается удобный и очень практичный инструмент управления по исключениям.

Ниже — короткий ликбез про то, что это вообще такое, когда и для чего внедряется, как суровая российская реальность меняет процессы и несколько советов из практики. И рассказы про 4 самых интересных внедрения из моей практики.

В этом обзоре мы поговорим про бесплатные курсы виртуальной академии Microsoft MVA, которые будут полезны как ИТ-профессионалам так и разработчикам программного обеспечения.

Новый. Начинаем разработку на языке HTML5 с использованием JavaScript и CSS3
Этот курс представляет собой краткое введение в HTML5, CSS3 и JavaScript, которое поможет учащимся освоить основы программирования на HTML5/CSS3/JavaScript. Основное внимание уделяется реализации программной логики с применением HTML5/CSS3/JavaScript, определению и использованию переменных, организации циклов и ветвлений, разработке пользовательских интерфейсов, получению и проверке введенных пользователем данных, их сохранению и созданию хорошо структурированных приложений.

Новый. Начало работы по созданию веб-приложений с помощью ASP.NET
Этот курс предназначен для опытных разработчиков приложений, которые собираются разрабатывать приложения для современных браузеров с использованием ASP.NET и Visual Studio 2012. Три лектора Microsoft с огромным опытом работы с ASP.NET подробно рассказывают о разработке веб-приложений с помощью ASP.NET 4.5 и ASP.NET MVC 4, позволяющих создавать веб-сайты, которые удобно просматривать c мобильных устройств, социальные веб-приложения и многое другое. Это курс для слушателей с уровнем знаний от среднего до продвинутого. Он поможет подготовиться к сдаче экзамена Microsoft 70-486.

Новый. Начало работы с ALM в Visual Studio 2012
Целевой аудиторией этого курса являются разработчики приложений, заинтересованные в применении подхода ALM (Application Lifecycle Management управление жизненным циклом приложений) для улучшения процессов разработки в среде Visual Studio 2012. Курс рассчитан на опытных разработчиков и соответствует критериям экзамена 70-498 по курсу MCSD: ALM.

Всем привет!
У нас хорошая новость! Уже в продаже книга «Универсальные методы дизайна». Эта книга является продолжением серии «Универсальные принципы дизайна». В этой книге в числе прочего на каждом развороте в левой части предлагается краткое текстовое описание метода, сопровождаемое ссылками на работы авторов.



Прототип: Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions
Publisher: Publisher: ROCKPORT
Publication Date: 17-Jan-2012

Книга доступна в печатном виде. До 9 ноября 2013 года для посетителей Хабры действует купон на скидку 20%. Чтобы получить скидку, при оформлении заказа введите код купона: 238650081c8186c9636cb

Аннотация:

В этой книге 100 наиболее популярных и эффективных методов создания высококачественных дизайнерских работ, без которых не обойтись ни одному современному дизайнеру, в какой бы сфере он ни применял свое мастерство.

Пуш-уведомления критически важны для мобильных приложений подключенных к интернету. Они позволяют бэкенду сервисов отправлять частые и своевременные обновления определенным пользователям и устройствам, которые затем могут быть представлены в виде обновлений живых плиток, всплывающих тост-уведомлений, бэдж-обновлений и так далее (обратитесь к этой серии статей для того, чтобы узнать больше). Представляясь в таком виде, пуш-уведомления – это, возможно, наиболее мощный механизм вовлечения клиента доступный разработчикам приложений на телефонах, планшетах и ПК.



Существует множество инструментов, которые могут помочь вам упростить работу с пуш-уведомлениями (Windows Azure Mobile Services, например, уже включает в себя такой функционал). С помощью этих инструментов отправка отдельных уведомлений одному отдельному пользователю – это сравнительно простая задача.  Тем не менее, постоянная отправка уведомлений с низкими задержками миллионам мобильных пользователей с учетом реальных требований по локализации, поддержке разных мобильных платформ, персонализации для пользователя становится гораздо более трудной задачей.

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

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

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


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

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

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

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

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

Действительно, при таком подходе view-файлы начинают выглядить лучше. Но кастомные элементы форм и хелперы становятся просто невыносимыми.

Но есть простой и элегантный способ как сделать их чище и проще…

Доброе время суток, дорогие хабравчане! Данная статья является продолжением топика, и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.

Стадию создания или разработки требований условно можно разделить на 4 этапа.

Суть проблемы

Бывают ситуации когда документы имеют много различных полей и необходимо иметь эффективные запросы по ним. Например есть документ описывающий человека:

{
    _id: 123,
    firstName: "John",
    lastName: "Smith",
    age: 25,
    height: 6.0,
    dob: Date,
    eyes: "blue",
    sign: "Capricorn",
    ...
}

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

В ноябре 2012 в МГТУ им. Баумана мы, Школа системного анализа,
провели открытое событие «Введение в профессию системного аналитика».

Наконец стала доступна первая часть видео, выступление
Сергея Нужненко на тему «В чём заключается работа системного аналитика»:

1. Мифы о задачах и ответственности. Смежные роли (5 минут): vimeo.com/61652862​

2. Риски и неопределённость. Место и задачи в проектном цикле (18 минут): vimeo.com/61968936

3. Окружение, предмет и модель работы. Типовые процессы (10 минут): vimeo.com/62449309

4. Аналитический цикл работы с информацией. Модальная логика (12 минут): vimeo.com/64330992

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

Фреймворк Ruby on Rails меня просто очаровывает, но до недавнего времени некоторую сложность представляла из себя генерация CRUD контроллеров.

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

• стандартный генератор scaffold_controller — ничего подобного нет, CRUD с простейшим дизайном
• nifty Scaffold — его разработка приостановлена, но все равно фильтрации и сортировки нет
• гем для DataTable — не прижился, он обеспечивает только представление данных, а код для фильтрации и сортировки пришлось бы писать самому

Долгое время не удавалось найти ничего похожего на полюбившийся мне виджет CGridView из Yii framework. Уже почти смирился с необходимостью писать свой велосипед, но наткнулся на DRY CRUD и хочу поделится опытом его использования. Может кому-то он окажется полезным, а может кто-то подскажет еще более подходящий инструмент.