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

В чем ее суть?

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

К чему же приводит такая «доброта»?

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

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

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).

Недавно наткнулся на ошибку в Android приложении Яндекс.Метро. Если бы был чемпионкой мира по синхронному плаванию, то обязательно спросил бы: «Кто создавал программу „для галочки“? Кто работал „на отшибись“? Кто слабое звено?». Недоумение вызывала не сама ошибка, а то, что она попала в приложение и всё ещё не исправлена.

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

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

В статье же мы будем рассматривать распространённые приложения, которые протестировать может любой участник команды. Давайте проведём небольшой эксперимент. Если у вас нет Android устройства, то попросите минут на десять у коллег или друзей. Скачайте приложение Яндекс.Метро и попробуйте его протестировать. Интересует актуальная на текущий момент версия 1.63 от 02.11.2012 сборка 159 (на Google Play стоит дата 21.01.2013). Для корректности проверки предлагаю снять галочку «Автообновление» в настройках Google Play.

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

Эта же ошибка может проявить себя не так явно:

Всем привет!
Хотел бы поделиться с Вами наиболее полной информацией о тенденциях и направлениях веб-дизайна уже в нынешнем 2013 году.

Добрый день/вечер/утро, уважаемые хабравчане и Вы, %username%!
Я занимаюсь разработкой приложений для Android, обожаю эту операционную систему и хочу поделиться своим опытом использования в своих проектах диалоговых окон. В первую очередь эта статья записка очень пригодится начинающим в области разработки для Android.
Также для новичков в этой отрасли рекомендую сперва прочитать вот этот пост уважаемого Hoorsh.
А теперь приступим к рассмотрению данного вопроса (у которого есть несколько подводных камней) под катом.

Скажу сразу, всю DOM-модель мы строить не будем, а лишь рассмотрим ее элементы и как с ними работать при помощи jQuery. Статья рассчитана на начинающих или тех кто хочет вспомнить как можно строить элементы «на лету», надеюсь кому-то это будет полезно.
Большинство веб-разработчиков сталкивается с необходимостью вставить какое-либо содержимое из js, возможно это ajax или событие. Но никто не задумывается о том что с вашим кодом возможно кому-то придется работать. И часто даже в очень известных плагинах можно встретить код такого типа:

var content = "<table>"
for(i=0; i<3; i++){
    content += '<tr><td>' + 'result ' +  i + '</td></tr>';
}
content += "</table>"

$('#table').append(content);

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

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

К счастью, царствию уныния и страха пришел конец. Встречайте переродившийся, красивый и удобный, полезный, логичный и пригодный к использованию Реестр Плагинов jQuery

Написать расширение для google chrome несложно. Но при написании первого раширения могут возникнуть (и возникают) вопросы. Большинство мануалов по написанию первого расширения расчитаны на использования манифеста первой версии, поддержка которого в скором будущем прекратится.

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

По работе мне несколько раз приходилось участвовать в собеседовании кандидатов на должность клиент-сайдера у нас в компании, смотреть на их познания в Javascript. Удивительно что никто из них не знал толком как же работает jQuery изнутри, даже те, кто отметил свои знания jQuery уровнем «отлично», увы.

У jQuery очень низкий порог вхождения, о нем часто пишут и используют всюду, где только можно (и даже там, где, в общем-то, не нужно), поэтому некоторые даже не смотрят на чистый Javascript. Зачем, мол, его знать, когда есть jQuery, а по нему — тонны примеров и готовых плагинов? Даже на Хабре видел статью про рисование на Canvas, где автор подключил jQuery и использовал его только один раз — для того, чтобы получить доступ к Canvas по его идентификатору. И не считал это чем-то ненормальным.

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

Многие C++ программисты, пишущие под Windows часто путаются над этими странными идентификаторами как TCHAR, LPCTSTR. В этой статье я попытаюсь наилучшим способом расставить все точки над И. И рассеять туман сомнений.

В свое время я потратил много времени копаясь в исходниках и не понимал что значат эти загадочные TCHAR, WCHAR, LPSTR, LPWSTR,LPCTSTR.
Недавно нашел очень грамотную статью и представляю ее качественный перевод.
Статья рекомендуется тем кто бессонными ночами копошиться в кодах С++.

Вам интересно ??
Прошу под кат!!!

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

Уважаемые хабровчане, как и обещали, мы с madkite выкладываем в общий доступ хак in-app покупок и проверок лицензий для Google Play. Все, что от вас нужно — рутованное устройство на Android. Работает на телефонах, планшетах, плеерах и даже телевизорах! Смотрим видео:

Не так давно мне стало любопытно, насколько сносно современные браузеры поддерживают HTML5 и я не нашел лучшего
способа, чем написать простейший 2D платформер. Помимо удовольствия от разработки игрушки и улучшения навыков в использовании JavaScript, в ходе развлечения кропотливой работы был накоплен определенный опыт и эмпирическим путем были найдены основные грабли, на многие из которых мне пришлось наступить. В этой статье я попробую кратко и с примерами резюмировать то, что вынес для себя из проделанной работы. Желающих создать свое высокопроизводительное JavaScript приложение, эффективно работающее с графикой, прошу под кат.

В некоторых странах уже начали приходить письма торрент счастья от провайдеров. «На вас поступила жалоба от правообладателя такого-то фильма что с вашего IP в такое-то время было скачано/роздано. И мы(провайдер) конечно пока не вправе без решения суда разгласить правообладателю запрашиваемую информацию о вас, но по решению суда будем вынуждены сделать это… »

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

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

Картинки кликабельны.

Form builder

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

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

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

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

Итак, я подготовил некий список неочевидных моментов, с которыми мне неоднократно приходилось сталкиваться на практике. Начнем:

Установка копирайта и публикация в портфолио

Очень часто при общении с заказчиком при запуске нового проекта конфликтным моментом становится размещение «марки» студии на сайте («Сделано в XXX » и пр.). Если данный момент никак не обозначен в договоре, то убедить заказчика прислушаться к вашим доводам бывает сложно. Часто проблемы возникают в самый последний момент, даже если изначально лейбл присутствовал и на макетах, и на тестовой зоне: «Ой, а мы не думали, что так и пойдет на основную версию сайта». Итак, что рекомендуется сделать:

В связи с тем, что накопилось несколько вопросов и решений по работе со временем, решил сделать небольшой обзор.

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

Второе место, куда я пошел за информацией, после Википедии, был Хабр. С удивлением обнаружил не обнаружил здесь блога, посвященного Prototype и более того, никакой информации «для новичков». Решил исправить этот недостаток.

Все заинтересованных — прошу под кат

ХО-ХО-ХО! Праздник к нам приходит! Всегда coca-co… HTML5!
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима «HTML5. Руководство разработчика» (DIVE INTO HTML5). Оригинал книги также есть в бесплатном варианте в Интернете.

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

Глава 1. Как мы сюда попали?

Приступим

Недавно я прочел высказывание одного разработчика для платформы Mozilla, где говорится о той напряженности, которая всегда сопутствует разработке стандартов:

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

Пока я буду рассказывать, как появился HTML5, помните эти слова.