Проверьте свой проект: вы летите или думаете, что летите?

Ниже вопросы, которые стоит задавать себе на старте проекта и время от времени на его протяжении.

Контрольные вопросы на старте проекта:

1. Что конкретно нужно сделать на текущем этапе? В целом? Есть ли чётко определённые цели каждого этапа? Как вы определите, что цели достигнуты? Соответствует ли текущий статус заявленным планам и целям или их необходимо корректировать?
2. Реалистичны ли эти цели?
3. Что случится, если цели не будут достигнуты в срок? Каков план действий?
4. Насколько этот проект значим? Например, зависит ли от него место вашей компании на рынке?
5. Какую выгоду вам, обществу и инвесторам принесёт проект?
6. Достаточно ли хорошо спланирован проект? Все ли в вашей команде понимают пункты плана одинаково?
7. Нужны ли внешние эксперты, например, юристы?
8. Есть ли у команды опыт работы вместе? Кто будет координировать команду? Важно ли для проекта работать именно вместе — или возможен труд одиночек? Отвечает ли каждый член команды за работу всех остальных?
9. Можно ли сократить размер команды? Если нет, то почему? Если да, то почему это не сделано?
10. Как вы будете компенсировать форс-мажоры с персоналом, например, что случится, если ваш ведущий разработчик сломает руку?

Я пишу сайты на asp.net mvc. В этих 16 главах я хочу рассказать, как я это делаю. Это некий учебник-справочник всех тех знаний, которые я накопил в течение трех лет.

Почему именно asp.net mvc

ASP.NET MVC я люблю потому что:

• Это .net. Я знаю .net и С#.
• Это компилируемый код.
• Это не ASP.NET WebForms, я работаю с html-кодом.
• Используется MVC-паттерн.
• Visual Studio – самое популярное средство разработки, в котором есть IntelliSense.
• Отличные инструменты отладки.

Иногда бывает любопытно подсмотреть, что пересылают туда-сюда разные Android-приложения по HTTP и HTTPS протоколам. Иногда даже при разработке собственного ПО удобно видеть весь трафик в реальном времени. Для реализации этих задач давно придумано много хороших программ, таких, к примеру, как Charles или Fiddler2. На самом деле их намного больше, вот только две вышеуказанные дают возможность нормально просматривать не только HTTP, но и HTTPS.

Трудности начинаются тогда, когда речь заходит о перехвате трафика между Андроид-устройством и внешним сервером. В случае незашифрованного (HTTP-протокол) трафика всё весьма тривиально (вот и инструкция есть) — разрешаем Fiddler2 внешние соединения, в Андроиде устанавливаем прокси сервером адрес нашей машины с Fiddler2 — и вуаля, всё работает. А вот на настройку перехвата HTTPS-трафика у меня ушло чуть больше времени.

Давайте напишем программу для создания своих собственных фильмов в технике Time Lapse. Завораживающее видео, снятое в этой технике с борта МКС, можно посмотреть здесь, более доступный вариант, который можно повторить с помощью описываемой программы — здесь.

Программа имеет простой интерфейс и несложный принцип работы:
• пользователь задает периодичность снимков встроенной камерой (например, 10 с) и желаемую частоту кадров генерируемого видео (например, 25 кадров в секунду);
• после нажатия кнопки «Старт»  программа каждые 10 секунд делает фотографию и записывает jpg-файл на SD-карту;
• процедура повторяется до нажатия кнопки «Стоп» и «Создать видео», после чего последовательность фотографий превращается в видео файл формата Motion JPEG, который показывает отснятый материал в 250 раз (25 * 10) быстрее реальной скорости происходивших событий.

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

Класс MJPEGGenerator, взятый с code.google.com, был слегка переделан в связи с тем, что в Android Java отсутствует пакет java.awt.

Процедуры работы с камерой были преимущественно взяты из материала Работа с камерой в Android, где есть хорошее описание примененных решений, проблема «залипаний» камеры после лока/анлока Android-устройства была устранена благодаря stackoverflow.

Программа была отлажена на планшете Prestigio MultiPad 7.0 Prime под Android 4.0.

Термин «скрам-бат» (от «scrum, but..») впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

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

Типичные примеры скрам-батов, соответственно, выглядят так:

• У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
• У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

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

Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.

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

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.

Классический подход обязывает руководителя проекта, в ускоренном режиме, проводить приоритезацию задач используя для этого категоризацию требований на основе классификации Эйзенхауэра. Результатом всей этой «приоритезации» может стать упущенная выгода, потеря конкурентного преимущества и 100% удовлетворенность процессом руководителя проекта. Другое дело, когда команда реализует требования, которые клиент с восторгом готов принять!
Личностей типа «сноллигостер» хочется предупредить, что они могут этот топик не читать, дабы не травмировать свою психику.
Всем остальным: Добро пожаловать в новый мир!

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

Но у меня была девушка, которая круто всё изменила, когда спросила, чего я жду.

В результате я продолжаю учиться и работать – но у меня уже есть свой проект. Свой, понимаете! Ощущения такие, как будто я только что стал папой (хотя я даже не представляю, как это вообще бывает).

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

На прошедшей недавно Winter Nights 2013: Mobile Games Conference я рассказывал об истории успеха нашей мобильной игры «Джаггернаут: Месть Соверинга» — о создании, подводных камнях процесса разработки, запуске проекта на разных территориях и о том, как игра смогла достичь рекордных позиций по скачиваниям в России и выйти на первое место в рейтинге приложений в Корее. Сегодня я хочу поделиться своим докладом на Хабре.

О раскрутке на Facebook’е русскоязычными специалистами по SMM (или просто людьми, которые с этим столкнулись) написаны уже, пожалуй, целые талмуды. Но есть ли польза от этого? Сотни статей пересказывают одно и то же: пригласите друзей, закажите рекламу, купите пару тысяч ботов… Многие из расхожих рекомендаций совершенно неэффективны на практике. И российские компании очень редко могут похвастаться активной социальной жизнью в Facebook-сообществе.



Мы хотим рассказать о своём опыте Facebook-раскрутки. Обратите внимание на то, что мы производим мобильные приложения для детей (а не приложения для самого Facebook’а), и это накладывает определённый отпечаток на наши методы, которыми мы пользуемся.

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

Сейчас появляется очень много материала про юнит и нагрузочное тестирования. Все поголовно пишут тесты, код создают исключительно через TDD, используют jmeter/ab. Однако, все тестирование очень тесно связано с тестовыми данными. А их нужно генерировать/писать. Проблема не стоит остро для юнит тестирования — накидал mock, погонял его и забыл. Но как быть с нагрузочным тестированием? Когда мне нужно не 1-2-5-10 объектов, а миллионы?

Большинство (php) разработчиков, которых я встречал, сталкиваясь с задачей нагрузочного тестирования своего кода, создают несколько фикстур руками и насилуют их (ab/jmeter). Полученный результат тестирования не является достоверным, но они об этом не думают. Более продвинутые пишут скрипты для генерации данных, закидывают в БД и после этого уже играются. Похвально, но таких значительно меньше, а сам способ мне не кажется идеальным — другой программист может не разобраться в говнокоде генерилки фикстур (ведь создатель писал это быстро и для утилитарных целей) и рано или поздно все либо пойдут по первому пути, либо начнут писать новую генерилку.

Ценность правильного составления фикстур сейчас недооценена, многие просто на это забивают из-за трудоемкости такой работы (представим 15-25 связанных таблиц, писать скрипт генерации фикстур будет весьма, кхм, интересно). Я прекрасно понимаю почему разработчики так поступают, и, когда появилась такая же задача, то решил не биться головой об стену, а поискать инструментарий для нормальной генерации связанных данных.

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

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

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Приятная новость для многих российских разработчиков игр и приложений поступила от команды Google Checkout. Подготовлено важное обновление, которое позволит разработчикам из Бразилии, России и Тайваня получать банковские переводы за продажи в Google Play через аккаунт Google Checkout. Очередной запланированный платеж девелоперы получат через аккаунт Google AdSense, однако в дальнейшем будет использоваться новый способ оплаты.

Некоторое время назад мною был написан Бизнес-план, Дизайн документ и Концепт документ по созданию игры.
К сожалению информация 2011 года, но думаю полезна коллегам.
Система показателей оценки геймплея придумана собственно мной, так что этот бизнес-план, целиком моё субъективное видение.

1. Введение

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

2. Возможности рынка

Для начала надо просто делать бизнес в русском интернете — это один из самых быстрорастущих рынков. Если говорить о конкретных бизнес-направлениях, большой потенциал — у проектов электронной коммерции и сервисов, основанных на социальных связях. И конечно, игры, игры, игры. Играть начинают люди, которые раньше играми не интересовались — например, на мобильном телефоне. Игры привлекают все новых и новых пользователей, и это продолжится. Просто оказалось, что среди огромного разнообразия контента наибольшей популярностью пользуются игры. Комбинация общения и развлекательных сервисов (особенно игр) очень хорошо работает.(1)
Российский интернет-рынок — один из немногих рынков, не переставших расти в кризис, по всем показателям: реклама, домены, хостинг, объем аудитории. Сегмент веб-разработки — не исключение.
Сегодня в 2011 году Интернет населяют 43 млн. россиян (39% населения). Из них активной аудиторией Рунета является 35 млн. человек, а 25 млн. посещают русскую сеть ежедневно. При этом 92% пользователей зарегистрированы хотя бы одной социальной сети, где ежемесячно бывает 25 млн. человек и 16 млн. — ежедневно. Доля пользователей Интернета в стране в среднем составляет: 92% в категории 12-24 года, 76% в населении 25-44 лет, 25% в населении от 45 лет и более.(2)

Рисунок 1 Пользуются интернетом хотя бы один раз.

1 Глава Mail.ru Group Дмитрий Гришин в интервью для Forbes Russia.

2 По данным TNS Russia – лидера в предоставлении комплексной медиа- и маркетинговой информации.

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.

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

UPD: получил инвестиции под свой проект в сфере обучения облачным технологиям

Здравствуйте уважаемые Хабравчане, особенно те, у кого есть идея своего стартапа! А вот с деньгами и осведомленностью похуже. Хочу Вам в помощь поделиться небольшой таблицей IT-инвесторов, которая была составлена для себя. Дело в том, что я также как и вы, обладаю минимум информации. Такие вопросы как: «к кому идти за деньгами», «как составить бизнес-план», и наконец «кому я вообще нужен со своей идеей» — давно стали навязчивыми.
Именно сейчас, после Новогодних праздников, самое время начать искать тех самых менторов, инвесторов, бизнес-ангелов, да и в целом зачитываться информацией на эту тему. Да, и у меня есть свой стартап, который перестал быстро развиваться и я активно ищу инвестора на дальнейшее развитие (О чем уже писал неделю назад).
Под катом таблица, со списком полезных ссылок, в помощь начинающим IT-компаниям.

Всем желающим использовать меню из браузера и новой камеры



добро пожаловать под кат.

Всем привет,



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